ドキュメントを作っている余裕がない---。多くのSE，開発者に共通する悩みである。開発期間の短縮，ビジネス変化への追随などで，ドキュメント作成の負荷が今まで以上に高まっている。しかし，ドキュメントを全く作成せずに，システムを開発/運用していくことはできない。リスクを考えながら，無駄なドキュメントを減らし，範囲を絞って確実にメンテナンスしたい。
ドキュメントがないとシステムに手をつけられない---。ライオンは2年前，業務の効率化を進めるために生産購買管理システムを見直すことにした。ところが，ドキュメントが全く残っていないという問題が発覚。同システムは1985～86年にエンドユーザーが中心となって開発したもので，ドキュメントがないまま運用されていた。
口頭レベルでは引き継ぎがされていたものの，担当者は既に4代目で，問題が起きても対処できないような状況になっていた（図1[拡大表示]）。これではシステムを見直すにも手のつけようがない。下手に修正すれば，どこに影響を及ぼすか分からない。
結局，同システムは横河情報システムズが販売するERPパッケージ「iRenaissance」を利用して再構築することになった。2003年6月に無事カットオーバーできたが，再構築には苦労した。「画面や帳票から機能を想像するしかなく，テストした結果が同じになるまで修正を繰り返した」（統合システム部 主任部員 宇都宮真利氏）。
今では，「EUCに懲りたので，使い続けるシステムはエンドユーザーに開発させない。エンドユーザーにドキュメントを書かせるわけにもいかないので，任せるなら“使い捨て”と割り切るしかない」（同氏）と考えている。
負荷は増すばかり
最近では，短期開発やビジネス環境の変化で，ドキュメント作成の負荷が今まで以上に重くのしかかっている。「忙しくてドキュメントを作成，メンテナンスしている余裕がない」という悩みは多くのSE，開発者に共通するところだ。経験のない新しい言語や開発環境を採用すれば，何をドキュメントに残せばいいのか分からないという問題も出てくる。
ただ，そうはいってもドキュメントを作成するモチベーションはなかなか上がらない。システム稼働前であれば大きな負荷となって足を引っ張るし，稼働後は自分で保守運用しているかぎり必要性を感じない。「必要だけど，一番手を抜きやすい」（東建コーポレーション 経営開発本部 マルチメディア開発部 部長 小山伸治氏）。ドキュメントを作成しているくらいなら，先にプログラムを書いてしまった方が早いケースもある。「if文の条件を変えた，消費税を3％から5％に変えた，などはソースコードを修正するよりもドキュメントを書き直す方がよっぽど時間がかかる」（住友林業 情報システム部 マネージャー 宮下敬史氏）。
結果，本来あるべきドキュメントが残っていない，残っていてもソースコードと乖離かいりしている---という状況に陥ることになる（図2[拡大表示]）。
変更/引き継ぎができない
もちろん，ドキュメントがなくてもシステムは動くし，最終的にはソースコードを確認すれば現状を調べられる。しかし，ライオンの事例からも分かるように，ドキュメントがないとシステムを維持管理できない。規模が大きくなればソースコードを追うだけでもかなりの手間がかかるし，業務要件や設計ルールを知らなければソースコードを見てもすぐには理解できない。
機能追加やバグの修正，リプレースがない場合でも問題は起きる。ドキュメントがなくシステムが属人化した状態だと，「システムの運用をベンダーにアウトソースすることにした」「担当者が病気になった」「異動/退職した」といった場合に引き継ぎができない。実際，ライオンでは人事システムの担当者が退職するため，急きょシステムを再構築した痛い経験がある。
新しい担当者が入ってきたという場合も同様だ。「忙しくて教えている暇はない。ドキュメントを読みながら勉強してもらうことになる」（GMOメディアアンドソリューションズ 取締役 システム本部 本部長 堀内敏明氏）。特に大企業の場合はベンダーや新入社員の出入りが多くなる。一人ひとりに一から説明するよりもドキュメントがあった方が最終的には効率が良くなる。ドキュメントは“必要悪”と考えて取り組んでいくしかない。
無駄をなくし確実にメンテする
では，設計書や仕様書といったドキュメントを効率良く作成，メンテナンスしていくにはどうすべきか。ドキュメントはたくさん作ればいいというものではない。後で誰も読まなければ無駄に終わるし，メンテナンスできなければ無意味だ。「ドキュメントがあってもメンテナンスされている保証はないし，信用できない」（ウルシステムズ 執行役員 兼 CTO 山岸耕二氏）という結果になる。無駄なドキュメントはできるだけ作成しないようにし，範囲を絞って確実にメンテナンスしていく必要がある。
その上で，ドキュメントを標準化/共有したり，ベテランのSEが品質をチェックしたりする体制が不可欠である。せっかくドキュメントを作成しても，「何が書いてあるのかが分からない」では元も子もない。
ドキュメントが目的ではないドキュメントは人間同士のコミュニケーションを補う役割を果たす。コミュニケーションがうまくとれていない環境では，ドキュメントにしわ寄せがくる。ドキュメントに問題があると思っていても，実は「ドキュメント以外の部分に問題があることが多い」（カブドットコム証券 代表取締役COO 齋藤正勝氏）。仕様変更が多い，大規模でシステム構築にかかわる人数が多い，開発と運用がバラバラ---などである。 そのため，これらの要素を排除できれば大きな効果を得られることが多い。例えば，ユーザーや開発者同士のコミュニケーションを頻繁にとることで，意思疎通を図るXP（Extreme Programming）による開発を進めれば，仕様変更によるドキュメントの書き直しは減り，負荷を大幅に削減できる。何が原因でドキュメントが問題となっているかを把握し，その原因を取り除くことが負荷削減の近道になる。標準化などの体制作りは有効だが，決してドキュメントの作成自体を目的としてはならない。 |
