//ohina.work/tags/%E4%BA%8B%E4%BE%8B%E9%9B%86/ Recent content in 事例集 on 地方SEナビ Hugo -- gohugo.io ja-jp Fri, 07 Aug 2026 10:00:00 +0900 //ohina.work/post/real_engineer_deal_killer_pl/ Fri, 07 Aug 2026 10:00:00 +0900 //ohina.work/post/real_engineer_deal_killer_pl/ はじめに 顧客との打合せでは、要件への理解不足を指摘された時にどう振る舞うかで、その後の信頼関係が大きく変わります。 この記事では、自分の理解不足を認めたくないという心理が、かえって顧客の不信感を招いてしまった職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「チャンスを自ら潰す案件潰しP」 これは、大手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からも「一緒に仕事をしたくない」と思われていることが少なくありません。 //ohina.work/post/real_engineer_holiday_home_visit/ Fri, 07 Aug 2026 10:00:00 +0900 //ohina.work/post/real_engineer_holiday_home_visit/ はじめに 休日は業務から離れて自分の時間を過ごすものだと考えている人は多いのではないでしょうか。 しかし、IT業界では、休日に仕事をしているワーカホリックな管理職も存在します。 今回は中四国のシステム開発現場で実際にあった、休日にサービス残業をしていたPLの話を紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「休日に部下の家で仕事するプロジェクトリーダー」 これは中四国のあるシステム開発会社での出来事。 このプロジェクトは、複数の協力会社が入り交じる中規模の案件で、リリース直前ということもあり、現場全体に慢性的な余裕のなさが漂っていた。 PLは、要領の悪さで社内でも有名な人物で、進捗管理や資料作成をいつもぎりぎりまで溜め込んでしまう癖があった。 後輩のDさんは、ノリの軽さで周囲から「ちゃらお」と呼ばれるタイプで、久しぶりの休日に自宅でゆっくりくつろいでいた。 すると、スマートフォンにPLからの着信が入る。 Dさん 😌 「はい、Dっす。」 PL 😐 「明日、顧客向けの報告資料を作らないといけなくてさ。今日中に仕上げたいんだよね。」 PL 😊 「いや、Dが作ったドキュメントとかプログラムのこと、分からないところがあったらすぐ聞きたいから、そっち行っていい？」 Dさん 😆 「家っすか？別にいいっすよー、散らかってますけど。」 PL 😊 「うん、近くまで来てるんだ。」 すでに移動を始めていたPLは、そのままDさんの自宅に到着する。 本来であれば会社の設備で行うべき作業を、部下の自宅の私的な空間で、しかも休日にこなす状況を、PL自身が作り出していたのである。 PLはノートPCを広げ、資料作成に取りかかった。 PL 😅 「あー、この処理どうなってたっけ……。ちょっと聞いていい？」 Dさん 😐 「ああ、それはこういう処理っすよ。」 質問に答えながらも、Dさんは何をするでもなく手持ち無沙汰になっていた。 すると、ちょうどそこへ別のプロジェクトで一緒だった他社のメンバーから連絡が入る。 自社メンバー 📱 「暇してるなら麻雀しない？」 Dさん 😆 「お、いいっすね！ちょっとうちに来てくださいよ。」 Dさんは自分の家であることをいいことに、プロジェクトとは無関係の自社メンバーたちを呼び寄せ、ノリノリでリビングの隅に雀卓を用意して麻雀を始めてしまった。 牌をかき混ぜる音と談笑が響く隣で、PLはエアコンの効きが悪い部屋の中、額に汗をにじませながら黙々と資料作成を続けていた。 Dさん 😆 「お、リーチ！」 自社メンバー 😂 「まじかよ、また負けた。」 数時間後、ようやく資料が仕上がったところで、PLは疲れた様子で切り出した。 PL 😮‍💨 「なんとか終わったよ……。じゃあ、また明日会社でよろしく。」 Dさん 😆 「お疲れさまっす！気をつけて帰ってくださいねー。」 解説 百歩譲って休日に作業をすること自体は仕方ないとしても、事前に「この部分についてメモをまとめておいてほしい」と後輩に指示しておけば、わざわざ部下の自宅にいく必要はなかったはずです。 //ohina.work/post/real_engineer_nearshore_estimate_padding/ Fri, 07 Aug 2026 10:00:00 +0900 //ohina.work/post/real_engineer_nearshore_estimate_padding/ はじめに 大手企業の案件を地方の下請け企業が受注する「ニアショア開発」は、コストメリットの大きい発注形態として広く活用されています。 しかし、その内側では、社内の都合によって工数が実態とかけ離れた形で見積もられているケースも存在します。 今回は岡山のとある下請けIT企業で実際にあった、見積もり水増しにまつわる話を紹介します。 地方企業に発注をしてはいけない理由。ニアショアのリスク これは、大手SIerである富士通の案件を受注している、岡山のとある下請けIT企業での出来事。 ある日、若手エンジニアが新規案件の見積もりを行っていた。 若手エンジニア 🙂 「この作業は設定ファイルを修正するだけだから、1日あれば十分だな。動作確認とバッファを含めて3人日で見積もっておこう。」 若手エンジニア 😅 （これでもだいぶ多めに見てるけど……。） すると、隣の席で作業をしていたベテラン社員がその見積もりに気づく。 ベテラン社員 😏 「おいおい、それじゃ工数が少なすぎるよ。2週間は取らないと。」 若手エンジニア 😳 「え！？　実際の作業時間ってそれくらいですよね？」 若手エンジニア 😰 （3人日でもだいぶとりすぎのつもりだったのに……。） ベテラン社員 😏 「それじゃうちの利益にならないから。」（ヘラヘラしながら鼻で笑う） 若手エンジニア 😞 「わかりました……。」 納得はいかないまま、若手エンジニアは2週間分の工数で見積もりを作成することになった。 その後、この見積もりはそのまま顧客へ提出され、無事に発注を受けた。 若手エンジニアは指示された通りに、2週間かけて作業を進め、完了後に顧客への作業報告を行った。 顧客 🤨 「ん？　この作業って設定ファイルを変更するだけで、コード修正は入ってないですよね？　なんで2週間もかかったんですか？」 若手エンジニア 😨 「えっと、それは……。」（ちらっとベテラン社員の方を見る） ベテラン社員 😶 （ぷいっとそっぽを向いて知らん顔） 若手エンジニア 😱 （だんまりかよ！） 結局、顧客への説明はすべて若手エンジニア一人が背負うことになり、水増しを指示したベテラン社員は素知らぬ顔で自分の作業に戻っていった。 解説 今回のケースのように、実際の作業量とかけ離れた工数を見積もりに乗せる背景には、下請け企業側の「利益確保」という社内事情が存在します。 //ohina.work/post/real_engineer_uraja_festival/ Thu, 06 Aug 2026 12:00:00 +0900 //ohina.work/post/real_engineer_uraja_festival/ はじめに 社内のレクリエーションや地域行事への参加は、本来自由参加であるべきものです。 しかし、参加が実質的に強制され、さらに費用まで自己負担させられるとなると、話は変わってきます。 今回は岡山の企業で実際にあった、うらじゃ祭りの盆踊りにまつわる出来事を紹介します。 「うらじゃ祭りの光と闇」 これは岡山のとあるシステム開発会社での出来事。 従業員数百名規模のSier企業で、この会社では毎年夏、岡山の風物詩である「うらじゃ祭り」の盆踊りに、会社として団体で参加するのが恒例行事となっていた。 表向きは「地域交流」「社内の親睦」を目的としたレクリエーション活動であり、就業規則上も参加は任意とされていた。 ある年、入社1年目の新人達に集合がかけられた。 先輩B 😐 「新人はうらじゃに参加してもらいます。練習は今週土曜にやります。参加者は各自準備お願いします。」 新人A 🙂 「任意参加なんですよね？正直、うらじゃ自体あまり興味ないんですけど……。」 先輩B 😠 「は？やってみたら面白さがわかるから！やってもないのに興味ないとか言うな。」 新人A 😨 「す、すみません……。」 先輩B 😊 「もちろん参加は任意だよ。まあ、みんな出てるけどね。」 新人A 🤔 「（貴重な休日が……。）」 練習が始まった当日。 先輩B 😊 「Aくん、衣装まだ持ってないよね？購買部で買っといて。」 新人A 😳 「え、これ自分で買うんですか……？」 先輩B 😐 「そうそう、みんな自費で用意してるよ。1万円くらいかな。」 Aは驚いたが、周りの先輩たちも当然のように自分の衣装を用意している様子を見て、それ以上何も言えなかった。 練習は連日、休日に行われた。 新人A 😩 （今日も練習か……休日出勤もつかないし。） 先輩C 😅 「まあ毎年恒例だからね。うちの部は昔から皆勤で出てるし。」 新人A 😶 「皆勤……ですか。」 祭り本番当日。 猛暑の中、嫌な顔で衣装を着て踊る新人たちの姿を、会社の先輩達が観覧席から満足げに眺めていた。 先輩B 😄 「うらじゃって素敵やん。」 解説 制度上「任意参加」とされているイベントであっても、実際には職場の空気や上司の視線によって、事実上の強制力が生まれてしまうことは珍しくありません。 うらじゃ祭り自体は、岡山を代表する素晴らしい伝統文化であり、地域を盛り上げる魅力的な催しです。 だからこそ、その価値観や参加意欲を職場の空気で他人に押し付けるのではなく、一人ひとりの意思を尊重した形で継承していってほしいものです。 価値観は人それぞれであり、興味を持てない人がいることも自然なことだと理解した上で、本当に楽しみたい人たちの手によって、この伝統が気持ちよく次の世代へ受け継がれていくことを願います。 おわりに 昨今は労働環境の改善されてきてはいますが、以前こうしたトラブルは継続している状態です。 //ohina.work/post/real_engineer_shower_room_company/ Thu, 06 Aug 2026 10:00:00 +0900 //ohina.work/post/real_engineer_shower_room_company/ はじめに 社内の福利厚生制度の中には「なぜ？」と、首をかしげてしまうものもあります。 今回は中四国のある企業で実際にあった、新社屋のシャワールームにまつわる話を紹介します。 社内にシャワールームがある会社 この企業では、オフィスの建設にあわせてオフィス内にシャワールームが設けられました。 一般的な社員向けの福利厚生施設であれば納得もできますが、設置の経緯を聞くと事情は少し異なります。 このシャワールームは、すでに経営の一線から退いている経営者一族の要望によって作られたものでした。 引退後、畑仕事に精を出していた会長が、作業でかいた汗をその場で流せるようにという理由で、会社にシャワールームを設置することになったといいます。 解説 制度上は従業員も利用できることになっているそうですが、実際に使っている社員はほとんど見当たらないとのことです。 考えてみれば当然で、一般的なシステムエンジニアが、オフィスで汗を流すほどの作業をする機会はまずありません。 社屋にシャワールームを設置するとなれば、給排水設備の工事や、専用スペースの確保など、決して小さくない投資が必要になります。 会社の資金は本来、事業の成長や従業員の労働環境の改善のために使われるべきものです。 経営に関わる立場の人間が、私的な目的のために会社の予算を投じることが許容されてしまう体質は、同族経営やオーナー企業においてしばしば見られる問題の一つといえます。 まとめ 会社員として働く以上、こうした組織のしがらみや、経営陣の意向に振り回される場面から完全に逃れることは難しいものです。 そうした環境に悩まされ続けるのであれば、独立してフリーランスとして働くという選択肢を検討してみるのも一つの手です。 会社の資金の使い方や組織の体質に一喜一憂することなく、自分自身の裁量で仕事を選べる働き方も、キャリアの可能性として視野に入れておきましょう。 関連記事 地方エンジニアにおすすめのフリーランスエージェント //ohina.work/post/real_engineer_ignorance_operator_term/ Tue, 04 Aug 2026 13:00:00 +0900 //ohina.work/post/real_engineer_ignorance_operator_term/ はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 Operatorの意味を知らないDevOpsエンジニア これは富士通の下請けの仕事をしているとある岡山県のシステム会社の話です。 DevOpsの導入支援を行っていたプロジェクトでの出来事です。 上司🤔：「運用者って英語で何て言うの？」 部下😐：「operatorです。」 上司😤：「なんか違うなー。actorにしよう!!」 部下😐：「????」 解説 業界ではリテラシーが低い人がプロジェクトをマネジメントしているケースは少なくありません。 誰でも最初は知らないことがありますし、無知であること自体は仕方ないのかもしれません。 しかしながら、今回のケースでは、DevOpsプロジェクトに参画しているにもかかわらず、「Operator」という言葉の意味を理解していませんでした。 参画が決まった段階で普通はDevOpsの意味を調べているはずですが、それを調べていないことから、仕事への意識の低さが伺えます。 さらに厄介な問題は、正解を教えても間違った理解をしてしまう方がいることです。 脳の仕組み的に、本人の中では独自の定義や解釈が形成してしまう方がいて、世の中で一般的に使われている意味と異なる定義で理解してしまっているケースがあります。 そして、そのような人が意思決定を行う立場にいると、プロジェクト全体が誤った方向に進んでしまうこともあります。 おわりに アサインされる案件は「案件ガチャ」と呼ばれ、リテラシーが低過ぎる人がマネジメントしてるチームにアサインされることもあります。 自身の力でもがくことも大事ですが、中々環境は変わりません。 フリーランスになって、環境を変えるのも選択の一つかもしれません。 関連記事 地方エンジニアにおすすめのフリーランスエージェント //ohina.work/post/real_engineer_money_blue_tax_return/ Tue, 04 Aug 2026 12:00:00 +0900 //ohina.work/post/real_engineer_money_blue_tax_return/ はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 確定申告には「青色申告」と「白色申告」の2種類がある 副業やフリーランスで働くエンジニアが所得を申告する際、確定申告には大きく「青色申告」と「白色申告」の2種類があります。 青色申告: 事前の申請と帳簿付けの手間はかかるものの、最大65万円の控除など税制上の優遇が受けられる 白色申告: 事前申請が不要で手続きは簡単だが、節税効果はほとんどない このように、手間をかけてでも節税するか、簡単さを優先するかで選択が分かれる制度になっています。 意外と多い白色申告エンジニア これはフリーランスで働くエンジニアの確定申告の話です。 無頓着エンジニアB🙄:「確定申告はExcelを使って白色申告でやってる。」 エンジニアA😳:「え、青色申告の方が節税になりますよ。」 無頓着エンジニアB🙄:「白色申告でいいよ、青色申告は面倒くさいから」 節税対策ができない白色申告を選ぶエンジニアって意外と多いんです。 エンジニアは技術に興味はあるけど、金融とか資産形成に全く興味がないって人も珍しくないんですよね。 私物を経費にする脱税エンジニア 一方で、割合としては少ないですが節税を意識しすぎて、脱税に近い行為をしているエンジニアもいます。 脱税エンジニアC😏:「自宅の冷蔵庫、経費で買ったよ。仕事の合間に飲むもの入れてるから」 エンジニアA😳:「え、それ完全に私物じゃないですか…」 脱税エンジニアC😏:「業務に関係あるから大丈夫でしょ(笑)」 エンジニアA😨:「（それ、脱税に近いのでは…）」 業務との関連性が薄い私物まで経費として計上してしまうのは、節税ではなく脱税に近い行為です。 また、意図的でなくても、スーツや化粧品などを仕事で使うものだからという理由で、経費計上してしまっている方も結構います。 フリーランスって税理士を介さず、独学で確定申告している方が多いので、こういった間違った申告が行われることは多々あるそうです。 金額が小さければ、税務署もいちいち調査しないと思いますが、税務調査が入れば、追徴課税や罰則の対象になる可能性もあります、法に抵触するような脱税は辞めておいた方がいいでしょうね。 確定申告を楽にするおすすめ会計ソフト 青色申告のハードルとなる帳簿付けも、会計ソフトを使えば大幅に楽になります。 フリーランスや副業エンジニアに人気の会計ソフトには、以下のようなものがあります。 freee: 銀行口座やクレジットカードとの連携が強く、簿記知識がなくても使いやすい マネーフォワード クラウド確定申告: 家計簿アプリでも有名なマネーフォワードが提供、他サービスとの連携が豊富 弥生会計（やよいの青色申告 オンライン）: 老舗の会計ソフトで、サポート体制が充実している いずれも銀行やクレジットカードの取引を自動で取り込み、青色申告に必要な帳簿や決算書を自動作成してくれるため、独学でも大きな負担なく青色申告を続けられます。 おわりに 白色申告か青色申告かは、最終的にはその人の価値観や手間のかけ方次第ではありますが、できれば節税につながる青色申告をおすすめしたいところです。 帳簿付けの手間も、freee、マネーフォワード クラウド確定申告、弥生会計といった会計ソフトを使えば大幅に軽減できるので、ぜひ活用してみてください。 一方で、経費の範囲を都合よく解釈してしまうと、それは節税ではなく脱税に近づいてしまいます。 脱税は当然おすすめできません。 正しい知識に基づいて申告することを心がけたいですね。 関連記事 地方エンジニアにおすすめのフリーランスエージェント //ohina.work/post/real_engineer_money_romance_scam/ Tue, 04 Aug 2026 11:00:00 +0900 //ohina.work/post/real_engineer_money_romance_scam/ はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 SNSでのビジネスロマンス詐欺被害 これはあるベテランフリーランスエンジニアがLinkedinというSNSを通じて知り合った外国企業に金を騙し取られた話です。 外国企業から一緒にビジネスをやらないかと持ち掛けられたそうです。 しかし、「取引相手」と思っていた相手は、実は詐欺グループで、取引のために自分たちの口座に振り込んでもらう必要があると言われたそうです。 最初は数千円。その後、何度か追加投資を促され、最終的には50万円を失ったそうです。 驚くべきは、そのことを話したときの彼の態度です。 エンジニアA😳:「えっ、50万円も！？」 ベテランエンジニア😳:「まあ、勉強代みたいなもんだから。」 エンジニアA😳:「変だと思わなかったんですか？」 ベテランエンジニア😳:「外国との取引なので、そういうものかと思ってた。」 エンジニアA😳:「….(リアクション薄いな。。。)」 解説 50万円という大金を失ったにもかかわらず、怒ることも悔やむこともなく、平然とした態度をとっています。 エンジニアにはお金に無関心に人も多く、一人暮らしでお金を必要としない生活を続けていて、金銭感覚がずれてしまったのかもしれません。 おわりに 社会人になったからといって金銭の正しい使い方は会社が教えてくれる訳ではないので、金銭に無頓着な方も多いです。 会社の先輩や同僚など周囲の考えに染まるのではなく、自分のお金の使い道には自分自身が責任を持ち、いい加減な社会人にならないよう日頃から意識しておきましょう。 関連記事 地方エンジニアにおすすめのフリーランスエージェント //ohina.work/post/real_engineer_money_debt_boast/ Tue, 04 Aug 2026 10:00:00 +0900 //ohina.work/post/real_engineer_money_debt_boast/ はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 借金を自慢するピエロエンジニア これは岡山県のある40代のエンジニアの方の友人との金銭トラブルの話です。 ご本人はコミュニティと称して、ジモティーでカフェ会などを開いているそうです。 その方はカフェ会で以下のような発言をしたそうです。 40代エンジニアさん😎:「友人が困っているから20万円貸したけど返ってこなかったことあるよ(キリッ)」 エンジニアA😳:「えっ、20万円も！？」 40代エンジニアさん😏:「自己投資(人生経験)だったと思ってるよ(ドヤ～)」 エンジニアA😳:「….(何で自信満々なんだ。。。)」 40代エンジニアさん😎:「コミュニティ運営してると色々あるからね(キリッ)」 エンジニアA😳:「….(コミュニティってカフェ会開いてるだけだろ、ピエロだな。。。)」 大金を人に貸すのはよくない、お金を返さないような人は友人ではない、という小学生でも分かることを理解できてないのに何故か自慢話のように語っているのです。 コミュニティと称してやっていることもハッカソンやアイデアソンなどではなく、 小規模なカフェ会やボードゲーム会で学生さんでもできるような大したことではなく、年齢に相応しい行動とは思えないですが、主催して人を集めている自分に酔ってしまい、客観的な分析ができなくなっているようです。 本当の友達を知ることのないまま大人になり、周りに担ぎ上げられたピエロのような社会人も世の中にはいるようです。 解説 大金を貸して返ってこないという失敗を「自己投資」と称し、反省すべき出来事を武勇伝のように語ってしまう金銭感覚の麻痺が問題です。 そもそも、お金を貸すような相手は本当の友人とは言えません。 ただ、社会人になっても友人と呼べる存在がいない人は、実は少なくありません。 そうした世間とのズレを出さないためにも、スポーツサークルなどのコミュニティに参加し、様々な人と交流を持つことをおすすめします。 おわりに 失敗を自慢話にすり替えてしまう姿勢は、周囲からの信頼を失うだけでなく、社会人としての金銭感覚そのものを鈍らせます。 自分のお金の使い道には常に責任を持ち、いい加減な社会人にならないよう日頃から意識しておきましょう。 関連記事 地方エンジニアにおすすめのフリーランスエージェント //ohina.work/post/real_engineer_ladybug_icon/ Mon, 03 Aug 2026 12:00:00 +0900 //ohina.work/post/real_engineer_ladybug_icon/ はじめに 「経験」や「勘」に頼って仕事を進める文化は、時に思いがけない成果物を生み出してしまいます。 今回は、社内の勉強会をきっかけに、勤怠管理ソフトのデザインが思わぬ方向に進んでしまった職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「エンジニアにデザインを任せてはいけない理由」 これは勤怠パッケージソフトを自社開発している神奈川県の中小企業での出来事。 社内の勉強会で、自社の勤怠管理ソフトのUIデザインを改善しようという話が持ち上がった。 メンバーH（若手）🙂 「せっかくなので、ペルソナを設定したデザイン設計の一連のプロセスを経験し、デザインの基礎をちゃんと学びながら進めませんか?」 勉強会リーダーI 😐 「ペルソナ設計ぃ？　なんか時間かかりそうだなそれ。」 メンバーH（若手）🙂 「UI/UXの原則も踏まえて、視認性とか操作性とか一貫性とか、意識した方がいいと思うんですけど……。」 メンバーJ 😑 「なんか難しい話してるなー。もっと感覚でパッと決めちゃえばよくない？」 メンバーH（若手）😅 「いや、一連のプロセスを理解しないとスキルの取得にならないんじゃ……。」 勉強会リーダーI 😤 「今回はいいんじゃないの」 基礎的なプロセスを「面倒くさい」と感じたリーダーとメンバーたちは、結局、明確なコンセプトを決めないまま、思い思いの感覚でHTMLファイルの編集を始めた。 メンバーJ 😊 「ボタンのアイコン、てんとう虫にしてみようよ。」 勉強会リーダーI 🙂 「こっちは星型で。バランスも良さそうだし。」 メンバーH（若手）😨 「……勤怠管理ソフトに、てんとう虫と星のアイコンですか？」 勉強会リーダーI 😊 「可愛いからいいでしょ！」 コンセプトを誰も定めていなかったため、カラーリングの意図も統一されないまま、デザインは完成してしまった。 メンバーH（若手）😱 （このアイコン、実際に使う社員は何のボタンか分かるんだろうか……。） 出来上がった勤怠ソフトは、ボタンの各種アイコンがなぜか「てんとう虫」や「星」になっており、コンセプトが不明なままカラーリングの意図も分からない、残念な仕上がりとなってしまった。 解説 問題点 HTML5が登場した頃、「デザインは理論化できるので、デザイナーでなくてもデザインができる」という意見が広まったことがあります。 //ohina.work/post/real_engineer_mandala_chart/ Mon, 03 Aug 2026 10:00:00 +0900 //ohina.work/post/real_engineer_mandala_chart/ はじめに 目標設定の手法として有名な「マンダラチャート」。 用紙を9つのマスに分け、中心に書いた目標から具体的なアクションを展開していく、大谷翔平選手も用いたことで知られるメソッドです。 しかし、この手法を導入しても、組織の土台次第では機能しないことがあります。今回はそんな職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「マンダラチャートで目標すら立てられない会社のPDCA」 これは神奈川県の社員数300名規模のIT系中小企業での出来事。 その年、チームの目標設定に「マンダラチャート」を導入することになった。 発案したのはチームリーダーC自身だった。 リーダーC 🙂 「今期からマンダラチャート使って、みんなでチーム目標立てていこうと思うんだよね。」 メンバーD 🙂 「大谷選手が使ってたやつですね！やってみましょう。」 期待に胸を膨らませて始まった打ち合わせだったが、いざマスを埋める段階になると空気が変わっていく。 リーダーC 🙂 「じゃあ中心のマスに、今期のチーム目標書いてみて。えーと……『スキルを上げる』とかでいいんじゃない？」 メンバーE 🙂 「私は『もっと頑張る』でいいと思います。」 メンバーD 🤔 「あの、もう少し具体的に、何をどれくらい、という形にした方がよくないですか？せっかくリーダーが導入してくれた手法なので、ちゃんと活かしましょう。」 リーダーC 😅 「うーん……『スキルをたくさん上げる』とかでいいと思うけどな……。」 メンバーE 😑 「細かく決めなくても、なんとなく伝わればよくないですか？」 具体的な数値や行動に落とし込もうとしても、抽象的な言葉しか出てこない。 メンバーDは何度か具体化を提案したが、発案者であるはずのリーダーCも、メンバーEも取り合わず、打ち合わせの時間は限られているまま時間だけが過ぎていく。 リーダーC 😓 「……とりあえず今日はこのままで進めとこうか。」 具体的な目標が定まらないまま、打ち合わせは終了となった。 その後も、 誰が何を担当するか どの周期で振り返りをするか 進捗が遅れたときの修正方法 といった基本的な仕組みは決められないまま、なんとなく計画だけが独り歩きしていった。 メンバーDは「せめて振り返りの日程だけでも決めましょう」と何度か声をあげたが、誰からも明確な返答はなかった。 メンバーD 😮‍💨 「言い出しっぺのリーダーが一番動いてくれないと、この仕組みは回らないと思うんですが……。」 リーダーC 😐 「まあまあ、そのうち何とかなるって。」 数ヶ月後。 //ohina.work/post/real_engineer_dormitory_trouble/ Sun, 02 Aug 2026 10:00:00 +0900 //ohina.work/post/real_engineer_dormitory_trouble/ はじめに 社会人になれば、会社という組織はきちんとルールに則って運営されているというイメージを持つ人は多いのではないでしょうか？ しかし現実には、社内の意思決定プロセスが曖昧なまま放置され、従業員が振り回されてしまう会社も存在します。 立場が上だから、総務だからといって、必ずしも合理的な対応をしてくれるとは限らないのです。 本記事が、会社という組織を過信せず、自分の権利や手続きについて主体的に確認する姿勢を持つきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 社員寮の退寮手続きだけで2ヶ月以上かかるトンデモ会社 通勤時間短縮のための退寮相談 これは、とある神奈川県のSES会社での話です。 この会社では従業員に対して、会社近隣のアパートを社員寮として提供していました。 ある新人社員Aさんは、社内勤務から客先常駐に配属が変わったことで、社員寮からの通勤に時間がかかり過ぎるようになり、退寮を検討します。 就業規則や寮規則には退寮に関する規定がなかったため、退寮が可能かどうか、可能な場合はどのような手順を踏めばよいかを直属の上司に確認しました。 すると、上司からはこんな反応が返ってきます。 上司😕：「会社の方針として、若手が社員寮を出るのはあまり良く思われていないんだよね……」 はっきりした理由は語られず、曖昧な物言いでしたが、話によると、過去には女性社員が「ユニットバスが嫌だ」という理由で退寮を申し込んだものの、否認された前例もあったそうです。 その後、上司から 上司:「取り敢えず、総務部に確認のメール送信して」 新人A😐: 「分かりました。」 指示を受けたAは、退寮を検討している理由と、手続きが可能かどうかを総務部・上司・課長宛にすぐにメールで送信しました。 新人A😳:「通勤時間短縮のために退寮を検討してます、退寮できるかどうか確認したいです📨」 噛み合わないコミュニケーション ところが、何故か総務部は新人Aに返信せず、上司と、課長にのみメール返信しました。 総務からの指摘を受けた上司は新人Aに以下のように指摘しました。 上司😠：「なんでメールを総務部に送ったんだ。」 新人A😳 ：「え、先ほどメールを送信するように指示を受けたので。。。」 上司😠：「今送るとは思わなかった。」 新人A😳 ：(いつだったらいいんだよ) Aさんとしては、上司から総務に確認するよう指示されたため、すぐに送信しただけです。 内容的に何時送信しても特に問題ないような内容ですが、何故か上司から叱責をうけ、さらにいつ送信すればよかったのかは最後まで明かされませんでした。 また、総務部からの返信内容は一切新人Ａには共有されず、どうも会社側が何かひた隠ししているような状態でした。 その後、会社が月末に実施ている帰社報告会で、課長・上司と対面で話し合いの上、方針を決定することになりました。 これにより退寮は1ヶ月先延ばしになりました。 帰社報告のドタキャン ところが、帰社報告の日に課長も上司も欠席していることに気づきます。 新人A😐: 「課長も上司もいないな。。。」 社内の別の社員Bに聞いて回ったところ、以下のように教えてくれました。 新人A😐: 「課長と上司って今日出社してます?」 社員B😅：「上司さんは業務都合で休み、課長はプライベートの都合でお休みだって。」 新人A😐: 「。。。」 新人Ａに連絡がなく、ドタキャンされてしまったため、帰社報告では方針を決められず、さらに1ヶ月ほど時間が過ぎていきました。 社内で見えてきた「本音」 社内やインターネットで似たような事例を調べてみると、社会人経験の浅い新人が退寮すると金銭面でのトラブルを起こすリスクがあることから、総務部が寮に留めておきたがる、という噂があるそうでした。 一方で、新人でも実家からの一人暮らしに切り替えた社員は特に総務から指摘がなかったことから、上記は表向きの理由は本音は以下の理由だと推測しました。 住宅手当を支給するより、社員寮を維持する方が会社にとって節税効果が高い 退寮時期が中途半端だと、不動産会社への賃料を余分に支払う必要が生じる そこで新人Aは、退寮時期や、移住先の物件の賃料は会社の希望に合わせられること、通勤経路が短くなれば通勤手当の支給額も減り会社側にもメリットがあることを提案してみることを検討しました。 「それはお前が考えることではない」 後日、現場で上司と直接話す機会がありました。 新人A🙂: 「退寮時期と賃料などの条件をご提示していただければ会社の条件に合わせます。また、通勤手当が少なくなるので会社にもメリットがあります。」 上司😑：「社員寮を出ると、普通のアパートよりお金がかかる」 言われなくても分かるようなことを、執拗に念押しされます。 //ohina.work/post/real_engineer_unreasonable_boss/ Sun, 02 Aug 2026 10:00:00 +0900 //ohina.work/post/real_engineer_unreasonable_boss/ はじめに 仕事では「言われたことをそのまま実行したのに怒られる」という理不尽な出来事が起こることがあります。 この記事では、曖昧な指示や、認識の違い、記憶違いによる職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「自分が言ったことを5分で忘れる理不尽上司」 これは関東のとあるシステム開発会社での出来事。 複数のプロジェクトが同時に動くオフィスでは、サーバー構築やシステム開発、データ分析などの業務が日常的に行われていた。 社員たちはそれぞれの案件を抱え、部署やプロジェクトの垣根を越えて協力する場面も多かった。 ある日、オフィスレイアウト変更に伴い、別プロジェクトの上司Bが、別フロアに異動となり、デスクを移動することになった。 部下Aは自分の担当業務を進めている最中、突然電話を受ける。 上司B 😐 「これからデスクを移動するから、私の机の上にある物を全部机から片付けてまとめておいて。」 部下A 🙂 「わかりました。」 上司Bの机に目をやると、デスクトップ型PCが設置されていたからだ。 念のため確認した方がいいと考えた部下Aは、再度連絡を入れた。 部下A 🤔 「机の上にデスクトップPCがありますが、これも片付けてよろしいでしょうか？」 上司B 😐 「いいよ。全部片付けておいて。」 部下A 😊 「承知しました。」 確認も取れたため、部下Aは安心して片付けを始めた。 書類、文房具、小物類を整理し、段ボールにまとめる。 最後にPCへ手を伸ばす。 するとPCの電源ランプが点灯していることに気付いた。 部下A 🤔 「あれ、電源が入っているな。」 しかし、机から移動するには電源を切るしかない。 しかも先ほど「PCも片付けてよい」と明確に許可を得ている。 デスクから下すにためには、当然電源も切る必要がある。 そう判断した部下Aは、通常の手順でシャットダウンを実施し、PCを片付けた。 数分後。 オフィスの空気が突然変わった。 上司B 😠 「誰だ！！PCの電源を切ったのは！！」 周囲の社員たちが驚いて顔を上げる。 部下A 😳 「私です。片付けるよう指示をいただいたので……。」 上司B 😡 「勝手に人のPCの電源を切ったらだめだろ！！」 部下A 😨 「???」 どうやら上司BはPC上で大規模な計算処理を実行していたらしい。 その処理は長時間かかる作業で、電源を切られたことで途中で停止してしまったのだ。 部下A 😰 （いや、だから確認したんだけど……。） しかし上司Bの怒りは収まらなかった。 //ohina.work/post/real_engineer_vocabulary_lacking_pm/ Sat, 01 Aug 2026 14:00:00 +0900 //ohina.work/post/real_engineer_vocabulary_lacking_pm/ はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 語彙力なさすぎPM TMの意味が分かっていないレビュアー これは、神奈川県のとあるシステム会社で社内向けスライド資料のレビューで起きた出来事です。 PM😤：「スライドタイトルの製品名の『TM』が付いていないじゃないか。ちゃんと表記しなさい。」 部下😐：「????」 TMは「Trade Mark」の略で、製品名、ロゴが自社の商標であることを示すための記号です。 Nintendo DSなどNintendoの製品にも末尾に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の下にいるとレビューでもピントのずれた指摘を受けることが多く、自身の成長には繋がりません。 //ohina.work/post/real_engineer_goal_setting_takes_forever/ Sat, 01 Aug 2026 11:00:00 +0900 //ohina.work/post/real_engineer_goal_setting_takes_forever/ はじめに 目標管理制度を初めて導入する会社では、思わぬところでつまずくことがあります。 今回は、目標設定そのものに膨大な時間がかかってしまい、肝心の業務改善に手が回らなくなってしまった職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「目標設定に四半期の約1/4を消費する会社」 これは設立30年以上の中小SIerでの出来事。 これまで目標管理の仕組みが存在しなかったこの会社で、経営層の意気込みのもと、初めて全社員による個人目標設定が導入されることになった。 現場を統括する課長Hが自身のチームの目標を作成し、役員Fへの説明の場に持ち込んだ。 課長H 🙂 「今期のチーム目標は『担当システムの保守品質を向上させる』としました。」 役員F 😐 「そんな目標じゃ、ぬるい。もっと危機感を持って考えろ。」 課長H 😳 「危機感……ですか。具体的にはどのあたりを……」 役員F 😠 「そんなことまで俺が説明しなきゃいけないのか！お前がチームの責任者だろう！！」 課長Hは何が悪かったのか具体的な説明を得られないまま、感情論だけで目標を突き返された。 しかし部下への説明の場では、役員から言われたことを何とか自分の言葉に変換しようとする。 課長H 😓 （役員は「危機感」とか「ぬるい」って言ってたな……つまり、もっと厳しくすればいいのか？） 課長H 🙂 「みんな、今期の目標だけど、もっと危機感を持って厳しめに設定しよう。」 部下G 🤔 「危機感、というのは具体的にどういう……」 課長H 😅 「いや、そこはお前らで考えてくれ。とにかく緩い目標はダメだって話だから。」 部下Gたちは意図のつかめないまま、とりあえず数値を厳しくした目標を作り直し、再び課長Hを経由して役員Fへ持ち込む。 課長H 🙂 「危機感を持たせた目標に修正しました。」 役員F 😡 「なんだこれ、数字だけ厳しくすればいいってもんじゃないだろ！！本質を考えろと言ったはずだ！！」 課長H 😨 「す、すみません……」 課長Hはまた役員から罵声を浴びるが、「本質」という言葉の意味も具体的にはつかめないまま部下の元へ戻る。 課長H 😰 「役員から、本質を考えろって言われたんだ。もう一度、本質的に考え直してくれ。」 部下G 😔 「本質……というのは、前回の『危機感』とは違う話ですか？」 課長H 😩 「いや……それは……とにかく、もっと深く考えてくれ。」 部下Gたちは、前回の指摘との関係もわからないまま、また目標を修正する。 このやり取りが何度も繰り返され、目標は一向に固まらなかった。 部下G 😩 （もう4回目の書き直しだ……何を直せばいいのか、誰にもわかっていない。） 課長H 😥 （役員が何を言いたいのか、自分にも正直よくわかっていない……。） 気づけば、目標設定だけで3ヶ月以上が経過していた。 //ohina.work/post/real_engineer_stranger_odd/ Tue, 30 Jun 2026 10:00:00 +0900 //ohina.work/post/real_engineer_stranger_odd/ はじめに 社会人になれば、誰もが知識面でも精神面でも自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし現実には、知識や精神が未成熟な方も少なくなく、先輩や上司が必ずしも頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの意見を受け入れるのではなく、自分のキャリアを自分自身で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 エンジニアは「変わった人」と思われるケースが多い ハッカソンで出会った独特過ぎる発想 これは、生成AIを活用したバイブコーディングのハッカソンに参加した際の話です。 あるミドルエイジのエンジニアの方が、ハッカソンで提案するアプリについてこう話していました。 ミドルエンジニア🤪：「汚物を投げるアプリを作ろう💩」 思わず耳を疑うアイデアでした。 もちろんハッカソンでは、実用性よりも発想の面白さを重視したネタアプリが数多く生まれます。 とはいえ、そのアイデアは私にとってかなり常識離れしたものに感じられました。 周囲も苦笑いしていましたが、本人はまったく気にする様子がありません。 ミドルエンジニア😏：「面白いでしょ？」 むしろ自信満々に語っていたのが印象的でした。 エンジニアには、既成概念にとらわれず自由な発想をする人が少なくありません。 その創造性が革新的な技術を生み出す一方で、時には周囲から「変わった人」と見られてしまうこともあるようです。 異業種から見たエンジニアの印象 これは異業種交流会での話です。 交流会に参加していると、エンジニアに対する印象について話題になることがあります。 その際、営業職や事務職の方から次のような意見を聞くことがありました。 営業職の方😕：「エンジニアは少し話しかけづらいイメージがありますね」 事務職の方😣：「個性的な人が多い印象なので、最初は少し緊張します」 もちろん、これは一部の方の感想に過ぎません。 しかし、技術職に対して似たようなイメージを持つ人が一定数いることは肌で感じました。 ある交流会で、私が参加者と普通に会話をしていたときのことです。 相手からこんなことを言われました。 交流会の相手😲：「あなた、エンジニアなんですか？ エンジニアの割に話しやすいですね」 相手に悪気はなかったのでしょう。 しかし、この言葉からは「エンジニアはコミュニケーションが苦手」という先入観がうかがえます。 実際、技術的な話に熱中し過ぎたり、自分の専門分野の話ばかりしてしまったりするエンジニアは存在します。 私自身、そうした場面を目にしたことがあります。 ただし、それはエンジニア全体に当てはまる話ではありません。 コミュニケーション能力が高く、相手の立場に合わせて分かりやすく説明できるエンジニアも数多くいます。 それでも、一部の印象的な言動が目立つことで、「エンジニアは変わった人が多い」というイメージが生まれているのかもしれません。 まとめ 社会人だからといって、全員が自立した大人というわけではありません。 先輩や上司をリスペクトすることは重要ですが、妄信するのは危険です。 先輩や上司の良いところは取り入れ、悪いところは反面教師として捉え、自立した社会人を目指しましょう。 関連記事 地方エンジニアにおすすめのフリーランスエージェント //ohina.work/post/real_engineer_stranger_ignorance/ Tue, 30 Jun 2026 10:00:00 +0900 //ohina.work/post/real_engineer_stranger_ignorance/ はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 意外と無知な人が多い エンジニアとして働く中で、意外な部分で知識が抜けている人に遭遇することがあります。 以下の記事では、実際にあった知識レベルにまつわるエピソードをそれぞれ個別に紹介しています。 Operatorの意味を知らないDevOpsエンジニア ピントがずれた指摘が多いレビュアー 関連記事 地方エンジニアにおすすめのフリーランスエージェント //ohina.work/post/real_engineer_stranger_money/ Tue, 30 Jun 2026 10:00:00 +0900 //ohina.work/post/real_engineer_stranger_money/ はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 金銭感覚が疎い人が多い エンジニアの中には、意外と金銭感覚がずれてしまっている人も少なくありません。 以下の記事では、実際にあった金銭トラブルのエピソードをそれぞれ個別に紹介しています。 借金を自慢するピエロエンジニア SNSでのビジネスロマンス詐欺被害 青色申告を使わないエンジニアが意外と多い 関連記事 地方エンジニアにおすすめのフリーランスエージェント //ohina.work/post/fan_global_solution/ Fri, 05 Dec 2025 10:00:00 +0900 //ohina.work/post/fan_global_solution/ はじめに 「資産形成をサポートします」という話を聞いたとき、あなたはどう反応するでしょうか。 本記事では、岡山のシステムエンジニアの間で口コミ的に広まっているとされる「ファングローバルソリューション（FAN GLOBAL SOLUTION）」という団体について、現時点で確認できる情報を整理します。 なお本記事は、特定の団体や個人を断定的に非難する目的のものではなく、公開情報をもとに一社会人として金銭に関する判断を行う際の参考情報を提供するものです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 ファングローバルソリューションとは? 「ファングローバルソリューション（FAN GLOBAL SOLUTION）」は、名古屋・岡山・シンガポールで活動しているとされる、資産形成のサポートを行う団体らしいです。 Google検索をしても公式ホームページは見つからず、日本の法務局のオンライン登記情報検索で調べても、該当する法人登記は確認できません。 現時点で情報公開しているのは以下の2サイトのみです。 崖っぷちシングルマザー 詐欺ったー 公式に情報を公開していないにもかかわらず噂が広まった理由としては、岡山市内に在住しているシステムエンジニアの中に会員となっている人がいるという噂があるらしく、その人物からの口コミを経由して、岡山のSEの間で一気に噂が広まったとされています。 サポート内容 情報源によると、入会金2〜3万円と、サポート料約90万円を支払うことで、生涯に渡って資産形成のサポートを受けられるとされています。 公式サイトを確認していないため、具体的にどのようなサポート内容が提供されるのか、解約や返金の条件がどうなっているのかといった基本的な情報は、不明です。 90万円という高額な金額を支払って、資産形成のサポートを受ける必要があるかどうかを一社会人として自分自身で判断しろということだと思われます。 余談ですが、生涯保証サポートというとこの業界だとShift-AIが有名ですね。 この類のサービスは生涯サポートにしなければならないという制約でもあるのでしょうか。 SHIFT-AIについて興味のある方はこちらをご参照ください。 SHIFT-AIとは? おわりに こうしたサービスが岡山のSEの間で広まりやすい背景には、金融リテラシーの低さがあると考えられます。 岡山のシステムエンジニアには中小SIerで働く方や専門学校卒の方が多く、業務の中で金融について体系的に学ぶ機会が少ない傾向があります。 実際、NISA 開始時に周りに煽られて勢いで投資を始めて失敗した人が結構いました。 周囲に流されるのではなく、公開情報を自分で確認し、金銭を支払う価値があるかどうかを一社会人として主体的に判断する姿勢を持つことが大切です。 また、金融関連のエンジニアのトラブル事例について別記事で取り上げているので、こちらもご参照ください。 本当にあった?エンジニアの怖い話「借金を自慢するピエロエンジニア」 本当にあった?エンジニアの怖い話「SNSでのビジネスロマンス詐欺被害」