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

---

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

---

---

クライアントとの折衝については開発する上で重要な要件について、クライアントが納得する内容を話し合い決めていきます。

話が進むにつれ、「本当はこうしなきゃいけない」「これを実現したい」というのが、抽象的なイメージから具体的なイメージに変化していくのが楽しく感じるのです。

実際の開発業務では設計段階から携わることが多く、詰めた要件を基に、詳細に落とし込んでいくところでクライアントと認識齟齬が無いよう話し合いを重ねます。

その後、設計書からコーディングに進みます。

こちらは設計自体も関わることが出来ていれば、どうコーディングしていけばいいのかが自身で分かるため、設計を形にしていくのは大きなやりがいです。

コーディング後はテストを行い、エラーを一つずつ解決し、よりクライアントが満足できるものを作れるかが勝負。

最後に納品後のクライアントからの評価も重要です。

納品する前にテスト結果や制作物の評価を頂いた後、実際に稼働し「ありがとう」などの感謝の言葉や、継続して仕事をお願いしたいなど要望を頂けることが何より大切だと思います。

一方で、要件を詰めることが大変でした。

クライアントはやりたいことがたくさんあるが、何を優先的に行うか、何がいらないかの「取捨選択」をしなければなりません。

決定権はこちらには無いため話が平行線になると決まるものも決まらず時間が経過してします。

その結果、あらかじめ決められていたスケジュールにずれが生じ、後工程がきつくなります。

いかにスケジュール通りに進めつつ、折衝するかは大変なところです。

また、開発（実装）後のテストも苦労の連続です。

開発自体は割とすぐ出来るのですが、作ったものが正しく動作するかのテスト量が膨大になります。

特に新規でシステムを作るとなるとテストケースが膨れ上がることも珍しくありません。

1つ1つのテストは簡単なものが多いですが、実証且つ証跡に残す作業が膨大で、ここが一番苦労するところかと思います。

さらに、複数案件を同時進行していくときも大変です。

話がこんがらがるというのは往々にしてあるのですが、タイムマネジメントや関係各所とのやりとりが複雑になるため、複数案件を抱える時は大変だったと思います。

---

ITエンジニアのやりがいは実際に自分が関わったシステムが動いたときだと思います。

ITエンジニアというのはプログラマーからキャリアがスタートすると思いますが、初めて自分で書いたプログラムが動いて、思い通りのシステムができたときは何ともいえない達成感です。

また実際にユーザーが自分が作ったものを利用しているのを見ると、より自分が作ったものの実感が湧いて嬉しくなります。

キャリアが進むにつれて、設計や要件定義などの上流にも関わってくることができます。

このあたりの仕事をやりだすとシステムエンジニアとして、1人前になってくるのです。

プログラマーは単に仕様が決まったものを、プログラムに落とし込んでいく形ですが、システムエンジニアはユーザーと一緒になって、何もないところからシステムを作り上げていかなければなりません。

システム的な知識ももちろんですが、コミュニケーション能力、ユーザーの業務内容の把握など、幅広い範囲のスキルが求められます。

このあたりの仕事を任せられるようになると、やりがいも大きくなり、給与面も上がってきて、さらにやりがいが大きくなります。

システムエンジニアの仕事は、納品間近になると大体忙しくなり、残業が増える傾向にあります。

これはどの業界でもそうかもしれませんが、IT業界は特に顕著だとと思います。

なぜなら、大体納品前にユーザーがシステムのチェック、動作確認を行う時、いろいろと問題や要望が出てくるからです。

そんなの聞いて無いですよというような内容も出てくるので、このあたりをうまく乗りきるのがITエンジニアとしての腕の見せどころなのです。

予算が許されるのであれば力技で残業して乗り切ることになりますし、予算に余裕がなければユーザーと厳しい交渉を行うことになります。

また、大体のシステムがOSやその他のミドルウェアのバージョンアップに影響を受けてしまいます。

突然ユーザーからシステムが動かなくなったという連絡が来て、夜中まで原因調査を行うはめになるようなこともありました。

最終的にOSやミドルウェアのバージョンアップが原因だったとしても、システムが動かなくてはどうにもなりませんので、何とかシステムを復旧するために深夜作業を行うのです。

---

新しく何かを作り出すのが好きで、エンジニアはゼロからひとつのシステムを生み出すことができます。

システムエンジニアはものづくりの楽しさや達成感を得るこができるのです。

クライアントの要望はさまざまでひとつとして同じものはありませんので、それを作り上げるのが楽しいです。

画面イメージや業務のしやすさなど、こだわりは企業によって異なります。

全く新しいものを自分自身の能力で作りあげるクリエイティブなところがあるので、創造力のある方にはぴったりな職種でしょう。

またシステムエンジニアはさまざまな業界に関わることができ、あらゆる場面で活躍できるのが魅力です。

近代化に伴いITシステムの導入は活発化し、システムエンジニアの需要も増えています。

IT業界だけでなく、金融や医療・ゲーム会社などのさまざまな業界に関わることができるのが特徴です。

あらゆるものがインターネットやコンピューターと繋がっている昨今では、多くの企業でシステムエンジニアが求められているので、手に職があり働きやすいのもメリットでしょう。

一方でシステムエンジニアの仕事は、チームを指揮できることや最新情報に常に触れ続けられるといった華やかな業務だけではありません。

裁量が広いばかりに業務負担が多く、作業面や人間関係の悩みが生じることがきつく感じることもあります。

多くの知識を身に付ける必要があるので、常に勉強してないと行けない点も難しいです。

システムエンジニアは、企業によって求められる分野も異なるため覚える内容が幅広くなります。

ネットワークやサーバーなどのITインフラや、業務に適したアプリケーションの開発などもあります。

そのためIT分野はもちろん、機械工学や電気工学などの知識も必要です。

またクライアントとのコミュニケーションもあるため、クライアントの事業理解も欠かせません。

対人関係を良好にするためのマナーやビジネス戦略なども求められるでしょう。

システムエンジニアは、マルチな知識を身に付けるため時間と労力がかかります。

以外とパソコンだけ触ってればいいというものでもなく、その辺りを誤解していると厳しい面もありますね

---

自分は主にプログラマーとして働いていましたが、お客様との打ち合わせ等の機会も頂けることが多かったです。

仕様書通りに作るだけではなく、よりよいシステムになるようにこちらから提案し、完成したシステムに満足して頂ける瞬間にやりがいを感じ、また頑張ろうという気持ちになりました。

また、仕事を取ってくるだけではなく、社内で今後求められる新たなシステムに関しての企画を考えたり、実際にそのシステムを作成し、お客様に利用して頂く機会も経験。

求められている要望からの作成ではなく、一から企画から販売までを自社で行うのはとても貴重な経験だったと感じています。

また、様々な言語を習得することで自分自身がやれる仕事の幅が広がり、スキルアップにも繋がります。

自分の勤めていた会社は、海外（アジア圏）にも会社があり、プログラミング業務を海外へ依頼することも多く ありました。

そんな中、完成品の確認作業や、外国人との意思疎通の難しさを感じることもありましたが、IT業界では、海外とのやり取りも少なくないため、海外交流という意味でも良い経験になったと思います。

なによりも、システムを利用して頂いたお客様に感謝の言葉を頂く瞬間にやりがいを感じました。

システム開発の仕事で大変だと感じるのは、お客様の抽象的な要望をいかに理想の形にするかだと思います。

プログラミングの内部的な部分は勿論、UIもどれだけお客様が使いやすく出来るかという部分が出てくるため、途中で「こうしたい、ああしたい」と言った要望も勿論出てきます。

それに対応しながら、納期を守るのはとても大変でした。

納品後、実際の運用が始まってから想定外の不具合が発生することも少なくありません。

納品前の仕事（プログラミング）・納品後の仕事（保守/不具合対応）どちらも、システムの作動が毎日・24時間の場合は特に迅速かつ正確な対応を求められるため、深夜残業や休日出勤も日常茶飯事。

自分は元々、大学ではエンジニアになるための勉強をしていたわけではありません。

プログラミング自体は会社から内定を頂いた後の研修と新入社員研修、実践で身につくため、エンジニアになるハードルは予想よりも高くはありませんが、とにかく体力が必要な仕事だと感じました。

現在では労働基準なども見直されていて、自分がエンジニアとして働いていた頃よりはハードな仕事ではなくなっているかもしれませんが、突発的な仕事が発生し、プライベートの予定が立てられないと言った事も多かったです。

---

私はシステムエンジニアとしてC#等を用いて業務用のアプリケーションを設計・製造を行っています。

デザインパターンや効率的なアルゴリズムの記事を参考に、その手法を活かして自身のやり方でコードに上手く落とし込めた時の達成感はプログラマーの醍醐味です。

メンテナンス性や拡張性の高いコードを書いておくと、いざ修正することになった時に自分を褒めたい気持ちでいっぱいになります。

また、他人の書いたコードをリファクタリングで効率化できた時は、自身のスキルを客観視することができるので、プログラマーとしてやりがいを感じることがあります。

プロジェクト全体で見た時に一番やりがいを感じるのはソフトウェアの結合時です。

複数のソフトを繋いでみて初めて発覚する問題が出て新たな課題が出たりもするんですが、完全ではないにせよ自分たちの作ったソフトが通信して動いているところを見ると達成感があります。

特に結合・総合フェーズでは全ての操作項目を網羅するので、自分のシステムが動くところを全て見れるので、動作のアルゴリズムをイメージすることで大きなやりがいを感じます。

一方で、原因を特定するのが難しい不具合が見つかった時は、精神的にきついです。

実際に参画していたプロジェクトで、作成したソフトの結合試験で負荷テストを行っていた時に、一日起動したままにおくとブルースクリーンが表示されてPC自体が落ちる不具合が見つかったことがあります。

常時起動が前提のソフトだったので致命的な不具合であり、原因調査を行いました。

ブルースクリーンのエラーコードなどからソフトのリソースリークが原因でPCが落ちていることは早期に判明。

しかし、問題のソフトのソースコードをいくら探してもリソースリークの原因箇所が特定できずにいました。

何日か立って精神的に壊れ始めた頃に問題のソフトが外部アプリを操作していて、外部アプリがあるリソースの開放を行っていないことが発覚。

外部アプリ側を修正することで事なきを得たのですが、原因が特定されるまでずっと見当違いである呼び出し側のソースコードを目を皿のようにして探し続けていたのだと思うとなんだかやりきれない気持ちになりました。

原因特定が難しい不具合ほど怖いものはないと思っています。

情報系の大学院を卒業し、社会人になってから8年間ほど継続してITエンジニアをしています。

まず、ITエンジニアを目指される方はシステム開発やプログラミングが好きな方が多い、と感じているのですが、その好きな開発をし続けることができるのがエンジニアのやりがいです。

もちろん、仕事ですから、ずっと好きな作業をしているわけではなく、お客様に見ていただく資料作成や、ミーティングなど、人によっては好きではない作業をすることもあるかと思います。

ただ、それら全ての作業が最終的にシステムやアプリケーションの完成に繋がっていると考えると、開発に携わることができて良かったと感じます。

私が特にやりがいや達成感を感じるのは、不具合修正です。

発生した現象を元に、再現確認、原因の調査をし、見つけた不具合を修正したときは、自分が解決した！という、ITエンジニアとして何とも言えない嬉しさを感じます。

プロジェクトによっては、不具合管理表に不具合が何百件も登録されていて、先の見えない不具合修正に手が止まってしまう、ということもあるかもしれませんが、それもこの業界の醍醐味。

チームメンバーと1件ずつ解決していきましょう。

ITエンジニアとしては、コミュニケーション能力は他の業界よりも必要になってくると思います。

なぜなら、システムやアプリケーションなどといった成果物は目に見えにくいからです。

ソースコードを見たらよいじゃないか？と言われるかもしれませんが、ソースコードを軽く見たからと言って、作っているシステムのことを全て理解できるわけではありません（時間をかけて、隅々まで確認＆理解できれば別ですが）。

家を立てたりする建設の仕事と違って、各作業員がどんな作業をしていて、ミスなくできているのか？という点がシステム開発の場合、わかりづらいのです。

目に見えないソフトウェアへの理解を少しでも増やすために、様々な観点から設計書が作られ、それらを持って作業メンバー間での共通の認識ができてきます。

もちろん、人によっては設計書から読み取る観点が違うかもしれないので、細かいところまで確認する、成果物が半分くらいまで完成したらいったん上長に見てもらう、密なコミュニケーションで認識の齟齬を無くす、などは常日頃から心がけています。

あとは、プロジェクトの後半にさしかかると、主に不具合修正などの対応で、どうしても残業時間は増えてくると思います。

好きな人にとっては、大好きな開発の仕事を夜遅くまでできて、残業代ももらえる、と前向きに捉えられるかもしれませんが、そうでない人は、こんな側面のある業界だということは割り切ってもらうしかないです。

ITエンジニアとしてのやりがいは、客先の要望を実現し、一つのシステムに作り上げることに尽きます。

それによって、客先で喜んでもらえるのはもちろんのこと、仕事の労力の軽減、経費の軽減などにつながります

あまり目に見えないところではあったとしても、結果として会社に利益を産むシステムを構築していけることが魅力です。

具体的には、商品の販売管理をするためには、紙ベース、個々の社員がエクセルで管理、などということが初期段階では多く見られますが、手書きや手入力によるミスの防止などの面からも、データで管理することは必須となります。

ただ、受注、発注などの流れをそれぞれでやったとしても業務の効率化にはつながらず、一つのシステムとして一元管理化することで業務間の受け渡しや２度手間などをうまく省くことができます。

さらに、担当者間のデータの受け渡しもスムーズになり、担当者が不在であったとしても会社全体としてシステムを動かすことができるようになります。

システムを導入することで、同じ入力の繰り返し、二度三度の見直しなどの手間が省けるだけで負担が大幅に減らせるのです。

顧客の業務負担を減らした結果、より必要としてる業務に力を注ぐことができるようにすることが使命であり、それが実現できることが一番のやりがいを感じるときです。

またITエンジニアは、システムの根幹となる流れを整備していくことに注力します。

それがゆるぎないものであることを徹底的に洗い出すことが必要です。

ここを誤ると、システムの根底を覆すほどの例外事項が発見され、再設計に迫られることもあります。ここがある意味一番大変なところです。

苦労する点は、現在の業務を全てまかなおうとすると、無理が生じるところです。

全てをシステムにすることができたとしても、それは肥大したシステムであり、予算と手間がかかるばかりです。

どこまでを正常、どこからを例外処理として分けるかというのがシステムをコンパクトに収めるコツであり、エンジニアの手腕が問われるところでもあります。

ただ、現場からすればご自分でされている作業が例外処理として扱われるのを好むはずもなく、そのあたりの駆け引きに近いものが一番苦労するところでもあります。

また、通常の運用に盛り込めないことはいくらでも後付で出てくるので、いかに早く、全てのパターンを洗い出して、歪みのないシステムにまとめることが、今後のメンテナンスを楽にすることでもあり、運用側だけでなく、メンテナンスをする側でも最善を尽くす必要があります。

---

お客様から要望を聞き、それを仕様として具体的に形にしていく。使用するハード環境やソフトの指定はあるが ソフトの作成方法は自分で決められる為、要望に応えるよう設計を行い動く形にしていく。 決まった手順はなく、思い通りに進まないことはもちろん、仕様変更や残業などの苦労も多々あります。 当初の予測どうりにソフトが動かない事は多々ありますが、それを乗り越えて期待どうりの動きをした時は嬉しいものです。 「お客様が何を要望しているか？」「期間内に作成するには？」「そもそも何がやりたいのか？」等の打ち合わせを重ね お客様から情報を引き出し、悩みながら設計、プログラミングを行うことで創り上げていきます。 もちろん、プロジェクトによっては最後まで、ほぼ計画通り順風満帆に進むこともありますが、大抵のプロジェクトは 工程の途中で予期しないトラブルや課題などが発生します。そういった困難に対して、正面から向き合いながら チームメンバーやお客様と協力し共に乗り越え、システムがリリースした時の達成感は言葉にはできない格別なものが あります。 自分の担当は飲料製造工場の製品製造の管理システム設計なのですが、新製品が出るとそれに合わせたシステムが 必要になります。その都度、客先との打ち合わせになるのですが相手も人間なので客先によっては「俺はお客様だ！」 「俺の方が偉いんだ！」的な考えを持つ人がいらっしゃいます。このあたりは日本人に多いと思います。日本人は とにかくお客様には頭を下げる的な発想や考えが多く見られます。海外のお話だと相手が客先でも「イヤなら使わなくていいよ？」とザックリ仕事自体を切るそうです。「日本が生きづらい」「便利だけど幸福度が低い」を言われている典型的な件 だと思います。ただ、自分は日本人なので相手に合わせて、怒らせないように低姿勢でうまく対応するようにしています。 このあたりもスキルだと思います。生きづらいですが・・。 また、担当が工場の為、各地に打ち合わせの為に出張に行きます。北は北海道、南は熊本＆宮崎あたりです。 中国、韓国にも担当工場がある為、出張しました。客先人数分の打ち合わせ資料を持ち、移動方法、移動時間も考慮しつつ 遅刻などしないようにしなければいけません。荷物が多くなる為、結構大変です。

---

顧客（クライアント）の要望を聞き、システム化によって得られるメリット（人件費削減、ヒューマンエラー削減）を説明しながら設計を行い、開発・テストを経て完成させます。

完成した時に「御社（あなた）にお願いして良かった」と言われるようなシステムをクライアントと一緒に作り上げることがITエンジニアの醍醐味です。

システムのIT化が当然となっている現在でも、いわゆる既製品（汎用的なシステム商品）をカスタマイズなしに利用できる業種はほとんど存在しません。

そのため、顧客の細かい要求を満たしたシステムをフルカスタマイズで作り上げる必要があります。

自身の働き方（会社員かフリーランスか）によって異なる部分もありますが、基本的に対象となる顧客の業種・業態は多種多様です。

業界用語や専門用語はもちろん、仕事の進め方や求められる精度・冗長性も様々です。

場合によっては、その業界について基本的な知識を得るために勉強をすることから始める場合もあります。

システムを作るという作業はそれだけ大変な労力を要しますが、だからこそ完成した時の喜びは格別です。

この喜びを一度体験すると、それまでの苦労は一気に忘れてしまうほどです。

自分自身の経験が豊富かどうかに関わらず、顧客は何でも質問してきます。

誤った回答はいつかバレてしまいますし、信頼を失うことにも成りかねません。

そのため即答できない（全く知らない）ことでも、「その件については調査して後ほどご回答致します」と言わなければなりません。

新たな知識を得る機会が出来たと思うことが出来れば良いですが、見当も付かない内容だと、調査して正しい回答を作成するのに非常にたくさんの時間と労力を要します。

同僚や知り合いに頼ることが出来れば良いのですが、ネット検索が当たり前になっている現在、検索すればすぐに回答が得られるような質問をそもそもして来ないので、たいていは苦労します。

また、ITエンジニアだからという訳でもありませんが、一度引き受けた仕事は途中で投げ出すことは出来ず、最後までやり遂げる必要がありますし、スケジュール管理も重要です。

自分の担当部分が遅れてしまうことで、他の人たちにも迷惑を掛けてしまうことが多いので、とても気を使います。

与えられたスケジュールで完成させることが到底できないような無理強いをされた場合には、きっぱりお断りするような決断力も必要です。

もちろん、断れない諸事情があることがほとんどなのですが、「できます」と言って置きながら期日になって「できません」というのが一番悪いです。約束を守れない＝社会人として失格だからです。

---

まず、現行の業務やシステムを調査分析した結果を共有してお客様から何をしたいのか聞き出し、あるべき形や業務の流れを検討したものをもとにしてシステムを作り上げます。

その結果、現場のお客様がそのシステムを使い「使いやすい」とか「便利になった」といった言葉とともに「ありがとう」と感謝の言葉は何よりの励みです。

そして、そのシステムを導入した結果、お客様の目に見える数字が改善されてお客様の会社として感謝の言葉をいただく時にやりがいを感じるるのです。

また、お客様のやりたいことを実現するためにどうしても既存の方法では難しいのこともあります。

そんな時、新しい技術や方法を身に付ける必要があり、エンジニアだけでなくお客様と一丸となって学び取り組んだ結果が出た時の達成感は最高です。

具体的な例としては、過去の膨大なデータから全文検索を行うサービスを求められた時にElasticsearchの知見を深める必要がありました。

そのため、お客様の有識者の方と文字解析についてトライ&エラーを繰り返しながら最適な設定を模索。

さらに、「アジャイルで開発してみたい」という要望があった時には、お客様の有志と勉強会に参加したりして一緒に学びつつプロジェクトを進めて成功。

ITエンジニアとして、クライアントと一体になってプロイジェクトの課題を解決したときの達成感は何物にも代えがたいものです。

このような理解のあるお客様がいる一方で、対応に苦慮するクライアントもいます。

自分達のやりたい事も理解できてない、話を何もせず、最終段階で「こうなるのが当たり前なんだ。なんでそうなってないんだ」と理不尽なことを言うお客様

お金は出せないけど「アレもやりたいコレもやりたい。とにかく安くしてくれ。」といった無謀な要求をされること どう頑張ってもスケジュール的に無理な開発をゴリ押ししてくる等の無理難題を言ってくるお客様

外注は言われたことだけやっていればいいと言いつつ、言われてない機能が実装されていないと文句を言ってくるお客様

そのような手に負えないクライアントに対して、次回以降の仕事をどうやって断るか考えるのは苦労します。

またシステムは日進月歩のせかいなので、数年前に勉強した知識が今では陳腐化していたり既に使われなくなっていたりすることもザラです。

常に最新の知識と業界動向を掴んでおく必要があるため、日々勉強をすることが大切になってきます。

最新の技術や動向はアメリカ発の内容であることが多いため、最初の頃は英語の勉強と新しい技術の知見や知識をどこでどうやって探すのか？といったことに苦労していました。

下手をすると学生の時より勉強しているかもしれません。

---

私は現在はソフトウェアの開発は行っていませんが、以前、IT関係会社員時代はソフトウェアを開発していました。

新しいシステムを構築していたわけですが、開発途中で何度も仕様変更が発生します。

意図してなかったことが開発中に発見されることが多いですので、それの対応で開発のやり直しになったりします。

こうした試行錯誤を繰り返しながら、新しいシステムが構築されていき、それが運用されるようになった時はとてもうれしく思います。

開発中はいろんなケースを想定してテストを実施しますが、実際に運用でしか発生しないケースも多々ございますので、運用中にバグが見つかるケースも少なくありません。

完璧にできたと思っていても、必ず仕様変更などは発生します。何度も修正を繰り返して、運用しながら本当に良いシステムが完成します。

ユーザー様からは、運用中にバグが発生することでクレームになりますが、バグが無くなったところでユーザー様の役に立ったことができたことをうれしく思います。

毎日、新しい技術的なことが進歩していきますので、そのノウハウについていくには毎日が勉強になります。

システムを構築する開発中でも、新しい技術が生まれますので、その対応に追われる日々です。

仕様変更などで修正しなければならないプログラムを修正しテストした後、さらに仕様変更で修正が入ってしまったり、二度手間になることも多々ございます。

システム構築は月単位のコストが決まってきますので、仕様変更が多くなってくればその労力が増えてしまい、当初の費用では開発できないケースも出てきます。

システム設計の段階で十分に検討していても、必ずと言っていいほど仕様変更は出てきますので、そのための余分にコストを考えておくことも必要だと思います。

しかしながら、ユーザー様は仕様変更の有無にかかわらず、当初のコストでシステムを構築するものと思っていますので、開発者側が余計なコストを支払わなければなくなります。

システムを構築する際には十分すぎる設計ができている必要性がかなり重要になってくるのです。

---

お客様の要望を聞き取り、使いやすく堅牢でメンテナンスしやすいシステムを作り上げる達成感。

対象業種に関する知識を持っていない場合には、その勉強から始める事もある。

専門用語やその業種ならではの仕組み、ルールなどシステムを構築するうえで考慮しなければいけないことが非常に多いのだ。

要望が多岐に渡る場合もあるが、予算とスケジュールに照らし合わせて実現可能なものを絞り込んでいく作業が必要である。

システム開発の要望を行っている部門と、実際のシステム利用者が異なることも多く、テストの段階でさらなる改善要望を出されることもあるのだ。

そんな場合でも、「既に承認頂いたことだから、変更できない」などと杓子定規の対応を行ってると、融通の利かない会社だと思われ、その後の受注が無くなる可能性もあるだろう。

そのため着地点をどこに設定するかを検討し、その為の調整を行うことも重要なのだ。

予算やスケジュール的に絶対に間に合わないような問題、修正依頼があった場合にはシステム運用開始日（カットオーバー）の日付はずらさず、その後の追加修正として対応していくような柔軟な姿勢も時には必要である。

お客様から見た場合ITのプロという目で見られるため、自分の得意・不得意に関わらず、質問や要望に対応しなければならない。

その場でどうしても答えられないようなこと（答えに自信がないこと）は、持ち帰って調査のして回答を作成しなければならないのだ。

お客様の中にIT知識に長けている方がいる場合は対応が難しい。

その方の意見が間違っていたり、正論すぎて対応に困るような内容であったときにもお客様の総意として採用される場合があり、エンジニアの立場としては非常にやりにくいのだ。

エンジニアとしては納期を絶対に遵守しなければならないため、開発後期になっての大幅な仕様変更は避けたい。

それでも事前調査の不足、お客様側の認識誤りなどの原因によって変更対応を余儀なくされることがある。

その際の工数増大分はお客様との話し合いで金額的には追加要求出来るかもしれないが、失った時間は取り戻すことが出来ない。

対応人員を追加することが難しい場合、日々の残業・徹夜によってスケジュールを死守することが必要になるのだ。

さらにIT業界は進化が速いため、自分の知識も日々ブラッシュアップしていかなくてはいけない。

---

システムエンジニアのやりがいは大きく４つあげられます。

１．複数名で１つのものをつくりあげること

ＩＴエンジニアの仕事には、１人で完結する小規模なものもありますが、多くは複数名で共同して１つのもの（コンピュータシステム）をつくりあげます。

このため、他人と協力してアウトプットをつくりあげることで、得られる充実感・満足感が大きいのです。

２．「頭の良さ」を活かせること ＩＴエンジニアの作り出すアウトプットは、工業生産物と違い、目にみえづらいです。

そのため、頭の良さ（目に見えないロジックを組み立てる／読み解くことができたり、それをわかりやすく他人に説明することができること）はとても大事で、それを自認する人にとっては、高い成果があげられやりがいにつながります。

３．ニーズが多く稼げること

ＩＴエンジニアの技術（特にシステム設計技術とプログラム開発技術）は、言語やインフラしだいではありますが、各企業・団体からの開発要望が引く手あまたのように見えます）。

少し前から言われているＤＸも、ＩＴエンジニアに追い風だと感じています。

４．場所を選ばずに働けること

ＩＴエンジニアのメリットの１つに、時間と場所を割と自由に選んで働けることがあります。

あくまで付帯的な要素ですが、ＩＴエンジニアでよかったと感じるポイントです。

大変な点・苦労する点は大きく３つあげられます。

１．複数名での共同作業であるが故に、意見の衝突がある

ＩＴエンジニアは概して、自分に自信がある人が多いです。

このため、設計思想やロジック組み立て等、お互いが譲らず意見が衝突することがあります。

メンバが精神的に大人であれば、それでも何とか落としどころを見つけて解決させるのです。

しかし考え方を譲らない人も中にはいるので、まとめ役となる人は苦労する場面が少なからずあります。

２．相手がコンピュータなので、いい加減さはきかない（１００点が求められる）

ＩＴエンジニアのうち特にプログラマは、コンピュータが動くためのものを作るので、人間を相手にするようないわゆるなあなあな仕事のやり方では、まず思った通りに動きません。

それをバグと呼びますが、このバグをつぶすのにとても苦労します。

３．ついつい働きすぎてしまう

ＩＴエンジニアの仕事は相手がコンピュータなので、融通が利かない反面、やれば進捗が見られます。

そのため仕事が好きな人にとっては、区切りが悪くなり働きつづけることとなります。

またバグがあるような場合も、それをつぶすのにとても時間がかかる場合があり、特に期限が間近の場合は、働きすぎてしまう傾向があるのです。

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---