Living Documentであるプロジェクトチャーター（続き）

前回のコラムではLean Six Sigmaのコアツールであるプロジェクトチャーターについてご説明しました。
チャーターには「一定期間内にどのようなアウトプットを出すのか」についての約束が記載されているのですが、それぞれの要素も重要ながら、各要素が連動しあっており、それぞれが整合するように仕上げていく必要がある“Living Document”（生きていて、都度、修正可能な文書）であることをご紹介しました。

ここまでProblem StatementとGoal Statement & Business Impactについてご説明しましたので、今回は残りの要素について解説すると同時に、引き続き“Living Document”についてもご案内していきます。

Project Scope：一定期間内に扱うこと・意図的に捨てること、の記載

プロジェクトスコープとは、今回の取り組みの中で何を（どこまで）扱うのか、逆に何は扱わないのかの線引きをしておくことです。

若手育成に限らずアクションラーニングや各種プロジェクトの最終発表当日に、いきなり聞き手（経営幹部）から、

「もっと視野を広くもって考えてほしかった」

などと言われることは珍しいことではありません。この聞き手の反応はまさにプロジェクトスコープについての合意形成がなされていなかったことが原因です。

変化の時代にあって限られた時間、限られた資源でアウトプットを出し続けて改善と変革を継続していくためには、この「スコープ設定」（と利害関係者との合意）が極めて重要です。

例えば「残業の削減」というテーマがあるとします。これをスコープを定めずに「全社・全部門で残業の削減」などというスコープにしてしまうと、個別の部門の事情を理解するのに時間がかかりすぎたり、残業の要因を調べるために様々なデータをひっくり返して分析作業に膨大な時間がかかったりと、一定期間内に結論を出して行動に移すことはほぼ不可能です。筆者はスコープ設定があいまいなままに作業ばかりやらされている人事部スタッフ、HRBP、管理職の方々のぼやきを散々聞いてきています…。

そこで例としてスコープを「人事部門」に限定してみることにします。

部門を限定することで、「その部門で起きていること（ここでは残業）」をより具体的に知ることができます。具体化されるので、原因を特定するために必要なデータは何か、などがその時点で見えてくることは少なくありません。これがLiving Documentであることの証であり、スコープを定義することで、Problem Statementの内容が変わってくることが往々にしてあります。（上図の2. 具体的な問題の記述）

また上図の3.にあるように、今回はスコープを人事部門に限定しましたので、最終提案の聞き手からすると「では、他の部門はどうするのか？」が当然、気になるところです。

ですので、スコープ設定はProblem Statementの変更だけではなく、Goal Statement（ここでは、例えば「解決策の横展開のための条件定義」まで行うことを成果物とするという）の変更が加わります。

スコープの切り方は部門・部署や地域、職務階層などいろいろな切り口があります。エンゲージメントや生産性向上といった抽象度の高いテーマも「人事部門におけるエンゲージメント」や「入社5年目（管理職手前）従業員の生産性向上」などとすると解像度がかなり上がり、扱いやすくなるのです。

Project Timeline：いつまでにどのようなアウトプットを出すのか？の約束

次にProject Timelineです。

要するにスケジュールなのですが、前編でご紹介したDMAICVの各フェーズがいつまでに終わるのか？を明示していくことになります。つまりD＝Define＝課題の定義はいつまでに実施されて主たる利害関係者の合意を得るのか、M=Measure＝現状（ベースライン）を把握できるデータ収集はいつまでに完了し、プロジェクトスポンサーに提示できるのかなどを記載していきます。Project Timelineも他の要素と連携しているLiving Documentの一部です。

例えば先ほどの「残業」のテーマですが、スコープが「人事部門」であった場合は通常、3-4か月程度で何らかの解決策を出して実行に移れるでしょう。しかし、スコープを人事部門のみではなく、「すべての間接部門」としたらどうでしょうか？

すべての間接部門（財務、経理、IT、総務などなど）をすべてスコープに入れるとなると、かなりの大規模プロジェクトになりますので、様々なコミュニケーション、調整が発生しますので最短でも半年はかかるでしょう。

しかし、次の要素であるRelated Initiative（関連する社内外の取り組み・ベストプラクティス）まで考えてみたらどうなるでしょうか？

実は残業削減については社内の各部署で行われており、成果がでている（しかし横展開はされていないもったいない状態）ということも珍しい現象ではありません。このような場合はGoal Statementには社内の類似事例の探索と横展開の方策立案が成果物として入ってきます。また社内に限らず、多くのテーマは社外にベストプラクティスが存在する可能性があります。社外にベストプラクティスがある場合はそれをコピーするのではなく、例えば「自社の間接部門で実行できるようにするための施策立案」というゴールになるかもしれません。いずれにしても実施中ないしは実施済みのものがある場合はその解決策をうまく使わない手はありません。そしてうまく使えれば全体のスケジュールを短縮し、組織の改善・変革に勢いをつけることが可能なのです。

Project Member：“意味のある対話”から生まれる社内のネットワーク

それでは最後の要素であるProject Memberですが、要するに「誰と一緒に（誰を巻き込んで）、この取り組みを進めていくのか？」ということです。

メンバー選定＝誰を巻き込むか？誰と一緒に仕事の経験をするのか？をきちんと考えることで、社内に通常業務以外の人脈ができたりします。オープンに対話をしているよりも、目的をもって決められた期間内に成果を出す経験をした方が、会社にとっても個人にとってもより良い結果をもたらすと筆者は確信しています。

Project Memberには以下の3種類の登場人物がいます。

1. Project Sponsor・・・プロジェクトの支援をしてくれる（主に）上位役職者でありDMAICVの各トールゲートミーティングで、例えばDefineフェーズのトールゲート時点で課題の定義が適切になされているか、Analyzeフェーズのトールゲートではいきなり解決策に飛びつくことなく、根本原因まで掘り下げて分析がなされているかなどの承認を行う役割を担います。自分たちが扱っているプロジェクトテーマに関して、誰が社内で権限を持っているのか、その人はこれまでどのような方針を打ち出してきていて、何がうまくいっていて何を課題と感じているのか、それはなぜかなど、スポンサーを特定し、その方のプロファイル（ペルソナ）を明らかにするだけでも、相当にいろいろなことがわかります。
2. Project Member （Core）・・・リーダーとメンバーで構成されますが、プロジェクトのミーティングに毎回出席が求められる人たちになります。少し話は外れますが、リーダーはプロジェクトチャーターをメンバーや、ときには上位者を説得して巻き込み、プロジェクトを始動・完結させる役割を負いますので、２、３つのプロジェクトでリーダーを務めるだけでも相当にリーダーシップが鍛えられます。
3. Project Member（Extend/SME）・・・2．のコアメンバーと違って、毎回、ミーティングに出席する必要はありませんが、フェーズやテーマに応じて召集される専門家（SME：Subject Matter Expert）になります。こちらも余談ですが、例えば若手育成プログラムで若手リーダーにテーマを与えて、「このテーマであればだれをSMEとして巻き込むべきか？」を聞いてみてください。すらすらと個人名が出てくるようであれば常日頃から部門を超えてネットワークを作れているかどうかがすぐにわかりますし、名前が出てこない場合は、プロジェクトを通じて社内人脈形成を目指していただけるようになります。

Living Documentの真の意味：変化の時代に上手に失敗するためのコアツール

ここまででプロジェクトチャーターの説明は終了ですが、プロジェクトチャーターが“Living Document”であることはまだまだ続きます。

Defineフェーズでチャーターを作ってプロジェクトスポンサーからOKをもらったものの、Measureフェーズで情報収集をしてみたら、新たな事実が発見された、というケースは良くあります。この場合は初期のチャーターに固執することなく、ProblemやGoalの設定をし直すという作業が必要になります。チャーター内の各要素が連携している以外に、プロジェクトのフェーズが進んで新たな事実・異なる事実が分かった場合でもチャーターの修正が発生するのです。

「いったん始めたプロジェクトにそんなに変更が生じるなんて・・・」

と思われるかもしれませんが、新たな事実が発見されれば、軌道修正をするのは当たり前です。軌道修正なしに最後まで突き進んでしまい、膨大な時間を投資したにもかかわらず「そういう問題じゃないんだ」と言われてしまうほうが、よっぽどもったいないのです。

Define（問題の定義）、Measure（ベースライン＝現状を捉えるための各種データ収集）のフェーズごとにメンバーやスポンサーとコミュニケーションをとり、必要な場合にはその都度、軌道修正をしていく。

こんな当たり前の仕事の進め方、「型」を取り入れるだけで、生産性を飛躍的に上げることは可能ですし、現場で多忙にしている管理職の「余計なコーチングの手間」を減らすことは十分に可能です。

DMAICVという「フェーズが区切られた進め方」をすれば、どのフェーズで失敗してもすぐにリカバリーが効きます。アジャイルの時代とは言え、多くの会社の中ではいろいろな承認をとっていきながら物事を進めることが一般的でしょう。DMAICVの型であれば、たとえ失敗があったとしても、問題の定義・課題設定が間違っているのか（Define）、分析の仕方・根本原因の認識が間違っているのか（Analyze）、打ち手の内容が間違っているのか（Improve）、など、より具体的に失敗からも学ぶことが可能になるのです。

リーダーが行うべき意味ある対話

これで一連のコラム（前・中・後編）は終了です。前編で問題提起したように、筆者は対話そのものに意味がないと言っているのではありません。しかし、単に対話がしたいのであれば会社の外でも十分にできます。ビジネスリーダーが組織の中でとるべき対話はビジネスの議題を中心に据えるべきと考えており、そのための一つの手法としてDMAICVからなるLean Six Sigmaをご紹介しました。

昨今広がった対話ブームはどこか「年長者が若者の話を聞かなければいけない」という雰囲気があり、ただでさえ忙しい管理職の時間を浪費しているように見えます。そうではなく、ビジネスを成長させることや業務を遂行する上での障害を解消することを議題の中心に据えて、なおかつ結果を出すことをまずはやったうえで「自分の言いたいこと」を言ってみるのはどうでしょうか？

組織内で信用されるのは明らかに後者のパターンです。中長期的、かつ本当に若手リーダーのキャリアを考えるのであれば、型にはめるというイメージを持つのではなく、「持続的成長のための型を（早い段階で）作ってあげる」ことが大事なのです。DMAICVの流れに沿えば成功するということでもありません。むしろ最初は失敗、七転八倒の方が多いでしょう。DMAICVのような型を持っていれば上手に失敗することができ、学習につなげやすいのです。

いろいろな価値観を持った利害関係者と課題認識を共有するにはどうすればよいのか（Defineフェーズでの学び）、分析の精度を上げるには今後、何を学ぶ必要があるのか（キャリア自律につながるAnalyzeフェーズの学び）。せっかくの自分の貴重な時間と提案を聞いてくれる利害関係者の時間を無駄にしないためにも、ぜひ意味のある対話手法を早いうちから身に着けていただければと思います。

対話よりDMAICV：古くて新しいカタの勧め（前編）
対話よりDMAICV：古くて新しいカタの勧め（中編）