【初めてのロードマップづくり 第9回】それ、やることリストだよね

　こんにちは。クオリティアーツの池田です。ソフトウェアの品質とテストを中心に、ソフトウェアエンジニアリング全般が専門です。コンサルタントとして、組織の伴走支援をしています（自己紹介）（noteホーム）。年度の欄がやることリストになってしまう。改善の計画が止まる、よくある行き止まりです。

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

　前回は、5周目でした。ギャップはまだ存在しないアウトプットのこと、人・仕組み・道具・情報の4つに切り分けること、初めてのことには段取りが要ること。前回はこの3つでした。

　今回は、中村さんへの壁打ち6周目です。ギャップを年度の欄に並べます。3年目の欄から、逆に。あわせて、ここまで何度も出てきた「状態」という言葉の意味を、田口さんが自分の言葉でつかみます。

この記事のポイント

• 年度の欄は、3年目から先に書く。1年目から書くと、また積み上げに戻る

• 状態とは、ある時点で時間を止めて見たときに「ある」もの。作業には時間の幅があり、終われば消える

• ToBeに効かない打ち手は、良いものでも別の紙に取っておく。残した分を、兼務前提で検算する

1. 場面　6周目

　年度に割り振る作業は、本業の合間に少しずつ進めて、金曜の午前にようやく形になりました。

　手をつけやすい順に並べると1年目が溢れ、均すと2年目と3年目がすかすかになる。

　（これ、たぶん並べる順番が違うんだろうな）

　6周目の金曜。朝から会議が3つあって、頭が切り替わらないまま夕方になりました。部長に見せるβ版のレビュー会は、来週です。年度ごとに打ち手を割り振った表を持っていきます。その表が、図表1です。

　中村さんの席で、表を渡しました。

　「年度に割り振ってみました」

　中村さんは、表をざっと見て、眼鏡を少し上げました。

　「これ、途中から1年目に降りたね」

　「はい。3年目から書き始めたんですが、2年目のあたりで分からなくなって。結局、手をつけやすい順に並べ直しました。そこは自分でも気持ち悪かったです」

　中村さんは、3年目の欄を指さします。

　「ここ、声に出して読んでみて」

　「えっと、『全チームへ展開する』『レビュー手順書を改訂する』『分析を定着させる』……」

　「読んでみて、どう思った？」

　僕は、自分の欄をもう一度見ました。3年目も2年目も1年目も、全部が「〜する」で終わっています。

　「……やることリストです。3年後にどうなってるかが、書いてないです」

　「うん。それ、やることリストだよね」

　「状態で書く、でしたね」

　そこで、ひと月前から引っかかっていたことを聞いてみました。

　「中村さん。僕、そもそも状態というのがまだよく分かっていないみたいです。『されている』にすれば状態だと思って、また同じことをやっています」

　中村さんは、ペンを置きました。

　「じゃあ聞くけど。田口さん、今日この部屋に入ってきたとき、何が『ある』と思った？」

　「えっと、机と、椅子と、中村さんと」

　「そう。それ、全部そのとき『あった』ものでしょ。作業は？」

　「作業は、見えないです。やってる途中なら見えますけど、終わったら残らない」

　「うん。で、終わったあとに何が残る？」

　「……結果、ですかね。作られたものとか、変わったあとの様子とか」

　言いながら、1周目の帰りぎわに中村さんが言った「3年後の写真」の話と、頭のなかでつながりました。

　「状態って……ある時点で止めて見たときに、そこに『ある』もの、ですか。作業は、時間の幅があるけど。状態は、一点で見える」

　「俺はそう思ってる」

　「あ。だから『展開する』は書けなくて、『14チームで使われている』なら書ける」

　「そう。あと、それ、来年も再来年も同じ質問ができるでしょ」

　「使われてるか、使われてないか」

　「うん。やることは1回で終わるけど、状態は毎年確かめられる」

　「ああ、そういうことか」

　声に出してしまいました。ひと月ひっかかっていたものが、ようやく落ちた感じでした。

　「今晩やり直します。たぶん、全部書き換えになります」

　「たぶん、違うのが出るよ」

　中村さんは、1年目の欄を指でたどりました。

　「それと、1年目にこれだけ入ってるけど。WG、田口さん入れて6人だよね」

　「はい。メンバー5人はまだ候補ですけど」

　「みんな本業あるでしょ。週に何時間、WGに使えると思う？」

　「……考えてませんでした」

　「先に枠を決めてから中身を入れると、どうなる？」

　「入らないものが、出ますね」

　その日の帰り道、電車のなかで考えていました。

　（枠を先に決めてから、中身か）

2. 3年目の欄から書く

　ここでようやく、年度に並べます。書く向きは、1年目からではなく、3年目からです。

　2029年度末の状態が成り立っているには、その1年前に何が出来ていればよいか。2028年度末が成り立っているには、その1年前に何が。この問いを3回くり返して、2029年度末から2027年度末へさかのぼります。たとえば3年目が「14チームすべてで使われている」なら、2年目末には「7チームで使えていて、残り7チームに渡す型と説明の材料がある」が要る。さらにその1年前には「3チームで試して、直した跡が残っている」。この3段が、そのまま年度の欄になります。年度ごとの中身は、第5節の図表2にまとめました。

　0年目（2026年度の残り、2027年1〜3月）：ToBeとAsIsの2つの文書と、WGの立ち上げ。ここが今です。

3. そもそも「状態」とは何か

　「状態で書く」は、この連載でくり返し出てくる言い方です。ただ、言われた側がいちばん困るのも、たぶんここです。田口さんが6周目に自分でたどり着いた言い方を、書いておきます。

　状態とは、ある時点で時間を止めて見たときに、そこに「ある」もののことです。

　作業には時間の幅があります。「展開する」は、終わった瞬間に消えます。3年後の金曜の夕方に部を見回しても、どこにも見当たりません。状態には幅がありません。「14チームが同じ手順でレビューしている」は、その日に見れば、成り立っているかどうかが分かります。

　この違いから、3つのことが出てきます。

　ひとつめ。状態は、何度でも確かめることができます。 作業は1回終わったらそれきりですが、状態は1年後も2年後も同じ問いを立てることができます。「使われているか、使われていないか」。3か月ごとに見直す計画を作るなら、毎回読み返す欄でなければ、使い道がありません。

　ふたつめ。状態は、人の手を離れても残ります。 「誰々がやった」ではなく「そうなっている」なので、担当が代わっても意味が変わらない。第6回で調べた「5年前の活動が推進役の異動で止まった」という話は、裏返すと、状態として書かれたものが残っていなかったということでもあります。

　みっつめ。状態は、そのままでは判定できないことがあります。 「品質への意識が高まっている」は、文の形こそ状態ですが、時間を止めて見ても、それが成り立っているかどうか分かりません。だから第5回で扱った裏付けのアウトプットが要ります。状態は時点を指し、アウトプットはその時点に残っている現物を指す。 この2つで1組です。

　言い換えると、こうなります。

• 作業　…　時間の幅がある。終わると消える。「展開する」「手順書を作る」

• 状態　…　時点で見える。あとから何度でも確かめられる。「14チームで使われている」

• アウトプット　…　その時点に現物として残っているもの。「7チーム分の運用記録」

　ロードマップの上の段、年度末の姿を書く欄に入るのは、真ん中と下です。いちばん上の作業は、上の段には書きません。下の段に打ち手として名前だけを置き、その中身を作れる大きさまで分けるのはWBSの仕事になります。

4. 状態で書けているかを見分ける

　各年度の欄に入れるのは、打ち手の名前ではなく、その年度末にどうなっているかと、そのとき存在しているアウトプットです。

• タスクで書いた欄：全チームへ展開する／レビュー手順書を改訂する／分析を定着させる

• 状態で書いた欄：14チームすべてがリリース週も定時で帰れている（時間外記録、判定議事録）

　違いは、読んだ人に判定できるかどうかです。年度の欄は、読んだ人が「出来ている」「出来ていない」を判定できる形で書く。 言われれば分かるのに、書いていると崩れます。

　その場で見分ける方法は、4つあります。

　見分け方1　文末を見る。

　いちばん単純な方法です。「〜する」「〜を導入」「〜を実施」で終わっている欄は、作業。「〜になっている」「〜が残っている」「〜で回っている」で終わっていれば、状態です。

　ただし、これだけだと化粧ができてしまいます。「テスト自動化を導入する」を「テスト自動化が導入されている」に書き換えても、中身は同じです。

　見分け方2　「誰が見て、そうだと分かるか」を聞く。

　「テスト自動化が導入されている」。これを誰がどう見て判定するのか。答えられないなら、まだ作業のままです。「先行3チームの回帰テストが、毎晩自動で流れていて、朝に結果の一覧が出ている」なら、見れば分かります。

　見分け方3　来年の同じ時期に、この欄をそのまま読めるか。

　「導入する」は、導入したら読む意味が無くなります。「回っているか、回っていないか」なら、1年後も同じ問いが立ちます。

　見分け方4　その欄が達成されなかったとき、何が言えるか。

　作業で書いた欄は、「やりました」か「やっていません」と言うほかありません。状態で書いた欄なら、「ここまでは出来ていて、ここが出来ていない」と報告できます。3か月ごとの見直しに耐えるのは、後者だけです。

　崩れ方には、もう1つあります。状態で書いたつもりが、努力目標になっている場合です。「品質への意識が根づいている」「改善が文化になっている」。文末は状態ですが、判定できません。第5回で扱った「裏付けのアウトプット」を、この欄でももう一度当ててみる。誰の手元に、いつ、何が残るのか。

　田口さんが2年目の欄を書き直したのは、この問いを自分に当てたあとでした。

5. 最短でたどり着く道を選ぶ

　もうひとつ、5周目の最後に出た問いがあります。これ、全部やる必要があるのか、というものです。

　ギャップから出した打ち手を、全部やる必要はないのです。ロードマップは、やりたいことの一覧ではなく、ToBeに最短で届く道です。

　田口さんは、段を足した23本の打ち手を、3つに分けました。

• 3年後の状態に直接効くもの：載せる

• それを支えるために先に要るもの：載せる（依存関係の手前側）

• あったら良いが、3年後の5行に効かないもの：落とす

　3つ目に入ったのは、テスト技法の社内資格制度や、ツールの新機能の全面展開など5本でした。どれも、いつかやりたい話です。ただ、3年後の5行には直接は効かない。23本のうちこの5本を取っておくことにして、18本にしました。

　取っておく5本は、別の紙に移しました。3年後、次のロードマップを作るときの材料になります。

　落とす、と決めるより、取っておく、と決めるほうが手が動きます。

　順番を決めるのは、やりたい順ではなく依存関係です。手戻りの減り方を語るには、基準年のデータが要る。つまり初年度の最優先は、区分と判定基準と月次集計です。派手さはありませんが、これを2年目に回すと、3年目に評価ができません。逆算とは、この依存関係を表に出すことです。

　6周目の時点で出来上がった一枚が、図表2です。

　図の中身を、文字でも抜き出しておきます。6周目の時点の、田口さんの一枚です。年度ごとに、年度末の状態とその裏付け、その年度に動かす打ち手を並べてあります。

• 2029年度（3年目）

  • └ 状態：14チームすべてがリリース週も定時で帰れている。レビューの主催者名に20人が並び、その半分が入社5年目までの若手

  • └ 裏付け：リリース週の時間外記録、判定会の議事録、レビューの記録

  • └ 打ち手：残りの7チームへ広げる。観点表の改訂を、現場の手で回す

• 2028年度（2年目）

  • └ 状態：7チームで追い込みが消えている。集まれない人がいても回る非同期の型がある。手戻り工数のデータが2年分たまっている

  • └ 裏付け：手戻り工数の月次集計（2年分）、非同期レビューの運用記録

  • └ 打ち手：次の4チームに入れる。レビューを主催できる人を育てる

• 2027年度（1年目）

  • └ 状態：3チームで先行。リリース週の時間外と判定会の差し戻しを毎月集計している。受入基準書のひな型とレビュー手順書の初版がある。工数入力に手戻りの区分がある

  • └ 裏付け：月次の集計表、ひな型と手順書の初版

  • └ 打ち手：手戻りの区分と月次集計を始める。受入基準書のひな型を先行3チームで試す。レビュー手順書の初版を作る

• 取っておく5本（別紙）：テスト技法の社内資格制度、ツールの新機能の全面展開など

　状態と裏付けは「その年度の終わりに見に行けば、あるかないかが分かるもの」、打ち手は「そのために、その年度に手を動かすもの」です。

6. 「それ、本当に出来るの？」兼務前提で検算する

　改善プロジェクトのWGは、たいてい専任ではありません。メンバーは開発の仕事を抱えたまま、その合間に集まります。ここを見ないまま年度に割り振ると、紙の上では完璧で、実際には1年目から破綻する計画ができます。

　検算のしかたは単純です。先に枠を決めて、中身を入れます。 中身を決めてから必要な時間を足し上げるのとは、順番が逆です。

　※ この「先に枠を決める」やり方を、タイムボックスと呼びます。アジャイル開発では、2週間なら2週間と先に決めて、その中に入る分だけをやると決める。同じ考え方を、年度の割り振りにも使うことができます。

1. 1人あたり週に何時間をWGに使えるかを決める。控えめに見積もる

2. 人数を掛けて、その期に使える総時間を出す

3. 打ち手ごとに必要な時間を粗く見積もる。学ぶと試すの時間も入れる

4. 合計が枠を超えたら、打ち手を減らすか、期をずらす

　田口さんの場合はこうなりました。主査の自分は、部長が週1日を認めてくれているので週8時間。メンバー5人は、本業があるので控えめに週4時間ずつ。合わせて週28時間です。1年目の前半（4月から9月）は26週あるので、枠は約730時間になります。

　※ 主査の分だけ多いのは、部長が全体会で時間を出すと言っていたからです（第1回）。主査の週8時間は、枠全体の3割近くを占めます。 ここを会社として出してもらうことができるかで、計画に入る量が変わります。 兼務の活動を任されたら、まず時間の手当てを確認してください。なお、9月の試行の週はメンバーも8時間ほどに増えますが、その分は前後の週を軽くして、半年の合計では均す前提です。

　最初に見積もった打ち手の合計は700時間ほどで、ぎりぎり収まっていました。ところが、学ぶと試すの時間を足し直すと1,200時間を超えます。1.7倍です。

　ここで気をつけてほしいのが、減らし方です。

　減らすのは、依存関係の後ろ側からです。手前側、つまり道具と情報を削ると、後ろに並べたものが全部動かなくなります。分類の欄がないまま集計の担当だけ決めても、集計するものが出てきません。

　田口さんは、1年目の前半から「広げる」の打ち手をすべて後ろへずらしました。残したのは、学ぶ、試す、そして道具と情報を作る打ち手だけです。730時間の枠に対して、580時間になりました。

　※ 見積もりは外れます。外れる前提で、枠の8割くらいに収めておくと、3か月後の見直しが楽になります。

　枠の作り方と、入れた量の変わり方を、図表3にまとめました。

7. ここでWBSの出番が来る

　年度ごとに「どうなっているか」が決まりました。ここまでがロードマップの仕事です。

　そのあと、1年目の欄をもう一段ほぐします。1年目の終わりに存在しているアウトプットを並べて、それぞれを作れる大きさまで分けていく。観点表のひな型、3チーム分の運用記録、判定の基準。作るものの側から分けていくので、これが本来のWBSの形です（第3回の3-1）。

　田口さんが1周目に持っていった紙とは、ここが違います。あれは、今やれることを下から積み上げた作業計画書でした。向きが逆だっただけでなく、分ける対象そのものが、作業と成果物で違っていたわけです。

　つまり2つは競合しません。役割が違います。

• ロードマップ：3年分。年度末ごとに、どうなっていて何が存在しているかを示す

• WBS：直近の実行分。その期の到達点にある成果物を、作れる大きさまで分ける

　ロードマップを先に作り、そこからWBSを起こす。逆はできません。どちらも行き先から逆に分けていく道具なので、順番さえ守れば自然につながります。 行き先のないWBSは、今できることの寄せ集めになります。

8. 場面　6周目のあと

　週末に書き直して、月曜の朝、もう一度持っていきました。

　中村さんは、表をひととおり見てから言いました。

　「ごめん、もう一回見せて」

　中村さんは表を引き寄せて、二度目は指でなぞりながら読みました。

　「かなり良くなった」

　「あとは図にしようと思っています。今週、部長に出すので」

　僕は、手書きの下書きを出しました。横軸に3年分。表のままより、こちらのほうが伝わる気がしています。

　「いいと思う。あと、最初の半年は？」

　「そこも部長から言われています。別紙で細かく出します」

　「うん。そこまでやって、ようやく渡せる紙になる」

　「行ってきます」

9. 第9回のまとめ

　6周目で、3年分の欄が埋まりました。

　埋め方の順番は、3年目から。1年目から書くと、また積み上げに戻ります。

　この回でようやく、「状態」の意味がはっきりしました。ある時点で時間を止めて見たときに、そこに「ある」もの。作業は幅を持っていて、終われば消えます。状態は一点で見える。だから1年後も2年後も、同じ問いを立てることができます。3か月ごとに見直す計画に状態の欄が要るのは、そのためです。

　書けているかどうかは、4つで確かめることができます。文末はどうか。誰が見て分かるか。来年も読める欄か。達成されなかったとき、何が言えるか。

　打ち手は出し切ったあとで、最短の道に絞る。ToBeに効かない打ち手は、良い施策でも落とす。依存関係が順番を決めて、兼務前提の工数検算が量を決めます。専任0人の計画に、専任前提の量を並べない。

　ここまで来て初めて、WBSの出番が来ます。行き先が決まったので、作るものを分解できるようになったわけです。田口さんが1周目に持っていったのは、早すぎた道具というより、別の道具でした。作業を積み上げる紙と、成果物を分けていく紙は、見た目が似ていても出発点が違います。

　次回、田口さんはこの3年分を部長に見せます。手応えは、ありました。

次回予告

　第10回はβ版のレビュー会です。部長に見せた3年分の計画に、思いがけない指摘が返ってきます。

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

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

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

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

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

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

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

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

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