システム開発の業務に、保守・運用という業務があります。開発されたシステムの、実際の運用や、継続的なメンテナンスを行う業務です。
フリーランスエンジニアにとっても、保守・運用は他人事ではありません。この記事では、筆者の実際のワークフローを通して、フリーランスエンジニアにとっての保守・運用業務の実際を紹介していきます。
ソフトウェアには保守・運用がつきもの
一般的な工業製品では、製造されたらあとは販売されるだけというケースも多いでが、ソフトウェアの場合、
- 継続的なアップデートが必要
- 実際の運用を担当する人が必要になる場合もある
といったように、必ずアフターフォローが必要になります。これが保守・運用です。
フリーランスエンジニアの場合、典型的なのは、自分が開発したWebシステムの運用を自分で行うという業務になります。
Webシステムでなくても、バグをフィックスしたり、ソフトウェアで利用している周辺技術のアップデートに対応してアップデートしなければなかったりと、様々な保守業務が発生します。
これは会社であれば専門の担当者がいてその人が対応するということになる場合も多いですが、フリーランスエンジニアは自分でやらなければいけません。
保守・運用業務は実は、段取りによって仕事の負荷が全く異なってくる業務でもあります。ですので、未経験の方は、実際に保守・運用業務を行っているエンジニアの仕事内容を聞いておいた方がいいでしょう。
段取り次第で、大きく毎日の仕事量が変わってくるのです。
保守・運用の具体的なワークフロー
それでは実際に、保守・運用のワークフローを紹介します。
アップデート
あなたが利用しているソフトウェアも、アップデートが頻繁にかかることと思います。
現在において、ソフトウェアは最初ミニマルな機能でリリースし、アップデートしていく中で洗練させていく、という手法が一般的です。
あなたが開発したソフトウェアも、一度開発して終わりという場合はほぼありません。アップデートが必要になります。
ソフトウェア・アップデートは大きく次の3つのパターンに分かれます。
- バグフィックス
- 仕様変更
- 外部リソースの仕様変更に伴う作り変え
それぞれについて解説します。
1. バグフィックス
バグのないソフトウェアはありません。一般的に、ソフトウェアは99.5%正常に動けばリリースして良いとされています。裏を返せば、0.5%異常に動くのです。だから、バグフィックスは常に必要な作業となります。
リリースして稼働させているうちに、開発時には想定できなかった使い方をされたり、予期できなかったデータを処理しなければなかったりと、バグの原因は様々です。
放っておいてもいいバグ、致命的なバグ、様々あります。致命的なバグのときは、他の仕事を止めても優先的に対応しなくてはいけない場合もあります。
ただ、バグフィックスするときは、そのフィックスによって新しいバグを作りこむことがないよう、十分注意してください。時間がない中でのバグフィックスとなった場合、誰しもが焦るものですが、だからこそ、細心の注意を払って作業してください。
最近はテスト自動化ツールもいろいろ出てきていて、一つバグをフィックスるごとに全体のテストを一通り行える場合も多いです。ツールを上手に使い作業しましょう。
2. 仕様変更
ユーザの要望が変わった、もしくは新しい機能の追加などで、仕様を変更する場合があります。この場合、得てして大掛かりな変更になります。
そのとき重要なポイントは、もともとの内部構成が、変更に耐えられるものであるかどうかです。時にはゼロから作り直した方が早い場合もあります。
そのさじ加減は、経験を積まないと分からないものですが、疎結合で機能がまとまっている構成であるほど、仕様変更に柔軟に対応できるので、初めから仕様変更を想定して開発しましょう。
3. 外部リソースの仕様変更に伴う作り変え
OSや使用しているAPIの仕様変更などです。これは、小さい修正で済む場合が多いです。
また、言語やフレームワークのバージョンを最新のものにしなければなかったり（たいていバージョンは一度決めたら固定ですが）もします。この場合、全体に渡って修正が入ることになります。
仕様変更当初は参考となるドキュメントも少なくて、やや難儀な修正ではありますが、ソフトウェアが変更によって動かなくなるなら、急を要する修正です。対処しましょう。
日次定期処理運用
夜間にバッチジョブを動かしている場合があります。他にも、Webシステムであればcronですね。
筆者は、PCのみで見るメールアドレスにバッチジョブとcronの終了報告（エラーの場合はエラー報告）のメールを送信するようにしていて、翌朝にその結果をチェックします。場合によってはバッチジョブの一部をやり直したり、サーバーを再起動したりします。
最初はリアルタイムでメールを見ていたのですが、寝る間際にメールを見るとリラックスして眠れなくなるので止めました。仕事の時間は決めた方がいいです。働き方は重要です。
事故
Webサーバーは落ちることがあります。負荷が高かった、サイバー攻撃があった（DOS攻撃などは防ぎようがありません）など、様々な原因で落ちます。
このような事故への対応も、保守・運用業務の一つです。
事故にはすぐに対応しなくてはなりませんが、同時に、事故対応はストレスがたまる業務です。24時間いつでも通知が来るのは気が抜けません。
だから、事故対応には向き不向きがあります。もし自分が事故対応に向いていないと思ったら、思い切って保守・運用業務を人に任せるのも一考に値します。やってみて、無理だと感じたら考えてみてください。
ログ解析
Webサーバーのログはサーバーの挙動をリアルに表します。攻撃の跡、そのWebシステムのどの部分がアクセスされているか、などなど、ログが語るものは多いです。
だから、ログ解析は保守・運用業務の大事な一部分です。
小さなWebサーバーであれば目でログを見ていればいいのですが、少し規模が大きくなると手に負えなくなります。20KBのログを解析するのは手作業では無理です。
そんなときはSaaSなどでできているツールの導入を考えてください。敷居は高いですが、簡単にログが解析できます。
保守・運用の心構え
保守・運用は、毎日の定型業務として組み入れておくのが一番です。筆者は朝一番の定型業務です。その中で、対応が必要なものだけを対応します。
また、クライアントにも、何か普段と違うことが起きていたら密に連絡を取るのをおすすめします。クライアントは心配性なものです。あなたが専門家としての知見を添えて起きたことを分析すれば、顧客満足度は上がるでしょう。
このとき、起きたことをただ報告するのは絶対にしてはいけません。対応策を考えてから報告するようにしましょう。
インシデントにまず対応しなければならないのは、保守・運用を任されているあなたなのですから。
まとめ
この記事ではフリーランスエンジニアの保守・運用業務について書いてきました。実際のワークフローがイメージできたでしょうか。
繰り返しになりますが、ソフトウェアは開発したら終わりではありません。顧客満足度のため、的確な保守・運用を行うようにしましょう。
