「思いがけず情報システム部門に配属された」
「本業でいっぱいいっぱいなのに新規プロジェクトにアサインされ、膨大な時間とられてうんざり」
「専門用語もITのしくみも、正直、意味不明」

企業がITビジネスをどんどん広げていく傾向にある中、そんな悩みを抱える人が増えているようです。

そこで、かつてない「システム発注者のための入門書」として注目を集め、発売早々連続増版を重ねる『システムを「外注」するときに読む本』の著者が、「知識ゼロ」からでも、自社に貢献するIT企画や要件定義ができて、失敗率の高いIT導入を無事成功させることができる、実践的な知識とスキルをお伝えしていきます。

あなたがきちんと要件定義しなかったのが悪い
と言われないために

前回の記事『要件定義でモメないための発注者「5つの決め事」』(http://diamond.jp/articles/-/143840)では、ITシステムを導入する際、発注者にとって最も重要な「要件定義」という工程の概要についてお話ししました。

簡単におさらいすると、要件定義とは、「どのようなシステムを作ってほしいのか?」を、発注者がベンダーに伝える作業であり、おもに次の5点を決める必要がありました。

● 要件定義でモメないための発注者「5つの決め事」
(1)「企業や組織にどんな課題があるのか?」を確認する(IT導入の背景と目的)
(2)「それを達成するために業務をどう変えるのか?」を考える(業務要件定義)
(3)「そこにどんなITシステムが役立つのか?」を検討する(IT化の方針)
(4)さまざまな「条件」を考慮する(IT化の前提と制約)
(5)「具体的にどんなシステムを導入するのか?」を決める(システム化要件)

要件をきちんと伝えなければ、たとえベンダーが間違ってシステムを作ったとしても、文句は言えません。しかし、要件をきちんと定義できれば、それが良いシステムとなって、会社の売上向上やコスト削減などに大きく貢献します。さらに言えば、きちんとした要件定義ができる社員は、トップクラスの営業マンや、コスト削減で会社を救う管理部門のエースに匹敵する「価値」をもたらす存在なのです

しかし、要件定義を別の側面から見ると、場合によっては訴訟に及ぶような「ITトラブル」を引き起こす原因の中で、その4割ほどが要件定義に端を発している、という事実があります。

私は以前、裁判所でITシステム導入に関わるさまざまな「モメごと」の調停をしていました。「ITシステム導入プロジェクトが失敗した。悪いのはベンダーだ! 損害賠償を請求したい!」と訴える発注者が、結果として「いやいや、それはあなたがきちんと要件定義をしなかったのが悪いんですよ」と厳しい判決を受けることが、たびたびありました。

そこで今回は、要件定義工程の中から、冒頭「5つの決め事」の(2)業務要件について、少し掘り下げてお話ししていきます。

要件定義を「大炎上」の火種にしないために