- 困りごとはいくつか抽出したが、課題を全て洗い出しできているか不安
- 課題を業務を知らないシステム部署に、うまく伝えることができるか心配
- 課題の洗い出しはしたが、粒度がバラバラで課題の優先度がつけられない
漠然と今の業務の困りごとだけをあげ連ねると、せっかく時間をかけて作成した資料が無駄になってしまうかもしれません。
私は、店舗数800店舗を越える小売企業のシステム刷新プロジェクトに、物流部門の業務メンバーとして5年間参加しています。プロジェクトを進める中で行った業務改善の経験を踏まえ、『課題』が伝わる資料作成の方法をご紹介します。
この記事でご紹介するのは、『課題の解像度を上げて本質的な課題抽出をする方法』と『業務を知らない第三者へ情報を正しく共有できる資料作成』方法です。
読者は、本当に伝えるべき情報を抽出でき、第三者にわかりやすく伝えらえるようになります。
課題は、過去・現在・未来とあるべき姿とのギャップを確認し、決められた項目で深掘りをすることで洗い出しができます。同じ粒度で書かれた課題は、課題解決によって得られる効果も見やすくなるため、解決をすべき優先度が明確です。
3つの視点から見る課題抽出
《過去・現在・未来のギャップを捉える》

課題の抽出をどこから始めればいいかわからない時には、過去・現在・未来と現状の業務とのギャップを探してみてください。
『今はこうなっている』『こうなっていればもっとやりやすい』『今後はこうしたい』が課題抽出の第一歩です。
過去と現行業務の不一致
過去の前提条件・やり方を把握する
◆ 過去に導入されたシステムやフローの目的・背景を明確にします。
例えば・・・
・導入当時は商品数が少なく、入力項目も限られていた。
・法規制や社内ルールが現在とは違っていた。
現在の業務・システム運用と比較する
◆ 実際の現場での運用が、過去の設計や仕様と合っていない部分を洗い出します。
例えば・・・
・本来システムが対応すべき処理を手作業で行っている
・システム仕様と現行フローがズレているため、現場が独自の帳票を作っている
◆ 変化した要素を特定する。
例えば・・・
・商品バリエーションが増えて入力項目が膨大になった
・組織変更や業務フローの変更により、当初想定外の使い方をしている
課題抽出のポイント
- 運用負担がどこで増えているか
- データ入力を二重・三重
- データ入力を二重・三重
- 品質やリスクに影響が出ていないか
- 手動処理の増加でミスが多発、顧客への回答が遅れるなど。
- 手動処理の増加でミスが多発、顧客への回答が遅れるなど。
- 過去のシステム仕様やルールが現行と乖離している原因
- 誰が、いつ、どのような目的で変更したのか履歴を追う。
現行業務で効率化を図りたい
現状フロー・システムの整理
◆ 業務フローを可視化し、どこに時間や手間がかかっているかを明らかにする。
例えば・・・
画面遷移の多さ、承認フローの煩雑さ、属人的な知識に頼っている部分
外部の事例や既存ツールとの比較
◆ 他社事例や市販ソリューション(RPA、AI-OCR、クラウドサービスなど)の機能を比較し、現在とのギャップを探します。
例えば・・・
発注作業で在庫確認画面と発注画面を統合するソリューションがあるが、社内はバラバラで手動切り替えが必要
課題抽出のポイント
- 重複作業や無駄な工程がどこにあるか
・他の画面で見られる情報をいちいちダウンロードして再入力している - 追加コストやリスクが生じているか
・人在庫で処理している部分が多いため、ミスが起こりやすい・工数がかかる - 既存システムの制限を超える必要があるか
・システム改修なしでは効率化が難しい部分の特定
会社の将来に向けた方針を実現
将来の方針・理想像を明確にする
◆ 企業の中長期計画や経営方針、DX戦略などを把握し、どのような業務形態を目指しているのかを具体化します。
例えば・・・
・将来的にはオンライン受注をメインにして、リアルタイム在庫管理を実現する
・国内だけでなく海外展開を見据え、多言語対応や時差対応のオペレーションにしていく
目標を実現するために必要な業務フロー・システムの要件を仮定する
◆ 未来の業務を支えるシステムや仕組みとして、どんな機能・連携・データ管理が必須かを洗い出します。
例えば・・・
・リアルタイム在庫と連動した自動発注・自動請求
・顧客接点をオンライン化し、社内基幹システムと統合する
課題抽出のポイント
- 将来フローと現行フローの差分を具体的に示す
・どの工程をなくす(または統合する)のか、どのタイミングで自動化するのか - 必要なシステム改修や新規投資
- インフラ面:サーバーやクラウド移行、セキュリティ要件
- アプリケーション面:新機能追加、外部サービス連携
- 人材や組織面:新ツール導入に伴う教育や体制づくり
- 導入・移行のステップを検討し、期限やロードマップを仮定する
- 「いつまでに」「どの部分を」「どう変えるか」
- 「いつまでに」「どの部分を」「どう変えるか」
業務課題の解像度を上げる
《根本原因、優先度が明確で、課題のモニタリングができる状態》

企業の中で業務観点の課題抽出が必要になるシーンには以下のようなものがあります。
- システムリプレイス(更新)や新規導入の検討時
《開発再度に齟齬なく要望を伝えたい》 - 新規事業やサービスの立ち上げ時
《PDCAサイクルを短期間で回していきたい》 - 業務改革や効率化プロジェクトの立ち上げ時
《課題をプロジェクト内で共有したい》 - 法令や規制対応の必要性が生じた時
《あるべき姿とのギャップを抽出したい》 - 組織再編や部門の統合・分割時
《業務の整流化が必要なポイントを知りたい》
いずれのシーンにおいてもありがちなのは、課題はわかっているものの課題の解像度が低いことにより解決方法が抽象的になりやすいという点です。
過去、現在、未来とのギャップの根本原因、解決の優先度を明確にし、継続的にモニタリングできる状態を構築していきます。
表面的・断片的な認識にとどまっている
根本的な原因を理解せず、前後の業務を理解しないまま認識するのでは、全体最適にはなりません。また、関連部署の課題認識に齟齬がないことにより初めて課題化することが可能です。
◆ 実際には複数の根本原因があるのに、表面的な問題しか認識していない
例えば・・・
「システムが使いにくい」という声はあるが、なぜ使いにくいのか(データ入力項目の多さ、操作ルールの不透明さなど)まで踏み込んでいない。
◆ 業務フローの一部だけ見ているため、前後工程や他部署との連携に潜む課題が見えていない
例えば・・・
自部署が担当する工程だけにフォーカスし、他部署とのやり取りで生じている情報ロスや手戻りには気づけていない。
◆ 課題の存在を一部の人は把握しているが、関係する部署・担当者全体には伝わっていない
例えば・・・
現場担当者は困っているのに、管理職やシステム部門はその課題を詳しく聞いたことがない。
課題の定義や優先度付けがあいまい
業務課題を解決する際には、システム開発などが伴うことが多いです。システム開発となると当然コストがかかりますが、費用対効果が可視化できてないことを実現することは、コストの浪費につながります。
◆ 課題が「やりたいこと」や「希望要望」だけで終わっており、具体的な影響やリスクが整理されていない
例えば・・・
「この機能を追加してほしい」という要望はあるが、実現しないと何が起こるのか(ビジネス的影響、コストやリスク)は曖昧。
◆ 緊急度・重要度・発生頻度などの観点から課題を客観的に評価していない
例えば・・・
小さな不満と大きなリスクが同列に扱われ、どれから手を着けるべきか決められない。
◆ 社内合意形成や調整がされておらず、どこまでが重要課題か不透明
例えば・・・
「とにかく直してほしい」「とりあえずやっておいて」といった曖昧な依頼が多く、どの問題が最優先か判断できない。
課題検証やモニタリングの仕組みがない
運用変更による改善、システム導入による改善、課題解決の方法はいくつかありますが、効果的な課題可決につながっているか検証ができないと継続的な業務効率化は望めません。
◆ KPIやKGIなどの測定指標がなく、課題が解消されたかどうか把握できていない
例えば・・・
新しいシステムを導入しても、「なんとなく便利になった」「まだ不便があるらしい」など主観的な声だけで判断している。
◆ 定期的な見直しや振り返り(PDCAサイクル)が機能していない
例えば・・・
導入後や改善後のレビュー会が形だけになっており、具体的なデータや事実に基づく評価が行われていない。
業務課題のまとめ方
《社内外の誰もが読んで理解ができる文章にする》

業務課題は、リスト形式である程度決まった項目に合わせて記述をすることをおすすめします。
理由としては、課題解決の優先度を確認する際に情報項目が揃っていることで、比較をしやすいためです。
業務内容を認識し課題を理解しやすくするためには、業務フローと合わせてみていくことがより効果的です。
課題抽出をするためにも業務フローの作成をしてみてください。
フォーマットのご紹介
《目的を明確にした記述で、誰にでも伝わりやすい記述にする》
以下のような9項目で記述をしていきます。
誰が、どこで、どんな風に行なっている業務で、その中の何が、誰にとって、どれくらいの問題になっているのかを書き出します。
※項目は必要に応じて増減させてください。
確認観点 | 観点の目的と書き方 |
---|---|
業務カテゴリー | 【目的】 カテゴライズは、雑多な情報を共通の性質などでまとめることで、整理が行いやすい状態とする。 【書き方】 業務フロー図と合わせて見比べも行うことから「プロセス・フロー別」に まとめます。 |
どんな業務なのか? | 【目的】行っている業務の範囲を把握する。 【書き方】何をする業務なのか?システムを使うのか?どのような手順なのか? |
業務の目的は? | 【目的】この業務で何を求められているのかを把握する。 【書き方】何ができていることで、業務は完了といえるのか?業務が完了しているとはどんな状態なのか? |
業務を行う人は? | 【目的】誰にとっての課題解決になるべきかを理解する。 【書き方】個人名ではなく、部・課の名前で記載します。 |
業務が行われるタイミングは? 頻度は? | 【目的】他部署や他工程との連携を把握、業務ボリュームの認識する。 【書き方】タイミング:毎週月曜日、毎月1日 etc…頻度:100件/週 4回/月 etc… |
前後の業務はある? (あるなら誰が何をしているかも表現) | 【目的】課題解決が限定的なものなのか?横断的な解決が必要になるか?の判断材料。 【書き方】誰がどんなアクションをすることで、自分たちの業務につながるのか?自分たちの業務の後に誰かが何かを行うのか? |
この業務での課題は? | 【目的】あるべき姿とのギャップの認識する。 【書き方】何が問題なのか?本来どうあるべきなのか?いつどのようにして起きる問題か?原因は何か? |
その課題は業務にどんな影響を与えているのか? | 【目的】影響範囲の把握する。 【書き方】誰の何の作業に弊害がでているのか?実害としてどんなケースがあるか? |
影響を数値化 (人時、費用などで課題の重要度を表現) | 【目的】影響の見える化する。 【書き方】業務そのものの数値ではなく、課題の影響でロスをしている数値を記載します。 |
どんな目的で項目を書くのか?どのような書き方が業務を知らない人でも理解できるのか?を意識しながら記述していくことが重要です。
フォーマットを使った実例
「商品マスター登録」という業務の課題を記述していきます。今回はサンプルですので縦に項目を並べますが、実際に作る時はExcelなどで、項目を横並びにしリスト形式で作成をします。
確認観点 | 観点の目的と書き方 |
---|---|
業務カテゴリー | 商品マスター登録 |
どんな業務なのか? | ・新商品や既存商品の情報(商品名・型番・価格・在庫単位など)をマスタDBへ登録・更新する業務。- 基幹システムのマスタ管理の機能を使用する。 ・手順は以下 1. 販売部門より商品情報を受領 2. マスタ管理画面で必要項目を入力 3. 登録内容を他部署と確認(承認フロー) 4. マスタDBへ反映完了 |
業務の目的は? | ・マスタDBに商品の基本情報が正しく登録され、下流工程(受注・在庫管理など)で利用可能な状態にすること。 ・販売・物流・経理など、関連部門が商品データを問題なく参照できること。 |
業務を行う人は? | 生産管理部(マスター登録担当) 販売部門(情報提供・チェック) 経理部門(原価・税区分の確認) |
業務が行われる タイミング・頻度は? | ・タイミング 新製品立ち上げ時、商品仕様変更時、価格改定時 ・頻度 月に10〜15件の新規登録発生 / 価格改定は年数回 |
前後の業務はある? (あるなら誰が何をしているかも表現) | ・前工程 販売部門が商品情報(仕様・価格など)を整備 / 経理部門が原価や税区分を確定 ・後工程 物流部門が在庫管理システムで在庫設定 / ECサイト担当がオンラインストアに商品情報を連携 |
この業務での課題は? | ・入力項目が多く、手入力ミスが頻発 。 ・部門間の承認フローが非効率で時間がかかる。 迅速かつ正確にマスタが更新される体制 / 入力・承認がスムーズで業務遅延を招かないことが必要。 ・新商品が集中するシーズン(春・秋)に登録担当が対応しきれずエラーが増化する傾向にある。 ・原因は、入力画面に必須項目が多すぎることとメールベースの属人的承認フローであること。 |
その課題は業務にどんな影響を与えているのか? | ・販売部門の販売開始が遅れる- 経理の原価計算のタイミングがずれる ・登録ミスにより一部商品が注文不可で機会損失 / 在庫や価格情報の誤りで顧客クレーム |
影響を数値化 (人時、費用などで課題の重要度を表現) | ・手動入力ミス修正 1件あたり平均30分〜1時間かかる / 月間20件で10〜20時間のロス ・販売機会損失 新商品公開遅延により毎月何十万円の売上減(推定) |
業務部署のメンバーが知っていることを、誰もがわかる状態にし、横並びで「影響範囲」「優先度」「数値化」を比較することができて初めて価値が生まれます。
まとめ
課題の洗い出しでよくある失敗は、業務の説明を怠り抽象的な表現をすることで、重要性やあるべき姿が正しく理解されておらず、整理整頓が進まないことです。あるいは間違った伝わり方をしてしまうことです。
整理整頓が進まない、正しく伝わらない理由は、課題の解像度が低く内容を具体化できないため当事者以外理解ができないためです。
例えば・・・
課題の洗い出しが、商品のマスタ情報を管理するシステム開発を目的としている場合、システム開発者は業務の担当者がどういった手順で、作業をするのか把握する必要があります。
システム開発者が正しく業務を理解し具体的な問題点を把握することで、はじめてどんな機能、データ処理方法、もしくは画面設計が必要かなどを検討し、業務部署へ提案ができます。
課題の洗い出しで重要なのは2点
- 資料を読むことで、業務を具体的にイメージすることができる
- 同じ粒度で課題をリストアップすることで、「範囲」「優先度」「数値的な影響」をと比較検討できる状態にある
業務を言語化することは、日頃から業務を行っているメンバーであっても難しいものです。
改めて考えることで本質的な課題を見つけられることも多々あります。
地道で、手間のかかる作業ではありますが、今回ご紹介した方法で、成果につながる課題の洗い出しをしてみてください。
コメント