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