プロジェクトマネージャをしていると、メンバーの進捗管理をする仕事がある。メンバーが遅れた時に言い訳のパターンが見えてくる。いや、長年メンバーをしていると言い訳のパターンが増えてきたというべきか。
しかし、それを秒速でホッテントリ入りしそうに制していくプロジェクトマネージャの諸先輩。自分が今までしてきた言い訳とそれを制してきた先輩PMの立ち居振る舞いをおさらいすることで、明日の言い訳を思いつくきっかけになればと思うんだ。
ココがポイント
- タスクが遅れた時に使える言い訳
- 遅延を出さない、言い訳させないためのプロジェクトマネージャーがやるべきこと
プロジェクトマネージャもメンバーも経験したから、両方のつらい気持ちが痛いほどわかる。システムエンジニア歴22年のわたしが解説します。
目次【本記事の内容】
- 1.タスクが遅れた時に使える言い訳
- 1-1.メンバーがなぜ遅れるのか？
- 1-2.言い訳5選
- 1-3.そもそも遅れないようにできるのか？
- 2.遅延を出さない、言い訳させないためのプロジェクトマネージャーがやるべきこと
- 2-1.無駄な事をメンバーにさせない
- 2-2.キープレイヤーにバッファをもたせる
- 2-3.EVM(Earned Value Management）の弊害
- 3.まとめ
タスクが遅れた時に使える言い訳
メンバーがなぜ遅れるのか？
プロジェクトには不確実性がある。将来のことを予測するのだから当たり前だ。未来を正確に予測できるのだったらプロジェクトマネージャーよりよっぽど楽な仕事がある。株、FXの投資家に転職するほうがよいだろう。
未来を正確に予測することは至難の業。しかし、経験豊富なプロジェクトマネージャは不確実性を見越してプロジェクト計画を作る。
- プロジェクトメンバーが病気で休む、転職
- 自然災害
- 見積もり以上に予算を使うタスクの発生。コストオーバー
- 不具合が発生した
- 顧客から変更要求がきた
- 期待した要員が確保できなかった
- 法律が改正される
自分がメンバーとして働いている時にはそんなプロジェクトマネージャの難行苦行などつゆ知らず。
目の前のタスクを者に遮二無二こなしていた。
それだけ頑張ってやってもやっぱり自分のタスクが遅延してしまうことがある。そんな時に限ってふら～～とプロジェクトマネージャが私のところにきて「順調？」と聞いてくる。
なんでこの人はいつも順調じゃない時に順調？って聞いてくるのか？最初の頃は摩訶不思議だったが、進捗管理表で遅れているから聞きに来ていただけであった。
そして遅れている理由を説明するのだが、ああ言えばこう言う。こう言えばああ言う。そんな攻防をプロジェクトマネージャとやり取りしなければならない。こんなやり取りしている暇があったら、タスクを片付けたいのだ。結局キャッチアップの報告書を出せという話になり、報告書を作る時間があったら、作業が終わっているのではないか！と顔を真赤にすることも度々あった。それが嫌なら遅れるなよ。というプロジェクトマネージャからの間接的なメッセージだったのだろうか。
でも自分がプロジェクトマネージャをやるようになって、状況を把握することができた。
当たり前だが、プロジェクトマネージャは遅れが出ると、もっと上の上司や顧客、全社PMO（プロジェクト・マネジメント・オフィス。会社全体でプロジェクトの状況をウォッチしている部署でPMはサポートしてくれない）からアレヤコレヤと責められ報告書を出さないといけないのだ。
言い訳5選
プロジェクトマネージャだって中間管理職。さらに上には報告をする人がいるわけだ。プロジェクトメンバーだろうがプロジェクトマネージャだろうが、関係ない。言い訳のバリエーションは増やしておく必要がある。
1．こんな見積もりでは全然足りませんよ。
まず覚える言い訳がこれだろう。進捗管理表を作った時にメンバーも含めてそれぞれ担当する作業はこのくらいの工数でできるかどうか確認する。
でも実際にやってみたら思ったよりも大変だということはいつものことだ。
それならなんでスケジュール確認した時に言わなかったのかと聞かれるが、全部のタスクについて蓋を開けて詳細に調べる時間が無いのだから仕方ないではありませんか。プロジェクトマネージャのあなたの方こそなんでわからなかったのですか？と喉元まででかかって、その言葉を飲み込むわけだ。若いときは血気盛んだったから飲み込めずに言い放ってしまったこともあるわけだ。プロジェクトマネージャも返す言葉もないからどうやって解決するか話し合うわけだ。ただ、プロジェクトマネージャの心のなかには「生意気な奴」として心に残ったことだろう。
自分もプロジェクトマネージャになってそう思ったことは何回もあるが、その頃には大人の対応を心がけていたから、机をバンバン叩いてぶちギレしたということは一回しか無い。その一回ぶちギレしたことで、キレても良いこと無いなって悟ったからそれからはやめたの。パワハラで訴えられるご時世だしね。
2．誰かが作った成果物の品質が悪いせいです。
基本設計が遅れている。理由を聞くと
「要件定義書がぼやっとしすぎてて、どんな画面が必要かわからないのですよ！」
詳細設計が遅れている。理由を聞くと
「基本設計書がぼやっとしすぎてて、どんなロジックにすれば良いのかわからないのですよ！」
プログラミングが遅れている、理由を聞くと（以下略）
こういうケースはウォーターフォールでプロジェクトを進めているのに、前工程に戻ってしまうという最悪のパターンになりかねない。
3．95%は終わってます。
進捗管理表で予定の日を過ぎたのに、終了日付が入っていないとプロジェクトマネージャからチェックされる。
「もうほとんど終わってます」
「95%は終わってます」
と言われることがある。95%って言われたらどんな計算をして95%って言ったのか確認しなければならない。
100ステップコーディングするうちの95ステップが終わってて、残りの5ステップでどうしてもビルドが通らず困っている。
それって95%終わっているけど、いつ終わるか目処が立たないということ。
あと何日かかるのかって聞いたら「それはわかりませんね」ってなっちゃう。技術力の有るシステムエンジニアを送り込んで問題解決にあたって貰う必要がある。
プロジェクトリーダーになって、先輩PMから教えてもらったのは「99%のジレンマ」。
進捗を確認したら90%と言われ、次の週に確認したら95%と言われ、次の週に確認したら99%と言われ、次の週には99.5%って言われて、おい！となる減少だそうだ。そんなになる前に流石に気づくだろとおもうだが、メンバーが90%とか言い出したら気をつけろということだ。
4．QA待ちですね
プログラムが予定通りに終わっていない。何があったのか聞きにいく。詳細設計でわからないところがあって詳細設計した人に質問をしているそうだが、答えてもらっていないので終わらない。
詳細設計した人に聞きに行く。どうすればいいかわからなかったから、基本設計を書いた人に質問をしているが、まだ答えてもらっていないのでプログラマーに回答できないとのこと。
基本設計をした人に聞きに行く。どうすればいいかわからなかったから、顧客に問い合わせ中でまだ回答できないという。
顧客との定例で確認する。ユーザー部門に聞かないとわからないという。更にコンプライアンス部門のチェックも確認するまで待ってって。
ため息が漏れる展開だ。
5．実はやり方知らないのです
プロジェクトメンバーをアサインする時、プロジェクトで使用する技術に精通しているかどうか確認する。
プロジェクトでつかう技術に100%マッチする人なんてほとんどいない。だから50%ぐらいでもチームとして成果を発揮できそうな人ならOKだ。人手不足なんだから贅沢は言えない。
プロジェクトマネージャとしてもそのことは分かっているので最初は余裕をもたせたスケジュールを設定する。それでも予定通りに終わらないこともある。それぐらいのリスクは分かっているつもりだ。
でも万が一ということもあるので様子を見に行く。
あのひと苦戦しているようだけど大丈夫ですか？
協力会社のリーダーの人に聞く。
実は進捗があまりにも悪いからうちのメンバーも入れて見ているのですが、JAVAが全くわからないみたいです！
え！ JAVAはわかるって言ってたのに。「自信有ります」って言ってたのに。「経験あります」って言ってなかった？
本を読んだらしい orz
協力会社でもこりゃ駄目だと思ったのだろう。一ヶ月で退場されてしまった。
プロジェクトは遅れるもの
プロジェクトをやっていて不思議なのが予定通りに終わるか、遅れるプロジェクトしか経験していないことだ。予定通り終わったプロジェクトでも途中で遅れが発生してそれをなんとか挽回して終わったというケースだ。
すご～～く前倒しで無事に終了しましたというプロジェクトをやったことがない。
個人レベルの仕事についてはパーキンソンの法則が有名だ。本の表紙に部下には絶対に見せるなと書いている。
でもほとんどの部下が知っている法則となってしまった。そうするとパーキンソンの法則を知っていることを逆手に利用することを考える。
パーキンソンの法則があるから5人日かかる見積もりだけど、3人日のスケジュールにすればそれなりのレベルでできるんじゃないの？
この法則をつかってメンバーに試したこともあるし、メンバーとして試されたこともある。
自分がメンバーとして試された時、私が本当にテストしないといけないなと思ったテストケースの7割を消化したら期日になってしまった。パーキンソンの法則があたっているとすると残り3割は品質過剰なテストケースになるのだが。
だめだ、こりゃリリース延期だわと思ったら、お客様から
「よし！ 腹くくった！リリースしよう」
いやいや、さんざんプロジェクト計画の時にこれくらいの品質レベルを確保しないとリリースNGとか言ってませんでしたっけ？
そりゃ期限に間に合わなくて、リリースするか延期するかお客様に丸投げしてバンザイしているうちのPMもどうかと思いますけど、リリースしますか？そうですか、そのあと地獄見るのは分かっていますよ。
ホストのリース期限があって延長するとすごくお金がかかるらしい。予定日通りにはカットオーバーしたけど、リリース後に障害だらけで地獄見た案件の一つとなった。
幸せなプロジェクトを経験してみたいものだ。
でも情報処理推進機構（IPA）が発行しているソフトウェア開発データ白書2018-1019（*1）によればQCDすべて成功したプロジェクトは71.9%にもなる。結構高い確率で成功しているのである。
だとすると私のやり方がまずいということなるではないか！ん？ただし、これはベンダー側のアンケートになっている。
もうちょっと調べてみたら日経ビジネスの記事を発見。
回答者の6割が情報システム部門という記載があるからこちらの回答はユーザー部門が混ざっているのだろう。
https://business.nikkei.com/atcl/opinion/15/100753/030700005/
●2018年（回答者数1201件、プロジェクト件数1745件）
プロジェクト成功率： 52.8％
満足度： 78.5％（経営層）、79％（利用者）
コストの順守率： 81.8％
スケジュール（納期）の順守率： 72.3％
成功率が20%も下がっている。何を持って成功とみなすか定量的な基準がないが、ベンダー側の意見とユーザー企業の思いにずれがあるのだろう。
遅延を出さない、言い訳させないためのプロジェクトマネージャーがやるべきこと
無駄な事をメンバーにさせない
プロジェクトマネージャになって何に一番気を使うか？ 無駄な作業をしない。メンバーにさせない事だと私は考えている。
ココがダメ
- 不具合の発生（作業のやり直し）
- 不要な成果物を作らせる
- 前工程の完成待ち
- 不必要な処理
- 非効率的な働き方
- 必要な機器の不足、もしくは性能不良の機器
- そもそもの要求が間違っている
ウォーターフォール開発だろうがアジャイル開発だろうが、前工程の成果物が悪かったために予定より時間がかかるというのはよくある話。
だからプロジェクトが失敗する原因の多くが上流工程にある割合が多い。先の日経ビジネスの記事でも要件定義工程が失敗の元と断言している。
だからアジャイル開発ではユーザーは正しい要件を出せないという前提でまずは動くソフトウェアを使ってもらいながら考えるという発想だ。
私はユーザーが正しい要件を出せないと断言してしまうのはどうかと思っている派の一人なのだ。でも私が入社したばかりの頃は社内システムが中心だった。
でも最近の案件はインターネットに公開される前提のシステム開発案件が増えている。だとすると何がうけるかユーザー企業の担当者でもわからないというのは仕方がないとも思う。アジャイル開発をやりたがっているユーザー企業が増えるのも仕方がないことだろう。
それについて以下の記事で書いてますのでもしよかったらご覧ください。
-
-
SIerがAgile開発を始めるための課題と対策
日経コンピュータに書いてある。2019年8月22日号。「さらばウォーターフォール型ベンダー」という見出しの記事。アジャイル開発が出来ないベンダーはユーザー企業から見放されるよ。前回私が怒りの提言記事を ...
続きを見る
キープレイヤーにバッファをもたせる
プロジェクトにはその特性によってキーパーソンになる人がいる。
プロジェクトマネージャ、リーダー、業務に精通したSE、技術に精通したSE。
そういう人たちにはバッファをもたせるようにしている。具体的にはプロジェクトマネージャを自分がするなら、具体的なタスクは持たない。
その他のキーパーソンにもプロジェクトの状況によるが、50%から80%のタスクしか割り当てしないことがある。
そういう人たちには突然やってもらわないといけないタスクが発生したり、周りのメンバーをフォローしてもらったりしないといけないからだ。
しかし、要員計画を作るとそういう人たちにはタスクが割あたってないからスカスカに空いているように見える。物分りの良い上司なら問題ないが、そうでなければもっとタスクを積めば短い期間で終わるだろうとツッコミを受ける。あなたもその昔PMやった時にその方法で失敗したのではないかと言いたくなるのだがぐっと堪える。
そう言われることが事前にわかっている場合は管理工数で埋まっているように見せるのだが、今度は管理工数比率が高すぎないか！と突っ込まれる。
今度はリスク費用を・・・
今度は営業利益率を高めの計画に・・・（以下略）
ゴールドラット先生のクリティカルチェーンでボトルネックが生産性を決めるとある。この私のやり方はボトルネックをなるべく使わないようにするやり方なのでザ・ゴールで言われているボトルネックを最大限活用する考えに従っていない気がするのだがどうなのだろうか？
EVM(Earned Value Management）の弊害
プロジェクトの流れをパート図で以下のようになる。
EVMだけでプロジェクト管理をしていると詳細設計段階ではどこか一個のタスクでつまずいても別のタスクがある。詳細設計の機能1がつまずいたら機能2の詳細設計をやればEV（出来高）が稼げるので報告書では遅れたように見えない。
でも詳細設計 機能１がクリティカルパスになっていたらどうするのだろうか？以前勤めていた会社ではEVMの数値で報告するのが習わしだった。プロジェクトの前半では問題なくても後半で火を吹くケースが多い。
上の図で90%の確率で実装・単体テストがスケジュールどおりに終わるとしたら、結合テストを予定通りに初められる可能性のは何%？
0.9×0.9×0.9×0.9＝0.43ですね。
実際のプロジェクトではこれよりもさらに複雑な組み合わせでしょうから更に確率は下がるでしょう。
私が後輩PMにEVMの数値を良くしようとするのではなくてクリティカルパスやボトルネックに注意を払っておけよと忠告するのは、後工程になるほど遅延の確率が高くなるからです。
まとめ
プロジェクトの失敗原因について話しだしたらきりがありません。
私が書いたことが間違っているということもある。書いたことが間違っていると書いたことが間違っていることもある。
でも日経ビジネスの記事で年々プロジェクトの成功率が上がっていることを知りました。
IT環境はますます複雑になって、ユーザーもどんなシステムだったら良いのかわからないような状況なのに成功率が上がっているとは驚きました。
皆様とともにプロジェクトマネジメントのスキルに更に磨きをかけていきたいと思います。
参考文献
日経ビジネス https://business.nikkei.com/atcl/opinion/15/100753/030700005/
C.N.パーキンソン 著 パーキンソンの法則（Amazonリンク）
エリヤフ・ゴールドラット 著 クリティカルチェーン（Amazonリンク）