SysAdmin's Group システム管理者の会
日本最大規模の
システム管理者のネットワーク

運用ノウハウを学ぶ

システム管理に関わるベーシック情報やトレンドをご案内します!

システム運用に活かせる業務の可視化と改善手法 第3回 業務フローの描き方
2021年10月13日 14:00

業務フローを描く手順

今回はいよいよ業務フロー作成の手順について触れて行きたいと思います。前回に引き続き、お客様からお問い合わせを受付し、これに回答する業務を例にとって話を進めて行きます。業務フローの一段上位にあたるレベル2の業務マップが次のように設定されているとしましょう。

図1. 問い合わせプロセス(レベル2)

「受付」は電話、メール、問い合わせシステムといった手段別に分かれていますが、いずれにせよ、お問い合わせの内容がしっかりと把握され、その内容が記録され、後続プロセスのパターンが特定されるまでが描かれるとしましょう。今回はこれを受けて「切り分け」の業務フローを作成してゆきます。受付時点では即答ができず、問題の切り分けが必要となった場合のプロセスとなります。一般的に業務フローの作成手順は次のように分解されます。

1. 始点と終点を決める
2. 登場人物 (役割分担) を特定する
3. 業務ステップを洗い出す
4. インプット、アウトプット、利用システムを特定する
5. イベント (開始条件や分岐条件) を洗い出す

こうして書き出してみると、難しい作業のように見えてしまいますが、業務フロー作成に慣れていて、いきなり先頭から綺麗にフローが書けてしまう方であっても、頭の中ではこのような要素を同時並行で考えながら描いています。初めての方もこの手順に沿って実行してゆけば、自然に業務フローが出来上がります。上記の一つ一つのステップは事実を知っていればそれを淡々と描くだけですので難しいことではありません。但し、その事実がわからない (情報が足りない) 場合には調査する必要があります。その手段がヒアリングやレビューです。多少、真偽が曖昧な所があったとしても、まずは仮説で描いておき、後でこのプロセスをよく知る方にレビューしてもらって直せば良いのです。そのように割り切って進めましょう。

1. 始点と終点を決める

この業務フローの開始条件と終了条件を定めましょう。「切り分け」プロセスですので、開始条件は「問題の切り分けを依頼された」という状態です。終了条件は「問題の切り分けと対応方針が確定した」もしくはそれが「仮説設定された」状態としましょう。

業務フローの終点を始めに意識して描き始めることは重要です。このプロセスのゴールは何かを考えてみて下さい。どんな情報 (アウトプット) が確定されれば完了と言えるのか、と考えると良いでしょう。アウトプットをイメージすることにより、このプロセスで集めなければならない情報、確認や判断をしなければならないポイントなどが見えてきます。これにより必要な業務ステップも自ずと想定できるので、正確に実情を知らなくても仮説ベースで業務フローが描けるようになります。この技は業務の改善を検討する際にも役に立ちますが、それは次回以降でお話します。

2. 登場人物 (役割分担) を特定する

始点と終点が定まったら、その間に登場する役割を特定してゆきます。依頼者は問い合わせの受付担当者でした。このプロセスの主人公は問題の切り分けを任された担当者です。問題切り分けにあたり助言や情報提供を求める相手 (上長、インフラ担当者、アプリケーション保守担当者等) が必要であれば、これらも登場人物となります。業務フローには役割別のレーンを設けますが、フローを描き始める前に、ここで洗い出された役割をレーンとして準備しておきましょう。

レーンの並び順は、「依頼者を一番左に、依頼を受ける主人公をその右隣とし、あとは社内の関係者を主人公に近い順に右方向へ並べる」というルールに統一することをお勧めします。業務をうまく進めるコツとして「(立場の)遠い人から先に調整をかけるべし」とよく言われます。前述のルールに従うと、このような観点も視覚化でき、(遠い人にはもっと早く調整するようにしたらどうか等) 叩き甲斐のある業務フローとなります。

図2. 業務フローのレーンの並び順 (イメージ)

 

3. 業務ステップを洗い出す

役割別のレーンが準備出来たら、業務フローの上から下へ業務ステップを並べてゆきます。線は始めから綺麗に繋がなくても良いでしょう。思いつくまま、まずは気楽に箱を並べてみましょう。この際のポイントは、一つの箱として描く業務ステップの粒度感 (荒さ、細かさ) についてです。業務フローにおける業務ステップは、「ハンドオフの単位」にするのが良いとされています。ハンドオフ (Hand-off) とは、英語では「何かを人に手渡しする」ことを表します。アメフトではランプレーでクォーターバックが後ろからくるランニングバックにボールを渡して走らせる時のことをハンドオフと言います。業務でも「ボールを持っている」「ボールはあっちに渡した」という比喩をよく使いますね。まさにその感覚で、ボールを持っている単位を一つの業務ステップとして描きましょうというガイドラインです。

最近の業務ではいろいろな局面でITを使いますので、ハンドオフは必ずしも人から人へ手渡しされるとは限りません。ITツールを使って「何らかの情報を共有フォルダに保存する。」あるいは「アプリケーションに何らかの情報を登録する。」これらもハンドオフにあたります。その瞬間にアウトプットは他人にも利用可能となるからです。また、情報を記録する媒体 (器) が紙→エクセル→システム→PDFと変わってゆく (転記される) 際もハンドオフとみなして下さい。転記業務は無駄の典型例ですが、将来的にそれをなくしてゆくためにも、現在の事実として明記すると良いでしょう。

業務フロー上の業務ステップの粒度をハンドオフの単位に揃えることにより次のようなことが見えるようになります。

  • ●責任の切れ目が明確となり、課題やリスクの所在として指さすのにちょうど良い
  • ●業務の所要時間を測る単位としてもちょうど良い
  • ●業務ステップ数が業務の複雑さやスマートさを表す指標として使えるようになる

システム運用を回すにあたり、ハンドオフの単位で描かれた業務フローだけでは粗すぎて情報不足だと思われるかもしれません。その通りで、運用マニュアルとして使うにはもう一段詳細のレベル4にあたる手順書類が必要になります。この話は前回の「業務可視化成果物の全体構造」についての解説でご紹介していますので、連載の第2回をご参照下さい。

図3. 業務可視化の構造 (第2回より再掲)

 

4. インプット、アウトプット、利用システムを特定する

業務ステップの箱を配置出来たら、次はそれぞれの業務ステップにおけるインプット情報とアウトプット情報を配置してゆきます。「切り分け」プロセスにおいては、依頼された担当者がまずは「依頼内容を確認する」という業務ステップにおいて、自分自身で切り分けできるのか、他の人に支援や情報提供を依頼する必要があるのかを判断することになります。インプットは依頼内容、アウトプットはその判断結果となるでしょう。この際、それぞれの情報はどのような媒体やフォームで目にすることができるでしょうか。紙なのか、メールなのか、依頼時に利用されるシステム画面なのか。ITを使う場合は何らかのユーザーインターフェースがあるはずですので、そのシステム名、画面名を業務ステップに付記します。

業務ステップはハンドオフの単位で描きましょう、と書きましたが、インプット、アウトプット、利用するシステムは1セットで考えます。つまり、同じような内容の業務ステップであっても、インプット、アウトプット、利用システムの組み合わせが異なる場合は別の業務 (バリエーション) であると捉えて下さい。もちろん、インプット、アウトプットの中身は一件一件異なるのは当然ですが、媒体やフォームが同じなのかどうかで判断します。こうすることで現状業務のバリエーションがどれだけ複雑な状態なのかが可視化されます。「フォームは場合に応じて使い分けているので一概には言えないし、そんなのを全て洗い出したら大変」と思われるかもしれませんが、それがまさに属人化した状態、他人に説明できない状態です。ここが”可視化する”という事の正念場です。(実際問題、全てのバリエーションを可視化するなんて無理ということもあるでしょう。その場合は代表例を描いておき、洗い出せないほどに複雑であるという課題をメモとして残して下さい。業務可視化の前にフォームの統一をしなくては、と気づくことも成果の一つです。)

5. イベントを洗い出す

イベントとは、一般用語で「出来事」のことを指します。現場の業務の多くは何かを依頼されたり、気づいたりしたという「出来事」をきっかけにして開始されますよね。業務フローを作成する時も、それぞれの業務ステップはどんな「出来事」をきっかけにして開始されるのか、を考えながら描くと、高品質で改善余地に気づきやすいフローになります。

実際に業務フロー上でイベントを書こうとしてみると、開始条件が曖昧な (または不明な) 業務がとてもたくさんあることに気づきます。前述のように、不明な場合は仮説で書き進め、レビュー時に質問するようにして下さい。業務全体のリードタイムを短縮しようとする時に、個々の業務ステップの所要時間を縮めることを考えがちですが、ホワイトカラーの現実は「業務間の待ち時間」の方が業務を実際に行っている正味時間よりも長いことが一般的です。一件あたり正味10分かかっていた仕事を効率化して5分にするという努力も大切ですが、その仕事に取り掛かる前に2時間の待ち時間がある (下手をすると一日気づかずに放置している) という事が日常茶飯事だと思います。開始イベントを丁寧にヒアリングして記述することで、そのような無駄が洗い出されます。

図4. 業務フロー (切り分け) の完成イメージ

 

まとめ:業務フローの描き方

一本の業務フローを描くステップを、要素分解しながら解説してきました。ステップ1から5を進める中で、不足点に気づいて前に戻ることもあると思います。ステップ1〜5はそのように繰り返し試行錯誤しながら進めて下さい。上級者になるにつれて、手戻りが少なくなってゆきますが、はじめは気にせず、何度も戻って描き直せば良いと思います。ステップ1〜5の各要素を揃えることが出来たと思ったら、最後に全体的なフローの体裁を整えて完成となります。

次回はこのように描いた業務フローを対象にしてレビューを受け、課題を洗い出す工程について解説してゆきます。

補足
本稿の図版1と4は株式会社ユニリタが提供する業務可視化ツール Ranabase (ラーナベース) で作成しています。本ツール内でこれらのサンプルが提供されており、コピーして皆様の業務に合わせて書き換えてゆくことで効率的に自社の業務可視化を進めることができます。無償トライアルも可能ですので、ご興味があれば是非お試し頂ければ幸いです。
お申し込みサイト: https://lp.ranabase.com/

  •  

 

 

スキルアップ
システム運用に活かせる業務の可視化と改善手法
業務可視化と継続的改善のための方法論であるBPM(ビジネス・プロセス・マネジメント)をシステム運用領域に適用し、網羅性・検索性の高い業務フローの作成方法や、描かれた業務フローを対象にした業務改善の検討方法などをご紹介し、そのノウハウを身につけていただくとともに、属人化しやすいシステム運用業務の透明性を保ち、ベテランからの技術伝承や若手人材のスキルアップ・上流化につなぐ可能性を検討します。
記事一覧へ
筆者紹介

冨樫 勝彦 (トガシ ヨシヒコ)
1972年生まれ 株式会社ユニリタ クラウドサービス事業本部 ビジネスイノベーション部 部長、当部が運営・提供する業務の可視化・改善・共有ツール Ranabase (ラーナベース) のプロダクトオーナー。大学卒業後、ERP導入に従事、プリセールス・企画・設計・アドオン開発・データ移行・AP保守などさまざまな工程・業務領域を30代前半までに経験し、そのうちPMを務めた一社では稼働後約15年間にわたりAP保守を担当、2回のハードウェア入れ替えと1回のソフトウェアバージョンアップを果たしたが、そのノウハウが完全に自分一人に属人化したという経験を持つ。2000年にはBPM(ビジネス・プロセス・マネジメント)分野のコンサルティングに転向し、国内へのBPMの普及・展開を推進、システム運用を属人化させないことと、ユーザー企業が自ら継続的に業務プロセスを改善してゆける姿を模索する日々を過ごす。仕事上のテーマは変わらないが所属先は転職・買収・事業移管等を経て2015年にユニリタへ、他社製のBPMツール活用では飽き足らず2019年からBPMツールの自社開発に着手、現在に至る。著書:「正攻法の業務改革」(現代書林)
Ranabase製品サイト: http://lp.ranabase.com
仕事を可視化し、継続的に改善する方法を学べるブログ “カエル塾” : https://kaerujuku.jp/

コメントを書く

未ログイン: ログインする

コメント: ログイン(会員登録)すると、コメントを書き込むことができます。

  • 新着Q&A
  • 最新の回答
回答数:22019年11月12日

システム管理者認定講座<全コース共通>試験のみ受験希望の方はこちら

動画で見るセミナー
動画で見るセミナー

2021年7月 第15回システム管理者の会 感謝の日イベントの開会のご挨拶の様子を掲載いたします。

個人情報保護方針
運営者につい て
利用規約
サイトマップ