それは不思議な仕様書なの！？
こんにちは。草食系妙齢プログラマ 野口おおすけです。iPadの予約受け付けが行われましたが、皆さんの購入予定はいかがでしょうか。わたしは、Wi-Fi 32Gモデルを予約してきました。予約番号が後ろの方だったので、当日手に入るか分かりませんがとても楽しみです。
さて、今回と次回は「マジカル仕様書」についてお送りします。マジカル仕様書、つまりは「不思議な仕様書」。実務ではめぐり合いたくありませんが、どうしてもめぐり合ってしまうものです。そんな、憎まれながらも愛すべき存在であるマジカル仕様書についてのお話です。
■そもそも仕様書って何？
読者の皆様が、開発業務の中で「仕様書」というものを作成する、あるいは読むことは日常茶飯事だと思います。これらのドキュメントには、開発しているシステムの概要や各モジュールの挙動など、さまざまなことが記述されています。
これらを作成することがゴールではありませんが、開発業務の中では多くの時間を仕様書作成に費やします。仕様書を元にプログラムを作成したり、各機能の検証を行ったりと、各開発工程の橋渡しをしてくれるものだからです。つまり、仕様書は各開発工程のアウトプットであり、次の開発工程のインプットとなります。
これらが、役割を果たさなければ、その時点で開発の流れは途絶えてしまいます。ウォーターフォール開発で例えれば、そこで「水の流れ」が途絶えてしまいます。途絶えてしまうだけでなく、水がこぼれだし、まったく違う流れを作ってしまうことだってあります。仕様書が役割を果たさなければ、目的から遠ざかってしまうことすらありえるのです。
■マジカル仕様書って何？
前回のコラムでは、「『ピッと押したらドーンとなる』というレベルのものから、日本語としてパースできないものまで」と表現しました。前回ご紹介したものを例に見ていきましょう。
1．ピッと押したらドーンとなる！？ 仕様書
前回のコラムでご紹介した「このボタンクリックしたらファイルがDLできる」というものを例に紹介していきます。
この仕様には、さまざまな疑問点があります。
- そもそもこのファイルってなんだ？
- このファイルを作るためのデータはどうやって生成するんだ？
- ファイル名はどうしたらいいんだ？
プログラミングを行う工程のインプットとなる仕様書には、これらのことが一切書かれていませんでした。エンドユーザーの要望からプログラミングを行う工程まで、ずっとこのままの状態であったわけです。決して、エンドユーザーさんの要望が悪かったわけではありません。要望としては妥当だったのです。
エンドユーザーさんが事細かに「このファイルはutf-8のCSVでカンマ切りで～～」なんて定義してくれたら、プログラムを書く以外、わたしたちの仕事はなくなってしまいます。システムに関して素人であるエンドユーザーさんが、ゆるくてふんわりした仕様（ゆるふわ仕様）を提示するのは当然です。逆に、システムを作ることに精通しているわたしたちが同じようなことを言っていると、プロとして恥ずかしい限りです。
2．情報の伝達に齟齬が発生するかもしれない……仕様書
とある小説の中で、「宇宙人的存在の少女が主人公に自分の正体を説明するシーン」があります。少女は淡々と、ロボットのように自分の存在を説明します。その説明はとても長く現実離れしているため、主人公は言われていることが理解できず、そのシーンは終わってしまいます。仕様書も同様に書き手（設計者）と読み手（実装者）の間の情報伝達に、データ欠損を起こすことがあります。
それでは、「文字列SがAまたはBでない」という表現を思い浮かべてください。日ごろの仕様書の中でも「文字列HOGEがAまたはBでない時は処理MOGEをする」という表現をするかと思います。この「AまたはBでない」という表現をよく考えてみると以下のパターンが考えられます。
- 「文字列SがA、または、B、ではない」＝「文字列SがA、Bのいずれでもない」
- 「文字列SがA、または、Bではない」＝「文字列SがA、あるいは、notBである」
文字列SがAだった場合、上の例だと条件を満たしませんが、下の例だと条件を満たします。条件が複雑になれば、さらに複雑な文章になり、どの場合が適合するのかわからなくなってしまいます。
「AまたはBまたはCではない条件を満たさない場合」と表記されると、書いてる本人が分かってるのかどうかもあやしくなってきます。冗長な文章ほど、真の意味を外してしまいがちです。よくインターネットでいわれる「（長すぎるから）3行でよろしく」というのは、ある意味ベストプラクティスなのかもしれません。
上記2つの例を見てきましたが、これ以外にもマジカル仕様書と呼びたくなるものは世の中に数多く存在します。
マジカル仕様書かどうかを判断する大きなポイントとして、「書き手（設計者）の意思が読み手（実装者）に伝わっているか」ということがあります。ミスリードされやすい文章になっていないか。情報を書き漏らしていないか。仕様書を作成する側も読む側も、十分にこれらの点を確認し合うことが必要です。
次回は、ケーススタディを通して、ちょっと面白いマジカル仕様書の世界をご紹介しようと思います。
それではまた次回お会いしましょう。