すべてのカテゴリ

開発には、同時に行える「並列処理」と、経時で行うしかない「直列処理」があるハズです。たとえば、設計と実装は「並列処理」できません。「並列処理」と「直列処理」の違いをきちんと描き込まないと、フロー図を描いても進行管理が難しくなります。前回は、下図のようなフロー図を示しましたが、この中では、現状把握、業務要件、機能要件、非機能要件の見当が同時並行で描かれています。現状把握、業務要件、機能要件、非機能要件の四つは、時間経過を上から下へと位置で示すとしたら、並行処理として表現されています。また、それぞれの面積（横幅、高さ）が狭く表現されています。しかし、この四つの処理はもっとボリュームがあるハズです。同時に進められるとも限りません。次の図のほうが、皆さんの実感に近いのではないでしょうか？時間を縦軸で表現すると、自然と作業のボリュームがイメージできます。（コーディングを複数人で分割担当するなら、コーディングの部分だけ横幅を広げると、作業の日数とボリュームが伝わりやすくなるでしょう。）上の図をみて直感的にわかることは、現状把握～非機能要求までをPMが担当するとなると、PMの負担が大きすぎるということです。さらに問題なことは、VBAの開発経験が豊富なPMでなければ、この部分の対処ができないことです。特に業務要件の把握が難しいと思います。PMにすべての負担が集中する（PL的／PMO的なVBAエンジニアがいない）場合）を図に示せば、次のようになるでしょう。このため、ありがちなのは、現状把握～非機能要求のまとめを、非エンジニアの事業部門様に丸投げしてしまっている、という状態です。当然ながら、要求の

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