エンジニア実録

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

はじめに システム開発の現場では、進捗が思わしくない部下に対して上司が厳しい言葉をかける場面は珍しくありません。 しかし、それが「暴言」の域を超えてしまうケースも、残念ながら実際に存在します。 この記事では、大手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は言葉を失い、他の参加者たちも誰一人フォローの言葉を発することができなかった。 会議室には、しばらく重苦しい沈黙だけが流れた。 令和のこの時代に、しかも社外の関係者が多数同席するオンライン会議の場で、このような発言が飛び出したことに、参加者全員がドン引きしたのは言うまでもない。 解説 令和になってから労働環境の改善は大幅に進み、今回のような露骨なハラスメントは以前に比べて少なくなってきました。 それでも、まれにこうした暴言を吐いてしまう方が存在します。 そして厄介なことに、その場に居合わせても、当然のように誰も彼を諫める人はいません。 大手企業に勤め、高年収で安定した立場にありながら退職を選ぶ方がいるのは、こうしたハラスメントの存在も一因なのかもしれません。 一方で、性分的に熱くなるとつい汚い言葉を使ってしまう人はどこにでもいるのも事実です。 罵声を言葉通りに真正面から受け止めて思い悩むのではなく、「夏になったらセミが鳴くようなものだ」くらいに捉え、いちいち気にしないというメンタリティを持つことも、必要なのかもしれません。 とはいえ、それでもどうしても理不尽な環境に耐えられないという方は、無理をする必要はありません。 退職や独立も、有効な選択肢の一つです。 おわりに 世の中には、様々な企業やそこで働く人が存在し、常識では考えられないような出来事が実際に起こり得ます。

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

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

はじめに 中四国地方には中小企業が多く、清掃員を雇う予算を確保できない企業も少なくありません。 そうした企業では、清掃業務をエンジニアや事務職を問わず、全従業員で協力して実施しているケースがあります。 この記事では、地方の中小企業に実際に存在する「掃除事情」を紹介します。 中小企業の掃除事情 定時後・休日の清掃強要 会社によっては、定時後の業務時間外や休日に掃除をするよう強要されることがあります。 掃除は業務として認められず、サービス残業扱いになってしまう会社もあるようです。 トイレ掃除は当番制 トイレ掃除が順番制になっている会社もあり、当番の日は業務の合間を縫って清掃を行う必要があります。 昔は客先に出向しているエンジニアも、掃除のためにわざわざ早朝7時に出社して掃除するケースもあったそうです。 年末の大掃除もサービス残業に 年末には従業員総出で本社の大掃除を行う企業が多々ありますが、こちらもサービス残業になるケースがよく見られます。 就業規則に記載がある会社も 就業規則に「〇〇時から社内清掃をしなければならない」というルールが明記されている会社さえあるほどですが、実際には業務が忙しい人はやっていない、という運用の緩さも見られます。 持ちビルの清掃をさせられるケースも 遺族経営で不動産事業も手がけている企業の中には、従業員に自社所有のビルを清掃させることで清掃コストを削減しているケースもあるようです。 解説 掃除も企業経営において必要な作業であることは間違いありません。 しかし、その時間に他の技術者がスキルアップに時間を充てていることを考えると、掃除の負担が大きい会社にあえて入社すべきかどうかは、よく考えたほうがよいでしょう。 本業以外の業務に長時間従事することにストレスを感じる方は、入社前に清掃業務の有無や負担度合いを確認しておくことをおすすめします。 サービス残業扱いになっているかどうかも、労働条件を判断するうえで重要なポイントです。 おわりに 世の中には、業務とは直接関係のない清掃業務を従業員に負担させている企業が実際に存在します。 しかしAIやアウトソーシングの活用が広がる中で、こうした非効率な運用を続ける企業は、今後人材確保の面でも不利になっていく可能性があります。 もし今の職場の清掃負担に疑問を感じているなら、転職やフリーランスとして独立するなど、環境を変えることも検討してみる価値があります。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 社会人になれば、会社という組織はきちんとルールに則って運営されているというイメージを持つ人は多いのではないでしょうか？ しかし現実には、社内の意思決定プロセスが曖昧なまま放置され、従業員が振り回されてしまう会社も存在します。 立場が上だから、総務だからといって、必ずしも合理的な対応をしてくれるとは限らないのです。 本記事が、会社という組織を過信せず、自分の権利や手続きについて主体的に確認する姿勢を持つきっかけになれば幸いです。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 社員寮の退寮手続きだけで2ヶ月以上かかるトンデモ会社 通勤時間短縮のための退寮相談 これは、とある神奈川県のSES会社での話です。 この会社では従業員に対して、会社近隣のアパートを社員寮として提供していました。 ある新人社員Aさんは、社内勤務から客先常駐に配属が変わったことで、社員寮からの通勤に時間がかかり過ぎるようになり、退寮を検討します。 就業規則や寮規則には退寮に関する規定がなかったため、退寮が可能かどうか、可能な場合はどのような手順を踏めばよいかを直属の上司に確認しました。 すると、上司からはこんな反応が返ってきます。 上司😕：「会社の方針として、若手が社員寮を出るのはあまり良く思われていないんだよね……」 はっきりした理由は語られず、曖昧な物言いでしたが、話によると、過去には女性社員が「ユニットバスが嫌だ」という理由で退寮を申し込んだものの、否認された前例もあったそうです。 その後、上司から 上司:「取り敢えず、総務部に確認のメール送信して」 新人A😐: 「分かりました。」 指示を受けたAは、退寮を検討している理由と、手続きが可能かどうかを総務部・上司・課長宛にすぐにメールで送信しました。 新人A😳:「通勤時間短縮のために退寮を検討してます、退寮できるかどうか確認したいです📨」 噛み合わないコミュニケーション ところが、何故か総務部は新人Aに返信せず、上司と、課長にのみメール返信しました。 総務からの指摘を受けた上司は新人Aに以下のように指摘しました。 上司😠：「なんでメールを総務部に送ったんだ。」 新人A😳 ：「え、先ほどメールを送信するように指示を受けたので。。。」 上司😠：「今送るとは思わなかった。」 新人A😳 ：(いつだったらいいんだよ) Aさんとしては、上司から総務に確認するよう指示されたため、すぐに送信しただけです。 内容的に何時送信しても特に問題ないような内容ですが、何故か上司から叱責をうけ、さらにいつ送信すればよかったのかは最後まで明かされませんでした。 また、総務部からの返信内容は一切新人Ａには共有されず、どうも会社側が何かひた隠ししているような状態でした。 その後、会社が月末に実施ている帰社報告会で、課長・上司と対面で話し合いの上、方針を決定することになりました。 これにより退寮は1ヶ月先延ばしになりました。 帰社報告のドタキャン ところが、帰社報告の日に課長も上司も欠席していることに気づきます。 新人A😐: 「課長も上司もいないな。。。」 社内の別の社員Bに聞いて回ったところ、以下のように教えてくれました。 新人A😐: 「課長と上司って今日出社してます?」 社員B😅：「上司さんは業務都合で休み、課長はプライベートの都合でお休みだって。」 新人A😐: 「。。。」 新人Ａに連絡がなく、ドタキャンされてしまったため、帰社報告では方針を決められず、さらに1ヶ月ほど時間が過ぎていきました。 社内で見えてきた「本音」 社内やインターネットで似たような事例を調べてみると、社会人経験の浅い新人が退寮すると金銭面でのトラブルを起こすリスクがあることから、総務部が寮に留めておきたがる、という噂があるそうでした。 一方で、新人でも実家からの一人暮らしに切り替えた社員は特に総務から指摘がなかったことから、上記は表向きの理由は本音は以下の理由だと推測しました。 住宅手当を支給するより、社員寮を維持する方が会社にとって節税効果が高い 退寮時期が中途半端だと、不動産会社への賃料を余分に支払う必要が生じる そこで新人Aは、退寮時期や、移住先の物件の賃料は会社の希望に合わせられること、通勤経路が短くなれば通勤手当の支給額も減り会社側にもメリットがあることを提案してみることを検討しました。

はじめに バージョン管理システムのGitは、今や多くの開発現場で当たり前に使われている技術です。 しかし、Gitが導入され、メンバー全員が使えるにもかかわらず、なぜか誰も使おうとしないという不思議な現場も存在します。 この記事では、国内屈指の大手企業のプロジェクトで実際に起きた、Gitを意地でも使わない現場の実話を紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 Gitを意地でも使わないプロジェクト これは、国内屈指の大手企業が発注するシステム開発プロジェクトでの出来事。 このプロジェクトでは、Gitがすでに導入されており、メンバーも一通りコマンドを扱える状態だった。 つまり技術的な障害は何もない。それでも、なぜかチームの誰もGitを積極的に使おうとしなかった。 あるとき、新しく参画したエンジニアCが、レビューの進め方について尋ねた。 紙でのソースコードレビュー エンジニアC 🙂 「プルリクエストって、どうやって出せばいいですか？」 ベテランエンジニアD 😐 「プルリクエスト？ うちはそういうのやってないよ。」 聞けば、このプロジェクトのコードレビューは、WinMergeで差分を取り、その画面をExcelに貼り付けて印刷し、紙で行うのが慣例だという。 エンジニアC 😳 「え、印刷して紙でレビューするんですか……？」 ベテランエンジニアD 😑 「その方が見やすいでしょ!!」 半信半疑のまま、エンジニアCは初めて紙でのレビューを受けることになった。 WinMergeの差分画面をExcelに貼り付けて印刷したものをベテランエンジニアDに提出し、確認を待つ。 数分後、ベテランエンジニアDが眉間にしわを寄せながら紙を持ってやってきた。 ベテランエンジニアD 😠 「ちょっと、これ変更したところの色が分かりづらいよ」 エンジニアC 😕 「え、色、ですか……？」 ベテランエンジニアD 😡 「見づらいだろ！ 」 エンジニアC 😥 （Gitがあるのに、なぜ紙の色使いで怒られているんだろう……） 結局、エンジニアCはその場で色設定を変更し、WinMergeの差分をあらためて印刷し直すことになった。 ブランチ一本化戦略 さらに話を聞くと、開発は複数人が並行して進めているにもかかわらず、ブランチはほとんど使われていないという。 エンジニアC 🤔 「複数の機能が開発同時進行してるから、ブランチ切った方がいいんじゃないですか？」 ベテランエンジニアD 😠 「ブランチが複数あると煩雑になるから、うちは一本化でいくことにしてるんだ。」 一本化とは、つまり全員がひとつのブランチに直接手を加えるという運用のことだった。 エンジニアC 😨 （それ、実際の開発が並列で進んでいるんだから、ソース管理するの放棄して、現実逃避しているだけでは…） 案の定、コンフリクトは発生したが、他のメンバーが加えた改修を、上書きしてしまってもベテランエンジニアDは悪びれる様子はなかった。

はじめに 中小SIerで働いていると、「うちの社長って本当に凄いのか？」と疑問に思う社員は少なくありません。 現場で技術力を発揮している先輩や上司と違い、社長の仕事ぶりは日常業務の中で見えにくく、その凄さが正しく評価されないケースがよくあります。 この記事では、業界の人からヒアリングした、中小SIerにおける「社長の凄さが伝わらない理由」を紹介します。 社長の凄さが伝わらない理由 社長と接する機会がそもそも少ない 社員数が多かったり、客先常駐だと社長と接する機会ないというケースは珍しくありません。 日々の業務は現場のリーダーやマネージャーとのやり取りが中心になるため、社長がどんな仕事をしているのか、社員からは想像すらつかないのです。 比較対象がなく、凄さの判断基準がない そもそも、他社のビジネスモデルや経営スタイルを知る機会がない社員にとって、自社の社長が凄いのか普通なのかを判断する材料がありません。 Sierはビジネスモデルはどこも同じに見えるし、他社の社長のことなんて知らないという状態では、比較のしようがないのも当然です。 技術知識の低さが目立ち、信頼を落とす場面もある 技術者出身でない経営者も多くいるため、ミーティングなどで技術的な発言をした際に、その知識の浅さが露呈してしまう場面もあります。 技術者からすれば、経営者にも一定の技術理解を期待してしまいがちですが、経営者の本来の役割は必ずしも技術力そのものではありません。 経営者としては優秀でも評価が下がってしまうことがあります。 社員に経営知識がない 多くの社員は、そもそも経営という仕事の中身を知りません。 社長は、資金繰り、人材の採用、案件の獲得、契約交渉、リスク管理など、会社を存続させるために必要な業務を一手に担っています。 社員が安心して働ける会社を作るためには、これらすべてを同時に守り続けなければなりません。 しかし、社員側に経営の知識がなければ、こうした仕事の大変さや重要性は伝わらず、「社長って最近オフィスで何してるんだろう」という印象だけが残ってしまうのです。 解説 こうした「社長の凄さが伝わらない」現象に共通しているのは、社員と社長の間にある情報の非対称性です。 社員は現場の技術や日々の業務を通して評価軸を持っていますが、経営の仕事は数字や交渉といった、現場からは見えにくい領域で行われています。 そのため、技術力だけを評価基準にしてしまうと、経営者の本当の凄さを見落としてしまう可能性があります。 技術力だけでなく、経営の視点を少しでも知ることができれば、社長という存在への見方が変わるかもしれません。 おわりに 中小SIerに限らず、経営者と社員との間には見えない壁が存在しがちです。 社長の仕事が見えにくいのは事実ですが、それを理由に一方的な評価を下してしまうのはもったいないことでもあります。 もし自分のキャリアや職場環境について考える機会があれば、技術力だけでなく経営の視点からも会社を見つめ直してみると、新たな発見があるかもしれません。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 大学の情報工学部には、様々な学生が在籍しています。 プログラミングに強い人もいれば、まったく興味を持てない人、そして「本人の特性ゆえに」なかなか苦戦してしまう人もいます。 この物語では、ある学生の言動を通して、当時は気づかれにくかった特性と、それを見抜けないまま採用してしまう企業側のリスクについて考えます。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 変数名が理解できない情報工学部生 これは中四国内のとある国公立大学、情報工学部での出来事。 その中に、少し目立つ学生A君がいた。 ロン毛でどこにでもいそうなヤンキー風の見た目、口癖は「なんや！？」。 一見よくいるタイプの学生に見えたが、周囲の学生たちは彼のある一点だけは他のヤンキー学生とは違うと感じていた。 異常なまでに、落ち着きがないのだ。 講義中じっとしていられない 講義中、A君は講師の話をまったく聞かず、隣の学生の肩を叩いては振り向かせ、変顔を見せるという行為を延々と繰り返していた。 学生A🙄「なんや！？」 一度や二度ではない。講義が始まってから終わるまで、ずっとである。 待つことが苦手 自分が待ち合わせに頻繁に遅刻するのに、他人が数秒でも遅れると、途端に不機嫌になるのだ。 学生A😤「5分もたってるやん。いつまで、待たせるんや！？」 講義室を出る際、自分より数秒遅れて出てきた学生に対し、「5分以上待った」と本気で怒り出すこともあった。 学生C😳「え、5分どころか数秒だよ……」 学生A😠「待ったんじゃ！」 数秒と5分の感覚のズレに、周囲はただ困惑するばかりだった。 変数が理解できない 講師🙂「ファイル名や変数名は、任意の名前をつけて構いません。」 A君はこの言葉の意味がわからなかったらしく、隣の学生Bに尋ねた。 学生A🤔「なあ、任意って何や？」 学生B🙂「どんな名前にしてもいいってことだよ」 Bの説明を聞いたA君は、キーボードを叩き始めた。 そして出来上がったファイル名と変数名がこれだった。 aaaaaaaaaaaaaaaaaa.c bbbbbbbbbbbb 学生B😳「え、それは……」 学生A😠「なんでもええんやろ！」 不機嫌そうな顔でそう言い放つA君。 講師が「任意でよい」と言ったのは、複数のファイルやデータを扱う際に、自分自身が後から見て分かりやすい名前をつけてほしいという意図があってのことだった。 しかしA君には、その言葉の背景にある意図までは伝わっていなかったようだ。 最初は冗談で言っているのかとBは思ったが、A君はその後もアルファベットの羅列を使い続けた。そして案の定、途中で集中が切れてしまう。 学生A😡「できん！できん！」 周囲の学生に当たり散らしながら、A君はキーボードを叩く手を止めてしまった。 こうした光景は、この講義に限らず何度も繰り返されていた。 当時、発達障害に関する知識は今ほど広く知られておらず、周囲には「発達障害かもしれない」という発想自体がなかった。 A君と音楽の話などをしているときは普通にコミュニケーションが取れていて、工学部でプログラミングが苦手な学生自体は珍しくなかったため、A君もその一人として片付けられていた。 もし当時から特性への理解があれば、A君に対して何かしてあげられたのかもしれない。 A君は国公立大学の情報工学部卒という学歴で一般企業に就職した。 中小企業の中には、面接一発で採用を決めてしまう企業もいるが、短時間のやり取りだけで採用を決めることには、大きなリスクがあることはこの例からも明らかだろう。 解説 A君の言動を振り返ると、いくつかの特性が重なっていたことがわかります。 講義中に落ち着きがなく、他者への干渉行動をやめられない 自分の遅刻には無頓着な一方、他人のわずかな遅れに強い怒りを感じる 「任意」という言葉の裏にある意図や背景を汲み取ることが苦手 集中が長く続かず、うまくいかないとすぐに感情的になる これらは今の知識で見れば、ADHD（注意欠如・多動症）の特性と重なる部分が多いように見えます。 当時はこうした特性への理解や、投薬をはじめとする対策の情報が今ほど普及しておらず、A君自身も、周囲の学生も、そして大学側も、「変わった学生」「集中力がない学生」という認識で片付けてしまっていました。

はじめに 「コーディングができる」ことと「技術的な意思決定ができる」ことは、似ているようでまったくの別物です。 サッカーで「守備が強い」と言っても、1対1の対人守備が得意な選手とチーム連携の守備が得意な選手がいるように、エンジニアにも得意分野の偏りがあります。 この物語では、経歴や年齢だけで「ハロー効果」的に評価され、本来向いていないポジションを任されてしまった技術リードが、現場をどう混乱させたのかを描きます。 暴君と化す技術知識ゼロのテックリード 背景 これは、東京都内にある業界屈指の大手企業のクラウド案件でのことである。 この案件に、50代のベテランフリーランスエンジニアCが参画してきた。 プロジェクトには経験の浅い若いメンバーが多かったため、Ｃがテックリード的ポジションに就任した。 Cはコーディング歴は長く、実装スピードには定評がある。 しかし、インフラの知識やトレンドキャッチアップ、技術そのもの理解度については、正直かなり怪しいという噂がメンバーの間で流れていた。 Amazon S3はNoSQL? ある日のミーティング。設計担当のエンジニアDが、データ保存先の構成について説明していた。 エンジニアD 🙂 「このファイルはAmazon S3に保存する設計です。」 テックリードC 🤔 「S3ね、了解。あれはNoSQLだから、柔軟にデータ入れられて便利だよね。」 エンジニアD 😳 「……え？ S3はオブジェクトストレージで、NoSQLデータベースとは別物ですが……。」 テックリードC 😤 「いや、SQLじゃないんだからNoSQLでしょ。」 エンジニアD 😨 （SQLじゃないもの全部NoSQLだと思ってる……？） テックリードCはS3でのアプリケーションの実装経験があるにも関わらず、S3をデータベースと言い張る始末。 わがままでミドルウェア変更 本番稼働中のWebサーバーについて既存環境はApacheで安定稼働していたが、テックリードCが突然言い出した。 テックリードC 😤 「俺はnginxの方が使い慣れてるから、nginxに変更しよう。」 エンジニアD 😐 「今Apacheで問題なく動いていますし、変更するリスクの方が大きいのでは……。」 テックリードC 😅 「何か問題があったら、Apacheだと俺何もできないよ～。nginxにして。」 明確な技術的理由もないまま、Webサーバーはnginxへ切り替えられることになった。 そして切り替え後。 テックリードC 😨 「あれ……？ 俺が作ったWebアプリが動かない……！」 エンジニアD 😳 「え、どこが動かないんですか？ エラーログは出てますか？」 テックリードC 😖 「分からない！ 動かし方が分からないよ～」 エンジニアD 😰 「いや、動かし方が分からないと言われても、状況を教えていただかないと調べようが……」 自分が得意と言っていたのに、いざ変更すると分からないと言い出し、トラブルの詳細を聞いても分からないの一点張りで説明をちゃんとしない。 言い出した変更で他のメンバに迷惑をかけたにも関わらず、テックリードCから謝罪の言葉はなかった。