• 業務分析サービス
• 現状業務フロー作成
• 理想的業務フロー討議・作成
• 改善提案作成
• システム要望/システム化提案作成


• ＩＴ関連
• システム化計画サイクル策定
• システム化コンセプト構築
• システム要求作成
• ベンダー選定
• 外部設計検討
• 設計書作成
• 業務フローとの付き合せ
• 導入テスト
• IT導入テスト
• 業務フローとの総合テスト
• プロジェクトマネージメント


• 情報システム部門改善

　システム開発で業務分析が大切だと言われながら、SIer、システム
開発会社の開発標準で、業務分析の必要な場合、不要な場合が例示され
ていません。

　結果、業務分析の目的、必要性、位置付けが不明瞭になっています。
業務分析が必要な場合を、規定したい、システム開発において、何でも
カンでも業務分析が必要なわけではない、というのが当文章の趣旨です。


　システムは、業務の中で使われて、業務の一部として機能すべきものです。
従って、システムへの要求を決めるのは、業務プロセス、業務フローを
決めてからになるはずである。業務プロセスが決まっていないと、システム
への要求が決まりません。

　最近は、業務が既にシステム化されている場合が多い。従い、システム開発
といっても、現行システムの改修が非常に多い。
　システム改修では、既にある画面、データ内容、チェック方法の改善など、
お客様の要求が具体的である。また、業務プロセスは既に詳細まで定義されて
いて、システム改修でも大きな業務プロセス変更にもならないことが多い。
　こういう場合には、業務分析は不要です。

　大きく業務プロセスを変更する、または新規のシステム開発などの場合に、
業務分析が必要にます。但し、これらの場合でも、お客様が業務プロセスを充分に
理解していて、システム化後の業務プロセスを理解されている場合には、業務分析
は不要になります。
　但し、お客様が自社の業務プロセスを理解して、システムへの要求を出される
場合が非常に少ないのも現実です。システム開発の要求定義段階で業務分析が
必要になる場合が多々あります。

　つまり、業務分析が必要になる場合は、お客様が現行業務プロセスを理解して
いない、システム化後の新業務プロセスを明確にする場合に、業務分析が必要
になる。

　 　システム開発における業務分析とは、

• 現行の業務プロセスを明確にし、
• それを改善するためのシステム化要求を決定し、
• 新業務プロセスを組み立てる

ことです。
システム要求を決定するので、要求定義工程で実施します。

　業務分析が必要な場合は、お客様が業務プロセスを明確にできない時です。

　新規業務などでは、お客様が業務プロセスを簡単には決定できないのも事実です。
業務プロセスを最終化できずに、システム開発を開始してしまい、後で大きな変更
になる場合も良くあります。業務プロセスの決定を待っていると、開発期間がドンドン
なくなってしまい、見切り発車で開発を始めなければいけないことが良くあります。

　タイミング、リスクの認識、注意が必要です。

　システム開発の最終に近いテスト段階になって要求の変更が多々あるプロジェクト
を良く見かけます。
　これは、お客様が業務プロセスを詳細化せずにシステム要求を作成し、システム
サイドはこれを信じて開発を実施し、システムが見え始めてからお客様が業務と
合わないと気付き、システムへの変更を要求してくる、という流れです。

　要求の明確化と同時に、要求が本当に業務プロセスと合致しているかの確認は
必須です。システムは業務の流れの中で使われて、初めて役に立つのですから。

　業務システムはシステムだけで動くのではありません。

　業務システムは、業務の一部として使われて、初めて力を発揮します。

　業務フローの書き方の説明が必要だったようです。

　アクセスログを見ると、多くの方が、”業務フローの書き方”という検索結果から、
当サイトに来ています。
　フローの書き方より分析の方が重要だと思っていましたが、フローの書き方に興味が
ある方の方が多いようです。今までは、業務プロセスの分析方法、改善策の作成について
書いてきましたが、業務フロー図の作成方法について説明します。


　ここでは、業務プロセスは判っているとの前提で業務フローの書き方だけに付いて説明
しています。従い、業務プロセスの抽出方法などは説明しません。


基本

　業務フロー図には、フローを書き出す枠組みとフローに組み立てるための工程記号が必要です。

　枠組みとは、部門/担当者などの枠（レーン）です。各プロセスを実施する部門などを長い
枠でくくり、これを必要分だけ並べます。水泳のレーンのようなので、スイムレーンとか、
単にレーンとか呼びます。これが、横書きでは横長になり、縦書きでは縦長になります。

　工程記号とは、プロセスとか帳票を表す記号です。これを組み合わせて業務フローを書き
表します。


　書き方は横でも、縦でもかまいません。他のドキュメントとの関係で決めます。最近は
パソコンで書くためか、横書きが多いようです。


レーンのサンプル

縦書きの場合


横書きの場合


　いずれも、Visioで作成しました。ここまではVisioを使うとフローチャート、
部門連携フローチャート、横方向/縦方向と言う順番の選択で簡単に作成できます。

　このような図は、Visioでなくとも、PowerPointやExcelでも簡単に作成できます。

　レーンは、業務の主な部門/担当者は細かめに作成し、主でない部門などは大まかに
作成します。
　日時レーン：時系列を示すレーンを端に作る（横書きであれば上に、縦書きであれば左）。
処理日、経過日数/時間など記入し、該当する下とか横にプロセスを書き込みます。
　システムレーン：システムを利用している場合は、またはシステムを検討する場合は、
時系列とは反対側にシステムレーンを作る（横書きでは下、縦書きであれば右側に）。
主なシステムと関連システムとか内部と外部のシステムなどがある場合は、システムレーン
を２つ使用します。


　誰にでも判りやすいという意味では、使用する工程記号は減らすべきです。産能大の
業務フローの書き方では、沢山の工程記号を使用し、慣れていない人には判り難いように
思っています。工程記号が多いと、工程記号の説明、理解が面倒です。

　判り難い部分は、工程記号の多用でなく、コメントを付ければ良いでしょう。

　利用する工程記号は、プロセスボックス、帳票、データベース（PCなどに保存する場合）、
台帳（マスターファイル）などで充分です。これらの工程記号を矢印（接続線）で結んで
フロー図を作成します。システム機能はプロセスボックスでも良いですが、システムを明確に
分けたい場合に利用します。

　プロセス数が多い場合は、プロセス番号を付けるべきです。プロセス番号は、プロセス
ボックスの脇に付ける方法と、プロセスボックス上部を横線で区切ってプロセス番号を書く
部分を作る方法もあります。
　システム機能も多い場合は、システム番号を付けるべきです。

　分岐の条件とか、特別なメモなどは、接続線の脇や工程記号の脇にメモ書きとして書き
加えます。

　各工程記号の内にプロセス名とかシステム機能名、帳票名などを記入します。業務フローを
見る関係者が、内容を理解できる名前を付けます。

　お客様番号など、業務プロセスとして重要な肝のナンバリング方法などとか、特定処理内容
の注意書きなどは、フローとは別ページで説明すべきです。


業務フロー図記述ツール

　本来は手書きでも良いのですが、作成後の修正、転用などを考えると、当然パソコンでの
フロー図作成ツールを使うべきです。いまどきパソコンを使わないで、手書きはないです。

　関係者全員が利用している、利用できるツールを選ぶべきです。現在は企業のパソコン
利用ではMSオフィースが、多いと思いますから、ツールもMSオフィース系を使用すべきです。

PowerPoint
・通常ですと、PowerPointが描画ツールです。
・まあ普通の作図ツールで、誰でもが書きなれています。


Excel
・意外と作図には適していて、IT系ではよく利用されます。印刷する用紙の大きさを意識せず
　に書け、フロー図が大きくなった時にも、そのまま書いていけます。多くのSEが、Excelで
　業務フローを作成しています。
・Excelの上に図を書く方法でなく、セルを1つのプロセスと考える書き方で、業務フローを
　Excelで作成することもあります。


Word
・業務フロー図を書くのは適切ではないです。Wordは、あくまでドキュメント作成ツールで
　すから、作図には向かないと考えています。
・Wordのドキュメントに統一するためには、PowerPointなどで完成させてから、全体を
　Wordにコピーすることはあるかと思います。


Visio
・MS系では、Visioが本来の作図ツールですが、MS Officeというパッケージには含まれ
　ていません。
・しかし作図ツールですので、フローチャートだけでなく、グラフ、ネットワーク図、
　機械設計、電気設計などいろいろな図の作成に利用できます。利用にはVisioの購入が
　必要ですが、Visioで作成した図を見るだけならば、マイクロソフトのWebサイトから
　無料で参照プログラム（Visio Viewer）をダウンロードできます。
　したがい、フロー作成者だけがVisioを購入はあるかと思います。
・Visioでは、工程記号もステンシルということで付属しています。必要な記号だけを
　ステンシルとしてカスタマイズも可能です。他のツールではフローチャートから選択
　します。
ということで、作図には、MS Office系では、PowerPoint、Excel、Visioが利用可能です。


書き方

　まず、書くツールと横書きか、縦書きかを決める。決めたツールで、プロセスを拾い出し
てボックスに書いていく。

　業務フローの書き方を悩んでいる人が多いですが、とにかく書いてみるべきです。想定で
書いて直していくべきです。単に悩んでいるのはダメです。とにかく書き出していくべきです。

　レーンの中に、左から右へ、上から下へ時系列に流れる様にプロセスを、つなげて書き出
します。
　レーンを始めに用意して、プロセスを書き出していく方法でも、プロセスを書き出してから、
レーンに移す方法でもフロー図になります。

　書き出したものを、業務を知っている人に聞いて、相談して修正して、洗練し、全員で納得の
行く業務フローを作り上げます。
　処理のかたまりでの流れを作っていきます。このかたまりがプロセスで、大きさも問題になり
ますが、とにかく書き出すことです。

　工程記号を使って、きっかけ、プロセス、帳票などを時系列に書き出して、矢印記号で接続し
ていきます。

　プロセス間を行き来する情報/帳票名の明記が必要であれば、接続の線上にでもメモする。
　電話、メール、郵便、手渡し、FAXなどの情報の伝達手段が決まっている、もしくは明記し
ないと判らない場合は、接続線の上にメモ書きにする。

　プロセス全体の始まるきっかけが帳票であれば、フローチャートの帳票記号を使う。
　その業務プロセスの最終成果物が帳票などであれば、帳票記号で記入し、その帳票を作成
するプロセスと線で接続します。

　各プロセスボックス、帳票工程記号を担当の部門レーンに入れる。

　特別な注意書きを付けたい場合は、該当するプロセスボックスなどに*1などと付記して、
欄外に*1として注意書きを書く。


　こんな風に書いていくと、用紙に入りきらなくなります。１つのフロー図には、10個程度
のプロセスにすべきです。
　ページが2、３であれば問題ないですが、これ以上ですと見難く判り難いです。
　幾つかのプロセスをまとめたりして、プロセスの粒度の検討をすべきです。

　業務の全体像を大まかに書き表す業務フロー図と、各詳細プロセスフロー図に分けると、
ページに入る、入らないの問題は解決します。

　一般的に、業務概要は1枚にまとめ、各業務詳細を個々のフロー図にします。この方が、
大局からの理解もでき、上位マネージメントへの説明、実務者との検討などでの使い分けが
できます。
　プロセスが多い場合には、概要と詳細を3段階とか4段階にすることもあります。


工程記号

業務プロセスはボックスに
　プロセスボックス内には、プロセス名だけで内容が判る場合はプロセス名のみ、判らない
場合はスペースがあれば作業内容を書く。スペースがなく、明記必要であれば、注釈にする。

　ボックスは一人の人が連続して処理する論理的なかたまり（業務、仕事、処理）を１つの単位
として書く。
　一人の人が連続して処理していることを、細かく分けない。
　但し、休みなく働くということではなく、あくまでも論理的なつながりの単位です。
　 　論理的につながっていない仕事は、別なボックスにする。
　または通常は違うフロー図になるはずです。

　システム機能はボックスでも、角の取れたボックスでもいい。
ボックスには機能名を記入（誰でもが内容を想像できるような）する。
　情報のかたまりはコンピュータフローチャートで使う帳票マークで記入。

　ボックス、帳票などを時間的流れを線で結ぶ。連続した論理的な業務のかたまりを単位として
フロー図を書いていく。

　同じフロー図に、全く違う業務を書き込まない、違う業務は別のフロー図に書き出す。

　1つのフロー図には、通常10個程度の業務プロセスボックスを書き出す。多くなった場合には、
ページを分ける。
　フロー図が長くなった場合は、論理的なかたまりに代表的な名前を付けて、レベル分けをする。
詳細は別の1枚のサブのフローとして書き出す。

　何らかの判断でプロセスボックスが分岐する場合は、接続線上に分岐条件を書き出す。





でも、本当は

　業務フロー作成自身よりも、重要、難しいことがあります。

·業務プロセスの拾い出し方
·業務プロセスの粒度（レベル）そろえ方
·インタビュー方法
·業務改善の方法
·業務フローを書く目的の明確化は重要です


業務分析でできること

·仕事の品質、コスト、作業時間の改善
·業務改善
·業務全体の可視化
·関係者全員で業務の全体像の共有することで品質改善、作業者のモチベーション向上

以下も重要です。
·通常、担当者は、自分の担当部分しか判らず、全体での位置付けを理解していない。
·担当者のモチベーションを向上し仕事の品質の改善できます。
·担当部分の業務の全体での位置付けを理解することで、担当者のモチベーションをあげる。
·単にやらされるだけの仕事では担当者のモチベーションは上がりません。
·自分の仕事の全体への位置付け、必要性が判って、担当者のモチベーションはあがります。
·モチベーションをあげることで、仕事の品質が上がります。
·前工程、次工程を理解することで、自分の仕事を改善して、業務全体の改善効果をあげていきます。

以上、業務フローの書き方だけと思いましたが、以外の部分にも触れてしまいました。

　以前ご紹介した 米国生産性品質センター(APQC)の
　提供しているProcess Classification Frameworkを翻訳していましたが、
　偶然、日本能率協会コンサルティングの翻訳が既にAPQCのサイトにあるのを
発見しました。

　企業の一般化した業務プロセスの一覧表です。非常に詳細なリストです。
　業務プロセス構築、改善、見直し、また業務プロセスの勉強などに役立ちます。
　経営者、マネージメントの方々は、もっと業務プロセスのあり方を考えて、
　業務品質、仕事の品質の向上をはかるべきです。

　誰でも利用できるようです。是非、ご一読ください。

　当社では、PCFを別な形態にすることによる利用方法を検討していきます。

　初めて、業務分析方法論を開発したときの話です。

　1993年始めに、当時勤務していた会社で、業務フロー作成ツールを利用
して、お客様の業務フローを作成しました。
　非常に便利なツールだったので、実際に業務をしている人にインタビュー
して、最終的にフローが生成できます。

　数人の部下が、出来たあがったフロー図を見せてくれました。
しかし、問題があるとの話。

　フローは出来たが、何処の、何が問題か、どうか改善すべきかが判らない
という問題でした。米国本社でも、ツールの使い方、インタビューの方法
などはガイドがあります。しかし、分析そのものについての方法がありません。

　一人が、図のある部分が花火のようになってるんですよね、と言い出した。
これだと、思い付いたのが方法論の始まりでした。

　花火のようになっている部分は、幾つもの前後の処理から１つの処理に、
情報、用紙などが沢山集まって、沢山の処理をしている部分でした。

　調べると、1つの処理で、複数の処理をしています。いろいろな知識、スキルが
必要な複雑な処理です。１つの処理を複数の処理に分解、マニュアルの用意など
によって、処理の単純化が可能になりました。

　他にも、フローを図として見るだけでも、部門間で処理が行き来している部分、
処理がループしている部分、単純に処理が連続している部分など、図として見た
だけでも、問題の可能性、改善の可能性の発見出来ることが判りました。

　それぞれには、そのような図になる理由、改善の可能性の説明が、常識で考えれば
判ります。

　それから、これらを方法論としてまとめ、業務フロー作成ツールと業務分析方法論
のセットでお客様へ営業しました。方法論とて紹介することで、お客様にスキルを
理解して頂くことも出来ました。

　常識的判断を、順序立ててで説明することで方法論になります。説明されると、
当り前だよなと思われますが、方法論は、特別な魔法ではなく、順序立てた理屈の
積み上げです。

　真面目に解決方法を考えて、組み立てれば何事も解決できます。