【初めてのロードマップづくり 第5回】それ、どうやって確かめるの？

　こんにちは。クオリティアーツの池田です。ソフトウェアの品質とテストを中心に、ソフトウェアエンジニアリング全般が専門です。コンサルタントとして、組織の伴走支援をしています（自己紹介）（noteホーム）。在りたい姿が、願望のまま止まってしまう。ここで計画の寿命が決まります。

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

　前回は、2周目でした。田口さんが最初に書いた3年後は、今の延長でした。ToBeは今より嬉しい世界を描くこと、目標は高くてよいこと、ひとつ上のToBeにぶら下げること。この3つが前回の中身でした。

　中村さんへの壁打ち、3周目です。嬉しい世界は、ひとまず書くことができました。では、それが実現したとどうやって確かめるのか。裏付けとなるアウトプットの話をします。

この記事のポイント

• 嬉しい状態には、たいていそれを裏付けるアウトプットがある。書けない行は、代わりに何で確かめるかを決める

• 状態には「できるようになっている」も入る。獲得した力は、人・型・仕組み・資産のどれかに現れる

• アウトプットは大小を問わず全部挙げる。数字だけに寄せると、数字を作る仕事に化ける

1. 場面　3周目

　金曜の一日と、本業の合間の時間を使って書き直しました。「残業が消えている」と書いては消し、また書く。会社に出す計画の言葉としては軽すぎる気がして、何度も手が止まります。

　最後は開き直って、そのまま残しました。

　（違うと言われたら、そのとき直せばいい）

　次の週の金曜。外はもう暗くなっています。部長に見せるβ版のレビュー会まで、あと4週間。僕は、書き直した5行を持っていきました。図表1が、その紙です。

　「5行になりました。今度は、嬉しいほうで書いてみました」

　中村さんは紙を受け取り、今度は声に出して読みました。めずらしく、両手で持っています。

　「いいね。こういうのが読みたかった」

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

　「で、ひとつ聞くけど。それ、どうやって確かめるの？ 3年後、これが本当になってるかどうかは、誰がどうやって判定する？」

　「……僕が見れば、分かると思います」

　「3年後、田口さんはこの部にいる？」

　「分からないです」

　「俺もいないかもね」

　中村さんは、天井のほうを見て笑いました。

　僕は、しばらく黙りました。

　「次の人が見て判定できないと、書いただけになりますね」

　「じゃあ、その人は何を見る？」

　「記録、でしょうか。あとは、文書とか、データとか」

　「それ、この5行の下に書いてある？」

　紙を見ました。5行の下は、白いままです。

　「空いてます」

　中村さんは紙を裏返して、白い面を上にしました。

　「じゃあ、思いつくかぎり書き出してみて。3年後に残ってるもの」

　僕は、記録、文書、データ、と3つ書きました。そこで手が止まります。

　「アウトプットって、それだけ？」

　「ほかにも、ありますか」

　「小さいのから大きいのまで、いろいろあるよね。WGで俺たちが書くもの、考えてみて。議事録、検討のメモ、テンプレート。あとは報告の類。セミナー行ったら参加報告書くだろ」

　「たしかに。全部アウトプットですね」

　「小さくても、整ってなくても、全部書いといて。成果だと思ってないと、そういうのは消えるから。実際、消えたし」

　紙の白い面を埋めていくと、思っていたより多く出てきました。

　中村さんは、マグカップを置きました。

　「そういえば。3年後、田口さんたちは何ができるようになってる？」

　「……できるように、ですか」

　「今は外の人に頼んでることが、自分たちでできてる。それも状態だよね。で、それを確かめるものは何？」

　僕は、また黙りました。

2. 嬉しい状態には、裏付けのアウトプットがある

　嬉しい世界が書けたら、次の一段が要ります。

　その嬉しい状態が本当に成立しているなら、それを裏付けるアウトプットが、どこかに残っているはずです。文書、記録、データ、動いている仕組み。形は何でもかまいません。

　「リリース前の追い込みがなくなっている」なら、何が存在しているか。リリース週の時間外の記録が残っていて、そこに低い数字が並んでいる。リリース判定の議事録があって、差し戻しがゼロになっている。この2つです。

　ToBeを1行書いたら、その下に「裏付けとなるアウトプット」の行を足す。 これを1組と考えます。足せない行は、まだ願望のままです。

　順番だけは、取り違えないようにしたいところです。先に嬉しい状態、あとからアウトプット。逆にすると、また現状の延長に戻ってしまいます。

　※ どうしても現物が思いつかない行もあります。そのときは、代わりに何で確かめるかを決めておけば、いったんは進めてかまいません。 「テストがやりたい仕事になっている」を直接示す文書はありませんが、アサイン希望の件数なら数えることができます。代理の指標だと分かって使う分には、それでかまいません。

　整理すると、ToBeの1項目には3つが要ります。

• 主語：誰が、どの範囲でそうなっているのか

• 時点：いつの姿なのか

• 現物：その状態を裏付ける文書・記録・データは何か。誰がいつ確かめるのか

　3点そろえると、長くなります。格好は悪い。ただ、標語のように短い目標は、読む人ごとに別の意味で受け取られます。

3. 状態には「できるようになっている」も入る

　ここで、状態の書き方をもうひとつ足しておきます。

　ToBeを書くとき、多くの人は「困っていることが無くなっている状態」を書きがちです。残業が消えている、手戻りが減っている。減る方向です。前回、嬉しさの型を6つ挙げたなかの「減る嬉しさ」にあたります。

　もうひとつの軸が、3年後に組織として何ができるようになっているかです。前回の型で言えば「出来るようになる嬉しさ」、獲得する力のほうです。ケイパビリティと呼ばれることもあります。

• 今は社外の方に見てもらっているテスト設計のレビューを、自分たちで回せるようになっている

• 新しい案件が入ったとき、テスト計画の骨組みを2日で組めるようになっている

• 若手が入ってきたとき、3か月で独り立ちさせられるようになっている

　減る方向の状態だけを並べると、3年かけて少し楽になった組織になります。できるようになる状態が入ると、次の3年に使える力が残ります。どちらか一方ではなく、両方を混ぜておきたいところです。

　獲得した力も状態ですから、やはり裏付けのアウトプットが要ります。ここは形がだいたい決まっていて、次の4つのどれかに現れます。

• 人　…　それができる人が何人いるか。担当した記録、教えた記録、認定や有資格者の名簿

• 型　…　標準、手順書、テンプレート、チェックリスト、観点表。改訂の履歴つきで残す

• 仕組み　…　動いている環境、自動化された流れ、いつでも見られるダッシュボード

• 資産　…　再利用できる設計やテストのかたまり、過去の事例集

　「できるようになっている」と書いたとき、この4つのどれにも現れないのであれば、その力はまだ誰か個人の頭の中にとどまっているということです。人が異動すれば、一緒に出ていきます。

　※ 型と仕組みに移し替えるところまで書いておくと、3年目に残ります。第6回で田口さんが話を聞きに行く5年前の活動は、ここが人だけで終わった例です。

4. アウトプットの探し方。4つの問いを当てる

　嬉しい状態は書けているのに、裏付けの現物が思い浮かばない。そういうときは、4つの問いを順に当ててみます。

　問い1　その状態のとき、誰の手元に何が残っていますか。

　嬉しい状態が本当に実現しているなら、たいてい何かが残っています。設計書、テスト計画、ダッシュボードの画面、レビューの記録、受講の記録、顧客からのメール。残るものが何ひとつ思い浮かばないなら、その状態はまだ頭の中だけにあります。

　問い2　その状態のとき、今までと違う会話が起きていますか。

　状態が変わると、交わされる言葉が変わります。「リリース前夜に総出で確認しなくてよくなっている」のなら、リリース前日の夕方にSlackで飛び交う確認の依頼が、無くなっているはずです。変わった会話は、議事録やチャットやチケットに痕跡を残します。

　問い3　それを外の人に見せるとしたら、何を見せますか。

　監査でも、他部署への紹介でも、採用の説明会でもかまいません。「うちはこうなっています」と説明するときに画面に映すもの。それが、そのまま裏付けのアウトプットになります。見せるものが無いなら、外から見て変わっていないということです。

　問い4　それが出来ていないとき、何が起きますか。

　逆から攻める問いです。出来ていないときに起きることが書けるなら、その裏返しが判定条件になります。「テスト設計が属人化したままだと、担当者が休んだ週にテストが止まる」。では、止まらないことを確かめる現物は何か。誰が見ても同じテストが実行できる資産、ということになります。

　4つのうち、どれかひとつでも答えが出れば足がかりになります。4つとも答えが出ない行は、この時点ではまだ願望のままです。 書き直すか、いったん別紙に移して、実現の道が見えてから拾い直すことになります。

5. 思いつかないときの逃げ道と、その危うさ

　裏付けが思いつかないとき、逃げ道がいくつかあります。どれも、その場では紙が埋まる。ただ、あとで効いてきます。

　逃げ道1　「〜が向上している」で止める。

　「テスト品質が向上している」「開発者の意識が高まっている」。もっともらしく読めますが、向上したかどうかを誰も判定できません。3年後の見直しで「これ、達成したんですかね」と聞かれて、全員が黙ることになります。

　逃げ道2　アンケートの満足度に頼る。

　「開発者アンケートで満足度80%」。数えられるので、一見すると裏付けの形をしています。ただ、満足度は聞き方と聞く時期で動きます。それに、満足度が上がったからといって、手戻りが減っているとは限りません。補助の指標としては有効ですが、これ一本に寄せると、アンケートの文面を工夫する仕事になっていきます。

　逃げ道3　実施回数を裏付けにする。

　「レビュー会を年12回実施」「研修を全員受講」。これは数えることができますし、証拠も残ります。ただし数えているのは活動量であって、状態そのものではないのです。12回やったが何も変わらなかった、ということは十分に起こります。第1回で部長が「単なる勉強の集まりにしないでほしい」と言っていたのは、ここのことです。

　逃げ道4　数字だけを置く。

　「不具合の流出を半分に」。数字は明確です。ところが数字だけを置くと、数字を作る方向に力が働きます。流出の定義を狭める、報告の基準を変える、集計の対象から外す。悪意がなくても、そちらに寄っていきます。

　では、どうするか。

　数字と現物を、セットで置くことです。 「不具合の流出が半減している」だけでなく、「その判定に使う月次の集計表が、定義つきで残っている」まで書く。定義が紙に残っていれば、定義をいじったときに分かります。

　実施回数も、単独ではなく状態とセットなら意味を持ちます。「レビュー会を12回」ではなく、「レビュー会で出た指摘が設計標準に反映され、その改訂履歴が残っている」。回数ではなく、回したことで何が変わったかのほうを書く。

　ここを逃げた行は、3年間ずっと、どう判定するかを議論し続けることになります。

6. アウトプットは、小さいものも数える

　ToBeの裏付けとして書くのは、3年後に残っている大きめの現物です。集計表、標準、記録。ただ、WGが3年のあいだに生み出すものは、それだけではありません。

　1章で中村さんが挙げたような、議事録から参加報告までです。どれも、単体では小さいものです。ただ、小さくても、整っていなくても、WGの成果です。

　改善のプロジェクトは、効果が出るまでに時間がかかります。半年やって「で、何が良くなったの」と言われたとき、積み上がった小さいアウトプットの一覧が、そのまま活動の跡になります。

　だから、ロードマップの段階でアウトプットの置き場所と名前の付け方を先に決めておきます。決めておかないと、各人の手元に散ります。散ったものは、3年目には無いのと同じです。

　※ 大きい現物だけを一覧にして、小さいものを作業の副産物として外すやり方もあります。整理はしやすいのですが、外したものは残らないので、この連載では全部挙げる側に寄せています。

7. 出来上がったToBe

　舞台は、業務システムのパッケージ製品を作る会社の開発部門。14チーム、約120人。田口さんはテスト品質強化WGの主査として、2027年度から2029年度までのロードマップを一人で作っています。すべて架空の設定です（扉の4章）。

　田口さんが一人で仕上げた、テスト品質強化WGとしてのToBe（2029年度末）は、次の5つになりました。部のToBeではありません。 部の3年後のうち、このWGが受け持つ分です。

• リリース前の追い込みがなくなっている。14チームすべてが、リリース週も定時で帰れている

• └ 裏付け：リリース週の時間外記録（チーム別、月次）と、リリース判定の議事録（差し戻し件数）

• 平日の夜と休日が、自分のものになっている。リリース週の時間外が、平常週と同じ水準まで下がっている。リリースのある月でも、有給休暇の取得率が他の月と変わらない

• └ 裏付け：勤怠の月次集計（リリース週で切り出したもの）と、有給休暇の取得率（月別。リリース月とそれ以外の比較つき）

• 担当者が休んでも、テストが止まらない。どの案件も、テスト設計を任せられる人が3人以上いて、同じ標準と観点表で回している

• └ 裏付け：テスト設計の標準と観点表（改訂履歴つき）と、案件ごとに設計を担える人が何人いるかの点検記録（半期ごと）

• 手戻りに使っていた時間が、新しい挑戦に回っている。テスト起因の手戻り（不具合の出戻りと再テスト）が半分に減り、浮いた分の行き先が「新しい仕事」「スキルへの投資」「ゆとり」の3つに分けて記録されている。14チームすべてが、年に1件以上、テストのやり方に関わる新しい技術や手法を実務の案件で使っている

• └ 裏付け：工数区分つきの月次集計（手戻り／検証・学習／通常。手戻りにはテスト起因かどうかの欄をつける）と、浮いた時間の行き先を示す年次の報告。チームごとの技術検証レポート（狙い・結果・実務に入れたかどうかの判定つき）

• テストが、やりたい仕事になっている。テスト設計レビューを主催できる人が部に20人以上いて、その半分は入社5年目までの若手。社外のイベントや記事で、部から年に3人以上が自分たちのやり方を話している。案件のアサインで「テスト設計をやりたい」と自分から希望する人が、毎期いる

• └ 裏付け：テスト設計レビューの記録（主催者名と年次の欄つき）と、社外発表・社内勉強会の記録（登壇者名つき）、アサイン希望の記録

　5つの行と、その裏付けを並べたのが図表2です。

　20人、3人以上といった数字は、この時点では仮置きです。14チームのどこでもレビューを主催できるように、休みや異動も見込んで20人。根拠と呼べるのは、そのくらいの見当でした。部長も全体会で「今の時点で細かく詰めても、たぶん当たりません」と言っていました。初版で問われるのは、夢が描けているかどうかです。数字は、AsIsを数えたあとと、3か月ごとの見直しで確かめていく前提で、まず置いています。

　前回の6つの型のうち、5つがひとつずつ入っています。上から順に、減る（前回の1つ目）、仕事の外が変わる（2つ目）、怖くなくなる（4つ目）、出来るようになる（3つ目）、面白くなる（5つ目）。そろえようとしたわけではなく、嬉しいほうから書いていったら、こうなりました。

　3つ目と4つ目は、獲得する力の話です。だから裏付けの側にも、集計や記録だけでなく、型（標準と観点表）と仕組み（工数区分つきの集計）が並んでいます。

　4つ目と5つ目は、判定できる形にするまでに手がかかりました。「手戻りの時間が新しい挑戦に回っている」「テストが、やりたい仕事になっている」。書いた本人は分かっているのですが、3年後の誰かが読んで判定できる書き方ではありません。どちらも、何人が・どのくらい・どこで、まで書いて初めて判定できる行になります。 4つ目は、浮いた時間の行き先まで書きました。12月に部長が挙げた3つの使い道が、そのまま判定の枠になっています。5つ目は、「やりたい仕事になっている」を人数と場と希望の3つに置き換えました。気持ちを測ることはできませんが、気持ちが動いた結果は数えることができます。

　2つ目は、田口さん自身が書き足した行でした。1つ目の「リリース週も定時で帰れている」だけだと、リリース週以外は今のままでも成り立ってしまう。それでは、部員の暮らしは変わりません。

8. 上の数字を、そのまま書き写さない

　2つ目と4つ目は、一度書き直しています。最初に書いたのは、こうでした。

• 部の時間外が月平均20時間を下回り、有給休暇の取得率が8割を超えている

• 部の手戻り2,000人日が浮き、その行き先が3つに分けて記録されている

　どちらも部ぜんたいの数字です。4つ目の2,000人日は、部長が12月に示したものをそのまま書き写していました。2つ目も、時間外と有給を部全体の数字のまま置いています。書いたあとで、田口さんはこれが4つのWG全部の成果であることに気づきます。

　WGは4つあります。同じ数字を4つのWGが掲げたら、3年後に誰の成果か分からなくなります。自分の取り分を何人日と決めるのは、1年まわして実績が見えてからの仕事です。上のToBeにぶら下げるというのは、上の数字のうち、自分の領域の言葉で言える分を切り出すことです。

　田口さんが思い出したのは、部長が全体会で言っていたことでした。2,000人日をどのWGが何人日ぶん減らすのか、その内訳は今は決めない。1年目は各WGが自分の領域で測れる形を作り、2年目の初めに1年の実績を見て決める。

　そこで、配分の数字は書かずに、自分の領域の言葉で書き直しました。 リリース週の時間外が平常週と同じ水準になっていること。テスト起因の手戻りが半分に減っていること。どちらも、部の数字に足し算で乗るものではなく、このWGが自分で判定できるものです。

　分からないことを、分かったふりで決め切らない。部長が全体会で言った「アジャイル的な考え方でいきたい」は、配分のような、いかにも最初に決めておくべきに見えるものにも使うことができます。

　※ 打ち手の効果は、足し算になりません。標準化で受入基準がそろえば、テスト起因の流出も一緒に減ります。重なった分をどちらの成果として数えるかを先に決めるのは、実はかなり難しい。決められないものを先に決めると、辻褄合わせが始まります。

9. 場面　3周目のあと

　中村さんが顔を上げます。

　「アウトプットまで入ったね。これでToBeは出来上がり」

　「けっこう長くなりました」

　「長くていいんだよ。短い目標は、1年後に全員が別の意味で覚えてるから」

　「覚えがあります」

　僕は、自分から次の予定を口にしました。

　「じゃあ次は、この5つについて今どうなってるかを数えます」

　「いいね。で、その数字、どこから持ってくる？」

　「記録を開いて、自分で数えます」

　「うん。それと、今日そっちに書き出したやつ」

　中村さんは、裏返した紙を指で示しました。議事録、メモ、テンプレート、月次レポート。白い面は、ほとんど埋まっています。

　「捨てないで、置き場所を決めておくといい。3年やると、けっこうな量になるから」

　「分かりました。この紙も、そこに入れておきます。来週までにやってきます」

10. 第5回のまとめ

　3周目で足されたのは、ToBeの各行の下にぶら下がるアウトプットの行でした。

　嬉しい状態には、たいていそれを裏付ける現物があります。思いつかないなら、誰の手元に何が残るか、どんな会話が変わるか、外の人に何を見せるか、出来ていないと何が起きるか。この4つを当てる。それでも出ないなら、代わりに何で確かめるかを決めます。

　書くときは、主語・時点・現物の3点をそろえ、数字だけに寄せず現物とセットにする。状態には「できるようになっている」も入れ、人・型・仕組み・資産のどれかに現れるところまで書く。アウトプットは大小を問わず全部挙げる。成果と認識されなかったものは、残らないからです。

　上のToBeにぶら下げるときは、上の数字をそのまま書き写さず、自分の領域の言葉で言える分を切り出します。

　これでToBeは一枚に収まりました。3年後の嬉しい世界が5行、その下に裏付けのアウトプット。1月の頭には存在しなかった紙です。

　次回は、反対側に取りかかります。現状のほうです。

次回予告

　第6回は4周目です。ToBeが固まったので、今度は現状のほうに取りかかります。AsIsは、既にある資料の寄せ集めではないのです。

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

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

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

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

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

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

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

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

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