アプリはリリースした。でも誰も使っていない。
ロッカーの前に「新しい点検アプリを使ってください」という張り紙がある。でも現場の人間は相変わらず紙に書いて、あとで事務所でExcelに転記している。管理者が「なぜ使わないんだ」と聞くと、「入力が多くて面倒で……」と返ってくる。
これは担当者の意識の問題ではない。アプリを作る前の設計に問題があった、ということだ。
—
「作ったのに使われない」は珍しくない
ノーコードツールの普及で、FlutterFlowやGlideを使えばプログラミングなしで業務アプリが作れるようになった。現場改善の機運が高まると、「とりあえず作ってみよう」という動きが生まれやすい。
ただ、私がいた現場では「作ったのに定着しなかった」ケースを何度も見てきた。
よく見たパターンはこの3つだ。
1つ目は「入力項目が多すぎる」パターン。作った側は「せっかくだから全部記録しよう」と考える。結果、1回の入力に5分かかるアプリができあがる。現場の人間が「紙の方が早い」と言い始めたら、そのアプリは終わりだ。
2つ目は「誰のためのアプリかが曖昧」なパターン。入力するのは現場担当者、見るのは管理者、データを使うのは品質部門——という三者が存在するのに、誰の課題を解くのかが整理されていない。結果、どの視点でも「使いにくい」アプリになる。
3つ目は「既存の業務フローと噛み合っていない」パターン。作業中に手が汚れているのに画面タップを求める。記録するタイミングが作業の流れと合っていない。手順書の順番とアプリの順番が違う。こういう細かいズレが積み重なって、現場に受け入れられなくなる。
—
なぜこの問題が起きるのか
「良かれと思って作った」という言葉をよく聞く。それは本当だと思う。問題は善意ではなく、情報の整理の順番にある。
多くの場合、こういう順番で進む。
> 「Excelが大変そう → アプリにしたら楽になるはず → 作ろう → リリース」
ここに抜けているのは「誰が、何を、いつ、どう使うか」を先に固める工程だ。
システム開発の世界では「要件定義」と呼ばれる。ただ、現場改善の文脈では「そこまでやらなくていいだろう」と省略されやすい。ノーコードツールは「すぐ作れる」ことがメリットである反面、「考える前に作り始めてしまう」落とし穴を生みやすい。
担当者の熱意や努力とは関係ない。仕組みを先に決めていないから、こうなる。
—
放置するとどうなるか
使われないアプリは、ただ無駄になるだけでは終わらない。
まず、二重管理が生まれる。アプリに入力している人と、紙で記録している人が混在する状態になる。どちらが正しいのか分からなくなる。医療機器の点検記録であれば、記録の信頼性そのものに影響する可能性がある。
次に、「DXへの不信感」が現場に広がる。「あのアプリも使われなかった」という前例ができると、次の改善提案に対して現場が動かなくなる。一度の失敗が、その後のDX推進を何年も遅らせることがある。
さらに、作った担当者が孤立する。「頑張って作ったのに誰も使ってくれない」という状況は、モチベーションを削ぐだけでなく、担当者の評価にも関わる。
→ 担当者の属人化問題については[こちらの記事](/medical-device-maintenance-solo-dependency-risk/)も参照してほしい。
—
内製前に確認すべき要件定義の3つの視点
では、どうすれば「使われるアプリ」になるのか。開発の前に、3つの視点で整理することが重要だ。
視点1：「誰が使うか」を一人に絞る
ユーザーが複数いてもいいが、「主に使う人」を一人に絞る。その人の立場で、全ての設計判断を行う。
入力する現場担当者を主ユーザーにするなら、「入力のしやすさ」が最優先になる。管理者が主ユーザーなら、「集計・閲覧のしやすさ」が最優先になる。両方を同時に解こうとすると、どちらも中途半端になる。
視点2：「解決したい課題」を一文で言えるかテストする
「業務を効率化したい」は課題ではない。「点検記録の転記に1件あたり10分かかっていて、月20時間が消えている」なら課題だ。
一文で言えない場合、まだ課題が整理されていないサインだ。アプリは課題を解くための手段であって、アプリを作ること自体が目的になってはいけない。
視点3：「既存の動き」を先に図に書く
現状の業務フローを先に可視化する。「誰が・何を・いつ・どこで・どうやって」やっているかを書き出す。
そのうえで「どのステップをアプリに置き換えるか」を決める。この順番を逆にすると、アプリが現場の動きと噛み合わなくなる。
—
判断基準——まだ手作業でいい場合
全ての業務をアプリにする必要はない。以下の基準で判断するといい。
まだ手作業・紙・Excelで十分な場合:
- 月に数回しか発生しない業務
- 記録する人が一人だけ
- 集計・分析が不要で、ただ残すだけでいい
テンプレート・フォーム化で十分な場合:
- 記録する項目が固定されている
- 承認フローが複雑でない
- データの活用より「記録の標準化」が目的
アプリ開発を検討すべき場合:
- 複数人が同じタイミングで記録する
- リアルタイムで情報を共有・集計したい
- 現場でカメラや計測器と連携したい
—
今日できる改善手順
Step 1：「誰が・何に困っているか」を20分で書き出す
管理者が困っていることと、現場担当者が困っていることは違う。両方を書き出して、今回解くのはどちらかを決める。
Step 2：現状の業務フローを1枚の紙に書く
ポストイットでも、ノートでもいい。「記録するまでの動作」を時系列で書き出す。何ステップあるかを数える。アプリはそのステップ数を増やしてはいけない。
Step 3：「最小限の機能」で試作する
最初から完璧なアプリを作ろうとしない。3つの入力項目だけで動く試作版を1週間で作り、現場で試す。フィードバックを受けてから拡張する。
FlutterFlowのようなノーコードツールは、この「試作→検証→改良」のサイクルを速くするために使うものだ。最初から全機能を盛り込むためのツールではない。
—
おすすめの次アクション
要件定義の方法が分かっても、「何から始めるか」が曖昧なまま止まることは多い。
まず自社の業務フローを書き出す作業を、チームで30分やってみることをおすすめする。フローが可視化されると、「どこをアプリで解くか」が自然と絞られてくる。
現場の属人化やデータ管理に課題がある場合は、[こちらの点検管理の記事](/medical-device-maintenance-depersonalization/)も参考にしてほしい。
現場アプリの設計や業務フローの整理に使えるテンプレートは、このブログの関連記事でも紹介している。
—
よくある質問
FlutterFlowで医療機器業界の現場アプリは作れるか
FlutterFlowはFlutterベースのノーコードツールで、モバイル・Web両対応のアプリを作れる。現場の点検記録、設備台帳、報告書入力といった用途には技術的に対応できる。
ただし、医療機器製造業でのシステム導入にあたっては、QMSとの整合性、記録の真正性・可読性・保管要件など、適用される規制やガイドラインに照らした確認が別途必要になる。ツールの機能ではなく、運用設計と管理体制が問われる部分だ。最終的な判断は、自社の品質責任者や薬事担当者に委ねることを前提に進めてほしい。
要件定義にどれくらい時間をかけるべきか
規模にもよるが、現場1〜2人と管理者1人で行う小規模な内製アプリであれば、2〜3回の打ち合わせ（計3〜5時間）で十分なことが多い。重要なのは時間の長さではなく、「誰が・何を・いつ使うか」と「現状フローの可視化」が揃っているかどうかだ。
現場担当者がアプリの使い方を覚えられるか心配
操作が直感的でないアプリを「慣れてもらう」のは難しい。それよりも、現場の人間が「説明なしで使える」設計にすることを目指す方がいい。試作段階で現場担当者に実際に触ってもらい、「ここが分からない」という箇所をつぶしてから本番に移ることが定着への近道だ。
外注と内製、どちらが現場アプリに向いているか
繰り返し改善が必要な業務アプリは内製の方が向いている。仕様変更のたびに外注費用が発生すると、改善の速度が落ちる。一方、セキュリティ要件が高い、外部システムとの連携が複雑、という場合は専門家の関与が必要になる。「まず内製で試作→課題が明確になったら外注または継続内製」という順番が現実的だ。
—
ツール紹介
FlutterFlow——ノーコードで現場アプリを試作する
FlutterFlowは、プログラミングなしでiOS・Android・Web対応のアプリを作れるノーコードツールだ。ドラッグ&ドロップで画面を組み立て、データベース接続やカメラ入力も設定できる。
試作フェーズで「このアプリが現場に合うかどうか」を短期間で検証するのに向いている。開発環境の構築が不要で、社内のDX担当者やITリテラシーのある管理者が自力で動かせるレベルの学習コストで始められる。まず要件定義を固めてから使い始めることで、設計のやり直しを最小限にできる。
Notion——要件定義と業務フローの整理に使えるドキュメントツール
要件定義の内容をチームで共有・管理するツールとして、Notionは使いやすい選択肢の一つだ。「誰が・何を・いつ使うか」「現状フロー」「改善案」を一か所に書いてチームで編集できる。
ExcelやWordと違い、ページのリンクや埋め込みができるため、関連する点検記録様式や業務手順書と紐づけて管理しやすい。アプリ開発に入る前の「整理の場所」として使い、開発が進んでも引き続き仕様のドキュメントとして活用できる。
コメント