「思いがけず情報システム部門に配属された」
「本業でいっぱいいっぱいなのに新規プロジェクトにアサインされ、膨大な時間とられてうんざり」
「専門用語もＩＴのしくみも、正直、意味不明」
企業がＩＴビジネスをどんどん広げていく傾向にある中、そんな悩みを抱える人が増えているようです。
そこで、かつてない「システム発注者のための入門書」として注目を集め、発売早々連続増版を重ねる『システムを「外注」するときに読む本』の著者が、「知識ゼロ」からでも、自社に貢献するＩＴ企画や要件定義ができて、失敗率の高いＩＴ導入を無事成功させることができる、実践的な知識とスキルをお伝えしていきます。
「あなたがきちんと要件定義しなかったのが悪い」
と言われないために
前回の記事『要件定義でモメないための発注者「5つの決め事」』（https://diamond.jp/articles/-/143840）では、ＩＴシステムを導入する際、発注者にとって最も重要な「要件定義」という工程の概要についてお話ししました。
簡単におさらいすると、要件定義とは、「どのようなシステムを作ってほしいのか？」を、発注者がベンダーに伝える作業であり、おもに次の5点を決める必要がありました。
● 要件定義でモメないための発注者「5つの決め事」
（1）「企業や組織にどんな課題があるのか？」を確認する（ＩＴ導入の背景と目的）
（2）「それを達成するために業務をどう変えるのか？」を考える（業務要件定義）
（3）「そこにどんなＩＴシステムが役立つのか？」を検討する（ＩＴ化の方針）
（4）さまざまな「条件」を考慮する（ＩＴ化の前提と制約）
（5）「具体的にどんなシステムを導入するのか？」を決める（システム化要件）
要件をきちんと伝えなければ、たとえベンダーが間違ってシステムを作ったとしても、文句は言えません。しかし、要件をきちんと定義できれば、それが良いシステムとなって、会社の売上向上やコスト削減などに大きく貢献します。さらに言えば、きちんとした要件定義ができる社員は、トップクラスの営業マンや、コスト削減で会社を救う管理部門のエースに匹敵する「価値」をもたらす存在なのです。
しかし、要件定義を別の側面から見ると、場合によっては訴訟に及ぶような「ＩＴトラブル」を引き起こす原因の中で、その4割ほどが要件定義に端を発している、という事実があります。
私は以前、裁判所でＩＴシステム導入に関わるさまざまな「モメごと」の調停をしていました。「ＩＴシステム導入プロジェクトが失敗した。悪いのはベンダーだ！ 損害賠償を請求したい！」と訴える発注者が、結果として「いやいや、それはあなたがきちんと要件定義をしなかったのが悪いんですよ」と厳しい判決を受けることが、たびたびありました。
そこで今回は、要件定義工程の中から、冒頭「5つの決め事」の（2）業務要件について、少し掘り下げてお話ししていきます。
要件定義を「大炎上」の火種にしないために
