IT業界因習村仕草

README.md

readme

元ネタ

https://x.com/wraith13/status/1916723006203986283

ITエンジニア因習村仕草、たぶん、実際にはいろいろあると思うんだけど、村の住人なのでサッパリ分からない。

本当は実例を探してもらいたかったが難しかった。とりあえず定義などを残しておく。

• definition.md 会話から抽出した自分の定義

---

特定コミュニティの「因習村仕草」定義（簡略版）

目的

コミュニティ内部の人が気づきにくい、**独自の当たり前（＝因習村仕草）**を客観的に理解するための定義。

「因習村仕草」とは？

特定のコミュニティ（"村"）で見られる、以下の特徴を持つ個人の行動や習慣のこと。

1. 外から見ると「変」:

   • 一般社会や他のコミュニティから見ると、「なんで？」「変わってるね」「奇妙だ」と感じられる。
   • 必ずしも古かったり非合理的だったりするわけではない（これは勝手に付け足した条件）。

2. 中では「普通」:

   • そのコミュニティ内では、「**当たり前」「常識」「これが普通」**として受け入れられ、疑われない。
   • 多くは「専門性」「効率」「情熱」「文化」などを理由に（無自覚に）正当化されている。

3. 暗黙のルール:

   • 明確な決まりではなくても、「**こうするのが普通」「やらないと浮く」**という空気や同調圧力がある。

4. 従わないと…？:

   • ルールを破っても直接怒られなくても、評価が下がったり、仲間外れ感があったり、居心地が悪くなったりする可能性がある（ソフトなペナルティ）。

ポイント

• 対象は個人の具体的な「仕草」。
• 「外からの奇妙さ」と「中の当たり前」のギャップが鍵。
• 暗黙のルールとソフトな影響力に着目。

definition.md

特定コミュニティにおける「因習村」および「因習村仕草」の概念規定

目的

本規定は、特定の専門職コミュニティやサブカルチャー集団（以下、コミュニティ）の内部構成員が、自らが所属する集団内で自明視されているものの、外部からは特異に見える可能性のある暗黙的な規範や行動様式（以下、「因習村仕草」）を客観的に認識し、自己省察を促すための一助となることを目的とする。

1. 「因習村」の概念規定

「因習村」とは、以下のような特徴を持つ特定のコミュニティや集団を指すための比喩的・分析的概念である。

• 外部からの観察における特異性: コミュニティ外部の一般的社会規範や価値観、あるいは他のコミュニティの基準から観察した場合に、独自の、時には理解困難または奇異に映る行動様式、思考パターン、価値観、専門用語の使用法などが顕著に見られる集団。
• 内部における規範の自明視: 当該コミュニティの内部構成員にとっては、それらの特異な様式が「当たり前」「合理的」「効率的」「専門性に基づく当然の帰結」あるいは「コミュニティ固有の文化」として広く受容・内面化されており、通常は疑問視されることが少ない状態。
• 境界の存在と閉鎖性の傾向: 明示的か否かにかかわらず、コミュニティ内外を隔てる認識上の境界が存在し、内部の論理や規範が外部のそれとは独立して維持・強化される傾向を持つ。

2. 「因習村仕草」の詳細定義

「因習村仕草」とは、上記の「因習村」的コミュニティにおいて観察される、以下の構成要素を持つ個人レベルの具体的な行動様式、習慣、思考パターン、コミュニケーションスタイルを指す。

2.1. 行動主体

• コミュニティに所属する個々の構成員によって日常的に実践・表出される具体的な振る舞いや思考の癖。組織文化全体といったマクロなレベルではなく、ミクロな個人行動レベルに着目する。

2.2. 外部観測性（異質性・特異性）

• コミュニティ外部の観察者（例: 一般社会の構成員、他分野の専門家）の視点から見た際に、その行動様式が既存の理解の枠組みから逸脱しており、「なぜそのような行動を取るのか理解しがたい」「特異である」「非効率または過剰にみえる」「独特のこだわりが感じられる」といった評価や感想を引き起こす蓋然性が高い。
• ここでいう特異性は、必ずしも「古臭い」「非合理的」であることを意味せず、むしろそのコミュニティ独自の進化や最適化の結果として生じた行動様式が、外部環境の文脈においては奇妙に見えるケースも含む。

2.3. 内部受容性（規範の内面化と正当化）

• コミュニティ内部では、その「仕草」が規範として広く受容され、構成員によって自明のものとして内面化されている。多くの場合、疑問を差し挟む余地のない「常識」や「基本動作」と認識される。
• その正当性は、多くの場合、コミュニティが共有する特定の価値観（例: 技術的卓越性、効率性、品質、特定の思想・哲学）、専門性に基づく合理性（と内部で認識されているもの）、歴史的経緯、あるいはコミュニティへの帰属意識や一体感の醸成といった論理によって（明示的または暗黙的に）支えられている。

2.4. 規範の潜在性（暗黙知と非明示的ルール）

• 「仕草」の実践は、明文化された規則や強制によるものだけでなく、暗黙知、非明示的な期待、場の空気、同調圧力といった、言語化されにくい要素によって維持・強化されている側面を持つ。
• 新規参入者は、模倣、観察、あるいは周囲からの微細なフィードバックを通じて、これらの潜在的規範を学習・習得していくプロセスが見られる。

2.5. 逸脱への陰性フィードバック（間接的・社会的影響）

• 当該「仕草」から逸脱した行動を取った構成員に対して、直接的な懲罰や明確な非難が行われるとは限らない。しかし、以下のような間接的、社会的、心理的な陰性フィードバックが発生する可能性がある。
  • コミュニティ内での評価の微妙な低下（例: 「専門性が低い」「意欲がない」「文化を理解していない」）。
  • 重要な情報共有や意思決定プロセスからの緩やかな排除。
  • 特定の役割や機会からの忌避。
  • 他の構成員からの心理的な距離感の増大や疎外感の惹起。
  • コミュニティ内での居心地の悪さの醸成。

この定義は、特定のコミュニティにおける行動様式の多面的な理解を促し、内部構成員が自らの行動や所属集団の規範をより客観的な視点から捉え直すための枠組みを提供することを意図している。

キャラクター.md

粒度が雑いキャラクターの例

例1：「神エディタVim原理主義村」の若手エンジニアAさん

• 村の状況: チーム内にVim（またはEmacsなどの特定のエディタ）を熱烈に信奉する古参エンジニアが複数名おり、「Vimこそが真のエンジニアの道具」「Vimを使えないのはプロではない」という空気が（冗談めかして、しかし本気で）漂っている。コードレビューでは、Vimの効率的な使い方を知らないことによる（と彼らが主張する）些細な編集ミスも指摘されることがある。
• 外部から見た奇妙さ:
  • AさんがモダンなIDE（VSCodeなど）の便利な機能（強力な補完、デバッガ連携）の話をすると、先輩から「そんなものに頼るからタイピングが遅くなる」「Vimならプラグインで全部できる（実際は設定が複雑）」と一蹴される。
  • ペアプログラミングでAさんがVSCodeを使っていると、隣の先輩が「ふーん…マウス使うんだ…」「その操作、Vimなら2キーで終わるのにね」とボソッと呟き、Aさんはなんとなく居心地が悪くなる。
  • チームのSlackチャンネルに、AさんがVSCodeの便利な拡張機能の情報を共有しても、ほとんど反応がないか、「Vimの〇〇プラグインの方が優れている」というリプライがつく。
• 内部の常識/規範:
  • 「Vim（特定のエディタ）を使いこなすことが生産性の鍵」
  • 「マウスは悪、キーボードですべてを操作するのが理想」
  • 「エディタのカスタマイズに時間をかけるのは当然の投資」
• 暗黙の了解/ソフトな強制力:
  • Vimに関する知識が豊富だったり、華麗なキー操作を見せたりすると、技術的に「デキる奴」として一目置かれる。
  • モダンなIDEを使っていると、どこか「本気度が足りない」「楽をしている」と見なされがちな空気。
• 逸脱へのペナルティ:
  • Vimを使わないことで、直接的に怒られることはないが、技術的な議論やペアプロの相手として、Vim原理主義の先輩から敬遠されがちになる。
  • 「A君はまだVimに慣れてないから」という理由で、複雑な設定変更やサーバーでの直接編集作業などを任せてもらえないことがある。
  • コードレビューで、エディタ操作の効率に関わる（と彼らが考える）指摘を受け続け、心理的なプレッシャーを感じる。

例2：「OSS（ライブラリX）絶対貢献村」の個人開発者Bさん

• 村の状況: 特定のOSSライブラリ「X」のコミュニティが非常に活発で、コアメンバーや熱心なコントリビューターの間では、「ライブラリXへの貢献度＝エンジニアとしての価値」という価値観が強い。GitHubのContributionグラフ（草）が緑で埋まっていることが一種のステータスになっている。
• 外部から見た奇妙さ:
  • Bさんは、本業とは別に、週末や深夜にライブラリXのIssue対応やPR作成に膨大な時間を費やしている。友人との約束を断って、緊急度の低いバグ修正をすることも。
  • BさんがライブラリXとは競合する（あるいは思想の異なる）別のライブラリYについて、SNSで「Yもなかなか良い」と呟くと、ライブラリXのコミュニティメンバーから「なぜXではダメなのか具体的に説明せよ」「Xへの愛が足りないのでは？」といった反応が（半ば冗談、半ば本気で）寄せられる。
  • ライブラリXのカンファレンスやオンラインミートアップに参加しないと、「最近Bさん見ないね、忙しいの？」「Xへの情熱冷めちゃった？」と他のメンバーから心配（という名のプレッシャー）をされる。
• 内部の常識/規範:
  • 「ライブラリXを使い、コミュニティに貢献するのは当然」
  • 「GitHubの草は生やし続けるもの」
  • 「ライブラリXの思想や方向性を理解し、支持する」
• 暗黙の了解/ソフトな強制力:
  • 継続的に貢献しているメンバーは、コミュニティ内で尊敬され、発言力を持つ。
  • 貢献が滞ったり、コミュニティイベントへの参加率が下がったりすると、「最近アクティブじゃない」と見なされ、重要な情報や議論から疎外されがちになる。
• 逸脱へのペナルティ:
  • ライブラリX以外の技術を公然と推奨したり、ライブラリXへの批判的な意見を述べたりすると、「裏切り者」とまでは言われなくとも、コミュニティ内で居心地が悪くなり、他のメンバーとの交流が減る。
  • 貢献度が低いと、新しい機能の提案や重要なIssueへの意見を述べても、あまり真剣に取り合ってもらえなくなる。
  • （極端な場合）ライブラリX関連の仕事の紹介などが回ってこなくなる。

例3：「テストコードカバレッジ100%村」のQAエンジニアCさん

• 村の状況: Cさんの所属する開発チーム（あるいはQAチーム）では、「テストコードのカバレッジ100%達成」が半ば神格化されている。マネージャーやシニアエンジニアが「カバレッジ100%は品質の証」と公言しており、カバレッジレポートの結果がチーム内で常に共有され、注目されている。
• 外部から見た奇妙さ:
  • Cさんは、明らかにテストする価値の低い些末なコード（例：単純なゲッター/セッター）に対しても、カバレッジ100%を達成するためだけにテストコードを書いている。その作業に多くの時間を費やしており、より重要な結合テストや探索的テストの時間が圧迫されている。
  • カバレッジがわずかに100%を下回った（例えば99.8%）だけで、CI/CDパイプラインが失敗するように設定されており、その修正のためにリリースが遅れることがある。外部の協力会社からは「そこまでやる必要が？」と訝しがられている。
  • チームミーティングで、Cさんが「カバレッジ目標を少し下げて、他のテスト活動に時間を割きたい」と提案すると、「品質意識が低い」「カバレッジ100%から逃げるのか」という非難めいた空気に包まれる。
• 内部の常識/規範:
  • 「カバレッジ100%は絶対的な目標であり、品質の最低ライン」
  • 「カバレッジが低いコードは悪」
  • 「カバレッジを上げるための努力は惜しまない」
• 暗黙の了解/ソフトな強制力:
  • カバレッジ100%を維持している開発者やQAは「仕事が丁寧」「品質意識が高い」と評価される。
  • カバレッジを下げてしまうようなコード変更に対しては、レビューで厳しい目が向けられる。
• 逸脱へのペナルティ:
  • カバレッジ目標の達成に非協力的な態度をとると、「チームの輪を乱す」「品質に対する責任感がない」と見なされ、評価に影響が出る可能性がある。
  • カバレッジを優先するあまり他の重要なテストが疎かになっていることを指摘しても、「言い訳だ」「まずはカバレッジを達成してから言え」と一蹴される。
  • カバレッジが低いコードをコミットしてしまうと、チーム内で「犯人探し」のような雰囲気が生まれ、心理的な負担が大きい。

これらの例は、技術選択、コミュニティ活動、開発プロセスといった異なる側面から、「外部から見ると奇妙（または過剰）に見えるが、内部では強い規範意識と逸脱へのプレッシャーが存在する」状況を描写しようと試みました。

失敗したgrokとの会話の振り返り.md

客観的に観察した結果、この会話が失敗した原因と、ユーザーが求めていたもの、そしてGrokの出力に不足していた点について以下のように分析します。

ユーザーが求めていたもの

1. 「因習村仕草」の核心: ユーザーは単なる「ITエンジニアあるある」や「業界の特徴」ではなく、「因習村」というミームが持つ特有のニュアンスを含んだ具体例を求めていました。そのニュアンスとは、以下の要素の組み合わせです。
   • 外部からの視点: 一般社会（そのコミュニティ外）から見ると「不思議」「奇妙」「（場合によっては）少し異様」に感じられる行動。
   • 内部の論理/当たり前: そのコミュニティ内部では「当たり前」「常識」「当然の行動」として受け入れられている。
   • 暗黙の了解/不文律: （会話の後半で強調された点）その行動が単なる個人の選択ではなく、コミュニティ内の暗黙のルールや同調圧力に基づいており、従わないと何らかの不利益（仲間外れ、評価の低下、"怒られ"など）が生じる可能性がある。
   • 「仕草」レベルの具体性: 組織や文化といった抽象的な話ではなく、実際にそのコミュニティに属する「個人」が行う具体的な行動や振る舞い。
2. 定義の明確化プロセス: ユーザーは、Grokとの対話を通じてこの「因習村仕草」の定義を徐々に明確化しようとしていました。ホラー要素や不合理性を排除し、「不思議さ」「奇妙さ」に焦点を当て、最終的には「暗黙の了解とペナルティ」という要素を加えました。
3. 質の高い具体例: この洗練された定義に合致する、深みとリアリティのある具体例をGrokが提示することを期待していました。特に、他の業界（イラストレーター）との比較を通じて、ITエンジニア特有の「因習村仕草」の輪郭を明らかにしようと試みていました。

Grokの出力に不足していたもの

1. 具体例の深さとリアリティの欠如:
   • 初期の例（Slackの絵文字、紙レビュー）は表層的すぎました。
   • 「一般社会から見て奇妙」な例（カジュアル服装、フレックスタイム）は視点を捉えましたが、「暗黙のルール」の側面が欠けていました。
   • 「暗黙のルール」を加えた例（ハッカソン参加義務、技術ネタ投稿ルールなど）は要求に近づきましたが、その「義務」や「ペナルティ」の描写がステレオタイプ的で、後付けのように感じられた可能性があります。「本当にそれが破ると怒られるレベルの不文律なのか？」というリアリティや具体性に欠け、多くの人にとっての「あるある」の域を出ないように見えました。
2. 「不思議さ/奇妙さ」のニュアンスの捉え方の甘さ:
   • Grokが挙げた例は、「そういう文化なんだな」「効率のためなんだな」と外部からもある程度理解・納得できてしまうものが多かったかもしれません。「因習村」が持つ、外部から見て「なぜそんな奇妙なことを？」「理解不能だけど面白い/不気味」と感じさせるような、文化人類学的な面白さや異質さのニュアンスを十分に表現できていませんでした。
3. 定義と具体例の乖離:
   • Grokはユーザーの指示に従って定義を修正することはできましたが、その定義（特に後半で強調された「暗黙のルール」「ペナルティ」）を、説得力のある具体例に落とし込むことができませんでした。定義は洗練されても、出てくる具体例の質が追いついていない状態でした。
4. 検索能力と対話内容の統合不全:
   • 最終的にDeepSearchを行いましたが、提示された例はそれまでの対話で出たものと大差なく、新たな発見や深い洞察をもたらしませんでした。これは、検索結果を表面的にリストアップするだけでなく、ユーザーとの対話で練り上げた独自の定義（「不思議さ」「暗黙のルール」）に照らして情報を解釈・選別し、質の高い具体例として再構成する能力が不足していたことを示唆します。検索した情報と対話で得た要求を結びつける部分が弱かったと言えます。
5. 「仕草」への焦点:
   • ユーザーが求めた「個人レベルの仕草」に対し、Grokの回答は時折「業界では」「チームでは」といった、ややマクロな視点での説明に留まる傾向がありました。もっと微視的な、個人の具体的な行動様式の描写が不足していた可能性があります。

結論として会話が失敗した理由

この会話の失敗は、ユーザーが対話を通じて定義しようとした「ITエンジニア因習村仕草」という複雑でニュアンス豊かな概念を、Grokが具体例のレベルで十分に捉えきれなかったことに起因します。Grokはユーザーの指示に段階的に応答しましたが、提示される具体例が常にユーザーの期待する深さや質（特に「外部から見た奇妙さ」と「内部の暗黙の強制力」の絶妙なバランス）に一歩及ばず、表面的な「あるある」やステレオタイプの域を出られませんでした。最終的に、Grokが検索能力を活かしてもこのギャップを埋められなかったため、ユーザーは求める回答が得られないと判断したと考えられます。

いわゆる「理系の人々」で描写されるものを除外したものを本当は抽出したい