「納期に間に合わない」という焦りで失敗しないためには？ ―― 第12回 組込みシステム技術に関するサマーワークショップ（SWEST12）

●「ちょっと直す」ときにもソース・コードは最後の最後に

　筆者が理解した清水さんのモンスターを退治する手法は，次の（1）～（3）の通りである．ただし，筆者のバイアスがかかった解釈なので，清水さんの考えとは異なる部分があるかもしれないことをご了承いただきたい．XDDPに興味を持たれた方は，ぜひ，清水さんの講演を聞いたり，著書を読んだりするなどして，自分なりに解釈していただきたい．この実践的な技術は勉強する価値があると，筆者は思う．

（1）PFD（Process Flow Diagram）として，仕事のプロセスを設計する
　ソフトウェア開発のしごとは，要求を定義し，設計を行い，実装し，テストするという，万人が認める工程がある．この工程は，一つの製品開発の間に，試作品を作る場合など，何度か繰り返されるが，この順で行われることが必要である．例えば，実装を行うためには設計が必要である．設計しないでコードを書くと，生産性が悪く，おまけにバグを埋め込んだりして，ロクなことがない．

　また，ソフトウェア開発に従事する技術者は，いずれかの工程を担当する．その工程をやりきることが「付加価値」を生み出すことであり，給料を得る根拠となる．開発の全体を見渡す工程を定義することが，「しごと」の基本である．工程の定義なくして，しごとは始まらない．

　工程を定義することとは，工程に対する入力文書を定義し，工程で行うことを出力文書として定義することである．ソフトウェア開発の場合，開発文書の定義を通したプロセスの定義が最重要である．XDDPにおいても，PFDとして仕事の工程を設計することが，出発点となる．

（2）USDM（Universal Specification Describing Manner）として，要求を仕様化する
　詳細化されていない「顧客の要求」は，多様な解釈が可能である．その解釈を唯一のものとするところから，具体的なしごとが始まる．一つの解釈として要求を定義したものを，清水さんは要求仕様書と呼ぶ．

　USDMの特徴は，要求に現れる「動詞」に着目し，その振る舞いを「文」により定義することである．一つの動詞に着目し，その動詞を使う文を書き，振る舞いを定義する．動詞が目的語をとる場合は，目的語を明記する．明確な文を書くことが，明確に仕様を定めることにつながる．

　加えて，USDMでは，その要求の背景に存在する理由の記述を求める．優れたソフトウェア技術者は付加価値として，その理由を踏まえて，要求の妥当性や，隠された要求を見出すことができる．講演では，理由から考えて要求が不適切であることを指摘した例が挙げられていた．

　また，USDMでは，階層構造によって要求を段階的に詳細化することを求める．USDMで要求をインデントされた箇条書き形式にまとめる理由は，そこにある．Excelを使い表形式で記述することが目的ではなく，要求に構造を見出すことが目的であると，筆者は解釈した．

（3）XDDPに準拠して仕事をする
　XDDPでは，PFDとUSDMを用いた具体的な仕事の進め方が定義されている．具体的には，次の3点の成果物を作成することが，XDDPにおいて求められる．変更要求仕様書と，TM（トレーサビリティ・マトリックス），変更設計書の3点である．清水さんはこれを「3点セット」と呼んでいた．そして，この3点セットを作るまでソース・コードを変更してはならないと，強調していた．「ソース・コードはぎりぎり最後に触る」という言葉が，筆者の印象に残っている．

　3点セットを作るまでに3回ソース・コードを読んでいるはずなので，ソース・コードの改訂はすぐに行えると，清水さんは主張した．実際に，その時点でのコード生産性の実績値は，従来手法と比べるとけたが違うという実例を挙げていた．実は筆者も，過去に上司から安易なコーディングを戒められ，徹底して設計を行うことを求められていた．さらに，ソフトウェア技術者の本分として，要求仕様書や設計書などの開発文書を明確に記述することの必要性を叩き込まれた．清水さんの講演を聞きながら目を閉じると，以前の上司の顔が浮かんできて，清水さんをさらに親しく感じるようになった．

　筆者は現在，ソフトウェア開発文書に対する研究と教育を進めているのだが，清水さんが進めるXDDPと多くの類似点があることを，講演を聞いてて感じた．清水さんを親しく感じた筆者は，講演終了後に2回にわたって清水さんと話し，そして，その感想は確信に変わった（日を改めて，清水さんに筆者らの活動をご紹介しようと考えている）．