経営とITの同期を議論していくと、経営の要求をどうITに反映させていくのかとう問題が出てくる。ここの議論での焦点は、「要求定義」と「要件定義」の違いである。

米国ではこの前者の「要求定義」のための「要求工学」というのがしっかりとあるというのは一色教授の話にもあった。「要求工学」というのは要求獲得―要求仕様化―要求検証―要求管理というサイクルを工学的にやろうという動きである。

日本にも要求工学はあることはあるし、要求開発というコンソーシアムもあるのだが、概して、「要件定義」に寄っている。どういうことかと言うと、システム化するための要件、システムとして備える要件に持っていってしまうということである。

そうなると端的にいえば、システム化できる業務だけに限った要求になってしまう。この時点で、経営とITの乖離が起きる。経営戦略の達成は何もIT化できる業務だけでできるわけではなく、手作業やコラボレーションなども重要な手段であるからである。

ここが従来の上流設計と言われるところの不備である。ですから、いつのまにかビジネス上の要求がとんでいってしまい、単なるコンピュータシステムを作ることになってしまうのである。

ですから、要求工学に則ってきちんと要求を定義し、それは崩さすIT化するという連続性を担保した要件定義にならなければいけない。

もう少し詳細化していうと、経営戦略たとえばバランススコアカードで設定したKPIなどを実現するための業務プロセスを大きな流れから徐々に分解していきます。このときは、人間系でやろうがITでやろうが関係無しに、業務のアクティビティとして定義します。そこで定義したアクティビティを定型ITとともに不定型なコラボレイティブな場とで実装していくのです。このあたりは、設計と実装の連続性のところで書いたとおりです。

こうしたレベルになってくるとオペレーショナルな観点で決めていくので、より柔軟に考えていけばいいのです。すなわち、使う人の使い勝手で変えてもいいし、新しい技術ができたら乗り換えてもいいのです。それは戦略的な要求を損なうものではありません。

ですからここでの議論である、｢要求定義｣と「要件定義」の違いを正しく理解することが非常に重要なことといえます。