  |
はてなキーワード: OJTとは
「代理の効力感」（代理効力感）とは、主にアルバート・バンデューラ（Albert Bandura）の自己効力感（self-efficacy）理論で扱われる概念に関連します。
1. 基本的な意味自己効力感 ：自分が特定の課題や状況をうまく対処できるという自信・信念のこと。
代理の効力感（vicarious efficacy / proxy efficacy）：自分ではなく、他者（代理人・モデル）の成功や行動を観察することで生まれる「自分にもできそう」という効力感（期待感）。
日本語の心理学・教育・組織論の文脈では、主に**「代理体験（vicarious experience）」**を通じて得られる自己効力感のことを指します。他者の成功を見て「自分もやれる」と感じる心理メカニズムです。
達成経験（Mastery Experience） ：自分で実際に成功した経験（最も強い影響）。
言語的説得（Verbal Persuasion） ：他人から「あなたならできる」と励まされる。
生理的・感情的状態（Physiological and Emotional States）：不安や興奮などの身体反応の解釈。
代理体験は、特に**「自分と似た立場・能力の人」**の成功を見ると効果が高まります。遠すぎるスーパースターの成功例は逆に「自分には無理」と効力感を下げる場合もあります。
3. 代理効力感（Proxy Efficacy）のもう一つの側面
一部の研究では、proxy efficacyとして「他者（代理人）に頼ることで目標を達成できるという信念」を指します。
例：医師やトレーナー、チームメンバーに頼ることで「自分はうまくいく」と感じる。
これは個人で全てをコントロールせず、他者にコントロールを委ねることでストレスを減らし、間接的に自己効力感を支える考え方です。
教育・研修：看護学生や新入社員が、先輩の成功事例（動画・同行観察・ロールモデル）を見て自信をつける。
スポーツ・健康：同じ年齢・体型の人が運動で成果を出しているのを見てモチベーションを上げる。
ポイント：観察するモデルが「似ている」ほど代理の効力感が高まりやすい。相互的な自己開示（悩みを共有）も効果を強めます。
black-smith.co.jp
この概念は、直接経験が少ない人（初心者・挫折経験者）のモチベーション向上に特に有効です。他者の成功を「自分の可能性」として取り込むことで、行動を促し、持続させる力になります。もっと具体的な文脈（例：教育、職場、自己啓発など）で知りたい部分があれば、詳しくお答えします！
現在、私は第一志望の自治体で臨時的任用職員として公務に就いています。
しかし、標記のとおり第一志望の自治体には不採用となりました。そして今回が年齢制限のため、最後の採用試験でした。
今回の結果は単純に筆記と面接でスコアを伸ばせなかった私の準備及び実力不足です、と片付けられるものです。
でも、何か、片付けられない何かがあって、こうして言葉を綴り始めてしまいました。
現職は今年で2年目です。昨年度は非常勤の枠で、今年は同じ部屋で休職された職員の方の枠に臨時的任用職員として半年の雇用契約を結びました。
1年間みっちり携わったことで、年度末にはできることも相当増えて今年度は責任が大きくなりました。
仕事上ミスが許されないため、どのような設計をするのか、複数の非常勤職員の方々に依頼をしつつ、立ち回っています。
もちろん主担当以外にも他の業務も兼務していて、これが相当にややこしい…。
ただ、昨年度の仕事ぶりを見て任せて貰っている部分があるために、少なからず嬉しい部分もあるのです。激務部署と呼ばれている中でこの立ち回りをできていることは自信に繋がりました。
また、他職員の方からも少なからず認めていただいており、本当に有り難い限りです。今回の採用試験についても親しい間柄の方々が積極的に応援してくれていました。
しかし、結果はご覧の有様です。本当に面目がない。
私は試験結果を「君は今後の自治体行政に要らない」という最後通牒と受け取りました。長期的に投資する価値がない、としっかり値札を付けられたのです。
2年目のため、即戦力と見られなったのか。短期離職の経験があるからか、年齢の問題があるからか、要因は…と考えれば幾らでも湧いてきました。
ここまで愚痴をこぼしているようですが、職務と試験結果は別物です。
そのため、残りの任用においても十全に職責を全うする所存です。
また、職務における技術的課題、業務量の課題、引継の課題があるため、これらの課題を次年度までに解消させておきたいです。
特に引継ぎについて、ひとつ付言すると、担当者のみならず組織的な課題が存在していると思われます。
全くの未経験の状態から職務をキャッチアップするためには引き継ぎ書の存在は非常に大きいです。
例え文量が数十ページに及ぶ代物だとしてもです。中には資料も引き継ぎも無く仕事を始めて見事なキャッチアップを行う職員の方もいらっしゃいますが、全職員が行えるわけではありません。
組織の運営が持続的であることを目的とする以上、頼れるものは沢山あれば良いのです。可読性はさし置いて、初任者の支柱の一本にはなります。
しかし、職場では引継ぎがうまくいった職員と引継ぎがうまくいかなかった職員が必ず生じます。
そして、引継ぎがうまくいった職員は職場にも馴染む等の好循環が生じ、うまくいかなかった職員は課題を解決するためにリソースを割かれることとなり、他職員と比較してキャッチアップが遅れる場合が往々にしてあります。
※「引継ぎがうまくいくorうまくいかない」を厳密に定義付ける必要がありますが、ここではひとまず「職務を遂行する上で必要最低限の知識及びデータを現担当が適切に把握できたこと」とします。
引継ぎという職務の内実を観察すると、非常に属人化された部分であり、担当者に作成された資料の出来の良し悪しによって次の担当者の運命を決定付けることさえあります。
私の組織では引継ぎ書のチェックはされません。少なくとも属する最小限の単位の所属ではそうです。
例えば引継ぎ書に設けるべき項目がどれほどあるか、作成した引継ぎ書はどのようなものであるか等は全く管理されません。
私自身はこれはあくまでも担当者の仕事であり、管理職の管轄外という認識と理解をしています。
しかし、私自身はこれは間違いなく行政機関における業務上の歪みと考えています。
多忙な部署等や諸々事情があった際には「引き継ぎ書がない」状況が生じることもあります。しかし「引継ぎ書がある」or「引継ぎ書がない」というどちらも可能性があると言及していることがそもそも間違いなのです。
引継ぎ書は必ず作成しなければならないのです。「引継ぎ書が無い」ことはあってはならないのです。これは後任担当者の立場を不利にします。
もちろん優秀ですぐキャッチアップできる職員の方もいらっしゃいますが、体感一握りの方です。
また、個々の認知特性もあることでしょう。聴覚情報優位型の職員なら、視覚的優位の職員はこうした音声情報による情報伝達に苦手意識がある場合もあります。
また、業種経験組で今までの経験の紐づけが難しい職員なら尚更でしょう。
担当者レベルでは後任者の認知特性などは全く分かりません。ましてや年度末の直前にならない限り自分がどこに配属されるかも分からないのです。
このような制度であるならば、引継ぎ書の仕組みはある種のUD思考やインクルーシブな仕組みに則って行われた方が、よいのではないかと考えるのです。
※ここで言うUD思考やインクルーシブな仕組みとは、様式を定めて規格化することではなく、後任者の認知特性や経験から来る行動、思考特性等が担当者レベルでは共有されない（管理職は除く）点と個々の得意領域が異なるため、誰が読んでも必要な情報が伝わるような仕組みを構築しようという考え方や、どのような認知特性の方でもひとまず理解できる書き方やフォーマットを構築しようとすること、とする。
ただし、こうした指摘をすると自助努力と自己責任論の側面から指摘を受けます。
「何を舐めたことを言うな。ただ結果を出しなさい。」というようなご指摘はごもっともですし、プロとして批判は免れない側面はあるでしょう。
しかし、マウンドが整備されていなければ投手は安定した投球ができませんし、ホームベースがなければ選手も球審もジャッジができません。
私は、こうした最低限度のプレーを担保する条件がすべての部屋において整備されていないことが「フェア」ではないと言いたいのです。
公務員である限り、どの職員がこの事象の当事者になるか分からないのです。言葉を変えれば誰もがこの事象の当事者になり得るのです。それを「運が悪かった」として個々の努力で乗り越える風潮があります。
この側面を限りなく少なくすることは組織の持続性に大きく係わってくると思うのです。
（※ただ、私が非正規のために引継ぎ書の内容が少ないだけで、私はここまで課題感を持っているけれど、正規雇用の方々は研修及びOJT等があるためにここまでの課題感を持っていないという可能性もある。うーん！何だかとても虚しくなったので突き進みましょう！（白日））
幸か不幸か、私が今の任用に就いているのは部屋で休職された職員の方がいるためです。
当該職員の方は人当たりがよく、聡明で闊達な方でした。私も昨年度は別業務において大変お世話になり、非常に仕事ができる方という印象がありました。
ただ、そんな方でも休職してしまうのです。本当に仕事が多く、誰もが多忙であり、ケアをできていなかったという課題もあったと考えられます。
そもそも任用される職員の方々は基本的に優秀な方々ばかりです。
しかし誰もが皆、新しく仕事を行えるものではありません。また、職場環境も様々あります。超勤がave.80時間を超える部屋もありますし、上席や同僚も色々なタイプの方がいらっしゃることでしょう。
そうした環境的要因に引継ぎ不十分が重なった場合、心的ストレスが閾値を超えてしまう場合は往々にしてあると考えられます。
それでもジョブローテーションは公務員の制度として組まれているため、こうした状況でも職員の一人の能力で「何とかする」ことが普通であるという認識は強いと感じます。
ですが、これが公務員の常識というならば、将来を見据えた際に不合理なマインドセットではないでしょうか。
採用者については、高い意識と倫理観、そして能力を担保する必要がありますが、日本全国で人口減少している中で自治体職員に相応しい方を採用することはより一層、難しくなります。
この将来を見据えた際に、引継ぎの問題は職員一人における負担が大きいため、現在のままでは「引継ぎがうまくいかなかった職員」が出た際に離職者や業務の遅滞を招くリスク要因になる恐れもあるかと思います。
そもそも引継ぎの問題は業務が多忙であることに加え、後任者の状況や組織運営の持続可能性を射程においていないため、生じるのです。
優先順位が低いと捉えられがちですが、その実、引継ぎはＢＣＰの中核を成すものではないかと思えてなりません。※ここに他者との認識のギャップがある。
そのため、私自身は以下の事項について率直に改善すべき点なのではないか…？と思うところです。
②「引継ぎ書が作成されない」という状況の解消
（※課題として提示するなら解決策・案も同時に提示しろ！はごもっともです）
身も蓋もない話をすれば、職員にWordべた打ちでも職務のファイルパスや箇条書きを行わせることは可能と思うのです。
上記の件は民間でも同様の問題が生じていると思われます。ただ、行政機関における引継ぎの問題は余りにも良し悪しのブレ幅が大きすぎるのではないかと推察します。
これぞ属人化されている仕事です。前任者の裁量による質がブレる仕事です。
私は尊敬する管理職の方から「引き継ぎこそが公務員の最大の仕事だ」と教わりました。
しかしそう仰られた管理職の方も、この考えを周知し、各自の意識を啓発する以外に具体的な方法は取れませんでした。
※管理職の仕事がどれだけ多忙であるかを存じ上げている以上、部下が引き継ぎ書を作成しているかチェックするなんて新しい仕事を増やす訳にもいかないのです。こうした事情も少なからずあるでしょう。
そして激務部署ならば、尚更難しい部分があります。照会やら膨大なデータ処理やら議会対応、ちょくちょく法改正、突然の通知、HP更新、諸対応があるために割ける時間が無いよ…となりがちです。というかなっています。
そのため、こうした部分において、自治体においては自社LLM（源内）のようなAIが活用されて欲しいと切に願います。
どの職員についても引継ぎが適切になされるように、少なくとも引継ぎ書がない、ということが起こらないよう職員の円滑なキャッチアップに貢献できる部分やセーフティネットの構築に寄与して欲しいです。
さて、ここまで延々と述べておきながら私自身、正規職員ではありません。恥ずかしながら、私はこの採用試験が最後の機会でした。
私が志望する自治体の行政職員として、正規雇用を得る道は断たれました。
これも私の人生です。行政におけるスポットワーカーとしての価値はあれど、正規職員として長期投資されるほどの価値はなかったのです。
これを単純に試験と面接で示せなかったのです。単純なことです。
ただ、どうしても、ここまで書いておいて何故か筆を折れないのです。なぜか。どうしてなのでしょうか。
理由は分からないです。ただ、世の中は本当に可笑しい。つくづく可笑しいものだと思わないとやっていられません。
ここからは非常に私的なことになりますが、どなたかの役に立つのであればと思って記します。
採用試験に落ちた職場で働くことが、どれほど悔しいか、狂いそうになるか、想像はすれども経験するまでそのおぞましさは分かりませんでした。
しかし、あれは明らかに人生において絶対に経験すべきことではないことの一つです。
ただ、私は早まることはせず今の業務に注力し続けて私自身の能力を高め、できることを一つでも多くしていくしかないのです。でも私はこの先、どこでどのように生きているのか、そしてどうあればよいのか、今のところ全く想定ができないのも事実です。否応なしに他者と比較しては「誰一人君の替わりはいないけど上位互換が出回っている」という有名な短歌が頭をよぎります。
つまるところ、公に携わりつつも、社会の薄暗い日陰への緩やかな坂道を下っています。
ただ、この日々の中であとどれだけ言葉を遺せるのかも、私に与えられた使命でしょうし、ここに至るまでに培ってきた、いや、培わざるを得なかった私の目でしか見ることのできないものたち、そして見ざるを得ないものたちが多々あることでしょう。そう思わないとやっていけませんよ、本当に。
「結局のところ10,000文字を書いて行政職のちょっとした批判を交えて大事な私が「悔しい」「挫折した」と言いたかったのですねぇ」と要約されたら私は静かにキレ散らかすことでしょう。
本当に報われないことばかりの人生ですけれど、それでも生きてはいるんですよ。偉いでしょう？。でも「ね？簡単でしょう？」なんて言えないですよ、本当に。
ただ辞めていないだけなんですよ。これから先に転がっていくしかない坂道があるっていうのに、親は年老いて介護もしなければならないのに、ひとまず今が無茶苦茶なのに、とりあえず今をぷつんと切ることはせずに世の中におけるお勤めを果たしているんです。
机の上にいつでも取れそうなハサミがあって、毎日その姿が視界に入るのですけれど、張りつめた弦がここまで張っているのをちょきんと切るのは何だかできなくて、結局ここまで来ているんです。
それで、弦が張りつめていると神様か誰かが知らないけど、突然隕石みたいなピックで弦を弾くんですよ。
猛烈に狂わせにきてますよ。もう止めてくれ、何でこんなって思うんです。でも、その時にストラディバリウスやカルザスのチェロなんか目じゃない音が鳴るんですよ。
それが自分自身の音なんです。誰が聞いても酷い音で、それこそ整理された整った綺麗なものではないけれど、自分にしか出せない音なんですよ。
誰が生きてもこの音は出せない、これは絞り出せないって分かるからどうしてか、この弦は切れないんです。
これを確認するために書いていたんですよ。長ったらしい文章になってしまって本当に申し訳ない。
2年前の新卒をOJT教育という名目で、技術的なことをもろもろと教えたり実装してもらったりして、当時はフレッシュな感じで生き生きとしていた。
いま担当しているプロジェクトにその当時の新人(今は3年目の若手)がいるのだが、やはり会社の負の部分に染まってしまったのだなと感じた。
・チーム間でコミュニケーションがない (というか良くも悪くも放任主義)
・新人は欲しいというリクエストはあるが、そもそもリクエストした上司や管理職がどうコミュニケーションしたら良いかが分からない
・若手が上司から言われたことを、どう対応したら良いかが分からない
・カレンダーに予定を入れない
・ポジティブさがなくなっている
・顔色が悪くなっている
・ポジティブさとか顔色を置いておいて、「注意をすると上司経由にしてもらえます」と反論してくる
※(自分で言うのも良くないけど)管理職から新人まで、転職したら活躍できなそうな人が多い。
まあ、中堅は大変なのである。
2026年春、短期間に複数の情報漏洩炎上が相次いだ。西日本シティ銀行の行員による顧客情報の流出、病院・学校・大手企業での内部資料の露出——いずれもSNSアプリ「BeReal」が引き金となった事案だ。
こうした炎上が起きるたびに、日本社会は「個人の意識の問題」として処理する。当事者を叩き、企業が謝罪し、「再発防止を徹底する」という定型文が出て、やがて忘れられる。しかし同種の事案が繰り返されるという事実が、この処理の仕方そのものの失敗を示している。
本稿で問いたいのは、なぜ日本でだけこれが繰り返されるのか、という点だ。そしてその答えを、「管理の不在」と「私刑による補完」という逆説的な構造に見出したい。
まず前提として確認しておきたいのは、BeRealの仕様が特別に危険というわけではない、という点だ。
確かにBeRealは1日1回のランダム通知から2分以内に即投稿を求める設計であり、「考える時間を奪う」という批判はある程度妥当だ。しかしBeRealには「Late投稿」という機能があり、通知を無視して後から投稿することも可能である。反射的に投稿しなければならない強制力はない。
より根本的な問題は、職場での私物スマホの扱いにある。BeRealがなくても、スマホを持ち込める環境と撮影を思いとどまらせる仕組みがなければ、同種の事故はInstagramでもTikTokでも起きる。実際、今回の炎上事例を見ればNTT東日本の事案ではInstagramのストーリーズも同時に問題になっている。
BeRealは問題の「引き金」ではあっても「原因」ではない。この区別が重要だ。
同様の事例が海外ではほとんど問題化していない。BeRealはフランス生まれで欧米でも普及していたが、職場での情報漏洩炎上として報じられた事例は見当たらない。なぜか。
最も説得力のある説明は、欧米の機密情報を扱う職場では私物端末の持ち込み自体が物理的・規則的に制限されているという点だ。GDPRをはじめとする法的枠組みが組織に厳格な情報管理を義務づけており、「個人の意識」に依存する前に環境が設計されている。
翻って日本の銀行営業店では、顧客の氏名や営業目標がホワイトボードに書き出され、新卒行員がスマホを手にしたままそれを日常的に目視できる。この環境設計の時点で、情報漏洩のリスクはすでに内在している。BeRealの通知はそのリスクを偶発的に顕在化させたに過ぎない。
問題が日本に集中する理由は、日本の組織が情報管理を「システム」ではなく「個人の自覚」で担保しようとしてきたことにある。
なぜ日本の組織はシステムによる管理を怠ってきたのか。ここに日本型雇用の構造的な問題がある。
情報セキュリティの基本原則に「最小権限の原則（Principle of Least Privilege）」がある。その人の業務に必要な情報にしか触れさせない、という考え方だ。これを実装するには、誰がどの情報にアクセスすべきかを職務ごとに定義する必要がある。
ところが日本の新卒一括採用は、職務を定義する前に人を採用する。「この仕事のためにこの人を雇う」ではなく「この会社のメンバーとして雇う」という発想なので、権限の範囲が職務に紐づかない。全員が同じスタートラインに立つという建前が、権限設計を不可能にしている。
加えて、同じ採用プロセスを経た全員が同じ水準のリテラシーを持つという暗黙の前提がある。実際にはリテラシーは個人差が大きく、職種・業務内容によって求められる判断能力も異なる。「研修で周知する」という対応は一見平等に見えて、実態はリテラシーの低い人間に高度な自己管理を要求するという無理な設計だ。
均質に扱うことが、かえってリスクを生む。これが「悪い意味での平等」の正体である。
ここで本稿の核心に入る。
日本の組織が情報管理をシステムで担保しない一方で、問題が起きたときに機能するのがネット上の「私刑」だ。クローズドなSNS投稿のスクリーンショットが瞬時に拡散され、特定班による個人情報の発掘、実名・顔写真の晒し、SNSアカウントの掘り起こしが組織的に行われる。
これは国家や企業による「上からの監視」ではない。市民が市民を監視・制裁する「横からの相互監視」だ。
逆説的なのは、この相互監視が組織の管理不全を補完する機能を果たしているように見える点だ。組織がシステムで防げなかったことを、事後的にネット民が制裁するという構造が出来上がっている。企業は謝罪文を出して幕引きし、当事者個人がネットの私刑を受ける。組織の設計責任は問われないまま、個人だけが燃やされる。
欧米では問題が起きても法的手続きで処理されるのに対し、日本ではネット上の私刑が事実上の社会的制裁として機能する。上からの管理が緩いほど、横からの監視が過剰になる——この逆説が、日本のSNS炎上に繰り返し見られる構造だ。
この構造が持つ最大の問題は、制裁の重さが行為の重さと全く釣り合わない点だ。
今回の当事者たちが受けた被害——実名・顔写真のデジタルタトゥー、過去のSNS投稿の全掘り起こし、勤務先・住所の特定、無期限の晒しと嘲笑——は、新卒の若者が「反射的にスマホで撮影して投稿した」という行為に対して著しく不均衡である。
問題をさらに複雑にするのは、この制裁に終わりがないという点だ。法的な手続きであれば時効があり、処分には上限がある。しかしネット上の私刑には期限がない。検索すれば半永久的に出てくる。「デジタルタトゥー」という言葉はまさにこの永続性を指している。
一方で、組織側の責任——スマホを持ち込める環境を放置したこと、権限設計を怠ったこと、教育をOJTに丸投げしたこと——は「再発防止に努める」という一文で免責される。個人が過剰に燃え、組織が軽く済む。この非対称性は偶然ではなく、構造的に生産されている。
BeRealが照らし出したのは、アプリの危険性でも当事者の愚かさでもない。「管理をシステムで行わず個人の自覚に委ね、失敗した個人を私刑で燃やす」という日本社会の処理構造だ。
この構造が維持される限り、引き金がBeRealであろうと次の何かであろうと、同じことは繰り返される。そして繰り返されるたびに、誰かの20代が終わる。
BeRealの「2分間投稿縛り」という仕様の問題だとか、Xをやっている人間の方が情報の取捨選択に長けているだとか、色々と語られているが
まず、この手の「閉鎖的・特権的な空間」を可視化するSNSのルーツを辿れば、前略プロフィールやmixiに行き着く。
あくまで身内向けのコミュニティでありながら、個人情報や写真を共有して悦に浸る場所だ。
その後、インスタのストーリーズのように「一定時間で消える」機能が一般化したが、20年ほど前の「2ちゃんねる」や「mixi」が玉石混交だった時代とは、ユーザーの前提が根本的に違う。
かつて、クラス単位でこうしたツールを使い倒していたのは、昭和の最後～平成一桁生まれの世代だ。
完全に個人的な肌感覚だが、この世代の「まともな人間」は、FBやTwitterを一度は触ってみるものの、リスクを察知して早々に身を引いている。
今回、おそらくそれなりの大学を出て、それなりの組織に属する人間たちが立て続けに不祥事を起こしている背景には、売り手市場による「質の低下」もあるだろう。
だが、彼女たちの行動原理を推測すると、より根深い問題が見えてくる。
BeRealには「2分以内に投稿しなければならない」というルールがある。
別に真っ暗な画面を撮って上げれば回避できるはずなのに、彼女たちはそれをしない。
それをしないのは、彼女たちの中に「クランの掟」への忠誠心があるからだ。
それと同時に、「今の自分は特別な場所にいる」という優越感を、無意識のうちにグループ内で示したいという承認欲求が、理性を上回ってしまう。
これに拍車をかけたのが、コロナ禍による物理的な社会的摩擦の減少と、過剰なまでのハラスメント教育。
本来、人間は人前で叱られたり、恥をかいたりすることで「公共」と「私的」の境界線を学ぶ。
最近めっきり聞かなくなったが、それがかつて「TPO（時間、場所、場合）」と呼ばれていたものだ。
過剰に保護され、現実の社会摩擦に晒される経験を奪われた彼女たちは、「社会から自分がどう見られるか」という客観的な視点を養う機会を永遠に失ってしまった。
※永遠に、とは言いすぎかもしれないが、もう彼女たちにそれを教えてくれるお節介な人間は軒並み消えている上に、おそらく彼女たちは忠告を聞き入れるつもりがない。
彼女たちにとって、人生は常に誰かに見られていることがデフォルトだ。自宅、通勤中、そして勤務中。
本来、気を張っているべき「オン」の時間に、SNSという「オフ」の感覚が溶け込んでくることに、何の抵抗も抱かない。
ブラウザ経由でネットに触れ、2ch、mixi世代の洗礼を受けた「90年前後生まれ」と、
物心ついた時からスマホが身体の一部だった「2000年前後生まれ以降」の間には、マリアナ海溝よりも深い溝があるように思う。
とまあAI生成の適当な考察を並べてみたが、これはリテラシー教育でどうにかなるレベルではない気がする。
ある意味、氷河期世代よりもかわいそうな世代なのかもしれない。
だって、子供の頃に経験しておくべき摩擦で学ぶことは、一体誰にどうやって教わる？
炎上して怒られてからじゃないと学べないのなら、そんな人間怖くて採用できないでしょ。
本人はたったスマホで撮影しただけ、何が悪いの？という感覚でいて、OJT、課長、支店長は飛ばされちゃうのにね。
動画で取られている同期か先輩社員見た？「辞めてよ～笑」って感じで叱ってもくれてないじゃんね。
新入社員が入るたびに、爆弾持たされた～という感覚で一生懸命、優しく、辞めないように根気よく説明・教育できる？
というより、たぶん教育でどうにかなるような問題じゃないんだ、これは。
だって情報リテラシーや社内規定や社会規範なんかより、SNSという謎のクランの掟や承認欲求を満たすことの方が優先順位が高いんだから。
プログラマとそれ以外の人って世界の捉え方からして違いすぎて、そのギャップが毎日嫌になる。プログラマってパソコンが存在しなくてもプログラマなんやなって毎日思う。以下、嫌な点の列挙
・プールプルーフの考え方がない。あらゆる分野のエンジニアは、「人は基本的にヒューマンエラーを起こす無能」という前提で環境を作るが、そうでない人は、啓蒙したり、ミスを叱って気を引き締めさせることで解決する。（特に私はヒューマンエラー多めの人間なのでつらい）
・カプセル化や疎結合を意識していない。部署ごとの役割の境目が曖昧なので、たしかに「他部署のミスを発見できる」とか「例外的なことが起こった時に融通が利く」のようなメリットはあるが、他部署の都合も把握していないといけないと、意識すべきことが膨大になる。
・水平思考ができない。自分の主観はいつだって正しくて、押し付けて良いと思っている。プログラマは常に「自分は間違ったことや、ソースがないことを喋っているかもしれない」と気をつけて喋っているというのに！ 主観と主観がぶつかったときは常に、地位が高い方の主観が正しい。
・業務の持続可能性をついて考えていない。業務の全容は人の脳内にあり属人的で、業務内容を次世代へ引き継ぐときもフローチャートや手順書に起こしたりしない。OJTでは、知識が必要になったり、例外的な事が起こったら、場当たり的に知識を教える。知識を断片的に、枝葉から順番に覚えることになる。（なんなら、そうやって業務内容を容易に理解させない事で、属人的な業務をこなしている上司の威厳や上下関係を担保しているのではと疑いたくなる）
・弊社ではようやく「手順書を書こう」というムーブメントが起こり始めているのだけど、みんな（プログラマと比べて）命令を厳密に記述するのがド下手。「ここまで書けばわかるでしょ」という、複数の解釈ができてしまう記述や、前提知識を多分に要する記述が多い。というか手順書に限らず普段のOJTでもそう。
・エンジニアの「チョットワカル」の精神がない。なんでもいいので学問を１つ本気で学んだことがある人はみんな「自分は途方もないくらい無学だ」ということをわかっていて謙虚なのだが、そうでない人は傲慢で、「新人の方が自分より業務内容に詳しい」という状態が許せない。
・新人が、プログラミングであらゆる既存のルーチンワークを解決できることが実証されると、（そのルーチンワークをしている自分の尊厳が失われるためか）集団で無視する。
プログラマとそれ以外の人って世界の捉え方からして違いすぎて、そのギャップが毎日嫌になる。プログラマってパソコンが存在しなくてもプログラマなんやなって毎日思う。以下、嫌な点の列挙
・プールプルーフの考え方がない。あらゆる分野のエンジニアは、「人は基本的にヒューマンエラーを起こす無能」という前提で環境を作るが、そうでない人は、啓蒙したり、ミスを叱って気を引き締めさせることで解決する。（特に私はヒューマンエラー多めの人間なのでつらい）
・カプセル化や疎結合を意識していない。部署ごとの役割の境目が曖昧なので、たしかに「他部署のミスを発見できる」とか「例外的なことが起こった時に融通が利く」のようなメリットはあるが、他部署の都合も把握していないといけないと、意識すべきことが膨大になる。
・水平思考ができない。自分の主観はいつだって正しくて、押し付けて良いと思っている。プログラマは常に「自分は間違ったことや、ソースがないことを喋っているかもしれない」と気をつけて喋っているというのに！ 主観と主観がぶつかったときは常に、地位が高い方の主観が正しい。
・業務の持続可能性をついて考えていない。業務の全容は人の脳内にあり属人的で、業務内容を次世代へ引き継ぐときもフローチャートや手順書に起こしたりしない。OJTでは、知識が必要になったり、例外的な事が起こったら、場当たり的に知識を教える。知識を断片的に、枝葉から順番に覚えることになる。（なんなら、そうやって業務内容を容易に理解させない事で、属人的な業務をこなしている上司の威厳や上下関係を担保しているのではと疑いたくなる）
・弊社ではようやく「手順書を書こう」というムーブメントが起こり始めているのだけど、みんな（プログラマと比べて）命令を厳密に記述するのがド下手。「ここまで書けばわかるでしょ」という、複数の解釈ができてしまう記述や、前提知識を多分に要する記述が多い。というか手順書に限らず普段のOJTでもそう。
・エンジニアの「チョットワカル」の精神がない。なんでもいいので学問を１つ本気で学んだことがある人はみんな「自分は途方もないくらい無学だ」ということをわかっていて謙虚なのだが、そうでない人は傲慢で、「新人の方が自分より業務内容に詳しい」という状態が許せない。
・新人が、プログラミングであらゆる既存のルーチンワークを解決できることが実証されると、（そのルーチンワークをしている自分の尊厳が失われるためか）集団で無視する。
高卒で缶詰工場で働いてて、給料も全然上がらないし、思い切って、やりたかったWebデザインの仕事に転職してみた
昔ちょっとだけ勉強したことがあったから、どうにかなるだろうと思ってたら、未経験可、何か作品を提出すればokって求人を見つけた
仕事でやってたわけでもないし、出せる作品なんてなかったんだけど、AIを使ってみたらすぐにそれっぽいサイトが出来たから、それを提出したから採用された
OJT で教えてくれるって言うから余裕だろうと思ってたら、会社の求めてるレベルよりもあまりにもレベルが低かったらしく、すぐに OJT は取りやめで、研修というなのお勉強だけになった
三ヶ月みっちり教えてもらったら何か出来るようになるかと思ったんだけど、そもそもパソコンの使い方も仕事レベルに達してなかったらしく、試用期間が一ヶ月延長された
それに、転職と同時に一人暮らしを始めたせいで、誰も朝起こしてくれなくて、かなりの頻度で遅刻してしまい、もう試用期間の延長も出来ないし、会社都合で良いから、頼むから辞めてくれってことで退職した
あとで聞いたら、教育を担当してくれた社員さん達が口を揃えて、頼むからクビにしてくれってお願いしてたらしい
次はどんな仕事しようかな
全てを否定するわけじゃないが、前提として教える環境、マニュアル、体系化、その他があって初めて機能するもんなんだよ
でも大半はマニュアルとか体系はおざなりにしてとりあえずやりながら覚えよ？ってスタンスで採用する
どうなるか
教える側がしっかりと理解できていないから、OJTはほんとうにその場限りの対応に成り下がり、再現性など担保されるはずもない
問題に気付いている人も多いはずだが、形ばかりのOJTはなくならない
なぜか
自分も教えてもらえなかったから、マニュアル作成工数は自分の評価に何ら関係ないから
そりゃあまともなマニュアルができるはずもないわな
だからしっかりしたマニュアルを作成した奴は評価する、インセンティブを与えるなどしないとダメなわけだ
ここで新たな問題が生じる
いなきゃ作るしかない
みんな頑張って行こうぜ
そこそこの規模の会社でITエンジニア（社員）がやってる業務の一覧（全部ではない）
| 組織レベル | タスク | AI親和性（予想） |
| Lv0：個人〜最小チーム | コーディング（実装） | 🟢 早期に大部分自動化 |
| 単体設計（クラス/API） | 🟢 早期に大部分自動化 | |
| テストコード作成 | 🟢 早期に大部分自動化 | |
| リファクタリング | 🟢 早期に大部分自動化 | |
| ログ調査・軽微なバグ修正 | 🟢 早期に大部分自動化 | |
| Lv1：役割分離（PM/Design等） | 仕様書ドラフト整理 | 🟡 補助的に自動化 |
| 要件の解釈・曖昧さ発見 | 🟡 補助的に自動化 | |
| UI/BE責務の切り分け | 🟡 補助的に自動化 | |
| PMとの仕様すり合わせ | 🟡 補助的に自動化 | |
| QAとの再現条件調整 | 🟡 補助的に自動化 | |
| チーム内認識合わせ | 🟡 補助的に自動化 | |
| Lv2：チーム間連携 | API境界整理 | 🟡 補助的に自動化 |
| モジュール責務設計 | 🟡 補助的に自動化 | |
| 影響範囲分析 | 🟡 補助的に自動化 | |
| Feature Flag運用判断 | 🟡 補助的に自動化 | |
| 他チームとのリリース同期 | 🟡 補助的に自動化 | |
| Lv3：組織運営（10人〜） | 技術調査（SaaS/AWS等） | 🟡 補助的に自動化 |
| 技術選定 | 🟡 補助的に自動化 | |
| 非機能要件の検討 | 🟡 補助的に自動化 | |
| ADR作成 | 🟡 補助的に自動化 | |
| KPI→開発優先度変換 | 🟡 補助的に自動化 | |
| 事業計画→技術タスク分解 | 🟡 補助的に自動化 | |
| Lv4：人間系（組織的責務） | 採用（面接・評価） | 🔴 自動化ビジョン不透明 |
| 育成（OJT・レビュー文化） | 🔴 自動化ビジョン不透明 | |
| 勉強会・ナレッジ共有 | 🔴 自動化ビジョン不透明 | |
| 社内技術広報 | 🔴 自動化ビジョン不透明 | |
| チーム間政治調整 | 🔴 自動化ビジョン不透明 | |
| 炎上時の説明責任 | 🔴 自動化ビジョン不透明 | |
| Lv5：プロジェクト外部接続（受託/SI） | 顧客折衝 | 🔴 自動化ビジョン不透明 |
| 契約仕様の解釈 | 🔴 自動化ビジョン不透明 | |
| 外注管理 | 🔴 自動化ビジョン不透明 | |
| 稟議資料作成 | 🔴 自動化ビジョン不透明 | |
| SLA調整 | 🔴 自動化ビジョン不透明 | |
| ベンダー管理 | 🔴 自動化ビジョン不透明 |
AIがプログラミングできたくらいではまだ「残業を減らす」程度でしかなくなる
コロナ禍を契機に全社的にフルリモートが可能になった職場だった。
もちろん、顧客先に行かないとできない仕事、セキュリティの関係からプロジェクトルームでしか作業できない仕事もある。
そのような業務に就いている方は当然出社されていたが、それ以外は現場判断で週5リモートも可能だった。
---
私は地方の政令指定都市に拠点を置く、総勢30名ほどの部門に配属された。
部長1名の下に、課長+10名程度のメンバーからなる「チーム」が配置されている。
業務は基本チームの中で完結し、業務におけるチーム間の関わりは多くない。
同僚が10名程度、その中の若手1人がOJTの教育担当、という体制で私のビジネスライフはスタートした。
最初は教育担当の先輩を追いかける形で業務を覚え、OJT期間終了までにはエンジニアとして自走できるようになる。
はずだった。
---
現実は違った。
仕事がない。
焦りと不安が心を蝕んでいく。
気づいた時には、もう、私の精神状態は限界一歩手前まで来ていた。
精神が壊れる前に心臓を病み、ドクターストップがかかったのが不幸中の幸いだった。
---
断定できるものではないが、大きく次のような要因があると考えている。
---
私のチームでは、業務上必要な場合以外はフルリモートが可能だった。事業所に出社するのは、物理的に機器等を触る必要がある場合、対面での手続きが必要な場合、部門レベルでの会議が開催される場合。あるいは顧客先に行く際、前後の時間で出社する場合。そのような機会は多くても毎週あるかないかという程度だった。
その結果、私と同僚の間で、特に配属初期のコミュニケーションが大幅に不足し、関係性を構築できなかった。
---
それに拍車をかけたのが、業務体制だった。課長1人の元で10名程度のメンバーが稼働していたが、単一のプロジェクトに関与しているのは2-3名程度。一人が複数のプロジェクトを掛け持ちしていることも当たり前にあった。チーム全体でコミュニケーションを取る必要性は極めて限定的で、関与するプロジェクト内で意思疎通ができていれば業務上十分な環境だった。そのような環境に新人が一人入ってきても、同じプロジェクトに関わらない限り、コミュニケーションを取る必要もなかった。
また、プロジェクトのオーナーシップにも原因があった。チーム内で複数のプロジェクトが稼働しているが、各プロジェクトの（実質的な）監督はプロジェクト担当者に一任されていた。チームとしてプロジェクトを受注し、課長の名の下でメンバーをアサインする、という形態はよく耳にする。しかし私の職場では、各プロジェクトの受注から納品まで特定のメンバーが指揮権を持ち、課長は意見を述べる程度の関与しかしていなかった（勿論、社内事務上必要な決済などには関与する）。
私が課長に「仕事が欲しい」と相談しても、課長にできることは「各メンバーに対し、新人をプロジェクトにアサインするよう依頼する」ことだけであり、現場のプロジェクトリーダーがNOといえば、それまでなのだ。あとは私がプロジェクトリーダーと直接交渉し、アサインしてもらえるよう説得しなければならない（課長からも、そうするよう言われていた）。とはいえ、普段からコミュニケーションをとっているわけでもなく、何なら顔を合わせたことも数回しかない。先方も、私が持っているスキルを知らないし、人手が不足しているわけでもないのでアサインする理由も義理もない。「お仕事をください、私は〇〇ができます、事務作業だけでもいいです、お仕事を…」と何度乞うただろうか。
---
恒常的な環境要因として1, 2を挙げたが、私のケースでこれらの要因を軽減できなかった理由には、OJT期間の体制という問題もあったように思う。
OJTの教育担当を務めてくれた先輩は、私のチームの中でもやや特殊な立ち位置だった。他メンバーが2-3名のプロジェクトを推進している一方で、この先輩はおおよそ1人でプロジェクトを回し、必要に応じて協力会社への発注を行なっていた。技術的にも他のメンバーとは距離があり、プロジェクトという観点で他のメンバーとの関わりは少なかった。
OJTの教育担当としてこの先輩に面倒を見ていただいたが、逆に全てが先輩に一任（丸投げ）されていた。私が他のメンバーとのプロジェクトに関わる機会は特段計画されなかったし、その計画や調整もまた先輩に一任（丸投げ）されていた。先輩も暇ではない。私が他のプロジェクトに関われるよう根回しをしている余裕があるはずもなく、私のOJT期間のほとんどは、この先輩とのプロジェクトで終わってしまった。
---
「新卒でフルリモ可のJTCに入社し速攻詰んだ話」と言ってフルリモートのネガティブキャンペーンをするには、他の要因も多々ありやや不適切なことは承知しているが、せめて初日からメンバーの顔が見れて声をかけられる環境にあれば、精神を壊し心臓を病むこともなかったのではないか…と思う。
そして何よりも、このチームで過ごしたN年間は何だったのだろうか！と慟哭せずにはいられない。気づけば「新人」というラベルも、「第二新卒」という選択肢も失った。別の環境に飛び込み再起を図ること能わず、特段成長したこともなく、ただ周囲から向けられる目線が冷たく鋭くなっていくだけである。かといって今の環境に留まることを選んでも、私がエンジニアとして生きていけるだけの仕事はない。
フルリモート可の職場が私に与えてくれたのは、一生回復することのない心身の喪失と、目的もなくPCの画面と窓の外に見える雲を交互に眺める、果てしなく長く感じられる8時間だけである。
