グーグルのモデルには、同社が「フルスタック」と呼ぶ優位性がある。身近なライバルたちのように競争相手に頼る必要もなければ、複雑な循環的資金調達に巻き込まれることもない。
グーグルのGemini 3が持つ、OpenAIに対する最大の優位性とは | Business Insider Japan
グーグルが今、フルスロットルで動いているとしても、ブランドの問題を抱えている。「ChatGPT」という言葉は多くの人にとってAIと同義になっている。それは「グーグル」がインターネット検索の、クリネックス（Kleenex）がティッシュペーパーの代名詞となっているのと同じだ。
グーグルのGemini 3が持つ、OpenAIに対する最大の優位性とは | Business Insider Japan
グーグルにとって幸いなのは、それを変える時間はたっぷりあるということだ。OpenAIは先発の優位性を持っているが、手元資金ではグーグルが優位だ。すでに無料モデルも提供しており、もし競合他社よりも低価格でモデルを普及させ、より多くの人々に届けたいのであれば、そうすることもできる。
グーグルのGemini 3が持つ、OpenAIに対する最大の優位性とは | Business Insider Japan
11月だけで3社が、新しいLLM（自然言語処理モデル）を投入した。OpenAI、Google、xAI――。米国のAI御三家にイーロン・マスクが加わり、わずか1週間の間に、首位争いがめまぐるしく変動した。さらに中国のDeepSeekとQwen（アリババ）が「コスト激安」を武器に殴り込みをかけている。選択肢が多すぎるが、ビジネスパーソンはどうすればいいのか。
生成AIの最新動向は？ OpenAI、Google、xAI、そして中国勢の米中バトル：Gemini 3登場（1/3 ページ） - ITmedia ビジネスオンライン
⇧ まぁ、「エンジニア」としては、「幻覚（ハルシネーション）」の問題が解決されていることが選択肢として重要なのよな...
流石に正確な「情報」に辿り着くまでに、「AI」との問答を膨大な回数繰り返したくもないですし、「AI」の「回答」の「ファクトチェック」のために、何回もネット上で検索をしたくはないのよな...
ChatGPTにソフトウェア開発の業務フローを整理してもらった
「ソフトウェア開発」の「業務フロー」って、いまいち、全体像が整理がされていない気がしますと。
本ブログでも、
⇧ 過去の調査において「ソフトウェア開発」の「タスク」や「成果物」などの関係や全量がハッキリしないモヤモヤした状態であった...
いやはや、ネット上の「情報」が「錯綜」し過ぎていて、正確な「情報」を整理するために「検索」を繰り返す作業に疲れたのよ...
というわけで、改めて「ChatGPT」氏に「ソフトウェア開発」の「業務フロー」を整理してもらった。
ちなみに、「ChatGPT（Chat Generative Pre-trained Transformer）」が正式名称らしい。
ChatGPT is a generative artificial intelligence chatbot developed by OpenAI and released in November 2022. It currently uses GPT-5.1, a generative pre-trained transformer (GPT), to generate text, speech, and images in response to user prompts.
A generative pre-trained transformer (GPT) is a type of large language model (LLM) that is widely used in generative AI chatbots. GPTs are based on a deep learning architecture called the transformer. They are pre-trained on large datasets of unlabeled content, and able to generate novel content.
https://en.wikipedia.org/wiki/Generative_pre-trained_transformer
「 検索」を利用してます。
一応、以下の「フレームワーク」を反映する形でお願いしてみた。
勿論、不足している「フレームワーク」があれば、適宜、採用・反映するようにお願いしている。
■ソフトウェア開発の業務フローに関係してきそうなフレームワーク
- ビジネスアナリシス知識体系ガイド（BABOK：A Guide to the Business Analysis Body of Knowledge）
- 共通フレーム2013
- ITIL（Information Technology Infrastructure Library）
■ソフトウェア開発の業務フロー
| No | フェーズ | 工程 | フレームワーク | タスク | 成果物 | 関与ステークホルダー（正式名称 + 略称） | 前提依存 |
|---|---|---|---|---|---|---|---|
| 1 | 企画 | プロジェクト立案 | 共通フレーム2013 | 経営・業務ニーズ分析 | 構想文書 | 経営層（Executive / Exec）、事業部門（Business Unit / BU）、プロジェクト管理オフィス（PMO） | なし |
| 2 | 企画 | プロジェクト立案 | 共通フレーム2013 | 構想立案 | 初期要件案 | 経営層（Executive / Exec）、プロジェクト管理オフィス（PMO） | なし |
| 3 | 企画 | プロジェクト立案 | BABOK | ビジネスケース作成 | ビジネスケース | 経営層（Executive / Exec）、ビジネスアナリスト（Business Analyst / BA） | なし |
| 4 | 企画 | プロジェクト立案 | BABOK | 利害関係者整理 | ステークホルダー分析 | 事業部門（Business Unit / BU）、利害関係者代表（Stakeholder Representative / Stakeholder） | なし |
| 5 | 計画 | スケジュール策定 | 標準 | WBS作成 | プロジェクト計画書 | プロジェクトマネージャー（Project Manager / PM）、チームリーダー | 企画完了 |
| 6 | 計画 | コスト計画 | 標準 | 見積り | コスト見積書 | プロジェクトマネージャー（Project Manager / PM）、経理部門 | 企画完了 |
| 7 | 計画 | 品質計画 | ITIL | 品質基準設定 | 品質計画書 | 品質管理部門、プロジェクトマネージャー（Project Manager / PM） | 企画完了 |
| 8 | 計画 | コミュニケーション計画 | 標準 | ステークホルダー情報共有計画 | コミュニケーション計画書 | プロジェクトマネージャー（Project Manager / PM）、利害関係者代表（Stakeholder Representative / Stakeholder） | 企画完了 |
| 9 | 要求定義 | ビジネス要求 | BABOK/共通フレーム2013 | ビジネス目標・課題特定 | ビジネス要求文書 | 経営層（Executive / Exec）、ビジネスアナリスト（Business Analyst / BA）、プロダクトマネージャー（Product Manager / PdM）、ドメインエキスパート（Domain Expert / Domain） | 計画完了 |
| 10 | 要求定義 | ステークホルダー要求 | BABOK/共通フレーム2013 | 利害関係者ニーズ収集 | ステークホルダー要求文書 | ユーザー代表（User Representative / User）、事業部門（Business Unit / BU）、プロダクトマネージャー（Product Manager / PdM）、ドメインエキスパート（Domain Expert / Domain） | ビジネス要求完了 |
| 11 | 要求定義 | ソリューション要求（機能） | BABOK/共通フレーム2013 | 機能要件抽出 | 機能要求仕様書 | ビジネスアナリスト（Business Analyst / BA）、ユーザー代表（User Representative / User）、プロダクトマネージャー（Product Manager / PdM）、ドメインエキスパート（Domain Expert / Domain） | ステークホルダー要求完了 |
| 12 | 要求定義 | ソリューション要求（非機能） | BABOK/共通フレーム2013 | 性能、可用性、信頼性、セキュリティ、運用性、法規制、移行適応性整理 | 性能要件仕様書、可用性要件文書、セキュリティ要件仕様書、運用・保守要件書、法規制遵守報告書、移行要件文書 | IT部門（Ops）、運用担当（Operations / Ops）、情報セキュリティ担当（IT Security Officer / Security）、法務部門（Legal Department / Legal）、プロダクトマネージャー（Product Manager / PdM） | ソリューション要求（機能）完了 |
| 13 | 要求定義 | 移行要求 | BABOK/共通フレーム2013 | 現行システムから新システムへの移行要件整理 | 移行要求文書 | 運用担当（Operations / Ops）、データベース管理者（Database Administrator / DBA）、IT部門（Ops） | ソリューション要求（非機能）完了 |
| 14 | 設計 | ソフトウェア方式設計 | 共通フレーム2013 | アーキテクチャ設計 | 方式設計書 | アーキテクト（Architect / Arch） | 要求定義完了 |
| 15 | 設計 | ソフトウェア方式設計 | 共通フレーム2013 | 論理データモデル設計 | 論理データモデル図 | データベース設計者（Database Designer / DD） | 要求定義完了 |
| 16 | 設計 | 外部設計（基本設計） | 標準 | 画面設計 | 画面仕様書 | UXデザイナー（User Experience Designer / UX）、開発チーム、ドメインエキスパート（Domain Expert / Domain） | 要求定義完了 |
| 17 | 設計 | 外部設計（基本設計） | 標準 | 入出力設計 | 入出力仕様書 | 開発チーム、ドメインエキスパート（Domain Expert / Domain） | 要求定義完了 |
| 18 | 設計 | 外部設計（基本設計） | 標準 | 概略データ設計 | 概略データモデル | データベース設計者（Database Designer / DD）、ドメインエキスパート（Domain Expert / Domain） | 要求定義完了 |
| 19 | 設計 | 内部設計（詳細設計） | 共通フレーム2013 | モジュール設計 | モジュール設計書 | 開発チーム、ドメインエキスパート（Domain Expert / Domain） | 外部設計完了 |
| 20 | 設計 | 内部設計（詳細設計） | 共通フレーム2013 | DB設計 | テーブル定義書 | データベース設計者（Database Designer / DD）、ドメインエキスパート（Domain Expert / Domain） | 外部設計完了 |
| 21 | 設計 | 内部設計（詳細設計） | 共通フレーム2013 | API・インタフェース設計 | API仕様書 | 開発チーム（Dev） | 外部設計完了 |
| 22 | 設計 | 内部設計（詳細設計） | 共通フレーム2013 | 物理データモデル作成 | 物理データモデル図 | データベース設計者（Database Designer / DD）、開発リーダー | 外部設計完了 |
| 23 | インフラ | インフラ設計 | 共通フレーム2013 | サーバ／ネットワーク設計 | サーバ設計書、ネットワーク設計書 | インフラエンジニア（Infra）、情報セキュリティ担当（Security） | 設計完了 |
| 24 | インフラ | インフラ設計 | 共通フレーム2013 | クラウド設計 | クラウド設計書 | インフラエンジニア（Infra）、情報セキュリティ担当（Security） | 設計完了 |
| 25 | インフラ | インフラ設計 | 共通フレーム2013 | DBサーバ設計 | DB設計書 | インフラエンジニア（Infra）、DBA | 設計完了 |
| 26 | インフラ | インフラ構築 | 共通フレーム2013 | サーバ／ネットワーク構築 | インフラ環境 | インフラエンジニア（Infra）、運用担当（Ops） | インフラ設計完了 |
| 27 | インフラ | インフラ構築 | 共通フレーム2013 | クラウド環境設定 | クラウド構築手順書 | インフラエンジニア（Infra）、運用担当（Ops） | インフラ設計完了 |
| 28 | インフラ | インフラ構築 | 共通フレーム2013 | DBサーバ設定 | データベース環境 | インフラエンジニア（Infra）、DBA | インフラ設計完了 |
| 29 | 実装 | コーディング | 共通フレーム2013 | プログラム作成 | ソースコード | 開発者（Dev） | 内部設計完了 |
| 30 | 実装 | コーディング | 共通フレーム2013 | ライブラリ組込み | ライブラリ | 開発者（Dev） | 内部設計完了 |
| 31 | 実装 | モジュール統合/結合 | 共通フレーム2013 | 結合準備 | 結合モジュール | 開発チーム（Dev） | コーディング完了 |
| 32 | 実装 | モジュール統合/結合 | 共通フレーム2013 | 結合実施 | 結合テスト報告書 | 開発チーム（Dev）、テスト担当（QA） | 結合準備完了 |
| 33 | テスト | 単体テスト | 標準 | モジュール単体テスト | 単体テスト報告書 | 開発者（Dev）、テスト担当（QA） | コーディング完了 |
| 34 | テスト | 内部結合テスト | 標準 | モジュール間結合確認 | 結合テスト報告書 | テスト担当（QA）、開発チーム（Dev） | 単体テスト完了 |
| 35 | テスト | 外部結合テスト | 標準 | サブシステム間結合確認 | 結合テスト報告書 | テスト担当（QA）、ユーザー代表（User） | 内部結合テスト完了 |
| 36 | テスト | 総合テスト / システム適格性確認 | 共通フレーム2013/標準 | 機能テスト | システムテスト報告書 | ユーザー代表（User）、テスト担当（QA） | 外部結合テスト完了、インフラ構築完了 |
| 37 | テスト | 総合テスト / システム適格性確認 | 共通フレーム2013/標準 | 性能テスト | 性能テスト報告書 | IT部門（Ops）、運用担当（Ops） | インフラ構築完了 |
| 38 | テスト | 非機能テスト | BABOK/共通フレーム2013 | 可用性テスト | 可用性テスト報告書 | IT部門（Ops）、運用担当（Ops） | インフラ構築完了 |
| 39 | テスト | 非機能テスト | BABOK/共通フレーム2013 | セキュリティテスト | セキュリティテスト報告書 | 情報セキュリティ担当（Security） | インフラ構築完了 |
| 40 | テスト | 要件対応確認 | BABOK | 機能・非機能要件整合性確認 | 要件トレーサビリティレポート | PM、PdM、QA、利害関係者代表（Stakeholder） | 単体テスト・非機能テスト完了 |
| 41 | 展開・運用 | リリース管理/配備 | 共通フレーム2013/ITIL | リリース準備 | リリース計画 | リリース担当（Release）、運用担当（Ops） | インフラ構築完了、テスト完了 |
| 42 | 展開・運用 | リリース管理/配備 | 共通フレーム2013/ITIL | 移行実施 | 移行チェックリスト | 運用担当（Ops）、DBA | リリース準備完了 |
| 43 | 展開・運用 | 運用・保守 | 共通フレーム2013/ITIL | 運用モニタリング | 運用マニュアル | 運用担当（Ops） | リリース完了 |
| 44 | 展開・運用 | 運用・保守 | 共通フレーム2013/ITIL | 障害対応・改修 | 改修履歴、インシデントログ | 運用担当（Ops）、サポート担当（Support） | 運用モニタリング完了 |
| 45 | 展開・運用 | インシデント／問題管理 | 共通フレーム2013/ITIL | 問題分析・対策 | 問題記録、是正報告 | 運用担当（Ops）、Support、PM | 運用・保守完了 |
| 46 | 展開・運用 | 要件再評価／変更管理 | 共通フレーム2013/BABOK | 運用中要件見直し | 要件変更記録 | PM、PdM、運用担当（Ops）、利害関係者代表（Stakeholder） | 運用完了 |
| 47 | 展開・運用 | 廃棄 | 共通フレーム2013 | システム廃棄計画 | 廃棄計画書、資産処分記録 | PM、IT部門（Ops）、資産管理担当 | 運用完了 |
■関与ステークホルダーの一覧
| No | 略語 | 正式名称 | 役割・説明 |
|---|---|---|---|
| 1 | Exec | Executive / Management（経営層） | 経営視点でプロジェクトの承認、投資判断、ビジネス目標の設定を行う |
| 2 | Legal | Legal Department（法務部門） | システム・サービスの法規制遵守、契約、リスク管理を担当 |
| 3 | BU | Business Unit（事業部門） | 業務現場視点で要件や課題の提示、業務プロセスやルールの提供を行う |
| 4 | Domain | Domain Expert（ドメインエキスパート） | 専門領域の知識・経験を提供し、要件や設計の妥当性を確認 |
| 5 | Security | IT Security Officer（情報セキュリティ担当） | システムのセキュリティ要件策定、セキュリティテスト、脅威管理を担当 |
| 6 | PdM | Product Manager（プロダクトマネージャー） | プロダクト全体の戦略・要件優先順位を管理し、ビジネス価値最大化の意思決定を行う |
| 7 | PM | Project Manager（プロジェクトマネージャー） | プロジェクトの進行管理、予算・スケジュール・リソース調整、リスク管理を担当 |
| 8 | Arch | Architect（アーキテクト） | システム全体の技術アーキテクチャ設計、方式設計の方向性を決定 |
| 9 | UX | User Experience Designer（ユーザー体験デザイナー） | ユーザー視点で画面・操作性の設計、ユーザビリティ向上の提案を行う |
| 10 | DBA | Database Administrator（データベース管理者） | データベースの運用・管理・移行・パフォーマンス管理を担当 |
| 11 | DD | Database Designer（データベース設計者） | 論理・物理データモデルの設計、データ整合性・パフォーマンスを考慮した設計を行う |
| 12 | Dev | Developer（開発者） | プログラム開発、モジュール実装、単体テストを担当 |
| 13 | Tester | Tester / QA（テスト担当） | 単体・結合・総合テストの計画・実施・報告、品質保証を行う |
| 14 | Ops | Operations（運用担当） | システム運用、監視、障害対応、保守・管理作業を担当。インフラ構築後の運用環境の管理も行う |
| 15 | Release | Release Manager（リリース担当） | リリース計画の策定、展開作業管理、リリース後の検証を担当 |
| 16 | Support | Support（サポート担当） | 利用者サポート、インシデント対応、問い合わせ対応を行う |
| 17 | Stakeholder | Stakeholder Representative（利害関係者代表） | プロジェクトの利害関係者を代表し要件や承認・意見を提供 |
| 18 | PMO | Project Management Office（プロジェクト管理オフィス） | プロジェクト管理標準の提供、管理支援、進捗・成果物のレビューを行う |
| 19 | User | User Representative（ユーザー代表） | 実際のシステム利用者視点で要件確認・受入テスト・意見提供を行う |
| 20 | QA | Quality Assurance（品質保証担当） | プロジェクト全体の品質保証、レビュー、改善提案を行う |
| 21 | Infra | Infrastructure Engineer（インフラエンジニア） | サーバ、ネットワーク、クラウド、DBサーバ設計・構築を担当。インフラ環境の安定化を実施 |
実際に可視化してみると、「エンジニア」のやること多過ぎなのよな...
正直、各々の技術について造詣の深い「フルスタックエンジニア」とかになるのは、茨の道としか思えないのよな...
おまけに、「経営」的なことも理解しろとなると、10人ぐらいに分身できでもしない限り、「エンジニア」の業務が成り立たない気がしてしまうのよな...
最早、技術が飽和した昨今においては、「フルスタックエンジニアやめますか？人間やめますか？」的な圧力を感じてしまいますな...
「覚せい剤やめますか? それとも人間やめますか?」（かくせいざいやめますか? それともにんげんやめますか?）は、日本民間放送連盟（民放連）が1983年2月より開始した、放送による啓蒙広告「覚せい剤追放キャンペーン」のために考案されたキャッチコピー。
欧米諸国では学校教育でも薬物の特性や影響を教えているが、日本ではあらゆる薬物が一括で人間をやめる薬物として扱われ、廃人になりますということでは知識としても誤りで、どんな薬物にどんなリスクがあるのかと話し合える場がないと、回復の場からもはじき出されてしまう。
ジャパンタイムズ紙のPhilip Brasorは2017年、日本では薬物使用で逮捕された芸能人は単に罪を犯したというだけでなく、「ヒトではない何か」として扱われていると指摘し、その原因は「人間やめますか」のコピーの影響によるものとした。
日本国外ではロバート・ダウニー・Jrのように薬物依存症になり刑務所に入ったこともある人物が世界でも有名な俳優となっているが、日本では薬物を使用した俳優の映画出演シーンはカットされ、国民は芸能人の薬物使用を忘れようとはせず烙印を押し続けている。
⇧ まぁ、日本は「穢多・非人」とか差別の文化があったり、「村八分」とか「人非人」とか「レッテル」を貼るのが兎にも角にも好きな民族っぽいですからな...
日本は、今でも、余所者や新参者が受け入れられるのが難しい地域もあるという話を聞きますしな...
話が脱線しましたが、
そりゃあ、実際の「業務」で利用される「ソフトウェア」の「品質」の維持は至難の業になりますわな...
当然のことながら、「機能」の「開発」は繰り返し実施されていくことになり、システムが複雑さを増していくのは不可避なので、必然的に「障害」が発生する可能性は高くなることになるのだから、「障害」からの「復旧」に時間がかかるのは致し方ないのだが、「復旧」した際に感謝されることが少ないのは解せぬ...
むしろ、「障害」が発生したことを非難されることの方が圧倒的に多いのが現状で、「ソフトウェア開発」のモチベーションが保てるわけがないのよな...
よく「完璧さを求める必要はない」という話を聞くので、「障害」が発生したとて、非難するのでなく、同じことが繰り返されないような防止策の「仕組み」を検討するために協力して欲しいところですな。
やはり、「保守・運用」に耐え得る「ソフトウェア」を作ることの難しさなのよな...
だからこそ、「変更容易性」が大事になってくるのよね...
そのためには、「影響範囲」が把握し易くなっている必要があるのだが、往々にして、「影響範囲」の特定が非常にし辛い作りになっていることが多いのよな...
「リファクタリング」したくとも、「影響範囲」が特定できない状態では、「リファクタリング」を実施した影響で現行のシステムが動作しなくなるかもしれないリスクが払拭できないので、怖くて「リファクタリング」を実現できないのよな...
とりあえず、「独立行政法人情報処理推進機構（英: Information-technology Promotion Agency, Japan、略称: IPA）」は、「ソフトウェア開発」の「業務フロー」の「標準化」をして情報を公開して欲しいのよね...
独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Information-technology Promotion Agency, Japan、略称: IPA）は、日本のIT国家戦略を技術面・人材面から支えるために設立された独立行政法人（中期目標管理法人）。所管官庁は経済産業省。
日本のソフトウェア分野における競争力の総合的な強化を図る。情報処理の促進に関する法律の一部を改正する法律（平成14年法律第144号）により、2004年（平成16年）1月5日に設立され、同法附則第2条第1項の規定により解散した、特別認可法人である情報処理振興事業協会（IPA）の業務等を承継した。
毎度モヤモヤ感が半端ない…
今回はこのへんで。
