株式会社シスアナコム

情報システムに関することなら、どんなことでも適切に助言いたします!

この投稿は1年以上前に公開されました。
現在では状況や内容が変わっている可能性があります。
ご注意下さい。m(_ _)m

情報システムの開発から保守へ

      2014/06/11

概要

  • 情報システムは開発が完了したと同時に保守が必要になる。
  • 開発から保守への引継を順調に行うことは困難だが、やらねば開発者の負担が増えるだけ。
  • 情報システムそのものよりも、業務知識を伝えることが重要。

情報システムの開発から保守へ

だいぶ暖かくなってきました。春ですねぇ。

のーんびりしたいところなのですが、多分、どこの企業でも年度末なので忙しいことでしょう。

私が勤務している会社もそう。

年度内に終わらせなければならない情報化がたくさん残っています。

情報システムを構築して会社の利益に貢献することは大変なことなのですが、実は完成してからがもっと大変なのです。

情報システムは構築した瞬間から保守が必要になります。

というのも、どんなに完璧に事前調整がなされた情報システムであっても、実際に稼働して利用者が使い始めると修正要求が多発します。

もちろん、修正要求を少なくすることは可能なのですが、ゼロにすることは不可能ですし、そんな情報システムが存在するという話は聞いたことがありません。

情報システムが完成しても開発者は、しばらく忙しい状態が続きます。

でも、いつまでも開発者たちがそのシステムを保守している訳にはいきません。

なぜなら、経営者や利用者からの情報化要求は年々増加しているにもかかわらず、情報システムを構築できる技術を持った人たちは、残念ながら極端に不足しているから。

私が勤務している会社のようなユーザ企業では本当に深刻な問題です。

そのため、情報システムの開発ができる人材は、できる限り開発業務へ投入したいのが管理者の本音なのです。

でも、開発者が異動したり退職したら保守できなくなってしまったということでは、企業の存続にすら影響するかもしれません。

そこで保守作業を開発者以外の人たちにやってもらう必要が出てきます。

でも、これが上手く行かないんですよ。(泣)

引継の難しさ

当然ですが、情報システムを構築した本人は、その情報システムについて何でも知っています。

しかし、保守を行う人はコンピュータに詳しいかもしれませんが、その情報システムについては何も知らないのです。

ちゃんと引継を行わなければ、保守なんかできるはずがありません。

「仕様書を見りゃ分かるだろ!」という人がいるかもしれません。

その情報システムに関する全てのことが網羅されている仕様書が(仮に)あったとしたら、どんな小さな情報システムであっても、文庫本1冊ぐらいの厚さの文章が必要でしょう。

ちょっと大きな情報システムだと、辞書並の厚さになるはず。

私が勤務している会社に導入されている、某メーカが作った巨大な情報システムだと、仕様書が何十冊もあって棚に整然と並んでいます。

こんな仕様書を読みたいと思う人は少ないでしょう。

つまんない仕様書を読みゃわかると言われても、私だったらイヤです。

また、仕様書が正確に記述されているかどうかも疑問です。

特にシステムの完成前後は、仕様書まで手が回らないくらい忙しいのが現実。

よって、その情報システムを保守して貰うためには、工夫が必要なのです。

「何をどう伝えたらいいかよく分からない」とか「引継やってるんだけど上手く保守できていない」という問題を抱えている企業は多いはず。

特に情報システム部門の人数が少ない企業はそう思うでしょう。

だって、私が勤務している会社も少し前まではそうでしたから。

でも、やっと最近になって保守担当者への引継のこつを覚えてきました。

それをここで公開しますので、みなさまの参考になればと思います。

ただし、このノウハウは社内向けの中規模システム(プログラム十万行以下、画面数百画面以下)程度までのものです。

私は大規模情報システムを扱った経験はありませんので、ご了承ください。

開発から保守へ、ノウハウ一覧

業務知識を伝える

情報システムの中身よりも、まずは業務知識が最優先。

その情報システムが「なぜ構築されたのか」、「誰にいつ利用されるのか」、「以前のやり方はどうだったのか」、「会社にどのような利益をもたらすのか」ということを保守担当者に教えましょう。

情報システムの中身なんか後回し。

情報システムの背景を伝えることが最優先です。

開発担当者と保守担当者で一緒に保守

もう一度書きますが、情報システムが本稼働すると利用者からすぐに修正要求が来るはずです。

これを開発担当者だけで対応してはいけません。

引継のチャンス!

言葉だけの引継では伝えきれないことも多いので、一緒に保守作業を行い、ノウハウを伝えましょう。

時系列の開発日記をつける

開発作業中の出来事を時系列に記述した履歴があると便利です。

保守担当者が開発中の出来事を知っているといないのとでは、保守の質が大幅に変わってきます。

後になって保守担当者がこの文書をキーワードで検索することが多いので、手書きの日記ではだめ。

当然ですが、電子化して下さい。

開発担当者は毎日5分間でいいので、帰宅前に仕事場で日記を付けるようにしましょう。

プログラムの仕様書は不要

はっきり言いますが、小~中規模システムにおいてプログラムの仕様書は不要です。

仕様書として作るならば、業務知識について記述すべき。

プログラムの仕様書よりもプログラム中のコメントの方がよほど重要です。

なぜプログラムの仕様書が不要かというと、正確なプログラムの仕様書なんてあり得ないから。

とりあえずプログラムを修正しても、忙しくて仕様書を修正し忘れることはよくあります。

また、仮に正確な仕様書があったとしても、最後は結局プログラムを見て直すのですから、そこにしっかりとした日本語のコメントが記述されていれば十分です。

ただし、日本語のコメントをどのように記述するかというルールと教育は必要になります

正確なプログラム仕様書を作れるだけの人的な余裕があれば、作ってもかまいませんがね。

引継期間を設定する

いつまでに引継を完了させるかという目標を設定します。

これがないと、いつまでたってもずるずると開発担当者が保守担当者に引きずられます。

期限が決まっていれば、保守担当者も気合いを入れて引き継ごうとするはず。

私が勤務している会社では、小~中規模システムなら引継期間は1ヶ月以内ですが、各社の実情に合わせて調整して下さい。

利用者向けマニュアルはしっかりと

プログラム仕様書とは逆に、利用者向けマニュアルはしっかりと整備しましょう。

これにより、「利用者からの質問責めによる保守業務への影響」をかなり押さえることができます。

保守担当者がヘルプデスクにならないようにするためには、丁寧なマニュアルづくりが必要なのです。

仕様書を作る時間があったら利用者マニュアルを作りましょう。

また、利用者マニュアルは情報システムに関するノウハウの宝庫です。

保守担当者にも十分な参考資料になるでしょう。

開発者は異動させない

退職してしまった場合は仕方ないのですが、開発者はできる限り他の部署へ異動させてはいけません。

どうしても緊急に保守しなければならない場合や、どうしても保守担当者では分からない問題が発生することも現実には多いのです。

その際に開発した人間がいるといないのでは大きな違いです。

いざというときの保険です。

少なくとも1年間は稼働後に様子を見ましょう。

まとめ

いかがでしたか?

これは実際に私が勤務している会社で実践していることです。

少人数で情報システムを開発し保守するためには、様々な工夫が必要なのです。

 - ひとこと, ひとこと(情報化)

↓ブログランキングに参加しています!


ネット・PC(全般) ブログランキングへ
にほんブログ村 IT技術ブログ ITコンサルティングへ
にほんブログ村

Message

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です