はじめに 「フリーアドレス」は、席を固定せず、その日の気分や業務内容で自由に座る席を選べる、自由で柔軟な働き方のはずでした。 しかし現場では、「自由」とは名ばかりの不自由さを感じている人が少なくありません。 この物語では、導入目的が曖昧なまま始まったフリーアドレスが、職場にどんな歪みを生むのかを描きます。 「自由なはずなのに、席が足りない・座れない・誰がどこにいるか分からない」 これは関東にある、従業員300名ほどのシステム開発会社での出来事。 コロナ禍を機にリモートワークが定着したことで、会社は「オフィスコスト削減」と「コミュニケーション活性化」を掲げ、全社でフリーアドレスを導入した。 出社率は5割程度と想定され、席数は全社員の6割に削減された。 導入時の説明会では、次のような話があった。 総務 😄 「これからは部署の垣根を越えて、自由に交流できる職場になります！」 社員一同 🤔 「（で、結局なんのために導入するんだろう……？）」 コスト削減なのか、交流促進なのか、働き方改革なのか。 会社の説明は日によって微妙に変わり、結局誰も本当の目的を説明できないまま運用が始まった。 朝の疲労 導入から数日後の朝。 中途入社2年目のAさんは、始業の15分前にオフィスへ到着した。 Aさん 😪 「今日はどこに座ろう……。」 通勤で既に疲れているのに、席探しが始まる。 窓際は日差しがまぶしい。 壁際は落ち着くが、もう埋まっている。 モニター付きの席は、当然ながら全滅だ。 Aさん 🤔 「ここ空いてるかな……。荷物は置いてないけど、誰か使うのかな？」 Aさん 😅 「（近くの人に聞くのも気まずいな……。）」 結局、10分かけて席を決め、PCをセットアップする頃にはもう始業時間。 仕事を始める前に、すっかり気力を消耗していた。 暗黙の固定席 数週間後。 Aさんがようやく見つけたお気に入りの席に座っていると、背後から声がかかった。 Bさん 😐 「あの、そこ、いつも私が座ってる席なんですけど……。」 Aさん 😳 「えっ、あ、すみません！　自由席だと思って……。」 Bさん 😒 「まあ、別にいいですけど。」 Bさんは言葉とは裏腹に、明らかに不機嫌な様子だった。 Aさんは慌てて荷物をまとめ、別の席を探しに行く。 Aさん 😰 （自由に座っていいんじゃなかったの……？） 周りを見渡すと、いつの間にか席は「いつもの人のいつもの席」になっていた。 誰が決めたわけでもないのに、暗黙の固定席が完成していたのである。 98%が同じ席 導入から半年が経つ頃には、状況はさらに明らかになっていた。 同僚C 😑 「最初は『今日はどこに座ろう』ってワクワクしてたんですけどね。」 Aさん 🙂 「今はほぼ毎日同じ席ですよね。」 同僚C 😅 「そうなんですよ。結局、98%の人が同じ席に座ってるんじゃないですかね。」 部署を超えた交流を生むはずの制度は、いつしか「毎日同じ席に座る」ことが前提の運用に変わり、本来の狙いはすっかり形骸化していた。

はじめに 「社内でみんなが使っているツール以外を使うと、基礎ができていないと言われる」。そんな話を聞いたことはないでしょうか。 この物語では、使うツールの好みが、なぜか「基礎力」の評価にすり替えられてしまう職場を描きます。 SIerは「古臭い」と言われがちですが、問題は技術への感度ではなく、別のところにあるのかもしれません。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 「同調圧力が強い会社におけるツール選定」 これは、とあるSIerでの出来事。 官公庁や民間企業の業務システムを請け負い、Javaを中心とした開発を行っている会社だった。 社内では長年の慣習から、テキスト編集は サクラエディタ、Javaの開発は Eclipse、サーバーへの接続は TeraTerm を使う人が圧倒的多数を占めていた。 新しい技術のキャッチアップ自体は、決して遅れているわけではない。 クラウドやコンテナ、生成AIの勉強会も開かれ、新しい取り組みに前向きな社員も多い職場だった。 そんな中、中途入社した部下Aは、これまでの経験から、Javaの開発には IntelliJ IDEA、サーバーへの接続には Rlogin を使っていた。 1. エディタ編 ある日、上司Bが部下Aの席の後ろを通りかかった。 上司B 🤨 「ん？　それ、Eclipseじゃないね。」 部下A 🙂 「あ、いえ、IntelliJ IDEAです。補完やリファクタリングが便利なので使っています。」 上司B 😒 「ふーん……。テキストの編集もサクラエディタじゃないの？」 部下A 😊 「IDEの組み込みエディタで済ませています。ファイル間の移動が楽なので気に入っています。」 上司B 😑 「…………そう。」 2. ターミナル編 数日後、部下Aがサーバーのログを確認していると、再び上司Bが画面をのぞき込んできた。 上司B 🤨 「ターミナルもTeraTermじゃないね。」 部下A 😊 「Rloginです。タブ管理で複数サーバーに同時操作ができるので、このプロジェクトでの利用にてきしているかと。」 上司B 😠 「みんなTeraTermでやってるんだよ。なんでわざわざ違うものを使うの？」 部下A 😳 「便利だからですが……。」 3. 「基礎ができていない」編 その日の夕方、部下Aは会議室に呼び出された。

はじめに ベテランの会社員からは「朝早く出社すると評価が上がる」という声をよく聞きます。 しかし、実際にやってみても評価が上がらない、それどころか逆効果になることさえあります。 この物語では、役員のアドバイスを素直に実行したSIerの新人が、客先常駐先で思わぬ現実に直面する様子を描きます。 「誰よりも早く出社した新人と、遅れて来る先輩」 これは関東のとあるSIerでの出来事。 従業員は数百人規模。多くのエンジニアが客先に常駐して開発や保守を行っており、自社オフィスに出社する機会はほとんどない。 上司や役員の目が届かない客先常駐では、勤怠の管理は各自の裁量に任されている部分が大きかった。 新人Aは入社して間もない頃、研修の懇親会で役員Cと話す機会があった。 新人A 🙂 「どうすれば早く評価してもらえるようになりますか？」 役員C 😊 「簡単だよ。誰よりも早く出社しなさい。やる気は必ず見られているからね。」 新人A 😃 「わかりました！頑張ります！」 素直な新人Aは、配属された客先常駐先で、翌日から始業の30分以上前に出社することにした。 オフィスにはまだ誰もいない。静まり返ったフロアで、Aは一人、席に着いて先輩たちを待った。 始業時間の9時になった。先輩の席は空いたままだ。 9時15分。まだ来ない。 9時30分を過ぎた頃、ようやく先輩Bがコーヒー片手にのんびりと現れた。 先輩B 😄 「おはよー。あれ、もう来てるの？早いねぇ。」 新人A 😳 「おはようございます。……先輩、始業時間は9時ですよね？」 先輩B 😏 「ああ、客先だから誰も見てないしね。細かいこと気にしてたら疲れちゃうよ。」 困惑するAをよそに、他の先輩たちも次々と遅れて出社してくる。 誰も遅刻を気にしていない。それどころか、始業前から席にいるAの姿は、むしろ浮いていた。 その日の昼休み、先輩Bが他の先輩たちに話しているのが聞こえてきた。 先輩B 😆 「新人のA、朝一番に来てたんだよ。役員に何か吹き込まれたんだろうなぁ。」 先輩D 🤣 「マジで？かたいやつだなぁ。」 先輩B 😂 「応用力ないよね〜。」 へらへらと笑う先輩たち。その輪の中に、Aの居場所はなかった。 新人A 😨 「（僕は、ただ評価されたかっただけなのに……。）」 その後もAは、しばらく早めの出社を続けた。 しかし、評価が上がる気配はなかった。むしろ「言われたことをそのままやる、融通の利かないやつ」というレッテルだけが残っていった。 解説 なぜ、早く出社しても評価されなかったのでしょうか。 人間は、自分に近いマインドの人を高く評価する傾向があります。 出勤時間にルーズな組織では、「時間を守ること」そのものが評価軸になりません。そこで誰よりも早く出社しても、「自分たちと違う人」と見なされ、無意識に「かたいやつ」「応用力のない人」と評価を下げられてしまうことがあります。 役員の助言が間違っていたわけではありません。役員が過ごしてきた組織では、それが評価につながったのでしょう。しかし、評価の基準は組織によって異なります。 過去の成功体験に基づくアドバイスは、別の組織では通用しないことがあります。 また、朝型・夜型は遺伝的な要素も大きいと言われています。最近は朝はゆっくり始めたいと考える人も増えており、出勤時間の早さだけで人を評価することは、そもそも適切ではないのかもしれません。 評価を上げたいのであれば、世の中全体の流れと、自分が所属する組織のマインドを知ることが重要です。「何をすれば評価されるのか」は、誰かの助言を鵜呑みにするのではなく、自分の目で見極める必要があります。 おわりに 世の中には様々な企業や人が存在し、常識では考えられないようなことが実際に起きます。 勤怠に対する意識ひとつ取っても、組織によって驚くほど違いがあります。

はじめに Claude Codeには、ファイル編集やコマンド実行をどこまで自動で許可するかを決める権限モードがあります。 本記事では、各モードの特徴と使い分けをまとめます。 詳細は公式ドキュメントも参照してください。 権限モード - Claude Code Docs 権限の強さ順 概ね、弱い順では次の順番になります。 Plan < Manual < Accept edits < Auto << Bypass permissions モード別の詳細 Plan ファイルの読み取りのみで、基本的にファイル編集を行わない調査専用モードです。 実装前に、実装方針や変更計画を作成する際に使用します。 Manual Claude Codeが操作前にユーザーへ確認を求める標準的なモードです。 ファイルの読み取りなど一部の操作は承認なしで自動的に行われますが、それ以外は原則、ファイルの編集やコマンドの実行前にユーザーの承認が求められます。 機密データを扱うプロジェクトや、変更を一つずつレビューしたい場合に適しています。 Accept edits 作業ディレクトリ内のファイル編集を自動承認するモードです。 ファイル・ディレクトリの作成、移動、複製などが承認なしで実行されます。 gitなどのコマンド実行は、ユーザーに承認を求めます。 通常の機能実装やテストコードの追加、変更を最後にまとめてレビューしたい場合に適しています。 Auto 別の分類用モデルが安全と判断した操作を自動実行するモードです。 確認回数を減らしながら、危険な操作を自動的にブロックしたり、確認対象にしたりできます。 長時間の実行が必要なタスクや、機械的なコード変換など人間の介在が少なくても問題ないタスクをAIに自走させたい場合に適しています。 Bypass permissions 通常の権限確認や安全チェックを大きく省略するモードです。 リモートリポジトリへの操作や、保護されたファイルへのアクセスなど、リスクのある作業も自動実行します。 基本的にホストOSや本番環境での使用は非推奨とされており、Dockerコンテナや使い捨てVMなど隔離された環境での使用が推奨されています。 モード比較表 モード 自動で行われる操作 向いている場面 Plan 読み取りのみ 実装前の調査・設計 Manual 一部の操作のみ 機密データ、1件ずつレビューしたい場合 Accept edits 作業ディレクトリ内のファイル編集 通常の機能実装、テスト追加 Auto 分類モデルが安全と判断した操作 長時間タスク、機械的な変換 Bypass permissions ほぼすべて 隔離環境のみ 実務上の推奨 開発作業では、Planで調査・設計した後、問題なければManualまたはAccept editsで実装するのが好ましいです。

はじめに フリーランスのエンジニアにとって、エージェントは案件獲得の心強いパートナーです。 一方で、やり取りの中で「またか……」と思うような、あるあるも存在します。 この物語では、フリーランスエージェントとのやり取りで起きがちな出来事を、ユーモアを交えて描きます。 フリーランスエージェントあるある あるある① 契約更新のたびに営業電話 契約更新が近づくと、決まって着信がある。 エージェント営業B 😊 「Aさん、お世話になっております！直近案件のお探し状況の確認のため、ご連絡しました！」 A 😑 「（毎回電話かかってくるの面倒だな……。）」 あるある② 担当間で情報が連携されていない エージェントには、営業担当とキャリア担当がいる。 キャリア担当C 🙂 「Aさん、今後の希望についてお聞かせいただけますか？」 A 🤔 「先週、営業のBさんにお伝えしたのですが……。」 キャリア担当C 😅 「あ、そうでしたか。共有が漏れていたようで……。」 あるある③ 案件紹介の前に毎回、希望条件の面談 エージェント営業D 😊 「良い案件があります！ご紹介前に、希望条件の確認で30分ほどお時間いただけますか？」 A 😑 「（毎回同じこと言うの面倒だな……。）」 あるある④ 作業報告書の提出方法が食い違う エージェント営業B 🙂 「作業報告書はExcelで月末にメール提出でお願いします。」 ところが、初日に現場で言われたのは違う内容だった。 客先担当E 🤔 「作業報告書は、弊社の勤怠WEBシステムに入力してください。」 A 😳 「エージェントからはExcelと聞いていたのですが……。」 客先担当E 😐 「いえ、こちらのシステムです。」 提出方法は、Excel、エージェント専用の勤怠WEBシステム、常駐先のWEBシステムと案件ごとに違う。 そして、エージェント側の勘違いで、事前連絡と異なるケースが意外と多い。 解説 こうして並べると不満ばかりに見えますが、 会社員時代に経験した理不尽な上司や、責任の押し付け合いに比べれば、エージェントのあるあるは「可愛いもの」だからです。 そもそも、エージェントの担当者は多くの案件と人材を同時に抱えています。 情報連携の漏れや確認の重複は、その業務構造から起きやすいミスと言えます。 対策として、報告書の提出方法など重要な事項は、着任前に必ずメールなどの文面で確認し、証跡を残しておくと安心です。 また、エージェントを使うメリットも見逃せません。 営業活動を任せられ、自分で好きな案件を選べる点は、フリーランスにとって大きな価値です。 多少の手間は、その対価と割り切ることもできるでしょう。

はじめに IT業界には以前から、プログラミングスクールやAIスクールなど、情報商材を扱うセミナーが数多く存在します。 中には「情弱ビジネス」と呼ばれ、現役のプログラマーから嫌われているものもあります。 しかし、実際にセミナーに参加してみると、困惑させられるのは提供側よりも、参加者側だったりします。 この物語では、そんな「情弱セミナーあるある」を描きます。 「情弱セミナーで一番困惑したのは、講師ではなく参加者だった」 これは、とあるAIスクールが開催した無料WEBセミナーでの出来事。 主人公Aは、都内のシステム開発会社に勤めるエンジニア。 その日は特に予定もなく、暇つぶしのつもりで「AIで人生が変わる！」とうたう無料セミナーにWEB参加していた。 画面には熱弁を振るう講師と、司会、そして数十人の参加者が映っている。 講師B 😄 「当スクールでは、他では絶対に教えない黄金のタレのプロンプトを、受講生の皆さまだけにお伝えしています！」 主人公A 😑 「（はいはい、情弱乙。）」 主人公Aは、あきれ顔でコーヒーをすすった。 内容は、ネットで少し調べれば出てくる程度のプロンプトのコツを、大げさな名前で包んだものだ。 講師B 😆 「このプロンプトさえあれば、未経験からでも月収100万円が見えてきます！」 主人公A 🙄 「（そんなプロンプトがあるなら、自分で使って稼げばいいのに……。）」 そして、セミナーは質疑応答の時間に入った。 司会C 🙂 「それでは、ご質問のある方はチャットでお願いします。」 参加者D 🤔 「あの、スクールの受講料は経費にしても大丈夫ですか？」 一瞬、画面の中の空気が固まった。 主人公A 😳 「（え、それをスクールに聞くの？）」 司会C 😅 「えっと……そちらは……。」 講師B 😓 「……。」 本来、経費として認められるかどうかは、税理士や経理担当者に確認すべき内容だ。 スクール側が「大丈夫ですよ」と答えられるはずもない。 司会C 😐 「そちらは、税理士さんか経理の方にご確認いただくのがよろしいかと存じます。」 参加者D 🙂 「わかりました！ありがとうございます！」 質問者だけが満足そうだった。 主人公A 😑 「（講師より、参加者のほうが怖いわ……。）」 情弱セミナーで困惑させられるのは、提供側よりも参加者側であることが多い。 主人公Aは、そう痛感しながらブラウザのタブを閉じた。 解説 情弱ビジネスは提供側を批判する声が多い一方で、「騙される側にもいらいらする」という声も多いです。 地方でも、AIやDXをうたい文句に、中小零細企業へ高額な契約を持ちかける怪しげなコンサル会社は珍しくありません。 IT担当者がいない会社ほど、「よく分からないから、詳しそうな人の言うことを信じる」状態に陥りやすいので注意が必要です。

はじめに Claude Codeは通常Anthropic社のAPIを直接利用しますが、すでにAWSプラットフォームを利用している場合は、Amazon Bedrock経由でClaudeモデルを呼び出すこともできます。 Bedrock経由で利用することで、以下のようなメリットがあります。 既存のAWS請求・IAM権限管理の仕組みをそのまま利用できる AWSのネットワーク内（VPC等）からセキュアにアクセスできる 社内でAWSの利用が前提となっている環境でもClaude Codeを導入できる 本記事では、Claude CodeでAWS Bedrock経由のClaudeモデルを使用するための設定手順を紹介します。 1. AWS CLIをインストールする Bedrockへのアクセスには、事前にAWS CLIをインストールし、認証情報を設定しておく必要があります。 AWS CLI公式ドキュメント: インストール手順 上記ドキュメントの手順に従って、使用しているOSに応じたインストーラーをダウンロードし、AWS CLIをインストールしてください。 2. AWSにログインする ターミナルを起動し、AWS CLIでログインします。 aws login コマンド実行後、ブラウザが起動するのでAWSの認証情報を入力してログインしてください。 ログイン方法の詳細は以下の公式ドキュメントも参考にしてください。 AWS公式ドキュメント: コマンドラインでのサインイン 3. 推論プロファイルIDを確認する Claude CodeからBedrock上のモデルを指定するために、推論プロファイルIDが必要です。 AWSマネジメントコンソールから、Amazon Bedrockの画面を開き、以下の手順でIDを確認します。 左メニューの「推論」→「推論プロファイル」を選択 利用したいモデル（例: Claude Sonnet、Claude Opusなど）の行から「推論プロファイルID」をコピー コピーしたIDは、次の手順でsettings.jsonに設定します。 4. settings.jsonを設定する Claude Codeのsettings.jsonに、以下のようにBedrock利用のための環境変数を設定します。 { "env": { "CLAUDE_CODE_USE_BEDROCK": "1", "AWS_REGION": "us-east-2", "ANTHROPIC_DEFAULT_SONNET_MODEL": "global.anthropic.claude-sonnet-5-5", "ANTHROPIC_DEFAULT_HAIKU_MODEL": "global.

はじめに 一人法人（合同会社や特例有限会社など）を経営していて引越しをすると、個人の転入転出手続きとは別に、法人としての住所変更手続きが発生します。 法務局・年金事務所・税務署・地方税事務所・郵便局・金融機関など、届出先が多岐にわたるうえ、それぞれ提出期限や必要書類が異なるため、うっかり漏れやすいのが実情です。 この記事では、管轄外（他の法務局の管轄エリア）への本店移転を前提に、一人法人が住所移転する際にやるべき手続きを移転前・移転後に分けてまとめました。 実際に自分の会社を移転させた際の経験をベースにしているので、これから移転を予定している方の参考になれば幸いです。 移転前にすべきこと 取引先への住所変更予定の連絡 契約書や請求書に登記住所を記載している取引先がある場合は、移転前に住所変更の予定を連絡しておきましょう。 契約書の再締結が必要になるケースもあるため、早めに伝えておくとその後の事務作業がスムーズです。 移転後にすべきこと 以下は、管轄外への本店移転を行った場合の手続きです。同一法務局の管轄内での移転の場合は、一部の手続きが簡略化されることがあります。 🏛 法務局（本店移転登記） 本店移転の日から2週間以内に、移転前の法務局へ登記申請が必要です。 本店移転登記申請書（旧管轄用・新管轄用の2枚） 商業・法人登記の申請書様式｜法務局 登録免許税：3万円 × 2通（新旧の管轄法務局分） 添付書類：総社員の同意書（フォーマットは自由） 特例有限会社変更登記申請書（該当する場合） 登録免許税：1万円 補足事項として、令和7年4月21日の商業登記規則改正により、本店移転登記のみであれば印鑑届出書の提出は不要になっています。 実務上のポイントは以下の通りです。 移転申請書は移転後でないと提出できないため、郵送またはオンライン申請（電子署名料金：最低1,300円／3ヶ月有効）での提出になる 事前に法務局の相談窓口で予約を取り、記載内容を確認してもらうと差し戻しを防げる 移転申請と登記申請は同時に実施してもよい 定款には移転先住所を市区まで記載する 完了報告は行われないため、法人番号公表サイト等で自分で更新を確認する 🏥 年金事務所（社会保険） 移転前の年金事務所に、移転から5日以内に提出します。 健康保険・厚生年金保険 適用事業所名称／所在地変更（訂正）届 法人登記事項証明書のコピーが必要 参考: 1-4：適用事業所の名称・所在地を変更するとき（管轄外の場合）｜日本年金機構 🏢 税務署（国税） 国税に関する異動届は、移転後に、移転前の所轄税務署へ提出するだけで完了します。提出期限は1か月以内で、e-Tax・郵送・窓口のいずれでも対応可能です。 異動届出書 定款の写し 給与支払事務所等の開設・移転・廃止届出書 消費税異動届出書 参考: C1-8 異動事項に関する届出｜国税庁 / A2-7 給与支払事務所等の開設・移転・廃止の届出｜国税庁 💡 補足：国税は1か所で済むのに、地方税は移転前・移転後の両方に届出が必要なのはなぜ？ 国税は国税庁が全国の税務署を一元管理しており、納税者データが組織内部で統合されているため、移転前の税務署に届け出るだけで新管轄への引き継ぎが自動的に行われます。一方、地方税は都道府県・市町村がそれぞれ独立した課税主体であり、法人住民税・法人事業税はその自治体自身の税収になります。そのため、移転前の自治体は在籍期間分の税額を確定するため、移転後の自治体は新たな納税者として登録するため、それぞれ別の目的で届出が必要になります。地方公共団体間には国税庁のような自動連携システムがないため、納税者自身が両方に届け出ないと、旧自治体側は課税漏れ、新自治体側は納税者を把握できないままになってしまいます。 都道府県税事務所（地方税） 管轄外への移転の場合、移転前・移転後の両方の事務所に法人異動届の提出が必要です（法人登記事項証明書のコピーが必要）。

はじめに 会社という組織を眺めていると、人狼ゲームの役職構成にそっくりだと感じることがあります。 不正や責任転嫁を平気で行う「人狼」、悪意はないのに話をこじらせて周囲を混乱させる「狂人」、そして周囲を静かに支える「村人」や「占い師」的な人たち。 この記事では、会社にいるさまざまなタイプの人を人狼ゲームの役職になぞらえて紹介します。 「うちの会社にもこういう人いるな」と思い当たる部分があれば、それだけ会社という組織が人狼ゲームの構造に似ているということかもしれません。 人狼：自分のことしか考えないブラック社員 自己都合を優先し、会社に負の影響を与える上司・先輩。 トラブルが起きれば真っ先に自分の保身を考え、都合の悪い事実を隠したり部下に責任を押し付けたりすることも珍しくありません。 成果が出た場面では手柄を横取りし、コンプライアンス違反すれすれの指示を後輩にやらせておきながら、自分は関与していないような顔をするのもお家芸です。 人当たりが良く仕事ができるように見えるこ とも多いため、周囲から人狼だと気づかれるまでに時間がかかるのも厄介なところです。 狂人：悪意なき妨害者 本人には全く悪気がないのに、結果としてチームの足を引っ張ってしまう社員。 人狼のように明確な悪意があるわけではありません。 むしろ本人は「良かれと思って」動いているのですが、報連相のタイミングがズレていたり、確認不足のまま見切り発車したりして、周囲がそのフォローに追われてしまうのです。 本人に自覚がないケースも多く、ADHDなどの特性が背景にある場合もあります。 悪意がない分、責めるに責められず、人狼よりもある意味で対処が難しい存在です。 村人：大多数の一般社員 特に強い派閥意識もなく、日々の業務をこなしている大多数の社員。 人狼ゲームにおける村人と同じく、会社組織の中では最も人数が多い層です。 悪意はないものの、自分の身を守ることに精一杯で、人狼が嘘をついている場面を目撃しても見て見ぬふりをしてしまうことが少なくありません。 占い師：炎上の匂いを嗅ぎ分けるベテラン 長年の経験の中で、ヤバい人・ヤバい案件を見抜く目を持ったベテラン社員。 過去に幾多の炎上案件やトラブルを目の当たりにしてきた経験から、要件定義の曖昧さや客先の温度感、体制の組み方といった些細な違和感から、炎上プロジェクトの匂いを早期に嗅ぎつけます。 霊媒師：過去の炎上案件を知る情報通 他の社員が知らない過去の炎上案件やデスマーチの顛末を知っている情報通。品質保証部などにいることが多い。 品質保証部やPMOのようなポジションは、プロジェクトの振り返りや障害報告、トラブル対応の記録に日常的に触れる立場にあるため、表沙汰になりにくい過去の顛末を把握しやすいのです。 騎士：メンバーを庇う有能社員 無茶な客先要求や社内の理不尽な責任転嫁から、メンバーを体を張って庇う有能社員。 優秀であるがゆえに正論を臆せず口にするため、人狼系の上司から疎まれ、割の合わない部署へ飛ばされてしま あるいは本人が理不尽な組織構造に見切りをつけ、転職してしまうので、早期に会社から退場するケースが多いです。 共有者：自分と同じ立場の同期 会社の息がかかっていない自分と同じ立場の心を許せる唯一の存在。 会社の息がかかっておらず、自分と同じ立場なので、会社に密告されることもないので、気軽に相談することができます。 部署をまたいで同期同士が情報を交換し合うと、一人では気づけない人狼や狂人の存在を、同期のネットワークを通じて早期に把握できるようになるのです。 おわりに 会社組織には様々な人がいるため、どんな会社でも人狼や、狂人のような人もいます。 会社の同僚に業務上の悩みを不用意に相談してしまうと、相談相手が人狼や狂人だったりすると、情報が歪んで伝わったり、都合よく利用されたりして、自分にとって不利な結果を招きやすくなります。 だからこそ重要なのが、人狼ゲームにおける共有者のような立ち位置にある「同期」との交流です。 利害関係の薄い同期同士で部署をまたいで情報交換をしておくことで、特定の人物に関する評判や過去のトラブルを早期に把握でき、人狼や狂人らしき人物を見抜く手がかりを得やすくなります。 村人のまま孤立して情報を得られずにいると、いつまでも人狼に振り回され続けることになりかねません。 日頃から同期や信頼できる先輩との交流を大切にし、こまめな情報交換を心がけることが、会社という人狼ゲームを生き抜くための最大の防御策と言えるでしょう。 関連記事 本当にあった?エンジニアの怖い話「社員寮の退寮手続きだけで2ヶ月以上かかるトンデモ会社」

はじめに 社員旅行への参加を就業規則で義務付け、さらに顧客へのお土産代まで社員に自費で負担させる会社が実際に存在します。 この物語では、「社員の福利厚生」であるはずの社員旅行が、なぜ負担とストレスの温床になってしまうのかを描きます。 「社員旅行強制＆お土産自腹編」 これは中部地方にある、社員数百名規模のシステム開発会社での出来事。 この会社は毎年恒例で1泊2日の社員旅行を実施していた。 旅行自体は福利厚生の一環として案内されていたが、実際には就業規則に「社員旅行への参加」が明記されており、実質的に欠席が許されない行事だった。 新入社員のAは、配属されて間もない時期にその案内を受け取ることになる。 先輩B 😐 「今月末、社員旅行あるから。日程空けておいてね。」 新人A 🙂 「わかりました。参加は必須なんですか？」 先輩B 😐 「就業規則に書いてあるから、基本は全員参加だね。」 新人A 😳 「そうなんですね……。」 有給休暇のような扱いではなく、業務の一環として組み込まれているため、私用の予定を調整して参加するしかなかった。 旅行当日が近づくと、Aはさらに別の指示を受けることになる。 先輩B 😐 「あと、取引先へのお土産も買っておいてね。」 新人A 🤔 「お土産は会社の経費で購入するんですよね？」 先輩B 😐 「いや、それは各自の自腹だから。」 新人A 😨 「……自費、ですか？」 先輩B 😐 「うちはずっとそうだよ。慣習だから。」 社員旅行への参加そのものが半ば強制であるうえに、業務上の付き合いである顧客へのお土産まで自分の懐から支払わなければならないという事実に、Aは戸惑いを隠せなかった。 旅行当日。 バスに乗り込む社員たちの表情は様々だった。 楽しみにしている社員もいれば、明らかに気乗りしない様子の社員もいる。 先輩C 😑 「毎年これで有給1日分潰れるようなもんだよな……。」 同僚D 😔 「お土産代も地味に痛いですよね。」 先輩C 😑 「そうそう。でも参加しないと後で何言われるか分からないから。」 旅行そのものは景色も良く、食事も悪くなかった。 しかし、Aの心には「参加を選べない」ことへの引っかかりが残り続けた。 旅行後、Aは経費精算の書類を確認してみたが、お土産代の項目はどこにも用意されていなかった。 新人A 😥 （やっぱり自腹なんだ……。） 先輩たちに聞くと、この慣習は何年も前から続いているものであり、誰も特に疑問を持たずに受け入れているようだった。 新人A 😐 （みんな当たり前だと思ってるのか……。） 解説 社員旅行は本来、社員同士の交流や労をねぎらうための福利厚生の一環です。 しかし今回のケースのように就業規則で参加を義務付けてしまうと、実質的には「休日出勤」や「業務の延長」に近いものになってしまいます。