イチから全部作ってみよう（23）業務フロー図があれば“伏魔殿”も理解可能に：山浦恒央の“くみこみ”な話（192）（2/3 ページ）

ソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」。第23回は、円滑なソフトウェア開発に向けて発注側と開発側が相互に歩み寄るために生まれた業務フロー図について説明する。

[山浦恒央 人間環境大学 環境情報学科 教授（工学博士），MONOist]

3.2.3 業務の共通認識を共有できる

　銀行業務におけるATMでの現金の引き出し処理は、ソフト開発側にもある程度は理解できますが、少し専門的で複雑になると理解できません。例えば、銀行の投資部門の業務として以下のような記述があったとします。

　日経225のような対象インデックスが上昇すれば、AP（Authorized Participant）は、対象となるETFの原資産（指数に連動する株式）をあらかじめ決めた割合で購入し、主催者に提出してETFを新たに生成（Creation）することでETFの株価を上昇させる取引を実施し、逆に、対象インデックスが下落すれば、対象ETFを市場で買い付けて主催者に返却し、原資産に戻して償還（Redemption）させ、株価を下げる方向の売却を実施する。また、市場価格とNAV（基準価額）が乖離した場合、APがアービトラージを実施して、利ザヤを取りながら乖離幅を縮小させる。

　開発歴10年のプログラマーでも、上記が何のことか理解できる人は少ないでしょう。逆に、銀行側のスタッフには以下のようなシステム内の動作は分かりません。

　実行中のプロセスよりも優先度が高い割り込みを検知した場合、そのプロセスを生成して待ち行列に入れると、ジョブスケジューラにより実行中の低優先度のプロセスは実行待ち状態に遷移し、高優先度のプロセスがCPUとメモリを独占して処理を実行する。ただし、実行中のプロセスが資源の一部を既に占有し、別の資源の排他制御のためセマフォの待ち行列に入っていて占有待ち状態の場合、待ち行列内の優先度を最大にして処理を終わらせてから、高優先度のプロセスを生成する。

　日常利用しているサービスは簡単に見えますが、実は非常に複雑で、タクシーの配車管理、新幹線の運航制御、スーパーマーケットの在庫／発注処理、エレベーターの運行管理など、どれもプログラマーにはものすごくディープな「発注側の業務の世界」です。一方、発注側には、システム内の動作は何とも複雑怪奇で「伏魔殿」と同じでしょう。開発側は発注側の業務を、発注側はシステム内での処理の流れを理解しようと歩み寄ります。両方がぶつかってできたのが業務フローです。業務フローを記述することで、発注側と開発側が共通認識を持つことができます。

3.3 記述方法

　業務フロー図の記述方法は、フローチャートを担当別に記述します（図3）。

　図3は業務フローの記述例です。下記に、簡単な書き方を説明します（表1）。

表1　業務フローの書き方［クリックで拡大］

　このように、担当別のフローチャートと捉えていただければOKです。