月曜なので、PM話（笑）
”マネジメント”って言いますが、何をどう管理するのか？
意外に難しい問いだったりしますな。
各社とも、それなりに自社の管理規定を持ってることだと思いますが、規定通りやれば良いのか？と言えばさにあらずで。
ISO9000とかだと、開発の品質ってよりも「プロジェクト品質」、それもどちらかと言うと、顧客との契約とか取り決め関連が中心で、忠実にやってもプログラム品質に直結するような規定は、実は余りなかったりします。
ま、各社の規定を作る際、その部分を補完してたりするところもあるだろうから、一概には言えないんだけどね。
それに、実際の開発以前に問題が起きてるケースてのも異常に多いので、これはこれで無意味ではないかと。
そこ行くと、CMMIは開発プロセスをターゲットにしたものなので、非常に開発者にとっては判り易いっすね。
と言っても、CMMIでレベル取得した各社のプロセス定義とかアーティファクトとかの話で、CMMIの公式日本語翻訳とかは解説がないと難しいかも。
それはそれとして．．．
で、寨主的にCMMIの方が実際の現場から見て優れていると思われる最大のポイントは、CMMIにテーラリングのプロセスがあることっす。
簡単に言うと、テーラリングってのは、規定されたプロセスを自分のプロジェクトのニーズに合うようにカスタマイズするためプロセスです。
何故これが大きいか？
例えばですけど、１００人のプロジェクトを管理する方法論と５人のプロジェクトを管理する方法論では、当然違いがあるんですけど、普通規定を作る際には大きい方をターゲットに作るもんです。
つまり、ISO9000のように規定通りに遵守しろってことになると、月働１００人月を管理するためのプロセスを５人のプロジェクトでもやらないといけないわけで、オーバースペックになっちまうんですな。
が、テーラリングがあると、５人のプロジェクトを管理する必要最低限のプロセスやアーティファクトを自分たちで検討できるんですわ。
勿論、勝手にやって良いわけじゃなくて、SQAと呼ばれる人たちに承認はしてもらわないといけませんけどね。
勘違いしちゃ困るけど、「面倒臭いからやらない」ってのはダメよ（笑）
小さいプロジェクトには当然管理工数も沢山は取れないので、現場にできるだけ負荷を掛けず、しかも押さえないといけないQCD＋αの状態を管理するために、どうやって何を管理するかを自分たちで検討できる余地があるってことですね。
本当の管理ってのは、つまりそう言うことですってば。
いや、実際覚えのある人もいると思うけど、ISO9000の流行り始めた当初は、
「今回のプロジェクトはISO9000対象なんだよ」
「はぁ、じゃあ工数３割増しで良いっすか？」
「うん、仕方ないよな」
なーんて非生産的な会話が交わされたもんです（笑）
何でもかんでも紙に残す、残したら互いに承認する、承認されたこと以外は基本的に認めない、みたいなもんがISO9000のベースにあるので、洒落にもなりませんねぇ。
ISOは敢えて言うならヨーロッパ系のものですけど、実はソフトウェアの開発に関しては、ヨーロッパってのは酷かったらしい。
納期を守らないなんてのは当たり前だったみたいっす。
イギリスなんかの話でも、良く聞きますけどね。
なので、契約したんだから約束守れ！って意味合いが強くて、どちらかと言うと顧客側を守るための規定と言った感じがします。
事実、欧州方面との取引の際には、ISO9000取得が絶対条件なんて言われてた時期がありましたしね。
それに比べると、日本は随分古くから世界に冠たるQC先進国だったし、納期意識も抜群に高いので、そもそも欧州とは土壌が違うわけなんですが、ISO9000入れるについては、まぁ世界の風潮ってこともあったんでしょう(^_^;
てなわけなので、CMMIのレベル２とか３を取得して、自社プロセスの運用をしている会社で、「テーラリングなんて以ての外！全てのプロジェクトは規定通りのマネジメントを行うべし！」なーんて運用をしてる会社があったとしたら、将に宝の持ち腐れ、と言うより寧ろ百害あって一利なし、CMMIを理解してないと言うしかありませんな。
まぁ、真面目にSEPGやSQAをやってる人たちが運用していればそんなことはないと思うけど、結構片手間に業務持ちながらってとこが多そうだからなぁ(-_-;
あ、SEPGって、システムエンジニアとプログラマってことじゃないよ（笑）
CMMIのプロセスを検討する人のこと。（参考までに言うと、「ソフトウェア・エンジニアリング・プロセス・グループ」の略っす）
もし、うちの会社は理解してないかも．．．と、心当たりがあるようなら、自社のSQAと話してみるとよろしいかと。
で、SQAが理解してそうもなかったらどうするかって？
喧嘩するしかないでせう（笑）
”マネジメント”って言いますが、何をどう管理するのか？
意外に難しい問いだったりしますな。
各社とも、それなりに自社の管理規定を持ってることだと思いますが、規定通りやれば良いのか？と言えばさにあらずで。
ISO9000とかだと、開発の品質ってよりも「プロジェクト品質」、それもどちらかと言うと、顧客との契約とか取り決め関連が中心で、忠実にやってもプログラム品質に直結するような規定は、実は余りなかったりします。
ま、各社の規定を作る際、その部分を補完してたりするところもあるだろうから、一概には言えないんだけどね。
それに、実際の開発以前に問題が起きてるケースてのも異常に多いので、これはこれで無意味ではないかと。
そこ行くと、CMMIは開発プロセスをターゲットにしたものなので、非常に開発者にとっては判り易いっすね。
と言っても、CMMIでレベル取得した各社のプロセス定義とかアーティファクトとかの話で、CMMIの公式日本語翻訳とかは解説がないと難しいかも。
それはそれとして．．．
で、寨主的にCMMIの方が実際の現場から見て優れていると思われる最大のポイントは、CMMIにテーラリングのプロセスがあることっす。
簡単に言うと、テーラリングってのは、規定されたプロセスを自分のプロジェクトのニーズに合うようにカスタマイズするためプロセスです。
何故これが大きいか？
例えばですけど、１００人のプロジェクトを管理する方法論と５人のプロジェクトを管理する方法論では、当然違いがあるんですけど、普通規定を作る際には大きい方をターゲットに作るもんです。
つまり、ISO9000のように規定通りに遵守しろってことになると、月働１００人月を管理するためのプロセスを５人のプロジェクトでもやらないといけないわけで、オーバースペックになっちまうんですな。
が、テーラリングがあると、５人のプロジェクトを管理する必要最低限のプロセスやアーティファクトを自分たちで検討できるんですわ。
勿論、勝手にやって良いわけじゃなくて、SQAと呼ばれる人たちに承認はしてもらわないといけませんけどね。
勘違いしちゃ困るけど、「面倒臭いからやらない」ってのはダメよ（笑）
小さいプロジェクトには当然管理工数も沢山は取れないので、現場にできるだけ負荷を掛けず、しかも押さえないといけないQCD＋αの状態を管理するために、どうやって何を管理するかを自分たちで検討できる余地があるってことですね。
本当の管理ってのは、つまりそう言うことですってば。
いや、実際覚えのある人もいると思うけど、ISO9000の流行り始めた当初は、
「今回のプロジェクトはISO9000対象なんだよ」
「はぁ、じゃあ工数３割増しで良いっすか？」
「うん、仕方ないよな」
なーんて非生産的な会話が交わされたもんです（笑）
何でもかんでも紙に残す、残したら互いに承認する、承認されたこと以外は基本的に認めない、みたいなもんがISO9000のベースにあるので、洒落にもなりませんねぇ。
ISOは敢えて言うならヨーロッパ系のものですけど、実はソフトウェアの開発に関しては、ヨーロッパってのは酷かったらしい。
納期を守らないなんてのは当たり前だったみたいっす。
イギリスなんかの話でも、良く聞きますけどね。
なので、契約したんだから約束守れ！って意味合いが強くて、どちらかと言うと顧客側を守るための規定と言った感じがします。
事実、欧州方面との取引の際には、ISO9000取得が絶対条件なんて言われてた時期がありましたしね。
それに比べると、日本は随分古くから世界に冠たるQC先進国だったし、納期意識も抜群に高いので、そもそも欧州とは土壌が違うわけなんですが、ISO9000入れるについては、まぁ世界の風潮ってこともあったんでしょう(^_^;
てなわけなので、CMMIのレベル２とか３を取得して、自社プロセスの運用をしている会社で、「テーラリングなんて以ての外！全てのプロジェクトは規定通りのマネジメントを行うべし！」なーんて運用をしてる会社があったとしたら、将に宝の持ち腐れ、と言うより寧ろ百害あって一利なし、CMMIを理解してないと言うしかありませんな。
まぁ、真面目にSEPGやSQAをやってる人たちが運用していればそんなことはないと思うけど、結構片手間に業務持ちながらってとこが多そうだからなぁ(-_-;
あ、SEPGって、システムエンジニアとプログラマってことじゃないよ（笑）
CMMIのプロセスを検討する人のこと。（参考までに言うと、「ソフトウェア・エンジニアリング・プロセス・グループ」の略っす）
もし、うちの会社は理解してないかも．．．と、心当たりがあるようなら、自社のSQAと話してみるとよろしいかと。
で、SQAが理解してそうもなかったらどうするかって？
喧嘩するしかないでせう（笑）
