(日本語) 3.ゆるやかな標準の作り方

Sorry, this entry is only available in Japanese. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

インダストリー4.0の報告書の中でも、まず最優先に取り組むべき課題は、標準化であると書かれています。ここでいう標準化には、厳格な標準化とゆるやかな標準化の両方が含まれます。ただし、実際のところ、ドイツでは、こうした標準化の取り組みが着実に進んでいるかといえば、そうではありません。こうした作業は大幅に遅れており、あそ2、3年はかかるといわれているようです。

ここで、標準化について、国際標準などのデジュール標準と、個別企業が単独あるいはコンソーシアムを形成して実質的な標準とするデファクト標準があり、さらにはよりオープンな議論をとおして実質的に有効であるフォーラム標準がその中間に位置します。インダストリアル・バリューチェーン・イニシアチブとしては、この第三のカテゴリに対応します。

そのためには、まず、日本の製造業が個別のプロジェクトの中で既存のリファレンスモデルの活用を促し、あらたなリファレンスモデルの開発を支援するチームが必要となります。

おそらく、インダストリアル・バリューチェーン・イニシアチブの中で繰り広げられるさまざまなプロジェクトの中で、異なる企業が共通の業務アクティビティや共通の業務オブジェクトを議論する際に、こうした標準化チームが関与することで、混乱や回り道をできるだけ避けることができるでしょう。そして、同時に、そうした成果を、標準化チームが、他のプロジェクトや、既存の国際標準との整合性も見比べながら、最終的には、わが国からの提案として、国際標準の一部として提案していくことをめざしています。

業務シナリオの定義

IVIのリファレンスモデルを作成するにあたっては、まず業務シナリオから定義します。データはあくまで業務を実行し目的を達成するための手段だからです。業務シナリオを定義する場合、以下のように、(1)現状と課題、(2)解決手段、(3)目指す姿、そして、そのために必要となる(4)共通化すべきモデル、を明らかにします。

現状と課題

企業または工場において、現状の業務がどのようなものであって、どの点が問題あるいは課題となっているかについて説明してください。通常、問題や課題は、有のままの現状に対して、こうしたい、こうあるべきという要求、願望があってはじめてなり足ります。つまり、現状をどのような立場で、どうとらえ解釈するかによって問題や課題は異なってきます。企業の場合、あるいはコンソーシアムのWGの場合、こうしたある意味で主観的となるとらえ方について、その立ち位置やベクトルを、ディスカッションのなかである程度レベル合わせしておく必要があります。

解決手段

解決手段とは、先に挙げた問題あるいは課題を解決するための方法、手順を中立的かつできるだけ一般的にしめしたものです。ここでは、具体的に示す必要はなく、すでに世の中でしられている手法やソリューションを一部で活用するような場合には、それをどのように利用するかまでを記述すれば足ります。多くの場合、課題に対する解決手段は複数あります。どれを選択するか、あるいはどのような解決手段をデザインするかは、これも主観的かつクリエイティブな領域となります。複数の解決手段が併存する場合は、併記することも可能です。

目指す姿

目指す姿とは、問題や課題が解決された状態ではなく、その先にあるであろう新たな世界のことです。課題が解決された状態と目指す姿とは、因果関係がある必要はありますが、必然性は必ずしも必要ありません。言い換えれば、課題が解決された状態は、理想とする目指す姿の必要条件であって、十分条件ではないと認識します。目指す姿になるためには、他にもやるべきことがありますが、少なくとも今回の課題は解決しておかねければならない、といった関係になります。

共通モデル

課題を解決するための手段を実行する上で、業務アクティビティ、および業務オブジェクトの標準化の視点がどこかで必要となります。立場の異なるステークホルダあるいはアクターが相互にコミュニケーションする場合、あるいはデータを用いてさまざまな業務やその背後にある知識にアクセスする場合に、共通となるリファレンスモデルがあると便利です。アウトプットでは、実際にシナリオをデジタルプラットフォーム上で実行するために必要となるリファレンスモデルを列挙します。

業務シナリオの構造

業務シナリオは、具体的には、いくつかのシーンによって構成されています。これは、あたかも映画や演劇のシナリオがいくつかの場面(シーン)で構成されているのと同じです。そして、シーンは、一人以上の登場人物(アクター)が行うアクティビティによって構成されています。このように、脚本家がシナリオを組み立てるように、業務シナリオを大雑把に定義していきます。

シーン

シーンとは、ビジネスシナリオを構成するそれぞれの場面です。シーンには1人以上のアクターが登場します。アクターは固有名詞ではなくある役割をもった登場人物です。シーンでは、登場するアクターがそれぞれ行うアクティビティのインタラクションによってひとつの関係性(パターン)が構成されます。シーンは、一般的に、時間を場所が連続しており、時期や場所が異なる場合は、別のシーンとなります。

アクティビティ

アクティビティは、シーンにおける各アクターのそれぞれの一連の振る舞いをいいます。アクティビティは、それを開始するためのトリガーによって起動され、いくつかのアクションを実行した後に終了します。結果として(副作用として)アクティビティは、モノや情報を生み出したり、加工・修正したり、廃棄・削除したりします。アクティビティはあらゆる活動の基本単位となり、原価計算の単位にもなります。

ドキュメントとオブジェクトを区別する

話がだいぶ抽象的になってきました。アクティビティとは、簡単にいえば、仕事の単位です。「注文を受け付ける」「作業日報を作成する」「指示を受けて装置を起動する」といったことは、その終了後に何か意味のある変化があり、それが仕事の最小の単位です。ただし、一般に、アクティビティは、複数のアクションで構成されている場合が多いのです。たとえば、「注文を受け付ける」というアクティビティは、「注文書の内容にぬけがないか調べる」「在庫を確認する」「単価を調べ、金額、納期を設定する」「最終的な確認し受理通知を送る」といった複数のアクションで構成されています。

ここで、アクションの多くは、情報を生成したり、確認したり、訂正したり、追記したりすることがほとんどであることがわかります。こうしたアクションが対象とする情報は、注文書であったり、価格表であったり、顧客リストであったりします。これらをドキュメントとよび、そこに登場する現実のモノ、コトの単位をオブジェクトと呼びます。つまり、アクティビティを定義するには、何をどうするのか、において、その“何を”にあたる情報の形を、ドキュメント及びオブジェクトによって記述し完成します。

業務フローを定義するのではない

事務処理をIT化する場合に、業務フローを定義し、それにあわせて情報システムを構築するという方法がとられます。業務フローは、仕事の流れそのものですので、直観的にわかりやすく、検証もしやすいので、多くの企業の業務分析などにもよく利用されます。しかし、業務フローの欠点は、例外的な状況、あるいは状況によってフローが変わるといった臨機応変な仕事の流れを記述しにくいということです。生産現場は、まさに、例外的な状況のオンパレードですよね。

そこで、IVIでは、例外処理だけアクティビティを定義し、それをフローにはしません。複数のアクティビティをつなぐのは、条件で指定されたトリガー(きっかけ)と特定オブジェクトのデータです。言い換えれば、データの形式と、つなぐためのインタフェース(とりきめ)だけ決めておき、レゴブロックのように、業務アクティビティが例外の状況に応じて柔軟に連携するようにしておきます。