ーーーー講義録始めーーーー
マネジメントのダウンサイジングとマイクロプロジェクトの設計
════════════════════════════════════════
■ プッシュ型からプル型の市場へ
次に、IoTとマネジメントのダウンサイジングという話をします。今までしてきたのはシステムのダウンサイジングという話でした。ここではマネジメントそのもののダウンサイジングを課題とします。分散型で進化する生産システムのビジョンというものをここでは示したいと思います。
企業からのプッシュ型市場から、ユーザーからのプル型――ユーザーが必要なものを引っ張る――そういう形のプル型のネットワーク市場への変化が現在進みつつあります。中期的（約四半世紀の間）には、消費者直結でプル型の多様な生産・サービスシステムがさらに拡大する可能性があります。マス・カスタマイゼーション（Mass Customization）は、顧客注文を起点として、必要な部材や生産を調整しながら、比較的柔軟なカスタム生産を行う考え方として理解されています。そのうえで、大企業中心のモジュール組み合わせ型の生産システムと、オープンで設計が消費者や多様な事業者と共進化し、中小企業も関与しうる生産システムという、二つのシナリオを考えることができます。
これは20年以上前に私が書いたスライドですが、今のIoTの台頭によって、ここで書いたビジョンの一部は以前より実現に近づいています。ここでは情報ネットワーク空間の下で、製造、商品のライフサイクルマネジメント、デザイン、販売、物流といった機能が事業に結びつくことで、消費者の要望を反映した製品が、この組み合わせの中で実現できる――そういう世界を大体四半世紀前に構想していたわけです。もっとも、現実にはそれほど単純ではありませんでした。しかし現在では、クラウド、IoT、データ連携、プラットフォーム技術の発展によって、その一部は以前より現実味を帯びていると言うことはできるでしょう。ここでいう商品のライフサイクルマネジメントは、単なる個別サーバーではなく、企画・設計から調達・生産・サービス・廃棄までを end-to-end で管理するPLMのような基盤的機能として理解するほうが正確です。
ただし、そこでの実現の仕方――つまり大きな企業によるマス・カスタマイゼーションの範囲での実現と、人々が次々に新しいアイデアを出して、オープンな連携の下で広がっていくシナリオの間には、大きな差があります。
■ マネジメント単位のダウンサイジングとマイクロプロジェクト
そこでマネジメント単位そのもののダウンサイジングに注目したいと思います。IoTの時代には、色々な小さな仕事が――ネットワーク上でのもの・人・ソフトウェアが結合した小さなプロジェクト単位として――実行可能になる場面が増えると考えられます。IoT時代には、従来の情報システムの領域を超えて、様々な仕事がネットワーク上でのもの・人・ソフトウェアの結合で行われ、その際にその仕事をどのようにデザインするかというのが課題となります。なお、ここでいう「マイクロプロジェクト」は、講義上の説明概念であり、標準化されたIoTの正式用語として断定するよりも、小さく分解された仕事の束を設計・実行する考え方として理解するのが適切です。システム側の近い概念としては、よく定義されたAPIで連携する、小さく独立したマイクロサービスが知られています。
ネットワークに関して「クラウド（雲）」という言葉は非常に有名ですけれども、ネットワークの末端そのものをそのまま「フォグ」と呼ぶのは正確ではありません。一般に、エッジ（Edge）はデータ生成源や現場により近い側を指し、フォグ（Fog）はクラウドとエッジのあいだ、あるいはその近傍に分散配置される計算・保存・通信の層を指す説明が広く用いられています。このフォグ/エッジ領域でのIoT技術には現在も大きな関心が集まっています。仕事の現場からの継続的な改善を可能とする疎結合で組み替え可能なシステムをデザイン・実装・管理する、そのようなIoTシステムを、クラウドだけではなく、現場に近いフォグやエッジの領域も活用しながら構築する――そこに新たな可能性があるわけです。
■ ブラウンフィールドへの後付けIoT
既存の環境――すでに存在している工場など――20年ものもあれば50年もの、30年ものぐらいの機械がある。そういう工場というのはたくさんあります。製造業やIT導入の実務では、このような既存設備や既存システムが残っている環境をブラウンフィールド、新規に構築する環境をグリーンフィールドと呼ぶことがあります。現実の工場の多くは、まさにこうした既存設備を抱えた環境です。そういうブラウンフィールドに後付け的に付け加える形で、IoTの新しいシステムが導入できて、ローコストで改善・改変ができる――そういうIoTシステムのデザインが求められているわけです。
■ タスクの組み合わせによるカスタマイズされたサービス
IoTをうまく使うことで、世の中のあらゆるタスクを結びつけ、見える化して、複数の組織にまたがることもある多品種・小ロット生産や、多様で個々に異なるタスクの組み合わせでカスタマイズされたサービスを実現しやすくする可能性があります。ここに書かれているものは、様々なタスクです。工場のタスク――プレス、塗装、切削加工――そして遠隔監視のようなIoTのタスク、データ保存、そしてコミュニティのサービス――入院患者支援、退院患者支援、留守宅のペット支援、家事支援、入院中の生活のコンシェルジュ的なサービス――さらに内装工事では、電気工・塗装工・壁張り工・床工・配管工など、様々な職能の人たちが異なった仕事・タスクを行って、それらが結びつくことによって、個別性の強いさまざまなサービスが実行可能になるわけです。
ただし、そこでは、そのようなタスクの組み合わせでカスタマイズされたサービスを実現するために、原価管理、スケジューリング、タスクの着手状況の見える化などの開発・運用が必要になります。そしてそれらは、疎結合に連携可能なマネジメント機能の組み合わせとして実現されることが望ましいわけです。ここでいう「マネジメントのマイクロサービス」は、厳密には小さく独立した管理機能をAPI等で連携させるシステム設計の方向性として理解するのが適切です。
■ タスクとプロジェクトの具体例：工場での製造プロジェクト
ものづくりでのタスクとプロジェクトの例を見てみましょう。ここでは簡単な筐体（箱）を作る製造のプロジェクトを考えています。
【図2：筐体製造マイクロプロジェクトのタスク構造】
開始
├── タスクA：鉄板の切削加工（並列実行可能）
└── タスクB：銅板の切削加工（並列実行可能）
↓（タスクAとBの両方が完了次第）
タスクC：プレス加工（鉄板と銅板を合わせてプレス成形）
↓
タスクD：塗装加工
↓
終了（筐体完成）
このプロジェクトの図式というのは、「これとこれが完了すれば、次が可能になる」「これが終われば、次が可能になる」というふうに順序付けられたタスクの全体がプロジェクトと呼ばれるわけです。プレス加工が終わった後で塗装加工が可能になり、それが終わると筐体が出来上がるという、非常に単純化された4つのタスクからなる製造プロジェクトを考えているわけです。
個々のタスクは、その遂行がプロジェクトの構造の中で順序付けられて実行され、このタスク単位での業務遂行のプロセスは、タスク間の結合がプロジェクト上で比較的組み替え可能な疎結合である、という特徴を持っているわけです。イノベーション等が入った場合には、ここでのタスクの構造が変わって、ここは組み替えられるかもしれません。あるいはプレス加工機械だけが新しいものに変わるかもしれませんが、全体としてこういうものを組み替えながら、一つのプロジェクト――小さなプロジェクトという意味で、ここではマイクロプロジェクトといいますが――このマイクロプロジェクトとして1単位の、ひとまとまりの仕事が定義され、デザインされ、実行されるわけです。
■ タスクの具体例：内装工事プロジェクト
もう少し別の例を見てみましょう。ここでは内装工事ですね。コントラクター（施工業者）がやるマンションなどの内装工事の事例で、通常は200工程ぐらいあるのですが、それを簡略化したものを示しています。
【図3：内装工事マイクロプロジェクトのタスク構造】
開始
├── タスク①：配管（配管工 担当）
└── タスク②：配線（電気工 担当）
↓（①と②の両方が完了次第）
├── タスク③：床張り（床工 担当）（並列実行可能）
└── タスク④：壁張り（壁張り工 担当）（並列実行可能）
↓（③と④の両方が完了次第）
タスク⑤：塗装（塗装工 担当）
↓
終了（部屋の内装工事完成）
まず配管を行い、そして配線を行います。両方が終われば、床張りと壁張りはまた同時にできます。そしてその両方が終われば、今度は塗装タスクが必要となり、それが終わると一つの部屋の内装工事が終了するという形になります。配管タスクには配管工が、配線タスクには電気工が、床張りタスクには床工が、壁張りタスクには壁張り工が、塗装タスクには塗装工が割り当てられて仕事をする必要があります。ここでの工程順序は、実務上の全工程を網羅した標準工程表ではなく、タスク依存関係を説明するための簡略化モデルとして読むのが適切です。
■ タスクの具体例：入院支援コミュニティサービス
さらに、これは今ほとんど実現されていない例ですけども、コミュニティの中で個人の状況に応じて、例えば入院するときなど、いろいろな困った時に、必要なサービスをプロジェクトとして提供する例を考えてみましょう。
【図4：入院支援コミュニティサービスのマイクロプロジェクト例】
開始（入院）
├── 入院手続き支援（支援者 担当）
├── 留守宅のメンテナンス（管理者 担当）
├── ペットの世話（ペット対応者 担当：ペットがいる家庭のみ）
├── 子どもの送迎等（支援者 担当：子どもがいるケースのみ）
└── 在宅業務のコンシェルジュ的サービス（専任者 担当：就労者のみ）
↓（入院期間中、各サービスを継続）
退院支援タスク（各担当者）
↓
終了（退院・生活復帰）
例えば入院時の入院手続き支援、留守宅のメンテナンス、あるいはペットがいる家庭では入院中のペットの面倒を見る、あるいはお子さんのいるケースではお子さんの送迎からいろんなサービスが入ってくるわけです。そして入院中に仕事をしている方で言えば、コンシェルジュ的なサービスが必要になります。そして退院が必要な時期になれば、退院の支援タスクがあるという――そういう形で、ひとまとまりのサービスを定義できるわけです。
そして、この場合、例えば家事支援であれ、ペット支援であれ、入院手続きの支援であれ、あるいは入院中のコンシェルジュ的なサービスであれ、これらが一つの組織から提供される必要もなければ、そうしない方が地域の実情に合う場合もあるでしょう。小さな異なった組織や個人がこれらのタスクを提供して、それが全体として結びついて、きちんとマネジメントできる。そういうIoTベース、あるいはデジタル基盤ベースでのマネジメントがダウンサイジングして低いコストで可能になれば、分散組織の下でこういう新しいタイプのサービスも増えてくる可能性があります。
その意味では、工場というものは物の集積したシステムだったのですけれども、工場のIoT化とは異なる形での様々なサービスのIoT化――つまりマネジメントのIoT化というのがここでは課題となるわけです。ただし、ここでいう「マネジメントのIoT化」は、厳密には、IoTそのものだけでなく、クラウド、エッジ／フォグ、データ連携、可視化、スケジューリング、業務設計などを含む広いデジタル化の問題として理解するのが適切です。
