システム開発の教科書的なものに必ずあるのが「要件定義」という言葉です。

要件定義が大切だという話はまぁググれば嫌っと言うほど出てきますが、この「要件」というのは修飾語がないから、何を要件と呼んでいるのか非常に分かりにくい。要件って何と聞いたら、エンジニアの方やITコンサルタントの方でも答えがブレると思います。

私どもは要件定義の要件を「プログラムを開発できるのに必要な前提条件」だと考えています。前提条件は３つあって、画面、データ、機能の３つです。どんな画面を作って、どんなデータを読み書きして、そのデータを作るためにどんなプログラム(機能)を作らねばならないのかを決めるのが、要件定義という工程です。

この要件の妥当性を決めるのが、一番難しいです。この業務システムを使うユーザーの行動が適切なものであるかを、どうやって決定したら良いかの基準を満たすのに、時間がかかります。

自分たちの業務を、この画面でこんな操作で行うのであるというデザインをするには、システムの作り手・設計者が、システムを使う人よりも対象業務をよく知らないといけません。

私どもは、当該業務の専門家ではありませんが、様々な業種のIT企画や業務システムのデザインを行いました。体験したことがない仕事や業界を対象にしたことも多くありますが、それらをキャッチアップする術を知っています。

業務知識を得るためにやっていることは、「追体験」です。追いかけてユーザーの立場に立って同じ体験をイメージし、ロールプレイングをします。

追体験は元々「他人の体験を、作品などを通してたどることによって、自分の体験としてとらえること。」の意味です。作品ではなく業務内容を通じて自分が今この仕事をやれと言われたらどんなタスクをこなす必要があり、何を確認しなければならないのか。そこでどんなコミュニケーションを誰と取って仕事を回す必要があるか・・・をイメージして、自分なりに作業の流れを組み立てて、業務内容の理解を深めています。画面設計を行うと、必然的にそういった力がつきます。

この理解と皆さんの要望をぶつけ合って、より良い行動が取れるように、この業務システムを使うことで「こういう行動が取れるようになるのがベスト」を作り上げないと、要件定義がうまくまとまりません。

左目では使い手の目線、右目では作り手の目線で、最適な要件をきめていきましょう。