はじめに 「コーディングができる」ことと「技術的な意思決定ができる」ことは、似ているようでまったくの別物です。 サッカーで「守備が強い」と言っても、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から謝罪の言葉はなかった。

岡山県がシステム開発に向かないと感じる4つの理由 はじめに 物事には地域ごとの向き不向きがある、というのはよく言われる話です。 例えば「立ち食いそば」は東京や大阪では駅前の当たり前の光景ですが、地方に行くとほとんど見かけなくなります。 これは単純な人口密度の差だけでなく、都市部特有のせっかちな気質や、通勤・移動の合間に短時間で済ませたいという生活スタイルが背景にあると言われています。 「少しでも早く」「立ったままでも構わない」という都市部の価値観があってはじめて成立する業態であり、時間にゆとりのある地方では同じ理屈が働きにくいわけです。 需要密度やビジネスの成立条件だけでなく、その土地の生活スタイルや文化と合っているかどうかが大きく関係していると言われています。 サッカーの世界でも同様の話があります。 中国は巨額のチャイナマネーを投じて自国リーグの強化を図りましたが、結果として世界トップレベルへの成長には至っていません。 理由の一つとして挙げられるのが、他人を信頼しない・組織のために動く協調性が根付いていないといった国民性が、パスをつないで連携するヨーロッパ型のサッカースタイルと相性が悪かった、という指摘です。 お金をいくら投じても、その土地の文化や気質と合わなければ、望んだ方向には育たないという典型例と言えるかもしれません。 これはシステム開発という仕事にも、同じことが言えるのではないかと思っています。 岡山で長年システム開発に携わっていると、「この土地はシステム開発とあまり相性が良くないのでは」と感じる場面がたびたびあります。 感覚論だけで語ると単なる愚痴になってしまうので、この記事ではできるだけ具体的な事実やデータを示しながら、岡山県とシステム開発の相性について考察してみます。 結論を急ぐ記事ではありません。最後まで読んでいただいたうえで、読者自身がどう感じるかを考えていただければと思います。 1. 図書館のIT関連キュレーションの弱さ 岡山県立図書館は、蔵書数・貸出数ともに全国トップクラスの実績を誇る図書館です。 実際に「都道府県立図書館 貸出冊数」で検索すると、岡山県立図書館は毎年上位にランクインしています。 一方で、IT関連書籍、特にAWS関連の技術書に絞って蔵書を確認すると、2026年時点で該当する蔵書は0冊でした。 他県の県立図書館では、地方であってもAWSやクラウド関連の書籍が一定数揃っているケースが多く、これは岡山県立図書館に限った傾向のように見えます。 読書文化自体は根付いている土地であるにもかかわらず、技術書という観点では選書が薄い。 これは図書館側の選書方針の問題という側面もありますが、裏を返せば「IT関連書籍を求める利用者の声がそれだけ少ない」ということでもあります。 岡山のIT従事者に読書習慣を持つ人が少ない、という仮説を補強する材料の一つと言えそうです。 2. ソフトウェア投資を嫌う文化 岡山のSier(システム開発会社)であっても、勤怠管理や会計処理にソフトウェアを導入せず、Excelで運用しているケースを何度も見てきました。 本業がシステム開発である企業自体が、自社の業務効率化にはソフトウェアへの投資を渋る、という状況です。 この傾向は企業だけでなく、個人のフリーランスエンジニアにも見られます。 クラウド会計ソフトを月額契約で使い続けるのではなく、確定申告の時期だけサブスクを契約してデータをエクスポートし、申告が終わるとすぐに解約するというやり方をしている人が少なくありません。 月額1,000円前後のコストを惜しむかどうかという話ではなく、「継続的にソフトウェアへお金を払う」という発想自体への抵抗感が強いように感じます。 システム開発を生業としながら、ソフトウェアへの投資に消極的というのは、なかなか皮肉な構図です。 3. 合理化・標準化を嫌い、型破りな人材を好む文化 システム開発の本質は、業務を合理化・標準化し、再現性を持たせることにあります。 その観点で見ると、岡山県民性そのものが合理化と相性が良くない側面を持っているように感じます。 例えば以下のような点です。 県内主要道路の渋滞の多さ(合理的な交通導線が整備されているとは言い難い) ウィンカーを出さずに車線変更・右左折をするドライバーが多い(ルールより経験則優先) 「とんかつラーメン」のような、効率よりも奇をてらった方向性のご当地グルメが好まれる いずれも一つ一つは些細な事象ですが、共通しているのは「ルールに則って合理化する」よりも「その場のノリ・ルーズさ」を許容する県民性です。 システム開発は良くも悪くも「決めたルール通りに動く」ことが前提の仕事なので、この県民性とは根本的に相性が悪いのかもしれません。 この傾向は、採用や評価の場面にも表れています。 会社によりますが、ルール通りに堅実に仕事を進める人材よりも、斬新なアイデアを出す型破りな人材の方が評価されやすい空気があります。 実際に岡山のシステム会社の経営者の中には、「うちの社員は色がある」ということを、むしろ自慢げに語る方もいます。 「色がある」こと自体は個性として悪いことではありませんが、システム開発という「決めたルール通りに正確に動く」ことが前提の仕事において、型破りであることを評価軸にしてしまうと、品質や再現性が犠牲になりやすいという側面もあります。 合理化を嫌う県民性と、型破りな人材を好む採用・評価の傾向は、根っこの部分でつながっているのかもしれません。 4. 第三次産業の弱さ 岡山県は製造業(第二次産業)の比率が比較的高い一方、情報通信業を含む第三次産業の集積は他の政令指定都市エリアと比べると弱いことがたびたび指摘されています。 システム開発企業やIT人材の絶対数が少なければ、当然コミュニティも育ちにくく、勉強会やカンファレンスの開催数、技術情報の流通量にも影響してきます。 「エンジニアが少ないから情報が集まらない」のか、「情報が集まらないからエンジニアが育たない・定着しない」のか、因果関係は一概には言えません。 ただ、いずれにしても第三次産業、特にIT分野の集積の薄さが、システム開発という仕事にとって向かい風になっているのは間違いなさそうです。 おわりに ここまで4つの観点から、岡山県とシステム開発の相性について考察してきました。 技術書へのアクセスのしやすさ ソフトウェアへの投資意欲 合理化・標準化を嫌い、型破りな人材を好む文化 第三次産業(IT)の集積度 いずれも「岡山だから絶対にダメ」と断言できるものではなく、あくまで傾向や仮説の域を出ません。 一方で、複数の観点から似たような傾向が見えてくるという事実は、それなりに示唆的ではないかと思います。 皆さんは、この4つの理由をどう捉えるでしょうか。 「たしかに」と感じる部分もあれば、「自分の周りは違う」と感じる部分もあるかもしれません。 もし岡山でシステム開発の仕事をしている方、あるいはこれから岡山でのキャリアを考えている方がいれば、ぜひ自分の経験と照らし合わせて考えてみてください。 本サイトへのご意見、お問い合わせなどありましたらこちらからご連絡下さい。

はじめに 職場では、周囲となかなか協調できず、業務が思うように進まない社員に出会うことがあります。 本人の努力不足と決めつけてしまう前に、その背景に何があるのかを考えることが、職場全体にとって重要な視点になります。 この記事では、岡山県のとある中小システム会社で実際にあった、新人社員を巡る出来事を紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「全く仕事をしない問題新入社員」 これは、岡山県のとある中小システム会社での出来事。 数十名規模のこの会社に、ある年、新人社員が配属された。 しかし配属直後から、周りと全く協調せず、仕事もほとんど進まないという状態が続いた。 先輩社員は見かねて、総務部に報告・相談をした。 先輩社員 😟 「新人のAさん、業務が全然進まないみたいなんですが、大丈夫でしょうか。」 総務部 😐 「まあ、新人だし、そのうち慣れるでしょう。」 しかし、面倒くさがられ、まともに取り合ってもらえなかった。 先輩社員 🤔 （さすがにこれだけ進まないのはおかしい。何が起きているのか確認しよう。） その後も一向に改善が見られず、あまりにも仕事が遅いことを不信に思った先輩社員は、こっそりと該当社員のPCにキーロガーを仕込んだ。 ※ 無断でキーロガーを仕込む行為は、プライバシー侵害に当たる可能性があります 数日後、キーロガーの記録を確認した先輩社員は、驚くべき事実に気づく。 先輩社員 😳 （……パソコンが、まったく動作していない!!!） 業務時間中、ほとんどキー入力もマウス操作も行われていなかったのだ。 その後も状況は改善されず、さすがに会社側からも問題視されるようになり、当該社員は自主退職を求められることになった。 しかし、本人は退職を拒否し、ギリギリまで会社に居座り続けようとした。 解説 このエピソードの背景には、発達障害への理解や対応方針が社内で十分に整備されていなかったという課題があると考えられます。 ある小学校では、小学1年生の10人に1人が発達障害だったというデータもあるように、発達障害を持つ方は決して珍しくないということが、社会的にも認知されつつあります。 自分自身が発達障害を持っている可能性もありますし、発達障害を持つ方と一緒に仕事をする場面も、今後ますます増えていくでしょう。 特にSIerの業務では、プログラミングなど論理的思考力を要するタスクが多いため、発達障害の傾向を持つ方が期限内にタスクを遂行することが難しい場合があります。 発達障害の疑いがある場合には、周囲の従業員でフォロー体制を整えたり、軽作業を割り当てたり、障害者雇用に関する助成金を活用したりといった対応が、企業側に求められます。 しかし、今回のケースのように、中小企業では発達障害への理解度が低く、総務部に相談しても問題を先送りにされてしまうことが少なくありません。 また、周囲の社員自身も「発達障害を持つ人がいるかもしれない」という認識が薄いため、仕事ができない社員に対して笑ったり不満を言うだけで終わってしまうこともあります。 おわりに 世の中には、こうした課題に対する理解や対応体制が整っていない企業が、実際に数多く存在します。 本人の特性への理解不足や、相談窓口の機能不全は、当事者だけでなく周囲の社員にとっても大きな負担となります。 もしあなたの職場が、こうした課題に真摯に向き合う体制を整えていないと感じるなら、転職やフリーランスとして独立するなど、環境を変えることも一つの選択肢です。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 顧客が明確に伝えたニーズを正しく理解できないまま、無理に案件を受注しようとする「くれくれ営業」は、顧客の時間を奪うだけでなく、会社の信頼そのものを損ないます。 この記事では、Entra IDに関する依頼を巡って発生した認識のズレと、その後の営業報告書を巡る不可解なやり取りを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 チャンスを自ら潰す案件潰しPL その2 案件依頼 これは、大手メーカー系SierのB社の下請けとして開発案件を受けている、岡山県のシステム会社A社での出来事。 A社は数十名規模のシステム会社で、B社から受注した案件をPL（プロジェクトリーダー）とエンジニア数名の体制で回すことが多かった。 ある日、B社からA社のエンジニアCに、Entra IDでのユーザー管理設計に関する問い合わせがメールで届いた。 顧客B社 🙂 「別案件でEntra IDのユーザー管理設計をする必要があるんですけど、Cさんはその辺の知見ってありますか？」 C 😐 「僕はちょっと詳しくないんですけど、社内で該当の知見があるエンジニアを探してみます。」 Cは該当のエンジニアを探すため、営業報告書を作成しPLに提出した。すると、PLからこう返信が来た。 PL 🤔 「社内ルールで、クライアントのニーズをFace to Faceで確認しないと、営業報告書出しても『クライアントのニーズを詳細に聞け』って突っ返されるんよ。」 PLは社内で適切なエンジニアを探すため、顧客に対面で詳細な打合せをしたい旨をメールで連絡した。 打合せ 打合せが始まると、顧客が丁寧に背景を説明し始めた。 顧客 🙂 「A社さんに依頼をした背景なんですけど、ユーザーがオンプレからクラウドへの移行を検討中で、クラウド化にあたりいくつか課題があります。」 顧客 🙂 「A社さんにはそのうち、『Entra IDの部分』を対応していただきたいと考えているんですよ。」 分かったような顔で頻繁に相槌を返すPL。 C 😶 （本当に分かってるのかな……。） 顧客の話によると、クラウド化にあたってリソースをIaC化することなど複数の課題があり、そのうち依頼したいのはEntra IDによるセキュリティ設計の部分のみだという。 顧客の説明が一通り終わったところで、PLが口を開いた。 PL 🤔 「C君は（Entra IDの設計）できんのかなぁ？」 C 😳 「え!? もともと私が対応できないから、社内で技術者を探すって話でしたよね?」 すると、PLが声を張り上げ、驚愕の発言をした。 PL 😤 「社内で（技術者を）探したけど、いなかったんよ!!」 C 😨 「!?」 そもそもこの打合せは、社内で該当のスキルセットを持つエンジニアを探すために、クライアントのニーズを聞く必要があるという理由で開催されたものだった。 ニーズを聞かなくても社内でエンジニアを探せるなら打合せを開く意義は薄れるし、既に社内に該当のスキルセットを持つエンジニアがいないと分かっているなら、なおさら打合せを開く意味がない。

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

はじめに 脳科学的に見ても、記憶力には個人差があり、物事を覚えておくのが苦手な人は一定数存在すると言われています。 実際、自分が作ったファイルの場所がわからなくなり、人に聞いてしまうという方も少なくありません。 本記事では、作業報告書の提出をめぐって起きた、ある岡山のシステム会社のPLとエンジニアのやり取りを紹介します。 「自分で作ったファイルを忘れるマン」 これは岡山のとあるシステム会社での出来事。 社員数数十名規模のこの会社では、複数の顧客のシステム保守・開発プロジェクトが同時に進行しており、PLも複数のプロジェクトを兼任するのが当たり前の環境だった。 このPLは、兼任するメンバーの作業時間を集計し、毎月作業報告書として顧客に提出する責務を負っていた。 しかし本業が多忙で、報告書作成の作業がいつも後回しになっていた。 見かねた部下のエンジニアAが、報告書作成を手伝うと申し出た。 エンジニアA 🙂 「PLの作業時間を教えてください。代わりに記載しておきますよ。」 PL 😑 「うーん、複数プロジェクト兼任してるから一概に言えないんだよね……。」 PLは言葉を濁し、結局時間を教えなかった。 それでもエンジニアAは食い下がらず、歩み寄った提案をする。 エンジニアA 🙂 「では、自分以外のメンバーの時間は私がまとめます。PLは自分の分だけ書いてもらえますか？」 PL 😐 「あ、うん、わかった。」 そう答えたものの、それ以降もPLは自分の作業時間を記載せず、報告書のPL欄だけが空欄のまま数ヶ月放置される状態が続いた。 数ヶ月後、PLが突然エンジニアAに連絡してきた。 PL 😐 「作業報告書ってどこに置いてる?」 エンジニアA 🙂 「PLがいつも置いてるファイルサーバにありますよ。」 PL 😐 「いや、そうじゃなくて。顧客に提出したファイルがどこにあるか知りたいんだけど。」 エンジニアAは一瞬戸惑った。 報告書の提出はPLの役目であり、提出していれば自分の送信メールボックスに残っているはずだ。 そもそもPL自身が作業時間を記載していないため報告書自体が完成しておらず、提出できるはずがなかったのである。 エンジニアA 🤔 「……そもそも報告書、PLの作業時間欄が空欄のままなので、まだ完成していないと思うんですが。」 PL 😳 「……。」 エンジニアA 😳 「もしかして、提出していないんじゃないですか？」 指摘を受けたPLは一瞬呆然とした。 PL 😳 「……。」 そのまま謝罪や礼を口にすることもなく、PLは無言でその場を去っていった。 解説 今回のPLは、自分が報告書を完成させていない事実を認識できておらず、代わりに提出先を他人に尋ねるという矛盾した行動に出てしまいました。 このような相手には、相手が記憶していないという前提で会話をすすめると有効です。 例えば、打合せ前に「前回の打合せでは〇〇という状況でしたが～」のように会話に前回の情報を付与することで、認識違いがでにくくなります。 おわりに 記憶力の低さそのものは個人の特性であり、責められるべきものではありません。 しかし、それを理由に自分の役割を放棄してしまうようでは本末転倒です。

はじめに 「立場が上の人だから、指示は正しいはず」と思い込んで動いてしまうと、思わぬトラブルに巻き込まれることがあります。 今回は、東京都内にある業界屈指の大手企業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関連 「地元に案件が無い技術に、地方から挑戦できる」 ──これがエージェント利用の最大のメリットだと思います。

はじめに この記事では、フリーランス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.

はじめに 顧客との打合せでは、要件への理解不足を指摘された時にどう振る舞うかで、その後の信頼関係が大きく変わります。 この記事では、自分の理解不足を認めたくないという心理が、かえって顧客の不信感を招いてしまった職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 チャンスを自ら潰す案件潰しPL これは、大手SIerの下請けとして開発案件を受けている、岡山のシステム会社A社での出来事。 A社は数十名規模のシステム会社で、大手SIerから受注した案件を、PL（プロジェクトリーダー）とエンジニアの数名体制で回すことが多かった。 今回参加した打合せは、クラウド上に蓄積された大量のPDFファイルに対してOCR技術を適用し、メタ情報を抽出して検索性を高めるという新規案件のキックオフだった。 打合せの中で、要件の説明が一通り行われた。 キックオフ後、顧客とA社で個別の打合せを実施した。 顧客 🙂 「さっきの打ち合わせ、A社さん的にどう思いました？」 A社PL 😐 「まだ、要件がプアーな感じで、なんとも……」 要件はすでに十分に説明されていたにもかかわらず、A社PLは言い訳し、言葉を濁した。 横で聞いていたA社エンジニアは、内心「そんなに曖昧だったか？」と首をかしげていた。 要件を理解できていないのではと感じた顧客は、あらためて丁寧に補足を始めた。 顧客 🙂 「ユーザーがやりたいことって〇〇だと思うんですよ。で、〇〇を実現するとなると……」 A社PL 😠 「私も分かってますよ！」 顧客の言葉を遮り、食い気味に返すA社PL。 要件が理解されていないと思われたことで、自分が無能だと見られていると感じたのかもしれない。 その場に、しらーとした空気が流れた。 顧客もA社エンジニアも、思わずドン引きして青ざめる。 引き気味になりながらも、顧客は会話を続けようとした。 顧客 😕 「OCRを使うとなると、どのサービスを使うかというのが課題だと思うんですが……」 A社PL 😏 「OCR、文字認識機能ですね。」 理解できていることをアピールしたいのか、顧客の言葉をそのまま復唱したり、別の言い方に言い換えたりするA社PL。 しかし内容そのものへの回答にはなっていなかった。 らちが明かないと感じた顧客は、単刀直入に核心を尋ねた。 顧客 😐 「いや、聞きたかったのは、A社さんはこのシステムのアーキテクチャとか提案できますかってことなんですよ……」 A社PL 😳 「そういうことでしたら是非当社に！」 それまでの態度が一変し、急に前向きな姿勢を見せるA社PL。 その落差の大きさに、周囲は言葉を失った。 雰囲気を察したA社エンジニアが、慌ててフォローに入る。 A社エンジニア 😅 「と、とりあえず詳細は持ち帰らせていただいて、ご提案させていただきますね。」 打合せはひとまずその場を収める形で終わったが、顧客のA社に対する印象は、決して良いものではなかった。 解説 顧客の補足説明を遮って「分かっている」と主張したり、言葉を復唱・言い換えするだけで実質的な回答を避けたりする行動は、理解できていないことを隠そうとするあまり、逆に理解できていないことを露呈させてしまう典型的なパターンです。 顧客側も最初は好意的に補足していましたが、やり取りが重なるうちに「この人は本当に理解しているのか」という疑念を強めていきました。 こうした場面では、理解できていないことを素直に認め、「その点については確認させてください」と伝える方が、よほど信頼を損なわずに済みます。 分からないことを認めるのは、必ずしも無能の証明ではありません。 むしろ、分からないことを分かったふりで乗り切ろうとする方が、後々大きな信頼の損失につながります。 おわりに こうしたPLは、実は発注元の大手SIerからも「一緒に仕事をしたくない」と思われていることが少なくありません。