【WBS再入門 前編】あなたのWBSは、たぶんWBSではない　やってしまう11の分け方と、直し方

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

　いま使っているWBSを、思い浮かべてみてください。

　左に「要件定義」「基本設計」「実装」「テスト」が縦に並んでいて、右に担当者と開始日と終了日、いちばん右に進捗率のパーセント。たぶん、そういう形だと思います。私もそうでした。

　その紙は、WBSではありません。

　意地悪で言っているのではなく、WBSを定めた規格の理屈を借りると、そう言えます。規格のどこにそう書いてあるかは、記事の終わりで解説します。

　以下、WBSと呼ばれているその表を「紙」と呼びます。全3本の連作ですが、手元の紙を直すいちばん大きな一手は、この前編で出し切ります。 なお出典と断り書きは、読みの流れを切らないよう、記事の最後にまとめました。

この記事のポイント

• WBSは表ではなく、作るものを枝分かれさせた木です。 だから見るのは、レベル2とレベル3の2階層だけ。並んでいる言葉が「作るもの」か「やること」か、それだけで判定できます

• 直し方は3つ。 完成形を1つ据える。名詞で分ける。足して100%になるかを確かめる。分け直すと、検証環境・移行データ・利用者マニュアルのような、抜けていたものが表に出てきます

• いちばん変わるのは、進捗の判定です。 「基本設計 90%」は本人に聞くしかありませんが、「承認済みの基本設計書があるか」なら誰にでも分かります。進捗会議の水掛け論の半分は、たぶんここから来ています

1. 見るのは、2階層だけ

　まず、階層の数え方をそろえます。いちばん上、プロジェクトそのものを指す1行がレベル1。その下の「大項目」がレベル2、「中項目」がレベル3です。

　ただし、プロジェクト名の行がない紙のほうが多いと思います。A列が「1 要件定義」から始まっている形です。この紙では番号が1段ずれて見えます。番号ではなく段で数えて、大項目をレベル2と読んでください。

　見るのは、レベル2とレベル3。この2階層で足ります。

　そこに並んでいる言葉に、問をひとつ当ててみます。

　これは「作るもの」か。それとも「やること」か。

　判定は、これだけです。

2. いちばん多いのは、工程で分けている形

　レベル2に「要件定義」「基本設計」「詳細設計」「実装」「テスト」「移行」。左端がこの並びなら、ほぼ確実にここです。

　きれいに並ぶので、見た目は整います。整いすぎると言ってもいいくらいです。

　これは、規格が外しているものと理屈が同じです。

　根拠にする規格を、先に名乗っておきます。MIL-STD-881F（ミルスタンダード・はちはちいち・エフ）。1968年に米国防総省が出した軍用規格の、現行版です。米軍が兵器を買うときに、納入業者へ契約で守らせるためのもの。

　その 2.2.5.1 は、入れてよいのは成果物だけだとしたうえで、入れてはいけないものを並べています。

　「エンジニアリング作業を機能で切り出したもの」とは、仕事の役割で切ったもの、という意味です。設計をする役割、テストをする役割、要求を分析する役割。どれも、作るものを指してはいないのです。

　では、要件定義や基本設計はどうなのか。同じ条文の続きに、書いてありました。

　ここで言う「取得フェーズ」は国防調達の段階で、日本の受託開発の要件定義や基本設計と同じものではありません。それでも、理屈はそのまま重なります。ライフサイクルの段階で分けるな、と条文が名指しで書いている。 要件定義も基本設計も、ライフサイクルの段階です。

2-1. 工程で分けると、下に置くものがなくなる

　条文から離れて、実務の話もしておきます。

　「基本設計」の下に、何を置きますか。

　たいていは「基本設計を行う」「基本設計書をレビューする」になります。その下は「画面設計を行う」。さらに下は「画面一覧を作る」。作るものが出てこないまま、下へ下へと降りていく。どこまで行っても、語尾が動詞のままです。

　この形には、もっと重い弱点もあります。

　この紙を見ても、何を納品するのかが分からないのです。

　要件定義、基本設計、詳細設計、実装、テスト、移行。6つ全部に丸が付いたとき、お客さまの手元に何が残るのか。紙のどこにも書いていません。書いていないものは、見積りにも入りません。

3. 次に多いのは、日付と進捗率の列

　開始日、終了日、進捗率。この3列が入っていたら、それはもうスケジュールです。

　PMBOKを出している団体、PMI（Project Management Institute）のライブラリにある論文が、こう書いています。WBSは「プロジェクトを遂行するために踏むプロセスの記述ではない〔中略〕。成果物がどのように、あるいはいつ作られるかを定めるスケジュールを扱うものでもない」。いつの話は、WBSの仕事の外にあります。

　もちろん、実務では1枚で済ませたくなります。それ自体を止めるつもりはないのです。困るのは、順番のほうです。 日付の列が最初からあると、作るものの構造を考える時間が、日付を埋める時間に食われます。

　進捗率の列は、もっと困ります。作業の進み具合は、本人の申告でしか分かりません。90%が3週間続く行に、心当たりはないでしょうか。なぜそうなるのかは、7章で扱います。

4. あとの9つは、一行ずつ

　残りは9つ。一行ずつ挙げていきます。心当たりのあるものが、いくつあるでしょうか。

• 組織や担当で分けている……レベル2が「設計チーム」「開発チーム」。規格は「プログラム事務所や契約者の組織の構造を、WBSの土台として使ってはならない」と、命令の形で書いています。チームをまたぐ成果物が、どこにも載らなくなります

• 費目や分類で分けている……「人件費」「ライセンス費」「外注費」。外注費が300万円を超えていると分かっても、どの成果物のための300万円なのかが読めません。削る相談ができないのです

• 人の名前が、要素になっている……「田中さん担当分」。人が抜けると紙が壊れます。中身は、田中さんの頭の中にしかありません

• 階層が、1段しかない……200行の一覧表。1段というのは、分解をしていないのと同じです。親がないので、足して検算することも、一部を切り出して渡すこともできません

• 要素が動詞で終わっている……「テスト設計を行う」「環境を構築する」。直し方は6章で扱います

• 足して100%になっていない……見ただけでは分からない唯一の型です。これも6章で

• 「その他」「共通」という要素がある……足して100%にならないときに差分を押し込む場所があると、検算が永遠に通ってしまいます。漏れは、ここに隠れます

• 粒度が、ばらばら……「基幹システム刷新」と「画面のボタン色変更」が並んでいる形。たいてい、気になっていることを忘れないように書いたものです。メモはメモの紙に書く

• 工程の下に、成果物をぶら下げている……ここまでの10より、ずっとよく出来ている形です。いちばん惜しいので、6章で別に扱います

5. いくつ、当てはまりましたか

　ここまでが、11の型です。一枚にまとめておきます。

　さて、いくつ当てはまったでしょうか。

　ひとつも当てはまらなかった方へ。 この先は、なぜ当てはまる紙のほうが出回っているのか、という話になります。

　1つか2つの方へ。 直せます。直し方は6章です。ただし、2章（工程で分けている）と3章（日付と進捗率）は、たぶんほとんどの紙に当たります。この2つだけなら、3つめを探すより、工程の1点を見直すほうが早いと思います。

　3つ以上当てはまった方へ。 ここは、言い方が強くなります。その紙は、WBSという名前で呼ばれているだけの別の紙です。スケジュールか、作業の一覧か、体制図か、そのどれかに近いものだと思います。

　別の紙であること自体は、悪いことではありません。 行き先が決まっている仕事なら、作業計画書として十分に役に立ちます。誰がいつ何をするかを決めて、追いかける。それができる紙です。

　悪いのは、WBSだと思って使っていることのほうです。 WBSにできるはずの仕事、たとえば「これで全部か」の検算を、その紙はできません。できないまま、できるつもりで使われています。

　見積りが外れる場所は、だいたいそこです。 チームをまたぐ成果物。検証環境。移行と教育。どれも、作業の一覧には行がないのです。紙にない行は、誰も見積もれません。

5-1. この形は、あなたが考えたものではない

　気が重くなった方もいると思います。

　同じ形が、繰り返し出てきました。

　日本語で「WBS 作り方」「WBS テンプレート」と検索して、上位に出てくるページを5件見てみました。このうち、列の構成まで確かめられた3件が、ほとんど同じ形をしていました。大項目は3件とも工程。タスクは動詞で終わっている。日付と進捗の列が、最初から入っています。真面目にテンプレートを探して、真面目に埋めた人ほど、この形になります。

　1件は、カレーを作る例で説明していました。大項目が「具材を切る」「炒める」「煮込む」。中項目が「玉ねぎを切る」「にんじんを切る」。最上位から最下層まで、すべて動詞です。 完成したカレーは、紙のどこにも出てきません。

　面白いのは、文章と雛形が、食い違っていたことです。きちんと「成果物ごとに階層的に分解して」と書いているページもありました。しかも、その同じ会社の、同じサイトの中でです。定義のページには成果物と書いてあり、テンプレートのページを開くと大項目は「企画／設計／開発／公開」。

　どちらを長く見ることになるかは、考えるまでもないでしょう。定義の1文を読むのは一度きりで、雛形は何週間も開くことになります。手が覚えるのは、雛形のほうです。

　もうひとつ、裏の取れていない推測を書いておきます。確認した範囲では、WBSの訳語はどれも「作業」から始まっていました。見様見真似で作ろうとしたとき、定義の1文より先に目に入るのは、この名前のほうだと思います。訳語そのものの話は、後編で扱います。

6. 成果物で分け直すと、こうなる

　では、どう直すか。順番は3つです。

1. いちばん上に、完成形を1つ据える

2. その完成形を、部分に分ける。部分は、すべて名詞

3. 足して100%になっているかを確かめる

　同じ案件を、2通りに分けてみます。工程で分けると、レベル2は「要件定義／基本設計／詳細設計／実装／テスト／移行」。成果物で分けると、「受注機能／在庫機能／帳票／移行データ／利用者マニュアル／検証環境」になります。

　違いが、いちばん右の列に出ます。 工程で分けた表の右端は進捗率で、成果物で分けた表の右端は完了の判定です。「基本設計 90%」と「利用者マニュアル：利用部門のレビューが済んでいる」。前者は本人に聞くしかなく、後者は見れば分かります。

6-1. 手順2。語尾を、残るものに変える

　4章で挙げた「要素が動詞で終わっている」は、ここで片づきます。

• テスト設計を行う → テスト設計書

• レビューを実施する → レビュー記録

• 環境を構築する → 検証環境

• 性能を測定する → 性能測定結果

　ところが、どの行も変えられるわけではないのです。変えられない行が、必ず出てきます。 ここは、2つのパターンです。

　ひとつは、何が残るのかを決めていない行です。「調整する」「検討する」「対応する」。決めてから書くことになります。決まっていないものに、工数を積んでいた。 言い方を変えると、そういうことになります。「ベンダーと調整」に5人日と書いてある行を、どうやって見積もったのか。たぶん、勘です。何が出来たら終わりかを決めていない行は、勘で積むしかないのです。

　もうひとつは、そもそも残るものが出ない行です。他社との結合試験の立会い。利用者からの問い合わせ対応。障害の切り分け。無理に名詞を当てると「立会い報告書」のような紙が生まれるだけで、判定基準に合わせて書類を作っただけになります。こちらは、名詞に直さないでおくほうがよいと思います。

6-2. 手順3。足して100%になるか

　4章で「見ただけでは分からない」と書いた型が、これです。

　100%ルールは、下位レベルの作業の合計が、親の作業の100%と等しくなることを求めます。MIL-STD-881F の付録にも、PMIの文書にも出てきます。

　ここで、よく聞かれることを先に書いておきます。足すのは、工数でも金額でもないのです。「作るもの」です。

　電卓は要りません。レベル2の要素を順に読み上げて、「これで全部できたら、このプロジェクトは完成か」と聞くだけです。

　完成しないなら、足りないものがあります。同じものが2回出てくるなら、超えています。

　この検算は、たいてい2か所で引っかかります。

　ひとつは、足りないほう。いちばんよく抜けるのが、移行、運用の引き継ぎ、ドキュメント、教育です。どれも「作るもの」なのに、工程で分けた紙には居場所がないのです。

　もうひとつは、2回出てくるほう。設計のところにも、テストのところにも「テスト仕様書」が出てくる、といったものです。

　どちらでもなく「数えようがない」なら、それが答えです。要素が成果物になっていないので、足し算そのものが始まりません。 「基本設計」と「実装」を足しても、何にもなりません。

6-3. いちばん惜しい形を、ひっくり返す

　4章の最後に挙げた、工程の下に成果物をぶら下げている形です。

　レベル2は工程。ただし、レベル3がその工程の成果物になっている。「基本設計」の下に「画面設計書」「DB論理設計書」が並び、作業はレベル4から。日本の受託開発では、たぶんこれがいちばん多い形だと思います。

　これは、かなり良い形です。成果物が表に出ているので、何が出来たかを言うことができます。それでも、問題が2つ残ります。

　工程をまたぐ成果物が、どこにも入りません。 移行データも検証環境も、特定の工程の持ち物ではないので、置き場所がないのです。もうひとつ、同じ成果物が2か所に出ます。 設計の下にも「テスト仕様書」、テストの下にも「テスト仕様書」。足すと100%を超えます。

　直し方は、レベル2とレベル3をひっくり返すだけです。上を成果物にして、工程はさらに下の段へ落とす。「受注機能」の下に「画面設計書」「テスト済みコード」「テスト結果の記録」を並べる。載っている情報は、ほとんど同じです。

　この入れ替えをすると、さっきの2つが片づきます。移行データは移行データとしてレベル2に立つ。テスト仕様書は、それが属する機能の下に1回だけ出ます。

6-4. 工程に見える欄が、全部だめになるわけではない

　ひとつ断りが要ります。

　MIL-STD-881はサービス（システムズエンジニアリング、システムの試験と評価、プログラム管理など）を要素として認めています。レベル2に「プロジェクト管理」が入ることはあります。

　では、何が入ってよくて、何がだめなのか。手元で引ける線は、ひとつです。

　その欄が終わったとき、外から人を1人連れてきて、終わったかどうかを判定してもらえるか。

　「基本設計」は、判定できません。何をもって終わりかを決めていないからです。「承認済みの基本設計書」なら、判定できます。「プロジェクト管理」も、計画書と報告書という渡すものがあるので、判定できます。

　全部を工程で埋めるのが問題であって、工程に見える欄が1つ混じっていること自体が問題なのではありません。

7. 進捗の判定が、本人の外に出る

　成果物で分け直すと、進捗を、本人以外の人も判定できるようになります。

　この章は、それだけの話になります。

　3章で触れた「90%が3週間続く行」に戻ります。なぜそうなるのか。作業には、終わりの線が引かれていないからです。 「画面設計を行う」が終わったと言えるのは、一通り書いたときか、レビューが済んだときか、指摘が直ったときか。決めていないので、本人の感覚で答えるしかないのです。

　成果物を単位にすると、変わります。その文書があるか。動くか。レビューが済んでいるか。本人以外にも見えるものになります。 進捗会議で起きていた水掛け論の半分は、たぶんここから来ています。

　同じことを、英国生まれのプロジェクト管理手法PRINCE2の進め方を説明した文章が、短く言っています。

　ただし、「出来たか出来ていないかの二択になる」とまでは言えません。 設計書ひとつ取っても、初版がある、指摘が未反映、承認済み、といった段があります。細かく刻めば「8個中7個が完了」に置き換わるだけで、残り1個がいつ終わるかは残ります。二択になるわけではないのです。変わるのは、誰が判定できるかです。

8. 明日できることは、2つです

　ここまで読んで、月曜の朝にExcelを全部書き直そうと思った方へ。そこまでしなくてよいと思います。

　ひとつ。工程をまたぐ成果物のための行を、レベル2に1本立てる。 移行、検証環境、教育、運用の引き継ぎ。いまの紙が工程で並んでいても、ここに1本足すだけで、抜けの大半が表に出ます。

　ふたつ。同じ成果物の名前が2か所に出ていたら、片方は成果物ではなく作業です。 片方を消すか、名前を変えるか。足して100%を超えている印です。

　この2つだけで、抜けと重複はかなり減ります。 レベル2とレベル3をひっくり返すのは、そのあとでかまいません。

8-1. そのかわり、失うものがあります

　片側だけ並べるのは、たぶん不誠実です。成果物で分け直すと、工程で分けていたから出来ていたことが、出来なくなります。

　以下はベンダー社内の事情が中心になります。発注する側で読んでいる方は、ベンダーが工程の形でWBSを出してくるのには、こういう事情がある、という目で読んでみてください。

• 契約との対応が切れます。 日本の受託開発では、工程で区切った多段階契約が広く使われています。工程末に検収があり、支払条件もそこに付いている。ひっくり返すと、契約のどこまでが終わったのかが読めなくなります

• 社内に溜まっている数字が、使えなくなります。 工数の実績コードも、レビュー指摘密度も、たいてい工程単位で持っています。軸を変えると、比べる相手を失います

• 提案の時点では、作れません。 最初のWBSを作るのは提案のときで、その時点で機能が何本になるかは決まっていません。工程なら、スコープが未確定でも作れました

• 横串の仕事が、宙に浮きます。 アーキテクチャ設計、セキュリティレビュー、性能の全体最適。どの機能の持ち物でもないので、置き場所を決め直す必要が出ます

　ただし4つめは、置き場所を作ることができます。 方式設計書、セキュリティの評価結果、性能試験の報告書。これらをレベル2に1本立てて、その下にぶら下げる。規格がサービスを要素として認めているので、「プロジェクト管理」と同じ扱いです。

　4つを並べたうえで言うと、「ひっくり返すだけ」は言い過ぎでした。載っている情報はほとんど同じですが、紙が刺さっている先が変わります。 契約、原価、品質、顧客への報告、要員の計画。ひっくり返すというのは、ここを全部引き直すという意味です。

　そのうえで発注する側の方は、「移行データと検証環境と利用者マニュアルは、どの行に入っていますか」と聞いてみてください。それが、この記事のいちばん実用的な使い道かもしれません。

9. では、WBSとは何なのか

　11の型に当て、直し方まで見てきました。最後に、そもそもWBSとは何だと決められているのかを見ておきます。MIL-STD-881F の 1.5.3a は、こう定義しています。

　ファミリーツリー。家系図です。 表ではなく、木でした。

　この一文が、いつからこの形なのか。中編では、そこをたどります。出発点は1950年代の後半、米海軍のポラリス・ミサイル計画です。

　そして、「WBSは最低3階層」という、よく見かける説明の出どころも、中編で分かりました。 根拠はありました。ただし、書いてあったのは「報告のために推奨される最小限」で、しかも現行の規格からは、その数字ごと消えています。

　そのうえで「なぜ軍の調達規格がプロジェクト管理の土台になったのか」という問いが残りますが、そちらは後編で扱います。

10. 根拠と断り書き

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

　規格について

• 根拠にした規格は MIL-STD-881F（2022年）。引用はいずれも和訳が筆者によるものです。2章の引用は 2.2.5.1、組織の条文は 2.1 と 2.2.5.1、100%ルールは分野ごとの付録（A.3.2 ほか）、9章の定義は 1.5.3a

• 2章で「外れる」と書いているのは、国防調達のWBSの中での話です。手元の紙が規格違反になるわけではないのです。借りるのは、外している理由のほうになります

• 規格が名指しで外しているのは、組織の構造のほうです。工程と費目は、規格が外しているもの（取得フェーズ、資金の種別、会計上の分類）と理屈が一致する、という関係になります

• 6-4章で書いたとおり、サービスは入ってよい側にあります。「物しか入らない」規格ではないのです。 「プロジェクト管理」の扱いは、ここから来ています

• 「その他」については、規格の 4.3.1 が同じことを書いています。必要なら「その他」という語は残さず、要素として定義して置け。要らないなら使うな。ただし規格の「その他」は、付録の既製の型にない製品が出たときのための空き枠で、手元の紙の「雑務」とは出自が違います

• 「粒度がばらばら」は、規格の条文には書かれていません。ここは私の経験則です

• 「WBSは最低3階層」という説明をよく見かけますが、現行の規格に根拠にできる条文は見つけられませんでした。出どころは中編で扱います

　PMIの文書について

• 3章の引用は Applying the work breakdown structure to the project management lifecycle（Brotherton ほか、2008年）。文の途中から引いています

• 「名詞と形容詞を使い、動詞を使わない」は Creating effective work breakdown structures（2005年）

• 100%ルールは、PMIの『Practice Standard for Work Breakdown Structures』第2版（2006年）にもあります。こちらは原文に当たれておらず、第2版を紹介したPMIの論文によります

• 「WBSに動詞は一切出てこない」という話ではないのです。同じ文書は、最下層が動詞で表されるアクティビティにつながることがあるとしています。問題は、分解の軸そのものが動詞になっていることのほうです

• 工程で分けた紙では、工程の中だけなら足せてしまいます。100%ルールの検算が効くのは、軸を成果物に直したあとです

　テンプレートの調査について

• 5件を見ただけなので、日本語の解説がすべてこうだ、とは言えません。 個々のサイトを責める話でもないのです。図表も、各サイトの表そのものではなく、共通していた形をこちらで組み直した架空の例にしてあります

• 3件に必ずあったのは、WBS番号が「1 → 1.1 → 1.1.1」と振られていること、日付の列、進捗の列、担当者の列の4つです。列の名前と数そのものは、3件それぞれでした

• 成果物の列は、3件のどれにもありました。ただし、それは列であって、軸のほうではないのです。 分けるときの軸は工程のほうにあって、成果物は、分けたあとに作業の行へ書き添える属性の位置に置かれています

• 訳語が原因でこの形になった、というところまでは確かめていません

　そのほか

• 「バッファ」「予備」は、ここで言う成果物の木から外して考えてください。見積りの不確かさに備えて積む予備費は、スコープではなくコストの側の話で、別の層にあるものです

• 多段階契約については、IPAのモデル契約が勧めているのもこの形です

• ここで扱っているのは、新規開発の案件です。年間保守のように、そもそも成果物の木が立ちにくい仕事は、射程の外に置いています。また、ここまでの組み立ては、MIL-STD-881そのものではなく、PMI側の作法に寄ったものです

• 7章の引用は英語版Wikipediaの product-based planning の項によるもので、PRINCE2のマニュアル本体には当たっていません

11. まとめ

　手元の紙に戻る前に、箇条書きでまとめておきます。

• 見るのは2階層。 レベル2とレベル3に並んでいる言葉が「作るもの」か、「やること」か。判定は、それだけです

• やってしまう分け方は11。 いちばん多いのが工程で分けた形、次が日付と進捗率の列。3つ以上当てはまったら、WBSという名前で呼ばれている別の紙です

• その形は、自分で考えたものではないのです。 日本語で出回っている雛形が、確かめられた範囲でそろって同じ形でした

• 直し方は3つ。 完成形を1つ据える。名詞で分ける。足して100%になるかを確かめる

• いちばん変わるのは、進捗の判定です。 本人に聞かなくても、終わったかどうかが分かります

• そのかわり、他でカバーする必要があるものががあります。契約との対応、工数の実績、提案時点での作りやすさ、横串の仕事の居場所

• 明日できることは2つ。 工程をまたぐ成果物の行を、レベル2に1本足す。同じ名前が2か所に出ていたら、片方は作業なので消す

　WBSは、表ではなく木です。
中編では、その形がいつからのものなのかをたどります。

#WBS #プロジェクトマネジメント #プロジェクト管理 #Excel #見積り #品質管理 #IT業界

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

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

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

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

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

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

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

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