はじめに
コジマです。
エンジニアを志す方々は「作る」ことを考える方が多いと思います。
システムを作った後、何故運用を続けられるのか？
というのを考えてみてください。
それはサービスやソフトウェアを「守る」人たちがいるからなんですね。
「保守」という作業がIT業界には存在します。
地味なイメージ持つと思います。確かに地味だと思います。
保守を嫌がる人もいると思います。
開発しないですしね。でも大事な役割だと思うので、お話しようと思い書くことにしました。
私の経験に基づいてお話致します。
「保守ってなにすんの？」って部分少しでも伝えられたらと思います。
説明していく
契約について
リリース後の運用を続けられるようにしたり、よりよいサービスにしていくために行う業務を「保守」と呼びます。
お客様とこちらで保守契約というのを結びます。
大まかにこんな内容を取り決めます。
- 保守の期間（例：2018/11/1～2020/10/31の2年間）
- 保守の金額（例：月100万など）
- 保守の範囲（例：仕様の問合せ対応はします。プログラム修正は別途費用が発生します。等）
ざっくりですが、こんな感じ（細かくはもっとあるよ）
弁護士に頼んだりしてめっちゃお硬い文章で契約書を書いてもらいます。
それが正義(justice)です。
作業内容
じゃあ実際保守って大体どんなことをやるのかというと
- 調査依頼
- 作業依頼
- 障害対応
の3種類に分けられると思います。
大枠としては「納品したシステムの運用に関してお客様をサポート」をします。
上述した点を少し掘り下げていこうと思います。
一応今はBtoBのシステムの場合を想定しています。
BtoCのサービスでも大筋は変わらないと思うので、保守作業について気になる方はみて
調査依頼
「アプリが変なエラー出してる！なんで？どうすればいいの？」
「この機能使い方わからない！教えて！」
など。仕様、使い方、運用改善なんかについての質問に答えてあげます。
回答するためには調査が必要です。
簡単なものはメール一本返して終わる時もありますし、難しいものだと調査資料を作成して結果報告を行うこともあります。
調査の結果、作業必要となれば後述する作業依頼に移りますし、
実はバグでした。となれば後述する障害対応へと移っていきます。
作業依頼
「サーバー新しくしたい！」
「組織改変でデータが一度に変わって大変だから代わりにやって！」
のようにお客様の運用の助けをする役割があります。
契約内容にもよると思いますが、基本的に見積った上で別途費用請求を行います。
あまり難しいことは発生しないです。
ただ、お客様の運用環境に変更を加えることもあるので、作業ミスを発生させてはいけません。
作業ミスによってシステム障害が発生したりすればクレームになります。
そうなってしまうと以下の障害対応が発生してしまいます。
障害対応
「ネットワークつながらなくなった！直して！」
「あるデータ入れたらソフトが動かなくなった！動かせるようにして！」
のようにお客様の運用の妨げになる事象を解消します。
これが一番重要かつ大変です。
経年劣化によるハード障害の場合などは別途取替費用を請求して対応することもありますが、
プログラムバグや作業ミスによるものである場合には「瑕疵対応」という形で無償対応を行います。
ちょっと障害対応について詳しく話していこうと思います。
障害対応のいろは
上流工程きちんとこなしていれば滅多に訪れるものでもありませんが、やはりゼロではありません。
障害対応は本当に大変です。
上手く捌けないと泥沼化します。そうなると地獄です。
別枠で実際どんな作業が発生するのか見ていきたいと思います。
１：原因究明
まず、「何故」障害が発生したのか突き止めます。
例外はありません。絶対やります。
プログラムかもしれないし、データベースかもしれないし、サーバーの設定かもしれません。
問合せ内容から切り分けて目星をつけていきます。
詳細な事象は必要に応じて都度ヒアリングを行います。
直接的な原因と根本的な原因が問われます。
いわゆる「なぜなぜ」と呼ばれるやつですね。
例えば、「追加したユーザーでログインできない」という事象が発生したとします。
直接的な原因は
「パスワードが半角英数のみの仕様だったのに、ユーザー登録画面で記号を含むパスワードの登録ができてしまった。」
ということが分かりました。（こんな間抜けなことをしないと思いますが、例なので許してね）
しかし、それでは許してくれません。
「なんでこんなしょうもないバグを見逃して納品したのか」を説明しないといけません。
根本的な原因を探る必要があります。
調査したら「単体試験でパスワードのバリデーションに関する試験項目に誤りがあった」ことが分かりました。
まだ、これが根本原因なわけではありません。
根本的な原因は
「試験の作成から実施まで1人で担当していて、レビューの実施工数の確保ができなかった。」
となっていきます。
繰り返しますが、あくまで一例ですよ。
こんなミス実際にやらかしたら一発で信頼失うと思います。
２：対応策提案
原因が分かったら対応策を提案します。
もしかしたらお客様で運用回避してくれるかもしれません。
しかし、9割9分くらい対応は必要になります。
直接的な原因に対応する「暫定対処」と
根本的ば原因に対応する「恒久対処」というものが必要になります。
さっきの例の続きだと、暫定対処は「ユーザー登録画面で記号を含むパスワードを登録できないように修正する」となり
恒久対処は「レビュー体制の強化。試験の作成者と実施者を分けて実施する体制を組む。」な感じになるかと思います。
恒久対処は恒久なんで今後とも継続する必要があります。
３：作業前試験
プログラム修正の修正が発生したら試験環境で動作試験をします。
データベースのテーブルを更新するデータの作成をしたらそのデータに問題がないか確認します。
機能試験だけでなく、実際にお客様の環境に修正プログラムを導入する想定で導入試験も行います。
このために作業手順書を事前に作成します。
障害の復旧のためなので、確実かつ慎重に行う必要があります。
ここを適当にこなして更なるバグを生むとクレームや訴訟問題にもなります。
４：復旧作業
試験を完了したらお客様と日程調整を行い、復旧作業を行います。
対面で障害発生の経緯や原因、今回の対応内容なんかを説明してお詫びすることもあります。
大体偉い人がやってくれますが、自分もあなたもいつかはその偉い人になるんですよ。
3で作成した作業手順書に従って作業を行います。
慣れた作業でも一つ一つ慎重に行います。
試験でOK出てもこれを間違えるとすべてが水の泡です。責任重大です。
５：報告書提出
すべて作業が終わったら障害報告書なるものを提出します。
いつ、何の障害が発生して、誰がどのように対応したか。その経緯も含めて
詳細に記載します。
細かい内容や書き方については触れませんが、気になる人は
「障害報告書 書き方」なんかでggってみるといいと思います。
最後に
大体どんなことするか見えましたでしょうか？
確かに「エンジニアになりたい！」と夢見る方々が思い描くような華々しいものではありません。
地味だし場合によっては大変だし。
しかし、皆が普段使っているサービスやソフトウェアが長く使えるのも
こうしてシステム全体を守ってくれる人がいるからなのです。
こうして保守の大事さを問うことで保守という作業の実績ももっと評価されたい
障害対応でプログラムの修正が発生すると試験をしないといけません。
試験をするとエビデンスを取らないといけません。
皆が大嫌いな「excelエンジニア」にならなければいけません。
好きなことをやりたい気持ちはとても分かりますが、
好きなこと適当にやると痛い目を見ます。
また、分業している場合は迷惑をかけます。
保守がやりたいんだ！という人はあまりいないとは思いますが、
「保守」というものはシステム開発の先にある大事な役割なんだと
今一度感じて頂ければ幸いです。
この記事が面白いと思ってくれたら是非Twitter(@kojimanotech)のフォローもお願いします！
以上、読んでくれてありがとうございました！
