フロム「ずくだす」

アスリートにはレジャーとしてスポーツを楽しんでいる人は含まないようです。すくなくとも、自らの気力・体力の限界を伸ばそう、超えようとする人こそアスリートにふさわしい人でしょう。つまりスポーツを通じて、自分や他人の気力・体力の限界、つまり記録に挑み、記録を残そうとする人がアスリートです。

この『記録に残すことが大事だ！』という点が、システムとの共通点です。

システムと記録

システム開発では、多くの文書＝記録を作ります。提案書＞外部仕様書＞詳細仕様書＞プログラム仕様書＞検収仕様書＞検収手順書＞操作説明書等々、システムの半分は記録でできている　といってもいいでしょう。

東証のトラブルも記録の不備が原因だった

しかし、開発作業が切羽詰ってくると、往々にして記録を残すことが後回しになることがあります。かの東証（こちらの藤商ではなく、東京証券取引所のほうです）のトラブル・・・東証もこのところトラブルが多発しているので東証のトラブルだけでは不十分ですね・・・去年の１１月１日システム変更に伴う月替わり処理の際にシステムが半日に渡り全面ストップしたトラブルです。システム変更時に作成した作業指示書に記載漏れがあったことが原因だとされています（ こちらのサイトを参照させていただきました）。システムの増強に終われ、作業優先となり、何とか納期に間に合わせてホットして、つい記録を忘れてしまった・・・・・・システムの開発者としては、多分こんなところだったんだろうな？などと勝手に想像しています。

何億円かけたシステムであろうと、いかに優秀な人材が手がけたシステムであろうと、記録をキチンと残していなければ、トラブルは防げない　という教訓でした。

開発初期段階での記録の重要性

トラブルはシステムのバグだけではありません。バグも怖いのですが、それより恐ろしいのが、言った言わないのトラブルです。

システム開発の初期＝クライアントの要望を元に要件定義や基本設計を行う段階では、ユーザとの打合せ内容を記録して確認し、その記録を元にシステムの要件を定義し、その要件定義を元にシステムを基本設計する　という作業が主となります。文字通りシステムの基本を決める、極めて重要な段階です。最低でも２，３ヶ月、時として半年や一年もかかることがありますが、この間、自分の言ったことを正確に記憶している人はマレです。ひどいときにはつい一週間前の発言と逆の意見が飛び出したりします。そんなとき頼りになるのは記憶ではなく、記録です。記録を残し、双方の確認がなされていれば、無用なトラブルは防止できます（多分・・・・・）。

開発最終段階での記録の重要性

さらに開発が進み、数ヶ月から半年以上もたって納品するとなると、ほとんどの人は自分の言ったことなど覚えていません。形のないモノについて机上で言ったことと、実際に動くモノを前にして言うことが一致している方が不思議かもしれませんが・・・

『これでは使えない！』『イメージと違う！』『なぜこんな動きをするのか？』

それでも要件定義と同じ人物に納品するのであれば何とかなります。最悪なのは、要件定義で話しをした人とは別の人物が納品段階で登場することです。意外にこれはよくある話で、要件定義ではトップもしくは管理者が自社の理想の姿からシステムの要件を語り、納品になると現場の担当者が現実的側面からシステムへの注文をつける　などということは当たり前だと考えていたほうがいいでしょう。

システムの製造とは、仕様書に書かれた要件をコンピュータ上で実現することです。この段階で、上流に遡り、要件や仕様を変更されたら、システム開発は成り立ちません。そんなとき頼りになるのは仕様書です。仕様書がキチンと作成され、双方で承認されていれば、納品の際のトラブルは防止できます（多分・・・・・・・・・）。

信じるものは救われる？

防止できないまでも、記録の有無によって対応は大きく違ってきます。もし記録がなかったら、恐らくは力関係を前提とした対応となることでしょう。そうならないために、記録の重要性を信じて、システム開発者は今日もWordに向かって、モクモクと（ムカムカと）作業を続けるのでした。