「システムエンジニア（SE）」のお仕事☆「システムエンジニア」のやりがいと苦労をリアルに暴露

---

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

---

---

社内で使う顧客情報登録システムの改修を行っていた。

すでにあるシステムAを別のシステムBに合体させるため開発である。

並行してシステムがどのように動くかを記載した設計書の作成も行なった。

システムの開発が完了した後は、想定通り動くかを確認する単体テストも行なったのだ。

またシステムAを合体させたことに伴い、システムBになにか不具合が生じていないかのテストも一緒に行う。

この時なにか不具合が生じた場合はその修正も行うのだ。

またHPの作成や改修も行った。

こちらは法改正に伴い規則が変更になった際に注意の追加を行なった。

画面上で登録や修正の処理があった場合は、登録時にチェック処理を追加する作業も行うこともある。

こちらも併せてテストを行なった。

テスト時、データが想定通りに登録できているかを確認するためExcelの関数を使用したこともある。

データが保存されているデータベースから、登録したデータを取り出しExcelに貼り付ける。

少ないデータの場合は目視で確認するほうが早いが、データが多い場合、データAとBが同じ値か、狙った部分だけを削除できているかなどを関数を使って確認した。

大変なことの一番は覚えることが多いこと。

プログラム言語は数多くの種類が存在し、システムによっては複数の種類を使っている場合もある。

その度に覚えることが増えていくので大変だった。

また大規模な開発の場合締め切りが近づくにつれて残業時間が増えていくのも大変だ。

開発があらかた終わっている終盤は、テストが主な業務となるが、そこでエラーが発生した場合その部分は一度手戻りとなる。

場合によっては以降のテストも実施不可能な場合があるため、締め切りが近くやることもあるのに先へ進めないということもあった。

必然的に残業が増え、場合によっては休日に出勤することも多々ある。

やりがいとしては、システムが想定通りに動いた時の爽快感だ。

想定通りに動かしたいが、うまく出来ず悩んだ結果動くようになった時はかなり達成感を感じることができる。

簡単なプログラムでもそうだが、複雑なプログラムの場合その度合いはかなり大きい。

またその後もドキドキしながらテストを実施し、大きなエラーが発生しなかった時の喜びはかなり大きい。

気持ちとしては難しい脱出ゲームに友人と参加し、無事脱出できた時の達成感に似ているだろう。

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

医療現場で使われる患者情報や検査情報などを扱う業務ソフトの開発、運用、保守を行ってきました。

Web系ではなくWindowsアプリケーションの開発だったため、Web系と比べて開発の規模は大きかったです。

開発ではまず病院側との必要な機能（検体登録や検査の外部委託連携、検査機器とのデータ連携など）と使用するデータ（患者の基本情報から入院病棟や各種必要な検査項目や使用薬剤など）のすり合わせを行い、ベースモデルを作成していきます。

データベースも同様に病院側からの要望を汲み取り、こちら側で設計、開発を行っていました。

運用と保守では実際に病院側に納品し、一通りの動作テストを通して運用を開始して頂きます。

実際には動作テストで色々なトラブル（外部機器との連携確認の際が多いです）が起こることが多く、現場での修正作業を行っていました。

実際に運用してみて欲しい機能などが出てきた際には、その都度機能を追加していきます。

追加で発生する作業は実装が困難な物が多かったため、こちらから病院側への改善案の作成なども行うのです。

ソフト上であれば、パソコン一つでものを最後まで作り上げられる事はITエンジニアの醍醐味だとでしょう。

ITエンジニア以外だと、どうしても色々な部品や要素が絡まないと一つのものが作り上げられないからです。

よく言われている残業の多さなども私はあまり経験する事なく、ここまでこれているのでその点も救われているのかと思っています。

また医療現場は昨今の情勢もあり、自分も前線で戦っているという実感を持てます。

病院側から直接コロナに関する検査の機能追加の業務が来た際は、忙しくはありましたが一番やりがいを感じました。

ITは様々な現場で使われていますが、その現場ごとによって姿形を変えることも魅力です。

業務内容でも記載しましたが、一番苦労した経験は病院側での運用を開始する際です。

打ち合わせをして仮想の連携機器を使用して事前にテストケースも一通り行ってはいますが、実装テスト時にソフト側だけで完結できないような問題は多々起こります。

検査機器が使用するデータフォーマットにこちら側が合わせる形になるので、事前に仕様書をよく理解していないといけないです。

しかし取引相手と顔を合わせて仕事をする機会が多いわけではないので、問題を解決できたときは達成感を感じることができます。

---

郵貯のシステム開発をしている企業だったので、BAGLESSという言語を使い、システムの開発・チェック・テストなどを行っていました。

私が入社したときはちょうど郵政公社化の時期だったのでそれに伴うシステム改変が主な業務です。

私の担当は「通常オン」というもので、簡単に言うと郵便貯金のATMのシステムを開発、すなわち通常貯金の「通常」のオンラインという意味です。

基本的に多くこなしていた業務内容は、データ室という場所にある実際と同じ仕様の郵貯ATMを使います。

様々なデータをそのATMをに流して色々な状況下で正常に稼働するかどうかを、モニターをみて確認し、エラーが出たらそこをチェックして持ち帰り再びシステムの組み直しをする作業です。

物凄く簡単に言えば、ATMがちゃんと動くかチェックするようなものでした。

またその後にやった業務内容は、郵貯のATMのお正月三賀日運用可能化のシステム改変です。

これは実際にお正月の日に各地にある郵貯事務センターという場所でデータを一斉に流して、ATMのシステムがダウンしないか確かめるものでした。

私が担当していた郵貯は、ATMの数などから言うと世界最大規模級の金融システムで、その開発に携われるというのは非常にやりがいがあり誇りでもありました。

特に私は通常貯金の担当でしたので、お客様方が実際に身近に使うATMのシステム開発だったので、余計にやりがいも強かったです。

醍醐味と言えるのは、やはり給与水準の高さではないでしょうか？

私の会社では4月に新卒入社した年の夏からもうボーナスが出て、更には残業代も100％支給でしたので、大学時代の他の同期と比べてもかなり羽振りが良かったです。

ただその反面実際に残業はかなり多かったです。

一番多かったときで月に100時間くらいの月もありました。

そういう時期はお金があっても使う暇がないという実情で、買い物好きな私としては結構しんどかったです。

また時には夜勤もありました。

途中で仮眠を取れるのですが、仮眠室のようなものは無かったのでデスクの下で寝袋で寝るという過酷な状況でした。

ただ総じて言えるのは非常に大きな達成感を得られる仕事だということです。

これからエンジニアを考えていらっしゃる方には、ぜひ一度チャレンジしてもらいたいと思います。

---

主に企業の商品販売に関するアプリ開発に携わっておりました。

アプリを通してどんな会社なのか概要を知って頂いたり、商品の成分だったり価格などを調べたり、新商品のPRを読めたり、ネットで商品を注文して手元に届くまでをアプリで一括で出来るようなサービスです。

またどんな商品なのかレビューを読んだり、また自分でレビューを書き込んだりも出来るようなサイトアプリです。

お客様の要望に合わせてアプリはチームで開発していきます。

作業はPCのみで行うため、リモートワークでも昨今は可能な作業内容でしょう。

購入した商品の金額によってポイントが貯まっていき、そのポイントで他の商品と交換する事ができたり割引で購入する事ができるシステムが組まれております。

アプリが完成した後も、何度もより良いアプリになるように、またお客様のニーズにより合うようなものを作るためにアップデートが必要でした。

それぞれ請け負っている箇所などが違うので一人で悪戦苦闘する事もたびたびで大変でしたが、やりがいはとても感じる仕事内容だったと感じております。

やはりITエンジニアとして大変な事は常に新しい知識が必要となる分野なので、ずっとその方面の勉強を続けていかなければならないことです。

大学や専門学校で違う分野の勉強をしてきた方にとっては、最初は学生の時よりも勉強に時間が取られてしまうでしょう。自分がそうでした。本当にとても知識が問われる業種です。

またPC作業と言えど同じ会社の人々や他社の方々、お客様との対話ややり取りがかなり多い職種なので対人スキルなども必要です。

他社の方々とチームを組んでの開発などもとても多いので人見知りするタイプだと、日々が苦痛に感じてしまう業種かもしれません。

しかし完成したプログラムやアプリなど、自分も目に見えて完成したものが目の前に出来上がるので物つくりの面白さや達成感があります。

その点はこの仕事は本当に素晴らしいです。

実際に自分が作ったプログラムやアプリが動き、使われていくのを見るのはとても感動するし、お客様に喜んでいただけるとITエンジニアとしてのやりがいや醍醐味を強く感じる事が出来ます。

---

新人の間は上司の指導のもと、設計書をもとに既存プログラムの改修を担当していました。

徐々にどのような機能を作ればユーザのニーズを満たせるか、というのを考えながら文書にしていく設計や、作成したプログラムをいくつかつなぎ合わせてテストを行い、実際にリリースする作業も担当するようになります。

その1年後くらいからは自分でモノづくりを行うのではなく、パートナー会社の方に作成してもらったものをチェックする側に周り、品質の確認や進捗管理を行う立場にシフトしていきました。

5年目くらいになると、超上流工程と呼ばれる基礎検討を担当するようになります。

ここではユーザ要件を既存のシステムを意識しながら詳細化していき、後続の設計につなげていく作業を行うのです。

ユーザはシステム知識があまりないので、やりたいことをどうすれば実現できるか、実現するにあたってどのような制約が障壁があるのかをシステム目線で確認・指摘していく必要があります。

システム側は業務的な知識とシステム知識の両面が必要になり、設計者と開発者の懸け橋としてシステム開発に貢献します。

プログラムの作成は、モノを作るのが好きな人は楽しみながら行えるでしょう。

私は自分がイメージしたものを形にして、実際に動かして思い通りに行ったり、うまくいかなかったところの原因を分析して、解消させたりすることに達成感を感じるので、非常に高い関心を持ちながら業務を行えています。

また人を動かす立場になると、俯瞰的にモノを見る力が鍛えられるとともに、人間関係の難しさを感じます。

自分の考えていることがうまく相手に伝わらなかったり、逆に相手の考えが理解できなかったり。

他の職業でもあることだと思いますが、業務が複雑なため、頻度も高く、伝え方や受け取り方にかなり苦戦しました。

基礎検討ではさらに、お互いが相手の領域について知識が乏しい状況の中でのコミュニケーションになるため、より頻度が高くなります。

テストを行った後、ユーザにテストの結果を説明し、合意が取れたところでリリースに移るのです。

エビデンスがどうしてもシステム色の強い資料になってしまうため、なかなか書面だけで理解してもらうことは難しく、言葉で丁寧に説明しながら合意を取る必要があります。

使える言葉も限られるので、かなり頭を使う仕事です。

---

開発経験としては、要件定義からシステムテストまで一通り行いました。

これにより、各フレームワークの特色、利点、欠点を把握できます。

加えて中企業の社内SEという立場で、システム投資額を抑えつつ、業務改善をする必要があります。

様々なフレームワーク、API、SDKの調査・導入を行った経験から、利点や欠点を把握すると共に、費用対効果計測などしました。

企画・提案・要件定義においては、理由の掘り下げを繰り返し行うことを意識し、コストとパフォーマンスのバランスの基準を明確にした上で決定します。

また開発したシステムに関しては、振り返り及び効果測定を行い、その結果から、次に活かす点や改善する点を明確にし、未来につなげていくようにしたのです。

要件定義では、システム使用部署へのヒヤリングを隔週で実施し、システム機能要件、非機能要件のすり合わせを実施し、要件定義書というドキュメント作成まで実施します。

基本設計では、設計とクライアントによるレビュー、承認を繰り返しながら進めていきました。

基本設計は、クライアントがレビューするので、クライアントにわかるように作成することを心がけます。

詳細設計では、プロトタイプを作成して実際に触れてもらう事で、認識齟齬を減らす取り組みをしました。

システムエンジニアは、コミュニケーションスキル、プレゼンテーションスキル、ビジネスライティングスキル、プログラミングスキル、マネジメントスキルなど、様々な能力が求められます。

またシステムが完成後には、『このシステムがあってよかった』等の喜びの声を聴くことが出来るのです。

これはITエンジニアにとっては一番の喜びであり、やりがいでしょう。

一方で納期に追われることが多いです。

最初に立てたスケジュール通りに開発が進行しないことも多々あります。

予期しないイレギュラーが発生した場合や、クライアントから直前に変更依頼などがあった場合は、残業や休日出勤など、納期に間に合わせるために直前まで働かざるを得ない場合もあります。

またチーム開発の場合には、人間関係のトラブルなどを苦労だと感じるシステムエンジニアも少なくありません。

人間関係を円滑に進めるテクニックを持っていないと、孤立してしまいます。

一番の苦労する点と言ってもよいかもしれません。

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

ホテルの予約システムの設計、開発業務に携わっていました。

ユーザーからあがる機能追加について検討して、機能追加すると決まったらどのような機能を、どのようにシステムに取り入れるかを検討し、機能設計を行い、設計書を作成するのです。

設計書が社内レビューに通ると、その機能を実際にプログラミングしていくことで実装し、新しく追加した機能が使えるようにします。

開発を終えたらテストを行います。

テストは単体テストでそのプログラムの動作に間違いがないか確認し、結合テストで他のプログラムや連携するプログラムに影響がないかなどを確認するのです。

テストに通ったら実際の本番環境に修正したプログラムをアップロードし、ユーザーが使えるようにします。

またユーザー用のマニュアルがあるので、マニュアルに新機能の使い方などを載せることも行います。

そのために画面スクリーンショットが必要だったらスクリーンショットをとって、視覚的に分かりやすいマニュアルとなるように、マニュアルを修正・加筆です。

付随業務として新機能の案内メールの文面を考えたりもして、より多くの人にその機能を使ってもらえるように宣伝もしていました。

お客様の声をダイレクトに聞ける環境だったので、自分の関わった機能が役に立ったとの声をお客様から直接聞くきはやりがいを感じます。

大変だったのはバグを出してしまったときには素早い対応が求められるので、ミスをして落ち込んでいる暇もなくすぐに修正をしなければなりません。

修正では2度と不具合は出せないので、何度も問題ないか確認しながら修正、テストを行い本番環境にリリースするときは気が気でなかったです。

またこちらが良いと思って行った機能追加などに対して、前のほうがよかったとの声を聞いたときは少し落ち込むこともあります。

また自分が関わった機能を、ユーザーになかなか使ってもらえないときは、設計が悪かったのかとか、実装方法がよくなかったのかとか、新機能のお知らせがあまり魅力的にはとらえてもらえなかったのかを悩みます。

また自社サービスだったので、基本的にはすべて自分たちで解決しないといけません。

ベンダーに原因究明を任せて自分たちはそれを待っているだけといったことはできないのが厳しい点でしょう。。

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

地方銀行の情報系システムと勘定系システムに携わっていました。

とくに長かったのは、ATM(現金自動預入機)の開発・運用・保守です。

他にも大手製紙会社のシステム開発、医科大学のシステム開発などを経験しました。

一番長かったATMのシステム開発は、C言語で実施しました。

ATMを利用されるお客様の操作パネル、現金、キャッシュカード、通帳、振込票、などを制御するためのプログラミングを行います。

また裏のパネルにて銀行員の業務操作パネルの制御と、遠隔地から一括制御できる監視システムの開発など、多岐にわたりC言語を利用してプログラミングさせていただきました。

運用時の不具合発生によるバグ修正と新バージョンのインストールなど、運用と保守もさせていただきます。

これに携わったのは20年ほど前ですので、細かいところまではあまり覚えておりません。

それでもATMを設置してから運用される間、操作をされる銀行員の方のフォローをさせていただきました。

設置した時に一通り銀行員の方に取扱いの説明をさせていただきましたが、一回の説明ですべてを覚えることは困難で、繰り返し操作することで慣れてきている感じです。

システム開発は、どの開発言語で実施しても必ず納期があります。

いつからいつまでに開発からテストを終了させるといった、スケジュールを管理しなければなりません。

予定したスケジュール通りに順調に開発が進めばいいのですが、開発中に必ず仕様の変更があったりします。

これによりスケジュールが遅れる可能性が高くなるのです。

かなりの月日をかけて案件の設計をしていても、開発中に、こうしなければならないなど気が付くケースが多々あります。

最初に作るスケジュールは、日付に余裕をもって作っておけばいいのです。

それでもお客様からいつまでに作ってほしいと依頼されている場合が多く、納期に間に合わさなければなりませんのであまり余裕も持てません。

やみくもに開発者を増やしてもそれがスケジュールの前倒しにつながるとは限らないでしょう。

テストまで納期通りに仕上がった場合は、よかったと思い達成感を感じさせていただきますが、納期に遅れる場合も多々ございますので、お客様にも迷惑をかけてしまう場合も多々あります。

ただしスケジュール通りにいかないのは仕様変更による場合が多いため、仕様変更はお客様の依頼から発生する場合が多いため、お客様も仕方がないと思われるケースも多いです。

---

基幹業務のシステム化における、全工程を主に汎用コンピュータと呼ばれる機種でのシステム化を行っていました。

全行程はシステム化計画、業務分析、基本設計、詳細設計、システムテスト、システム導入、プロジェクト管理、ユーザー教育、保守運用等に及びます。

担当した業務は、会計システム、人事システム、給与システム、職能給システム、販売管理システム、生産管理システム、顧客管理システムなど企業における業務全般を対象に行っていました。

業種としては、消費者金融や保険会社のローン管理システム、公営ギャンブルの電投システム、自動車部品の生産工程管理システム、出版社の全業務システムなど、有名企業のシステム化に携わることが多かったです。

もっとも得意としていたのは、経理会計システムで、多数の企業のシステム化で培ったノウハウをもとに、パッケージシステムを作り、全国のイベント会場での販売、説明会なども担当し、実際に10社程度の企業への導入や保守運用を管理していました。

パッケージシステムといっても、ほとんどがカスタマイズしての導入となりましたので、導入に当たっては、通常のシステム開発と同様の業務を行っています。

私の場合は、社会人になって2年間ほどプログラム開発を担当した後、24歳で担当顧客をもってシステムエンジニアとして業務に携わっていたのです。

若干24歳で、大手企業の部課長クラスを相手に正論をかざして、説き伏せていくのがとても痛快で楽しかったです。

私の持論は、システム化とはコンピュータ化でなく、今ある業務を効率的に無駄をなくして、合理化していくことの過程の中で、手段としてコンピュータを利用するべきだというものでした。

特にシステムの概要設計の段階においては、現状業務の分析を通して、無駄や形式化している業務の見直しなど、徹底的に顧客に理解してもらうために、ある意味顧客を問い詰める場面が打ち合わせのたびに毎回あります。

とても生意気な発言をしていて、クレームに近い評価を会社にいれられるようなこともあり、その際の対処が大変難しかったです。

それえも最終的にそれが受け入れられ、顧客に喜んでもらえるシステムが完成したときが、一番のやりがいを感じてました。

よくシステム稼働後の打ち上げで顧客から、あの時は腹立たしく感じることがあったけど、担当してもらってよかったといってもらえた時が、この仕事の醍醐味だと感じた瞬間です。

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

●「こんな上司は苦手」！私が出会った嫌いな上司と、嫌な上司の特徴

---

●【知らないと危険】事務職と事務系職種の微妙な違い！事務職の使い方間違ってない？

---

●「転職したい」人必見！リアルな口コミでオススメ転職エージェントを徹底比較

---