【いわゆる神エクセル？】システム開発の設計書を、エクセルで作ってしまう日本の悪習。設計書は、スリム構成、マークダウンで作るべき

こんにちは。

システム開発の際、ビジネスパートナー（SIerなどの外注先）との意思疎通に用いられる設計書。

筆者の周辺だけの傾向なのかも知れませんが、本来、表計算ソフトであるはずのエクセルを使って、設計書を作るという文化ができている企業が少なくないと感じます。

市役所の帳票にはExcelで作成されているものがあり、見栄えを整えるためだけに、セル結合や罫線が多用された結果、本来の表計算ソフト（データ収集などの機械的処理）の利点が生かせなくなるという、いわゆる「ネ申エクセル」問題も発生しています。

本記事では、情報システム開発の現場で発生している「ネ申エクセル」問題に踏み込んだ上で、今後、日本のITエンジニアの目指すべき方向性について提言したいと思います。

「ネ申エクセル」問題によって、情報システム開発の現場に起きている問題

テーブル構造定義や要件一覧リストなどの「表」が多く含まれるという性質上、システムの設計書にエクセルが活用され始めたという推移は、容易に想像できます。

システムの設計書をエクセルで作ることによって、以下のような弊害が生じていると筆者は感じています。

これらは（数多くある弊害の）一例にすぎません。

エクセルを使うことが非合理的であると（頭では）分かっていようと、多忙なエンジニアが改善業務を優先することは難しく、いつまでたっても断ち切られない「悪習」として根付いていくのでしょう。

設計書は本来、シンプルであるべき。設計書の品質と、システムの品質には、強い相関関係があるので

設計書を解釈するのがコンピュータであれば、どれだけ長かろうと、どれだけ複雑なパターン分岐があろうと、記載事項にミスがない限り、システムは欠陥ゼロで完成するでしょう。

実際には、設計書を手に取って読むのは人間であるため、プログラム完了時の品質は、設計書の良し悪しをダイレクトに反映したものになります（設計書の品質がショボいほど、納品されるプログラムの品質も低下するため、設計書の品質は、システムの品質と強い相関関係があると思います）。

エクセルを使って設計書を作ると、「弊害」でもあげたような問題が発生するため、読み手も書き手も消耗し、本来、品質を担保するために費やされるべきパワーが、おそまつな設計書の解読作業へ分散されてしまう結末が待っています。

逆の発想をすれば、効率よく情報伝達できる設計書の書き方スタイルを確立すれば、完成するシステムの品質も、うなぎ上りに上昇するでしょう。

このような観点で、設計書とシステムの品質について考えたとき、「ネ申エクセル」ってやっぱり是正されるべき問題だということになるのです。

構造化・細分化を意識した設計書づくりが、設計書の品質担保に貢献し得るという話

これまでを通じ、以下の３点について述べました。

本記事を締めくくる前に、もう少し深堀して、本来あるべき設計書の姿について論じておきましょう。

人間はミスをする存在です。

個人差はあろうと、書く側も、読む側も、ミスを犯す可能性をゼロにすることはできません。

そこで重要となる、設計書作成上のキーワードは、構造化と細分化の２点です。

本記事のテーマからはみ出るため、あまり詳しく論ずることはできませんが、骨子となるアイデアのみ記載します。

構造化について

ドキュメントの構造には、スタイル（h2, h3, h4, ul, ol）を必ず適用します。

また、一度決めたドキュメントの構造は、プロジェクトが終わるまで一貫して、すべてのファイルに対して適用することが重要です。

こうすることによって、書き手も読み手も、頭の中に「フレームワーク」が完成し、次にどのようなコンテンツを書くか（読むか）について、共通認識が形成でき、コミュニケーションミスが激減します。

細分化について

一つあたりのドキュメントに書く内容（のスコープ）を小さくすることも、検討しましょう。

たとえば、従業員マスタ情報のメンテ機能を作成する場合、設計書を以下のように４分割することで、（書き手にとって）記述スコープ、（読み手にとって）読解スコープが限定されることになり、成果物（設計書、ソースファイル）の品質を担保することにも寄与します。

一つの設計書で記載できるところ、四つもの設計書を作るなんて無駄だと感じるかも知れませんが、いちど騙されたと思ってやってみてください。

いろんなメリットを実感できると思いますし、一つの設計書にあれこれ詰め込むよりも、最終的には時間が短縮できることもあると思います。

エクセルよりは、マークダウン。良い設計書を作るための強制力にもなり得る

「ネ申エクセル」の話題に始まり、設計書の理想論（構造化・細分化）までお話しました。

本記事で書いたようなことを実業務で実践するには、エクセルではなく、マークダウンによる設計書作成を念頭に入れるべきだということを最後に付け加えておきます。

エクセルに慣れ親しんだエンジニアであるほど、マークダウンへの移行には抵抗があるかも知れませんが、構造化・細分化を意識してドキュメントを作るためには、マークダウンほど最適なツールはないと思うのです。