表現のミスをなくすには，誤解を招かないように書くことを心掛けたい。表現があいまいな部分にこだわって，詳細に書き込む方法もある。表現の誤りを強制的になくす仕組みも有効だ。
「ローマ字」や「以上」を使わない
情報量が同じでも，表現ひとつで意図の伝わり方は違ってくる。プライドの中嶋健一郎氏（システム・コンサルタント）は，オフショア開発を通じてそれを痛感した。そこで意識したのが，誤解を与えない表現である（図8）。
名前の付け方がその一つ。アルファベットを使う場合，日本人が理解しやすいようにデータ項目を「kokyaku」や「kakaku」などローマ字にする人は多い。だが「海外の開発者はローマ字の意味を考え込んでしまう」（中嶋氏）。これは「customer」や「price」といった英語で表記することで解決できる。
数値の範囲を日本語で示すのも危ない。例えば「Aの範囲は，500円以上，1000円未満」という表現。500円や1000円など境界値を含むのかという点で誤解を生みやすい。「≧500」や「＜1000」といった記号を使えばよい。
主語がないのも問題である。日本語は主語がなくても意味が通じる。だがインドや中国の開発者は，ここに疑問を感じるという。「顧客テーブルの情報を読み込んで画面上に表示する」という文章がある場合，「機能Aが」と主語をはっきりさせなければ意図が相手に伝わらない。
表で示せばよいものを文章で記述している場合もミスのもとだ。「区分Aが0の場合は割引率10％，1の場合は同20％，2の場合は同30％とする」という記述があったとする。読み手は項目と数値の関係を文章から読み取らねばならず，その過程で誤解が生じるかもしれない。表で示せば，一覧性が高まり，誤解が生じるリスクが減る。
場面ごとに「標準」を示す
「基本設計書には，機能に求める仕様だけを示せばよいと思っているエンジニアが多い」。こう指摘するのは，ソフトウェアプロセスエンジニアリングの岡大勝社長だ。岡氏は品質問題の原因に，手本となる開発方法を示していない，あるいは示していても記述があいまいであるという点を挙げる。「何に従って開発すればよいのか。それをあいまいにすると，各メンバーが試行錯誤を繰り返す」（岡氏）と言う。
岡氏がITアーキテクトとして参加したある開発プロジェクトでは，ピーク時に130人の開発者が参加していた。事前にそれを知った岡氏は，メンバーを迷わせないために九つの場面における「標準」を定めた。それをまとめたのが「アプリケーション方式設計書」である（図9）。
九つの場面とは，開発環境の構築からプログラムの作成，ドキュメントの作成，ログの取得まで多岐にわたる。それぞれの方法を約150ページのドキュメントに集約した。
問題は，開発者ごとにスキルの差があることだった。メンバーの中には設計書の内容を理解できない人もいる。そこで岡氏は，開発方法の説明とともに，サンプルコードを掲載した。これを流用すれば，そのまま開発を進められる。開発に入る前には，スキル・レベルに応じた勉強会も開催した。その結果，多少の問い合わせはあったものの，ほぼ問題なくプロジェクトは完了。「すべては標準を明確にした結果」と岡氏は自信を見せる。
