「要件定義が不十分」という反省が後を絶たない。開発の初期に要件を業務部門に決めさせることがそもそも難しい。打開策は業務と情報の構造を把握した上で試作品を用意することだ。
情報システムの開発においては要件定義が最重要である。日経コンピュータの読者ならこの点に論をまたないはずだ。その上で「最重要だが難しい」と悩んでいる方が多いだろう。要件定義について経営陣や業務部門に働きかけても協力をなかなか得られない。そもそも開発の初期段階に「要件を決めてくれ」と業務部門に求めること自体に無理はないのだろうか。無理だとしても打開策はあるので紹介する。
要件定義の大切さは調査結果を見ても明らかだ。日経コンピュータは3月1日号に「1700プロジェクトを納期・コスト・満足度の3軸で独自調査」した結果、開発プロジェクトの「半数が失敗」だったと報告する特集を掲載した。それを読むと失敗の理由は「要件定義が不十分」ということに尽きる。
調査結果によると、納期を守れなかった理由の筆頭は「システムの仕様変更が相次いだ」、コストが超過した理由の筆頭は「追加の開発作業が発生」、満足度が低かった理由の筆頭は「要件定義が不十分」だった。
15年前も失敗理由は変わらず
いずれの失敗理由も15年前からほとんど変わらない。本誌は2003年にもシステム開発の実態を調査していた。2018年と調査方法は異なるものの、2003年の結果を見ると3点を順守できなかった理由は、納期が「要件定義が長引く」、コストが「追加開発」、品質が「要件定義の不備」だった。2003年の調査は満足度ではなく品質について聞いていた。
「要件定義が不十分（不備）」のまま開発を進めると、経営陣や業務部門に資するシステムが出来上がらず、満足度が下がる。開発途中で要件の不備に気付くと仕様を変更することになり納期に遅れる。見直した仕様に基づき追加の開発をするとコストがかさむ。
開発における最重要事であるにもかかわらず、15年たっても経営陣や業務部門の理解が得られず、要件定義が不十分なプロジェクトが散見される。
「業務設計もシステム開発も一切合切コンサルティング会社かIT企業に頼みたい。社内の情報システム部門に新しいことを考えさせるのは無理」と語る社長に会ったことがある。10年以上前の話だが、2018年の今、いわゆるデジタルビジネスについて同様の発言をする経営者がいる。
業務部門の反発もある。「親会社と会議を繰り返し、要件定義を迫ったところ、忙しいから後はそちらでやれと叱られた」。つい最近、ある情報システム子会社の役員はこう嘆息した。
