前回の記事「解説: プロセス構造DSM」では 設計構造マトリックス（DSM: Design Structure Matrix） の中でも、特にプロセス構造DSMについて解説しました。 今回は実際にプロセス構造DSMを使った業務プロセスの改善事例を紹介します。
前回の記事の中で、ガント・チャートなど一般的なプロセス管理ツールは各ステップの依存関係がほとんど考慮されておらず、その結果として後工程からのフィードバック（不具合の発見等）による前工程のやり直しなどもほとんど考慮されていないことなどを指摘しました。そして プロセス構造DSMはその問題点を補完するものとして、各ステップの依存関係を明示し、プロセスに潜む潜在的リスクを見つけ出し、各ステップの順序を最適化するアイデアを与えるプロセス改善ツールだと説明しました。
では実際にどのようにプロセス構造DSMを使うのでしょうか。 新製品の開発から製造開始までの業務プロセスを例にとって説明します。
問題の定義
問題となった新製品の開発から製造開始までのプロセスには、各ステップ間に複雑な依存関係がありました。各部署や各職務の業務プロセスが平行して進められていたために、各プロセス・ステップ間の入力と出力が時間的にも内容的にも複雑に絡み合っていただけではなく、至る所で「やり直し作業」が発生しており、プロセス全体の流れや進捗を知ることが非常に困難でした。
問題を一言で定義すれば「新製品開発スケジュールの遅れ」であり、その原因としては
- 後工程で設計不具合が発見される
- そのため、開発後期になって前工程に戻るやり直し作業が発生する
- また、依存アイテムの入力待ち時間が発生する
などが考えられました。改善の課題は「潜在的リスクを軽減し、やり直し作業を防ぐこと」としました。
ワークショップの開催
そこでプロセス構造DSMを使って各プロセス・ステップ間の 依存構造を表現してみることにしました。しかしプロセス構造DSMを作るためには、各プロセス・ステップ間 の入力と出力を前もって知る必要がありました。そこで14の部署から46人の参加者を集めてワークショップを開催し、SIPOCを使って14部署のプロセスとその入出力を確認してみました。
14個のSIPOCを作る過程でワークショップ参加者が共通して認識したことは、
- それぞれの部署は自らのプロセスを最適化しているので、全く問題は無いように見える
- しかし各プロセス・ステップにおける他部署からの入力は単なる希望や期待であり、定義されたものではない。またそのタイミングも他部署と同期がとれていない。
- 結果として他部署から期待している入力がなかったり、入力が遅れたり、遅れた入力や間違った入力のためにやり直し作業が生じている
- 14部署のプロセス全体を把握している人が誰もいない
というものでした。
次に、14個のSIPOCから得た情報を基に、大きな一つのプロセス構造DSMを作りました。しかしプロセス・ステップ総数は100以上にも及び、またその依存関係は300以上にもなったため、すべての依存関係を一度に検討することには無理がありました。そこで依存関係に優先順位をつけるために、ワークショップ参加者に2つの質問をしました。
- あなたの部署が仕事を進める上で最も重要な入力は何ですか？
- あなたの部署が「やり直し作業」をするとすれば、それはどのステップで、そのきっかけとなる入力は何ですか？
回答を基にプロセス構造DSM上の依存関係マークをこの優先順位に従って色付けし、その優先順位（色付け）に従ってプロセスに潜むの潜在的リスクを検討し、リスクを軽減する改善策を議論しました。以下はSIPOC や プロセス構造DSM を使ったワークショップの大まかな流れです。
プロセス構造DSMを使った潜在的リスクの認識
以下は、実際のプロセス構造DSMと認識したリスクを示したものです。
プロセス構造DSMによって認識したリスクは特に新しいものでも、驚くべきものでもありませんでした。ただワークショップ参加者はそのリスクは薄々分かっていたけれども、どうすることもできないでいただけでした。一つずつ見ていきましょう。
リスク1: 製品開発仕様書や売上予想の変更
製品企画管理部門では、新製品の開発仕様書や売上予想を作成します。これらがある程度まとまると、他部門はその情報を基に各プロセスを開始します。製品開発部では開発仕様書を基に設計を開始し、商品化開発部では売上予想を基に製造ラインの準備を開始し、製造部では製造技術の調査などを開始します。つまり各部署が製品開発仕様書や売上予想に強く依存しており、これらの変更が及ぼす影響は甚大だということです。実際に新製品の開発仕様書や売上予想は頻繁に更新（追加や変更）され、そのたびにドミノ倒しのように各部署でやり直し作業が発生していました。
リスク2: 回路、機械、ファームウェアなどの機能変更
開発工程で新たな問題が見つかり設計のやり直しが生じることは避けられません。しかし電気回路や機械、ファームウェアなどから構成される複雑な製品開発の場合、ある部署での機能変更は他の部署の機能にも大きな影響を及ぼします。機能変更のタイミングが悪かったり、部署間のコミュニケーションが悪かったりすると、その影響は甚大なものになります。
リスク3: プロトタイプ試作時に発見される不具合
開発作業が完了するとプロトタイプを作成しますが、この時に不具合が発見されると、不具合を修正するためにプロセスが前工程（つまり開発作業）に再び戻ってしまいます。そして不具合の内容によっては開発を一から始めることになります。
これらのリスクはプロセス構造DSM上の依存関係（マーク）の並び具合、固まり具合、対角線からの距離から判断しました。プロセス構造DSMを使うことでリスクを目に見える形で表現できただけではなく、ワークショップ参加者とそのリスクを共有することができました。
しかしプロセス構造DSM に慣れていない人達に認識したリスクを説明するために、プロセス構造DSMを単純なプロセス・フロー図に変換してみました。
最初の図は、皆が期待しているスムーズなプロセスの流れです。
そして次の図が、実際に起こっているプロセスの流れです。黄色の線は、後工程から前工程へのやり直し作業を示しています。
プロセス構造DSMを使ったプロセスの改善
前々回の記事「解説: 設計構造マトリックス」の中では、分析（改善）のやり方には以下の二つがあることを説明しました。
- 集合分析（Clustering Method）
- 順序分析（Sequencing Method）
そして前回の記事「解説: プロセス構造DSM」の中では、プロセス構造DSMを使った分析（改善）の目的は
- 対角線から上の依存関係を減らすこと
- 対角線から上の依存関係の対角線までの距離を縮めること
- 依存関係が固まった集合を作ること
であることを説明しました。
実際にプロセスの順序を目的に従って変えてみたところ（行と列を同時に動かす）、プロセス構造DSM上の依存関係（マーク）の位置が以下のように変わりました。
対角線よりも下の依存関係（マーク）は大きなリスクではないのでそのままにしました。しかし対角線よりも上の依存関係、特に赤色のマークは危険度が高い依存関係なので、できるだけ左側（対角線からの距離を縮める方向）に動かしてみました（プロセスの順序変更）。
そしてワークショップの中で、参加者と一緒に新しいプロセス構造DSMから導いた改善案は以下のようなものになりました。
「リスク1: 製品開発仕様書や売上予想の変更」に対する改善案
開発仕様書や売上予想に変更があれば、速やかに各部署に通知し、変更がプロジェクトに与える影響をチーム全体で検討し、チームが受け入れることができる変更であれば、速やかにプロジェクト計画に反映させる。
「リスク2: 回路、機械、ファームウェアなどの機能変更」に対する改善案
開発工程で新たな問題が見つかり設計のやり直しが生じることは避けられないため、アジャイル開発等を採用して各設計部署間の協調を高め、問題の早期発見・解決に努め、やり直し作業の影響を局所的かつ短期的にする。
「リスク3: プロトタイプ試作時に発見される不具合」に対する改善案
基板製造ツールによる試作を開発段階から導入し、開発部メンバーと製造部メンバーが協働することで、後工程で不具合が発見されるリスクを未然に防止する。プロトタイプの試作についても、３Dプリンターなどを使って開発段階から設計を評価し、同じく後工程で不具合が発見されるリスクを未然に防止する。
プロセス構造DSM を使って認識したリスクや、 プロセス構造DSM を使って 導いた改善策は、決して驚くほど斬新なものではありませんでした。しかしワークショップの中で参加者全員がリスクと改善策を共有できたことは何よりの成果でした。後はこの共有した改善策を実行するのみです。