「開発組織改善MTG」でPDCAサイクルを加速、エンジニアファーストな開発を目指して
AI開発の全プロセスをカバーするサービスやプロダクトを開発・提供するFastLabel。設立3年目の急成長株であり、同社VPoEの植野氏は「スタートアップでは、さまざまな価値あるものを創って世の中に提供するPMF（Product Market Fit）が基本。迅速なPDCAで仮説検証・改善することが望まれる」と語る。つまり、速いスピードで機能リリースを実施し、改善することが求められる。そのサイクルスピードを上げるのに、「開発生産性（Developer Productivity）」の向上が必要というわけだ。
開発生産性を上げる方策では、Linterの導入やTestの拡充など手段・ツールの話になりがちだが、植野氏は「それをどうやって取り入れるのか、組織や文化の方が重要ではないか」と指摘する。つまり、PDCAサイクルを高速化するには、メンバー全員の課題発見・解決能力を高め、仕組み化することが有効というわけだ。
なにか問題があった時、経営層やマネージャーが施策を打つこともできるが、現場の困りごとや事情は、現場の方がより深く熟知しているはずである。もしかすると、現場スタッフは既に解決のための最適解に気付いているかもしれない。そこで、FastLabelではボトムアップでの改善・対応が望ましいと考え、「エンジニアファーストな開発生産性向上」を目標として「開発組織改善MTG」を実施している。
このMTGでは、「よりよい開発のためにどうすべきか」をテーマに、毎週金曜日の夕方にプロダクト開発に関わるメンバーが集まって、ボトムアップでの議論・実践を話し合う。エンジニア出身の同社CEOも同席するなど、Unit（チーム）や役職に関わらずさまざまな立場の人が集まり、東京・大阪間をリモートでつなぐこともあるという。
MTG当日までに各参加者がNotionに用意されたリストへ「改善したい内容」や「問題だと感じる内容」などを記載する。MTGではリストから取り組み内容を議論して決め、その上で実践するという流れになっている。テーマは特に限定しておらず、「PCメモリの増設」から「AWSを自由に使える検証環境」「バッチやテストのCI希望」など、さまざまなトピックが出されている。開発に関わることであれば何でもOKというスタンスだ。
植野氏も「ソースコードのtypoが多いこと」に気づいたときに、メモするような気持ちでNotionに問題を提起したことがあったという。このときのMTGでは、スペルチェックができるライブラリ「cspel」の導入提案があり、結果的に導入・運用がスタートした。
また開発環境については、Dockerで構築し、環境ごとに差分を調整していたが、IntelやMacなどマシンによってはDockerfileに手を入れる必要があった。そこで、支給PCの統一や推奨スペックなどについても議論し、それまで個人のPCはおのおので購入していたものを、MacBook M2 Proに統一した。これについては、開発だけでなく人事や総務部門なども巻き込み、会社の制度として改革に至った。
開発組織改善MTGの落とし穴！ 積極的な課題抽出を阻む、意外な原因とは？
「開発組織改善MTG」の実施は一見簡単に見えるものの、植野氏によると「運用にはくれぐれも気をつける」必要があるという。その最たるものが「心理的安全性」の確保だ。たとえば、ある提案を行うと、提案者がその内容を一番理解していると思われ、問題解決の担当者にもアサインされてしまう。
組織やチームとして改善していこうと提案しても、結局自分が推進することになるのなら、提案をやめようという気分にもなるだろう。こうしたことを気にせず、問題の提案のみに集中することを大前提の場にすることで、心理的安全性を確保しようというわけだ。
この心理的安全性を確保するために、「①問題を提起する際、誰が書いたかがわかるように名前を書くが、実際の担当は話しながら決めていく」「②書いた時に解決策まで思いついていなくても構わない」という2つのルールを特に重視しているという。そのうえで、問題だと思ったこと、改善したいことをとにかくNotionにあげることを徹底した。
その結果、約半年間で全75件提言され、そのうち68件について解決に向けたアクションが取られているという。植野氏は「アジャイルと同様、毎週何か提起される問題があり、それに対してアクションが取られる状態がよい。完璧にやりきらなくても、ちょっとでも改善できるという積み重ねが大切」と評した。なお、必ず振り返りも行い、その進捗を共有することが重要だという。
なお、たいへん有用なMTGではあるが、新入社員をはじめ、全員がいる場で話すのが苦手という人も少なくない。そこでマネージャーとの定期的な1on1も実施し、別途不安や違和感などのヒアリングを行っている。開発組織改善MTGの外でも、そうしたフォローをきめ細やかに実施することが大切だ。
課題が「自分ごと」になる、FastLabelのエンジニア組織構成とは？
FastLabelの組織構成は、デベロップメント部門の下、「アノテーション」「データセット」などの5つの機能チームによって成り立っている。
一般的な、フロントエンドやバックエンド、インフラという領域ではなく機能モジュールごとに分かれているのは、コミュニケーションロスを回避することがもともとの目的だった。それがコミュニケーションだけでなく業務についても、各メンバーが領域を横断して取り組むようになり、幅広いスキルを身につけることに繋がっている。そのため、理解の深さに若干の違いがあるとはいえ、多くのエンジニアが複数領域をまたいで技術を理解し、さまざまな問題や課題解決に当事者意識を持って取り組む「自分ごと化」の土壌が整っていたという。
植野氏は、「通常は、フロントエンドで起きている問題に対して、バックエンド担当は関心を持たないという状態に陥りがち。しかし、機能モジュールで分かれた組織の場合、各人が領域横断的に関与できる形になっているため、さまざまな課題を共有できる。その結果、解決に対する議論も活発に行われ、生産性を上げるだけでなく組織に良い影響を与えるので、開発環境が改善されている」と語った。
植野氏は改めて「スタートアップ・ベンチャーは、機能リリースの速度を上げるために、開発生産性を上げる必要がある。そのためにはボトムアップで効率的に課題をあげ、解決するという、開発組織全体でのミーティングが有効であり、このとき心理的安全性を確保することが重要。また、職能横断的な組織構成や1on1ミーティングなども、開発生産性の向上の一助になるため、適切に行っていくことが大切」と語り、「設立からの3年で、開発組織づくりや事業スケールなど、0から1、1から10をつくってきたことがベースになった。今後もこのスピードをあげていく」と意欲を見せた。AI関連のサービス開発に興味のある方は、問い合わせてはいかがだろうか。
