■ 1. Project OTの全体像
- Project OTの発足:
- 2026年1月にハワイの邸宅で開かれた年次リーダーシップ合宿で、ザッカーバーグと側近が構想した組織変革計画
- Organization Transformationの略で、FacebookとInstagramの所有企業に「AIネイティブ」な未来を描く
- 人間の業務のAIへの置き換え:
- 数千人の従業員が日々担う業務の多くをAIが引き継ぐ構想
- 仮想の労働者を、より小規模で「talent-dense」な人間の精鋭集団が社内で監督する形
- 最大60%の人員削減シナリオ:
- シナリオプランニング演習で、全社の多くのチーム規模を最大60%削減する案を検討
- 一部の従業員は新設部署の役職を提示され、残りはレイオフの対象
- 3年前を上回る規模の想定:
- 人事幹部は、3年前の約25%の削減と同等かそれ以上の規模になると見積もった
- 2波構成の再編計画:
- 5月の第1波の粛清に続き、11月に第2の組織改編を行う二段構え
- レイオフに加え、募集中ポジションの閉鎖と、低評価とみなした人材の追い出しで補完
- 直前での撤回:
- 5月19日の夜、第1波のレイオフ実施の数時間前にザッカーバーグが翻意
- 翌日に従業員の10%のレイオフは実施したが、11月の削減計画は取りやめ
- 撤回時点の社内状況:
- 従業員は公然と反乱状態にあり、AI変革が自分たちの置き換えを一部狙っていると確信していた
- 戦略の中核である自律型AIエージェント技術が期待した生産性向上をもたらしていないと社内データが示していた
- 巨額のAI支出に見合う成果を投資家の一部が問い質していた
- 取材の基礎:
- 多数の社内文書、投稿、録音と、社内事情を知る20人超との対話に基づく
- 未解明の点:
- ザッカーバーグの方針転換を引き起こした直接の要因は特定できていない
- 人員構成の再編について現在どのような計画があるかも不明
■ 2. Metaの公式見解
- Project OTの存在の認定:
- コスト削減、チーム構造の再設計、新重点領域への人員移動に注力した1年間のプロジェクトと説明
- 新重点領域の例として、AIモデル用の訓練データ生成を挙げた
- 2波構成と60%削減の認定:
- 最も抜本的なシナリオでは一部チームの規模を最大60%縮小する内容だったと認めた
- 対象部署の特定は拒否し、いくつかの主要部門は対象外だったと説明
- 全社の60%解雇の否定:
- シナリオにはレイオフと再配置の双方が含まれ、全従業員の60%を解雇する意図は一切なかった
- 第2波中止の時点:
- 全体で何人が職を失うかを確定する前に、経営陣が第2波の計画を取り消した
- 演習という位置づけ:
- 再配置、募集ポジションの閉鎖、削減の潜在的影響を検討するシナリオプランニング演習を一部チームに依頼したもの
- 結果として数千人が新設チームの優先業務へ異動した
- 演習の全シナリオを実行したわけではなく、実行を前提としてもいなかった
■ 3. AIネイティブ思想の流入
- 生成AIへの期待:
- 2022年末のChatGPT公開以降、シリコンバレーの経営者は生成AIが解き放つ働き方の革命的可能性を思い描いてきた
- エージェント技術の位置づけ:
- 質問に答えを返すだけのチャットボットと異なり、買い物、旅行予約、アプリ作成などの自律的行動を担う新興技術
- 「AIネイティブ」への傾倒:
- 既存プロセスにAIを組み込むのではなく、完全にAIネイティブへ移行すべきというスタートアップ発の発想に幹部が魅了された
- Project OT文書は、AI対応のツールとエージェントが相互作用し、ワークフローが自動化され、新規開発はAIファーストになる姿を描いた
- AIエージェントの外販:
- 予約調整や成約などの業務を担うAIエージェントを他社に販売する構想も戦略に含む
- アジア視察:
- 最高データ責任者アレックス・シュルツと製品責任者ナオミ・グレイトが昨年アジアを訪問
- 現地スタートアップがAIを軸に組織図を構築している点を高く評価した
- 独自調査とパイロット:
- AIスタートアップの組織編成に関する独自研究を委託
- 社内で「AIネイティブ」が何を意味するかを見極めるパイロットを設置
- グレイトの説明:
- シンガポール拠点で相当の時間を過ごし、その慣行がカリフォルニアとニューヨークのチームを触発した
- アイデアの多くはボトムアップで、一部の従業員は自ら変革を実装し始めていた
■ 4. パイロットと「AI-Native Playbook」
- アーチボンによる先行実験:
- 製品管理担当バイスプレジデントのイメ・アーチボンが昨年7月、製品開発を近代化する第一歩を社内投稿で公表
- バスケットボールの比喩:
- 速攻を取り入れればより多く、より良いシュートが打てるのと同じで、AIツールは低コストかつ高忠実度で多くのアイデアを探索させる
- AIで素早く作った試作品は従来より完成品に近づく
- 単に楽しいだけでなく、AIファーストの時代にはそれが勝つ戦略である
- 経営トップの同調:
- ザッカーバーグも半年後の決算説明会で、AIが仕事をずっと楽しくする可能性に言及した
- 「small tech pod」の構成:
- エンジニア2〜3名とデザイナー1名にAIツールを持たせた5つのポッドを設置
- 6か月の固定計画サイクルなど確立された製品リリース手順を廃止
- 4週間の「スプリント」で試作品を作ることを目指す
- 「builder」への職種統合:
- 10月の社内投稿「AI-Native Playbook」が、他チームが移行するための指針を提示
- 製品デザイナーやエンジニアの伝統的職務は消滅し、ポッド構成員は「builder」という汎用の肩書きを得る
- 中間管理層は排除され、ポッドは単一の上位ユニット長へ直接報告する
- エージェント支援の優先順位付け:
- 日々の優先順位設定を「Agent-assisted analysis」が支援する
- 展開状況:
- 年初にザッカーバーグがProject OTを始動させ、管理構造の変更を進めるよう幹部に指示
- 6月までにエンジニアリングや研究を含む11以上のユニットが小規模ポッドを導入
■ 5. 新しい組織構造と人事運用
- チーム構成の対比:
- 従来の製品開発は10〜20名で、役割ごとに期待が明確な専門分化型
- AIネイティブ型は3〜5名で、必要な作業を何でも担う流動的な役割と、方向づけを担うリード1名で構成
- デザイン、UXR、データサイエンス、データエンジニアリング、機械学習の専門職はポッド横断でプール
- 組織階層の対比:
- 従来は少数の大きな柱の下に大きなチームが連なる多層のヒエラルキー
- 新型はより平坦で機動的な多数の小ポッドが、同等以上の領域をカバーする
- 「village approach」:
- 人事評価と昇進は「Org Lead」と呼ばれる上位ユニット長が決定
- 人事担当者と、内容が明示されない「AIシステム」がその決定を支援する
- ユニット長1人が30〜50人を統括する
- Pod Leadの権限:
- 小ポッドの日々の運営を担うが、正式な人事管理権限は持たない
- 現場の混乱:
- ポッド管理を任された社員が、管理職研修も評価ツールへのアクセスも与えられていないと社内掲示板に投稿
- 評価主体に関するMetaの説明:
- 各チームがより機敏になる方法をさまざまに実験したと説明
- 「AIシステム」への言及の説明は拒否し、評価と昇進の決定はAIではなく人間が行っていると主張
- 「Irreplaceable Talent」ツール:
- 代替不能な人材を特定する新しい人事ツールを同時期に導入
- 10人分の働きをするという「10X Performer」の仮想像を提示した
- 極めて優秀な個人がチーム全体分の仕事をこなせるとAI信奉者が信じる中で、この古い型が再び流行している
- レイオフ原資の再配分:
- 削減で得た資金の一部を、特にAIエンジニアリングの花形人材を獲得し引き留めるための巨額報酬に充てる意図
■ 6. 従業員の反乱
- 報道による発覚:
- 3月13日、副社長級の多くがProject OTの説明を受ける前に、20%以上に及びうるレイオフ計画が報じられた
- 2022年末から2023年初めに約25%を削減した前例があり、同規模は初めてではない
- 情報漏れへの反応:
- 現場は動揺し、まだ知らされていないはずの削減が露見したことでザッカーバーグは苛立った
- 幹部は反発への備えができていなかった
- 広報担当者は当時、理論上のアプローチに関する憶測記事と切り捨てた
- 経営陣の火消し:
- 記事を現場と議論せず、上級管理職には静かに否定
- AIによって役割が「進化する」と部下へ伝えるよう指示するトーキングポイントを用意
- 4月の追加報道:
- 5月20日の第1波で約10%を削減し、下半期にさらに人員を減らす方針が報じられた
- Metaは10%削減を社内で認め、ザッカーバーグは巨額の設備投資が理由だと従業員へ説明
- 訓練データ生成への配置転換:
- 一部エンジニアを新設のApplied AI Engineeringへ異動させた
- AIモデルのコーディング能力を高める訓練データとして、ソフトウェア工学のパズルを作らせた
- 多くの社員がこの作業を機械的で退屈だと社内投稿で揶揄した
- 再配置の成果に関するMetaの主張:
- 再配置は成果を出し始めており、同ユニットが生んだデータが先月公開したAIモデルの訓練に役立った
- 人員の減少幅:
- 一部のエンジニアリングユニットでは、異動と削減により5月末までに人員が最大30%減少
- キーストローク追跡の義務化:
- 米国従業員の端末に追跡ソフトの導入を義務づけ、キー入力とマウスクリックを取得
- 人間のコンピュータ操作をAIエージェントに再現させるための訓練が目的
- Workplaceでの抗議:
- 自分のAI後継者を訓練させられているかもしれないと考え、レイオフの説明不足にも憤った
- 社内ネットワークWorkplaceが怒りの長文と自虐的な冗談で溢れた
- 象の画像による皮肉:
- 幹部の社内投稿に対し、レイオフが「部屋の中の象」であることを示す象の画像で返信
- 幹部との衝突:
- AI変革を統括し投稿で擁護していたCTOアンドリュー・ボズワースと社員が直接衝突
- 中小企業向けAI施策の告知を、人類に火を与えたプロメテウスになぞらえて皮肉る者もいた
- 士気の低下:
- 半期のPulse調査で、社内の従業員感情の指標が肯定的74%から55%へ低下
- 労働組合結成の動きが勢いを増した
■ 7. AI技術の期待外れ
- コード量と成果の乖離:
- AIの利用で生成されるコード量は激増したが、生産性への効果は疑わしい
- 社内の開発基盤とインフラへのコード変更は前年比220%増
- 一方、ユーザーに届く新機能や改良につながった変更は36%増にとどまった
- 信頼性の警告:
- 3月時点でインフラチームが、AIコーディングの急増による「信頼性の警告サイン」を指摘
- 暴走するエージェント:
- 4月の投稿は、制御されないAIエージェントが人間なら実行しない大規模かつ破壊的な操作を行っていると報告
- インシデントの急増:
- サービス障害やデータ漏洩の可能性を含む重大な技術・セキュリティ事案が前年比40%増
- その対応に費やす時間は70%増
- 顧客サポートボットの悪用:
- 6月初旬、新しいAI搭載の顧客サポートボットをハッカーが悪用し、著名Instagramアカウントへ侵入
- 休眠状態のオバマ政権ホワイトハウスのページも被害を受けた
■ 8. 方針転換と沈静化
- 第2波の中止:
- 5月20日の第1波実施の数時間前にザッカーバーグが側近と再度協議し、11月に予定した第2波を取り消した
- 安定の約束:
- 通知後、今年これ以上の全社的レイオフは想定していないとWorkplaceに投稿
- 従業員により大きな「安定」を与えたいと表明した
- 士気回復策:
- ユニット長に対し、従業員の感情を受け止めるよう促した
- マウス追跡プログラムを一時停止した
- 新AIエンジニアリングユニットの一部社員に元のチームへの復帰を認めた
- 最高財務責任者スーザン・リーを福利厚生の拡充に投入した
- 待遇改善の具体策:
- レイオフ後の数週間、共感を示す幹部の投稿がWorkplaceに相次いだ
- オフィスのマイクロキッチンの軽食の質向上を約束した
- 出張費と社交イベント費の増額を約束した
- タウンホールでの釈明:
- 7月初旬に社内タウンホールへ不意に登場し、組織改編のタイミングを読み違えたと認めた
- AIエージェント技術は想定したほど加速しなかった
- 今後3〜6か月で技術は改善し、より多くの便益を示し始めると期待している
■ 9. 「betting on people」への転回
- 広報攻勢:
- 社内AI変革の最も破壊的な部分を後退させる一方、人間中心の企業としてMetaを位置づけるPRを開始
- 「betting on people」と宣言する動画広告を投入した
- 6,500語のエッセイ:
- AIエージェントの作成をより使いやすくする計画を強調
- 名前を伏せた競合こそが真の雇用破壊者だと描いた
- 自社の立ち位置の主張:
- 業務の自動化を主眼とするのではなく、全製品を通じて何十億人にこの新技術の力を渡し、人々に力を与えることに注力する唯一の大手企業である
- 限定的な言葉遣いへの疑念:
- レイオフを語る際に「全社的」と「今年」という限定語を使い続けている
- チーム単位の削減や成績不良を理由とする解雇が続くと社員は推測している
- 全社的な人員削減が来年へ先送りされるだけだという見方もある
- 資金面の圧力:
- 目のくらむようなAI支出により、資金繰りの逼迫と投資家の監視に直面し、節約の圧力が高まっている
- 今年AIチップなどのインフラに最低1,300億ドルを投じる計画で、2026年の営業キャッシュを食い尽くすとアナリストは見込む
- 将来の雇用予測:
- エッセイ「The Future is for Everyone」で、将来は仕事が豊富に存在しうると予測
- 産業界の巨人からテック企業への移行時と同様、企業の規模は縮小しうる
- ただし仕事の総量が減るのではなく、少人数の企業がより多く存在する形になる
■ 1. 置き去りは構造で起きる
- 上司の「正しいことを言っているのだと思う」:
- 週次の報告会でAIで作ったスライドとHTMLレポートを映したところ、上司はすぐには理解できないが正しいと述べた
- そのときは好意的な反応として受け取ったが、あれはレビューが壊れた瞬間だった
- 筆者の立場:
- 大手製造業のDX推進部門でマネージャーを務める
- この1年ほどチームの若手中堅メンバーと一緒にAI活用を進めてきた
- 生産性3倍と置き去りの同時発生:
- 体感の生産性は3倍になり、同じ時期に上司とベテランメンバーを置き去りにした
- 置き去りの性質:
- 誰の悪意でも怠慢でもなく、構造で起きる
- 置き去りにした側も損をする
- 悪役の不在:
- 上司は誠実、ベテランは真面目、若手は優秀であり、それでも壊れた
- だからこの話は、たぶん他の組織でも起きる
- 対象読者:
- 組織のAI活用を推進している人、チーム内のAI活用の温度差にモヤモヤしている人
- 一部の若手だけが突っ走っていると感じている管理職
■ 2. 私たちが走った道
- AI活用の入口:
- 製造現場出身で、転職を機にPythonを1から勉強した
- 製造ライン向けのアプリを現場に入れるようになり、やがてAIコーディングを使い始めた
- 標準化から仕様駆動開発へ:
- 作る人によって構造がバラバラで引き継げないため、標準仕様を作ろうとした
- そこで仕様駆動開発という思想を知り、Claude Codeでそれを回す取り組みを始めた
- 業務時間外での学習:
- 30代前後の若手中堅が中心の取り組みメンバーと議論するうちに面白くなった
- 気づけばプライベートの時間にも情報を集め、試すようになっていた
- 報告資料の変化:
- 本社や幹部への報告資料は、それまで1週間ほど頭を支配される仕事だった
- AIとの壁打ちなら1日集中すればだいたい形になり、そこから手直しはする
- 頭を占有される期間が1週間から1日になった
- コーディング外への拡大:
- アプリ開発は仕様さえあれば待っているだけで出来るようになった
- 気を使うメールの下書きは一瞬で出る
- 打ち合わせのメモを雑多に投げれば、ToDoとテーマの進捗が自動で更新される
- 自分用の秘書エージェント:
- markdownのリポジトリを記憶の置き場にし、AIがそれを読み書きしながら育っていく仕組みにしてある
- 3倍の中身:
- 作業のスピードではなく、同時に抱えられるテーマの数が3倍になった
- 解放されたのは時間ではなく、頭の占有だった
- 1件あたりが3倍速く終わるのではなく、並行して持てる件数が増える
- 体感は少し速くなったではなく、働き方が別のものに変わったに近い
■ 3. 効率化の可視化と爆発
- 見えない場所で進んだ効率化:
- AIコーディングは上司から見えない場所で進んでいた
- コードが速く書けても、上司の目に入るのは成果物とスケジュールだけだった
- 1年かけた変化は、上司にとって順調に進んでいるらしいという以上の解像度を持たなかった
- 報告会での断絶:
- AIで作ったスライドとレポートが報告会に出た瞬間に置き去りが可視化された
- 上司にとっては段階的な変化ではなく、ある日突然現れた断絶であり、驚くのが当たり前である
- 置き去りの一般法則:
- 進行中には気づかれず、可視化された瞬間に一気に表面化する
- 表面化したときには、もう差は1年分ついている
■ 4. レビューが上下両方向で壊れた
- 壊れたものの正体:
- 個人の能力ではなく、レビューという組織の品質保証機構が上下の両方向で同時に壊れた
- 上から私へのレビューの機能不全:
- AI製の資料は情報が濃く、AIと壁打ちしながら考えを詰めるぶん私自身の視座も上がっていた
- 結果として、上司がレビューできる点がなくなった
- 信頼と検証の分離:
- 正しいと思うは信頼の言葉であって、検証の言葉ではない
- 検証が抜けて承認だけが残り、信頼はレビューにおいては機能不全の症状である
- 逆転した知識の勾配:
- 上司は中身にはついていけなくて申し訳ない、持ち帰ってちゃんと読む、勉強します、教えてくださいと言うようになった
- 職制上の関係は何も変わっていないのに、知識の勾配だけが逆転していた
- レビューの場が、いつのまにか謝罪の場になっていた
- 上司の誠実さ:
- 自分のギャップを公の場で認め、AIで急速に変化が起きており自分が一番キャッチアップが必要だとメンバーに言えた
- 分からないことは自分で調べて、この場で質問していこうと促していた
- できることをやっていたが、それでも壊れた
■ 5. 作っても定着しなかった自動化
- 上司の定型集計業務:
- 手元のデータを所定のフォーマットにまとめるだけの仕事に見えるが、例外的な扱いをする項目がいくつもあった
- そのルールは上司の頭の中にしかなく、毎回それなりの時間を取られていた
- 3時間での自動化:
- まずルールを本人に書き出してもらい、それをもとにアプリ化してマニュアルを付けた
- このアプリをどうやってAIと作ったかの手順もレポート形式でまとめて添えた
- 作り方まで見てもらえば、AIでアプリを作る感覚を少しでも掴んでもらえると考えた
- 自動化が業務移管に化けた:
- 上司は次の集計タイミングである1ヶ月後までまともに触らなかった
- 触らないうちに使い方が分からなくなり、最終的にアプリごと集計業務を別のメンバーに渡すことになった
- 良かれと思って添えた作り方のレポートも、たぶん誰も読まなかった
- OJTを省いた言い訳:
- このときあえてOJTをほとんどせず、実験のつもりだった
- マニュアルも手順も揃っているのだから、読んで試して、詰まったら調べて動かせるはずだと考えていた
- 今思えばこれは実験ではなく、教える手間を惜しんだ自分への言い訳であり、無理だった
- 自走力の希少性:
- 説明を読んでやってみる、詰まったら調べてまたやってみるという自走力は、実は希少なスキルである
- マニュアルを配れば全員が使えるようになるという前提が成り立った現場を見たことがない
- エンジニアの世界にいると基礎スキルに見えるが、人間のデフォルトはたぶん逆側にある
- 管理職は時間の貧困の最深部:
- 上司には自分の会議、部門の調整、上からの依頼がある
- 持ち帰ってちゃんと読むと言った本人が、一番その時間を持っていない
- 自走力の問題だと思っていたが、その手前に時間の問題があった
- 新しいことを覚える時間が最もない人に、新しいことを覚えてもらおうとしていた
- 定着リードタイムは潰せない:
- 開発リードタイムはAIで潰せたが、定着リードタイムは潰せなかった
- 作るのは3時間で済むが、定着は人間の時間で動く
- AIによって開発が速くなるほど、ボトルネックは開発から定着へ移動する
■ 6. 上から若手へのレビューの崩壊
- 若手の報告への違和感:
- 自分の専門から外れたテーマの説明で、資料はきれいなのに自分の言葉になっていなかった
- 詰まるわけでも劇的な破綻もなく、書いてあることをそのまま読んでいるように聞こえた
- そういう場面が一度ではなく増えていき、上司はそれを指摘できなかった
- 検知器としての資料の崩壊:
- これまで資料が書けないことは、理解していないことの検知器だった
- 分かっていない人間にはそれらしい資料が作れず、資料作成自体が理解度のテストとして機能していた
- AIはこれを壊し、資料の完成度と本人の理解度を切り離した
- 検知器の質問への移動:
- 本人の言葉かどうかを見抜くには、的確な質問をぶつけるしかない
- AI活用についていけていない上司には、その質問が出せない
- 検知器が移った先に、検知できる人がいなかった
- 私が質問しなかった理由:
- できなかったのではなく、しなかった
- 人前で答えられない状態を作れば指摘ではなく晒しになり、そこで恥をかかせるのは違うと思った
- 質問という検知器の副作用:
- 相手に恥をかかせるという副作用がついてくる
- 上司は質問できず、私は質問しなかったが、検知されなかったという結果だけが同じだった
- 自分の原体験:
- 学生時代に論文やネットから拾った言葉をそのままスライドに貼り付けて発表し、質問に答えられず叱られた
- 以来、自分の資料は一言一句自分の言葉で説明できなければならないを自分のルールにしてきた
- この原則はAI以前からあり、AIはこの失敗モードを大量生産できるようにしただけである
- 若手に責任はない:
- AIがなければ彼は勉強して出直しますと言っていたはずである
- 能力の前借りは道具の性質であって、本人の資質の問題ではない
■ 7. 時間の貧困ループと双方向の恨み
- 非対称になった時間の使い方:
- AIを使うメンバーは資料作成もデータ集計も極力自動化し、空いた時間を創造的な仕事に使うか、単に楽をする
- 使わないメンバーは相変わらず資料作成とデータ集計に時間をかけている
- 自己強化する非対称:
- 作業に時間を取られている人にはAIを学ぶ時間が生まれず、学ばないから作業が減らない
- 自動化した側は空いた時間でさらに学んで差を広げる
- 同じ職場に逆向きに回る2つのループが立ち、分断は放置しても自然には解消しない
- 時間を作るだけでは解決しない:
- 奪われているのは時間だけではなく、頭の占有である
- 来週の報告資料に頭を支配されている人は、空き時間を与えられてもその頭では新しいことを学べない
- 占有そのものを外す道具がAIである以上、ループの入口はAIしかなく、だからこそ外からの介入が要る
- 共通言語の消失:
- AI活用の話をしても通じなくなった
- ただただ凄いことをやっている人たちという見られ方になり、それは理解ではなく畏怖である
- 当時の私たちの苛立ち:
- 自分たちばかりが仕事をこなしている、なぜ自分で情報を取りに行かないのか、なぜ勉強しないのかと感じていた
- これは間違いだった
- 学ばないことの道徳化:
- プライベートの時間を投じて学んだ人間は、学ばないことを意欲の問題として道徳化してしまう
- 実際には学習機会の構造の問題だった
- 私たちが学べたのは意欲が高かったからではなく、たまたま面白いテーマに当たり、たまたま自分の時間を使えたからだ
- 分断が完成する条件:
- 技術の差がついたときではなく、お互いが相手を道徳的に責め始めたときに完成する
■ 8. ベテランの静かな退場
- ベテラン層の反応:
- 40代以降のベテラン層からはあきらめを感じた
- 自分たちはもう自分が知っていることでやっていくという静かな退避だった
- 驚き、動揺し、ついていこうとした上司とは違った
- 促されても出ない質問:
- 上司はこの状況に危機感を持ち、ベテランメンバーのこともちゃんと心配していた
- だからこそ分からないことは自分で調べて、この場で質問していこうと言ってくれていた
- それでも質問が出なかった
- あきらめの危険性:
- あきらめが可視化された形は、質問が出ないことだった
- 驚きは声になるが、あきらめは声にならない
- 声にならないから問題として表面化せず、表面化しないまま固定化する
- だから畏怖よりあきらめの方が危険である
- 質問が出なかった原因は私にもある:
- 普段から浅い発言にはすぐに厳しく追及していた
- 悪気はなく議論の質を上げるつもりだったが、質問すると詰められる場を日常的に作っていた
- 上司がいくら質問しようと促しても、質問が出るわけがない
- 最初に必要だったもの:
- 底上げに必要だったのは教材でも時間でもなく、質問が出る場だった
- そして私は、それを壊す側にいた
- 降りる側の合理性:
- 降りたくて降りる人はいない
- 何十年もかけて自分のやり方を作り上げた人にとって、道具が変わることは仕事のやり方そのものを疑われることに近い
- 持ち込んだのが一回り以上年下の人間で、質問すれば詰められる場なら、降りる方が合理的である
- あきらめは、置かれた条件に対する妥当な判断でもある
- 暗黙知の時限問題:
- 降りたベテランは、自分の知識をAIの射程の外に置いたまま現場を去っていく
- 不良の因果、工程パラメータの勘所、過去の失敗など、最もAIに載せる価値のある暗黙知を持つ人から先に離れていく
- 底上げは追いつかせる話であると同時に、その知識が失われる前に接続する時限問題でもある
■ 9. これはあなたのチームの予告編
- 分断を駆動した2つの要因:
- 学習機会の非対称であり、業務の仕組みではなく個人の余暇で学ぶ構造だったから、学べる人と学べない人に割れた
- 道具が業務の形そのものを変えたことであり、働き方が変わったから使う側と使わない側で仕事の形が乖離した
- 固有事情の不在:
- ここにうちのチーム固有の事情は何ひとつない
- この力学はチームから部門へ、部門から会社へ、会社から社会へ、スケールを変えてそのまま働く
- これはうちのチームの失敗談ではなく、あなたのチームの予告編である
- 社外カンファレンスでの確信:
- AI時代の開発生産性をテーマにした社外のカンファレンスに参加した
- 個人の開発生産性が上がっても、なぜ組織の生産性は上がらないのかというテーマが繰り返し語られていた
- 開発の現場ではないのに、私たちの状況とほとんど同じだった
- 先頭集団の普遍的問題:
- AI導入で先を行くソフトウェア業界が、すでにこの問題に組織として取り組んでいる
- 私たちの悩みは個別の失敗ではなく、先頭集団が直面している普遍的な問題である
- 製造業から見れば、あの業界の議論は他人事ではなく、数年後の自分たちの姿である
- 共通言語の有無という条件差:
- ソフトウェア業界で語られる格差は、基本的にエンジニア同士の格差である
- コードとレビューという共通言語を全員が最初から持つため、キャッチアップという言葉が成立する
- 私たちの現場では置き去りにされた側がそもそもコードを書かず、共通言語は最初から存在しなかった
- 共通言語がある組織では追いつく話で済むが、ない組織では言葉から作らなければならない
- DX部門の存在意義:
- この部門がAIを諦めれば、ツールは新しくなっても仕事の形は変わらず、ただのデジタイゼーションで止まる
- それはイノベーションには繋がらない
- まだAIを使っていない側との合流は、福利厚生でも人材育成でもなく、部門の存在意義そのものの防衛である
■ 10. 底上げは優しさではなく自衛
- 底上げの位置づけ:
- 置いていかれた人への優しさではない
- 動いた3つの理由:
- レビューが機能しない組織では、私たちの成果は正しく評価されない
- ベテランの暗黙知は、彼らが現場を去る前にしか接続できない
- AIを諦めた瞬間に、DX部門は存在意義を失う
- やるべきことは教えるではない:
- 置き去りは構造で起き、誠実な上司がいても起きる
- 分断は時間の貧困ループで自己強化するから、放置では解消しない
- 驚きは声になるが、あきらめは声にならない
- そして、質問が出ない場を作ったのは私だった
- ハンズオン教育の2つの設計:
- 上司も含めたチーム全体へのClaude Codeハンズオン教育を始めた
- 資料を配る方式をやめて、隣で手を動かしてもらう形にした
- 私が講師をやらず、教えるのは私より若いメンバーに任せ、私は同席するが多くは喋らない
- 私が教えない理由:
- チームで一番知識のある人間が教えないのは奇妙に見えるかもしれない
- 質問が出ない場を作ったのが自分である以上、私が前に立てば同じことが起きる
- 教える力より、聞ける場を優先した
■ 1. timesを巡る議論の前提
- timesは好きにすればよい:
- 書きたい人が書き、読みたい人が読む分には業務の邪魔にならない
- 違和感が生じる場面:
- 「timesに書いたんですが」とtimes前提で仕事の話をされるとツラい
- 議論の再燃点:
- 社内Slackのtimesで「お気持ち」を書くなという記事が起点
■ 2. 分報という起源
- times文化の始まり:
- 2015年頃の記事から広まり、元は日報に対する「分」を意味する分報
- 典型的な形式:
- 「times_氏名」のような個人チャンネルを各自が持ち、そこに随時書き込む
- 分報の意図:
- 一日の終わりにまとめる日報と異なり、リアルタイム性の高い報告を目的とする
- 今何に詰まっているか、何を調べているかをその場で流し、周囲が早く助けに入れる
- 仕組みとしての評価:
- 合理的な発想である
- 日本特有の文化:
- 海外ではrandomチャンネルを雑談用に使うことはあっても、分報のような使い方は見られない
■ 3. 社内Twitter化と意味の上書き
- 社内Twitter化した実態:
- 技術メモや作業ログもあるが、ランチの写真、仕事への愚痴、時事ネタへの感想が混ざって流れる
- 業務の詰まりどころを共有する場ではなく、お気持ちや雑感が流れる場になった
- 消極的な容認:
- 「Twitterに書かれるよりまし」という理由で受け入れられてきた
- 社外に不満を書かれて炎上するくらいなら社内に書かせておくという判断
- コロナ禍での位置付け:
- フルリモート環境下のコミュニケーション手段にカウントされていった
- 会社紹介資料での扱い:
- 分報という意味合いでの紹介はほぼなく、風通しの良さや心理的安全性の文脈で語られる
- リアルタイムの業務報告として生まれたものが社風や福利厚生の一部として扱われるようになった
- 議論が噛み合わない理由:
- この経緯で意味合いが何度も上書きされてきたため
■ 4. 業務の前提に組み込まれた瞬間の問題
- 問題の発生点:
- timesが業務の前提に組み込まれた瞬間に問題が発生する
- 若手からの苦情:
- 「timesに書いたのに会社の制度が変わらない」という不満が複数の企業で見られる
- 本人たちに悪気はなく、きちんと発信しているという感覚でいることが多い
- timesの位置付け:
- 分報として機能していないtimesは便所の落書きであり、タバコ部屋の雑談に等しい
- 正式な業務報告には値しない
- 期待の非対称性:
- タバコ部屋で愚痴を言って制度が変わらないと怒る人はいない
- timesだけがなぜか、書けば拾ってもらえる場として期待されている
- 組織側の問題:
- 正式な提案ルートが機能していない、または入社後に教えられていないという側面もある
- ただしそれによってtimesが業務報告に格上げされるわけではない
■ 5. 拾う側が払う工数
- 期待に応えるリーダーの存在:
- 複数並べたディスプレイの一枚でずっとtimesを監視しているリーダーを見たことがある
- それはマネジメントではない:
- 部下のつぶやきを常時監視し、拾い、フォローしなければ回らないなら飼育である
- 書き込めば大人が気付いて拾い上げてフォローする光景は職場より保育園に近い
- だから「園児ニア」などと揶揄される
- コストの非対称:
- 書く側は数十秒で済むが、拾う側は全部下のtimesを読み、文脈を推測し、声を掛けるか判断する工数を払う
- この非対称に無自覚なまま「書いたのに」と言われても組織としては応えようがない
■ 6. エンジニアバブルの名残
- 非対称な期待が放置された理由:
- times文化が根付いたのが各社でITエンジニアの正社員数を競っていたエンジニアバブル期だから
- 採用コストとしての正当化:
- エンジニアの機嫌を損ねないことが優先され、お気持ちを拾う工数は採用コストの一部とされた
- timesを見てフォローしてくれる上長は実質的に福利厚生だった
- 市場の変化:
- エンジニア採用は数を揃えるフェーズを終え、選別のフェーズに入った
- 今の転職市場が求めているのはコミュニケーション力や事業貢献
- 福利厚生の終了:
- お気持ちのフォローを提供し続ける理由は企業側からすでに消えている
- 上長に見せることを前提としたtimesは逆行している
- あるべき振る舞い:
- 言いたいことは自身の中でまとめ、然るべき場に建設的な議論という形で出すべき
- 課題を感じてから議論に持ち込むまでを自力でやり切れることがコミュニケーション力として評価される
- timesに書いて拾われるのを待つのはその真逆の振る舞い
■ 7. ライバルとしてのAI
- メンバー層のライバル:
- 多くのメンバー層のホワイトワーカーにとってライバルはAI
- 上長の現状:
- 先進的な企業の上長は、部下だけでなくAIが上げてくる内容の精査とフィードバックに疲れている
- AIとの比較:
- AIは文句を言わず、お気持ちも書かず、成果物だけを上げてくる
- 拾ってもらえなかったことに不満を溜めることもない
- 組織の余裕:
- お気持ちを拾ってもらう前提で働く人間を抱える余裕がどれだけ残るか疑問である
- timesを拾うことを上長に強制する働き方は組織から排除されても仕方がない
■ 8. timesの活用余地
- 人が読むのをやめる方向:
- SlackをAIで定期的に舐めさせ、お気持ちを除外して課題や詰まりどころだけをサマライズさせる
- 分報が本来目指したリアルタイムの状況把握が人間の工数を掛けずに手に入る可能性がある
- 皮肉な結論:
- timesを読むのに最も向いているのは上長ではなくAI
■ 9. 問われているのは読む工数
- 議論のすり替え:
- 必要・不要論はチャンネルを残すか消すかの話として語られがち
- 本当の論点:
- 問われているのは書く自由ではなく読む工数の方
- 前提が変わる瞬間:
- timesは好きにすればよいが、誰かに読んでもらう前提にした瞬間に無料ではなくなる
- 議論の出発点:
- その工数に見合う価値が自分の書き込みにあるのか
- 読む側の工数を組織として払い続けるのか
■ 1. 問題の概要
- 個人としては合理的な判断が組織として見た場合に非合理な判断となり事業を圧迫する
- よくある相談内容:
- 開発に時間がかかりすぎる
- サーバーコストが高いのではないか
- 新機能追加のたびに想定以上の工数がかかり見通しが立たない
- 月間数百/数千ユーザー程度のサービスに対して規模に明らかに過剰な状態となっていることが多い:
- 複雑な運用が必要な大規模向けの構成
- 最新技術が多数導入され全体の見通しが悪い
- ほとんど負荷がないのにキャッシュ層が導入されている
- データベースは大きめのサーバーで複数拠点での冗長構成
- エンジニアの能力不足ではなく個人として合理的に行動した結果意図してこのような状態にしている可能性がある
- 個人の問題ではなく構造的な問題
■ 2. 原因1: 転職市場が生む「キャリア最適化」のインセンティブ
- 転職市場での評価:
- 3年間安定したシステムを堅実に運用しパフォーマンスを最適化した経験より1年で最新技術を使った新しいシステム構築をリードした経験の方が年収が上がりやすい
- 「事業に必要かどうか」より「履歴書に書けるかどうか」が優先される構造
- 評価されるのは「ポータブルなスキル」:
- 最新技術の導入経験
- 有名な技術スタックでのシステム構築実績
- 業界標準とされる開発手法の経験
- 評価されにくいもの:
- 自社サービス固有の知見
- チーム独自のノウハウ
- 結果として生まれる構造:
- 月間利用者数が少ないサービスでも大規模構成
- 小規模チームで複雑なシステム分割
- シンプルな構成で十分な規模で最先端技術を導入
■ 3. 原因2: 成功企業の事例を真似する罠
- 技術カンファレンスやブログで目にするのはメルカリ/freee/エムスリーのような成功企業の事例
- 「最新技術で組織をスケールさせた」「マイクロサービス化で開発速度を向上させた」という事例は極めて特殊な前提条件の上に成り立っている
- 彼らにとっての「複雑なシステム」は組織のスケールに対する解決策であって技術的な理想形ではない
- 「成功企業のやり方=正解」という空気が規模に合わない設計を正当化してしまう
■ 4. 原因3: "絶対に落とさない"に対してのコスト
- 「システムが止まったら困るから念のため」という思考が過剰な構成を生む:
- 複数拠点での冗長構成を初期から導入
- サーバーは「大きめ」で確保
- 全システムを最高レベルの安定性で設計
- 将来の負荷に備えて先行投資
- 月間数千ユーザーのサービスに月間数百万ユーザーに対応できる構成
- 「念のため」という言葉で正当化されるが経営的には大きな機会損失
- 余剰コストで本来は新機能開発や顧客獲得に投資できたはず
■ 5. 対策1: 「キャリア最適化」のインセンティブに対して
- 「シンプルに保つこと」を評価項目に追加:
- 新技術導入だけでなく技術的負債の削減も評価
- 「コスト削減に成功した」を実績として認める文化
- 長期的な運用/改善を正当に評価
- 技術選定の意思決定プロセスを明文化:
- 「なぜこの技術を選ぶのか」を意思決定プロセスに組み込みドキュメント化
- 事業的な必要性を説明できることを前提とする
- 外部の目を入れる:
- 技術顧問やアドバイザーによる定期的なレビュー
- 「今の規模に本当に必要か」を客観的に判断
■ 6. 対策2: 成功企業の事例を真似する罠に対して
- 小さく始めて段階的に拡張する原則とする:
- 初期フェーズはシンプルな構成でスタート(1つのアプリケーション/基本的なデータベース構成/最低限の監視/目標レベル99.5〜99.9%)
- 成長に応じた3段階の拡張ステップを想定:
- ステップ1: まず最適化(クエリ最適化/インデックス追加/キャッシュ導入/N+1問題の解消)
- ステップ2: サーバー性能アップ(CPU/メモリの増強/スケールアウト)
- ステップ3: システム分割(マイクロサービス化/専門チームの配置)
- 多くの場合ステップ1〜2のみで十分対応できる
- 「今の規模」に最適化する文化を作る:
- 「最初から完璧」ではなく「必要になったら拡張」を原則とする
- 各段階のコスト対効果を明確にし拡張のタイミングを事前に合意
- 「早すぎる最適化」を避ける文化を醸成
- 成功企業の規模と自社の規模の違いを認識
■ 7. 対策3: "絶対に落とさない"に対してのコストに対して
- 「どれだけ止まっていいか」を経営判断として決める:
- 「止めない」ではなく「どこまで止まっていいかを最初に決めること」が重要
- 99.9%稼働率ということは月43分程度は止まる可能性があるということ
- 止まってはいけないということはリスクを取りづらくなるコストが存在する
- システム内で優先順位をつける:
- ユーザーが見る画面やクライアントが常に使っている機能については落ちづらくしておく
- 社内で使用する管理画面などは落ちても問題ないとする
- ユーザーやクライアントに直接影響する機能と社内でしか使わない管理機能を同じレベルで守る必要はない
■ 8. 結論
- エンジニアが個人として合理的に動いた結果事業が後退してしまうのは構造的なインセンティブの帰結
- 「うちのエンジニアは大丈夫」と慢心せずに対策していくことを推奨
- 最高なのは個人の合理性と組織の合理性を一致させること
- それを思わせるのが経営者の役割
- エンジニアと経営者が同じ方向を向いて判断できる組織は強い組織
特にエンジニア採用では「モダンな技術や最新の開発手法が取り入れられておりあの会社は優秀なエンジニアが数多く集まっている。自分もあの中に入ると何か少しエンジニアとして優越感が出そう」という空気感大事なんですよね。金払いがちょっと良いくらいではこの優越感が得られない。
ITエンジニアが最強だと思っている高度なアーキテクチャが技術力の高い企業に採用されてるのは「サービスが超絶儲かっているから」であって
お前らが担当する、そこそこしか儲からないシステムに高度なアーキテクチャは不要。
ITエンジニアの自己満足はビジネス上、害悪であると言い切った元上司。
スタートアップ的な開発と技術的負債の話、スタートアップからの案件相談とか聞いてて思うのは、安定化・リファクタリング期間を明示的に積む経営判断をすれば済んでる話を、現場レベルで技術的負債が生まれる前に完璧なアーキテクチャを組もうみたいなアプローチをして爆散してる印象なんだよな
まあ、このあたりの話、単に経営者が技術に疎いとかそういう話ではなく、CTO的な人間がそういうマネジメント概念を持ってないケースもあり
アプリやサービスをソフトウェアエンジニアが作るときに「ここはSaaSで賄いましょう」「ここは自作しましょう」みたいな判断を迫られがちです。
プロダクトごとに背景が違うので一般論は述べにくいですが、最近の僕の気持ちはこんな感じ、というのをまとめておきます。
内製したい人たちは一定いまして
- 「ここはコア機能だし、SaaSにするとサービスクローズされて詰みますよ！」
- 「SaaSの料金はスケールで掛かってくるから、この想定ユーザ規模だと内製した方がお得ですよ」
みたいなことを言ってきます。（それは確かにその通りなんですが）
ここで一個邪悪な論点があります。
エンジニア的には「認証基盤を内製しました」とか「課金基盤を内製しました」とか「エラー監視機構を内製しました」みたいな事が言えると、SaaSを使ったって言うより将来のキャリア形成で有利と言うのがあります。
さらにCTOやCEOにとっても「わが社はここを内製しました」みたいなアピールをするのは「SaaSを組み合わせてペペッと作りました」よりかっこいいという問題があります。
技術的挑戦は福利厚生という話の一種だ
先月末で約15年程勤めた技術者派遣を辞めてメーカーの正社員に転職した。
辞めるに当たって思っていた気持ちとかを書いておくので、技術者派遣に就職・転職しようと思ってる人は是非参考にしてほしい。
ただし、以下は俺が所属していた技術者派遣会社の話と、派遣先で一緒になった他の技術者派遣会社の人から聞いた話だけなので
全てが全て当てはまるわけでは無いとだけは言っておく。
■ 辞める理由について
辞める理由は大体3個くらいあって、
- 理由1：給料が上がらない
- 理由2：正当に評価されないケースが多い
- 理由3：家族、親戚、友人から誤解される
以下でそれぞれについて説明する
■■ 理由1：給料が上がらない
もちろん技術者派遣会社にも寄るが、労働組合があっても機能していない(ただ存在があるだけ)のケースが多く、
世間がやれベースアップだ、物価高高騰してるんだから給料上げろみたいな風潮になっても
上がる給料は所属年数で上がる昇給額の数千円くらいなもの。
転職サイトとか見ると技術者派遣会社は最低保障給が比較的良い会社が多いが、
それ以上大幅に上がることは無いと思った方が良い。
■■ 理由2：正当に評価されないケースが多い
派遣先に評価者が一緒に派遣されている場合であれば多少融通は利くのだろうが、
派遣元会社から一人で派遣先に派遣されている場合だと評価者が業務内容を把握しにくいケースが多い。
どんなに派遣先企業から良い評価を頂いていて、実績として売り上げなどに貢献した数字が出ていても
それらが評価として自分に返ってくることは非常に希
なぜなら評価者は他の派遣者からも盛りに盛られた自己評価を出す一方で業務中のミスなど失敗は全て隠すので、
それらを全て信じて評定をつけていたら全員の評価が優秀になる。
そのため、自己評価の5〜7割程度しか自社からは評価されないケースが多い。
■■ 理由3：家族、親戚、友人から誤解される
これが正直一番キツかった。
技術者派遣会社は俺の知る限り全てが登録型ではなく技術者派遣会社に正規雇用された社員を派遣している。
そのため派遣先企業からすると「派遣」であっても、社会的には技術者派遣会社の「正社員」である。
しかし世の中では「派遣」というと「登録型派遣」が真っ先にイメージされ、
どこの会社にも正規雇用されていない非正規雇用だと思われる。
そのため、親族や友人と仕事の話になり、今は技術者派遣会社であることを話すと大体が哀れんだ目で見てくるか、
偉そうにも上から目線で「早く正社員になれるといいね」などとぬかされる始末。
その都度、技術者派遣は旧・特定派遣なので技術者派遣会社に正規雇用された正社員がメーカーなどに派遣されて働いているので、
社会的な肩書きは正社員の会社員であるという話をしないといけない。
そしてそこまでしっかり話してもそのうちの3割程度は理解出来ない人が多い。もちろんそれは俺の説明が悪い場合もあるが。
先日実家に帰った際、技術者派遣を辞めてメーカーに転職するという話を母親にしたところ、母親すら誤解していたようで
「ようやく正社員になれたんだね、良かったね」などと言ってきた。
技術者派遣会社に勤める前に業種の話だとかはもちろんして、正社員だから福利厚生もしっかりあるという話をしていたにも関わらず、だ。
つまり俺は親から"15年もの間非正規雇用の不安定な業種に就いている"と思われていたという事である。
さすがにこれにはガックリきた。せめて親ならばそこは把握していて欲しかった。
■ 結論
技術者派遣は理系大学でも入社、未経験者でも転職できる事が多いので、
技術系の会社で働きたいがメーカーには転職できないのでという踏み台として使うのは最適だと思う。
だが、上に挙げたようなデメリットも多いため、転職の踏み台として考えるのであれば5年程度を目安にすると良いと思う。
■ 個人的なお気持ち表明
一般的に思われがちな派遣を広めた元凶と言われている竹中平蔵氏についてだが、
真意はどうであれ少なくとも俺は竹中氏に感謝こそするが恨み辛みは1mmも無い。
技術者派遣が無ければ次の転職企業には入れなかったのは確実なので、広めてくれてありがとうという気持ちが強い。
(先日なにかの記事で派遣を広めたのは竹中氏では無いとあったが)
それよりも『「派遣」=「登録型派遣」である』
という風潮を広めたヤツ、お前が死ぬときはマジで苦しんで苦しんで苦しんで苦しんでから死んでもらいたい。
そいつには非常に強い恨みがある。お前のせいで俺は何度受けなくて良い職業差別を受けなくてはいけなかったのだ。
本当にこの風潮を広めたヤツだけは許せない。誰だかさっぱりわからんのだが。
日本の機械系技術者ってクソの集まりだからすぐ「日本人は投資しない」みたいに間違った主張するんだけど
一方で日本の食品系技術者は普通に働いてるんで、ちゃんと投資を受けてるし、どんどん新技術を開発してるしで、しっかり回ってるんで別に日本は技術者や研究者を軽視してるわけじゃないのよね
じゃあ何なのかっつーと
・ロボやITなど一部のオタク臭え分野は資金を私的な挑戦に横領するゴミ人格が多くて避けられてる
・真人間の多い食品・建築・自動車などはちゃんと多額の研究投資を受けている
結論としては、ゴミ技術者とかゴミ研究者が集まりやすい分野から投資が引き上げられてるだけ
これは別にアメリカでも同じことで、向こうの研究者らも「アメリカは技術に投資しない」とか言ってますからね。Google とか Amazon があってもそれ
結局こういうのって「ゴミ技術者が遊ぶために金をドブに捨ててくれる人が居ない」ってだけの話なんで、大体全部の国で言われてますね
これって国の研究力に問題があるとかではなくて「国の特定分野の技術者の人格に問題がある」ってだけの話なんで、まともに相手をする必要は無いですよ
そこに金入れるのってドブに捨てるのと同じで、100％絶対に何も出てこないからな。それをゴミ共は屁理屈で「わからない」にしたいわけ
でもね、当たり前なんだけど、真っ当に働く技術者集団と、資金を得た瞬間に遊び始めるゴミの集まりだったら「当たる確率は明確に違う」んだわ
違うから「資金を出した人間が破産する確率が違う」わけ、真面目な人に金を出した人は生き残り、ゴミに金出した奴は死ぬ
それで経済淘汰が進んで、ある国のゴミ技術者が集まりやすい産業に金を出す人間ってのはどんどん減って消えていく、日本だとそれがロボ系ってわけ
アメリカだと食品加工系の分野がゴミで、だから UberEats みたいな飯屋→家みたいなサービスが産まれる
これは本当にそうで、明らかに個人的な趣味やこだわりを製品に盛り込むエンジニアは多い。
己の業務経歴書の彩りを増やす為にキャッチーな技術を使いたがるのも広義の意味では同じだ。
マンガやアニメでそういうのが「技術者魂」みたいに美化されているのも原因だろうか。
結果としてオーバーエンジニアリングや使われもしない機能セットなどが発生し、技術的負債と化して後任のエンジニアが怨嗟の叫びを上げることになる（その頃には最初に作った人間は転職している）。
ベンチャー企業などはエンジニアが技術で遊ぶことを福利厚生の一環（＝求人戦略）としているので、余計に勘違いしたエンジニアが増えやすいという問題がある。
なんか最近は自分達の能力や実績を立証できていないのに自分達が開発において一番価値を持つものを作ると思っていて、自分達がやりたくない事は周りがやるべき、自分達の価値創造の為に周りは頑張る、または奉仕をするのが当然みたいな論調のソフトウェアエンジニアが増えた気がする。
周りが自分達にとっての快適な開発環境を用意するのは当然だし、進捗は周りが自分達がやってる内容から負担をかけずに知るべきだし、進捗等聞いて圧をかけるべきではないし、能力が足りない場合はそれを学ぶ時間を調整して確保すべきだし、文書等作りたくないものはやりたくないので我慢すべきだし。
ビジネスのゴールや顧客への仕様は周りが用意すべきだし、ステークホルダーとの交渉は当然リーダーやマネジメントの仕事だし、コミットが未達でも自分達は頑張ったのだからその中でどうにか顧客を納得させるのは周りのやるべき事だし、コードをリファクタリングする時間も当然周りが確保すべきだし。
規律等は創造性を狭めるから敢えて定義をしないと言って自分達を律するコミットはしないし、それで理解が足りない場合は説明責任ではく周りの知識不足が原因だし、成果の質で悪い場合の責任を取るのは周り、よい成果を受領は自分達の当然の権利。なんか書いててあれだけどホントよく見かける。
GAFAなどがやっているから、成功している事例を聞いたなど自分達ではなく周りの成果は自分達の成果と同義的なアピールをしてたりする。客観的に見てみると正直昔も今もソフトウェアエンジニアが出している成果に劇的な大差はないのに、自分達を金の卵を生み出す鶏のように大事にせよと言う。
自分達が価値を作るんだという心意気は全然いいし、そうあって欲しいけど劇的な成果を出した訳でもないのに待遇は1流にしてくれというのはおかしいと思ってる。だって変でしょ？売れてもないデビューすら怪しい漫画家が周りに人気漫画家みたいな要求するのは。そりゃ売れて貢献してから言えとなる。
昔は社内など閉じたコミュニティで歪んだ自己評価が問題になって世間を見ろという話が多かったけど、今のソフトウェアエンジニアは社外だけど閉じたコミュニティで歪んだ自己評価が増えている気がする。ネットには自分の意見を肯定する都合の良い意見が溢れてるので自己評価が正しいのか判断が難しい。
こういう極端なソフトウェアエンジニアカースト的な我儘を推奨するような現在の状況は正直どうなのかなと思ってる。自分もソフトウェアエンジニアだけどそんなにカースト作るほど価値作ってないよ。ホント。素晴らしいプロダクトができたってニュースがあったからってそれは自分達の成果じゃないよ。
君ら本当に自分達の現在の立ち位置を見てる？と。自分達が大きい存在だと思っているかもしれないけど、それは本当に成果を出している人達の光を背にしているからできている影で実体ではないよ。自分達で光ろうとするのはいいけど他人の光でできた影で自分を大きく見せるのは悲しい話だよと思う訳です。
ソフトウェアはハードウェアの上で動く付属品扱いされていた時代の人からすると今のソフトウェアエンジニアの立場の向上は嬉しいけど、実体の伴わない我儘や傲慢な態度の人が増えてくるのはホント周りの真面目なソフトウェアエンジニアの価値毀損にもなるので勘弁して欲しいと思う今日この頃です。
サーバーもBFFもフロントもライブラリのプラグインすらもクリーンアーキテクチャで書かれてて、それはさすがに思考停止に近いのではと思ってしまった
自分がまだ詳しいほうのフロントで言うと誤りに近いと思ってて、状態がクラス階層の奥にあることで変更検知がいびつになったり最近の動向はその真逆だし。そもそもドメインロジックは大抵フロントにないし。
言語やライブラリの風習をすべて無視して全部これで行くってのはまあ一つの戦略としてありなのかもしれないけど個人的には否定的だ😎
まあでもこういうのTwitterに放流するくらいで実際に議論する気があんまなくて、PoEAAもエヴァンス本も読んでないのでそのへんで殴りかかられるとなんも言えないし読む気もない
クリーンアーキテクチャの本質を反映したコードでなく、本で紹介された用語や図を全部もりでそのままコードにおとしこんだものは、うげーってなりますね
これはあるある。
「本に書かれていた事をちゃんとやりました！」 みたいな事言われると、受験勉強じゃねぇんだからよぉ...ってなってしまう。
「何故そうする必要があるのか？」「そうするとどういうメリットがあるのか？」「そうしないと生じるデメリットは？」ぐらいの質問に即答できないなら余計な事をしないでほしいという気持ちはある。
まぁ、ピカピカの技術やアーキテクチャは福利厚生みたいな側面もあるので一々言わないけども。
「最新技術触れられる！」的なのは福利厚生みたいなものなので。
現在進行系で経済的価値を生み出しているシステムを適切にメンテナンスできるドメイン特化のエンジニアの方が市場価値が高いのは冷静に考えなくても当然。
おそらくリファクタリングの工数を確保する説得力のある材料がほしくて、リファクタリングの効果をどう示すか悩んでる人がいたのですが、リファクタリングって非開発者に示せるような数字だすのは難しいよねという結論になったので、そのまとめ。
まず、リファクタリングはそれ自体では価値を示せません。人工衛星に搭載するプログラムで、動きだしたらメンテナンスできないようなコードを最後にリファクタリングしたとして、どのような価値を示せるかと考えると想像できるのではないかと思います。
あと、「住めば都」原理により、人間はそれなりに散らかったコードでも割と適応して、結構コードを把握できてしまって、リファクタリングの効果が構造の変化ほどは出ないんではないかというのもあり。
もちろん、リファクタリングがちゃんとされているコードと書き散らしのコードでは、作業の気持ちよさが違います。ということはリファクタリングはエンジニアの精神衛生を保つ福利厚生の面が高いんではないでしょうか。
福利厚生、つまり、エンジニアに与えられる金銭以外の報酬ってことです。
レビューはエンジニアの好き嫌いとか最近興味がある技術とかなどの思いの丈を語る為に提供されたしゃべり場ではなく、成果物の品質が基準に達しているかを確認する場という事が分かっていない人がホント多いなというが最近の感想。
この手のレビュアはひたすら自分の好みを語るけど、じゃあその指摘を反映させないと成果物は要件を満たせないのかというと大体そんな事はない。その指摘はどの品質要件に紐づくのかと聞くと大概明確な回答はない。代わりに”今のままでも問題はないけど…こうした方がよりいいって話”と言ったりする。
別にこれらの指摘は純粋な技術議論として変な話ではない。ただ場が違うだけなのだ。これは要は技術を議論して組み立てる場と出来た物が適切に出来ているかを判断する場というのがきちんとそのチームで定義できていない事に尽きる。事前に指摘をしたくても場がない為レビューの場が使われてしまう。
ただこの手の指摘はプロジェクト運用からすると正直進行の障害になるのも現実であるので、事前にこれらナレッジワーカーの意見を吸い上げて合意形成を事前に取る場が必要になる。その為に場を作るのはいいんだけどナレッジワーカーは基本俗にいう”つよつよエンジニア”が多いのでその運用が難しい。
書面レビューなどを使ってある程度抑制する手段もあるんだけど、これをやるとそのナレッジワーカーのチームや組織への不満度が高まる。何故かというと、この手のエンジニアは技術的な指摘がただしたいだけではなく、【自分の言葉で相手と直接対話して議論をして意見を反映させたい】のだ。
要は、以下の環境を彼らは欲している。
・技術的に語る題材が既にある
・自分で準備は必要がない
・ある程度のオーディエンス
・直接意見が言える
・指摘をしても問題のない場
これに今一番近似する場がレビューの場なのだ。書いてて思ったけどすげーわがままだなこれ。
この手の語りたいナレッジワーカーエンジニアのモチベ維持と彼らから有効な指摘を貰う為にはこれだけのコストを払う必要があるって話になる。おまけにクリティカルな指摘が来るかは運次第。そしてそれが反映されていないと"指摘したのにあいつらわかってない"とモチベが下がるリスクもある。
プロジェクト運営側からすると、本当にこれ払う対価があるのかなと思ってたりもする。なのでこの場に用意する事に対しては消極的である。ただレビューの場で暴発されても困るし。モチベを下げられても困る。なんかうまい方法ないかなぁとは思うけどなかなか見つからない。困ったもんだという話でした。
技術で遊べるのも福利厚生として必要な側面である一方、「今、それを、ここで、議論する意味は本当にあるのか...？」みたいなことをされると温度感が一致してないと即座に辞めたくなるというのはある。
俺の経験則でしかないがエンジニアって単価や給料が上がれば上がるほど労働の辛さが逆に下がるバグある
儲かってる良い会社だと、もはや労働の辛さより面白さが上回ることもある
つまり、単価や給料の安い会社はカス
最新の技術やアーキテクチャへの挑戦はエンジニアにとっての福利厚生である。そして、福利厚生は儲かってる会社ほど潤沢に投資できる。更に本業が儲かっているなら挑戦が少々失敗しても「戦略的投資」で片付けることができるのでシビアに評価されることもない。
というわけで、利益は全ての痛みを麻痺させてくれるのである。
公的機関（とある病院）で情シス部員として、もう何年か勤務しているが、なかなか酷い。
公共機関全部が一緒じゃないことは分かっている。
でも、これが医療情報学会が育てた医療情報技師の姿なのか？
■理由1：請負業者・外部業者に丸投げ
保守、運用管理を別業者に委託するのはよくあるにしても、
「保守・運用管理以外の仕事」も丸投げしてしまう。
理由は単純で、正職員が「定時で帰りたいから」と、「やっかいな仕事はやりたくないから」（正職員のくせに）。
あと人によっては、実務担当職で採用されているのに「研究がしたいから」を理由に請負業者に丸投げしている（口では言わないが、見てたら分かる）。
ちな、請負業者は契約を切られたくないから、理不尽でもやらざるを得ない。
医療情報部的な部署がある医療機関になると診療情報管理士がいることもあるのだけど、
ITとか全然知らない人も多いので、文書とか診療情報のことに関しても、
「ITとか全然分からないから」ということで「保守・運用管理」だけが契約範囲の業者に丸投げする人もいる（管理士の仕事なのに）。
ただ、診療情報管理士が個人的に丸投げしているわけではなく、当病院では部署ぐるみ。
実際はできないから投げているのではなく、雑用だと決めつけ、やりたくないから、投げているのが実態。
正職員を甘やかしている。
まぁ、でも、当院の診療情報管理士について言えば、とりわけ、丸投げとか「これは私の仕事じゃない」とすぐに逃げたりするのですけどね（システム職ではないが）。
「システムのことなんて分からない」と言えば、すぐに誰かに押しつけれる（請負業者に）。
そして、甘やかしてそれを認めてしまう文化。
それに対して、請負業者・非常勤職員は雑巾のように扱われる。
請負・非常勤が大変な状態になっていても、「役割が違うから」と手助けすることは一切ない。
反対に、正規職が大変な時は、請負・非常勤は手助けをするように求められる。
医師・看護師が怒っても責任も含めて丸投げしているのが現状だから、改善しない。
現場から怒られるのは責任の重いはずの正規職員ではなく、半分は組織の外側にいる請負業者の社員と非常勤職員。
逆に、忙しい人間を尻目に、半日以上も政治の雑談したり、業務的に必然性のない資格の勉強をしている職員も実際いる。
不健全でしょ？
で、「自分、公務員だぞ、いいだろ」という態度出てるんですよ。
そのくせ、指示されなければ何もしないのだけどね（当院について言えば、これは管理士・事務方に多いな）。
「発注側」という高みに立って上から目線になっているのもあるし、
端から見ていると「自分たちは公務員で誰もが羨む天上人」という意識があるようで、
「公務員になれたというゴールを達成」したものだから、自己研鑽するという意欲さらさらない（実際にない）。
ちなみに、自己研鑽をしなくても怒られることはない。評価も下がらない。民間企業ではありえないぬるい職場。
あと、簡単な帳票を作成する作業でさえ、業者に頼らないといけない。
Accessレベルを使いこなせない、のが実態。
ああ、あと、公的機関は予算は全部使い切るのが基本なのも一因かもね。
手が空いている人もいるのに、請負・非常勤に実務はそちらにふって、業務中に業務に関係ない資格の勉強をする人もいるのだけど、
請負・非常勤の存在がないと、そういう仕事の仕方は成り立たないでしょ。
腐ってるけど。
ちなみに、非常勤職員は1年の任期付きなのだけど、確信犯的に継続を繰り返して任用することが普通になっている。
「時短勤務をしているだけの常勤職員」のはずなのに、経費の安い非常勤にしているだけ。
■理由2：実務経験者が少ない
あとでも書くけど、特定大学のある研究室の就職の受皿になっているせいで、競争試験が形骸化している。
医療情報学会経由かつ、その大学の人間が優先的に採用されるのが実態。
こういう人は大抵がSE実務の経験はないけど、「研究だけはしたい」奴ら。
帳票作れば多少の業務改善もできるのだけど、そんなこともできない。
ただ、研究は大好きらしいので、医療情報学会とか論文の書き方は詳しい。
だけど、現場の医師・看護師さんが困っていても、
研究＞＞＞＞＞＞＞＞実務
という優先順位。
大丈夫、仕事が溜まったら請負業者・時短勤務の非常勤職員にねじこめばいい。
こうして、
- 定時で帰宅する正規職員
- 実務そっちのけで研究に勤しむ正規職SE
- 仕事をねじこまれて残業続きで給料の安い請負業者・時短勤務の非常勤職種
という構図ができあがる。
医師や看護師の実務を改善してそれを研究成果にする、なら納得するのだけど、
あいにく、そうではない（あまり書くと身バレするが）。
技術的に分からないことがあったらどうするか？
これの解決方法は、簡単。
外部業者・請負業者に分かりやすい資料を作成させて説明させればいい。
「説明するのは、お前らの仕事だ」と恫喝してね。
こうして、専門知識を勉強していくわけさ。
理由3：正職員の目標管理制度がザル（形式だけ）
そりゃあ、自己研鑽を義務づけたら自分たちが大変になるのが分かってるから、上司ぐるみでちゃんとやらない。
DXもくそもない。
■理由4：ずっと同じ作業しかできなくても評価は下がらずボーナス満額もらえる
公務員は絶対に首にならないからね。
むしろ、DX推進なんてやったら仕事が増える。
だから、やらない。
やっても、やらなくても給料は一緒だから。
だったら、やらないほうが楽だよね？
現場の医師・看護師は大変だけど、「別業務で大変だから」とか「できない」と言えば、何とでもなる。
実態は、暇で手の空いてる人もいるけど。
ちなみに、現場の医療職が怒っても、電話は受付対応は非常勤職種と請負業者に全てやらせている。
これについては、ある診療情報管理士の正規職員がこう言っていた。
「電話や受付対応をすると怒られたり、トラブル対応のために走り回って調べないといけないから、やりたくない」
「専門知識がないから対応できない」とか「正規職員の業務に差し支えるから」、という理由なら理解できる。
でも、そうじゃないのは見れば分かる。
ただただ、高ストレスの仕事で仕事の種類として嫌だから、えり好みしているだけ、なんだよな。
病院という組織の立場に立って責任ある地位にいるから高い給料を貰っているのに、ね
実際、正規職員はSEも含めて、後ろに隠れたがる。
責任感ある正職員もいるが、全員がそうじゃない。
回答の責任も丸投げし、現場の怒りは請負業者・非常勤職員に対応させる。
正規職員の責任なんてどこへやらだ。
博士課程で採用された人は、「私、博士卒だから給与はいいですよ〜（笑顔）」と言ってた。
6時間勤務のはずの非常勤職種にも、常勤職員には与えないような詰め込みの仕事、残業が発生しやすいトラブル対応の仕事を与えることも普通。
見る限り、時短勤務の職員が残業をする率が高く、申請もきちんとしていない（あまりきちんとやると「なんで多いんだ」と怒られる）。
請負業者も同じような境遇だ。
人の入れ替わりが多く、どんどん人が辞めていく。
でも、直接雇用しているわけじゃないから、何も問題視はされない。
でも、こうなって一番困るのは、現場の医師・看護師・コメディカルなんですよ！
■理由5：特定大学出身者でポストが独占されてるから外部者が入らず、改善の余地がない
まぁ、これも大きいよね。
能力じゃなくて出身大学で取るものだから、実務能力も関係ないし、公正な競争もない。
白い巨塔で育って来た人に実務ができるわけがない。
クビにすることもできない。
できないから請負業者、非常勤職種に丸投げするしかない。
ちな、公的機関（独立行政法人も）は、採用にあたっては必ず公募をしないとけない。
でも、特定の人しか入れないようにするための抜け道がある。
これは、自分の職場で実際していることなのだけど、
採用条件を他の人が応募できないような条件にしてしまうこと。
「博士課程保持者」とかね。
実際は博士課程の人間じゃなくても十分できる仕事なのだけど（そもそも実務の仕事に博士課程は必要とは言えない）、
特定大学の特定研究室の就職の受皿になっているから、要するに、特定者に便宜を図った不公平な採用が行われいるんですよ。
公平な競争なんて、一切無い世界ですよ、公共機関なのに。
法令遵守してんのかよ。
で、来た博士課程の人と言えば、院卒なのに実務的な対応能力なんて無いんですよ。
実務を担う職種に研究職を無理矢理ねじ込んで研究活動してるもんだから、現場から問合せが来ても他の誰かが代わりに対応しているのが実情。
理由6：職場・組織の問題に対して当事者意識がない、現場対応から逃げたがる
現場の医療職からの問合せに対して、受付対応・回答（調査をさせたりも）を請負・非常勤職種にやらせ、
正規職はコア業務へ集中したいからと称して、ネットのニュースサイトをずっと見ていたり、資格の勉強をする者もいる。
正規職には現場の怒りは届かない。
彼らは後ろに隠れたがる。当事者意識なんてものはない。
なんだろうな、こういう意識の持ち方は公務員特有だという気がする（当然人によるよ）。
ああ、そいや、正職員の方々の中には、情報収集に熱心な人がいて、
管理する立場でもないのに請負業者が記録している対応の履歴を業務時間中にやたら細かく見てる人も、一定数いる。
職務上は明らかにする必要ない行為なのだけど、そんな時間をわざわざ作る余裕があるから不思議。
で、現場対応、窓口対応は嫌だと言う。
情報収集に熱心なのは、重たい仕事が自分に来ないよう注意してるからだが。
現場対応はできればやりたくないから請負業者・非常勤職員にやらせる、これは本当に多い。
これは本当に正規職員の給与に見合った責任ある行動なのか？
正規職員のイスはもらった。大変なことは別の人にやらせて、楽もしたい。でも、しっかりとした給与も退職金も福利厚生もほしい。
それが実態。
理由7：そもそも経費削減・業務効率化という意識がない。経費の使い方ガバガバ。
だって、年間の予算全部使い切らないと次年度から減らされますから。
備品、必要ないのに買いまくってます。
数名は職場の自分PCに、iMacを使用しています。
当然、予算で買っている。
Macを買う業務上の必然性は一切ありません。
ていうか、職場のシステムはWindowsがベースなんで。
なぜMacか？
当人達いわく「かっこいいから」「Macがいいから」だそうです。
同等の性能ならWindowsのほうが絶対安いですよ。
でも、「Macがほしいから」というだけの理由でMacを買ってました。
いいねー、公務員。
こういうことをするのは大抵、公的機関で純粋培養された職員です。
職場全体は慢性的に赤字なのだけど、経費は使い切るものという意識があるようで…。
さすがに自分はMac買ってません。
無駄遣いすぎることが分かっているので。
あぁ、あと、ブレードサーバーわざわざ買った人いるけど、
あんまし使ってらっしゃいませんね。
研究費は使い切るもんだという意識もあるみたいですが、それにしても無駄遣いでは？
業務効率化も糞もないのに、ボーナス満額もらえるんですよね、国の財源で！
これが、公共機関の情報システム部門ですよ。
DXなんてできない、というより、DXなんてそもそもやる気がない。
だって、自分のことしか考えていないからね。
こうしている間にも、医療職はどんどん疲弊しているというのに。
くたばっちまえ。
医療情報学会も嫌いになりました。
これが、お前らの言う、コミュニケーション、コラボレーション、コーディネーションの本当の姿だったんだな？
言っても何も変わらないんだ。
だから、ここに書いて残す。
今、IT業界は人手不足だ。
それでもIT業界の大部分を占めるSI業界が体質を改めるどころか更に姑息になっているので、これから就職活動をする学生さんには気を付けてもらいたい。
その姑息さが目立つのが客先常駐をメイン事業とした企業の存在である。
社員数200人以上の規模を誇る独立系企業でも客のセキュリティの都合上、社員を客先に常駐させている事が多く「自社開発」と言っても「客先での開発」になる事がほとんど。
SI業界のユーザー子会社・メーカー系・独立系は共に客の都合で客先常駐にならざる負えないのが現実である。
それぐらいは業界研究してる人には既にわかりきったことかもしれないただ求人広告に記載する内容が詐欺に近いデタラメを載せる企業が多いので自分が見た事実を元に警告しておきたい。
まず、１回でも名刺交換したら取引企業として扱う会社が存在するため規模が小さい割に名だたる大企業をたくさん載せてる会社は危ない。
面接まで進んだら取引企業との関係と業務について具体的にどんな事をしているか聞いてみよう、口ごもり始めたらその会社の面接官はバカか主な取引がないのに載せている事になる。
そして、求人広告で主な事業内容に「ネットワーク構築・運用」とか「ソフトウェア開発」とだけしか書かれておらず具体的な事は一切書かれていない会社は危ない。
そんな書き方をする企業は客先で派遣された自社の社員が何をやっているか把握していないだけでなく、SES派遣をメイン事業としている可能性がある。
面接まで進んだら客先での主な仕事と単独派遣かチームで派遣か聞いてみよう、ほとんどの会社が「派遣先によるので何とも言えない」とか「セキュリティの都合上くわしく説明できない」とか
「1人での派遣もありうる」と答えるはずだ。その時点でSES派遣をメイン事業としている可能性が非常に高い、その会社はやめよう。
加えて福利厚生や社内制度も社内で利用した人がいるか聞いた方がいい。
理由は利用実態がない制度は絵に描いた餅状態になっていることが多く、福利厚生や社内制度が事実上存在しない会社もあるからだ。
そんな会社は利用した人を異端者扱いしてパワハラなどで退職に追い込む可能性がある。
SES派遣について説明する。
SESとは「システム・エンジニアリング・サービス」の略で、簡単に言うと「お客様の要望に沿って業務を支援する業態」である。
その業態をメインとしているかはほとんどの企業が表に出さず求人票や求人広告にも一切載せない、と言うかそもそも載せられるほどクルーンな業態ではない。
一昔前はSES派遣と言っても客や他の派遣社員と一緒にマネジメント・開発・構築・運用・保守に携わる事が出来たため主に新卒や新人を派遣する時に利用された。
営業からすれば「使えない子だけど最安値で派遣するので使ってやってください」みたいな意味合いがあったと言う。
しかし、今はシステムの高度化や少数精鋭でコストを抑える会社が多いためSES派遣された新卒を受け入れる余裕がある現場が少ない上にソフトウェア開発と聞いて
派遣したらやることはExcelとwordを使ったマニュアルの更新と客からの問い合わせ応対だけとか、システム運用と聞いて派遣したら在庫管理倉庫に放り込まれて
毎日段ボールを開けながら在庫の確認をするだけと言った性質の悪い派遣先が多く買い叩かれる事も多いため、技術力が身につかない上に低賃金と言うのが実情である。
そもそもSES派遣は多重派遣や偽装請負が横行していることが多く、「A社からB社に派遣」と言う契約でも「A社からD社を経由してC社を介してB社」や「A社からB社に１人請負でSES派遣されたけどD社の指示で動いてる」
なんて事も多くSES派遣＝違法労働なんて認識になりそうな状態だ。ただこの問題は派遣社員が気が付くことが少ない、理由は労働法を知らない人が多すぎて派遣会社の言いなりになってしまっているからだ。
辞めるか退職に追い込まれても知らないままの人が多く表にも出にくい。
この問題は面倒な一面もある、それはSES派遣で「運よく技術的な仕事ができるポジションに着けた人」の存在である。
「運よく技術的な仕事ができるポジションに着けた人」は客先常駐型の派遣を肯定する傾向にあり違法労働も良しとする人が多い。
多重派遣を「社員を待機にさせないためには必要なこと」、偽装請負を「客の利便性を考えると多少の法律無視は仕方がない」と言うとんでもない存在もいるが、技術力があるため
先ほど記した技術力が身につかない上に低賃金なポジションに着いてしまった人よりも発言力があり業界内で幅を利かせている事が多い。
そんな人は「派遣先で技術的な仕事が出来なかったのは本人に問題があるのでは？俺はできてたし」と言い実態を知ろうとしないため問題を自己責任で処理し、表に出来にくい空気を作ってしまっている。
客先常駐の技術者は守られるのか。
これは「守られない」と断言できる。
チームでの派遣であれば多少守ってくれる人もいるが単独もしくは少人数（4人か5人）だと客先での技術者の立場が弱くなり奴隷にならざる負えないのが実情だ。
極端な話、自分以外は全員客な状況と考えると良い。自分たちにサービスを提供するポジションの労働者を客が同等に扱うだろうか？
客先常駐技術者の評価を下すのは客で昇給させる権利を握るのも客だ、そもそも派遣とは営業と客先の責任者の交渉の末に行われることであり評価と賃金を交渉材料にする会社が多い。
多くの場合、派遣会社の営業は客に従うため客が「安くこき使いたい」と考えて低評価で低賃金を主張したら余程の事がない限り営業は客に従う。
1聞いて10知るような要領がいい人（頭がいい人）は稀にいるがそのレベルにならないと評価が上がることも賃金が上がることもない。
客のほとんどが「こっちは金を出してるんだから教えることに時間を取ることもミスすることも許さない」と考える人が多いのが原因なのだが取引先を怒らせる事を恐れる営業は客の言いなりだ。
その状態が続いた上にSES派遣で派遣された技術者は40歳になってもこれと言った技術が身に着くことなく低賃金労働を強いられ、転職さえも難しくなるという３重苦に陥ってしまう。
それなのに年齢を理由に派遣先から契約打ち切りを通告される人も多く、そうなった社員は派遣会社から自己都合での退職を迫られ多くの人が自己都合で辞める。
派遣会社としてもSES派遣メインで派遣され何の技術もない無能に用はないのである。
今はもっとひどい。
それは新卒をSES派遣して現場にねじ込む会社が増えてきている事だ、今までで一番ひどいと思ったのが「専門学校でプログラミングを学びjavaの資格も取った新卒が客先でシュレッダー係りになっていた」話だった。
彼はその会社の技術者重視・ソフト開発メインと書かれた求人にひかれて入社したようだがSES派遣で5社ほど介して派遣されたのちプロジェクトでソフトを開発するためのチームに入って雑務処理をしている。
もちろん違法性に気が付くことなく、営業や会社からは「今は下積み段階だろうから頑張ろう」と励まされ元気を出して黙々と客先でシュレッダー係りをしている・・・・これが下積みと言えるのか。
元請けや1次請けの新卒が初歩的な業務を行っていると言う話だったのを考えると恐らく技術の初歩的な部分を元請けや1次請けの新卒が行い多重派遣で派遣された彼は雑用処理要員として派遣されたのだろう。
一度彼を見たことがあるが、まだ新しさが目立つスーツを着て小奇麗な革靴を履いて新卒特有のキラキラさを持っていた・・・そんな彼が元請けのネームカードを首にかけて延々とシュレッダー係りを務めているのである。
新卒でSES派遣するような会社に入り悪質な派遣先に派遣されてしまった彼は運が悪かった人なのだろう・・・・でもこれを運の悪さで処理をしていいのか？
警告する、具体的な事業内容を記載していない求人を出す会社に新卒が入るのは危険だ。
しかし学生のレベルによってはクソみたいな会社から、クソくない会社を探す羽目になる事もあるだろう。
だからそんな会社に入らざる負えなかった人は、なるべくはやく転職することを考えて行動するべきだし労働法も勉強しておくといい。
自己責任を理由に闇に葬りされないようにな。
■追記
いつの間にか注目された記事になったようだ、勢いで書いたために確かに誤字脱字がひどい。
新卒SES派遣で辞めるまで劣悪な環境で働いていた労働者は無能と言う反面教師にもなると思うのでこのままにしておく。
労働に対して何の免疫も知識もない新卒が就職した会社の違法労働状態に気が付くのは稀だと思う、新卒で就職したら誰しも就職した会社が基準になるのだから。
それをいいことに、間違った社会の常識を新卒に吹き込み奴隷のように扱い不要になれば退職強要して自己都合退職させる客先常駐メインの企業が自分が見てきた範囲だと多かったので騙されないように予備知識として書いた。
「客先で仕事をさせてもらっているのだから残業代を要求する事は社会人として間違っている」と言う派遣も見てきた、おそらく所属会社の入れ知恵だろう。
SES派遣はありえないなんて意見もあったが違法労働状態が横行する現場では法律はないに等しい（区別もない）、監査が会社に入ったら終わりだからありえないと言う意見も
そもそも監査がしっかり入っていたら事前面接や偽装請負や多重派遣やSES派遣が当たり前のように行われていないはず・・・・。
常識ではありえないような無法地帯化した現場や会社もある事を知ってほしいと思う。
最近は、特定派遣会社の一部で正社員を「限定正社員」にする流れが起きている、職種・地域限定の限定正社員にすれば体力のある特定派遣会社は今まで通り社員を客先に常駐させることができるらしい。
つまり雇用形態が「正社員」でも入社したら「限定正社員」扱いの場合もあるため「正社員」書かれていてもどのような雇用形態かは入社前に確認して欲しい。
そもそも求人票や採用情報に労働者を騙すような事を書いても問題とされない現状がおかしいのだが、改善される見込みはないため労働者側が気を付けるしかない。
タイトルの通り2018年に入社したNTTグループの某社を退職しました。
2019年１月中旬に正式退職したので、約9ヶ月間働いたことになります。
本記事では非常に主観的かつ局所的な話を書くつもりであり、一般性には欠けますのでご承知ください。
■自己紹介
NTTグループの某SIer企業に2018年度の新入社員として入社しました。
前年度までは大学院に在籍しており、情報系の研究を行っていました。
入社してからの立ち位置としては一応システムエンジニアに分類されるはずですが、あまりシステムエンジニアらしい仕事は行いませんでした(これについては後述しています)。
■退職までの流れ
2018年の4月に入社し、最初の2ヶ月間は新入社員研修を行っていました。
研修内容は大手企業あるあると言った感じで、挨拶練習や名刺渡し練習、ビジネス文章の書き方等を行いました。
周りは「研修が手厚くて良い」と言っていましたが、個人的には退屈なだけでした。
今振り返ってみると、この研修期間中が最もつらかった様に思います。
しかしながら研修自体は退屈であったものの流石に大手企業と言うべきか入社同期には優秀な方が多く、変な人間も少なかったため人間関係の面ではこれといった苦労はありませんでした。
6月になって研修期間が終わると正式に部署配属が行われました。
この時配属された部署に退職するまで在籍していたことになります。
部署自体の詳細についてはこのエントリでは伏せますが、元々配属を希望していた部署であったため、配属当初は安心した記憶があります。
■退職理由
何か1つこれが決め手になってといった明確な退職理由はありません。
インターネットで言われるようなSIer業界の悪評についても内定前から知っていて、実際に入ってみての感想としても「噂は真実だったんだな」くらいのものだったので特に入社したことに対する後悔もありません。
入社して詰まらない・つらい仕事であったら適当なところで辞めようと思っていましたし、その結果として詰まらない・つらい事象がいくつか重なったため退職するに至りました。
それらの事象を細かく挙げていくと切りがありませんが、そのうち幾つか分かりやすいもの(且つ社内機密や違法行為に当たらないもの)を以下に挙げます。
■■仕事の内容がほとんど雑務に分類されるようなものばかりだった
少なくとも自分が想像していたシステムエンジニアとしての業務は殆どありませんでした。
いわゆるSIerへの批判的な記事に挙げられるようなこと(Excelにスクリーンショットを貼り付ける作業、何に使われるのか分からない謎の資料作成、etc.)や、電話番等が主な業務でした。
新入社員に対して雑務を割り当てるというのはある種合理的な部分もあるとは思うので批判は控えますが、個人的には特に学ぶべきこともなく時間の無駄に感じました。
一方でExcelスクリーンショットに関しては批判するべき部分があります。
Excelスクショは「エビデンスを残す」という名目で行われることが多いと思いますが、システムが正しく動作したかを顧客に証明する目的であれば、結果ではなく検証をする方法を提供するべきではないかというのが私の意見です。
スクリーンショットなんてものはいくらでも改竄可能なもの(WebページなどであればDeveloper ConsoleでHTMLを書き換えれば良い)であり、普通に考えればエビデンスとしての効力はないと考えられます。
■■特に学べることがなかった
これは主にシステム開発・運用まわりについてです。
周りにはそれなりの年齢の方も多く、また社会インフラの構築を担うことの多い会社であるため、技術的な知識に造詣の深い方が多いと考えていたのですが、そのようなことはありませんでした。
大きな会社なのでそういった人も社内のどこかにはいるのかもしれませんが、少なくとも自分の周りでは観測できませんでした。
詳細は避けますが、技術的な知識に関してはその辺の情報系学部生の方が理解していると思います。
Linuxコマンドが分からない方向けにコマンドの打ち方をまとめた手順書(ターミナルエミュレータを立ち上げて、どこにユーザ名・パスワードを打ち込んで、どのボタンを押して...をスクリーンショット付きでExcelにまとめる)や殆ど問題を丸投げしている様な質問表等を作っていた時の心中は決して穏やかなものではありませんでした。
ファイル名の末尾に日付を付けるようなバージョン管理方法も噂では聞いていたものの本当に実在しているとは思っていませんでした。
また部署としては今後コンサルタントとなるような人材を増やしていきたいような雰囲気がありましたが、システムを殆ど理解していない人にコンサルが務まるのかはよく分かりません。
個人的にコンサルタントという肩書に懐疑的なのもあります。
■■環境に満足できなかった
主に常用していた端末周りの環境についてです。
使用しているコンピュータのスペックがあまりにも低く(メモリ2G、ハードディスク50GB、32bitOS)、まともに作業ができるような環境ではありませんでした。
Excelを開いたり、酷い時はIMEの変換機能を使用した時にもコンピュータが固まっていました。
上で雑務が殆どと書きましたが稀に開発をすることもあり、そういった場合は特にスペックの低さによるストレスを感じていました。
私自身そこまで気合を入れて仕事をするような人間ではなく、むしろできることなら仕事せず遊んでいたい人間ですが、やるべき仕事がくだらない原因で阻害されるというのはそれはそれでストレスが溜まるものだなと思いました。
自分だけでなく周りの人達の環境でもそういったことは起こっていましたが、周りの人達はこの現象について好意的に感じている(コンピュータが固まるのを理由に仕事をしなくても済むため)ようでしたので、その辺りの温度差も退職の理由になっています。
計算すれば高スペックのコンピュータを導入するコストよりも、低スペックなコンピュータを使うことにより生じる人件費の無駄の方が大きいと分かるような気がしますが、あまり計算が得意な人がいないのだと思います。
■■全体的な会社の方向性に疑問を感じた
これは主にセキュリティ施策についてです。
昨今セキュリティが重要視され、セキュリティに関する施策に予算が付くようになったのは良い点だと思っています。
しかしながら、実施される施策が的外れなものと言わざるを得ないものばかりでした。
的外れならまだ良いですが、それはセキュリティリスクを高めるだけなのでは？と言った理解のない上の人間が思いつきで実施したとしか思えないものもあり大変疑問を感じました。
意味のない施策で業務環境が不便になるのも見てる分には面白いですが、その中で仕事がしていきたいとは思えませんでした。
パスワードの定期変更や、暗号化zipファイルをメールで送り続いてパスワードをメールで送る等のバッドノウハウが未だに存在していることも知りました。
またこれはSI業界全体に言えることだとも思いますが、RPAとかDX(Digital Transformation)とか10,20年前に言うならともかく、今更言っても時代錯誤感が強いです。
■良かった点
退職理由として不満点を挙げることになってしまいましたが、良い点もありました。
■■残業がほとんどなく休みが取りやすかった
これは部署やプロジェクトに依る部分もあるみたいですが、少なくとも私の所属部署では早く帰ったからと言って咎められるようなことは殆どありませんでした。
最近は労働時間に関する制限がかなり厳しくなっているようで、残業が多い部署は上から注意されているようでした。
有給休暇についても申請して拒否されるようなことはなく、むしろ消化が推奨されていました。
休んだことにより後から文句を言われることもありませんでした。
■■周りの人が良い人ばかりだった
上司や同僚から理不尽な扱いを受けるようなことは殆どありませんでした。
入社前のイメージがパワハラ・モラハラは当たり前といったものであったため、非常に驚かされた部分です。
また少なくとも自分の観測範囲では人種や国籍、性別による差別は行われていないように見えました。
■■福利厚生が充実していた
流石にNTT系列と言うべきか、福利厚生は充実していました。
色々ありすぎて私も全てを把握できていませんが、恐らく福利厚生に関しては国内企業ではトップクラスに充実していると思います。
■■年収が高かった
少なくとも1年目の年収としては比較的高い方であったと思います。
業務内容の割に高いとも思いました。
日本人の平均年収程度は貰えていたはずです。
私の場合は残業は殆どありませんでしたが、役職のない若手が残業をした場合残業手当が付くため(役職がつくと裁量労働制になる)、残業をした場合は更に貰えると思います。
もちろん残業手当は働いた分だけしっかり付くようでした。
ただどうやら年収の伸びはそこまで良くはなく、聞いた話では20~30年勤続し管理職になってやっと1000万程度らしいです。
また国内大企業らしく厳格な年功序列制があるようでした。
■まとめ
入社してから退職までの約9ヶ月間を振り返りました。
ただ勤務中はかなりささくれ立った心境であったため、こうして比較的穏やかに振り返ることができて良かったなと思う次第です。
巷ではSIer崩壊説みたいなものもありますが、個人的にはSIerは今後も続いていくと考えています。
環境も改善していって数十年後に「あの時辞めなければ...」と後悔することになると面白いですね。
今後の身の振り方については決まっていて、ソフトウェアエンジニアとして転職をすることにしました。
具体的な企業名や待遇等について詳細を書くことができませんが、年収については前職であれば20~30年勤続し管理職になった場合と同程度になります。
最後になりましたが、読んでいただきありがとうございました。
■前置き
https://anond.hatelabo.jp/20181005233454
↑これを書いたものです。書いたとおり会社を離れることになり、次の職場も決まっている。8月から9月いっぱい活動し、複数社内定をいただいた。アラフォーのジョブホッパーだが、人生の中で最も就職活動がうまく行った時期だった。別に自分が優れているわけでも何でもなく、超売り手市場の売り手職種だったというだけである。しばらくは転職したくない。
以前高内定率のハイスペックジョブホッパー増田がバズっていたが、自分は平凡なおっさんジョブホッパーなので、多分この増田は誰かの役に立つと思う。
※例によって身バレすると現職と次職と面接受けた会社に迷惑かかるのである程度ぼかす。
■スペック
- アラフォー、WEBエンジニア。領域としてはフロントエンド。WEB系ベンチャー所属。
- 離職理由は会社の事業の方向性と自分の指向がずれ始めたため(加えて自分の採用に関わった人たちが会社を離れたことも理由の一つ)。
- 私立大卒で20代前半までは別業界、20代後半から制作会社→ECサイト運営→WEB系事業会社で次で5社目。いわゆるロスジェネ。一応マネジメント経験もあり。
- 志望としてはWEB系事業会社。会社規模にはこだわらない。受託会社やSIは行かない。
■これを書く理由
はてブもGoogleもすっかりアフィスパムに汚染され、ビズリーチやワークポートへのアフィブログばかりだったから。増田に書いたのもタダで拡散するため。
正直、並レベルの実力があるWebエンジニアならエージェントやビズリーチを使う必要はない。ヘッドハンティングがほしければ、Wantedlyにレジュメを登録して、Qiitaに何個か記事を投げておけば勝手に来る(役に立つかどうかは保証できないが)。
Qiitaじゃなくて増田に書いたのは、Qiitaはテック系の記事を投稿すべきものでQiitaにある転職系の投稿は全部ゴミだと思っているから。そもそも規約違反だしね。
■使ったサービス
■■Green
エンジニア転職の定番である。ここにレジュメを登録しておくと、確度の高いスカウトが来たり、「気になる」が届いたりするので、これを利用して気になった会社とコンタクトを取りカジュアル面談をする。
職務経歴書＆ポートフォリオも書面ではなくWEB(今流行りのサーバーレス)で作った。個人情報もあるので認証付き。去年あたりはやったOSS職務経歴書はやっていない。
試しに何社か自分から気になるを押してみたがほとんど反応なかった(自分がポンコツだったからもしれないが)。基本的にオファーを待つサービスである。
■■Wantedly
去年上場時にDCMA悪用で炎上したWantedlyである。はてブにいる理想主義者の人達はこのサービスを嫌うが、正直なところ代わりになるサービスもないので使った。採用側のときも使ってたし。
ここもレジュメを充実させて、ポートフォリオへのリンクを張ってスカウトを無制限に受け取るように設定。スカウトが来た会社の中で、特に気になるところにコンタクトを取ってカジュアル面談をする。社員数名のガチスタートアップから、上場したばかりの有名ベンチャーまでいろいろなオファーが来る。流石に創業メンバーをWantedlyで募集しているようなところはお察しなのでスルー。
この2つで合計15〜20社ほどとカジュアル面談し、数社を除いてほぼ「ぜひ本選考に来てください！」となった。旧来的な転職活動の書類選考はほとんどなかった。というか、レジュメとポートフォリオのおかげでほぼ書類はパスできていたと思う。いちから自己応募をせずにダイレクトリクルーティングを最大限に活用した。
■■ヘッドハンター(エグゼクティブサーチ)
今回は転職エージェントは使わないと、固く心に誓ったのだが、Wantedlyに以前から登録してたり、会社ブログを書いてたりしてたせいか何社からメールが来たり、会社の電話に連絡が来たりした。
正直なところ、数千万プレイヤーでもない限りこの手のサービスを使う意味はないと思っているのだが(実態は単なるプッシュ型エージェントだし)、興味本位で数社ほど会うことにした。結果1社だけいい感じのカジュアル面談をセッティングしてきたので、それだけ会うことにした。
■使わなかったサービス
■■人材紹介(転職エージェント)
上記の通りヘッドハンターは1社だけあったが、転職エージェントは使わなかった。以前の転職活動のときに、的はずれな会社を紹介され続けたのですっかり嫌になっている。採用側から見てもアレな人の紹介が多かったし。
ジョブホッパーで転職なれしているせいで、レジュメの添削も面接対策もスケジュール調整も年俸交渉も不要で、自分にかかる高額な採用費のほうがマイナスになるからである(Greenもそれなりに高いけどね)。
あれは一見すると採用側が負担するように見えて、実は最終的に求職者側にも見えない形で金銭的負担がかかる。交渉無しで全社希望額よりプラスでオファーをくれた。転職エージェントは基本的にポジショントークしかしないので、あまり頼らないほうがいい。ただ、大企業に行きたければ意味あるかもしれないが。
■■リファラル
実は転職活動を全くしていなかった頃に知人に誘われたのだが、今回あえて連絡を取らなかった。
リファラルはM社(田町)やM社(六本木)のようなエリートベンチャーが、ハイスペックエンジニアを採るのにはいいかもしれないが、自分の場合その知人の会社に会いに行く→不採用or辞退なんてなったら気まずいので行かなかった。
■■SNS
ちょうど自分が活動を始めたとき、某有名フロントエンドエンジニアがTwitterで仕事くれと言ったら大量のDMが届いたそうである。ハイスペックエンジニアならこの方法も有効だが、業務以外に大きな実績もないエンジニアには無関係な話である。
■■他の転職サイト
以前は使ったのだが、例えば@typeやDODAなどは全く関係のない職種のメール爆撃がひどかったし(東建コーポレーションと夢真ホールディングス、あと外食やドライバーとか)、ビズリーチは圏外。FindJobはGreenやWantedlyに比べて求人の質が下がっている気がする。リクナビNEXTは行きたい会社がまったくない。Miidasは眼中になかった。
転職ドラフトは長い長いレジュメを書かされる→レビューでやり直し→オファーが来ても通常の採用フローに回される、というのを見て工数オーバーだと思って使わなかった。通常の採用フローがある時点でドラフトでも何でもないやん。
■■ハロワ
東京でWebエンジニアがハローワークで本気で仕事を探すことなんかあるんだろうか(嫌味でも何でもなくて素)？
東京以外で何回か利用したことあるが、求職者相談に関してはいっその事民営化して、悪名高いR社にでも委託したほうがマシな気がする。少なくとも金がかかっている分彼らのほうが真剣であるし、失業保険だけせしめるだけで就職する気のないような輩は追っ払ってくれるだろう。
■選考辞退したところ
以前の転職活動は自分から辞退することはほとんどなかったのだが(選べる立場じゃなかった)、今回は落ちることも少なく多忙を極めたため、何社か辞退することとなった。
■■スケジュール調整が遅い、連絡が遅いところ
ほとんどの会社がコンタクトから1営業日程度でアポイントを返してきていたのだが、何社かは信じられないほど遅い会社があった。
余裕のをとり広く日程を提示したにもかかわらず、返事に1週間もかけてよこしてきたり(当然他社のアポイントが入っている)、相手側都合で約束していた日程が合わなくなりリスケ依頼してきたり(当然他社のアポイントが入っている)。こういうところは人事が回っていないか、面談するエンジニアを用意できないかのいずれかで、入社してもいいことがなさそうなので辞退した。
■■土日や深夜に連絡が来る
自分の面談は自分の業務終了後希望しておいて勝手なのだが、流石に深夜未明とか日曜日にメールを寄越してくる会社は、労働環境に問題がありそうなので辞退した。休むときは休むべきである。
■■スキルミスマッチ
自分側の問題だが、ハイスペック系やフルスタック系を求めてくる会社もカジュアル面談の時点で辞退した。まず次の選考が通らないし、間違って採用されても多分自分が苦しむことになるから。そもそもなぜ自分にスカウトを出してきたのかが謎だったが。
■結果
辞退以外のお見送りが3〜5社ほどで、内定が2〜4社ほど。それ以外は選考中に辞退。上に上げたような理由がなくても、スケジュールが合わずに辞退した会社もある。
内定をくれた会社はいずれもレスポンスが早く、スケジュール調整もかなり早くしてくれた。辞退防止のためか人事もかなりフォローを入れてくれる。新卒はかなり辞退率が高いそうだが、中途採用も高くなっているのであろう。最終的に辞退する会社には申し訳ないが、丁寧にお詫びするつもりである。
年収も30〜70万円ほど上がった。現職と同じから+50ぐらいで希望していたが、思いの外高く評価いただいている。あとフレックス制や副業OKやストックオプションなど、福利厚生や労働条件も今どき風になった。しばらくは転職したくない(2回目)。
■追記
なんかトラバでフリーランスがどうのとかって言ってるけど、自分がフリーランスになってもせいぜい800〜900万前後の年商(年収ではない)をうろうろすることになり、社畜で500〜700前後でうろうろしたほうが楽だと思ったので社畜を続けることにした。技術ゴリゴリの人とか金金金の人ならいいんだろうけどねw
あと年収1億のやつが転職サイト使うわけ無いだろ、少しは考えろw