VBAで自動化ツールを作る際の手順をルーチン化しておけば、開発の効率を高めることができます。今回は開発効率を高めるための手順をまとめます。
目次
開発効率を高めるためには開発手順をルーチン化する
自動化ツールに限らず、効率化の要諦はルーチン化にあります。毎回同じ手順で開発ができれば、それだけで開発効率があがりますし、さらに手戻りに強い手順でルーチン化できれば、よりよい効率化を図ることができます。
それでは早速、VBAの自動化ツールの開発効率を高める具体的な開発手順を見ていきましょう。
結論：具体的な手順
具体的な手順は下記の通りです。
- 概要書受領
- 要求仕様書を共同で仮作成（完璧を目指さない）
- 操作画面や機能面の深堀するためのPoC
- 要求仕様書を共同で修正
- リリース前のチェックリストを作成
- 開発用サンプルデータ受領
- プログラミング着手
- コアな部分が一通りできたらレビュー
- 機能の追加、修正を行い、必要なら要求仕様書に反映
- プログラミング再開
- リリース前テスト
- リリース
上記の手順を読んだだけで納得できた方はもう、最後まで読まなくても大丈夫かもしれません。早速、自動化の準備を進めていきましょう。それ以外の方は、最後までお付き合いください。
順番に説明していきます。
概要書受領
開発のきっかけになるものです。この件に着手することを明確にすることが目的です。そのため、堅苦しいフォーマットは不要です。メールで依頼を受けるだけでもOKです。
口頭だけで話を進めるのはやめましょう、ということです。
要求仕様書を共同で仮作成（完璧を目指さない）
キーワードが３つも出てきましたが、大丈夫です。順に解説します。
- 要求仕様書
依頼者が実現したいこと、要するに何がしたいのか、どんな処理をしたいのかを記載した文書のことです。口頭ではなく、文書に残すこといよって、エラーが出たり、想定外の処理が実行された時にこの文書を参照することによって、求められていた機能が実装されていたのか、という事実に基づいた議論ができるようになります。
- 共同
要求仕様書は依頼者側と開発者側の双方を守る開発ドキュメントです。プロのシステム開発では要求仕様は依頼者側が用意するのが当たり前ですが、非エンジニアのちょっとした業務効率改善ツールなら、依頼者と一緒に作るのが現実的です。
また、共同で作成することにより、作成過程での齟齬、勘違いを防ぐことが可能となります。プロは使う言葉を共通にするなどの工夫をすることにより要求仕様をユーザー側で作成できるようにしているようですが、非エンジニアは自動化ツールの作成が本職ではないので、そこまでは不要です。
膝を付き合わせて一緒に要求仕様をまとめるようにしましょう。
操作画面や機能面の深堀りするためのPoC
PoCはProof of Conceptの頭文字をとったものです。意味は「あなたが求めているのはこういうことですよね。これで狙った成果があげられる、と証明してください！」ということです。
私の苦い失敗談があります。ユーザーの言う通りの自動化ツールを作成したものの、利用されなかったということがありました。使ってみた感想が、「んー、まあそういうことだけど、なんか使いにくい。」
依頼されたことを単に実装するだけではダメなのです。実際に使ってみると「なんか違う」とか「勢いで依頼してしまったけど実は緊急性はなかった」ということが少なくありません。
このタイミングで、「ユーザーが必要なこと」と「それは本当にやって意味があること」であることを確認するPoCを作っておくのがよいでしょう。操作画面は実際にプログラムを書かなくてもパワーポイントでイメージ図を作ったり、A4の紙に手書きするだけでも有効です。
要求仕様書を共同で修正
非エンジニアの素人同士が頭を捻って要求仕様書を作ったところで、たかがしれています。PoCをつくると要求仕様に足りないところが出てくるので、ここで、深掘りしていきましょう。
「非エンジニアの素人」とはバカにした表現ではありません。私自身がそうですし。ポイントは、修正があることを前提に設計すべし、ということです。
最初から完璧な要求仕様を作るのは難しいので、要求仕様は修正を前提としてざっくりと作りPoCとその後の修正を大切にするようにしましょう、ということです。
リリース前のチェックリストを作成
依頼者側であるユーザーとのトラブルを防ぐための対策で、大事なステップです。
実際に開発を進める段階ではサンプルデータを使って挙動を確かめながらプログラミングを進めていくことになります。
これらの開発用のサンプルデータとは別にリリース前のテスト内容を決めておくことが大事です。
どういう条件でどんな不具合を出さずにどんな処理結果が出たら、合格、というのをあらかじめ決めておくのです。
たとえば、ユーザーが間違った入力データを選択した場合、処理を中断する、というように、うまくいったとき以外の処理方法についても、どんなテストをすべきかあらかじめ決めておくべきです。
プログラミング着手
下準備が完了したので、実際にプログラミングに着手します。
コアな部分が一通りできたらレビュー
VBAはとりあえずコアな部分だけ先に作ってしまう、ということが可能なプログラミング言語です。エラーの細かい処理は後で実装することにして、真っ先にコアな部分を作成してしまいましょう。
プログラミング開始後のPoCといえる段階です。
機能の追加、修正を行い、必要なら要求仕様書に反映
PoCの確認をしたにも関わらず、やっぱり何かしらの追加の要求が出てきます。
この時に「初めから言ってよ」というおのはNGです。
依頼する側も素人なので、ここも手直しを前提に進めるべきです。あまり細かく初めから作り込みすぎない方がよいゆえんです。
VBAは後から安心してコードを追加できます。
プログラミング再開
追加の要求、想定内の仕様変更を実装して仕上げていきます。
リリース前テスト
リリース前テストのチェックリストに従ってテストを実行します。
ここでのポイントは、ここでエラーが出ているようではダメということです。
リリース前のテストは受かるように準備をすべきです。この段階のテストは言わば、ユーザーが安心して使えるようにするための儀式です。
事前にリリース前のテスト内容は合意しているのですから、そのテストに合格する品質に高めてからリリーステストに望むのが当たり前です。
リリース前テストの目的は、バグ出しではなく、安心感を与えるための儀式。これを肝に命じておきましょう。
リリース
必要に応じて、運用手順書を作成してもらいます。作成するんじゃないですよ。ユーザー側に作成することを促すだけです。
この記事は会社員でちょっとした自動化をVBAで組める人がよりトラブルなく、効率的に開発ができるように考えて書きました。
プロのITの現場とは違う場面が多々あることをご了承ください。
それでは、改善のためのプログラミング作業の改善も図っていきましょう！
＜関連記事＞
