DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回は、人によってさまざまな思いを持つ「品質」について、品質マネジメント計画書に具体的な定義を記載して、ステークフォルダー間で合意すべきと結論づけました。

じゃ、いったい品質を具体的にどう定義すべきなのか、、、と続けたいところですが、すみません、今回は少し脇道にそれます。。。

【　宮本亜門氏が語ったオペラ演出の難しさ　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
先日、実家で父親と食事をしていたときのことです。そのとき偶然テレビに映っていた番組に、演出家の宮本亜門氏がゲストとし出演していました。（※１）

その番組の中で宮本亜門氏がオペラ演出の難しさについて質問されたときの答えを聞いて、私はまたプロジェクトマネジメントと結び付けて考えてしまったのです！

「オペラ歌手たちはそれぞれ先生についており、先生の教えと違う演技を指示しても簡単に受け入れられないことがある。そういう時は、その歌手の意志を尊重しながらいろいろ試行錯誤するのだけれども、結局は最初に指示した演出に落ち着くことが多い」

「オペラを観に来るお客様は音楽を聴きにくる。オペラでは最も権威が高いのが指揮者である。音楽を第一に考えると、歌声がしっかりとお客様に聞こえるように、登場人物の動き方や向く方向など、いろいろ制約がある中で演出を考える必要がある」

これを聞いて私はプロジェクトマネージャー（以下ＰＭ）やプロジェクト・マネジメント・オフィス（以下ＰＭＯ）として、プロジェクトをコントロールすることの難しさを思わず連想してしまったのです！（やっぱ、職業病か？？？）

現実のシステム開発プロジェクトにおいても、オペラ歌手のように長年のシステム開発を経験してきてそれぞれのやり方にこだわりを持つ技術者やサブリーダーの方もたくさんいます。それらのプロジェクトメンバーをうまくコントロールするのがＰＭの仕事です。ＰＭＯも毎週決められた期限までにプロジェクトメンバーから進捗報告書を吸い上げたり、課題一覧やTodoListへの状況更新をフォローするなど、プロジェクト運営の円滑化のためのコントロールを行います。

しかし、プロジェクトによっては、なかなか指示に従わなかったり、期限通りに進捗報告を提出してくれないメンバーなどがいて、お困りのＰＭやＰＭＯの方たちも多いのではないでしょうか？だからと言って、プロジェクトがうまく行かない原因を指示に従わないプロジェクトメンバーたちのせいにして、愚痴を言っているだけではプロジェクトはうまく行くはずがありません。

宮本亜門氏がさまざまな制約の中でも、我慢強く演出を手掛けることでオペラ公演を成功させてきたように、ＰＭやＰＭＯも「数々の制約の中でプロジェクトをなんとか成功させる」という結果が求められるのです。さまざまな思いや経験を持つ数多くのステークフォルダーたちを束ねるという点で、オペラ演出とプロジェクトマネジメントの難しさには共通点があり、その難しさを乗り越えたときにはじめて「成功」を勝ち取ることができるのだとあらためて感じました。

【　プロジェクト成功へのシナリオ　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
演劇やオペラにはシナリオというものがあります。もちろんシナリオの良し悪しが演劇やオペラの成功を左右することは言うまでもありません。では、システム開発プロジェクトはどうでしょうか？

そりゃ、もちろん同じでしょう！成功へのシナリオが描けていないプロジェクトは成功するはずがありません。システム開発プロジェクトにおけるシナリオは何かというと、言わずとしれたプロジェクト計画書です。プロジェクト計画書のインプットとなるプロジェクトに内在するリスクの洗い出しと対応計画が十分検討され、私の大好きなマスタースケジュールの中に成功へのシナリオのエッセンスが盛り込まれているはずなのです。（※２）

ＰＭはマスタースケジュールを眺めながら、プロジェクトの進行状況に応じてその後のプロジェクトの展開を予測し、最終的にプロジェクトがどんな形で成功を成し遂げるかのシナリオを描いて、そのシナリオに導くための数々の演出を施すことになるのです。

もし、ＰＭが成功へのシナリオを描かないまま、成り行き任せにプロジェクトを進めてしまったらどうなるでしょうか？

システム開発プロジェクトはさまざまな思いや経験を持つ多くのメンバーが集まっていることから、それぞれのメンバーが自分の考えに固執してしまうとプロジェクトは推進力を失い、失速してしまう可能性が高くなります。つまり、ＰＭが成功へのシナリオをしっかり描いてプロジェクトメンバーに共有し、そのシナリオに従ってプロジェクトが進行するように演出しなければ、プロジェクトが失敗する可能性が高くなるのです！

「プロジェクト成功へのシナリオを描き、成功を演出するという感覚が必要だ！」

「プロジェクト成功へのシナリオ」は「プロジェクト計画」であり、「プロジェクト成功の演出」は「プロジェクト・コントロール」と対応付けて考えると、わかりやすいでしょう！ＰＭやＰＭＯは、秀逸なシナリオライターであり、良い演出家であるべきなのです！

【　どんな風にシナリオを描き、演出を行うのか？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
シナリオの描き方、演出のやり方は、それぞれのＰＭやＰＭＯのスタイルによって、どんな方法でも構わないと思います。大切なのは「こうすればプロジェクトは成功する」という信念であり、その信念に基づいたマネジメントがプロジェクトメンバーを動かすのです。（※３）

ここまでだいぶ抽象的な話しになっていましたので、たとえばどんな風にシナリオを描いたり、演出したりするのか、私の思っているイメージを紹介したいと思います。（言葉だけではなかなか伝わりづらいかもしれませんが。。。）

＜　要件定義後に描く、外部設計～カットオーバーまでの想定シナリオ ≪ 例 ≫　＞

大規模な再構築プロジェクトで、要件定義ではかなり欲張りな新機能追加を目指していたこともあり、なかなか要件が固まらずに一時紛糾し、いくつかの検討課題を残したまま外部設計工程に突入することになったというシチュエーションとします。

このプロジェクトにおいては、新機能の要件やスコープ決定をめぐる山場が必ずいくつかやってくることが予想されます。その山場は次の３つぐらいのポイントで訪れると想定します。
・　実装すべき機能の全体が固まるはずの外部設計中盤以降
・　ユーザーテストの計画を検討し始める結合テスト段階
・　システムの動きが見え始めるシステムテストの後半からユーザーテスト段階

それぞれの山場を乗り切るために、おそらく外部設計段階で膨らむであろう開発スコープを十分開発が可能なボリュームに抑えこむための手立てを講じておくが、やはりうまく抑え込めずにどうしてもはみ出す部分が少なからず出てくることを想定して、リリース日の延伸と開発工数の追加をネゴるための準備もしておきます。

最終的にいくつかの山場をスコープ削減やリリース日の延伸などによりそれなりに乗り越えたのち、無事カットオーバーを迎えます。当初計画のプロジェクト目標に対して、納期やコストは一部見直しが発生したものの、スコープや品質はそこそこの状態で本番稼働を迎えたことにより、プロジェクトとしては十分成功したという評価を得られるというシナリオを描きます。

＜　上記シナリオにおける演出 ≪ 例 ≫　＞

１．外部設計のスタート時にキックオフを開催します。ＰＭから追加機能に関する検討課題があることを明言し、ユーザーを含む主要なステークフォルダーからプロジェクト成功に向けての協力のことばを発言してもらうことで、全員で課題を乗り越えるという雰囲気を演出します。

２．早い段階でステアリングコミッティを開催し、スコープ拡大リスクとそのリスクが顕在化した場合の対策案を報告します。まだスコープ拡大がそれほど顕在化していない段階でも、リリース日の延期とコスト追加が必要となる可能性があることを意思決定者に印象付けます。

３．設計・開発担当者に対しては仕様変更多発が想定されることを重ねてインプットします。仕様変更を取り込むためのスケジュールバッファや予備工数を確保するために、できる限り作業を前倒しするように仕向けます。そして、仕様変更の兆しがあった場合には、きっちりとした変更管理基準にのっとり対応するよう粘り強く徹底し続けます。

プロジェクト成功のシナリオと演出がどんな感じなのか、私の伝えたいことがなんとなく理解できたでしょうか？なんのことは無い、プロジェクトに内在するリスクへの対応策と言ってしまえばそれまでです。しかし、さまざまな思いや経験の違いのあるプロジェクトメンバーたちを束ねて、リスク対応に協力を得るために粘り強くあの手この手を使っておぜん立てすることは、プロジェクト成功のためには欠かせないことだと思います。

宮本亜門氏のオペラ演出の難しさに関するトークの中に、プロジェクトマネジメントの本質を見たような気がしました。

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　「宮本亜門」『フリー百科事典　ウィキペディア日本語版』
2015年5月26日 (火) 21:47 utc https://ja.wikipedia.org/wiki/宮本亜門

※２　シナリオ、計画とリスク、マスタースケジュールに関しては、当ブログの以下の回も参照してください。
・【第１８回】計画が先か？リスクが先か？
・【第３０回】マスタースケジュール・フェチ
・【第３８回】80対20の法則でプロジェクトを変える！

※３　信念に基づくマネジメントの重要性については、当ブログの以下の回も参照してください。
・【第１０回】落合「オレ流野球」はＣＭＭＩレベル５か？