SIerの設計書は無駄なのか？

始めに

　近年、Web系キラキラ企業の人達からはSIerが作成している設計書は無駄という声が聴こえる。これについてSIerのインフラ担当者として、歴史解説と意見を述べたい。

結論（インフラ領域に限定しています）

　インフラ領域に於いては従来型の詳細設計書は不要になる。一方、方式設計、基本設計書の重要性は増加し拡充が必要となる。

詳細設計書は不要になる

　筆者は、詳細設計書は不要、もしくは必要頻度の高い情報を集約したもののみで良くなると考えている。

　歴史的経緯を考慮すると、特に本番環境は変更頻度が低くリモート接続が充実していなかったため、紙に大量のパラメータ類を記載して残す必要があった。またWindows環境はGUIによる操作容易化の反面、一覧性が低下していた
という事情もある。

　しかしながら現代では、変更頻度が高くなり詳細設計書へ反映が不十分な場面が増加している。また、リモート接続の普及により調査が容易になった。パラメータ確認には不正確な詳細設計書より、環境の現物を確認した方が確実なのである。
　加えてインフラ構築の自動化（Infrastructure as a codeなど）により、パラメータをコードで出力可能となった。これはExcel方眼紙の詳細設計書を十分に代替する。
　現代では、Excel方眼紙の詳細設計書は技術力のないエンジニアがGUIをExcelに1文字づつ手作業で心を込めて転記する「写経」でしかなく、本質的な価値はない。
　それよりは変更後に各種パラメータを出力してファイル保管した方が検索も容易であり、万一の復旧にも活用可能である。

　残るのはIPアドレス、ホスト名、認証情報の一覧等のパラメータを操作時に利用し易く加工したものであろう。

方式設計、基本設計書の重要性の増加と拡充

　方式設計、基本設計書の重要性は増加する。
　ビジネス環境変化の高速化に伴うITシステムへの機能追加変更頻度が高まっており、追加変更する際「変更して大丈夫なのか？」という判断の頻度や難易度が高まっている。

　変更可否は設計書を確認して判断する建前である。
　一方、大半の方式設計、基本設計書は「方式Aです」と記載されているが「方式A,方式Bが採用可能ですが、要件Cを鑑みて方式Aを採用しました」と記載しているものは殆どない。よって、設計書を見ても判断できず当時の担当者を呼び出して「〜って変更しても大丈夫？」と質問するのが常である。
　当時の担当者が捕まっても油断はできない。「前のシステムが〜だったから」と前例踏襲しているだけで「方式設計していない」事例は多い。

　これはクラウド時代でも変わっていない。むしろクラウド時代はGUIをポチポチ操作するだけで何となく動作して、クラウドの高可用性のお陰で見掛け上のトラブルが少ないシステムが増加している。

　本来、設計書は「方式A,方式Bが採用可能ですが、要件Cを鑑みて方式Aを採用しました」の形式で記述するべきだがエンジニアには広範囲の技術理解が必要となり工数も増え、利用者には構築時点での付加価値が直ぐに感じられないため、普及しているとは言い難い。
　さらにインフラ領域では「提案書」が要件定義と方式設計を代替している例がある。提案時の要員と質が不十分で「取り敢えずHWベンダに丸投した見積を基に提案」して、基本設計は急に呼ばれたエンジニアが「提案書に基づいて〜を採用、方式Aです」と記載したものが稀に良く見掛ける。この場合、方式を理解している人間が誰一人おらずトラブル発生時に容易に詰んでしまう。

　類似事例では「VBA」「RPA」と言ったEUCや自動化ツールのメンテナンス問題がある。これらも迅速な立ち上げは促進するものの、判断基準や考え方と言った難易度の高い思考の文書化が追いついておらず、後日苦労する例が増加している。

ウオーターフォールの建前と現実

　SIerはウオーターフォール設計が建前である。その建前を信じるなら、基本設計書を記述するには要件定義書を読むだけで良い筈である。同様に詳細設計書を記述するには基本設計書を読むだけで良い。
　現実では詳細設計と構築は安価なパートナーに丸投げされており、詳細設計の基準、規範は「基本設計書を読む前に元請けに質問」するエンジニアが大半である。
　例えば詳細設計書に記載されたWindows Server OSの機能と役割は、基本設計書に記載された各サーバの業務機能やシステム上の役割、それらを何で実現するのか（OSの機能と役割、他のミドルウエアなのか等）から導かれるのだが、そこまで丁寧に記述する基本設計書は少ないし、記述しても基本設計書をきちんと読む技術者も少ない。
　パートナーには「写経」の工数で設計書を読み込んで欲しいのだが、高レベル要員が担う「理解のための工数と体制」を省略する代わりに、低レベル要員で対応可能な「パラメータ写経」「確証スクリーンショットをExcel方眼紙に貼る」工数が水増しされた見積が届くSIer業界多重構造の闇は終わりそうにない。

終わりに

　筆者はSIer側の人間であるが、上記の悪しき慣習は変えていきたいと強く思っている。また、アジャイル開発、クラウドのPaaS,SaaS普及によるリリース期間の短縮で起きやすい設計思考、思想の非文書化を懸念している。
　悲観的な事ばかり書いてしまったが、エンドユーザやSIerの評価基準が変われば改善しやすいとも言えるのである。皆様の前途が明るいものでありますように。