Get a network qualification

資格取得でネットワークエンジニアへの道が開けます。
資格取得に役立つ勉強法を自身の体験を交えて紹介します。
現在、過去数百に及ぶ記事を只管修正中(ちょwww)。

資格を手に入れてネットワークエンジニアになろう

スポンサーリンク


21
2015  23:39:15

元ネットワークエンジニアの構築エンジニアとしての仕事の遣り甲斐とその難しさ><

構築エンジニアの仕事のやり甲斐と難しさserver-construction-engineer-work.jpg

相変わらず、構築エンジニアとしての多忙極まりない日々を送っております><。

とは言っても、まだ今の職場に入場して2ヵ月半程なので、まだまだ半人前以下の働きしか出来ていないんだけどね^^;。

改めて、サーバ構築というお仕事の難しさを実感している今日この頃であります><。

構築エンジニアは日々が期日との戦いです><


なんと言っても、毎日が期日との戦いであり、その為に各段階毎に計画を立て、最終的に成果物であるサーバを納期に間に合うよう仕上げる事が構築エンジニアに与えられた使命なのです。

その為に、当初からしっかりと構築計画を立て、設計から構築に至るまで適切に対処する事が求められるわけです。

実際にWBS(Work Break down Structure)※を作成し、各段階での作業タスクを設定し、チームで作業分担し合って業務に取り組んでいます。

その際も、各自が独断で先行しないよう、必ず、設計チームと実際にサーバを構築する実装担当の構築チームとで情報連携を行いながら、間違いのないよう業務を遂行しているわけです。

もっとも、ソレでも情報伝達の遅れ伝達漏れ構築資料の誤り作業ミスが起きることがあります><。

※プロジェクトのスケジュール管理に使われるツールの事
作業工程を「ワークパッケージ」と呼ばれる最小レベルの作業単位に分け、ワークパッケージ単位の具体的な作業である「アクティビティ」に作業内容を設定するものです。

構築エンジニアは「コンフィグシート」に基づいて作業を行う


サーバ実装を行う構築エンジニアにとって、もっとも信頼出来る資料としては、各顧客とのヒアリング打ち合わせに基づいて作成されたサーバ構築の為の設計書である「コンフィグシート」と呼ばれるものがあります。

また、その「コンフィグシート」に基づいて作業を行う手順や作業方法を、別途手順書に纏めており、実際の作業時にはその手順書を参照して各種設定を行います。

我々、構築エンジニアは基本的にはその「コンフィグシート」に基づいてサーバ構築を行っているわけです。

「コンフィグシート」の内容が必ずしも正しいとは限らない!?


ところが、時としてその最も信頼すべき「コンフィグシート」そのものに誤りがあり、そのまま構築を進めると顧客サイドが求めるものと全く仕様の異なるサーバになってしまう危惧を孕んでいたりします><。

実際に、構築期間に設計書である「コンフィグシート」が何度も手直しされ、当初とは全く違ったモノになる事も珍しくはありません^^;。

当然の事ながら誤った情報となった「コンフィグシート」及び作業手順書を基に作業を進めると間違った成果物が生成される事になります><。

手順書は都度見直し修正を加える必要あり!?


よって、手順書も都度見直し、修正を加えていく必要があるわけです^^;。

実際、手順書を信頼して作業を行い、設計担当者のチェックを受けた所、作業ミスが発覚し、叱られたことがあります><。
理不尽な気もしますが、要求変更に基づいた作業を行う事が必要になるわけです><。

事実、資料に書かれている情報だけを頼りに独断で構築を進めると最悪取り返しの付かない事になります><。

本来、設計書が間違っている事はあってはならない事ですが、そこは生身の人間同士、要求される成果物は契約が成立してからもめまぐるしく変わり、常に情報収集を怠ってはいけないのです><。

設計書が間違っていると正しく組み立てることが出来ない><


例えば、プラモデルの組み立て説明書がもし間違っていたとするなら、その通りに組んでも完成させる事は不可能ですが、それと同じ事がサーバにも言えるわけですorz。

この世界に入ってまず最初に学んだのは、世間一般の定石はココでは通用しないという事です><。

スポンサーリンク




構築業務と運用業務との基本的な違い


運用業務であれば、完成した成果物を監視ツール等を導入して運用マニュアルを整備し、日々の運用・管理・監視そして、より効率の良い業務改善に取り組むという使命を帯びていますが、基本的には一度ルールを設定してしまえば、それに基づいた業務を行う事になります。

また、一部の設定作業の依頼運用テストを除き、納期に追われるという事も殆どないと言えます。

これは、過去私が経験してきた運用業務で実際に取り組み、その身を持って学んできたことです。

ところが、構築の世界では決まり毎は当事者同士の話し合いや、顧客の希望によっていとも容易く覆ってしまうのです><。

納期確実に守り、かつお客様からの要望を出来る範囲で可能な限り実現する事こそが我々構築エンジニアに求められていると言えます^^;。

「仕様変更」は顧客と構築ベンダーとの折り合いがあってこそ!?


誤解を与えるといけないので、少し補足しますが、いくらお客様仕様変更を求められたとは言え、ソレを際限なく聞き入れていては、何時まで経っても仕事は完結出来ません><。

また、予算や開発工期の関係で実現不可能な場合もあります><。

よって、顧客側とベンダーである我々構築エンジニアサイドで折り合いのつくギリギリのラインで仕様変更が行われるわけです。

勿論、当初の予定通り変更される事なく、案件が進む場合も少なくありません。

要はその時々のケースバイケースという事です。

以上から、普段から設計を行う設計担当と実際にサーバ実装を行う構築チームとで連絡を密にし、常に最新情報を共有した上で作業を進める事が肝要なのです><。

構築エンジニアは設計エンジニアとの業務調整が不可欠です


特に自身が担当するタスクに関する設計担当者との情報連携は欠かせません><。

自身に割り当てられたタスクを理解し、作業タイミング設計担当者と調整した上で業務に取り組むことが求められます。

以上から、構築エンジニアという仕事は非常にイレギュラーの多いものだと言えます><。

時短や働き方改革が叫ばれるものの仕事を完結出来ない事実><


私を含め、設計及び構築エンジニアの多くが日々業務に追われ残業しているという現実はそのように考えると至極当然の事なのかもしれません><。

世間では「時短」や「働き方改革」が叫ばれ、残業に関する法案も整備される等、残業に対する厳しい見方が多勢ですが、現実は仕事が終わらない以上、残業するより他ないのです(ガーソorz)。

現状では厳しいかもしれませんが、少しでも業務軽減の方向にシフトしていく事を切に願います><。

構築エンジニアはじめ、多くのITエンジニアの方々は明らかに働きすぎですからね><。

構築エンジニアになって活躍しよう!


でも、私にとっては念願だった構築エンジニアの業務に就くことが出来、自身の活躍の場としてのフィールドが与えられていることにとても遣り甲斐を感じています。

かつてコレほどまでに充実した時間を過ごせた事はなかったかもしれません(ニヤw)。

あまり、コレまで上昇志向を持っていませんでしたが、この職場に長く務める事が出来るのであれば、ソレナリの地位を目指してもみても良いのではと少し思っていたりもします(ダマレコノ青二才がwwwww)。

とりま、残業続き体調管理が大変ではありますが、毎日元気に明るく職務に取り組みたいと考えております><。

ITエンジニアの皆さまは少なからず多忙な日々を過ごされていると存じますが、一日一日を大切にまた実りのあるものにしていきましょう><。

構築エンジニアとして必要なスキルを身につけよう!

↓ ↓ ↓

構築エンジニア関連書籍はこちら

関連記事

スポンサーリンク


 業務報告

0 Comments

Leave a comment