業務フロー、整理してますか？
この記事は ウェブクルー Advent Calendar 2018の7日目の記事です。
昨日は@DotaKobayashiさんの「Microsoft Flowで電車遅延のメールを送信する」でした。
私は社内の売上管理・請求明細管理システムを始めとした管理システム系を担当しています。
その中で業務フローの整理の大切さをひしひしと感じたので、その知見をアウトプットします。
また、業務フローを整理するために以下の本を読んで参考にしました。
はじめよう! プロセス設計 ~要件定義のその前に
本記事でもその内容を一部抜粋します。（以下、「参考書籍」）
また、純粋にシステムの実装に係るエンジニアはもちろん、業務システムではないもののサービスの企画から関わるデザイナー・ディレクター、システムを使うユーザーにも有意義な本なので興味がある人は是非。
業務フローってそもそもなに？
業務とは？
そもそも業務とは何なのでしょうか？
これに関しては参考書籍のなかで 「業務とは、商売の実現に必要な仕事の集まり」 と定義しています。
どの会社・組織でもこの定義と大きなズレはないと思うので、本記事でも業務の定義は 「業務とは、商売の実現に必要な仕事の集まり」 とします。
業務フローとは？
上記の業務の定義から、業務フローとはは「仕事の流れ」と定義できます。
ここで大切なのは「業務」を分解して、「仕事」を単一化して考えることです。
私達は慣れている物事を一まとまりに考えてしまいます。
例えば、歯磨きや洗濯をいちいち分解しませんよね。
「歯磨きをする、洗濯をする」と考えるはずです。
ここで料理を例に業務フローを考えて見ましょう。
「味噌汁をつくる」までの業務フロー
ざっくりですが、上記のような流れになると思います。
ただ一言「味噌汁をつくる」といってもここまで分解できます。
ここで注目してほしいのが条件分岐もあれば、並行作業も存在するということです。
さらに「味噌汁をつくる」ことは一人で成り立ちます。
これが「フレンチのコース料理を作る」なら複数のシェフが登場しますし、条件分岐も多くなるでしょう。
そう、仕事が大きくなるに連れ、業務フローは複雑化するもの なのです！
これは今みなさんの目の前にある「業務」についてもおなじことが言えるのではないのでしょうか？
なぜ業務フロー整理するのか？
業務フローについて一定の理解が固まったところで、次に「なぜ業務フローを整理するのか」について考えてみたいと思います。
「業務フローは複雑化する」ことを考えると、なぜ整理するのか待ったなしなのですが、ここはQiitaなのでもう少しエンジニア的観点から考えてみたいと思います。
保守性の観点から
障害時や調査依頼で大切になるのが保守性です。
保守性を担保するにはよく「良い設計」と「わかりやすいソースコード」が大切と言われます。
実際私もそう思います。
ただ、より保守性をより高めるために ソースコードの意図を知るための業務フロー理解が必要 なのではないかと考えています。
ここでは「ソースコードで保つ保守性」と「業務フロー理解で保つ保守性」に分けて保守性について考えてみたいと思います。
ソースコードで保つ保守性
俗に言うきれいなコードを書くことで保守性があがることは間違いないと思います。
ここでは「きれいなコード」の定義や書き方については言及しませんが、きれいなコートを書くことでクラス単位・ロジックメソッド単位での理解が早まります。
業務フロー理解で保つ保守性
とはいえ、「きれいなコード」を書けば確実に保守性が担保されるかと言われると正直厳しいケースもでてきます。
仕様がシンプルで機能が少ないシステムの場合はソースコードだけで担保できそうですが、要件や機能が一定数を超えてきた場合はもっと抽象的な理解が必要です。
システムに対する抽象的な理解において、業務フロー図が役に立ちます。
一機能内、つまりソースコードレベルで連携している箇所はすぐわかります。
しかし、複数機能、異なるユーザーが使う機能との間でデータ連携している場合、それをソースコードから追うのは困難です。
このときに業務フロー図があれば、全体の機能の理解がしやすくなります。
拡張性の観点から
拡張性の観点からいうと、拡張子やすさに関しては設計とソースコードの記載しだいです。
しかし、そもそも「どこに機能を拡張するか？」を考えたときに業務フロー図があると考えやすくなります。
そもそも機能の追加は「ユーザーが使っていて楽になる」ために行うものなので、業務上どこに使われるかを意識することが求められます。
「いつ、どこで、だれが使うか」によって画面構成も機能仕様もデータ構成すらも変わります。
業務フロー図があれば「いつ、どこで、だれが使うか」の理解の助けになるのです。
どうやって業務フロー整備したの？
参考書籍ではマジカという表記法を薦めています。
私はマジカを使わずにフロー整備したので、詳しいことは参考書籍やリンク先を参照してください。
直近の業務フロー整理に関しては以下のように実施しました。
- 業務フロー整理の意図と協力依頼を事前に周知
- ディスプレイとホワイトボードがあるスペースに関係者をあつめる
- 一つの業務に対して、ディスプレイにシステム画面を映しながら、「いつ、だれが、なにをする」に注目してヒアリング。
このとき仕事の単位を強く意識する。一言に「〜する」でも実は細かく分解できる箇所があったりする。 - ホワイトボードに仕事をひとつのコマとして記載し、線でつなげて１業務あたりのフローをつくる。
(1業務あたりのフロー図ができたら私は写真を撮っていました) - ３と４を業務分行い、最後に業務レベルごとのフロー図をつくる。
新規システム要件定義やもっと巨大なシステムの業務フロー整理の場合はマジカやBPMNを用いれば良いと思いますが、ある程度の大きさのシステムならば形式にこだわらなくても整理できました。
え？まだ業務フロー整備していないのにだれかにシステム引き継ぐの？
タイトルで出落ち感でてますが、だれかにシステムを引き継ぐ場合は業務フロー図作成作ったほうがあとで引き継ぐ人が幸せになれます。
想像してみてください。特定の業務で初めて使われる機能があるのに作成者とユーザー以外知らずにいることの恐ろしさを。
想像してみてください。機能のロジックが複雑な上に、インプットされたデータがどのように作られているのがわからない状態を。
想像してみてください。ただでさえロジック複雑なのに調査に速度が求められるときのプレッシャーを。
業務システムを一生面倒見る気がある人だけが業務フロー整備を怠る権利をもっています。
まとめ
前職のSIer時代ではソースがかければいいやと思っていたのですが、今のウェブクルーに入り、色々と至らない点を始め、考えさせられることが増えました。
この業務フロー整理もその一つで最初はシステムを引き継ぐだれかのためにという建前のもと実施していたのですが、やっていくなかで結局は自分のシステムへの理解、システムに対する理解が深まりました。
これが「情けは人の為ならず」というやつでしょうか。
駄文ではございますが、最後まで見ていただきありがとうございました。
明日は@m-hosokawaです。
よろしくおねがいします。