パートナーネットワークの成熟度モデルを構築する方法

成熟度モデルの構築は、文章を書く仕事ではなく、設計する仕事です。目的からバージョン1.0までの8つのステップ、無料の4ページテンプレート、架空の連盟を例にした記入済みサンプル、避けるべき落とし穴を紹介します。

理事会資料に、依頼が一行で記されていることはよくあります。「パートナー向けの成熟度モデルを開発すること」。事務局の誰かが表計算シートを開き、「初級」から「優秀」までの見出しを5つ入力して、セルを埋め始めます。数週間後の会員会議では、ガバナンスやデジタルスキルについては誰も話しません。話題になるのは、会員が「良い」のか「とても良い」のか、そして誰がそう決めたのかです。

問題は、たいてい作業量ではありません。意思決定の順序です。このガイドでは、目的から初回の改訂まで、パートナーネットワークの成熟度モデルを8つのステップで構築する方法を紹介します。無料の4ページテンプレート、架空の連盟を例にした記入済みサンプル、そして私なら避ける落とし穴も取り上げます。

成熟度モデルとは何か、その着想はどこから来たのか

1986年11月、カーネギーメロン大学のソフトウェア工学研究所(Software Engineering Institute)は、米国連邦政府がソフトウェア請負業者の能力を評価できるようにする方法を求める依頼を受け、プロセス成熟度の枠組みの開発に着手しました。1993年までに、それは「ソフトウェア能力成熟度モデル(Capability Maturity Model for Software)」となり、SEI自身の言葉によれば、その5つの成熟度レベルは「順序尺度を定義」しています[1]。

基本的な形は変わっていません。想定された、望ましい、または典型的な発展の道筋を、個別の段階に分けて示すものです[2]。各レベルは、そこに到達するために何が満たされていなければならないかを示します。そのため、評価を通じて組織の現在地を把握し、次のステップを明らかにできます。2005年までに、ITサービスからナレッジマネジメントまで、150を超える成熟度モデルが存在していました[3]。しかし、Becker、Knackstedt、Pöppelbußがそのうち51件を調査したところ、設計プロセスを詳細に記録していたのはわずか9件でした[2]。以下では、その研究に基づく手法をプログラムチーム向けに紹介します。

成熟度モデルを構築する8つのステップ

ここで紹介するステップは、あらゆる成熟度モデルの開発に向けてde Bruin、Rosemann、Freeze、Kulkarniが提案した各段階、すなわち範囲設定、設計、内容の作成、テスト、導入、維持に沿ったものです[3]。各段階の判断は次の段階を制約します。また、パイロットを行うと、少なくとも一度は記述を書き直すことになります。

成熟度モデルを構築する8つのステップを示す図。目的と用途、次元、レベル、記述、エビデンス、パートナーとの検証、パイロットと調整、ガバナンスと再評価を、それぞれ該当する開発段階とともに表示
8つのステップと、それぞれが属する開発段階。

1. モデルの目的を決める

レベルを一つでも書く前に、このモデルがどのような意思決定に役立つのかを記してください。研究では、モデルの用途を3つに分類しています[3][4]。記述型モデルは、各パートナーの現在地を示します。処方型モデルは、次に何をすべきかも示します。比較型モデルは、パートナー間や地域間のベンチマークを行いますが、そのためには多数の評価と非常に安定した基準が必要です。ほとんどのパートナーネットワークに必要なのは、最初の2つです。

同じページに、誰が記入するのか(パートナー単独、あなたと共同、またはあなたの確認を受けて記入)、どのくらいの頻度で行うのか、そして何には決して使わないのかも記してください。私の経験では、最後の項目を一行加えるだけで、どんな説明文よりも率直な回答を得やすくなります。会員が、このモデルによって会員資格や助成金が決まるのではないかと疑えば、自己評価を高くつけます。その結果、モデルには実在しないネットワークが描かれることになります。

2. 次元を選ぶ

次元とは、モデルで扱うテーマです。ガバナンス、財務、デジタルスキル、セーフガーディング、若者の参加などが該当します。複雑さを抑え、互いに独立させるため、数は絞りましょう(de Bruinらの2つのモデルでは、主な構成要素はそれぞれ6つと4つでした)。また、相互に重複せず、全体として必要な範囲を漏れなく網羅するようにします[3]。同じエビデンスが二重に数えられず、目的の達成に必要な要素が欠けていない状態が理想です。私は、4〜7個を目安にし、テーマの範囲が広い場合は2〜3個の下位次元に分けています。

独自のモデルを書く前に、既存のモデルを確認しましょう。新しいモデルを構築する際に、既存モデルとの比較を行うことは、Beckerらが示した最初の要件です[2]。能力強化を目的とするなら、2001年にMcKinseyがVenture Philanthropy Partners向けに作成したグリッドの7つの要素が、確かな出発点になります[5]。当社のパートナー能力評価ガイドで紹介している6つの領域も参考になります。

3. レベルを4つまたは5つにする

CMMは5段階[1]、McKinseyのグリッドは4段階です[5]。数そのものより重要なのは、de Bruinらが示す要件、すなわち各段階が明確に区別され、十分に定義されていること、論理的な順序になっていること、そして各段階の意図が短い名称で伝わることです[3]。

レベルは4つ、それとも5つ?
  4段階 5段階
名称の例 探求、構築、定着、先導 初期、反復可能、定義済み、管理済み、最適化(CMMの場合)[1]
適しているケース 最初の一歩から他者を先導する段階まで、明確に異なる4つの状態をエビデンスで示せる 適切に実行している状態と、体系的に改善している状態の違いをエビデンスで示せる
注意点 異なる2つの状態を1つのレベルに押し込み、パートナーが何年もそこにとどまる 誰も到達しない最上位レベルや、評価者が区別できない中間レベル

私のルールはオペレーションズ・リサーチの経験に基づいています。エビデンスを使って説明でき、隣り合うレベルと区別できる場合にのみ、そのレベルを設けます。実際にネットワークで観察できる状態の数を数えたら、そこで止めましょう。数が増えることもあります。Beckerらは、ITパフォーマンスモデルを4段階で始めましたが、ITマネージャーへのインタビューを経て、より弱いケースを区別するため、「存在しない」から「最適化済み」までの6段階に増やしました[2]。また、最下位レベルは判定ではなく出発点として表現しましょう。「探求」は対話を始められますが、「不十分」では対話が終わってしまいます。

4. 各レベルを観察可能な状態として記述する

ほとんどのモデルがつまずくのはここです。記述とは、グリッドの一つのセルに入る文章です。PöppelbußとRöglingerは、有用な成熟度モデルの設計原則の一つとして、主観の異なる人同士でも検証できる基準を挙げています。つまり、あるレベルと次のレベルを見分けられるほど、説明が明確かつ具体的であることです[4]。簡単に言えば、同じパートナーを見た2人が、同じセルを選ぶ必要があります。

形容詞から観察可能な状態へ(以下の架空の連盟の例)
曖昧な記述 観察可能な記述 エビデンス
適切なデータ保護 データ管理責任者が任命され、同意と保存期間のルールが文書化され、実施されている データポリシー、同意書、保存期間のルール
強力なデジタルリーダーシップ 理事会が、予算と責任者を明記したデジタル計画を承認している 理事会議事録、予算
適切な報告 主要指標を別の担当者が確認し、期限内に報告している 指標シート、直近2回分の報告書
オンラインで若者が参加している 若者がコンテンツを共同制作し、リーチを四半期ごとに測定している コンテンツカレンダー、四半期ごとのリーチ数

役立つ習慣は3つあります。

  • 目で見たり、手に取ったりできるものを挙げる。文書、定例業務、役割、数値などです。「良い」「強力な」「適切な」「効果的な」は使わないようにしましょう。
  • 各ステップで変えるのは一つだけ。レベル3で予算、責任者、年次レビューを一度に追加すると、そのうち2つだけ満たすパートナーが当てはまる場所がなくなります。
  • 各レベルを累積的にする。各段階には、それより下の段階で必要とされる内容も含めます[3]。オペレーションズ・リサーチに携わっていた頃に使っていたテストを紹介します。レベル2は満たしていないのにレベル3は満たしているパートナーを想像できるか試してください。想像できるなら、順序が間違っているか、そのセルは別の次元に属しています。

5. 各レベルのエビデンスを定義する

すべてのセルについて、何を見ればその状態を確認できるかを記します。ポリシー、議事録、報告書、数値などです。主張がより大きくなる上位レベルほど、求めるエビデンスを増やし、下位レベルでは負担を軽くしましょう。誰が提出し、誰が確認するのかも明記します。誰も読まないエビデンスを求めてはいけません。書類一つひとつが、パートナーの本来の活動に使える時間を奪います。

6. パートナーとモデルを検証する

草案は、実際に使う人たちに見てもらいましょう。de Bruinらはモデルの構築と確認にデルファイ法やフォーカスグループを用いました[3]。McKinseyは、非営利組織のエグゼクティブディレクターを10人近く集めてグリッドをテストしました[5]。CMMのバージョン1.1は、ソフトウェア専門家約200人が参加したバージョン1.0のワークショップから寄せられたフィードバックを受けて作成されました[1]。パートナーネットワークなら、まず多様なパートナー8〜10組と2時間のワークショップを開きましょう。「自分たちの姿が反映されていますか?」「自分たちが使う言葉になっていますか?」「何が抜けていますか?」「屈辱的に感じる点はありませんか?」と尋ねます。

7. パイロットを実施して調整する

パートナー3〜5組で実際にモデルを運用します。de Bruinらは、結果が正確で再現可能となるよう、評価手法の妥当性と信頼性をテストする必要があると述べています[3]。実務上は、2人が同じパートナーを別々に評価し、意見が分かれるたびに、その原因となった記述を書き直します。パイロットに参加した全パートナーがレベル2に集中するなら、レベル間の識別ができていません。誰もレベル4に到達する姿を想像できないなら、それは願望のリストです。全員を同じ箱に入れる尺度には、情報がありません。

8. 変更を管理し、再評価する

Beckerらは、状況、技術、知識の変化に伴ってすべての成熟度モデルは古くなり、必要な変更は新しいモデルのバージョンに反映すべきだと指摘しています[2]。モデルを標準のように管理しましょう。バージョン番号を付け、年1回の変更期間を設け、変更内容と理由を変更履歴に記録し、評価ラウンドの途中では編集しないようにします。バージョン1.1でセルを変更する場合は、1.0での評価結果をどう引き継ぐかを示しましょう。文章を書き換えたせいでパートナーのレベルが下がることがあってはなりません。その後は6〜12か月ごとに再評価します。評価ラウンドの進め方や、レベルを平均して一つのスコアにまとめてはいけない理由については、当社のパートナー能力評価ガイドをご覧ください。

パートナー成熟度モデルのテンプレート(無料ダウンロード)

このテンプレートでは、8つのステップをA4用紙4ページにまとめています。目的と範囲、次元とレベル、記述グリッド(記述のテストと調整のメモ付き)、そしてエビデンス計画、検証計画、バージョン履歴です。

未記入の成熟度モデル作成テンプレートの1ページ目。モデルの詳細、手法の8つのステップ、モデルの用途、目的に関する5つの質問を掲載
テンプレートの1ページ目。レベルを書く前に、モデルの目的を定めます。

成熟度モデル作成テンプレートをダウンロード(PDF、4ページ)。設計ワークショップで印刷して使うか、各セクションをコピーしてください。

グリッドを、パートナーが取り組めるプログラムにしませんか? Advancer.Worldでは、次元をトピックに、レベルをステージに、各記述をセルにできます。レベル間のステップには、エビデンスの提出依頼を設定できます。すべてのパートナーが自分の現在地を確認できます。無料で始められます。

今すぐ登録

例:連盟の「会員向けデジタル成熟度パス」

以下は、架空の連盟であるMeridian Youth Federation(全国の会員組織26団体で構成)の情報を記入したテンプレートです。

記入済みサンプルの3ページ目。デジタル成熟度の6つの領域を「探求」から「先導」までの4段階で記述し、記述のテストとパイロットを経て加えられた調整メモを掲載
サンプルの3ページ目(架空の連盟):記述グリッド、テスト、パイロットで変更した内容。

記入済みサンプルをダウンロード(PDF、4ページ)。参考になるポイントは4つあります。

  • 目的に含めない用途がある。このモデルは、ピアコーチングを誰から始めるか、デジタル支援基金で何を助成するかの判断に使います。会員資格の判定やランキングには決して使いません。
  • 5段階を試した後、4段階にした。初稿の中間にあった2つのレベルの違いをエビデンスで示せなかったため、5つ目のレベルを削除しました。
  • 3つのテーマの下に6つの領域を設けた。ある会員組織がオンラインでのエンゲージメントでは「先導」、データ保護では「探求」の段階にある場合もあります。連盟が把握したいのは、まさにこうしたプロフィールです。
  • パイロットで表現を変更した。2人の評価者が「定期的に投稿する」を「毎週」と「毎月」の両方に解釈したため、オンラインでのエンゲージメントのレベル2を「対象者ごとにチャネルを定めたコンテンツカレンダーがある」に変更しました。

成熟度モデルを構築する際によくある間違い

  1. 目的を決める前にレベルを書く。判断に役立てる対象が定まっていないと、モデルはランキングへと逸れていき、パートナーもそのように受け止めます。
  2. 質問票をモデルそのものと取り違える。SEIは1987年に独自の成熟度質問票を作成しましたが、質問票そのものがモデルだと誤解されることがよくありました[1]。モデルは道筋であり、質問票はその道筋を測定する方法の一つです。
  3. 観察可能な状態ではなく、形容詞を使う。「適切」という言葉の意味は、評価者によって異なります。
  4. 次元が多すぎる。指標が40個もあれば、最後まで終わらないモデルになってしまいます。
  5. パートナーのために設計し、パートナーと設計しない。失敗のリストとして書かれたレベル1は、パートナーに問題を隠すことを教えてしまいます。
  6. 評価ラウンドの途中で変更する。記述を一つ編集するだけで、今回の結果と前回の結果を比較できなくなります。

Advancer.Worldで成熟度モデルを構築する

Advancer.Worldは、UNICEFやAirbusなどの組織におけるプログラムのデジタルトランスフォーメーションから生まれました。Advancer.Worldのプログラムは、成熟度モデルと同じ構造です。ステージがレベル、トピックとサブトピックが次元にあたり、各セルに記述を設定します。

Advancer.Worldのプログラム設計画面。戦略、運営、人材の各テーマにまたがる6つの領域を、「探求」から「先導」までの4つのステージで示す会員向けデジタル成熟度パス
サンプルのモデルをAdvancer.Worldのプログラムにした画面(サンプルデータ、架空の連盟):3つのテーマの下に6つの領域、4つのステージ。

セル間のステップには、パートナーが次のレベルに進むために必要なものを設定できます。エビデンスのアップロード依頼、アンケート、取り組み、電子署名の依頼などです。プログラムごとに、パートナーの進み方を選べます。自己評価で進む、前のステップが完了すると自動的に進む、またはチームの確認後にのみ進む、という方法があります。チームはリアルタイムで一緒に設計を編集できます。パートナーは自分の現在地と次のレベルで求められる内容を、22言語のいずれかで確認でき、他のパートナーのデータを見ることはありません。日次スナップショットで履歴が保存されるため、レポートでは評価ラウンド間のネットワークの変化を確認できます。

よくある質問

成熟度モデルにはいくつのレベルを設けるべきですか?

多くのパートナーネットワークでは、4〜5段階が適切です。重要なのは、各レベルが明確に区別され、十分に定義されており、ひとつ下のレベルから論理的に進んだ段階になっていることです [3]。試行評価で評価者が2つのレベルを見分けられない場合は、統合しましょう。

成熟度モデルの構築にはどのくらい時間がかかりますか?

初版の作成には2〜3か月を見込んでください。目的、評価軸、レベルの策定に数週間、説明文とエビデンスの整備にさらに数週間、その後にパートナーとのワークショップと試行を行います。近道を選ぶと、予算を確保していなかった第2版が必要になるものです。

成熟度モデルを一から作るのではなく、既存のものを調整して使えますか?

多くの場合、可能です。まず既存のモデルを探すべきでしょう [2]。ライセンスを確認し、目的に合うなら構成を維持して、説明文を自社ネットワークの言葉に書き換えます。

パートナーは評価軸ごとに異なるレベルに位置することがありますか?

はい、通常はそうなります。そのプロファイルこそが、このモデルから得られる最も有用な成果です。ただし、ひとつの評価軸の中でレベルを飛び越えてはいけません。これはCMMの開発者が、自らのレベルについて述べている点でもあります [1]。

レベルではなく、目的から始める

このガイドからひとつだけ覚えておくなら、進める順序です。まず目的を1ページにまとめ、数社のパートナーと合意してから、評価表を作り始めましょう。この順序で構築したモデルは、着手までに時間がかかる一方で、説明や正当性の立証にかかる時間は大幅に短くなります。

成熟度モデルを一度構築すれば、すべてのパートナーと運用できます。チームと評価表を設計し、パートナーを招待して、各パートナーの状況をラウンドごとに確認しましょう。無料で始められます。

今すぐ登録

参考文献

  1. Mark C. Paulk、Bill Curtis、Mary Beth Chrissis、Charles V. Weber、カーネギーメロン大学ソフトウェア工学研究所、「Capability Maturity Model for Software, Version 1.1」(CMU/SEI-93-TR-024)、1993年2月、https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/(2026年10月閲覧)。
  2. Jörg Becker、Ralf Knackstedt、Jens Pöppelbuß、「Developing Maturity Models for IT Management: A Procedure Model and its Application」、Business & Information Systems Engineering、1(3)、2009年、213-222頁、https://doi.org/10.1007/s12599-009-0044-5(2026年10月閲覧)。
  3. Tonia de Bruin、Michael Rosemann、Ronald Freeze、Uday Kulkarni、「Understanding the Main Phases of Developing a Maturity Assessment Model」、第16回オーストラリア・ニュージーランド情報システム学会(ACIS)年次大会、シドニー、2005年、https://aisel.aisnet.org/acis2005/109(2026年10月閲覧)。
  4. Jens Pöppelbuß、Maximilian Röglinger、「What Makes a Useful Maturity Model? A Framework of General Design Principles for Maturity Models and its Demonstration in Business Process Management」、第19回欧州情報システム学会(ECIS 2011)論文集、2011年6月、https://aisel.aisnet.org/ecis2011/28/(2026年10月閲覧)。
  5. McKinsey & Company、Venture Philanthropy Partners向け、「Effective Capacity Building in Nonprofit Organizations」、2001年、https://www.bridgespan.org/getmedia/ef1ff943-173b-48ec-843a-b5ce85c6c807/effective-capacity-building-VPP.pdf(2026年10月閲覧)。

© 2026 Mourinho Solutions. All rights reserved.

← ブログに戻る