有料会員限定

システム開発の肝「要件定義」はなぜ失敗するのか 「丸投げ」は絶対NG、開発の成否はここで決まる

✎ 1〜 ✎ 9 ✎ 10 ✎ 11 ✎ 最新
著者フォロー
ブックマーク

記事をマイページに保存
できます。
無料会員登録はこちら
はこちら

有料会員限定記事の印刷ページの表示は、有料会員登録が必要です。

はこちら

はこちら

縮小

企画実現のために必要な条件を整理する要件定義。不十分だと失敗リスクが一気に高まる。

打ち合わせで議論するビジネスパーソン達
議論の中で課題を解決していくことも重要(写真:PIXTA)

特集「文系管理職のための失敗しないDX」の他の記事を読む

すべての事業活動がデジタル化に向かう中、「苦手」や「丸投げ」ではもう済まされない。2月27日発売の『週刊東洋経済』では、「文系管理職のための失敗しないDX」を特集(アマゾンでの購入はこちら)。システムやWeb、アプリの開発において管理職が知っておくべき「地雷ポイント」や、知識ゼロから着手できる「ノーコード」の活用法などを解説する。この記事は本特集内にも収録しています。
週刊東洋経済 2023年3/4特大号[雑誌](文系管理職のための失敗しないDX)
『週刊東洋経済』2023年3/4号では「文系管理職のための失敗しないDX」を特集。アマゾンでの購入はこちらから

企画の段階では何を実現したいかを決めたが、要件定義では、企画を実現するための要件=必要な条件を整理する。そのうち、システムで実現する必要があるものを設計・開発(プログラミング)してつくり上げる。

要件定義は、主に2種類ある。「業務要件定義」と、その業務を実現するために必要な「システム要件定義」だ。順序は必ず業務要件定義を先に行う(スケジュールの都合上、途中から並行で行うことも多い)。業務のためにシステムを開発するので、システム要件を先には決められないからだ。

業務要件の中にはシステム以外の方法で対応できるものもある。当然、それらに関してはシステム要件定義を行う必要はない。

このとき、時間をかけて細かく要件定義を行っても、100点満点にするのは不可能と考えていただきたい。そもそも要件をすべて出し切ること自体が難しいうえに、ビジネス環境の変化で要件自体が変わることはよく起こるからだ。

丸投げは絶対にNG

肝に銘じたいのは、要件定義の内容に責任を取るのは「自社」だということ。外部のコンサルティング会社やSIer(システムインテグレーター)と一緒に検討することが多い工程だが、丸投げは絶対にNGだ。

外注先との契約上の責任の所在の話だけではなく、要件定義の失敗によって使えないシステムが出来上がっても、その被害を受けるのは実質的に自社であり、裁判となり勝訴したとしても、失った時間は取り戻せない。

企画を実現できる要件をしっかりと出せていること。プロジェクトの成否はこの時点で決まっていると言っても過言ではない(この先の工程で失敗することもあるので、成功の可能性がなくなるという言い方のほうが正しいだろう)。

少し古い話だが、米国のアラン・M・デービスという教授が1990年代に出版した著書『ソフトウェア開発201の鉄則』の中で、「要求時点の誤りの修正は、設計段階だと5倍、開発段階だと10倍、テスト段階だと20倍、リリース時点だと200倍のコストがかかる」と指摘している。

いかに上流工程で正しい設計ができるかがコスト面でも大きく響くということを知っておいてほしい。

次ページ「(新)業務フロー」を作成してみる
関連記事
トピックボードAD