問題にとらわれるな

前に述べたように、要求を把握するためには、その要求を導出した問題を知らなければなりません。しかし、問題の重大度合いと問題聞の依存関係は多くの場合一定ではありません。問題には解決が随分以前から先送りされていて、既に当初の問題意識が何であったか不明になっているようなものや、その反対にその時々の状況に応じて変化するものなど、表面的な点だけを捉えていては本質を見失うような性質のものが数多くあります。ステークホルダーが感じる問題も、すべて同じ方向を向いているとは限りません。CEOが考える問題と現場の担当者が感じる問題が異なるのは当たり前のことですね。

きて、問題がやっかいなのは、問題を問題としてだけ把握しているとその重要度合いを区別しにくいことが多いということです。「その現象はどれくらい問題なのか」を知ることが難しいと言い換えてもいいと思います。なぜでしょうか。それはやはり問題のインパクトというものを測りにくいからでしょう。問題のインパクト、たとえばある企業で「法規制の改定に応じて提供するサービスのあり方を変えなくてはならない」という問題があった場合、インパクトは何をもって測るべきか難しいところです。タイム・トゥ・マーケットを重要視したリード・タイムなのか、改定された法規制の道守レベルなのか、サービス提供価格の弾力的な変動対応なのか。それらの目標値は、要求定義の作業を経由して初めて、ビジネス要求やシステム要求として明らかになるわけです。

また、問題はいつでもどんな人にとっても問題であるとは限りません。私自身も、あるお客様でエンタープライズ・アーキテクチャを整備しようとしてCEOが望む全体最適と、現場の方が望む日々のオベレーションの最適化に対する意向が、まったくと言っていいほど噛み合わない例を何度も見てきました。これは、お互いの問題意識がぜんぜん違うレベルに置かれていることに原因があります。しかし、要求事項として抽出・定義する際にはこうしたまったく相反する意見も取り込む必要があります。では何をもって採用・不採用、あるいは折り合いをつけるかというと、何らかの「重要度」を設定した後の要求仕様が必要になるのです。

また、問題を解こうと定義される要求の多くが機能的な解決にフォーカスされます。しかし、読者の皆さんがよくご存知のようにある機能要求を実現しようとすると、非機能要求や制約事項がいくつも派生し、結局実現に莫大なコストがかかってしまうことも少なくありません。しかもそうしたシステム構築やシステム運用において、かかるコストの重大要素の一つである非機能要求は、相互干渉する場合もあります。アーキテクチャの柔軟性を高めると、パフォーマンスやキャパシティの効率性が低下するといった具合です。

アーキテクトにとって問題を理解することは、要求の妥当性や実現手段の検討に欠かせないものですが、一度方向が定まったらより明確なゴールが提示される要求項目にフォーカスしなくてはなりません。アーキテクトは要求項目の「物差し」によって優先順位と実現手段のトレードオフを判断しなくてはならないのです。解決策が適切で、ない場合は、問題に立ち返って要求の妥当性を検証しなくてはなりません。しかし、問題を問題のまま捉えていては、開発コスト・品質・開発納期・運用コストなどの諸々の点を包括的に考慮した、よりよい解決策を実現することの判断を誤る危険性もあるのです。