VBAツール開発、特にレガシーツールの改修は、ほかのツール開発とは異なる特徴があります。
「既存のツールが現状把握、業務要件と直結する」ことが多い点です。
比較のために図を示すと、一般的な開発の役割分担は次のようになるでしょう。
お客様のニーズをPM／PMOチームが把握し、事業部門様／システム部様を支援しながら、要件定義書をまとめていきます。
ところが、VBAツール、特にExcel VBAツールの改修では、SE／プログラマーがもっと早い段階から関わる事例が多くみられます。
これは、現状把握、業務仕様、機能要件、非機能要件（UI設計など）のために、既存のVBAツールの解析が必要となるためです。
いわゆる「属人化」したVBAツールでは、事業部門様がすべての業務内容、処理内容を把握できていない事案が少なくありません。
このため、VBAツールを解析し、事業部門様（非エンジニア）、システム部様（エンジニア）を支援するには、次のような体制が必要になる場合があります。
SE／エンジニアが、事業部門様、システム部様と直接、要求整理・要件定義についてコミュニケーションをとる方法です。
VBAツールの開発者について、「一気通貫の開発が可能」「一人称で、顧客との折衝が可能」といったご要望を見かけるのは、こうした理由からだと考えております。
これを、WBS風に分解して書けば、次のようになると思われます。
VBAツール開発で望まれるエンジニア。
１）既存ツールを解析できる。
２）既存ツールの現状を、非エンジニアの事業部門様に説明できる。
３）既存ツールの課題を、エンジニアのシステム部様に説明できる。
４）業務要件、機能要件、非機能要件を、PM／PMOと相談できる。
VBAツールは（独自の）業務ルールと直結している場合が多く、上記の１）～４）が望まれます。ここで失敗すると、受入テスト（UAT）で問題が露呈し、プロジェクトが炎上してしまいます。
さらに、次のような能力が望まれます。
５）仕様書作成、基本設計（外部設計）、詳細設計（内部設計）ができる。
６）処理速度対策、UI効率化を盛り込んだコーディングができる。
７）テスト計画作成、テスト報告書作成ができる。
８）UATへの対応ができる。
９）運用支援、必要であれば修正も対応できる。
５）では文書作成能力が、６）では応用的なコーディングが、９）ではコミュニケーション能力が必要です。
以上のように考えるとVBAツール開発者は、色々なポジションに対応できる「ユーティリティプレイヤー」でなくてはいけません。
開発言語としてのVBAは、比較的容易です。
しかし、VBAツールの開発（改修）では、業務把握のためのコミュニケーション能力や、文書作成能力など、「一気通貫の開発が可能」な人材が必要になります。
「ユーティリティプレイヤー」としての課題について、次回にお話ししたいと思います。
ここまでお読みいただき、有り難うございました。
