こんにちは。

株式会社オータムGMの長田です。

本日のテーマは「【チーム開発】開発生産性を底上げするアプローチとは」です。

チーム開発を加速させるには開発生産性向上が必要不可欠ですが、実際の現場の課題解決と迅速なニーズへの対応は簡単ではありません。

現在、オータムでは新規開発事業のひとつとしてメタバースを取り扱った自社開発PJを進行しています。

業界的に未開の地とも言われるこの分野に着手する上で数多くの課題や困難が常に隣り合わせでありますが、失敗や成功を重ねて確実に進められている自社開発PJです。

今回は、エンジニア主体で進める開発生産性向上取り組みと独自のアプローチに焦点を当て、新たな視点と実例を交えて解説していますので、チーム開発の進め方が気になる、開発生産性の上げ方を知りたい！という方はぜひご一読ください。

チームの開発生産性を上げるためにエンジニアができることとは？

開発生産性を意識したPDCAサイクル

オータムは設立3年目の急成長株であり、スタートアップにおいて多種多様に価値あるものを創って世の中に提供するPMFを大事にしています。

※PMF=Product Market Fitの略称。製品と市場の適合度を評価し、成功の可能性を示す尺度です。

その過程で迅速なPDCAで仮説を立ててケースを検証して改善を行うことをサイクルとしています。

特に新規開発事業においては、まだまだ業界的にも未知の要素の多いメタバースを取り扱っていることから、このプロセスは体現化する上で欠かせません。

限られたリソースや構想と開発期間で着実にコミットを進めるには速度も求められます。

つまり、スピード感を持って機能実装を実施してそこで発生したバグケースは即時改善することが求められます。

そのサイクルスピードを上げるのに、開発生産性（Developer Productivity）の向上が必要というわけなのです。

定例の内容はより”主体性ある内容に”

開発生産性を上げる事業施策としては、一般的には環境ツールの導入やテストツールの拡充など手段・ツールの話になりがちなのですが、重要なのはそれをどうやって取り入れるのか、それ以前に事業としての組織や文化の方が重要ではないかと個人的に思ってます。

つまり、PDCAサイクルを高速化するには、メンバー全員の課題発見・解決能力を高め、それらを一元的に仕組み化することが有効というわけなのです。

例えばなにか問題があった時、経営層やマネージャーが施策を打つこともできますが、現場の困りごとや事情は、現場の方がより深く事情を熟知しているはずです。

もしかすると、現場エンジニアでは既に解決のための最適解に気付いているかもしれません。

そこで、私はボトムアップでの改善・対応が正しいと考えて、エンジニアファーストな開発生産性向上を目標として定例を開発改善MTGとして実施しています。

このMTGでは、作業報告だけでなくよりよい開発のためにどうすべきかをテーマに、毎週木曜日の夜にプロダクト開発に関わるメンバーが集まって、ボトムアップでの議論・実践を話し合っています。

エンジニア出身のGM長田も同席するなど、Unitや所属に関わらずさまざまな立場の人が集まり、東京・大阪間をリモートでつないでいます。

開発改善MTGの様子

MTG当日までに各参加者がRedmineに用意されたアジェンダリストへ改善する内容や問題だと感じる内容などを記載します。

MTGではリストから取り組み内容を議論して決め、その上で実践するという流れになっています。

テーマは特に限定しておらず、アセットデータの増量からAWSを自由に使える検証環境など、さまざまなトピックが出されています。

つまり、メタバース開発に関わることであれば何でもOKというスタンスです。

ちょっと意外かもしれませんが、アイデアベースでトピックを取り決めすることでメンバーひとりひとりが"自分事"としてタスクを持つ意図が含まれているんですね。

実際の改善事例

また開発環境については、当初はDockerで構築して環境ごとに差分を調整していたのですが、 WindowsやMacなどマシンによってはDockerfileに差異がありました。

そこで、それまで個人のPCでおのおので環境を用意していたものを軸にしつつ共通検証機や推奨スペックなどについても検討し、立ち上げのコストを限りなく抑えた形で実機検証環境を用意できました。

（求める機能を突き詰めると機器調達って高くつきますからね…笑）

これにより共通の環境下でリリース前チェックやプロトタイプ開発ができるようになり、主体性がメインで基本的に水面下活動が多い新規開発事業の見える化にもつながりました。

これについては、開発だけでなく社内なども巻き込んで事業を飛び越えたインフラ整備に至りました。

ちなみにSESの現場ではこういった動きが企業の制度レベルの改革につながることもあります。

開発改善MTGの落とし穴は心理性にあり

積極的な課題抽出を阻む問題とは

事業の見える化にもつながるこの定例には気をつけるべきことがあります。

開発改善MTGの実施は一見話し合いとして簡単に見えるものの、運用にはくれぐれも気をつける必要があります。

それが心理的安全性の確保です。

たとえば、ある提案を行うと、提案者がその内容を一番理解していると思われ、問題解決の担当者としてもアサインされてしまいます。

仮に組織やチームとして改善していこうと提案しても、結局自分が推進することになるのなら面倒やできない時に困るから提案をやめようという気分にもなりますよね。

こうしたことを気にせず問題の提案のみに集中することを大前提の場にすることで心理的安全性を確保します。

MTG運用で気をつけているポイント

この心理的安全性を確保するために、

• 問題を提起する際、誰が書いたかがわかるようにチケットに名前を書くが、実際の担当は話しながら決めていく
• 書いた時に解決策まで思いついていなくてもOK

この2つのルールを特に重視しています。

そのうえで、問題だと思ったこと、改善したいことをとにかく Redmineにあげることを徹底しています。

アジャイルと同様、毎週何かしら提起される問題があり、それらに対して有効なアクションが取られる状態が理想です。

完璧にやりきらなくても、ちょっとでも改善できるという積み重ねが大切です。

なお、必ず振り返りも行い、その進捗を共有することが重要ですね。

小さな改善事を積み重ねる

なお、この定例は有意義なMTGではありますが、開発者をはじめ全員がいる場で話すのが苦手という人も少なくないです。ここは開発者の性格面や相性なども関係してます。

そこでGM長田との1on1も実施機会を設けて、別途不安や違和感などのヒアリングをしています。

他にも、チャットツールとしてDiscordを使っているのですが、プロジェクトサーバーにユニット別にスレッドスペースを作成、タグ分けして目的に応じた環境を用意しています。

例えば相談したいことがあれば相談タグを使ってスレッドを立ててそこで文章に起こしてもらうことで内容の整理にもなって根本的な問題の究明もできます。

また、定例以外の時間にもそうしたフォローを積極的におこない、問題のブラックボックス化を防いだり、問題になる前に早期解決を積み重ねて予防策として対策案にも還元できたりします。

エンジニアファーストな開発を目指して

課題が「自分事」になる理想的なエンジニア組織構成とは？

開発内容によって組織構成は多種多様ですが、一事業において理想的な構成としてはまず部門別に役割を持たせることです。

例えばオブジェクト構築ならばプロップ、サーバー構築であればインフラストラクチャーなどの意味や役割を持ったチームによって成り立たせます。

一般的なフロントエンドやバックエンド、サーバーサイドというだけの領域別ではなく機能モジュールごとに分かれているのは、コミュニケーションロスを回避することが目的です。

それがコミュニケーションだけでなく業務についても、各メンバーが領域を横断して取り組むようになり、幅広いスキルを身につけることに繋がっています。

そのため、理解の深さに個人差があっても多くのエンジニアが複数領域をまたいで技術を理解し、最終的にはさまざまな問題や課題解決に当事者意識を持って取り組む自分事化の土壌を整えられます。

職能横断的な組織構成を理想とした事業部に

いかがでしたでしょうか。

一般的にはフロントエンドで起きている問題に対してバックエンド担当は関心を持たないという状態が常態化してます。

ここを機能やモジュールなど役割別で分かれた組織の場合は担当者それぞれが領域横断的に関与できる形になっているため、さまざまな課題を共有できます。

そうすることで解決に対する議論も活発に行われて組織に良い影響を与えるので結果的に開発環境が改善されて生産性のあるいわゆる職能横断的な組織構成を築けます。

つまり、開発にはボトムアップで効率的に課題をあげて解決する組織が必要というわけです。

オータムでは未経験からでも現場デビューできるように独自カリキュラムの研修やエンジニア同士のナレッジ共有をしており、社内事業にも挑戦できる機会を設けています。本記事を読んでエンジニアとして活躍できる能力やコミュニケーション力を身につけたい人はぜひ一度お話しましょう。