はじめに
こんにちは。
私は、ビジネスエンジニアリング株式会社で製造業向けのシステム導入コンサルティングを担当しています。
普段、エンジニアの皆さんが実装に取り組まれる前段階の「要件定義」において、私たちコンサルタントがどのように業務を整理し、仕様へと落とし込んでいるのか、その思考プロセスを共有したいと思い、この記事を執筆しました。
技術的な実装そのものではなく、システムが現場で真に活用されるための「土台作り」の視点から、エンジニアの皆さんと共通認識を持つための一助となれば幸いです。
システム導入後の実態
システム導入を検討されているお客様にお話を伺いに行くと、以下のような声を耳にすることがあります。
- 「システムは入れたけど、思っていたのと違った」
- 「結局使いづらくて、一部的にしか使っていない」
多額の資金と労力をかけて導入したシステムが、現場で十分に活用されていないケースは意外と多いのです。
その原因はさまざまですが、大きな要因の一つに本記事で説明する 「業務のモデル化」の不十分さがあります。特に製造業の現場は「暗黙知」や「例外的な運用」がブラックボックス化しがちです。
このブラックボックスを解消し、製造業のDXを成功させるために不可欠なのが 「モデル思考」 です。
本記事では、システム構築の土台となる「モデル思考」の重要性と、その具体的なフレームワークをお伝えできればと思います。
なぜ「モデル化」が必要なのか？
モデル化とは、業務の構造、データ、そして流れを抽象化・可視化し、「設計図」 として定義することです。
注文住宅を建てる際に、家族の人数に合わせた間取り、生活導線に合わせたレイアウトやコンセント位置などを決めた設計図が必要なように、複雑な製造業務をシステム化する際も、業務の理想的な姿をモデルとして設計しなければなりません。
モデル化をせずに導入を進めてしまうと、システムは単なるツールに留まり、非効率なプロセスやムダまでそのままITに組み込まれてしまいます。
その結果、しばらく経つと使われないシステムになってしまうです。
業務をIT化するための３つのモデル思考フレームワーク
製造業の複雑な業務をITシステムに落とし込むためには、以下の3つの視点からのモデル化が必要です。これらも注文住宅に置き換えてご説明します。
1. 業務プロセスモデル
業務が 「いつ、誰が、どこで、どのような順序で」 行われるかを定義します。
- 注文住宅での例え: 「生活動線」の設計
- 詳細: 「朝起きて、洗面所へ行って顔を洗い、リビングへ行って朝食を食べる」といった動きに対し、動作のトリガー（目覚まし時計）や条件分岐（時間があればランニング）まで洗い出します。
2. データモデル
業務で扱うすべての情報の構造、定義、関係性を明確に定義します。
- 注文住宅での例え: 「収納や配線」の設計
- 詳細: 「家族全員の服をどこで管理するか（一括or個別）」「テレビ用のコンセントはどこか」を考えます。データの置き場を決め、情報の分散や欠落を防ぎます。
3. 機能モデル
業務プロセスを実現するために必要な機能を階層的に整理し、どのシステムで実現するかを定義します。
- 注文住宅での例え: 「住宅設備（スペック）」の設計
- 詳細: 「全館空調にするか」「スマートキーにするか」など、特定の目的を叶えるために、どんな便利機能を持たせるかを洗い出します。
モデル化をするための５ステップ
【ステップ1】生産・業務プロセスの可視化
対象とする業務範囲を決め、スタートからゴールまでの作業をすべて書き出し、まずは現状を把握するところから始めます。現状の「業務プロセス」を図解し、現場で起きている不便やムダを洗い出すことで、「部署をまたぐ承認待ちが発生している」「毎日Excelへの転記作業に時間を費やしている」といった現場の停滞箇所を特定します。
- 作成文書: As-Is業務フロー、課題一覧表など
【ステップ2】情報の整理・構造化
プロセスの中で使われる「モノ（顧客・製品）」や「書類（伝票・履歴）」をデータとして抽出し、それらの情報がどのように関連しあっているかを整理します。「同じ顧客の情報が複数のエクセルに散らばっている」といった情報の分散や重複をなくし、データの正しい置き場を決めます。
- 作成文書: データ項目定義書、ER図など
【ステップ3】理想的な業務フローの設計
ステップ1で特定した課題を解決し、ITで自動化・簡略化した「理想の業務プロセスの流れ」を描きます。「一定条件を満たせす場合は承認をスキップする」「オンラインフォームからの入力値をそのままシステムへ自動反映させる」などの自動化シナリオを決めます。
- 作成文書: To-Be業務フローなど
【ステップ4】必要なIT機能の定義
ステップ3で描いた理想的な業務フローを実現するために、ITシステムが具体的に何ができなければならないかを機能単位でリストアップします。その際、人がやるべきことと、ITが自動でやるべきことの「役割分担」も併せて明確に決めるなければなりません。
- 作成文書: 機能一覧表、画面・帳票イメージ案など
【ステップ5】モデル間の整合性チェック
「新しい流れ（プロセス）」に「必要な情報（データ）」が揃っており、「選んだ道具（機能）」で正しく動かせるかを最終確認します。「プロセス・データ・機能」3つのモデルが矛盾なく連携しているかの検証です。
- 作成文書: 機能・プロセス対応表、データフロー図など
モデル化する上での留意点
今までの経験から、3つのモデルを定義する上で、特に気をつけるべき2つのポイントを挙げます。
① 現行踏襲の罠に陥らない
ユーザーは、今の業務のやり方が一番（最適解）と信じ込んで、As-Isの大部分をTo-Beに持ち込みたがってしまうことです。
実は無駄な業務であったり、もっと効率的にできる方法があるにも関わらず、俎上にもあがらずTo-Beに入れてしまったり、現行の運用を変えることを嫌がり業務の見直しを十分にしないままシステム化することで、結果として思ったより投資対効果を感じられないシステムになってしまう恐れがあります。
To-Beを設計する上で「なぜこの作業が必要か？」という問いに対し、「昔からそうだったから」以外の明確なビジネス上の付加価値を問うプロセスが不可欠です。
② 「ほどよい加減」のモデル化
効率化を目指しすぎたことにより、ガチガチにシステム制約がかかってしまい、現場のイレギュラーにシステムで対応しきれなくなることです。
それを防ぐために、あえて「ゆとり」を持たせる設計が重要です。
- 9割の標準パターン: 自動化・効率化。
- 1割の例外: 人間が備考欄や手動介入で柔軟に処理できる 「ゆとり」 を持たせる。
このバランスが、長期的に使われるシステムにするコツです。
さいごに
技術的な視点だけでなく、この「モデリング思考」を技術者の皆さんと共有し、同じ方向を向いてシステムを組み上げることができれば、お客様に長く愛されるシステムが実現できるはずです！