Merpay Tech Fest 2021は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りで、2021年7月26日（月）からの5日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「技術発信のため文化とリレーション」の書き起こしです。
kiko：こんにちは、安藤です。
mhidaka：@mhidakaです。
kiko：今回のテーマは、これですね。
mhidaka：どれですか？
kiko：これ、これ、メルカリ・メルペイにおける「技術発信のため文化とリレーション」このテーマについて社外発信編と社内共有編に分けて話をしていきたいと思います。よろしくお願いします。
mhidaka：よろしくお願いします。
kiko：それでは早速まいりましょう。まずは、社外発信編から。パチパチパチパチ～。私のプロフィールはこちらです。
mhidaka：イエーイ！
kiko：現在、メルペイのTechPRや予算管理などのプロジェクトを担当しています。詳しく知りたい方は、動画を止めて見ていただければと思います。TwitterのDMを解放しているので、このあとのプレゼンを聞いて情報交換をしたいとか、詳細をもっと知りたいと思った方はTwitterからお気軽にご連絡ください。
技術発信の文化とリレーション 〜社外発進編〜
私、メルカリ・メルペイのTechPRを担当していて、よく聞かれる質問があります。
それは「御社のエンジニアって、よく技術発信していますよね。なんでそんなに発信するんですか？」「え、強制ですか？」「どんな人が関わっているんですか？」「どうしたら弊社もエンジニアの発信量が増えますか？」「参考にしたいので、ぜひ教えてください」こういったことをよく聞かれます。これに対して、これまで私が回答したことをお伝えしたいと思います。
その前に、メルカリ・メルペイって、そんなに技術発信してたっけ？と思った方へ、こちらが弊社エンジニアの直近1年間の発信・露出量です。メルカリエンジニアリングブログが120本、メルカンというオウンドメディアでの露出が70本以上、自社開催した技術系イベントや登壇した外部イベントの合計が約100、デベロッパー向けのYouTubeチャンネルの登録者増加数は2,000、この期間の累計PV数は、なんと66,000PV以上です。もちろん、領域やテーマに少し偏りがあるので、われわれが発信した内容をよく受け取る人もいれば、あまり受け取っていない人もいると思います。ですが、それなりの多さなのではないでしょうか。
先ほどの質問の回答に戻ります。
これらの質問の回答を結論から言いますと、まず、技術発信は強制ではありません。ただし、技術発信を促すためのルールや工夫、人々の努力があります。
そして、発信に関わっている人は、メルペイエンジニア組織全体の約20～30％です。関わり方はさまざまで、発信者として表に出る人もいれば、運営担当として発信の場をつくったり、ほかの人を推薦したりと裏方的な動きをする人もいます。発信に関わる頻度も人それぞれで、毎月発信しているつわものもいれば、マイペースに発信したり、しなかったりする人もいるし、今までに一度も発信したことがない人もいます。
そして、自社の発信量を増やすために重要なのは「三方良し」という考え方です。この言葉を初めて聞いた方もいるかもしれませんが、これは「いい商売とは、売り手と買い手が共に満足し、社会貢献もできる商売である」という、近江商人の心得を示したものです。私はこれを「エンジニア良し」「会社良し」「業界良し」とし、いい技術発信とはエンジニア自身と所属会社が共に満足し、業界貢献にもなる内容であると言い換えてます。
なぜならば、メルカリ・メルペイのプロダクトは、多くのオープンソースで開発されたソフトウェア、社外のエンジニアのプレゼンやブログによる技術発信、日々の交流によって支えられているからです。これらのコミュニティ、技術発信、交流がなければ、メルカリ・メルペイが今のシステムをつくり上げ、多くのお客さまに価値を提供することは難しかったと断言できるでしょう。
このプレゼンでは、まず、メルカリ・メルペイにおける技術発信文化の歴史について、次に技術発信の推進担当がやっていること、最後に技術発信における「三方良し」の考え方、この3つについてもう少し解説していきます。
技術発信文化形成の歴史
まず、技術発信文化の歴史について。
メルカリ・メルペイの文化が形成されるきっかけとなったのは、何だと思いますか。時は2015年、当時のメルカリCTOだったsotarokさんの存在が大きいです。2015年といえば、メルカリ初期リリースからの2年後、社内は少し落ち着いてくるころ。エンジニアたちは日々多くの技術的課題に挑戦しています。その様子を見て「うちの会社には、すごいエンジニアがたくさんいる。もっと多くの人にこのことを知ってほしい。今ならやれる！」と思ったCTOは（ここの発言内容はイメージです！）メルカリの技術発信を推進し始めます。
推進初期にやったことは、この3つ。まずは想いを言語化し、社内に共有すること。具体的には、社内向けwikiで「みんな、エンジニアブログを書こう」「目的はこれでこんな効果が見込めるんだよ」というCTO通信を執筆したり、このwikiがあることで、あとから入社したエンジニアもCTOの技術発信への想いを理解することができました。2つ目は、制度の整備です。具体的には、技術系カンファレンスのスポンサーや参加時のルールといったものが策定されました。また「技術発信を評価に反映するぞ」と断言もしました。3つ目は、CTO自らがエンジニアに声をかけること。例えば今度開催される、ほげほげカンファレンスのCFP「〇〇さんのあのネタ、出せるんじゃない？」「その事件、ブログに書こうよ」といった具合に。そして、実際に発信されたものにはできるだけ目を通し、感想を伝えたりもしていました。
これらの取り組みは状況に合わせてアップデートされ、現在にもつながっています。1つ目については2020年、去年ですね。メルカリ・メルペイCTO VPoEによって内容が遂行され「技術広報の方向性」というドキュメントにまとめ直しました。2つ目についても、過去策定されたルールや仕組みのフローが見直され、ブラッシュアップされて存在しています。3つ目に関しては、私のようなTechPR担当者を採用し、技術発信の推進を任せています。
その他、具体的なHow toはたまにブログで公開しているので、気になる方はメルカリエンジニアリングブログにぜひ一度お越しください。ちなみに、現在、技術発信を推進するチームの名前は、Engineering Office Teamといいます。このチームについて詳しく知りたい人は、スライドの下部に記載しているテックブログやメルカリ記事をご覧ください。
技術発信の推進担当がやっていること
次に、技術発信の推進担当がやっていることについてです。理想を言うならば、担当者がいなくてもたくさんの技術発信がされていたいですよね。しかし、現実はそうではありません。それでは、推進担当者がやっていることはどういうことになるでしょうか。
技術系カンファレンスのスポンサー実施にあたり、提案者のエンジニアと一緒にプラン内容やコンテンツを考えたり、発信量を増やすため、領域の偏りを減らすため、リードの人たちといつどのような発信ができるだろうかと考えたり、ブログの公開本数を増やすため、自社独自の特集を組んだり、アドベントカレンダーの企画をしたり、メルカンに出演してほしいエンジニアを考えたり、これらの施策は毎回振り返りを行い、次にやるときにもっとよくできるようにということも常々考えています。
技術発信における三方良しの考え方
最後に「三方良し」の考え方についてですが、ここでいう三方良しとは「いい技術発信とは、エンジニア自身と所属会社が共に満足し、業界貢献にもなる内容である」という考え方のことでしたね。
さて、技術発信を行うエンジニアのメリットは何でしょうか。1つ目は、発信された情報を整理したり、調べ直したりすることで自分の思考が整理できます。2つ目は、情報の受け手から存在を認知されたり、時には感謝されたりします。3つ目は、技術発信にリソースを割いて協力したことが会社から評価されます。
次に、会社のメリットは何でしょうか。まず、発信のために思考を整理したり、詳しく調べたりしたエンジニアの技術力がアップしますよね。そして、社外のエンジニアからのフィードバックで新しい知見やソリューションが生まれ、自社のプロダクト開発が進んだりもします。さらに、社外発信したエンジニアが所属会社名を言えば会社やプロダクトが認知されますし、技術発信から自社採用への動線をつくることだってできます。
最後に、業界のメリットは何でしょうか。まず、業界全体にオープンな知見が増えます。さまざまな知見が増えることで、初心者がつまずくポイントが減ったり、交流する仲間が増えてコミュニティー全体が盛り上がります。さらに、コミュニティーが盛り上がることで、よりテクニカルな挑戦がされて技術の発展につながります。
以上の技術発信におけるメリットについて、社内のエンジニアに「実際どうですか？」と聞いてみたところ、このような声をいただきました。
「技術発信をすることで自分の知識の編纂（へんさん）ができた」「発信したURLを渡せばいいから、繰り返しの説明が不要になって楽」とか「技術発信もちゃんと業務に見なされるし、給与にも反映されている気がする」とか「新しく入社した人から自分の記事を読んだんですよと言われる」とか「この技術をやりたかったのでメルカリ・メルペイを受けましたって聞くよ」とか「自分が運営発信してコミュニティーを盛り上げることで、そのプラットフォームがより進化していくんだよね」とか、実際にさまざまなメリットを感じているようです。
まとめ
それでは、最後にまとめに移りましょう。
情報発信は、自分、会社、業界の三者にメリットがあります。もちろん、デメリットやつらみもありますが、このプレゼンテーションを聴いている人や担当者にとってはメリットのほうが上回ると思うので割愛させていただきました。それから会社側は、エンジニアが安心して情報発信できるルールや仕組み、雰囲気をつくりましょう。エンジニアと共通の目的意識が取れないままだったり、エンジニア側のメリットを提示せずに無理して進めると一時的にはうまくいくかもしれませんが、いずれ崩壊を招くでしょう。
ぜひ、御社で行っている技術発信を推進するためのルールや仕組みについて発信してください。技術発信を推進する会社を一緒に増やしていきましょう。
以上、参考になれば幸いです。ちなみに私は、今、現時点で弊社のルールや仕組みは完成してはいないと思っています。より良い技術発信を続けるため、あなたの会社のルールや仕組みについて、ぜひハッシュタグをつけてツイートして教えてください。また、技術発信について個人や会社でまとめている人もいらっしゃると思います。あなたが過去発信した技術発信についてのプレゼン資料やブログURLもツイートしてください。メルカリ・メルペイの技術発信については、@mercaridevjpというTwitterアカウントで発信しています。まだフォローしてない人は、ぜひフォローしてくださいね。
以上、メルペイTechPR担当、安藤からの発表でした。ありがとうございました。続いて、エキスパートチームの日高さんの発表です。日高さん、よろしくお願いします。
技術発信の文化とリレーション 〜社内共有編〜
mhidaka：はーい。ご紹介ありがとうございます。皆さん、私の声は聞こえていますか。二次元の世界からお届けしたいと思います。kikoさん、ありがとうございます。パチパチパチパチ。
先ほどは、社外に対してどういうふうに共有していくかというところをお伝えいただけたかなと思います。僕のほうからは「技術発信の文化とリレーション～社内共有編～」という形で、組織内部について共有します。
私なんですけども、ご紹介にあずかりましたとおり、@mhidakaと申します。株式会社メルペイのエキスパートチームに所属していて、もしかしたらDroidKaigiのようなカンファレンスとか、技術書典というイベントでご存じの方もいらっしゃるかもしれないです。そういう方がいらっしゃれば、ぜひコメント欄で応援していただけるとうれしいです。今日は、メルカリ・メルペイという企業の中におけるお話という感じなので、もしかしたら皆さんの知らない姿、もしくはいろんなことやっているんだなという感想を持ってもらえるとうれしいなと思って準備してきました。
1つは、どういう技術共有の形があるかなというお話をするにあたって、エンジニア組織の背景というのを知ってもらおうと思って、こんなスライドを用意してきました。メルペイとメルカリどちらも同じ会社としてやってはいるんですけども組織の形が少し違いまして、最初にその形をご理解いただくのが、どういうアプローチが適切なのかというところが分かってもらえると思います。まず、メルペイのほうは、クロスファンクショナルなチームをベースにアレンジした組織になっていまして、縦軸ですね。
職能を置いてエンジニアであったりとか、プロデューサーであったりというところを縦軸に置いて、横軸にプロジェクトを用意しています。こちらのプロジェクトのほうは、職能のほうのチームから何人かが集まって1つのタスクをこなしていく。バックエンドのマイクロサービスとかは別の形になっていたりするので、あくまでこういう形なんだなと思っていただくというところと、メルカリのほうはもうちょっと違っていて、Camp Systemというものになっています。
考え方は大体一緒なんですけども、組織の単位が少し小さくなって動きやすくなっています。Campごとに、例えば出品数とかいろんなKPIを持っていますので、そこの部分についてアプローチをしていくという形の組織です。私はこの2つの組織にまたがって活動することが多いので、そのあたりがケアできる内容というのをお話ししていきます。
まずは、組織の中での技術共有という話をするときに、やはり合意形成の文化、どういう技術共有が良いのだろうというところに触れておきたいなと思って準備したのが、こちらのスライドと図です。
エンジニアリング組織、特にエンジニアが関わる部分、聞いていただいている皆さんもエンジニアだと思いますので、そういう人たちが自分たちのプロジェクトに関わる部分で、どこにボトルネックがあるんだろうなというのを考えてもらうために用意しました。この図ですが、よくあるソースコード、Module、設計、Architecture、設計思想という設計周りでソースコードにいけばいくほど変更頻度が高くて、具体性が高いというのを分かっていただけるかなと思います。
具体的なほど、チームのメンバー、エンジニアでの認識というのは不一致が起きにくいと。抽象度の高いArchitectureや設計思想というところに寄っていくと「将来どうしたらいいの？」とか「設計思想ではこう考えるのがいいんだよね」という、ベストプラクティスという認識のずれが起きやすいポイントかなと思います。なので、合意形成というのは、どこに向かってアプローチしていくべきか、これが主題です。
私は技術共有に関していうと、ドキュメンテーションを使うのが合意形成にもいいんじゃないかなと思っています。
1つは、コミュニケーションツールとしてのドキュメントというのをお話ししたいなと思うんですけども、ドキュメントを使うことで合意が取りやすくなって、組織がすごく回りやすいよねという状況というのがどういうものかというのを示したい。
さらに、こうやって皆さんとビデオでお話しするビデオ会議のようなシステムもありますし、Slackのようなツールを使ったチャットということもできると思います。その中でドキュメントという、いわば非同期ツールをどういうふうにうまく使えばいいのかというところに触れたいなと考えています。なぜかというと、ドキュメントというのはやっぱり「継続的なメンテナンスが難しいんじゃないの？」とか「技術共有はもうちょっと口頭でやったほうが早いよね」と思ったりするんですけども、このスライドの4番に書いてあるような意思決定の背景を残すことでガイドラインだったり、資料的価値だったりが発生します。
先ほどの図に戻ります。技術ドキュメントの利用を、特に組織を越えたり、組織の中でチームを越えたり、何かの壁を越えようとしたときには、ドキュメントというのは意思決定ツールとしてうまく活用できる。
メルカリ・メルペイでは、Design Docを使って設計のバックグラウンドを可視化しています。おおむねこちらの図でいうと、Architectureや設計思想に寄ったものに対して使っているかなという印象が僕にもあるんですけども、原則、変更が大きいところというのはやっぱりソースコードに書いたほうが良くて、コメントとか、Why、なぜなの？というのを書いていくと便利ですよね。ドキュメントは、ソースコードで表現できないものを補っていきましょうというところが主な使い方です。
ディスカッションツールとしてのDesign Docという前提で、どういうものをDesign Docと呼んでいるかというのを今からお伝えできればなと思うんですけども、詳細なものはこのあとサンプル用意していますので、それをぜひ見ていただきたいですね。まずは内容をザクッとお伝えします。
まず、ゴールやノンゴール、いわゆる何を目指しているのかという部分や背景、そして技術をどういうふうに使って設計しましょうという方針、今ある仕様に対する懸念や考察というものをカバーするのがDesign Docです。全部事細かに書いていると大変なので、今から話したい内容とか、これに注目していますねという主題に対して書いていきます。
技術選択・内容に集中できる、建設的な議論ができるというのがとても良いところです。議論のなかでヒートアップしてしまってどんどん論点がずれていったりとか、今決めなくてもいいのにというところを意図的に無視して、ちゃんと議論が前に進むというのが良いポイントです。悪い点もあって、やっぱり書くのに慣れてないと、とても大変なんですよね。なので、書く文化、そういうカルチャーとして定着するまでが少し長いというのがデメリットにあたります。
技術共有のためのドキュメントとして、先ほど例をお見せしますねと言ったんですけども、私のほうからはメルペイとメルカリ両方で使うライブラリ、フロントエンド側ですね、モバイル技術のライブラリについてルールが定まっていないときに用意したドキュメンテーションを例に取りながら紹介していこうかなと思います。
この右側の「目指すライブラリアップデートの姿」というスライドを用意しているんですけども、これが最終的なゴール、このような形を運用していきたいなと思っている姿だと考えてください。ここでは最終的に、ライブラリをもっと頻繁にアップデートして、どんどん最新の状態に追従したいなと考えているというのが、私の目指す良い姿だとドキュメントを通じてチームメンバーであったり、意思決定者に伝えていくというのがDesign Docの最初のステップです。
意思決定にあたっていろんなことを気にしていくとは思うんですけども、ゴールやそのほかですとソフトウェアの拡張性や安定性、将来的なスケーラビリティや保守に関わる部分など、取捨選択している自分の中の考えを言語化して、提案内容として非同期に書いていくというところが良い点です。
こちらのスライドも2つ用意しているので見ていただくとリリーススケジュールに組み込む場合とか、ソフトウェアの工程がある中で、オレンジ部分について今回話したいですよということを書いて示しています。それ以外に関しては、リリーススケジュールは変わらないんだなとか、運用保守に対しても今回は変更がないんだなというスコープが合っていく。こうやって何について話しているのかを明確にしていきます。
さらに、右側のちょっと大きめのスライドのほうですね。実際、開発支援をもっと強化したいと思っていますと表現しています。ライブラリのバージョン差分を分かりやすくして早く取り込みましょうという僕の主張に対して、ライブラリの更新の検出とか、PRの作成、プルリクエストですね。自動ビルドというところは自動化ができるよねと提案できる。
さらに、自動化しただけだと実は品質保証できているかわからなくて怖いから、CIによるユニットテストももっと強化しなきゃというところの私の主張に至る補強すべき道筋も図示しています。
全てを図で書く必要はないですが、技術的課題が明らかになるためには、ドキュメンテーション以外にもこうやって図をたくさん使ってディスカッションを有意義にしていければいいなと考えています。特に、こういうのは怖いよね、今動いているのを変えると大変だよねというリスク管理の視点では、私は「大きな変更」がリスクだと思っているんだけども、もしかしたら、ほかの人たちは「小さな変更」のほうがリスクだと思っているかもしれないと。
エンジニアリングの視点では、例えば「QAは変更したところにしかしないのに、実はライブラリの更新があって変更点がもっと広かったです」みたいな見落としがあるかもしれないですという、これは立場の違いから出てくる認識の違いだと思うんですが、そういうのもDesign Docさえあればカバーして「なるほど、ここを気にしているのか」というのを議論して解決することに導けると、非常に建設的ですよね。
ただ、私のつくったこのドキュメントは、実は、100ページぐらいあって、日英両方整備しているのでやりたいことに比例して大変な作業だと思います。なのでスモールスタートするポイントをご紹介したいと思います。
Design Docは普通に始めるだけだと、きょうお話しする技術発信のための文化という面ではちょっと大変なところがあるので、そこはテンプレートを用意するといいですね。ゴール、背景、設計方針、先ほど紹介したもの以外に、例えば誰がレビューするの？とか、どうやって履歴管理している？とか、このドキュメントはいつ変わったの？とかですね。
このドキュメントの参考文献とかドキュメントのリファレンス、そしてスケジュールやマイルストーンまで、これら共通の関心を全員が見られるように管理していくというのがテンプレートの良いアプローチだと考えています。メルカリは専用のリポジトリがありまして、モバイルチームはリポジトリを見て、こういうDesign Docがあるんだなとか、「過去にこういう議論があったんだ」とか「なるほどね、こういう結論にそのときはなったんだ」というのが理解できるようになっています。
このドキュメントを使った合意形成というのは、技術共有のためのツールとして紹介したんですけれども、議論自体を活発にするという良い効果があります。
なぜかというと、なんだか話しているけど進んだ気がしないぞということがなくなって、小さくても確実に進んでいるよねというところが分かる。ドキュメントがあるので考慮漏れがあっても私の人格が否定されているわけではなくて、技術的なポイントを指摘してくださってありがとうございますという感じでポジティブに受け取れる。そして、過ちを繰り返さない。議論の背景が残っているので、新しい話をするときにそこの議論はスキップできると。みんな読んでねということで済んじゃうので。その中で、どんどん新しい貢献やアップデートというのが見込めていけると。
先ほどはライブラリの更新という視点でお話ししたんですけども、Design Docは要件であったりとか、改善であったりとか、いろんなシーンで使っています。その中で新しい貢献があるというのはどういうことかというと、Design Docを使うチームメートは知識に差がある人たちで困っている人たちなんですよね、きっと。その問題を解決したいという人たちが1つのドキュメントをもとに一緒にコントリビューションできるというのがすごく良いところです。更に新しい人が入ってきたときに、なんでこうなっているの？と疑問に思ったところに、このドキュメントに全部書いてあって、チームの議論を伝えられるというのが良い点です。
技術発信のための文化とリレーションという形でお伝えしていたんですけども、ここまでのお話をまとめると、非同期に知識を伝えることというのはとても重要なんだなというのが理解いただけたと思います。そういうのが技術発信のためにドキュメンテーションを使ってみてはという提案のポイントにもなります。なぜかというと、スタックしていく知識なんですね。
発信するだけじゃなくて、ちゃんとたまっていくことによって雪だるま式というか金利がついて、どんどん良いものに出来上がっていきます。その金利を使って今後どういうアプローチで改善したいかという議論にまで発展し、意思決定合意形成が取れるという形だと非常にきれいに技術共有が回っている姿じゃないかなと思います。
ドキュメントというのは組織ごとに異なるので、きょうご紹介したものをそのまま使う必要は全然なくて、私が考えるに1ページのＡ4の提案書から始めてもらっても十分Design Docとしては有効でしょう。皆さまの組織やチーム、もっと小さく表現すると自分の考えをまとめるツールですね。そういう形で書き出していって、Design Docという形で共有してもらえると、多分それは社内の誰にとっても良いものではないかなと考えています。
これで、技術発信のための文化とリレーション社内共有編をおしまいにしたいと思います。kikoさん。
kiko：お疲れさまです。
mhidaka：皆さまもこれで得るものがあったらいいなと思います。この30分間のご清聴誠にありがとうございました。
kiko：ありがとうございました。
mhidaka：楽しんでほしいね、イベント。
kiko：そうですね。
mhidaka：お疲れさまです。
kiko：引き続きよろしくお願いします。
