「本当に間に合うの？」の答えが「何もなければ大丈夫」は“圧縮スケジュール” プロジェクトマネジメントアンチパターンの回避策

よかれと思ってやっていることに苦しめられているケースがある

西郷智史氏：みなさんはじめまして、株式会社ビーイングコンサルティングでコンサルタントをしている西郷と申します。よろしくお願いします。

本編を始める前に、まず弊社の紹介をします。弊社はビーイングコンサルティングといいまして、事業内容は、制約条件の理論に基づいた生産性向上のコンサルティングサービスの提供です。制約条件の理論は、TOC（Theory of Constraints）と略されることもあり、有名な著書として『ザ・ゴール』『クリティカルチェーン』などがあります。

もう少し具体的に言うと、今回のテーマにもあるプロジェクトマネジメントに関して困っていることへのコンサルティングサービスです。

例えば、「納期遵守率が非常に低いので、納期に間に合うようなマネジメント環境を作りたい」や、製品開発するお客さまでしたら、「なかなか事業戦略どおりに商品が出せない」「いつも遅れてしまっている」「出せてはいるが、残業や休出が多くなってしまい、非常にコストがかかっているためなんとかしたい」などの困りごとがあるお客さまに対して、一緒にプロジェクトマネジメントの体制を作ったり、組織のルールを変えたりするなどのコンサルティングサービスを提供している会社です。

コンサルティングする中で、みなさんが良かれと思ってけっこういろいろな対策やマネジメントの仕組み作り、ルール作りなどをやっているということを聞きます。それが改善につながっていればいいのですが、良かれと思っていることが実は自分たちを苦しめてしまっている、いい結果につながっていない、などのケースがかなり見られます。

私たちが支援しているお客さまは世の中のほんの一部ですが、私たちのお客さまだけではなく、今回参加してもらっているみなさんの会社でもそういったことが起こっているのではないかと思いました。そこで、少しでもヒントやポイントを提供できたらと思い、今回のセミナーを開催することにしました。

「元SEが」と書いてありますが、私はIT業界でSEをしていまして、ECサイトや通信キャリアのサイト、料金システムなどを担当していました。なので、みなさんの気持ちを少しはわかるつもりでいます。当時のことをいろいろと振り返りながら、具体的なことを盛り込みながら、話を進めていきたいと思っています。

今回のセミナーの構成です。まず、「アンチパターンとはそもそも何ぞや？」というところからスタートします。IT業界はもちろん、そうでなくても、近しいようなプロジェクトマネジメントと呼ばれている範囲の中で、よく見かけるアンチパターンを4つ紹介します。

「アンチパターンとはこうですよ」だけではありません。先ほど私が紹介したTOCとCCPM（Critical Chain Project Management）というソリューションの中に、それを回避する方法のヒントがありますので、それと関連づけて4つの事例を紹介し、最後にまとめます。

ちょっと時間が短いので、少し駆け足になったり、詳細までお話しできなかったりするかもしれませんが、お付き合いください。

アンチパターン＝陥りがちな避けるべき悪い典型例

まず、「アンチパターンって何？」から始めます。聞いたことがある人もいれば、意味はそこまでわからなかったけれども今回参加したという人もいると思うので、まずはアンチパターンの定義から一緒に認識合わせをしておきましょう。

ざっくり言うと、アンチパターンとは、よく陥りがちな避けるべき悪い典型例のことです。

もう少し柔らかく説明します。「これは最適だ、いい手法だ」と最初は思ってやるのですが、最終的にはそれとは逆の好ましくない結果をもたらしてしまう。しかも、それがさまざまな現場で繰り返されている。IT用語辞典にも書いてありますが、これがアンチパターンであるということを、まず認識してもらえればと思います。

次に、その例です。今回はマネジメントというタイトルで、今から4つのパターンを紹介しますが、マネジメント以外でももちろんアンチパターンがあります。

例えばスパゲッティコードであれば、その構造がほとんど理解できないシステムや、そもそも構造が誤っているもの。（スライドを示して）写真のようにスパゲッティになっているものです。こういったこともよくあると思います。はじめは良かれと思ってやっているのですが、どんどん進めていったら、最終的によくわからなくなってしまった例です。

また、切り貼りプログラミングもそうです。汎用的なコードを作らずに、良かれと思って既存のコードをコピーします。コピーしているから間違いも少ないだろう、早く終わるだろう、とコピーして改変して使っていきます。

でも、それを繰り返していくうちに、少しのズレが大きなズレになってしまうことがあります。つながりがわからなくなってしまったり、もともとのコメントが残った状態でそのコメントが次のシステムにコピーされてしまい、もともとの意味とは違う意味になってしまったり。そのように、良かれと思ってやったことが後々悪い結果をもたらすということが、この切り貼りプログラミングでもよくあります。

それと、「ドキュメントは後で」ですね。アジャイルでよくありがちなのですが、納期に追われている時にみなさんが何を優先しないといけないかというと、やはり動くもの、動くシステムを早く出すことになります。

成果物やドキュメントを作る前に、とりあえず動くものを作ってしまおう、となります。結果としてバグが多く発生してしまって手戻りになったり、試験ができなかったりします。ドキュメントがないがゆえに、大きな手戻りになってしまうことはよくあると思います。

アンチパターンの例としては、このようなものが挙げられます。今回は、これら以外に、プロジェクトマネジメントというテーマでよく見られるアンチパターンを紹介します。

その中でも実は大きく3つ、傾向があります。みなさんが良かれと思ってやっていることもあれば、無意識のうちにやってしまっていることもあります。あとは、「ちょっと悪そうだな」と思っているにもかかわらず、仕方なくやっていることもあると思います。

今回は、アンチパターンをこの3つに分けて紹介していきたいと思います。

アンチパターンその1　「圧縮スケジュール」

仕方なくやっていること、その1。圧縮スケジュール。よくあります。参加してもらっているみなさんの中にも、「ああ、やっているわ」「まさに今やっている最中だよ」という人もいると思います。

どういうことかというと、納期にはどうやっても間に合わないのに、無理やり圧縮した計画表を作ることです。みなさんもやりたくてやっているわけではなくて、仕方なしにやっています。チェックポイントとしては、要求される納期がいつも厳しいこと。「なんでいつもこんなに厳しい納期を言ってくるの？」「営業が取ってきてしまった」などがあります。

あとは、要求納期ピッタリに終わるスケジュールになっている。「本当に間に合うの？」に対する答えが「何もなければ大丈夫なんじゃないですか」となってしまっていたら、この圧縮スケジュールを仕方なくやってしまっている傾向があるかもしれません。このチェックに当てはまった人は、やっているかもと自分の現場に重ねながら聞いてもらえればと思います。

これはどのようなメカニズムになっているか。プロジェクトマネージャーは要求が来た時に、「だいたいこれぐらいの工数はかかりそう」「ほかにも動いているプロジェクトがいくつもある」など、技術的に不安な要素をいくつも考えます。それらを踏まえて、最低でもこれぐらいかかると考えます。

それが要求納期を超えている場合ですね。経験上、これはマズそうだとはわかるのですが、「じゃあ計画を出して」と言われると、なぜかこの要求納期に終わるように出してしまうと。なぜなのでしょう？　本当はヤバいと思っているのに、なぜか良かれと思って「要求納期どおりに終わります」という計画を出してしまいます。

これは文化の話でもあるのですが、上位マネージャーから「とりあえずやるのがSEなんだ」「やるのが君の仕事なんだよ」と言われると、それに間に合わせるように計画を作ってしまうのです。「なんとかするのがマネージャーの仕事ですよ」と最初から諦めたり、「間に合いません」と言ったりすることが悪とみなされる文化がある場合に、この傾向がよく見られます。

プロジェクトマネージャーも、「これこれ、こうだから、こうだから、これぐらい間に合わない」と論理的に言えればいいのですが、最初はそこまで詳しい要求が来るわけでもないので、論理的な説明がなかなかできないことがあると思います。

期間ありきで仕事を進めてしまう

この計画の中身を少しひもといていくと、よくあるケースが（スライドを示して）このような工程表の場合です。例えば、タスクの設計AからC、開発AからCまでをXさんがやります。設計AからCをXさんが3週間の中で完了させる、と表現することが多いと思います。しかも、オーバーラップしている箇所もあります。

よく考えてみてください。Xさんは1人しかいません。この1週目から3週目を、モニターを3つぐらい並べてABC同時にやっているわけではありません。Aをちょっとやって、次にBをやって、Cをやって、またAに戻って、Bを仕上げて、最後にCを仕上げて……と、要するに、各タスクを行き来しながらやっているケースがほとんどだと思います。

しかも、細かいことはやりながら検討しようということで、計画はざっくりしていて、この3週間で何をやるかはぜんぜん決まっていません。細かいことはやりながら検討しよう、今月中に何をやろう、などと言いますが、「今月」は1ヶ月あります。その中で設計AからCと開発があるのですが、もちろん設計が終わらないと開発ができないので、設計からやることになると思います。その設計のどこから手をつけるか、だいたいこれぐらいで終わればいいぐらいの感覚で、たぶんやり始めることが多いのだと思います。

要するに、考え方のアプローチとして、そのタスクにどれぐらいの期間が必要かというよりも、この期間にどれをやろうかという期間ありきで仕事を進めてしまうケースがほとんどなのではないでしょうか。それがなぜ起こってしまうかというと、決まったスケジュール策定方法がなかなかないケースが多いからです。

私たちもいろいろなお客さん先に行って、「御社の計画を見せてください」と言うことがあります。一番ひどい場合は、Excelに棒が2、3本書いてあるだけ。少し細かくやっていたとしても、ツールでバーが引かれていて、「ここでなになにをやる」と、1週間、2週間単位のもので書いてあるケースがほとんどです。そういった場合は、この期間でどのタスクをやるかというアプローチをしていることが多いです。

必要なリードタイムを客観的に表現し、最も長いタスクのつながりを明確にする

ここで注意が必要なポイントがあります。上位マネージャーやお客さん、つまり、この計画を出された側、見せられた側には、特に問題なく納期を守ることができると見えてしまうことです。

そうすると、マネージャーは必要な支援を受けにくくなります。本当はリソースをもう1人追加したい、要求の内容やターゲットをお客さんと受注前に調整したい、など、プロジェクトを成功させるためにいろいろとやりたいことや、やるべきことがあるのですが、それができなくなってしまうんです。

さらに、一度作成した計画は、「君はこういう計画出している、約束なんでしょう？」と言われてしまう。最終的にPM（プロジェクトマネージャー）は、辻褄を合わせることに翻弄されてしまう。各タスクの作業内容や完了条件が不十分なまま、検討されないまま、計画完了になりがちです。結果として、いざ蓋を開けてみたら、手直しややり直しが頻発して、ズルズルとタスクが長引いてしまうことがよくあります。

ここまで、アンチパターンその1、「圧縮スケジュール」が起こってしまう理由と、起こった時の弊害を紹介しました。これを回避するために、私たちはTOCやCCPMというソリューションの中で、必要なリードタイムを客観的に表現しましょうと言っています。

PMの感覚や経験で「これは難しいですよ」と言ってはいけません。むしろ、言われたほうは、「本当に？」って思ってしまいます。きちんと客観的に表現できるものを用意しましょう。

2つ目は、最も長いタスクのつながりを明確にしていきましょうということです。これについて、詳しいことはまた後で説明します。

その上で、納期に間に合わせるために必要な支援を明確に要求する。これが、プロジェクトマネージャーが本来やるべき仕事だと考えています。それを実現するためのお手伝いを私たちはしています。

タスク間の依存関係にリソースの依存も表した上でリードタイムを求める

もう少し具体的な話に入っていきます。まず、作業には依存関係があります。

例えば先ほどの例でいうと、設計が終わってからでないと開発ができない、開発をしていないとテストもできない、ということです。ちょっとアジャイルとは違いますが、ウォーターフォールでいうとこういった流れになっていきます。

IT業界以外でも、組み立てやものづくりなどでは、各パーツがないと組み立てができないといった依存関係が絶対に存在します。なので、まずはみなさんと一緒にタスクと依存関係を結びます。私たちはそれをネットワーク図と呼んでいます。

プロジェクトマネジメントの資格の勉強などで携わっている人なら1度は目にしたことがあると思いますが、いわゆるクリティカルパスです。依存関係ですべてを結んで、一番長いつながりを見つけましょうということをやっていきます。

（スライドを示して）この例でいうと、色が変わったところです。ここが一番長いつながりなので、ここがこのプロジェクトのリードタイムであることが明確にわかります。14日がこのプロジェクトのリードタイムです。

ここに1個抜けている観点があります。リソースです。（スライドを示して）このページの例でいうと、緑の人と赤い人は同じ時期に2つのことをやらないといけなくなっています。人間は1人しかいないので、2つに分かれることはできません。どちらかしかできないということです。

したがって、先ほどの14日というのは真のリードタイムではありません。どちらかしかできないので、ずらしてやるしかありません。

なので、このリソースをもし設定できるのであれば、私たちはこのようにしっかりはじめからずらしてあげます。リソースの負荷も加味して、こちらを先にやらなきゃいけないよねとか、ずらさないとできないという時には、しっかりずらしてあげます。これをリソース依存と呼んでいるのですが、タスク間の依存関係にリソースの依存もしっかり表した上でリードタイムを求めていくことが重要です。

この例でいうと、最初はリソースを加味しないので14日でした。リソースを加味すると実は違うパスが見えてきます。日数ももちろん長くなってしまうので、しっかりとそこまでを特定して、プロジェクトのリードタイムを計っていきましょうとアドバイスしています。

私たちはこれをクリティカルチェーンと呼んでいます。先ほどのものはクリティカルパスですが、リソースの割り振りを加味した状態のものをクリティカルチェーンと呼んでいます。計画を作る時には、この最も長いつながりを明確にすることが非常に大事になってきます。

（スライドを示して）クリティカルチェーンのパターンを3つ挙げています。納期が短い場合は余裕があるので特に何もアクションを起こさなくてもいいと思います。ちょっとギリギリぐらいの時は注意が必要です。危険なのは、納期から大幅にはみ出してしまう時。例えば、プロジェクトマネージャーは「このCパーツの設計と制作の人数を増やしてください」などと明確に要求するべきです。

『PMBOK』などを読んでいる人は知っているかもしれませんが、プロジェクトマネージャーの役割は、プロジェクトの最初に計画を立てて、リスク検知をして、要求するところは最初に要求することです。なぜなら、プロジェクトマネージャーにはプロジェクトを成功させるミッションがあるので、最初から手を打っておくということが役割なのです。

それをプロジェクトマネージャーに単に押しつけるだけだとなかなか難しいと思います。このようなことが許される、むしろやるべきだよという組織。プロジェクトマネージャーはそれをしていいんだよ、という雰囲気作り・ルール作りが大事になってきます。

プロジェクトマネージャーが動きやすいように経営層や事業部長レベルの人が配慮してあげることが、あわせて必要になってきます。それを頭に入れておいてください。それをやった上で、はじめの段階からリスクにしっかり対応しておくことが大事になってくると思います。

1つ目のアンチパターンは、「圧縮された納期を出してしまいがち」でした。その回避策として、プロジェクトの最初から、クリティカルチェーンを求める計画をしっかり立てる。もし危険な状態であれば、リクエストをしっかり出していくことが必要になってくる、という話でした。

補足です。この説明をすると、「最初からこんなことできないよ」「こんな細かいことわからないよ」と声が挙がることがあります。もちろん現実的にそのようなケースもあるのですが、ないよりはあったほうが論理的に説明できます。

例えば、細かく「2日」などではなくて「2週間」などの単位でもけっこうです。依存関係の見える化をしっかりやっておかないと、周りも納得できません。粒度は少し粗くてもいいですが、計画をしっかり立てておいたほうが、後々痛い目を見ずに済みます。以上が1つ目のアンチパターンの説明です。

質問がある人は、チャットでもいいですし、後ほど時間を設けますので、そこで質問してもらってもいいです。先に、アンチパターンその2にいきたいと思います。

（次回へつづく）