はじめに
私は社内のAI基盤を目指すkeelaiプロジェクトに携わっており、そこではオープンソースの開発方法を参考に誰でも提案やプルリクエストを送ることを推奨しています。この方法は全社アプリケーション実行基盤 KEELから継承しています。
しかし、実際にはそれほど多くの頻度で提案は来ないし、他のチームでも有効な場面も多いはずだと考えているのですが、その考え方も広がっていないように見えます。端的に言ってしまうと思ってたより盛り上がっていません😢
この記事では、主に社内向けに「社内オープンソース」という考え方や、その使いどころを解説して盛り上げることを狙っています。
社内オープンソースとは
『ユニコーン企業のひみつ―Spotifyで学んだソフトウェアづくりと働き方』では次のように説明されています。
テック企業のソフトウェア開発におけるもう一つ重要なプラクティスは、社内オープンソースモデルの採用だ。社内オープンソースでは、社内の誰でもいつでも他のメンバーのコードをチェックアウトできる。
誰が変更を提案してもかまわない。バグを修正していい。社内限定であっても、世にあるオープンソースと同じような考え方にもとづいている。
これはインナーソースという名前でも呼ばれることがあります。「オープンソースの開発スタイルを企業内で実践するインナーソースとは？ メリットとポイントを理解する」で説明されています。
keelaiは社内オープンソースモデルを採用することで、次のようなことを狙っています。
- keelaiのチームとしては、チームの枠を越えて開発をスケールできるようにしたい
- 社内の生成AI基盤として、別の開発者やチームにとって重要な機能のプルリクを受け付けたい
- 特に「LLM活用促進に向けたPlatform Engineeringからのアプローチ」にあるような機能をAPIとして提供しているため、他の開発者も必要に応じてプルリクを送れる状態にしたい
社内オープンソースを機能させるために必要なこと
ただ、実際にソースコードを公開するだけなら難しくなく、社内オープンソースを機能させるためには多くのことを工夫しています。
プロダクトの方向づけをするチームがいる必要がある
『ユニコーン企業のひみつ―Spotifyで学んだソフトウェアづくりと働き方』でも、「指針のあるコラボレーション」が必要だと述べられています。つまり、継続的にきちんと改善活動に役立てるためには、きちんとオーナーシップを持って、ある程度の方向づけをしているチームがいる必要があると思います。
社内オープンソースは「勝手気ままに」とはいかない。あなたが加えた変更は、システムの所有者によって検証されねばならない。これは良いことだ。自分で自分に必要な作業ができるだけでなく、それを一貫性のある、きちんとした設計で実装できる。こうすることで、誰でも変更が加えられることと、それをちゃんとしたやり方で行うこととの間で適切なバランスを保つことができる。
例えば社内オープンソースモデルを使って古い基盤システムの改善を行っても、方向づけができていないと散発的な改善に終わってしまうはずです。それを防ぐためには、そのシステムの方向づけをするためのチームをまず設置し、オープンソース的な開発ノウハウを身に着けている必要があると思ってます。
余談ですが、これはスクラムのプロダクトオーナーの役割に近いものと思います。しかし、「バザール方式の分散チームマネジメント」にも書いたように、プロダクトオーナーの役割も積極的に権限委譲しようとする点が違っていると思います。
一定の貢献が認められた開発者に対してContributor権限を付与することがある
Contributorには当該リポジトリのチームの一員として権限の範囲内であらゆる意思決定が行える
意思決定の際には以下に従うこと(KEELチームの文化より継承)mergeされた全ての変更の所有者はチーム全体となるため製造者責任はなく、チーム全体でリポジトリを所有することを求める
これはリポジトリ内の全てに対して変更を提案する権限があるということを意味する
CODEOWNERSで明記されている場合を除き特定の意思決定者も存在しないため、許可を求めずチームと相談しながら自身で意思決定すること
私はContributorなのですが、ある権限設定をしようするために許可を求めようとすると、「ブロック要因はなに？無ければやっちゃっていいよ」と言われて面食らったことがあります。というより未だに「ここまで勝手にやっちゃっていいの？」と思ってしまうことも多いです。
プロダクトチームが積極的に説明責任を果たす
方向づけするだけでなく、keelai（やKEEL）の開発では、次のように積極的にその意図や理由を説明しています。
- 方向づけするだけでなく、その理由や意図をドキュメントで説明する
- 主にドキュメントでカバーできない範囲は、Slackチャンネルやハドルで常設の相談窓口も用意している
これは、オープンソース開発の次のような考えを踏襲しています。また「バザール方式の分散チームマネジメント」から。
慈悲深い独裁者は「コミュニティ内で論議、論争が発生した際に最終的な仲裁を行う権利を持つプロジェクト創設者」という意味の用語である。また、『オープンソースの成功』では、リーナスのリーダーシップが「カリスマ的だが控えめ」と評されており、Linux初期の時代に次のように発言しているらしい。
「『コントロールを保つ』ことについてのぼくの立場を一言で言うと、保たない。Linuxに関して現在もきちんとコントロールできていることはただ一つ、誰よりもLinuxをわかっていることだ。」
コンセプトの完全性も放棄し、後から変更することもあるし、なんならコンセプト自体を完全にはコントロールしようとしない、ただ意思決定の説明はしっかり行うというスタンスのようだ。
コントリビュートしてくれた方からは次のようなコメントを頂いていて、ある程度は始めやすい形のドキュメントは整備できているのかなと思ってます。
keelai、最近よく使っていますが、ほんとすごいです
また、自身でkeelaiの動作試したい場合も、keelチームのみなさんが環境や手順を整備してくれていて、すぐに動作確認できました
今までと違うオープンソース開発の"ノリ"の普及が必要
ただ、最初に言った通り、このオープンソースモデルの導入は、当初の思惑ほどには盛り上がっていません。ただ、本当は生成AIの基盤をこの方法で作ることで、チームトポロジーで言うイネイブリングチームやプラットフォームチームとはかなり多くのコラボレーションができるはずで、受け入れ側としてはそれなりに準備はできていると思ってます。
私の視点では、いくつかのレイヤーで課題があるように見えています。ただし、あやふやにしか捉えられていません。
- 生成AI自体の可能性の説明が難しい。例えば私も「社内情報を使った自動テストやレビューができるはずだ」程度のことは大雑把な考え方は分かるが、テスト分野では専門家ではないためどれだけのことができるか分からない。だからなおさら提案してほしいし積極的な議論をしたい。
- （プロダクトマネジメントのノウハウが導入されて改善しているが、未だに）多くのチームで「プロジェクトにアサインされている」という感覚を持ってしまっていて、その計画外にあることをやりづらい。チーム外の専門家の力を借りて仕事する習慣が無いチームも多い。
- オープンソースの考え方と一緒に、プロダクトを方向づけるための方法も必要だと思う。
また、大きく権限委譲されて勝手に仕事を進めることが求められ、むしろ自分で意思決定しないと叱られるのも私は面食らいました。以前私は『伽藍とバザール』を読んでいたのでその意図が分かったのですが、こうした自律を求める文化自体の説明や、その中でどうモチベーションを保つのかは様々な工夫が必要になるんじゃないかと思ってます。
「社内向けAI botの運用で学んだ技術コミュニケーションのコツ」でも書いた通り、私はkeelaiや生成AIの使い方の社内発信やサポート面を担うことが多いです。しかしkeelaiを基盤として機能させるためにはそれだけでは不十分で、こうした社内オープンソースの考え方や動き方も普及させていく必要があると思っています。そのためにいろいろと実験していこうと思います。
まとめ
この記事では、社内のAI基盤を目指すkeelaiプロジェクトが、社内オープンソースの考え方を採用し、プロジェクトをどのような思想で進めているのかを解説しました。
この記事には次のような提案を含めているつもりです。
- LIFULLでは社内オープンソースの考え方に則った改善活動が行われることがあるが、実態として散発的な活動として終わってしまうことが多い。もしそうした改善活動を機能させたいのなら、まずはそのプロダクトを管理するチームを置いて、そのチームがオープンソース開発の考え方やノウハウを持っている必要があるんじゃないか？
- システム基盤を持つチームはContributeを受け付けてほしい。特に集客システムはバッチ管理のシステムを再発明してしまっているため、将来のシステム改善でこれらのバッチ基盤が一緒に管理できるようになると嬉しくて、その際に社内オープンソースのノウハウが役立つはずだと思っている。