どうすればアーキテクトが決めた仕様の通りに実装が行われるのか。どうすれば多数の人が開発に参加する状況で概念的な整合性を維持できるのか。これらを達成するための技術について概略を以下に示す。詳細は原著のこの章を参照のこと。
仕様書としてのマニュアル
- マニュアルは外部仕様書であり、アーキテクトが作成する文章の中で最も重要である。
- フィードバックを受けて、マニュアルは開発中に何度も修正される。よって、マニュアルの版と改版日は実装担当者のためにきちんと管理すること。
- ユーザーが目にしない部分、つまり、実装の領分については記述しないこと。
- アーキテクトが10人いたとしても、マニュアルを書くのは1人か2人にすること。文体の、そして、製品としての一貫性を保つためである。
- 何が規定されているのかと同じくらい何が規定されていないのかも注意深く記述すること。
形式的記述を用いた定義
- 自然言語ではなく形式的記述を用いても良い。例としては、プログラミング言語の仕様でよく利用されるBNF（バッカス・ナウア記法）や、PL/Iで行われた形式的記述がある。
- 形式的記述は厳密だが、仕様がなぜそうなっているかの理由の説明に向かないなどの欠点もある。よって、自然言語との併用が現実的である。
- 形式的記述と自然言語を併用する場合には、どちらが基本となるものでどちらが派生物なのかを明記すること。どちらのやり方も過去に実例がある。
- 形式的記述を構文（syntax）以外にも使おうとすると実装に踏み込んでしまいやすい。したがって、形式的記述で規定しているのは外部仕様のみであること、そして、その内容が何であるかを明示するよう注意すること。
- 互換機の開発などで既に実装が存在する場合は、実装を仕様とし、その挙動を確認するテストを用意して、新たな実装をそのテストをパスするように作ることがある。しかし、このやり方には厄介なデメリットがある。例えば、エラー時の挙動などを仕様として規定しすぎる傾向があるのである。こうした挙動は、しばしば過去に誰からも検討されておらず、別の機種に実装しようとすると処理速度などで問題となるような仕様になりすい。そのため、注意が必要なのである。
アーキテクトによるソースコードのインターフェイス部分の記述
- モジュールのインターフェイスに相当する部分をアーキテクトが直接書いても良い。具体的には、関数や変数の宣言を書いたヘッダファイルをアーキテクトが書くのである。これにより、アーキテクチャを守らせることが出来る。
会議と意思決定の工夫
- 週に1回の会議と半年に1回の会議など、2つの異なるレベルの会議を設ける。
- 会議の出席者、誰が議長か、議題の種類、進行、焦点、資料などを工夫する。
- 会議だけでなく、その前後のプロセスや最終的な決定をいつどう行うかなどを工夫する。
始めから複数の実装を開発することが持つ仕様を守る効果
- 実装が1つの場合は、実装とマニュアルではマニュアルの方が修正が楽である。よって、実装とマニュアルに記述された仕様に食い違いが発生したときに、マニュアルにある仕様の方が変更されやすくなる。
- 実装が2つ以上あり互換性が必要な場合は、マニュアルと正しく動いている実装を直すよりも間違いのある実装を直す方が低コストになる。結果として、仕様に関して規律や綺麗な状態を保ちやすくなる。
アーキテクチャに対する質問への回答記録の公開
- 疑問を持った場合に実装担当者がアーキテクトに質問することは推奨されるべきだ。なぜなら、勝手に推測して作業を進めるよりも良いからだ。
- この質問と回答を他の人からも見られるような仕組みを作っておくと良い。この仕組みは略式ではあるが迅速で分かりやすい。
製品テスト部門との早期からの連携
- 設計が適切に理解されていなかったり正確に実装されていなかったりする部分をテスト部門は見つけ出すことが出来る。
- したがって、テスト部門にも適切に設計情報が届くようにして、テスト部門が早期に、そして、設計と同時に動き出せるようにすべきである。
他の章はこちらから：
「人月の神話」の要点
人月の神話の要点・ポイントをまとめています。原著に基づき、人月の神話の要点・ポイントを主に箇条書き形式でご紹介しています。
picolab.dev
2022.04.18
