開発プロセスの課題と改善

こんにちは！
プログリットでエンジニアマネージャーをやっている島本（X（旧Twitter）、Mastodon）です。

プログリットに入社してから早いもので3年が経ちました。おかげさまでプログリットの英語コーチング事業でもアプリが定着し、シャドテンも着実にお客様の数が伸びており、サーバの稼働状況やお客様からのフィードバックからもアプリの利用が増えていることを実感しています。

そんな中、エンジニア組織においても、プロダクトの種類も増え、更にそれぞれ機能も増えていく中、開発の進め方も変わってきました。今回のブログでは、弊社プロダクト開発の成長と共に起きた課題とその改善の取り組みについて紹介させていただきます。

以前の流れと課題点

以前、こちらの記事でプロダクト開発がどのように開発に当たっているかを紹介させていただきました。

そちらの中では大きく以下のような流れで開発をしておりました。

• 戦略検討
• 開発項目洗い出し
• 要件設計＆UIデザイン
• エンジニアによる設計
• 実装
• Quality Assurance
• 本番リリースと確認

開発するものの数や仕様の複雑さもそれほど大きくなく、基本的にはプロダクトマネージャー（以下PdM）、デザイナー、エンジニアの全員が全体像を把握していきながら進めておりました。
この形を2年ほど進めていく中、取り巻く環境には、以下のように変化がありました。

• 「シャドテン」の専用アプリを開発
• 「プログリット先生」「プログリットスピーチチェッカー」などのAIを利用したLINEボットの開発
• エンジニアの内製化の進展

上記に加え、それまでの英語コーチング向けの機能開発項目も進めているため、開発の深さ（1つの機能の複雑さ、等）と開発の幅（プロダクトの種類、等）は大きくなる一方でした。以前のように1つのチームで開発をしようとすると一人ひとりが、仕様の確認、デザインの確認、開発の状況把握、設計、実装内容等のすべてを把握することが難しくなり、以下のような弊害が生じ始めました。

• 実装後の手戻り
• 実装時間の圧迫による短期思考な仕様や実装
• 意見反映不足によるモチベーション低下

実装後の手戻り

こちらはよくある話ではありますが、エンジニアによる実装が進んだ後に仕様の考慮漏れや、より良い実装方法などが後から判明し、やり直し（手戻り）が発生してしまっていました。
以前は開発する内容が比較的少なかったため、全員で仕様を把握したり検討する機会が多くありました。それにより直接関わらないメンバーでも仕様についての理解をしやすく、事前に懸念事項の共有などもしやすかったのですが、開発の幅が広がってくると、全員での相談が難しくなり、一部の人で進めることが多くなってしまい、上記のような問題が発生しやすくなっていたのだと思われます。

実装時間の圧迫による短期思考な仕様や実装

以前のプロセスではPdMにより、機能にそれぞれマイルストーン（リリース日）が仮で割り振られていました。
あくまで「仮」のものであり、常に議論で調整などは可能にしていましたが、実際には仕様を考える際にどうしても、そのマイルストーンを意識してしまうため、それに合わせた仕様作成や実装をしてしまいがちでした。仕様を少し調整することにより、より綺麗に、より堅牢な実装ができる場合でも、その選択肢を取らずにマイルストーンを優先して、短期的な判断や実装をしてしまいがちでした。

意見反映不足によるモチベーション低下

1つ前の「実装後の手戻り」の課題とも関連しますが、開発の幅が広がってくると、開発の内容を全員で把握することが難しくなり、開発に関わっていないメンバーが、開発の内容を把握することが難しくなってしまいました。これにより、PdMやデザイナーで一部のエンジニアのインプットを入れつつデザインや仕様などを作成した後に、関わっていなかった他のエンジニアには意図せず「仕様が確定済み 」と受け取られてしまうような状況が発生しました。 実際には仕様は確定しておらず、フィードバックを取り入れることも可能な状態だったのですが、完成に近い形を見せられてしまうと、どうしても受け身になりやすい空気を作ってしまっていたのだと思います。
結果として様々なメンバーの意見などを吸い上げつつ、チームで一体となって開発していける内製化の強みを活かしきれていない状況になってしまっていました。

改善の取り組み

改善への取り組みですが、上記の課題は全員で共有できていたので、PdMが中心となって「課題点の整理」「原因の究明」「対策の検討」というのをドキュメントでまとめつつ、必要に応じて会議などで説明をしながら、全員のフィードバックを積極的にもらいつつ、検討していきました。

その作業や議論の量に関して、ほんの一部を紹介させていただくと、内容をまとめていたEsaというツールで、本体の内容よりもコメント欄の方が3〜4倍の長さになり、内容の更新回数も40回を超える程になりました ⬇️

改善案

チームで話し合った結果の改善案を簡単にまとめると以下のようになります。

• PdMは「要求」を決める
• 仕様を決める権限を分散
• 意見を言うのは自由

それぞれ解説をしていきたいと思います。

1. PdMは「要求」を決める

プログリットの開発では元々「要求」と「仕様」を共にPdMが決めていました。もちろん、必要に応じてエンジニアやデザイナーにも意見を聞きながら決めていましたが、最終的にはPdMが決めており、上記のような課題に繋がっていました。
今回の改善で、PdMは「要求まで」を決めることにし、その次の「仕様」などは案件ごとにエンジニア、デザイナー、PdMのいずれかから責任者を出し、その責任者が主導することにしました。

2. 仕様を決める権限を分散

前述の「PdM、デザイナー、エンジニアのいずれかが責任者」になることにより、デザイナーもエンジニアも、仕様を決める権限を持つことになります。
実際に仕様を詰めていく際には責任者以外にも各役職から1名ずつメンバーを選出し、そのメンバー間を中心に話し合いを進めていき、

• 技術的な仕様
• デザイン
• マイルストーン（＝リリース時期）

を決めていくことにしました。

3. 意見を言うのは自由

上記に書いてある「1名ずつメンバーを選出」していますが、仕様はGitHub DiscussionsやFigmaで誰でも見える状態にしているため、誰でも意見を言うことができます。実際に選出されたメンバー以外でも、有用な意見をしたり、見落としなどに気付く可能性があるので、積極的に意見を言って良い、という認識を持ってもらうようにしました。
ただ、それだけでは元々の課題であった「実装後の手戻り」のリスクが残ってしまうので、 仕様を決めた後には変更はしないというルールを設けています。表現として厳しく聞こえてしまうかと思いますし、実際にはクリティカルなバグや仕様の見落としが出てくる可能性があるので変更がゼロというわけではありませんが、意識として、意見をするのはその手前でじっくり仕様を検討してほしい、というメッセージが伝わるようにしています。

改善案の狙い

上記を実施することにより、PdMの負荷や権限が集まるのを防ぎ、エンジニアやデザイナーにも仕様の議論に積極的に入り、意見を言ってもらいやすくすることを狙いとしています。
マイルストーンなども議論する中で決めるため、そのマイルストーンに関して納得もしやすいですし、内容によっては、短期間で無理に終わらせるのではなく、時間を取ることもできるようになるのではないかと思っています。
また、定性的に一番大事な効果として早い段階から機能の仕様に関われることで、PdMだけでなく、デザイナーとエンジニアも一緒に作り上げている、という一体感が生まれやすくなるのではないかと思っています。

最後に

こちらの取り組みを初めてから、まだ2ヶ月ほどなので、結果などはまだ見えきっていませんが、今後も継続していき、より良い開発プロセスを作っていきたいと思っています。

まだまだ成長途中のプログリットですが、一緒に働いてくれる仲間を募集しています！