保守の価値とは

ソフトウェアを利用してサービスを提供すること、すなわちソフトウェアを運用することによって、初めてソフトウェアは価値をユーザに提供できる。
そして期待される期間にわたり運用を継続して価値あるサービスを提供し続けるためには、ソフトウェアを保守することで、ソフトウェア自体の価値を維持していくことが必要になる。

「ソフトウェア品質知識体系ガイド―SQuBOK Guide」より引用

ハッとした。
叱られた気がした。

いうまでもないことだが、ソフトウェアを開発するのは、ソフトウェア（あるいは、それを包含するシステム）を利用して、ユーザに価値を提供するためだ。
上記に書かれている通り、保守はその価値を維持する活動である。
維持できなければ価値は（環境の変化等により）細っていく。また、競合がより優れたシステムを開発し、相対的に価値が下がっていくこともある。

保守は嫌われる？

なのに、保守は嫌がられることがある。
大手ＩＴベンダーは「作り逃げ」することがある。
「ライフサイクルまるっと面倒見まっせ！」と言っていても、気がつくとメンバーが子や孫請けに移行していることもあるし、メンバーが極端に若返っていることもある。

私は入社１年目の後半から、他社の保守チームでしばらくお世話になったため、保守に育てられたという意識が強い。
保守時には、他人の書いた設計書やコードを大量にみる必要があるため、大量のインプットを得ながらそれなりの量をアウトプットする必要がある。
本番データを観察し、プログラムを観察し、システム（ソフトウェア、手作業、運用などを含む）を観察する必要がある。
本番障害時には敏捷性も求められるし、周囲をうまく巻き込むことも求められる。
現場の声も直接聞けるし、改善や対応がよければ感謝されることも多い。
教育という面からみて、保守は理想的な環境に思える。なぜ嫌われるのか。

保守は儲からない

なぜ儲からないかというと、顧客企業が新規開発時に比べ、投資を控えるためだ。
顧客企業側は、新規にシステムを作るのに、すでに十分な投資をした。ソフトウェアやシステムの運用が始まった「今」は、投資を回収する時期だ。
開発時から、段階的にシステムをリリースする計画をたてていた場合などは、予算が確保されている。
が、システムの利用中に発生した要望への対応は予め予算が確保されていない場合もあり、その場合は都度予算の確保が必要となる。
回収フェーズなので、予算は出にくい。政治的なものが働くこともある。
予算がでないと、ＩＴ企業への大きな支払いもない。確保しておいた保守予算の中で細々と保守していくことになる。

保守は怒られる？

障害や、保守作業のミスが、顧客の業務を止めてしまうことがある。
業務を止めること当然、ビジネス上の損害もある。
ビジネス上の機会ロスかもしれないし、ビジネス継続のために無駄な費用を使うことになるかもしれない。
顧客の業務を止めてしまった場合は、責任を追及されることもある。
顧客から直接文句を言われるかもしれないし、顧客に謝罪した上司から怒られることもある。
ＩＴベンダーに落ち度がなくとも、いきなり怒られることもある。

新しい技術を得られにくい？

顧客企業の性質によっては、新規開発時に安定していた技術でソフトウェアが開発されていることがある。
新規開発時には画期的だった技術で開発されていることもある。
いずれの場合でも、リリース後年数を重ねるに従って、当然技術は古くなっていく。
古くなるばかりでなく、あっという間に廃れた技術でつくられたソフトウェアの保守を続けるはめになることもある。
「作り直したいんだよね〜。これ以上お金はかけられないんだよね〜」という顧客の声を聞きながら保守を続けることになることも。
技術者には新しい技術に飢えている人が多いし、やっぱりモチベーションが上がる仕事をしたいよね。

もちろん、保守であっても、アーキテクチャの変更を伴う場合など、新しい技術を伴うものもある。
要求追加であったり、チューニングであったり。
なので、保守＝新しい技術に触れないということはない。
が、自分の経験の中では頻度は少ない。

「技術」とひと括りにしたが、変化の激しい技術もあるし、変化の少ない技術もある。
よい設計思想で作られていれば学ぶものが多い。
また、「手作りであること」が自慢できるようなものもある。自作暗号化プログラムとか、自作ＯＲマッパーとか、自作の高速なソートプログラムとか。
ノスタルジーでなく、単純に自慢できるものも多いと思う。

スパゲティ

保守を重ねたソフトウェアは、さまざまな人の設計意図が混じり、理解しにくいものとなっていることがある。
最新の設計書や要求文書などが整備されていても、設計書なんて見ない人もいる。
イケてないプログラムもあるかもしれないし、イケすぎててわかりにくいものもある。
単純に「自分のコーディングスタイルと違うから読みにくい」ものもある。命名規則が違うだけでも十分読みにくい。
もともとの設計意図を無視して、その場しのぎの修正を加えた箇所があることもある。

こういった、わかりにくいプログラムを、仮に新しい人が、短期間で修正しろと言われたら、なんだか分からないなりに修正を加え、スパゲティ化を進めることになったとしても責められない。
モチベーションが上がるとは思えない。

保守は価値を継続して提供するためのものである

ここまで挙げた特徴は、すべてＩＴベンダーの視点で書いた。
自分の経験はＩＴベンダー側からの視点での経験が多く、その中で保守が嫌われる現場を見てきたからだ。
保守について書いた書籍なども、ＩＴベンダーの視点で「辛い仕事だけど工夫して楽にしようよ」という趣旨のものしか読んだことがなかった。
＃単に勉強不足なだけかもしれません、ハイ。

冒頭で引用した文にハッとしたのは、これが顧客の視点からのものだったからだ。
システム化企画を行う際や、要求を分析する際には、意識して「顧客視点」で捉えるようにしてきたつもりだった。
このシステムは、顧客のビジネス目標にどうマッチするのか？目標の達成をどう助けるのか？
ＵＩなどの「ソフトウェア」の要求を出してきているが、顧客は「システム」に何を期待しているのか？（よく言われることだが、顧客が欲しいのはドリルなのか、4cmの穴なのか、絵を飾ることなのか？等）

ところがどうだ。
「保守」に対しては、ＩＴ企業の立場でしか見ていなかったではないか。
儲からないとか、つまらんとか。
顧客の立場でみると、新規開発は、あくまでもＰＤＣＡサイクルの「Ｐ」でしかない。
これから運用し、見直しをかけ、調整を繰り返していくのだ。
システムを使い倒して、ビジネスを行い、儲けていくのだ。
ようやくＰＤＣＡサイクルが回り始めたところなのだ。

なのに、ＩＴ企業の努力不足のせいで、十分にサイクルを回せないかもしれないのだ。
なんてこった！