はじめに 仕事では「言われたことをそのまま実行したのに怒られる」という理不尽な出来事が起こることがあります。 この物語では、曖昧な指示と認識の食い違いが、どのように職場のトラブルを生むのかを描きます。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「自分が言ったことを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の怒りは収まらなかった。

はじめに 「なぜ中小企業ではスキルが伸びないのか」—— 転職や異動を経験した人なら、この疑問を感じたことがあるかもしれません。 大企業と比べて研修制度が整っていない、という指摘はよくあります。しかしそれだけではなく、組織文化や個人の習慣レベルに深い根本原因が存在します。 表面的な「研修がない」「予算がない」という理由の背後には、目標設定能力の欠如、学習に対する姿勢の問題、そして日常的な生活習慣まで、複合的な要因が絡み合っています。これらは一朝一夕には解決できず、組織全体の文化として根付いているケースがほとんどです。 本記事では、実際の現場で起きた事例をもとに、中小企業でスキルアップが進まないの理由を解説します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 1. 目標設定と達成プロセスが機能しない 中小企業だとメンバーの論理的思考力や語彙力に長けた社員が少ないため、目標設定自体ができないケースが多々あります。 以下の例では、目標設定メソッドにマンダラチャートを採用しましたが、社員のスキルの低さから、目標設定ができずに終わってしまったようです。 本当にあった?エンジニアの怖い話「マンダラチャートで目標すら立てられない会社のPDCA」 —— 論理的思考力の弱さから目標設定そのものが機能しなかった事例 目標を立てる能力が弱い組織では、スキル向上の仕組みそのものが成立しません。 論理的思考力がなければ「何を・いつまでに・どうやって」という構造で考えられないため、計画は絵に描いた餅になります。 目標を設定すること自体にもスキルが必要で、適切な目標設定をできない組織にいる限り、成長は難しいのではないかと思います。 目標設定に時間がかかり過ぎる 本当にあった?エンジニアの怖い話「目標設定に四半期の約1/4を消費する会社」 —— 目標設定の仕組みが整っておらず、議論だけで大量の時間を消費した事例 目標設定のノウハウが組織に蓄積されていないと、毎回ゼロから議論を始めることになり、肝心の実行期間そのものが削られてしまいます。 さらに厄介なのは、「時間をかけた＝真剣に取り組んだ」という誤った達成感で終わってしまい、プロセス自体の非効率さが問題として認識されにくい点です。 目標設定に時間がかかること自体は個人の努力不足ではなく、仕組みが整っていない組織のサインであり、そうした環境ではスキルアップに使うべき時間がそもそも確保できません。 自分本位の考えを重視し、教科書通りの学習をしない 本当にあった?エンジニアの怖い話「勤怠ソフトのボタンをてんとう虫にする会社」 「経験」や「勘」に頼って仕事を進める文化では、教科書的な手法が「理屈っぽい」「現場をわかっていない」と軽視されがちです。 しかしこの文化のもとでは正しい方法論を学ぶ動機自体が生まれず、再現性のあるスキルが身につきません。 感覚的な判断は個人の経験に強く依存するため、他のメンバーへの知識移転もできず、組織として学習が積み上がっていかないのです。 技術への興味が薄く、知識が広がらない 事例 これは、複数の物理サーバーを管理するプロジェクトの事例です。 あるプロジェクトで、複数のサーバーに対して同時にコマンドを実行できるSSHクライアント「Rlogin」を選定・採用しました。 このRloginを使うことで、同じ作業を各サーバーに個別に実施する手間が大幅に削減でき、ヒューマンエラーのリスクも低減できます。 導入した担当者は事前に動作検証を行い、Rloginがプロジェクトの要件にも合致していることを確認した上での採用でした。 ところが、このツールをプロジェクトで展開しようとしたとき、ベテラン社員から思わぬ反発を受けました。 「Teraterm以外のツールは聞いたことがない。有名なツールではない。」 という理由だけで、「基礎を無視したやり方だ」「なぜ実績のあるツールを使わないのか」と担当者に対して批判的な意見が述べられました。 ツールの選定基準として本来評価すべきは、プロジェクトとの適合性のはずです。　しかし実際には、「自分が知っているかどうか」が唯一の判断基準になっていました。 結果として、このツールの採用は見送られ、効率の悪い従来の手作業が継続されました。 理由 ツールの知名度や自分の馴染みで技術を評価する文化が存在すると、合理的な判断ができなくなります。 この姿勢の根本には、技術への好奇心の欠如があります。 「知らないものは怖い」「今のやり方で困っていない」という意識が強いと、新しい技術や手法を積極的に学ぼうとする動機が生まれません。その結果、知識が特定の範囲に固定されたまま広がらず、技術の進化に取り残されていきます。 また、このような文化では新しい提案をした人が「基礎がわかっていない」と逆に批判されるため、若手エンジニアの学習意欲を削ぐ効果もあります。 知識を広げようとする行動がリスクになる組織では、現状維持が最も合理的な選択になってしまいます。 2. 学習を阻害する生活習慣 事例 これは、特定の1社ではなく、複数の中小企業で共通して見られた傾向をまとめた事例です。 スキルアップには継続的な努力が必要です。しかし、日常の生活習慣がその継続を根本から阻害しているケースが少なくありません。 具体的には、 業務後にパチンコや競馬などのギャンブルを日課にしている 喫煙の頻度が非常に高く、就業中も離席が多い 飲酒量が多く、翌朝に疲労が残った状態で出勤する スマートフォンのSNSやゲームに長時間費やしている といった習慣を持つ人が、複数の中小企業の現場で一定数見られました。 こうした習慣が日常化している人ほど、 資格の勉強を始めても数日で挫折する 「勉強しようと思っていたが、気づいたら夜になっていた」を繰り返す 仕事中の集中力が続かず、同じ作業に時間がかかる という傾向が見られ、長期的なスキル形成に至りませんでした。

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

はじめに この記事では、 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.

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

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

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

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 意外と無知な人が多い エンジニアとして働く中で、意外な部分で知識が抜けている人に遭遇することがあります。 以下の記事では、実際にあった知識レベルにまつわるエピソードをそれぞれ個別に紹介しています。 Operatorの意味を知らないDevOpsエンジニア ピントがずれた指摘が多いレビュアー 関連記事 地方エンジニアにおすすめのフリーランスエージェント