エンジニアリングマネージャーをしています芦川です。2024年12月16日に GitHub Universe 2024 Recap in ZOZO に参加、登壇させていただきましたので、そのご報告いたします。
イベント内容としては、冒頭、GitHub 服部様によるGitHub Universe 2024のRecap（めちゃくちゃ丁寧な説明、copilot初心者の私でも分かる内容！）、続いて株式会社ZOZO 山田様によるiOS開発におけるCopilot For XcodeとCode Completion（3番勝負が非常に面白かったです！copilotの勝ち！）、同社佐藤様によるGitHub Copilot のテクニック集（すぐにでも使えるショートカットやプロンプトの書き方満載でした！）というところで、短時間ながらも非常に濃密な時間でした。
私の方からは、GitHubの活用事例として、インナーソースの取り組みをメインに話させていただきました。Ask the speakerの時間では、「偶然、今日、社内でインナーソース部を立ち上げてインナーソースを始めたところです！」という方もいまして、神の力か何かで引き合わせてくれたのかな、という、すごい引力を持った場であり、有意義な時間を過ごすことができました。ありがとうございます。
スライド全体はこちらになります。
どんな会社？エンジニア組織の構造？GitHub導入状況？
ここからは、スライドをピックアップしていき、話した内容を文章にしていこうと思います。
コラボレーション文化の話をするので、まず会社の組織構造についてお話しました。実際の職制とは異なりますが、チームトポロジーのチームタイプにわけるとざっくりこのようなエンジニア組織の構造になります。エンジニアは全部で約160名いまして、7-10名ほどのサブチームにわかれておりまして、内製開発がメインです。
注目するところとしては、ストリームアラインドがドメインの違いでざっくり2分割されている点だったり、あとは、コンプリケイテッドサブシステムでは、ISP独自のネットワーク部分を扱っているようなところでしょうか？
次にGitHub利用状況です。organizationは1つであり、Repository creationルールは、internalとしていて、組織内の誰でもリポジトリ閲覧可能をデフォルトにしています。一方、Copilot Metrics Viewerからみたcopilotの利用状況です。こちらの導入は全員ではまだありませんが、コード受け入れ率は31%であり、割といい感じなのかな、と思っております。言語はpython、エディタはvscodeが多いですね。
ここからインナーソースの話
ここからインナーソースの話です。
2022年の下期だったとおもいますが、私含めた周辺のマネージャーの中である悩みがありました。事業部からはもっとこうしたいという要望はたくさんでるのですが、開発リソースも限られている。外部発注もありますが、でも、キャッシュアウトせずにもっと内部でうまく回せるやり方や特定のチームへ開発依頼が集中してしまうような状況を打開するものはないかと。で、いろいろググったのですが、ここは衝撃的な出会いでした。この世の中には「インナーソース」というやり方があることを知りました。
最初に私が読んだのは、右のcodezineに乗っているという東芝の小林さんが書いた記事「オープンソースの開発スタイルを企業内で実践するインナーソースとは？ メリットとポイントを理解する」です。ものすごくわかりやすかったです。で、これ導入したら余力のある人がほかのチームの開発手伝えるようになるのでは？と安易に思いまして、組織に「インナーソース」とやらを導入したいと強く思ったわけです。
でいろいろとやり始めました。そのあたりのくだりは、以下の記事のほうが詳しいですので割愛しますが、なかなかうまくやれてきたのでは？と思っています。
また、今回の発表では、組織にこういう新しい流れをいれるときにエンジニアリングマネージャーとしてどのように動いたかについて新しく触れました。生々しい話にはなりますが、私としては、以下のようなことをしてきました。
- トップダウンで進んでいるようには見られたくなくて、1人現場メンバーの推進者を決め、そのメンバーから全社へ発信するように仕向けたこと
- 周りのマネージャーを巻き込み、事業計画としてインナーソース推進活動を公式化したこと
- インナーソースガイドラインでは、コントリビューターの評価や工数の考え方を含めたこと
- 業務の一環としてインナーソースコミュニティ運営に携われるようにしたこと
このあたりもうまくいったのかなあ、と考えています。もう少し、細かい話が書けそうなので、いつか「新しい取り組みをボトムアップで組織に導入するには？」みたいに抽象化したお題で書いてみたいと思います。
インナーソースがうまくいっているところ
個人で作ったツールへのコントリビュートや、業務に少し踏み込んだところだと、API利用者定義ファイルの追加について明らかにリードタイムを短縮できた事例などを紹介しました。このあたりの話は、小松の下記の登壇内容でもありますので、ここでは割愛いたします。
インナーソースがうまくいっていないところ
このブログでは、これまであまり語っていなかった、いまのところうまくいってないところを文章化しておきます。やってみていくと、ハマらないパターンもあることが体感としてわかってきました。例えば、ドメイン知識が違う同士のストリームアラインドチームのコラボレーションです。
ドメインが同じチーム同士であれば、ビジネスの方向が同じチームどうしてあれば、どちらのチームが提供しているAPIをお互い利用しながら、そこにコントリビュートが生まれる余地があるかと思うのですが、例えば、弊社の例でいうと、WEBサービスと、ISPサービスはかなり属性が違うというか、土俵が違うというか、ドメインがかなり異なるチームであり、そこにはコントリビュートするためのモチベーションがうまれないので、厳しいかな、と正直に思っています。（もちろん個人のスキルアップやチャレンジ精神というところは大歓迎ですが、ベースとして、という意味です。）
考えてみれば、コントリビュートは己や己のチームのためにまずやってみよう、と思うはずなので、そもそも協働するチームでなければ、やっぱりうまれないよな、と思ったところです。
つづいてはドキュメントへのコントリビュートです。ソースコードにPRを出すよりは圧倒的にドキュメントにPRを出すほうがハードルは低いと思います。が、弊社では、すべてのドキュメントがリポジトリで管理されてはなく、どうここを進めていこうか、と現在悩んでいるところです。どなたか助けてください。。もしかして、生成AIできれいなテキスト化ができるといい感じになるのでしょうか？
ここは用語が社内に先に広まった分、理解が実はあまり追いついていなかった？という想像です。新規プロダクト開発や、なにかの事情がありブラックボックス・運用保守コスト増になってしまったシステムの改善に関して、インナーソースは寄与しません！誤解なさらずように。
まとめ
で、まとめになります。
組織内でコラボレーション文化がどう作られるか、というところがインナーソースにチャレンジして見えてきました。
- まず、土台となるプラットフォームが必要です。つまりGitHubです。
- 次に、コラボレーションする方法の明確化が必要で、つまりインナーソースです。
- プラットフォームやコラボレーション方法だけではコラボレーションは生まれません。最後に、人間が必要ですが、大事な点として同じ方向を向いていること、つまりお互いがメリットを享受できる間柄である必要があります。
以上、3点が組織の後ろ盾（評価制度、工数管理など会社の動きの中で公式的に動けるか、という点）を行うことで達成されるのではなかろうか、というのが現時点での結論になります。
まだ道半ばでの途中の状態ですが、また進捗あり次第アップデートしていきたいと思います！
以上です。
