社会人の途中でプログラマーになる方が良いこともある
VBAは業務アプリケーションの開発言語だ。
（VBAでゲームを作ることも可能だが）
などがVBAで求められるシステム要件だ。
要するに、多くの場合で、すでに存在する業務を人力をやめシステム化することが目的となる。
すでに存在する業務なのだが、客観的にその業務の全容を見える化することが意外と難しい。
次に紹介する業務を一度聞いた(読んだ)だけで理解するのは難しいだろう。
ある社内システムから出力してきた売上実績データをエクセル上で加工している業務があるとする。
ある社内システムから出力できる売上実績は品番ごとの売上金額なのだが、取引先別に集計し、取引先別の掛率を掛け算する必要がある。
ただし、取引先の中には、ある一定金額以下の掛率とある一定額超の掛率が異なる契約をしている場合がある。
(理解できなくてまったく問題ないので、先を読み進めでほしい)
システム化する対象の業務を漏れなく聞き出し、可視化することを要件収集という。
さらに、システム化するorしない部分の境界をはっきりさせたりして、まとめ上げて関係者全員の合意をとれたものを要件定義という。
要件収集と要件定義をしっかりすることからシステム化が始まる。
実際に経理事務や管理会計や請求業務などの実務に携わった経験があるプログラマーは少ない。
経験がまったくないプログラマーもたくさんいる。
小中学校からパソコンでゲームを作ったことがある人や高校でロボコンに関わっていた人だからといって、業務アプリケーションも同じように作れるとは限らない。
ビジネスの実務経験がなければ要件を洗い出すことは困難な作業だし、一人の力ではやりきれないはずだ。
そんなわけで、業務アプリケーションの開発には社会人経験がありノンプログラマー時代を送ったことのある人が価値となる場合がある。
そのような人がVBAスキルを身につけることはこれまでの社会人経験すべてが有利になるバックグラウンドとなる。
実務経験があるプログラマーは自分の経験を重ねながら、ユーザーの業務を具体的に聞き出すことに長けている。
アプリケーション開発において、一番避けたいことの一つに要件定義の見直しだ。
要件定義を元に、設計→製造→テスト→リリースと各工程が進む。
開発工程が進んでから、要件が漏れていたと発覚すると設計まで工程を巻き戻して、一からやり直すことになる。開発工程の終盤での手戻りは悲劇だ。絶対に避けなければいけない。
業務を可視化して要件定義を書き起こし、関係者の合意をとれるプログラマーの価値は高いので、実務経験豊富なビジネスパーソンがプログラミングスキルを身につけるメリットは大いにある。
