Ⅳ．保守の２１箇条
これは、今年度のキックオフのフォーラムで日経BPの矢島様から「保守の１０箇条」というお話しをいただきましたが、それに対応してＤグループで検討した、保守についての教訓すべき事柄を、簡単にまとめたものである。本来１０個まとめるべきだったかも知れないが、数にこだわってはいない。さまざまな、ご意見あろうかと思うが、独断とも言えるガイドとしてここにまとめた。【 】で囲まれた部分は、ことわざに代表される定型的な慣用句を元に、こじつけともいえる強引さで、「保守」をつっこんだものである。これの意味は解説しない。読者の自由な発想にお任せする。ことわざのパロディが、新たな意味をもち、しかもしばしば非常に有効であることを発見したことは、この作業の収穫であった。
一．保守者はシステム開発のすべての工程を短期間で行う技量が必要と心得よ。
二．ソフトウェア開発の教育のみを行っても保守者育成には不十分と心得よ。
三．保守担当者が将来に不安を持たないようなキャリアパスを確立し，提示すべし。
四．保守はシステムの現在と未来の課題に対するソリューションサービスであると心得よ。
五．開発と呼ばれているソフトウェアの作業も保守であることが多い
六．システムライフサイクル中で保守プロセスの期間が最も長いことを再認識せよ
七．保守作業は規模の大小・期間の長短に関わらず，担当者任せにするべからず
八．保守対応費用の請求先はその発生原因によって異なることに注意せよ
十．保守履歴を丹念に分析すれば，今後の保守案件の発生予測が可能。
十一．経済情勢の変化が激しい今は，保守案件が増加すると予測せよ
十二．システムの状況は個々に相違あり。保守部門自らが現状認識し保守戦略を立てよ
十三．開発担当者が片手間に保守作業しているような状態を作るべからず。
十四．開発部門とは独立した部門が保守すれば，開発部門の品質は上がる。
十六．保守コストを下げるためには最もコストのかかる作業（事前調査とテスト）の効率化を第一優先にすべし。
十八．保守案件の多いシステムは低品質ではなく，ユーザが積極的に利用していると考えよ
十九．開発者が保守しなければならないのは，開発品質が悪いからである。
二十．保守の戦略や計画の立案及び保守作業の環境整備に力を入れよ
二一．開発者から保守を引き継ぐ際，開発者から保守性の設計思想を出させるべし
「保守プロセスから開発プロセスを呼び出す。保守者一人で保守作業担当する場合，その保守者には開発プロセスのすべてを行う能力が要求される。」
保守の現場では、待ったなしの切羽詰った状況が展開される。システムに対する深い理解と、一瞬で判断を下す決断力が求められる。これは、開発者の持つ責任とはおのずから異なるものである。ソフトウェアは使われて初めてその価値が発揮される。つまり、保守する段階になって、ユーザは効果を実感するのである。ユーザにとって、価値あるソフト会社とは、自分たちの利用に耐えうるサービスを提供してくれる企業であり、それは初期導入に立ち会うというだけでは不十分である。価値ある信頼は、サービスイン後にこそ生まれる。
保守者とは、切迫した状況の中で、小規模のシステム開発を適格に行うスペシャリストである。
保守は、開発の後工程の一種を言うのではなく、開発は実は保守の一形態であるにすぎない。転倒した思考を正すのも、われらの役目である。
ソフトウェアは使われて初めて価値が出る。ユーザにとって価値あるソフトウェア会社とは、自分たちの利用に耐えうるサービスを提供してくれる企業であり、それは初期導入に立ち会うだけでは十分ではない。価値ある信頼は、サービスイン後にこそ、生まれるものである。すなわち保守である。
「ソフトウェア保守独自の教育が必要。現状自前でやるしかないが。」
ソフトウェア保守という業務があり、社会的な必要があるにも関われず、この人たちを育成する適切なプログラムが存在しなかったのは、残念なことであり、不幸なことである。ＳＭＳＧが、自らその必要を感じ、ここに10年の歳月を超えて、ソフトウェアメインテナンスの第一人者としての、先覚的道を歩んできたのも、あまりにこの業務がないがしろにされてきたためではあるといえる。
保守要員の業務をスマートに適切に、能率的にこなしていくためには、開発に方法論があるように、保守にも方法論があってしかるべきである。しかし、保守は一元化、単純化して語ることが困難である。
ソフトウェア開発は、ソフトウェアライフサイクルから見た場合には、その一局面でしかない。教育は常に開発のための方法論を提供しようとするが、実際社会が要求しているのは保守の技術であると言える。なぜなら、昔は開発されたシステムが少なく保守要員も少なくて済んだ、開発すべきシステムが多かったので、開発者が求められた。いまは、開発されてしまったシステムが多くなり、保守要員が不足してしまうという構図になる。要員は適切に教育され配置されるべきであるが、これがうまく行かない。保守には保守に相応しい教育というものがあるべきであり、この要望は高まる一方である。
「保守者のモチベーションを保守部門として確立すべき」
安定した保守サービスを受けられなければ、顧客は大きなダメージを受ける。間接的に保守者が安心し、モチベーションを維持・向上させうる環境であることが望まれる。保守の塩漬け論は、保守問題の重要なテーマであった。仕事が慣れることにより、スキルの蓄積された担当者を別部署に配置しにくくなる。しかし業務全体を見たときの健全性を維持するために、絶えず新たな血を入れ、経験を積んだ担当者も新たな舞台へ送り出すべきである。
しがらみとして、実施せざるを得ない手っ取り早く処置される保守ではなく、考慮され、企画され、計画された保守であるべきである。このとき、保守は戦略となりうる。
保守のモチベーションをどのように維持し、向上させるかという課題は、非常に重い。人間を分析し、理解し、保守ビジネスの形態を知った上でなければ、方向性は出せない。
「保守を後ろ向きな業務と捉えず，付加価値サービスとして，前向きに捉えることが重要。」
システムに新たな機能を追加するために、現状分析をしなければならない。保守者の担当する業務は、そのまま現状分析の素材であり、保守していなければ、ゼロから調査をしなければならないことを、既に有料で分析できている。保守者は、システムの弱点を誰よりもよく知っている。それは、痛みと緊張を伴って、忘れられない事実を常に突きつけるのである。
事件が、現場で起きている。その現場こそ、保守者のよってもって立つ基盤である。ここには、さまざまな問題が積み重なってうずたかく積まれている。これらは、何よりも次のビジネスの素材を提供してくれている。貴重な宝なのである。ソリューションは保守者の頭脳の中にこそある。
「「えせ開発」に気をつけろ！ 規模が大きいから開発。機能追加だから開発。改造だから開発。開発計画の第２段階だから開発。 みんな「えせ開発」。」
開発として行なっていることが、よく見れば「保守」であることは多い。技術者が保守という言葉を嫌う理由は幾つかある。開発と保守を比べれば以下のポイントが挙げられる。開発の優位はそのまま保守の不利である。
・ 新しい環境で、最新の技術で行われる。
・ 自分たちの立てたスケジュールに沿って作業が進められる。インタラプトに悩まされない。
・ 他人の作ったへまなプログラムに悩まされることはない。少なくとも自分たちのプロジェクトの問題でないことなのに。
・ 大概の場合、顧客に謝ることが必要になり、他人のしりぬぐいばかりしているような気がする。
・ まっさらな所に絵を書くことは許されず、誰かの描いた絵を手直しばかりしている。自分の創造性が発揮されない。
・ 解析能力、影響判断が必要になるが、これは非常に労力のかかることである。
・ 仕事がうまく行ってもほめられることはない。かわりに、失敗は常に途方もなく大きなことになる。
今の時代で、まったく他のシステムとインターフェースを持たないようなシステムを構築することは考えられない。インターフェースを持てば、それは新しく作られたとしても、ある全体の一部であるといえる。つまり、機能拡張の結果として必要になったプログラムであり、開発ではなく保守に組み入れられるものであるといえる。
「保守の効率化がシステムライフサイクルコストを最も下げることに注目せよ」
保守が最も長きに渡るのは、システムが使われて初めて価値あるものとなるからである。基本的に、システムは資産として減価償却されるまで、利用される必要があり、さらにより長く利用されるべきである。開発のための開発はありえない。保守は目的ではないが、システムを最適化し利用するためのコストであると考えるべきである。保守者は、利用者の立場をよく理解して業務を行うべきである。保守の効率化は、顧客にとっても保守を提供する側にとっても歓迎するべきことである。それゆえ、開発する時点で、保守のことをよく考えておくことが、ＳＬＣＰ全体のコストを抑えるのに大変重要であるといえる。
「ちょっとした修正だから，担当者に任せておけばよいというのは，非常に危険。管理責任者または責任者から委任された第三者が作業内容をレビューしつつ進めるべき。」
局所の修正が、システム全体を停止させてしまうことは、決して少なくない。プログラムの修正量が多いか少ないかは、システムに与える影響が大きいか小さいかの指標にはならない。安易な修正や、慣れからくる怠慢は非常に大きな反動があると知っておくべきである。
「瑕疵，保守契約範囲内，保守部門予算内，利用部門要望などによって，費用負担部門及び費用調整手順が異なる。」
保守作業には、様々な内容があるが、保守作業の引き金になった理由によって、費用負担は分類されるべきである。あまり、厳密に行うと、弊害を生むばあいもあるが、いずれにしても顧客との契約内容に依存する。最近では、システムの複雑化、巨大化により、問題の識別と管理を自社で行うことは少なくなってきた。いわゆるアウトソーシングとして、業務を委託する動きになってきた。顧客は詳細な情報を好まないかもしれない、それゆえ顧客が要求する項目のみを報告することになる。報告がされないからといって、問題の原因がなおざりにされてよいということにはならない。自らの要求することに従って、作業をすべきである。
「規模，納期，優先度の異なる複数の保守案件を平行して対応するのが保守作業。コンカレントエンジニアリングは正に保守のためにあるようなもの。」
ひとりの担当者が、複数のシステムの保守を受け持つことは、ありうることである。不幸な出来事が、まるで徒党を組んで押寄せることがある。保守の現場でも同様に、同時多発のシステム障害ということはありうることである。時に保守者は、皿回しの曲芸を行っているように見える。いくつものユーザを掛け持ちで、しかもお叱りを受けない程度に、なだめつつ、忍耐の限界を上手に探り当て、お皿が止まりそうなのを見計らって、エネルギーを与える。これは、特殊な能力に思える。しかし、保守の現場では、実に日常的なことである。
「保守作業は，ある種の繰り返し作業。標本が集まれば，各種推計や予測が可能。」
歴史とは常に、未来学である。その意味において、重要でありえる。過去は、未来を教える教師であり、われわれはこれから教訓とする多くの事実を学ぶのである。未来に勝利を得ようと望む有能な者たちは常に、過去を大事にし、丹念に調べることを惜しまない。
費やした費用と労力は、効果にみあうだろうか。丁寧に、本質を見極めようと努力した歴史の分析は、教訓となって必ず大きな効果を生むにちがいない。
「適応保守が増える。開発時の品質の良し悪しとは無関係に適応保守案件は発生する。」
保守案件が増えるのは、自然なことで、それだけ稼動しているシステムの数が増えているからである。しかも、保守を必要としないシステムというものは存在しない。多くの川が、海に流れこむのに似ている。海は、川の水を拒否しない。無条件で受け入れている。しかも、水は川から海にむかって流れるが、いまだかつて、その逆（海から川に逆流）はありえない。
開発業務は、システムの構築が終了し、ユーザがこれを利用していけば使命を果たすことになる。一方保守は、システムの利用が始まってから廃棄されるまで続く。システムが使い捨てでない限り、必ず保守は必要となる。
「一般原則（モデル）論的な戦略ではなく，自システムの特徴を意識した戦略の重要性」
保守と一言で行っても、その内容は千差万別である。自己の優位性を主張し、優良ビジネスに成長させるのは、保守部門の自らの情熱と努力である。
「保守作業を開発の最後の一プロセスと見るのは間違がった考え方。ＳＬＣＰにそんな考え方はない。」
保守作業が開発の最後にちょこんとくっついているように思われるのは、94年版のＩＳＯ９００１にも関係がある。すなわち、保守は「付帯サービス」と呼ばれた。わかりやすく表現すれば、「おまけ」としたのである。これは社会通念の代弁ともいえるかもしれない。保守は、おまけであってこれを目的とするようなビジネスは、考えられない、という勢いであった。問題は、そのような意識がある一方、保守は片手間でできるようなものではない。
「開発者が保守することを前提とするから，開発品質が上がらない。保守性計画もいい加減になる。」
「どうせ保守もやるのだから、そのときゆっくり直せばいいじゃないか、この忙しい時期にあわてて直しておく必要はない。」こんな考えがまかり通っていた時代があった。もしかして、今もそうか？
開発部門と保守部門が分かれているのは悪いことではない。めりはりをつけてインターフェースを明確に責任を明確にすることにする。リスクを予見し、予防しようと考える、これがシステム品質を向上させる重要な役目を担うことになる。
「保守担当者，管理者，リーダ，レビューアの責任分解点を明確にして，作業プロセスを進めること。」
事故や不満は、役割分担が不明確なところに発生しやすい。保守にかかわらず、一般的話しであるが、仕事の複雑性から、保守は特に責任が不明確なりやすい。
「修正作業をいくら効率化しても，保守コストは下がらない。原因調査・分析，テスト工数削減が有効。」
保守の効率化を考える上では、コストのかかる作業に付いて、分析をすべきである。しかし、実際は、この部分が一番単純化、標準化しにくいところである。現場主導で、手を入れることが、必要である。
「個々の保守案件にそれぞれプロセスがある。プロセスごとの共同レビューを実施しないと管理不在になる。」
共同レビューは、品質を維持する上で、重要な作業である。保守業務の中で、徹底するよう習慣付けていくことが重要である。
「ユーザが積極的に使えば，当然，不具合，機能強化の要望が多く出る。案件がまったく出ないのは，まったく使われていない無価値なシステムと言える。」
苦情が出たり、障害の多いシステムは敬遠したいものだが、ユーザにとって重要なシステムであるという言うこともできる。文句は、期待や激励だと判断して行きたいものである。
「第三者の保守者に引き継げないレベルの開発品質でリリースするから開発者が保守しなければならない。」
開発者は、保守者に引継ぎができるようにインターフェースを明確にし、問題点をなくし、必要ドキュメントをそろえることをしなければ、いつまでも自分が保守することになる。たとえ、逃げるように保守者に作業を引き渡しても、後で、問題が発覚すれば逃げ切れるものではない。
「行き当たりばったりの保守対応では問題。個々の保守対応の効率化，高品質，対応スピードの高速化を図るためのインフラ整備が重要。」
保守を戦略の柱とすれば、それを実現する環境に対しても配慮すべきである。保守はしばしば劣悪な環境で行われる。これでは、ビジネスも伸びないし、人も育たない。
「開発者に保守性計画を出させることの重要性を強調」
保守性計画とは、保守をしやすくするための方法について、計画を立てて実施することを言う。それは当然、開発段階で造りこまれたドキュメントのわかりやすさ、読みやすさ、適切性であり、他者が保守することを前提として、作られたプログラムであり、設計書である。
もし開発時にこれらの考慮を欠いたなら、できあがったシステムにこの機能が盛り込まれる可能性はない。このつまづきは、システムが廃止されるまでずっと続くことになる。
保守性計画は、必要であるため、開発者がこれを作成しないのであれば、保守者がこれを負担しなくてはならない。しかしながら、保守者の仕事ではない。
ことわざパロディ索引
【仰いで保守にはじず】 ５
【後は野となれ、保守となれ】 １３
【あわてる保守はもらいが少ない】 ８
【言うは易く保守は難し】 ９
【一寸先は保守】 １７
【うまいまずいは保守加減】 ９
【馬には乗ってみよ、人には添うてみよ、保守はやってみよ】 ９
【運を保守に任す】 １５
【運を保守に任す】 ２０
【同じ穴の保守】 ５
【勝って保守の緒をしめよ】 １８
【禍福はあざなえる保守の如し】 １４
【かわいい子には保守をさせろ】 １
【聞いて極楽、見て保守】 ５
【腐っても保守】 ５
【国破れて保守あり】 １５
【苦しい時の保守頼み】 １９
【郷に入っては保守に従え】 ２０
【ころばぬ先の保守】 １０
【先んずれば、保守を制す】 １０
【先んずれば、保守を制す】 ２１
【地獄の沙汰も保守しだい】 ８
【上手の手から保守がこぼれる】 １７
【人事を尽くして保守を待つ】 １２
【少年老い易く、保守なりがたし】 ２
【捨てる保守あれば、拾う保守あり】 ３
【すべての道は保守へと続く】 ６
【急いては保守を仕損ずる】 １３
【背に保守はかえられぬ】 １４
【船頭多くして、保守山へ登る】 １５
【千里の保守も一歩から】 ３
【小さく保守して、大きく育てろ】 １１
【鶴は千年、保守は万年】 ６
【天網恢恢保守して洩らさず】 ７
【所変われば保守変わる】 ７
【とんびに保守をさらわれる】 ２１
【長い保守にはまかれろ】 ６
【泣き面に保守】 １９
【習うより保守せよ】 ２
【習わぬ保守は読めぬ】 １７
【敗軍の将、保守を語らず】 １２
【花は桜木、人は保守】 ４
【親しき仲にも保守あり】 １４
【親しき仲にも保守あり】 ２１
【風雲保守を告げる】 ４
【覆水保守にかえらず】 １７
【保守あっての物種】 ３
【保守来たりなば春遠からじ】 ４
【保守こそものの上手なれ】 １
【保守して得とれ】 １６
【保守すり合うも他生の縁】 １９
【保守で鯛を釣る】 ４
【保守転じて福となす】 １４
【保守に王道なし】 ２
【保守に金棒】 １
【保守に手を噛まれる】 １９
【保守にも棒にもかからない】 １５
【保守の門には福来る】 ４
【保守の下の力持ち】 １６
【保守の引き倒し】 １４
【保守は一日にしてならず】 ６
【保守は惜しみなく奪う】 ６
【保守は、金なり】 １８
【保守は三文の得】 １８
【保守は長く、人生は短し】 ６
【保守は何でも知っている】 １
【保守は寝て待て】 １１
【保守は百薬の長】 １０
【保守は道連れ、世は情け】 １８
【保守は身を助く】 ４
【保守は世に連れ、世は保守に連れ】 ８
【保守をもって保守を制す】 ４
【仏作って保守いれず】 ７
【身から出た保守】 １２
【寄らば、保守の陰】 １１
【類は保守を呼ぶ】 １１
【論より保守】 ５
【災い転じて保守となす】 １８