半年以上かかる大規模システム開発の時にハマったこと

自分は事業会社で働いているのですが、最近徐々に「完了までに半年以上関わるプロジェクト」に関わることが増えてきました。

その大規模システム開発時の自分の経験を振り返るとともに、今後の大規模システム開発の時に改善するためにも、半年以上の大規模システム開発の時にハマったことをメモしておきます。

どのようなプロジェクトに関わってきたのか？

f:id:virtual-surfer:20180805113226p:plain

まずは、どのようなプロジェクトに関わってきたのかを書いておきます。

①古いバージョンで書かれたアプリの最新バージョンでの書き換え
②サイトのデザインと機能をフルリニューアル

①に関しては、古いバージョンでのアプリ申請が通らなくなるということで、機能は変えずに最新バージョンで全面的に書き変えるというプロジェクトでした。当初は「2人で取り組んで4ヶ月くらいで書き換え切ってリリースできるかな？」というざっくりした見積もりでしたが、実際には「3人で9ヶ月以上かかった」という結果になりました...。

②は、サイトのデザインや機能を企画し直して、サーバーサイドも全面的に書き換えるというプロジェクト。マテリアルデザインやAPIでのデータやりとりなどがまだ普及していなかった数年前に開発されたWebサイトを全面的に改修するというもの。企画からリリースまで、20人程度の人が関わり、2年間前後の工数がかかる見込みで始まりました。

これらが関わってきたプロジェクトです。SIerでの大規模開発と比べると全然大規模開発と言えないのかもしれませんが、普段は1,2週間のリリースサイクルで回っている事業会社なので、リリースまでに半年以上かかるプロジェクトは大規模開発だとしています。

大規模開発でハマったこと

それでは、大規模開発においてハマったことを羅列していきます。

相互レビューなしで各個人が分担して開発を進めてしまった

「既存機能を最新バージョンで書き換えるだけだし、相互にレビュー必要ないでしょ。一気に開発進めていこう！」と開発を進めてしまい、プロジェクトが4ヶ月程度進んだところで、それまでレビューされていなかった箇所が全面的に書き換えられる必要があることが発覚するという事態が発生し、壮大な手戻りが発生しました。

そもそも相互レビューがされない状態で開発を進めるという開発体制をとったことが問題だったのもありますが、プロジェクトのオーナーが不在で、実装メンバーだけでプロジェクトを進行してしまったことが最大のミスだったかなと。プロジェクトの人員が割けないという場合にも、プロジェクトオーナー（全体の開発方針の管理・進行管理）・実装者（実装をゴリゴリ進める）の役割分担をしっかり分けたほうがよかったなと。

最初に既存仕様をまとめず、調べながら実装を進めた

「機能が複雑かつ仕様書が残っていない（当時の開発者は不在）」という開発者泣かせなプロジェクトにおいて、まずは既存の仕様をまとめ切って、その仕様が正しいことを担保してから実装に着手するという進め方ではなく、「一つ一つの機能において既存の仕様を調べながら実装する」という体制をとってしまいました。この結果、仕様が実装者の頭の中にしか残っていない状況は変わらず、サービス全体の仕様を確認することもできないという状況になってしまい、実装に新たに加わったメンバーも仕様を確認できず開発速度が上がらず、レビューも進まない...という事態に陥ってしまいました。そして、仕様がまとまっていなかったため、実装が終わって「テストを書こう！」という段階になって、テストを作るために仕様をまとめる必要があって結局仕様をまとめることになるという...。

どんなに開発者の工数が限られていても、「仕様を調べながら実装していく」という進め方ではなく、「最初に一気に仕様を調べて、仕様が文書化できて、正しさが担保できてから実装する」という進め方の方が、全体の工数は削減できたなと。特に、「実装できたものからリリースしていくことができる」というものではなく、「全ての機能を実装しきらないとリリースできない」というものでは、後者の進め方をすべき。

長期にわたる開発未経験のメンバーのみで進めてしまった

長期にわたる開発を経験したことがないメンバーだけで開発プロジェクトを進めていた結果、プロジェクトのメンバー全員が探り探りで実装を進めていき、結果的に非効率な開発体制になってしまっていた点が多かったなと。長期的な開発を経験したことがあって何に注意してどのような手順で進めると効率的にプロジェクトを進めることができるのかを知っているプロジェクトオーナー（もしくはメンバー）がいれば、そのメンバーが全体の開発体制を決め、全体の管理をできたのかなと思います。

もしも長期的な開発を経験したことのあるメンバーを用意できない場合には、「大規模開発注意すべきこと」とかでググって開発体制を先に検討しておく、大規模開発を経験したことのある他メンバーの知見を聞いてみるなど、できることはいくらでもあるなと。プロジェクトを最速で完了させるためには、すぐに開発に取り掛かるのではなく、最初に開発体制を最適化するのが重要だと。↓実装力が尋常じゃない岩田さんのチームで大規模開発を進める上で注意したことも参考にすると良いです。

【岩田聡氏追悼企画】岩田さんは最後の最後まで“問題解決”に取り組んだエンジニアだった。「ゲーマーはもっと経営者を目指すべき！」特別編 - 4Gamer.net

最終目標が定量的でなくリリースがゴールになってしまった

「プロジェクトにおいて、最終的にどの数値がどの程度上がっていればプロジェクトは成功なのか。」を決めることは何よりも重要なことでありながら、何よりも難しいことですよね。これを決めきらずに、プロジェクトを進めながら決めよう！としてしまった結果、プロジェクトの完了がゴールになってしまい、そのプロジェクトが成功だったのか、失敗だったのかを振り返ることができないという事態に陥ってしまいました。

最終的な定量目標が決まっていないと、結果が良かったのか、悪かったのかを振り返ることができないとともに、決まり切らない議論が永遠続いてしまって、プロジェクトの完了が遅れてしまうという事態になってしまいました。意思を持って先に定量目標を決め切る。それをプロジェクトのメンバー全員の頭に叩き込む。プロジェクトの最初にどれだけ時間がかかってもこれをやっておくことで、最終的な開発速度と開発の結果の成果は最適化されるかなと。

開発全体の進捗を確認できるWBSが用意できなかった

長期にわたる開発を経験したことがないメンバーだけで開発プロジェクトを進めていた結果、プロジェクトのメンバー全員が探り探りで実装を進めていき、全体の進捗は順調なのか、遅れているのか、何が進捗のボトルネックになっているのか。それをプロジェクト内外のメンバーは知ることができません。

その結果、探り探りでプロジェクトを進めていくことになり、遅れを取り戻そうと残業が続き、生産性が落ちてさらに進捗が遅れてしまうと...。全体の進捗の中で何をどのくらいする必要があるのか。どこに工数を優先的に割くべきなのか。をプロジェクトメンバーが管理することができ、外部のメンバーも進捗を確認してレビューができる状態にしておくことは大事かなと。