開発標準
大手のSIerやベンダだとシステム開発でだいたいあるものが開発標準です。サブコンが事業主体になると結局プライムコンダクタの標準か顧客標準を適用することになって自社向けの標準の必要性が下がり、結果的に使われないから維持されず消えてなくなるわけだけど。そういったことを想定すれば、自社の開発標準を持っていて鮮度を維持しているなら、その組織には自社がプライムになっている事業があるということかもしれないですね。
そうそう、前述した開発標準とは、システム開発における開発標準であり、作業標準、品質管理標準、進捗管理標準、変更管理標準などのプロジェクトマネジメントの管理ツールである文書です。PMBOKは考え方の器でしかないのは以前に書いたとおりで、じゃあどうするののところを組織の中で揃えておく方が組織の中の誰もが見ても同じ理解できるようにするために揃えたのが標準を作る目的です。
とは言え、現実のプロジェクトは、そのプロジェクト毎に特性を持っているので作業標準が組織が定めたとおりそのまま使えることはないのは、作業標準自体が汎化してしまっているのでプロジェクトの特性の特性部分が考慮されていることはまずない、という背景があります。開発標準や業界のガイドラインを導入しようとするときには、こうしたことがあるものだと認識した上で、どう使うか考える時間を確保しないと導入したはいいがそれが組織の開発標準であったとしても使えない、使いにくい、意味がわからないというないないづくしになって、せっかくコストを掛けて維持していた開発標準の息の根を止めてしまいかねないので実は使う側の頭が問われていたりします。
自分が担当するプロジェクトの作業標準を決めたいけれど、組織には開発標準はないし、顧客（＝スポンサ）にはおたくのでいいよと裁量を渡されたときにはどうしたらよいでしょうか。何事も遡求するのはとても骨の折れる仕事ですし、なんのためにやっているかわからなくなる（作業をしつつやっておくことに意味があるタスクは、後からやっても意味がないことが多い）のでメンバの振る舞いを揃えるなら作業に手をつける前にやっておきましょう。
それで開発標準がないときにどうするかですが、メンバ全員が揃って成果物を作るために必要な工程や作業をトップダウンで段階的詳細化をして、一つひとつの作業を完了させることで成果物が出来上がる作業を記録すればいいです。それが作業標準になるので。
成果物目線ではそれでいいけれど、プロジェクトの品質要求や進捗遅延のペナルティ（債務不履行で裁判所にお呼ばれされるとか）があるならそういったことの予兆をモニタリングする仕組み＝進捗管理のプロセスを組み込んでいきます。
こうして作ったものがプロジェクトの、チームの開発標準だし、これは組織に開発標準があったとしてもその標準をテンプレにプロジェクトの特性を加減していくので最終的には同じものになります。全部出さなければならないと思うか取捨選択をプロジェクトの特性から判断できるかと結果は同じだけれどチームに求められるスキルは違うのでどっちがいいというものでもないです。特に後者はその作業は要らないと判断するのは難しいですね。
