要件定義でモメないための発注者「5つの決め事」

要件定義の基本的な「5ステップ」

要件定義の手順を大まかに言うと、下記のようになります。順番は若干前後することがありますが、よくできた「要件定義書」の目次を見ると、大体こうした順番で書かれています。

【要件定義の5ステップ】

これらのうち、IT導入プロジェクトを任されたシステム担当者が決めるのは、主に、（3）のＩＴ化の方針と、（5）のシステム要件です。

（1）や（2）は、そもそもＩＴを導入しようと決めた人たち（経営企画部や経営陣など） が決めることで、システム担当者は、それらを確認することが主な仕事になるはずです。また、（4）のＩＴ化の前提と制約については、導入担当者が自分で決めるものとそうでないものが混ざっているようなイメージを持っておいてください。

では、１つずつ簡単に見ていきましょう。

（1） ＩＴ導入の背景と目的

「そもそも、なぜ大金をかけてＩＴシステムを導入しなければいけないの？」

この根本的な質問の答えを、企画者や経営陣に確認しながら文書化していく仕事です。

ＩＴを導入するにあたっては、必ず、「大きな動機」のようなものがあります。たとえば、経営陣から、下記のような「答え」を聞き出せたとしましょう。

「最近、ウチは競合他社との売上競争に負けることが多い。調べてみると、ウチの会社は顧客から依頼があってから見積りを提出するまでの時間が長すぎることが敗因だとわかった。だから、ＩＴシステムを利用して見積期間を短縮したい」

これを 、次のような形に文書に落とし込んでいくのです。

＜背景＞
当社は見積期間の長さの為に、競合他社に対する勝率が低い
＜目的＞
見積期間を短縮すること

（当然、実際にはもっと長くなりますが）

こうしたことをわざわざ要件定義書に書く理由は、他のプロジェクトメンバーや実際にシステムを使うことになるエンドユーザー、そしてベンダも理解しておく必要があるからです。

（2） 業務要件

背景と目的がわかったら、今度は、「目的を実現するためには、今の業務をどう変えたらよいのか？」を考えます。見積り作業が遅いというなら、「どこで時間がかかっているのか？」を明らかにして、「それをどのように改善するのか？」を検討するわけです。

実際の現場でやることとしては、まず現在の業務の流れ（As-Is＝アズイズ）を調べ、業務フロー図や手順書などに落とし込んで見える化し、「どこに問題があるのか？」をその図に書き込みます。その次に、今度はそれらの問題が解決した理想の姿（To-Be＝トゥビー）を、別の業務フロー図や手順書に書いたりしていきます。

詳細は今後の回でご説明しますが、ここでは「現在の業務のどこに問題があり、それを解決したらどうなるのか？」「そのためには、業務をどう変えるべきか？」をわかりやすく表現する作業である、とだけ覚えておいてください。

（3） ＩＴ化の方針

業務をどう変えるのかが明らかになったら、今度は「じゃあ、業務改善を実現するためにＩＴシステムをどう使うのか？」を検討します。

先ほどの見積業務改善の例で言えば、こんな感じです。

「顧客に見積依頼をWebで入力してもらい、それをリアルタイムで見積担当部門が見られるように一元的なデータベースに入れよう。見積依頼があったことは、メールで自動通知しよう」

このあたりから少しずつ話が難しくなるので、ベンダーに協力を得る場合が出てくるでしょう。