ちょいとした事情で品質まわりの情報を調べていたのですがISO 9126-1（JIS X 0129-1）というのに初めて目を通しました（不勉強ですみません）。本物は、ＪISの検索ページで、「x0129」と入力するとでてきます。
で、品質とは何かというページがうまくエッセンスを抽出しています。まず品質をモデル化すると次のようにすることができます。
※上記ページからの直リンク
右側の「利用時の品質特性」というのは特定の状況における利用者が感じる品質です。だから、状況や利用者が違えば変わってきてしまうもの。で、一般的な指標は「外部品質」と「内部品質」で、それぞれソフトウェアの動きと中身の構造のこと。
そして注目すべきは一番左側のプロセス品質でしょう。プロセスとは設計／開発のやり方や手順。さてJISのドキュメントから少し引用してみましょう。
プロセス品質（JISX0160に規定されているすべてのライフサイクルプロセスの各品質）は、製品品質の向上に寄与し、製品品質は、利用時の品質の向上に寄与する。したがって、プロセスの評価及び向上は、製品品質を向上させるための手段であり、製品品質の評価及び向上は、利用時の品質を向上させる手段の１つである。同様に、利用時の品質の評価は、製品の向上に反映させることができ、製品の評価は、プロセスの向上に反映させることができる。
とまぁ、こんな感じです。では、JIS X0160はどんなんかいなというとこれは長い。ソフトウェアのライフサイクル全体を示すのですから、主プロセスとしては取得プロセス-供給プロセス-開発プロセス-運用プロセス-保守プロセスとなるます。簡単に書くとRFP作成-プロポーサル-要求分析、設計、実装、テスト、デプロイ-運用計画-保守計画というものです。ようは、アプリケーション・ライフサイクルの各プロセスの品質が、最終的な利用者品質に影響するよ、といっているわけです。
うん、すごい正しい。
最近、特に感じるのですがプロセス品質には驚くほど意識が払われていません。というか、順番が違うのです。どちらかというと内部品質にあたるものが一番右側で、次にプロセスが出てきます。これはどういうことかというとアーキテクチャが静的な構造であるというところから生まれているようです。で、そのアーキテクチャを前提としたうえでプロセスが改めて定義される。
ですが、実際に重要なのは「いかに作るか」「いかに動かすか」という動的な要素です。そこから静的な構造が定義されるべきです。ITアーキテクチャを決めてから、設計プロセスや開発手法を定義するといった手順を見かけますがうまくいくようには思えません。
アプリケーション・アーキテクチャも同じです。Strutsだぁ、Springだぁと決めてから開発プロセスを定義するのは遅いのです。プロセスの設計はプロジェクト・マネージャーの仕事と思われていそうですが、実際にはアーキテクトの仕事です（プロセスの施行と調整はPMの仕事）。
もちろんストラクチャードエンジニア（構造設計者）は重要です。ですが、そのまえにプロセス定義があるべきかのです。アーキテクチャとは思想や行為であって、構造（ストラクチャー）ではありません。
品質モデルを見ているとアーキテクトが静的な構造ではなく、プロセスを大事にすべきだということがわかります。
