システム保守の担当者はつらい立場に追い込まれることが多い。
なぜなのかを考えてみた。
システム保守者は当然、そのシステムにおける業務の知識を習得する必要がある。
では、業務の知識ってどのように習得するか。
システム保守を行う場合、自分がかかわっていなかった処理についても、業務の知識を理解しておく必要が出てくる。
システム開発を行う場合、設計書があるわけなので、それを読み込むことで習得できるじゃん。と考えるのは甘い。
じゃあ、システム開発を行った人たちから、引継ぎを行えばよいだろう。とも思うかもしれないが、そうでもない。
上記について、自分の考えを書いてみる。
・設計書
俺の経験上、設計書はシステム開発するために必要なことを書くため、システム保守について必要な事項は書かれていないことが多い。
書かれていたしても、システム保守者が知りたいことまでは書いていない。
（プログラム読めば分かるでしょ、って発想なんだろうね）
・引継ぎ
システム開発者の知識とシステム保守者の知識に開きがあり、説明を受けても業務内容を習得することは難しい。
引継ぎする側（システム開発者）は、何を説明すればよいのかよく分からない。
引継ぎを受ける側（システム保守者）は、何を言っているのかよく分からない。
（何が分からないのか分からない）
なので、結局はシステム保守者が自分で興味を持って、学習していくことが大事だと思う。
ただし、学習する期間なんてもらえるわけが無いので、システム保守者は苦しむことになる。
可能なのであれば、システム開発者がいるうちに、システム保守者と一緒に問い合わせ対応を行う（OJT）ことをお勧めする。
極論を言ってしまうとシステム保守者をシステム保守する立場に放り込んで任せる（追い詰める）ことが、業務知識習得の近道なのかもしれない。
このときシステム保守者は、得た知識をドキュメント化（形にしておく）しておき、後から同じような事象を再度１から調査することを無くすことが大事なんだと思う。
作ったドキュメントについては、みんなが見ることができるところに置いておき、情報の共有を行うことが大事かな。
（体裁にはとらわれず、メモ程度で十分約に立つ）
本当は、システム開発者がシステム保守まで意識して、設計書なりのドキュメントを整備しておくことがよい。
ただし、システム開発者は往々にして、システム保守にかかわったことが無いため、システム保守で何が必要になるか想像がつかない。
システム開発一辺倒で育ってきた人たちには、理解してもらえないだろう。。。
ぎりぎりでシステム開発しているのに、余計な作業してられないってのが、本音なのかね。
このように、システム保守の担当者がスキルを習得するには、地道な学習、経験、ドキュメント整備が求められるわりに、即、結果を求められ、失敗は許されない。
なので、システム保守者はつらい立場になることが多いと思うよ。