4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

保守業務についての知見

Posted at

保守業務をいくつか経験して得た知見を共有します。
対象の案件はBtoBを想定しております。
またここでは取引先会社のことを取引先とします。

君は誰?

入社3年目のエンジニアです。
保守案件を取りまとめています。

引き継ぎについて

ここでは対象の案件を前任から引き継がれた場合を話します。
よって、開発後そのまま保守業務へスライドした場合は除きます。

保守を行うことになったら、まず業務の引き継ぎを行う必要があります。
前任者がいるのであれば頼ると良いでしょう。

引き継ぐべき内容は以下になります。

ドキュメント情報

設計資料や全体構成図、マニュアル、引き継ぎ資料(あれば)をできるかぎり集めて読みましょう。
外部APIを使用している場合はその資料も探してください。

アクセス権限

aws、gcp、github、sluckなどの必要な権限の付与を取引先または前任者に依頼します。

デプロイ方法の確認

デプロイの方法は確認しましょう。これがなければ終わりません。

環境へのアクセス

本番やステージング環境などへのアクセスを確認します。
また、アプリやブラウザ側からも入れるように各環境のURLやストアページへのアクセスも確認します。

関係者一覧の洗い出し

案件に関わっていた社内と取引先担当者の情報を洗い出します。

取引先担当者については運用責任者・請求先担当者・運営責任者の連絡先を手に入れられれば
連絡先に困ることはないと思います。
社内に関わっていた人が残っていればその方に業務の相談が出来ます。

提供内容

受付時間や対応時間、上限稼働時間、対応内容を契約書を読み込んで覚えましょう。
例えば月ごとの上限稼働時間を超えてしまう場合、取引先に交渉が出来ます。
また、対応内容の範囲外(例えばOSのバージョンアップ)などを依頼された場合、追加開発として話を進めることが出来ます。

保守対応範囲内の残タスク

前任者、もしくは取引先に未対応のタスクを聞きましょう。
その後、どのくらいで全て完了するかスケジュールをたて、計画的にこなしていきましょう。

tips)
これらの引き継ぎ内容が資料化されていない場合、今のうちに資料を書いておきましょう。
案件をいつまでも行うことはないのでいつでも次の担当に引き継ぎできる体制を整えておき、円満な引き継ぎを目指しましょう。

人員について

必ず二人以上その案件に関わっているようにします。
保守案件は突発的に依頼が来ることが多いからです。
規模にもよりますが、常に複数人いる必要はないのでサブとして有事の際は誰かが業務を行えるように整えておくと良いです。
誰も旅行中に部屋にこもって作業をしたくはないでしょう。

業務について

保守案件は依頼が来ることがほとんどです。
この機能を追加・削除して欲しい、このデータを追加・削除して欲しい、このバグを修正して欲しい、この機能を調べて欲しいと言ったものです。
手順は大まかに以下の通りです。

  1. 依頼が届く・ヒアリング
  2. 過去に同様の依頼がないか探す
    同様の依頼があり、手順書もあればその通りに行えば良いでしょう。
  3. 検証を行い、対応方法を模索する
    ログやコード、場合によってはサーバーの監視データから対応方法を模索します。
  4. 対応想定時間を割り出し、取引先へ確認する
    依頼によっては月ごとの上限稼働時間を超える場合があります。
    単純に時間のかかる依頼であったり、大量に依頼がある場合などです。
    なのであらかじめ対応時間を割り出し、今月行うか、来月以降行うか、または対応自体行わないか取引先に判断をしてもらいます。
  5. 対応
    対応を行います。
    対応内容は細かくメモしておきます。
    コマンドレベルに事細かく、メモを見れば何も考えずに行えるくらい書いておくことがベストです。
  6. 報告・作業内容の保存
    先方に報告を行えば終了です。
    作成した対応内容はプロジェクトメンバーが確認しやすい場所に保存しましょう。

重要なのは逐一対応内容のメモをとり、どこかプロジェクトメンバーが確認しやすい場所に保管しておくことです。
メモがあれば次同じ依頼が来た時に少ない時間で対応を行うことが出来ます。
取引先も早く問題を解決でき、こちらも時間を節約できる。winwinでユーザーフレンドリーな世界が待っています。

属人化箇所について

保守業務を行なっていると、同じ依頼が何度も来ることに気がつきます。
これを私は属人化箇所と呼んでいます。
属人化箇所は業務上必要な箇所ですがエンジニアによる変更が必要な箇所です。
これがあると毎回依頼をしなければならず取引先としても負担になります。

属人化箇所を見つけたら取引先と解消するか話し合いましょう。
修正にどのくらい時間がかかるか、追加開発費用は必要になるか天秤にかけ、話がまとまったら対応しましょう。

例えば毎月行う作業があるとして、エンジニアが行う時間が5分程度とします。この属人化箇所を解消するために必要な作業時間は3時間。
とすると単純計算で作業時間分のコストを属人化箇所解消で削減される時間が上回るのに3年ほどかかる見込みとなります。
長期運用の予定がないならばこの箇所は対応しない方が良いでしょう。

逆に毎週20分かかり作業時間が3時間ならば先ほどの計算で3ヶ月なので早めに対応した方がいいでしょう。

最後に

保守業務のなかで新しい開発のチャンスがくることもあります。
そのチャンスを掴むためにも円満な保守業務を保っていきましょう。
そして次保守を行う後輩に感謝されるようにドキュメントのメンテナンスは忘れずに。

4
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?