業務改善の進め方：現状把握→設計→試作→定着の4ステップ｜ノーコードで進める業務改善 第4回

ステップ1：現状把握 — 今の流れ・困りごと・数字を見える化する

最初のステップは、今の業務がどうなっているかを、関係者全員が同じ絵で見られるようにすることです。次の3つを書き出します。

1. 今の流れ（業務フロー）
誰が、何をきっかけに、何をして、次の誰に渡すのかを、順番に書き出します。付せんに1つの作業を1枚ずつ書いて、壁やホワイトボードに並べるのが手軽です。このとき、例外の流れ（差し戻し、急ぎの対応、担当者の不在時など）も忘れずに書きます。例外こそ、現場の手間が隠れている場所だからです。

2. 困りごと
それぞれの作業で、何に困っているかを、実際にその作業をしている人に聞きます。「探すのに時間がかかる」「誰が対応中か分からない」「同じことを何度も入力している」「上長の承認待ちで止まる」など、具体的な言葉で集めます。

3. 数字
可能な範囲で、件数や時間を測ります。「月に何件あるか」「1件にどれくらい時間がかかるか」「承認まで何日かかっているか」などです。数字があると、改善の前後を比べられ、効果を説明しやすくなります。

細かく測る時間がない場合は、1週間だけ、担当者に作業のたびに「正の字」をつけてもらう、かかった時間をざっくりメモしてもらう、といった簡単な方法でもかまいません。完璧な数字より、改善の前と後を同じ方法で測れることの方が大切です。

よくある誤解：「現状把握は担当者1人で十分」

業務をいちばんよく知っている担当者に聞けば、現状は分かると考えがちです。しかし、1人の視点だけでは、その人が関わらない前後の作業や、他の人の困りごとが抜け落ちます。たとえば、申請する側は「申請が面倒」と感じ、承認する側は「申請の内容が分かりにくい」と感じているかもしれません。流れに関わる人それぞれから、少しずつでも話を聞きましょう。

現場を巻き込むコツ：推進役と「使う人の代表」を決める

業務改善を進めるときは、最初に2つの役割を決めておくとスムーズです。1つは、全体を進める推進役です。関係者の予定を調整し、決めるべきことを期限までに決めていく人です。もう1つは、使う人の代表です。実際にその業務を毎日行っている人に、現状把握から試作の評価まで、継続して関わってもらいます。

使う人の代表が最初から関わっていると、「現場のことを分かっていない人が作った仕組み」と受け取られにくくなり、定着の段階で大きな力になります。代表の人の時間は、上長に相談して、業務の一部として確保してもらいましょう。

ステップ2：設計 — あるべき姿と、項目を決める

現状が見えたら、改善後の「あるべき姿」を描きます。図2のように、今の流れとあるべき姿を並べて書くと、何が変わるのかがはっきりします。

設計で決めることは、次の4つです。

1. あるべき流れ：誰が、何をして、何が自動になるのか。第3回の「なくす→まとめる→自動化する」の順で考えます。
2. 項目：第2回の項目表を作ります。「誰が何の判断に使うか」が説明できない項目は外します。
3. 見る人と権限：誰が入力し、誰が見られ、誰が直せるのか。
4. 成功の目安：改善によって、何がどう変わればよいか。ステップ1で測った数字と比べられる形で決めます（例：返却の催促の手間を月5時間から1時間に）。

設計で大切なのは、最初から完璧を目指さないことです。めったに起きない例外まですべて仕組みに入れようとすると、設計が複雑になり、いつまでも作り始められません。「よくある流れの8割を仕組みで回し、まれな例外は人が対応する」くらいの割り切りが、最初の設計には向いています。

権限の決め方：「見る」「入力する」「直す」「消す」を分ける

設計の4つめの「見る人と権限」は、後回しにされがちですが、あとから変えると利用者が混乱するため、最初に決めておきます。権限は、次の4つに分けて考えると整理しやすくなります。

• 見る：記録を見られる人。部署全体か、関係者だけか
• 入力する：新しい記録を作れる人
• 直す：既存の記録を変更できる人。自分が作った記録だけか、全員分か
• 消す：記録を削除できる人。原則として管理者だけに絞る

特に「消す」権限を広く与えると、誤操作で大切な記録が消えてしまうおそれがあります。多くのノーコードの道具では、項目やアプリごとに細かく権限を設定できます。

ステップ3：試作 — 小さく作って、使ってもらって、直す

設計ができたら、ノーコードの道具で試作します。ここがノーコードの強みが最も生きるステップです。図3のように、作る→使ってもらう→意見を聞く→直すを、短い間隔で繰り返します。

試作を進めるときのポイントは次のとおりです。

• 最初の版は数日で作る：見た目や細かい機能は後回しにして、まず流れが一通り動くものを作ります。
• 実際に使う人に、実際のデータで使ってもらう：会議室で画面を見せるだけでは、本当の使い勝手は分かりません。少人数でよいので、実際の業務で1〜2週間使ってもらいます。
• 意見は「何に困ったか」で聞く：「良かったですか」と聞くと、多くの人は「良かった」と答えます。「どこで手が止まりましたか」「前のやり方の方が楽だったところはありますか」と聞くと、改善点が見えてきます。
• 直すのは1回に少しずつ：一度にたくさん変えると、利用者が混乱します。変えた点は、短く知らせます。

試作の期間中は、旧来のやり方（紙やExcel）と並行して使うことが多くなります。ただし、並行期間は期限を決めておくことが大切です。期限がないと、二重管理がいつまでも続いてしまいます。

ステップ4：定着 — 使い続けてもらう仕組みをつくる

試作で手応えが得られたら、本番運用に移り、現場に定着させます。ノーコードの業務改善は、作ったときではなく、使われ続けて初めて成功です。定着のために、図4の項目を確認します。

1. 旧来のやり方を止める日を決める
最も大切なのがこれです。紙の台帳やExcelのファイルが残っていると、人は慣れたやり方に戻ってしまいます。「○月○日からは、新しい仕組みだけで受け付けます」と決めて、関係者に知らせます。古いファイルは、読み取り専用にして保管するなど、新しく書き込めない形にします。

2. 使い方の短い手引きを作る
画面の写真を数枚つけた、1〜2ページ程度の手引きで十分です。長いマニュアルは読まれません。

3. 困ったときの問い合わせ先を決める
「分からないことは誰に聞けばよいか」が決まっていないと、使わない理由になってしまいます。

4. 管理者を2人にする
作った人1人だけが分かる状態だと、その人が異動したときに仕組みが止まります。第5回で詳しく扱います。

5. 振り返りの日を決める
1か月後、3か月後に、成功の目安と比べて振り返ります。効果が出ていれば関係者に共有し、出ていなければ原因を探して直します。

「前のやり方の方がよかった」と言われたら

新しい仕組みに切り替えると、「前の方が楽だった」という声が出ることがあります。これは自然な反応で、慣れたやり方を変えること自体に負担があるからです。こうした声は、頭ごなしに否定せず、具体的にどこが楽だったのかを聞いてみてください。入力の項目が多い、画面の切り替えが多い、といった具体的な理由が分かれば、直せることも多くあります。一方で、慣れの問題であれば、手引きを見直したり、使い方の短い説明の場を設けたりして、慣れるまでの期間を支えます。

この記事の監修者に相談できます

監修者の田中磨生が代表を務める株式会社Abinで、ご相談をお受けしています。

相談無料ツギノテ編集部に相談する→

進め方の失敗パターンと、その防ぎ方

最後に、ノーコードの業務改善でよくある失敗のパターンを、図5にまとめました。

図5の4つのパターンは、規模の大小や業種を問わず、多くの職場で繰り返し起きています。どの失敗も、4つのステップのどこかを飛ばしたことが原因になっています。「作った人しか使わない」のは試作で利用者を巻き込まなかったから、「項目が多すぎる」のは設計で項目を絞らなかったから、「二重管理が続く」のは定着で旧来のやり方を止めなかったから、です。逆に言えば、4つのステップを丁寧に進めれば、多くの失敗は防げます。

実務ではこう使う：最初の題材の進行表

最初の題材を、6週間で進める場合の進行表の例です。

進行表は、関係者全員が見られる場所に貼り出し、週に一度、15分程度の短い打ち合わせで進み具合を確認すると、遅れに早く気づけます。他社がどのように進めたかは、ノーコード開発の成功事例が参考になります。社内でこうした進め方ができる人を育てたい場合は、DX研修おすすめ比較も比べてみてください。

この回のまとめ

• いきなり作り始めるのが最大の失敗の原因。現状把握→設計→試作→定着の4ステップで進める
• 現状把握では、今の流れ（例外も）・困りごと・数字を、流れに関わる人それぞれから集める
• 設計では、あるべき流れ・項目・権限・成功の目安を決める。最初から完璧を目指さない
• 試作は「作る→使ってもらう→意見を聞く→直す」を短く回す。並行期間には期限を決める
• 定着では、旧来のやり方を止める日を決め、手引き・問い合わせ先・管理者2人・振り返りを用意する

確認テスト

次回予告

第5回は「野良アプリと属人化を防ぐ」です。ノーコードで作る仕組みが社内に増えてくると、作った人しか分からないアプリや、誰も管理していないアプリが生まれます。そうした問題を防ぐ、ガバナンスの基本ルールと推進体制を学びます。

参考資料

• ツギノテ「中小企業のDXの進め方 第2回 現状の見える化」（2026年11月時点の公開内容）
• ツギノテ「ノーコード開発の成功事例」（2026年11月時点の公開内容）