維持管理に埋められた新人SEをアジャイルに慣れさせる冴えたやり方

マインドセットやリリースまでのスピードではアジリティがないかもしれないが、それ以外は、アジャイル開発の要素が揃っているのである。

契約

 まず、契約面においてが重要である。スコープを決められない保守運用・維持管理は決められないからこそ、面倒を見る範囲を決め、ヘッドカウントでできる範囲でという準委任契約で締結することが多い。

スコープが決められないのだから見積もりができない。よって、請負契約では契約できない。していたら、政治的な理由があるか偽装請負の可能性が高い。

なお、偽装請負の場合は、その案件の上から下まで全員しょっぴかれるらしい。

一般的な保守運用・維持管理のイメージを以下に示す。保守運用と維持管理の違いはその契約を締結する組織や顧客の文化的背景で使っているのではと思うがそこはテーマではないのでここまで。以降は維持管理で統一するので。

横軸は時間で、縦が道幅である。つまりエンジニアの工数。ヘッドカウント。

このほか、維持管理に必要な技術要素が含まれる。

契約の観点では、維持管理の作業（メンテナンス、拡張等）のサービスを行う作業の定義や定量的な作業上の制限を設け、それを超える場合は事前に協議、などの制約を設けることもある。

作業

現場での作業は、基本的な作業計画を立てて行う。ベースとなるのが不具合対応で優先されるものである。システム運行上のハウスキーピング的な作業やシステム拡張がある。この他、セキュリティの脆弱性対応なども計画的に行うものと緊急対応するものがある。

これらをどこまでやるかは契約時に決めるが、そうした範囲の作業を年間で計画し、一定のサイクル、月次や四半期などのサイクルで維持管理業務を制度化する。制度化するのはプロセスづくりと本番適用の計画を立てるということである。

これをやらないと人的リソース管理が破綻し、維持管理で契約のキャップがある場合は赤字になってしまうのと人のやりくりができなくなる。

 上図の期間の繰り返しを見て何か気づきはないだろうか。

期間ごとにリリースするということはスプリントを回しているのである。

要員

アジャイルな開発では要員を固定化することで様々な恩恵を受けることを進めている（意訳）。

開発スピードをあげようと思ったら、コミュニケーションのハードルは低い方がいいし、成熟度も上がった方が良いに決まっている。まあ、それはウォーターフォールでも同じだけど。

維持管理は比較的というかシステムをサンセットするなどがない限り同じ要員で走り続けることが多い。それはシステム運行に必要な業務ドメイン的な知識の蓄積が暗黙で求められているからだ。

結果的に要員が固定化するので新人SEが維持管理に配属させられると蝉になるわけだが、それはさておき、アジャイルな開発の必要要件の一つを満たしている。

導入言ってはいけないこと

もしこれを読んでアジャイルな進め方が合っていそうだと思っても、間違っても契約上はもちろん、顧客にアジャイルで維持管理をやります、とは言わないこと。

あくまでも維持管理チームの中での運用的な位置付けにとどめておくこと。アジャイルなら人は少なくて済むのだろうとか、逆に文書は作らないのだろうというような、誤解から変な方向に行かせないためである。

それにやってもないこと（ここでは今までの維持管理のやり方からアジャイルなプラクティスを取り入れた維持管理）をできますなんて言えないのだから。

ただ、受け身な仕事の仕方を少しずつ変えていきたいとか、蝉になってしまいがちなSEに技術的な養分を与えたいなどの狙いがある場合は、運用の改善として進めるのが良い。

冴えない彼女の育てかた Memorial (ファンタジア文庫)