【目次へ戻る】

■なぜシステムの引継がうまくいかないか

　他人の作ったシステムを引き継いでも、その仕組みがよくわからない。あるいは、パッケージを導入したが、メンテできるかどうかわからない。
　なぜそのようなことが起こるのか。どうすれば新しく携わるシステムを理解できるか。


考え方・メモ

・ホスト、VB、web系など、システム（言語）によって理解のしかたが変わる。
とくにパッケージの場合は、「くせ」があるので、その「くせ」を知り得ないと理解が遠くなる。

理解するためには、まずおおまかな業務を知っておく必要がある。
また、システムのポイントとなるところを押さえる必要がある。
この「ポイント」が難しい。
保守資料を作る側の能力が問われるところ。

保守資料は、たんにプログラムの仕様やジョブの仕様を客観的に書き出せばいいということではない。
もちろん、それも大切だが、それらが有機的につながる補助資料〜人間が人間に伝えるためのある種主観的なことばの使用〜が必要となる。
また、客観的な仕様書も、内容をつぶさに書き出せばいいというものではない。重要なところと、脇の存在であるようなところを、メリハリをつけて作らなければ、見る方は何もわからない。細かいところはソースを見ればわかる。資料は、ソースの内容を理解しやすくするためのものであるべき。
※具体的には、テーブル参照など、そのしくみをわざわざ細かく書き出す必要はない。ただし、これも場合によっては細かい記述が必要なときもある。


■引き継ぐシステムをいかに理解するか
＜手法＞
・気になるキーワードを書き並べる

・ソースは例外処理の記述が多くを占めるので、細かくみていると全体の流れがつかみにくくなる。まずは全体を眺めて、メインとなる処理フローを押さえることが大切。
おおまかな流れがつかめたら、内部に入り込んでいく。この時も、要の部分をかぎ分ける能力が必要。細かいif条件等の分岐に惑わされないようにする。それらしいコメントがあればいいのだが、なければ自分で判断するしかない。自分が作るときは、そういうことに注意して簡潔で要点をおさえたコメントを付加すること。

・頭を柔らかくして考えること。知識のない分野でわからないことにあたったら、推測で済ますのではなく、どうやったらその部分を理解できるか考えること。知っていそうな人を探して聞いてみたり、ネットで調べたり、本屋へ行って参考になりそうな書籍を買ってくるなど、あらゆる手段を使って理解していくこと。ただし、これもそこまで注力するべきことか、あるいはもっと重要なところが他にあるので、まずはそちらに注力するかどうかの判断など。
かぎ分ける力は、一朝一夕には身に付かない。繰り返し鍛錬することでしか得られない。仕事は、壁にぶつかるほど自分の力となって蓄積される。


■システム運用を改善していくには

そもそも、システムの運用改善とは、どういうことか。あるいは、どうなっていくべきなのか。

問題点を考えるところからスタート。