ドキュメントという資産の考察(2)

これまでの経験において、色々な状況や立場において、ドキュメントが無くて困っている状況があった。
一言でシステム開発と言っても、アプリを作り込むことだけでなく、サーバーや動作環境も含めたインフラ整備も必要なことも多い。
運用がエンドユーザーに移っている場合、そもそものサーバー設定資料が何も残ってない場合がある。
最初の立ち上げ時には作っているはずなのに、日々の運用手順だけで事足りるからと、いつの間にか何処かに行ってしまって、次期システム開発時には、旧サーバーを調査するのも作業に入ってくる事になる。
しかも、そういう時に限って、アプリ側の資料も残ってなかったりする。
そうなると、新システムとのインタフェースになる部分の調査をして開発する事になるが、得てして、本番運用後に想定外のデータが連携されてシステムダウンしたりする。
開発会社として考えた時、前回のプロジェクトでも、同じメンバーで同じ不具合を経験していたにも関わらず、また同じ部分で躓いたり、同じ調査を繰り返したりする。
どちらも作業者や担当者の知識に依存していて、管理者が先を見据えた判断が大事だという発想に至らない。
その結果、エンドユーザーは動かないコンピュータをつかまされ、開発者は泥沼に入って行く・・・

ドキュメントという資産の考察(1)

新規で作り始めるプロジェクトは楽しい。何のしがらみもなくて、純粋にお客さんとベストなモノを考えていける。
しかし最近のプロジェクトは、そんなのはあまりなくて、大抵の企業は既に何らかのシステムが導入されている。
ハードウェア的にも、アプリ的にも、また時代の流れで業務がかわったりで、旧システムをリプレースしたり、機能追加したりする。
新規システムでも、旧システムとの連携は必須で、全くの新規は本当に少ない。
そんなプロジェクトを幾つもやってきて、毎度の様に困るのが、現行システムを理解する為のドキュメントの少なさ。
全く残っていないという悲惨なシステムもある。
運用する事だけを考えたら、大抵のシステムで担当者が熟知しているから、それ程に大きな問題が出ずに動いてたりする。
逆に、それが問題の本質を誤魔化せてしまってるように感じる。
とにかく、そういうシステムが多くて、開発者は大困りと嘆くんだが、よく考えたら自分もその開発者の一人だと思い出す。