リソース

本の発送前に利用できるもの。

この『フィールドガイド』は、単に読むだけでなく、実際に活用できるよう意図的に構成されています。ここでは、すでに公開されている内容、本書の発売に合わせて公開される予定の内容、そして今すぐさらに詳しく知るための情報をご紹介します。

本書より

挙げられたフレームワーク

これらについては、それぞれが属する章で、定義、仕組み、そして実際に適用された事例など、包括的かつ実用的な解説が行われています。

第5章

コンポーザビリティの5つの柱

ボトムアップ、アジリティ、民主化、人間中心、コンプライアンス。システムが真に構成可能であるかどうかを検証するための試金石。

第6章

事業目標の枠組み

現場(ゲンバ)から始め、ビジネス価値、オペレーターの活動、物理的要件、ビジネスプロセスを融合させて、最初のユースケースを選定する。

第6章

使い捨て診断アプリ

ソリューションの構築に着手する前に、ユースケースが現実的なものかどうかを検証するために使用される、意図的に使い捨てとして設計されたアプリ。

第7章

最小限の実現可能なソリューション

ステーションでの状況を変える、展開可能な最小単位のもの――さらに、アジャイル風ウォーターフォールを見抜くための診断テスト。

第8章

制作、キュレーション、構成、消費

最初のプロジェクトチームが対応すべき4つの関与モードと、最初のユースケースに必要な5つの役割との対応関係。

第9章

業務フロー図

設計の核心となる成果物――同じ操作に対する3つの視点であり、チームが建設的な議論を行えるよう整理されたものである。

第9章

ソリューション・クレド

提案された解決策が実装される前に、設計テストに合格しなければならない。

第9章

コンポーザブル・エージェント型フレームワーク

ビルダーエージェントとスタッフエージェントを、組み合わせ可能な構成要素として――適用範囲が明確で、ガバナンスが確立され、人間の関与が組み込まれている。

第10章

デジタル成熟度モデルとエスケープ・ベロシティ

「探索、拡大、変革」――そして、デプロイメントが前進し続けるために、もはや中央からの推進力を必要としないタイミングを見極める方法。

名前付きパターン

「」と名付けられた故障モードは、

故障モードに名前をつけることで、チームは会議でそれを指摘しつつ、誰かを非難することなく議論を進めることができます。こうした例は本書の至る所に見られます。

モノリシック・トラップ

あらゆるプロセスを同じ方法で処理できるという前提で構築されたシステムでは、プロセスがシステムに適応することになります。コンポーザブル・テクノロジー上でそのように実装されると、それはJAM、つまり「Just Another MES(ありふれたMES)」となってしまいます。

リーン・シアトリクス

リーン手法の「目に見える成果物」は、それを機能させるためのルーチンや関係性、意思決定権が伴わずに導入されてしまった。デジタルツールは、同じ過ちをより速く、より大きなコストをかけて繰り返してしまう。

ウォーターフォール・リバージョン

カレンダー上ではスプリント方式が維持されているものの、実際の作業の流れは静かにビッグバン方式へと回帰している。

一元化された執筆管理

依然としてすべては1つのチームによって開発されているため、民主化によって解消されるはずだった作業の滞留は、単に別の場所へ移っただけである。

価値よりもガバナンス

ガバナンスの枠組みは、製品が一切出荷される前に導入されるため、プログラムは、その成果が実証される前に監視の対象となる。

『孤独な狼』

1人の優秀な、監督されていない開発者が、単一障害点となってしまう。市民開発とシャドーITの違いは、ガバナンスにある。

エージェントパターン

最前線のエージェントたち

AIは、Augmented Leanが業務にもたらすデジタル技術の基盤であり、それが適用される業務の質を向上させます。日々の現場での問題解決や、発生源で収集されたデータが活用される業務にAIを適用すれば、その業務の学習速度は向上します。一方、不完全で文脈情報が乏しいデータにAIを適用すると、現場のオペレーターだけが把握している制約と矛盾する提案が生成され、その結果、業務はAIに対する信頼を失うだけでなく、AIによって促進されるはずだったカイゼン活動への信頼も失うことになります。

本書では、エージェント型AIを「コンポーザブル・アーキテクチャ」の延長線上にあるものと位置づけている。コンポーザブルなソリューションは、すでにマルチエージェントシステムのように機能している。つまり、各アプリには明確な目標があり、独自のスコープ内で動作し、共有データを通じて他のアプリと連携している。エージェントは、そのアーキテクチャに認知層を追加するものである。第1章では、その設計論理をトヨタ生産方式にまで遡って考察し、第9章では、拡張されたリーンプロジェクトにおけるエージェント型アーキテクチャについて詳述している。 本書で取り上げられているすべてのエージェントは、スコープが定義され、統制されており、人間をループ内に巻き込んでいる。

本書と並行して制作中

コンポーザブル・エージェント・エクスチェンジ

本書で紹介されているエージェントのパターンは、「Exchange」の出発点となります。「Exchange」とは、Composable Agentic Framework に基づいて整理された、運用エージェントおよびそれらを組み合わせて構成されるマルチエージェントソリューションの厳選カタログです。各エージェントは、バリューストリームのどの部分で作業を行うかによって分類されています:

  • 運用を支援する。エンジニアリング、品質、企画の各部門、およびそれらに所属する市民開発者と連携して業務を行うビルダー、スタッフ、およびコンパニオンエージェント。
  • 運用において。物理的なアーティファクト(製品、機械、または装置)や運用上のアーティファクト(指示、逸脱、またはスケジュール)を対象とするエージェント、およびERP、MES、WMS、あるいは統一ネームスペースと限定的なやり取りを行うシステムエージェント。

この「エクスチェンジ」は、幅を広げるよりも、意図的に深みを追求しています。その重点は、分類、構成、監視、および検証に置かれています。なぜなら、実際の運用においては、不備のある指示が欠陥部品を生み出してしまうからです。本書ではその手法を紹介していますが、「エクスチェンジ」では、各エージェントの完全な定義と、エージェントがどのように組み合わさって解決策を形成するのかについて解説します。

この本に登場するすべてのエージェントには、4つのルールが適用されます。「求められていないオペレーターのために設計する」「人間の関与を確保する」「手元にあるデータから始める。手に入れば良いと思うデータから始めない」「利用状況ではなく、成果を測定する」。

次へ

まずはその章から始めましょう。

ここでの内容はすべて、第1章で説明されている基礎を前提としています。第1章は、学び始めるのに最適な場所であり、誰でも自由にアクセスできます。