就職活動

はじめに システム障害が発生した際、本来であれば原因を究明し、その原因に対して恒久対策を打つのが筋です。 しかし現場では「原因が分からないまま、恒久対策だけを先に決めてしまう」という理不尽な進め方がまかり通ることがあります。 この物語では、原因究明を後回しにしたまま恒久対策を求められたことで、現場がどのように混乱していったのかを描きます。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「原因究明してないけど恒久対策」 これは、国内大手SIer企業のA社での出来事。 とあるクラウドシステムにおいて、顧客のデータが消失するという重大障害が発生した。 再現性の低い事象で原因調査は難航し、一方で顧客への障害報告を早期に実施する必要がある。 チームには、重い緊張感が漂っていた。 今後の方針を決めるため、チーム内で打合せが開かれた。 課長 😤 「本件、時間をかけるわけにはいかないので、原因究明はしないけど、恒久対策は打つことにします。」 メンバーA 😳 「え!? 原因分かってないのに恒久対策ですか?」 課長 😐 「そうです。まずは、顧客に説明する障害原因と恒久対策をブレストで提案して。」 メンバーたちが次々と手を挙げる。 メンバーB 🙂 「クラウドベンダーのサービス障害が原因で。」 メンバーC 🙂 「デバイスのハードウェア障害が原因で。」 メンバーA 😣 「いや、ベンダーから障害通知出てないですよね? ハードウェアもこの件と因果関係ないんじゃ……。」 課長 😐 「いや、ブレストで一旦説明案出したいだけだから、指摘しなくていいよ。」 メンバーA 😩 「はあ……。」 メンバーD 😆 「んじゃ、TCP/IPの世界をパケットが彷徨ったことが原因で。」 課長 😃 「それ採用で。」 メンバーA 😶 （TCP/IPの世界を彷徨うってなんだ……？） まともな検証をしていない思いつきが、あっさり採用された。 その後、「有識者会議」という名目で、プロジェクト外部のメンバーを含めた恒久対策の打合せが開かれることになった。

はじめに 「立場が上の人だから、指示は正しいはず」と思い込んで動いてしまうと、思わぬトラブルに巻き込まれることがあります。 今回は、東京都内にある業界屈指の大手企業N社のクラウド案件で実際に起きた、あるPMの言動をご紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 話したことを5分で忘れるPM これは、東京都内にある業界屈指の大手Sierのクラウド案件に参画していたPMとのやり取りです。 このPMは、常に丁寧な敬語で話す人物でしたが、ふるまいはどこか子供っぽく、こだわりの強さや思い込みの激しさが目立っていました。 プロジェクトは複数のベンダーやメンバーが関わる規模で、日々多くのタスクが並行して進んでいました。 同じタスクを別人に割り当てる ある日、エンジニアAはPMからタスクについての指示を受けました。 PM 🙂：「このタスク、Aさんお願いします。」 エンジニアA 🙂：「承知しました。」 数分後、同プロジェクトのメンバーBとPMが話し込んでいるのに気付きます。 話の内容からAに依頼する前にタスク、Bにも同じタスクをアサインしていたらしく、タスクの進捗状況についてBと話していた。 エンジニアA 😐：「すいません!、そのタスク、さっき僕がやるって話でしたよね。Bさんに任せるってことですか?」 PM 😶：「え？。。。」 混乱するPM。 エンジニアB 😐：「今から担当変更すると引継ぎとか余分なタスクがかかる」 機嫌悪そうに語るB。 エンジニアA 😐：「では、このタスクBさんが実施するということで」 さらに数分後。 PM 🙂：「さっきタスクの進行状況どうですか?」 エンジニアA 😳：「あ、いやだからそれもうBさんがやるって話さっきしましたよね……」 エンジニアA 😨（さっき話してから5分も立ってないのに……） 一度だけならうっかりミスとも思えますが、この手の割り当て忘れは日常的に発生していました。 検証環境障害でメーリングリストがパンク 検証環境で障害が発生し、監視システム(Zabbix)から障害通知が一日1万件以上が通知される事象が発生しました。 エンジニアA 😟：「PM、検証環境で1万件以上が発生しているみたいです。アプリのログを確認して原因を調査しましょう。」 PM 🤔：「ログより、障害メールを見た方が早いです。メールで確認しましょう。」 エンジニアA 😕：「メールだと件数が多いとメールサーバーへの負荷も高いし、ログの方がgrepとか使えて効率的ですよ……」 PM 😤：「念のためにメールで送るんですね！!、メンバー全員が入っている検証環境用メーリングリストを作るのでそこに送信してください。」 エンジニアAは思わず声を上げました。 エンジニアA 😨：「メーリングリストに送ると、メンバー全員のメールボックスに障害メールが大量に届いてしまいます。それはさすがに危険です。」 PM 😠：「いいから、やるんですね。」 エンジニアA 😰：「……承知しました。」 指示通りにメーリングリスト宛てに設定したところ、障害通知メールが繰り返し送信され続け、メンバー全員のメールボックスが瞬く間にパンクしました。 エンジニアB 😱：「メールボックスの容量が上限に達しました……何も送受信できません……」 エンジニアC 😭：「私のところも同じです……」 メンバーからの悲鳴のような報告を受けたPMは、ようやく事態の深刻さに気づきます。

はじめに フリーランスへの独立のファーストステップとしてやるべきことは、エージェントを選定することかと思います。 フリーランスエージェントの選定において、以下のように感じる方は多いと思います。 評価サイトのおすすめエージェントが多すぎて結局どれを選べばよいか分からない 地方在住だと案件があるかどうか分からない この記事では、これから独立をされる予定の地方在住エンジニアの方に向けて、おすすめのフリーランスエージェントやエージェントを選定する観点について紹介します。 これから、独立をされる予定の方の少しでも約に立てば幸いです。 そもそもフリーランスエージェントとは？ フリーランスエージェントは、企業の開発案件とフリーランスエンジニアを結びつける仲介サービスです。 案件の紹介、選考調整、契約手続き、単価交渉、稼働中のフォローまでを一気通貫で支援します。 基本的な流れは以下の通りです。 登録・面談：希望条件（報酬、技術、働き方、稼働日数）を伝える 案件紹介：条件に合いそうな案件を複数提示 選考・面談：書類調整、面談日程の調整、アピールポイントの補強 契約・稼働開始：契約書や支払いサイト（入金までの日数）を整備 稼働フォロー：契約更新、単価交渉、トラブル時の介入など フリーランスエージェントとの契約は準委任契約になることが多いです。 契約した単価で、月140-180時間の範囲内で労働することを条件として働くことになります。 準委任契約は契約上は派遣契約とは異なりますが、働き方自体は派遣社員のような形式で働くことになります。 地方の会社員エンジニアが抱えがちな課題 地方で働く会社員エンジニアには、こんな「壁」を感じている人も多いのではないでしょうか? 給与水準が低い傾向：同等のスキルでも都市部と比較して年収差が出やすい 技術スタックが古い：レガシー環境での保守運用が中心、新技術に触れる機会が少ない 古い非合理の企業文化：生産性が下がるような制度やハラスメントなど古い企業文化で精神的にストレスが溜まる 人脈不足：同じ企業とのコネクションしかなく、都市部の成長企業・有力プロダクトとの接点が持ちにくい 「このままでは技術的に取り残される」「収入も上がらない」という不安が、独立や転身を考えるきっかけになることは珍しくありません。 エージェントを利用するメリット ここからが本題です。 地方在住×エージェント活用で得られるメリットを描きます。 1) 都市部の企業との取引が可能になる エージェントは都市部の企業と太いパイプを持っています。 「都市部の最新技術 × 高単価 」 という条件の案件に、地方からフルリモート で受注が可能になります。 2) 収入が上がる フリーランスエンジニアになるとスキル・稼働日数にもよりますが、一般的に月50〜70万円、高スキルなら80〜100万円の報酬を得ることができます。 マージン（手数料）や税などが差し引かれることを考慮しても、総収入は会社員時代を超えるケースが珍しくありません。 3) 希望する最新技術の案件に挑戦できる 地方では希少な以下のような技術領域にもチャレンジすることができます。 モダン言語：Go / Rust フロントエンド：React / Next.js / TypeScript モバイル：Flutter / React Native / Kotlin / Swift クラウド&インフラ：AWS / GCP / Azure / Kubernetes / Terraform データ&AI：Python / MLパイプライン / MLOps / LLM関連 「地元に案件が無い技術に、地方から挑戦できる」 ──これがエージェント利用の最大のメリットだと思います。

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 語彙力なさすぎPM TMの意味が分かっていないレビュアー これは、神奈川県のとあるシステム会社で社内向けスライド資料のレビューで起きた出来事です。 PM😤：「スライドタイトルの製品名の『TM』が付いていないじゃないか。ちゃんと表記しなさい。」 部下😐：「????」 TMは「Trade Mark」の略で、製品名、ロゴが自社の商標であることを示すための記号です。 Nintendo DSなどNintendoの製品にも末尾にTMとついていることがあると思います。 しかし、ロゴを正式なブランド表記として利用しているわけでもなく、社内向けの説明資料において単純に製品名に言及するだけであれば、TM表記が必須となるケースはほとんどありません。 実際、新聞記事の見出しなどでもTMは記載されていないことがほとんどです。 悪意があるわけではないと思いますが、リテラシーが低く過ぎる人がレビュアーとして参画していると、本質的な内容よりも些末な部分にばかり注目し、ピントがずれた指摘が繰り返されることがあります。 SaaS、PaaS、IaaSを知らないクラウド案件のPM これは、東京都内にある業界屈指の大手企業のN社のクラウド案件に参画していたPMとのやり取りです。 あるミーティングで、クラウド構成の話題になった。 エンジニア 🙂 「このシステムは〇〇をSaaS、□□をPaaS、△△をIaaSとして採用しています。」 PM 😐 「SaaS、PaaS、IaaS……ソレ、ナニ？」 エンジニア 😳 「え、クラウドの提供形態の分類です。SaaSはソフトウェア、PaaSはミドルウェア、IaaSはインフラを提供するサービスですね。」 クラウド案件に参画しているPMが、基本用語であるSaaS/IaaSを知らないという事実に、メンバーは驚きを隠せなかった。 BIOS = Vaio S これは、東京都内にある業界屈指の大手企業のN社のPMとのやり取りです。 パソコンの初期設定に関する話題になった際のことである。 PM 🤔 「バイオエスの設定は、もう終わっていますか？」 エンジニア 😶 「……Vaio Sですか?、使ってるのLifebookですけど。。。」 PM 😐 「バイオエスです!!」 部下Aは一瞬、何のことか理解できなかった。 しばらく考えて、ようやく気づく。 エンジニア 😨 （まさか、BIOSのことか……？） 実はこのPM、4文字以上の英単語をアルファベット読みしてしまう癖があるようです。 他にもMosquitto (モスキート)のことをモスキューティーティーオーと呼んだりしていたそうです。 解説 業界内ではメンバーからの回答に対して、ある程度回答ができる人物がPMをするべきとされていますが、相当優秀な人でないとそんなことはできないため、現場ではそうではない人物がPMをやっていることは多いです。 そのため、周りがフォローをする必要があるのですが、PMという立場にたったことでふんぞり返ってしまい、周囲を混乱させ、周りがフォローする気を失せさせてしまうPMもいるのが実態です。 おわりに あまりにもリテラシーが低いPMの下にいるとレビューでもピントのずれた指摘を受けることが多く、自身の成長には繋がりません。

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 Operatorの意味を知らないDevOpsエンジニア これは富士通の下請けの仕事をしているとある岡山県のシステム会社の話です。 DevOpsの導入支援を行っていたプロジェクトでの出来事です。 上司🤔：「運用者って英語で何て言うの？」 部下😐：「operatorです。」 上司😤：「なんか違うなー。actorにしよう!!」 部下😐：「????」 解説 業界ではリテラシーが低い人がプロジェクトをマネジメントしているケースは少なくありません。 誰でも最初は知らないことがありますし、無知であること自体は仕方ないのかもしれません。 しかしながら、今回のケースでは、DevOpsプロジェクトに参画しているにもかかわらず、「Operator」という言葉の意味を理解していませんでした。 参画が決まった段階で普通はDevOpsの意味を調べているはずですが、それを調べていないことから、仕事への意識の低さが伺えます。 さらに厄介な問題は、正解を教えても間違った理解をしてしまう方がいることです。 脳の仕組み的に、本人の中では独自の定義や解釈が形成してしまう方がいて、世の中で一般的に使われている意味と異なる定義で理解してしまっているケースがあります。 そして、そのような人が意思決定を行う立場にいると、プロジェクト全体が誤った方向に進んでしまうこともあります。 おわりに アサインされる案件は「案件ガチャ」と呼ばれ、リテラシーが低過ぎる人がマネジメントしてるチームにアサインされることもあります。 自身の力でもがくことも大事ですが、中々環境は変わりません。 フリーランスになって、環境を変えるのも選択の一つかもしれません。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 確定申告には「青色申告」と「白色申告」の2種類がある 副業やフリーランスで働くエンジニアが所得を申告する際、確定申告には大きく「青色申告」と「白色申告」の2種類があります。 青色申告: 事前の申請と帳簿付けの手間はかかるものの、最大65万円の控除など税制上の優遇が受けられる 白色申告: 事前申請が不要で手続きは簡単だが、節税効果はほとんどない このように、手間をかけてでも節税するか、簡単さを優先するかで選択が分かれる制度になっています。 意外と多い白色申告エンジニア これはフリーランスで働くエンジニアの確定申告の話です。 無頓着エンジニアB🙄:「確定申告はExcelを使って白色申告でやってる。」 エンジニアA😳:「え、青色申告の方が節税になりますよ。」 無頓着エンジニアB🙄:「白色申告でいいよ、青色申告は面倒くさいから」 節税対策ができない白色申告を選ぶエンジニアって意外と多いんです。 エンジニアは技術に興味はあるけど、金融とか資産形成に全く興味がないって人も珍しくないんですよね。 私物を経費にする脱税エンジニア 一方で、割合としては少ないですが節税を意識しすぎて、脱税に近い行為をしているエンジニアもいます。 脱税エンジニアC😏:「自宅の冷蔵庫、経費で買ったよ。仕事の合間に飲むもの入れてるから」 エンジニアA😳:「え、それ完全に私物じゃないですか…」 脱税エンジニアC😏:「業務に関係あるから大丈夫でしょ(笑)」 エンジニアA😨:「（それ、脱税に近いのでは…）」 業務との関連性が薄い私物まで経費として計上してしまうのは、節税ではなく脱税に近い行為です。 また、意図的でなくても、スーツや化粧品などを仕事で使うものだからという理由で、経費計上してしまっている方も結構います。 フリーランスって税理士を介さず、独学で確定申告している方が多いので、こういった間違った申告が行われることは多々あるそうです。 金額が小さければ、税務署もいちいち調査しないと思いますが、税務調査が入れば、追徴課税や罰則の対象になる可能性もあります、法に抵触するような脱税は辞めておいた方がいいでしょうね。 確定申告を楽にするおすすめ会計ソフト 青色申告のハードルとなる帳簿付けも、会計ソフトを使えば大幅に楽になります。 フリーランスや副業エンジニアに人気の会計ソフトには、以下のようなものがあります。 freee: 銀行口座やクレジットカードとの連携が強く、簿記知識がなくても使いやすい マネーフォワード クラウド確定申告: 家計簿アプリでも有名なマネーフォワードが提供、他サービスとの連携が豊富 弥生会計（やよいの青色申告 オンライン）: 老舗の会計ソフトで、サポート体制が充実している いずれも銀行やクレジットカードの取引を自動で取り込み、青色申告に必要な帳簿や決算書を自動作成してくれるため、独学でも大きな負担なく青色申告を続けられます。 おわりに 白色申告か青色申告かは、最終的にはその人の価値観や手間のかけ方次第ではありますが、できれば節税につながる青色申告をおすすめしたいところです。 帳簿付けの手間も、freee、マネーフォワード クラウド確定申告、弥生会計といった会計ソフトを使えば大幅に軽減できるので、ぜひ活用してみてください。 一方で、経費の範囲を都合よく解釈してしまうと、それは節税ではなく脱税に近づいてしまいます。 脱税は当然おすすめできません。 正しい知識に基づいて申告することを心がけたいですね。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 SNSでのビジネスロマンス詐欺被害 これはあるベテランフリーランスエンジニアがLinkedinというSNSを通じて知り合った外国企業に金を騙し取られた話です。 外国企業から一緒にビジネスをやらないかと持ち掛けられたそうです。 しかし、「取引相手」と思っていた相手は、実は詐欺グループで、取引のために自分たちの口座に振り込んでもらう必要があると言われたそうです。 最初は数千円。その後、何度か追加投資を促され、最終的には50万円を失ったそうです。 驚くべきは、そのことを話したときの彼の態度です。 エンジニアA😳:「えっ、50万円も！？」 ベテランエンジニア😳:「まあ、勉強代みたいなもんだから。」 エンジニアA😳:「変だと思わなかったんですか？」 ベテランエンジニア😳:「外国との取引なので、そういうものかと思ってた。」 エンジニアA😳:「….(リアクション薄いな。。。)」 解説 50万円という大金を失ったにもかかわらず、怒ることも悔やむこともなく、平然とした態度をとっています。 エンジニアにはお金に無関心に人も多く、一人暮らしでお金を必要としない生活を続けていて、金銭感覚がずれてしまったのかもしれません。 おわりに 社会人になったからといって金銭の正しい使い方は会社が教えてくれる訳ではないので、金銭に無頓着な方も多いです。 会社の先輩や同僚など周囲の考えに染まるのではなく、自分のお金の使い道には自分自身が責任を持ち、いい加減な社会人にならないよう日頃から意識しておきましょう。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 借金を自慢するピエロエンジニア これは岡山県のある40代のエンジニアの方の友人との金銭トラブルの話です。 ご本人はコミュニティと称して、ジモティーでカフェ会などを開いているそうです。 その方はカフェ会で以下のような発言をしたそうです。 40代エンジニアさん😎:「友人が困っているから20万円貸したけど返ってこなかったことあるよ(キリッ)」 エンジニアA😳:「えっ、20万円も！？」 40代エンジニアさん😏:「自己投資(人生経験)だったと思ってるよ(ドヤ～)」 エンジニアA😳:「….(何で自信満々なんだ。。。)」 40代エンジニアさん😎:「コミュニティ運営してると色々あるからね(キリッ)」 エンジニアA😳:「….(コミュニティってカフェ会開いてるだけだろ、ピエロだな。。。)」 大金を人に貸すのはよくない、お金を返さないような人は友人ではない、という小学生でも分かることを理解できてないのに何故か自慢話のように語っているのです。 コミュニティと称してやっていることもハッカソンやアイデアソンなどではなく、 小規模なカフェ会やボードゲーム会で学生さんでもできるような大したことではなく、年齢に相応しい行動とは思えないですが、主催して人を集めている自分に酔ってしまい、客観的な分析ができなくなっているようです。 本当の友達を知ることのないまま大人になり、周りに担ぎ上げられたピエロのような社会人も世の中にはいるようです。 解説 大金を貸して返ってこないという失敗を「自己投資」と称し、反省すべき出来事を武勇伝のように語ってしまう金銭感覚の麻痺が問題です。 そもそも、お金を貸すような相手は本当の友人とは言えません。 ただ、社会人になっても友人と呼べる存在がいない人は、実は少なくありません。 そうした世間とのズレを出さないためにも、スポーツサークルなどのコミュニティに参加し、様々な人と交流を持つことをおすすめします。 おわりに 失敗を自慢話にすり替えてしまう姿勢は、周囲からの信頼を失うだけでなく、社会人としての金銭感覚そのものを鈍らせます。 自分のお金の使い道には常に責任を持ち、いい加減な社会人にならないよう日頃から意識しておきましょう。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 社会人になれば、会社という組織はきちんとルールに則って運営されているというイメージを持つ人は多いのではないでしょうか？ しかし現実には、社内の意思決定プロセスが曖昧なまま放置され、従業員が振り回されてしまう会社も存在します。 立場が上だから、総務だからといって、必ずしも合理的な対応をしてくれるとは限らないのです。 本記事が、会社という組織を過信せず、自分の権利や手続きについて主体的に確認する姿勢を持つきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 社員寮の退寮手続きだけで2ヶ月以上かかるトンデモ会社 通勤時間短縮のための退寮相談 これは、とある神奈川県のSES会社での話です。 この会社では従業員に対して、会社近隣のアパートを社員寮として提供していました。 ある新人社員Aさんは、社内勤務から客先常駐に配属が変わったことで、社員寮からの通勤に時間がかかり過ぎるようになり、退寮を検討します。 就業規則や寮規則には退寮に関する規定がなかったため、退寮が可能かどうか、可能な場合はどのような手順を踏めばよいかを直属の上司に確認しました。 すると、上司からはこんな反応が返ってきます。 上司😕：「会社の方針として、若手が社員寮を出るのはあまり良く思われていないんだよね……」 はっきりした理由は語られず、曖昧な物言いでしたが、話によると、過去には女性社員が「ユニットバスが嫌だ」という理由で退寮を申し込んだものの、否認された前例もあったそうです。 その後、上司から 上司:「取り敢えず、総務部に確認のメール送信して」 新人A😐: 「分かりました。」 指示を受けたAは、退寮を検討している理由と、手続きが可能かどうかを総務部・上司・課長宛にすぐにメールで送信しました。 新人A😳:「通勤時間短縮のために退寮を検討してます、退寮できるかどうか確認したいです📨」 噛み合わないコミュニケーション ところが、何故か総務部は新人Aに返信せず、上司と、課長にのみメール返信しました。 総務からの指摘を受けた上司は新人Aに以下のように指摘しました。 上司😠：「なんでメールを総務部に送ったんだ。」 新人A😳 ：「え、先ほどメールを送信するように指示を受けたので。。。」 上司😠：「今送るとは思わなかった。」 新人A😳 ：(いつだったらいいんだよ) Aさんとしては、上司から総務に確認するよう指示されたため、すぐに送信しただけです。 内容的に何時送信しても特に問題ないような内容ですが、何故か上司から叱責をうけ、さらにいつ送信すればよかったのかは最後まで明かされませんでした。 また、総務部からの返信内容は一切新人Ａには共有されず、どうも会社側が何かひた隠ししているような状態でした。 その後、会社が月末に実施ている帰社報告会で、課長・上司と対面で話し合いの上、方針を決定することになりました。 これにより退寮は1ヶ月先延ばしになりました。 帰社報告のドタキャン ところが、帰社報告の日に課長も上司も欠席していることに気づきます。 新人A😐: 「課長も上司もいないな。。。」 社内の別の社員Bに聞いて回ったところ、以下のように教えてくれました。 新人A😐: 「課長と上司って今日出社してます?」 社員B😅：「上司さんは業務都合で休み、課長はプライベートの都合でお休みだって。」 新人A😐: 「。。。」 新人Ａに連絡がなく、ドタキャンされてしまったため、帰社報告では方針を決められず、さらに1ヶ月ほど時間が過ぎていきました。 社内で見えてきた「本音」 社内やインターネットで似たような事例を調べてみると、社会人経験の浅い新人が退寮すると金銭面でのトラブルを起こすリスクがあることから、総務部が寮に留めておきたがる、という噂があるそうでした。 一方で、新人でも実家からの一人暮らしに切り替えた社員は特に総務から指摘がなかったことから、上記は表向きの理由は本音は以下の理由だと推測しました。 住宅手当を支給するより、社員寮を維持する方が会社にとって節税効果が高い 退寮時期が中途半端だと、不動産会社への賃料を余分に支払う必要が生じる そこで新人Aは、退寮時期や、移住先の物件の賃料は会社の希望に合わせられること、通勤経路が短くなれば通勤手当の支給額も減り会社側にもメリットがあることを提案してみることを検討しました。 「それはお前が考えることではない」 後日、現場で上司と直接話す機会がありました。 新人A🙂: 「退寮時期と賃料などの条件をご提示していただければ会社の条件に合わせます。また、通勤手当が少なくなるので会社にもメリットがあります。」 上司😑：「社員寮を出ると、普通のアパートよりお金がかかる」 言われなくても分かるようなことを、執拗に念押しされます。

はじめに 「なぜ中小企業ではスキルが伸びないのか」—— 転職や異動を経験した人なら、この疑問を感じたことがあるかもしれません。 大企業と比べて研修制度が整っていない、という指摘はよくあります。しかしそれだけではなく、組織文化や個人の習慣レベルに深い根本原因が存在します。 表面的な「研修がない」「予算がない」という理由の背後には、目標設定能力の欠如、学習に対する姿勢の問題、そして日常的な生活習慣まで、複合的な要因が絡み合っています。これらは一朝一夕には解決できず、組織全体の文化として根付いているケースがほとんどです。 本記事では、実際の現場で起きた事例をもとに、中小企業でスキルアップが進まないの理由を解説します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 1. 目標設定と達成プロセスが機能しない 中小企業だとメンバーの論理的思考力や語彙力に長けた社員が少ないため、目標設定自体ができないケースが多々あります。 以下の例では、目標設定メソッドにマンダラチャートを採用しましたが、社員のスキルの低さから、目標設定ができずに終わってしまったようです。 本当にあった?エンジニアの怖い話「マンダラチャートで目標すら立てられない会社のPDCA」 —— 論理的思考力の弱さから目標設定そのものが機能しなかった事例 目標を立てる能力が弱い組織では、スキル向上の仕組みそのものが成立しません。 論理的思考力がなければ「何を・いつまでに・どうやって」という構造で考えられないため、計画は絵に描いた餅になります。 目標を設定すること自体にもスキルが必要で、適切な目標設定をできない組織にいる限り、成長は難しいのではないかと思います。 目標設定に時間がかかり過ぎる 本当にあった?エンジニアの怖い話「目標設定に四半期の約1/4を消費する会社」 —— 目標設定の仕組みが整っておらず、議論だけで大量の時間を消費した事例 目標設定のノウハウが組織に蓄積されていないと、毎回ゼロから議論を始めることになり、肝心の実行期間そのものが削られてしまいます。 さらに厄介なのは、「時間をかけた＝真剣に取り組んだ」という誤った達成感で終わってしまい、プロセス自体の非効率さが問題として認識されにくい点です。 目標設定に時間がかかること自体は個人の努力不足ではなく、仕組みが整っていない組織のサインであり、そうした環境ではスキルアップに使うべき時間がそもそも確保できません。 自分本位の考えを重視し、教科書通りの学習をしない 本当にあった?エンジニアの怖い話「勤怠ソフトのボタンをてんとう虫にする会社」 「経験」や「勘」に頼って仕事を進める文化では、教科書的な手法が「理屈っぽい」「現場をわかっていない」と軽視されがちです。 しかしこの文化のもとでは正しい方法論を学ぶ動機自体が生まれず、再現性のあるスキルが身につきません。 感覚的な判断は個人の経験に強く依存するため、他のメンバーへの知識移転もできず、組織として学習が積み上がっていかないのです。 技術への興味が薄く、知識が広がらない 事例 これは、複数の物理サーバーを管理するプロジェクトの事例です。 あるプロジェクトで、複数のサーバーに対して同時にコマンドを実行できるSSHクライアント「Rlogin」を選定・採用しました。 このRloginを使うことで、同じ作業を各サーバーに個別に実施する手間が大幅に削減でき、ヒューマンエラーのリスクも低減できます。 導入した担当者は事前に動作検証を行い、Rloginがプロジェクトの要件にも合致していることを確認した上での採用でした。 ところが、このツールをプロジェクトで展開しようとしたとき、ベテラン社員から思わぬ反発を受けました。 「Teraterm以外のツールは聞いたことがない。有名なツールではない。」 という理由だけで、「基礎を無視したやり方だ」「なぜ実績のあるツールを使わないのか」と担当者に対して批判的な意見が述べられました。 ツールの選定基準として本来評価すべきは、プロジェクトとの適合性のはずです。　しかし実際には、「自分が知っているかどうか」が唯一の判断基準になっていました。 結果として、このツールの採用は見送られ、効率の悪い従来の手作業が継続されました。 理由 ツールの知名度や自分の馴染みで技術を評価する文化が存在すると、合理的な判断ができなくなります。 この姿勢の根本には、技術への好奇心の欠如があります。 「知らないものは怖い」「今のやり方で困っていない」という意識が強いと、新しい技術や手法を積極的に学ぼうとする動機が生まれません。その結果、知識が特定の範囲に固定されたまま広がらず、技術の進化に取り残されていきます。 また、このような文化では新しい提案をした人が「基礎がわかっていない」と逆に批判されるため、若手エンジニアの学習意欲を削ぐ効果もあります。 知識を広げようとする行動がリスクになる組織では、現状維持が最も合理的な選択になってしまいます。 2. 学習を阻害する生活習慣 事例 これは、特定の1社ではなく、複数の中小企業で共通して見られた傾向をまとめた事例です。 スキルアップには継続的な努力が必要です。しかし、日常の生活習慣がその継続を根本から阻害しているケースが少なくありません。 具体的には、 業務後にパチンコや競馬などのギャンブルを日課にしている 喫煙の頻度が非常に高く、就業中も離席が多い 飲酒量が多く、翌朝に疲労が残った状態で出勤する スマートフォンのSNSやゲームに長時間費やしている といった習慣を持つ人が、複数の中小企業の現場で一定数見られました。 こうした習慣が日常化している人ほど、 資格の勉強を始めても数日で挫折する 「勉強しようと思っていたが、気づいたら夜になっていた」を繰り返す 仕事中の集中力が続かず、同じ作業に時間がかかる という傾向が見られ、長期的なスキル形成に至りませんでした。