システム開発に限らず、プロジェクトと呼ばれる仕事には通常複数の人間が関与する。複数の人間が関与する以上、その工程の中で作成される成果物はそれぞれ個性を伴っている。この個性がプロジェクト全体の生産性と品質を高めることに寄与していれば良いが、残念ながらそのようなことは極めてまれである。
多くの場合は個性があるが故に品質にばらつきが生じ、結果としてプロジェクト全体でみれば決して良い方向へは向かわない。そのため各企業はこれらのばらつきを押さえるべく、「○○基準」「××標準」といった約束事を設けることで、個人の成果物に対して一定の縛りを付けて品質改善に取り組むのである（図1）。
標準を軽視したBさんの例
Bさんは独立系システムインテグレータA社の中堅SEであり、今回同社が受注した大手生命保険会社の大規模Webシステム構築のPM（プロジェクトマネジャー）として抜擢された。これはBさんの実績と、今後PMとしてさらに大きくなってほしいというA社の人材育成的な観点も含まれていた。
Bさんはこれまで幾つかの小規模Webシステムの開発においてSEとして従事してきたことはあったが、今回のような規模のシステム開発経験は初めてである。会社側もBさんの経験不足を心配し、PL（プロジェクトリーダー）として、協力企業社員ではあるがベテランのFさんを付けることにした。
Fさんは、大規模システムということもあり、着任早々Bさんに次のような提案を行った。
・設計フェーズは、サブシステムごとに複数のチームに分けて設計を行う
・標準化チームを設置し、要件定義と並行して標準化作業を行う
・標準化チームは設計フェーズ以降、成果物の品質管理を行う
大規模システム開発経験の無いBさんは、サブシステムごとのチーム編成には「なるほど」と思って合意したが、標準化チームの設置には難色を示した。Bさんとしては、「なぜ標準化が必要なのか」と疑問に思ったからだった。これについて何度Fさんが説明してもBさんはなかなか納得しなかった。それどころか「Webシステムの開発は若手の方がむしろセンスがあるはず」と言い出す次第であった。Fさんは渋々Bさんに従うことにした。
基本設計フェーズに入り予定通り複数のチームに分かれて設計を行った。画面の概略は既に要件定義フェーズで確定している。そのため基本設計はすんなり完了するだろうとBさんは高をくくっていた。
ところが、設計書レビューに参加してBさんはがくぜんとする。開発チームごとに、作成した画面の操作方法がバラバラだったのだ。パッと見たところでは同じ思想で作られているように見えたが、詳細に見るとかなり違っていた。フォントや色・ケイ線といった画面の見た目だけならまだしも、画面遷移の考え方やポップアップメッセージの有無など、システム設計全体に影響を及ぼすような項目も違っていた。
小さいながらも入社以来多くのWebシステムを見てきたBさんである。このままではユーザーからNoを突きつけられると直感した。そこでシステム全体で統一感のある設計にしようと考えた。しかし、実際に統一しようとすると簡単では無いことが分かった。
各チームのサブリーダーは自分のチームの手戻りを恐れ、簡単には従おうとしないのである。あれこれ理由を付けては自分のチームの設計が一番だと言う。そうこうしているうちに時間だけは過ぎて行く。やむなくBさんは「えぃ！や！」とばかり、あるチームの設計に合わせるように他のチームへ指示したのだった。
結果的に、各チームの努力により遅延は最小限にすることができた。Bさんが大規模プロジェクト初挑戦だということで、Fさんがマスタースケジュール作成時にバッファーとして余分に取っていた期間が役に立ったのである。しかし、他チームの設計方針に従うことになったサブリーダーたちが抱いた小さなしこりは、プロジェクト終了まで消えることは無かったのである。
