Tanti Anni Prima

雑食なエンジニアの本棚

【蔵書No. 27】プロジェクト管理術のアップデート | ProjectManagement進化論

 社会人になって企業で働くと、規模の大小問わず組織のプロジェクトに参入することがあるだろう。自分は複数の企業を練り歩いたわけでは無いので詳細は分からない。だが、当初定めたはずの開発日程や計画が遅れてしまうというのは日常茶飯事なのではないだろうか。原因は開発仕様の認識違いによる手戻りであったりとか、新規部品の発注漏れの発生など、粒度は様々だろう。当初定めたはずの計画には、当時は予想のできない不確実な部分が潜んでいるのである。それで頭を悩ませるのはプロジェクトのリーダーだけではない。その下で働くプレイヤーも同じだろう。大元の開発を要素に分解していって個人のタスクに落とし込んでも、ある日突然緊急の案件が横槍として入る。その案件を捌いているうちにさらに横槍が入る。結果当初の計画は達成されるはずもなく、マネージャからも叱責が入って板挟みになる。入社時に魔法の言葉のように刷り込まれてきたPDCA(Plan,Do,Check,Action)サイクルは、いつしか不名誉なPDCA(Plan,Delay,Cancel,Apologize)へとすり替わってしまうのだ。そんな無数の横槍に耐えうるようなスケジュールのマネジメント方法はないのだろうか、と思いたどり着いたのが本書である。

読んだ本

・タイトル:Project Management 進化論
・著者:後藤智博、渡瀬智、西郷智史

感想云々

 本書は精密機器メーカーの開発部長である津田が、壮大なプロジェクトの納期が間に合わないという緊急事態に直面し、その立て直しを図るというストーリー形式である。これを読んだ時は正直、「自分が所属している組織の話だろうか?」と思えるほど親近感の湧く組織の状態であった。前述のようにプロジェクトには不確実な部分が多い。そのため、どんなに優秀な人を集めたとしてもプロジェクトの遅延は発生してしまうのだ。一方で近年では、「できる限り短納期で、できる限り高品質で、できる限り低コストで実現して欲しい」という中々の無理難題が降り掛かってくる。もちろんそのような姿勢で開発を行うことが重要であることは言うまでもない(「あえて頑張らないでおこう」なんて姿勢の人はあまりいないだろう)。だがよく考えてみれば、これから新しい製品を開発するということは「誰も経験したことのことを、誰も発揮したことのないようなパフォーマンスで実現する」ということに等しい。そういう意味では、当初の計画から一切変更しないという方が稀なのではないだろうかと思えてくる。
 なぜ作成した計画がただの計画で終わってしまうのだろうか。それは本書によれば、緻密に詳細の計画を作り過ぎているからだそうだ。「計画には変更がつきもの」という前提で、「緻密に間違えるよりも大体合っている方がいい」というマインドのもと計画を練ることが大事だと語られている。これは自分としては非常に耳が痛い内容だった。恐らくプロジェクトの進捗管理を行う上では、各の「作業日数」を管理していることが多いだろう。そしてそれぞれの作業日数は2~10日の範囲で計画されていることが最適だと本書では謳われている。しかし自分の場合はさらに細く設定してしまっていたのだ。日割りにするどころか、半日単位でタスクを見積もっていることが多いのが現状であった。結果、少しでもタスクのずれが生じると、全てのタスクがスライドして遅延することになりかねないのだ(各タスクに多少のバッファを設けていたとしても、である)。さらに言えば、スケジュールにおいて設定するバッファ(安全余裕)の置き方も自分にとっては問題があった。自分はタスクの作業日数を見積もる際、全てのタスクの日程を守るために「各タスクごとに」バッファをもたせることを意識していた。ところが、この方法は本書ではまぁまぁ否定されている。「タスクごとにバッファをもたせる」のではなく、「各タスクのバッファを取り除いて、プロジェクトの最後に集約」すればいいとのことである。すべてのタスクの期限を守るという個別最適から脱却して、プロジェクトの納期を守る全体最適に視点を変える必要があったのだ。タスクごとに考えてしまっていた自分のような人間はもしかするとマイノリティなのかも知れないが、同じような境遇の方々にとっては思わず「へぇ」と感心してしまうような内容ではないかと思う。明日から実践が可能、という手軽な内容であるのも個人的にはポイントが高かった。
 ところで前述のようなバッファの持たせ方について、既に実施しており「んなもん当たり前だろ」と思っている人もいるかも知れない。だが、このようにプロジェクトにバッファを持たせると確実にうまくいくのだろうか?悲しいが、実はそんなことはない。バッファを持たせているはずなのにギリギリになってしまうのは、人間の心理が働いているからだそうだ。この心理的な内容も自分にとっては非常に刺さった。例えば「学生症候群」。学生が与えられるレポート課題や試験に関して、ギリギリにならないとやり始めないというアレである。これは学生だけではなく社会人にも通用する内容であるが、改めて知識として持っておかないと見逃してしまいそうな落とし穴だろう。他にも「与えられた予算と時間はあるだけ使ってしまう」というパーキンソンの法則や、「たとえ早めに終わっても早期完了の報告をしない」といった心理問題が本書では挙げられている。ここまで読んで、「全部自分のことじゃないか」と悲観してしまう人も少なくないだろう。だが、自分はそうなる必要はないと思っている。これらの内容は、本書で大々的に述べられるほど一般的な心理である。どんな大企業でも、どんな優秀な人の中にも潜在している問題である。大事なのは、こういう心理があるということを組織の人間全員が認識して向き合っていくことだと思うのだ。組織の人間が集団免疫的にこの知識を持っていないと、どんなにいい人材がいても、どんなにいい仕組みを作っても、文化として定着せずすぐに頓挫してしまうのが予想できてしまう。このマインドセットと、本書冒頭で書かれている「1つだけ確かなことは『今、抱いているプロジェクトの悩みや課題は、必ず解決できる』ことだ。」という救いの言葉をモチベーションに、組織全体で同じベクトルで挑む必要がありそうだ。

終わりに

 プロジェクトを進める上で、どんなにいい手段を取ってもそれを実践・継続出来なければ意味がない。プロジェクトリーダーである人もそうでない人も、本書を読んだ上で「論語読みの論語知らず」にならないためでも、規模問わず明日からすぐにでも実践すべきなのだ。そうすれば、企業が長年抱え続けているプロジェクト遅延問題にも明るい兆しが見えてくるのではないかと思う。


それでは。