40代情シス女子、押してもダメなら引いてみろという話

相変わらずどん詰まっているプロジェクトでございます

　まあ、要件定義で失敗しているわけですよね。要件定義の失敗例なんてそこらじゅうに転がっているわけですが、

システム開発における要件定義の失敗事例を紹介！失敗しないコツも解説！

　ここまでオールクリア。クリアしても何も出ませんよっと。さらに「要件定義が超ざっくりしていてあちこちに書類に分散している」というのまであるぞ。

・要件定義の段階で焦ってしまう
・設計が遅延する
・過剰なニーズを受け入れてしまう
・下流工程や下請け業者に丸投げしている

正道でやってもうまくいかない状況をどう解決するのか

　これまで正道でやってきたわけです。

　で、最初は決定事項を決めてそこを機関決定してみたいなことをやって、プロジェクトの「軸」を作ろうとしたわけ。

　でも、結局、現場で、その決定と関係ないところでいろいろな要件を受けまくってたみたいな状況に陥っておりました。。。

　まあ、決めたことを無視して現場で丸投げしまくってりゃそうなるよね。

　で、決めたことを全然守らない人たちに対して「どーすんのこれ？」みたいなことを言っても、ＰＭの人も頭を抱えるばかりで動かないわけですよ。

　なので、いったんあれこれ考えるのを止めて、今資料として何があって、それをどう組み合わせれば全体の要件になるのかみたいなところを根気強く探ってみたわけです。

「これはどこに書いてあるの？」
「資料はどこにあるの？」

みたいなやつですな。
すると、資料がめっちゃ分散して整合性が取れていないだけで、まー資料はそれなりにあることがわかってきた。

押してダメなら引いてみては――思考停止のススメ

さあ、仕切りなおすわよ

　結局、要件が整理されていないと、誰か連れてきても作れないですし、何かしら作れたとしてもまたもめる案件が一つ増えるだけですからね。

　なので「要件定義の資料をきっちり整理して要求側が話せる状況を作る」っていうことを考えると、いったんウォークスルーをやるしかないなという結論に至りました。

なぜ、システム開発は必ずモメるのか？

　ウォークスルーというのは、機能を一通り説明して、そのなかでの矛盾点や課題、未解決事項などをたたき出してクリアにしてしまうみたいなやつです。

　本来は作業者のみでやるんだけどね。こうなると大々的にやるしかないっていう感じになっております。

ウォークスルーとは - IT用語辞典

　あとは、どういった人割りでどうするかですね。。。。
　そこは正直私ではどーにもならんので、やらなければならないことをつきつけて戻ってきましたが、これでうまくいかなかったら、

　もうこれはダメかもわからんね。

　まあ「ダメ」っていう見切りをつけるにしても、資料は必要なわけなので、今やっていることは無駄にはならないと思っています。

　あきらめることも大事だしね。