SI案件で要件がはっきりしない時

SI開発でよく起きる問題の1つ。エンドユーザーのシステム要件がなかなか決まらないというのが
たびたび問題になる。

決まらないと、スケジュールを圧迫したり、開発工数を圧迫したりなどで、
スケジュールが遅延したりなどがたびたび起きて、開発者にとっては厳しい状況になりがち。
業界の慢性的な病気とも言えるかもしれない。

パターンを分類してみた

  • エンドユーザー側の決定が遅れがち、大事なことを決断する力が弱い

この場合は、PMや営業を通じて仕様決定者間で解決できない場合は、
会社同士のもっと上のレイヤーをうまく使う。現場でMTGしてる人がどうこうしようとしてるので、あまりうまく
いってるのを見たことがないし。うまく行くなら、もっと前にうまくいっているような気がする。

  • 開発側、請け負ってる側に要求管理する力が弱い

この場合は、開発側にうすうすまずいと思ってるメンバーがいる場合は、気がついたメンバーが動くことで
解決する場合もあるが、誰も動かない場合は目も当てられない状況が待っている。誰でもいいから
気がついたら、アラートを誰かにあげるべきである。

  • そもそもエンドユーザー側、開発側にも意思決定する能力が弱い

この場合は、PJに関わっている人間以外が、気がついてメンバーの交換か、改善策を
講じないといけない。しかし何となく決めてるだけで、進んでるPJもまた多いのが事実。


他にも色々パターンがありそうですが、よくありがちだなと思うのを挙げてみた。
結局誰かが気がついて、行動しないといけない気がするが、誰も行動できない状況が
多いというのもまた現実なんだよなー。シワ寄せは誰かに行く。
けれども、気がついて、行動して状況を変えれればちょっとしたスター扱いされるかもしれない。