維持管理プロジェクトはまなびのチャンス

悩み多き維持管理プロジェクト
コミュニティ活動中で会うエンジニアは様々で、業種もそうだし、SIプロジェクトもあれば維持管理プロジェクトもあります。その中でよく聴く悩みは、維持管理プロジェクトに入っていると“モチベーションを維持することが難しい”とか、“新しい技術に触れる機会がない”と言ったものが多いんです。

維持管理プロジェクトのメンバは、ずっと固定化されるところもあれば、頻繁に入れ替わるところもあったりして、メンバというリソースの悩みもあるようでそれをずっと抱えていることも多いらしい。でも、その悩みってホントに維持管理プロジェクトでの悩みなのかな、って思うんだけどどうでしょう。わたしの経験からもそれって切り口を変えたら違うアプローチができるのではないかな、って。

実は意外と計画が立て易い
Siプロジェクトで開発から維持管理に移されたときのシステムの安定度合いによるけれど、−まぁ、不安定だったら実運用に移行しませんけどねぇ−、移管当初はシステムの成熟度の浅さから対応する手間は多いこともあるだろうけれど、次第にある一定の手間で済む様に安定するものです。
＃いや、安定させるようにする、が正しいか。

実運用後のシステムは、システム運行上のメンテナンスや異常処理の対応の他は追加機能開発が主だった作業で、それをある道幅のエンジニアがお守りをするイメージだけれど、だいたい同じだろうか。

エンジニアの道幅、つまり、ワークロードは固定だから、メンテナンスや追加機能開発をいくらしたいからといってリソース以上には出来ないからはなから計画を立てるときにそのリソースの中で無理がないように立てるものです。勿論顧客とエンジニアとの力関係はあるだろうけれど、維持管理のリソースを目一杯使ってしまうと、実運用で運行しているシステムにトラブルが起きたときにトラブル対応を最優先するから、目一杯立てた作業が全く対応できなくなってしまい、仕舞にはスケジュールの期限が遅れてしまってそれはそれでにっちもさっちも行かなくなってしまうのでスラックをいかに持たせるかが腕の見せ所だと思います。

こういった予定する作業量のキャップが掛けられるという制約は、システム運用コストを下げたいという顧客の要望とあわせると、定時内で仕事を調整して欲しいという指示に変わることもあります。多少は時間を超過するにしても、エンジニアから見れば、システム開発のような怒涛のスケジュールや鬼のような残業はないので、維持管理しているシステムがほぼ安定しているなら...放課後の時間はかなり余裕があるものです。それは、自分の時間をSIプロジェクトに居るより時間というリソースを確保できるということであり、システムのメンテナンスの計画も前もって立てられるので、事前に計画を立てないと実運用しているシステムを止めることはできないこともあって、休日も含めて時間という一番価値の高いリソースを手に入れ易いと思っています。

実は学び易い
維持管理のエンジニアは、時間という一番価値の高いリソースが手に入れ易い位置に居ることを理解しなくてはならないでしょう。その上で、維持管理に従事しているエンジニアの悩みを解決するかどうかを決めればいいのです。自分自身の関心が新しい技術に触れたいのであれば、一番価値の高いリソースである時間をそれに当てればいいのです。それは、自分でそれを出来る環境をそろえてもいいし、盛況な社外勉強会に参加してもいいのです。

モチベーションが上がらない、は、実は仕事でも私生活でもいづれの場にしても、誰かから注目されないとか、認めてもらえないということが原因であったりするものです。ならば、自分で関心を持ってもらえるようにちょっとだけ、冒険をしてみたら言いのです。やっぱり、社外勉強会はその注目や反応がストレートに返ってくるのでお勧めです。その反応を得るためには、社外勉強会や読書会でひとコマでいいからLTなどで話すことを試みることです。

それが自分に合うならとてもモチベーションというより自分の存在価値を認めてもらえるとか関心を持ってもらえたとかといった自分が自分に対する認識を満足させることが出来るでしょう。