相手ができないことわかってるのに受注してあとからグチグチいう人が多いとか

特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐 － Publickey

を読んで。

内容を要約すると、発注側がIT技術の生かし方が分からず、そのため業務フロー設計も無用な産物で大量に作成しつつ、開発ベンダーに丸投げという体制が続く限りだめになる、って感じだ。

実際これは、開発現場に於いてよくあるパターンであり、よくある愚痴である。
「この客、全然要求が整理されてねぇ！」
「自分たちの業務が整理できてねぇ！」
「詳細が見え始めてからの要件変更が多すぎる！」
などなど。

確かに、上記は発注側として解決していくべき問題・課題ではあるかもしれない。
ただ、個人的には「発注側の責任」をグチグチ言う前に、開発側で他に取るべき手段があるのではないか？と思う。

というのも、発注側のプロジェクトの人間は、そのような業務全体を設計するような経験もなければ、それをできるだけのスキルも持ちあわせていないことが多いという現状なのは、最初から開発側は理解しているはずだ。発注側にも、数は少ないが全体を見据えて話をする人間はたま〜に見かけるが、ステークホルダーが多すぎて調整に時間がかかり過ぎるという問題もあったりする。
つまり、発注側は自分たちのビジネスに於いてはプロなのかもしれないが、IT資産を活用し設計することにおいては、ほんとに素人の人間がほとんどだ。

それがわかっていて受注しているのに、さんざん言いたい放題の客の言うことを聞いてきて、無理な期間と金額で受注をし、後から「要件変更が多すぎる」って、「うけるー」としかいいようがない。そんなの最初からわかってることだろ。何回同じ事繰り返すんだって話である。

あくまで恒久的には(長く付き合う取引先の)発注側自身が新しい業務モデルを設計し、IT資産をどのように活用すればよいか考えることができ、要求・要件を整理し、きちんとした RFP を作成した後に発注できるようになってくれるのが理想なのかもしれないが、それも含めてコンサル業務として、要件定義前の新業務フロー構築の手順やノウハウを伝達し、先々のリスクをヘッジするのが、開発側へのニーズではなかろうか。

「すみません。言われたことしか作れません」
でもよいが、それはそれではずかしー話だなぁ、とよく思う。

※ あくまで、自分の周りの経験上の話。他の開発会社のスキルはもっと高いかもしれない。俺が「はずかしー」ところにいるだけかもしれない！