前々回の成熟度の話、その前の業務プロセスの「見える化」において、システム開発や導入の前に行うべきこととその重要性について述べました。簡単におさらいすると、無駄な投資をしないためには無駄なシステムは作らないということ。そのためには
・今の業務手順は、本当に無駄がないのか（業務の「見える化」）
・今の従業員のレベルは、システムに対応できるのか（成熟度）
をしっかり把握しておくべきです。残念ながら多くの企業では、この前準備がほとんど出来ていないままに、開発に臨んでいます。また、システム開発会社（ＩＴベンダーとも呼ぶ）も、企業の要求を鵜呑みにするか、「今の予算では出来かねます」と突っぱねてオーソドックスな仕組みを提供します。つまり、企業要求
そのものがきちんと精査されることは非常に少ない状況になっているのです。
結果的に、「こんなはずではなかった」「ＩＴベンダーが悪い」などと責任のなすり合いで、プログラマーが懸命に作ったシステムは、部屋の片隅に追いやられるのです。そこまではいかずとも、使わない機能がてんこ盛りで使いづらいとの話も多く聞きます。
そこで重要なのが「要求定義」です。
これは、（専門家に手伝ってもらうかどうかは別にして）「企業側」が準備しなくてはいけません。難しい言葉で言うと「要求定義書」と表現するものを作成します。
これに対し、「そんな難しいこと言われてもできない」「おまかせにしておけばいいよ」との声が聞こえてきそうですが、使えるシステムにするには、この要求定義に労力を惜しんではいけません。そこで、比較的簡単にできる要求定義をご紹介します。
１．画面イメージをつくる
まずは、入力と出力でほしい画面を作ってみましょう。難しく考える必要はありません。手書きでもいいですし、エクセルにテキストボックスやボタンなどを貼り付けるなどしてイメージを作ります。このとき、それぞれの入力箇所の制約事項を記入しておくことが大切です。（管理番号は８桁とか、表なら行数は６行まで、等。）これら制約事項は、データベースやシステム変数を決めるときにベンダーさんから非常に重宝されます。また、並びや入力順序も番号や矢印を用いて書いていきましょう。これらの作業をベンダーさんに依頼する企業もありますが、意図がうまく伝わらず無駄に作り直しをしていることが多くあります。作り方を教わってでも、自分たちで作ることをお勧めします。
画面イメージがよくわからない方は、今使っている帳票を利用して、入力する項目を赤色・結果出てくるものを青色などと塗り分けて並べてみてもよいでしょう。どちらにも使わない無駄な項目や、次に述べる用語の違いなどを見つけることも出来ます。あとは、入力項目だけ、出力項目だけをそれぞれ集め、切り貼りをすれば画面イメージができあがります。
２．用語の定義
日常使っている当たり前の用語が、社内でしか通用しないことは意外と多いものです。極端な場合は、担当者間ですら異なることもあります。また、同じ用語なのに違う名称で使われているものも少なくありません。（日付が納品日なのか発注日なのか、現場番号と場所ＮＯ、等。）これらは、ベンダーを悩ます最大の要因ですから、必ず整理しておきましょう。今後の業務にも役に立ちます。（今回、「企業」「会社」などと、同じものを意識的にいくつかの違う語句で表現しています。違和感を感じるとお気づきでしょうか？）これは、業務担当者以外の人や新人さんに見てもらうと見つけることができます。
３．利用者の特定と調整
要求定義からは少し外れるようですが、どのような人がシステムに関わっているかを明確にすることが重要です。ベンダーが要求整理をする場合は、ユーザー企業から担当者という人を教えてもらい、その人から業務手順や要求事項をまとめていきます。ところが、要求整理の重要性を認識していない会社は、時間に余裕があるからと全体像を把握していない新人を割り当てたり、極端に自
分のポリシーを固めてしまっている人を割り当てたりしがちです。その結果、
・利用者間の意見調整が出来ていない
・利用者が何をしたいかわかっていない
・利用者の要求がくるくる変わる
・ヒヤリングに協力してくれない
のようなことが起こってしまうのです。当然、出来上がったシステムはおかしくなってしまいます。
こういった失敗を避けるには、ユーザー側が積極的に利用者の調整を行うことが大切なのです。特に、標準作業と例外作業の区別をつけることができる社員（課長や部長、ベテラン社員）が必ず参画するようにしてください。
システムを無駄に大きくしないポイントは、標準作業のみをシステム化し、例外作業は運用で対応することです。そして、従来の業務をそのままシステム化するのではなく、一度見直しをかけることが要求定義を生かすことになるのです。利用者間の調整や特定といったことは、外部の人間には不可能です。このことを忘れないでください。
４．他システムとの整合性（会社の全体像を意識する）
対象システムが小さい場合は、「できれば」のレベルですが、大きい場合には、必ず他システムとの整合性を考慮してください。開発側は言われていないことまで考慮しません。結果、閉鎖的なシステムとなり、「システム間が手入力」などといった悲惨な出来事が起きます。
もちろん、経営方針や経営計画を踏まえた要求も考慮するべきですが、中小企業ではそこまで求めるのは難しいのが現状です。お勧めはシステムマップ。マップといっても難しいものではなく、社内で使っているシステムを書き出し、関係を矢印や説明文でまとめます。システムの重複や不足がわかりやすくなります。
本来の要求定義からすると、不足部分はありますが、上記の内容をまとめるだけでもＩＴベンダーからは感謝されるはずです。もちろん、システムが自分たちの理想に近づくのはいうまでもありません。大変な作業ですが、システムで自分たちが楽をすると思えば、出来ない作業ではありません。「急がば回れ」でがんばりましょう。