--- type: guideline title: Step.4 業務の現状把握 source: デジタル庁 ds_code: ds-120 category: government-system updated: 2025-06-19 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/9ab95eed/20250619_resources_standard_guidelines_guideline_06.zip --- # Step.4 業務の現状把握 利用者のニーズ把握と並んで重要なことは、実際に発生している様々な事象をしっかり観察し把握することです。現状を正しく把握せずにサービス・業務企画を行うと、見た目としては新しいサービスが実現できたように見えても、実際にはサービスが使われなかったり、業務上大きな問題が発生したりするなど、様々なトラブルが発生する危険性をはらんでいます。 このStepでは、現状のサービス内容や業務内容を調査するに当たり、どのようなことに注意しながら、どのような調査をすべきかについて解説していきます。 ## 業務を観察する 【標準ガイドライン関連箇所：第３編第４章第２節】 業務を観察するということは、誰にでもできそうな簡単なことにも思えますが、観察者の経験によって見えてくるものは全く異なります。一般の人が工場見学に行った際に見える風景と、工場の生産性改善を専門とする人に見える風景は、全く異なるものでしょう。ですが、業務を観察する経験が少ない人であっても、これから説明するポイントを押さえれば十分に基本的な現状把握を行うことができます。 まず、一番に注意してほしいことは、先入観を持たずに観察するということです。 例えば、申請した案件に対する審査期間が長いという問題を調べることを想定してみましょう。この時、「審査職員の能力が重要」という先入観を持っていると、経験年数の異なる審査職員を比較して、審査の着眼点や審査方法に違いがないかという分析をしたくなります。しかし、先入観を持たずに実際に発生していることをよく観察していると、単純に審査に入るまでの待ち時間が長かったり、やっと審査に入っても、基本的な書類の不備が見つかって差戻しになったりといった、本質的な審査に関係のない部分で多くの時間を費やしていることがわかるかもしれません。 仮説を立てて検証するという手法は多くの面で有効なのですが、最初の現場観察の時点で仮説を持っていると、重要な事象を見落としてしまうことになりかねないということに注意が必要です。つまり、あれこれと頭の中で考えることは後回しにして、まずは実際に発生している事実を詳細に把握するという姿勢で臨みましょう。 ### 事実を詳細に把握する 事実を詳細に把握するということは、サービス・企画のプロセス全般を通じて根底となる重要な姿勢です。この章の以降の説明では、いろいろな視点や事例に触れながら、どのような進め方だと事実把握が十分ではなく、その場合はどのように改善すべきか、について説明します。 ただ、この先の解説を読む前に、ぜひ留意してほしいことがあります。事実把握の方法について解説すると、どうしても当たり前で一般的な事柄のように思えてしまうという点です。これから、「平均、合計ではなく、ばらつきを見る」、「推測ではなく、現場で発生している事実を見る」等、様々な考え方を説明しますが、あまりにも当然のことであるため、そんなことはわかっていると読み飛ばしたくなるかもしれません。 しかし、今までに数多くのプロジェクトでトラブルが発生したり失敗に終わってしまったりした原因を辿ると、最初の企画時点で事実を詳細に把握できていなかったことに帰結する例が本当に多いのです。 細かな粒度で１つ１つの事実を徹底的に把握していくと、今までに気づいていなかった物が見えてきます。実際に発生している事実に基づいて問題が可視化されれば、その問題に対して因果関係の整理を行った上で具体的な改善策を打つことができます。逆に本当の問題が可視化されなければ、思い込みや仮説に基づいてサービス・業務を設計することになり、その問題を解決することはできません。 - 図4-3 事実を詳細に把握する ![](../assets/ds-120-ch04-image5.png) また、特にプロジェクトの業務分野の経験が長い方にとっては、自分自身が現場のことも含めてよく知っているため、あえて事実関係を調査するまでもなく、問題点や背景事象を説明できるかもしれません。ですが、そういった「プロ」の人ほど、いろいろな事象に対して頭の中で説明をつけてしまうので、かえって事実を見過ごしてしまうこともあります。現場を観察し、業務で発生する実データを確認しながら、何が起きているかを先入観なく調べてみましょう。 ### 推測ではなく、現場で発生している事実をみる 政府のプロジェクトは、ボトムアップよりもトップダウンで立ち上がることが多いかもしれません。トップダウンで立ち上がるプロジェクトは、本省等の数名の職員がチームとなって企画内容をまとめあげるというような体制が典型的で、成果を達成する期限、そのための計画を作成する期限等が切られて、検討を短期間で完了させることも求められます。 このように少ない体制で多忙な中では、つい現場に足を運ぶことを省略しがちです。サービス・業務の概要は、既存のドキュメント（利用者向けの説明文書、内部の業務フローや業務手順書等）を読めば理解できるので、それらのドキュメントを穴が開くほど眺めながら、この業務に重複がある、この部分で利用者を待たせてしまっていると、問題点を指摘することができます。でも、このような進め方では、現場で本当に起こっている問題は見えませんね。 これはひどい例でしたが、実際にはもう少し丁寧なやり方になることも多いでしょう。現場にアンケート調査をかける形です。サービス・業務の流れや現状の問題点等について、書面でのアンケート調査を行い、その結果を整理します。そうすると、検討プロセスも外部に説明しやすく、現場の声を反映した企画案のように見えます。しかし、これでも本当に十分でしょうか。アンケートの取り方の巧拙にも大きく左右されますが、現場の声を聞いたという証拠作りのためだけのアンケートでは、本当の問題を浮かび上がらせることは難しいかもしれません。 まずは、とにかく現場に行ってみましょう。現場に行かずして、サービス・業務企画は成立しえません。数多くの異なる現場に足を運び、現場を見た上で、業務実施方法や処理時間を調べてください。現場に行かず、「このような業務が行われているはず」と推測した結果に基づいて情報システムを作ると、現場では使えないものになりかねません。 また、現場に行くだけでなくドキュメントを集めることも非常に有用です。業務マニュアル１つをとっても、組織全体で整備した標準的な業務マニュアルだけでなく、各拠点で独自の業務マニュアルを作成していることがよくあります。各拠点の業務マニュアルを入手し並べて比較してみると、標準的な業務マニュアルでは十分でなかった部分を補完したり、地域の実情に合わせた追加的な対応を行っていたり、様々に工夫していることがうかがえます。これらの工夫点は、今後のサービス・業務を企画するための貴重なインプットとなります。業務マニュアルだけでなく、前任者が後任者に引き継いだ際のドキュメントも有用です。このような様々な現物のドキュメントを集めることで、生々しい業務の実態を捉えやすくなります。 サービス・業務企画の段階で現場に調査に行くことは労力のかかることですが、プロジェクトがうまく行かなくなってから立て直すにはもっと労力がかかってしまいます。現場調査には、十分な期間を確保する価値があると考えて良いでしょう。 - 事例4-2 現場の業務と合わないサービスを提供し活用されなかったシステム

事例：現場の業務と合わないサービスを提供し活用されなかったシステム

あるプロジェクトでは、市町村が登録したデータを都道府県が審査して国へ送付する制度が新設されることに伴い、これらの情報を電子的にやりとりするシステムを整備することとしました。

このプロジェクトの企画段階では、一部の市町村を招へいして数回の検討会を開催しましたが、最終回の時点においても新制度での市町村等における業務の具体的な実施方法は決定しませんでした。また、新制度に関する情報をどのように分析し、活用し、公表するか、そのために収集する必要がある情報は何かといった点についても具体的な議論は行われていませんでした。

その後、システムを作ることが優先され、新制度の開始に伴いシステムの稼働が開始しましたが、結果としてこのシステムは非常に使いにくいものとなってしまいました。例えば、都道府県が審査するための帳票はＰＤＦしか出力できず、集計作業が行えませんでした。また、市町村が登録した情報は一般利用者が確認できるようになっていましたが、利用者が情報の検索を行おうとしても、必要以上に詳細な項目を羅列しているなど閲覧しづらく、利用者が検索を行う目的に資するとは考えられないものでした。このような理由から、システムを利用する自治体はかなり少数に留まり、システムの外で紙媒体や表計算ソフトを使って業務が行われることになってしまいました。

このプロジェクトは、会計検査院による検査を受けることとなりました。会計検査院の意見では、このような事態が発生した原因の１つとして、「システムの構築をするに当たり、市町村が通常の業務で使用し又は保有する情報の内容等の実態、交付申請等の手続の実施状況等を十分に把握していないこと」を挙げています。
なお、現場へのヒアリング等を行う際には、ヒアリングを受ける担当者への配慮が重要です。初対面の担当者にヒアリングするのであれば、その担当者も身構えてしまうのが自然なことでしょう。ともすれば、余計なことを口走って宿題をもらいたくない、業務が非効率になっていることへの責任を追及されたくないといった思いから、ヒアリングに非協力的になることもあるかもしれません。 まず、調査の目的がサービスや業務を改善することであり、問題の責任所在や犯人捜しをしているわけではなく、調査結果についても担当者や担当部署を特定できるような形での公表を行わないことなど、担当者が率直に回答しやすいための環境を整えましょう。 また、今回の取組みによって現場の担当者にもメリットとなることを、丁寧に説明することが重要です。例えば、業務やシステムの非効率で無駄な部分を取り除き、注力すべき本来的な業務に十分に時間を割けるようにすることを目標としているのであれば、その趣旨をしっかりと現場の担当者に伝えましょう。１回のヒアリングの場だけで調査を終えるのではなく、ヒアリングを契機として今後も継続的に意見交換を図れるように担当者間の関係性を構築できることが理想ですね。 ### １か所だけの現場分析結果を全体に拡張しない さて、先ほどは現場へ行くことの重要性を説明しました。では、とりあえず１つの現場に行けば、それで十分でしょうか？ １か所ではやはり少なすぎるのではないでしょうか。多くの場合、サービス・業務を運営している現場は１つではないでしょう。全国に拠点があるような業務であれば、数百、数千か所といった多数の拠点があることもあるでしょう。１か所の現場分析結果にその現場のみの特性が含まれていると、それを全体に展開しても、他の現場には適合しません。 とは言え、全ての拠点に訪問して調査することも現実的ではありません。まずは、全体を正しく代表する拠点を探しましょう。都市部と地方でも利用者のニーズは大きく違うでしょう。拠点ごとに扱っているサービスも違うかもしれません。それぞれの拠点が様々な特性の違いを持つ中で、細かな差異は置いておいたとしても大きな特徴を持つグループに分け、それぞれのグループから現場調査の対象拠点を選ぶことが効率的です。選ぶ拠点数は、一概には言えません。都市部で２拠点、地方で３拠点という選び方で良いケースもあるでしょうし、数十拠点を調べないといけないケースもあるでしょう。 なお、最初から調査拠点を選んでしまうのではなく、全拠点を対象に簡易なアンケート調査を実施した上で、特性の違いを考慮しながら詳細な現場調査を行うべき拠点を選択するという手法もあります。 - 事例4-3 １か所のみだった現場調査を改善

事例：１か所のみだった現場調査を改善

あるプロジェクトでは、特定条件に該当する施設利用者に対して支援金を支給する制度の開始に合わせ、各施設に必要となる事務作業を支援するシステムを整備することを計画しました。

全国に数千の施設が存在するのですが、当初の計画策定時には１施設だけに電話ヒアリングによる調査を行い、その結果に基づいて現行の業務フロー、サービス開始後の業務フロー等を作成していました。

しかし、ここでプロジェクトの進め方について見直しが入りました。本当にこのままシステム構築を進めて良いのだろうか、もっと施設の現場を調べるべきではないか、そのような観点から、計画の途中で軌道修正を行ったのです。

まず、施設の特性別、手続の種別、対象者の種別を基に、施設間の差異を洗い出しました。そして、支援金の支給対象地域における利用者層の人口や施設の規模により抽出基準を策定し、その基準に基づき、各特性を網羅するよう複数の施設を選定しました。つまり、施設ごとに様々に背景や業務実施方法が異なるため、各施設の特徴を「正しく対象として、現場調査を行うこととしました。調査方法も電話だけでなく、書面、現地調査等の様々な方法を複合的に用いました。

![](../assets/ds-120-ch04-image6.png)

調査方法の見直しにより、施設間の業務の違いを考慮した業務要件を定めることができ、早い段階で軌道修正することができました。
なお、多くの現場を調べることで、現場ごとの「ローカルルール」を把握することも重要です。ローカルルールを調べて業務を標準化することについては、「Step.5-2-D. システムを作る前に、業務を標準化する」で後述します。 ### 日常的に業務の課題を収集し、分析に利用する サービス・業務企画を実施する時に初めて現場の課題を収集しようとしても、なかなか効率的には収集できないでしょう。そもそも現場の職員は忙しいので、過去の話を聞いてもそのことを覚えていないかもしれません。課題がないかと聞かれても、過去に何かがあったような気がするけど何だったかなと、曖昧な回答になってしまいがちです。 発生した課題を最も記録しやすいタイミングは、発生した直後です。記憶が新鮮なうちに、どのような事象が発生して何が課題になったのかを記録することが習慣化されていると、後々になって業務改善や新たなサービス・業務企画を行う際にとても有用なナレッジとなります。 では、どのような情報をナレッジとして蓄積すればよいでしょうか。一般的な例を見てみましょう。 日常的な課題収集手法の例 - **現場の窓口等への問合せ、クレーム\** 組織に対する明示的な問合せ（公式の問合せ様式によるもの等）については管理しているものの、窓口に来訪した利用者からの口頭問合せや、電話での問合せについては、その場で職員が対応するだけで記録が残っていないケースが多くあります。窓口や電話についても対応記録を残すなど、組織全体でナレッジを蓄積できることが望ましいと言えます。 利用者からの問合せがあった都度、問合せ管理台帳のようなドキュメントに記録を行います。問合せ管理台帳は、表計算ソフトで作成することもできますし、問合せの種類や件数が多い場合は専用のツールやシステムを活用することもあります。 - **コールセンターやヘルプデスクへの問合せ\** 外部委託でコールセンターやヘルプデスクを開設している場合は、委託先の事業者が問合せ内容や対応履歴等を詳細に記録していることが一般的です。ただ、せっかくこれらの情報を蓄積していても、この情報を見るのが一部の職員に限られていて、サービス・業務企画時に活かされないというケースもあります。また、管理対象となる件数が多いため、適切に分類を行わないと重要な課題が埋もれてしまうことにもなりかねません。このことに注意しながら、管理方法自体も継続的に見直しを行うことが望ましいです。 - **情報システムへの要望やインシデント** 外部委託で情報システムの運用を実施している場合は、利用者からの情報システムに対する要望や、情報システム起因の課題（エラーの発生等）が、通常業務の中でも報告されやすく、情報として管理されていることが一般的です。ただし、上記と同様に管理対象となる件数が多いので、適切な分類を含めて、管理方法自体も継続的に見直すことが望ましいです。 なお、後段で説明しますが、これらの問合せ内容については根本原因が同じになる粒度まで分類を行っておくことで、サービス・業務改革のためのポイントを数多く把握できるようになります。 ## 実績データを分析する 【標準ガイドライン関連箇所：第３編第４章第２節】 業務の現状を把握する方法は、現場へ行って人の動きやドキュメント等の実物を見るだけではありません。業務の中で生まれているデータを収集し分析することで、業務の実態をつぶさに可視化することができます。 ただ、実績データを収集することには労力がかかります。そして、やみくもにデータだけを入手しても、その先の分析で困ってしまいます。業務で発生している問題に対する先入観を持つ必要はないのですが、どのようなデータを調べたいかについて基本的な方針を立て、その目的に沿ってデータを収集して分析することが必要です。この作業には、少しコツのようなものが必要です。 以下に、実際に様々なプロジェクトでデータを分析した事例に基づいて、コツとなる部分を例示します。 ### 平均、合計ではなく、ばらつきを見る このサービスを利用する人は、何人くらいでしょうか？ このような質問を受ければ、１日平均で300人ですとか、１年間の合計で７万人ですとか、平均や合計で答えるのが一般的だと思います。もちろん、平均や合計で表される数値は、全体的な規模感をざっくりとつかむために大切な数値です。しかし、サービス・業務企画で調査する内容としては、さらに踏み込みが必要かもしれません。 例えば、１日平均で300人なので、余裕を見て400人分の対応ができるようにサービス・業務を設計しようと考えることがあるかもしれません。しかし、この考え方は少し安易すぎないでしょうか。なぜなら、平均や合計という代表値の裏に隠された、利用者ごとの違い、求めるニーズの違い、時刻や曜日ごとの違いといった様々な「ばらつき」を無視してしまっているからです。 ばらつきを注意深く見ていくと、サービスの中でもよく利用されるものとほとんど利用されないものの差が大きかったり、特定の利用者が何度も繰り返してサービスを利用している傾向が見えたり、時間帯や曜日によって利用方法にピーク特性があったりと、様々な実情が見えてきます。このようなばらつきをうまく捉えることができれば、単純に平均400名の対応量を確保するというやり方ではなく、特定の利用者向けの対応を別出ししたり、特定の時期のみに体制を強化したりといった対策を打つことができるようになります。また、ピークを分散させ平準化させることも、有効な手段です。 - 図4-4 ばらつきを分析する ![](../assets/ds-120-ch04-image7.png) このことは、様々な局面で注意してほしいポイントです。手続数、書類数、問合せ件数、業務処理時間といったサービス・業務面でも、アクセス数、画面レスポンス時間、夜間バッチ処理時間、障害発生件数といったシステム面でも、そのほかにも費用面、効果面、品質面など様々な指標を扱うときに、「平均」や「合計」といった言葉は頻出します。この言葉に出会ったときは、表面的な平均値や合計値だけを鵜呑みにせず、その陰に隠れているばらつきを捉えられているかどうか確認してみてください。 ### 時間と期間を区別して滞留状況をつかむ 業務フローを可視化すると、様々な問題点が見えてきます。しかし、業務フローだけでは見えない問題があるのも、また事実です。 その１つが、業務のどこで滞留しているかを探ることです。そのためには、業務フローに紐づいた計測ポイントを設定し、業務処理の１件１件の単位で、それぞれの計測ポイントを通過した日時を確認します。 この分析を行うときには、時間（実際の業務処理に必要な時間）と期間（開始から終了までの全体の時間）を取り違えないように注意する必要があります。最初の計測ポイントから次の計測ポイントにいくまで５日間かかったとすれば、これは「期間」の考え方です。でも、その５日間の間で、実際に確認や審査等の実業務に要したのは僅か30分だったかもしれません。これが「時間」の考え方です。時間と期間を区別して捉えることで、実際の業務処理に必要な時間と、単に処理待ちで放置されていた時間を明確にすることができます。 このような分析を行うと、業務処理の中のボトルネックを可視化することができます。可視化ができれば、大きなボトルネックが発生している箇所について、その原因を確かめてみましょう。現場にヒアリングに行く際も、何も準備をせずにヒアリングへ行くと一般的な回答しか返ってきませんが、実データで特定部分にボトルネックが発生していることを示した上でその時に何が発生していたかを確認するようにすると、具体的で本質的な回答を得ることができます。 - 事例4-4 １件１件の業務処理の滞留状況を可視化（ヘビ図）

事例：１件１件の業務処理の滞留状況を可視化（ヘビ図）

ある内部的な精算業務において、精算が完了するまでの期間が長いことが積年の問題になっていました。過去にも様々な問題提起がなされ、精算期間の目標日数を定めるとともに、業務を標準化するためのマニュアル等も整備しました。

その後、精算業務の開始から終了までの「平均」期間について測定を行っていましたが、状況はあまり改善しておらず、日数を集計して平均しただけの情報では、どこに原因があるのか見当がつきませんでした。そして、このように状況が改善しない理由としては、「他の業務が忙しい中で、精算業務は後回しになってしまう」、「最後は、担当者のやる気の問題」といったように、受け止められていました。

この状況に対して、まずは実際の決裁での滞留状況を可視化してみようということで検討活動がスタートしました。この精算業務では、複数の決裁者が内容の確認を行っているので、決裁者が確認を行い次の決裁者へ送るタイミングを計測ポイントとして、精算案件の１つ１つについて精算業務の際に利用するシステムのログを調べてみました。また、表形式でログを並べても滞留状況がわかりにくいので、次のような方法で決裁者ごとの処理期間を時系列に並べて可視化しました。

![](../assets/ds-120-ch04-image8.png)

この表の中では、決裁者が当日中に処理しなかった部分を赤色に着色しています。そして、赤色部分が極端に長くなっている部分を中心に、この記録を示しながら該当する決裁者に長期間かかった理由と当時の状況についてヒアリングを行いました。そして、その結果を「滞留・差戻し理由一覧表」にまとめました。

この分析の結果、様々なことがわかりました。精算時に計算方法が誤っていたり必要な資料が整っていなかったりすると差し戻し等で時間がかかるのですが、その前提となるルール自体が複雑でわかりにくく、部署間で統一もされていないことがわかりました。また、特定の人に業務が集中し、この精算業務が後回しになる実態も見えました。

実際の問題点がわかれば、その対策を行うことが可能になります。このケースでは、精算に係るルール自体を改めて見直すとともに、必要な資料の漏れを入力時に警告するようにシステムを改修し、精算処理の進捗状況もシステム上で可視化して、業務の集中状況を把握できるようにする等、制度（ルール）面、業務面、システム面でそれぞれ対策を行うこととしました。

対策実施後も、精算完了までの期間については定期的に分析を行っています。部署によって差はありますが、全体的には期間が短くなっており、目標としていた日数にほぼ近づいている状況です。

なお、この図については、関係者の間で「ヘビ図」と名前を付けていました。処理状況を示す形が、ヘビのように様々に形を変えながら長く伸びていたためです。元々はこの精算業務の分析に始まった「ヘビ図」ですが、他のプロジェクトでも応用され、サービス・業務改革（ＢＰＲ）の１つのツールとして使われています。
上記の例は、前の決裁者の処理が終われば次の決裁者へ移るという、基本的に一方向での業務処理でした。 一方で、業務の中には、複数の関係者間で処理が何度も往復するような複雑なものもあります。このような業務について滞留状況の分析を行う際は、次に示すシーケンス図が有効です。 - 事例4-5 関係者間を往復する複雑な処理状況を可視化（シーケンス図）

事例：関係者間を往復する複雑な処理状況を可視化（シーケンス図）

ある省で利用者向けに行われているサービスにおいて、利用者の申請を受け付けてから審査結果を返すまでの期間が長い事が問題となっていました。この業務では、利用者が申請書類を提出した後、書類を受け付けた担当者が内容に応じて様々な担当者に受け渡していくものであったため、関係する数多くの担当者のどの作業でどのくらいの時間が掛かっているのかがはっきりしておらず、対策を打つことができていませんでした。

そこで、業務処理の実態を正しく把握するための手段として、シーケンス図を用いて、分析を行うことしました。シーケンス図とは、業務に係る担当者を全て登場させ、担当者自身の作業と、担当者間のやり取りを区別できるように記載したものです。

![](../assets/ds-120-ch04-image9.png)

これらのやり取りをした日時は、システムのログ等には存在しなかったため、関係者間の電子メールや関連書類の記録等を基に洗い出しを進めることにしました。手作業での洗い出しであり全件を対象とした分析は困難であったため、審査期間が長引いている案件を中心に選択的に分析を行いました。

シーケンス図の分析結果を見ると、関係者間で頻繁にやりとりする期間もある一方で、待ちが中心となる期間も存在することがわかりました。頻繁にやり取りする期間については、なぜ何度も状況確認を行う必要があったのか、その都度ごとの確認内容や質問内容を確認し、審査の途中ではなく最初から必要な情報を得ることができなかったか等について検討を行いました。また、待ちが中心になる期間についても、待ちが発生している理由等を調査しました。

このように、シーケンス図を作成することによって、何に時間がかかっているかという全体的な問題構造を可視化することができ、関係者間でその内容を共有した上で、問題分析に当たることが可能となりました。
### 業務量のピークを捉え、ピークの発生原因を把握する 業務フローだけでは見えてこないものは、ほかにもあります。それは、業務処理量です。 業務フローだけを眺めると、毎日、決まりに従ってスムーズに業務が流れていくように錯覚しがちですが、実際の業務では日々の業務量が大きく異なるので、繁忙期には処理が停滞しがちです。業務量に応じて、処理の方法まで変わることもあります。 このため、業務量の変化を捉えた上で、特にピークが発生するポイントを把握することが重要です。ピークが発生する例としては、年度末等の申請時期の区切りの直前、長期連休明けの営業日の午前中等が典型的ですが、業務の特性で様々な時期、時刻にピークが存在します。まずは、このようなピークがどこに発生しているかを把握しましょう。 業務のピークについては、サービス利用者側の要因で発生するものであり、サービス提供者側の工夫でピークを抑えることは難しいと考えてしまいがちです。しかし、まずは工夫できる余地があるかどうかを検討するためにも、ピークの時に実際に何が起きているかを調べてみましょう。どのような利用者がどのような目的でその時期に利用せざるを得ないのか、実際に発生している事象を確認すると、ピークが発生している理由を理解することができます。 ひょっとすると、とてもつまらない理由でピーク時期に余計な負荷がかかっているかもしれません。そういった一例を、参考として示します。 - 事例4-6 利用ピークの分析を活かして電子申請利用率を向上

事例：利用ピークの分析を活かして電子申請利用率を向上

あるプロジェクトでは、ある免許の定期的な更新について、書面で行う方法だけでなく、電子申請でも行えるようにサービスを提供していました。この免許は、数年に１度の頻度で更新が必要であり、更新期限の３カ月前までに手続を終えることを規則で定めていました。

実際に電子申請のサービスを始めていくと、申請期限間際にサービスの利用が集中してしまうことが明らかになりました。そこで、その集中時における利用者のサービス利用状況等を調べてみました。

すると、少し不思議なことが判明しました。正常に更新申請を行っている利用者以外に、パスワードの再発行申請やログイン自体を諦めている利用者が、比較的多い割合で存在していました。この時期の申請内容を確認したところ、以前に電子申請を使った経験のある利用者が、また書類申請に戻っているケースが一定数存在していたのです。一度、電子申請を経験すれば、次回も電子申請を使った方が効率的なはずなので、この理由は調べてみる必要があります。

色々と周辺状況を調べてみた結果、これらの利用者はパスワードを忘れている可能性が高いことがわかり、サービス利用状況の分析結果と一致しました。更新手続は数年に１度しか利用しないので、電子申請を行おうとした際にＩＤやパスワード等がわからず、パスワードの再発行を待っていると申請期限である３か月前を超えてしまうため、やむなく書面での手続を行っているということでした。

![](../assets/ds-120-ch04-image10.png)

このようなケースが多くなると、せっかく整備した電子申請の利用が進みません。様々な検討の結果、規則自体を改正し、書類申請の期限は変更しない一方で、電子申請サービスの申請期限のみを１か月前まで延長するようにしました。

これにより、書類申請期限と電子申請期限に差ができ、業務上の利用ピークが分散されるとともに、パスワード忘れによる再発行が発生したとしても、それを待って電子申請が行えるようになりました。

![](../assets/ds-120-ch04-image11.png)
既存の業務内容そのままに業務量のピークを想定とすると、業務に必要な職員体制を見直すことも難しいですし、情報システムの処理能力も大きなものが必要となってしまいます。当然ながら、情報システムのコストも上がってしまいます。 特にピーク時と平常時の業務量の差が極端に大きい場合は、ピーク自体を分散化させることを検討したいですね。そのためにも、いつピークが発生しているか、そのピークに何が起きているのか、よく調べてみると改善のヒントをつかまえることができます。 業務のピークが、利用者の行動の締切り直前の集中にある場合は、利用者を締切り以前から行動するように誘導することや、利用者を複数のグループに分けて締切り自体を分散化することを検討します。例えば、公共料金の支払いにおいても、利用者を複数のグループに分けてそれぞれ支払い期限を変えていることが一般的になっています。 なお、業務量のピークを抑えることが根本的に難しい場合においては、システム方式としてクラウドサービスを導入することも有効な選択肢になります。クラウドサービスでは、基本的にリソース（サーバ等の能力）を使用しただけ費用が発生するので、瞬間的なピークにも対応しながら全体的にはコストを抑えるといった使い方が可能になります。 ### 問合せや要望は、根本原因が同じになる粒度まで分類する サービスを提供していると、様々な問合せ、要望等が寄せられます。ヘルプデスクとして電話で問合せを受けることもあるでしょうし、窓口で利用者から直接問合せを受けることもあるでしょう。毎日10件の問合せがあったとしても、１か月で200件、１年では2,000件を超える問合せを受けることになります。 さて、サービス・業務改革を進めるためには、このような問合せの履歴は「宝の山」になります。利用者が何に困っているのか、何を望んでいるのか、そこに利用者のニーズの原石が埋まっているからです。ただ、大きな山なので、なかなか掘り起こすのが大変ですね。年間数千件、場合によっては数万件にもなる問合せの履歴の山から、どのようにして宝となる原石を掘り当てればよいのでしょうか。 そのキーポイントとなるのが、分類です。多くの場合において、サービスの種類別や工程別に分類を行っていると思います。施設予約のサービスであれば、利用者登録、施設予約、抽選、料金支払いといった分類です。また、問合せ内容の原因別という観点もあるかもしれません。施設予約システムの操作方法、システムの動作環境、システムの不具合といった分類です。 しかし、いずれの例も、かなり大括りであることに気づかれたでしょうか。「利用者登録」の「システム操作方法」に関する問合せが今月20件あったとします。先月は30件でした。確かに合計数値では減少していますが、こういった数値を見て一喜一憂することに意味があるのでしょうか。この20件という数字は、内容の全く異なる問合せをその違いを考慮せずに単純に「合計」しています。これでは、どのような事象が利用者から問題にされていて、何を対策すればよいのか、何も探ることができません。 最初に少し手間はかかるのですが、利用者からの問合せが発生した根本原因が同じ所に行きつくまで、詳細に分類することが重要です。根本原因に行きつくまで分類を行った一例を、以下の参考に示しました。 - 事例4-7 根本原因が特定できるまで詳細な分類を行う

事例：根本原因が特定できるまで詳細な分類を行う

あるプロジェクトでは、ある資格の更新等をWebサイトで行える電子申請サービスを提供しています。しかし、申請の手順や操作方法等についてヘルプデスクへの問い合わせが多く、利便性が高いサービスとは言えない状態になっていました。

これまでも、ヘルプデスクに問合せ対応履歴を登録する際には、問合せ対象となった機能、問合せの原因等である程度の分類は行っていました。しかし、実際に問合せの内容として登録されている文章を読んでみると、同じ分類とされているグループの中にも、全く異なる内容が多く含まれていることがわかりました。一方で、いくつかの内容を読んでいくと、問合せの中に頻発する「キーワード」があることがわかりました。そこで、頻発するキーワードを頼りにしながら分類の詳細化を進め、問合せの根本原因が同じ粒度になるまで分類を行っていきました。

例えば、頻発するキーワードの１つに「ポップアップ」という言葉がありました。ポップアップとは、Webブラウザで画面遷移する際に新しく小さな子画面（ウインドウ）を出すことを指しているのですが、その子画面が出るはずのところで画面が出現しない（ブロックされる）という問合せのようでした。そこで、このキーワードが含まれる問合せを洗い出した上で、詳細な原因別に分類しました。いくつかの原因があったのですが、最も多かったのがブラウザの設定等でポップアップ画面を出すことを妨げていたので、設定を変える必要があるというものでした。

このように、内容がわかってしまえば対策が簡単な問題が多いのですが、利用者にとってはこのような問題が１つでも発生すると利便性が大きく低下してしまいます。この例ではWebサイトのＦＡＱ等のわかりやすい場所にポップアップに関する注意を載せるなど、問合せ内容の分析結果に応じて各種の対応を行いました。

![](../assets/ds-120-ch04-image12.png)
同じ原因別に分類することができれば、その発生傾向を分析することができます。 例えば、参考に記載した例では、ＦＡＱにわかりやすく注意を載せる等の対策を打ちました。この対策に効果があったかどうかは、対策を打つ前後で同じ分類の問合せの件数を見るとわかります。対策を打った後でこの問合せが大幅に減ったのであれば効果があったと言えますし、対策を打った後もこの問合せの件数がほとんど減らなかったのであれば、何か別の対策を打つ必要があるということです。 このような詳細な分類を行うことは、確かに手間がかかります。ただ、全体的な分類を一度見直すことができれば、その後に発生する問合せに対しても発生の都度正しく分類しやすくなります。そして、何より利用者が感じている小さな不満から大きな苦情までを捉えることができ、同じ原因別での問合せ発生数を時系列で把握できるという点で、業務・サービス改革のために非常に有効な分析が行えます。 もし、利用者からの問合せのデータが大括りのままに眠っているとすれば、一度、職員の中で分析チームを作って分類を進めることにトライしてみてはどうでしょうか。 ## 業務を可視化する 【標準ガイドライン関連箇所：第３編第４章第２節】 業務を観察した結果、実績データを分析した結果は、様々な観点からまとめられた大量のドキュメント群となることがあります。分析を実施した当事者はこれらの内容をよく理解ができますが、これらの資料を初めて読む人にとっては、ポイントをつかむことが難しいでしょう。 業務の分析結果は、プロジェクト内部の職員（ＰＪＭＯ職員）、プロジェクト外部の利用者や関係者、システムを整備する際のシステム開発事業者等、様々な立場の人がその内容を確認する必要があります。これらの関係者に対して的確に業務の状況を伝えるためには、業務フロー等、業務を誰にとってもわかりやすく可視化した資料を作成することが重要です。 ### 様々な立場の人が理解できる業務フローを作成する - 注記 AsIsとは、「現状」の意。「将来あるべき」のToBeとセットでよく使われる。 業務フローは、現在行っている業務を「誰が（どの組織が）」「いつ」「何を」「どの順番で」実施しているか、「どの範囲が情報システム化されているか」を可視化するものです。対策の検討や企画後の業務内容の変化箇所を特定するためにも有効です。 業務フローには、現行（AsIs）と将来（ToBe）がありますが、ここで作成するのはまず現行の業務フローです。 業務フローの書き方については、様々な表記方法があります。基本的には、関係者にとってわかりやすい表記であれば、どのような表記方法でも十分です。縦に流れるフローでも、横に流れるフローでも、どちらでも構いません。 - 図4-5 業務フロー（現行）の定義例 ![](../assets/ds-120-ch04-image13.png) なお、将来（ToBe）の業務フローについては、「Step.5-2-E. 将来の業務フローには、効果を紐づける」で後述します。 業務フローの表記方法には様々な手法がありますが、次のようなことに留意すると関係者が理解しやすいものとなります。 業務フロー作成時の留意点 - **業務を実施する主体ごとに表記を分ける\** 業務を実施する主体を分けないと、誰が実施している作業なのか区別がつかなくなります。実施主体ごとに「レーン」を作成し、発生する業務をプロットします。 - **業務単位を軸に体系化する\** 業務フローは、大きくなりすぎると読みにくくなるため、一定の業務単位にサブフローとして１つのフローを作成します。業務の単位は、業務一覧の階層と合わせることで整合性がとりやすくなります。 - **システムを利用して行う業務を明確にする\** 業務フローの中には、人が手作業等で実施する業務と、システムを利用する業務が入り混じります。システムを利用する業務については、色を変えたり、枠囲みによって利用するシステムを表したりすることで、区別できるようにします。 - **帳票やデータの受け渡し内容を明確にする\** やりとりする帳票やデータ等の起点と終点を明らかにするとともに、その内容（特にインプットとアウトプット）を明確にします。なお、インプットとアウトプットに関する情報は、帳票名やデータ名に留め、詳細な項目は後述の業務記述書や業務ルールに記載し、業務フロー上で詳細になりすぎないように注意します。 - **業務の流れ方を一方向にする\** 横書きであれば左から右、縦書きであれば上から下の基本的な流れに沿って業務をプロットします。基本的な流れに沿わない業務の進み方が多くなると、理解しにくくなってしまいます。 - **中心となる業務について記載する\** 実際の業務の中では様々な例外処理が発生しますが、それらを全て記載する業務フローが複雑になりすぎて理解できなくなります。中心となる業務について記載し、例外等については後述の業務記述書や業務ルールとして別に書き出した方がわかりやすくなります。 - **業務のばらつきに留意する\** 業務フローを書くと全ての業務がこの標準的な業務フローで動いているかのように錯覚してしまうことがあります。実際には各拠点、各組織でそれぞれ工夫を行ったり独自の背景があったりするため、様々な業務のバリエーションが存在することが多くあります。確かに、これらのバリエーションを全て業務フローとして可視化するのは煩雑です。しかし、業務のばらつきが存在することについて現地調査や担当者へのヒアリングを通じて十分に把握して、それらの業務も標準化するのか、又は複数の業務実施パターンを許容した上でシステムも各業務パターンへの個別対応を行うのかについて、業務要件作成時に方針を定めることが重要です。 前述の業務フローのイメージは、一般的なＰＣのプレゼンテーション・ソフトウェア等で作成することをイメージしたものです。なお、業務フローを効率的に作成するためのツールも多種存在しているので、必要に応じてそのようなツールを整備することも検討してください。 また、業務フローの表記についての国際的な標準として、ＢＰＭＮ（Business Process Model Notation：ビジネスプロセスモデリング表記法）があります。業務フローを作成するツールの多くは、このＢＰＭＮに準拠した表記を行うことができます。 - 図4-6 ＢＰＭＮ表記で書いた業務フロー図 ![](../assets/ds-120-ch04-image14.png) ### 業務ルールや業務実施方法をまとめる 業務を可視化した文書は、関係者がサービス・業務や情報システムの目指すべき姿を共有するものであるため、誤った定義や曖昧な定義が行われると、後続の工程に重大な影響を与えます。 そのため、業務を可視化した文書を作成する際には、次に示す点を参考に、正確で一貫性のある記載となるようにしましょう。 - 曖昧な用語や一般的な意味と異なる使い方をしている用語等は、プロジェクト関係者間の認識そごを防止するため、用語の定義及び機能を定義する粒度や深さについて統一する。 - 事例4-8 業務は複数の切り口で表現すると漏れなく可視化できる サービス・業務企画内容の検討における作業のしやすさを考慮して、業務単位や区分、順番等を整理する。 - 注記 「業務可視化資料の作成について」（特許庁ＰＭＯ　平成27年５月18日）

事例：業務は複数の切り口で表現すると漏れなく可視化できる

ある省の大規模な業務システムの刷新プロジェクトにおいて、システムリリース後の業務要件を漏れなく調達仕様書で示すために、従来の業務要件定義のやり方を改め、より要件を漏れなく記述し、可視化する資料を作成する取り組みを行いました。

対象となる業務は、業務実施部門職員向けの特定業務に特化したマニュアルしか存在しておらず、網羅的かつ業務知識のない第三者でも理解できるような内容の資料とはなっていませんでした。

このため、業務を「流れ、判断、内容」の３つの視点から表現し、業務を可視化するドキュメントとして業務フロー、ディシジョンテーブル（条件分岐表）、業務説明書を作成することとしました。（下図（「業務可視化資料の作成について」（特許庁ＰＭＯ　平成27年５月18日）を参照））

![](../assets/ds-120-ch04-image15.png)

これらドキュメントを用いて、プロジェクト関係者間（業務実施部門、情報システム部門、外部事業者）の課題認識の共有や、開発工程の効率化、開発範囲に対する設計の網羅性確認に活用することができました。

さらに、各ドキュメントを組み合わせて、記述内容をチェックすることで、要件の抜け漏れを防ぐことができました。
### 入出力情報や管理対象情報をまとめる 業務を構成する要素には、業務フローに代表される「プロセス」だけでなく、「情報、データ」があります。「プロセス」が業務の動的な側面（流れ、動き）を表すのに対し、「情報、データ」は業務の静的な側面（常に成り立つ相互の関係と、ある時点での状態）を表すといった特徴があり、いずれも業務（システム）を定義するために欠かせない要素となります。 「情報、データ」の現状を把握するには、「入出力情報及び取扱量」及び「管理対象情報一覧」をまとめます。 「入出力情報」と「管理対象情報」の違いは、「入出力情報」が画面、帳票、CSV形式の一時ファイルなど、実際の業務でやり取りする単位の情報であるのに対し、「管理対象情報」はそれらの要素を管理しやすい単位に分解、集約した情報（将来のデータベースの元情報）となります。 　一般的な「管理対象情報」の抽出方法は以下のとおりになります。（）内は、別紙「要件定義書標準テンプレート」における図書貸し出しシステムの事例です。 1. **「入出力情報」の項目を同じ単位の情報に分解する\** ある入出力情報に記載されている項目を分析し、同じ単位で括れるものを抽出する。（例えば、「貸出申請書」の項目を、「書籍」「利用者」など単位が異なるものに分解する。） 2. **「入出力情報」自体も、１つの「管理対象情報」として抽出する\** 入出力情報自身も、その事象自体を管理する場合は、管理対象情報となる。（例えば、「貸出申請書」という入出力情報について、一枚ごとの「貸出申請」という事象は業務上で通常は管理するものであり、管理対象情報になる。一方で、「貸出状況照会履歴」のように、貸出状況の照会を誰がいつ実施したかという情報までを業務上管理する必要がないのであれば、管理対象情報とする必要はない。） 3. **抽出した管理対象情報のうち、親子関係があるものをさらに分解する\** 抽出した管理対象情報の中で、合計と内訳のように親子関係を持っているもので、親子別々に管理する必要があるものは、別の管理対象情報とする。（例えば、上記の「書籍」をその本の基本情報（タイトルや著者など）と、実体（本一冊ずつ）が持つ情報に分け、前者を「書籍情報」、後者を「書籍」と名づける。）例えば、貸出用に同じ本が３冊ある場合は「書籍」としては３つの実体があり、そのタイトルや著者などの「書籍情報」としては１つとなる。 - 図4-7
![](../assets/ds-120-ch04-image16.png)

管理対象情報の抽出

既にシステム化されている業務においては、データベースの情報を参考に「管理対象情報」を作成することもできますが、ここでは、あくまでも業務視点で管理すべき情報を洗い出すようにしてください。（システムの都合で作られたデータや、業務のデータであっても管理単位や属性の持ち方がシステム処理上の都合によって変更されているものは「管理対象情報」としては使わないでください。） - 様式例4-1 現状分析結果報告書のひな形

様式例：現状分析結果報告書のひな形

現状分析結果報告書のひな形を本章別紙としてまとめています。システムを新規構築時に作成し、改修・更改時に更新しましょう。

![](../assets/ds-120-ch04-image17.jpg)