はじめに：これはすべて、私の泥臭い実体験です
最初にみなさんにお伝えしておきたいことがあります。これまでのブログ記事でご紹介してきたDXや業務効率化のノウハウ、そしてこれからお話しするエピソードは、すべて私自身が社内で実際に経験し、手を動かしながら積み上げてきたリアルな実績に基づいています。
ITの専門家が書いた教科書通りのきれいごとではありません。
「現場の負担をなんとかして減らしたい」「入力されたデータを意味あるものに変えたい」
そんな想いだけでスタートし、古いシステムからの脱却、業務フローの再設計、そして現場への定着まで、数々の壁にぶつかりながら進めてきた「生きた軌跡」です。
あなたの職場にも、こんな悩みを抱えたシステムや業務はありませんか？ 「あっちのシステムにも入力して、こっちの共有メモ帳にも同じことをコピペしている……」 「せっかく毎日記録しているのに、過去の事例がまったく活かされていない……」
今回は、私が開発した「業務改善（事象管理）アプリ」を題材に、単なるツールの置き換えに留まらない本質的な変革のプロセスを、前編・後編の2回に分けてお届けします。
後から知ったのですが、私がやった一連の取り組みは、IT業界では「モダナイゼーション」と呼ばれる格好いい活動そのものだったみたいです。前編となる今回は、現場の課題認識から泥臭い本番導入、そして不具合との格闘までを振り返ります。
💡 ちょっと解説：モダナイゼーションとは？ 「現代化」や「最新化」という意味のIT用語です。長年使い込んで古くなったシステム（レガシーシステム）を、現在のビジネス環境や最新のクラウド技術に合わせて刷新することを指します。単に見た目を新しくするだけでなく、今の時代に合った使いやすい形に中身ごと生まれ変わらせるのが特徴です。
起点：情報分散の闇と、見えてきた「本質的な課題」
物語の始まりは2023年頃に遡ります。当時、私たちの職場では長年使い込んできた古い共有の電子メモ帳データベース（DB）を、日々の業務記録や発生した事象の管理に使っていました。
しかし、時代が進むにつれて、このシステムの歪みが限界を迎えていたのです。
業務に必要な情報は、その古い電子メモ帳だけでなく、日々の引き継ぎを行うための「主要な申し送りシステム」、さらには安全活動や改善活動で使う「個別の報告用シート」など、内容ごとにあちこちに分散してしまっていました。
その結果、現場では何が起きていたか。
「何か事象が発生したら、まずは申し送りシステムに入力する」 「その後、同じ内容を古い電子メモ帳DBにも手作業でコピペして二重登録する」 「内容によっては、さらに別の報告シートにも書き込む」
現場の作業者は、ただでさえ日々の対応で忙しい最中に、何度も同じ内容を異なるシステムに打ち込むという、不毛な「二重入力・手作業コピペ」を強いられていました。
さらに致命的だったのは、これだけ苦労して入力したデータが、それぞれ独立した場所に眠っているため「まったく活用できない」という点です。過去の類似事例を探そうにも、検索すらままならない状態でした。
この状況を前にして、私は議論を重ねる中で一つの方向性を確信しました。 「日々の記録は、個別のメモ帳にバラバラに書くべきではない。現場の運転データ・稼働データとしっかりと紐づけて一元管理するべきだ」
ここがすべての出発点でした。私たちが解決すべき本質的な課題は、単に「古いツールを新しいツールに変える」ということではなく、「データの分散」「二重入力の手間」「データが死んでいる（活用できない）」という、業務の構造そのものにあったのです。「モダナイゼーション」なんて言葉は1ミリも頭にありませんでしたが、結果的にこれがその第一歩となりました。
初期構想と業務設計：「アプリ開発」ではなく「業務プロセスの再設計」
「作れるか？」を検証する初期構想フェーズ（2023年〜2024年前半）
全社的なシステム刷新の流れとも連動し、私はマイクロソフトの「Power Platform（主にPower Apps）」というローコードツールを使った、新たな事象管理・共有アプリの構築に乗り出しました。
2023年から2024年前半にかけては、いわばプロトタイプ（試作）の時期です。 社内のコミュニケーションツール上でメンバーと「こんなアプリにしたら使いやすいんじゃないか？」「画面の入力フォームはこれがベストか？」と、UI（画面デザイン）の相談や試作を繰り返しました。
この段階の特徴は、「本当に自分たちで思い通りのアプリが作れるのか？」という技術的な検証とUIのブラッシュアップが中心だったことです。まだ正式なプロジェクトというよりは、可能性を探る種まきのフェーズでした。
「単なる入力アプリ」にしない、業務フロー全体の再設計（2024年前半）
2024年の前半に入ると、この取り組みはDX推進チームでの正式な議論へと格上げされました。ここで私は、アプリの機能を拡張すること以上に、「業務のあるべき姿とは何か」という業務フローの整理に多くの時間を割きました。
具体的には、単なる画面作りではなく、以下のような生々しい業務の骨組みを一つずつ整理していったのです。
- 各部門・部署へのヒアリングと業務の違いの整理： 一口に「事象の報告」と言っても、部署や部門によってやり方も違えば、求めているルールもバラバラでした。まずはそれぞれの現場に足を運んでヒアリングを重ね、どこが共通でどこに違いがあるのかを徹底的に洗い出しました。
- 承認設計の抜本的な見直し： 「誰が確認し、誰が承認するのか」というプロセスが曖昧だと、アプリを入れても結局仕事は回りません。現場の負担にならず、かつ管理者が責任を持ってチェックできる最適な承認ルートへと、これまでのやり方を見直しました。
- 管理側の動作確認と必要な機能の整理： 入力する側だけでなく、それを受け取る管理側（上長など）がどう動くかも重要です。「どこにコメントを残せるようにするか」「上長が本当に知りたい情報はどれか」を突き詰め、管理側の画面や動作を細かく検証しました。
お気づきでしょうか。これは、散らばっていたメモ帳を一つにする「単なる入力アプリの開発」ではありません。 「事象の発生から対策・完了に至るまでの、業務フロー全体の再設計（リエンジニアリング）」を行っていたのです。
既存のめんどくさい業務をそのままデジタル化しても、めんどくさいデジタル業務が生まれるだけです。システムを変えるタイミングこそ、業務そのものを一番綺麗な形に整える最大のチャンス。横文字を使えば「業務のモダナイゼーション」ですが、要するに「現場が一番楽に、正しく仕事ができる仕組み作り」を泥臭く追求したわけです。もちろん現場の猛反対もおまけについてきます。笑
現場を巻き込む試運用から、本番移行へのリアルな格闘
運用マニュアルの確立とユーザーテスト（2024年7月〜9月）
2024年8月頃、練り上げた業務フローをベースに、ついに具体的な運用の形が完成しました。
アプリ内のプロセスは、以下のように明確な4ステップに構造化しました。
- 報告登録（現場が事象を即座に入力）
- 上長判断（管理者が内容を確認し、方針を決定）
- 対策登録（具体的な対応策や再発防止策を記録）
- 完了判断（対策が機能したかを確認し、クローズ）
このフローを動かすために、私は誰でも直感的に使える「簡易マニュアル」を作成し、配布しました。
正式リリースに向けて、2024年7月から9月にかけて試運用フェーズへと突入します。 説明会を丁寧に行い、時には個別に足を運んで使い方を説明しました。組織内での連携を通じて「9月中に全員でテストを実施します」とアナウンスし、実際に現場のユーザーに触ってもらう「ユーザーテスト」を徹底したのです。
現場に使ってもらうことで、システムは初めて命が吹き込まれます。この段階で運用の細かいシミュレーションができたことは、大きな収穫でした。
本番移行と、直面した「システム開発あるある」の壁（2024年10月）
正式な稼働を迎えた2024年10月、アプリは満を持して本番環境へと移行しました。長年続いた旧運用からの切り替えです。
しかし、スムーズに100点満点のスタートが切れたわけではありませんでした。 本番稼働直後、自動化ツールを使って構築していた「関係者へのメール自動送信機能」などに、想定していなかった不具合が次々と発生したのです。
通知が飛ばない、あるいは想定外の挙動をする——。 まさに「運用して初めて、隠れていた課題が顕在化する」という、システム開発における手痛い洗礼を浴びることとなりました。
ですが、ここで私はプロジェクトを止めることはしませんでした。
そこからは、想定外の不具合を必死で改修する日々の始まりです。毎日頭を悩ませながらコードや設定と格闘していましたが、不思議と心が折れることはありませんでした。なぜなら、現場のメンバーが「ここが動かんぞ」「こういう風になったらもっと使いやすい」と、次々にリアルなフィードバック（声）を寄せてくれたからです。
文句を言われて終わりではなく、「一緒にシステムを良くしていこう」という現場の熱量があったからこそ、私も「すぐに直してやろう！」と奮起し、泥臭く修正を続けることができました。
この私の「粘り強さ」が現場との二人三脚を生み、お互いの信頼関係が深まったことで、結果として迷いのない「圧倒的なスピード感」での改修へとつながっていったのです。
最初から完璧なシステムを狙って作ったわけではありません。不具合にぶつかりながらも、現場の声を力に変えて一緒に仕組みを育てていく――これこそが、アプリを殺さずに定着させる唯一の道だったと思います。
前編のまとめ：ここからアプリは「真の価値」を発揮する
新アプリの立ち上げから本番稼働までを振り返ってみました。
「モダナイゼーション」なんて大層な言葉は知らなくても、この前編のプロセスからは、現場主導のシステム刷新における重要な教訓が2つ見えてきます。
- 教訓①：本質は「ツールの導入」ではなく「業務の再設計」にある
単なるツールの置き換えを目標にせず、既存システムとの連携や承認プロセスの見直しなど、業務フロー全体を綺麗に整えたからこそ、現場に意味のあるシステムになりました。 - 教訓②：現場の声に支えられた「粘り強さ」がシステムを育てる
本番稼働後の不具合に対しても、現場と二人三脚で泥臭く修正を重ねたからこそ、大きな混乱なく運用を定着させることができました。
こうして2024年10月、新しい業務改善アプリは無事に正式運用というスタートラインに立ちました。
しかし、物語はここで終わりません。現場に定着したアプリは、ここからさらなる「進化」を遂げることになります。
ただの不具合対応に追われるフェーズから、現場が本当に欲しかった「検索機能」や「上長コメント機能」といった便利な機能の追加。そして2025年から2026年にかけて、アプリは「単なる記録ツール」から「未来の業務を予測・支援するデータ活用ツール」へと、次元の違うステージへと駆け上がっていくのです。
次回の後編では、Power BIやAIを組み合わせた「データ活用フェーズへの進化」、そして部内から他部門へと広がっていく「横展開の軌跡」について詳しくお話しします。
あなたの会社のデータを目覚めさせるヒントが詰まっています。ぜひ、次回も楽しみにしていてください！
コメント