秋田県でデジタルキャリアをスタート!「秋田デジタルアカデミー」エントリー受付中

  • POST
はじめに 地方でのキャリア形成において、デジタルスキルの習得は大きな武器になります。秋田県では、地元でデジタル分野のキャリアをスタートさせたい人に向けたプログラム「秋田デジタルアカデミー」のエントリーを受け付けています。 地方在住のまま新しいキャリアに挑戦したいと考えている方は、この機会にチェックしてみてください。 「秋田デジタルアカデミー」とは 秋田県でデジタルキャリアをスタートするための取り組みです。プログラムの詳細な内容やカリキュラム、対象者の条件などについては、公式サイトで案内されていますので、興味のある方はそちらをご確認ください。 エントリー受付期限 エントリー受付期限は 2026年9月23日(水) までです。参加を検討している方は、期限に余裕を持って申し込み手続きを進めましょう。 公式サイトはこちら 詳細情報やお申し込みは、以下の公式サイトからご確認ください。 秋田デジタルアカデミー公式サイト まとめ 地方在住のままデジタル分野のキャリアを築きたいと考えている方にとって、「秋田デジタルアカデミー」は新しい一歩を踏み出すきっかけになるかもしれません。エントリー受付期限が近づいていますので、興味のある方は早めに公式サイトをチェックしてみてください。

Azure SRE Agent の Live Reports を解説

  • POST
はじめに Azure SRE Agent に、チャットから作成できる保存・共有可能な運用画面「Live Reports」が Public Preview として追加されました。 本記事では、Live Reports の概要、提供状況、活用メリット、利用時の留意事項について解説します。 Live Reports とは 発表日: 2026年8月25日 提供状況: Public Preview Live Reports は、Azure SRE Agent とのチャットから作成できる、保存・共有可能な運用画面です。 利用者が必要な情報を自然言語で説明すると、Agent が chart、table、diagram、status indicator を含む report を作成します。一度作成した report はレイアウトを維持し、開くたびに connector から最新データを取得します。 利用例 serviceのエラー率やlatencyを確認する朝会用dashboard deploymentの成功率と失敗一覧 未解決incidentと担当者の一覧 Kustoの運用データを用いたservice trend compliance、capacity、costの定期確認 on-callの引き継ぎ画面 何が嬉しいか 毎日同じpromptを入力したり、複数のdashboardを開いたりする作業を減らせます。 reportの形が固定されるため、日ごとの数値を同じ視点で比較できます。 connector toolのみで更新するreportは、表示のたびにactive-flow AAUを消費しません。 link共有により、同じAgentへのアクセス権を持つチームメンバーが共通の運用画面を利用できます。 sanitized static HTMLとして出力し、postmortemなどの記録へ添付できます。 report上のbuttonから、incidentの更新やworkflowの開始など、許可されたtool actionを実行できます。 留意事項 reportはsandboxed iframeで実行され、session tokenやcookieへアクセスできません。 reportが呼び出せるのは、保存時に承認されたconnector toolに限定されます。 linkの共有だけではアクセス権は付与されません。閲覧者にも対象Agentのロールが必要です。 reportの作成・変更はactive-flow AAUを消費します。 model-assisted analysisを設定した場合、reportを更新するたびにmodel利用分のactive-flow AAUが発生します。 Previewでは、生成HTMLは10 MB以下です。 cross-tenant userは、approvalが必要なreport actionを承認できません。 model-assisted sectionにreport単位またはuser単位のAAU budgetはありません。 おわりに Live Reports は、Azure SRE Agent とのやり取りをそのまま日々使える運用画面に変換できる機能です。

Claude Codeを使うのにおすすめのWindowsターミナル「Warp」を紹介

  • POST
はじめに Claude CodeはCLI(コマンドライン)ベースのツールのため、どのターミナルを使うかによって開発体験が大きく変わります。 本記事では、Windows環境でClaude Codeを使う際におすすめのターミナルとして、Warpをご紹介します。 結論から言うと、Warpは「コマンドと出力をブロック単位で管理できる」「入力補完が強力」という特徴を持つモダンなターミナルで、Claude Codeを日常的に使うWindows開発者にとって作業効率を上げてくれるツールです。 Warpは2022年に登場した、Rust製のターミナルエミュレーターで、従来のターミナルにはない独自の機能が多く搭載されています。以下、具体的な特徴とインストール方法、Claude Codeとの組み合わせ方を紹介します。 Warpとは WarpはエディタやAI機能なども備えた多機能のターミナルです。 Warpを使うことで、開発者は以下のような恩恵を受けることができます。 ブロック機能 Warpは、コマンドと出力を「ブロック」という単位で区切って表示してくれるのが最大の特徴のターミナルです。 Powershellなどの標準のターミナルではコマンドと出力がすべてまとまって画面上に出力されるため、コマンドや出力が長くなると見づらいという欠点がありました。 Warpでは1つ1つの実行結果がブロックとしてまとめて表示されるため、コマンドに紐付く実行結果について迷う必要がなくなります。 # PowerShell PS> git status On branch main nothing to commit, working tree clean PS> npm test ✓ 124 tests passed PS> docker ps CONTAINER ID IMAGE STATUS a1b2c3d4 app Up 2h ---------------------------------------------- ↑ 複数のコマンドと出力がまとめて出力されるので見づらい ---------------------------------------------- # Warp ┌─ Block #1 ─────────────────────┐ │ $ git status │ ├────────────────────────────────┤ │ On branch main │ │ nothing to commit, working │ │ tree clean │ └────────────────────────────────┘ ┌─ Block #2 ─────────────────────┐ │ $ npm test │ ├────────────────────────────────┤ │ ✓ 124 tests passed │ └────────────────────────────────┘ ┌─ Block #3 ─────────────────────┐ │ $ docker ps │ ├────────────────────────────────┤ │ CONTAINER ID IMAGE STATUS │ │ a1b2c3d4 app Up 2h │ └────────────────────────────────┘ ------------------------------------------------- ↑ コマンドと出力が「ブロック」でまとまっているので見やすい ------------------------------------------------- ブロック単位で管理されているため、以下のような操作が可能です。

地方在住エンジニアがフルリモート案件で働くときの注意点

  • POST
はじめに 地方在住のエンジニアにとって、「フルリモート可」と書かれた求人は非常に魅力的に映ります。しかし実際に働き始めてから、「月1回は出社が必要だった」「勤務地は東京本社のまま扱われていた」といったギャップに直面するケースは少なくありません。 この記事では、地方在住エンジニアがフルリモート案件を探す・実際に働く際に注意しておきたいポイントを、求人票の見方から入社後の働き方までまとめて紹介します。 注意点1: 求人票の「フルリモート」表記のワナ 求人票に「フルリモート」「リモートワーク可」と書かれていても、実態は様々です。契約時に想定と異なっていた、というトラブルを避けるために、以下のような表記の違いに注意しましょう。 「原則フルリモート」:緊急時や研修時など、一定の条件下で出社を求められることがある表現 「リモートワーク可」:出社とリモートを選択できるだけで、フルリモートを保証する表現ではない 「一部リモート」「週◯日リモート」:定期的な出社が前提になっている 勤務地欄が「東京都」などになっている:実際の業務はリモートでも、雇用契約上の勤務地は本社所在地のままというケースがある 「フルリモート」という言葉だけで判断せず、募集要項の勤務条件・勤務地欄まで必ず目を通すことが重要です。 注意点2: 出社頻度の実態を面接で確認する 求人票の記載だけでは実際の出社頻度がわからないことも多いため、選考段階で具体的に確認しておくことをおすすめします。 過去1年間で、実際にリモートメンバーが出社した頻度・理由 出社が必要になる場合の交通費・宿泊費の支給有無 チームメンバーの居住地(全国に散らばっているか、首都圏在住者が多いか) 緊急時(障害対応・重要な意思決定など)の出社要請の有無 特に「チームメンバーの居住地」は、その企業が本当にフルリモート運用に慣れているかどうかを判断する材料になります。首都圏在住者ばかりのチームでは、地方在住者だけが不利な扱いを受けるリスクもあるため注意が必要です。 注意点3: 面接で聞くべき質問リスト 選考時に遠慮せず確認しておきたい質問をまとめました。 「入社後、出社が必要になるのはどのようなタイミングですか?」 「現在リモートで働いている方は、どのくらいの頻度で出社していますか?」 「評価制度は勤務地に関わらず公平に運用されていますか?」 「コミュニケーションは主にどのツール・どのくらいの頻度で行われますか?」 「機材の貸与や通信費の補助はありますか?」 これらの質問に対して具体的な回答が返ってこない、あるいは曖昧にはぐらかされる場合は、実態としてリモートワーク運用が整っていない可能性があるため注意しましょう。 注意点4: 入社後に発生しやすいギャップ 実際に働き始めてから顕在化しやすい問題として、以下のようなものが挙げられます。 評価面でのギャップ:オフィス出社組が評価されやすく、リモート組が昇進・昇給で不利になる「プロキシミティ・バイアス」 情報格差:雑談や廊下での会話から生まれる情報がリモートには共有されにくい 孤立感:チームとの心理的な距離を感じやすく、モチベーション維持が難しくなる 通信トラブル時の対応:自宅の回線トラブルが直接業務に影響するため、通信環境の整備が必須(詳しくはこちらの記事も参照) これらは入社前には見えにくいため、口コミサイトやカジュアル面談などを活用して、実際に働いている社員の声を集めておくことが有効です。 注意点5: フルリモート求人自体が減少傾向にある 近年は、これまでフルリモートを掲げていた企業が方針を転換し、出社を前提とした働き方に戻すケースも増えてきました。「出社は絶対にしない」という姿勢のままでは、応募できる求人の選択肢が狭まってしまうかもしれません。 今後は、完全リモートにこだわりすぎず、リモートと出社を組み合わせたハイブリッドワークにも対応できる柔軟さが求められそうです。その対応策の一つとして、東京まで日帰りや短時間で行き来できる関東圏に住むという選択肢も検討する価値があります。地方在住のメリットを活かしつつ、月数回の出社にも無理なく対応できる立地を選ぶことで、求人の選択肢を広げることができます。 まとめ フルリモート案件を探す際は、求人票の表記を鵜呑みにせず、以下のポイントを事前に確認しておくことがトラブル回避につながります。 求人票の「フルリモート」表記の実態(勤務地欄・出社条件)を確認する 面接で出社頻度やチームの居住地分布を具体的に聞く 評価制度やコミュニケーション方法など、入社後のギャップになりやすい点を質問しておく 自宅の通信環境など、リモートワークの土台となるインフラも事前に整えておく 地方在住だからこそ、フルリモート案件は大きなチャンスになる一方、実態を確認せずに飛びつくとミスマッチのリスクも高くなります。事前の確認を徹底し、納得のいく形でリモートワークを始めましょう。 関連記事 地方でリモートワークするならどの回線がおすすめ?光回線・WISP・Starlink・テザリングを徹底比較

本当にあった?エンジニアの怖い話「Teams会議での殺害予告」

  • POST
はじめに システム開発の現場では、進捗が思わしくない部下に対して上司が厳しい言葉をかける場面は珍しくありません。 しかし、それが「暴言」の域を超えてしまうケースも、残念ながら実際に存在します。 この記事では、大手SIerで実際にあった、Teams会議上でのハラスメント発言のエピソードを紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 「Teams会議での殺害予告」 これは某大手SIerが元請けを務める、大規模システム開発プロジェクトでの出来事。 このプロジェクトには、元請けの大手SIerに加え、ビジネスパートナー(BP)として参画する複数の協力会社が名を連ねていた。 週次の進捗会議はTeamsを使ったオンライン形式で行われ、画面には元請け・BP各社の担当者がずらりと並んでいた。 部下Cは、この会議に参加していたエンジニアの一人だった。 以前から担当タスクの進捗が思わしくなく、直近の会議でも上司Dから厳しい指摘を受けていた。 会議が始まり、進捗報告の順番が回ってくる。 上司D 😑「C、先週指摘した件、対応できたのか?」 部下C 😰「すみません、まだ調査中でして……」 上司Dの表情が険しくなる。 上司D 😠「前回も同じこと言ってたよな。何回目だよ、これ。」 部下C 😨「申し訳ございません……」 質問への回答も要領を得ず、要点がまとまらない部下Cに対し、上司Dの苛立ちは徐々に大きくなっていった。 上司D 😡「だから、原因は何なんだよ。結論から言えよ。」 部下C 😖「えっと……その、まだ切り分けが……」 要領を得ない回答が続く中、画面の向こうにいる他社の参加者たちも、次第に空気の重さを感じ始めていた。そしてついに、上司Dの怒りが爆発する。 上司D 😤「いい加減にしろよ!コ〇スぞー!!」 会議に参加していた全員が、一瞬何が起きたのか理解できずに固まった。 BP担当者E 😳(……今、なんて言った?) BP担当者F 😧(聞き間違いだよな……?) しかし、それは聞き間違いではなかった。上司Dは、部下Cの度重なる要領の悪い回答に業を煮やし、画面越しに他社の担当者も多数参加する公の場で、明確な暴言を吐いたのだった。 部下C 😱「……」 部下Cは言葉を失い、他の参加者たちも誰一人フォローの言葉を発することができなかった。 会議室には、しばらく重苦しい沈黙だけが流れた。 令和のこの時代に、しかも社外の関係者が多数同席するオンライン会議の場で、このような発言が飛び出したことに、参加者全員がドン引きしたのは言うまでもない。 解説 令和になってから労働環境の改善は大幅に進み、今回のような露骨なハラスメントは以前に比べて少なくなってきました。 それでも、まれにこうした暴言を吐いてしまう方が存在します。 そして厄介なことに、その場に居合わせても、当然のように誰も彼を諫める人はいません。 大手企業に勤め、高年収で安定した立場にありながら退職を選ぶ方がいるのは、こうしたハラスメントの存在も一因なのかもしれません。 一方で、性分的に熱くなるとつい汚い言葉を使ってしまう人はどこにでもいるのも事実です。 罵声を言葉通りに真正面から受け止めて思い悩むのではなく、「夏になったらセミが鳴くようなものだ」くらいに捉え、いちいち気にしないというメンタリティを持つことも、必要なのかもしれません。 とはいえ、それでもどうしても理不尽な環境に耐えられないという方は、無理をする必要はありません。 退職や独立も、有効な選択肢の一つです。 おわりに 世の中には、様々な企業やそこで働く人が存在し、常識では考えられないような出来事が実際に起こり得ます。

2026年10月からインボイス経過措置が変更。フリーランスエージェントの対応方針から見るSE・フリーランスへの影響

  • POST
はじめに 2023年10月のインボイス制度開始以降、免税事業者(インボイス未登録の事業者)からの仕入れについては、一定期間の経過措置が設けられています。 この経過措置の控除率が、2026年10月から段階的に引き下げられることをご存じでしょうか。 これに伴い、フリーランスエンジニア向けエージェントのギークスが、免税事業者パートナーへの消費税相当額の補填方針を見直すことを発表しました。 本記事では、経過措置の制度変更の内容と、ギークスの対応方針を例に、フリーランスSEが受ける実務上の影響を整理します。 インボイス経過措置とは インボイス制度では、適格請求書発行事業者(インボイス発行事業者)でない免税事業者からの仕入れは、原則として仕入税額控除の対象になりません。 ただし、制度導入による急激な負担増を緩和するため、以下のような経過措置が設けられています。 期間 免税事業者からの仕入れに対する控除率 2023年10月〜2026年9月 80% 2026年10月〜2028年9月 70% 2028年10月〜2030年9月 50% 2030年10月〜2031年9月 30% 2031年10月〜 0% 発注側企業が免税事業者に支払った消費税相当額のうち、控除できる割合が段階的に引き下げられます。 これにより、発注側企業が実質的に負担する消費税額(控除できない分)が増えることになります。 ギークスの対応方針 ギークスはこれまで、免税事業者であるフリーランスパートナーに対し、本来控除できない消費税相当分を特別措置として全額補填してきました。 しかし今回の経過措置変更を受けて、以下の方針転換を発表しています。 対象: 適格請求書発行事業者の登録をしていない(免税事業者の)パートナー 変更内容: 仕入税額控除が制限される分(消費税相当額の30%)を差し引いた金額で支払い 適用開始: 2026年10月稼働分(11月支払い分)から ギークスはこの見直しについて「他社を含めた市場の標準的な精算ルールに準拠するため」としており、制度上の経過措置の段階的移行に合わせた対応であると説明しています。 参考資料: インボイス制度の改正について(国税庁) 単価50万円の場合の計算例 実際にどの程度の減額になるのか、単価50万円(税抜)のケースで試算してみます。 項目 金額 元の税抜単価 500,000円 元の税込金額 550,000円 控除できない消費税の30%分 15,000円 調整後の税抜金額 485,000円 調整後の消費税(10%) 48,500円 調整後の税込金額(振込額) 533,500円 このケースでは、月額16,500円の実質減額となります。 単価が上がるほど減額幅も大きくなるため、高単価案件を扱う免税事業者ほど影響が大きくなる点に注意が必要です。

リモートワーク×地方移住は最大100万円もらえる?移住支援金の仕組みと注意点

  • POST
はじめに フルリモートで働けるようになったエンジニアの中には、「家賃の安い地方に移住して、今の仕事はそのまま続けたい」と考える人が増えています。 そんな移住を後押ししてくれる制度が、国と自治体が連携して実施している 「地方創生移住支援事業(移住支援金)」 です。 条件を満たせば、単身でも最大60万円、世帯であれば最大100万円の支援金を受け取れる可能性があります。 この記事では、リモートワークで地方移住を検討しているエンジニア向けに、移住支援金の仕組みと申請時の注意点を解説します。 なぜ今、地方移住者が増えているのか 移住者増加の背景にあるのは、「家賃が安く、それでいて東京へのアクセスが良い」地域への人気の高まりです。 フルリモートであれば通勤の必要がないため、家賃相場の高い東京23区にこだわる理由が薄れます。 一方で、出社が必要な場面や実家・知人との行き来を考えると、東京から近い地域の方が何かと安心という声も多く、「家賃は下げたいが、東京から離れすぎたくない」というニーズが移住先選びに強く反映されています。 移住希望地ランキングトップ3 公益社団法人ふるさと回帰・移住交流推進機構の調査によると、移住希望地ランキングの上位は以下の通りです。 順位 都道府県 1位 群馬県 2位 栃木県 3位 長野県 出典: ふるさと回帰・移住交流推進機構 いずれも東京圏からのアクセスが比較的良く、家賃水準は東京23区に比べて大きく抑えられるエリアです。 移住支援金の対象地域に含まれる自治体も多いため、リモートワークを継続しながらの移住先候補として検討しやすいのも人気の理由です。 移住支援金とは 移住支援金は、東京圏(東京23区在住、または東京23区に通勤していた人)から地方へ移住し、一定の条件を満たした場合に支給される国の制度です。実際の窓口や上乗せ額は都道府県・市町村ごとに異なります。 支給額の目安 世帯区分 支給額の目安 単身 最大60万円 世帯(2人以上) 最大100万円 18歳未満の子どもを帯同 子ども1人あたり最大100万円加算 自治体によっては独自の上乗せ加算を行っている場合もあるため、移住先候補の自治体サイトで最新の金額を確認しましょう。 【例】ランキング1位・群馬県の移住支援制度 移住希望地ランキング1位の群馬県では、移住支援金に加えて独自の支援制度も用意されています。ここでは、群馬県への移住を例に、単身世帯でも使えるものと家族がいる世帯向けのものに分けて紹介します。 単身世帯でも使える支援 移住支援金:東京23区からの移住・テレワーク継続などの条件を満たせば単身でも最大60万円 住宅取得・改修に関する補助:市町村によっては単身者も対象とする空き家改修補助や家賃補助制度がある 家族がいる世帯向けの支援 移住支援金(世帯加算):世帯での移住は最大100万円、18歳未満の子ども帯同でさらに加算 子育て世帯向け住宅支援:多子世帯やU・Iターン世帯を対象にした住宅取得補助 保育・教育関連の助成:市町村独自の保育料減免、給食費補助などを併用できる場合がある いずれの制度も移住先の市町村ごとに詳細や申請窓口が異なるため、群馬県内での移住先を検討する際は、候補となる市町村の移住相談窓口で最新の支援内容を確認することをおすすめします。

本当にあった?エンジニアの怖い話「エンジニアに聞いた中小SIerの職場あるある」

  • POST
はじめに システムインテグレーター(SIer)といっても、その規模や社風は会社によって大きく異なります。 特に中小規模のSIerでは、独自の職場文化や人間関係が形成されやすく、外から見ると驚くようなルールや雰囲気が存在することも珍しくありません。 この記事では、業界の人からヒアリングした、中小Sierの職場で見られがちな「あるある」を紹介します。 中小Sierの職場あるある 職場でのコミュニケーションが少ない 中小Sierの現場では、開発業務中は驚くほど静かなオフィスも珍しくありません。 雑談もほとんどなく、社員同士が黙々とキーボードを打ち続けているだけ、という職場も存在します。 コミュニケーションが少ないこと自体が悪いわけではありませんが、困ったときに相談しづらい雰囲気を生んでしまっているケースもあります。 陰湿な人間関係と飲み会での愚痴 普段のオフィスは静かでも、飲み会になると一転、陰口や愚痴を延々と聞かされることがあるという声も聞かれます。 システム開発をしている会社は、男女問わず、サバサバした性格というよりは、陰湿な一面を持つ社員が多く、仕事へのストレスが多いことが要因と言われています。 女性社員の少なさとキャラクターの違いによる確執 中小Sierでは女性社員の比率が低く、多くても3割程度、新卒女性採用が0人という年も珍しくないという企業もあります。 また、技術系の女性社員と総務系の女性社員とではキャラクターが大きく異なり、その違いから微妙な人間関係や確執が生まれることもあるようです。 独自の食事ルール 企業によっては、休憩時間以外の飲食を禁止していたり、飲食スペース以外での飲食を一切認めていなかったりと、独自のルールを設けているところもあります。 中には、蓋つきの飲み物のみデスクでの飲用を許可するという細かいルールを敷いている企業もあるようです。 解説 こうした「あるある」に共通しているのは、いずれも会社ごとの独自ルールや社風によって生まれているという点です。 静かなオフィス環境や独自の食事ルールは、一定のマナーや集中環境を保つという意図があるのかもしれませんが、行き過ぎると閉塞感やストレスの原因になりかねません。 また、女性社員比率の偏りやそこから生まれる人間関係の確執は、職場の多様性やダイバーシティへの取り組みが不十分な会社ほど起こりやすい傾向にあります。 こうした環境で働き続けることが自分に合っているかどうかは、入社前や転職前によく見極めておく必要があります。 おわりに 世の中には、様々な社風・ルール・人間関係を持つ企業が存在し、実際に働いてみないと分からないことも多くあります。 もし今の職場の閉塞感や独自ルールにストレスを感じているなら、転職やフリーランスとして独立するなど、環境を変えることも選択肢の一つです。 自分に合った働き方ができる環境を探すことは、長期的なキャリアにとって重要な選択になるはずです。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

本当にあった?エンジニアの怖い話「Operatorの意味を知らないDevOpsエンジニア」

  • POST
はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか? しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 Operatorの意味を知らないDevOpsエンジニア これは富士通の下請けの仕事をしているとある岡山県のシステム会社の話です。DevOpsの導入支援を行っていたプロジェクトでの出来事です。 上司🤔:「運用者って英語で何て言うの?」 部下😐:「operatorです。」 上司😤:「なんか違うなー。actorにしよう!!」 部下😐:「????」 解説 業界ではリテラシーが低い人がプロジェクトをマネジメントしているケースは少なくありません。 誰でも最初は知らないことがありますし、無知であること自体は仕方ないのかもしれません。 しかしながら、今回のケースでは、DevOpsプロジェクトに参画しているにもかかわらず、「Operator」という言葉の意味を理解していませんでした。 参画が決まった段階で普通はDevOpsの意味を調べているはずですが、それを調べていないことから、仕事への意識の低さが伺えます。 さらに厄介な問題は、正解を教えても間違った理解をしてしまう方がいることです。 脳の仕組み的に、本人の中では独自の定義や解釈が形成してしまう方がいて、世の中で一般的に使われている意味と異なる定義で理解してしまっているケースがあります。 そして、そのような人が意思決定を行う立場にいると、プロジェクト全体が誤った方向に進んでしまうこともあります。 おわりに アサインされる案件は「案件ガチャ」と呼ばれ、リテラシーが低過ぎる人がマネジメントしてるチームにアサインされることもあります。 自身の力でもがくことも大事ですが、中々環境は変わりません。 フリーランスになって、環境を変えるのも選択の一つかもしれません。 関連記事 地方エンジニアにおすすめのフリーランスエージェント