【IT技術者のリアル】ITエンジニアになりたい！ITエンジニアのやりがいと苦労

---

ITエンジニアと言っても様々な分野があり、一般の方もよく見るWEBサイトの事や、普段使っているスマホのアプリを思い浮かべる方が多いと思います。

その他、自家用車にもコンピューターが搭載されており、見えない所で車の制御を行っていたり、企業の中では経理や在庫管理等のシステムがあり、コンピューターのシステムとは無縁で暮らしている方は、ほとんどいない社会になっています。

学校を卒業してから15年ほどIT企業に勤務していましたが、現在は退職しています。

私は主に企業の物流・在庫管理、工場の生産工程管理などのシステムの開発に携わってきました。

このような企業のシステムの構築は人が行っている仕事を効率化させる事を目的にしています。

クライアントから効率化させたい業務の内容を聞き、どのようにコンピューターを使って実現させるかを検討し、システムの設計・開発を行います。

ITエンジニアと聞くと一日PCに向かってプログラムを作っているようなイメージがあると思いますが、クライアントの業務理解が一番大切な事だと私は考えていて、それによって自身の様々な知識や技術力が磨かれると感じます。

クライアントによって業務の内容は様々で、他業種にいながらそれを知り、システムの開発を通して業務に携われることがオープン系エンジニアのやりがいではないかと思います。

大企業の基幹システムなどは1社で請け負うことはなく、システムを機能ごとに分割して別々のIT企業が開発しています。

IT業界は専門用語が大変多く、それを知っている前提で話すとクライアントと言葉が通じない事があります。

例えばマウスはマウスとしか言いようがないので、それを知らない人にはマウスとは何かを説明しなければなりません。

同じ業種のIT企業でも言い回しが違っていたり、複数の企業が参入しているシステムを開発する場合は、認識のすり合わせが必要な事もあります。

これを怠りとんでもない障害が発生してしまう例が、近年の電子マネーシステムで散見されます。

私が現役だった頃とは違い業務の進め方などもスマートになってきているとは思いますが、別会社の開発した機能との結合テストが始まるととても大変です。

納期は絶対ですので「できませんでした」は許されません。突然の仕様変更や想定外データでのプログラム修正とテストで連日の徹夜など残業時間が1月分の労働時間分ということもありました。

また無事に稼働したシステムでも突然の夜間の呼び出しなどもあり、長いエンジニア生活ですっかりショートスリーパーになってしまいました。

---

私は、新卒配属（23才）から早期退職（55才）まで32年を社内SEとして従事しました。現在はITコンサルタントとして独立しています。

社内SEのやりがいは、身近な人から感謝を得られるということです。

私が入社した当時はシステムは内製が主流でした。

社員自ら社内ユーザーの要望を聞いて、自ら設計、コーディングからテスト・導入までを行っていたのです。

システムを理解するのは、とても困難で、幾度かの失敗（障害）も起こしてしまいましたが、ユーザー部門との関係は濃くなり、成功すれば直接感謝の言葉をいただけることが仕事のやりがいでした。

時代は変わって、近年は社員SEは上流工程（企画）と現場の導入支援を担当するなど、役割は大きく変わりました。 それでも、社内SEは社内の他部門の方々から見れば『情報システムの顔』であることに変わりはありません。

システムはパッケージが主体となり、昔のようなカスタマイズの自由度はなくなっていますが。

それでも利用部門の方々と導入を検討するためには、システム機能への理解に加えて対象部門の業務知識が求められます。

これらの課題をクリアして導入が成功した際には、昔同様、感謝を得ることができると同時に自らの成長も感じることができます。

大変のことは、常に自らの知識・スキルのアップデートが必要なことです。

知識とはアプリに対してだけでなく、担当するアプリがカバーする業務領域も対象になります。

ユーザーから見ると『自分の立場に立って一緒に悩み、検討するSE』の存在が頼もしく感じます。

何かかあれば業務を代行できるくらいの自覚をもって打合せに臨んください。

そこから信頼関係も深まると思います。そのような関係を構築することがシステム導入の成功確率を高めるのです。

また、労務管理は比較的難しいです。昨今『働き方改革』が注目されていますが情報システムの業務はプロジェクト体制で進めることが多いため、業務負荷にはピーク性があります。

かと言ってプロジェクト期間中は明確はオフピークのサインも無いので、オフは自らコントロールして、自発的・計画的に休暇を取得する必要があります。

『忙中閑あり』の気持ちで、忙しいプロジェクト中でも気力・体力の維持に努めてください。

またプロジェクトが一段落したら思い切り羽を伸ばして、休んでいただきたいと思います（これは責任者の方ににお願いしたいことです）

---

設計者としては、自分がシステムの具体的な中身を作るというのが楽しい。

発注者の要望する機能を実現するため、業務内容を理解して取り組む。

この理解するというのは、自分が担当者として業務ができるようでなければ、機能や設計に見落としが出てしまうので重要。また改善ポイントも見つからない。

ここで課題の解決を提案したり、仕様漏れを発見したりできるかがプロとしての腕の見せ所。

もちろんエンジニアとしての能力と担当システムの業務の理解を両立させなければならないのは大変なこと。けれどもやはり良い成果を上げられるとエンジニアで良かったと感じる。

コーディングを実施する際には、設計を実現するのは自分だという自負を感じる。

ほとんど自分の設計したものをコーティングした経験しかないので、他人の設計をコーティングした経験は多くない。

それでも他人の設計については気を使うし、自分自身の設計であっても改めて使用漏れがないか目を光らせることが大切。

ここできちんと開発できなければテストで手戻りが出てしまう。

設計やコーディングだけで参加しているならばともかく、全体を自分で担当していると身が引き締まる。

しかしだからこそ上手くいった時の達成感は大きい。

保守担当としては、システムを守るという自負を感じられる。

システムエンジニアの場合にはプログラマーよりも折衝に時間や気力を取られるところが大変。

業務内容によってはエンジニアとしての仕事が折衝ばかりになるということもある。

例えば複数のシステムから構成されるサービスの保守エンジニアである場合、各システムの部門と折衝が必要になる。

またそのシステムのヘルプデスクが一つの部門を窓口としていると、その窓口とのやりとりが大切になる。

システムは無機物であるが利用者は人間であり、１か０のデジタルというわけにはいかない。

日頃から良好な関係を維持することが運用の向上につながるし、逆に人間関係のトラブルが起きるとサービスにも悪影響である。

保守はヘルプデスクのような応対だけから、インフラのメンテナンス、システムの更改などがあり、どれかに大きな比重があることはあっても、完全に特化しているようなことは少ない。

複雑なシステムは各グループの担当領域が密接に影響しあっていて、ともかく折衝しなければ物事が進まなくなる。

単純に開発に専念している場合、完成させなければ話にならないというところの気苦労がある。

ITエンジニアにありがちな残業ばかりで帰れないという光景は、開発の不調によって生じる。

---

・「システムエンジニア」のリアル。「システムエンジニア」のやりがいと苦労を赤裸々に暴露

---

---

大手の通信販売会社の物流倉庫内のネットワーク・インフラを設計、構築をしてきました。

電車のICカード乗車システムは、日々の通勤でも毎日使用しており、自身の携わったサーバが元気に動いているんだなと感じ、日常生活の中でも携わったシステムが社会の役に立っているんだなと感じることができます。

また、県立病院の院内ネットワークを設計構築運用している案件にも参画しています。

現在のコロナ禍もあり、県立の重要な病院であり、また入院されている患者様が当たり前に治療を受けられるように、可能な限り無停止での稼働が要求されます。

機器の故障などの際にも、業務が止まることの無いよう、全体でどのような構成が最適か、費用と稼働率の両方のバランスを取りつつ、社会的に重要なシステムを支えていくことにやりがいを感じます。

また、次々と新しい技術、製品が出てきますので、常に勉強をする姿勢が必須ですので、何歳になっても常に勉強をし続ける必要があることが大変です。

ただ、勉強と思ってするとなかなか続きませんが、業界の動向にアンテナを張り、新しいことに興味を持てるようになると、勉強も苦ではなくなりました。

ITインフラのエンジニアは地方に行くほど人手不足になっています。

以前某地方都市の製造業のお客様を担当していた際は、ITインフラの担当が私一人でした。

ゴールデンウィークなどの長期連休においても、工場は稼働し続けていますので、家族で旅行に出ていた時に障害が起こり、製造が止まってしまったことがありました。

その時は旅行先から呼び戻され、せっかくの家族旅行が台無しになったのです。

---

営業が受注してきた案件に対して実際にその会社に行き、まずは詳しい調査をします。

そこで現在のネットワークの使用状況等の聞き込みをし、新しくするにあたりどのような仕組みにするか打ち合わせです。

私はほぼ未経験の状態で入社したので最初は先輩に指導してもらい、業務をこなしました。私は簡単な社内LANが担当でした。

顧客の企業の規模も大きく無いのですが、そもそもITという事の理解が今ほど広がっていない時代でした。

そのため、顧客の企業に対して、このようにネットワークの仕組みを組むとこのようなメリットや効率化ができますという提案をし、実際に運用して便利になったとの声を聞ける事がとてもやりがいです。

信頼関係が築けてくると、ネットワーク以外のPCや複合機の相談や「この業務で困っているんだけど解決方法はないか」などのIT全体の相談を受けるようになりました。

当時はまだITに対して重要視していない企業も多かったのですが、提案やサポートを繰り返すうちにIT化に積極的になり、それに対して自分が役に立てるというのはとても嬉しい事でした。

また、多くの企業を担当しているうちにこの場合はこのような解決方法が適しているというような引き出しも増えてきて顧客に対して自信を持って提案できるようになりますし、色々な企業を知る事は強みになります。

顧客のニーズに答える事は仕事においてとても重要で大変な事です。

まず、ネットワークという目に見ない部分を説明し、なるべく専門用語は使わないように分かりやすく提案。

その為には言葉だけではなく、文章や図で説明したりします。

どの企業も同じものは一つも無いので、その企業に合わせた、また人に合わせた提案や説明が必要になります。

それにはコミュニケーション能力が不可欠です。

ITと人間同士のコミュニケーションというのは遠い関係性だと思う方も多いかも知れませんが、実は密接に繋がっており、エンジニアであっても人間関係を構築する能力はとても重要です。

相手は個性があり一人一人違うので、とにかく場数をこなし経験する事でしか能力を向上させる事ができません。

IT系の仕事がしたかったのに顧客との信頼関係が一番難しいという部分に非常に苦労しました。

また、業界によって違うかもしれませんが、トラブル対応は気を遣う事が多かったです。

PCやネットワークのトラブルはその企業の動きを止めてしまう事が多く、緊急の対応が求められます。

ですが、どんなに急いでも復旧に２～３日かかってしまう事やすぐに復旧できてもお客様からの信頼を失う事もあります。

それがこちらの過失（電源コードが抜けていた等）で無かったとしても、お客様の不満の声はこちらに向けられます。

そんな時にどれだけお客様の気持ちに寄り添えるかが苦労する部分でした。

中小企業が連なったグループ会社で小規模な30拠点ほどを束ねる本部にて、社内サーバやネットワークの保守管理・新規導入の業務を行なっていました。

やりがいとしては、新しい拠点のネットワークを構築し運用可能になったことや、新しいソフトを使用できるようになった時の達成感です。

社内の要望をまとめて実現する方法を考えられるのは自社では自分しかできないことのため、自分の仕事によって拠点が業務をできるようになるという自負を得られます。

また、各拠点の業務が円滑に回るようにトラブル対応を迅速に行ない、間接的に利益に寄与している実感があり、会社にとって必要な役回りと思います。

そして、日々進化するITサービスを身近に実感でき、自分や周りの仕事を楽にすることができるようになるところもやりがいの一つです。

それまでにはどうすることもできなかった問題に対して、新たなサービスが出てきて時代が対応してくれるような感情は他の仕事では得難いものがあると思います。

新しい技術の情報を得て、自社に活かすことができるかを検証するときは楽しく感じます。

一方で、休日にも連絡が来ればなんとしてでも対応をしなければいけないことは大変でした。

遠方への旅行中に限ってトラブル対応希望の連絡が来て、現地でないとわからないような内容に対応するのは困難でしたが、現地でできるようなことは指示するようにしました。

また、応急処置を取ること、その日の業務を問題なく終えられるようにすること、完全に復旧すること、と段階的な対応を取れるようにすることに苦慮します。

一般ユーザは、サーバーやネットワークは動作して当たり前の物、という認識が強いため、障害対応をして感謝されない時は報われない気分になります。

遅れた仕事を取り戻さなければいけないという一般ユーザの気持ちもわかるものの、もし自分が対応していなければ業務をできていなかったという事実は理解してほしいと思います。

そして、機械相手の仕事のため、どうやっても障害がすぐに解決しない場合もあり、そのときに苦情を言われるのは堪えました。

代替機を準備できないような状況でも最善策を取れるように考え続ける仕事に疲弊してしまうことはあります。

私が携わってきた分野は、サーバの構築やソフトの設定、運用管理、ビル内LAN環境のインフラ周りの構築や運用管理と、サービスの土台となる部分が多くありました。

また、新規で一から組み上げる場合もあれば、既存のサービス環境を移管される場合もあり、担当環境も多岐に渡りました。

初めのうちは、正直に言って用語もチンプンカンプンで、何をやっているのか、何が面白いのか全く分かりませんでした。

それでも、基本を理解し、自分の言葉で説明ができるようになったその時から自分が変化し、やりがいを感じるようになったことを覚えています。

まず、顧客も含めて人の分からない事を噛み砕いて説明ができるようになると感謝してもらえます。

それにより良好な関係を築きやすくなり、対人関係をもっと良くしたいと思えるようになりました。

他にも、基本が理解できれば、環境は違えど管理するために最低限必要なものが見えてきます。

そうなると環境改善のための必要な材料や工程を提案して取り組めるのです。

そして、管理環境の問題点解決を面白く感じるようになりました。

技術や知識面においても、昔と比べて手軽に触れることができるようになりましたし、貸与されたPC環境でもプログラミングが可能になりました。

自分が欲しい機能を持たせたプログラムを勉強しながら承認が必要でない範囲で勝手に実装できたのは楽しかったです。

時代的なものもあるかとは思いますが、ITエンジニアとしては、まず人付き合いに苦労しました。

とんでもない事を言い出す顧客や、内部の人間は必ずいます。

プライベートとは違い、嫌でも付き合っていかなければならないのは大変です。

大きな有名企業ほど、さまざまな時代を生きた人達で構成されていると思うので、今の時代に変えたくても技術も知識もアップデートされていない人たちが壁となって変えられないことも多いです。

または、発言者の負担がとても大きくなってしまい格差が生まれる。そういう悪しき文化が、未だ根強く残っているところも多いと思います。

また、技術進歩が著しく早いのもIT業界の特徴です。

構築する時に10年先まで見越していても、いざ時間が経過してみると時代遅れになっている事も少なくありません。

時代遅れになったからといって簡単に費用も出ないので変える事もままならず、そのまま使用し続けなればならないジレンマがあります。

そのせいでお客様に文句を言われる事もありました…。

結局のところ、時代が変わっても、変わらない（変えられない）人たちや物を扱わなければならない環境に置かれたエンジニアは苦労するのだろうな…。

2年ほどインフラエンジニアとして仕事をし、現在は別の仕事をしております。

自分で学んだことを活かせるのがまずやりがいだと思います。

誰でもできる仕事ではないので、サーバーのことやプログラムのこと、デベロップを開いて修正を加えられたりなどの対応ができるとやはり重宝もされます。

今の時代、IT系の会社なんかでいえば優秀なエンジニアの場合、企業にとっても命綱のようなものです。

なんといっても、他の人が変われないので、貴重な存在でもあります。

そして、ちょっとやそっと学んだからといって、実際に使えるような技術になるまではやっぱり時間も手間もかかります。

ですが、慣れてきてしまえば、大体のパターンも把握しますし、やっているうちにやり方を覚えたり、何か修正が必要になった場合なんかに、ここだろう、と原因を突き止めやすくなってきたりします。

ここは経験則が効いてくるというか、そうなってくると自分自身の成長を感じることもできますよね。

これは、嬉しいですし、頑張ってよかったなと感じる瞬間でもあるし、何か故障とかバグが合った時に、対応するのも怖くなくなりました。単純に自信もつくんだと思います。

一番大変だったのは、勉強を始めた時、そしてそこから少し経ってからくらいが成長が見込めなくて、前進している感じもないので、心が何度も折れそうになりました。

専門用語なども出てきて、サーバー のことなんかもわからないし、構造すらまともにわかっていません、その上、複雑で進化も早くて、時代性をしっかり読んでついていかないと、全ての勉強やそこに費やした時間と労力が無駄になってしまうのです。

今は、どんどん新しい技術や便利なものが出てきています。

大抵はプラグインで対応できますし、やらなくていいこととやるべきことを見極めていかないと、時間だけが過ぎていきます。

私の場合は、無駄なことに時間を費やしてしまって後悔しました。

ですが、そういうことを経験すると、もう二度と同じようなミスはしないと心から思えるので、それはそれでよかったのかもしれません。

個人的なことですが、私は、1回目の失敗は自分を責めないことにしています。それは挑戦した証だからです。むしろ褒めるべきこと。

しかし、同じようなことを繰り返しやるのは最悪なのでそうならないようにしていきたいです。

---

大規模な案件より小規模な案件にやりがいを多く感じますが、私自身が多くやりがいを感じるのはエンジニアのサポート業務です。

大規模案件は仕様書や設計書が既存でしっかりした物が多くありますが、小規模な案件は自ら作成する事が多いです。

アジャイル開発ということもできます。

別のエンジニアが作成した物の動作を確認しながら、仕様書を修正を行うこともあります。

また小規模案件の多くは納期が短く見た目が大事です。

致命的なバグ以外はあとに回し、クライアントに提出します。

ここで大事な事はバグを発見できているかいないかです。

クライアント側に提出した際、デバッグシートを提供。

デバッグシートには再現性の高い物から低い物までを記述し、仕様とするかバグとするかの判断をクライアントに委ねます。

ほとんどのバグを網羅出来ていれば、今後の予定含めて話合う事が出来ますが、提出後にクライアント側から苦情が入る事がありますので、デバッグシートは非常に重要です。

納品後の達成感は小規模な案件の方が自分の関わった部分が非常にわかりやすく、成果物の仕様を人に説明する事も簡単です。

エンジニアである以上自分がこの制作物に関わったというのは周りにアピールしたいですが、大規模な案件ですと自分の関わった割合が少なく感じてしまいます。

そのため、小規模な案件の方が達成感は大きいですが、比較的ハードである事が多いです。

社内ＰＣのマスターＰＣ作成をしていた際、PCの規格が当初想定していたもの違うというトラブルが発生したことがあります。

当時社内の全端末が32bitのＨＤＤディスク搭載機でした。

それにもかかわらず、64bitのSSD搭載機が採用されてしまい、32bitの資料しかなく、64bitに移行する上でのインシデントが当時の上司も把握していません。

それでいて通常のマスターＰＣの作成と同じスケジュールだった時は非常に冷や汗をかきました。

マスターＰＣというのは社内のスタッフに配るＰＣの元となる物で社内の規定に沿った物になります。

簡単に言えば、インストールされているソフトやネットワーク設定（プリンターや社内ファイルサーバ）等をすでにしてある物です。

32bitの端末しかなかったという事は32bit用のソフトしかなく、セキュリティ設定も32bitの物を流用して使うため、ソフトによっては起動しない場合もあり、そのような動作チェックもされていませんでした。

ソフトは導入する予定のリストしかなく、64bitの用の新しいソフトになるため、使用する為の手順書も新たに作成が必要な状況です。

また、Mac機からWindows機への変更という事もあり、当時のＳＳＤの容量では膨大なフォントのインストールで容量が一杯になります。

完成したマスターＰＣは空き容量が10ＧＢという悲惨な結末を迎えましたが、当時の担当の社内ＳＥの方には本当に感謝されたので、良い経験にはなりました。

---

わからないことが多い新人のときにネットショップの新規立ち上げを任されました。

社内には他にコーディングができるスタッフがいなかったので、わからないことはネットで調べました。

もともとの知識に、仕事で覚えたことが加わって、いろいろなデザインをコーディングで実現できるようになることが面白かったです。

また、周囲からもすごいと褒めてもらえて嬉しかったです。

やがて最初に担当したネットショップの他に、会社のブランドサイトを１から構築する仕事を任されました。

未経験なので不安がいっぱいでしたが、やはりネットで同業他社のサイトを見たり、理想的なサイトにするために必要なコーディングを学んだりして３ヶ月をかけて挑みました。

行き詰まった時に相談できる先輩がいないことが大変でしたが、なんとか形にすることができ、非常に達成感を感じおました。

その仕事を退職するときには、社長から「あなたがやってくれたITの仕事はは誇りに思っていい」と言ってもらえたのです。

コーディングは時間をかけただけサイトが目に見えて成長していくのでやりがいがあります。

私の場合は、専門的に従事しているのが自分1人だったため、行き詰まった時に気軽に相談できる相手がいないことが大変でした。

コーディングがうまくいかないときや、どっちの方法がよりスマートなのかなど、ネット上では解決できないこともあります。

そうようなときは、無理やりコーディングしたり、やりたかったデザインを諦めたりしました。

また、サイト上のデザインに関してなどはIT関係の知識のないスタッフから技術的に容易ではないことに関して、「こうしたほうがいい」「これはおかしい」と安易な口出しをされることに悩みました。

そして何よりストレスだったのは、レイアウト崩れなどの不具合があるとサイトを見るお客様にご迷惑をおかけしてしまうというプレッシャーです。

不具合が発生したときは早急に解決したいものの、どこに不備があるのかなかなか見つからなかったりしてひとりで残業を余儀無くされることもありました。

私が感じる苦労は、私自身に豊富な経験と知識があることと、他に同じ立場のスタッフがいれば解決することばかりだったように思います。

今は離職したので、後任者は私のめちゃくちゃなコーディングに悩まされているかもしれません。

---

お客様の要望に基づいて、試作機を作る仕事をしており、仕様設計が主な業務でした。

途中のトラブルを何とか乗り切って、試作機がうまく動作した時はホッとすると共に、できて良かったという実感できます。

何しろ、世の中に出回っていない装置なので、世界にたった一つだけの装置で、最先端をやっているという面白さはありました。

その様な装置を使って、実験するわけですから、予想もしない現象が起き、デバック修正が大変な所はあるものの、エンジニアのスキルを磨くには良い機会でしょう。

論文や特許を書く機会もあるので、そういった経験を積めることも貴重です。

コスト削減や世の中の状況によって、海外発表の機会は、年を重ねるごとに減ってきたものの、色々な国へ海外出張で経験できることも良いスキル磨きになります。

その為、色々な種類の経験を積むことができることもやりがいの一つだと思います。

色々と、苦労はあったものの、最後にお客様に「良かったよ」と言っていただけると、それはそれで、やりがいが出てきます。

世の中にない物を作るわけで、色々と過去のトラブル集から、トラブル回避を仕込み、何かあった時の際、デバック検証を行ないやすい様に、各信号が見える様に仕込みはすることは必須です。

それでも、予想外のトラブル現象が出たり、初期の進捗スケジュール通りには行かず、遅れが出たりと、下期から年度末になるにつれて、プロジェクトの壁をどう乗り切るかで苦労します。

時間が足りなくなると、サービス残業でカバーするしか方法がない場合もあります。

運用でカバーできる方法が見つかると、それはそれで、助かるのですが、ネットで調べてみると分かりますし、世間の噂でも、厳しい業界に入っていると思います。

お客様にも、納品後のスケジュールがあるので、そのスケジュールを睨みつつ、どの様に壁を乗り越えれば良いかが難しいところです。

現場の人間はそのプレッシャーから、視野が狭くなってしまうこともあります。

トラブル対応研修の様な事を若いうちから経験させてもらえれば良いのですが、その時間を作ってもらえず、現場で学ぶにも限界があります。

中間の上司がしっかりハンドリングしてくれれば良いのですが、中間層は上から催促され、下からも催促され、どうしても、四面楚歌状態になってしまいます。

負のスパイラルに入ってしまうと、ゼロに戻し、プラス側へどう立て直すかを考える必要があります。

そんな時に限って、対策は走りながら考える（作業を行ないながら考える）になるので、調整が難しい仕事です。

---

工場で動いている大きな機械が、自分が作ったプログラムで動いていると考えると、とてもやりがいを感じます。

ある意味で、工場で動いている機械の心臓部とも言えるプログラムを作ったという実感があり、その仕事を誇らしく思うことができるのです。

また、お客様から様々な要求は、ギリギリのタイミングで言われることが多く、それを実現する方法を考え出し、一つのプログラムに仕上げることが出来たときには、自分のプログラマーとしての実力が上がったと実感できます。

もちろん、うまく納品できた際にはお客様からも感謝されるので、やりがいがあります。

エンジニアとして実力がついてくると、社内的にも頼られる存在です。

単純に多くの仕事を回してもらえるというだけではなく、さまざまな内容を相談されるます。

例えば受注に際しての納期や要員数、金額、プログラムの基礎設計など、相談の種類は様々。

もちろん、その分、残業が増えたりすることはありますが、頼られているという実感があるので苦にはなりません。

それでも、うまくいかないときに、納期までにその原因を追求し、修正しなければなりません。

そのため、大きなトラブルが発生するとかなり忙しくなりますし、お客様のプレッシャーにかなり焦ります。

納品時に大きなトラブルが発生した場合にはかなり残業をすることになり、精神的にも肉体的にもボロボロになるのです。

トラブルの原因がすぐに判明して、軽微なものであればそれほど問題はないのですが、些細なミスすぎて、何度も見落としてしまい、原因を特定できない場合には焦ります。

また、チームで働くこともあるので、自分が分担していた部分にトラブルがあると皆さんに申し訳ない気分になり、それはそれで大きなストレスです。

納品トラブルだけでなく、営業活動(受注に向けた打ち合わせ)においてもお客様からのプレッシャーもあります。

納期や価格について、かなり厳しい要求をされることが多く、営業担当は「出来るよね？」と、むしろお客様の都合に合わせようとしてきます。

トラブルの発生を考えると簡単に「できる」とは言えず、板挟みになることも多いのです。

---

当時の携帯電話のシステム開発の現場にいたので、ITの最先端を担うことができるのはやりがいと誇りがありました。

実際社会で動かしているシステムを、自分たちが手を入れて開発しているのはとても緊張感があり責任を感じていたのです。

自分達の仕事が社会の発展を支えているんだという雰囲気が会社全体にありました。

若い人でも能力があれば評価されましたし、下っ端の意見でも上司は耳をかたむけてくれます。

「わからないやつは黙っておけ」ということはなかったです。

任される仕事も初歩的な内容ですが重要なものでしたし、「こうしたほうがうまくいくと思う」という意見はいつでも発言しやすかったです。

女性でも男性でも、能力があれば分け隔てなく活躍できました。

「女性だから、簡単な仕事を割り振る」ということはなく、全員がチームの一員としてそれぞれに尊重し合ってお仕事できたと思います。

そもそもチーム一丸となって取り組まないと、とてもじゃないですが終わらない仕事量でした。

「新人だから、後ろで見ていればいい」という余裕がないのは厳しくもあり、とてもやりがいのかる環境だったのでしょう。

一方でとにかく残業が多いです。

残業代はしっかり払われていましたが、使う余裕など全くありませんでした。

毎日早朝に出社して、パソコンを担いでクライアントの事務所にいき、共同で試験等を実施。

試験項目は山のようにあって、やってもやっても終わりません。夜中に帰社して、資料整理、終電で帰る毎日でした。

職場の上司や仲間は皆良い人ばかりでしたが、それでもしんどくなるほど仕事量がありすぎて、体も心もつらかったです。

当時のITの最先端の仕事でしたが、確認作業は結局紙に印刷したもので行われ、膨大な量のプログラムを蛍光ペン片手にひたすら追っていく作業も大変でした。

プログラムをいじる作業はまだいいのですが、その試験が本当に大変です。

データとすべてのプログラムを紙に印刷したものを合わせて、お客さんに納品しなければなりません。

何時間もかけて試験をして、試験が成功したら何時間もかけてそれを印刷して、また何時間もかけて印刷物から該当箇所をみつけて蛍光ペンでチェックしていく。

本当に地味で終わりのない作業がひたすら続くのがつらかったです。

---

現在だと、AWSで環境構築を行っており、サーバ５台、データベース1台の構築をしています。

例ですが、以下となります。
サーバ１：業務サーバ
サーバ２、３：一般利用向けサーバ
サーバ４：監視サーバ
サーバ５：業務サーバ（待機系）
データベース：PostgreSQL（サーバ１、２、３、５のみアクセス可）

その他ではAWS関連の通信管理を行っており、業務やサーバに応じて通信制限を設けたり、VPNでオンプレサーバとAWSの通信網を用意したりしています。

サーバ構築後、リモートアクセスでのサーバOSの設定、AWS構築側はサーバOSの基本的な設定を行う時刻同期設定、今回WindowsServerの利用なのでIISの初期設定を行う。

その他、Windowsのサービスの一部無効化作業を行いアプリ担当にサーバを引き渡し、アプリ設定後スナップショット取得、マシン全体のイメージの取得を行います。

構築中のスナップショットは手動での取得としていますが、構築後は、自動でのスナップショット取得を行い、世代管理として管理を行う予定です。

AWSはサービスを組み合わせることで動作をしますが、資料上で構築しようとしている内容と、実際の構築では大きな差異が発生することがあります。

そのため、資料を修正したり、仕様を再確認して本当に構築出来るかどうかの確認が多くなかなか苦労させられました。

仮構築でもAWSはクラウドなので、短時間でも費用が発生するので、なぜ費用が発生するのか説明することもあります。

AWSを使ったときの月々の費用計算にも大変です。

ドル換算で計算した後、円に直して資料作りなど、手間が掛かる部分が多いのです。

後は、AWSは管理用コンソール画面仕様が頻繁に変わることもあり、数ヶ月語にはぜんぜん違うレイアウトになっていて、混乱することもしばしば。

AWSはドキュメント資料も数多くあるのですが、廃止予定サービスと現行サービスの資料が一緒に掲載される事もあり 現在の環境に廃止予定のサービスを組み込むわけにはいかないので、資料の読み違えをしないように注意する必要があります。

またドキュメントの中には英語しか存在しないものもあります。

英語のドキュメントを日本語訳する場合、日本語が不自然で読みにくいドキュメントが数多くあり、AWS公式以外のサイトを見比べて整合性を確認したりとドキュメント関連でも手間が多いです。

その点、他のクラウドサービス（Microsoft Azure）は資料も読みやすく翻訳されていてわかりやすいだけに、AWS構築時は比較的ストレスが貯まります。

---

●「会社を辞めたい」人は必見！会社や仕事を辞める前にまず転職エージェントに登録するべき４つの理由

---

●高年齢者の再雇用と定年延長により、老害が大量発生する危機的状況

---

●若手職員を蝕む、国家公務員の老害たちの実情

---

●霞が関での若手の離職が止まらない。国家公務員の業務効率化や働き方改革は待ったなし

---

●河野太郎行革担当大臣の霞が関改革

---

●会社を辞める前にまず休職しよう。会社を休職したい人必見

---

●社内政治必勝法！職場の人間関係で負けないために考えるべきこと

---

●専門性とは何か？専門的職も実は単純労働の集まり！AI時代も単純労働を侮るな

---

●ジョブ型雇用で変動するビジネスパーソンとしての市場価値

---

●文系と理系の区別意味なくない？文系と理系という不毛なアイデンティティー

---

●解雇の法規制と抜け道！簡単に会社を解雇される時代が到来するのか

---

●リアルな口コミで検証、ITエンジニアのやりがいと苦労

---

●介護のお仕事のやりがいと苦労。いつかはお世話になる介護職の実態を大暴露

---

●新人に優しくしなさいの弊害、新社会人に意識してほしいポイント

---

●IT社会における完璧主義や理想主義が、クリエイティブ業務にもたらす弊害

---