前回のブログで、VBAツールを改修するには、「ユーティリティプレイヤー」なエンジニアが必要と説明しました。
今回はその件をもう少しお話ししたいと思います。
サッカーの解説で、フォワードよりなMF、ディフェンスよりなMFという表現を聞いたことがあると思います。
VBA開発のエンジニアは、こうした「ポジションの調整」を自主的に行う必要があります。
オーナー様（事業部門様、システム部様）の要求整理、現状把握が難しければバックアップに走ります。
また、同じチームのプログラマー、コーダーの開発力が不足していれば、開発手法の相談にのる必要があります。
開発チームのメンバーはもちろん、プロジェクトに関わるPM／PMO、オーナー様である事業部門様／システム部様、さらには、対象となっているツール自体の難易度に合わせて、立ち位置を調整するのです。
一番問題となるのは、下の図の濃い黄色の部分です。
開発では、「事業部門様が要求を整理できないから、エンジニアは集めたけれどプロジェクトが動かないまま。」という事態がたびたび発生します。
このとき、事業部門様は独りぼっちで頑張っている、という状態です。
（本来なら非エンジニアである事業部門ご担当者様には難しい作業です。）
エンジニアによるサポートが必要です。
現状を説明したり、言語化できないご要望を、ヒアリングを通じて一緒に読み解く作業が必要なのです。
また、Excelを用いたツールでは、非機能要件が重要となる場合があります。
商品コードが入力されたら、商品名をマスターシートに自動で参照に行く、といった機能があると、事業部門様はそれがVBAで実装された機能であっても気がつかない場合があります。
「使い勝手」は、作業効率化のための重要な要素ですが、非エンジニアの方には、要求として書いてよい事項のか、はっきりわからないようです。
Excelは、誰もが使っているアプリケーションです。
だれでもわかるツールのように思われがちです。
しかし、その動作にVBAのコードが必要か、セル関数だけで良いかは、エンジニアでなければ判断が難しいものです。
ぜひご相談いただければと思います。
ここまでお読みいただき有り難うございました。
補足
基本設計（外部設計）は、操作方法を決めていく作業ですが、Excel VBAでは特にむつかしい課題です。
Excelのワークシートは、DBのテーブルのようでいて、直接入力も可能です。（DBMSではテーブルへの直接入力は推奨されません。）
実際、Excelのワークシートはたびたび「入力画面」として使用されます。
混乱が起きないように、ワークシートの使用方法に、明確なポリシーが必要です。
このためには、現状把握、業務要件の段階から、きちんと分析し、方針を立てておく必要があります。
VBAのコードが書けるだけの「初心者エンジニア」には難しい作業と思います。
