Part1●効率化を図る
リスクを考えながら無駄をなくす
ドキュメントを大幅に削減したいのであれば，開発プロセスを見直すのが最も効果がある。ユーザーや開発者同士の意思疎通が図られ，お互いの合意がとれているのであれば，ドキュメントは省略可能だ。この特徴を最大限に生かしたのが，XP（Extreme Programming）による開発である。
ただ，XPを含め，お互いの合意がとれている状態にするのはかなり難しい。規模が大きくなればそもそも困難になるほか，ユーザーの立場からするとリスク回避のためにどうしてもドキュメントが不可欠になる。開発プロセスの見直しが難しい場合は，合意がとれているものは省略する，できるだけ再利用する，などして地道にドキュメントを削減していくしかない。
開発プロセスを見直す
一般に，システム構築では要求→分析→設計→実装→テストといった手順を踏んでいくが，このようなプロセスではドキュメントを大幅に削減するのが難しい。業務要件定義やシステム設計書，プログラム仕様書などは，システム構築にかかわる人間同士，すなわち，エンドユーザー，情報システム部門，ベンダーSE，プログラマなどがお互いの認識をすり合わせるために不可欠となるからだ（図3[拡大表示]）。合意を得て，はじめて次の工程に進むことができる。これを無理やり省略しても，後工程で手戻りが増えるだけだ。基本的に，どんなに短期の開発と言えども，省略はできない。
清水建設では独自の開発プロセスをとることで，上流工程の効率化とドキュメントの大幅な削減に成功した。以前は，ユースケースごとにシナリオを書き，アクティビティ図やシーケンス図，コラボレーション図などを作成してから必要なクラスを抽出していた。しかし，「膨大なシナリオを書いてもユーザーに『これを読むのか』などと言われる。仕様が変わるたびにユースケース図やシナリオを変更しなければならず効率が悪かった」（情報システム部 課長 安井昌男氏）。
そこで，LFD（Lane Flow Diagram）と呼ぶ独自の業務フロー図を利用して業務設計を進めるようにした（図4[拡大表示]）。LFDでは業務を遂行するユーザーを列にとり，誰が何をトリガーにどのような処理をするのか，その後は誰が処理するのか，といった業務の流れを図にまとめる。(1)業務対象とシステム化対象を明確にする，(2)業務の全体像をとらえ，要件を可視化させる，(3)業務フローを実現するために必要なエンティティを抽出する---という3つの目的で使用する。
検討会で徹底的に仕様を詰める
LFDを作成したら関連部署のキーパーソンならびにベンダーと共同で集中検討会を開き，HTMLの画面モックアップを使って仕様を徹底的に詰めていく。エンドユーザーとベンダー用に別々のドキュメントを作成するようなことはしない。エンドユーザーが見ても分かるドキュメントであれば，ベンダーが見ても分かるという考えからだ。「結局は誰が何を処理しているのかが分かればいい」（安井氏）。
集中検討会では，どのような処理が不足しているか，どのようなデータをどのような画面で表示すべきか，などをエンドユーザーから聞きとり，丸々1日を使って仕様を決める。ユーザーに指摘された部分はその場で修正し，ホワイトボードなどを利用してすぐに確認してもらう。シナリオの書き直しといった面倒な作業は発生しない。
LFDで仕様を固めると，概念クラス図→設計クラス図→実装クラス図と詳細に落とし込んでいく（図5[拡大表示]）。これに，E-R図とメソッド詳細仕様書を加えたものが最終的なドキュメントになる。「各工程のアウトプットは必ず次工程のインプットにする」（情報システム部 野田伊佐夫氏）ことで，無駄なドキュメントの作成を防いでいる。
省略と流用で地道に減らす
清水建設のように開発プロセスから見直すのが理想だが，ベンダーを交えて新しい開発プロセスを導入，実践していくにはかなりのスキルと体力がいる。情報システム部門が中心となってプロジェクトを進めるのはもちろん，ベンダーのSEなども教育しなければならない。そのスキルと体力がなければプロジェクトが失敗する可能性もあり，リスクが伴う。
開発プロセスの見直しが難しい場合は地道に減らしていくしかない。具体的な例としては，(1)複雑なもの/代表的なものだけを残す，(2)後工程で再利用できるように作る，(3)他のもので代用する---などがある（図6[拡大表示]）。
(1)は，ロジックが複雑なものだけをドキュメントに残し，後は省略する。例えば，「シーケンス図は成功するパスと失敗するパスを1つずつ作成し，後は省略することがある。シーケンス図を作るよりもコーディングした方が早いし，ソースコードからシーケンス図をリバースして作れるツールもある」（ウルシステムズ シニアコンサルタント，テクノロジ 中村正弘氏）。次の工程に進むためのものであれば省略のしようがないが，結果としてあればいいものならツールを使って自動生成することも検討したい。
(2)の再利用の例としては，詳細設計書の一部をテスト仕様書に流用する方法がある。テスト仕様書での流用を前提に設計書を作成する。条件分岐による処理フローの違いをまとめた制御パス，入力と出力の対応関係をまとめたデシジョン・テーブルなどを図や表にして設計書にしておけば，ロジックが分かりやすい。
画面仕様書はなるべく作らない
(3)の代用の例としては，画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減る。これは帳票にも同じことが言える。
プロトタイプは，最初から本番を想定して作る。「同じ数値の羅列，空欄だけになっている画面や帳票を作成しても，本番とイメージが全然違う」（住友林業 宮下氏）。結局，手戻りが発生してしまう。「今はこうなっているが，本物はこうですというのも駄目。微調整は後でやればいいと考えていると，後で微調整だらけになる」（同氏）。
画面や帳票は一生懸命作ってもすぐに変わってしまう。どうしても仕様書が必要な場合は「なるべく後工程で作り，手戻りを少なくするようにする」（ウルシステムズ 中村氏）しかない。
常にリスクを考える
ドキュメントを省略する場合は，そのリスクを常に考えることが重要である。ドキュメント作成の負荷が減っても，その結果手戻りが発生して工数が増えたり，工期が延びたりしてしまったのでは逆効果である。リスクを減らすために，ドキュメントが増えてしまうこともある。
最近では，中国やインドなどに開発を委託する「オフショア開発」が増えているが，この場合はドキュメントが非常に重要になる。「どうしてもコミュニケーション・ギャップが生じる」（ガリバーインターナショナル ITアプリケーションチーム ITインフラストラクチャチーム 統括リーダー 宮崎哲明氏）からだ。「仕様書でかなり細かい指示を出しておかないと誤解を招きやすい」（住友林業 宮下氏）。
中電技術コンサルタントの場合，「相手にドキュメントを読む力がないような場合は別の資料を作る。相手を納得させないまま進め，後でひっくり返される方が怖い」（情報化推進室 部長 中村仁士氏）。また，「必ずしもSQL文を分かっている人がプログラミングしているとは限らない」（同氏）ため，開発に入る前には必ずSQL文をチェックする。複雑な場合は自社で書いて渡すこともある。
稼働後に何を残すべきか
ドキュメントの中には，開発工程で必要なだけで，稼働後は不要なドキュメントも多い。とはいえ，「後で使わないと分かっていても捨てるのは勇気がいる」（富士フイルムコンピューターシステム システム事業部 主席 菊谷哲夫氏）。ベンダーを変更しなければならないような状況に陥ったときに，ベンダーから見てどのようなドキュメントがあると望ましいかをまとめたのが表1[拡大表示]だ。
当たり前だが，もっとも重要なのはソースコードである。最近はソースコードからクラス図などを生成できるツールも充実してきており，ソースコードがあればかなりのことを調べることができる。しかし，それでは分からない，あるいはソースコードから理解するのは時間と手間がかかるというのが他のドキュメントである。基本的には「リバースをかけても分からないものを残しておく」（日本ユニシス サービスビジネス開発本部 メソドロジ＆アーキテクチャ部長 羽田昭裕氏）。
中でも重要度が高いのが，業務要件，業務用語/設計ルールである。ソースコードを読んでも，そのシステムがどのような目的で開発され，何をしているのかが分からなければ再構築できない。ネーミング・ルールなどの設計ルールがあるのとないのとでもソースコードの理解に大きな差が出る。
これに加え，非機能要件，インタフェース仕様，テスト仕様/結果などがあれば，現状を分析するための工数を大幅に削減できる。テスト仕様/結果は，「後で問題が起きた際にテスト漏れがなかったかどうかを確認できるだけでなく，ベンダーの評価にも役立つ」（東建コーポレーション 小山氏）。
メンテナンスする範囲を絞る
稼働後は機能追加やバグ修正が発生する。そのたびにすべてのドキュメントをメンテナンスするのは非現実的だ。メンテナンスするドキュメントを絞り，確実に更新していくことが重要である。中途半端は駄目で，「メンテナンスを一度でもやめてしまうとその仕様書は無意味になってしまう」（東京海上システム開発 プロジェクト推進本部 品質管理部 コーポレートソリューションプロデューサー 小野直子氏）ので注意したい。
最低限メンテナンスを実施すべきものとして多くの企業が指摘するドキュメントが，システムの変更履歴だ。「何のためにやるのか，課題と解決策，具体的な機能を明確にしておく」（ガリバーインターナショナル 宮崎氏）。この“なぜ”という部分が分からないと，「第三者が見たときに削除してしまう恐れがある」（東京カンテイ システム部 課長代理 瀧内誠氏）。
変更履歴はID番号で変更一覧と詳細を紐付けする。その際，ソースコードにもID番号と変更履歴をコメントとして埋め込んでおくと便利である。後で確認する際に関連性が分かりやすくなる。
ソースを勝手に変更させない
ドキュメントとソースコードが乖離するのは，「ドキュメントを直さなくても，コードをちょこちょこっと変更できてしまうから」（東建コーポレーション 小山氏）。変更履歴を管理するだけでは不十分で，ソースコードを勝手に変更させないようにしなければならない。軽微な変更でも，必ず申請しなければソースコードを変更できないように運用している企業が多い。
GMOメディアアンドソリューションズは，オープンソースのバージョン管理ソフト「CVS」を使い，必ずCVS経由でソースコードを修正する（図7[拡大表示]）。修正した場合は関係者全員にメールで通知される。消費者金融のシンキの場合，システム構築を手がけたフューチャーシステムコンサルティングが作成したWebシステムを使い，システムの障害や変更履歴を管理している。
