2019-07-14

ガントチャートをやめる、課題ドリブンのプロジェクトマネージメント

あるシステム開発プロジェクトに途中参入しました。まだ序盤であるのにプロジェクトの進行は停滞しているようです。大きく舵取りをする必要がありました。今回は、これまであまり意識せず感覚的にやってきたことを大事にしました。無意識にやっていることを意識的に表現してみることにしました。これはその挑戦の記録です。

“美しい”ガントチャート

システム開発プロジェクトの会議ではガントチャートをよく見ます。ガントチャートは成果物やタスクを挙げて、それぞれにかける時間を帯で表現したものです。何をいつまでに完成するということを予定します。実績と見比べることで進行の程度を様子見ることもできます。

ガントチャート

ここで知っておきたいことがあります。ガントチャートのとおりにプロジェクトが進行することはまずありません。ガントチャートを作ることはその通りにならないと言うことに等しいとすら思えます。それでもガントチャートは作られます。このとおりにやれ、と言ってしまうことが楽だからだろうと私は想像しています。棚田のように並べられた帯はいかにも計画されたものであるかのように見えます。帯が期日までに収められていれば、そのように終えられるように思えます。

見える、思える、というのは危険なことです。不安をつかの間の安心によってごまかすことができてしまうからです。”美しい”ガントチャートにはそのような作用があると私は思っています。そして、考えることをやめさせる副作用があります。”美しさ”に安心するあまり実際の問題に目を向けることができなくなってしまいます。

何人日遅れています

ガントチャート上で遅れが発覚したときにできることは限られています。後続の帯を遅れた分後ろにずらすか、あるいは短くすることだけです。報告の大概は、何人日遅れていますという内容です。遅れた分は稼働を増やして取り戻します、と続けます。この一連の報告は、複数の現場で、本当に何度も、聞きました。この報告は何も意味を成さない、そう感じてきました。それで解決することなら、はじめから稼働を増やして貯金を大きくしておいた方がよいというものです。

そもそもガントチャート上の遅れだけではプロジェクト進行の真意が分かりません。引かれた帯が短かっただけかもしれません。だとすれば改めるべきは帯の長さだったわけです。改めるのは手出しする前にするべきでしょう。しかし、その必要が分かるのは帯の右端に至ってからです。それで帯の長さが改められる、リスケジュールされるならまだよい方です。ガントチャートを利用することはリスケジュールで頭を悩ませることを必然にします。しかし、システム開発の目的はリスケジュールすることではないはずです。

状況を足止めする具体的な何か

システム開発の目的はシステムを完成することです。特に何もなければメンバーが手を動かしてシステムを完成させます。が、現実に特に何もないということはありません。メンバーが手を動かすことを妨げる何か、それを把握する必要があります。それさえ取り除いていければメンバーは手を動かすことができます。このことを当てにしてプロジェクトの前進を管理するようにしました。状況を足止めする具体的な何かを目当てにする、というわけです。

課題構造

まず、ガントチャートに代わる新しい管理簿を作りました。整理の仕方はこうです。サブシステムや主要な機能、技術要素の違いなどで達成すべき目標を分解します。目標に辿り着いたとみなすことができる要素、達成する事項を挙げます。達成すべき目標はストーリーや成果物、達成する事項は決めごとや未知なことに対する課題、このくらいの粒度がよいです。達成する事項を挙げたら、それぞれの事項について状況を理解します。状況を理解したら、その中で取り得る選択肢・目当てを挙げます。優先の基準を明確にして、選択肢からすぐに着手するものを決めます。

達成すべき目標・達成する事項・取り得る選択肢を考えることは計画する課題の管理です。しかし計画する課題では洗い出せないものは必ずあります。目の前の課題が状況下で発生します。対処が遅れればその分足止めされます。目の前の課題が顕在化すればこれに対処する必要があります。これは状況下の課題としてリストアップしますが、計画する課題のように整理しません。ひとつひとつ挙げては対処します。対処した、あるいは対処できなかった事実は計画する課題の状況にフィードバックします。計画する課題において新たな状況を理解します。新たな状況に応じて達成する事項と取り得る選択肢を見直します。

状況の把握が解決すべき課題と目当ての輪郭を作る

大事なことは状況を把握することです。状況は進行を足止めするもの、予想されるリスクに着目して観察します。状況の理解が解決すべき課題と目当ての輪郭を作ります。状況によっては課題は解消されているかもしれません。あるいは目当てが変わることがあるかもしれません。状況下の課題を管理することで状況そのものを把握します。観察したことを計画の状況にフィードバックして何度も見直します。

ここで、状況下の課題を計画する課題と一緒に一覧しない方がよいです。状況下の課題はボトムアップなこと、計画する課題はトップダウンなことです。大局的な舵取りのことなのか目の前の足止めのことなのかが曖昧になってしまいます。一緒にすると解決すべき課題と目当てが不明瞭になります。

足止めするもの、予想されるリスクを取り除けばプロジェクトは前進します。ここで何人日と言ったところで締めつける以上の効果を与えません。今の状況を次の状況に更新することが大事です。解決すべき課題と目当てに焦点を合わせるのは状況に変化を与えるためです。状況が変わらなければ帯を後ろにずらしたり短くしても意味はありません。

状況へのインパクトをいつも考えます。状況が一変することを重要視します。やってもやらなくても状況が変わらないことならやらなくてよいです。予想されるリスクについても考え方は同じです。状況を一変させ得ることは最初に対処する必要があります。悪い方に転じ得ることならなおさらです。あらかじめ悪い方に傾けておいて状況の更新を考えなければならなりません。


プロジェクトは停滞していました。進んでいるような進んでいないような、何から手をつけてよいか分からない状態でした。

まずは出来ていることと出来ていないことを仕分けしました。”出来ていること”の出来は慎重に確認しました。”出来ていること”が出来ていないことはよくあります。そして、実際にありました。

後で変更があると面倒なものから、その決めごとを目当てに捌いていきました。サブシステム間の連携について、そのアプリケー・ションインタフェース。状態が複雑な画面操作について、そのユーザー・インタフェース。そして、技術と権利と握りの問題が関わっていた機能のスコープ。

大筋の決めごとが解決できれば、あとはOODAの実践です。目の前の課題を適宜捌いて対処して、目下の状況を観察します。観察したことは計画の状況にフィードバックして、新たな状況における計画を再構築します。やったことと言えば、この実践の繰り返しだったように思います。

ジャーニーはつづく。

ふくちはるき
フリーランスのソフトウェアエンジニア
オブジェクト指向やドメイン駆動設計に興味があります。趣味で写真もやります。 もっと詳しく