最終更新日 2025年1月13日
インフラエンジニアは作業時に過去の作業実績を重視する？
インフラエンジニアの仕事では、過去の作業実績がとても重要視されます。
初めてインフラ系の現場に入った方や、エンジニア初心者の方にとって、「なぜ過去の実績がそんなに大事なの？」と思うこともあるでしょう。
インフラエンジニアがネットワークやサーバーの構築や設定変更を行う際、過去に作業実績があるかどうかで状況が大きく変わります。
作業を始める前に、エンジニアは作業手順書を作成し、それを顧客に提出して内容を確認してもらい、作業承認を得るのが一般的ですが、この作業承認のプロセスにおいて、作業実績の有無が顧客の対応に大きなインパクトを与えます。
過去に同様の作業実績がある場合、顧客からの確認は比較的スムーズで、細かい部分を突っ込まれることなく承認を得られることが多いです。
しかし、作業実績がない場合、手順書を非常に細かくチェックされるだけでなく、「なぜこの設定にしたのか」「この部分で問題が発生しないことをどう確認したのか」など、具体的で厳しい質問が多く投げかけられます。
このように、作業実績の有無が、承認プロセスや顧客の信頼度に大きな影響を及ぼすのです。
X(旧Twitter)では下記のような投稿がされています。
このことからも、インフラエンジニアでは過去の作業実績が重要視されていることが分かります。
この記事では、過去の作業実績が重視される理由を、初心者の方でも理解できるように丁寧に解説します。具体的な事例も交えて、インフラエンジニアとしての作業を成功させるためのポイントもお伝えします。
スポンサーリンク
過去の作業実績が重視される理由
過去の作業実績が重要視される理由は大きく分けて5つあります。
- 同様の手順で問題がないことを確認できるから
- 想定外の事象が発生するリスクが低くなるから
- 作業実績がある場合1から10まで確認する必要がなくなるから
- 手順を標準化できるから
- 作業トラブルが発生した際に、過去の実績を根拠に説明できるから
上記の5つの理由について以降でそれぞれ事例を交えて解説していきます。
理由① 同様の手順で問題がないことを確認できるから
作業実績が重視される理由の一つは、過去に同じ手順で作業を行った実績があることで、予定している作業が問題なく実施できると確信を持てる点です。
具体的には、過去に同じ手順で本番作業を行った事例があれば、それを根拠として「同じ条件下で同じ手順が成功する」と説明することができます。
例えば、作業で使用するアカウントに顧客から特定の権限が割り当てられる場合、その権限で必要な操作が全て行えるかどうかを事前に確認する必要があります。
権限によっては、一部の操作が制限されたり、使用できる機能が限定されて表示される場合があります。
そのため、本当に想定通りの手順で操作できるかどうかは、実際に試してみないとわからないことがあります。
このような場合、過去に同じ権限で同じ手順を実行した実績があれば、予定している作業も問題なく実施できると確信が持てます。
理想的には、本番環境と完全に同じ検証環境を作り、想定した手順を事前に確認するのが望ましいですが、実際には本番と全く同じ環境を構築するのはほぼ不可能です。
そのため、過去の本番環境で同様の条件で同じ手順を実施した実績がある場合、それが重要な根拠となります。
このように、過去の作業実績があることで、「予定している手順で操作できない」という不安要素を排除することができます。
不安要素を排除できれば、顧客やチームが手順書を確認する際も「この手順で問題なく実施できる」という前提でレビューを行えるため、確認にかかる時間や手間を大幅に削減することができます。
事例 Microsoft 365でメールボックスの権限付与を実施したが失敗
顧客から「特定のユーザーに別のメールボックスへのフルアクセス権を付与してほしい」と依頼を受け、Microsoft 365管理センターで作業を実施しました。
しかし、作業を進める中で、顧客が用意したアカウントに十分な権限が付与されておらず、必要な設定を実行できないという問題が発生しました。
使用したアカウントに「Exchange Online管理者」の権限が付与されていないため、Add-MailboxPermissionコマンドを実行できませんでした。
過去に同じ顧客環境や類似の条件で、メールボックス権限を付与した実績があれば、事前に「この作業にはExchange Online管理者の権限が必要」ということを把握できていたはずです。さらに、過去に実施した際の権限設定や手順を参照することで、適切な権限をリクエストすることができ、作業をスムーズに進められるはずです。
このように、過去の作業実績がない場合、作業を進める中で想定外の問題が発生しやすくなります。一方、過去の実績があれば、事前にリスクを排除し、無駄な手戻りを防ぐことが可能です。
理由② 想定外の事象が発生するリスクが低くなるから
作業実績が重視される2つ目の理由は、同じ条件や環境で過去に同じ作業を行った実績があると、予期せぬトラブルが発生するリスクを大幅に低減できることです。
例えば、ソフトウェアのアップデート作業を行う場合、設計書をもとに机上で検証した結果、問題はないと判断したとします。しかし、実際の環境では設計書に記載されていない別のソフトウェアがインストールされており、そのソフトウェアとの互換性の問題によってバージョンアップが失敗してしまうケースがあります。
一方で、複数の拠点で同じ構成やソフトウェアを導入しており、同じアップデート作業を行った実績がある場合、過去の事例をもとに環境の互換性や問題点、どのように対処したかを 事前に把握できるため、こうした想定外のトラブルを未然に防ぐことができます。
このように、同じ環境や条件で同じ作業を実施した実績があることは、作業中に起こり得る予期せぬ事象のリスクを大幅に低減することができます。
事例 Windows Serverの累積更新プログラム適用作業
顧客のWindows Server環境で累積更新プログラムを適用する作業を実施するべく、設計書をもとに机上検証を行い特に問題なくアップデートできると判断しました。
しかし、実際のサーバーには設計書に記載されていないサードパーティ製のウイルス対策ソフトウェアがインストールされており、このソフトウェアが累積更新プログラムと互換性の問題を起こし、その結果、更新プログラム適用後にサーバーが再起動ループに陥るトラブルが発生しました。
設計書にはWindows Serverにインストールしたソフトウェアの情報が記載されていましたが、サードパーティ製ソフトウェアがそこに記載されていませんでした。
同じWindows Serverのバージョンや構成で、同じ累積更新プログラムを適用した実績が他の拠点がありましたが、その情報の確認ができていませんでした。その作業でも同様に互換性の問題が生じ、アップデート前にウイルス対策ソフトウェアを一時的に無効化する対策をしていました。事前にこの実績を確認できていればこのような事態は防げたはずです。
理由③ 作業実績がある場合1から10まで確認する必要がなくなるから
既に同じ手順で作業実績がある場合、作業手順書に記載されている手順を一から十まで確認する必要がなくなります。
理由は過去作業でも同様に作業手順書の手順をレビューしているため、他の人も目を通して、同じようにレビューし、同じようにその手順について承認がされているという証でもあるので、そこまで細かく確認する必要がなくなるからです。
このように作業実績がある手順を採用することは、その手順が記載された作業手順書を確認する際にかける労力を削減できます。
事例 サーバーアップデート作業
月次のサーバーアップデート作業を行っており、この作業には、OSパッチの適用、ログの確認、再起動の手順を行っていました。最初の作業承認依頼時に作業手順書に作業手順を記載するとともに顧客へのレビュー依頼をする形で承認を得ました。作業承認時、作業手順書をもとに詳細なレビューが行われ、複数の担当者から承認を得ました。
その後、同じ作業手順書を基に2か月連続で同じ作業を実施しましたが、特に問題は生じませんでした。
3回目以降のアップデート作業では、手順書のレビューは「変更点がないことを確認する」程度に留められました。一から十まで全てを確認せずとも、過去の作業実績に基づいて確認の観点を減らすことで、レビュー時の労力を削減できました。
このように過去の作業実績がある場合、レビュー時の確認をを簡略化できます。
作業を効率的に進めるためにも作業実績の有無は重要になります。
理由④ 手順を標準化できるから
作業実績を重視する理由の一つに、「作業手順を標準化する必要がある」という点があります。
同じ作業であれば、同じ手順で実施するのが望ましいためです。
なぜなら、手順がバラバラだと顧客が混乱する可能性があるからです。
例えば、同じ作業をGUI操作で行ったり、スクリプトを使って行ったりと手順が統一されていない場合、顧客は「なぜ方法が変わったのか」と疑問を持ちます。また、「過去の手順に問題があったのではないか」「そもそも手順が誤っていたのではないか」といった不安を抱かせてしまうことにもつながります。
そのため、顧客の立場からすると、作業実績がある場合は、過去と同様の手順で実施したほうが余計な心配をかけず、また、手順を変更した理由を聞かれるなどの突っ込みを避けることができます。
特に明確な理由がないまま手順を変更すると、顧客から指摘を受け、その回答を作文するのも労力がかかります。こうしたリスクや余計な労力をかけないためにも過去の作業と同じ手順で実施することが良いと考えています。
事例 ネットワーク機器の設定作業
ある企業で、複数の拠点間を接続するネットワーク機器の設定を行いました。初回の設定時には、手順書に従いCLI（コマンドラインインターフェース）で設定を実施し、顧客にもその手順を共有して承認を得ていました。
次回の設定作業時、別の担当者がGUIツールを使って設定を行いました。理由は「GUIの方がわかりやすく、作業が早く終わる」と判断したためです。しかし、顧客に事前の説明がなかったため、作業報告を見た顧客が混乱し、以下のような質問を受けました。
• なぜ前回と方法が違うのか？
• CLIでは何か問題があったのか？
• 今後の保守作業時に、どちらの方法で対応するのか？
以降、実績がある作業においては、操作方法を変更する場合、顧客に事前に説明と承認を得ることになってしまいました。
理由⑤ 作業トラブルが発生した際に、過去の実績を根拠に説明できるから
作業実績が重要な理由の一つは、万が一作業中にトラブルが発生し、顧客への報告が必要になった際に「過去の作業実績に基づいてこの手順で実施しました」と、作業実績を盾に説明できるからです。
作業実績は、同じ環境・条件で行われた確かな根拠となり、顧客への説明材料としては非常に強力です。
特にトラブル時には、手順が適切だったかどうかを確認する必要がありますが、作業実績があればその手順が過去に問題なく実行されていたことを証明できます。
そのため、トラブルが発生した場合の切り分けのことを考えても、作業実績の有無は非常に重要なポイントになります。
事例 ネットワーク設定変更時の障害対応
ある企業のデータセンターで、ネットワーク機器の設定変更作業を実施しました。この作業は過去にも同じ環境、同じ手順で複数回行われており、問題が発生していませんでした。そのため、作業手順書には「過去の作業実績あり」と明記さしていました。
しかし、今回の作業中にトラブルが発生し、一部の通信が止まりました。結果、顧客への報告が必要となり、「手順には問題はないのか」という質問を受け、以下のように回答しました。
今回の手順は、過去に同じ環境で問題なく実施された実績があるものであり、同じ条件のもとで、過去の作業では成功しているため、手順自体には不備がないと考えています。
過去実績があることから、手順自体には問題がないことが顧客に伝わり、トラブルの原因は別の要因であるという方針で調査を進め、結果的にキャリア側の設定ミスであることがわかり、無駄なく復旧作業を進めることができました。
作業実績をもとに作業する重要性
インフラエンジニアの仕事では、過去の作業実績を参照することが非常に重要です。特に、ミスを防ぎつつ効率よく作業を進めるためには、実績に基づいた手順を採用することが最善の選択であると考えています。
この記事を参考に、作業時に過去の実績を活用し、安全かつ効率的に作業を進めて頂けると幸いです。
ゴリタン
インフラエンジニアとして、ネットワークとサーバーの運用・保守・構築・設計に幅広く携わり、
現在は大規模政府公共データの移行プロジェクトを担当。
CCNPやLPICレベル3、AWSセキュリティスペシャリストなどの資格を保有しています。