それマイルストーンじゃねーから

はじめに

　今回は、プロジェクトマネージャがマイルストーンを作成する時に
　これだけは意識しとけよ！という事をメモしていきます。

　経営に用いられるマイルストーンは想定していませんのでご注意下さい。

マイルストーンを書く時に意識すること

　手っ取り早く、結論を書くと
　　「外部と関連するイベントの定義」
　これをちゃんと意識しようよということ

以降は、
え？私の知ってるマイルストーンのページにそんな事書かれてるの見たことねーな
という人を対象にしています。

この意識を明確にこれを定義しているのは、
私も見たことはありません。
しかし、この意識一つでマイルストーンの見え方がクリアになり
見えるポジションを上げることができるのでは無いかとおもいます。

以下、雑記

目次

1. マイルストーンについてインターネット上の定義
2. よくある間違いマイルストーンを考える
3. マイルストーンの本当の意味を理解しよう
4. もう一度インターネット上の定義を眺める
   　 # マイルストーンについてインターネット上の定義

コトバンク
マイルストーンとは、物事の進捗を管理するために途中で設ける節目をいう。もとは道路などに置かれ、距離を表示する標識（里程標）のこと。商品開発やシステム開発など、長期間にわたるプロジェクトなどでいわれることが多い。 各マイルストーンは最終的な到達点に向かうまでの通過点であり、それぞれの時点で達成すべき事柄（達成要件）と、実際の状況を照らし合わせることで進度の調整を行う。日付で指定されるほか、イベントや行事をマイルストーンとすることもある。

プロジェクトマネージメント連載シリーズ 第8回
マイルストンとは、プロジェクトの中で工程遅延の許されないような大きな節目のことを指します。一般的なプロジェクトマネジメントにおいては、マイルストンに対する進捗をモニタリングし、場合によっては適宜工程の修正を行って新たな計画を立て再び実施を行うという方法でプロジェクトを進めます。ガントチャート上でマイルストンをそれと分かるように表示すると、プロジェクトにおける主要なポイントが一目で分かるので便利です。よって、マイルストーンは、経営層向けのスケジュールの説明に用いられる場合が一般的です。

このように、外部とのインターフェースを意識しようということは書かれておりません。

よくある間違いマイルストーンを考える

前章のインターネット上の定義だけでマイルストーンのイメージを抽出してみます。

• 物事の進捗を管理するために途中で設ける節目
• それぞれの時点で達成すべき事柄
• プロジェクトの中で工程遅延の許されないような大きな節目
• マイルストーンに対する進捗をモニタリング

こんなところでしょうか。

では、皆さん一度自問してみて下さい。
一旦、マイルストーンという前提を取り除きましょう。

次の４点を確認するために作成するドキュメントは何でしょう。
　●進捗管理のために途中に設ける節目
　●それぞれで達成すべき事柄
　●工程遅延の許されない節目
　●進捗をモニタリング

この４点を実現したいために作るドキュメントは何でしょうか。

皆さん想定通り、「WBSのガントチャート」です。
各工程の節目を定義し、成果物を定義し、各工程遅れが出たら遅延報告、
そして定期的にモニタリングされています。

ここまで話すと、この説の結論は読めると思いますが
ガントチャートを作る人が多いです。
それもマイルストーンを作る段階では工数などの見積もりがないので、
WBSもほとんど分解されていないのが現実です。

大概、先に決め打ちされている納品日から逆起こしした
このぐらいに終われば良いなの何とも無意味なイメージガントチャート。
そして、各工程の終了がマイルストーンになる。

全く使い物になりません。
その時体裁上作られても、その後見られることは無いでしょう。

マイルストーンの本当の意味を理解しよう

何故、こんな無意味なマイルストーンがまかり通るようになってしまったのでしょうか。
マイルストーンが何故必要なのかの理解が不足している事が原因です。

マイルストーンの本来作られるべき工程や
元々経営層などの上層部マネージャが見ることが前提の資料である
という事を忘れてしまっているからだと考えています。

プロジェクトの総責任者が各部署のステークホルダーを集めて、
マイルストーンを決める

これがマイルストーンのあるべき理想の姿です。

現状、現実の現場でそうなることが少なく
開発プロジェクト内でマイルストーンが作成される事が多い

この理想と現実の隔たりが使い道の無い資料を
体裁上作らなければならないという状態に陥っています。

一度理想の状態でどのようなマイルストーンが作られるかイメージして見ましょう。

(※全てイメージです。)
<=======================>
責任者「今日は新規開発のプロジェクトXについてマイルストーンを作成する」
部門A「私の部隊はXX領域の開発を行います。」
部門B「私の部隊はYY領域の開発です。」
部門C「私の部隊は試験用のモジュール開発です。」

責任者「リリースは今年の８月末に1回目を迎えたい。Phaseをいくつかに分けて開発予定だから、全機能を乗せる必要はない。スケジュール可能な範囲で優先度の高い順に開発してくれ。」
部門A「AA機能群は、我々のXX領域の開発が終わらないと、YY領域の開発が進まなくなってしまう。」
部門B「それ以外の開発を先行するにしても、6月までにAA群機能のXX領域のモジュールをリリースしてもらわないと危ないかもしれない」
部門A,B「では6月末にAA機能群リリースをマイルストーンにしよう」
部門C「試験も8月には試験に入っていないと品質確保が難しいのではないか。」
部門A,B,C「では、7月末に試験用のモジュールリリースをマイルストーンに設定だな」
部門A,B,C「一度、現場に持ち帰って、そのマイルストーンを維持して作成するために詳細を詰めてみよう。」

部門A,B,C「週１の上層部定例では、マイルストーンに遅延が出そうになった場合はすぐに報告をあげるようにしよう。」

<=======================>

こんな簡単に運ぶものではありませんが、
イメージなのでご了承ください。

各自の担当部門の詳細設計や実装が何日遅れているという話は、
このレベルでは行われないという事が言いたい点です。

まぁ、とても悪い言い方すると

自分の部署以外の遅延なんてどーでもいい。
自分のところに影響あるのかないのかそれだけが知りたいんだよ。
それをまとめているのがマイルストーン

という事です。

つまり、マイルストーンとは、そこに遅延が発生したら
部署間を跨いで調整が必要なイベントを定義する事が重要なのです。

ガントチャートでは見える化できない情報であり、
ガントチャートとは大きな違いなので定期的にウォッチする必要があります。

マイルストーンの遅延を取りこぼすと最悪プロジェクト全体がコケます。

ここで結論の
「外部と関連するイベントの定義」
に到達します。

例えば、DB設計部隊が別部署であれば、いつまでにDBが決まらないと困るとか
試験用環境の構築をするなら、いつまでに環境が届かないと困るとか

もう一度インターネット上の定義を眺める

「外部と関連するイベントの定義」の意識を持ちながら、
これらの定義を眺めると行間がより深く意識できるのではないでしょうか。