「思いがけず情報システム部門に配属されてしまった」
「本業でいっぱいいっぱいなのに、新規プロジェクトにアサインされ、膨大な時間とられてうんざり」
「専門用語もＩＴのしくみも、正直、意味がわからない」
企業がＩＴビジネスをどんどん広げていく傾向にある中、そんな悩みを抱える人が増えているようです。
そこで、かつてない「システム発注者のための入門書」として注目を集め、発売早々連続増版を重ねる『システムを「外注」するときに読む本』の著者が、「知識ゼロ」からでも、自社に貢献するＩＴ企画や要件定義ができて、失敗率の高いＩＴ導入を無事成功させることができる、実践的な知識とスキルをお伝えしていきます。
「要件定義」は発注者の
最も大切な仕事
前回の記事（https://diamond.jp/articles/-/142954）で、ＩＴシステムを導入する際の全体的な「段取り」についてまとめました。
システム担当者が、経営陣や上司から「今度、ウチの会社で○○業務をシステム化することになったから、頼むよ」と言われたら、要件定義、設計、実装、テスト・検収、保守・運用という作業が発生するということだけ、まずは覚えておいていただきたい、という内容でした。
ちなみに、これらの行程の「名称」は、組織によって異なる言葉で表現されることがあります。たとえば、要件定義を「要求定義」や「仕様検討」と言ったり、実装が「開発」と呼ばれたりすることがあります。
ただし、それらの言葉は、ほとんどのＩＴ関係者が知っています。「要件定義？ ああ、それはウチでいえば仕様検討のことですよ」などと誰もが答えてくれるはずですので、安心してください。
それよりも注意が必要なのは、この作業行程の「順番」です。
ＩＴシステム導入プロジェクトでは、これらの作業を「要件定義」から順番にやっていく「ウォーターフォール型開発」もあれば、「実装」から開始したり、「テスト」から始めるやり方もあったりします。最近よく聞くようになった「アジャイル型開発」では、「要件定義」から「テスト」までを何度も繰り返していくような方式です。
これら個別の開発方式については別の機会にお話しするとして、今回は、それぞれの作業の詳細を順番にお話ししていくことにします。
システム開発プロジェクトは、そのシステムを使うことになる発注者と、実際にモノづくりを行なうベンダーが協力して進めていきます。その中でも特に「発注者」が重要な役割を果たすのが、「要件定義」です。
家の建築やレストランの注文では、お客さんが「こんなものを作ってほしい」「これが食べたい」と言ってくれなければ、作り手は何もできません。同じように、いやそれ以上に、ＩＴシステムの場合も、「どんなシステムが欲しいのか？」を、しかるべき時期までに正確かつ十分に詳細化した形で言ってくれなければ、ベンダーは何もしてくれません。
私は以前、裁判所においてＩＴシステム導入に関わるさまざまな「モメごと」の調停をしていました。
「ＩＴシステム導入プロジェクトが失敗した。悪いのはベンダーだ！損害賠償を請求したい！」
そう訴える発注者が、結果として「いやいや、それはあなたがきちんと要件定義をしなかったのが悪いんですよ」と厳しい判決を受けることが、たびたびありました。実に、ＩＴトラブルを引き起こす原因の中で、その4割ほどが要件定義に端を発しているのです。
ちょうど先日、まさにその典型とも言える事件がニュース沙汰になりました。発注者である旭川医科大学が、ベンダーであるＮＴＴ東日本に対して、14億を超える支払いを命じられたのです。
【※旭川医大事件の詳しい経緯と教訓に関しては、先日の「緊急寄稿」をご覧ください（リンク）】
要件定義は、発注者側が責任を持って、正しくかつ遅れることなく実施しなければならず、間違えると裁判にまでなるような重大な損害を出しかねないわけです。要件定義の方法や注意点について、発注者サイドのシステム担当者や経営者が知っておくことは、本当に役に立つシステムを作るという面で、また経営上の危機管理の面においても、とても重要なことです。
正しい要件定義の「手順」とは？
本連載では、これから数回に渡って、この要件定義について解説していきます。
今回はまず、要件定義で実施するべきことの概要をお伝えしましょう。
