【初めてのロードマップづくり 第6回】で、なんでそうなってるの？

　こんにちは。クオリティアーツの池田です。ソフトウェアの品質とテストを中心に、ソフトウェアエンジニアリング全般が専門です。コンサルタントとして、組織の伴走支援をしています（自己紹介）（noteホーム）。AsIsが、手元の資料の寄せ集めで終わってしまう。これもよくある外し方です。

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

　前回は、3周目でした。嬉しい状態には裏付けのアウトプットがあること、それを主語・時点・現物の3点で書くこと。ToBeが一枚に収まったところで前回が終わっています。

　4周目です。中村さんのところへ行くのも、4回目になります。ここからはAsIs、現状のほうに取りかかります。ToBeと同じ項目を数えるだけでは足りません。

この記事のポイント

• AsIsは、自分で数えて自分で書く成果物。数えた瞬間から、自分のものになる

• 数える前に、定義・範囲・時点を決める。決めずに数えた数字は、あとで揉める

• ToBeと同じ項目のほかに、経緯・制約・使える資産・周囲の動きまで書く。ここが打ち手の材料になる

1. 場面　4周目

　数えるのは、思ったより骨が折れました。リリース記録は案件ごとにフォルダが違い、様式もそろっていません。1件ずつ開いて、受入基準の文書があるかどうかを見ていきます。

　2日目の夜、僕は数え方を1回変えました。「文書がある」の判定が、自分のなかでぶれていたからです。1日目に数えた分は、やり直しになりました。

　（先に定義を決めておけばよかった。まあ、2回数えたぶん詳しくなったけど）

　4周目の金曜。週明けには部長への状況説明、その3週間後にはβ版のレビュー会が控えています。数えた目が、まだ少し乾いています。持っていったのは、5行のToBeと裏付け、その下に数字を並べた1枚でした。図表1が、その紙です。

　「今どうなっているかを数えてきました。受入基準書があるのは3チーム、レビューを主催できるのは2人、社外発表は0件です」

　「時間外は？」

　「部の月平均で38時間。リリースのある月だと、60時間超えるチームもあります。有休の取得率は48%」

　「それ、どこから持ってきた？」

　「谷口課長に、部の月次集計を出してもらいました。チーム別は人数が少ないので、個人が割れない形で」

　「みんな残ってるもんな」と言いながら、中村さんは数字の並びを目で追っています。

　「よく数えたね。自分で数えた？」

　「はい。リリース記録を全部開きました。途中から、グループの同僚が手の空いた時間に手伝ってくれて、なんとか間に合いました」

　「いい数字だと思う」と言って、中村さんは腕を組みました。

　「気になるんだけどさ。で、なんでそうなってるの？　3チームだけ基準書があるの」

　「そこ、僕も気になってて。基準書のある3チーム、様式が全部同じなんです。誰かが作った型だと思います。当時の人に聞いてきます」

　中村さんは、少し目を開きました。

　「お。そこまで見たなら言うわ。5年前にさ、開発プロセス整備っていう活動があったんだよ。俺、それに入ってた。あのとき作ったのが、その3チーム分。回してたのは久保田さん、一人で」

　「久保田さん、今どこにいるか分かりますか」

　「5階にいるよ。今から行けば、まだ残ってるんじゃない」

　「ありがとうございます。ほかにも、聞いておいたほうがいい人はいますか」

　「うん。あと、導入サポートで客先に出てる人たち。あの人たち、平日の勉強会に出られる？」

　「出られないです」

　「それ、書いた？」

　数字の並びをもう一度見ました。その人たちは、どの行にも入っていません。

　「あ、入ってないですね」

2. ToBeの項目に対応する現状を数える

　AsIsは、自分で調べ、自分で組み立てる成果物です。 数えた瞬間から、自分のものになります。

　※ フォルダも様式もそろっていない、と田口さんが書いたのは、部長が全体会で5Sと言っていた、まさにそこです。過去の報告書や他部署の資料を寄せ集めると、数字は並びますが、ToBeと引き算ができません。

　まず、ToBeで挙げたアウトプットが今いくつ存在するかを数えます。推測は持ち込まず、実物を開きます。

• リリース週の時間外：部門全体の月次記録（月平均38時間、リリース月は60時間超のチームあり、有給の取得率48%）はあるが、リリース週で切り出した集計はない。判定会での差し戻しは、昨年度7件

• 属人化：テスト設計を任せられる人が1人しかいないチームが、14のうち11

• 手戻り工数：手戻りを分けて記録していない。テスト起因かどうかの切り分けもできない。工数入力に区分の欄がないので、浮いた時間の行き先も追えない。技術検証レポートは、昨年度、2チームで3件

• テスト設計レビューを主催できるのは2人（どちらも15年目以上）。社外発表は0件

• アサインの希望：案件のアサインで本人の希望を聞く欄が、そもそもない

• 受入基準書があるのは3チーム。そのレビュー記録が残っているのは1チーム

　どの行も、誰かが数えるまでは存在していなかった情報です。

3. 数え方を先に決める。定義・範囲・時点の3つ

　数える前に決めておくことが、3つあります。定義と、範囲と、時点です。

　定義。 何を1件と数えるか。

　「不具合の件数」と一言で言いますが、社内テストで見つけたものと、顧客から報告されたものを混ぜるのか。1件の報告に3つの原因が入っていたら1件か3件か。仕様変更として処理したものは含むのか。ここを決めずに数えた数字は、あとで「その数字、何を数えてるんですか」と聞かれます。聞かれたときに答えられないと、数字ごと信用を失います。

　決め方に正解はありません。大事なのは、正しい定義を選ぶことではなく、選んだ定義を紙に書いておくことです。 3年後に同じ定義で数えてあれば、比べることができます。

　範囲。 どこまでを対象にするか。

　部の全14チームなのか、自分が知っている3チームなのか。製品本体だけか、カスタマイズ案件も含むか。狭く取れば正確になりますが、ToBeと対象がずれます。広く取れば対象は合いますが、自分では確かめられない数字が混じります。

　現実的には、「全体をざっくり」と「一部を正確に」の二段構えが扱いやすいです。部全体の粗い数字と、自分が中身まで見られる2〜3チームの詳しい数字。粗い数字で規模感をつかみ、詳しい数字で実態をつかむ。

　時点。 いつのデータか。

　直近1か月か、直近1年か、昨年度1年分か。月によって波のある数字を1か月だけ取ると、たまたま静かな月だったということが起こります。逆に3年分を平均すると、直近の変化が消えます。

　目安としては、年度単位の計画なら、直近1年分を取って、月ごとの並びも見ておくくらいです。平均だけを見て「だいたいこのくらい」と決めてしまうと、あとで「その月、特殊要因ありましたよね」と言われます。

　この3つを決めて、紙の隅に小さく書いておく。それだけで、AsIsの数字は「田口さんが勝手に出した数字」から「定義つきの測定結果」に変わります。

　田口さんがAsIsの下に注記を足したのは、4周目に行く前の晩でした。

4. 同じ項目だけでは足りない

　ここで止めないでください。ToBeに対応する項目だけを並べたAsIsは、点数表です。 そこからは打ち手が出てきません。

　同じ差でも、原因が違えば打ち手は変わります。現状の周りにあるものを、次の4つで書き足します。

• 経緯：なぜ今そうなっているのか。過去に何を試して、なぜ続かなかったのか

• 制約：動かせない事情。人員、他案件、顧客の都合、契約、スケジュール

• 使える資産：既にある仕組み、過去の成果物、詳しい人、動いているツール

• 周囲の動き：他のWG、他部門、全社の別の施策。重複と依存がどこにあるか

　田口さんが調べ直した結果は、こうでした。

• 経緯：受入基準が口頭で、リリース直前に認識違いが出る。3チームだけ基準書を持っているのは、5年前の「開発プロセス整備活動」の名残。正式なプロジェクトではなく、推進役の熱意と善意で動いていた活動で、その人の異動とともに立ち消えになった

• 制約：導入サポートやカスタマイズ案件で客先に出ている人が、各課に数人いて、決まった時間の集まりに出られない。2027年度は大型のリリースが2本ある

• 使える資産：去年入れたテスト管理ツール。それを使いこなしている1チーム。社外の勉強会に自分から出ている若手が3人。5年前を知っている中村さん

• 周囲の動き：開発プロセス標準化WG（5年前の整備活動のリブート）が、同じ時期にレビュー規程を作る。次世代エンジニア教育制度WGが研修体系を作る

　4つの中身と、田口さんが書いたものを図表2にまとめました。

　この4つを書いたかどうかで、あとの打ち手の質が変わります。「客先に出ている人は平日の勉強会に出られない」を知っていれば、集合研修だけという打ち手は最初から外れる。知らずに計画を立てると、2年目にその人たちがまるごと遅れることになります。

　「推進役の異動で立ち消えになった」も同じです。これを知った田口さんは、自分一人が回す形を避けて、3年目に自分がいなくても続く形を目指すことにしました。

5. 場面　5年前の人に会いに行く

　その足で、僕は5階へ上がりました。久保田さんは今、保守の部署にいます。面識はほとんどありません。

　「突然すみません。第2課の田口といいます。テスト品質強化WGで、3年のロードマップを作っていまして」

　「ああ、あれね」と、久保田さんはすぐに思い出したようでした。嫌そうな顔はしません。

　「5年前の観点表、久保田さんが作られたものですよね」

　「そうそう。懐かしいな」

　そう言って、古いフォルダをいくつか開きました。しばらくして、ファイルがひとつ出てきます。観点表の原型でした。

　「これ、途中なんだよね。3チーム分までしか作れなかった」

　「なぜ止まったんですか」

　久保田さんは、あっさり言いました。

　「一人でやってたからさ。楽しかったんだけどね。引き継ぐ相手を作らなかった」

　恨み言の響きはありませんでした。

　「今度は部のプロジェクトなんでしょ。いいなあ」

　「はい。4つのWGでやります」

　「投資枠まで取ってあるの？　ずるいな、それ」

　思わず笑ってしまいました。

　「あの、これ、使っていいんですか」

　「使って。そのために置いといたようなもんだから」

　ファイルをもらって、立ち上がりました。廊下に出る前に、ひとつ思いついて振り返ります。

　「今度、出来たやつを見てもらっていいですか」

　「え、いいの？　行く行く」

　（使える資産って、こういうことか）

　自分の紙に、行がひとつ増えました。「5年前の観点表（3チーム分・久保田さん保管）」。

6. 経緯は、人に聞くしかない

　経緯と制約は、数えても出てきません。人に聞くしかない情報です。

　ところが、若手がこれを聞きにいくのは、けっこう勇気が要ります。「なんで今こうなってるんですか」という問いは、聞き方を間違えると、今のやり方を否定しているように聞こえるからです。

　誰に聞くか。田口さんの場合、3種類の相手がいました。

　ひとつめは、その仕組みを作った人。 5年前の整備活動を知っている中村さんと、前章で田口さんが会いに行った久保田さんが、これに当たります。「なぜこうなったか」を、いちばん正確に知っている人です。当時の判断の理由、検討したが採らなかった案、途中でやめた理由。このあたりは、文書に残っていません。

　ふたつめは、今それを運用している人。 現場のリーダーやテスト担当者です。作った人が知らない「実際にはこう回っている」を持っています。標準は決まっているのに現場では別のやり方をしている、というのは普通にあることで、そのズレ自体が重要な現状です。

　みっつめは、隣の領域の人。 他のWGの主査や、開発チームのリーダー。自分の領域の外から見たときに何が困っているかを持っています。テストの都合で開発が待たされている、というような話は、テスト側にいると見えません。

　何を聞くか。4章の4つのうち、経緯・制約・使える資産は、そのまま聞けば出てきます。ただ、相手に向けて組み直すと、もうひとつ足りません。

• 過去の失敗　似たことを過去にやったか。やったなら、なぜ続かなかったのか

　最後のひとつが、実はいちばん効きます。過去に同じことを試して失敗しているなら、その失敗の理由は、そのまま今回の打ち手の条件になるからです。5年前に標準を作ったが浸透しなかったのなら、今回は浸透のさせ方まで含めて設計しないといけない。これを知らずに同じ打ち手を並べると、同じ結果になります。

　聞き方は、素直でよいと思います。「今のやり方を変えるつもりで聞いているのではなくて、経緯を知らないまま計画を書くと的外れになるので、教えてください」。これで、たいていの人は話してくれます。

　むしろ、聞かずに作った計画のほうが、あとで「あのとき言ってくれれば」と言われます。

7. 数えられない項目が見つかったら、それが初年度の仕事

　田口さんは、手戻り工数で手が止まりました。「手戻りに使っていた時間が新しい挑戦に回っている」と描いたのに、今の手戻り時間が分からないのです。

　ここで多いのが、過去の記録をさかのぼって分類し直す作業です。工数がかかるうえ、当時の記録に判断材料がなく、半分くらいは判定できません。

　ですので、手戻りを分けて記録する欄を足し、基準を決め、月次で集計を始めること自体を初年度の打ち手に載せます。数える仕組み作りは、改善の前提ではなく改善の一部です。

　区分は、ゼロから考えなくて大丈夫です。品質にかかるコストを分けて見る見方が、昔からあります。予防（起きないように先に手を打つ）、評価（確かめるために使う）、内部失敗（出荷前に見つけて直す）、外部失敗（出荷後に見つかって直す）の4つです。手戻りの工数は、このうちの失敗にあたります。田口さんの部で言えば、リリース前の追い込みのうち見つかった不具合を直すぶんは内部失敗、顧客からの指摘で直すぶんは外部失敗です。分けて記録しておくと、3年目に「どこが減ったのか」を自分の言葉で説明できます。

　※ この見方は、A.V. ファイゲンバウムが1956年に示したものが元になっています（Armand V. Feigenbaum, "Total Quality Control", Harvard Business Review, vol. 34, no. 6, November-December 1956。経緯はQuality costs｜Wikipediaにまとまっています）。失敗を内部と外部に分ける4区分の形は、そのあと広く使われるようになったもので、PAF法（prevention-appraisal-failure approach）とも呼ばれます（品質コスト｜日本能率協会コンサルティング）。

8. 外部の診断は出発点。AsIsは自分の成果物

　成熟度診断やアセスメント（外部の専門家に現状を評価してもらうこと）を頼むこともあると思います。私もその仕事をしています。ただ、そこで出てくるのは診断結果であって、みなさんのAsIsとは別物です。

　理由は翌年に出ます。AsIsは1回測って終わりではなく、2年目にも3年目にも同じ見方で確かめ、ToBeとの距離を見ます。数え方の定義を自分が持っていないと、この確かめ直しができません。

　外部の診断を使うなら、結果ではなく数え方のほうを引き取ります。項目の定義、判定の基準、どの記録を見たのか。この3つを自分の手順に写した時点で、AsIsは自分のものになります。

9. 場面　4周目のあと

　週が明けて、AsIsはA4で4枚になっていました。久保田さんに話を聞いたのが金曜の夜で、月曜の朝いちばんに書き足したからです。

　月曜の昼、通りがかりに声をかけました。

　「5分だけいいですか。AsIs、こうなりました」

　中村さんは、枚数を確かめて「増えたね」と言いました。

　「経緯と制約を足しました。あと、使える資産も。久保田さんの観点表、現物をもらってきました」

　中村さんは、4枚をぱらぱらとめくりました。

　「いいね。で、次は？」

　「ToBeとAsIsは、これでそろいました。次に何をすればいいのか、そこがまだ」

　「まあ、2枚そろったら、やることはそんなに多くないよ」

　「……考えてみます」

10. 第6回のまとめ

　4周目で分かったのは、AsIsは集める作業ではないということでした。

　数える前に、定義・範囲・時点を決めて、紙の隅に書いておく。ToBeと同じ項目を数えるのは出発点で、そのまわりにある経緯・制約・使える資産・周囲の動きまで書いて、やっとAsIsになります。経緯と制約は数えても出てこないので、作った人・運用している人・隣の領域の人に聞く。特に、過去に似たことをやって失敗しているなら、その理由は今回の打ち手の条件になります。

　数えられない項目が見つかったときは、それ自体が初年度の仕事になります。外部の診断結果は出発点で、そこから先は自分の手で組み立てる、ということです。

　これで、ToBeとAsIsの2枚がそろいました。1月末、田口さんはこの2枚を持って部長のところへ行きます。ロードマップの形には、まだなっていません。

次回予告

　第7回は1月末、部長への状況説明の日です。ToBeとAsIsだけを持って、田口さんは部長の前に座ります。

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

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

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

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

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

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

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

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

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