[SI]開発プロジェクトが破綻しないために必要なこと - 体制編

こんにちわ！BizDB CTOの松崎です

普段はStockDBというSO発行や付与対象者との契約締結、管理といったことができるSaaSを開発しています。
といいたいところですが今現在特に資金調達もおこなっていないので平日は自給自足のため代表の今井と共に受託案件を行いつつ、副業のような形でStockDBを開発しています。それでも生成AIのサポートもあり滞りなく開発はできておりより低リスクで起業できる環境になってるなと感じます。

さてさて、開発プロジェクトをうまく進めるために必要なことをエンジニア目線で話していきたいわけですが、今のところ主戦場はSIなので経験を踏まえ書いていこうと思います。

1. クライアントと主に話す人は一人に

開発会社側でもPM、エンジニア、デザイナー、営業、役員と色々な立場の人がプロジェクトにかかわっていると思いますが主に話す人は一人に限定するのが望ましいと思います。
プロジェクトの統制にかかわることで各々が個別最適を行っても全体最適になっておらず想定外に工数が膨らむということは往々にしてあると思います。また、全体最適になってないならまだいいですがプロジェクトチーム内での仕様面での情報共有がうまくいっておらず破綻の道まっしぐらということはありえるでしょう。
プロジェクトチームを強くまとめるPMがいて内部での情報を吟味したうえでクライアントと会話していくというのが無難でしょう。

2. エンジニアとPMは要件定義の段階から密なコミュニケーションを

1のクライアントと主に話す人がPMだと仮置きするとエンジニアとPMは要件定義の段階から密にコミュニケーションをとりプロジェクトを進めていくべきです。
時折PMとクライアントが話して仕様をまとめてエンジニアに見積もり・設計依頼するという状態を見かけますがこれは仕様に開発目線が入っていないためよくないです。
プロダクトのコード部分まで理解しているのはエンジニアなのでその観点から開発工数と照らし合わせてどのような仕様にしていくべきかを検討していくべきでしょう。
あとSIだとその後の保守開発まで確約されているわけではないので難しいですが保守性の高いコードになるかどうかを判断しながら要件定義していくといいと思います。無理やりな要件がでても一時的には達成できますがその部分は必ず技術的な負債になります。それによりその後の開発スピードが鈍化したり大きなリプレイスを行う必要が出てきたり結局損害を被るのはクライアントなのでその目線で指摘できるといいでしょう。

3. さいごに

簡単でしたがエンジニア目線での開発プロジェクトが破綻しないために必要なことでした。
開発案件って開発フェーズで主に遅れるので開発にしわ寄せがいく（原因探しがちな）イメージですが原因の多くが上流フェーズにあるんじゃないかと思ってます。
それをうまくいかせるためには１、２は必須だと思いますし２を行える優秀なエンジニアも必要です。

優秀なエンジニアを採用しましょう！