要件定義が目指すもの#1での内容、その定義をした成果、つまりは要件定義の目指すものをより深く理解、習得するためのページです。もし#1をご覧になっていない場合には要件定義が目指すもの#1を先に参照ください。

トップダウンの重要性

投資を伴うシステム開発において、要件を確定する際の大原則があります。システム開発の要件定義の基本はあくまで、「トップダウンで骨組み、ボトムアップで肉付け」、これがセオリーです。「要求」についても「要件」についても、後述のがセオリーであり、大原則です。但し、トップの期待値ばかりが大きすぎると、現場で使いものにならないシステムになってしまうことがあります。期待値を実現するよう現場で使わせるためには、現場を変えるしかない場合もあります。そうなると、ビジネスの方針変更や人事的処置等を行う覚悟があるかどうか、トップの姿勢が間われ、システムだけでは解決できない問題に発展します。ERP導入による抜本的な業務改革を目指す場合は、特に顕著かもしれません。その場合、経営陣には、ITシステム導入以外の覚悟(ビジネスおよび人、組織といったリソースの改革に対する覚悟)が問われます。

要件のレベル

前項で「要求」のレベルについて説明しましたが、「要件」にもレベルは存在します。要求同様に「ビジネス」「業務」「システム」のレベルです。
【要件のレベル】
★ビジネス要件、★業務要件、★システム要件
IＴシステムがシステム要件を満たしていても、「ビジネス要件」「業務要件」を満たさなければ、ただの役に立たない箱です。現場で使い物にならず、ビジネス価値に繋がらずに、結果として、投資効果を見込めないゴミになってしまいます。「システム要件」を満たす以前に、「ビジネス要件」「業務要件」を満たす術を講じなければなりません。それには強烈なトップダウンが必要です。トップダウンなしでは「業務改革」は成功しません。いきなり「部門長」以下に丸投げでは「業務改革」はムリです。部門で使用するシステムの開発案件に、該当の部門長をリーダーに任命するケースをよく見かけますが、止めた方がよいでしょう。リーダーはあくまでトップが務めるべきです。部門長は部門の利益を最大化する役割を担っています。いくら「全社最適」の視点を持ってはいても、自部門の利益を優先するので、結果的に「部分最適」に陥る恐れがあります。業務改革を伴うシステム開発で、トップの姿勢が問われるのはこのためです。但し、残念ながら日本の企業組織においては、そこまでのリーダーシップを発揮して、トップダウンで物事を決めていく風土がない、醸成されていないことの方が多いかもしれません。その場合には、現場で吸い上げた「業務要件」を「ビジネス要件」としてまとめ上げ、再度「ビジネス要件」か0第;「業務要件」「システム要件」へと落とし込む等の工夫が必要になります。

人真似でうまくいくか?

要件定義や上流工程で行うべきことは、既にいろいろな書籍で紹介されています。それらを参考にすれば、何とかかなったでしょうか? もしかすると、「そんなことはわかっている!」「自分はうまくやれている!」と立腹する方もおありでしょう。では、多くの本が出版され、参考にされたことで、システム開発の失敗は減っているでしょうか?どうも、そうは思えないのです。それとも、これまで以上に「先人の教え」を参考にすれば、何とかなるでしょうか? 残念ながら…そうでもないようです。なぜでしょうか?現場で「うまくいかない」原因があるのです。具体的には以下に挙げる5点が考えられます。
① やるべき事にみあう、充分な時間が与えられていない本には行うべき作業や作成すべき成果物が規定されており、認識してはいるものの、実際のプロジェクトでは時間を割くことができない。
② 難しくて非現実的(やろうとしてもできない)上記の①と同様に、行うべき作業や成果物は理解しているが、メンバーの技術的なスキルがついていけず、結果としては不可能。
③ 前工程で決めるべきことが決まらないあるべき姿として前工程で決められた事柄や成果物の記載事項が暖味なため、作業に入ることができない。
④ やらなくてはいけないことが形骸化している。行うべき作業や作成すべき成果物が規定されており、メンバーも理解はしているが、作業自体の目的までは共有されておらず、フォーマットに沿って形だけを落とし込んだものになっている。
⑤ やらなければならないことを共有するのが難しい行うべき作業や作成すべき成果物を、メンバーの一部は理解しているがプロジェクトで共有されていない。
たいていの場合は、達人もいるけれど、凡人が大多数を占めます。凡人でも生き延びることができるためには何が必要でしょうか。やはり理論より実戦の場で有効な手段を優先せざるをえません。もちろん、理論をないがしろにする気は毛頭ありません。「理論あっての実践」です。達人の人達にも、理論的に納得のゆくものでなければなりません。本記事では要件定義という実戦の場で、凡人でも生き延びることができるような術を説明していきます。

要件定義における成果物

本書では要件定義の成果物を最小限に抑える方針を採ります。換言すれば、「最小の管理(成果物)で最高の成果を出す」ことを目指します。主要な成果物は、なるべく少数に絞ります。アーキテクチャの中でビジネスの動的側面を表すプロセスモデル(「業務」の視点からプロセスの手順を表したもの)、ビジネスの静的側面を表すデータモデル、動的側面×静的側面の交差点を表すCRUDマトリクスを中心に考えます。それに加えて、UIの仕様(画面遷移)とそれぞれの概要を定義したものがあればよいでしょう。それ以上多いと、システムの成長に合わせて維持メンテナンスし続けて「育てる」ことが難しくなります。