【初めてのロードマップづくり 第10回】β版のレビュー会

　こんにちは。クオリティアーツの池田です。ソフトウェアの品質とテストを中心に、ソフトウェアエンジニアリング全般が専門です。コンサルタントとして、組織の伴走支援をしています（自己紹介）（noteホーム）。3年先まで決め切った計画を、褒められると思って持っていく。この日の田口さんがそうでした。

　連載「初めてのロードマップづくり。田口さんの奮闘物語。」の第10回です。連載の趣旨と登場人物、全16回の一覧は、扉記事にまとめてあります。

　前回は、6周目でした。3年目の欄から逆に書くこと、状態とアウトプットで書くこと、兼務前提で検算すること。3年分の欄がひととおり埋まったのが、前回でした。

　2月中旬、β版のレビュー会です。返ってきたのは、思いがけない指摘でした。

この記事のポイント

• 打ち手は仮説。3か月ごとに確かめて、組み直せばいい

• 3年目は方向、2年目は輪郭、1年目は具体。直近6か月は2週間×12コマに区切り、完了の判定を先に決める

• 自分たちの外側に働きかける行は、作っているときに思い浮かばない。他のWG、上への報告、外への発信、現場からの声

1. 場面　β版を部長に見せる

　2月中旬。午後の小会議室は、窓から低い日が差していました。β版のレビュー会です。日程表に「ロードマップβ版レビュー」と書かれていた回で、出席は部長と僕の2人だけでした。

　印刷した図をテーブルに広げます。横に3年分の軸、縦に2段。上が「どうなっているか」（年度末の状態と、その裏付け）、下が「どうやるか」。年度ごとの欄は、状態とアウトプットで書き直してあります。この日の図が、図表1です。上には、1月末に部長へ持っていった2枚を置いてあります。

　部長は、しばらく黙って見ていました。

　「1か月で、ずいぶん進みましたね」

　「ありがとうございます」

　「3年目の欄、読んでて行きたくなりますよ。ここは通ると思います」

　部長は、紙の右のほうに指を置きました。

　「ひとつ聞かせてください。2029年度の欄まで、担当と工数が入ってますよね。これ、今の時点でどのくらい当たると思います？」

　「……正直、あまり自信はないです」

　「ですよね。当たらないものを細かく決めると、どうなります？」

　「直すときに、手間がかかります」

　「そうなんですよ。年末に、アジャイル的な考え方でって話をしましたよね。今の形は、どっちかというと」

　「……ウォーターフォール、ですか」

　「そうですね」

　部長は、眼鏡を外して目のあたりを押さえました。

　「ただ、これ田口さんが悪いわけじゃないんですよ。真面目に作るほど、こうなりやすいので。私も昔、同じもの作りました」

　今度は、下の段を上から読み直しています。

　「もうひとつだけ。この3年目の5行に、下の段からちゃんと線が引けるか、確かめてもらえます？」

　僕は、5行を1つずつ押さえて、下の段を見ていきました。上から4つは、どれも線を引くことができます。5つ目で、手が止まりました。

　「5つ目に向かう打ち手が、1本もないです」

　「気づけたら大丈夫。人の気持ちに関わるものって、打ち手が思いつきにくいんですよね」

　「考えてみます」

　「あ、それと。他のWGの動きって見てます？　レビューの手順あたり、どこかと重なりそうな気がしません？」

　「開発プロセス標準化WGが、規程を作ると聞いています。話していません」

　「一度、話してみるといいかもですね。先に決めておくと、現場が楽なので」

　部長は、手元のメモに何か書き足しました。

　「あと、1月末にお願いした最初の半年、どうなりました？」

　僕は、別紙を出しました。4月から6月、7月から9月の2つに分けて、やることを並べてあります。

　「ちゃんと作ってきましたね」

　別紙を少し持ち上げて見ます。

　「ひとつ確認させてください。WGの場って、月に2回でしたよね」

　「はい」

　「ということは、2週間に1回、何かを見せる場があるわけですよね。そこに3か月先の話を持ってこられたら、私、何て言えばいいですかね」

　「言えることが、ないですね」

　「そうなんですよ。……割り方ですよね、要は」

　「2週間ごと、ですか」

　「ですよね。じゃあ、それで」

　今度は、一覧のほうを指します。

　「それと、これもう一度読んでみてもらえます？　終わったかどうか、誰が判定できます？」

　行を上から読み直しました。期限もなければ、どうなったら終わりなのかも書いていない。

　「判定できないです。やることを並べただけでした」

　「そこが入ると、ぐっと動けるようになりますよ。4月まで、まだ時間はありますので」

2. 田口さんは、ウォーターフォール思考のままだった

　β版レビューで部長が言ったのは、細かさの話でした。

　田口さんの紙は、3年分の打ち手が全部、同じ細かさで並んでいました。2029年度の欄にも担当と工数が入っている。一度決めて、そのとおりに進める形です。

　部長は全体会で「アジャイル的な考え方で進める」と言っていました。田口さんはそれを聞いていたのに、手が動くときはウォーターフォールの形になっていたのです。ここでいうウォーターフォールは、開発モデルの名前そのものではなく、最初に全部を決めて、そのとおりに進める計画の立て方のことです。

　これは責められる話とは違います。3年計画と言われて細かく決め切ろうとするのは、むしろ真面目な反応です。熱心な人ほど、こうなります。

　ただ、3年先は当たりません。計画を守ること自体が目的になり、外れたときに「実行が悪い」と結論しがちになります。

3. 3か月ごとに見直す前提で作る

　仮説として扱うと決めたので、見直しの作法も決まります。

　見直しには、動かすものと動かさないものがあります。

• 原則として動かさない：3年目のToBe（3年後の嬉しい状態）。ここが毎回動くと、積み上げたものが全部やり直しになります。前提が大きく変わって動かすときは、部長と相談して決めます

• 動かす：1年目と2年目の並び、打ち手の中身、打ち手の取捨

　3か月ごとに確かめるのは、次の3点で足ります。

1. その期に出来ているはずだったアウトプットは、出来たか

2. 依存関係は変わっていないか。前提にしていた事情が動いていないか

3. ToBeに効かなくなった打ち手はないか。逆に、要ると分かった打ち手はないか

　見直しの前提があると、初版の作り方も変わります。3年目までの細かい打ち手を、今から全部決めなくてよくなるからです。3年目は方向、2年目は輪郭、1年目は具体。この濃淡で作っておけば、3か月後の見直しが軽く済みます。

　※ 先を粗いままにしておくのは、アジャイルだけの作法ではありません。ローリングウェーブ計画法という昔からの計画技法で、直近の作業だけを細かく分け、先の作業は粗いまま置いておく進め方です。情報処理技術者試験のプロジェクトマネージャ試験にも出ていて、正解の選択肢は「将来実施予定の作業については、上位レベルのWBSにとどめておき、詳細が明確になってから、要素分解して詳細なWBSを作成する」でした（平成29年春期 午前Ⅱ 問4。問題冊子、解答例。解説はプロジェクトマネージャ試験.com）。もとはWBSを作るときの技法で、3年のロードマップに使うのは、その考え方を借りた形です。上の階層に説明するとき、この名前を使うことができます。

4. 計画は仮説。確かめて、組み直す

　言い換えると、こうなります。ロードマップに書いた打ち手は、仮説です。

　「受入基準をレビューする形にすれば、リリース判定の差し戻しが減るはずだ」。これは、やってみるまで分からない見込みです。3か月やって差し戻しが減っていなければ、仮説が外れたということになります。打ち手を変えるか、狙いそのものを見直すか。アジャイル開発でいう仮説検証と、考え方の向きは同じです。

　プロセス改善の世界では、この回転をPDCAと呼んできました。Plan（計画）、Do（実行）、Check（確認）、Act（処置）。

　ここにひとつ補足があります。デミングさん自身は、CheckではなくStudy（調べる）を使ったPDSAを推していました。1990年11月17日のMoenさん宛の書簡に「be sure to call it PDSA, not the corruption PDCA」と書き、1993年の『The New Economics』でPDSAサイクルとして示しています。PDCAのほうは、1951年に日本でデミング・ホイールをもとに組み直されたものです（Ronald Moen, "Foundation and History of the PDSA Cycle"）。

　Studyという語にしたのは、確認して終わりにせず、なぜそうなったのかまで調べるという意味合いです。差し戻しが減らなかったとき、「減らなかった」で止めるか、「なぜ減らなかったのか」まで見るか。3か月ごとの見直しで効いてくるのは、後者です。

　この連載の手順も、計画を並べる前にAsIsを数え、経緯まで調べています。まず現状を確かめてから計画に進む順番です。4月からは直近6か月を実行し、3か月ごとに確かめて組み直す。ここからが、PDCAそのものの回転です。

　呼び方はどれでもかまいません。大事なのは、一度で当てにいかないこと、期の終わりに確かめること、確かめた結果で次を組み直すことです。

5. 直近6か月は、実行できる形まで落とす

　4月に走り出すのですから、最初の6か月は、集まったその日から動ける形にしておきます。

　この部分だけは、年度の欄とは粒度が違います。具体的な活動とアウトプットまで決めます。田口さんが1周目に作ろうとした細かさは、本当はここで使うものでした。

　田口さんが出した別紙は3か月ずつの2分割で、これが粗すぎるというのが部長の指摘でした。粒度は、自分で決めるものというより、確かめる場の間隔で決まるものです。

　WGの活動は隔週と決まっていました。2週間に1回、誰かに何かを見せる機会がある。そこへ3か月先の話を持っていっても相手は何も言うことができませんが、2週間で出来たものを持っていけば、毎回まともな指摘が返ってきます。

　ですので、落とし方はこうなります。

1. 6か月を、確かめる場の間隔で割る。2週間ごとなら12コマ

2. 各コマの終わりに「出来ているもの」を1つ決める。名詞で書く

3. そのアウトプットごとに、担当・期限・完了の判定を決める

4. 合計時間を出し、WGの枠に収まるかを検算する

　3の「完了の判定」が、いちばん抜けます。「ひな型を作る」とだけ書いてあると、下書きができた時点で終わったことにも、レビューを通った時点で終わったことにもできてしまう。誰が何を見てOKと言ったら終わりなのかを、先に決めておきます。

　田口さんの最初の6コマは、こうなりました。

• 第1コマ（4月前半）：他社と社内の事例を集めた調査メモがある。完了の判定は、WG内で読み合わせ済み

• 第2コマ（4月後半）：工数入力に手戻りの区分が追加されている。完了の判定は、実際に1件入力できたこと

• 第3コマ（5月前半）：「手戻り」の判定基準が1枚にまとまっている。完了の判定は、開発プロセス標準化WGに見てもらって異論がないこと

• 第4コマ（5月後半）：先行3チームが決まり、各チームのリーダーに口頭で合意が取れている

• 第5コマ（6月前半）：受入基準書のひな型の初版がある。完了の判定は、先行1チームが自分の開発で書けたこと

• 第6コマ（6月後半）：月次集計が1回は回っている。完了の判定は、集計表がWGの場に出たこと

　もうひとつ、第6コマの直後に置いたものがあります。最初の見直しの場そのものの設計です。

• 7月の見直し（第1四半期の振り返り）：出席は部長・WGメンバー・先行3チームのリーダー。持ち寄るのは、3か月で増えたもの（ひな型・判定基準・集計表）、使った人の声、次の3か月の割り直し案。時間は1時間

　前半の6コマと、7月の見直しの設計を、図表2にまとめました。

　「3か月ごとに見直す」と書いてあっても、誰が出て何を持ち寄るかを決めていなければ、その日は来ません。来ても報告会になります。見直しの場は、打ち手のひとつとして計画に載せておくものです。

　後半の6コマは、ここまで細かくしていません。手前を細かく、奥をざっくり。3か月後の見直しで、後半を割り直すことになるからです。

　どのコマの終わりにも、動く何かが増えている。 部長の資料の言葉でいえばインクリメントです。「検討した」「案を作った」では、増えていません。使われているひな型が1つあるほうが、検討報告書10枚より先に進んでいます。

　2週間で1つも増えないコマがあったら、それは割り方が粗いか、そもそも打ち手が大きすぎます。そこは割り直しです。

6. ロードマップに載せ忘れるもの

　部長が指した2か所は、どちらも書いていないことへの指摘でした。打ち手の一覧を作ると、目の前にあるものだけで埋まります。 自分のWGが、自分たちの手で、自分たちの現場に対してやること。それ以外が落ちます。よく落ちるのは、次の4つです。

• 他のWGとの連携　…　同じ時期に、隣のWGが似たものを作っている。開発プロセス標準化WGのレビュー規程と、こちらのレビュー手順書は重なります。どちらが先に出すのか、どちらに合わせるのかを決めておかないと、現場は2つの手順を受け取ることになります。現場が混乱すると、両方が使われなくなります

• 上への報告　…　3か月ごとの見直しの場に、何を持っていくのか。誰がいつ作るのか。報告の準備も活動のうちで、時間を食います。載せていなければ、毎回だれかの残業で処理されます

• 外への発信　…　社内の他部門への共有、社外への登壇や記事。3年目のToBeに「社外で話す人が出ている」と書いたなら、そこへ至る打ち手が要ります

• 現場からの声を受ける口　…　部長が全体会で「使いにくいところを返してほしい」と言った、その受け口です。誰が、どこで受けて、どう扱うのか。決めていなければ、声は届いても流れていきます

　見つけ方は、レビュー会でやったとおりです。ToBeの項目を1つずつ指で押さえ、下の段にそこへ向かう打ち手があるかを確かめる。1本もない項目が、落ちているところです。

　田口さんの場合は、5つ目のToBe（テストが、やりたい仕事になっている）でした。書き足したのは、次の4本です。

• 社内勉強会を四半期に1回開き、先行チームが自分の試行を話す（2年目から）

• 社外のイベントへの登壇を、2年目に1人、3年目に3人まで増やす

• 若手が書いた試行記録を、部内のポータルに出す（1年目から）

• 案件のアサインに、本人の希望を書く欄を作る（1年目）

　これがないと5つ目のToBeは、3年後に何の裏付けもないまま残ります。最後の1本は打ち手というより器ですが、これがないと「自分から希望する人が毎期いる」を数える方法がありません。

7. 場面　レビュー会の2日後

　レビュー会の2日後の金曜。WGの作業に充てている日です。自席で、3年目の欄から担当と工数を消しました。代わりに、2027年4月からの6か月を別紙に起こします。

　同じ日に、5つ目のToBeに向かう4本に加えて、他のWGとの調整、上への報告の準備、現場からの声を受ける口も足しました。打ち手は18本から25本になっています。それでも1年目の前半は軽くなりました。広げる段を、後ろへずらしたからです。

　使ったのは、1周目に作りかけたExcelの形式でした。

　（これ、あのときの表と同じだ）

　消した分と、足した分。紙の枚数は変わっていません。

　この形で通るか、夕方に中村さんへ持っていこう。そう決めて、ファイルを閉じました。

8. 第10回のまとめ

　β版のレビュー会で手に入ったのは、直し方が3つでした。3年分を均一の細かさで埋め切った紙は、よく出来ているほど直しにくいのです。

　先に行くほど粗くする。3年目は方向、2年目は輪郭、1年目は具体。打ち手は仮説として扱い、3か月ごとに確かめて組み直す。直近6か月は2週間×12コマに区切り、手前のコマから細かく決めて、コマごとに完了の判定を先に決める。

　あわせて、載せ忘れるものも拾いました。他のWGとの連携、上への報告、外への発信、そして現場からの声を受ける口。自分たちの活動の外側に働きかける行は、計画を作っているときに思い浮かびません。

　次回、直した紙を持って7周目に行きます。中村さんが見るのは、埋めた欄ではなく、空いている段のほうでした。

次回予告

　第11回は7周目です。作り直した紙を見た中村さんは、いちばん上の段が空いていると言います。

#ロードマップ #バックキャスティング #ギャップ分析 #プロセス改善 #アジャイル開発 #組織開発 #IT企業

本記事をお読みいただくにあたって

• 出典について　統計・研究・法令につきましては、一次情報で確認のうえ、出典のリンクを本文中に記載しております。ただし、誤りの可能性を完全に排除することはできません。お使いになる際は、リンク先の原典をご確認ください

• 観察と事実の区別について　現場の事例および見立ては、筆者の観察によるものであり、統計ではありません。また、特に明示していない限り、特定の企業・個人を指すものではありません

• 執筆・調査時点について　これらを確認したのは、記事公開の時点です。統計は更新され、法令は改正されますので、現時点の内容とは異なる場合があります

• 生成AIの利用について　本記事は、調査および推敲、図表作成に生成AIを利用しております

• 商標について　本文中に記載されている会社名、製品名、サービス名等は、一般に各社の商標または登録商標です。なお、本文中では ™ および ® の表示を省略しております

• 見解について　本記事の内容は筆者個人の見解であり、筆者が所属または関与する団体・企業の見解を代表するものではありません

• 免責　本記事は、筆者の調査および考察に基づく情報提供を目的としたものです。ご利用にあたっての最終的なご判断は、お読みいただく方ご自身でお願いいたします。本記事の情報を利用されたことにより生じた損害等について、筆者は責任を負いかねますので、あらかじめご了承ください