今回は非エンジニアの会社員がVBAで自動化ツールを作成する時に必要な開発ドキュメントについて解説します。この記事はエンジニアではないフツウのサラリーマンを読者として想定しています。
目次
開発ドキュメントとは
開発ドキュメントとは何かのソフトを作成する時に作成するドキュメントです。どのような機能があって、どんな風に操作するソフト、というようにそのソフトについて書いてあるのが開発ドキュメントです。
非エンジニアが便利ツールを作るのに必要な開発ドキュメントは３つだけ
早速用意すべき開発ドキュメントがどのようなものかを見て行きましょう。非エンジニアによるVBA開発で用意すべき開発ドキュメントは3つだけです*1。
要求仕様書
要求仕様書とは、作成するソフトにどんな機能を求めるかが記述されたドキュメントです。ソフトに要求する仕様と言う事です。これは、ユーザーが用意すべき書類で、今回ご紹介する3種類のドキュメントの中で最も重要すべきものです。
ユーザーがどんなソフトを使いたいかという要求*2が書いてあるので、これがないと設計やプログラミングを始めることができません。
しかし、やってしまいがちなのが、口頭で「こんなの作って」と言われて簡単にメモしただけでプログラミングを開始してしまう事です。自分だけが作るちょっとした便利ツールであれば問題ありませんが、人に頼まれてツールなりシステムなりを作るときは必ず要求仕様書を作成してもらうようにしましょう。
要求仕様書を作成するのは案外難しいですし、ハマってしまうと時間が掛かるので、場合によっては打ち合わせの場を設けて、依頼者側の要求を引き出してあげましょう。でもユーザーの代わりに書いてしまってはダメですよ。理由は後ほど説明します。
仕様書
仕様書は開発者側が作成する開発ドキュメントです。要求仕様書に書いてある事を実現するために、どのようにするかが記述されているのが仕様書です。仕様書は要求仕様書をインプットとして作成される、という言い方があります。これは要求仕様書を受け取ってないようについて依頼者側と認識をすりあわせることが仕様書の作成の出発点になっている、と言う事です。
仕様書は一度書き上げたら自分以外の人に見てもらうのがオススメです。理由は、要求仕様書に書かれている要求事項を仕様書に書いてある内容で本当に実現できるかについて、自分だけではどうしても必要な事が抜け漏れが生じてしまう必要があるからです。
チェックリスト
チェックリストはテストの時に使います。予めどのようなテストを行うかユーザー側と合意しておくことが大事です。「実務の中で使いながら確認する」という方法をとると、いつ正式リリースなのか分からず、確認しているのか利用しているか分からない状態になります。
いくつかのテスト用のデータを用意し、それぞれのテストについてどんなことをテストするかを決めておきます。そのテスト項目に合格しているかを一つ一つチェックするリストがここで言うチェックリストです。
3つのドキュメントを用意すべき理由
自分だけの便利ツールであれば特に必要なかった3つの開発ドキュメントですが、なぜ人に頼まれて作る場合は必要なのでしょうか。その理由は下記の3点です。
- 「思っていたのと違う」を防ぐ
- 再現性を持たせる
- 開発の手戻りを防ぐ
重要な順に並べました。順番に説明します。
「思っていたのと違う」を防ぐ
口頭で要求事項の説明を受けると、誤解や勘違いを産んでしまいます。また、その場では正しく理解しても、記述された者がないため、プログラムをする過程で、勝手な思い込みを産むことがあります。
私の経験上、自動化ツールの要求を口頭で説明すると、作業そのものの説明に終始します。C列をコピーしてD列に貼り付けて、偶数行に色をつけて・・・といった感じです。この様な説明には、自動化したい作業の目的や背景、後工程はどのような作業なのかという事が入っていません。
作業の目的がない説明を元に、作業だけを記憶から取り出してプログラミングをすると、「たぶん、ユーザーはこういう事を求めているんだろうな」と勝手に気を利かせて機能を付け加えたり、削除したりします。こうやってできたプログラムはほぼ確実に「こんな筈ではなかった」という、ユーザーと開発者の双方に悲しい状況をもたらします。
要求仕様書には持たせたい機能だけでなく、自動化する作業の目的や背景を盛り込むことで、より強力になります。
開発の手戻りを防ぐ
依頼を受けてから、テストに至るまでの設計からプログラミングの間に、最低でも一回以上のレビュー会を設ける事がオススメです。もしテストの段階まで作り込んで「こんな筈じゃなかった」が発生したら大きな手戻りが生じてしまうためです。
途中のレビュー会で修正が入るのは仕方がないことなのですが、その時のダメージを最小限にするために要求仕様書は重要です。非エンジニアの素人サラリーマン同士が協力してつくった要求仕様書なんてたかが知れていますが、それでも被害を最小限にするための努力は、リスク回避に大いに有効です。
メンテナンス性と再現性を持たせる
要求仕様書と仕様書があれば、そのソフトを作った人がいなくなっても、かなりの程度、メンテナンスができます。プログラムの中身のコードを読んで、何をしているのかは分かっても、「何をしようとしているのか」まで読み取るのは多大な労力が掛かります。
「何をしようとしているのか」が分からなければ、業務変更に伴う仕様変更はほぼできません。エラーを修正するのが関の山です。メンテナンスが不可能なソフトは、一旦使えなくなると、「もう、いっそのこと新しく作った方が早い」という状況を生みます。
また、メンテナンス性だけでなく再現性を持たせることにもつながります。そのソフトが壊れてしまったときや、そのソフトを元に似たような機能をもつ別のソフトを作成するときに、要求仕様書と仕様書があれば、既存ソフトの知見が生かせるので、次の開発時に大幅な開発工数削減につながります。
必要に応じて作成する運用手順書
必須ではありませんが、運用手順書を整備しておくと思わぬトラブルを防ぐことができます。想定外の操作によってソフトを壊されたりしないように、想定している使い方、時間帯、データの種類、ExcelやWindowsのバージョンの指定などを記載した運用手順書を整備しておけば、安定した運用を見込むことができます。
まとめ
以上の内容をまとめます。
- 開発ドキュメントはユーザーと開発者の両方を「こんな筈ではなかった」から守る
- 必要な開発ドキュメントは要求仕様書、仕様書、チェックリストの３つ
- 必要に応じて運用手順書を作成する
自分だけの便利ツールと人の為に作るツールは違うのだ、と言う意識を持って、開発ドキュメントを整備するようにしましょう。初めはめんどくさいと思うものですが、ドキュメントを用意するのが習慣になると、ドキュメントがないと不安に思うくらいになってきますよ。面倒なようでも開発ドキュメントが私たちを守ってくれますからね。
頑張りましょう！
＜関連記事＞
