◆戦略的アラインメントを成功させる条件
前回、戦略的アラインメントのゴールとして３つのゴールとして
（１）組織の成長を最大化する
（２）無駄をなくす
（３）シニアマネジャーの組織統制の強化をする
があると述べた。また、そのためのアプローチについて説明した。今回からは、これらの戦略的アラインメントを成功させるためには、何を配慮すればよいかを説明する。
まず、ざっと箇条書きにすると
（１）バランスがとれ、また、よく考えられた目的・目標の設定されていること
（２）明確で、かつ、耐久性のある目的が設定されていること
（３）階層化をきちんとできるようなフレームワークがあること
（４）目標が計測可能であること
（５）ステークホルダの合意形成が行われていること
（６）実行計画が組織としての仮説になっており、実施体制作りが十分であること
の６つくらいに集約される。まず、それぞれを簡単に説明し、その後に、詳しく検討していきたい。
◆バランスと耐久性
まず、（１）である。目的・目標の設定について「バランス」と「よく考えられている」という２つの要件がある。また詳しく述べるが、マネジャーになっても目的や目標を与えられるものだと考えている人が少なくない。これはとんでもない勘違いである。目的や目標を決めるということが責任をとることであり、マネジャーの仕事である。
二番目のキーワードは「明確」であることと、「耐久性」があることである。前者は今回は説明の必要はないと思うが、後者については多少説明しておく。目的や目標は、戦略が変わったり、あるいは実施状況が予想外であった場合に、できるだけ変える必要がないものが望ましい。目標が変わることを容認することはパフォーマンスやモチベーションに悪影響があるためだ。変えなくてすむということが「耐久性」という言葉の意味である。
◆階層をまたがるフレームワークの必要性
三番目も重要だ。結局、なぜ、戦略的アラインメントができないかというと、トップから現場までの階層をうまくおろしていく方法がないことであることが多い。たとえば、第２回で説明した、ＧＢＳのような簡単な仕組みでもいいので、フレームワークがほしい。
四番目は、言い尽くされたことで、目標は計測可能であること。そして、目標は目的ときちんと整合していること。
五番目はある意味で、目的や目標、プロセスといったコンテンツよりもっと重要なことで、それがきちんとステークホルダの合意形成の行われたものであることが不可欠である。
◆計画を組織の「仮説」として共有する
最後は、目的・目標達成のための計画が正しいかどうかは別にして、組織全体でその方向でやる「仮説」になっていることだその計画でできるかどうかを組織全体がどう認識しているかはきわめて重要な問題である。。詳しいことは別の機会に説明するが、組織ができるかどうかわからないと思っているプロジェクトはだいたいうまくいかない。組織が楽観的にみているプロジェクトは、なんとかなるものだ。間違っても、評価だけをして、後はプロジェクトでどうぞのようなやり方はしてはならない。
※ＰＭ養成マガジンエグゼクティブ５号より
定期購読（無料）はこちらから。
]]>◆戦略アラインメントのゴール
前回は戦略アラインメントの視点について説明をした。今回は、もう少し踏み込んで、戦略アラインメントで何を目指すかを説明しておく。
大きく考えると、戦略アラインメントの落とし処（ゴール）は以下の３つだと思われる。
（１）組織の成長を最大化する
（２）無駄をなくす
（３）シニアマネジャーの組織統制の強化をする
では、これをどのように実現していけばいいのか？それぞれについて考えて見よう。
◆「組織の成長を最大化する」方法
まず、（１）であるが、もっとも重要なポイントはリソースだろう。すべてのリソースを組織の目標達成、あるいは戦略にコミットできるような配置をすることだ。こう書いてしまうと当たり前のように思えるが、例えば、既存商品のトラブル対応で、プロジェクトが遅れてしまうということはどこの企業でも珍しいことではない。これでは、リソースが組織の目標達成に投入されているとは言い難い。
もう一つのポイントは、効率の問題である。「できるだけ速やかに」戦略ゴールを達成することが求められる。これも当たり前だが難しい。戦略ゴールに対して、複数のプロジェクトが実行される。すると、各プロジェクトにおいて、そのプロジェクトのスケジュール目標を達成することは最低条件であって、それ以上のものではない。つまり、プロジェクトではスケジュール目標があっても一分一秒でも早く終わるように「工夫」されるべきなのだ。これは「品質思考停止」をしていると絶対にできないことであり、また、これができるということは成熟度レベルでいえば最難易度である。
◆「無駄をなくす」方法
次に（２）に移ろう。まず、アクティビティレベルで、整合している必要がある。特にプロセスの整合が重要である。また、組織的整合も重要である。
次に、政治的なコンフリクトで無駄がでないようにする。この問題がもっとも大きいのが、リソースの取り合いだろう。また、この延長線上にあるのが、リソースの再配置による混乱である。一般的にリソースの新規投入は３０％程度の生産性の減少をもたらすことが知られている。この数字を考えると、初期リソースを冗長にするという選択肢も考えられるべきだろう。
◆「シニアマネジャーの組織統制の強化をする」方法
最後は（３）だ。まず、定番ででてくるのがモニタリングである。モニタリングを強化することにより、シニアマネジャーの統制力を強化していく。また、モニタリングの背後にあるのは、これまで議論してきたようなゴールの構造化により、組織の各ヒエラルキーで適切なゴールのコントロールができることである。
また、もう一つ考えたいのはコミュニケーションである。コミュニケーションを活性化することによって、組織的な統制を強化していく。ある意味で、これがもっとも本質的なアラインメントの手段だと言えるのかもしれない。
※ＰＭ養成マガジンエグゼクティブ４号より
定期購読（無料）はこちらから。
]]>◆戦略達成のオペレーション
前回、プロジェクトマネジメントのトライアングルの話から、多少先走って、ＧＢＳの話をしたが、今回から多少、戻って、戦略アラインメント（戦略的整合）について考えて見よう。
まず、ガバナンスの話から。戦略達成のオペレーションには
（１）定常業務
（２）プロジェクト業務
の２つがある。一つのプロダクトやサービスに注目すると、この２つのオペレーションを併用して、戦略達成への貢献をしているケースが多くなっている。例えば、メーカであればプロジェクト業務として商品開発オペレーションを行い、定常業務として生産・販売オペレーションを行うというような形態を取る企業が増えてきた。ＩＴ企業であれば、プロジェクトとしてシステムの導入（開発）オペレーションを行い、その運用や保守サービスオペレーションを定常業務と行うことが多い。
◆マネジメントの基本はオペレーションマネジメント
このため、マネジメントとして基本になるのは、定常業務管理（一般的な意味でのオペレーションマネジメント）である。定常業務管理では、戦略実行のための事業計画を期ごとの業務計画に展開し、その業務計画に対するＰＤＣＡサイクルを回して管理していく。
これに対して、プロジェクト業務は、個々の業務が戦略実行に明確に紐づけられる。個々のプロジェクトがどのように戦略達成に貢献しているかを明確にし、それを実行するための計画をプロジェクトごとに作り、その計画を実行することによって、戦略貢献をする。これがプロジェクトマネジメントである。
一方で、プロジェクト業務の中には、単独では戦略貢献できないものが多い。例えば、商品開発プロジェクトを実施しても、そのあとの生産や販売オペレーションとの連携がなれば、何の意味もない。ＳＩプロジェクトはプロジェクトそのものが利益を生むが、戦略への貢献となると、そのあと５～１０倍の期間にわたる運用・保守・機能変更などのオペレーションなくては考えられない。
◆戦略アラインメントの視点
このように考えて見ると、プロジェクトの戦略アラインメントは、単に経営戦略、事業戦略との整合だけではなく、定常業務のオペレーションやオペレーション組織との整合が求められることは明らかである。むしろ、これらの整合が取られ、組織のマネジメントにプロジェクトマネジメントが統合されるというのがあるべき姿だと言える。
そこで、ここでは、戦略アラインメントによるプロジェクトマネジメントを組織マネジメントの統合を以下の視点から考えてみる。
（１）戦略的整合
（２）組織的整合
（３）プロセス的整合
（１）の視点からは、プロジェクト目標と組織（戦略）目標が整合していることが重要である。詳細は別途説明するが、これは最近、プロジェクトマネジメントで散々言われていることなので、イメージはおわかりだろう。
（２）の視点からは、プロジェクトのリソースが、研究やオペレーションなどの他の業務プロセスに従事しているリソースとシームレスに統合していけることが重要である。この例としては、
・技術開発の担当が商品開発プロジェクトに入る
・商品開発プロジェクトのキーマンが生産部門や営業に異動し活躍する
・システム開発をした人がそのままアウトソーシング業務を担当する
といったことを上げることができる。
（３）の視点からは、プロジェクトのアクティビティと定常業務のプロセスがシームレスに連結していることが重要である。この例としては、
・商品開発のプロジェクトのアクティビティに生産設計が入り、プロジェクト完了後、直ちに生産オペレーションにかかれる
・商品開発プロジェクトのアクティビティに試作販売が含まれ、活動にスムーズに営業オペレーションに移行できる
・ＳＩプロジェクトに開発したシステムの試験運用が含まれ、スムーズに運用オペレーションに移行できる
といった例を挙げることができる。
※ＰＭ養成マガジンエグゼクティブ３号より
定期購読（無料）はこちらから。
]]>◆プロジェクトマネジメントのトライアングル
プロジェクトマネジメントのトライアングルというのがある。プロジェクトの制約を表現するもので、基本的には
・スコープ（プロダクト品質）
・タイム
・コスト
であり、この３つの要素のバランスをうまくとり、プロジェクト品質を向上させるためのマネジメントを行う。あるいは、ＩＴなどの受注型のプロジェクトでは、スコープを目標と考え、目標達成のためのマネジメントを行うという考え方をするケースもある。この場合は、プロダクト品質がプロジェクトの品質になる。
◆ゴールの多層性とトライアングル
ここで、前回、述べたことを思い出して戴きたい。プロジェクトの目的は、成果物を生み出すことではなく、ゴールを達成することであると述べた。ここで、「ゴール」について少し考えておきたい。
ＰＭＢＯＫにはゴールという言葉は出てこないが、達成すべきものだ。この範囲は広い。目的も含まれるし、プロダクトスコープもプロジェクトスコープも含まれる。実際にゴールとはプロジェクトをどういう範囲で考えるかに関わってくる問題である。
つまり、ゴールは
開発チームの視点：達成すべきスコープ
組織としての視点：達成すべき目的
となる。最低限、この２つの視座がある。このような多層性がある。
そのように考えると、プロジェクトマネジメントのトライアングルは
・ゴール
・タイム
・コスト
と考える方が現実的である。つまり、開発チームにおいても、組織においてもコストとタイムという制約は変わらない。しかし、そこで達成しなくてはならないことには違いがある。
このようにマネジャーにとって、プロジェクトマネジメントとは、タイムとコストの制約の中で、プロジェクトチームの生み出した成果物を使って、（戦略・組織上の）目的を達成するための活動である。
逆にいえば、マネジャーがプロジェクトの目的をきちんと設定していない場合、あるいは、正しくその目的をプロジェクトに伝えていない場合には、スコープ計画は不適切になり、プロジェクトの生み出した成果物には手戻りが生じる。事実、スコープ変更の多くの理由は目的とスコープの不整合で起こっている。
◆ゴールのマネジメントツール ＧＢＳ
では、ゴールのマネジメントをうまく行うにはどうすればよいか？これはマネジメントの問題なので、いろいろなフレームワークや考え方があると思うが、その一つにブレークダウンストラクチャーを作るという考え方がある。ＧＷＳ（ゴールブレークダウンストラクチャー）である。
ゴールブレークダウンストラクチャーは
（１）ミッション（戦略ゴール）
（２）ビジネス目標（組織上のゴール）
（３）プロジェクトリクエスト（プロジェクトのゴール＝完了基準）
（４）スペック（プロダクト開発のゴール＝ＷＢＳのトップ）
というゴールのブレークダウンを行う。すると、（４）のスペックがＷＢＳのトップになるので、戦略ゴール（ミッション）から、スムーズにＷＢＳ（スコープ定義）まで展開していけるというメリットがある。
また、ゴールの多層性でいえば、一般的には（２）が組織のゴール、プロジェクトで達成すべき問題になるが、このゴールをプロジェクトリクエストに展開して行くことによって、マネジャーとしてのプロジェクトマネジメントとしてすべきことが明確になる。この点でもメリットのある手法だと言えよう。
ＧＢＳによって、プロジェクト側はプロジェクトリクエストを満足するためのプロジェクトマネジメント計画を策定する。ここから先は、いわゆるプロジェクトマネジメントの世界である。問題はマネジャー側である。トライアングルから分かるように、コストとスケジュールの制約はプロジェクトと同じものであり、管理をしておけばよい。しかし、ビジネス目標の達成については、自らがマネジメントしていく必要がある。ビジネス目標の中には、マーケットシェアのように、プロジェクトの成果物が上がってきたあとのマネジメントが必要なものがある一方で、ＲＯＩや技術開発のようにプロジェクト実施中にマネジメントが必要なものもある。プロジェクトマネジャーにプロジェクトスペックを渡す前に、ＧＢＳだけではなく、スケジュールについても検討しておく必要がある。
ＰＭ養成マガジンエグゼクティブ２号より
定期購読（無料）はこちらから。
]]>◆１０歳の太郎君と４０歳の太郎氏
太郎の１０歳の夏休み。
父親「もう、夏休みの宿題は終わった？」
太郎「自由研究以外は終わったよ」
父親「自由研究は何をするんだい」
太郎「１週間の星の観察にしようと思ってるんだ」
父親「なぜ、星の観察をするの」
太郎「担任の先生が１週間の星の観察をすればいいと思うと言ってたから」
太郎君は健やかに成長し、大学を卒業、ＩＴ企業に就職する。とりあえず、上司のいうことをよくきく、覚えめでたい社員で、順調に出世。４０歳で課長になる。ある日のこと。
部長「Ａ社のプロジェクトのスコープは決まった？」
太郎「はい、部長」
部長「どんな感じになった？ＲＦＰと大きな相違点はないかい？」
太郎「Ａ社担当の佐藤さんはシステムをよく分かっていて、細かく要求仕様を出してくれました。このプロジェクトは私が係長のときから目をかけている井上君を担当にしました。私は細かいところはよく分かりませんが、井上君はこれなら予算、納期とも大丈夫だと言ってくれました。ＲＦＰはＲＦＰですので、現実に受注条件をクリアできる方が大切です」
実は、この２つは両方とも実話だ。もちろん、同一人物ではないが、１０歳の太郎君が健やかに成長すると４０歳の太郎氏になると思った話を２つ並べて見た。
◆２つのストーリーの対比
あなたは、１０歳の太郎君と４０歳の太郎君の行動をどう感じるだろうか？みなさんが４０歳だとすれば、１０歳の太郎君は自分の子供に重ね合わせ、もっとしっかりとしろと思うが、４０歳の太郎氏の行動は多少問題はあるが、おおむね、こんなものだと思う人が多いのではないかと思う（著者の研修の歳の調査による）。
２つのストーリーを対比してみよう。
星の観察＝システムの構築
先生の指示＝顧客の指示
という関係がある。共通して抜けているものは何か？１０歳の太郎君がはっきりしているが、目的のないことである。おそらく４０歳の太郎氏だと目的はあるじゃないかと思う人は、１０歳の太郎君の行動「１週間の星の観察」は目的だと思えるかどうかを考えてみてほしい。星の観察も、先生の言うことを聞くことも、目的であるとは考え難い。手段、あるいは、目的実現のための目標である。
そのように考えると、「システムの構築」も、「顧客の指示」も目的であるとは考えにくい。
◆仕事の基本構造
なぜ、このような錯覚に陥るかというと、仕事の「基本構造」を理解していないことにつきる。仕事には必ず
仕事
→（生み出す）
サービス／プロダクト／・・・
→（実現する）
ゴール
という構造がある。ゴール（成果）がないものは仕事とは言わない。「作業」である。
作業と仕事の違いは、成果という付加価値を生み出すかどうかだ。仕事は付加価値を生み出す。作業は付加価値を生み出さない。簡単にいえば、自分の給料分（部下がいる場合にはプラス部下の給料分）だけ稼ぐのが作業で、自分の作業プラスアルファを稼ぐのが仕事である。
そして、付加価値の源泉が目的である。
ＰＭ養成マガジンエグゼクティブ１号より
定期購読（無料）はこちらから。
]]>