ソフトウェア保守現場におけるラストマン戦略

ラストマン戦略って

ラストマン戦略って、かの有名な小野和俊さんの造語だったのか。

ラストマン戦略とは、ある所属組織内で自分が一番(最後に立っている人 = ラストマン)になれそうなポイントを見つけて、実際にラストマンになったら対象となる組織自体を大きくしていく、という自分戦略である。

ソフトウェア保守現場の人員削減と最低限必要な人数

不景気と震災で経済的にダメージを被っている昨今、
悪名高きSI業界の、とあるソフトウェア保守の現場では、
ユーザ側から見ればコスト削減、ベンダ側から見れば売上確保という利害関係の中、
壮絶な(?)椅子取りゲームが繰り広げられています。

ただ、全く新規機能を追加しなかったとしても、
（主に作りがマズイせいで）不具合が発生して、
データベースパッチを当てたり、プログラムを修正しますし、
用意した機能ではできない、一括データ抽出や、一括データパッチなどの
作業を行う必要があることもあります。
（それは運用ってウワサもありますが、運用チームは仕様を把握してないので、
そこまで出来ないんですよね。）

つまり、ソフトウェア保守にも、最低限必要な人数というものがあるわけで、
人数を減らすにしても、残った人だけで保守作業が行えるのか、
負荷が高くなり過ぎないか、という観点が必要です。

ソフトウェア保守現場でラストマンとなるメリデメ

そんな中、うちのチームも先月末で人が一人減り（無事に仕事にありつけたそうです）、
気づいたら、あれ使えるの自分だけだなあ。
という、戦略もへったくれもない、単なるラストマンになっていたのに気づいたのでした。。

• 現場にとっては、必要なスキルを持った人
• 会社にとっては、売上を確保してくれる人
• 自分にとっては、仕事を確保できる（不景気ですもんね）

というわけで、いいことづくめのようですが、一方で、

• 辞めづらい
• 休みづらい
• 出勤時間以外に電話を受ける可能性が高くなる

など、いいことばかりでもありません。

というわけで、「あれ使えるの自分だけだなあ」の「あれ」は、
適切に他メンバへ引き継ぐのが、まっとうな社会人としての務めのようです。
そうした方が、信頼を得られるというメリットがあるかも知れません。

ソフトウェア保守現場で生き残るには

私が担当しているシステムは比較的大きな規模のものなので、
サブシステム単位に人員が割り当てられています。

現在は、サブシステム単位で人員が削減されている状況なので、
まずは、担当するサブシステムを技術・業務両面から、
熟知することが必須です。まあ、当然ですよね。

さらに今後は、サブシステム単位という枠を超えて（壊して）、
人員を統合していこうという動きがあるようです。
まあ、サブシステムが異なるといっても、
使用しているアーキテクチャ（技術）はほとんど一緒なわけで、
あとは業務を覚えれば保守できるでしょ。というのが理屈です。（たぶん）

まあ、サブシステムごとに微妙に作りが違うとか、
色々ワナがあるわけですが。。

というわけで、結論としては、
自分が担当するサブシステムを超えて、
技術・業務両面から熟知する。
が正解なのではないかと。

まあ、守備範囲が広いほど、どこかでラストマンになれる可能性が高くなる
ってことなんでしょうね。
書いてしまえば当たり前すぎました。