エンジニア実録

はじめに 脳科学的に見ても、記憶力には個人差があり、物事を覚えておくのが苦手な人は一定数存在すると言われています。 実際、自分が作ったファイルの場所がわからなくなり、人に聞いてしまうという方も少なくありません。 本記事では、作業報告書の提出をめぐって起きた、ある岡山のシステム会社の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 😰：「……承知しました。」 指示通りにメーリングリスト宛てに設定したところ、障害通知メールが繰り返し送信され続け、メンバー全員のメールボックスが瞬く間にパンクしました。

はじめに 顧客との打合せでは、要件への理解不足を指摘された時にどう振る舞うかで、その後の信頼関係が大きく変わります。 この記事では、自分の理解不足を認めたくないという心理が、かえって顧客の不信感を招いてしまった職場のトラブルを紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 チャンスを自ら潰す案件潰し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社に対する印象は、決して良いものではなかった。 解説 顧客の補足説明を遮って「分かっている」と主張したり、言葉を復唱・言い換えするだけで実質的な回答を避けたりする行動は、理解できていないことを隠そうとするあまり、逆に理解できていないことを露呈させてしまう典型的なパターンです。

はじめに 休日は業務から離れて自分の時間を過ごすものだと考えている人は多いのではないでしょうか。 しかし、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さん 😆 「お疲れさまっす！気をつけて帰ってくださいねー。」 解説 百歩譲って休日に作業をすること自体は仕方ないとしても、事前に「この部分についてメモをまとめておいてほしい」と後輩に指示しておけば、わざわざ部下の自宅にいく必要はなかったはずです。

はじめに 大手企業の案件を地方の下請け企業が受注する「ニアショア開発」は、コストメリットの大きい発注形態として広く活用されています。 しかし、その内側では、社内の都合によって工数が実態とかけ離れた形で見積もられているケースも存在します。 今回は岡山のとある下請けIT企業で実際にあった、見積もり水増しにまつわる話を紹介します。 地方企業に発注をしてはいけない理由。ニアショアのリスク これは、大手SIerである富士通の案件を受注している、岡山のとある下請けIT企業での出来事。 ある日、若手エンジニアが新規案件の見積もりを行っていた。 若手エンジニア 🙂 「この作業は設定ファイルを修正するだけだから、1日あれば十分だな。動作確認とバッファを含めて3人日で見積もっておこう。」 若手エンジニア 😅 （これでもだいぶ多めに見てるけど……。） すると、隣の席で作業をしていたベテラン社員がその見積もりに気づく。 ベテラン社員 😏 「おいおい、それじゃ工数が少なすぎるよ。2週間は取らないと。」 若手エンジニア 😳 「え！？　実際の作業時間ってそれくらいですよね？」 若手エンジニア 😰 （3人日でもだいぶとりすぎのつもりだったのに……。） ベテラン社員 😏 「それじゃうちの利益にならないから。」（ヘラヘラしながら鼻で笑う） 若手エンジニア 😞 「わかりました……。」 納得はいかないまま、若手エンジニアは2週間分の工数で見積もりを作成することになった。 その後、この見積もりはそのまま顧客へ提出され、無事に発注を受けた。 若手エンジニアは指示された通りに、2週間かけて作業を進め、完了後に顧客への作業報告を行った。 顧客 🤨 「ん？　この作業って設定ファイルを変更するだけで、コード修正は入ってないですよね？　なんで2週間もかかったんですか？」 若手エンジニア 😨 「えっと、それは……。」（ちらっとベテラン社員の方を見る） ベテラン社員 😶 （ぷいっとそっぽを向いて知らん顔） 若手エンジニア 😱 （だんまりかよ！） 結局、顧客への説明はすべて若手エンジニア一人が背負うことになり、水増しを指示したベテラン社員は素知らぬ顔で自分の作業に戻っていった。 解説 今回のケースのように、実際の作業量とかけ離れた工数を見積もりに乗せる背景には、下請け企業側の「利益確保」という社内事情が存在します。

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

はじめに 社内のレクリエーションや地域行事への参加は、本来自由参加であるべきものです。 しかし、参加が実質的に強制され、さらに費用まで自己負担させられるとなると、話は変わってきます。 今回は岡山の企業で実際にあった、うらじゃ祭りの盆踊りにまつわる出来事を紹介します。 「うらじゃ祭りの光と闇」 これは岡山のとあるシステム開発会社での出来事。 従業員数百名規模のSier企業で、この会社では毎年夏、岡山の風物詩である「うらじゃ祭り」の盆踊りに、会社として団体で参加するのが恒例行事となっていた。 表向きは「地域交流」「社内の親睦」を目的としたレクリエーション活動であり、就業規則上も参加は任意とされていた。 ある年、入社1年目の新人達に集合がかけられた。 先輩B 😐 「新人はうらじゃに参加してもらいます。練習は今週土曜にやります。参加者は各自準備お願いします。」 新人A 🙂 「任意参加なんですよね？正直、うらじゃ自体あまり興味ないんですけど……。」 先輩B 😠 「は？やってみたら面白さがわかるから！やってもないのに興味ないとか言うな。」 新人A 😨 「す、すみません……。」 先輩B 😊 「もちろん参加は任意だよ。まあ、みんな出てるけどね。」 新人A 🤔 「（貴重な休日が……。）」 練習が始まった当日。 先輩B 😊 「Aくん、衣装まだ持ってないよね？購買部で買っといて。」 新人A 😳 「え、これ自分で買うんですか……？」 先輩B 😐 「そうそう、みんな自費で用意してるよ。1万円くらいかな。」 Aは驚いたが、周りの先輩たちも当然のように自分の衣装を用意している様子を見て、それ以上何も言えなかった。 練習は連日、休日に行われた。 新人A 😩 （今日も練習か……休日出勤もつかないし。） 先輩C 😅 「まあ毎年恒例だからね。うちの部は昔から皆勤で出てるし。」 新人A 😶 「皆勤……ですか。」 祭り本番当日。 猛暑の中、嫌な顔で衣装を着て踊る新人たちの姿を、会社の先輩達が観覧席から満足げに眺めていた。 先輩B 😄 「うらじゃって素敵やん。」 解説 制度上「任意参加」とされているイベントであっても、実際には職場の空気や上司の視線によって、事実上の強制力が生まれてしまうことは珍しくありません。 うらじゃ祭り自体は、岡山を代表する素晴らしい伝統文化であり、地域を盛り上げる魅力的な催しです。 だからこそ、その価値観や参加意欲を職場の空気で他人に押し付けるのではなく、一人ひとりの意思を尊重した形で継承していってほしいものです。 価値観は人それぞれであり、興味を持てない人がいることも自然なことだと理解した上で、本当に楽しみたい人たちの手によって、この伝統が気持ちよく次の世代へ受け継がれていくことを願います。 おわりに 昨今は労働環境の改善されてきてはいますが、以前こうしたトラブルは継続している状態です。

はじめに 社内の福利厚生制度の中には「なぜ？」と、首をかしげてしまうものもあります。 今回は中四国のある企業で実際にあった、新社屋のシャワールームにまつわる話を紹介します。 社内にシャワールームがある会社 この企業では、オフィスの建設にあわせてオフィス内にシャワールームが設けられました。 一般的な社員向けの福利厚生施設であれば納得もできますが、設置の経緯を聞くと事情は少し異なります。 このシャワールームは、すでに経営の一線から退いている経営者一族の要望によって作られたものでした。 引退後、畑仕事に精を出していた会長が、作業でかいた汗をその場で流せるようにという理由で、会社にシャワールームを設置することになったといいます。 解説 制度上は従業員も利用できることになっているそうですが、実際に使っている社員はほとんど見当たらないとのことです。 考えてみれば当然で、一般的なシステムエンジニアが、オフィスで汗を流すほどの作業をする機会はまずありません。 社屋にシャワールームを設置するとなれば、給排水設備の工事や、専用スペースの確保など、決して小さくない投資が必要になります。 会社の資金は本来、事業の成長や従業員の労働環境の改善のために使われるべきものです。 経営に関わる立場の人間が、私的な目的のために会社の予算を投じることが許容されてしまう体質は、同族経営やオーナー企業においてしばしば見られる問題の一つといえます。 まとめ 会社員として働く以上、こうした組織のしがらみや、経営陣の意向に振り回される場面から完全に逃れることは難しいものです。 そうした環境に悩まされ続けるのであれば、独立してフリーランスとして働くという選択肢を検討してみるのも一つの手です。 会社の資金の使い方や組織の体質に一喜一憂することなく、自分自身の裁量で仕事を選べる働き方も、キャリアの可能性として視野に入れておきましょう。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 「資産形成をサポートします」という話を聞いたとき、あなたはどう反応するでしょうか。 本記事では、岡山のシステムエンジニアの間で口コミ的に広まっているとされる「ファングローバルソリューション（FAN GLOBAL SOLUTION）」という団体について、現時点で確認できる情報を整理します。 なお本記事は、特定の団体や個人を断定的に非難する目的のものではなく、公開情報をもとに一社会人として金銭に関する判断を行う際の参考情報を提供するものです。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 ファングローバルソリューションとは? 「ファングローバルソリューション（FAN GLOBAL SOLUTION）」は、名古屋・岡山・シンガポールで活動しているとされる、資産形成のサポートを行う団体らしいです。 Google検索をしても公式ホームページは見つからず、日本の法務局のオンライン登記情報検索で調べても、該当する法人登記は確認できません。 現時点で情報公開しているのは以下の2サイトのみです。 崖っぷちシングルマザー 詐欺ったー Xにも投稿がありましたが、投稿に記載されているサイトは閉鎖されていて、実態は分かりませんでした。 マッチングアプリで実際にあった勧誘方法＆ファングローバルソリューションの実態について https://t.co/oi4FHF47nW — ともやん【ブログ仲間募集中】 (@tomoyanblog75) May 7, 2023 公式に情報を公開していないにもかかわらず噂が広まった理由としては、岡山市内に在住しているシステムエンジニアの中に会員となっている人がいるという噂があるらしく、その人物からの口コミを経由して、岡山のSEの間で一気に噂が広まったとされています。 サポート内容 情報源によると、入会金2〜3万円と、サポート料約90万円を支払うことで、生涯に渡って資産形成のサポートを受けられるとされています。 公式サイトを確認していないため、具体的にどのようなサポート内容が提供されるのか、解約や返金の条件がどうなっているのかといった基本的な情報は、不明です。 90万円という高額な金額を支払って、資産形成のサポートを受ける必要があるかどうかを一社会人として自分自身で判断しろということだと思われます。 余談ですが、生涯保証サポートというとこの業界だとShift-AIが有名ですね。 この類のサービスは生涯サポートにしなければならないという制約でもあるのでしょうか。 SHIFT-AIについて興味のある方はこちらをご参照ください。 SHIFT-AIとは? おわりに こうしたサービスが岡山のSEの間で広まりやすい背景には、金融リテラシーの低さがあると考えられます。 岡山のシステムエンジニアには中小SIerで働く方や専門学校卒の方が多く、業務の中で金融について体系的に学ぶ機会が少ない傾向があります。 実際、NISA 開始時に周りに煽られて勢いで投資を始めて失敗した人が結構いました。 周囲に流されるのではなく、公開情報を自分で確認し、金銭を支払う価値があるかどうかを一社会人として主体的に判断する姿勢を持つことが大切です。 また、金融関連のエンジニアのトラブル事例について別記事で取り上げているので、こちらもご参照ください。 本当にあった?エンジニアの怖い話「借金を自慢するピエロエンジニア」 本当にあった?エンジニアの怖い話「SNSでのビジネスロマンス詐欺被害」

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