フリーランス

はじめに 2023年10月のインボイス制度開始以降、免税事業者（インボイス未登録の事業者）からの仕入れについては、一定期間の経過措置が設けられています。 この経過措置の控除率が、2026年10月から段階的に引き下げられることをご存じでしょうか。 これに伴い、フリーランスエンジニア向けエージェントのギークスが、免税事業者パートナーへの消費税相当額の補填方針を見直すことを発表しました。 本記事では、経過措置の制度変更の内容と、ギークスの対応方針を例に、フリーランスSEが受ける実務上の影響を整理します。 インボイス経過措置とは インボイス制度では、適格請求書発行事業者（インボイス発行事業者）でない免税事業者からの仕入れは、原則として仕入税額控除の対象になりません。 ただし、制度導入による急激な負担増を緩和するため、以下のような経過措置が設けられています。 期間 免税事業者からの仕入れに対する控除率 2023年10月〜2026年9月 80% 2026年10月〜2028年9月 70% 2028年10月〜2030年9月 50% 2030年10月〜2031年9月 30% 2031年10月〜 0% 発注側企業が免税事業者に支払った消費税相当額のうち、控除できる割合が段階的に引き下げられます。 これにより、発注側企業が実質的に負担する消費税額（控除できない分）が増えることになります。 ギークスの対応方針 ギークスはこれまで、免税事業者であるフリーランスパートナーに対し、本来控除できない消費税相当分を特別措置として全額補填してきました。 しかし今回の経過措置変更を受けて、以下の方針転換を発表しています。 対象: 適格請求書発行事業者の登録をしていない（免税事業者の）パートナー 変更内容: 仕入税額控除が制限される分（消費税相当額の30%）を差し引いた金額で支払い 適用開始: 2026年10月稼働分（11月支払い分）から ギークスはこの見直しについて「他社を含めた市場の標準的な精算ルールに準拠するため」としており、制度上の経過措置の段階的移行に合わせた対応であると説明しています。 参考資料: インボイス制度の改正について（国税庁） 単価50万円の場合の計算例 実際にどの程度の減額になるのか、単価50万円（税抜）のケースで試算してみます。 項目 金額 元の税抜単価 500,000円 元の税込金額 550,000円 控除できない消費税の30%分 15,000円 調整後の税抜金額 485,000円 調整後の消費税（10%） 48,500円 調整後の税込金額（振込額） 533,500円 このケースでは、月額16,500円の実質減額となります。 単価が上がるほど減額幅も大きくなるため、高単価案件を扱う免税事業者ほど影響が大きくなる点に注意が必要です。

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

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

はじめに フリーランスエンジニアとして独立すると、確定申告のたびに悩むのが**「これは経費にしてよいのか」**という判断です。 特に生活に関わる支出は、業務との線引きが曖昧になりやすく、明確な公的基準が存在するわけではありません。 この記事では、生活関連品の経費計上について、実務上の目安となる考え方を整理します。 最終的な判断は税務署や税理士によって見解が分かれることもあるため、迷った場合は顧問税理士に確認することをおすすめします。 生活関連品の経費計上基準 生活に関わる支出は、大きく「生活必需品」と「生活用品」に分けて考えると判断しやすくなります。 生活必需品は経費計上が難しい 服、食料、化粧品などの生活必需品は、プライベートでも当然に使うものという認識が強いため、業務上の必要性を説明しにくく、家事費（プライベートな支出）として扱われ、経費計上が困難です。 服（普段着、スーツなど） 食料、飲料 化粧品 これらは「仕事のために必要だった」と主張しても、生活する上で誰もが必要とするものであるため、業務との関連性を客観的に示すのが難しいと判断されがちです。 生活用品は業務上の必要性を説明できれば経費計上しやすい 一方、鞄やコンピューター関連機器などの生活用品は、理論上プライベートでも使えるものであっても、生活する上で必須というわけではないため、業務上の必要性を説明できれば経費、事業使用分を案分して計上しやすい傾向にあります。 鞄（打ち合わせや客先訪問で使うビジネスバッグなど） コンピューター関連機器（PC本体、モニター、キーボード、マウス、PCケースなど） 家具 (仕事用のデスク、チェア) 家電 (事業所掃除用の掃除機) 車両関係 (車両代、ガソリン代、アクセサリー、自動車税、自動車保険代) 書籍 サブスクリプションサービス (Kindle unlimitedなど) これらは「業務で使うために購入した」という説明が成り立ちやすく、生活必需品と比べて経費計上のハードルが低くなります。 フリーランスエンジニアのようなサービス業の場合、経費計上するものが少ないため、節税したい場合はモニターをウルトラワイドモニターにするなど、上記の生活用品を奮発して、生産性を向上させるといいでしょう。 法人と個人事業主での違い 法人化した場合、家事按分という計上の仕方はしなくなるので、基本的には事業に関係のあるものを全額計上することになります。 これは税法上決まっていることではなく、税理士の方に聞いた話なのですが、法人の場合は携帯電話や車両は1台ぐらいであれば業務用とみなされ、100%経費計上しても指摘されてないことが多いそうです。 上記のように法人と個人事業主では税務署がチェックするポイントも変わってくるようです。 我流の申告による税務調査リスク 正しい知識を持たないまま我流で申告を続けた結果、本人に脱税の自覚がないまま、結果的に脱税状態になってしまっているケースも少なくないようです。 売り上げや経費計上額自体が小さいフリーランスエンジニアの場合、税務署も大企業や高額所得者の調査を優先するため、いちいち細かくチェックされることは少ないと言われています。 実際、周囲で私物を経費にしているエンジニアの話を聞く機会は何度もありますが、税務調査を受けたという話は今のところ聞いたことがありません。 とはいえ、税務調査が入れば、追徴課税や罰則の対象になる可能性もあります、法に抵触するような脱税は辞めておいた方がいいでしょうね。 本当にあった?エンジニアの怖い話「フリーランスエンジニアの確定申告事情」 確定申告を楽にするおすすめ会計ソフト 青色申告のハードルとなる帳簿付けも、会計ソフトを使えば大幅に楽になります。 フリーランスや副業エンジニアに人気の会計ソフトには、以下のようなものがあります。 freee: 銀行口座やクレジットカードとの連携が強く、簿記知識がなくても使いやすい マネーフォワード クラウド確定申告: 家計簿アプリでも有名なマネーフォワードが提供、他サービスとの連携が豊富 弥生会計（やよいの青色申告 オンライン）: 老舗の会計ソフトで、サポート体制が充実している いずれも銀行やクレジットカードの取引を自動で取り込み、青色申告に必要な帳簿や決算書を自動作成してくれるため、独学でも大きな負担なく青色申告を続けられます。 まとめ 生活関連品の経費計上は、以下の考え方を目安にするとよいでしょう。 生活必需品（服、食料、化粧品など）: プライベートでも当然に必要なものとみなされやすく、経費計上が困難 生活用品（鞄、コンピューター関連機器など）: 生活必須ではないため、業務上の必要性を説明できれば経費計上しやすい 明確な公的基準がない領域のため、迷った場合は顧問税理士に相談し、業務上の必要性を説明できる記録（用途、使用頻度など）を残しておくことをおすすめします。

はじめに 「コーディングができる」ことと「技術的な意思決定ができる」ことは、似ているようでまったくの別物です。 サッカーで「守備が強い」と言っても、1対1の対人守備が得意な選手とチーム連携の守備が得意な選手がいるように、エンジニアにも得意分野の偏りがあります。 この物語では、経歴や年齢だけで「ハロー効果」的に評価され、本来向いていないポジションを任されてしまった技術リードが、現場をどう混乱させたのかを描きます。 暴君と化す技術知識ゼロのテックリード 背景 これは、東京都内にある業界屈指の大手企業のクラウド案件でのことである。 この案件に、50代のベテランフリーランスエンジニアCが参画してきた。 プロジェクトには経験の浅い若いメンバーが多かったため、Ｃがテックリード的ポジションに就任した。 Cはコーディング歴は長く、実装スピードには定評がある。 しかし、インフラの知識やトレンドキャッチアップ、技術そのもの理解度については、正直かなり怪しいという噂がメンバーの間で流れていた。 Amazon S3はNoSQL? ある日のミーティング。設計担当のエンジニアDが、データ保存先の構成について説明していた。 エンジニアD 🙂 「このファイルはAmazon S3に保存する設計です。」 テックリードC 🤔 「S3ね、了解。あれはNoSQLだから、柔軟にデータ入れられて便利だよね。」 エンジニアD 😳 「……え？ S3はオブジェクトストレージで、NoSQLデータベースとは別物ですが……。」 テックリードC 😤 「いや、SQLじゃないんだからNoSQLでしょ。」 エンジニアD 😨 （SQLじゃないもの全部NoSQLだと思ってる……？） テックリードCはS3でのアプリケーションの実装経験があるにも関わらず、S3をデータベースと言い張る始末。 わがままでミドルウェア変更 本番稼働中のWebサーバーについて既存環境はApacheで安定稼働していたが、テックリードCが突然言い出した。 テックリードC 😤 「俺はnginxの方が使い慣れてるから、nginxに変更しよう。」 エンジニアD 😐 「今Apacheで問題なく動いていますし、変更するリスクの方が大きいのでは……。」 テックリードC 😅 「何か問題があったら、Apacheだと俺何もできないよ～。nginxにして。」 明確な技術的理由もないまま、Webサーバーはnginxへ切り替えられることになった。 そして切り替え後。 テックリードC 😨 「あれ……？ 俺が作ったWebアプリが動かない……！」 エンジニアD 😳 「え、どこが動かないんですか？ エラーログは出てますか？」 テックリードC 😖 「分からない！ 動かし方が分からないよ～」 エンジニアD 😰 「いや、動かし方が分からないと言われても、状況を教えていただかないと調べようが……」 自分が得意と言っていたのに、いざ変更すると分からないと言い出し、トラブルの詳細を聞いても分からないの一点張りで説明をちゃんとしない。 言い出した変更で他のメンバに迷惑をかけたにも関わらず、テックリードCから謝罪の言葉はなかった。

はじめに システム障害が発生した際、本来であれば原因を究明し、その原因に対して恒久対策を打つのが筋です。 しかし現場では「原因が分からないまま、恒久対策だけを先に決めてしまう」という理不尽な進め方がまかり通ることがあります。 この物語では、原因究明を後回しにしたまま恒久対策を求められたことで、現場がどのように混乱していったのかを描きます。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 「原因究明してないけど恒久対策」 これは、国内大手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 😰：「……承知しました。」 指示通りにメーリングリスト宛てに設定したところ、障害通知メールが繰り返し送信され続け、メンバー全員のメールボックスが瞬く間にパンクしました。

はじめに フリーランスへの独立のファーストステップとしてやるべきことは、エージェントを選定することかと思います。 フリーランスエージェントの選定において、以下のように感じる方は多いと思います。 評価サイトのおすすめエージェントが多すぎて結局どれを選べばよいか分からない 地方在住だと案件があるかどうか分からない この記事では、これから独立をされる予定の地方在住エンジニアの方に向けて、おすすめのフリーランスエージェントやエージェントを選定する観点について紹介します。 これから、独立をされる予定の方の少しでも約に立てば幸いです。 そもそもフリーランスエージェントとは？ フリーランスエージェントは、企業の開発案件とフリーランスエンジニアを結びつける仲介サービスです。 案件の紹介、選考調整、契約手続き、単価交渉、稼働中のフォローまでを一気通貫で支援します。 基本的な流れは以下の通りです。 登録・面談：希望条件（報酬、技術、働き方、稼働日数）を伝える 案件紹介：条件に合いそうな案件を複数提示 選考・面談：書類調整、面談日程の調整、アピールポイントの補強 契約・稼働開始：契約書や支払いサイト（入金までの日数）を整備 稼働フォロー：契約更新、単価交渉、トラブル時の介入など フリーランスエージェントとの契約は準委任契約になることが多いです。 契約した単価で、月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関連 「地元に案件が無い技術に、地方から挑戦できる」 ──これがエージェント利用の最大のメリットだと思います。

はじめに この記事では、フリーランスITエンジニア向け案件紹介サービスレバテックフリーランスについて解説します。 岡山県など地方在住者におすすめできるかも含めて、メリット・デメリットを整理しました。 レバテックフリーランスとは レバテックフリーランスは、レバレジーズ株式会社が運営するフリーランスITエンジニア向けの案件紹介サービスです。 2014年頃のサービス開始から累計登録者数は約68万人を超え、業界最大級の案件データベースを保有しています。 レバテックフリーランス公式サイト .btn-wrapper { max-width: 600px; margin: 0 auto; padding: 20px 0; } .pink-btn { display: block; width: 90%; background: linear-gradient(#ff77bb, #ff4fa0); color: #fff; padding: 18px 0; border-radius: 8px; text-decoration: none; font-weight: bold; font-size: 18px; text-align: center; box-sizing: border-box; box-shadow: 0 4px 0 #d6458a, 0 6px 12px rgba(0,0,0,0.2); transition: all 0.2s ease; } .pink-btn:active { transform: translateY(3px); box-shadow: 0 1px 0 #d6458a, 0 3px 6px rgba(0,0,0,0.

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 語彙力なさすぎ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 (モスキート)のことをモスキューティーティーオーと呼んだりしていたそうです。