【初めてのロードマップづくり 第4回】それ、今の延長だよね

　こんにちは。クオリティアーツの池田です。ソフトウェアの品質とテストを中心に、ソフトウェアエンジニアリング全般が専門です。コンサルタントとして、組織の伴走支援をしています（自己紹介）（noteホーム）。ToBeを現状の延長で書いてしまう。いちばんよく起きる外し方です。

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

　前回は、1周目でした。田口さんが持っていったのは作業計画書で、3年目の欄が埋まりませんでした。ロードマップは3年後から逆に並べる道具らしい、と気づいたところで前回が終わっています。

　今回は、先輩の中村さんへの壁打ち2周目です。田口さんは、今度はちゃんと3年後を書いてきました。ところが、その3年後は今の延長でした。ToBeを未来志向で書くとは何をすることなのかを扱います。

この記事のポイント

• ToBeは、今より嬉しい世界を描くこと。現状の延長で書いた時点で、それはToBeではなくなる

• 嬉しさには6つの型がある。全部が「減る」で埋まっていたら、偏っている

• 目標は高くてよい。3年後に7割届けば十分に成功。ただし、ひとつ上のToBeにはぶら下げる

1. 場面　2周目

　その週、僕は「ToBe　書き方」で調べ直しました。出てくるのは「あるべき姿を描く」という説明ばかりで、何をどう書くのかまでは書かれていません。

　3年後の写真、という中村さんの言い方を思い出しながら、しばらく画面を見ていました。ただ、浮かんでくるのは今やっている仕事の景色ばかりです。

　結局、今やっていることの「ちゃんとやれている版」を3行にしました。書いてみると、どこがとは言えないのに物足りない。

　（物足りないけど、持っていけば何か言ってもらえるか）

　金曜の夕方。今度はA4に3行だけ印刷して持っていきました。紙が軽いぶん、先週より不安です。中村さんの机の隅には、飲みかけのマグカップがありました。

　「先週の話をふまえて、3年後の状態で書いてみました」

　持っていったのは、この3行です。

• テスト設計のガイドが全チームに配られている

• レビューの勉強会が定期開催されている

• 障害の分析が毎月実施されている

　紙にすると、図表1のとおりです。1周目の紙から、ずいぶん軽くなりました。

　中村さんは、3行を上から順に読みました。読み終えるまで、10秒もかかりません。

　「ちゃんと3年後を書いてきたね」

　「はい。今度は作業じゃなくて、状態で書きました」

　「うん。これ、今からやろうとしてることと、どう違う？」

　「……えっと」

　僕は、自分の3行をもう一度読みました。ガイドを配る。勉強会を開く。分析を回す。先週の紙に書いた「やること」を、そのまま「〜されている」に言い換えただけです。

　「……同じです。言い方を変えただけでした」

　思わず笑ってしまいました。語尾を「されている」にすれば状態になる、と思い込んでいたのです。

　「それ、今の延長だよね。……じゃあ、これが3年後に全部できてたとして、みんなは何が嬉しい？」

　僕は答えることができませんでした。

　中村さんは、ペンの尻で机をこつこつと鳴らしました。

　「聞き方変えるわ。3年後にみんながどうなってたら、田口さんは嬉しい？　仕事として」

　「リリース前の追い込みがなくなってたら、嬉しいですね。今、毎回みんな終電なので」

　「それ、この3行のどこかに書いてある？」

　「書いてないです」

　少し間が空きました。

　「……そういうことを、計画に書いていいんでしょうか」

　中村さんは、首をかしげました。

　「どう思う？」

　「改善プロジェクトなので、3年後は今より良くなってるはず、ですよね」

　「だよね」

2. まず、3年後の嬉しい世界を描く

　ここが、この連載でいちばん伝えたいところです。

　ToBeは、今より嬉しい世界です。 プロセス改善なのですから、3年経ったら改善が進んでいるはずです。つまり3年後は、今より仕事が楽になっていて、面白くなっていて、新しいことに手が出せている。その姿を描きます。

　部長が全体会の最後に「この3年間を、全員で助け合いながら、楽しい世界に行きましょう」と言っていました。あれは挨拶ではなく、この連載でいうToBeそのものです。

3. 現状に引きずられない

　初めてToBeを書くと、多くの人が同じところでつまずきます。今の延長で届く範囲を書いてしまうのです。田口さんの2周目が、まさにそれでした。

• 引きずられたToBe：テスト設計のガイドが全チームに配られている

• 未来志向のToBe：リリース前の追い込みがなくなっていて、リリース週も定時で帰れている

　前者は、今すぐ手をつけることができます。安心できます。ところがこれは打ち手であって、嬉しい状態とは違います。ガイドが配られただけで残業が消えるかどうかは、別の話です。

　もうひとつ、目標は高めに置いたほうがうまくいきます。 「少し良くなっている」を3年後に置くと、2年目には誰も見なくなります。届くかどうか分からないが、そこに行けたら本気で嬉しい。その水準がToBeです。

4. 「嬉しい」を業務の言葉にする

　「今より嬉しい世界を書いてください」と言われて、すぐ書ける人は、そう多くないはずです。嬉しいという言葉が、業務の言葉になっていないからです。

　手がかりとして、嬉しさにはいくつか型があります。田口さんが2周目のあとに書き出したのも、だいたいこの並びでした。

　ひとつめは、減る嬉しさ。 今かかっている手間や時間が減る。やらなくてよくなる作業がある。待たされる時間が短くなる。テストプロセスの文脈なら、「不具合の出戻りに使っていた時間が減っている」「毎回ゼロから作っていたテスト設計を、作り直さなくてよくなっている」あたりです。

　ふたつめは、仕事の外が変わる嬉しさ。 減った時間が、そのまま暮らしに返ってくる。「平日の夜が、自分の時間になっている」「休みの日に、仕事のチャットを見なくてよくなっている」「有給休暇が、ためらわずに取れている」。改善の計画にこれを書くのをためらう人は多いのですが、現場にとっては、いちばん実感のある嬉しさです。時間外や休暇の取得率という形で数字にもなります。

　みっつめは、出来るようになる嬉しさ。 今は出来ないことが、出来るようになっている。「リリース前夜に総出で確認していたものが、平日の日中に片づく」「今は手が出せない規模の機能に、手が出せる」。減るより一段、前向きな型です。

　よっつめは、怖くなくなる嬉しさ。 これまで不安だったことが、不安でなくなっている。「リリース日の朝に、誰も胃が痛くならない」「担当者が休んでも、テストが止まらない」。

　いつつめは、面白くなる嬉しさ。 仕事の中身が変わる。「単純な確認作業に使っていた時間が、設計を考える時間に変わっている」「若手が、外の勉強会で自分たちのやり方を話せるようになっている」。

　むっつめは、外から見える嬉しさ。 部の外や社外から、そう見られている。「品質のことなら、あの部に聞けと言われている」「お客さまから、テストの進め方について相談が来る」。

　6つの型を並べると、図表2のようになります。

　6つ全部を埋めなくてかまいません。3行なら、型が3つ違っていれば十分です。田口さんは最終的に5行になり、そこに5つの型が入りましたが、そこまでやらなくて大丈夫です。むしろ気をつけたいのは、全部が「減る嬉しさ」で埋まっているときです。削るだけの計画になっていて、3年後に何が増えているのかが書かれていません。田口さんの書き直しも、最初の案は全部が「減る」でした。

　なお、この6つの型は、書くための道具とは違います。書いたものが偏っていないかを見るための点検表です。先に型から埋めにいくと、型に合わせた言葉が並びます。

5. 最初の1行が出ないときの、3つの問い

　型を見ても手が動かないときがあります。そういうときは、質問から入ったほうが早いです。出やすい順に並べてあります。

　問い1　この1年で「もったいなかったな」と思った日を3つ挙げてください。そして、その日が来なかったら、あなたは何をしていましたか。

　後半のほうが大事です。嬉しい未来を思い出すことはできませんが、もったいなかった半日は誰でも覚えています。その半日が空いていたら何をしたかったか。それが1行目になります。田口さんの最初の嬉しさも、「今、毎回みんな終電なので」から出てきました。

　問い2　今いちばん頼りにしている人が、来月から別の仕事に移るとします。それでも回るようにするには、何が要りますか。

　欠けたものではなく、要るものを聞く形にしてあります。ここから出てくるのは、たいてい「出来るようになる嬉しさ」か「怖くなくなる嬉しさ」です。

　問い3　3年後、後輩に「この部に来てよかった」と言われるとしたら、その理由は何でしょうか。

　いちばん遠い問いですが、6つの型のうち「面白くなる」と「外から見える」は、だいたいここから出ます。

6. 高い目標が怖い、という感覚について

　中村さんに「それ、今の延長だよね」と言われたあと、田口さんが感じたのは、反省より不安のほうだったと思います。高く書いて届かなかったらどうするのか、と。

　これは自然な感覚です。達成できなかった目標を紙に残すのは、誰だって気が進みません。8年間、期日と約束を守ることを評価されてきたのなら、なおさらです。

　そのうえで、ロードマップの3年後の欄は、高く書いて大丈夫です。 理由は3つあります。

　ひとつめ。届く高さに設定すると、そこまでしか行かないから。 目標は、打ち手の上限を決めます。「不具合を1割減らす」を3年後に置くと、出てくる打ち手は今のやり方の微調整になります。「半分にする」を置くと、今のやり方のままでは無理だと分かるので、やり方そのものを変える案が出てくる。同じ3年を使って、たどり着く場所が変わります。

　これは、感覚だけの話でもないのです。目標と成果の関係は、心理学で長く調べられてきたテーマです。そこで繰り返し確かめられているのは、具体的で難しい目標のほうが、「ベストを尽くそう」と促すより成果が高くなるということでした。

　※ エドウィン・ロックとゲイリー・レイサムの目標設定理論です（Edwin A. Locke and Gary P. Latham, A Theory of Goal Setting and Task Performance, Prentice Hall, 1990）。35年分をまとめた総説として、Locke and Latham, "Building a Practically Useful Theory of Goal Setting and Task Motivation: A 35-Year Odyssey", American Psychologist, Vol. 57, No. 9, 2002, pp. 705-717。研究が言っているのは、努力と成果の水準が上がるということであって、高く書けば必ず届く、ということではありません。

　ふたつめ。3年後の欄は、約束ではなく方向だから。 次回以降で詳しく扱いますが、この計画は3か月ごとに見直す前提です。3年後の欄は、毎回の見直しで「この向きで合っているか」を確かめるための基準であって、「この数字を必ず出します」という契約とは別物です。契約として扱うのは、直近6か月の欄のほうです。

　みっつめ。7割で十分に成功だから。 現場感覚の話になりますが、3年後の高い目標に対して7割まで来ていれば、その組織はかなり変わっています。低く置いた目標を満額達成するより、高く置いた目標に7割届くほうが、手に入るものは大きい。

　※ 「7割」という言い方は、OKRの運用から広まったものです。Googleが公開しているガイドには、採点のちょうどよいところは60%から70%のあたりだ、と書かれています（Set goals with OKRs, Google re:Work）。研究の結論ではなく、運用上の目安として読んでください。

　もちろん、何の裏付けもなく大きな数字を書けばよいという話ではありません。高く置くことと、根拠なく置くことは別です。高く置いたうえで、そこに至る道が引けるかどうかを、このあと自分で確かめていく。引けなければ下げればよいし、引けたなら高いままでよい。順番としては、まず高く置いてから確かめる、です。

　先に下げてしまうと、確かめる機会そのものが無くなります。

7. 上のToBeにぶら下げる

　自分のWGだけで3年後を決められることは、あまりないと思います。たいていは、上に誰かの3年後があります。

　田口さんの場合、それは第1回で見た12月の部の全体会でした。部長は、数字で言えるものと言えないものを分けて示しています。

• 数字：手戻りの工数を3年で半分に／リリース判定の差し戻しをゼロに／14チームすべてが年に1件は新しい技術や手法を実務に入れている（4つ目の「リリース週の時間外」は、まだ測れていない）

• 数字にならないもの：リリース週に誰も胃が痛くならない／平日の夜と休日が自分のために使える／若手が「この部にいると力がつく」と言える／品質のことで社外から声がかかる

　これが、部としてのToBeです。

　WGのToBeは、ここにぶら下げます。ぶら下げると、3つの良いことがあります。承認の場で通りやすくなる。他のWGとの重複が見えやすくなる。何より、3年後の議論を一から始めなくて済みます。

　ひとつ気をつけたいのは、ぶら下げるというのは、上の数字をそのまま書き写すことではないという点です。部の目標が「手戻りを半分に」なら、そのうち自分のWGが受け持つのは何割なのか。その取り分を切り出します。部の数字をそのまま自分のToBeにすると、他のWGと同じ数字を3つも4つも掲げることになり、3年後に誰の成果か分からなくなります。田口さんがこれをやるのは、次回です。

8. 上のToBeが見当たらないとき

　ここまでは、部長が全体会で3年後を語ってくれている前提で書いてきました。田口さんは恵まれていたほうです。

　実際には、上のToBeが見当たらないことがあります。上位の方針が抽象的すぎて手がかりにならない、方針はあるが自分の担当領域に触れていない、そもそも文書になっていない。このどれかに当たることは、珍しくないはずです。

　そういうときに取れる手は、3つあります。

　ひとつめは、探す。 文書になっていないだけで、材料はどこかにあることが多いからです。中期計画、年度方針、期初の全体会の資料、社長メッセージ、採用ページに書いてある会社の説明。品質やプロセスに直接触れていなくても、「どういう会社になろうとしているか」を読み取ることができます。製品を売り切りからサブスクリプションへ、と書いてあるなら、求められるテストの形も変わるはずです。

　ふたつめは、聞く。 上長に「3年後、この領域についてどうなっているのが理想ですか」と正面から聞く。これは遠慮しなくてよい問いです。聞かれた側も、言語化していないことが多いので、話しながら固まっていきます。一度で明確な答えが返ってこなくても、方向くらいはつかむことができます。

　みっつめは、仮に置いて確認をもらう。 これが実務ではいちばん早いことがあります。「上位方針をこう読みました。この理解で合っていますか」と、自分の解釈を紙にして持っていく。正しく読めていれば承認が取れるし、外れていれば訂正が返ってきます。どちらに転んでも、情報が増えます。

　やめたほうがよいのは、上のToBeが無いことを理由に、自分のToBeを書かずに待つことです。待っている間、計画は進みません。それに、ぶら下げる先が無いなら、自分の紙のいちばん上の行を自分で書いてしまってよいのです。「この部が3年後こうなっているために、うちのWGはこうなる」という形で。上と食い違っていれば、レビューの場で誰かが必ず言ってくれます。

9. 場面　2周目のあと

　話が一段落したところで、中村さんは3行にペンで印をつけました。

　「今日ので、方向は合ってると思うよ」

　「書き直してきます。今度は、嬉しいほうで」

　「うん」

　「ありがとうございました。また来週お願いします」

　帰りの電車で、僕はメモアプリに打ち込んでいました。リリース前、定時で帰れてる。夜と休日が、自分のものになってる。担当が休んでも、テストが止まらない。手戻りの時間が、新しいことに回ってる。テストが、やりたい仕事になってる。

　（これ、本当に3年でできるのかな）

　できるかどうかは、まだ分かりません。ただ、できたら嬉しいことは確かでした。

10. 第4回のまとめ

　2周目で手に入ったのは、ToBeの中身でした。

　田口さんが最初に書いた3年後は、今の業務の言葉で書いた、今の延長の姿でした。向きは変えたのに、見ている場所が動いていません。

　ToBeは、今より嬉しい世界を描くこと。6つの型は、書くための道具ではなく、偏っていないかを見るために使います。目標は高くてよい。自分のToBeは、ひとつ上のToBeにぶら下げる。上が見当たらないなら、探すか、聞くか、仮に置いて確認をもらう。

　これで、3年後の世界を書くことができました。けれども、ここにはまだ大きな穴が残っています。その世界が実現したことを、どうやって確かめるのか。

　次回、中村さんはそこを突きます。

次回予告

　第5回は3周目です。書き上がったToBeに対して、中村さんは「それ、どうやって確かめるの？」と聞きます。嬉しい状態を裏付けるアウトプットの話です。

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

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

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

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

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

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

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

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

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