システム開発が失敗する理由、「動かないコンピュータ」から分かったこと
コメント
選択しているユーザー
注目のコメント
日経コンピュータの動かないコンピュータは、面白かったですが、購読者はそこからいったい何を学んできたんでしょうね。
データでもあきらかだし、体感的にも『要件定義』がキーなのはみんなわかっているはずなのに、要件定義がいい加減なのは、忠告を無視して納期があるからといって開発に着手せざるを得ないと考えるSEやプロマネ、あるいはマネージャが相変わらず居るからじゃないでしょうか。
ソフトウエアエンジニアたちは、「まじめ」だから論理的に正しければそれが間違っていてもその方法を選択する。
「納期に間に合わない、だからすぐに開発しなきゃいけない」という論理的に正しそうなことを言われると、まあ「適当に」とは言わないけど「作り始める」
それがパッケージではさらに厄介だ。なまじっか動くものがあるからなんとか間に合いそうな気がする。
これらは全部素人的発想の域を出ていない。
さすがにパッケージをカスタマイズすることは減ってきているようだが、いまの開発現場の様子から、手法も開発管理方法も相変わらずの様相。
開いた口がふさがらない。開発現場は30年前から変わっていないといっても過言ではないんじゃないだろうか。
これは持論ですが、「ユーザー企業（顧客）が要件をまとめられない」のは当たり前で、SIerはそれを見越してユーザー企業を支えなければならない。またSIerも表面的に要件を理解するのではなく、ユーザーの仕事の現場に足を踏み入れないとまともな要件定義ができるはずがない。ユーザーから聞いた事だけをシステムとして実現しようとしていたら、それはまったくの素人、アマチュアの仕事である。
つぶさにユーザーの話の内容、使う言葉、表現の癖、システム化対象の仕事の重要性、流れ、止まった時の影響、業務の上で習慣的になっていることでユーザーが当たり前だと感じていて説明されていないことは何かを探り、業界用語や表現の癖からくる要求内容の違いなど、要件定義局面は最大限の神経をつかって、繰り返し確認をおこなって、誤解ゼロ、カバーされていない事を徹底的にゼロにしないといけない。
これを言うと「納期が」と言われるが、実際の経験では徹底的に要件定義に時間をかけた場合、後工程が驚くほどスムースで納期を守れてしまう。
これができない限り、永遠に動かないコンピュータは続くでしょう。パッケージソフト導入の要件定義フェーズはFit&Gap分析と言われる適合性評価。粗々のRFPに対するベンダーの回答などを元に製品を決定しプロジェクトは始まる。フタを開けるとパッケージで出来ると思っていたことができないと分かり開発項目に追加され、それを繰り返すうちに予算を大幅に超過しプロジェクトが止まる。
RFPが悪いのか、選定した目が悪いのか、ベンダーの提案が甘いのか、
はたまたパッケージに合わせて業務を変えられないユーザー側の問題か
パッケージ側の機能不足の問題か
双方のPMのマネジメント力の問題か
まぁ色々ですね。
※なんじゃそりゃ。。そもそもどんなものを作るか使ってみないと分からない分野が増えた。要件は最初はまとめられないが事実では。リーン開発的な世界の必要性…「2010年代の開発失敗を見ると、最大の原因はユーザー企業がシステムの要件をまとめられないことで27.3％、続いて「ベンダーが要件を理解できない」が24.2％だった」
