煽りタイトルがついているが別に「ソースコードの内容を一語一句Excelに日本語化してでIf文ごとにブレークダウンしたりするドキュメント」をdisる記事ではない。
隣の火事
隣のプロジェクトでちょっとした炎上があったのを見たのがきっかけで、日々ドキュメントに対して抱いていた色々な悶々がついにこみだしてた。 たぶんバレたら怒られる類のものなので、匿名化は心がけようと思う。
なにが起きたのか
舞台となるのは、いわゆる下流システム、各発生したデータを収集しレポーティングするサブシステム領域の話になる。
既存システムも例外なく"ワケあり"で、基盤が比較的新しく技術的負債の面からはまあまあマシであるものの、 ユーザーUIや「外部」システム間インタフェース以外のドキュメントが壊滅的であり、特に各プログラムの挙動を規定する「詳細設計書」というものがなかった。
そして最近、そのサブシステムにある程度重点をおいた機能追加プロジェクトが発足した。（ちなみに、下請けを出さず設計開発すべてを一次受けでまかなっている） メンバーは新規参画者が多かったものの、要件定義フェーズの名目で調査・設計の工数を多く見積もりナレッジを取り込みつつ進捗させるねらいがあるように思えた。
アウトプットとして設計書が積み重なりやっと手を動かして開発が進める段階に至ったとき、急に大小の設計方針転換がいくつも発生した。 ウォーターフォール的にいうと、「前工程である詳細設計フェーズの品質が悪かったから」といえる典型例なのだが、起因についてもうちょっと踏み込んでみる。
開発プロセスは属人的なもの
あくまで個人的な見解としては、プロジェクトが炎上した直接要因は「保守チームがドキュメントに頼らず人依存でまわしていたシステム運用・開発を、別メンバーだけで回して実現性検証も不十分な設計をしてしまった」ことと思っている。
各個人への依存度が高い属人的な開発プロセスを継承したため、掛け算で不安定な幅が大きく悪いほうに振れた、とも言い換えられる。 （余談：こういう汎用ワードを使った抽象化は現場を理解していないマネージャーっぽくて嫌い）
一定のドキュメントを作ることと標準作業が定められていないなか、各位確保した工数に見合うことをする。 作るものによって作業を変容させるのは理にかなっているが、プロジェクトのコンディションの評価を難しくあるいは煩雑にする要因でもある。
「そもそも、開発プロセスは至極属人的な作業じゃないか？」と声があがる気がするが、 だからこそUMLや古くは業務フローチャートやDFDなどといった定型の規格や表現・規定方法・何より評価プロセスを統一することを目的としたツールが生み出され、 今日少しでも属人性を低減させるために運用されている。
設計書の役割
ドキュメントはコミュニケーションツールの側面が強い。
外部設計・基本設計と呼ばれるドキュメントを顧客や社外の人間と共有・承認し、共同で責任をもつ合意書とする。 内部設計・詳細設計と呼ばれるドキュメントは実装者・作業者への指示内容とし、膨大な実装作業の指針とする。
当プロジェクトにおいて、バッチ開発やテーブル設計になどの設計書は一通り作られ、そして上記のとおりの使い方をしていたが、それ以外、例えば有識者へのレビューは実施されなかった。 「実装指示書」という側面として利用したが、「有識者の一致認識」とはされなかった。
「詳細設計書」なんて架空の言葉でかたづけるな
そのまま、属人性に振り切ることを許容してしまった最後のトリガーとなるのだが、 実装につながる詳細設計書がモノがあるだけで「イケてるように見えていた」のが大きな失敗のひとつで、一番いいたいのはここになる。
「詳細設計書」とは何なのか？ウォーターフォールだったとして、実装工程のインプットとなれば何でもよいのか？ 開発プロセスを安定化するためのツールと知恵であって、納品するだけの成果物ではない。
そういう意味で、「詳細設計書」というオブラートに包んだ言い方が嫌いだ。 実績がなく単価の安い下請けに流すとして、実際は実装指示書なんだから「Javaコード実装指示書」と書けばいい。 実際に実装した画面のキャプチャをコピペして作る後付けの画面設計書は、実際は実装済みの画面を確認するものだから「画面説明書」という名前だと開発工程にあった適切なドキュメントとしてわかる。
私は口下手でドキュメントにおこしてコミュニケーションをとることを常套手段としていることもあり、 どんなに、受領する人間にクリエイティビティを期待しない、つまらないドキュメントであっても、 その役割とビジネス的な側面がある以上、私は否定しない。
だが、ただ流されるままに作業して、ステークホルダーの安心を買うだけ買って、実態のない「詳細設計書」というものを中心にソフトウェア開発が進むのは、ソフトウェアエンジニアリングを素人同然のレベルまで落とすことに等しいと主張したい。
だから「詳細設計書」という言葉はなくなればいい。 開発プロセスを体現する名前の設計書が言葉をもって規定され、 ソフトウェア開発のリスクを狩りとるツールとして磨きをかける動きの一助になればいい。 作業者が必要と思っているコミュニケーション事項の明文化こそがドキュメント作成の要務であり、既知の定型文書として存在しないことは素人が知る前に怖がっているだけだ。
