中四国

はじめに フルリモートで働けるようになったエンジニアの中には、「家賃の安い地方に移住して、今の仕事はそのまま続けたい」と考える人が増えています。 そんな移住を後押ししてくれる制度が、国と自治体が連携して実施している 「地方創生移住支援事業（移住支援金）」 です。 条件を満たせば、単身でも最大60万円、世帯であれば最大100万円の支援金を受け取れる可能性があります。 この記事では、リモートワークで地方移住を検討しているエンジニア向けに、移住支援金の仕組みと申請時の注意点を解説します。 なぜ今、地方移住者が増えているのか 移住者増加の背景にあるのは、「家賃が安く、それでいて東京へのアクセスが良い」地域への人気の高まりです。 フルリモートであれば通勤の必要がないため、家賃相場の高い東京23区にこだわる理由が薄れます。 一方で、出社が必要な場面や実家・知人との行き来を考えると、東京から近い地域の方が何かと安心という声も多く、「家賃は下げたいが、東京から離れすぎたくない」というニーズが移住先選びに強く反映されています。 移住希望地ランキングトップ3 公益社団法人ふるさと回帰・移住交流推進機構の調査によると、移住希望地ランキングの上位は以下の通りです。 順位 都道府県 1位 群馬県 2位 栃木県 3位 長野県 出典: ふるさと回帰・移住交流推進機構 いずれも東京圏からのアクセスが比較的良く、家賃水準は東京23区に比べて大きく抑えられるエリアです。 移住支援金の対象地域に含まれる自治体も多いため、リモートワークを継続しながらの移住先候補として検討しやすいのも人気の理由です。 移住支援金とは 移住支援金は、東京圏（東京23区在住、または東京23区に通勤していた人）から地方へ移住し、一定の条件を満たした場合に支給される国の制度です。実際の窓口や上乗せ額は都道府県・市町村ごとに異なります。 支給額の目安 世帯区分 支給額の目安 単身 最大60万円 世帯（2人以上） 最大100万円 18歳未満の子どもを帯同 子ども1人あたり最大100万円加算 自治体によっては独自の上乗せ加算を行っている場合もあるため、移住先候補の自治体サイトで最新の金額を確認しましょう。 【例】ランキング1位・群馬県の移住支援制度 移住希望地ランキング1位の群馬県では、移住支援金に加えて独自の支援制度も用意されています。ここでは、群馬県への移住を例に、単身世帯でも使えるものと家族がいる世帯向けのものに分けて紹介します。 単身世帯でも使える支援 移住支援金：東京23区からの移住・テレワーク継続などの条件を満たせば単身でも最大60万円 住宅取得・改修に関する補助：市町村によっては単身者も対象とする空き家改修補助や家賃補助制度がある 家族がいる世帯向けの支援 移住支援金（世帯加算）：世帯での移住は最大100万円、18歳未満の子ども帯同でさらに加算 子育て世帯向け住宅支援：多子世帯やU・Iターン世帯を対象にした住宅取得補助 保育・教育関連の助成：市町村独自の保育料減免、給食費補助などを併用できる場合がある いずれの制度も移住先の市町村ごとに詳細や申請窓口が異なるため、群馬県内での移住先を検討する際は、候補となる市町村の移住相談窓口で最新の支援内容を確認することをおすすめします。

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

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

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

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

はじめに 職場では、周囲となかなか協調できず、業務が思うように進まない社員に出会うことがあります。 本人の努力不足と決めつけてしまう前に、その背景に何があるのかを考えることが、職場全体にとって重要な視点になります。 この記事では、岡山県のとある中小システム会社で実際にあった、新人社員を巡る出来事を紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 「全く仕事をしない問題新入社員」 これは、岡山県のとある中小システム会社での出来事。 数十名規模のこの会社に、ある年、新人社員が配属された。 しかし配属直後から、周りと全く協調せず、仕事もほとんど進まないという状態が続いた。 先輩社員は見かねて、総務部に報告・相談をした。 先輩社員 😟 「新人の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 😤 「社内で（技術者を）探したけど、いなかったんよ!

はじめに 「特に準備するものはない」と言われて安心していたら、後になって「あれをやっておくべきだった」と言われる――。 指示が曖昧なまま任され、後から結果だけを咎められるのは、働く上で誰もが遭遇しうる理不尽の一つです。 本記事では、内部監査への準備をめぐって起きた、ある岡山のシステム会社でのやり取りを紹介します。 エスパー能力を部下に求めるPL これは岡山のとあるシステム会社での出来事。 社員数数十名規模のこの会社では、複数の顧客案件が同時に走っており、プロジェクトごとにリーダーが立てられ、進行管理やドキュメント管理を任されていた。 定期的に実施される内部監査は、日頃のプロジェクト管理状況を確認する場として位置づけられていた。 内部監査の実施が近づいたある日、プロジェクトリーダーBが、プロジェクトに途中から加わった中途入社のエンジニアAに声をかけた。 リーダーB 😐 「今度内部監査があるから、準備しておいて。」 エンジニアA 🙂 「わかりました。何を準備すればいいですか?」 リーダーB 😑 「うーん、特に準備するものはないよ。」 Aはプロジェクトに途中参加したばかりで、これまでの経緯やドキュメント管理のルールを詳しく知らなかった。 それでも「特に準備するものはない」という回答を受け、大掛かりな対応は不要なのだろうと判断した。 エンジニアA 🙂 「承知しました。特に何もしなくて大丈夫なんですね。」 リーダーB 😐 「うん、大丈夫。」 内部監査当日。 監査担当者から次々と質問が飛んできた。 監査担当者 🧐 「要件定義書とプロジェクト計画書に基づいて、ドキュメント管理は適切に行われていますか? レビュー記録票はありますか?」 エンジニアA 😳 「え……。」 Aはプロジェクトの途中参加であり、初期の経緯を把握していなかった。 さらに悪いことに、当時は顧客側のシステムトラブルが発生しており、プロジェクトドキュメントの格納先そのものにアクセスできない状態だった。 エンジニアA 😰 「申し訳ございません、現在システムトラブルの影響でドキュメントへのアクセスができない状況でして……口頭でご説明させていただきます。」 Aは手元の記憶と資料をかき集め、なんとか口頭でその場を乗り切った。 監査担当者も一定の理解を示し、大きな問題には発展せずに終わった。 エンジニアA 😮‍💨 （なんとか終わった……。） 数ヶ月後、今度は外部監査が実施されることになった。 外部監査の話が出た際、リーダーBがAに確認を求めてきた。 リーダーB 😐 「内部監査のときに使ったプロジェクトのドキュメント、どこにまとめてある?」 エンジニアA 🤔 「監査議事録はファイルサーバに置きましたけど、プロジェクトのドキュメントはシステムトラブルでアクセスできないし、準備不要とおっしゃられていたので、まとめてないですよ。」 リーダーBは腕を組み、記憶を辿るように黙り込んだ。 リーダーB 😐 「……私の指示ミスです。」 そう口では認めたものの、Bの表情には反省の色はなく、フンっと軽く鼻で笑って話を切り上げてしまった。

はじめに 脳科学的に見ても、記憶力には個人差があり、物事を覚えておくのが苦手な人は一定数存在すると言われています。 実際、自分が作ったファイルの場所がわからなくなり、人に聞いてしまうという方も少なくありません。 本記事では、作業報告書の提出をめぐって起きた、ある岡山のシステム会社の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は、自分が報告書を完成させていない事実を認識できておらず、代わりに提出先を他人に尋ねるという矛盾した行動に出てしまいました。 このような相手には、相手が記憶していないという前提で会話をすすめると有効です。 例えば、打合せ前に「前回の打合せでは〇〇という状況でしたが～」のように会話に前回の情報を付与することで、認識違いがでにくくなります。 おわりに 記憶力の低さそのものは個人の特性であり、責められるべきものではありません。 しかし、それを理由に自分の役割を放棄してしまうようでは本末転倒です。

はじめに 顧客との打合せでは、要件への理解不足を指摘された時にどう振る舞うかで、その後の信頼関係が大きく変わります。 この記事では、自分の理解不足を認めたくないという心理が、かえって顧客の不信感を招いてしまった職場のトラブルを紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 チャンスを自ら潰す案件潰し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社に対する印象は、決して良いものではなかった。 解説 顧客の補足説明を遮って「分かっている」と主張したり、言葉を復唱・言い換えするだけで実質的な回答を避けたりする行動は、理解できていないことを隠そうとするあまり、逆に理解できていないことを露呈させてしまう典型的なパターンです。