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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

・「インフラエンジニア（サーバエンジニア、ネットワークエンジニア）」のお仕事☆インフラエンジニアの苦労とやりがい

---

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

無線通信に関する研究開発で試作機作成や論文執筆、特許作成と言った会社での研究職をずっとやっておりました。

分かりやすく言えば、無線LAN (Wi-Fi)やETCで使用されている周波数帯での開発やミリ波レーダーの開発です。

身近に感じる似た製品で言えば、無線LAN、車載の前方監視レーダー、前方の車との距離を一定に保つための距離測定装置と言った所でしょう。

今や情報通信の時代で、知らない間に使用している通信装置に近い製品の試作品作りというと分かりやすいでしょう。

その様な製品を作るには、まずお客様とどの様なものを作るのかを話し合う方式設計に始まり、その方式設計を行なうと、今後は機械を作る為の具体的設計を行ないます。

無線機はハードウエアですが、人が操作するうえでソフトウエアを作る事も必要になり、それぞれの人たちが開発に携わり、一つの装置にしていくのです。

その後は、バグがないかのチェックを行ない、バグ発生時はその修正に追われ、出来上がった製品をお客様のもとに届けた後、一緒に実験を行なって論文としてお客様が発表していくことになります。

試作機はお試し機ですが、失敗に終わっても良いかというとそうではなく、お客様はそれを使って成果と出していく必要があるのです。

中にはタイトなスケジュールで最初から行なう必要のあるものや、試作機のため初めからスムーズに開発が進行して、ライン生産の様に行くわけではないので開発のハードルは高いです。

民間企業なのでお客様かた開発依頼を受け、開発してお金を頂く為、「失敗しました、納期が遅れました」では済まされません。

年度の後半になる急に問題点が出てきて、どこに問題があるのかを調べ修正の対策を打っていくのです。

もともとタイトスケジュールに加え、トラブルの修正対応が入ってくるのです。

年度の下期はドタバタ状態になり、残業や週末出勤をせざるを得なくなります。

なぜなら製品を作って終わりではなく、お客様はその製品を使って、発注通りに雨後しているのかをチェックして、展示会に出展したりデータを取得したりする必要があるので、その対応は多忙し状態になるのです。

やりがいは上手く行った時の喜びと安堵につきます。

お客様に喜ばれるのがやりがいであり、世界に一つだけの装置を作っている事も喜びや達成感に繋がるのです。

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---

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

---