こんにちは。つい最近まで IoT 向けのクラウドアプリ開発を担当していた いとけん です。

 

以前このブログで、プロセス改善ツール「PFD」知ってますか? という記事を書きました。その記事では「プロジェクトの課題管理」に着目して、プロセスを改善した事例を紹介しました。
今回は「運用プロセスの可視化」に PFD (Process Flow Diagram) を使った結果、予想以上に短時間で各チーム間の共通認識ができ、その後の開発・検証効率が良くなった事例を紹介したいと思います。

業務プロセス (⊃運用プロセス) の表記法には FlowChart や BPMN、Actibity 図など様々なものが有りますが、今回のプロジェクトではデータの種類の多さがトラブルの素になっていたため PFD を使ってまとめました。
PFD は DFD から着想を得て作られた記法で、成果物(やデータ)に着目しているためゴールの姿を描きやすいのが特徴です。多種のデータを取り扱っていても、ダイアグラムの特性上(※1)、取り違えが起きにくいのも利点の一つです。
(※1) 同一のデータは1つのオブジェクトで表され、複製する場合もID番号を振るため一意に特定できる。

PFD の表記法については、前述したブログや書籍「プロセスを自在に設計する─PFDを使いこなそう─」も出しましたのでご覧いただければと思います。

とあるプロジェクトでの課題

私の参画していたプロジェクトは、アジャイル的に必要最低限の機能を必要最低限の設計書で開発しようとしていました。
しかし「必要最低限の設計書」があらかじめ定義されている訳ではないため(※2)、しばしば「必要になった時に設計書を書く」という状態になってしまい、開発が4チーム構成であることも相まって、各チーム間での認識齟齬や課題解決のための会議、日程調整が頻繁に発生していました。
 (※2) アジャイル開発の場合は将来を予見しづらいので、あらかじめ定義したところで同じ問題が発生するとは思いますが…

そろそろ結合テストに入ろうか、、、という時期でも同様の問題が発生しました。
予定していた全ての機能は入りきらなかったため、以下のような機能削減が行われました。

  • 使用頻度の少ない一部の機能について WebAPI 経由でデータ投入する予定が、運用者の手作業(DB に直接書き込む)にする
  • 運用者向けの Web コンソールの作成が省かれ、開発者用の DebugTool を転用する

その結果、運用手順書(≒結合テスト仕様書)に「どのデータをどこに設定するか」などを詳細に記述する必要が発生しました。しかし、当初は運用手順書を文章だけで表現しようとしていたため、データの関連性が掴みにくく、運用者のデータ選択ミスが頻発してしまいました。

どんな PFD を書くか

PFD はシンプルで理解が容易であるという特徴がある半面、登場人物が増えると役割分担や責務が「ひと目」では分かりにくくなってしまう問題があります。
今回のシステムは、複数のユーザー・複数のマイクロサービス・IoTデバイスが登場し手順も多かったので、何の工夫もなしに PFD を書いてしまうと以下のような問題が発生することが予見できました。

  • 登場人物の多さから、責務が判りづらくなる
  • 手順の多さから、PFD が巨大になってしまい、視認性が落ちる
  • 巨大化対策として PFD を階層化すると、重要なデータが PFD の下位層に隠れてしまう

せっかく図表を使うのですから、直感的に理解(短時間でチーム間の合意形成を)したいです。

そこで、少しだけ PFD を拡張することにしました。

  • 責務が分かりにくくなるので、スイムレーン(アクター毎に区切り線を入れること)を導入する
  • 手順は多いがあえて階層化は行わずに、(スイムレーンと垂直に)作業フェーズ毎に区切り線を入れる
  • 横長の図だと補足事項が見づらくなってしまうので、縦長の図とする

直感的には、スイムレーンの付いた Actibity 図を思い浮かべると良いかもしれません。

実際に作った PFD (のイメージ)

実際のプロジェクトで作成した PFD(※3) は出せないので、かなりデフォルメしましたがイメージとしては下図のような感じです。
簡単に凡例を記しておくと、帳票記号=成果物(データ)、丸記号=プロセス、矢印=データの流れ(両矢印はデータの更新)、帳票記号内の「*」が複製(同一の成果物が複数個所に記述されている)です。任意でコメントも付けて良いです。
(※3) 実際は1枚の PFD に、スイムレーン(列)6個、作業フェーズ(行)12個を収めました。成果物もプロセスも各50個以上。

PFD を見るのは初めてだ!という人も多いと思うので、上のダイアグラムについて少し解説します。

基本的な読み方
例えば「P1-1.ユーザを登録する」に着目してみると、このプロセスはサーバーの仕事で、インプットデータは「D1.メールアドレス」と「D2.パスワード」であり、アウトプットデータは「D3.ユーザー情報」と「D4.ユーザID」であることが直感的に分かります。

今回のようにスイムレーンを追加すると、プロセスに主語を書かなくても責務が明確になるので、オススメです。

PFD のルール
PFD には、2つの原則となるルールがあります。

  1. 成果物で始まり、成果物で終わる。(プロセスで始まらない、プロセスで終わらない)
    インプット(成果物)の無いプロセスは何も出来ませんし、アウトプット(成果物)の無いプロセスは何もしていないのと同じですね。
     
  2. 成果物とプロセスを矢印で繋ぐ。(成果物どうし、プロセスどうしを矢印で繋がない)
    何もしていない(プロセスが無い)のに成果物が変化したら、それは事件ですね。プロセス間は矢印を繋ぎたくなってしまいますが、1.の通りアウトプットの無いプロセスは無いという考え方です。

高速に理解するために…
しかし今回、このルールを逸脱している箇所があります。P2-1→P2-2 と P3-1→P3-2 が該当します。
P2-1→P2-2 を例に取って説明すると、P2-1.で「ツールでデータを暗号化する」ので、P2-1 と P2-2 の間には「暗号化されたデータ」という成果物(≒データ)があるべきでが、あえて省略しました。なぜなら「暗号化されたデータ」と書かれても、どんな作用があるのかひと目で分からず冗長な記述(※4)になるだけだからです。
(※4) 今回のシステムは、全ての API が暗号化されているため、P1-1 や P1-2、P3-2 へのインプットも、暗号化プロセスと暗号化データを足さなければならず、冗長なうえに可視性が落ちる。

定義書の作成も省きました
本来の PFD では、成果物定義書 (DFD におけるデータ辞書) と、プロセス定義書 (DFDにおけるミニ仕様書) も書かなければならないのですが、今回はその他の設計資料(※5)を参照することで明確になるため、ダイアグラムの右側に補足事項として記載するにとどめました。
 (※5) 成果物定義は、ER 図や JSON Schema が代替になった。プロセス定義は、DebugTool の Readme が代替になった。

全チームでこの PFD を共有した結果

  • ひと目で伝わった

まず、記法の説明はほとんど行わない状態でこの PFD を説明して、ほとんどのメンバーが理解してくれました。そして、私の認識の誤り (記法ではなく意味的に) の指摘もその場で出てきて、ブラッシュアップが完了しました。(私も自分の担当箇所とその周辺しか正しく理解していなかったので、ここは違う・こうなっているなど、指摘や加筆もしてもらえました)

  • ほぼ初見のメンバーでもメンテナンス可能だった


次に、私が担当していない箇所で仕様変更が発生した時に、私以外の別メンバーがこの PFD をメンテナンスしてくれました。
ほぼ初見で、メンテナンス可能であることも PFD の特徴なのだなと思います。
  • 合理的な手順の入れ替えが容易だった


上記のデフォルメした図だと順序の入替えは困難なのですが、実際に作成した PFD では、「あのデータはこのタイミングで使用されるから、その手順は先に実施しても何ら影響がない」など、
完成した部分から順々に結合テストを開始することができるようになりました。
また、影響範囲の特定が容易になったため Bug 発生時も再テストの範囲が小さくなりました。

おわりに

純粋な PFD にスイムレーンとフェーズの分割線を入れるという小さな工夫を加えることで、業務プロセスも難なく記述でき、大きなプロセスでも可視性を損なわずに表現できることが分かしましたので、是非みなさんにも PFD を活用してみて欲しいなと思います。

今回作成した PFD は、記法の正しさよりも「直感的に伝わること」を優先して書きました。
なぜなら、各チーム間での認識が一致せずミスが頻発していたため、なるべく早く技術者間での「共通認識」を作ることが重要だったためです。その結果、PFD のルールから逸脱した方が良いケースも一部出てきましたが、目的は達せられたと思います。
今後は、どのようなパターンの時であれば逸脱しても問題が無いか(無秩序に逸脱するのは良くないので)探ってみたいと思います。