まずは日本語の作文から
ソフトウェア開発現場の七不思議の4回目。
> 4. 仕様書の解釈が読み手によって大きく異なる。
仕様書と言ってもいろいろあるが、ここでは日本語の文章で書かれた仕様書や設計資料についての話。文章で書く場合、とにかく記載方法が自由なので書く人によって内容はマチマチだし、それに応じて読む手も都合の解釈を行ってしまうことが多い。本来、ソフトウェアという一つの目標に向かって記載されるべき内容が、どうして書き手によって記載が異なり、しかも読み手によって解釈が異なるのか理解に苦しむ。
これではソフトウェア品質を確保できないので、仕様書記載の手引きを作り同じレベルの資料が揃うようにしている。下記のその一例。
- 「○×の場合は、×□を行う」
○×を満たさない場合は何を行うべきなのか？何もしなくて良いということを言っているのか？それとも単なる記載漏れなのか？ソースコードでも全く同じで、if文に対応するelse文が存在しない記述は、何か不吉な臭いがする。 - 「画面で正しく設定する」
「正しく」の解釈は人によって異なるので、何が正しいのか具体的に説明することが必須となる。「入力欄に0以上、99以下の整数値を入力する」など、誰でも「正しい」と判断できる客観的な根拠が必要だ。 - 「△▽について...」（専門用語、略語等）
特定の開発者にしか分からない用語は、まずその定義を行うべきだ。自分の知っていることは相手も知っていると思いこんでいる独りよがりの開発者が多すぎる。エンジニアとして知っているべき基本事項は不要だが、特定のドメインに属する用語なら事前に説明が必要だ。
しかしながら、グループの中には様々な開発者がいる。若手の場合、会社に入るまでソフトウェアの仕様書どころか、日本語の長い文章すら書いたことがないという人が珍しくないので、結果的にブリッジエンジニアが書いた日本語の方が分かりやすいのでは？と思える奇怪な文章が生まれることになる。一方、ベテランは、仕様書など書かずにいきなりコーディングしてき経験から離れられず、資料を通じて自分の考えを相手に理解させる努力が出来ない。しかも、こんな開発者が管理職となって、仕様書の承認印を押しているので余計にたちが悪い。あなた、本当に内容を理解しているの？
そんなわけでソフトウェア開発の現場では、仕様のレビュー前に日本語の文章についてお目付役（私だ）の厳しいツッコミが入るのであった。「仕様書をキッチリと書け」というのは改善の常套句だが、そのキッチリすら出来ていないのが現実だ。こんな開発はエンジニアリングから程遠いよね。
「テストやレビューをしっかりやれ」「プロジェクト・マネジメントをキッチリ徹底しろ」 今のソフトウエア開発では，誰もが品質確保の確かさを「キッチリ」としか表現できない面がある。 エンジニアリングの実践に程遠いこうした現状から脱却しハードウエアと同じ地位を持つ工業製品として ソフトウエア開発を昇華させる必要がある。
日経エレクトロニクス2005年12月19日号〜ソフトウエアは硬い ＜キッチリとは何か＞
