一見まともだけど、全然機能しなさそう。
構造的問題として、まず「要件確定の先送り」を挙げる。従来は、顧客とSIerが要件定義をあいまいにしたままでシステム構築を進めてしまい、結果として手戻りによる無駄なコストが発生するという問題があった。(中略)そこで要件定義の段階でユーザー企業との認識のズレをなくしておくことで、手戻りを食い止める。
ものすごおぉぉくサッパリとした切り口で斬ってしまうんだけど、要は後工程で「これは我々の欲しいものではありません」と言われてしまわないために、要件定義の工程を高度化・精密化してブレを可能な限り減らしましょうという話。
それ、限界があるって。
もうさ、良くある話なんだけど「提案力強化」っていう命題が上から降りてくるでしょ。で、そうなると大抵「業務 or ITコンサルタント育成」みたいな方向でシステム開発の上流工程を捉え直そうとする傾向が強いんだけど、コンサルってそう簡単に出来るもんじゃないって。方法論とツールと自動化プログラムがあれば出来るもんじゃない。絶対出来ない。ましてSIerはオーダメイド製品を請負で作っている。コンサルは一般的で常識的な各種理論・論理を委任で作っている。コンサルが商売になるのは委任だからでしょう。しかも、その委任で作られた成果物保証ゼロの要件を元に請負でシステムを作るわけだから、いくらビジネスアーキテクトだなんだと言って業務コンサルを強化して高質で堅牢な要件定義をというのは非現実的であるように感じる。
この問題を考える方向性は２つ。
要件定義の高度化により後工程へのブレを極小化するか、ブレて当然という前提で手戻りをベースにPDCAを回すスパイラルアプローチを取るか。
で、やっぱり我々SIerにとって後者は毒針を飲み込むようなもんだから怖くて出来ない。つまり、どこまで許容できるかなんて判断できない。やっぱりディエンシブな方向性になってしまうわけで。それはもう仕方なくて。前者ありきで考えるしかない。後者は今までのやり方の中で可能な限りテストファースト等の考え方を取り入れるしかないでしょ。
となれば要件というモンスターのブレを極小化するためには、複雑化している対象をあんまり変えずに要素分離していく方向とそもそも要素を減らして可能な限りシンプルにしていく方向の２つがある。富士通は前者のやり方で、後者はスターロジック社のマジカなんじゃないかな。
正直くだらないよ、要件があーだこーだもめるの。誰も喜ばない。揉めないで済むならそれにこしたことはない。
