この記事はマネーフォワードアドベントカレンダー2021🎄の8日目の記事です。　みなさんこんにちは！HRソリューション本部でQAエンジニアをしている筑後です。私は2021年9月にマネーフォワードに入社し、品質の可視化に取り組んでいます。

今回はその取り組みの中で、一番はじめに実施した開発プロセスの可視化にPFD（Process Flow Diagram）を使ったお話をします。

はじめに開発プロセス可視化のススメ

「品質」とは目に見えないものです。それを可視化するためには、不具合数、顧客満足度、売上、VOC（Voice of customer）…など様々な指標を検討することが必要です。これらはそれぞれのステークホルダーと入念に話し合って基準を決めた上、どのような評価手法を用いるかを検討しなければならないですが、それは非常に時間がかかると思っています。

そこで私は、まずは開発プロセスを可視化することから始めるのが良いと考えています。

（参画したばかりの立場として）開発が始まってリリースするまでの全体の流れを把握することができる
製品の不具合やプロジェクト上の課題が出てきた際に、それは具体的にどこで発生したのかを認識のズレ無くマッピングできる

まずは開発プロセスを可視化することで、開発〜リリース〜改善の活動を回しながら、一方でより上位の品質についての議論を継続することができると考えています。

PFD（Process Flow Diagram）とは

主に派生開発の現場で使われているプロセス設計のための表現手法で、インプット・アウトプット・作業を分けて表記するのが特徴です。

この手法が生み出された経緯や詳しい書き方は、提唱者の清水吉男氏の著書やスライドを参照いただきたいですが、大きなメリットは以下のとおりです。

成果物（インプット・アウトプット）と作業の両方を1枚で見ることができるので、ステークホルダーとの認識合わせがしやすい
ルールがシンプルなので、大きな教育コストを費やさずに作成、閲覧ができる

つまり、こんなの作ってみましたよ〜と持って行ってすぐ皆が使うことができて、お互いの認識が合っていない成果物や作業があるかも分かるのです！

PFDを使いたい理由

実は以前は、開発フローを表現する際には一般的なフロー図を使っていました。しかしこんなことが起きました。

私（QA） ：「今回流出してしまった障害ですが、テスト結果はどうなってました？」
テストT ：「テストケースの期待値は設計書通りでした。設計書の記載が間違っていたのでは？」
私（QA） ：「開発チームさん、設計書が間違っていた可能性があるので確認をお願いします！」
開発T  ：「設計書は合ってました。テストケースに起こすときに間違えたのでは？」
私（QA） ：（謎が謎を呼ぶ…）

この謎を調査したところ、テストチームが期待値として参照した値は、レビューを通っていない、開発者個人が作った資料だったことが判明しました。

つまり、通常のフロー図で表現すると以下のようになり、ステークホルダーの認識にズレはありませんでした。