GiftXは、全国の正社員・会社役員8,000名のビジネス職（オフィス系7職種）に「ビジネス職生成AI活用実態調査（2026年版）」を実施した。
AIが「役立っている」という実感があっても、生産性・成果が「明確に上がった」と答えた人は約2割だった（生産性19.4％／成果・品質20.2％）。最も多かったのは「やや上がった」で、約5割を占めた。
業務をAIエージェント化した層では、生産性が「明確に上がった」と答えた人が54％。チャットでの利用にとどまる層では14％で、約3.8倍の差がついた。成果・品質でも、AIエージェント化した層は44％に達した（他の段階は16〜19％）。自社の情報や業務手順を覚えさせて実行する段階でも一定の改善は見られるが、成果実感は、業務プロセスそのものをAIに任せる段階で伸びていることがうかがえる。
また、組織側の課題でも、1位は「AI活用が個人任せになっている」だった。一方で、「AIをより積極的に活用したい」は約6割にのぼった。
2026年7月9日、マッキンゼー・アンド・カンパニーは、AIエージェントが消費者の購買行動及び小売・EC企業の競争環境に及ぼす影響を分析したホワイトペーパー「エージェンティックコマースにおける自動化の進み方」を発表した。
マッキンゼーは、保守的なシナリオでも2030年までにAIエージェントが世界の消費者向け商取引の約3兆～5兆ドルを仲介する可能性を指摘した。日用品や食品・消耗品のような繰り返し購入・失敗の少ないカテゴリーでは自動化しやすい傾向がある一方、高級品や重要な買い物では人による最終判断の価値が残りやすいとする。また、旅行や家電、家具など多要素比較が必要なカテゴリーでは、AIが候補整理を担い、最終判断は人が行う「選択的自動化」が進む見通しだ。
小売・EC企業の競争環境も大きく変化する。これまで重要だったのは、検索や広告、ブランド認知など人の注意を引く手法だった。しかし今後は「AIエージェントに選ばれる」ことが肝要となる。商品カタログ、価格、在庫、配送、返品、ロイヤルティなどの情報をAIが処理・比較しやすい形に構造化し、APIなどで連携させる必要がある。情報が機械可読でなければ販売候補にさえ挙がらない可能性があるため、商品情報や条件の透明性、説明可能な設計が必須となる。
日本市場では、従来重視されてきた配送品質やアフターサービス、ポイントサービスなど独自の強みも、AIエージェントが認識できる形で提供しなければ競争力を発揮しづらくなる。企業は、すべてを自動化するのではなく、業務のどこに人の関与が不可欠かを見極め、それぞれのカテゴリーに最適な顧客体験の設計が求められる。
⇧ まぁ、
- AI に完全に委譲できる業務
- AI に部分的には委譲できる業務
- 人手でしか担うことができない業務
の「業務」の洗い出し、分類、整理が大前提となるのは当然として、「AI エージェント」が「性能」を発揮できる「環境構築」が肝になって来ると...
とりあえず、
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。
⇧ 上記の状況を避けるためには、適切な「情報」の整理と管理が必要よね...
とは言え、「カオス」な状況になっていることが多いので、適切な「情報」の整理と管理の体制を構築するには「コスト」はかかる...
ちなみに、
⇧ 上記にあるように、「JIS X 0161」によると、
- 是正保守 (corrective maintenance)
- 緊急保守 (emergency maintenance)
- 改良保守 (maintenance enhancement)
- 完全化保守 (perfective maintenance)
- 予防保守 (preventive maintenance)
の5つに大別される取り組みがある模様。
- ソフトウェア保守 (software maintenance)
との関係が分からないが...
Wikipediaによりますと、
ソフトウェア保守の区分
ソフトウェア保守はその動機により細分できる。JIS X 0161:2008には、次の区分が定義されている。
- 適応保守 (adaptive maintenance)
- 変化した又は変化している環境において、ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の引渡し後の修正。
- 是正保守 (corrective maintenance)
- 発見された問題を訂正するために行うソフトウェア製品の引渡し後の受身の修正。いわゆるバグ修正。
- 緊急保守 (emergency maintenance)
- 是正保守実施までシステム運用を確保するための、計画外で行われる一時的な修正。
- 完全化保守 (perfective maintenance)
- 潜在的な欠陥が故障として現れる前に検出し訂正するために行う、引渡し後のソフトウェア製品の修正。
- 予防保守 (preventive maintenance)
- 引渡し後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し、是正を行うための修正。
⇧ 上記のようなまとめになっている。
ただ、「完全化保守 (perfective maintenance)」については、
『注記 完全化保守は，利用者のための改良，プログラム文書の改善を提供し，ソフトウェアの性能強化，保守性などのソフトウェア属性の改善に向けての記録を提供する。』
⇧ とあるので、
- ソースコード
- ドキュメント
の「情報」の「乖離」などを修正する作業に該当するので、「情報」の「メンテナンス」という意味では、「完全化保守 (perfective maintenance)」が重要になって来そうではある...
要求工学のプロセス的には価値駆動開発、ドメイン駆動設計、仕様駆動開発の順で取組む感じか
前に、
⇧ 上記の記事の時に、「要求工学（Requirements engineering）」について触れたのだが、「要求工学（Requirements engineering）」の「プロセス」としては6つに大別されるらしいですと。
- Requirements inception or requirements elicitation
- Requirements analysis and negotiation
- System modeling
- Requirements specification
- Requirements validation
- Requirements management
で、表題の件。
「要求工学（Requirements engineering）」の「プロセス」の時系列で考えた場合、
- 価値駆動開発（VDD：Value Driven Development）
- ドメイン駆動設計（DDD：Domain Driven Design）
- 仕様駆動開発（SDD：Spec-driven development）
の順に取り組んでいくのかなと。
ちなみに、「価値駆動開発（VDD：Value Driven Development）」については、
哲学者Kant は人の根源的な心的要素として以下の「知、情、意」の三つを挙げ，そのバランスによって人々は動いていると説いています。価値駆動のソフトウェアエンジニアリングを考える上で、我々はこの「知、情、意」に着目し、以下のように捉えることにしました。
- 知（Cognitive, Intelligence）: 知覚・知性に基づくロジカルシンキングであり、従来のソフトウェア工学の手法の多くが該当する。
- 情（Affective, Emotion）: 相手や対象に対する感情・情的な過程であり、ソフトウェアを使う人が感じる魅力や、ソフトウェアを導入した企業が得られる価値を考えること。
- 意（Conative, Will）: 道徳的評価に基づく意志やコンセプチュアルシンキングであり、価値を生み出そうとしている主体自身の意志。
SE4BSでは価値駆動開発ということを提唱しています。価値駆動開発は、簡単に言うと『要求に対して「なぜ」という問いかけを行い、誰かの価値までたどり着くことで、ソフトウェア開発に重要となる核心を理解し開発に結びつける』ということです。
顧客価値、ビジネス価値や社会価値に基づいてソフトウェア開発・運用を進めること、また産業界で広く受け入れられているアジャイル開発をうまくソフトウェア工学に取り入れていくことの一つ方策として、SE4BSは価値駆動プロセスを以下のように提案します。
⇧ 上記サイト様によりますと、上図のように「ステークホルダー」の「価値」を明確化して、「ソフトウェア開発」の一連の「プロセス」が「価値」を実現する形になっていることを目指す「アプローチ」らしい。
その中で、「ビジネス」の核となる「ドメイン」部分を「設計」する際に、「ドメイン駆動設計（DDD：Domain Driven Design）」が活用できるはずであると。
そして、「ドメイン」が「モデリング」できたら、「仕様駆動開発（SDD：Spec-driven development）」が活用できるはずであると。
やはり、「ソフトウェア開発」の「情報」が「錯綜」しているからして、どの「開発手法」を、「ソフトウェア開発」のどの「領域」の「プロセス」に適用するのかが「ファジー」になってしまうのよな...
で、結局のところ、
『我々は「雰囲気」で「ソフトウェア開発」を行っている』
になってしまうのよな...
加えて、
- 既存の「認知負債」
- 「AI」の「幻覚（ハルシネーション）」などによる「意図負債」
- システムを運用し続けてきたことによる「技術的負債」
などが相まって、自然と「カオス」な状況を加速させ得る「要因」が増えていく状態になっていくので、非常に「ストレス」が蓄積されていくよね...
「AI-Ready」な「情報」の整理が重要なのは分かるのだが、
- AI フレンドリー
- Human フレンドリー
の両方を維持した状態を目指したいところですな...
兎にも角にも、「保守・運用」対象の「システム」が、終盤の「ジェンガ」のように不安定な状態になってしまうのは嫌だ...
ちなみに、
ジェンガ（英: Jenga）は、同サイズの直方体のパーツを組んで作ったタワーから崩さないように注意しながら片手で一片を抜き取り、最上段に積みあげる動作を交代で行うテーブルゲーム。おもにパーティーゲームとして利用されている。
概要
1974年にイギリス人の女性起業家レスリー・スコットにより開発され、1983年にロンドンで発売された。欧米ではハズブロより発売されている。日本ではかつてはタカラトミーより発売されていたが、同社での販売は2018年3月31日をもって終了し、その後はハズブロの日本法人であるハズブロジャパンより発売されている。
「ジェンガ」という語はスワヒリ語で「組み立てる」という意味の「クジェンガ」に由来する。その原型はレスリーの家族が遊んでいたゲームであり、当時住んでいたガーナのセコンディ・タコラディにちなみ「タコラディ・ブリック」と呼んでいた。
⇧ 上記によりますと、「スワヒリ語」が由来という...
話が脱線しましたが、「銀の弾丸」は無いと言われますが、「情報」は整理して欲しいお気持ち...
やはり、
概要
型破り・形無し
「本を忘るな」とあるとおり、教えを破り離れたとしても根源の精神を見失ってはならないということが重要であり、基本の型を会得しないままにいきなり個性や独創性を求めるのはいわゆる「形無し」である。
⇧ 上記にありますように、ある程度、先人たちの残してくれた「ノウハウ」から学ぶのが良い気がするのだが、「ソフトウェア開発」は「情報」が「錯綜」しており、上手いこと成長していける環境が整っていないのよな...
とりあえず、
独立行政法人情報処理推進機構（じょうほうしょりすいしんきこう、英: Innovation Platform Agency, Japan、略称: IPA）は、日本のIT国家戦略を技術面・人材面から支えるために設立された独立行政法人。所管官庁は経済産業省とデジタル庁（共管）であり、主要業務の主務大臣は経済産業大臣および内閣総理大臣。政府全体のIT政策を横断的に担う政策執行機関である。また、半導体および大規模サーバに関する事業体や、AIに関するソフトウェア分野への政府出資を行う産業投資機能、脅威情報共有機能および防御支援機能も有している。
タグラインとして「Beyond Digital（デジタルの、その先へ。）」を掲げ、「デジタル基盤の提供」「デジタル⼈材の育成」「サイバーセキュリティの確保」を事業の三本柱に据えて日本の情報化とデジタル化の推進を図る。情報処理の促進に関する法律の一部を改正する法律（平成14年法律第144号）により、2004年（平成16年）1月5日に設立され、同法附則第2条第1項の規定により解散した、特別認可法人である情報処理振興事業協会（IPA）の業務等を承継した。
⇧ 上記を謳っている「組織」が主導して、適切な「情報」を整理して公開して欲しいお気持ち...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
