Step.4 業務の現状把握

利用者のニーズ把握と並んで重要なことは、実際に発生している様々な事象をしっかり観察し把握することです。現状を正しく把握せずにサービス・業務企画を行うと、見た目としては新しいサービスが実現できたように見えても、実際にはサービスが使われなかったり、業務上大きな問題が発生したりするなど、様々なトラブルが発生する危険性をはらんでいます。

このStepでは、現状のサービス内容や業務内容を調査するに当たり、どのようなことに注意しながら、どのような調査をすべきかについて解説していきます。

業務を観察する

【標準ガイドライン関連箇所：第３編第４章第２節】

業務を観察するということは、誰にでもできそうな簡単なことにも思えますが、観察者の経験によって見えてくるものは全く異なります。一般の人が工場見学に行った際に見える風景と、工場の生産性改善を専門とする人に見える風景は、全く異なるものでしょう。ですが、業務を観察する経験が少ない人であっても、これから説明するポイントを押さえれば十分に基本的な現状把握を行うことができます。

まず、一番に注意してほしいことは、先入観を持たずに観察するということです。

例えば、申請した案件に対する審査期間が長いという問題を調べることを想定してみましょう。この時、「審査職員の能力が重要」という先入観を持っていると、経験年数の異なる審査職員を比較して、審査の着眼点や審査方法に違いがないかという分析をしたくなります。しかし、先入観を持たずに実際に発生していることをよく観察していると、単純に審査に入るまでの待ち時間が長かったり、やっと審査に入っても、基本的な書類の不備が見つかって差戻しになったりといった、本質的な審査に関係のない部分で多くの時間を費やしていることがわかるかもしれません。

仮説を立てて検証するという手法は多くの面で有効なのですが、最初の現場観察の時点で仮説を持っていると、重要な事象を見落としてしまうことになりかねないということに注意が必要です。つまり、あれこれと頭の中で考えることは後回しにして、まずは実際に発生している事実を詳細に把握するという姿勢で臨みましょう。

事実を詳細に把握する

事実を詳細に把握するということは、サービス・企画のプロセス全般を通じて根底となる重要な姿勢です。この章の以降の説明では、いろいろな視点や事例に触れながら、どのような進め方だと事実把握が十分ではなく、その場合はどのように改善すべきか、について説明します。

ただ、この先の解説を読む前に、ぜひ留意してほしいことがあります。事実把握の方法について解説すると、どうしても当たり前で一般的な事柄のように思えてしまうという点です。これから、「平均、合計ではなく、ばらつきを見る」、「推測ではなく、現場で発生している事実を見る」等、様々な考え方を説明しますが、あまりにも当然のことであるため、そんなことはわかっていると読み飛ばしたくなるかもしれません。

しかし、今までに数多くのプロジェクトでトラブルが発生したり失敗に終わってしまったりした原因を辿ると、最初の企画時点で事実を詳細に把握できていなかったことに帰結する例が本当に多いのです。

細かな粒度で１つ１つの事実を徹底的に把握していくと、今までに気づいていなかった物が見えてきます。実際に発生している事実に基づいて問題が可視化されれば、その問題に対して因果関係の整理を行った上で具体的な改善策を打つことができます。逆に本当の問題が可視化されなければ、思い込みや仮説に基づいてサービス・業務を設計することになり、その問題を解決することはできません。

図4-3

事実を詳細に把握する

また、特にプロジェクトの業務分野の経験が長い方にとっては、自分自身が現場のことも含めてよく知っているため、あえて事実関係を調査するまでもなく、問題点や背景事象を説明できるかもしれません。ですが、そういった「プロ」の人ほど、いろいろな事象に対して頭の中で説明をつけてしまうので、かえって事実を見過ごしてしまうこともあります。現場を観察し、業務で発生する実データを確認しながら、何が起きているかを先入観なく調べてみましょう。

推測ではなく、現場で発生している事実をみる

政府のプロジェクトは、ボトムアップよりもトップダウンで立ち上がることが多いかもしれません。トップダウンで立ち上がるプロジェクトは、本省等の数名の職員がチームとなって企画内容をまとめあげるというような体制が典型的で、成果を達成する期限、そのための計画を作成する期限等が切られて、検討を短期間で完了させることも求められます。

このように少ない体制で多忙な中では、つい現場に足を運ぶことを省略しがちです。サービス・業務の概要は、既存のドキュメント（利用者向けの説明文書、内部の業務フローや業務手順書等）を読めば理解できるので、それらのドキュメントを穴が開くほど眺めながら、この業務に重複がある、この部分で利用者を待たせてしまっていると、問題点を指摘することができます。でも、このような進め方では、現場で本当に起こっている問題は見えませんね。

これはひどい例でしたが、実際にはもう少し丁寧なやり方になることも多いでしょう。現場にアンケート調査をかける形です。サービス・業務の流れや現状の問題点等について、書面でのアンケート調査を行い、その結果を整理します。そうすると、検討プロセスも外部に説明しやすく、現場の声を反映した企画案のように見えます。しかし、これでも本当に十分でしょうか。アンケートの取り方の巧拙にも大きく左右されますが、現場の声を聞いたという証拠作りのためだけのアンケートでは、本当の問題を浮かび上がらせることは難しいかもしれません。

まずは、とにかく現場に行ってみましょう。現場に行かずして、サービス・業務企画は成立しえません。数多くの異なる現場に足を運び、現場を見た上で、業務実施方法や処理時間を調べてください。現場に行かず、「このような業務が行われているはず」と推測した結果に基づいて情報システムを作ると、現場では使えないものになりかねません。

また、現場に行くだけでなくドキュメントを集めることも非常に有用です。業務マニュアル１つをとっても、組織全体で整備した標準的な業務マニュアルだけでなく、各拠点で独自の業務マニュアルを作成していることがよくあります。各拠点の業務マニュアルを入手し並べて比較してみると、標準的な業務マニュアルでは十分でなかった部分を補完したり、地域の実情に合わせた追加的な対応を行っていたり、様々に工夫していることがうかがえます。これらの工夫点は、今後のサービス・業務を企画するための貴重なインプットとなります。業務マニュアルだけでなく、前任者が後任者に引き継いだ際のドキュメントも有用です。このような様々な現物のドキュメントを集めることで、生々しい業務の実態を捉えやすくなります。

サービス・業務企画の段階で現場に調査に行くことは労力のかかることですが、プロジェクトがうまく行かなくなってから立て直すにはもっと労力がかかってしまいます。現場調査には、十分な期間を確保する価値があると考えて良いでしょう。

事例4-2

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

なお、現場へのヒアリング等を行う際には、ヒアリングを受ける担当者への配慮が重要です。初対面の担当者にヒアリングするのであれば、その担当者も身構えてしまうのが自然なことでしょう。ともすれば、余計なことを口走って宿題をもらいたくない、業務が非効率になっていることへの責任を追及されたくないといった思いから、ヒアリングに非協力的になることもあるかもしれません。

まず、調査の目的がサービスや業務を改善することであり、問題の責任所在や犯人捜しをしているわけではなく、調査結果についても担当者や担当部署を特定できるような形での公表を行わないことなど、担当者が率直に回答しやすいための環境を整えましょう。

また、今回の取組みによって現場の担当者にもメリットとなることを、丁寧に説明することが重要です。例えば、業務やシステムの非効率で無駄な部分を取り除き、注力すべき本来的な業務に十分に時間を割けるようにすることを目標としているのであれば、その趣旨をしっかりと現場の担当者に伝えましょう。１回のヒアリングの場だけで調査を終えるのではなく、ヒアリングを契機として今後も継続的に意見交換を図れるように担当者間の関係性を構築できることが理想ですね。

１か所だけの現場分析結果を全体に拡張しない

さて、先ほどは現場へ行くことの重要性を説明しました。では、とりあえず１つの現場に行けば、それで十分でしょうか？

１か所ではやはり少なすぎるのではないでしょうか。多くの場合、サービス・業務を運営している現場は１つではないでしょう。全国に拠点があるような業務であれば、数百、数千か所といった多数の拠点があることもあるでしょう。１か所の現場分析結果にその現場のみの特性が含まれていると、それを全体に展開しても、他の現場には適合しません。

とは言え、全ての拠点に訪問して調査することも現実的ではありません。まずは、全体を正しく代表する拠点を探しましょう。都市部と地方でも利用者のニーズは大きく違うでしょう。拠点ごとに扱っているサービスも違うかもしれません。それぞれの拠点が様々な特性の違いを持つ中で、細かな差異は置いておいたとしても大きな特徴を持つグループに分け、それぞれのグループから現場調査の対象拠点を選ぶことが効率的です。選ぶ拠点数は、一概には言えません。都市部で２拠点、地方で３拠点という選び方で良いケースもあるでしょうし、数十拠点を調べないといけないケースもあるでしょう。

なお、最初から調査拠点を選んでしまうのではなく、全拠点を対象に簡易なアンケート調査を実施した上で、特性の違いを考慮しながら詳細な現場調査を行うべき拠点を選択するという手法もあります。

事例4-3

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

なお、多くの現場を調べることで、現場ごとの「ローカルルール」を把握することも重要です。ローカルルールを調べて業務を標準化することについては、「Step.5-2-D. システムを作る前に、業務を標準化する」で後述します。

日常的に業務の課題を収集し、分析に利用する

サービス・業務企画を実施する時に初めて現場の課題を収集しようとしても、なかなか効率的には収集できないでしょう。そもそも現場の職員は忙しいので、過去の話を聞いてもそのことを覚えていないかもしれません。課題がないかと聞かれても、過去に何かがあったような気がするけど何だったかなと、曖昧な回答になってしまいがちです。

発生した課題を最も記録しやすいタイミングは、発生した直後です。記憶が新鮮なうちに、どのような事象が発生して何が課題になったのかを記録することが習慣化されていると、後々になって業務改善や新たなサービス・業務企画を行う際にとても有用なナレッジとなります。

では、どのような情報をナレッジとして蓄積すればよいでしょうか。一般的な例を見てみましょう。

日常的な課題収集手法の例

*現場の窓口等への問合せ、クレーム* 組織に対する明示的な問合せ（公式の問合せ様式によるもの等）については管理しているものの、窓口に来訪した利用者からの口頭問合せや、電話での問合せについては、その場で職員が対応するだけで記録が残っていないケースが多くあります。窓口や電話についても対応記録を残すなど、組織全体でナレッジを蓄積できることが望ましいと言えます。利用者からの問合せがあった都度、問合せ管理台帳のようなドキュメントに記録を行います。問合せ管理台帳は、表計算ソフトで作成することもできますし、問合せの種類や件数が多い場合は専用のツールやシステムを活用することもあります。
*コールセンターやヘルプデスクへの問合せ* 外部委託でコールセンターやヘルプデスクを開設している場合は、委託先の事業者が問合せ内容や対応履歴等を詳細に記録していることが一般的です。ただ、せっかくこれらの情報を蓄積していても、この情報を見るのが一部の職員に限られていて、サービス・業務企画時に活かされないというケースもあります。また、管理対象となる件数が多いため、適切に分類を行わないと重要な課題が埋もれてしまうことにもなりかねません。このことに注意しながら、管理方法自体も継続的に見直しを行うことが望ましいです。
情報システムへの要望やインシデント 外部委託で情報システムの運用を実施している場合は、利用者からの情報システムに対する要望や、情報システム起因の課題（エラーの発生等）が、通常業務の中でも報告されやすく、情報として管理されていることが一般的です。ただし、上記と同様に管理対象となる件数が多いので、適切な分類を含めて、管理方法自体も継続的に見直すことが望ましいです。

なお、後段で説明しますが、これらの問合せ内容については根本原因が同じになる粒度まで分類を行っておくことで、サービス・業務改革のためのポイントを数多く把握できるようになります。

実績データを分析する

【標準ガイドライン関連箇所：第３編第４章第２節】

業務の現状を把握する方法は、現場へ行って人の動きやドキュメント等の実物を見るだけではありません。業務の中で生まれているデータを収集し分析することで、業務の実態をつぶさに可視化することができます。

ただ、実績データを収集することには労力がかかります。そして、やみくもにデータだけを入手しても、その先の分析で困ってしまいます。業務で発生している問題に対する先入観を持つ必要はないのですが、どのようなデータを調べたいかについて基本的な方針を立て、その目的に沿ってデータを収集して分析することが必要です。この作業には、少しコツのようなものが必要です。

以下に、実際に様々なプロジェクトでデータを分析した事例に基づいて、コツとなる部分を例示します。

平均、合計ではなく、ばらつきを見る

このサービスを利用する人は、何人くらいでしょうか？

このような質問を受ければ、１日平均で300人ですとか、１年間の合計で７万人ですとか、平均や合計で答えるのが一般的だと思います。もちろん、平均や合計で表される数値は、全体的な規模感をざっくりとつかむために大切な数値です。しかし、サービス・業務企画で調査する内容としては、さらに踏み込みが必要かもしれません。

例えば、１日平均で300人なので、余裕を見て400人分の対応ができるようにサービス・業務を設計しようと考えることがあるかもしれません。しかし、この考え方は少し安易すぎないでしょうか。なぜなら、平均や合計という代表値の裏に隠された、利用者ごとの違い、求めるニーズの違い、時刻や曜日ごとの違いといった様々な「ばらつき」を無視してしまっているからです。

ばらつきを注意深く見ていくと、サービスの中でもよく利用されるものとほとんど利用されないものの差が大きかったり、特定の利用者が何度も繰り返してサービスを利用している傾向が見えたり、時間帯や曜日によって利用方法にピーク特性があったりと、様々な実情が見えてきます。このようなばらつきをうまく捉えることができれば、単純に平均400名の対応量を確保するというやり方ではなく、特定の利用者向けの対応を別出ししたり、特定の時期のみに体制を強化したりといった対策を打つことができるようになります。また、ピークを分散させ平準化させることも、有効な手段です。

図4-4

ばらつきを分析する

このことは、様々な局面で注意してほしいポイントです。手続数、書類数、問合せ件数、業務処理時間といったサービス・業務面でも、アクセス数、画面レスポンス時間、夜間バッチ処理時間、障害発生件数といったシステム面でも、そのほかにも費用面、効果面、品質面など様々な指標を扱うときに、「平均」や「合計」といった言葉は頻出します。この言葉に出会ったときは、表面的な平均値や合計値だけを鵜呑みにせず、その陰に隠れているばらつきを捉えられているかどうか確認してみてください。

時間と期間を区別して滞留状況をつかむ

業務フローを可視化すると、様々な問題点が見えてきます。しかし、業務フローだけでは見えない問題があるのも、また事実です。

その１つが、業務のどこで滞留しているかを探ることです。そのためには、業務フローに紐づいた計測ポイントを設定し、業務処理の１件１件の単位で、それぞれの計測ポイントを通過した日時を確認します。

この分析を行うときには、時間（実際の業務処理に必要な時間）と期間（開始から終了までの全体の時間）を取り違えないように注意する必要があります。最初の計測ポイントから次の計測ポイントにいくまで５日間かかったとすれば、これは「期間」の考え方です。でも、その５日間の間で、実際に確認や審査等の実業務に要したのは僅か30分だったかもしれません。これが「時間」の考え方です。時間と期間を区別して捉えることで、実際の業務処理に必要な時間と、単に処理待ちで放置されていた時間を明確にすることができます。

このような分析を行うと、業務処理の中のボトルネックを可視化することができます。可視化ができれば、大きなボトルネックが発生している箇所について、その原因を確かめてみましょう。現場にヒアリングに行く際も、何も準備をせずにヒアリングへ行くと一般的な回答しか返ってきませんが、実データで特定部分にボトルネックが発生していることを示した上でその時に何が発生していたかを確認するようにすると、具体的で本質的な回答を得ることができます。

事例4-4

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

上記の例は、前の決裁者の処理が終われば次の決裁者へ移るという、基本的に一方向での業務処理でした。

一方で、業務の中には、複数の関係者間で処理が何度も往復するような複雑なものもあります。このような業務について滞留状況の分析を行う際は、次に示すシーケンス図が有効です。

事例4-5

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

業務量のピークを捉え、ピークの発生原因を把握する

業務フローだけでは見えてこないものは、ほかにもあります。それは、業務処理量です。

業務フローだけを眺めると、毎日、決まりに従ってスムーズに業務が流れていくように錯覚しがちですが、実際の業務では日々の業務量が大きく異なるので、繁忙期には処理が停滞しがちです。業務量に応じて、処理の方法まで変わることもあります。

このため、業務量の変化を捉えた上で、特にピークが発生するポイントを把握することが重要です。ピークが発生する例としては、年度末等の申請時期の区切りの直前、長期連休明けの営業日の午前中等が典型的ですが、業務の特性で様々な時期、時刻にピークが存在します。まずは、このようなピークがどこに発生しているかを把握しましょう。

業務のピークについては、サービス利用者側の要因で発生するものであり、サービス提供者側の工夫でピークを抑えることは難しいと考えてしまいがちです。しかし、まずは工夫できる余地があるかどうかを検討するためにも、ピークの時に実際に何が起きているかを調べてみましょう。どのような利用者がどのような目的でその時期に利用せざるを得ないのか、実際に発生している事象を確認すると、ピークが発生している理由を理解することができます。

ひょっとすると、とてもつまらない理由でピーク時期に余計な負荷がかかっているかもしれません。そういった一例を、参考として示します。

事例4-6

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

既存の業務内容そのままに業務量のピークを想定とすると、業務に必要な職員体制を見直すことも難しいですし、情報システムの処理能力も大きなものが必要となってしまいます。当然ながら、情報システムのコストも上がってしまいます。

特にピーク時と平常時の業務量の差が極端に大きい場合は、ピーク自体を分散化させることを検討したいですね。そのためにも、いつピークが発生しているか、そのピークに何が起きているのか、よく調べてみると改善のヒントをつかまえることができます。

業務のピークが、利用者の行動の締切り直前の集中にある場合は、利用者を締切り以前から行動するように誘導することや、利用者を複数のグループに分けて締切り自体を分散化することを検討します。例えば、公共料金の支払いにおいても、利用者を複数のグループに分けてそれぞれ支払い期限を変えていることが一般的になっています。

なお、業務量のピークを抑えることが根本的に難しい場合においては、システム方式としてクラウドサービスを導入することも有効な選択肢になります。クラウドサービスでは、基本的にリソース（サーバ等の能力）を使用しただけ費用が発生するので、瞬間的なピークにも対応しながら全体的にはコストを抑えるといった使い方が可能になります。

問合せや要望は、根本原因が同じになる粒度まで分類する

サービスを提供していると、様々な問合せ、要望等が寄せられます。ヘルプデスクとして電話で問合せを受けることもあるでしょうし、窓口で利用者から直接問合せを受けることもあるでしょう。毎日10件の問合せがあったとしても、１か月で200件、１年では2,000件を超える問合せを受けることになります。

さて、サービス・業務改革を進めるためには、このような問合せの履歴は「宝の山」になります。利用者が何に困っているのか、何を望んでいるのか、そこに利用者のニーズの原石が埋まっているからです。ただ、大きな山なので、なかなか掘り起こすのが大変ですね。年間数千件、場合によっては数万件にもなる問合せの履歴の山から、どのようにして宝となる原石を掘り当てればよいのでしょうか。

そのキーポイントとなるのが、分類です。多くの場合において、サービスの種類別や工程別に分類を行っていると思います。施設予約のサービスであれば、利用者登録、施設予約、抽選、料金支払いといった分類です。また、問合せ内容の原因別という観点もあるかもしれません。施設予約システムの操作方法、システムの動作環境、システムの不具合といった分類です。

しかし、いずれの例も、かなり大括りであることに気づかれたでしょうか。「利用者登録」の「システム操作方法」に関する問合せが今月20件あったとします。先月は30件でした。確かに合計数値では減少していますが、こういった数値を見て一喜一憂することに意味があるのでしょうか。この20件という数字は、内容の全く異なる問合せをその違いを考慮せずに単純に「合計」しています。これでは、どのような事象が利用者から問題にされていて、何を対策すればよいのか、何も探ることができません。

最初に少し手間はかかるのですが、利用者からの問合せが発生した根本原因が同じ所に行きつくまで、詳細に分類することが重要です。根本原因に行きつくまで分類を行った一例を、以下の参考に示しました。

事例4-7

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

同じ原因別に分類することができれば、その発生傾向を分析することができます。

例えば、参考に記載した例では、ＦＡＱにわかりやすく注意を載せる等の対策を打ちました。この対策に効果があったかどうかは、対策を打つ前後で同じ分類の問合せの件数を見るとわかります。対策を打った後でこの問合せが大幅に減ったのであれば効果があったと言えますし、対策を打った後もこの問合せの件数がほとんど減らなかったのであれば、何か別の対策を打つ必要があるということです。

このような詳細な分類を行うことは、確かに手間がかかります。ただ、全体的な分類を一度見直すことができれば、その後に発生する問合せに対しても発生の都度正しく分類しやすくなります。そして、何より利用者が感じている小さな不満から大きな苦情までを捉えることができ、同じ原因別での問合せ発生数を時系列で把握できるという点で、業務・サービス改革のために非常に有効な分析が行えます。

もし、利用者からの問合せのデータが大括りのままに眠っているとすれば、一度、職員の中で分析チームを作って分類を進めることにトライしてみてはどうでしょうか。

業務を可視化する

【標準ガイドライン関連箇所：第３編第４章第２節】

業務を観察した結果、実績データを分析した結果は、様々な観点からまとめられた大量のドキュメント群となることがあります。分析を実施した当事者はこれらの内容をよく理解ができますが、これらの資料を初めて読む人にとっては、ポイントをつかむことが難しいでしょう。

業務の分析結果は、プロジェクト内部の職員（ＰＪＭＯ職員）、プロジェクト外部の利用者や関係者、システムを整備する際のシステム開発事業者等、様々な立場の人がその内容を確認する必要があります。これらの関係者に対して的確に業務の状況を伝えるためには、業務フロー等、業務を誰にとってもわかりやすく可視化した資料を作成することが重要です。

様々な立場の人が理解できる業務フローを作成する

注記

AsIsとは、「現状」の意。「将来あるべき」のToBeとセットでよく使われる。

業務フローは、現在行っている業務を「誰が（どの組織が）」「いつ」「何を」「どの順番で」実施しているか、「どの範囲が情報システム化されているか」を可視化するものです。対策の検討や企画後の業務内容の変化箇所を特定するためにも有効です。

業務フローには、現行（AsIs）と将来（ToBe）がありますが、ここで作成するのはまず現行の業務フローです。

業務フローの書き方については、様々な表記方法があります。基本的には、関係者にとってわかりやすい表記であれば、どのような表記方法でも十分です。縦に流れるフローでも、横に流れるフローでも、どちらでも構いません。

図4-5

業務フロー（現行）の定義例

なお、将来（ToBe）の業務フローについては、「Step.5-2-E. 将来の業務フローには、効果を紐づける」で後述します。

業務フローの表記方法には様々な手法がありますが、次のようなことに留意すると関係者が理解しやすいものとなります。

業務フロー作成時の留意点

*業務を実施する主体ごとに表記を分ける* 業務を実施する主体を分けないと、誰が実施している作業なのか区別がつかなくなります。実施主体ごとに「レーン」を作成し、発生する業務をプロットします。
*業務単位を軸に体系化する* 業務フローは、大きくなりすぎると読みにくくなるため、一定の業務単位にサブフローとして１つのフローを作成します。業務の単位は、業務一覧の階層と合わせることで整合性がとりやすくなります。
*システムを利用して行う業務を明確にする* 業務フローの中には、人が手作業等で実施する業務と、システムを利用する業務が入り混じります。システムを利用する業務については、色を変えたり、枠囲みによって利用するシステムを表したりすることで、区別できるようにします。
*帳票やデータの受け渡し内容を明確にする* やりとりする帳票やデータ等の起点と終点を明らかにするとともに、その内容（特にインプットとアウトプット）を明確にします。なお、インプットとアウトプットに関する情報は、帳票名やデータ名に留め、詳細な項目は後述の業務記述書や業務ルールに記載し、業務フロー上で詳細になりすぎないように注意します。
*業務の流れ方を一方向にする* 横書きであれば左から右、縦書きであれば上から下の基本的な流れに沿って業務をプロットします。基本的な流れに沿わない業務の進み方が多くなると、理解しにくくなってしまいます。
*中心となる業務について記載する* 実際の業務の中では様々な例外処理が発生しますが、それらを全て記載する業務フローが複雑になりすぎて理解できなくなります。中心となる業務について記載し、例外等については後述の業務記述書や業務ルールとして別に書き出した方がわかりやすくなります。
*業務のばらつきに留意する* 業務フローを書くと全ての業務がこの標準的な業務フローで動いているかのように錯覚してしまうことがあります。実際には各拠点、各組織でそれぞれ工夫を行ったり独自の背景があったりするため、様々な業務のバリエーションが存在することが多くあります。確かに、これらのバリエーションを全て業務フローとして可視化するのは煩雑です。しかし、業務のばらつきが存在することについて現地調査や担当者へのヒアリングを通じて十分に把握して、それらの業務も標準化するのか、又は複数の業務実施パターンを許容した上でシステムも各業務パターンへの個別対応を行うのかについて、業務要件作成時に方針を定めることが重要です。

前述の業務フローのイメージは、一般的なＰＣのプレゼンテーション・ソフトウェア等で作成することをイメージしたものです。なお、業務フローを効率的に作成するためのツールも多種存在しているので、必要に応じてそのようなツールを整備することも検討してください。

また、業務フローの表記についての国際的な標準として、ＢＰＭＮ（Business Process Model Notation：ビジネスプロセスモデリング表記法）があります。業務フローを作成するツールの多くは、このＢＰＭＮに準拠した表記を行うことができます。

図4-6

ＢＰＭＮ表記で書いた業務フロー図

業務ルールや業務実施方法をまとめる

業務を可視化した文書は、関係者がサービス・業務や情報システムの目指すべき姿を共有するものであるため、誤った定義や曖昧な定義が行われると、後続の工程に重大な影響を与えます。

そのため、業務を可視化した文書を作成する際には、次に示す点を参考に、正確で一貫性のある記載となるようにしましょう。

曖昧な用語や一般的な意味と異なる使い方をしている用語等は、プロジェクト関係者間の認識そごを防止するため、用語の定義及び機能を定義する粒度や深さについて統一する。

事例4-8

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

サービス・業務企画内容の検討における作業のしやすさを考慮して、業務単位や区分、順番等を整理する。

注記

「業務可視化資料の作成について」（特許庁ＰＭＯ　平成27年５月18日）

入出力情報や管理対象情報をまとめる

業務を構成する要素には、業務フローに代表される「プロセス」だけでなく、「情報、データ」があります。「プロセス」が業務の動的な側面（流れ、動き）を表すのに対し、「情報、データ」は業務の静的な側面（常に成り立つ相互の関係と、ある時点での状態）を表すといった特徴があり、いずれも業務（システム）を定義するために欠かせない要素となります。

「情報、データ」の現状を把握するには、「入出力情報及び取扱量」及び「管理対象情報一覧」をまとめます。

「入出力情報」と「管理対象情報」の違いは、「入出力情報」が画面、帳票、CSV形式の一時ファイルなど、実際の業務でやり取りする単位の情報であるのに対し、「管理対象情報」はそれらの要素を管理しやすい単位に分解、集約した情報（将来のデータベースの元情報）となります。

　一般的な「管理対象情報」の抽出方法は以下のとおりになります。（）内は、別紙「要件定義書標準テンプレート」における図書貸し出しシステムの事例です。

*「入出力情報」の項目を同じ単位の情報に分解する* ある入出力情報に記載されている項目を分析し、同じ単位で括れるものを抽出する。（例えば、「貸出申請書」の項目を、「書籍」「利用者」など単位が異なるものに分解する。）
*「入出力情報」自体も、１つの「管理対象情報」として抽出する* 入出力情報自身も、その事象自体を管理する場合は、管理対象情報となる。（例えば、「貸出申請書」という入出力情報について、一枚ごとの「貸出申請」という事象は業務上で通常は管理するものであり、管理対象情報になる。一方で、「貸出状況照会履歴」のように、貸出状況の照会を誰がいつ実施したかという情報までを業務上管理する必要がないのであれば、管理対象情報とする必要はない。）
*抽出した管理対象情報のうち、親子関係があるものをさらに分解する* 抽出した管理対象情報の中で、合計と内訳のように親子関係を持っているもので、親子別々に管理する必要があるものは、別の管理対象情報とする。（例えば、上記の「書籍」をその本の基本情報（タイトルや著者など）と、実体（本一冊ずつ）が持つ情報に分け、前者を「書籍情報」、後者を「書籍」と名づける。）例えば、貸出用に同じ本が３冊ある場合は「書籍」としては３つの実体があり、そのタイトルや著者などの「書籍情報」としては１つとなる。

図4-7

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

様式例4-1

現状分析結果報告書のひな形