すべてのカテゴリ

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