仕様書の書き方って，習いました？
突然ですが，読者諸兄姉は，仕様書の書き方って，教わったことはおありでしょうか。あるいは，部下に教えたことはおありでしょうか。
日経エレクトロニクス 2007年2月12日号のGuest Paper（pp. 133-152）では，「仕様書の記述力を鍛える」と題して，フェリカネットワークスのソフトウエア・エンジニアの栗田太郎氏に，「形式仕様記述」という手法を使ったプロジェクトの体験記を執筆していただきました。
同社は「おサイフケータイ」などとして知られる携帯電話機向けの「モバイルFeliCa」の開発元で，そのICチップのファームウエア開発に当たって，「仕様をキッチリ書けるところは，書こう。実装者任せにしないようにしよう」という意識を徹底，高品質なソフトウエアの開発に成功しました。成果物は，NTTドコモの携帯電話機「903iシリーズ」の全機種に採用されるなど出荷数も多く，責任の重いプロジェクトです。
今回，著者の栗田氏と打ち合わせを重ね，原稿をやり取りする中で印象に残った言い回しがあります。それは，
「形式仕様記述を使いこなせるようになると，自然言語（日本語）での記述力も上がる。エンジニアのコミュニケーション・スキルを磨く手段として有効」（p.135より要旨を引用）
という文章です。申し遅れましたが，形式仕様記述というのは，見た目はC言語などのプログラミング言語に似たもので，「集合」や「状態」などをより厳密に書くための構文が豊富なことから，システムの仕様を，実装担当者や品質保証技術者に誤解なく伝えるのに適している，といわれています。
この形式仕様記述，「論理的に筋が通っていなければ表現できないため，書く上での負荷が大きい」（p.135より引用）こともあり，ソフトウエア業界では「形式仕様記述は，導入のハードルが高すぎて実用にならない」との反論もあります。しかし，これに対する著者の主張は，なるほどとうなずけるものでした。
「自然言語を用いて正確に仕様を記述できるような技術者を育成するのは，もっと難しい」（p.135より要旨を引用）
自然言語というのは概して曖昧になりがちで，特に日本語というのは，同じ趣旨のことを，いかようにも言い換えられる幅があります。この幅が技術的なドキュメントでは，仇になる。であれば，「曖昧に書きづらい，書き手にとって厳しい道具」である形式仕様記述の方が有用ではないか，というわけです。
栗田氏ご自身も，部下のプロジェクト・メンバーの「先輩からプログラムの書き方は教えてもらっているが，仕様書の書き方については，教えてもらうどころか，先輩達も悩んでいるようだ」（p.135より引用）という声を聞き，仕様書の難しさを改めて実感されたとか。
「商品力向上のための積極的仕様変更」と「曖昧なままの仕様」の混同
日本企業では，「つうかあ」のコミュニケーションを重視するあまり，仕様の精緻さが軽んじられる風習がありました。ソフト開発に限らず，自動車や家電，半導体など機械/電気/電子系の開発でも，曖昧な仕様書に苦しむという話は，日々の取材を通して非常によく耳にします。
「顧客のため，そして製品の商品力向上のため，たとえ下流工程に至っても必要とあれば積極的な仕様変更をためらってはならない」――。そういう局面があることは知っています。そして，それが日本の製品の世界市場での強さにつながっているともいえるでしょう。よくいわれる「すりあわせ型」の開発です。
最大の問題は，本来，よく検討すれば詰められる事項まで曖昧にし，「この仕様変更は顧客のため，商品力向上のため」という大義名分の下，上流工程でよく練らないまま，仕様を出し，下流工程に至ってそれを直すという悪習がはびこることです。本来のあるべき「すりあわせ型」の仕様変更とは，詰める部分は最大限，力を尽くして上流で仕様を詰め，ドメイン知識をつぎ込み，どうしても詰められない部分については，イテレーティブな繰り返し型プロセスで改善を加えていく，というスタイルのはずです。
私は今回の記事を編集者として読者の皆様にお届けする中で，「形式仕様記述がいい」とか「形式仕様記述をもっと使うべき」というつもりはありません。著者の栗田氏も記事の中で，「可能であれば自然言語を用いて仕様を記述した方がよい」（p.134），「仕様を策定する際には，形式仕様記述言語やツールだけに固執しない方がよい。仕様検討の過程や仕様選択の理由は従来通り自然言語で，全体を俯瞰するための図はUMLなどの記法で，それぞれの言語や記法の特徴を生かして表せばよい」（p.151）と述べています。
重要なのは，「形式仕様記述を使うべきかどうか」という天下りの発想ではなく，「自分は，仕様をうまく日本語で表現する力が欠けているのでは」「自分の今の説明の仕方では，まだまだ相手に誤解を与える可能性があるのではないか」と，繰り返し自問自答する姿勢でしょう。そして，形式仕様記述は，「ハードルの高い道具」であるがゆえに，その負荷の重さが書き手に対し，一種の「筋力トレーニング」として働く。論理的な説明能力を根付かせるための鍛錬になる，という点だと思います。
極論すれば，形式仕様記述を使わずとも，C言語のような実装言語でも，「精緻に分かりやすく書こう」という心がけを徹底し，それがそのエンジニアの脳ミソへの鍛錬として働くのであれば，形式仕様記述とほぼ同様な効果が得られるのではないかと，今回の原稿を見ている中で感じました。
最後に，今回の記事の中で，記者である私自身の心に最も突き刺さった下りを引用します。
「形式仕様がプログラムに近い形態であるとはいえ，皆に読まれる仕様とする以上，実装用のプログラムよりも，規約にのっとり，読みやすく，読者が誤読することのない，サービス精神旺盛な，かゆいところに手が届く，しかしテクニックに堕しない仕様を書くことを志向する必要があると痛感した」（p.150）
出版社に勤務し，記者として，編集者として働く私にとって，非常に身の引き締まる思いがし，「研鑽を重ねなければ」というエネルギーをいただいた記事でもありました。
20ページと少々長めの記事ですが，ぜひエンジニアである読者の皆様にも，ご一読いただければ幸いです。
■よく形式仕様記述はXP（エクストリーム・プログラミング）と対比されますが，
形式仕様記述はXPの「テスト駆動開発」と共通点があります。テスト駆動開発ではソフトウエアの仕様を曖昧さの無いプログラミング言語で記述することから始まります。記述方法は違うものの両者とも仕様を精確に表現することに重きを置いた手法です。
そう考えると形は違うものの，形式仕様記述の重要性は広く認められているように思えます。
■仕様書の書き方は習うのも教えるのも難しいかもしれません。コミュニケーションと同じで経験や資質などが要求されるからです。むしろ仕様書を書く機会を増やし「習うより慣れろ」式がいいと思います。仕様作成者は仕様を読む人に作成者の意図をなるべくわかりやすいように書くことを念頭に置き作成するようにすべきでしょう。形式仕様記述はベースにあってもいいかもしれませんが，あくまでも基本として身につけておいて自分なりに応用して創造していくのが必要です。
(2007/02/19)■「形式仕様記述」とは，極論すればメタ言語によるプログラム記述なのではないか？ 記録として残すための個々のモジュールやクラスの「仕様書」はこれでもいいかもしれないが，本当に必要なのはもう少し高次の，「設計思想」が明快に記述された文書ではないかというのが私の持論だ。初期の設計思想にそぐわない「改修」から，予期しない不都合が生じることは，分野を問わず，決して珍しくない。新規追加要件が既存製品の設計思想に合わないことが容易に判断できれば，抜本的再検討の決断も早まるというものだ。見える化という意味でも重要なことである。
(2007/02/18)■非常に面白い試みだと思います。是非拝読して参考にしたいと思います。
ただ，伝える相手がその表現手法を理解してなければ，やはり意図した情報を正確に伝える事は難しいのではないのかとも考えています。
私自身は，自然言語を使っても，ある程度問題を防止する為に，次の様な方法を使っています。
それは，仕様を一旦英語で記述してから日本語に機械翻訳し，翻訳結果が意図した内容と等しくなかったら，論理性，明瞭性，簡潔性に欠ける難解な文章として，理解できる日本語になる迄，記述を変えるという事です。
要は，PCに分からない文章は，他人にも伝わらないという事です。語学学習にもなり一石二鳥です。
それから分かったつもりにさせる「それらしい記述」というのも，プロジェクトを先に進める上で，人(顧客？)を説得する為に，これもまた重要かもしれませんね。
ただ，誤解や曲解を招くあいまいな仕様記述は，後々問題になるので危険な裏スキルだと思います。
■私もゲーム開発で仕様書を書いていましたが，最近，そういう能力を軽視する傾向にあるようです。
(2007/02/16)■形式仕様記述で仕様を書き上げられるところまでできれば，そのプロジェクトは60％終了している。まだあいまいな部分が多い状態で仕様をまとめて，それらしくしないといけないから皆さん困っているわけで，問題は本当は表現手段以外の所にある。
もしも，いきなり形式仕様記述でまとまるような，あいまいさや，決めかねる部分の少ない設計対象を例に，『なんとか記述手法はすごい!』のような論調が多く，ただただ。滑稽。
