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

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


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

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

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

その為に、当初からしっかりと構築計画を立て、設計から構築に至るまで適切に対処する事が求められるわけです。
実際にWBSを作成し、各段階での作業タスクを設定し、チームで作業分担し合って業務に取り組んでいます。
その際も、各自が独断で先行しないよう、必ず、設計チームと実際にサーバを構築する実装担当の構築チームとで情報連携を行いながら、間違いのないよう業務を遂行しているわけです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ところが、構築の世界では決まり毎は当事者同士の話し合いや、顧客の希望によっていとも容易く覆ってしまうのです><。
納期を確実に守り、かつお客様からの要望を出来る範囲で可能な限り実現する事こそが我々構築エンジニアに求められていると言えます^^;。

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

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

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

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

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

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

特に自身が担当するタスクに関する設計担当者との情報連携は欠かせません><。
自身に割り当てられたタスクを理解し、作業タイミングを設計担当者と調整した上で業務に取り組むことが求められます。

以上から、構築エンジニアという仕事は非常にイレギュラーの多いものだと言えます><。
私を含め、設計及び構築エンジニアの多くが日々業務に追われ残業しているという現実はそのように考えると至極当然の事なのかもしれません><。

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

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

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

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

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


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

スポンサーリンク



Comment

Leave a Reply


管理者にだけ表示を許可する