その仕様は本当に正しいですか？
正確な言葉は忘れてしまったのですが、開発エンジニアとして働いていた頃、上司にタイトルのようなことを言われてはっとした思い出があります。
当時の私はとにかくコードを書くのに必死で、「仕様さえ満たせばいい」と考えてコーディングを行っていました。しかし仕様書に書いてあることは必ずしも正しいわけではなく、上司に指摘されなければ私は不完全な仕様のままリリースするところでした。（そのとき専任のQAはいませんでした）
そんなことがあってからはタイトルの言葉を常に意識するようにしているのですが、今回の記事では具体的にどんな試みをしているかを書いてみようと思います。少しでも参考になれば幸いです。
正しい情報を入手する
最も気を付けていることは、要件定義書や仕様書に書かれている内容をそのまま鵜呑みにしないことです。そのために、可能な限り最新の正しい情報を手に入れるようにしています。具体的には以下のようなことを実践しています。
公式の情報に当たる
たとえば国の法律や何らかの団体の提示している規格などに従ってシステムを作る場合、仕様書にその法律ないし規格がある程度ブレイクダウンして記載されていることが多いですが、私はまずはその法律や規格の出典元の情報を見に行くようにしています。仕様書の情報が古くなっていたり、細かなエッジケースが抜けている場合がたまにあります。
世の中の動向を知る
どのシステムにでもあるような「性別」の入力欄一つをとっても、最近は多様性の観点から「未選択」や「回答しない」といった回答を選べるようになっているシステムも多いです。（国で議論もされているようです。ソース）「とりあえず今まで通りにやればいいや」と考えていると、思わぬ落とし穴にはまることがあるので注意します。
専門家に聞く
自分一人で何とかしようとせず、社内の詳しい人や専門家の手を借りた方が良い場合もあります。状況に応じて他のメンバーも巻き込んで勉強会形式にするのも良いと思います。自分が分かっていないところは他人も分かってない場合が意外とあります。
仕様の意図を知る
要件や仕様について、腹落ちし切らないところがあればプロダクトマネージャーやエンジニアに聞いてみるようにしています。仕様を決めている側も当然プロなので、こちらが思いつくようなことはとっくに検討済み、ということも多いです。どうしてその仕様になったのか？ ということを知ると、自分の中での仕様の理解が深まります。
自分なりに要件から仕様を考えてみる
ここからは発展系になるのですが、私は要件を聞いたら実際の仕様書を見る前に自分なりに仕様を考えてみるようにしています。もちろんプロダクトマネージャーやエンジニアの方と話した結果実際の仕様と異なることもままありますが、その場合でも自分の仕様理解の助けになります。（現場によっては、仕様としてそのまま採用されることもなくはない）
私は主にWEBアプリケーションに関わっているのでそれに偏った話にはなってしまうのですが、大体は作成・改修する機能に合わせて図を作ります。
画面遷移図
私は習慣的に新規で作る画面を青く塗っています。フロントは最終的に触ることになるのでイメージも湧きやすいですし、必要な画面が仕様書から漏れていたなんてことがあったら大問題なので、個人的にはおすすめです。そのままテスト分析としても使えます。
状態遷移図
状態遷移図自体はテストでよく使うものだと思いますが、これを実際の仕様を見る前に想像で書いてしまうこともあります。ユースケースの漏れに気づける場合があります。これもそのままテスト分析として使えます。
図にも示した通り想像で書くので複数のパターンが思いついてしまう場合がありますが、その場合は実際の仕様を書いている方と認識のすり合わせをします。
ユースケース
私はこちらに関しては図ではなくマインドマップで書くことが多いのですが、誰がシステムにどう関わるのかは必ず自分で整理するようにしています。
詳細は前回の記事をご参照ください。
終わりに
普段タスクに忙殺されているとついつい何も考えずに書いてあることに従ってしまいたくなりますが、仕様書が絶対に常時完璧ということはあり得ません。これは実装の仕様書であっても、テストの仕様書であっても同じことだと思っています。
最近触れた仕様書を思い出してみて下さい。
その仕様は本当に正しいのでしょうか？
ここまでお読みいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか？