【WBS再入門 中編】「最低3階層」には、出どころがあった　ポラリスから、消えた「3階層」まで

　こんにちは。クオリティアーツの池田です。ソフトウェアの品質とテストを中心に、ソフトウェアエンジニアリング全般が専門です。コンサルタントとして、組織の伴走支援をしています（自己紹介）。

　前編では、左に工程が並んで右に日付と進捗率が入った手元の紙を、やってしまう分け方11に当てました。直し方は3つで、完成形を1つ据える、名詞で分ける、足して100%になるかを確かめる。根拠にした軍用規格 MIL-STD-881F の定義は「成果物指向のファミリーツリー」で、WBSは表ではなく木でした。

　さて、ここからが中編です。

　「WBSは最低3階層」。あの説明には、出どころがありました。

　そこで「根拠にできる条文は見つけられませんでした」と書きました。見つかりました。ただし、そこに書いてあったのは「報告のために推奨される最小限」で、しかもいまの規格からは、その数字ごと消えています。

　どこに書いてあったのか。なぜ消えたのか。そこへ行くには、この規格がどこから来たのかを先にたどる必要があります。

　出発点は、潜水艦から弾道ミサイルを撃つという計画でした。管理のための組織が置かれたのが1956年、PERTという手法が生まれたのが1957年から1958年にかけて。Excelも、できあいの工程表の雛形も、まだ影も形もない時代です。

　歴史の回ですが、手が動くところは8章にまとめました。年号に興味がなければ、そこだけ拾っていただいてもかまいません。なお出典と断り書きは、読みの流れを切らないよう、記事の最後にまとめました。

この記事のポイント

• 「最低3階層」の出どころは、2005年の手引でした。 書いてあったのは「報告のために推奨される最小限」。ただし現行の規格からは、その数字ごと消えています

• 「ファミリーツリー」は、軍用規格より4年早い。 1964年の米空軍の文書にあります。定義の中核句は、1975年の版から47年そのままです

• 既製のWBSが10本、付録に付いています。 ただし開けてみると、航空機の型はレベル2が16項目で、作るものの名前はそのうち4つだけでした

　前編は、こちらです。

1. 名前が付く前から、やり方のほうがあった

1-1. 潜水艦から撃つミサイルと、PERT

　WBSの祖先は、潜水艦から弾道ミサイルを撃つという計画から出てきました。

　PERT（Program Evaluation and Review Technique）は、米海軍が潜水艦発射弾道ミサイル「ポラリス」の開発計画のために作った手法です。作業の前後関係と、かかる日数の見積りから、全体がいつ終わるかを計算するやり方だと考えてください。

　PERTが解こうとしたのは、見積りの不確かさでした。研究開発には前例がないので、「この作業は何日」と1つの数字で言えません。そこで楽観・最頻・悲観の3つを出して期待値を取る。PERTの中身は、この動機から素直に出てきます。

　旗を振ったのは、海軍の特別計画部（Special Projects Office）です。1956年に計画評価課の責任者として招かれたのが、ウィラード・ファザーという経済学者でした。与えられた仕事は、「ポラリス計画が突きつけたマネジメントの難題」を解くこと。チームは、特別計画部と、ブーズ・アレン・ハミルトンと、ロッキードのミサイル宇宙部門から集められています。

1-2. なぜ、作業ではなく物で分かれたのか

　ここが、この道具の面白いところです。work breakdown structure という語は、まだ出てきません。それなのに、やり方のほうが先に形になっていきます。

　階段を並べてみます。

• 1959年　ファザーらが加わった論文（Malcolm ほか）の図版に「Polaris Project Work Subsystems」という分解が載る

• 1961年　work breakdown structure という語が、説明なしで通じるようになる。GE社の論文が、FBM整備訓練施設のWBSの例を載せている

• 1962年6月　国防総省とNASAのガイドに、「いま使われているものと本質的に同じ」WBSの記述が現れる

• 1962年10月　NASAが拡張版を出し、WBSはトップダウンで作れと明記する

　名前より先に、やり方のほうがありました。

　では、なぜ物で分かれたのか。

　ひとつは、作るのがミサイルだからです。推進装置があり、誘導装置があり、弾頭があり、発射装置がある。物を作る計画を分けようとすれば、まず物で分かれます。「設計工程」と「製造工程」で分けて、その下に推進装置をぶら下げる人は、たぶんいないでしょう。

　もうひとつは、当時の事情です。ポラリスは、順番に作っていては間に合わないので、同時に作ると決めた計画でした。ミサイルだけ出来ても、積む潜水艦がなければ撃てません。潜水艦だけ出来ても、水中から撃ち出す装置がなければ沈んだままです。誘導装置が間に合わなければ、どこへ飛ぶか分かりません。

　どれかが遅れた時点で、全部が止まります。全部で何を作るのかを一枚に書き出しておかなければ、どこが遅れているのかも分かりません。作業の一覧では、これができないのです。 A社の「設計」が80%で、B社の「製造」が40%。足したところで、ミサイルが撃てるかどうかは出てきません。

　みっつめが、お金です。1962年6月、国防総省とNASAが『DOD and NASA Guide: PERT COST Systems Design』という文書を公表します。名前に「COST」が付いているところが大事で、日程だけでなく、お金も同じ構造で扱うということです。費用を積み上げるには、何にいくらかかるかを紐づける先が要ります。

　その先に、なぜ作業ではなく成果物を置いたのか。ここから先は、裏の取れていない私の推測です。

　国が兵器を買うとき、契約の相手は1社とはかぎりません。機体を作る会社、エンジンを作る会社、電子装置を作る会社。費用を作業の単位で管理しようとすると、会社をまたいだ瞬間に合わなくなるはずです。A社の「設計」とB社の「設計」が、同じ範囲とはかぎらないからです。

　作るものの単位なら、そこは揃います。誰が作っても、機体は機体です。この構図は、いまの受託開発にもそのまま残っています。 元請けと協力会社で「設計」の範囲が違う。合わないのは見積りの精度ではなく、数える単位のほうです。

　推測だと書きましたが、同じころの文書に、方向の同じ書き方がありました。1963年12月の米空軍のPERT/COSTマニュアルです。

　政府と契約者が、一緒に分解する。作業ではなく「ハードウェア、サービス、装備、施設」に分ける、とも書かれています。

　なお、製造業の方は「部品表（BOM）に似ている」と思われたかもしれません。似ていますが、同じではないのです。WBSにはサービス（試験評価やプログラム管理）も入りますし、BOMが「出来上がったものの構成」を表すのに対して、WBSは「作るために何を揃えるか」を表します。そのうえで、骨の形はよく似ています。完成品があって、ユニットがあって、部品があって、材料がある。子を足すと親になる。上から下へ展開するもので、下から積み上げて作るものではない。似ているけれど、重なり切らない。 この距離感を持ったまま、先へ進んでください。

1-3. 「ファミリーツリー」は、規格より前からあった

　もうひとつ、規格より先にあったものがあります。

　1964年の米空軍の技術報告（ESD-TDR-64-208）に、WBSの定義が載っています。

　「ファミリーツリー」も「最終目的から下へ分けていく」も、1964年にはもう揃っています。規格になる4年前です。 あとで見ますが、1975年の軍用規格A版の定義は、これとほとんど同じ形をしていました。

　それから、PERT/COSTそのものの行く末にも触れておきます。この仕組みは、定着しませんでした。 広まらなかったのではないのです。1962年6月、国防長官とNASAが主要な兵器・宇宙計画の標準として採り、契約で課しました。そのうえで1960年代半ばに批判が強まり、1967年に、別の仕組み（C/SCSC。後編1-1で扱います）へ置き換わっていきます。受注者の側に、社内用と政府提出用の二重の仕組みができてしまったことが、理由のひとつに挙げられています。

　道具だけが残って、それを必要とした仕組みのほうは消えました。 親のほうが先に廃れて、WBSだけが残ったわけです。この構図は、後編でもう一度たどります。

2. 1968年、軍用規格になる

2-1. 億単位の買い物を、契約で管理するための道具だった

　1968年7月31日、国防総省は指令5010.20「Work Breakdown Structures for Defense Materiel Items」を出します。狙いは、複数の調達プログラムのあいだで一貫性を持たせることと、履歴のデータベースを作ることでした。

　その3か月後の1968年11月1日、指令を実施するための規格として MIL-STD-881が発行されます。 表題を直訳すると「国防用資材品目のためのワークブレークダウンストラクチャ」。対象が「品目」。ここに、この規格の性格が出ています。

　A版の冒頭には、適用の範囲が4つ書かれていて、そのうちのひとつが「研究開発・試験評価費（RDT&E）が1,000万ドルを超えると見積もられるもの」でした。現行のF版の前書きは、もっと端的です。「すべてのACAT（調達カテゴリ）プログラムに対して必須」「契約要求に含めるべきもの」。

　億単位の買い物を、契約で管理するための道具でした。 Excelで週次の進捗を追うために作られたものではないのです。

　ただし、だからといって理屈が無効になるわけではないのです。規模が違っても、「何を作るのかを一枚に書き出す」という必要は変わらないのです。借りるのは条文の権威ではなく、外している理由のほうです。 前編も、その立場で書きました。

　ここまでの12年を、一枚にしておきます。

2-2. 定義の中核は、47年動いていない

　A版は1975年4月25日に出ています。その3.4に、WBSの定義があります。

　「成果物指向のファミリーツリー」という言い方が、すでにここにあります。1975年です。原語は product-oriented family tree。この product という語は、後編3章でもう一度出てきます。

　現行のF版と並べてみます。

　中核の言い方は、同じです。「成果物指向のファミリーツリー」。47年、動いていません。

　違っているのは、その周りでした。構成要素は3つから5つに増えています（ソフトウェアと施設・設備が足された）。もうひとつ、1975年にあった末尾の一句が、定義からは消えています。「そのプロジェクトないしプログラムを完全に定義する」。ただし、なくなったわけではないのです。同じ趣旨の一句は、現行版では2.1に移っていました。 そこでは「すべての参加者が実施すべき作業の、完全な定義を与えるもの」になっています。完全に定義する対象が、プロジェクトから作業のほうへ動いたわけです。

　ほかにも、「プロジェクトのエンジニアリング活動」が「システムズエンジニアリングの活動」に、「開発および製造のあいだ」が「取得前および取得のあいだ」に変わりました。動いたのは、軍の調達プロセスを指す言葉のほうです。

　ソフトウェアという語が1975年の定義になかったことには、少し考えさせられます。この道具は、ソフトウェア開発のために作られたものではないのです。 ソフトウェアのほうが、あとから乗ってきました。

2-3. 13年間だけ、規格ではなかった

　この規格は、いまも生きています。最新はF版で、2022年5月13日。1968年の原版から数えて、54年のあいだに8回の改訂がありました。そのうち2回は、規格ではなく手引としての改訂です。

　1998年から2011年までは、規格（STD）ではなく手引（HDBK）でした。

　この差は、表紙に出ています。 2005年の手引の表紙には「この手引は指針にすぎない。要件として引用してはならない」と刷ってあります。現行のF版の前書きは逆で、2-1で見たとおり「契約要求に含めるべきもの」とされています。

　同じ道具が、13年間だけ「守らせないもの」として置かれていたわけです。理由までは確かめられませんでした。1990年代は軍用規格そのものを見直した時期でもあるので、WBS固有の事情かどうかも分かりません。

　この13年が、次の章に効いてきます。

3. 「最低3階層」には、出どころがあった

3-1. 書いてあったのは、「報告のために推奨される最小限」

　前編では「根拠にできる条文は見つけられませんでした」と書きました。現行のF版には、段数を定めた規定が見当たらないからです。

　出どころは、ありました。 1998年から2011年まで規格ではなかった、あの手引のほうです。MIL-HDBK-881A（2005年）の 1.4.1c に、こうあります。

　「推奨される最小限」。「最低3階層」は、読み替えではなかったのです。書いてありました。

　もっとも、「上位3階層」という括り自体は、手引より前からありました。1975年のA版は、3.5で「サマリーWBS」を、この規格が定める上位3階層からなるものと定めています。ただし、そこに「最低」という語はありません。括りが先にあって、手引がそれを「報告のために推奨される最小限」と言い直した。 その順序です。

　そして、これは報告のための推奨であって、分解の義務ではないのです。何段に割るかではなく、どこまで見せるかの話でした。

3-2. 同じ文書の中で、言い方が4つに食い違っている

　もうひとつ、困ったことがあります。

　1.6.3c は「一般に、上位3階層で足りる」。こちらは上限のようにも読めます。1.6.5 は「上位3階層が、WBSにおいて規定される」と言い切り、1.6.6 にいたっては、プログラムWBSは「少なくとも3つのプログラムレベルからなる（at least three program levels）」。

　最小限、足りる、規定される、少なくとも3つ。 同じ文書の中で、この4つが同居しています。

3-3. そして、いまの規格には、その数字がない

　現行のF版には、「3階層」という数字そのものがありません。 「上位3階層（top three levels）」という言い方は、全文を検索しても出てきません。

　手引1.6.5にあった「上位3階層が規定される」という一文も、1.6.6の「少なくとも3つのプログラムレベル」も、F版の対応箇所からは落ちています。落ちたのは冒頭の一文で、レベルごとの説明はそのまま残り、レベル4・5まで伸びました。

　段数について書いているのは 1.5.3c で、こうです。

　数が消えて、相談事になりました。

　まとめると、こうです。「最低3階層」と書いてあったのは、表紙に「要件として引用してはならない」と刷ってある文書の、報告のための推奨だった。そこから17年たった現行の規格には、その数字がありません。

　では、段数は何でもよいのか。そこは、いま引いた条文が答えています。 「報告のために何段見せるか」は相談事ですが、「管理のために何段まで定義するか」は、必要なところまで、と書いてある。前編で書いたことと同じです。1段しかない200行の紙では、親で足して検算することも、一部を切り出して誰かに渡すこともできません。規定がないからといって、何段でもよいわけではないのです。

4. 規格は、WBSをこう定義している

4-1. 定義の続きに、動かし方が書いてある

　前編の最後と、2-2の図表で見た定義が1.5.3aです。その次の項（1.5.3b）に、こう書かれています。

　末尾の「より細かい階層の下位成果物へと分けていく」。ここに、この道具の動かし方が書かれています。完成形から下へ、下へ。 上から順に細かくするのであって、細かいものを集めて上を作るのではないのです。1-2で見たとおり、1962年のNASAの文書がすでに「トップダウンで作れ」と書いていました。

4-2. 入れてよい側の境目は、条文からは出てこない

　入れてはいけないものは、2.2.5.1に並んでいます。設計エンジニアリング、テストエンジニアリング、要求分析、アルミニウム、直接費。前編で引いたとおりです。

　ここでは、前編で触れなかったことを3つ足します。

　ひとつ。規格が挙げている「成果物」の例が、思ったより身近です。信号処理装置が成果物であり、モックアップやソフトウェア構成品目も成果物である、と条文に書かれています。外形の模型も、ソフトウェアの構成単位も、成果物として木に乗るのです。

　ふたつ。規格は、成果物指向を「形式」ではなく「目的のための条件」として書いています。F版の2.1に、こうあります。

　「使うためには」。 成果物指向は、規則を守るための決まりではないのです。この木を、目標を伝える枠組みとして使いたいのなら、そうでなければならない。そういう言い方になっています。

　みっつ。これは、私にとって都合の悪いことです。規格が原理を書いていないわけではないのです。 2.2.5 には「WBSは成果物指向である。必要な成果物を扱うのであって、それに伴う機能や費用を扱うのではない」とあり、2.2.5.1 は外した理由も書いています。機能の切り出し、材料という資源、会計上の分類。

　書かれていないのは、その先です。 システムズエンジニアリングやプログラム管理は、どう見ても「機能」に見えます。それがなぜ成果物の側に入るのか。そこは理由ではなく、列挙で決まっています。入れてよい側の境目は、条文からは出てこないのです。

　前編では、入れてよい欄かどうかを「その欄が終わったとき、外から人を1人連れてきて、終わったかどうかを判定してもらえるか」で見分ける、という線を引きました。けれど、あれは私が引いた線であって、規格が引いた線ではありません。

　ちなみに、テストの計画でよく見る「テスト計画／テスト設計／テスト実装／テスト実行」も、同じ理屈で外れます。これは作業の順番であって、作るものの木とは別のものです。直すなら、テストの成果物を、対象のシステムの下に置くことになります。

5. ただし、作業が消えるわけではない

　ここで気をつけたいことがあります。規格は「作業を扱うな」と言っているのではないのです。

　F版の2.1に、「すべての参加者が実施すべき作業と、参加者のあいだに必要なインタフェースの、完全な定義を与えるものである」とあります。1.5.3bにも「達成すべき作業の要素を、互いに、また最終成果物に関係づける」とあります。作業は作業として、ちゃんと出てきます。

　違うのは、並べる軸のほうです。作業を作業の順に並べるのではなく、作るものの構造に紐づけて置く。そうすると、どの作業がどの成果物のためのものかが、紙の上で分かります。

6. この木は、報告の土台として作られている

　WBSが単なる図ではなく、管理の土台として作られていることが、よく出ているところがあります。F版の1.4です。

　EIA-748というのは、出来高管理（EVM）の仕組みが満たすべき決まりを並べた米国の規格です。出来高管理は、計画していた分、出来た分、かかった分の3つを突き合わせて、費用と日程の両方のずれを出すやり方だと考えてください。

　その報告の土台が、WBSなのです。

　報告のためなので、規格はWBSを大きく2つに分けています。プログラムWBS（政府側の分も含めたプログラム全体）と、契約WBS（プログラムWBSのうち、その契約に当たる部分を、合意した報告階層まで展開したもの）。ほかに、下請WBSも立っています。どこまでを誰に見せるか、が設計に入っているわけです。

　前編で、成果物で分けると進捗を本人以外の人も判定できるようになる、と書きました。「基本設計 90%」は本人にしか分かりませんが、「承認済みの基本設計書があるか」なら誰にでも分かる、という話です。外に出た判定は、契約の相手に見せることができます。感覚で動く数字を土台にして、億単位の買い物の出来高を報告するわけにはいきません。

　ただし、WBSだけで出来高管理が回るわけではないのです。 出来高管理では、WBSの要素と、組織の側の分解を掛け合わせて、予算と責任者を置く単位を作ります。

　規格が「組織の構造を土台にするな」と言っているのは、組織という軸が悪いからではありません。組織は別の軸として置かれていて、2つを掛けて使う形になっているからです。 片方だけ借りて「組織はだめ」と読むと、借り方を間違えます。

　同じことは、記事の筋にも返ってきます。成果物で分ければ出来高を報告できる、というほど単純ではないのです。報告の階層の合意、基準線（ベースライン）の設定と凍結、変更の管理、報告様式の契約化。WBSは、その最初の一枚にすぎません。

7. 既製のWBSが10本。開けてみたら、製品の構造は4つ

　この規格には、分野ごとのWBSが、あらかじめ付録として用意されています。F版の付録はAからMまでの13本で、そのうち分野別はAからJの10本。残る3本は、共通要素（付録K）、サステインメント（L。運用と維持のこと）、政府によるシステムの試験と評価（M）です。

　現場が毎回ゼロからWBSを考えるのではなく、分野ごとの型が渡される形になっています。

　型を配れるのは、作るものの構造が、分野で決まっているからです。ミサイルを作る会社が10社あっても、推進装置と誘導装置と弾頭があるところは変わりません。作業の順番は、そうはいきません。会社ごとに違いますし、同じ会社でも案件ごとに違います。作業で分けていたら、型を配ることができないのです。

　逆に言えば、作るものの構造が案件ごとに違う分野では、この前提が成り立ちにくいということにもなります。ミサイルには推進装置と誘導装置と弾頭がありますが、業務システムに毎回同じ部品があるとはかぎりません。規格をそのまま持ってくるときに、いちばん気をつけたいところです。

　ただし、中身を開くと、話は少し複雑になります。

　付録A（航空機システム）のレベル2は、16項目あります。先頭は「航空機システムの統合・組立・試験」。作るものというより、活動の名前です。

　続いて、機体、ペイロード／ミッションシステム、地上・ホストセグメント、航空機システムのソフトウェアリリース。作るものの名前は、ここだけです。4つ。

　残る12は、システムズエンジニアリング、プログラム管理、システム試験評価、訓練、データ、専用支援装備、共通支援装備、運用／サイト立ち上げ、契約者による後方支援、工業施設、初度スペアと修理部品。先頭の「統合・組立・試験」も、この仲間です。

　これを「共通要素」と呼んでいるのは、規格の側です。 付録K.3が、この12項目を共通要素として定義しています。付録AからJまでに共通して効くものです。

　つまり、この型の4分の3は、作るものの構造ではなく、製品に依らない共通の要素でできている。 割合は分野でかなり違います（宇宙システムの型はレベル2が5項目で、うち4つが製品です）。それでも、共通要素がどの型にも入っていることは変わりません。2-2の定義で見た「サービスも構成要素に入る」が、実物の木で裏づけられる形になっています。

　型を配れる理由も、言い直しておきます。作るものの構造が分野で決まっているから、というのは半分です。もう半分は、受け手が一人（政府）で、契約で揃えさせられるからです。881が揃えさせているのは、現場の仕事の進め方ではなく、分野ごとの上層の木の形のほうでした。

　それから、付録Lに「サステインメント」が別に立っていることにも、意味があります。開発と製造の成果物の木だけでは、運用の段階を扱えない。規格の側も、そこは認めているわけです。

8. 手元に持ち帰れるのは、2つです

　年号の話が続きました。この回で手が動くのは、ここからの2つです。

8-1. 自分の会社の工数実績コードは、何で切られているか

　置き場所が効くのは、そこにお金と責任が紐づいているときだけです。

　軍の調達では、WBSの要素が原価を集計する軸になります（正確には、6章で見たとおり組織側の分解との交点です）。だから置き場所が死活問題になる。

　手元の紙がそうなっているかどうかは、自分の会社の工数実績コードが何で切られているかを見れば分かります。工程で切られているなら、WBSの行をいくら直しても、月末に出てくる数字は変わりません。

8-2. 辞書は、独立した紙にすると死ぬ

　段数の決まりはありませんが、規格が作れと書いているものがあります。WBS辞書（WBS Dictionary、2.2.4）です。

　木の図だけでなく、要素ごとに、それが何なのかを文章で書いた辞書を作れ、と。各要素の定義、階層の関係、その要素が使う資源やプロセス。しかも「プログラムの現在の状態を反映していなければならない」とされています。

　これが機能しているのは、契約で提出させる成果物になっているからです。提出義務があって、契約データとして受け取られる。だから書かれる。規格に書いてあるから書かれるのではないのです。

　では、手元の現場に持ち込めるか。辞書という独立した紙を作っても、たぶん死にます。 読む人がいない紙は、更新されません。更新されない辞書は、現物と食い違って、無いより始末が悪くなります。

　持ち込むなら、すでに読む人がいる紙に寄生させることだと思います。納品物の一覧か、検収の基準か、要件定義書の成果物の定義。そこに1列足す。

　足す内容は、定義の1行ではないのです。含むもの。含まないもの。完了の判定。前提と依存。 この4つになります。

　「移行データ」で揉めるのは、それが何を指すかではなく、何が入っていないかのほうです。過去何年分か。削除済みのレコードは入るのか。添付ファイルの実体は。名寄せの責任はどちらか。定義の1行は、このどれにも答えません。

9. 根拠と断り書き

　ここから先は、本文で引いたものの出どころと、言い切れていないところです。読み飛ばしていただいて構いません。まとめと後編へのリンクは、その下にあります。

　規格について

• 引用した規格はいずれも英文で、和訳は筆者によるものです。MIL-STD-881A（1975年）、MIL-HDBK-881A（2005年）、MIL-STD-881F（2022年）

• 定義を比べたのはA版とF版です。1968年の原版は、本文のPDFを見つけられませんでした。B版・C版・D版・E版と、1998年の手引の定義文は確かめていません。なお2005年の手引（1.6.3a）では、構成要素5つも「システムズエンジニアリングの活動」も、すでに現行版と同じでした。動いた中間点が、ここにあります

• 各版の日付は、表紙にある「置き換えた相手」の記載からたどりました。表紙まで確かめたのはA版・HDBK-881A・F版の3つで、B版・C版・D版は規格アーカイブの各版のページによります

• 4-2で引いたF版2.1と同じ趣旨の文は、2005年の手引（2.1）にもあります。「成果物指向でなければならない（must）」のほうは、手引の時代から同じです。変わったのはその次の一文で、要素が識別可能なワークプロダクトを表すことを、手引は「〜すべき（should）」、現行のF版は「〜でなければならない（must）」。2-3で見た手引と規格の差は、ここでは一段ぶんだけ出ました

• 7章で「既製のWBS」と呼んでいるものを、規格は standardized WBS（2.4）と呼んでいます。なお family tree はF版に4か所しかなく、いずれもWBSの構造そのものを指す語で、付録を指して使われてはいません

• 7章の共通要素は、本文1.5.4の列挙では11項目で、「契約者による後方支援」だけが抜けています。定義のある付録K.3は12項目。規格の中で、数が揃っていません

• 4-2で「外れる」と書いているのは、国防調達のWBSの中での話です。 手元の紙が規格違反になるわけではないのです

• 6章の出来高管理の説明は、実務についての一般的なものです。EIA-748の条文に当たって書いたものではありません

　歴史について

• 1-2の年表の出典は『Work Breakdown Structures』（Norman、Brotherton、Fried。Wiley／PMI）です

• PERTの年には、気をつけたほうがよさそうです。英語版Wikipediaは、WBSの項で「1957年」、ウィラード・ファザーの項で「1958年1月27日に、特別計画部がPERTを定式化する作業をチームに指示した」としていて、食い違っています。1957年の根拠は二次資料によるもののようです。ここでは、1957年に構想が出て、1958年に手法としてまとまった、としました

• WBSをファザー個人の発明として書く解説を見かけますが、そこまでは言えないようです。彼の経歴や論文の一覧に、WBSへの言及は見当たりませんでした。PERTの論文には名を連ねていますが、それとWBSを作ったこととは別です。ここでは、彼が率いたチームの仕事の中から出てきた、という書き方にとどめています

• 1962年6月の『DOD and NASA Guide: PERT COST Systems Design』は、書誌｜HathiTrustと英語版Wikipediaによります。Wikipediaは策定に関わった業界も発行者に数えていますが、ここでは文書名のとおり2者としました。文書そのものには当たれていません

• 1-2の引用は米空軍PERT/COSTマニュアル 1963年12月、1-3の引用はESD-TDR-64-208（1964年。前者と同じ題名のマニュアルの、より早い版を要約したものです）

• ESD-TDR-64-208が要約したマニュアルは、1962年12月に作られ、1963年3月に改訂されたものです（報告の前書きによる）。ただし、その改訂版そのものには当たれていないので、「ファミリーツリー」がそこにあったかどうかは分かりません。1963年12月のマニュアルに、この語は出てきませんでした

10. まとめ

　長い回になったので、畳んでおきます。

• 名前より先に、やり方のほうがありました。 1959年の論文の図版に分解が載り、1961年には語そのものが説明なしで通じています。1962年のPERT/COSTの文書で手法として記述され、1968年11月1日に軍用規格になりました

• 「ファミリーツリー」は、規格より4年早い。 1964年の空軍の文書にあります

• 定義の中核は、47年動いていません。 動いたのは、調達プロセスを指す言い回しと、末尾の一句のほうでした

• 「最低3階層」の出どころは、2005年の手引。 書いてあったのは「報告のために推奨される最小限」で、いまの規格からは数字ごと消えています

• 規格は、作業を扱うなとは言っていません。 作業が置かれる場所を、成果物の木の下だと決めているだけです

• 既製のWBSを開けてみたら、作るものの名前は4分の1でした。 型を配れるのは、構造が分野で決まっているからでもあり、受け手が政府ひとりで、契約で揃えさせられるからでもありました

• 持ち帰れるのは2つ。 自分の会社の工数実績コードが何で切られているか。WBS辞書にあたるものを、どの紙に反映させるか

　成果物で分ける理由は、3つにまとまります。 進捗の判定が変わること（前編で扱いました）。費用が、会社をまたぐこと（1-2）。作るものの構造が、分野である程度決まること（7章）。

　では、体系の側はどうなのか。 私たちが日常で触れているのは、軍の規格ではないのです。PMBOKであり、JISであり、ネットに転がっている雛形です。そちらでも、同じ筋が通ってきたのか。

　PMBOKはWBSをどう扱ってきたのか。JISは何と書いているのか。いま話題のSBOMと、どこが地続きなのか。そして「作業分解図」という訳語を、どう扱えばよいのか。ここまで書いてこなかった問い、なぜ軍の調達規格がプロジェクト管理の土台になったのかも、後編で答えます。

#WBS #プロジェクトマネジメント #プロジェクト管理 #歴史 #規格 #品質管理 #IT業界

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

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

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

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

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

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

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

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