要件定義の期待感と、リリース後の現実のギャップ
私がEAM導入プロジェクトに関わるなかでよく見聞きするのは、整備履歴や運転データを使って、 具体的にどんな指標をモニタリングし、どのような経営判断を行えるようにするのか、 そのためにどんなデータが必要なのかが設計されないまま、開発が進んでしまうことです。
これもよくある話ですが、開発の中盤以降になって「あれが足りない、これが足りない」と、 やりたいこと・やらなければならないことが次々と具体化します。 結果として追加開発が膨らみ、予算オーバーとなり、本来目指したかったビジョンを実現する前にプロジェクトが途絶えてしまう——そんなケースです。
ビジョンを具体化するために、要件定義に1年から3年をかけることもあります。その時期は、誰もが期待感に溢れていますよね。 ですが、その中身をよく見ると、ソリューションの機能や構成、使いやすさ、最新技術、段階的な開発ステップなど、 リリース直後の運用と乖離した内容であることが多いように感じます。
このようなギャップを抱えたまま進んだプロジェクトでは、あとから分かった追加開発や要件に、合わないソリューションを無理やりカスタマイズしていきます。 機能テストやバグ修正に多大な労力がベンダーにもユーザーにもかかり、初期導入疲れを起こしてしまう。 そして、要件定義で描いた将来ステップに進めない——そんな事例を、私はいくつも見てきました。
ソリューションより先に、流れる血液（データ）を見る
このよくある問題に陥らないためには、まず初めにソリューションの内部を流れる血液（データ）の中身に目を向けたほうがよいと考えています。
データを活用した事業運営のイメージをつかむために、まずはなんとなくでもデータの形を整え、Excelにレイアウトしてみる。 そのデータでExcelやPowerPointを使って画面や欲しいレポートを作成し、業務を少し回してみて、データの形や画面レイアウトを調整していく。 こうした作業が必要だと考えています。
現在は、生成AIがこのようなプロトタイプをすぐに作成してくれるので、コストや検証期間を大幅に短縮できると思います。
「機能を知らないと描けない」という壁
このような話をすると、「まずはソリューションの機能を知らないと、何ができるかイメージできない、具体的な絵にできない」というご意見をよく頂きます。 確かに人間は、白紙のキャンバスに自由に書いていいと言われると、何を書いていいか困ってしまいますよね。 （私自身も、大昔はそう言っていたことがあります。）
さまざまな失敗を経験してきた今の私の意見は、こうです。 これまで積み上げてきた業務のなかで重要だと感じていたことを、具体的な言葉にする。 その具体的な内容をデータレベルに分解したうえで、ソリューションのフィット＆ギャップを行う。 このプロセスこそが重要だと考えています。
データレベルに分解する、とは
たとえば、機器台帳ひとつをとっても、次のような問いがうっすらと脳裏に浮かび上がってくるはずです。
- 機器台帳は、機器の不具合履歴や修理履歴だけでなく、コスト・図面・工程管理なども可能にするか
- 機器の整備コストを可視化したいのは、機器単位か発注単位か
- 整備コストを機器単位に分解したい場合、発注データの案分値はコスト評価として妥当か
- 今後、機器単位で整備コストや整備工数をデータ化する場合、発注の分割は組織的に実行可能か
- コスト集計は発注工事単位、工数集計は工事項目単位とするか
- 機器台帳の階層構造は、コストや工数の集計・分析粒度か、図面等の検索インデックスか、工程管理上有用な単位か
- 設備保全の機器台帳粒度は、設計部門や建設部門の管理粒度とインターフェース可能か
- 保全コストや改造図面等を、設計部門の管理粒度にインターフェース可能か
- 機械担当・電気担当や部門ごとに、管理したい機器台帳粒度へ分ける必要があるか
- 部門の管理粒度に分けたあと、データを再集計できるか
- 管理粒度を変更したい場合、データ移行は容易に可能か
しかし、組織のなかにいると、他部門との調整量が多く、実現までの道のりが遠く感じてしまいます。 そのため、要件定義会議の場で口に出せなくなってしまう——そんな気持ちがあるのかもしれません。
モックアップで関係部門と共通認識をつくる
こんな時こそ、現在自社で利用している機器台帳や保全履歴をモックアップに手早く載せ、関係部門に見せてみることです。 データ整備後の具体的な業務イメージを共通認識として持ちやすくなり、議論が一気に生産的になることがあります。
モックアップは、近年のLLMに指示を出せば数分で作成してくれます。 （私が開発を主導していた頃は、モックアップだけで数カ月・数百万円のコストがかかったものです。）
HOSHUTARO なら、このアプローチのハードルが下がる
大手ベンダーが提供するモデルの利用が、所属組織のセキュリティーポリシーに合致しない場合もあります。 そんなときでも、HOSHUTAROのような完全ローカル駆動が可能なレディメイドアプリなら、 このアプローチのハードルがグッと下がるはずです。
自社の機器台帳や保全履歴を手元のPCだけで素早く形にし、関係部門と共通認識をつくりながら、データの設計を先に固めていく。 ソリューション選定の前に、この一歩を踏み出せるかどうかが、プロジェクトの行く先を大きく左右すると、私は考えています。