VBAのエンジニアは開発の早い段階から、事業部門様、システム部様と関わる必要があると、前回まででご説明しました。
現状把握、機能要件のまとめの段階から、既存のツールの解析や、事業部門様（非エンジニア）への説明が必要と考えられるからです。
しかしまた、そうしたオーナー様への対応はPMにお任せして、サポート役に徹する、という下図のような考え方もできます。
リスクマネージメントや、ナレッジマネージメントを主目的として、PMに向かって情報を提供する、という意味合いが強ければPMOと考えるとよいと思います。
逆に、技術的な問題点や解決手法の統一を主目的として、プログラマー／コーダーに向かって情報を提供する、という意味合いが強ければPLと考えるとよいと思います。
ところで、ここまで３種類のフロー図（構成図）をご覧いただいています。
「私のイメージは、最初の図だったな」
「いや、3番目の図が一番しっくりくるな」
「２番目がいいけど、一ヶ所、直したいところがある」
そんなご感想はなかったでしょうか？
「いや、全く違う。大幅に変えたい。私ならこうする！！」
そう思われた方もいらっしゃるでしょう。
お伝えしたいことは、それが、それこそがフロー図の効果だ、といういことです。
役割がイメージできる。
イメージできるから指摘できる。
賛成もできる。
改善点を指摘できる。
自分の意見と何が違うか、自分の意見を言いたくなる！
それこそが、フロー図（図案化）の効果なのです。
立場によって、メンバーの力量によっても、適切な図は変わってきます。
エンジニアのコミュニケーション能力が高ければ、オーナー様は直接の話し合いをご希望されるでしょう（前回の図）。
PMのコミュニケーション能力が高ければ、その逆も起こりえます（今回の図）。
プロジェクトの時期によっても、適切な図は変わってきます。
開発初期には、リスクの洗い出しのためにPMO的な役割を求められるかもしれません。
開発中期からは、実装の解決のためにPL的な役割が良いかもしれません。
「この図で言えば、この要素が大きくなってきたね！」
「わかった、この図にはフィードバックの導線がないぞ！」
そんな「共通理解」の下敷きが、図表化なのです。
皆様のプロジェクトのお手伝いになれば幸いです。
ここまでお読みいただき有り難うございます。
