業務フローについて思うことをまとめようと思います。
体感として、存在しないか、存在していたとしても「何のために作るのか」が理解されないまま、それっぽい資料を作って終わっている場合が多いように感じます。
業務フローの目的
要件定義での役割
ユーザーが業務を整理する
暗黙知になっている情報を見える化する。
関係者の中で業務の流れの共通認識をつくる。
業務のどの部分をシステム化するのか見当する元ネタ
ここで検討した結果、機能一覧が出来上がる。
設計での役割
開発メンバー間で各機能のつながりや順序を共有
全体の流れを把握してるメンバーと、自分が担当してる機能しか把握してないメンバーでは品質にかなりの差がでてくる。前後関係を理解して開発したほうが、結合テストやシステムテスト、運用テストでのバグが少なくなる。
テスト工程での役割
シナリオテストの元ネタ
業務フローをもとにシナリオテストを作成する。
業務フローに、扱うデータの種類、設定、確認したい観点に沿った期待結果をつけてやれば、シナリオテスト仕様書が完成する。
稼働後の役割
機能間のつながり、機能を動かす順番を入れ替わった保守担当者に理解させる
設計での役割と同じ。
業務フローの基本要素
- 四角:業務等の作業の塊をあらわす
- 矢印:複数の四角のつながりと実施順序をあらわす
- 菱形:条件分岐をあらわすひし形
視点の異なる2つの業務フロー
個人的にシステム開発においては、以下の2種類の業務フローが必要だと考えている。
- ユーザー視点のフロー
- システム視点のフロー
「ユーザー視点のフロー」とは
一般的に言われている業務フローのこと。
ユーザー視点で記述する。
普段行っている(または行おうとしている)業務を整理し、システムにどんな機能が必要が洗い出していく。
業務フローの四角(作業)を機能に落とし込んでいくので、きちんと資料を作れば、機能一覧の機能IDと業務フローの四角(作業の塊)は紐づけられるはず。
ユーザーテスト時には、この業務フローをもとにテストを行っていく。
「ユーザー視点の業務フロー」は2~3階層ぐらいあると良いと思う。
1.第1階層 全体
この段階ではスイムレーンなしで、四角と矢印だけで業務全体のつながりが把握できるように記載。
1つの四角が入荷、出荷ぐらいの粒度。下手に資料を分割せず、大きな紙1枚におさめるようなイメージで全体が見渡せるように記述する。
2.第2階層 各業務
第1階層の業務フローで定義した1つの四角の詳細を記述するイメージ。
各部署や担当者間のつながりや作業順序を明らかにする目的。
この階層のフローでは部署や担当者ごとのスイムレーンを設けて、各スイムレーンに四角を配置していく。
3.第3階層 各業務詳細
第2階層で部署間の連携を定義した場合、同じ部署間で担当者ごとに作業が分かれているなら、さらに詳細にしてフローを用意。
第2階層、第3階層の段階で、システムを利用する業務なのか、システムを利用しない業務なのかをわかるようにしておくとよい。(四角の線を太くする、背景色を変える、ディスプレイっぽいアイコンを配置する等。)
この業務フローをもとに機能一覧が作成される。
本来はユーザー側で作るべき資料。エンジニアとしては、新規システムで何を作ってよいかわからない。
システム視点のフロー
「ユーザー視点のフロー」までは、あきらかに「業務フロー」だが、エンジニア目線で話す人はこっち側のことをいってることもある。システム側なので「システムフロー?」かとも思うが、システムフローで検索すると、もっとPGよりのフローがでてきてしまう。「業務フロー(システム目線)」とでもいうのだろうか。。。
マイグレ案件でぶち当たる「この機能はどうやって使うのかわからない」問題。
大抵のプロジェクトでは、機能一覧はある(メンテナンスされてるかは別として)が、業務フローがないので、どの順番で機能を動かしていけばよいのかがわからない。
記載してほしい情報を、重要度の高い順番に記載していく。
1.機能を実行していく順番
「ユーザー視点の業務フロー」から、ユーザー業務の四角をなくしたようなイメージ。
機能名が記載された四角の実行順序が、矢印や分岐を使って記述されている。
2.関連システムのスイムレーン
連携している外部システムがあるなら、どのタイミングでどの外部システムと連携するのかがわかるように記述しておくとよい。
外部連携システムテストの元ネタにもなる。
3.機能の業務的意図、操作方法、期待結果
マイグレ案件を担当していると、「これなんのためにやってんの?」となることが多い。
業務的な意図と、そのためにどういう操作をするのか、そしてどういう結果を期待しているのかを記載してほしい。機能改修時に、ただの間違いなのか、意図してそうしたのかわからない仕様の判断材料になる。
業務フローというよりは、各機能ごとの設計書に記述してあるとよい。
(大抵の設計書ってコードから読み取れる情報しか記載されてないので、イマイチだなぁといつも持ってます。)
ex)記述例
業務意図
翌日の入荷に備えて、倉庫の配置整理をしたり、作業員の手配を計画する。
そのために必要な情報を検索し、表示された情報を帳票として印刷する。
操作
検索条件に翌営業日を入力し、検索ボタンを押下する。
一覧表示後、全件、または任意のデータを選択して、選択したデータの一覧を帳票で出力する。
期待結果
検索条件に合致したデータが表示される
選択したデータが帳票に出力される
4.参照テーブル、更新テーブル
データの流れがわかりやすいように主要テーブルへのアクセス。
各機能の設計書みればよいので、個人的にはどっちでもよいかなぁ。
コメント