エンジニア実録

はじめに 中小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から謝罪の言葉はなかった。

はじめに 職場では、周囲となかなか協調できず、業務が思うように進まない社員に出会うことがあります。 本人の努力不足と決めつけてしまう前に、その背景に何があるのかを考えることが、職場全体にとって重要な視点になります。 この記事では、岡山県のとある中小システム会社で実際にあった、新人社員を巡る出来事を紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 「全く仕事をしない問題新入社員」 これは、岡山県のとある中小システム会社での出来事。 数十名規模のこの会社に、ある年、新人社員が配属された。 しかし配属直後から、周りと全く協調せず、仕事もほとんど進まないという状態が続いた。 先輩社員は見かねて、総務部に報告・相談をした。 先輩社員 😟 「新人のAさん、業務が全然進まないみたいなんですが、大丈夫でしょうか。」 総務部 😐 「まあ、新人だし、そのうち慣れるでしょう。」 しかし、面倒くさがられ、まともに取り合ってもらえなかった。 先輩社員 🤔 （さすがにこれだけ進まないのはおかしい。何が起きているのか確認しよう。） その後も一向に改善が見られず、あまりにも仕事が遅いことを不信に思った先輩社員は、こっそりと該当社員のPCにキーロガーを仕込んだ。 ※ 無断でキーロガーを仕込む行為は、プライバシー侵害に当たる可能性があります 数日後、キーロガーの記録を確認した先輩社員は、驚くべき事実に気づく。 先輩社員 😳 （……パソコンが、まったく動作していない!!!） 業務時間中、ほとんどキー入力もマウス操作も行われていなかったのだ。 その後も状況は改善されず、さすがに会社側からも問題視されるようになり、当該社員は自主退職を求められることになった。 しかし、本人は退職を拒否し、ギリギリまで会社に居座り続けようとした。 解説 このエピソードの背景には、発達障害への理解や対応方針が社内で十分に整備されていなかったという課題があると考えられます。 ある小学校では、小学1年生の10人に1人が発達障害だったというデータもあるように、発達障害を持つ方は決して珍しくないということが、社会的にも認知されつつあります。 自分自身が発達障害を持っている可能性もありますし、発達障害を持つ方と一緒に仕事をする場面も、今後ますます増えていくでしょう。 特にSIerの業務では、プログラミングなど論理的思考力を要するタスクが多いため、発達障害の傾向を持つ方が期限内にタスクを遂行することが難しい場合があります。 発達障害の疑いがある場合には、周囲の従業員でフォロー体制を整えたり、軽作業を割り当てたり、障害者雇用に関する助成金を活用したりといった対応が、企業側に求められます。 しかし、今回のケースのように、中小企業では発達障害への理解度が低く、総務部に相談しても問題を先送りにされてしまうことが少なくありません。 また、周囲の社員自身も「発達障害を持つ人がいるかもしれない」という認識が薄いため、仕事ができない社員に対して笑ったり不満を言うだけで終わってしまうこともあります。 おわりに 世の中には、こうした課題に対する理解や対応体制が整っていない企業が、実際に数多く存在します。 本人の特性への理解不足や、相談窓口の機能不全は、当事者だけでなく周囲の社員にとっても大きな負担となります。 もしあなたの職場が、こうした課題に真摯に向き合う体制を整えていないと感じるなら、転職やフリーランスとして独立するなど、環境を変えることも一つの選択肢です。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 顧客が明確に伝えたニーズを正しく理解できないまま、無理に案件を受注しようとする「くれくれ営業」は、顧客の時間を奪うだけでなく、会社の信頼そのものを損ないます。 この記事では、Entra IDに関する依頼を巡って発生した認識のズレと、その後の営業報告書を巡る不可解なやり取りを紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 チャンスを自ら潰す案件潰しPL その2 案件依頼 これは、大手メーカー系SierのB社の下請けとして開発案件を受けている、岡山県のシステム会社A社での出来事。 A社は数十名規模のシステム会社で、B社から受注した案件をPL（プロジェクトリーダー）とエンジニア数名の体制で回すことが多かった。 ある日、B社からA社のエンジニアCに、Entra IDでのユーザー管理設計に関する問い合わせがメールで届いた。 顧客B社 🙂 「別案件でEntra IDのユーザー管理設計をする必要があるんですけど、Cさんはその辺の知見ってありますか？」 C 😐 「僕はちょっと詳しくないんですけど、社内で該当の知見があるエンジニアを探してみます。」 Cは該当のエンジニアを探すため、営業報告書を作成しPLに提出した。すると、PLからこう返信が来た。 PL 🤔 「社内ルールで、クライアントのニーズをFace to Faceで確認しないと、営業報告書出しても『クライアントのニーズを詳細に聞け』って突っ返されるんよ。」 PLは社内で適切なエンジニアを探すため、顧客に対面で詳細な打合せをしたい旨をメールで連絡した。 打合せ 打合せが始まると、顧客が丁寧に背景を説明し始めた。 顧客 🙂 「A社さんに依頼をした背景なんですけど、ユーザーがオンプレからクラウドへの移行を検討中で、クラウド化にあたりいくつか課題があります。」 顧客 🙂 「A社さんにはそのうち、『Entra IDの部分』を対応していただきたいと考えているんですよ。」 分かったような顔で頻繁に相槌を返すPL。 C 😶 （本当に分かってるのかな……。） 顧客の話によると、クラウド化にあたってリソースをIaC化することなど複数の課題があり、そのうち依頼したいのはEntra IDによるセキュリティ設計の部分のみだという。 顧客の説明が一通り終わったところで、PLが口を開いた。 PL 🤔 「C君は（Entra IDの設計）できんのかなぁ？」 C 😳 「え!? もともと私が対応できないから、社内で技術者を探すって話でしたよね?」 すると、PLが声を張り上げ、驚愕の発言をした。 PL 😤 「社内で（技術者を）探したけど、いなかったんよ!

はじめに システム障害が発生した際、本来であれば原因を究明し、その原因に対して恒久対策を打つのが筋です。 しかし現場では「原因が分からないまま、恒久対策だけを先に決めてしまう」という理不尽な進め方がまかり通ることがあります。 この物語では、原因究明を後回しにしたまま恒久対策を求められたことで、現場がどのように混乱していったのかを描きます。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 「原因究明してないけど恒久対策」 これは、国内大手SIer企業のA社での出来事。 とあるクラウドシステムにおいて、顧客のデータが消失するという重大障害が発生した。 再現性の低い事象で原因調査は難航し、一方で顧客への障害報告を早期に実施する必要がある。 チームには、重い緊張感が漂っていた。 今後の方針を決めるため、チーム内で打合せが開かれた。 課長 😤 「本件、時間をかけるわけにはいかないので、原因究明はしないけど、恒久対策は打つことにします。」 メンバーA 😳 「え!? 原因分かってないのに恒久対策ですか?」 課長 😐 「そうです。まずは、顧客に説明する障害原因と恒久対策をブレストで提案して。」 メンバーたちが次々と手を挙げる。 メンバーB 🙂 「クラウドベンダーのサービス障害が原因で。」 メンバーC 🙂 「デバイスのハードウェア障害が原因で。」 メンバーA 😣 「いや、ベンダーから障害通知出てないですよね? ハードウェアもこの件と因果関係ないんじゃ……。」 課長 😐 「いや、ブレストで一旦説明案出したいだけだから、指摘しなくていいよ。」 メンバーA 😩 「はあ……。」 メンバーD 😆 「んじゃ、TCP/IPの世界をパケットが彷徨ったことが原因で。」 課長 😃 「それ採用で。」 メンバーA 😶 （TCP/IPの世界を彷徨うってなんだ……？）

はじめに 脳科学的に見ても、記憶力には個人差があり、物事を覚えておくのが苦手な人は一定数存在すると言われています。 実際、自分が作ったファイルの場所がわからなくなり、人に聞いてしまうという方も少なくありません。 本記事では、作業報告書の提出をめぐって起きた、ある岡山のシステム会社のPLとエンジニアのやり取りを紹介します。 「自分で作ったファイルを忘れるマン」 これは岡山のとあるシステム会社での出来事。 社員数数十名規模のこの会社では、複数の顧客のシステム保守・開発プロジェクトが同時に進行しており、PLも複数のプロジェクトを兼任するのが当たり前の環境だった。 このPLは、兼任するメンバーの作業時間を集計し、毎月作業報告書として顧客に提出する責務を負っていた。 しかし本業が多忙で、報告書作成の作業がいつも後回しになっていた。 見かねた部下のエンジニアAが、報告書作成を手伝うと申し出た。 エンジニアA 🙂 「PLの作業時間を教えてください。代わりに記載しておきますよ。」 PL 😑 「うーん、複数プロジェクト兼任してるから一概に言えないんだよね……。」 PLは言葉を濁し、結局時間を教えなかった。 それでもエンジニアAは食い下がらず、歩み寄った提案をする。 エンジニアA 🙂 「では、自分以外のメンバーの時間は私がまとめます。PLは自分の分だけ書いてもらえますか？」 PL 😐 「あ、うん、わかった。」 そう答えたものの、それ以降もPLは自分の作業時間を記載せず、報告書のPL欄だけが空欄のまま数ヶ月放置される状態が続いた。 数ヶ月後、PLが突然エンジニアAに連絡してきた。 PL 😐 「作業報告書ってどこに置いてる?」 エンジニアA 🙂 「PLがいつも置いてるファイルサーバにありますよ。」 PL 😐 「いや、そうじゃなくて。顧客に提出したファイルがどこにあるか知りたいんだけど。」 エンジニアAは一瞬戸惑った。 報告書の提出はPLの役目であり、提出していれば自分の送信メールボックスに残っているはずだ。 そもそもPL自身が作業時間を記載していないため報告書自体が完成しておらず、提出できるはずがなかったのである。 エンジニアA 🤔 「……そもそも報告書、PLの作業時間欄が空欄のままなので、まだ完成していないと思うんですが。」 PL 😳 「……。」 エンジニアA 😳 「もしかして、提出していないんじゃないですか？」 指摘を受けたPLは一瞬呆然とした。 PL 😳 「……。」 そのまま謝罪や礼を口にすることもなく、PLは無言でその場を去っていった。 解説 今回のPLは、自分が報告書を完成させていない事実を認識できておらず、代わりに提出先を他人に尋ねるという矛盾した行動に出てしまいました。 このような相手には、相手が記憶していないという前提で会話をすすめると有効です。 例えば、打合せ前に「前回の打合せでは〇〇という状況でしたが～」のように会話に前回の情報を付与することで、認識違いがでにくくなります。 おわりに 記憶力の低さそのものは個人の特性であり、責められるべきものではありません。 しかし、それを理由に自分の役割を放棄してしまうようでは本末転倒です。

はじめに 「立場が上の人だから、指示は正しいはず」と思い込んで動いてしまうと、思わぬトラブルに巻き込まれることがあります。 今回は、東京都内にある業界屈指の大手企業N社のクラウド案件で実際に起きた、あるPMの言動をご紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 話したことを5分で忘れるPM これは、東京都内にある業界屈指の大手Sierのクラウド案件に参画していたPMとのやり取りです。 このPMは、常に丁寧な敬語で話す人物でしたが、ふるまいはどこか子供っぽく、こだわりの強さや思い込みの激しさが目立っていました。 プロジェクトは複数のベンダーやメンバーが関わる規模で、日々多くのタスクが並行して進んでいました。 同じタスクを別人に割り当てる ある日、エンジニアAはPMからタスクについての指示を受けました。 PM 🙂：「このタスク、Aさんお願いします。」 エンジニアA 🙂：「承知しました。」 数分後、同プロジェクトのメンバーBとPMが話し込んでいるのに気付きます。 話の内容からAに依頼する前にタスク、Bにも同じタスクをアサインしていたらしく、タスクの進捗状況についてBと話していた。 エンジニアA 😐：「すいません!、そのタスク、さっき僕がやるって話でしたよね。Bさんに任せるってことですか?」 PM 😶：「え？。。。」 混乱するPM。 エンジニアB 😐：「今から担当変更すると引継ぎとか余分なタスクがかかる」 機嫌悪そうに語るB。 エンジニアA 😐：「では、このタスクBさんが実施するということで」 さらに数分後。 PM 🙂：「さっきタスクの進行状況どうですか?」 エンジニアA 😳：「あ、いやだからそれもうBさんがやるって話さっきしましたよね……」 エンジニアA 😨（さっき話してから5分も立ってないのに……） 一度だけならうっかりミスとも思えますが、この手の割り当て忘れは日常的に発生していました。 検証環境障害でメーリングリストがパンク 検証環境で障害が発生し、監視システム(Zabbix)から障害通知が一日1万件以上が通知される事象が発生しました。 エンジニアA 😟：「PM、検証環境で1万件以上が発生しているみたいです。アプリのログを確認して原因を調査しましょう。」 PM 🤔：「ログより、障害メールを見た方が早いです。メールで確認しましょう。」 エンジニアA 😕：「メールだと件数が多いとメールサーバーへの負荷も高いし、ログの方がgrepとか使えて効率的ですよ……」 PM 😤：「念のためにメールで送るんですね！!、メンバー全員が入っている検証環境用メーリングリストを作るのでそこに送信してください。」 エンジニアAは思わず声を上げました。 エンジニアA 😨：「メーリングリストに送ると、メンバー全員のメールボックスに障害メールが大量に届いてしまいます。それはさすがに危険です。」 PM 😠：「いいから、やるんですね。」 エンジニアA 😰：「……承知しました。」 指示通りにメーリングリスト宛てに設定したところ、障害通知メールが繰り返し送信され続け、メンバー全員のメールボックスが瞬く間にパンクしました。

はじめに 顧客との打合せでは、要件への理解不足を指摘された時にどう振る舞うかで、その後の信頼関係が大きく変わります。 この記事では、自分の理解不足を認めたくないという心理が、かえって顧客の不信感を招いてしまった職場のトラブルを紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 チャンスを自ら潰す案件潰しPL これは、大手SIerの下請けとして開発案件を受けている、岡山のシステム会社A社での出来事。 A社は数十名規模のシステム会社で、大手SIerから受注した案件を、PL（プロジェクトリーダー）とエンジニアの数名体制で回すことが多かった。 今回参加した打合せは、クラウド上に蓄積された大量のPDFファイルに対してOCR技術を適用し、メタ情報を抽出して検索性を高めるという新規案件のキックオフだった。 打合せの中で、要件の説明が一通り行われた。 キックオフ後、顧客とA社で個別の打合せを実施した。 顧客 🙂 「さっきの打ち合わせ、A社さん的にどう思いました？」 A社PL 😐 「まだ、要件がプアーな感じで、なんとも……」 要件はすでに十分に説明されていたにもかかわらず、A社PLは言い訳し、言葉を濁した。 横で聞いていたA社エンジニアは、内心「そんなに曖昧だったか？」と首をかしげていた。 要件を理解できていないのではと感じた顧客は、あらためて丁寧に補足を始めた。 顧客 🙂 「ユーザーがやりたいことって〇〇だと思うんですよ。で、〇〇を実現するとなると……」 A社PL 😠 「私も分かってますよ！」 顧客の言葉を遮り、食い気味に返すA社PL。 要件が理解されていないと思われたことで、自分が無能だと見られていると感じたのかもしれない。 その場に、しらーとした空気が流れた。 顧客もA社エンジニアも、思わずドン引きして青ざめる。 引き気味になりながらも、顧客は会話を続けようとした。 顧客 😕 「OCRを使うとなると、どのサービスを使うかというのが課題だと思うんですが……」 A社PL 😏 「OCR、文字認識機能ですね。」 理解できていることをアピールしたいのか、顧客の言葉をそのまま復唱したり、別の言い方に言い換えたりするA社PL。 しかし内容そのものへの回答にはなっていなかった。 らちが明かないと感じた顧客は、単刀直入に核心を尋ねた。 顧客 😐 「いや、聞きたかったのは、A社さんはこのシステムのアーキテクチャとか提案できますかってことなんですよ……」 A社PL 😳 「そういうことでしたら是非当社に！」 それまでの態度が一変し、急に前向きな姿勢を見せるA社PL。 その落差の大きさに、周囲は言葉を失った。 雰囲気を察したA社エンジニアが、慌ててフォローに入る。 A社エンジニア 😅 「と、とりあえず詳細は持ち帰らせていただいて、ご提案させていただきますね。」 打合せはひとまずその場を収める形で終わったが、顧客のA社に対する印象は、決して良いものではなかった。 解説 顧客の補足説明を遮って「分かっている」と主張したり、言葉を復唱・言い換えするだけで実質的な回答を避けたりする行動は、理解できていないことを隠そうとするあまり、逆に理解できていないことを露呈させてしまう典型的なパターンです。

はじめに 休日は業務から離れて自分の時間を過ごすものだと考えている人は多いのではないでしょうか。 しかし、IT業界では、休日に仕事をしているワーカホリックな管理職も存在します。 今回は中四国のシステム開発現場で実際にあった、休日にサービス残業をしていたPLの話を紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 「休日に部下の家で仕事するプロジェクトリーダー」 これは中四国のあるシステム開発会社での出来事。 このプロジェクトは、複数の協力会社が入り交じる中規模の案件で、リリース直前ということもあり、現場全体に慢性的な余裕のなさが漂っていた。 PLは、要領の悪さで社内でも有名な人物で、進捗管理や資料作成をいつもぎりぎりまで溜め込んでしまう癖があった。 後輩のDさんは、ノリの軽さで周囲から「ちゃらお」と呼ばれるタイプで、久しぶりの休日に自宅でゆっくりくつろいでいた。 すると、スマートフォンにPLからの着信が入る。 Dさん 😌 「はい、Dっす。」 PL 😐 「明日、顧客向けの報告資料を作らないといけなくてさ。今日中に仕上げたいんだよね。」 PL 😊 「いや、Dが作ったドキュメントとかプログラムのこと、分からないところがあったらすぐ聞きたいから、そっち行っていい？」 Dさん 😆 「家っすか？別にいいっすよー、散らかってますけど。」 PL 😊 「うん、近くまで来てるんだ。」 すでに移動を始めていたPLは、そのままDさんの自宅に到着する。 本来であれば会社の設備で行うべき作業を、部下の自宅の私的な空間で、しかも休日にこなす状況を、PL自身が作り出していたのである。 PLはノートPCを広げ、資料作成に取りかかった。 PL 😅 「あー、この処理どうなってたっけ……。ちょっと聞いていい？」 Dさん 😐 「ああ、それはこういう処理っすよ。」 質問に答えながらも、Dさんは何をするでもなく手持ち無沙汰になっていた。 すると、ちょうどそこへ別のプロジェクトで一緒だった他社のメンバーから連絡が入る。 自社メンバー 📱 「暇してるなら麻雀しない？」 Dさん 😆 「お、いいっすね！ちょっとうちに来てくださいよ。」 Dさんは自分の家であることをいいことに、プロジェクトとは無関係の自社メンバーたちを呼び寄せ、ノリノリでリビングの隅に雀卓を用意して麻雀を始めてしまった。 牌をかき混ぜる音と談笑が響く隣で、PLはエアコンの効きが悪い部屋の中、額に汗をにじませながら黙々と資料作成を続けていた。 Dさん 😆 「お、リーチ！」 自社メンバー 😂 「まじかよ、また負けた。」 数時間後、ようやく資料が仕上がったところで、PLは疲れた様子で切り出した。 PL 😮‍💨 「なんとか終わったよ……。じゃあ、また明日会社でよろしく。」 Dさん 😆 「お疲れさまっす！気をつけて帰ってくださいねー。」 解説 百歩譲って休日に作業をすること自体は仕方ないとしても、事前に「この部分についてメモをまとめておいてほしい」と後輩に指示しておけば、わざわざ部下の自宅にいく必要はなかったはずです。