VBAによる開発は細かな要件定義などを省いてとりあえず核となる部分を作ってしまうのが最短です。VBAは簡単に自動化ツールなど便利ツールの開発に着手できることがメリットです。一方、簡単に開発が可能だからこそ、リリース前に本番移行判定という儀式を行う事が重要となります。今回はその事について説明していきます。
目次
- VBAは余り深く変えずにいきなり開発に着手できる（ことが多い）
- いきなりプログラミングの工程に着手できることのメリット
- 外してはいけないポイント
- リリース前の儀式とは
- 慣れてきたら追加したい手順
- 本番移行判定という儀式のまとめ
VBAは余り深く変えずにいきなり開発に着手できる（ことが多い）
VBAは非エンジニアの事務職が気軽にちょっとした便利ツールを開発するのに適したプログラミング言語です。いきなりコアとなる部分を作り始め、データの入力や出力時の方法などはあとからプログラムを追加して実装する事が簡単にできます。プロのエンジニアがゲームや基幹システムを作る際にはそうはいきません。簡単に違いを把握しておきましょう。
プロのエンジニアのシステム開発の工程
開発工程は大きく分けて以下の5つの段階に分けることができます。
- 要件定義
- 外部設計
- 内部設計
- プログラミング
- テスト・移行
これらは一つ一つが重要な工程として意味を持つものとされています。大まかに意味を書いていくと下記の様になります。
＜要件定義＞
実現したい内容（例えばAと言う作業を自動化する、など）を具体的にまとめるために、必要な作業の調査や分析を行う工程。詰まるところ何がしたいのかと言う部分なので、この部分がブレるとできあがったツールやシステムが狙ったモノとずれてしまう。
＜外部設計＞
メニュー画面の見た目や出力物のレイアウトなどをどのようにするかを決める段階。システムやツールを作る側と綿密な打ち合わせ、合意が必要な段階の最終部分となる。
＜内部設計＞
内部設計はデータはどのような構造になっているのか、どのようなデータが格納されているのか、データをどのように加工するのかと言った手順を設計する部分です。後のプログラミングの工程のメインの設計図となる部分を作り込む工程です。
＜プログラミング＞
外部設計や内部設計で作成した仕様に基づいてプログラミング言語で実装する工程です。
＜テスト・移行＞
この、テスト・移行という部分がこの記事のメインテーマです。ツールやシステムが組めたらユーザーに渡します。そのソフトを渡すことをリリースすると言いますが、その前にテスト・移行という儀式が必要となります。なぜ儀式と言うかについては後ほど説明します。
非エンジニアのVBAツールの開発工程
プロの開発工程の一部をざっくりと説明しました。実際はそれぞれの工程にさらに複雑なステップがありますが、この記事は事務職の方がVBAでエクセルなどでちょっとした便利ツールを開発する手順につい手の説明なので、その比較としての説明は上記で十分です。これに対して、非エンジニアの開発工程は下記の様になります。
- 作業の自動化など、作成するツールの目的を決める
- 核となる部分をいきなり作り始める
- 核となる部分以外の部分を開発する
- 完成度を高める
＜作業の自動化など作成するツールの目的を決める＞
プロの開発では要件定義に当たる部分です。ここも本格的にやろうと思えばキリがありません。そもそもプロのシステム屋ではない素人が要件定義をやろうとしてうまくいくはずがありません。この段階では、非エンジニアの私たちは要件定義をきちんと行う事よりも、何を自動化するのか、どういった動作をすれば良いのかと言った事を細かくなくてもいいので外さないように決めておくことが大事です。
そして、ツールを開発する人と利用する人が別の場合は、これから開発するツールが、どの作業を自動化し、その自動化の目的は何で、元データはどのようなデータで出力結果はどのように保存するか、と言った事を合意しておきます。メモ帳でもワードでもいいので、その議事録は取っておくようにしましょう。この作業が後にツールを作成する人とユーザーの双方を守ることにつながります。
＜核となる部分をいきなり作り始める＞
作成するツールの目的を決め、どの作業を自動化するのか、と言った事をメモできたら早速プログラミングに着手します。プロのエンジニアであれば、ユーザーが操作する部分の見た目をどうするかであったり、画面はどのように遷移するかと言った外部設計を先に行いますが、私たちはいきなりプログラミングを開始して問題ありません。
本格的なシステムやツールであれば、細かな作り込みが必要となるため、後から修正が必要になると非常に大きな手戻りが発生する可能性が高くなります。一方で、VBAでちょっとした便利ツールを開発する程度であれば、機能を追加したり、ユーザーインターフェースを修正する事は後からでもいくらでも可能です。
この後から修正できると言う事のメリットが非常に大きく、とりあえずプログラミングできる事につながっています。細かな仕様の検討や外部設計を飛ばして核となる部分のプログラミングに着手できる事のメリットについてはこの次の項で説明します。
＜核となる部分以外の部分を開発する＞
核となる部分が一通り完成したら、それ以外の部分の開発に移ります。例えば加工前の元データを取り込んだり、最後に保存して閉じたりと言った部分です。核となる部分は作業内容が厳密に決まりやすいのに対し、書くとなる部分以外は設計に自由度がある分腕の見せ所です。例えば、元データを取り込む段階では、対象のデータをユーザーに選ばせる事もできますし、ある名前のファイルを自動で開く事もできます。本日の日付がファイル名に含まれたデータをフォルダ内から検索すると言ったことも可能です。
ユーザビリティや便利ツール開発の背景に応じた設計、開発を行いましょう。この部分もユーザーと打ち合わせしたメモを残しておくようにしましょう。設計に自由度があると言うことはその分、期待外れになる可能性もあるためです。
＜完成度を高める＞
最後にいろいろなデータを使いながらデータに誤りが無いか、エラーが出ないか、使い勝手がいいかを確認しつつ修正を繰り返し、完成度を高めていきます。自分だけが使う便利ツールではこの部分は簡単に済ませることができますが、他人に使ってもらうツールを開発する場合、この部分を以下に丁寧に行うかで開発したツール、ひいては自分の信頼度が変わってきます。
どんなに丁寧にツールを作っても、ユーザーは思わぬ操作をするモノです。これでもか、というぐらい丁寧に作り込んでいきましょう。
いきなりプログラミングの工程に着手できることのメリット
さて、前項で細かい要件定義や外部設計といった工程を省いていきなり、ツールの核となる部分のプログラミングに着手できると説明しました。実はこのことは非常に大きなメリットがあります。それは決して要件定義や外部設計に割く時間が削減できると言うようなモノではありません。
いきなり核となる部分に着手できる事のメリットは、ある程度ツールの書くとなる部分ができたらユーザーに試しに使ってもらってフィードバックを得ることができる事です。細かく仕様を事前に固めても結局ユーザーに使ってもらうと色々と細かい修正の要望を受けることがあります。それなら、とりあえずある程度作ってもらって感想をもらい、それをフィードバックする方が速いですし、結局手間が省けます。
本格的なシステムやゲームの開発であれば、後から作成済みのプログラムを修正する事は手戻り、すなわち大きな時間のロスを意味します。しかし、VBAによるプログラミングは後から必要な機能を追加したり、内容を修正することが容易なため、とりあえず作って見ると言う事が気軽に可能です。修正がある事を前提にとりあえず作り始め、試しに使ってもらってそれをフィードバックするという開発手法が可能となるのです。
VBAによるツールの開発が簡単という本質的な意味合いはココにあると言えます。プログラミング言語の仕様としての簡単さよりも、あとから修正できるという点が評価できるのです。
外してはいけないポイント
いきなりプログラミングに着手できるのは、後からプログラムを追加したり修正したりするのが容易だからであるという説明をしました。ここで注意点があります。それは、VBAというプログラミング言語を使用して開発しようとするとき、間違いや修正を許容していると言うわけではないと言うことです。
フィードバックをあとから反映しやすいというだけであって、それはテキトーにプログラミングをしても良いと言うわけではありません。ココは勘違いをしないようにしましょう。
リリース前の儀式とは
実はこれまで解説してきた開発工程に大事な点が抜けています。これこそがこの記事のメイントピックです。それは開発した便利ツールをユーザーに渡すリリースを行う儀式、本番移行判定です。
本番移行判定とは開発した便利ツールをユーザーに渡す儀式です。移行判定というとリリース前のテストやバグ出しの事だと思う方がいるかも知れませんが、そうではありません。テストやバグ出しは開発の一部です。
いきなり着手できるの項で説明したように、VBAによる便利ツールの開発では素早く書くとなる部分を作成してユーザーに試してもらうことができます。これを素早く繰り返すことでエラーや使い勝手の向上は既にある程度済んでいます。その後、さらにバグ出しで強固なツールに仕上げる過程を経ています。それでは、なぜ本番移行判定を行うかというと、けじめをつけるためです。
前述の通り、VBAによるツールの開発においては、とりあえず作って見て試しに使ってもらうという事が容易にできるため、「これができあがったツールです」ときちんと宣言しないと、いつまでたっても機能の修正や追加の依頼が来て一向に手を話す事ができなくなってしまうのです。簡単に開発し、試してもらえるからこそ、本番移行判定という儀式をちゃんと行うことによって、開発終了の宣言を行う必要があるのです。
慣れてきたら追加したい手順
本番移行判定を含む一連の開発手順に慣れてきたら、是非付け加えたい工程があります。それはレビュー会です。レビュー会とは本番移行判定という儀式の各ステップ版です。本番移行判定という儀式を通過することによって、ツールの開発の完了を宣言する事ができました。それと同じ考えを、作成するツールの目的の決定、核となる部分の開発、核以外の部分の開発のそれぞれについて行います。もちろん開発のボリュームに応じてレビュー会は減らしたり増やしたりすれば良いです。
そして、レビュー会を行うようになると、その議事録が仕様書代わりとなります。この議事録があれば、本番で使ってもらったときにエラーや不具合が起きた時に、それが合意した仕様なのかどうかが明確に把握できることになります。面倒なようでいて、このことが結果として開発者とユーザーの双方を守ることにつながります。なぜならば、不具合が起きたときにそれが予め合意して取り決めた仕様なのか、それとも実装漏れやプログラムのミスなのかが分かるからです。
開発者にとって、合意した通りにプログラムを実装したのに「不具合」と言われるのは辛いことです。これは何としてでも避けたいところですし、レビュー会を行い、議事録を残す事で回避可能です。
本番移行判定という儀式のまとめ
今回の解説の内容をまとめます。
- VBAはあまり深く考えずに核の部分のプログラミングに着手できる
- すぐに着手できる事ができる理由はVBAが後でプログラムを追加したり修正したりするのが容易だから
- いきなりプログラミングの工程に着手できる事のメリットは、手軽に作ってすぐにユーザーにフィードバックをもらえること
- 手軽に作ってフィードバックを得る事ができると言う事は、間違いや修正を許容している事にはならない
- リリース前の儀式として移行判定会を行うべきである
- 移行判定会の目的は、開発の完了を宣言すること
- 慣れてきたら移行判定会の各ステップ版であるレビュー会を取り入れる
- レビュー会の議事録は、面倒なようでも、結果的に開発者とユーザーの双方を守る
以下の関連記事も参考にして、よりよい業務ハックライフをお楽しみ下さい！
＜関連記事＞
- チェックリスト｜VBAで人の為に作る開発ドキュメント
- 要求仕様書｜VBAで人の為に作る開発ドキュメント
- 会社員がVBAで自動化するのに必要な開発ドキュメント３点
- VBA 開発速度を高める開発手順まとめ
- VBA ｜初心者向けオススメ独学本レビューまとめ
＜お知らせ＞
Excel VBAでクラスやオブジェクトの概念と使い方を丁寧に解説し、ワンランク上の実力を目指すガイドが電子書籍になりました。この本で本物の実力を身に付けて一皮むけてみませんか？
books.rakuten.co.jp
