すべてのシステム要件は非機能的要件ではないか？

最近マイケル・ジャクソン（どっちかというと踊りの下手の方のマイケル）の「問題フレーム」という、かなりプリミティブなレベルでのシステムに関する問題の捉え方のパターンみたいな話に興味を持って、彼の本を読んでいる。この本は名著です。絶対みんな読みましょう。
　で、その本を読みながら考えたんだけど、システム、特にEnterprise系のシステムの要件って「すべて非機能要件」ではないか？と思いだした。つまり、Enterprise系のシステム処理って、昔は人がやっていた処理を効率化しようとした処理がほとんどのはずで、時間無制限という前提をおけばコンピュータでしかできない機能ってほぼないと思う。(ハードは、例えば原子炉のように、どう考えても人間じゃ無理だろみたいなことをやるものがある。同様に、ハードと連携するようなゲームとか組み込みソフトも無理)。最近、様々な部署の要件定義を見る機会をいただいているのでその観点でこの仮説を検証してみよっかなとか思っている。
　で、だから何なのさっていう突っ込みが入ると思うのだが、そういわれるとまだ整理しきれていない。が、ちょっと今思っていることは以下の２つ。
１：「開発プロセスのシステムの中の業務設計」を「ビジネスの機能を設計する」発想で今の「業務要件定義、業務設計。。。」をやること。で、これは当たり前にやっているよと思われがちがだが、決定的に違うのは「ビジネス要件というのはシステム開発の上流工程への入力ではなく」、システム開発と「並行して」行われるべきという発想に至ることだ（パワポ参照:なお、これとテストのＷモデルを組み合わせると「フォルクスワーゲンモデル」になるのでなんとかそうしたいと思案中）。

２： で、非機能要件だけ決めるとなると、平行して開発してるビジネス要件に対して最適な非機能要件を決めるという作業になるはずだ。これは何が嬉しいかというと、今は最終的に全体的な方式を確定させるためであろうか、今まではいわゆる機能全般に対してのっぺりと横断的に決めていた非機能的要件をもっと分割して定義して統合するため、「最適な非機能要件とその設計できる」のではないかという期待だ。これはシステムをブラックボックス的に見るから安全サイドに倒してものすごい高品質、高性能なシステムを「作らざるえない」という形態から、特定のボトルネックをつぶしていくことにより全体を最適化する方向に徐々に改善していきましょうという発想を実現するためには非常に良いとアーキテクチャになると思う。どうだろうか。

プロブレムフレーム ソフトウェア開発問題の分析と構造化 IT Architects' Archive ソフトウェア開発の課題3 (IT Architects' Archiveソフトウェア開発の課題)