あるプログラマの日記

プログラマのメモ、出来事、考えたこと、勉強とかの雑記

要求仕様問題プロジェクト その過程

 要求仕様に関しては、いつも確定しないまま実装に入ってインクリメンタルな開発を行うことが多かった。しかし、ついこの前の組み込み系通信システムの開発は完全なウォーターフォール型でした。結果はなんとか結合テストまで完了しましたが、その過程は散々でした。ウォーターフォール型では、設計に入る前に仕様が確定されることが前提ですが、T.B.D 項目以外にも仕様変更ではなく仕様漏れがけっこうありました。

 数人で実装しましたが、あいまいな仕様のまま実装した箇所は、結合試験ではまともに動作しなかった。当然といえば当然の成り行きです。短い期間で開発しなければならないプレッシャーがプロジェクトにあり、この圧力からプロジェクトリーダーは常にプロジェクトの建前上の進捗に執着して、実質的な問題点をおざなりにする傾向があったと思います。いや何が実質的な問題なのかもちゃんとわかっていなかったのではないかと思います。問題点をプロジェクトリーダーに報告してもその問題が根本的に解消されることはなかったし不明点が明確になることもなかった。開発時に、あまりにも不明点が多すぎましたが、それを問題としてクライアントにあげることができなかったのが致命的でした。クライアントへの進捗報告や打合せは、プロジェクトリーダーが行っていましたが、そこで問題点をクライアントに報告することをしていなかった。詳細仕様を設計段階で確定するとしても、それは要求仕様として本来確定すべきものであるとの認識がなかったように思います。
そのプロジェクトリーダーは結合試験前に、このプロジェクトから離脱しました。

【結論】

  • 不明点は不明点として顕在化させる。(報告する)
  • 短納期のプレッシャーに負けずに、本質的な問題を、把握して顕在化させる。(報告する)
  • 品質と納期に重点をおいて実現すべき機能に優先順位をつける。
  • それを踏まえて計画をたて、スケジューリングする。
  • その計画達成のための適切な開発手法を採用する。
  • 問題点の解決方法を検討する。