フロー図に時間の流れを盛りこむ

開発には、同時に行える「並列処理」と、経時で行うしかない「直列処理」があるハズです。たとえば、設計と実装は「並列処理」できません。「並列処理」と「直列処理」の違いをきちんと描き込まないと、フロー図を描いても進行管理が難しくなります。

---

前回は、下図のようなフロー図を示しましたが、この中では、現状把握、業務要件、機能要件、非機能要件の見当が同時並行で描かれています。

現状把握、業務要件、機能要件、非機能要件の四つは、時間経過を上から下へと位置で示すとしたら、並行処理として表現されています。

また、それぞれの面積（横幅、高さ）が狭く表現されています。

しかし、この四つの処理はもっとボリュームがあるハズです。同時に進められるとも限りません。次の図のほうが、皆さんの実感に近いのではないでしょうか？

---

時間を縦軸で表現すると、自然と作業のボリュームがイメージできます。

（コーディングを複数人で分割担当するなら、コーディングの部分だけ横幅を広げると、作業の日数とボリュームが伝わりやすくなるでしょう。）

---

上の図をみて直感的にわかることは、現状把握～非機能要求までをPMが担当するとなると、PMの負担が大きすぎるということです。

さらに問題なことは、VBAの開発経験が豊富なPMでなければ、この部分の対処ができないことです。特に業務要件の把握が難しいと思います。

PMにすべての負担が集中する（PL的／PMO的なVBAエンジニアがいない）場合）を図に示せば、次のようになるでしょう。

このため、ありがちなのは、現状把握～非機能要求のまとめを、非エンジニアの事業部門様に丸投げしてしまっている、という状態です。

当然ながら、要求の整理、要件定義に穴が開きます。

そして、その穴は受入テストで発覚し、言った、言わないの大炎上につながります…。

下の図に、そのような状況を示しています。これではダメなのです。

---

言った、言わない、聞いてない。

これは炎上したプロジェクトにありがちな会話です。

しかし本当の問題は、「言ったけど伝わっていない。聴いたけど理解していない。」なのです。

事業部門様に、ツールの解析を行わないまま、自分が気がついてもいない、言葉にもできない部分まで、取りこぼしなく要求として整理することは無理なのです。

また、そんな状態で人様の業務を理解するようPMに望むことも、無理難題です。

オーナー様（事業部門様、システム部様）とエンジニアが相互理解を得るためには、既存ツールの解析と十分な説明が必要です。