情シスがマスタースケジュールをつくる３つの理由
僕たちはどこにいて、どこに向かっているのだ？
車で移動する時にはナビもしくは道路地図。海に出たら航海図。山に行くなら登山地図。今いる場所から目的地に辿り着くには、必ず地図が必要です。そして、その地図により出発点からどのくらい進んで、残りの距離がわかる。それがないと、確実に迷子になります。
プロジェクトも全く同じ。違いは、この地図を自分たちで作らなければならない。世界にひとつだけにも関わらず。だから、プロジェクトは難易度が高いのです。世界中にある全てのプロジェクトは、この地図が唯一の手がかりになる。そして、多くはそれをマスタースケジュールとよびます。
マスタースケジュールですが、情シスが責任をもって進めるプロジェクトにおいては、情シスがつくった方が良い。いや、つくるべきなんです。
理由１.情シスだからこそ開発に関する網羅性を担保できる
どんなものでも、単体だけ考えていれば簡単です。レストランをイメージしてください。一品料理ならそれだけ意識していればOK。実際には、複数の注文がくる。お客さまも一人ではありません。俯瞰的にみて、順番を考える必要がある。
システムも同じ。今の世の中、システム単体だけ考えていれば良いという状況は少なくなってきています。多くの場合、他のシステムとIFをとっている。このIFの仕様や開発のタイミングが双方あっていないと問題になります。
多くの情シスをみると、主となるシステムの開発ベンダーのマスタースケジュールをそのままプロジェクト全体のマスタースケジュールとしています。情シスがちゃんと作っているところは少ない。
主となるシステムのマスタースケジュールは、その名の通り自分のところしか記載されません。連携先のシステムについての記載は接続テストくらいで、連携先のシステムの開発などのスケジュールは記載されません。
そんなマスタースケジュールで状況を適切に管理できるわけありません。
理由２.情シスだからこそ業務部門を意識できる
なぜ、情シスが存在するのでしょう？開発ベンダーからあがってくるマスタースケジュールをそのまま使っている場合は、やってることは単なる伝書鳩です。ちゃんと価値を出してますか？
情シスが価値を出せることのひとつとして、業務部門と開発ベンダーの間で、双方の通訳になり、さまざまなこと（多くは要望）を調整する。それが価値です。
開発ベンダーはどこまでいっても、開発ベンダーから見える世界しか見ることができません。業務部門も同じです。つまり、それぞれの世界観で会話してくる。ほとんどの場合、これが噛み合うことはない。わからなくて当たり前。
開発ベンダーのマスタースケジュールと業務部門の計画を把握・タスクを洗い出し、それを合体させたマスタースケジュールを作らなければなりません。それができるのは情シスしかいない。
理由３.情シスだからこその提案ができる
会社の中でシステム・ITに知見がある部署は？情シスなはずで、そうであるべきです。そのうえで、自分の会社の業務を知っているという稀有な部署は？それも情シスなはずで、そうであるべき。
理解していない人が多いのですが、実はものすごく情シスって貴重な部署であり、エキサイティングで面白いことができる部署なのです。
これは何を意味するかと言うと、経営課題・業務課題などをしっていて、ITでの解決策を提案できると言うこと。コンサルでも開発ベンダーでもない、情シスができるのです。A案でもB案でも現実的ではない。そんな時に情シスがC案を提示できる。
とても魅力てでき面白い部署だと思いませんか？
スケジュールとWBSの違いを確実に理解しよう
※このトピックについては、マスタースケジュールはいったん横に置いてください
多くの人がスケジュールとWBSを勘違いしている。同じものと考えています。しかし、違います。誰がなんと言おうと、絶対に違います。同じようなものと理解しているかぎり、適切なプロジェクトマネジメントはできません。
短く誰にでもわかる言葉説明すると、次のようになります。
「スケジュール」は工程表・日程表・予定表
「WBS」は最終成果物・達成したいゴールの構成要素
さきにお伝えすると、この違いをわからないPMやPMO専門家がいたら、非常に危ないと思って良い。この定義は基礎中の基礎。「英語得意です」といっておいて、英語全く読めない・書けない・はなせないのと同じ。
スケジュールは時間軸を意識したもの
工程表・日程表・予定表とある通り、スケジュールは時間軸を考えます。PMBOKではスケジュールは「タイムマネジメント」の知識領域として定義されている。随分と前からプロジェクトが研究されて、この整理になっているのです。まずはこれを信じるべき。
一点補足。スケジュールを意識すると必ず出てくるのが「マイルストーン」という言葉。これは時間軸は意識するも期間をもたない、意識すべき重要な日付。ある一点のことを言います。システム開発であれば、リリース日とかですね。
長いプロジェクトの場合は、中間地点としていくつか設定する場合もあります。例えば、開発ベンダーの請負契約が終わったシステムテスト終了日（＝受入テスト開始日）とかになります。
WBSは完成予定の最終成果物や達成したいゴールを分解したもの
WBSは「Work Breakdown Structure」の略。日本語では、作業分解構成図や作業分解図と訳されます。ちゃんとやると難しいのですが、意味するところは簡単です。
ある最終成果物や達成したいゴールがあって、それを完成・完了させるために分解した構成要素です。多くは階層構造をとること、そして同じ階層はMECEになっていなければならいことがポイントです。
ぜひ、気づいて欲しいのが、WBSには「時間」という概念はどこまで行っても出てこないのです。PMBOKでは、「スコープマネジメント」に定義される。
英語では「Work」、日本語では「作業」とありますが、長年の経験からプロジェクトで完成予定のものを分解して、そこに網羅性があれば構成要素の分解をするときに「作業」にこだわる必要はないと考えています。
何をいっているか？この辺り、あまり意識せずWBSを作っている人が多いのですが、世の中のWBSを見ると「作業ベース」と「成果物ベース」の２つに分かれることが多いです。
すごく乱暴ですが、会計専用のPCを設置するプロジェクトを例に取って説明します。
作業ベースの場合
よくあるのが工程ごとにWBSを分けるパターン。
成果物ベースの場合
よくあるのがソフトウェア・ハードウェア・ネットワークで分けるパターン。
マスタースケジュールの作成ステップ
マスタースケジュールに話を戻します。
ここにあげる作り方はかなり簡易的ですが、本質的で絶対的です。この考え方がど真ん中にある。この考えを中心において、あとはどこまで細かくするか。そして、リソースや予算、前提条件といった他の要素をどこまで考慮するかとなります。
Step1. 第二階層までのWBSをつくる
とにかく、WBSがすべてを左右します。徹底して考え抜きたいことが３つ。
一つ目は構成要素の名称は難しい言葉ではなく、できるだけ簡単な言葉で。
二つ目は、第二階層までつくり、全体像がイメージできる形にする。粒度のバランスがめっちゃ難しいですが、ぜひ考え抜きたい。
三つ目は徹底してMECEにこだわる。
この３つをとにかく徹底的に。簡単そうにみえて、ちゃんとやると難しいですが、だからこそ、これに尽きます。
Step2. 前後関係を考える
前後関係を考える前に、Step1で作ったWBSをスケジュールが作りやすい形に縦に並べ替えます。
次に、第一階層の要素を前後関係を考えて並べます。考えるのは、第一階層だけです。第一階層の数が多いと、これだけ大変なはずです。しかし、スケジュールらしくなってきているはずです。
第一階層が完了したら、それぞれの第一階層を構成する要素である第二階層を、同じように前後関係を考えて配置します。
Step3. マイルストーンをおく
慣れていないと難しく感じるかもですが、簡単です。必ず置くのは「プロジェクト開始」と「プロジェクト終了（＝リリース日など）」。そのほかにも、重要な日付があればそれをおきます。
次にそのマイルストーンを考慮しながら、第一階層の開始・終了を合わせる。
ここで、勘が鋭い方は「期間を考慮してないじゃない」とツッコミを入れる方がいるかもしれません。期間は次のステップで考えます。
マイルストーンというのは、相当な理由がない限りずらせない。つまり、マスタースケジュールの制約条件なんです。なので、先にマイルストーンを先にプロットするのです。
Step4. 期間を考える
ここでようやく期間を考えます。厳密にやるためには、アサインするメンバーの数やスキル・経験といったことを考慮しなければなりません。このあたりはかなり経験が必要となりますので、可能であれば有識者のレビューを受けるのをおすすめ。
多くの場合はマイルストーンが制約条件なので、「本当にできるのだろうか？」という不安にを感じるかもしれません。でも、それが感じられたら、かなり現実的なマスタースケジュールに近づいています。マスタースケジュールレベルでその感覚が重要なのです。
Step5. 整える
明言しますが、一度で完成することは絶対にないです。あとはStep1〜Step4を行ったり来たりします。何度もします。でも、それが普通です。多くの人は一発でできると思っちゃっている。世界にひとつだけの地図、簡単にできませんて。
WBSで構成要素が不足していたり、前後関係が間違っていたり。また、どう考えても十分な期間が取れない場合は、マイルストーンをずらさなければならない。制約条件をずらすというのは、かなりの労力がかかります。
そして見栄えは最後、とにかく最後。
そんなこんなで作成したマスタースケジュールは、かなり現実的なものになっているはずです。整理されたマスタースケジュールは、見るだけでプロジェクトの全体感が把握でき、どうプロジェクトが流れていくかイメージできます。
おまけ
余裕があったら第一階層で良いので、開始条件と終了条件を明確に設定しておくと、プロジェクトの品質が格段に上がります。プロジェクトマネジメントの教科書を読むと必ず書いていて知っている人が多いはずですが、実際やっている人は少ない。しかし、確実に品質上がります。
また、期間が足りないときどうするか？最低限の必ず必要な期間というのはありますが、ある程度なら期間を短くする方法があります。現実的にはどれも難易度が高いですが、優秀なPMやPMOはリスクを分析した上でこれらを選択し、実行します。
- 品質を落とす
- お金をかけてリソース（人）を投入する
- スコープを小さくする
絶対にやってはいけない３選
次にあげることをやると、プロジェクトはかなりの確率で成功率がさがります。もちろん、絶対失敗するとは言いませんが・・・結局、プロジェクトマネジメントはいかに成功の確率をあげるかですから。
❶WBSを考えずにマスタースケジュールを作成する
プロジェクトが走り始めてからの追加の大きいタスクは、かなりしんどい。無理すると、どこかに歪みが発生します。
❷WBSの構成要素が構成要素になっていない
よく見るのが「課題管理」「進捗管理」「確認」「調整」「共有」といったたぐいのもの。構成要素になってません。
❸WBSと時間軸を一緒に考える
いきなりマスタースケジュールを作成する。どんな理由があれまずはWBS、構成要素が先です。人間、そんなに器用ではないことを理解しましょう。
多くの人が、ここまであげたStep1〜Step4の違いを理解せずに「なんとなく」で同時におこないます。結果、「WBS=スケジュール」という誤った理解になっているようです。やってみればわかるのですが、同時にやるのはかなり難易度が高いのです。
＜情シスおさえどころ＞
たまに、「事情も知らず、好き放題言いやがって」みたいな文句っばかりを言う情シスをみます。考えてみましょう。もし、業務部門と開発ベンダーが問題なく会話できるとしたら。そうなったら、情シスの価値ってなんでしょうか？そうなってくると、もうやることは、おそらく決まりきった業務・お願いされた業務だけになる。文句をいう時間があったら提案しよう。
なんでもそうですが、AとBの間に何かしらの情報格差があって、それを埋めることができるから価値となるのです。弁護士、コンサル、マッチングサービスなど多くの仕事・ビジネスがそうであるように。