フレームワーク

エグゼクティブ・サマリー（要約）

「フレームワーク」とは、文字通り「枠組み」¹ を意味し、特定の目的を達成するための「構造化された基盤」¹ または「型」² を指します。この概念は、大別して二つの主要な領域—IT（情報技術）とビジネス—で異なる形態をとりながらも、共通の本質、すなわち「効率化のための構造化された制約」という特性を共有しています。

ITドメインにおけるフレームワーク（「何であるか」）:
ソフトウェア開発において、フレームワークは「実行可能なスケルトン（骨格）」として機能します。これはアプリケーションの「土台」3 であり、データベース連携、ルーティング、セキュリティ対策といった汎用的な機能が予め組み込まれています 3。開発者はこの「土台」の上に独自のビジネスロジックを追加することに集中できるため、開発効率、品質、保守性が飛躍的に向上します 6。
ビジネスドメインにおけるフレームワーク（「何であるか」）:
戦略的思考や問題解決において、フレームワークは「思考の足場（スキャフォールド）」として機能します。SWOT分析 9 や3C分析 10 に代表されるこれらの「思考の型」2 は、複雑な問題を整理・分析し、意思決定を導くための構造を提供します。これにより、思考の網羅性を高め（漏れや重複の回避 12）、チーム内での「共通言語」として機能し、議論の生産性を高めます 10。

フレームワークが**「何でないか」**を定義することは、それが「何であるか」を理解する上で不可欠です。本レポートは、以下の主要な境界線を明確に定義します。

ライブラリとの最大の違い（「何でないか」）:
最大の違いは、プログラムの主導権の所在、すなわち「制御の反転（Inversion of Control: IoC）」13 にあります。ライブラリは開発者が「呼び出す」道具（例：数学関数）ですが、フレームワークは開発者が記述したコードを「呼び出す」システムそのもの（例：Webサーバーの処理）です。
テンプレートとの違い（「何でないか」）:
テンプレートが「完成形の一部（静的な設計図）」16 であるのに対し、フレームワークは「プロセス全体（動的な建築プロセスとルール）」16 を定義します。
手順書（Procedure）との違い（「何でないか」）:
手順書が「How（どうやるか）」という具体的なステップ 17 であるのに対し、フレームワークは「構造（何がどう関連しているか）」19 を示す、より高次の概念です。
ポリシー（Policy）との違い（「何でないか」）:
ポリシーが「What/Why（何をすべきか/なぜか）」という個別のルール 17 であるのに対し、フレームワークはそれらのポリシー群を体系的に整理し、管理するための「枠組み」そのものです 20。

本質的に、フレームワークとは、特定の領域における先人たちの知見とベストプラクティスを「再利用可能な構造」として凝縮したものです。それは、効率と品質、網羅性を担保する代わりに、一定の「制約（ルール）」を受け入れるというトレードオフを内包する、高度な知的ツールであると結論付けられます。

第1部：フレームワークとは何か？ — 核心的定義と二つの側面

このセクションでは、「フレームワークとは何か」という問いに対し、その語源的な本質から、ITおよびビジネスという二大ドメインにおける具体的な役割と機能、そしてその利点と固有のリスクまでを詳細に分析します。

1.1 フレームワークの原義と本質：「構造化された基盤」

語源と核心的概念

フレームワーク（Framework）という言葉は、その語源が示す通り「Frame（枠）」と「Work（作業）」の合成語です 21。この語源が示唆するのは、「特定の作業（Work）を行うための構造化された枠（Frame）」という本質です。

リサーチによれば、フレームワークとは「枠組み」「構造」¹ であり、「特定の目的や課題に取り組むための基盤や枠組み」¹、あるいは「目標や課題達成のために必要な思考の枠組み」² と定義されます。

この概念の核心には、ゼロから物事を構築する「完全な自由」を意図的に放棄し、その代わりに「構造化された制約」を受け入れる、というトレードオフが存在します。建築における「基礎」や「骨組み」に例えることができます。基礎がなければ何も建てられませんが、一度特定の基礎（フレームワーク）を採用すると、その上に建てられるものの構造や間取りは、その基礎によって決定的に制約されます。この「制約による効率化と品質の担保」こそが、フレームワークが提供する核心的な価値です。

1.2 側面1：ITドメインにおけるフレームワーク — 「実行可能なスケルトン」

IT分野、特にソフトウェア開発において、フレームワークは単なる比喩ではなく、具体的かつ機能的な「土台」³ として機能します。

定義と機能

ソフトウェアフレームワークは、アプリケーション開発を効率化するために用意された、共通の構造や機能を提供する「ソフトウェアの土台」です 4。これは、アプリケーションの「スケルトン（骨格）」13 とも表現されます。

具体的には、Webアプリケーションフレームワークの場合、HTTPリクエストの受付、ルーティング（URLと実行する処理の紐付け）、データベースとの連携、セキュリティ対策（例：SQLインジェクション対策）、セッション管理など、多くのアプリケーションで共通して必要とされる汎用的な機能が、クラスやライブラリ、APIとして予め組み込まれています ³。

開発者は、この「土台（ベース部分）」⁶ が提供する仕組みの上で、そのアプリケーション固有の機能（例：ECサイトのカート機能、SNSの投稿機能）といった「メイン部分」⁶ の開発に集中することが可能になります。

利点（The “Why” – なぜ使うのか）

ITドメインでフレームワークを利用する動機は、現代のソフトウェア開発が直面する「複雑性」と「速度」の要求に応えるためであり、その利点は多岐にわたります。

開発効率の飛躍的向上:
最大の利点です。前述のベース部分の開発を省略できるため、開発工数を大幅に短縮できます 6。ゼロからコードを書く必要がないため、経験の浅いエンジニアでも一定レベルの機能を迅速に実装できます 7。これは、特にアジャイル開発やデジタルトランスフォーメーション（DX）のように、迅速な市場投入が求められる場合に不可欠です 3。
品質の均質化と保守性の向上:
フレームワークは、開発者に対して特定の「共通のルール」8（例：ファイルの配置場所、命名規則、設計パターン）に従うことを要求します。これにより、エンジニアごとのコーディングスタイルの差異（属人性）が減少します。結果として、ソースコードの「可読性」が向上し 7、コードレビューが容易になり、「バグの発生を抑える」ことができます 7。開発チームのメンバーが入れ替わったり、数年後に改修が必要になったりした場合でも、この「標準化」3 された構造が「保守性」7 を格段に向上させます。
セキュリティと堅牢性の担保:
現代のアプリケーションにとってセキュリティ対策は不可欠ですが、その実装は非常に専門的で手間がかかります 7。実績のあるフレームワーク（例: Spring Framework 4, Ruby on Rails 8）は、一般的なセキュリティリスク（例：クロスサイトスクリプティング、CSRF）への対処があらかじめ組み込まれていることが多いです 4。フレームワークのコミュニティによって脆弱性が発見・修正されるため、自前で実装するよりも高いレベルのセキュリティを実現できます 5。

具体例（The “What” – 何があるか）

フレームワークは、開発の目的や言語に応じて多種多様なものが存在します。

Webバックエンドフレームワーク:
サーバーサイドの処理を担当します。例：Ruby on Rails (Ruby) 8、Django (Python) 3、Laravel (PHP) 3、Spring Framework (Java) 4。
Webフロントエンドフレームワーク:
ユーザーインターフェース（UI）の構築と動作を担当します。例：Angular, Vue.js, React 22。
CSSフレームワーク:
Webサイトのデザイン（見た目）を効率化します。例：Bootstrap（HTML/CSS/JSの再利用可能なコード群）5。
データサイエンスフレームワーク:
データ分析や機械学習プロジェクトを容易にします 5。

制約と代償（The “Cost” – 代価は何か）

これらの強力な利点と引き換えに、フレームワークはいくつかの制約（トレードオフ）を開発者に課します。

開発の自由度の低下:
最大のデメリットは、フレームワークが「定められたルールや構造」4 に従うことを強いる点です。これにより、独自の設計や特殊な要件、イレギュラーなカスタマイズが困難になる場合があります 4。フレームワークの「お作法」から外れる処理を無理に実装しようとすると、かえって非効率になることさえあります。
学習コスト:
フレームワークを使いこなすためには、その構造、仕様、設計思想、そして固有の「お作法」を理解するための学習時間とコストが必要です 4。特にAngularのように機能が豊富で大規模なフレームワークは、学習コストが非常に高いことで知られています 23。
基礎スキルの空洞化リスク:
フレームワークの利便性に過度に依存すると、フレームワークが「裏側で何をしているか」（例：生のSQLクエリ、HTTP通信の仕組み）を理解しないまま開発が完結してしまう可能性があります。これにより、プログラミングの基礎的なスキルやアルゴリズムへの理解が浅くなるリスクが指摘されています 4。

現代のアプリケーション開発が直面する「複雑性」と「速度」の要求は、個人の技量でゼロからすべてを管理できる限界をはるかに超えています。フレームワークが「コードの書き方を統一」⁷ し「可読性を向上」⁷ させることは、「バグの低減」⁷ と「保守性の向上」⁸ に直結します。つまり、フレームワークは「個人の自由」を制約することで、「チームとしての生産性と持続可能性」という、より大きな価値を提供するのです。

1.3 側面2：ビジネスドメインにおけるフレームワーク — 「思考の足場」

ビジネス分野において、フレームワークはソフトウェアのような「実行可能な実体」ではなく、思考や議論を構造化するための「概念的な実体」² として機能します。

定義と機能

ビジネスフレームワークは、アイデア発想、事業の分析、タスクの洗い出しなどに便利な「考え方をまとめたもの」11、すなわち「思考の型」です。

これらは、事業に関する情報の整理、現状の把握とその分析、目標達成や課題改善に向けた意思決定のプロセスにおいて、判断材料として活用されます ¹⁰。ITのフレームワークが「コーディング」の足場であるならば、ビジネスフレームワークは「思考」の足場（スキャフォールド）と言えます。

利点（The “Why” – なぜ使うのか）

人間の思考は本質的に無秩序（カオス）であり、バイアス、漏れ、重複に満ちています。ビジネスフレームワークは、この思考のカオスに「秩序（オーダー）」を与えるために使用されます。

思考の効率化と網羅性の確保:
ゼロから「何を分析すべきか」と考えるのは非効率であり、重要な論点を見落とす危険が伴います。フレームワークは「考えるべき項目」をあらかじめ定義しているため（例：SWOTなら強み・弱み・機会・脅威）、思考の整理がスムーズに進み 12、重要な論点の「漏れや重複を回避」できます 12。
「共通言語」の構築:
チームで戦略を議論する際、個々人がバラバラの視点で語っていては議論が噛み合いません。フレームワーク（例：「SWOTのO（機会）について話しましょう」）は、チーム内に「共通認識」10 を生み出す「共通言語」として機能します。これにより、議論の方向性が定まり、生産性が劇的に向上します 10。
現状の整理と可視化:
複雑なビジネス環境や自社の状況をフレームワークに当てはめることで、現状を客観的に整理・分析しやすくなります 10。これにより、これまで漠然としていた課題や問題点が「可視化」され 12、課題発見が迅速化します 12。

具体例（The “What” – 何があるか）

ビジネスフレームワークは、その目的別に数百種類が存在すると言われています。

経営戦略・現状分析:

SWOT分析: 自社の内部環境（Strength:強み, Weakness:弱み）と外部環境（Opportunity:機会, Threat:脅威）を分析します ⁹。
3C分析: 外部環境（Customer:顧客, Competitor:競合）と内部環境（Company:自社）の3つの関係性から分析します ¹⁰。
その他、PEST分析、5F分析（ファイブフォース分析）²⁴ など。
マーケティング:

4P分析: Product（製品）、Price（価格）、Promotion（販促）、Place（流通）の4つの観点から戦略を分析します ⁹。
AIDMA（アイドマ）: 消費者の購買決定プロセスを分析します ¹²。
業務改善・目標設定:

PDCAサイクル: Plan（計画）、Do（実行）、Check（評価）、Action（改善）のサイクルを回して業務を継続的に改善します ⁹。
OKR (Objectives and Key Results): 目標設定と進捗管理の手法です ²⁴。
ロジックツリー: 問題を分解し、原因や解決策を論理的に整理します ²⁴。

制約と代償（The “Cost” – 代価は何か）

ビジネスフレームワークもまた、万能のツールではなく、固有のリスクを伴います。

思考の画一化・硬直化:
フレームワークはあくまで「型」であるため、「型」にとらわれすぎると、その枠外にある新しい考えや斬新なアイデアが思いつかなくなるというデメリットがあります 10。
目的と手段の取り違え:
フレームワークを「使うこと」自体が目的化し、分析（例：SWOT分析の表を埋めること）を行っただけで満足してしまい、具体的な行動や解決策に結びつかない「分析のための分析」に陥るケースです 12。
前提条件の変化への非対応:
多くの古典的なフレームワーク（例：4P）は、特定の時代背景や市場環境（例：マスメディア中心の時代）で生まれました。現代のデジタル化された市場環境では、古い「型」が現状にそぐわない可能性があります。

結論として、ITのフレームワークが「コードの自由度」を制約する ⁴ のと同様に、ビジネスのフレームワークは「思考の自由度」を制約します ¹⁰。この制約は、分析の「網羅性」¹² と「議論の生産性」¹⁰ を担保するための、意図的な「知的足場」なのです。

第2部：フレームワークとは何かでないか？ — 類似概念との徹底比較

「フレームワークとは何か」を定義する最良の方法は、それが「何でないか」を明確にすることです。このセクションでは、フレームワークと混同されがちな主要な概念との境界線を、専門家の視点から厳密に定義します。

2.1 最大の相違点：フレームワーク vs. ライブラリ

これは、特にITドメインにおいて最も重要かつ技術的な違いです。両者の境界は曖昧に見えますが、その本質的な違いは「制御の所在」にあります。

核心的差異：「制御の反転（Inversion of Control: IoC）」

この二つを分ける決定的な鍵は、「制御の反転（Inversion of Control: IoC）」13 という設計原則にあります。これは、プログラムの「主導権」を誰が握っているか、という問題です。

ライブラリ（Library）とは何か

ライブラリは、特定の、よく定義された操作を実行するための「機能の集合」です 13。例えば、数学的な計算を行う関数群（Mathライブラリ）や、文字列を操作する関数群（Stringライブラリ）などです 13。

制御の所在：あなた（開発者）
ライブラリを使用する際、プログラムのメインの制御フローは、開発者が書いたコード（アプリケーション）が握っています。開発者は、「自分のコードから、必要な時にライブラリの関数を呼び出し（Call）ます」 13。ライブラリの関数は処理を実行し、結果を返し、制御は呼び出し元のあなたのコードに戻ってきます。
比喩：
ライブラリは「道具箱（ツールボックス）」です。あなたは家（アプリケーション）を建てている大工であり、釘を打つという特定の作業のために、道具箱から金槌（ライブラリ関数）を取り出して使いますが、いつ、どこで、どのように金槌を使うかを含め、家を建てるプロセス全体を管理しているのは「あなた」です。

フレームワーク（Framework）とは何か

フレームワークは、アプリケーションの「スケルトン（骨格）」13 または「土台」4 であり、それ自体がアプリケーションのメインの制御フローを握っています。

制御の所在：フレームワーク
フレームワークを使用する際、制御は「反転」します 13。メインの制御フローはフレームワーク自身が握っており、「フレームワークが、必要な時にあなたのコードを呼び出し（Call）ます」 13。
比喩：
フレームワークは「建築会社（あるいはモデルハウスの建築プロセス）」16 です。建築会社（フレームワーク）が、「基礎工事」「骨組み」「配線」といった全プロセスを管理しています。あなた（開発者）の役割は、フレームワークが用意した「空白（フック、コールバック、サブクラス化すべき箇所）」25 に対して、アプリケーション固有の処理（例：壁紙の色、キッチンの仕様）を定義することです。そして、プロセスがその段階（例：内装工事）に達したとき、建築会社（フレームワーク）が「あなたの定義した仕様（コード）」を呼び出して実行します。

この「制御の反転」こそが、マーティン・ファウラー氏が指摘する「ハリウッドの原則（Hollywood Principle）」、すなわち「我々を呼ぶな、我々があなたを呼ぶ（Don’t call us, we’ll call you.）」¹⁵ の本質です。

なぜこの「制御の反転」¹³ が重要なのでしょうか。それは、アプリケーションの「関心事の分離」²⁶ を強制するからです。フレームワークが制御を握ることで、開発者は「いつデータベースに接続するか」「いつHTTPリクエストを受け取るか」「イベントループをどう管理するか」といった、アプリケーションの「流れ」や「ライフサイクル管理」²⁷ について考える必要がなくなります。開発者は「このイベントが起きたら、何をすべきか」という「ビジネスロジック（本質的な関心事）」²⁶ の記述に集中できます。IoCは、開発者を「全体管理」の重責から解放し、「部分（固有機能）」の充実に専念させるための、強力な設計原則なのです。

2.2 構造と具体性：フレームワーク vs. ツールキット vs. テンプレート

ツールキット（Toolkit）

ツールキットは、ライブラリの一種であり、特にGUI（グラフィカル・ユーザー・インターフェース）の文脈で使われます 28。

違い： GUIツールキットは、アプリケーションのGUI部分を構築するための「部品（ウィジェット、例：ボタンやテキストボックス）」28 を提供するライブラリです。制御の所在は開発者側にあります。
一方、GUI「フレームワーク」は、これらの部品の提供に加え、イベントループやウィンドウ管理など、「アプリケーション全体の構造を定義・支援」します 28。ここでも「制御の反転」が発生し、フレームワークが「ボタンがクリックされたら、あなたのこのコードを呼ぶ」という流れを管理します。

テンプレート（Template）

テンプレートは「ひな形」や「設計図」です。

違い： テンプレートは、それ自体では動かない「静的な構造」の定義（例：HTMLの穴埋め、モデルハウスの間取り図 ¹⁶）に過ぎません。
関係性： フレームワークとテンプレートの関係は「包含」あるいは「利用」の関係です。¹⁶ の比喩を解読すると、フレームワークは「モデルハウスを建築するプロセス全体（請負業者）」であり、そのプロセスの中で「いくつかのテンプレート（間取り図）を選ぶ」ことがあっても、テンプレート自体がフレームワークなのではありません。多くのWebフレームワークは、内部で「テンプレートエンジン」という仕組みを利用しますが、フレームワークはそれ（テンプレート）以上に、ルーティング、セッション管理、データアクセスなど、動的なプロセス全体を管理する、より広範な概念です。

2.3 規範と実行：フレームワーク vs. ポリシー、手順、標準、ガイドライン

この区別は、特にビジネス、ガバナンス、コンプライアンスの文脈で重要です。これらの用語はしばしば混同されますが、明確な階層と役割の違いが存在します。

ポリシー（Policy）

**「何（What）」と「なぜ（Why）」**を定めます。
これは組織の「ルール」であり、行動を「義務付ける（mandates）、指定する（specifies）、または禁止する（prohibits）」高レベルの文書です ¹⁷。
例：「我が社は、全従業員の良好な歯の衛生を確保し、虫歯を予防する」¹⁸。

手順（Procedure）

**「どうやって（How）」**を実行するかを定めます。
これはポリシーを実現するための、具体的かつ線形的な「ステップ」です ¹⁷。
例：「1. 歯ブラシに豆粒大の歯磨き粉をつける。 2. すべての歯にわたって円を描くようにブラシを動かす…」¹⁸。

標準（Standard）

**「品質（Quality）」**を定めます。
これは達成すべき「ベンチマーク」や技術的な仕様です ²⁰。
例：「歯磨きは1日2回行うべきである。フッ素入り歯磨き粉と、3ヶ月未満の電動歯ブラシを使用すること」¹⁸。

ガイドライン（Guideline）

**「推奨（Recommendation）」**を示します。
これは「ベストプラクティス」であり、義務ではありませんが、従うことが望ましいとされるものです ¹⁷。
例：「歯磨き粉は、特定のブランドのものが推奨される」。

そして、フレームワーク（Framework）

これらすべてを内包し、**「構造化（Structure）」**するものです。
フレームワークは、単一のルール（ポリシー）やステップ（手順）ではありません。それは、**ポリシー、手順、標準、ガイドラインといった要素群を体系的に整理し、管理・実行するための「枠組み」**です ¹⁹。
例：経済産業省が策定した「Society5.0」型サプライチェーンに対応するサイバーセキュリティのフレームワーク ¹⁹ は、「三層構造と6つの構成要素」という「枠組み」を定義します。そして、その枠組みの各部分に「どのポリシーが該当し」「どの標準を満たすべきで」「どの手順を実行するか」をマッピングすることで、複雑なセキュリティ対策の全体像を体系的に整理します ¹⁹。

ポリシー、手順、標準は、それぞれ「点」や「線」の情報です。しかし、組織が複雑な課題（例：サイバーセキュリティ ¹⁹ やコーポレート・ガバナンス ²⁰）に対処するには、それらがバラバラでは機能しません。そこで、これらの要素を「構造化」し、「全体像」¹⁹ を与える「枠組み」が必要になります。それが（ガバナンスにおける）フレームワークです。ポリシーや手順が「何を」「どうやるか」であるのに対し、フレームワークは「何を、どこに、どう位置づけ、どう関連させるか」という**「知のアーキテクチャ」**そのものを示すのです。

第3部：結論 — フレームワークという「知のOS」を使いこなすために

本レポートは、「フレームワークとは何か、そして何でないか」という問いを、ITとビジネスの両ドメイン、そして技術的および規範的な観点から徹底的に分析しました。

フレームワークとは何か（本質）

フレームワークとは、ITの文脈であれ 4、ビジネスの文脈であれ 11、「先人の知見とベストプラクティスを凝縮した、再利用可能な構造（枠組み）」1 です。

ITにおいては、コードの「土台」⁴ として、生産性、保守性、品質 ⁶ を提供します。
ビジネスにおいては、思考の「足場」¹¹ として、分析の網羅性、効率性、議論の共通基盤 ¹⁰ を提供します。

フレームワークとは何かでないか（境界）

フレームワークは、万能の「答え」そのものではありません 12。

それは、あなたが「呼び出す」だけの受動的な**「ライブラリ（道具）」ではありません。「制御の反転」¹⁴ により、あなた（のコード）を「呼び出す」能動的な「システム」**です。
それは、穴埋め式の**「テンプレート（設計図）」¹⁶ ではありません。設計図の利用を含む、より広範な「プロセスとルール」**です。
それは、単一の**「ポリシー（ルール）」や「手順（ステップ）」¹⁷ ではありません。それら複数の要素を体系的に管理するための「メタ構造（枠組み）」**¹⁹ です。

最終洞察：フレームワークという「知的オペレーティングシステム」

フレームワークの本質を統一的に理解するために、それを**「知的オペレーティングシステム（OS）」**として捉えることが有効です。

OS（オペレーティングシステム）は、コンピュータの複雑なハードウェア（リソース）を管理し、アプリケーション（利用者のコード）が動作するための「共通基盤」を提供します。
同様に、ITフレームワークは、「データベースアクセス」「セキュリティ」「HTTP通信」といった複雑なソフトウェアリソースを管理し、開発者が「ビジネスロジック」というアプリケーションの本質に集中するための「実行基盤」を提供します。
ビジネスフレームワークは、「思考」という複雑なリソースを管理し、分析者が「バイアス」や「漏れ」¹² というエラーを避け、本質的な「課題発見」¹² に集中するための「思考基盤」を提供します。

フレームワークを使いこなすとは、OSの作法を学ぶことに似ています。その「ルール（制約）」⁴ を深く理解し、その「制御の流れ（IoC）」¹⁴ に乗り、その上で「自分固有の価値（アプリケーション）」を構築することです。フレームワークは「答え」そのものを与えてはくれませんが、私たちが「より良い答え」に、より速く、より堅牢にたどり着くための、最も強力な「知のOS」なのです。

【補遺】概念的境界の比較分析表

本レポートの分析に基づき、フレームワークと類似概念の差異を以下の表にまとめます。

概念	核心的機能（Purpose）	制御の所在（Locus of Control）	具体性（Specificity）	強制力（Mandatory Force）
フレームワーク (IT)	アプリケーションの土台と骨格 ⁴	フレームワーク（が開発者のコードを呼ぶ）¹⁴	中（骨格は定義するが、詳細は開発者が埋める）	高（ルールに従う必要がある）⁴
フレームワーク (Business)	思考・分析の構造（型）²	利用者（が思考の型に従う）	高（分析の項目が定義されている）⁹	低（思考のツールであり、利用は任意）¹⁷
ライブラリ (Library)	特定機能の部品（道具）¹³	利用者（が必要な時にライブラリを呼ぶ）¹³	高（特定の機能に特化）	（利用は任意）
テンプレート (Template)	静的なひな形（設計図）¹⁶	利用者（が空白を埋める）	非常に高い（ほぼ完成形）	（利用は任意）
ポリシー (Policy)	組織の「ルール」（What/Why）¹⁷	（組織の構成員）	低（高レベルの原則）	非常に高い（義務）¹⁷
手順 (Procedure)	ポリシー実行の「ステップ」（How）¹⁷	（組織の構成員）	非常に高い（詳細なステップ）	非常に高い（義務）¹⁷
標準 (Standard)	達成すべき「品質ベンチマーク」²⁰	（組織の構成員）	高（具体的な仕様や数値）	高（遵守義務あり）¹⁸
ガイドライン (Guideline)	ベストプラクティス（推奨）¹⁷	（組織の構成員）	中（推奨される方法）	低（非義務、推奨）¹⁷