IT・Web・SaaSの仕事は「コードを書く」だけではなく、要件定義・設計・テスト・リリース・障害対応・保守運用・見積もりを、ビジネス価値とリスク（品質・セキュリティ・法令・納期・コスト）のバランスで回し続ける営みです。開発工程を成果物（アウトプット）と論点（なぜ揉めるか）で理解すると、会議・レビュー・運用の場で新人でも判断材料を出せるようになります。国際標準では、ソフトウェアのライフサイクルを共通言語として整理する枠組みが提示されています（例：ISO/IEC/IEEE 12207）。
新入社員がまず覚えるべき点
- 工程は手順ではなく意思決定の連鎖です。要件→設計→テスト→運用のどこでも、前提がズレると大事故になります（インシデントや炎上、契約トラブル）。
- 成果物で考える：各工程は「何を決めて」「何を残すか（成果物）」で区切ると、会話が噛み合います（例：受入基準、設計方針、テスト観点、運用手順）。
- 非機能（性能・可用性・セキュリティ等）は後回しにしない：品質モデルには代表的な品質特性が体系化されています。
- 障害対応は特別イベントではなく日常業務：インシデント対応は準備→検知・分析→封じ込め→復旧→再発防止の流れが基本です。
- 見積もりは当てる技術ではなく不確実性を管理する技術：測定・学習・合意形成が重要です（測定プロセスの国際標準もあります）。
30秒で説明するなら
「開発は、要件を決めて設計し、テストしてリリースし、運用しながら障害に対応して改善する価値提供の循環です。工程ごとの成果物と論点を押さえると、新人でも会議で確認すべき点と判断軸が持てます。」
ここだけは押さえる：工程名を暗記するより、その工程で何を決め、何を残すかを言語化できることが最初の戦力差になります。
導入と全体像
テーマの定義
ここでいう「新人エンジニアが最初に知るべき開発の流れ」とは、次を指します。
- 企画・要求整理（何を作るか／なぜ作るか）
- 要件定義（何を満たせば成功か）
- 設計（どう作るか／どう壊れないようにするか）
- 実装・レビュー（実際に作り、変更を安全に積む）
- テスト（品質・リスクを現実に照らして検証する）
- リリース（本番に出し、影響を制御する）
- 障害対応（インシデントを止め、復旧し、学習する）
- 保守運用（安定稼働と改善を継続する）
- 見積もり（不確実性を前提に、合意形成する）
国際標準の観点では、ソフトウェアのライフサイクル全体を共通の枠組みで扱う考え方が整理されています（例：ISO/IEC/IEEE 12207、国内ではその同等体系としてJIS化もあります）。
なぜ今このテーマを学ぶべきか
- デジタル経済は拡大し、企業活動の中核が「ソフトウェアで価値を出し続ける」形に寄っています。たとえば国連貿易開発会議の報告では、事業者間EC販売が2016年から2022年にかけて増加し、規模が大きいことが示されています。
- 攻撃・障害・法規制がプロダクト要件になりました。リスク管理の枠組み（NIST CSF 2.0など）や、セキュア開発の枠組み（SSDF）といった「開発工程に組み込むべき要求」が各国で整備されています。
- サプライチェーン（OSSや外部SaaS、クラウド）依存が増え、「作って終わり」ではなく「運用しながら変化に適応」が前提です。
読者にとってのメリット
- 先輩が言う「要件が弱い」「設計が甘い」「テスト観点が足りない」「運用見てない」「見積もりが根拠薄い」を、再現可能な言葉で理解できます。
- 会議での最低限の貢献（質問・確認・メモ・論点整理）ができ、話についてくる新人になります。
現場での使いどころ：この章の内容は、配属初日からの「用語の壁」を超えるための地図になります。
業界の基本構造
この業界は何を提供しているのか
IT・Web・SaaSの本質は「情報処理をサービス化し、継続的に改善して価値を届ける」ことです。ライフサイクルの観点でも、企画から運用・廃棄までを一連のプロセスとして扱うことが推奨されています。
SaaSの特徴は、納品で終わらず、運用しながら頻繁に更新される点にあります。その結果、開発工程は回すものになり、測定と改善が組み込まれます（測定プロセスの標準も存在します）。
主要プレイヤー
- 顧客（ユーザ企業・利用者）：要求の発信源であり、受入の主体です。要求工学の標準では、要求がライフサイクル全体で工学的に扱われるべき対象であることが示されています。
- 提供側（SaaS企業、受託開発企業、SI、コンサル等）：設計・実装・テスト・運用の責任を分担します。
- クラウド・インフラ提供者：SaaSの運用基盤を支えます（可用性・セキュリティ・監視が前提）。
- 行政・規制当局：個人情報、セキュリティ、取引慣行などを通じて実務要件を規定します（例：個人情報保護法、GDPR、NIS2、DORA）。
ここで一度、国・組織名を明示しておきます。特に日本では、受託開発の商流や取引慣行が品質・見積もり・責任分界に強く影響します。
価値と収益の流れ
- 受託開発：契約で合意した成果物（システム）を作り、対価を得ます。契約・仕様変更・責任分界が核心になります。
- SaaS：利用継続が売上を生み、継続率や拡張が重要指標になります。多くの企業が投資家向け資料でARR等の“非GAAP/非IFRS的な指標”を定義しており、定義は企業ごとに異なり得ます。
商流・情報流で新人が最初につまずきやすい点
- 多重委託（再委託）が起こると、仕様の意図が薄まり、品質と納期のリスクが増えます。実際に、ソフトウェア業の下請取引に関して、実態調査が行われています。
- 仕様変更が「誰の責任で」「いくらで」「いつまでに」を曖昧にしたまま進むと、炎上の典型パターンになります。モデル契約は取引構造の透明化や責務の明確化のツールとして位置づけられています。
- 下請法（下請代金支払遅延等防止法）は、取引の公正化と下請事業者の保護を目的とし、発注後の減額などが問題になります。
現場での使いどころ：配属直後に「この案件はSaaSか受託か」「契約形態は何か」「受入は誰か」を確認できるだけで、会話の理解度が跳ねます。
開発の流れを成果物と論点で理解する
この章で分かること：要件定義・設計・テスト・障害対応・保守運用・見積もりを、成果物（ドキュメントや判断）と論点（揉めどころ）でつなげて理解します。国際標準や公式ガイドが示す基本形も参照します。
開発工程の基本形
開発は直線ではなく、学習しながら反復します。アジャイルの価値観は「計画に従うことより変化への対応」「動くソフトウェアを重視」などを掲げ、短いサイクルで価値を届ける考え方を示しています。
実務では、ウォーターフォール的な合意（仕様を固める）と、アジャイル的な反復（学習して変える）が混ざります。フレームワークとしてスクラムの定義は公式ガイドで整理されています。
また、デリバリー全体の成果を測る指標としてDORAは「5つのソフトウェアデリバリーパフォーマンス指標」を提示し、スループットと不安定性の両面で捉える考え方を示しています（最終更新2026-01-05）。
要件定義
なぜ重要か
要件が弱いと、後工程で手戻りが増え、品質も納期もコストも崩れます。要求工学の標準は、要求がライフサイクル全体で反復的・再帰的に扱われること、良い要求の特性などを扱います。
成果物の例
- 要求一覧（ユーザ要求・業務要求・システム要求）
- スコープ（入る／入らない）と優先順位
- 受入基準（合格の定義）
- 非機能要件（性能・可用性・セキュリティ等）
現場の論点
- 「要件」なのか「設計・実装の案」なのかが混ざる
- 例外系が抜ける（想定外が運用で必ず出る）
- 非機能要件が後回しになる（しかし品質モデル上は主要特性として整理される）
新人ができる貢献
- 「誰が」「何を」「なぜ」必要としているかを一文で書き起こす
- 受入基準を「観測可能な条件」にする（例：レスポンスが速い→何ms以下か）
- 要件文の強さ（MUST/SHOULD等）を混同しない。RFC 2119は要求レベル語の意味を定義しています。
ここだけは押さえる：要件定義で新人が価値を出す最短ルートは、曖昧語（早い・簡単・安全）の測定可能化です。
設計
なぜ重要か
設計は「作り方」だけでなく、「変えやすさ」「壊れにくさ」「運用しやすさ」を決めます。アーキテクチャ記述の標準は、アーキテクチャそのものと記述（説明）を区別し、利害関係者の観点で表現する枠組みを規定します。
成果物の例
- アーキテクチャ方針（分割、依存、データの境界）
- API仕様、データ設計、権限設計
- 例外設計、運用設計（監視・ログ・復旧手順）
- 品質特性のターゲット（例：信頼性、性能効率性、セキュリティ等）
現場の論点
- 設計書を書くことが目的化してしまう
- 実装・運用の現実（監視、オンコール、データ移行）を設計に織り込めていない
- 品質の言葉が揃っていない（品質モデルが参照枠になる）
新人ができる貢献
- 重要な前提（トラフィック規模、SLA/SLO、データ保持期間、法令）を箇条書きで抜け漏れチェック
- 「この設計は何のリスクを下げるのか」を質問する（性能？可用性？セキュリティ？）
現場での使いどころ：設計レビューでは、正解探しよりもトレードオフの可視化が価値です。
テスト
なぜ重要か
テストは「バグ探し」ではなく、リスクを下げるための検証活動です。ソフトウェアテストの国際標準シリーズは、テストの概念・プロセス・文書・技法などを体系化しています。
成果物の例
- テスト計画（何を、どのレベルで、いつ、誰が）
- テスト観点・テストケース
- 欠陥（defect）管理表、リリース判定材料
ISTQBの用語集では、defect（欠陥）を「要求・仕様を満たさない不完全さ」といった観点で定義しています。
現場の論点
-「テストで品質を作れる」という誤解（品質は要件・設計・実装・運用で作り、テストは主に見つける）
- 重要度（ビジネス影響）と緊急度（優先度）が混在し、修正順が揉める
- 自動化が目的化し、価値の高い回帰（リグレッション）や監視が弱い
新人ができる貢献
- 受入基準とテスト観点を1対1で紐づける（「この要件は何で確認する？」）
- 再現手順を短く正確に書く（環境、手順、期待、実際）
ここだけは押さえる：テストは「網羅」ではなく、重要な失敗モードに厚く張るのが現実解です。
リリース
なぜ重要か
本番投入は、ユーザ影響・売上影響・法令影響が一気に顕在化する工程です。DORAは、変更を安全に早く届ける成果を測る指標として、変更リードタイムやデプロイ頻度、失敗後の回復時間等を整理しています。
成果物の例
- リリースノート、移行手順、ロールバック手順
- 監視・アラートの更新
- リリース判定（Go/No-Go）の根拠
現場の論点
- 変更が大きすぎて切り戻せない（バッチが巨大）
- 監視が追いつかず、異常検知が遅れる
- 運用チームに渡して終わりになり、責任分界が曖昧
新人ができる貢献：リリース前に「監視」「復旧」「問い合わせ導線」が揃っているかのチェックリスト化。
障害対応
なぜ重要か
障害は必ず起きます。重要なのは、被害を小さくし、学習して再発確率を下げることです。NISTのインシデント対応ガイドは、準備・検知/分析・封じ込め/根絶/復旧・事後対応という基本構造を示します。
国内でもCSIRTやインシデントハンドリングの実務資料が整備されています。
成果物の例
- タイムライン、影響範囲、暫定対応の記録
- 顧客連絡文、社内報告
- ポストモーテム（再発防止策、検知改善、教育）
現場の論点
- 原因追及が犯人探しになる（学習が止まる）
- 復旧と恒久対策が混線し、長引く
- 情報発信の粒度が難しい（法務・広報・CSも絡む）
新人ができる貢献
- 「今分かっていること／分かっていないこと」を区別してメモし続ける
- 影響（誰に何が起きているか）を整理する
- 手順書・監視・アラートの改善案を、具体的な変更として起票する
現場での使いどころ：障害対応で評価される新人の行動は、勝手な作業ではなく状況整理と記録です。
保守運用
なぜ重要か
SaaSでは運用が価値提供そのものです。サービスマネジメントの国際標準は、サービスを計画・設計・移行・提供・改善する枠組みを要件として提示します。
また、信頼性を測る考え方として、SREではSLO（目標）をSLI（指標）で測り、エラーバジェットで変化と安定のバランスを取る考え方が説明されています。
成果物の例
- 監視ダッシュボード、アラート設計
- ランブック（運用手順書）
- SLO/エラーバジェット方針
- 定常作業の自動化（運用負荷の削減）
現場の論点
- 運用が属人化し、改善が進まない
- 変更に追いつかない監視
- セキュリティ（脆弱性対応、ログ監査、権限棚卸し）が後回し
ここだけは押さえる：運用は「守り」ではなく、顧客体験を守りつつ改善スピードを保つ攻めの基盤です。
工数見積もり
なぜ重要か
見積もりは、納期・予算・体制の意思決定の土台です。ソフトウェア工学の知識体系では、ソフトウェア工学の実務領域として管理・計測などが含まれ、測定プロセスの標準でも「情報ニーズに適した測定」を定義します。
成果物の例
- 見積もり根拠（前提、スコープ、除外、リスク）
- WBSやバックログ、バッファ方針
- 変更時の再見積もりルール
現場の論点
- 要件が固まっていないのに精密さだけ求められる
- 楽観バイアス、未経験領域の不確実性が無視される
- 多重委託の商流で、現場の実態が上に伝わらない
新人ができる貢献
- 分からないことリストを可視化して、見積もりの前提に入れる
- 過去類似・実績データの所在を探し、再利用できる形に整理する（測定の文化づくり）
ここだけは押さえる：見積もりの質は、作業時間の計算ではなく「前提とリスクの明文化」で決まります。
必須用語・KPI・ルール
この章で分かること：新人が最初に覚えるべき用語（10〜20）、代表KPI、関連制度・ルール、混同しやすい概念の違いを、実務接続で説明します。
必須用語集
- 要求（requirement）：顧客・利用者・規制などが「満たしてほしい」と期待する条件。要求工学の標準では、要求の良さ（特性）や扱い方を扱います。
- 要件定義：要求を、合意可能・検証可能な形に落とす作業（受入基準が核心）。
- 非機能要件：機能以外の品質要求（性能、可用性、セキュリティ、保守性等）。品質モデルでは品質特性が体系化されています。
- アーキテクチャ記述：利害関係者の観点から、構造・関係・意図を説明する記述。標準で枠組みが定義されています。
- テスト計画／テストケース：テストの狙いと範囲、具体的な検証手順。ソフトウェアテスト標準シリーズが概念・プロセス等を整理しています。
- 欠陥（defect）：要求・仕様を満たさない不完全さ。用語集で定義されています。
- リグレッションテスト：変更によって既存機能が壊れていないことの確認。
- インシデント：重大な事故につながり得る出来事。CSIRT資料でも定義と体制が説明されています。
- ポストモーテム：インシデントの学習（再発防止・検知改善）。NISTのガイドでは事後活動が位置づけられます。
- SLO/SLI：SLOはSLIで測られる目標値。SREの公式資料で定義されています。
- エラーバジェット：SLOから導く「許容される失敗量」。1−SLOとして説明されています。
- DORAメトリクス：デリバリー成果を測る5指標（変更リードタイム、デプロイ頻度、失敗後回復時間、変更失敗率、デプロイ手戻り率）。
- SBOM：ソフトウェアの部品表。透明性向上の文脈で政府資料が整理しています。
- SSDF：セキュア開発の基本プラクティス集。NISTが公開しています。
このあたりの国際標準を取りまとめる代表的組織として、ISOやIEEEがあります。
代表的な指標・KPI
- デリバリーKPI：DORA 5指標。個別アプリ単位で測り、比較の誤用に注意することが示されています。
- 信頼性KPI：SLO（可用性・レイテンシ等）とエラーバジェット。SLOを顧客体験で測る前提が語られています。
- 品質KPI：欠陥の流出（本番障害件数）、再発率、テスト検出率など（用語はISTQB等で整理）。
- SaaSの事業KPI：ARR、NRRなど。ただしこれは会計基準上の統一指標ではなく、企業が投資家資料で定義しているケースが多い点に注意が必要です（例として、年次報告書でARRやNRRの定義を明示している企業があります）。
SaaS指標の例を一次開示で確認する練習として、D2Lの年次報告書や、GitLabの決算リリースは、ARRや（Dollar-based）Net Retentionの定義を記載しています。
代表的な制度・規制・資格・ルール
- 個人情報保護：個人情報保護委員会が法令・ガイドラインを公開しています。法の英訳も公的に提供されています。
- 欧州の個人情報保護：European UnionのGDPR（Regulation (EU) 2016/679）。
- 欧州のサイバー規制：NIS2（Directive (EU) 2022/2555）、金融分野のDORA（Regulation (EU) 2022/2554）など、運用・報告・第三者リスクに影響します。
- 米国のサイバー/セキュア開発枠組み：アメリカ合衆国のNISTはCSF 2.0やSSDFを公開しています。
- ソフトウェア供給網の透明性：CISAの資料はEO 14028やSBOM周辺を整理しています。
- 情報セキュリティ管理：ISO/IEC 27001はISMSの要求事項として位置づけられ、ISOが概要を示しています。
- 取引慣行：下請法の目的や禁止事項は、公正取引委員会が解説しています。
- 日本のセキュリティ人材：情報処理推進機構は情報処理安全確保支援士試験の制度変更（CBT移行予定等）を告知しています（更新：2026-02-02）。
初学者が混同しやすい概念の違い
- 要求 vs 要件：要求（欲しい）を、合意・検証可能な要件（満たす条件）に落とす。
- 仕様 vs 設計：仕様は外部から見える約束、設計は内部の作り。
- SLA vs SLO：SLOは内部目標（測定指標付き）、SLAは契約上の約束になり得ます（SLO/SLIの定義はSRE資料）。
- 指標の定義：ARRやNRRのような事業KPIは企業により定義が異なるので、一次開示の脚注を確認する癖が重要です。
ここだけは押さえる：用語は暗記より「定義→具体例→どの成果物に出るか」をセットで覚えると現場で使えます。
世界と日本の現状と影響
この章で分かること：一次情報・公式資料を中心に、世界と日本で「開発工程」がなぜ重くなっているか（規制・セキュリティ・産業構造・人材）を整理し、経済・社会・地政学への波及もつなげます。
世界の現状
事実として言えること
- デジタル経済は大きく、企業活動・貿易・環境負荷とも結びついています。国連貿易開発会議は、デジタル化の進展と環境面の論点を扱う報告書を公開し、ECや機器出荷などのデータを提示しています。
- セキュリティリスクは継続的に拡大し、組織的に管理する枠組みが求められています。NIST CSF 2.0は組織のサイバーリスク管理のガイダンスとして公開されています。
- セキュア開発やSBOMなど「開発工程に組み込むべき要件」が強化されています。EO 14028の文脈でSBOM最小要素などが整理され、SSDFがセキュア開発プラクティスを提示しています。
- 規制は地域差があります。EUのGDPR、NIS2、DORAのように、個人情報・重要インフラ・金融のデジタルレジリエンスが直接の実務要件になります。
解釈としてのポイント
- 開発工程は、単なる社内手順ではなく、国際取引と規制適合のための説明責任（設計根拠、テスト根拠、インシデント対応）を支える装置になっています。これはCSFやSSDFのような枠組みが「組織的・継続的」な管理を強調する点と整合します。
日本の現状
- 産業構造として多重委託の課題が指摘され、取引の適正化や役割分担の透明化が論点になります。ソフトウェア業の下請取引に関する実態調査が公表され、モデル契約は取引構造の透明化のツールとされています。
- デジタル人材不足は継続課題で、調査分析ペーパーでは不足の深刻化や職種別の不足感が論じられています。
- 企業向けのサイバーセキュリティ経営ガイドライン（Ver 3.0）や実践のためのプラクティス集が整備され、経営課題としてのサイバー対応が強調されています。
- 国家レベルでも年次報告が公表され、サプライチェーン・リスクなどが取り上げられています。
経済・社会・地政学への影響
- 経済：デジタルサービスの拡大は生産性・競争力に直結しますが、障害やサイバー事件は事業継続・信用に直撃します。欧州の脅威ランドスケープ報告は地政学的緊張と脅威動向の関係を扱っています。
- 社会：デジタルは生活基盤化し、品質（可用性、セキュリティ）は社会的影響を持ちます。品質モデルやサービスマネジメント標準が継続的改善を重視するのは、この性質と相性が良いです。
- 地政学：サプライチェーンの透明性（SBOM）や、規制（EU・米国）の違いが、開発工程（設計・開発・運用・監査）に要求として差し込まれます。
現場での使いどころ：世界・日本の動向は「開発工程がなぜ重いのか」を説明する材料になります。特に、セキュリティと規制は要件定義に戻ってくると理解すると、日々の判断がぶれにくくなります。
ケーススタディと理解確認
この章で分かること：現場で起きがちな状況を想定し、新人が何を確認し、どう考えればよいかを具体化します。最後にQ&Aと確認問題で理解を固めます。
ケーススタディ
ケースA 要件定義が弱いまま見積もり依頼が来た
- 状況：営業から「この機能、2週間でいける？」と聞かれ、要件が曖昧。
- 悪い例：根拠なく「いけます」と答える → 後からスコープ増、手戻り、炎上。多重委託や仕様変更が絡むとさらに悪化しやすいです。
- 良い例：次を質問として返し、前提を見積もりに埋め込む。
- 目的（誰の課題を解くか）
- スコープ（入る/入らない）
- 受入基準（何ができればOKか）
- 非機能（性能・セキュリティ・運用）
- 依存（外部API、データ移行、法務）
これは要求工学が要求の質を重視する姿勢とも整合します。
ケースB リリース後に障害が発生した
- 状況：デプロイ直後にエラー増加。顧客影響が疑われる。
- 新人がまず理解すべき流れ：準備→検知/分析→封じ込め→復旧→事後対応、という型を思い出す。
- 悪い例：原因調査に没頭して復旧が遅れる／記録が残らない
- 良い例：
- 影響範囲の整理（どの顧客、どの機能、いつから）
- 暫定復旧（ロールバックなど）と恒久対策の分離
- タイムラインと判断の記録（後の学習に必須）
- SLOの観点で「顧客体験」を軸に優先度を決める（SLO/エラーバジェットの考え方）
ケースC SaaS指標の定義が資料ごとに違うように見える
- 状況：ARRやNRRの数字を報告するよう言われたが、資料で定義が違う気がする。
- 結論：企業が投資家資料で自社定義を置くことがあり、脚注確認が必須です（年次報告書や決算資料で定義が記載される例）。
- 新人の行動：
- 定義文を抜き出し、分子・分母・対象期間・除外項目をメモ
- 会計指標と混ぜない（非GAAP指標はSECのガイダンス等も参照）
ここだけは押さえる：ケース対応で新人が一番価値を出すのは、「何が事実で、何が推測か」を分けて共有することです。
よくある疑問Q&A
Q:要件定義はどこまでやればいいですか？
A:合意と検証ができるレベルまでです。最低限、スコープ・優先順位・受入基準・非機能要件が明文化されると後工程の認識ズレが減ります。
Q:設計書はどれくらい必要ですか？
A:説明責任が必要な範囲に必要です。アーキテクチャ記述の枠組みのように、利害関係者の観点で伝わる形が重要です。
Q:テストはQAだけの仕事ですか？
A:いいえ。標準でもテストは組織・管理・技法まで含む体系として扱われ、開発全体の活動です。
Q:障害が起きたら最初に何をしますか？
A:影響把握と暫定復旧の優先順位付けです。NISTの基本プロセス（検知/分析→封じ込め→復旧）を思い出してください。
Q:工数見積もりはなぜ当たらないのですか？
A:不確実性が残ったまま精密さを求めるからです。測定プロセスの考え方に沿って前提と情報ニーズを明確にし、見積もりを更新する運用が必要です。
Q:DORAメトリクスはチーム評価に使っていいですか？
A:注意が必要です。DORA自身が、アプリ単位で文脈に合わせることや、比較の誤用・目標化の落とし穴（Goodhartの法則）を指摘しています。
理解確認
問題：受入基準が弱い要件の例を挙げ、どう直すとよいか説明してください。
模範回答：例「表示が速いこと」→「主要画面の95パーセンタイルの応答時間がX ms以下」など、測定可能にする。SLO/SLIの発想に近い。
問題：インシデント対応の基本ステップを順に述べ、各ステップで新人ができることを1つずつ挙げてください。
模範回答：準備→検知/分析→封じ込め→根絶/復旧→事後対応。新人は記録・影響整理・手順改善案の起票などで貢献できる。
問題：非機能要件が後回しになるリスクを2つ挙げてください。
模範回答：性能不足で顧客体験が悪化、可用性不足で障害が増える、セキュリティ不足で事故・規制対応コストが増える、など。品質モデルが品質特性を体系化している。
問題：多重委託が起こると、なぜ仕様の意図が薄まりやすいのか説明してください。
模範回答：関係者が増えるほど情報が要約・変形され、責任分界も曖昧になりやすい。取引実態調査やモデル契約の狙いは透明化にある。
結論と読者への提案
- 次に覚えるべき用語：非機能要件、SLO/SLI、DORA 5指標、SBOM、SSDF（このあたりを説明できると強い）。
- 追って読むべき一次資料：ISO/IEC/IEEE 12207（ライフサイクルの共通言語）、NIST SP 800-61（インシデント対応）、NIST CSF 2.0（リスク管理）、国内のモデル契約や下請法解説。
- 日々チェックすべき数字：リリース頻度、リードタイム、失敗率、回復時間、SLO達成状況（まずは自分のプロダクトで測れるものから）。
参考
- ISO. (2017). ISO/IEC/IEEE 12207:2017 Software life cycle processes. ISO. URL:
https://www.iso.org/standard/63712.html（閲覧日：2026-03-07） - IEEE. (2018). IEEE/ISO/IEC 29148-2018 Requirements engineering. IEEE Standards Association. URL:
https://standards.ieee.org/standard/29148-2018.html（閲覧日：2026-03-07） - ISO. (2022). ISO/IEC/IEEE 42010:2022 Architecture description. ISO. URL:
https://www.iso.org/standard/74393.html（閲覧日：2026-03-07） - ISO. (2011). ISO/IEC 25010:2011 System and software quality models. ISO. URL:
https://www.iso.org/standard/35733.html（閲覧日：2026-03-07） - ISO. (2013). ISO/IEC/IEEE 29119-1:2013 Software testing standards series. ISO. URL:
https://www.iso.org/standard/45142.html（閲覧日：2026-03-07） - Agile Manifesto authors. (2001). Manifesto for Agile Software Development. URL:
https://agilemanifesto.org/（閲覧日：2026-03-07） - Schwaber, K., & Sutherland, J. (2020). The Scrum Guide (2020). URL:
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf（閲覧日：2026-03-07） - DORA. (2026). DORA’s software delivery performance metrics. URL:
https://dora.dev/guides/dora-metrics/（閲覧日：2026-03-07） - NIST. (2012). SP 800-61 Rev.2: Computer Security Incident Handling Guide. URL:
https://csrc.nist.gov/pubs/sp/800/61/r2/final（閲覧日：2026-03-07） - NIST. (2024). The NIST Cybersecurity Framework (CSF) 2.0. DOI:
https://doi.org/10.6028/NIST.CSWP.29（閲覧日：2026-03-07） - NIST. (2022). SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. URL:
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf（閲覧日：2026-03-07） - CISA. (n.d.). Executive Order on Improving the Nation’s Cybersecurity (EO 14028) resource. URL:
https://www.cisa.gov/topics/cybersecurity-best-practices/executive-order-improving-nations-cybersecurity（閲覧日：2026-03-07） - CISA. (2024). Establishing a Common Software Bill of Materials (SBOM). URL:
https://www.cisa.gov/sites/default/files/2024-10/SBOM%20Framing%20Software%20Component%20Transparency%202024.pdf（閲覧日：2026-03-07） - UNCTAD. (2024). Digital Economy Report 2024. URL:
https://unctad.org/system/files/official-document/der2024_en.pdf（閲覧日：2026-03-07） - European Union. (2016). Regulation (EU) 2016/679 (GDPR). URL:
https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng（閲覧日：2026-03-07） - European Union. (2022). Directive (EU) 2022/2555 (NIS2). URL:
https://eur-lex.europa.eu/eli/dir/2022/2555/2022-12-27/eng（閲覧日：2026-03-07） - European Union. (2022). Regulation (EU) 2022/2554 (DORA). URL:
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A32022R2554（閲覧日：2026-03-07） - Japanese Law Translation. (n.d.). Act on the Protection of Personal Information (English). URL:
https://www.japaneselawtranslation.go.jp/en/laws/view/4241/en（閲覧日：2026-03-07） - 公正取引委員会. (2022). ソフトウェア業の下請取引等に関する実態調査報告書について. URL:
https://www.jftc.go.jp/houdou/pressrelease/2022/jun/220629_software.html（閲覧日：2026-03-07） - 情報処理推進機構. (2020). 情報システム・モデル取引・契約書（第二版）. URL:
https://www.ipa.go.jp/digital/model/model20201222.html（閲覧日：2026-03-07） - 情報処理推進機構. (2024). DX動向2024（人材不足）調査分析ディスカッション・ペーパー. URL:
https://www.ipa.go.jp/digital/chousa/discussion-paper/f55m8k00000039kf-att/dx-talent-shortage.pdf（閲覧日：2026-03-07） - 経済産業省. (2023). サイバーセキュリティ経営ガイドライン Ver3.0. URL:
https://www.meti.go.jp/policy/netsecurity/mng_guide.html（閲覧日：2026-03-07） - JPCERT/CC. (2021). インシデントハンドリングマニュアル. URL:
https://www.jpcert.or.jp/csirt_material/files/manual_ver1.0_20211130.pdf（閲覧日：2026-03-07） - U.S. SEC. (2022). Non-GAAP Financial Measures C&DIs (Last Update: Dec 13, 2022). URL:
https://www.sec.gov/corpfin/non-gaap-financial-measures.htm（閲覧日：2026-03-07） - IEEE Computer Society. (2014). SWEBOK Guide V3.0. URL:
https://ieeecs-media.computer.org/media/education/swebok/swebok-v3.pdf（閲覧日：2026-03-07） - ISO. (2018). ISO/IEC 20000-1:2018 Service management system requirements. URL:
https://www.iso.org/standard/70636.html（閲覧日：2026-03-07） - Google SRE. (n.d.). Service level objectives (SLO) — definition. URL:
https://sre.google/sre-book/service-level-objectives/（閲覧日：2026-03-07）
コメント