ボトムアップでなんか進捗しない

某プロジェクトの上流設計から参画してもらったシニアなエンジニアさんがどうもしかめっ面しながらディスプレイを覗き込んでいるのが気になって声を掛けてみたのです。

「どう」
「キッツイです…」
「なんか、ご支援したほうが良さそうなのでご支援しましょうか」
「お願いします」

シニアエンジニアの方は年齢もスキルレベルもシニアで手が動く先生みたいな人です。ですから技術的な不安は全くありませんし、ハナっから敵わないのでそちらはお任せです。

ただ、エンジニアには

・ボトムアップから積み上げる
・作業の目的より自分の関心事を優先する

という特性があるので放っておくと進捗がとんでもないことになる場合があります。

もちろん、シニアなエンジニアの方は専門領域であればプロジェクトマネージャもできるのでWBSを作ることなんてお茶の子さいさいなのです。

でも、こんな制約があると途端に嵌るのですが、これ、他のエンジニアでもみたことないですかねぇ。

制約条件はナニ？

「じゃあ見せて」
（ガントチャート風のざっくりスケジュールを映して）
「最初にこれして、次にあれして…見てください、余裕ないです。というか無理です！」
「最初のこれ何するの」
「これは現状を調査して…」
「ふーん。ところでマイルストーンなに」
「ここでレビューして、ここでアレして。後ろが決まっているので後ろから前に倒すと、ほら、全然無理です」
「無理なスケジュール引いているの。無駄なことしてるね」
「しょうがないじゃないですか（怒」
「でもさ、そのマイルストーン本当に守る必要あるの」
「この会議で承認もらわないと次が」

その作業ナニ？

「そっか。それはそうだね。でもさ、承認もらう内容って完成版じゃないといけないの。その会議にこのテーマで割けるの１−２枚程度の情報量だよ、パワポで」
「でも、翌週に配布予定があるから」
「そっか。会議資料はポイントに絞るとしてもそのあとすぐに完成版が必要なんだ。なるほど。じゃあさ、その完成版の仕様書作るためのどう進めるの」
「現状調査して、並行して技術仕様を調査して…、それでまとめて」
「現状調査って何するの」
「点在する拠点でどんなものを使っているかと、どんな使い方をしているかとかです」
「それ調べて仕様書なるんだよね」

作業の目的ナニ？

「え、ええ」
「ちょっと待って。今の変。おかしい。目次考えていないんじゃないの」
「…」
「仕様書なんだから目次がWBSにならないとまずいんじゃないかな」
「このスケジュールでやる作業全てが仕様書にならないといけないと思うけど。逆に言えば、仕様書に繋がらない作業はしてはいけない。第一、時間の余裕がないんでしょ」
「そうですが」
「その仕様書、要件書けばいいんじゃないの」
「だったらさ、論理モデルを描いて拠点を管理している部署に確認すればいいんじゃないの」

進捗することにリソース割けよ

「でも前工程でそうするって」
「いいよ。忘れて。そんなの間違っているって言えばいいんだよ」
「それまとめた人まだいるから場の雰囲気が悪くなるじゃないですか」
「関係ないじゃん。そんな気遣いして仕様書がキツキツのスケジュールでできるの。できるならいいけど実現性のないスケジュールなんて止めるよ、キツいんじゃなかったの」
「キツいです」
「だったら、実現できるスケジュールを作らないといけないじゃん。仕様書にならない作業をしてもいけないじゃん。やることは仕様を期限に作ることじゃん、どう」
「そうですね。わかってます」
「ほんとぉかなー、わかってるかなー」

どうやって実現するの？

「わかってます、WBSに展開できていますし」
「どれ。細っ。なにこの0.05の工数って」
「これは準備に」
「わかった。じゃあさ、どうやって進めるの」
「スケジュールですか」
「ほら、仕様書に書く項目の内容。それ。一人で好き勝手に書くの」
「いえ、関係者がいるので検討会を開いて決めます」
「どうやって」
「調査して似ているものをグルーピングしてこれでいいかって」
「どのくらい」
「200…くらいでしたっけ」
「け、じゃないよ。それ一人でやるの」
「彼ら工数ないからって」
「そうじゃなくて、叩きはこっちで作るのはそういう仕切りだからいいんだけど、200一人でやるの。死ぬよ。そりゃ終わらないわ」

作業プロセスで考えようよ

「だから、困っているんです」
「そうしたらさ、その進め方が間違っているって気づかないと」
「？」
「作業プロセスが間違っているんだよ、それ」
「？？」
「何回打ち合わせするの」
「別の分科会に入れてもらって」
「だから何回やるの」
「10回くらい…かな」
「それもおかしい。仕様書の目次の分だけ検討テーマがあるのでは。項目が10あるなら10回は必要でしょ。1時間もらえるとして、1テーマ30分なら5回は必要じゃん。開催頻度は…なら何週かかるかわかるじゃん。それカレンダにはめたら間に合うか間に合わないかわかるじゃん」

主体者としてリクエストしよう

「？？？」
「スケジューラ出して。ほら、ここで1回、ここで2回目…ほら。だめだこりゃ」
「だからキッツイって」
「違うよ。こうすればできると考えるんだよ」
「いいかい、この期間に仕様検討ができればいい。でも今の条件なら2倍の開催が必要。開催頻度を守るならスケジュールを伸ばす、守るなら頻度を変える。頻度を変えるとリソースが足らなくなるじゃないのかな。資料準備はこちらだから。でしょ。あ、これ付帯作業もいるね。仕様書ばっかりじゃ足らない。そうすると２倍じゃなくて2.5倍だ」
「作業工数はこのWBSで見積もった規模とほぼ合っていると思います。やっぱりWBSの最初の工数は正しかった」
「その細かさで」
「いえ、これはそこから削って」
「できるスケジュールだっけ」
「いいえ」
「意味のない仕事してどうするの。最初のが正しいならあとで検算で使おうね。でさ、できるスケジュールを実現するために必要なリソースをリソースリクエストするんだよ。もしくはスケジュールを伸ばすのかを選べって」
「…」
「ねえ、わかってないでしょ」
「いいえ」
「これ楽しそうだね。乗っ取っていい」
「それは…」
「こういうのはさ、トップダウンでこうやりますって進め方を決めて、その中で収めるために必要なリソースを要求するんだよ。終わらせたいなら」