「思いがけず情報システム部門に配属された」
「本業でいっぱいいっぱいなのに新規プロジェクトにアサインされ、膨大な時間とられてうんざり」
「専門用語もＩＴのしくみも、正直、意味不明」
企業がＩＴビジネスをどんどん広げていく傾向にある中、そんな悩みを抱える人が増えているようです。
そこで、かつてない「システム発注者のための入門書」として注目を集め、発売早々連続増版を重ねる『システムを「外注」するときに読む本』の著者が、「知識ゼロ」からでも、自社に貢献するＩＴ企画や要件定義ができて、失敗率の高いＩＴ導入を無事成功させることができる、実践的な知識とスキルをお伝えしていきます。
業務の段取りを
「ストーリー」にする
第4回の記事、「“ひねくれ者”がシステム担当者に向いている【新業務のネガティブチェックリスト】」（https://diamond.jp/articles/-/148054）では、新しい業務フロー図を書く時には、いったん自分が「業務改善反対派」になり、「ネガティブチェック」と呼ばれる否定的な目で新しい業務フローや要件を見直すことが、「結局使えないシステム」を作らないために大切になるという話を書きました。
さて今回は、この業務フロー図から、システム作りのための「業務要件」を作っていく方法をご説明します。業務要件作りとはつまり、「システムを入れた後にどんな業務を実現したいのか？」ということを明らかにすることです。
たとえば、「経費精算伝票を受け取ったら、権利部の担当者がその妥当性を確認して、経理部長の決済を経て、出金指示を出す」という流れを、コンピューターシステムの設計に馴染むような書き方で表現していくのです。
ここで注意すべきは、業務要件定義の段階では、まだ「コンピュータシステムにどのようなことをさせるのか？」については記しません。「業務全体の中で、どの部分をシステム化するべきか？」はもっと後の工程で全体を俯瞰しながら決めていきますので、この時点では「Web画面」とか「データベース」といった言葉は使わないのが原則です。（※）
※ただし、新しい業務を実現するために、既存の別のシステムにアクセスすることが前提になっているような時には、その部分についてのみ、そのような言葉を用いることがあります。
では、業務要件をどのように表現するのか、第4回の記事で例示した下記の業務フロー図の中から、上から3段目、生産管理部門が行なう「納期検討」の部分を例に見てみましょう。
（※図が見られなくても、記事の内容は理解できます）
上図を見ると、「納期検討」は、お客様からの「納期検討指示」を元に開始され、結果として「納期」を回答しています。これは、もっと詳細に見ていくと何をすることになるのか、具体的なストーリーを頭の中で考えていくのです。
納期の検討指示というからには、「どんな製品が、いくつ欲しいのか？」ということになるはずです。仮に、この会社が、「受注→製品を組み立てる→出荷する」というプロセスで仕事をしているとしまししょう。納期を回答するためには、組み立てるための部品があるかどうかを調べ、足りないものは発注し、それが届いたらラインで生産を開始する、ということになるわけです。
つまり、納期回答までのストーリーは下記のようになります。
（1）納期検討指示を受け取り
↓
（2）部品のある／なしを調べる
↓
（3）生産ラインの空き状況を調べる
↓
（4）それらの結果から納期をはじき出す
