Act10 一つの解
朝会は重たい雰囲気で始まった。
寝癖だらけの頭のまま、起きているのか寝ているのか分からない目で座っている設計チーム。自分たちだけ休んでしまったことに、なんとなく申しわけない空気を漂わせる製造チーム。見定めてやろうと身構えるように私の対面で腕組みして座る杉野PM。援護してやるから安心しろとでもいう感じで黙って横に座る草薙さん。……そして、私。
アジェンダが周知されずに始まった朝会。しばらく杉野PMが独壇場で話し続ける。大体30分くらいだろうか。
「では早瀬さんに、更新してもらったWBSの説明をしてもらいましょうか」
前ぶれなく不意に話がふられた私は慌てるまでもなく、あらかじめ準備しておいたWBSをプロジェクタに投影する。
「ここに上がっているWBSについては、今後また変更が入る可能性があります。後述する課題管理表に上がっている内容について、まだ盛り込めきれていないことがその理由です」
杉野PMはにらむようにWBSを見ている。今回私が引いたWBSは、もともと杉野PMが引いた線表をベースにしている。同一チームが同時期に複数タスクを進行させる、いわゆる「多重線表」の状態になっている。もちろん、セオリーに照らし合わせれば、ほぼアウト。熟練者が構成しているチームなら可能かもしれないが、正直、新兵に毛が生えたようなこの部隊では絶望的だ。
もともと、この時点でまず勝ち目はない。大きな前提条件（リリース範囲や時期）の変更をしなければ、勝ち目はないのだ。だから、タスクに関しては、あえて大きく修正をしなかった。大幅に変更したのは「進ちょく率」だ。
「提示されている進ちょく凡例が10％、50％、70％、100％でくくられている根拠は？」はぁ？ とでも言わんばかりの表情で杉野PMが私に食ってかかる。
「記載しているとおり、見直し分の基本設計書は10％が着手。50％が記述完了。70％が内部レビュー完了。お客さまレビュー完了で100％としています。製造に関しても、10％が着手。50％が製造完了。70％が単体テスト着手。単体テスト表に記入してテスト完了で100％としました。凡例に記載している各数値の間となる実際の進ちょく率は若干の感覚値も入ることになりますが、どの工程がどこまで完了しているかの把握はしやすくなったと思います。ただ、その結果これまで表記してきた進ちょく率から減ってしまっているタスクもありますが……」しれっと私は答える。
杉野PMはあからさまに不快な顔をしていた。
「いきなり進ちょくが戻ってしまって、お客さまに説明する必要があるよねぇ。説明できるんですか？」
「もちろん説明の必要はあります。ただ、お客さまにもメリットがあることを説明して、ここで管理方法を刷新することに納得していただくしかありません。どの設計書がお客さまレビュー待ちか、どのタスクが工程的に遅れているか、分かりやすくなったと思いますが」
ある意味、「今までの管理は見づらかった・把握しにくかったから、方法を変えますよ」と言っている私のWBSに対して、「今まで俺の管理が悪いからと言いたいのか？」と不満を露わにする杉野PM。お互いの意見の違いが明らかになる中、草薙さんが私に助け船を出した。
「元のWBSで進ちょく率90％で止まっていたタスクですが、同じ90％でも状況が若干異なるということをヒアリングのときにキャッチしました。それで、早瀬には私の方から進ちょく率の数値の意味をチームで定義・共有してはどうか？ とアドバイスしたんです。確かに進ちょくは戻ってしまいますので、お客さまに納得いただけるようにお話しする必要はありますが……。しかし、どの部分にリソースを割り当てなければならないかという観点についてつかみやすくなったので、メリットも十分あるかと思います。いかがでしょう？ 杉野PM」
杉野PMは少しだけ間を置いた。彼もPMだ。今のリソースでは足りないことを彼も理解できているのだろう。だからこそ、彼は草薙さんのいうメリットが理解できたのだろう。現在の進ちょくを直感的に見えやすくすることによって、現状が明らかなリソース不足であることをお客さまに訴えられる。プライドや感情と、プロジェクト完遂の可能性。彼はそれを両天秤にかけて、短い2～3秒の間に選択した。
「そういうことであれば了解です。その旨を、午後のお客さまとの顔合わせの際に説明してください」
ありがとうございます、と私は軽く頭を下げた後、今度はQA票と課題管理票について説明し始める。
「昨日、メールや議事録に書いてあった質疑応答については、QA票に集約し、記載しました。また、棚上げになっている各種課題についても、課題管理票に記載しました。今後、チームの皆さんはお手数ですが、質問はQA票に……課題については課題管理票に、それぞれ記載をお願いします。情報を一元化することによって、連携がスムーズになると思います」
プロジェクタで投影したQA表のいくつかを見て、杉野PMは指摘を入れる。
「No.13の道路幅については、その仕様は今組み込んでますね。テーブルも修正してあるから問題ない。単なる設計書のミスですよ」
彼からの指摘点をプロジェクトペーパーにメモを取りながら、私は問いかける。
「分かりました。ああ、そのお話ですが、メールや議事録に書いてありましたでしょうか」
「んー、多分書いてあると思いますけどねぇ。まあ、アジャイル的な感じですので、書いてないかもしれませんけど」
悪びれもせず、杉野PMは言い放った。アジャイルと名前が付けば、ドキュメントは作らなくていいのか？ お客さまとの合意した内容についてのドキュメントは、必要最低限のものだろう。手戻りは手痛いはずなのに。それに言った言わないのけんかほど、時間を無駄にするものはないはずなのに。
だが、ここでは彼を追い詰めない。追い詰めたところでそれは相手の感情を逆なでしてしまうだけだから。私が熱くなったら、負け。
「それではNo.13については今の回答をQA票に記載しておきます。お手数ですが、杉野PM、全体的な内容の確認をお願いします。各種資料の場所やWBSのルール。QA票・課題管理票のルールについては、後でまとめてメールしておきます。私からは以上です」
「あ、私から１つ、よろしいでしょうか？」私と杉野PMのやり取りを黙って聞いていた草薙さんが穏やかな口調で提案する。
「この先、仕様変更の依頼についてもきちんと変更管理一覧に残すことにしたいと思います。おそらくこの後、プロジェクトを無事着地させるには追加要員が必要になります。その際、変更管理一覧についても残しておくことによって、新規メンバーが設計チームや杉野PMのお時間を取ることも低減できるハズです。変更内容を軽くメールで伝えていただければ、変更管理一覧はこちらで作りますよ。いかがでしょう？」
私がすっかり言い忘れていた変更管理についても、きちんとまとめようという提言だ。うまい言い方だと内心、草薙さんの言葉の選び方に舌を巻く。「あんたにも変更一覧はメリットがあるんだ。あんた、暇じゃないんだろ？」という言葉を隠しつつ、やりたいことを飲ませようとしている。
「……了解しました。それでは、ひな形を作ってあとでメールで全体周知してください」妙に素直に杉野PMはそれを聞き入れた。
ほどなくして、朝会は終わった。きびきびと杉野PMは足早に会議室から出て行った。他の皆はほとんどが1日休んだとはいえ、疲れているんだろう。緩慢な動きでプロジェクトルームに戻っていく。草薙さんは「お疲れさん」と小さく私に声をかけて喫煙所に向かっていく。
「ちょっと熱くなってたわね、私……」と心でつぶやきながら、私は会議室PCの電源を落とす。そして、電源が切れるまでの間、今さっきのことをじっと考える。
朝会の前、喫煙所で草薙さんが言っていた言葉。
【ここまで明らかに、要件がきちんと詰められていないのは何故だろう】
要因はいくつかあるが、その要因の1つが判明した。変更された仕様は、空中戦によって決められたことだったからだ。だから、思いつきで決まる。そして、それが煮詰められることはない。ついでに、決まる場所は会議室だけではなさそうだと思って間違いない。
「取りこぼしている仕様がどのくらいあるのか、まだまだ分からないわね……」
この現場にきて3日目になるのか。窓の外のうるさい蝉の声を聴きながら、私は席を立って化粧室に足を向けた。