問題にフォーカスせよ

お客様あるいはユーザーの要求を把握し、システムとして実装することは簡単ではありません。多数の要求がすべて終始一貫しているとは限りませんし、そもそもビジネスとして実現したい内容もシステムに対する要求も、すべて要求として列挙されることがほとんどなのです。単純にシステム自体が理由となっている場合を除き、システムに対する要求（システム要求）はビジネス経営上の要求（ビジネス要求）から派生します。たとえばサポート期限切れのシステムを別な環境にリプレイスしたいなんでいう、単純にシステムが理由と思われている要求項目にしたって、本当はそれを機会にTCOの削減を行いたいというビジネス要求が背後にあるかもしれません。

日本のIT業界は長らくこうした点を暖昧に扱ってきました。そんなことはない、と言われる方も大勢いらっしゃることでしょう。でも、ビジネス要求もシステム要求も津然一体で暖昧模糊とした要求を「要求」、整理しおえたシステム要求を「要件」と呼ぶなんて、おかしな話です。わざわざ分かりにくい言葉で区別せず、もっと分かりやすく何に対する要求なのか言い表せばいいではないですか。こうした不思議な用語を作ることこそ、要求に対する取り組みを分かりにくくしている典型的な例ですね。

さて、話を戻しますと、アーキテクトはこうした要求の整理ができなくてはなりません。開発プロセスの例を出すまでもなく、システム開発は要求の展開と変換で成り立っています。さかのぼれば、設計仕様の根拠はシステム要求にあります。システム要求の根拠はビジネス要求に求められます。ウォーターフォールだろうがアジャイル開発だろうがこの原則に違いはありません。ではビジネス要求の根拠はどこにあるのでしょうか。それが「問題」なのです。要求は解いてほしい問題に対する必要事項であるはずですね。高度なビジネス戦略を実現する要求だって、日々の作業手順を改善する要求だ、って、すべてその背後には解きたい問題があってこそ成り立つものです。しばしば我々アーキテクトはお客様・ユーザーからいただいた要求の実現にフォーカスしすぎて、根本の問題を把握することをおろそかにしがちです。もしあなたが、荷物を最適経路で配達するためのシステムを開発してほしいと依頼されたなら、よくよく検討した方がいいでしょう。もしかしたらお客様の問題をより早くより安価に解く手段は最適経路ではなく、最適な荷物の積載アルゴリズムかもしれません。最適な配送拠点、を設置してオンデマンドに配達を行う方がもっと安価に解けるかもしれません。解く手段は一つではないのに、こんな場合、多くのプロジェクトでとても難しい最適経路アルゴリズムの実装を始めようとします。最適経路が最終的に正しい選択ならばそれでいいでしょう。しかしそうでなければ、その結果として生じるのは使われないシステムと巨額の投資、最悪の場合はプロジェクトの頓挫などの事態です。

問題にフォーカスすべきなのです。根本的な問題を正しく把握し、問題を解くための選択肢を生み出す発想力と経験こそが必要です。問題が何かを知るためには、業務や業界の知識が必要です。ユーザーの業務における問題点の理解、業界における経営戦略の必要性を理解することが必要です。ビジネス・レベルのサービスを用いるSOAや、ビジネス・プロセスを適切に管理するBPM、ビジネス要求をすばやくシステムとして実現するためのアジャイル開発手法など、多くのIT動向がこうした世界を指向しています。ソフトウェア・アーキテクトが知るべきこと、それはインダストリー・ナレッジを用いた問題把握なのです。