住宅を建てる時に最初に考えるのは「間取り」であるのが一般的だと思います。間取りを決める時には、住む人の「動線」が基本になりますね。どこを居間にして、居間から食堂へ、食堂とキッチンに住む人がどうのように移動するか？お風呂屋、トイレはどの位置にするか・・・など、この人の動線が仕事においては「業務工程」「業務手順」とか、また一般的に「業務プロセス」と呼ばれます。業務プロセスを広くは「ビジネスプロセス」と呼ぶことが多いです。
皆さんが仕事をするときには、「決められた業務工程」に従って業務を運用しているはずです。「決められた」と言うことは、どこかに「決めごとを定めたもの」があるはずです。一般的には「業務手順書」「業務手続」と呼ばれているでしょう。そこには、「どういう順番で」「どういう作業を」（つまり、業務プロセス）をするかが定められています。
ちょっと横道にそれますが・・・この決めごとは書かれたものがある場合（ちょっと難しいですが）「形式知化されている」といいます。書かれたものがなく誰か担当者の記憶に頼っている場合、これを「暗黙知」と呼びます。「形式知」と「暗黙知」を覚えておいてください。
さて、話しを戻します。業務プロセスは、企業や団体の活動目的に沿ったものになっています。製造業であれば「製品を作って販売し利益を得る」という大きな経営目標を達成するために業務プロセスが従業員等により実行されます。大きな目標のことを「ビジネスモデル」と呼んでいます。
整理すると、ビジネスモデルを達成するために業務プロセスが実行される訳です。
もう一つ覚えて戴きたいのが「業務判断基準」です。一般的にビジネスルールと呼びますが、業務プロセスを実行するとき、その過程で「判断」が求められる場合に採用すべき判断基準が定められています。ビジネスルールも覚えておいてください。
業務プロセスとシステムの関係を考えてみましょう。先に述べたように、ビジネスモデルを達成するために業務プロセスが存在しました。システムは業務プロセスを実行するための道具となります。従って、システムの振る舞いと言うものは業務プロセスによって決められ、「判断」が必要なときにはビジネスルールに従うことになります。
従って、システムは業務プロセス実行過程で使用される「道具」ですから、システム開発を行う場合とはその元となる業務プロセスになんらかの変更・追加・削除等が行われることが前提になっています。
つまり、システム開発の検討を行う前段階において業務プロセスをどのように変化させるのかが検討され定義されなければなりません。ここが重要なポイントです。
そして、業務プロセスの変更後の姿が決まった後に、その業務プロセスとビジネスルールからシステム開発の「要件」が導き出され定義したものが「要件定義」です。
さて、上で述べた「業務プロセス」や「ビジネスルール」について、最も詳しい立場の人は誰でしょうか？言うまでもなく「業務担当者」（階層はありますが広い意味で）が最も詳しいはずです。
従って、私が申し上げたいことは・・・「要件定義」は原則「業務担当者」（システム開発においては「ユーザ」と呼ぶのが一般的）これを策定すべきだと考えます。
また、であるからこそＩＰＡ（情報処理推進機構）から「ユーザのための要件定義ガイド」も発刊されたのだと思います。
前々回のブログで述べましたが、システム開発の失敗の半分以上が、要件定義の不備・不足に起因しています。その理由は、業務について知識のないＩＴベンダーに「要件定義」を含めて丸投げしてる現下の日本におけるシステム開発の体質にあると言わざるを得ません。
日本のＩＴベンダーは、システムの黎明期から50年間にわたりユーザの要件定義を支援してきており、要件定義の技術も蓄積されています。しかし、ユーザが１００人いれば１００種類のビジネスモデルがあり、業務プロセスがあります。従って、ＩＴベンダーは新しいユーザに接する都度新しいユーザの業務プロセスの分析をしなければなりません。しかし、ユーザの知見は自社に特化しているので、言うまでもなく、ユーザが要件定義を行えばシステム開発の失敗も大幅に減少するはずです。
ですので、ユーザである皆さんに是非「要件定義」の手法を身につけて戴きたいと思います。
さて、皆さんの会社では「業務プロセス」や「ビジネスルール」が形式知（書かれたもの）になっているでしょうか？また、暗黙知のままで放置されてはいないでしょうか？もし、形式知化されていない場合、または形式知化されていても内容が古くアップデートされていない場合、システム開発に際しては最新の状態でこれらを作成・アップデートしなければなりません。
システムに関して「現状」をAsIs（アズイズ）と言います。また、将来求める状態の姿（あるべき姿）をToBe（トゥビー）と言います。これらもよく使いますので覚えておいてください。