意思疎通が図れない外部設計書は危ない
基本設計工程あるいはそれに準ずる外部設計工程に着手する際、みなさんは
・「誰に読んでもらって誰に理解してもらおう」と思って作成しますか？
・設計書を作成するとき真っ先に誰を想像して作業に取り組んでいますか？
→ レビューしてもらう開発プロジェクトのリーダー向けですか？
→ 後工程でプログラミングを担当してもらう技術者向けですか？
→ 納品後、保守や次期開発を担う次の世代の技術者向けですか？
→ 自分のためですか？
→ 誰のためでもなく言われたから仕方なくやっているだけですか？
もちろん外部設計書はリーダーも読むでしょうし、プログラミングを担当する技術者も見ます。レビュアーがほかにいればその人も査読することでしょう。
しかし最も大切なことは、開発を依頼してきたお客さまに読んでもらい、理解してもらうことです。
そもそも外部設計書は「お客様の提示された要求をきちんと仕様化した上で、そのことを私たちがきちんと理解しているかどうか確認していただく」ための資料です。外部と内部という言葉の違いはまさにそこにあります。
外部：プロジェクトチームの外側にいる人
内部：プロジェクトチームの内側にいる人
そのことを十分に理解した上で、上記質問に対して「お客さまに読んでもらって、開発者に理解してもらおうと思っています」と自信を持って回答できること（accountabilityを持つこと）が今の技術者に求められています。
外部設計書を、開発メンバーだけではなくユーザー、すなわち発注者に理解してもらうためには、
『いかに発注者にとって分かりやすい外部設計書を作成できるか』
『レビューを通じていかに合意形成を図るか』
という考え方が重要になります。どちらも"相手"をイメージしながら仕事しないとできないことです。
私は以前から、設計書は「モノづくりのため」に作るものではなく、
『様々な形でコミュニケーションツールとして使うもの』
と言い続けてきましたが、まさにそういうことなのです。
外部設計書を介してシステム像の共通認識を持つ
コミュニケーションの本質は
・情報伝達（伝えるではなく「伝わる」）
・情報共有
であると、これまでもお伝えしてきました。
外部設計書は、発注者（お客さま、ユーザー企業）が挙げた要件に対して、要件を満たすために
どんな情報システムとして実現するのか？
どんな機能を実現するか？
を、開発者（ベンダー）が明らかにし、まとめたものです。
ほとんどの場合、標準化された表記方法を使って作成されます。
外部設計書を作成する外部設計工程は、発注者と開発者が「この仕様でソフトウエアの開発を進めてよいですね？」ということを相互に確認し合意する最後の段階です。従って外部設計工程では、開発者が外部設計書の内容を発注者にきちんと伝え、発注者にその内容を理解し納得してもらうことが必要です。
また外部設計書は、開発者と発注者が意思疎通を図り、目的とするシステム像に関して共通認識を持って合意された内容になっていなければなりません。その努力を怠ると、後になってトラブルを招く元となってしまいます。
ところが、外部設計工程はたいていの場合「エンジニア主体の作業」で進められていきます。
本来"何を実現するか"を決定する場であるにもかかわらず、既に頭の中では次に進んでいるのか、それとも「作る」こと以外に興味が持てないのか、
"なにを作るか"
"どう作るか"
に固執した設計書や仕様書を作成してしまうのです。
エンジニアのみなさんには見覚えがありませんか？
基本設計、外部設計と言っているにもかかわらず、
・お客さまが認識できない専門用語が敷き詰められた設計書
・既に処理ロジックが書きはじめられている設計書
それらは本来「見せるべき相手」「情報を共有しあう相手」が誰なのかを見ていないからやってしまうことです。そこに集められたエンジニアの大半が恐らくは「お客さま」と意思疎通が図れるスキルを持っているはずだとしても、実際にはほとんどお客さまと向き合おうとしていません。
そのため、外部設計書も後続の作業であるソフトウェア開発を意識した「開発者の視点」で作成されることがほとんどです。外部設計書を「開発者の視点」で作成してしまうと、発注者が読んでもその内容を正確に理解することは容易ではありません。発注者は、自社内の業務や作業のプロではあっても、ソフトウェア開発のプロではないからです。
その結果、外部設計書の内容が発注者にうまく伝わらないまま、システム開発が進むことになります。そうなると、後の開発工程で
仕様の抜けや誤りが発覚して修正に多大な工数がかかる
といったトラブルが起こりやすくなります。
そうなると、発注者側が出来上がったシステムを見て「こんなはずではなかった！」と不満を持つかもしれません。お客さまを見ようとしなかったエンジニアの自業自得とは言え、これでは技術者の苦労も報われないというものです。
発注者に外部設計書の意図を伝えるために、説明が不十分な事項を適宜補足説明しているプロジェクトも多いことでしょう。
しかし、この場合も「開発者の視点」で作成してしまうと、補足説明の資料作成に多大な工数がかかる割には発注者側にうまく伝えられず、期待していたほどには理解してもらえません。
４つのポイントを押さえる
それでは、外部設計という限られた工程のなかで、発注者と開発者の間において
「目的とする情報システム像に対して共通認識を一致させる」
ためにはどうしたらよいでしょうか。社会生態学者のピーター・Ｆ・ドラッカーは、彼の著書「マネジメント」の中でコミュニケーションの４つの原理を説いています。その４つの原理とは、
コミュニケーションは知覚である
コミュニケーションは要求である
コミュニケーションは期待である
コミュニケーションは情報ではない
というものです。これはそのまま外部設計にも当てはまります。
①発注者が日頃使っている言葉や用語、図表を使わなければ伝わらない。
（コミュニケーションは知覚である）
②発注者の価値観や欲求と合致すれば理解され合意されやすくなるが、
合致しなければ受け入れられないか、抵抗される。
（コミュニケーションは要求である）
③発注者は期待することしか見ないし、聞かない。
（コミュニケーションは期待である）
④設計書をただ見せただけでは受け入れてもらえない。
（コミュニケーションは情報ではない）
発注者に外部設計の内容をきちんと伝えその内容について合意してもらうためには、まず発注者にとって分かりやすい外部設計書を作成したうえで、レビューを通じて合意形成を図っていかなければなりません。
そのためにはここで挙げた4つのポイントを頭に入れておく必要があります。
なお、ここに掲載するコツは「実践的アプローチに基づく要求仕様の発注者ビュー検討会（以下、発注者ビュー検討会）」が作成した「発注者ビューガイドライン」がベースになっています。
発注者ビュー検討会は「発注者が理解しやすい外部設計書の書き方と合意形成の方法」を検討する目的で、2006年4月12日に発足しました。検討会の参加企業は、NTTデータ、富士通、NEC、日立製作所、構造計画研究所、東芝ソリューション、日本ユニシス、OKI、TISの9社です（現在ではIPA SEC（独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター）に移管されており、同検討会は終了しています）。
発注者ビュー検討会では、参加企業の成功事例などから、設計書の書き方のコツやレビューで合意形成を図るうえで効果的なコツを集め、合計187個のコツとその利用例を「発注者ビューガイドライン」としてまとめました。
様式としては若干古くなってしまっているのと、大手SIerだからこそできる部分もあるため、一概にこれらの187個のコツが使えるわけではなくなっていますが、その本質的な考え方自体は今でも普通に活きるものでありながら、それらの考え方や仕組みをまともに活かせていないプロジェクトが多く存在していることは残念なことです。
ちなみに、accountability（アカウンタビリティー）とは、意訳すると
"説明責任"
と言います。多くの人が間違って理解していますが、"説明責任"は"説明する責任"ではありません。たしかに"to account for"という動詞は「説明する」という意味です。しかし、この言葉が本当に意味するところはそういう広義の意味ではありません。
Wikipedia のaccountability のページの説明にそって解説すると次の通りです。
AがBに対して "accountable" であるということは、
AはBに対して自分の行動や決断を説明、正当化し、
また不正行為を働いた場合は、処罰を受け入れる義務を負う
ということです。つまり「説明責任を果たす」ということは、
与えられた権限を行使し自らの役割を果たし、もし任務に失敗したり、何か不正を働いた場合は、その責任を負う。
という意味です。もちろんその不正や失敗の経緯を明らかにするいう意味合いもありますが、より大事なのはその責任の所在が自らにあることを認め、ペナルティを受け入れるということです。その覚悟を持ったうえで説明を行い（言葉を発する）、それだけの覚悟および自信を以って取り組みなさい…と言われているわけです。
諸外国から「誰もが責任を避け、どこにも責任をとる人間のいない無責任社会」と評される日本の文化では、なかなかイメージできないものなのかもしれません。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。