本当にあったSierの話「中小企業ではスキルアップができない理由」

  • POST
はじめに 「なぜ中小企業ではスキルが伸びないのか」—— 転職や異動を経験した人なら、この疑問を感じたことがあるかもしれません。 大企業と比べて研修制度が整っていない、という指摘はよくあります。しかしそれだけではなく、組織文化や個人の習慣レベルに深い根本原因が存在します。 表面的な「研修がない」「予算がない」という理由の背後には、目標設定能力の欠如、学習に対する姿勢の問題、そして日常的な生活習慣まで、複合的な要因が絡み合っています。これらは一朝一夕には解決できず、組織全体の文化として根付いているケースがほとんどです。 本記事では、実際の現場で起きた事例をもとに、中小企業でスキルアップが進まない5つの理由を解説します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 1. 論理的思考力が弱く、目標設定と達成プロセスが機能しない 事例 これは、社員数300名規模のIT系中小企業での事例です。 ある年、社内で目標設定の手法として有名な「マンダラチャート」を用いて、チーム目標を立てる試みが始まりました。 マンダラチャートは大谷翔平選手が目標設定に用いたメソッドとして有名になった手法で、用紙を9つのマスに分け、マスの中心に書いた目標から具体的なアクションを展開していくものです。 しかし、いざ実践してみると問題が次々と浮き彫りになりました。 メンバーの論理的思考力や語彙力が不足しており、「スキルを上げる」「もっと頑張る」といった抽象的な表現しか出てこず、測定可能な具体的な目標を定義できませんでした。 具体的な目標設定が定まっていないにも関わらず、なぜか抽象的な目標設定のまま、打ち合わせが終了となり、その後も、 誰が何を担当するか どの周期で振り返りをするか 進捗が遅れたときの修正方法 といった基本的な仕組みを決めないまま、計画が進み、その結果、 そもそもPDCAのPlanすらちゃんと立てられない 目標の進捗確認が誰にも行われない 目標を立てただけで終わり、四半期後には誰も覚えていない という状態になり、スキル向上には全くつながらなかったようです。 理由 目標を立てる能力が弱い組織では、スキル向上の仕組みそのものが成立しません。 論理的思考力がなければ「何を・いつまでに・どうやって」という構造で考えられないため、計画は絵に描いた餅になります。 また、目標設定は一種のスキルです。 このスキル自体を学ぼうとしない組織では限り、毎回同じ失敗が繰り返されます。 2. 目標設定に異常な時間がかかる 事例 これは、設立30年以上の中小SIerでの事例です。 長年にわたって目標管理の仕組みがなく、初めて社員の目標設定を導入することになりました。 経営層の意気込みのもと、全社員が個人目標を立てて管理職と合意するプロセスが設計されました。 しかし蓋を開けると、想定外の問題が次々と発生しました。 まず、役員が期待するレベルと部下が設定している目標の内容に大きなギャップがあり、 何度もレビューをしましたが、全く話がかみ合いませんでした。 さらに、 目標の定義が共有されていない(「目標」と「行動計画」の区別がない) 評価基準が不明確なため、何を書けば良いか誰もわからない 上司も部下に適切なフィードバックができない といった問題が重なり、目標のすり合わせが何度もやり直されました。 結果として、 目標設定だけで3ヶ月以上かかり、四半期の約1/4を目標設定の議論だけで消費し、実際に業務改善に使える時間がほとんど残らなかった という非効率な状態になりました。 また、期末に採算レビューを行っても、何が問題でどこを改善すべきかを社員が理解していないため、多くの社員が目標未達となりました。 次の期になっても同じプロセスが繰り返され、改善の兆しは見えませんでした。 理由 組織として「目標を作る技術」すら持っていないのです。 目標設定のノウハウが蓄積されていない組織では、毎回ゼロから議論が始まり、肝心な実行期間が削られます。 スキルアップどころか、目標管理のプロセス自体が膨大な学習コストを組織から奪っています。 加えて、「目標設定に時間がかかる」こと自体が問題視されないことも大きな課題です。 本来であれば「なぜ3ヶ月もかかったのか」を振り返り、プロセスを改善すべきですが、「時間をかけた=真剣に取り組んだ」という誤った達成感で終わってしまうケースが多いです。 3. 自分本位の考えを重視し、教科書通りの学習をしない 事例 これは、勤怠パッケージソフトを自社開発している中小企業での事例です。 社内の勉強会の一環で、勤怠パッケージソフトのUIデザインの改善を題材として、 デザインについて学習しようという意見が上がりました。 デザイン設計時には以下のようなプロセスを踏む必要がありうます。

東京に上京しても最新技術を習得できるとは限らない

  • POST
はじめに エンジニアのキャリアを考えるとき、「東京に行けばもっと最新技術に触れられる」「地方にいては技術力が遅れてしまう」と考える方は多いのではないでしょうか。 確かに東京には多くのIT企業が集中しており、案件数も豊富で最新技術が採用されやすい環境があります。しかし、東京に上京したからといって、必ずしも最新技術を習得できるわけではありません。 この記事では、東京と地方のエンジニア環境を比較しながら、上京を検討しているエンジニアが知っておくべき現実について解説します。 東京のメリット 案件数・技術スタックの多様性 東京にはIT企業が数多く存在し、案件数も地方と比べてはるかに多く、プロジェクトで採用される技術スタックも比較的新しいものが採用される傾向があります。 最新のクラウド技術やモダンなフロントエンドフレームワーク、AIを活用したシステム開発など、先進的な取り組みをしている企業も多く存在します。 東京のデメリット 案件数が多い分、「案件ガチャ」がある 日本国内の企業のほとんどは中小企業です。案件数が多いがゆえに、以下のようなケースにアサインされるリスクも存在します。 マイナーな技術を採用したプロジェクト: 需要が限定的で、転職市場での汎用性が低い技術を使い続けることになる システム開発と関連性が低い作業: 運用監視や単純なデータ入力など、エンジニアとしての成長につながりにくい業務 レガシーシステムの保守: 最新技術とはかけ離れた古いシステムの維持管理 人間関係の課題: プロジェクトのステークホルダーとのコミュニケーションがうまくいかなかったり、メンバーの技術スキルが低く、レビューやサポートに想定以上の工数を取られる いわゆる 「案件ガチャ」 と呼ばれる状況があり、良い案件に当たればスキルアップのチャンスになりますが、そうでない場合のリスクも無視できません。 上京してもスキルアップできる保証はなく、運次第という側面があるのが現実です。 地方のメリット 使用技術の汎用性 地方で仕事をする場合でも、技術スタック自体は必ずしも時代遅れではありません。 マイナーな技術ではなく、業界で広く使われているメジャーな技術を用いた開発が多いため、習得したスキルが汎用的に活かせるケースが少なくありません。 昔からあるJava、C#など需要の高いプログラミング言語 AWS、Azureなど広く普及しているクラウドサービス SQL Serverやpostgrresqlなど標準的なデータベース 取引先は都市部の企業 地方に拠点を置いていても、実際の取引先はほぼ東京・大阪などの都市部の企業になることが多いです。 地方に就職したからといって、仕事内容が大きく変わるわけではありません。 リモートワークやオンライン会議の普及により、物理的な距離のハンデはかつてより小さくなっています。 生活コストが安い 地方と東京では生活コストに大きな差があります。 項目 東京 地方(岡山など) 家賃(1K) 8〜12万円 4〜6万円 駐車場代 2〜5万円 3,000〜5,000円 物価全般 高い 比較的安い 年間で50万円以上の差が出ることも珍しくありません。

AIツール向けタスク管理ツール「Beads」入門

  • POST
はじめに この記事では、 AIコーディングエージェント向けのタスク管理ツール「Beads (bd)」を紹介します。 Claude Codeなどのエージェントにタスクを記憶させ、セッションをまたいだ作業管理を可能にするツールです。 beadsとは AIエージェントが使用することを前提に作られたタスク管理ツールです。 bdコマンドというCLIを使ってタスク管理ができます。 CLIでタスクを操作できることから、Claude Codeなどのバイブコーティングツールを使用する開発者から高評価を得ています。 GitHub - gastownhall/beads: Beads - A memory upgrade for your coding agent GitHub Issueなどとの違い プロジェクトのタスク管理というとGitHub Issueが古くから使われていますが、GitHub Issueとbeadsのメカニズムの違いや、beadsを使うメリットは以下の通りです。 依存関係の設定ができる このタスクを完了しないと次のタスクを実行できない、といった複雑な依存関係の設定が可能です。 DBとJSONLでタスク管理 DBファイルとjsonlファイルの2つを用いてタスクを管理します。 DBファイル上でタスクのステータス、優先度、説明などが記録されています。 軽量な内部DBにクエリを実行することで、エージェントは必要な情報のみを参照でき、コンテキストの肥大化を防げます。 DBへの変更はjsonlファイルにも同期され、人間にも読みやすい形式で表示されるため、Gitなどのバージョン管理ソフトで差分を確認できます。 ローカルのDBファイルを用いるので、クラウドを使わずオフラインでも動作します。 コマンドラインから操作できるので、AIエージェントからも操作が可能です。 エージェントにセッションをまたいだ情報を記憶させるrememberコマンドなど、エージェント向けの機能があります。 初回セットアップ # Windowsにbeadsをインストール irm https://raw.githubusercontent.com/gastownhall/beads/main/install.ps1 | iex ## 環境変数 Pathに以下のPathを設定 >> ==> bd installed to C:\Users\pocke\AppData\Local\Programs\bd\bd.

フリーランスエンジニアにおすすめの健康保険の選び方

  • POST
はじめに 会社員からフリーランスエンジニアとして独立すると、多くの方が驚くのが健康保険料の負担です。 会社員時代は給与から天引きされ、金額をあまり意識していなかった方でも、独立後に自分で保険料を計算・納付する立場になると、想像以上の金額に驚くケースが少なくありません。 特にフリーランスエンジニアは、案件の単価が比較的高く、所得が上がりやすい職種のため、国民健康保険料も高額になりがちです。 この記事では、フリーランスエンジニアが検討すべき健康保険の主な選択肢を整理し、それぞれのメリット・デメリット、保険料の考え方について解説します。 最終的な選択や保険料の具体的な試算については、お住まいの自治体窓口や社会保険労務士、税理士に確認することをおすすめします。 フリーランスエンジニアが健康保険で直面する課題 国民健康保険料が高くなる理由 会社員が加入する協会けんぽ等の健康保険は、保険料を会社と折半するため、個人の負担は所得の一定割合に抑えられています。 一方、独立後に多くの方が加入する**国民健康保険(国保)**は、原則として以下の要素で保険料が計算されます。 所得割: 前年の所得に応じて金額が上がる部分 均等割: 世帯の加入者数に応じてかかる定額部分 平等割: 世帯ごとにかかる定額部分(自治体によって有無が異なる) このうち所得割は、所得が増えるほど比例して保険料が上がっていく仕組みのため、独立して所得が伸びたフリーランスエンジニアほど、国保料の負担も重くなりやすいという特徴があります。 なお、国民健康保険には保険料の**上限額(賦課限度額)**が設定されており、青天井に上がり続けるわけではありません。ただし、上限額自体も年々見直されており、高所得層にとっては依然として大きな負担になりやすい制度です。 会社員時代との違い 会社員の健康保険と異なり、国民健康保険には以下のような特徴もあります。 保険料の労使折半がなく、全額自己負担 傷病手当金・出産手当金が原則として支給されない(自治体や制度改正状況によって例外あり) 前年所得をもとに保険料が決まるため、独立初年度は前職の給与所得がベースになることがある こうした違いを理解した上で、自分に合った健康保険の選択肢を検討することが重要です。 主な選択肢の比較 フリーランスエンジニアが検討できる健康保険の選択肢は、大きく**国民健康保険(国保)と社会保険(社保)**の2系統に分かれます。 さらに国保は「市区町村国保」と「国民健康保険組合」の2種類、社会保険は法人の役員・従業員になることで加入するため、フリーランスが社会保険につながるルートとして「任意継続」「マイクロ法人」「社保加入代行」の3通りがあります。 健康保険は大きく以下のように分類されます。 国民健康保険団体(国保) 市区町村国保 国民健康保険組合(同業者組合) 社会保険団体 (社保) 全国健康保険協会(協会けんぽ) 健康保険組合 (組合健保) 共済組合 社会保険加入方法 任意継続被保険者制度 マイクロ法人スキーム 社保加入代行・一般社団法人加入 国民健康保険(国保) 市区町村国保 最も一般的な選択肢で、独立後に手続きをしなければ自動的にこの制度の対象になります。 市町村ごと微妙に保険料が異なるため、保険料が安い市町村で開業することで微小ですが保険料を抑えることができます。 メリット 手続きが比較的シンプルで、市区町村の窓口で完結する デメリット

Azure SRE Agent のカスタムエージェント機能を解説

  • POST
はじめに Azure SRE Agent では、ユーザーが特定のタスクを実行するための特化したエージェントを、カスタムエージェントとして定義・作成することができます。 本記事では、カスタムエージェントの定義方法から実際の活用方法まで、詳しく解説します。 カスタムエージェントとは カスタムエージェントは、ユーザーが入力した特定のタスクを実行するために特化したエージェントです。 標準的なSREエージェントではカバーしきれない、特殊な役割や機能を必要とする場合に活用します。 カスタムエージェントの定義方法 カスタムエージェントは以下のようにYAML形式で定義できます。 name: database_expert system_prompt: |You are a database specialist. Analyze query performance, diagnose connection issues, and recommend optimizations. handoff_description: Handles SQL and database troubleshooting tools: - execute_kusto_query - azure_cli connectors: - azure_sql enable_skills: true # Can use skills for additional expertise 定義要素の説明 要素 説明 name カスタムエージェントの識別子 system_prompt カスタムエージェントの役割や動作を定義するプロンプト handoff_description オーケストレーターがこのカスタムエージェントにタスクを委任する判断基準となる説明文 tools カスタムエージェントが使用できるツール(azコマンド、外部APIなど) connectors 接続するAzure リソースやサービス enable_skills 有効にするとカスタムエージェントがスキルに動的にアクセス可能 重要な注意点 SRE エージェントのカスタムエージェントは、Claude Code のサブエージェントとは異なり、使用するモデルを指定することができません。

Azure SRE Agent のコネクターについて解説

  • POST
はじめに Azure SRE Agentは、Azure Monitorやログなどの監視データを活用してインシデント対応を支援するAIエージェントです。 その能力を最大限に引き出す鍵となるのが「コネクタ」機能です。 コネクタを設定することで、SREエージェントはAzure Monitor、Application Insights、Log Analyticsといった監視サービスや、GitHubリポジトリ、Teamsなどの外部サービスとシームレスに連携できるようになります。 本記事では、Azure SRE Agentのコネクタの概要、サポートされているサービス、導入するメリット、そしてApplication InsightsとLog Analyticsの違いについて解説します。 Azure SRE エージェントのコネクタ エージェントには、Azureサービスへの組み込みアクセスが用意されています。 コネクタは、外部サービスとSREエージェントを接続し、SREエージェントから外部サービスへのクエリの実行や、コードの読み取り、通知の送信を可能にします。 Azure公式ドキュメント: SREエージェントのコネクター サポートされているコネクタ Azure Monitor Application Insights Log Analytics Azure Resource Graph GitHubリポジトリ Teams カスタムAPI コネクタのメリット コネクタが設定されていない場合でも、SREエージェントは az コマンドが組み込まれているので、azコマンドを使ってApplication Insights、Log Analyticsなどへのクエリの検索は可能です。 敢えてコネクタを設定するメリットとしては、以下の点があります。 コネクタを使用するメリット: 毎回対象を指定しなくてもよい - 特定のLog AnalyticsワークスペースやApplication Insightsリソースをエージェントが継続的に認識 接続先のデータがコンテキストに入る - 接続先の監視データが前提知識として扱われやすくなり、調査時の文脈理解が速くなる 高度な診断がしやすくなる - 接続されたリソース全体をまたいだMCPベースの診断に使え、組み込みで提供されたToolsが使える コネクタは「単にクエリできるようにする」ためだけでなく、「どの監視データを常に見てよいかをエージェントに覚えさせ、継続的な診断能力を上げる」させることができます。 Application InsightsとLog Analyticsの違い Application Insightsで表示できるメトリクスはLog Analytics Workspacesに保存されます。 Log Analyticsだけでなく、Application Insightsを使うメリットとしてはLAWの情報を抽象化(アプリケーションマップなど機能)が使えるようになることです。

Azure SRE Agent のメモリ機能を解説

  • POST
はじめに Azure SRE Agent には、過去のインシデント対応やユーザーとのやり取りから学習した知識を蓄積し、次回以降の対応に活かす「メモリ」という仕組みがあります。 本記事では、メモリの種類や自動学習の仕組み、ユーザーメモリの操作方法、ナレッジベースとの違いについて解説します。 メモリ メモリとは過去のインシデントで何が機能していたかなど、エージェントに蓄積することができる知識情報です。 メモリの種類 情報源 発見内容 最適な用途 過去のインシデント 同様の問題を解決した手順 以前、どのようにこれを修正したのですか。 ユーザーメモリ 明示的に保存するファクト “私の環境設定が使用することを覚えておいてください…” ナレッジベース アップロードしたランブックとドキュメント “標準手順に従う” 自動学習 SREエージェントはユーザーとの会話から自動で学習し、メモリに記録します。 スレッドが更新されなくなってから30分後、エージェントは会話を評価し、学習のインデックスを作成します。 プロアクティブな知識の永続化 完了したスレッドから学習するだけでなく、エージェントは会話中に重要と判断した知識をナレッジファイルに保存します。 ナレッジファイルは memories/synthesizedKnowledge/ 配下に保存され、次回セッション開始時に自動読み込み、より賢い回答を生成します。 ナレッジファイルの種類 ファイル 内容 文字数上限 overview.md サービスの概要とインデックス 約2,000文字(常にコンテキストに読み込まれる) トピックファイル 特定の主題に関する詳細な注意事項(例: aks-networking-gotchas.md) 各1,000文字 team.md チームメンバー、役割、専門知識 最大500文字 architecture.

本当にあったSierの話「エンジニアの世間評価編」

  • POST
はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか? しかし、現実でには、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 エンジニアは「変わった人」と思われるケースが多い ハッカソンで出会った独特過ぎる発想 これは、生成AIを活用したバイブコーディングのハッカソンに参加した際の話です。 あるミドルエイジのエンジニアの方が、ハッカソンで提案したアプリについてこう話していました。 ミドルエンジニア🤪:「汚物を投げるアプリを作ろう💩」 思わず耳を疑うようなアイデアでした。 もちろんハッカソンでは、実用性よりも発想の面白さを重視したネタアプリが数多く生まれます。 しかし、そのアイデアは私にとってかなり常識離れしたものに感じられました。 周囲も苦笑いしていましたが、本人はまったく気にする様子がありません。 ミドルエンジニア😏:「面白いでしょ?」 むしろ自信満々に語っていたのが印象的でした。 エンジニアには、既成概念にとらわれず自由な発想をする人が少なくありません。 その創造性が革新的な技術を生み出す一方で、時には周囲から「変わった人」と見られることもあるようです。 異業種から見たエンジニアの印象 これは異業種交流会での話です。 交流会に参加していると、エンジニアに対する印象について話題になることがあります。 その際、営業職や事務職の方から次のような意見を聞くことがありました。 営業職の方😕:「エンジニアは少し話しかけづらいイメージがありますね」 事務職の方😣:「個性的な人が多い印象なので、最初は少し緊張します」 もちろん、これは一部の方の感想に過ぎません。 しかし、技術職に対して似たようなイメージを持つ人が一定数いることは感じました。 ある交流会で、私が参加者と普通に会話をしていたときのことです。 相手からこんなことを言われました。 交流会の相手😲:「あなた、エンジニアなんですか? エンジニアの割に話しやすいですね」 相手に悪気はなかったのでしょう。 しかし、この言葉からは「エンジニアはコミュニケーションが苦手」という先入観がうかがえます。 実際、技術的な話に熱中し過ぎたり、自分の専門分野の話ばかりしてしまったりするエンジニアは存在します。 私自身、そのような場面を見たことがあります。 ただし、それはエンジニア全体に当てはまる話ではありません。 コミュニケーション能力が高く、相手の立場に合わせて分かりやすく説明できるエンジニアも数多くいます。 それでも、一部の印象的な言動が目立つことで、「エンジニアは変わった人が多い」というイメージが生まれているのかもしれません。 まとめ 社会人だからといって全員が自立した大人というわけではありません。 先輩や上司をリスペクトすることは重要ですが、妄信するのは危険です。 先輩や上司のいいところは取り入れ、悪いところは反面教師として扱い、自立した社会人になりましょう。 本サイトへのご意見、お問い合わせなどありましたらこちらからご連絡下さい。 お問合せフォーム 関連記事 地方エンジニアにおすすめのフリーランスエージェント

本当にあったSierの話「エンジニアの知識レベル編」

  • POST
はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか? しかし、現実でには、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 意外と無知な人が多い Operatorの意味を知らないDevOpsエンジニア これは、DevOpsの導入支援を行っていたプロジェクトでの出来事です。 上司🤔:「運用者って英語で何て言うの?」 部下😐:「operatorです。」 上司😤:「なんか違うなー。actorにしよう!!」 部下😐:「????」 業界では一般的な英単語であるにもかかわらず、その意味を理解していない人がプロジェクトをマネジメントしているケースは少なくありません。 今回のケースでは、DevOpsプロジェクトに参画しているにもかかわらず、「Operator」という言葉の意味を理解していませんでした。 さらに厄介なのは、正しい表現を提示しても同じ間違いが繰り返されることです。 脳の仕組み的に、本人の中では独自の定義や解釈が形成してしまう方がいて、世の中で一般的に使われている意味とのズレを認識できていないケースがあるのです。 誰でも最初は知らないことがありますし、無知であること自体は何も問題ではありません。 しかし、自分の認識がずれている可能性に気付けなければ、学習や修正の機会を失ってしまいます。 実際に社会人として働いていると、「知らない人」よりも「間違って理解していることに気付いていない人」に遭遇することがあります。本人の中では筋が通っているため、自分が間違っているという感覚がありません。 そのため、正しい情報を示されても自分の解釈を優先してしまい、結果として同じ間違いを繰り返してしまうのです。 そして、そのような人が意思決定を行う立場にいると、プロジェクト全体が誤った方向に進んでしまうこともあります。 ピントがずれた指摘が多いレビュアー これは、あるシステムに関する社内向けスライド資料のレビューで起きた出来事です。 上司😤:「スライドタイトルの製品名に『TM』が付いていないじゃないか。ちゃんと表記しなさい。」 部下😐:「????」 TMは「Trade Mark」の略で、商標であることを示すための記号です。 しかし、ロゴを正式なブランド表記として利用しているわけでもなく、社内向けの説明資料において単純に製品名に言及するだけであれば、TM表記が必須となるケースはほとんどありません。 もちろん、表記ルールを確認すること自体は大切です。 しかし実際のレビューでは、本質的な内容よりも些末な部分にばかり注目し、ピントがずれた指摘が繰り返されることがあります。 悪意があるわけではないだと思いますが、意味の薄い指摘への対応に時間を取られることで、本来議論すべき内容が後回しになってしまうケースは少なくありません。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

本当にあったSierの話「エンジニアの金銭感覚編」

  • POST
はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか? しかし、現実でには、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 金銭感覚が疎い人が多い 借金を自慢するピエロエンジニア これはある40代のエンジニアの方の友人との金銭トラブルの話です。 ご本人はコミュニティと称して、ジモティーでカフェ会などを開いているそうです。 その方はカフェ会で以下のような発言をしたそうです。 40代エンジニアさん😎:「友人が困っているから20万円貸したけど返ってこなかったことあるよ(キリッ)」 エンジニアA😳:「えっ、20万円も!?」 40代エンジニアさん😏:「自己投資(人生経験)だったと思ってるよ(ドヤ~)」 エンジニアA😳:「….(何で自信満々なんだ。。。)」 大金を人に貸すのはよくない、お金を返さないような人は友人ではない、小学生でも分かることですよね。 小学生でも知っていることを理解したことを自慢話のように語っているのです。 そのエンジニアの方はコミュニティと称してやっていることもハッカソンやアイデアソンなどではなく、 小規模なカフェ会やボードゲーム会で学生さんでもできるような大したことではなく、年齢に相応しい行動とは思えないですが、主催して人を集めている自分に酔ってしまい、客観的な分析ができなくなっているようです。 周囲からも自己分析ができないピエロエンジニアとして疎まれているみたいです。 SNSでのビジネスロマンス詐欺被害 これはあるベテランエンジニアがSNSを通じて知り合った外国企業に金を騙し取られた話です。 「取引相手」と思っていた相手は、実は詐欺グループでした。 最初は数千円。その後、何度か追加投資を促され、最終的には50万円を失ったそうです。 驚くべきは、そのことを話したときの彼の態度です。 エンジニアA😳:「えっ、50万円も!?」 ベテランエンジニア😳:「まあ、勉強代みたいなもんだから。」 エンジニアA😳:「変だと思わなかったんですか?」 ベテランエンジニア😳:「外国との取引なので、そういうものかと思ってた。」 エンジニアA😳:「….(リアクション薄いな。。。)」 50万円という大金を失ったにもかかわらず、怒ることも悔やむこともなく、「勉強代」という言葉で片付けているのです。 一人暮らしでお金を必要としない生活を続けていて、金銭感覚がづれてしまった例の一つと言えるかもしれません。 青色申告を使わないエンジニアが意外と多い これは副業やフリーランスで働くエンジニアの確定申告の話です。 知人のエンジニア🙄:「白色申告でいいよ、青色申告は面倒くさいから」 そう言って、経費がまったく計上できない白色申告を選ぶエンジニアって意外と多いんです。 青色申告を使うだけで、数十万円単位で損をしているのです。 関連記事 地方エンジニアにおすすめのフリーランスエージェント