【初めてのロードマップづくり 第3回】作ってきたのは、作業計画書

　こんにちは。クオリティアーツの池田です。ソフトウェアの品質とテストを中心に、ソフトウェアエンジニアリング全般が専門です。コンサルタントとして、組織の伴走支援をしています（自己紹介）（noteホーム）。3年のロードマップを頼まれて、作業計画書が出てくる。改善の計画が最初につまずくところです。

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

　前回は、主査の任命でした。部長から直接頼まれ、年明けの任命の会で進め方と時間の手当てを聞く。そこまでが前回です。

　今回から、田口さんの手が動き始めます。自分で調べて作った1枚を、先輩の中村さんに見てもらう。その1枚は、見事に的を外していました。

この記事のポイント

• 田口さんが作ったのは作業計画書。WBSは「作業分解図」と訳されるが、規格が求めているのは成果物の分解のほうで、別の道具

• 3年目が埋まらないのは、順番を変えれば埋まるというサイン

• 積み上げる向きの道具が効くのは、行き先が決まっているとき。行き先を決める仕事には、別の道具が要る

1. 場面　壁打ち相手を頼みに行く

　任命の会があった日の夕方。フロアの照明は半分落ちていました。僕はその足で、中村さんの席へ行きます。中村さんはコードレビューの途中らしく、画面から目を離さずに「なに」とだけ言いました。

　「お忙しいところすみません。テスト品質強化WG、僕がやることになりまして」

　中村さんは、椅子ごとくるりとこちらを向きました。

　「ああ、聞いた聞いた」

　「3年のロードマップを作るんですが、作ったことがなくて。自分で作ってみるので、途中で何回か見てもらえませんか。1回30分くらいで」

　「いいよ。金曜の夕方なら空いてる」

　「助かります。今週から、毎週お願いしていいですか」

　「どうぞ」

　そう言ってから、中村さんは少し姿勢を戻しました。

　「あ、先に言っとくね。俺、ロードマップは何枚か描いてるよ。ただ、部長が言ってるやつは作ったことがない」

　「違うものなんですか」

　「俺が描いてたのは製品ロードマップとか、開発ロードマップ。要は、どの機能をいつのリリースに載せるかの表」

　中村さんは、椅子の背にもたれました。

　「あれは、最初に全部決めて描くから。途中で変わったら描き直し」

　（それ、ウォーターフォールの描き方だ）

　「今回のとは、どこが違うんですか」

　「機能じゃなくて、部がどうなってるかを描くんでしょ。しかも3か月ごとに見直すって部長が言ってた。俺、そういう描き方をしたことがない」

　中村さんは、笑いながら続けます。

　「だから答えは出せない。一緒に考えるくらいならできると思う。機能のロードマップで外した経験なら、18年ぶんあるから」

　「じゅうぶんです。お願いします」

　答えを持っている人に見てもらうつもりでいたので、少し意外でした。ただ、気は楽になりました。

　部長が言っていた「適時レビューを依頼する」を、僕は週に1回と決めました。頻度も、時間も、決めたのは自分です。

　（あとは、作るだけだ。……何を作るのかは、まだ分かってないけど）

2. 場面　1周目

　任命の会の翌日から3日間は、調べることに使いました。「ロードマップ　作り方」「ロードマップ　テンプレート」。テンプレートはいくつも見つかります。ただ、どれも製品や技術の話で、自分のWGに当てはめるとどこに何を書くのかが分かりません。

　AsIsとToBeで調べ直すと、今度は説明が抽象的でした。「現状とあるべき姿のギャップを分析する」。言っていることは分かる。けれど、自分の紙に何を書くのかは、やはり分かりません。

　（言葉は知ってた。入れる場所を知らなかっただけか）

　3日目の夕方、僕は調べるのをやめました。

　（手を動かさないと、分からないままだ）

　ともかく手を動かすことにします。去年テスト管理ツールを入れたときのExcelを開きました。作業を分解して、担当と日程を引いた、あの表です。あれは評判が良かった。

　今やれそうなことを書き出していきます。テスト設計のガイドを作る。レビューの勉強会を開く。障害の分析を始める。1年目の欄は、30分で埋まりました。

　2年目の欄で、手が止まります。書けたのは「1年目の内容を他チームへ展開」の1行だけ。3年目は、もっと困りました。しばらく考えて、「定着」「継続的改善」と入れます。

　金曜の夕方。プリンタの音が遠くで鳴っています。僕は、刷り上がったばかりのA3を1枚持って、中村さんの席へ行きました。3年分の行と、担当と日程の列が並んでいます。

　この日の紙が、図表1です。

　「お時間いただいてすみません。一応、できました」

　中村さんはキーボードから手を離し、紙を受け取りました。黙って3分ほどながめてから、顔を上げます。

　「うん。作業は、よく分かる。……これ、作業計画だね」

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

　「ひとつ聞いていい？　この紙を3年後に誰かが読んだら、何が分かる？」

　「えっと、誰がいつ何をやったか、ですかね」

　「うん。じゃあ、3年後にうちのテストがどうなってるかは？」

　僕は、自分の紙をもう一度見ました。1年目の行は、担当も日程も埋まっています。ただ、どの行も「やること」でした。

　「……書いてないです」

　「部長、年末に何か言ってなかったっけ」

　「手戻りを半分に、ですよね。全体会のあと、去年の記録を開いてみたんです」

　「それ、この紙のどこにある？」

　どこにもありませんでした。

　（なるほど。ぜんぜん違うものを作ってきたな）

3. 作ってきたのは、作業計画書だった

　今できることを分解して、担当と日程に並べる。これは正しい仕事のしかたで、ツール導入のときはそれで足りていました。私も最初は、これしか作ることができませんでした。

　行き違いの原因は、求められていたものが別の種類だったことです。

　ここで、言葉をひとつ整理させてください。田口さんは、この紙を頭のなかで「WBS」と呼んでいました。現場ではよくある呼び方です。ただ、作業を縦に並べて担当と日程を割り付けた表は、本来のWBSとは別のものです。 実態に近いのは、作業計画書という呼び方のほうです。

3-1. WBSは、もともと米軍の規格

　WBS（ワークブレークダウンストラクチャ）の出どころは、軍の規格です。1957年に米海軍がポラリス・ミサイル計画でPERTを導入したとき、まだWBSという語はありませんでしたが、作業を成果物ごとの分類に整理していました。1962年に国防総省・NASA・航空宇宙業界がPERT/COSTの文書でこの考え方を示し、1968年に国防総省が MIL-STD-881「Work Breakdown Structures for Defense Materiel Items」を発行しています（Work breakdown structure｜Wikipedia）。最新の改訂はF版（2022年5月13日）で、いまも生きている規格です。

　そのF版が、WBSをこう定義しています。

　続けて、こうあります。WBSは、開発あるいは製造される成果物、または提供されるサービスを、示し、定義する。それは、達成すべき作業の要素を、互いに、また最終成果物に関係づける。WBSは成果物の構造であって、組織の構造でも能力の構造でもない（MIL-STD-881F 1.5.3、1.5.4）。

3-2. 分解するのは、作業ではなく成果物

　ここが肝心なところです。WBSで分けていくのは、やることではなく、作るもののほうです。

　同じ系統の手引（MIL-HDBK-881A）には、やってはいけないことまで書いてあります。成果物でない要素を入れてはいけない。設計エンジニアリング、テストエンジニアリング、要求分析は、どれもエンジニアリングの機能を切り出したものであって、WBSの要素として適切ではない（MIL-HDBK-881A 2.2.4.1）。言われてみれば、どれも見出しに置きたくなる言葉です。

　PMIがWBSの質について出した論文にも、同じ線が引かれています。良いWBSは名詞と形容詞を使い、動詞を使わない。多くのプロジェクトマネージャがWBSを作ったつもりでいて、よく見るとプロジェクトの活動を並べただけだった、という指摘もあります（Creating effective work breakdown structures｜PMI）。

　100%ルールという決まりも、ここから来ています。プロジェクトの範囲にある作業を100%含み、社内に出すもの、社外に出すもの、途中の中間成果物まで漏れなく拾う。それを守るいちばん確実なやり方は、要素を「行為」ではなく「成果」や「結果」の形で書くことだとされています（Work breakdown structure｜Wikipedia）。

　ですので、WBSの形は部品表（BOM）に近くなります。完成形があって、それを部分に分けて、さらに分けていく。出発点は、作るものの完成形のほうです。 新製品の開発では、成果物指向のWBSを作るために、PBS（product breakdown structure、成果物分解図）を併せて使うのが一般的だ、とも言われます。

3-3. 「作業分解図」という訳が、ずれを呼んでいる

　日本では、WBSは「作業分解構造」「作業分解図」「作業分解構成図」と訳されるのが普通です。国語辞典を引くと、「プロジェクトを細かい作業ごとに分解したうえで表にして管理する手法」「ワークパッケージという個々の作業要素に分解する」といった説明が出てきます（WBS｜weblio辞書。実用日本語表現辞典、デジタル大辞泉）。

　規格が「成果物の構造だ」と言っているものが、日本語では「作業の分解」として広まっているわけです。 訳語そのものが誤りというより、訳語に引きずられて中身が作業の一覧になってしまう。田口さんがやったのは、まさにこれでした。去年のツール導入でうまくいった紙を開いて、作業を縦に並べ直したのです。

　ひとつ気をつけたいのは、では正しい訳は「成果物分解図」かというと、そこも少しずれることです。成果物分解図はPBSの訳語で、WBSはそこにプロジェクトマネジメントの作業まで含みます。訳語を取り替えるより、分解の軸が成果物のほうにあると覚えておくのが確実だと思います。

　※ WBSそのものについては、規格の条文をたどった記事を別に書きました。この回では、連載の筋をたどるのに必要なところまでにとどめています。

　※ 2つ、書き分けておきます。ひとつ。JIS Q 21500:2018は、WBSの作成の目的を「プロジェクトの目標を達成するために完了する必要のある作業を表すための、階層的分割の枠組みを提供すること」としていて、成果物から分けるとは明示していません（JIS Q 21500:2018 プロジェクトマネジメントの手引 4.3.12）。成果物の側を強く打ち出しているのは、MIL-STD-881の系譜とPMBOKのほうです。ふたつ。MIL-STD-881の条文も、work（作業）という語は作業の意味で使っていて、「WBSは実施すべき作業の完全な定義を与える」と書いています。作業が消えるわけではありません。 作業を、成果物の形に並べ直す、というのが正確なところです。

3-4. WBSも、ゴールから逆に分けていく

　そうすると、見えてくることがあります。WBSとロードマップは、向きが逆ではありません。 どちらも、出来上がった姿を先に置いて、そこから分けたり並べたりする道具です。

　逆を向いていたのは、田口さんの作業計画書のほうでした。今やれることを洗い出して、下から積み上げた紙です。

　3つを並べると、こうなります。

• 作業計画書　…　今やれることを洗い出して、担当と日程に並べる。積み上げる向き

• ロードマップ　…　3年後の姿を先に決めて、そこから逆に並べる。逆算する向き

• WBS　…　作るものの完成形を、階層に分けていく。ロードマップと同じ向きで、出番が後ろ

　WBSは、行き先が決まったあとの道具です。 ロードマップと取り合う関係ではなく、ロードマップの下にぶら下がるものです。実際、田口さんがWBSを作ることになるのは第9回、3年分の欄が埋まったあとになります。

　※ ひとつ、書き分けておきます。JIS Q 21500:2018は、WBSの作成の目的を「プロジェクトの目標を達成するために完了する必要のある作業を表すための、階層的分割の枠組みを提供すること」としていて、成果物から分けるとは明示していません（JIS Q 21500:2018 プロジェクトマネジメントの手引 4.3.12）。成果物の側を強く打ち出しているのは、MIL-STD-881の系譜とPMBOKのほうです。

　田口さんがあとで思い当たったのは、去年のツール導入との違いでした。あのときは、入れるものが最初から決まっていて、決めたのは前の部長です。

4. 現状から積み上げると、3年目が埋まらない

　行き先を決めずに作業計画書の作り方で3年を埋めると、だいたい田口さんの紙と同じ結果になります。

　これは、順番の問題です。現状を起点にすると、今の手が届く範囲までしか届きません。1年の計画ならそれで足ります。3年で組織の姿を変えたいなら、足りません。

5. 逆から考える、という言い方

　先に到達したい姿を決めて、そこから現在に向かって逆向きに並べる。この進め方を「バックキャスト」「バックキャスティング」と呼びます。1982年にエネルギー政策の分析手法として提案された言葉です（John B. Robinson, "Energy backcasting: A proposed method of policy analysis", Energy Policy, Vol.10 No.4, 1982, pp.337-344。書誌はRePEc）。

　語源はさておき、使い方はひとつだけです。先に終わりの姿を決めて、そこから逆に並べる。これを3回くり返せば、3年のロードマップになります。

　※ 現状を見るのをやめる話とは違います。3年目の姿は逆算で決め、1年目に手が回るかどうかは今の工数で検算する。この往復が要ります。

6. 階層が上がるほど、この順番が効く

　自分の担当だけを見ているうちは、現状の延長で十分に回ります。ところが、見る範囲が広がるとそうはいきません。チームの計画は数週間先、WGの計画は年度、部門や経営の計画は3年から5年。先を見る距離が伸びるほど、現状の延長で説明できる範囲は狭くなります。経営に近づくほど、「何をやるか」より「何をやらないか」を決める仕事になる、というのが私の見立てです。現状を起点に並べた一覧からは、やらないことが出てきません。全部が「やったほうがよい」に見えます。

　公の道具も、すでにこの形です。経済産業省の「DX推進指標」のガイダンス（令和元年7月）には、指標の狙いがこう記されています。

　現状、あるべき姿、ギャップ、対応策。国が経営者向けに出した道具も、この記事と同じ並びを採っています（「DX推進指標」とそのガイダンス、経済産業省の案内ページ）。上の階層に説明するとき、この並びは後ろ盾になります。

7. 作業計画書が効く条件と、効かない条件

　ここで誤解のないように書いておきます。田口さんが作った作業計画書は、出来の悪いものではありませんでした。1年目の欄は、作業が漏れなく並んでいたし、依存関係も押さえてあったし、担当欄まで埋まっていた。1年の計画としてなら、よく出来ていたのです。

　問題は、出番が違ったことだけでした。

　作業を積み上げる作り方が力を発揮するのは、次の3つがそろっているときです。

• 行き先が決まっている。何が出来たら終わりか、もう合意がある

• やり方が見えている。少なくとも、経験者に聞けば分かる程度には

• 期間が、見通せる長さに収まっている。数週間から、長くて半年

　ツール導入はこの3つがそろいます。導入するツールは前の部長が決めていて、手順も検索すれば出てきて、展開まで含めて半年で終わる。だから田口さんの作り方は、これまでずっと当たりでした。

　では、今回はどうか。

　行き先は、決まっていません。部長が全体会で言ったのは部としての方向であって、テスト品質強化WGが3年後にどうなっているかは、まだ誰も書いていない。やり方も見えていません。部として初めての取り組みだと、部長自身が言っています。期間は3年。半年先の状況すら、そのときにならないと分かりません。

　3つとも、外れています。

　3つの道具の違いと、3つの条件を田口さんの2つの仕事に当てはめたものを、図表2にまとめました。

　ここを取り違えると、しんどい形で現れます。行き先が決まっていないのに作業を並べ始めると、「たぶんこういう作業になるだろう」という想像で作業を埋めることになるからです。埋まった紙は立派に見えます。けれども、その作業が何のためなのかは、どこにも書かれていません。 あとから「この作業、要るんでしたっけ」と聞かれて、答えに詰まる紙が出来上がります。

8. 「3年後の姿を書け」で手が止まる理由

　ロードマップを作れと言われて、白紙を前に手が止まる。田口さんが年明けの3日間で味わったのが、これでした。

　この止まり方には、理由があります。

　ひとつめ。これまでの仕事は、たいてい誰かが行き先を決めてくれていたということ。ツールを入れると決めたのは上司で、リリース日を決めたのは顧客で、機能の範囲を決めたのは企画でした。田口さんの仕事は、決まった行き先に向かって最短の道を引くことでした。

　ふたつめ。行き先を決める仕事には、正解がないということ。道を引く仕事なら、抜けや矛盾を潰していけば「合っている」状態に近づけます。ところが3年後の姿は、抜けを潰しても出てきません。誰かの頭の中にある答えを当てにいく作業ではないからです。8年かけて身につけた「合っているかを確かめながら進める」やり方が、ここでは使えない。

　みっつめ。間違えることが怖いということ。3年後を自分の言葉で書くというのは、外れる可能性のある言明を、名前つきで紙に残すことです。作業計画書なら「予定どおりに進めます」と言っていればよかった。3年後の姿を書くというのは、それより一段、身を晒す行為になります。

　この3つは、どれも田口さん個人の弱点とは違います。行き先を決める仕事を割り当てられた人が、最初に通りやすい場所です。

　ではどうするか。

　答えを当てにいくのをやめて、まず一度書いてみる、というのが出口になります。外れていてよい。外れていると分かるためには、外れた紙が要るからです。田口さんが1周目に持っていった紙も、役には立っていました。あれが出てきたおかげで、「作業計画と状態の計画は違う」という話ができました。

　白紙のまま1週間悩むのと、外れた紙を持って30分話すのとでは、進み方が違います。

9. 場面　1周目のあと

　話を金曜の夕方に戻します。僕の手元には、さっき「作業計画だね」と言われたA3の紙があります。

　中村さんは、紙を返しながら聞きました。

　「で、どうする？」

　「3年後を書いてみます。作業じゃなくて、状態で」

　言ってから、自分で引っかかりました。状態というのが何を指すのか、説明できません。

　「状態って、たとえばどういうものですか」

　中村さんは、少し考えるふりをしてから言いました。

　「うーん。それ、俺が答えると田口さんの言葉にならないんだよな」

　「ですよね」

　「あとさ。3年後の金曜の夕方に、この部を外から見た写真を撮るとするじゃん。そこに何が写ってたら嬉しい？　その写真の説明が、たぶん状態」

　「写真、ですか」

　「作業は写真に写らないでしょ。終わっちゃってるから」

　「なるほど。……来週、また30分いただけますか」

　「金曜ならいるよ」

　「ありがとうございました」

　席に戻って、Excelを閉じ、新しい白紙のファイルを開きます。1行目に「3年後の写真に、何が写っていたら嬉しいか」と打ち込んでみました。

10. 第3回のまとめ

　1周目で分かったのは、ひとつだけです。ロードマップは、作業計画書の長い版ではないということ。

　積み上げる向きと、逆算する向き。反対なので、片方のやり方をそのまま伸ばしても、もう片方にはなりません。

　田口さんの紙が3年目で止まったのは、このためでした。今から積み上げていくと、1年目は書ける。2年目は少し怪しくなる。3年目になると、何を書けばよいのか分からなくなる。埋まらない欄があるということ自体が、順番が逆だというサインです。

　次回、田口さんは向きを変えて3年後から書いてきます。ところが今度は、別のところでつまずきます。

次回予告

　第4回は2周目です。田口さんは今度こそ3年後を書いてきます。ところがその3年後は、今の延長でした。ToBeを未来志向で書くとはどういうことかを扱います。

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

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

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

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

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

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

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

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

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