業務の手順書や説明資料には、冒頭に業務の全体を表す図絵が提示され、各プロセスやフローの解説が加えられているのが通例です。解説がいかに簡潔かつ的確に書かれていても、図絵がなければ完成絵の無いジグソーパズルを組むようなもので、理解に時間を要するだけでなく誤解も生じやすくなります。

筆者が所属するネットワンパートナーズ株式会社セールスエンジニアリング部 第4チーム（通称、TechDesk）では、パートナー企業からの「技術QA業務（チケット対応）」を担当しています。本稿では、この業務をデータフロー図（Data Flow Diagram; DFD）による図示と可視化を2年目メンバーが取り組んだ事例と、筆者がDFDにたどり着くまでの図法の模索について紹介します。また業務を手順ではなく構造で捉え直すための、技術文化的な試みとしても位置付けています。

昔、情報処理教育といえば、JISフロー図の習得が必須科目でした。近年では、JISフロー図が古典的図法になってしまったのか正しく学ぶ機会も少なくなり、見様見真似で雑に描いているドキュメントが散見されるのは残念なことです。

古典的図法とはいえ、JISフロー図は業務の手続きを表現する利便性からいまでも多用されています。またJISフロー図を役割ごとに列で区切って、役割ごとの作業範囲と遷移を表現したものがスイムレーン図であり、こちらも多用されています。およそこの2つが、業務を表現する図法の主流であるといってもよいでしょう。JISフロー図とスイムレーン図の例を図1に示します。

図1　JISフロー図（左）とスイムレーン図（右）の例

筆者がかつて品質管理責任者だった頃、ISO 9001の品質マニュアルを全面改訂したときにも、JISフローチャートを用いました。また、スイムレーン図の役割の列を、前工程と自工程と後工程の縦3段に描き直した独自の拡張ものを工程管理図として併用しました。その工程管理図の例を図2に示します（一部、JISフロー図の記法に反する部分はあります）。

図2　工程管理図の例

ISO 9001で要求されるプロセスアプローチでは、インプットとアウトプットを明確にすることが求められます。これを表現するには、この工程管理図がとても使い勝手がよかった覚えがあります。

しかしJISフロー図及びその拡張の図法で、いかに美しく図絵を描いたとしても、手順はともかく「世界地図を広げる」ように業務全体を俯瞰できる感じがしません。これは、これらの図法に次の特性があるからだと考えています。

• JISフロー図にスイムレーン図を併用しても、役割（誰がやるか）を軸にした表現にしかならない

その後、筆者が人事部で労務人事を担当したときには、業務をより描きやすく説明しやすくする図法として、統一モデリング言語（Unified Modeling Language; UML）のアクティビティ図を採用してみました。UMLアクティビティ図では、割り込み処理及び並行処理、並びにオブジェクトやデータの流れも表現できます。加えて、JISフロー図では処理の流れの表記が一次元（櫛団子）ですが、UMLアクティビティ図だと二次元（縦横展開）で描けるので作画領域を有効に利用できます。これによって、複雑な労務人事の業務をA4 1枚にまとめることができました。

UMLアクティビティ図は、図形がJISフロー図に似ているのもよいところです。業務引継ぎのときに、後任者はこの図法を知らないようでしたが、特段、図法の説明をすることなしにご理解いただけました。参考までに、手順書に描いたアクティビティ図の一部抜粋（全体の約1/4程度）を図3に示します（図中のプロセス名やオブジェクト名などは割愛しています）。

図3　UMLアクティビティ図による業務表現（一部抜粋）

筆者は、UMLアクティビティ図によって業務を見た目にもすっきり描くことに成功し、暫く満足していました。しかし、業務の構造や内部の関係を表現できていないことの課題は残りました。UMLアクティビティ図は、時間軸に沿って処理の順序を表現している点でJISフロー図と本質的に同じであり、当然の帰着です。筆者の中では、表現の限界を超え、かつ平易な図法は無いものかという思いがくすぶり続けることになりました。

筆者が当チームに配属された2022年度の下期に、チケット対応の業務可視化と文書化の一環として、新卒メンバー（当時）に手順書の作成を取り組んでもらいました。チケット対応は、パートナー企業のSE様などからの質問の到着をトリガーに、TechDeskの担当者が、質問を受け付け、内容を確認し、社内ナレッジ及び製品メーカーへの照会結果を取りまとめて回答する業務です。新卒メンバーがチケット対応に従事し、それを文書化してレビューを受けることで、業務をより正しく認識・理解し、文書化スキルを高め、さらに成果物（手順書）を得るという、「一粒で何度もおいしい」ところを狙ったものでした。そして毎年度の新卒メンバーが手順書を加筆・修正することで、維持・管理を行ってきました。この手順書は、図絵を指で追いつつ解説を読めば、初任者であっても一連の業務ができるようにまとめられているものです。

話は若干戻りますが、この手順書に含める図絵は、（筆者の図法模索への思いは一旦横に置いておいて）JISフロー図で描くことを想定していました。そこでは正しい図法で描いてほしいので、JISフロー図の教育を行いました。2023年度には、1年目と2年目のメンバーに個別講座を、続く2024年度と2025年度には、入社・配属直後の「新卒OJT」のカリキュラムで、JISフロー図とスイムレーン図の講義をそれぞれ行いました。スイムレーン図の講義では、描画力をより高めるために、「参考図書の事前申請及び購入、並びに経費精算」の社内手続きをスイムレーン図で描くワークを設けました。スイムレーン図では、レーン（列）に役割を適切に割り当てることが鍵です。まだ会社制度に疎く、通り一遍の説明を聞いただけの新卒メンバーにお手本もなくこれを描いてもらうのは、かなり難易度の高いことでした。しかしあえて鬼教官として(笑)、ハンズアウトが提出されるたびにあちこち「ケチ」をつけて何度も書き直させました。研修でしっかり学んで自身が正しく描けるようになってこそ、他者の描いた図絵の良し悪しを論評できるようになるというものです。

なお、図1（右）のスイムレーン図は、先の研修の回答の例です（図中の処理名などは割愛しています）。

あるとき、チケット対応をJISフロー図のように一連の手順としてでなく、各プロセスで情報を加工していく動きとして眺めていました。そうすると各プロセスは、インプットの情報が使用可能になった段階で処理を行うデータフローアーキテクチャとして見立てられることに気付きました。アーキテクチャがデータフローであれば、図法はDFDの一択です。DFDの登場は古く、1970年代前半〜中頃に体系的に提唱・普及されたものなので、JISフロー図と同じ古典的図法かもしれません。いまどき見かける機会は情報処理試験の準備で学習するときくらいでしょうが、ここでDFDに「再臨」してもらうことにしました。

DFDで扱う要素は、プロセス、データストア、外部エンティティ及びデータフローの4つだけです。この数学の公理のように原理的なところが、とても気に入っています。要素の図形は記法によって異なりますが、今回採用したヨードン・コード（ヨードン・デマルコ）記法では図4の例のとおりです。

図4　ヨードン・コード記法によるDFDの例

データフローアーキテクチャを食品工場でイメージすれば、入荷した枝肉が搬送機で工場の各区画（プロセス）間を通り抜けていくうちにハム・ソーセージになって出荷されていく感じでしょうか。

筆者の構想がまとまりつつあった頃、いまの2年目メンバー（技術8名）向けの「新卒OJT」では、都合、JISフロー図やスイムレーン図の図法の講座を持てなかったことを思い出しました。その代替及び上級コースとして、「DFDの学習と業務可視化の実践」とする短期課題として取り組んでもらうことにしました。2年目メンバーはチケット対応の業務経験があるので、自業務の現状を図絵で表現し、そこから改善を見出す目線を持つことは有意義だと考えています。また良い図絵を描こうとするあまり、事実を曲げて図絵を美化してしまう危険もあるので、レビューの場でそれを含めて点検していくことにしました。課題提示の資料（抜粋）を図5に示します。

図5　課題提示の資料（抜粋）

課題提示では、DFDの記法とJISフロー図及びスイムレーン図の限界の解説、並びに工程管理のためのガントチャート表記の例を提示した程度です。2年目メンバーにとって各種図法は初めてのものでしたが、いまどきは「詳しくはWebで！」の時代であり、もう新入社員ではないので「説明でわからないところは自分で調べる、わからなければ後で聞く」という業務姿勢で臨ませました。

なお、2年目メンバーの1人が、この課題を手掛けた側の視点から次のブログ記事を寄稿しています。そちらもご覧いただければ幸いです。

２年目メンバーと何度かレビューした後に、DFDが出来上がってきました。オリジナルの成果物は、本記事のアイキャッチの写真がそれです（一部を撮影）。図6は、2種類あるチケット管理システムのうち、会員制ポータルサイト（NOP TECH INFO; NTI）を使用する場合のものを、本稿の掲載用に整理したものです（スペースの都合、データフローの説明を省略しています）。

図6　チケット対応のDFD（NOP TECH INFO版）

通常、1枚のDFDに置くプロセスの数を7つ以下にする暗黙のルールがありますが、前述の「世界地図を広げる」ように業務を俯瞰するには1枚に収める必要があり、現状の10個を許容しています。また、外部エンティティの右下の “*” 、データストアの左側の “縦二重線” は、それらが別の場所にあるもののコピー（再掲）であることを示しています。

図6を俯瞰すると、チケット対応をポータルサイトで扱っているとはいえども、舞台裏で多くのプロセス（ほぼ全て手作業！）が動いていることがわかります。TechDeskのメンバーが「力ずく」で業務を回している姿が見えてきます。

成果物としては、DFDのほか、データストア及びデータフローで扱う情報の「データ辞書」と、各プロセスの「ミニ仕様書」があります。また各プロセスは、サブプロセスに分解するほどの階層構造と複雑さを持たないので、ミニ仕様書での説明だけでよいことにしました。データ辞書とミニ仕様書の抜粋を、それぞれ表1及び表2に示します。

表1　データ辞書（抜粋）

表2　ミニ仕様書（抜粋）

なお、図6中に「KANBAN」とあるのは、TechDeskでチケット管理方式にKANBANを導入していることを示しています。詳細はこちらの記事をご覧ください。

初回のレビューでは、2年目メンバーが結構まともなDFDを提出してきたので、ちょっと驚きました。 DFDは記述が限定されていて曖昧さが許されないので、論理的に煮詰めないと図絵になりません。そもそも2年目メンバーがDFDを描けたこと自体が奇跡に近いことですが、若手メンバー8名が集まって「文殊の知恵」を駆使した証でしょう。

そうはいっても、レビューではプロセスやデータストアの抜け漏れを何度も指摘することになりました（予想の範囲でしたが）。これは、人間が業務を順序で覚えていて構造を理解していないことに起因するものです。「チケット処理とは、どういう業務ですか。」と問われると、担当者でもつい手順に沿った説明をしてしまうのは、それゆえのことです。こうして、レビューで抜け漏れを指摘されて気付くことを通じて新卒メンバーは、「構造で世界を見る回路」を頭の中に組み立てられて「理解が深まる入り口」に立てたのではないでしょうか。

さて、図6の各プロセスですが、実際の業務ではおよそ次のような形で動いています。

• 処理は独立している（担当者が1人とは限らない）
• データが揃うと処理を始められる（イベント駆動）
• 処理は状態ではなくデータの流れで決まる
• 複数の処理が並列で進む

これらはデータフローアーキテクチャの特徴そのもので、業務も状態遷移ではなくデータの流れが本質であることがわかります。こうして業務をDFDで描くと、普段は見えにくい構造（に依存する部分）が可視化されます。たとえば、次のようなものです。

• ボトルネック
• 属人化
• 並列化の可能性
• 自動化の可能性

きっと2年目メンバーにも、「このプロセスを分割したほうがいいのでは」とか「データストアを整理できないか」とか、又は「データフローの接続先を変えて短縮できないか」とか、DFDを見ているだけで業務の改善の方向性が自然に頭の中に湧いてくることでしょう。…と思いながら本課題の成果物の完成報告会に臨んだら、まさに的を射た改善ポイントを挙げてきたので感動したところです。

ここで筆者が、業務に慣れてきた2年目メンバーにDFDを描かせた意義について整理しておきます。もちろん、優れた図法を学んでほしいという思いがありますが、次に挙げる物事の見方の初歩が身に付くことを期待しています。

• 部分ではなく全体
• 順序ではなく構造（例： 原因と結果； 因果）
• 要素ではなく要素間の関係
• 手順ではなくそうする意味

2年目メンバーも近いうちに視野や視座を問われる中堅社員になります。これらを身に付けることに苦慮している姿を散見します。「会社人」の初手のうちに、対象を図絵で表現し、前述の4つの見方で問えるようになることが、視野や視座の強化のための一つのアプローチになるはずです。

業務改善のアプローチである、「①構造化→②可視化→③最適化」のうち、今回のDFDの完成によって①と②が完了しました。続いて、各プロセスの内外製分析及び機械化（AI処理を含む）を検討していけば、③まで進められます。ただし、これによってTechDeskの裏方のプロセスが全て機械化されたとしても、フロントエンドは人間であってほしいと思います。これは、世の中のチャットボットに対する一般的なアンチテーゼに加えて、「チケット対応での差別化及び価値創造の場は、パートナー企業のSE様ほかとTechDeskメンバーが直接向き合うヒューマンコミュニケーションである」と筆者は考えているからです。

以上、業務の可視化についてDFDに至るまでのアプローチを紹介しました。課題を企画している頃、DFDをうまく初心者に説明するための資料がないものかと、あちこち検索していまいした。そうしたら世の中には同じようなことを考えて、なんと2025年に書籍を出版されている方がいらっしゃいました。これを2年目メンバー向けにDFDの描き方の教科書として採用させていただいたので、ここでご紹介しておきます。

大嶋 和幸、松永 守峰 著

翔泳社

データフローダイアグラム いにしえの技術がもたらすシステム設計の可能性

ISBN： 9784798189338

世界や場を説明するために図法は重要です。「場」を説明する優れた図法と言えば、電気工学出身の筆者には電磁気学の父と称されるファラデーの磁力線や電気力線の表現が思い浮かびます。これらはマクスウェルらがその構造を高度な数学を用いて定式化しましたが、それによらずとも誰しも直感的に理解できるのが図絵の素晴らしいところです。世の中には先人による優れた図法が数多くあるので、図法の適用分野に限らず応用・流用してみるのも面白いでしょう。本稿が、業務の構造を図絵で可視化するための一助になれば幸いです。最後までお読みいただき、ありがとうございました。