ヨンと固辞の情報

成熟とは？

本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なりますが、この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 「プロジェクトの進め方を革新するプロジェクト」の最終目標は，企業そのもの，すなわち組織や文化・社風まで，プロジェクトを推進しやすいように変革することである。そのためには，自社の組織がどの程度プロジェクトをうまくこなせているのかを把握できる尺度が必要になる。そこで，ソフト開発プロジェクトを手掛ける組織の成熟度を測る手法を提唱し，本連載のまとめにしたい。 「プロジェクトのやり方を革新しろ，という提言に異論はない。ただ，革新を進めていくときに，物指しはないのかね。尺度がないと，そもそも目標が立てられないし，改革を進めていっても，どれだけ改善したのかが分からない。開発の生産性のデータは集めているが，それだけではプロジェクトの管理良しあしの巧拙を評価できないだろう」。 「プロジェクト管理は技術の問題ではなくて，その企業のマネジメントの問題です。組織とか，命令系統，仕事のやり方，さらには社風や企業文化までが複雑に絡みます。こうしたさまざまな要素の組み合わせによって，プロジェクトに強い企業から，いつも失敗してばかりの企業まで分かれるわけです。ですから，おっしゃるように，その企業や組織がどれだけうまくプロジェクトをやれるのかということを測る尺度が必要ですね。その一つとして，ソフト開発プロジェクトを担当するIT（情報技術）組織の成熟度を示すCMM（能力成熟度モデル）というものがあります」。 「CMMは，以前に勉強したことがある。米カーネギ・メロン大学が作った，ソフトウエア開発のプロセス群の分類でしょう。ただ，CMMで規定されている五つのレベルのどこに自分たちがいるかを判断するには，各レベルで規定されているプロセスを備えているかどうかを見るしかない。物指しとしてはちょっとおおざっぱなんだよね」。 「ソフト会社やユーザー企業の情報システム部門を調べると，8割以上の企業がCMMのレベル1になってしまうでしょうからね。優秀な社員（ヒーロー）に依存していて，きちんとした開発プロセスがない状態です。では，CMMのレベル1から2の間をもう少し分けた尺度を作ればいいのではないですか」。 以上は，ある超大手システム・インテグレータの幹部と筆者の間で交わされたやり取りである。この会話の後，インテグレータと筆者はプロジェクト・チームを作り，IT組織の成熟度を把握するモデルを開発している。 このインテグレータは日本を代表する企業の一つで，無数といってよいほど多数のプロジェクトを抱えている。各プロジェクトを成功させるために，同社は開発支援ツールや開発方法論の導入など，さまざまな手を打っている。次のステップとして，果たして効果が上がっているのかどうか，各プロジェクトを担当している組織のレベルを評価する方法を検討していた。 このインテグレータに限らず，ソフト開発を手掛ける企業や組織の経営者が切望しているのは，自分の会社や組織のレベルを測る物指しだろう。自社はどのくらいの水準で，他社より良いのか悪いのか。開発支援ツールを買ったり，プロジェクト管理のガイドラインを作ったりしたが，その効果はどうなのか。一連の疑問に答える適切な物指しがないのが現状である。 本連載で筆者はこれまで，「プロジェクトの進め方を革新するプロジェクト」の実施を提唱してきた。ここでも経営者の方々から，「プロジェクトのやり方が前より改善したということをどう測るのか」という疑問が出るだろう。 そこで，本連載のまとめとして，「IT組織の成熟度」を測る新しい手法を提案してみたい。この手法を使えば，自社の成熟度を把握して，プロジェクト革新の目標を立てられ，しかも改善状況も把握できるようになるはずだ。 図の右側に示したのが筆者が作ったIT組織の成熟度を示す新しいモデルである。ソフト開発企業あるいは組織のレベルを四つに分けた。プロジェクト管理やソフト開発にかかわる定性的な評価項目を100以上用意し，各項目について四つのレベルを規定してある。 図には例として，「ルール」と「測定」という評価項目を示した。ルールや各種の基準値が設けられ，それらに沿った活動ができていれば，ルールについてはレベル4になる。組織的にソフト開発の生産性などを示す数値を測定し，測定した数値を蓄積できていれば，「測定」についてはレベル4となる。 この新しいモデルを使うためのアンケート用紙も用意した。現場の開発者やプロジェクト・マネジャはアンケート用紙にある評価項目について，「できている」，「できていない」を記入していく。アンケート結果を点数に置き換えて集計すると，最終的には1から2の間の数値になるようにした。 なぜ1から2にしたかというと，新しいモデルは，CMMのレベル1から2の企業・組織を対象にしているからだ。つまり，新しいモデルで規定している評価項目をすべてクリアした企業は少なくとも，CMMのレベル2で規定しているプロセスを備えていることになる。 もちろん，アンケートへの回答が常に正しいとは限らない。そこで，実際には，幹部と現場の技術者の回答のギャップを分析したり，アンケート結果を基に個別に技術者をインタビューするなどしてから，最終的に成熟度を決めるようにしている。 新しいモデルは，四つのレベルごとに上位のレベルへ行くための「焦点」（ポイント）をまとめてある（図参照）。例えば，レベル2の企業は，プロジェクト管理に注力することで，レベル3へ上がれるようになる。さらに，各評価項目を上げるための改善策の案も用意した。このモデルを使う企業は，自社の強みと弱みを把握でき，弱い評価項目については用意された改善策を利用して，プロジェクト革新プロジェクトを始められる。

[ 89] 最終回 組織の成熟度向上に挑む：ITpro
[引用サイト]　 http://itpro.nikkeibp.co.jp/article/COLUMN/20070703/276584/?ST=biz_honshitsu

能力成熟度モデル統合 (のうりょくせいじゅくどもでるとうごう、CMMI; Capability Maturity Model Integration) は、組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したものである [1] 。 CMMIは、もともとは能力成熟度モデル (CMM; Capability Maturity Model) として開発された。 CMMIは、組織に5段階のプロセス成熟度レベルに照らして等級をつけて評価するために使うことができる。 CMMIで規定されている各レベルは、評価の対象となる領域のプロセスにおける標準化の程度に応じて、等級づけられている。 評価の対象となる領域はさまざまであり次のようなものがある。 1998年の時点では、ソフトウェア開発を行う組織の75%がレベル1であると推定されている (参考) 。 CMMIの前身にあたるCMMは、1980年代半ばにアメリカ合衆国のピッツバーグにあるカーネギーメロン大学 (CMU) のソフトウェア工学研究所 (SEI; Software Engineering Institute) で開発された。 CMMIは、航空電子工学ソフトウェアの開発や北アメリカ、欧州、アジア、オーストラリア、南アメリカ、アフリカなどの国々の政府主体で行うプロジェクトなどで、広く採用されてきており、こうした国々でCMMIに対する官民の関心は高い [2] 。 現在、いくつかの国々の省庁は、ソフトウェア開発契約に際して業者にレベル3の基準を達成しかつ運用できていることを必須としている。 また日本においても、ソフトウェアを発注する官公庁や民間組織がCMMIを採用し、一方でソフトウェア開発を担う組織がCMMIの指針に即して自らのソフトウェア開発プロセスを改善する動きが、徐々に広がりつつある。 CMMI (能力成熟度モデル統合) は、組織がプロセスを定め洗練するための手段である。 最初のCMMはソフトウェア開発プロセスを確立し洗練することを目標としていた。 成熟度モデルは、効果的なプロセスのさまざまな特性を構造化して記述した体系である。 カーネギーメロン大学 (CMU) のソフトウェア工学研究所 (SEI) はCMM/CMMIを英文で公表している。 有志によって日本語に翻訳された文書も公表されている。 いずれも無償でダウンロード/閲覧することができる。 CMMI (能力成熟度モデル統合) の前身である CMM (能力成熟度モデル) は、もともとは軍事研究の一環として資金を与えられて始まった。 アメリカ合衆国空軍がカーネギーメロン大学 (CMU) のソフトウェア工学研究所 (SEI) に資金を渡して、軍事部門がソフトウェアの下請業者を客観的に評価するものとして使えるモデルを作る研究を依頼した。 研究成果は1989年に Managing the software process の書名で出版された (日本語訳『ソフトウェアプロセス成熟度の改善』1991年) 。 CMMはその後も改訂・更新を経ている。 SEIはもはや CMM に対するサポートを止め、改訂版である CMMI (能力成熟度モデル統合、Capability Maturity Model Integration) が開発・サポートの対象となっている。 2006年現在、CMMI バージョン 1.2 が公表されており、またSEIのウェブサイトで全文を閲覧することができる。 1970年代に、技術の発達によりコンピュータが広く普及しよりさまざまな用途に使われるようになり、従来より少ない費用で導入できるようになっていた。 多くの組織は、コンピュータ化による情報システムを推進する方針を採り、それに伴い組織におけるソフトウェア開発の領域の比重も非常に大きくなった。 こうした情況から、開発者および開発管理者に対する要求は日増しに大きくなっていた。 このような要求には、経験をあまり積んでいない専門職の人々が対応していた。 不幸なことに、開発者に対する要求が非常に大きくなったことは、組織にとって苦痛を伴った。 ソフトウェア開発プロジェクトが失敗に終ることは、ごく普通のありふれたことになってしまった。 その原因は、コンピュータ科学が当時は未成熟であったことだけでなく、開発プロジェクトがその規模と複雑さにおいて野心的で多くの労力を伴う傾向が有ったためでもある。 この問題に対して、エドワード・ヨードン、ラリー・コンスタンティン、ジェラルド・ワインバーグ、トム・デマルコ、デイビッド・パーナスなどの人々は、ソフトウェア開発プロセスをより熟練した工程とするための研究を行い、その研究成果を論文および書籍として発表した。 CMMはもともとは政府のソフトウェア開発請負業者を評価するためのツールと位置づけられており、ソフトウェア開発契約に基づくプロジェクトを遂行する際に活用することが想定されていた。 もともとはソフトウェア開発の分野で活用されていたが、さまざまなプロセスの成熟度の一般的なモデルとして、広く適用されるようになっている (ITサービス管理プロセスなど) 。 システムインテグレータや情報技術関連組織などがCMMIを活用するようになっている。 CMMIのモデルは、ソフトウェア開発を行う組織のプロセス成熟度について、5つのレベルを規定している。 初期状態 (混沌とした、いきあたりばったりで、一部の英雄的なメンバー依存の状態)。成熟したプロセスを導入する際の、出発点のレベル。 管理された状態 (反復できる状態、プロジェクト管理・プロセスの規則の存在)、反復してプロセスを実行できるレベル 定義された状態 (制度化された状態)、プロセスが標準ビジネスプロセスとして明示的に定義され関係者の承認を受けているレベル。 定量的に管理された状態 (計測できる状態)、プロセス管理が実施され、さまざまなタスク領域を定量的に計測しているレベル。 最適化している状態 (プロセスを改善する状態)、継続的に自らのプロセスを最適化し改善しているレベル。 これらの各レベルには、それぞれの成熟度レベルを特徴づけるキープロセスエリア (KPA) が規定されている。 各キープロセスエリアには4つの要素 (共通特徴、コモンフィーチャ) が定義されている。 これらキープロセスエリアは必ずしもCMMI特有の要素ではない。 キープロセスエリアという文字通り、組織が成熟して任務を遂行できるようになるために行わなければならない諸段階を、表している。 CMMIによりプロセス改善に取り組む組織は、権威ある検証機関により成熟度レベルの検証を受けることとされている。 このように先ず組織が成熟度レベルの検証を受けることにより、次のレベルの達成に向けた計画を立てることができる。 成熟度レベルの飛び越しは許可されない。 注意: CMMはもともとは政府の請負業者が請け負ったソフトウェアを開発する能力を評価する手段を想定して作成された。 CMM/CMMIがソフトウェア開発プロセス成熟度のモデルとして一般的になると、CMM/CMMIに対する批判も多くなされるようになった。 商用のパッケージソフトウェアを開発する企業 (クラリス、アップルコンピュータ、シマンテック、マイクロソフト、ロータスなど) の多くは、CMMIが規定する水準の文書を滅多に管理していない。 この文書管理はCMMIのレベル2を達成するために必要である。 こうした企業のほとんどはレベル1に等級づけられるであろう。 アメリカ合衆国空軍が SEI (ソフトウェア工学研究所) に資金を提供して、SEIは軍がソフトウェア開発請負業者の客観的な評価基準として使うモデルを作成する研究を行った。 1989年に、CMM (能力成熟度モデル) は Managing the software process の書名で出版された (日本語訳『ソフトウェアプロセス成熟度の改善』1991年) 。 CMMに基づいた各モデルは多くの組織にとって有用であったが、複数のモデルを使いこなすことが難しい課題となっていた。 さらに、複数のモデルの適用を一つの組織内もしくは組織横断的に統合して実行することは、訓練、評価、プロセス改善において費用が高くついた。 複数のCMMモデルを適用するに伴う課題を克服する、CMM統合 (CMMI; CMM Integration) プロジェクトが立ち上げられた。 CMMI開発チームの目的は、3つのソースモデルを統合することであった。 CMMI は3つのソースモデルの後継版として位置づけられている。 SEI は SW-CMM、SECM、IPD-CMM および古いバージョンの CMMI を終了する方針を公表した[1]。 これらのモデルは新しいバージョンの CMMI が後継している。 SEIは、CMMIを改善する提案を歓迎している。 SEIにCMMIのフィードバックを渡す方法については、CMMIのウェブサイトを参照。 場合によっては、CMMIは他の方法論と組み合わせることができる。 CMMI と ISO 9001 を同時に施行することは、よく行われている。 JPモルガン・チェースは、CMMをコンピュータプログラミング方法論エクストリーム・プログラミング (XP) およびシックス・シグマと統合することを試みた。 この統合を行った人々は、統合した3つのの体系が互いを補強し、相互に矛盾することは無い、との所感をもった。 Extreme Programming (XP) Six Sigma CMMIを参照。 組織のソフトウェアプロセスの予測可能性、効率性、および管理は、これらの5つの段階を経て上ることを通じて改善されると確信している。厳格な基準ではないが、経験的な証拠がこの確信を裏づけている。 成熟度レベル1では多くの場合、プロセスは場当たり的であり、組織は安定した環境を提供しない。 こうした組織では、プロジェクトの成功は、組織に属する個々人の能力と英雄的行動に依存しており、有用性が証明されたプロセスを採用していない。 場当たり的で混沌とした環境であるにも関わらず、成熟度レベル1の組織は実際に動く成果物とサービスを提供することが少なくない。 しかしそれらは多くの場合プロジェクトの予算および予定期限を超過する。 成熟度レベル1の組織は、超過労働、危機に対処するプロセスの欠如、過去の成功を繰り返す能力の欠如、によって特徴づけられる。 成熟度レベル2の組織はソフトウェア開発などの成功を反復して実行ことができる。 このレベルの組織では、組織の全てのプロジェクトにおいて反復が実現できているとは限らない。 このレベルの組織では、何らかの基本的なプロジェクト管理を行い、費用と予定 (スケジュール) を管理している。 レベル2のプロセスの規律を実行することにより、これまで行ってきた実践は今後も意識して行われ続けられる。 これまで行ってきた実践は今後も首尾良く行われる場合、プロジェクトは文書化された計画に従って実行され管理される。 プロジェクトの情況や納品物の引渡しなどは、事前に定めておいた時点 (メジャーマイルストーンやメジャータスクの完了など) での管理を通して明確になる。 基本的なプロジェクト管理プロセスが確立し、費用、予定、開発対象の機能を管理する。 レベル2のプロセスの最低限の規律は、過去の類似した分野と範囲をもつプロジェクトの成功を、反復することである。 このレベルでは、費用もしくは納品予定日を超過するという大きなリスクは依然として存在する。 成熟度レベル3の組織では、組織の標準プロセスが確立しており、時が経つにつれ標準プロセスは改善される。 こうした標準プロセスは、組織全体に浸透させ組織における一貫性を確立すべく使用される。 組織のプロジェクトは、組織の標準プロセスにより適合ガイドラインに沿って、定義されたプロセスを確立する。 組織の管理部門は、組織の標準プロセスに基づいてプロセスの目的を確立し、こうした目的が確実に適切に取り組まれるようにする。 成熟度レベル2とレベル3の重要な違いは、標準群とプロセス記述と手続きである。 成熟度レベル2の組織では、標準群とプロセス記述と手続きは、プロセスのおのおのの具体的な内容において組織内でかなり異なっているかもしれない。 成熟度レベル3の組織では、あるプロジェクトや部門の標準群とプロセス記述と手続きは、組織の標準プロセスに適合している。 成熟度レベル4の組織では、正確な測定を行うことで、管理側はソフトウェア開発などの有効性を効果的に制御することができる。 特に、管理側は個別のプロジェクトに対してプロセスを調整し適合する道筋を同定することができる。 このとき測定可能な品質の低減や仕様からの逸脱は無い。 成熟度レベル4の組織は、ソフトウェア開発プロセスやソフトウェア保守などのための定量的な品質の目標を設定する。 プロセス全体の遂行に非常に大きく貢献するサブプロセスが選択される。 この選択されたサブプロセスは、統計的な技法と他の定量的な技法により制御される。 成熟度レベル3とレベル4の重要な違いはプロセス遂行の予測可能性である。 成熟度レベル4では、プロセスの遂行は統計的な技法と他の定量的な技法により制御され、定量的に予測可能である。 成熟度レベル3では、プロセスは単に定性的に予測可能なだけである。 成熟度レベル5は、段階的および革新的な技術的進歩を通じた継続的なプロセスの有効性の改善を重視する。 組織にとっての定量的なプロセス改善の複数の目標が定められる。 これらの目標は、ビジネス上の目標の変更を反映して継続的に改訂される。 またこれらの目標は、プロセス改善の管理における基準として使われる。 適用されたプロセス改善の有効性は計測され、定量的なプロセス改善目標に照らして評価される。 定義されたプロセスと組織の標準プロセスのセットの双方が、改善活動の計測の対象となる。 プロセス改善は、プロセスにおける変動の共通の原因に取り組み組織のプロセスを計測可能な形で改善するために、同定され評価され適用される。 敏捷で適応力のある進取的なプロセスの最適化は、能力の高い労働者がビジネス価値と組織の目標に同調して参加するかどうかにかかっている。 組織における変化と機会にすばやく対応する能力は、学習を加速し共有する道筋をみつけることで高まる。 成熟度レベル4とレベル5の重要な違いは、取り組む対象である、プロセスにおける変動の種類である。 成熟度レベル4では、プロセスはプロセスにおける変動の特定の原因に取り組むことと結果の統計的予測と関連している。 プロセスは予測可能な結果を出すかもしれないが、その結果はあらかじめ定めた目標の達成には不十分であるかもしれない。 成熟度レベル5では、プロセスはプロセスにおける変動に共通する原因に取り組むこととプロセスを変更し (すなわちプロセスの遂行能力の平均値を変更する) その遂行能力を向上させ (統計的確率を修整しつつ) あらかじめ定めた定量的なプロセス改善目標を達成できるようにすることと関連している。 SEIのCMMIの近年のバージョンではレベル0を導入している。 レベル0は、「不完全な」プロセスレベルとして特徴づけられる。 CMMIに関心をもつ多くの人々は、このレベルを冗長であるもしくは重要ではないとして、無視している。 ただしプレスマンなどの人々はこのレベルに注目している。 SEI CMMI 2002年8月のバージョンの18頁を参照 [5]。 アントニー・フィンケルシュタイン [6] は、負 (マイナス) のレベルが何段階か必要だと考えている。 負のレベルは、平凡であるに加えてはっきり非生産的な環境を表す。 この負のレベルは、トム・ショルシュ [7] により「能力非成熟度モデル」("Capability Immaturity Model") として改良された。 CMMI (能力成熟度モデル統合) には成果物開発の観点を示す複数のプロセス領域があり、組織のプロセスを網羅するべく定められている。 ソフトウェア業界内は多様でありまた気まぐれである。 あらゆるソフトウェア開発方法論には支持者と批判者が存在する。 CMMI (能力成熟度モデル統合) も例外ではない。 CMMは、国防組織に対して、ソフトウェアの請負業者が、期日どおりに、予算の範囲内で、受け入れ可能な基準に沿って、納品する能力を検証し記述する基準を、提供した。CMM/CMMIは、まず間違いなくこの役割を果たすことに成功している。それだけでなくソフトウェアの営業を行う一定の人々が自社の経営者やソフトウェア開発者に「CMM/CMMIによるプロセス改善を実施してください」と要求するよう促している。 CMMIは、組織のソフトウェア開発の成熟度を検証できるようにすることを意図している。CMMIは、アウトソーシングもしくはソフトウェア開発を外注する際に重要なツールとなっている。インド、アイルランド、エジプト、シリアなど多くの国々の経済開発を担う省庁は、CMMIをアメリカ合衆国のアウトソーシング契約を一定の基盤のもとで行えるとして、称賛している。 CMMIは、組織としての改善の良い枠組みを提供している。CMMIにより企業は自社のプロセス改善計画において優先順位をつけることができる。 CMMIは、世界的に広く影響を与えるには至っていない。SEIが公表している企業の名称と達成した成熟度レベルだけからは、実際の普及の度合いを正確に知ることは難しい。企業の名称と達成した成熟度レベルは、SEIが企業の要望を受けて一覧にして公表される[4]。CMMIの最近の成熟度の分析はウェブで公表されている[5]。 CMMは官僚的な組織に適している。官僚的な組織とは、例えば政府省庁、大企業、規律正しい専売会社などである。もしCMMを適用する組織が十分に大規模であれば、CMM監査チームを設置して監査結果を経営陣に報告させることができるかもしれない (この監査チーム設置と経営陣への報告は、SEIにより推奨されている) 。監査チームと経営陣への報告は、情報技術を担う組織全体に影響を及ぼし、一方でCMMの流儀を完全に達成することを重視するようになるが、他方でアプリケーションソフトウェアの開発や顧客の要求、市場については軽視する結果になるかもしれない。プロジェクトが納期に基づいて遂行される場合、CMMのプロセスと流儀に対する徹底した依存は、納期に間に合わせるためにはじゃまになるかもしれない。これは、とにかく何らかの製品を実際に出荷することが、製品の品質の高さや機能の豊富さよりも重要な場合に、あてはまる。 メトリクスによるソフトウェアプロセスの科学的な管理は、CMMIではレベル4以上で言及されている。ビジネスでプロセスの費用低減を検証することはほとんど無く、経験に基づいた根拠を参考にする程度である。望ましいのは、根拠の大部分が、CMMで要するビジネス上の全てのオーバーヘッドにより、情報技術の頭数と、ビジネス上の費用、および顧客を犠牲にすること無く市場に出荷するまでの期間を、低減することに、なっていることである。 ソフトウェア開発を担う組織に対してCMMIに準拠していると認定する第3者機関は存在しない。組織自らが正直に検証することが提唱されている ([6]および[7]) 。 CMMは有効なソフトウェア開発組織をどのようにして作るかを記述していない。CMMは成功した組織が行ったベストプラクティスを記述している。CMMに準拠することにより、プロジェクトが成功する保証が得られるわけではない。しかしCMMに準拠することにより、プロジェクトを成功する方向へと改善することは可能である。 CMMは、本質的なことの推進よりもCMMに記述されたプロセスを推進しているというように、過度に官僚的な内容だと解釈されることがある。例えば、エンドユーザへのサービスの提供よりも、予測可能性を強調しているというように。商業的に成功している方法論 (例えばラショナル統一プロセス) では、組織が他の組織を満足させるような能力や、仕様全体を満たすソフトウェアを開発する能力には、焦点を当てていない。そうではなく商業的に成功している方法論では、組織が OMG (Object Management Group) の 統一モデリング言語 (UML) の手法に従って、特定のエンドユーザの「ユースケース」を満たす能力に焦点を当てている。 開発する対象を記したソフトウェアの仕様を作成すると、発注側の経営者により公に承認される。この仕様は活きた文書ではない。しかし別途、後にソフトウェア開発の次のサイクルに編入される。 技術仕様を使う。この文書はソフトウェア仕様で規定された対象をどのようにして正確に開発するかを記した文書である。この文書は活きた文書である。 ソフトウェアコードのメトリクスを使うピアレビューを行う。開発者たちが実装のウォークスルーを行い、実装の改善を促す。 注意: ピアレビューには課題がある。レビューを行うのは既にコードが実装された時点であり、その際にまずい設計を「微調整」で直すことはできない。 ソフトウェアを開発の正しい方法があり、その正しい方法は工学的設計を含む科学的なプロセスであるという思想。 世界中の非常に多くの情報技術企業が CMMI (能力成熟度モデル統合) とそのレベルに関心をもっている。 1999年6月にインドの Wipro Technologies 社が、SEI CMM レベル5を達成した世界で最初の情報技術サービス企業となった。 レベル5はCMMの最高の水準である。 毎年、世界中の多くの情報技術企業が CMMI の制度を導入し、自社の CMMI レベルを向上させている。 2006年現在、CMMI レベル5を達成した企業の約75%がインドに存在する企業である。 これらの企業の多くはバンガロール市に存在する。[要出典] パーソナルソフトウェアプロセス (PSP) と チームソフトウェアプロセス (TSP) - この2つのプロセスモデルは、ソフトウェア工学研究所 (SEI) により個人とチームにそれぞれ適用するモデルとして開発された。 ある企業が何らかの「エンタープライズレベル」の成熟度レベルを達成したと主張している場合、私たちは懐疑的になる必要がある。 達成したと主張するレベルが高ければ高いほど、より懐疑的になる必要がある。 多くの場合こうした主張はあるときに何らかのプロジェクトを自社で行うことを意図したマーケティング技術である。 その企業が実際に主張する水準のレベルを達成していることはほとんど無い。 ワッツ・ハンフリー、日本電気株式会社 (訳)、藤野喜一 (監訳)『ソフトウェアプロセス成熟度の改善』、日科技連出版社、1991年 ISBN 4817160330 カテゴリ: 出典を必要とする記事 | プロジェクトマネジメント | ソフトウェア開発工程 | 組織 (団体)

[ 90] 能力成熟度モデル統合 - Wikipedia
[引用サイト]　 http://ja.wikipedia.org/wiki/%E8%83%BD%E5%8A%9B%E6%88%90%E7%86%9F%E5%BA%A6%E3%83%A2%E3%83%87%E3%83%AB%E7%B5%B1%E5%90%88

筆者がITSS導入のコンサルティングを進める中で、企業の人的組織の成熟度に合った導入が不可欠であることに気付いた。ここでは、ITSS導入の日本企業における意義、成熟度に合ったITSS導入の必要性を述べたうえで、「People CMM」を取り上げ「成熟度に合ったITSS導入とは何か？」を明らかにする。（→記事要約<Page2>へ） ITベンダやユーザー企業のシステム部門、システム子会社のITプロフェショナル人財（ここでは人的資本を「人財」という言葉で表す）育成を目的としたITSS（ITスキル標準：IT Skill Standard）導入のコンサルティングを進める中で、企業の人的組織の成熟度に合った導入が不可欠であることに気付いた。 ここでは、ITSS導入の日本企業における意義、成熟度に合ったITSS導入の必要性を述べたうえで、人的組織の成熟度モデルとして「People CMM」を取り上げ、「成熟度に合ったITSS導入とは何か？」を明らかにする。 ITSSはIT人財の効果的な育成、IT技術者のキャリアパスの確立を容易にするために、IT業界におけるスキルの共通言語・ものさし・辞書として、2002年12月に経済産業省から発表された。発表から2年半が経過し、大手ITベンダだけではなく、ユーザー企業やシステム子会社への導入も進んでいる。ITSSでは、11種類の職種、38種類の専門分野が設定されている（表1参照）。 ITSSを導入するためには、ITSSで定義されている職種・専門分野から自社で必要な職種・専門分野を取捨選択する必要がある。また、ITSSで定義されていない職種・専門分野がある場合には、「ETSS（組み込みスキル標準：Embedded Technology Skill Standards）」や「経理・財務サービススキルスタンダード」のような、ほかのスキル標準から該当するものを選択したり、あるいは自社で独自に定義する必要もある。 このようにITSSの導入には、ITプロフェショナルという限られたエリアではあるが、職種・専門分野の内容および、それに必要なスキルを自社用に定義することが必要となる。これは、日本企業が苦手としている仕事の内容を定義する職務定義を行い、なじまないといわれていた「職務制度」を導入することと同じではないだろうか？ 米国企業で一般的である「職務制度」と、日本企業で一般的である「職能制度」との差を明確にしたうえで、ITSS導入の日本企業における意義を考えてみる。 米国では、詳細な職務分析により定義された職務定義に基づく人事制度である職務制度が一般的である。詳細に仕事を分析し、職務内容をできる限り明確に定義した職務記述書と、その職務を遂行するために、必要な能力要件や経験を記述した職務明細書が作成される。これらに記述された職務定義によりレベル分けが行われ処遇が決定する。採用も職務定義に基づき募集が行われ、現場主体で採用が決定する。 一方、日本では1973年のオイルショック以来、年功序列制度に代わる人事制度として職能制度が多くの企業で採用された。職能制度は従業員の職務遂行能力（職能）に注目してレベル分けが行われ処遇が決まる。職務定義と同様に、職能を定義した職能要件定義書が作成されるが、その内容は職務定義と比較すると非常にあいまいであり、抽象的な表現のものがほとんどである。また、中途採用以外は職務を限定せずに募集が行われ、人事部門主体で採用を決定し、入社後に職務が決められる。 この日米の人事制度の差は、キャリア開発においてもスペシャリスト（プロフェッショナル）志向の米国に対して、ゼネラリスト志向の日本という差にも明確に表れている。職務定義に基づき募集・採用が行われる米国においては、個人は採用前に職務にふさわしいスキル・知識を持っていることが期待されるため、目標とする職務に合った能力開発を個人で行う必要があり、スペシャリストを目指すことになる。 日本では職務を限定しない募集・採用であり、入社後多くの部署をローテーションすることにより、幅広いスキル・知識を身に付けることが求められることから、ゼネラリスト志向となる（表2参照）。 ITSSの定義書の副題「〜IT サービス・プロフェッショナル育成の基盤構築に向けて〜」にあるように、ITSSはITプロフェショナル人財育成のためのものである。従って、ITSSを日本企業に導入するということは、IT関連部門という限られたエリアではあるが、従来のゼネラリスト志向のキャリア開発・人財育成から、スペシャリスト志向に転換するという大きな意義がある。 そのため、スペシャリストに適した職務制度を構築するのと同様な取り組みが、ITSSを導入する際に、企業内で行われなければならない。職務制度の基盤である職務定義に当たるのが、前述したITSSを活用した職種・レベルの定義である。そして、定義した職種・レベルをベースに給与などの処遇を決めるのであれば、まさに職務制度を採用することになる。 しかし、実際には定義された職種・レベルを給与・処遇に連動させず、人財育成のためのみに活用する企業が現状では多い。個人の職種・レベルを認定したうえで、目標面談の中でキャリアアップのための育成目標を設定し、研修・教育、実務経験の場の提供を行い、年度末に育成結果を評価して翌年の育成計画を立案する（図3参照）。あくまで、目標による管理の一項目として、また、人財育成のベースとして、職種・レベルを活用するに留めている。緩やかな職能制度から職務制度への移行を図っているとみることもできるであろう。 情報マネージャのための「今日のひと言」 - 2007/11/16『苦労』 何でも苦労するのが、人間として当たり前だと考えてしまいます。しかし……>>続きはクリック .NETアプリケーションの単体テストと静的検証を自動化する「Parasoft .TEST 4.0」、テクマトリックスが発売 ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン ＠IT情報マネジメント トップ｜IT戦略 トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ

[ 91] ＠IT情報マネジメント：人的組織の成熟度に合ったITSS導入とは（前編）
[引用サイト]　 http://www.atmarkit.co.jp/fbiz/cstaff/complete/itss/01/01.html

前回は、ITSS導入の意義と職種定義の必要性、そして現実の導入には企業間格差があり、それは人的組織の成熟度の差にあることを説明した。今回は、人的組織の成熟度のモデルとして「People People CMMは、カーネギーメロン大学がソフトウェア開発プロセスの成熟度モデルとして開発したCMMを人的組織力の管理に適用したものであり、Ver1.0が1995年に、Ver2.0が2001年にリリースされている。ソフトウェアCMMが開発されてから、CMMを多方面に活用しようという動きから、さまざまなCMMが開発された。 Integration）に統合化されたが、多くのCMMがプロセスを対象としているのに対して、People CMMは組織を対象としているため、統合化の対象にはなっていない。 People CMMは、組織の人的能力を「永続する人的組織の実力」に改善することを目的としている。この中では、人的組織の実力は、組織の事業活動を実行するための知識・スキル・プロセス能力によって示されるとし、これらを人的組織のコンピテンシと呼んでいる。個人に帰属する知識・スキルだけではなく、組織に帰属するプロセス能力を合わせて、人的組織の力として定義しているところが特徴的である。 構造はほかのCMMと同様に、5段階の成熟度レベルに対して、プロセスエリア、ゴールとゴールを達成するためのプラクティスを定義している（図4参照）。 すでに、IBMやボーイング、シティバンクなどの米国大手企業やソフトウェアCMMの導入に積極的なインドのIT企業などで導入されており、インド最大のIT企業であるタタ・コンサルタンシー・サービシズは、ソフトウェアCMMでレベル5、People People CMMの概要を知るために、成熟度レベルとプロセスエリアを見てみることにする（図5参照）。 レベル1：初期段階であり、人的組織のプラクティスが一貫せずに適用される状況である。アドホックな対応、その場限りな対応がなされている段階。プロセスエリアとして定義されているものはない。 レベル2：管理された段階であり、管理者は人を管理し、開発する責任を持つようになる。プロセスエリアとしては、要員配置、作業環境、トレーニングと開発、意思疎通と調整、業績管理、報酬が定義されている。レベル1からレベル2に上がるためには、繰り返し可能なプラクティスが必要となる。 レベル3：定義された段階であり、人的組織のコンピテンシ（知識・スキル・プロセス能力）とコンピテンシをベースとしたワークグループを開発し、事業の戦略や目標と一致させることが必要になる。プロセスエリアとしては、コンピテンシ分析、コンピテンシ開発、コンピテンシに基づくプラクティス、ワークグループ開発、人的組織力の計画策定、キャリア開発、参加型文化が定義されている。レベル2からレベル3へ上がるためのキーワードは、コンピテンシベースである。 レベル4：予見可能な段階であり、人的組織のコンピテンシに権限を委譲したうえで、成果を定量的に管理する必要がある。プロセスエリアとしては、コンピテンシ統合、権限委譲されたワークグループ、コンピテンシに基づく資産、定量的業績管理、組織の実力管理、メンタリングが定義されている。レベル3からレベル4へ上がるためには、プラクティスの測定と権限委譲が重要となる。 レベル5：最適化の段階であり、個人、ワークグループ、組織の実力を継続して改善し、整合させる必要がある。プロセスエリアとしては、継続した実力改善、組織的成果達成に対する一致協力、継続した人的組織力の革新が定義されている。レベル4からレベル5へ上がるためには、継続的にプラクティスを改善することが求められている。 People CMMは米国の大学で策定されたものであり、米国の人事制度である職務制度を基盤として開発されているため、日本企業に適用する場合には注意が必要である。 レベル2の段階においても、すでに職務定義されていることが前提になっており、職務定義に合わせた要員配置がなされ、報酬が支払われていることはあえて記述されていない。しかし、多くの日本企業では、職能制度の下で職務を決めずに募集・採用が行われ、職務ではなく職務遂行能力に基づく等級分けがなされ、報酬が支払われている。そのため、日本企業でレベル2をクリアするためには、まず、職種・レベルの定義を行う必要がある。 また、レベル3のプロセスエリアに挙げられているキャリア開発は、職種・レベルを定義し、職種間の関連を示した日本企業のいうキャリアパス構築ではなく、企業の事業戦略や事業目標に合わせたコンピテンシ開発をしたうえでのコンピテンシベースのキャリアを開発するための方法を策定することである。筆者のいう人財開発戦略立案に近いものである。 日本企業への適用する場合の考慮点を加味したうえで、人財開発という側面からPeople CMMを見ると次のようになる（図6参照）。 管理者が人を開発する責任を持つためには、組織として職種・レベルが定義され、キャリアアップを実現する仕組みが構築されている必要があるため。 人的組織コンピテンシを開発して事業戦略や事業目標と一致させるためには、事業戦略に基づく人財開発戦略を作る必要があるため。 情報マネージャのための「今日のひと言」 - 2007/11/16『苦労』 何でも苦労するのが、人間として当たり前だと考えてしまいます。しかし……>>続きはクリック .NETアプリケーションの単体テストと静的検証を自動化する「Parasoft .TEST 4.0」、テクマトリックスが発売 ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン ＠IT情報マネジメント トップ｜IT戦略 トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ

[ 92] ＠IT情報マネジメント：人的組織の成熟度に合ったITSS導入とは（前編）
[引用サイト]　 http://www.atmarkit.co.jp/fbiz/cstaff/complete/itss/02/01.html