仕事してる感を演出する極意：真の生産性よりも「見せ方」が重要なとき

職場で実際に成果を出すことと、忙しく見せることは全く別物です。もしあなたが過度な残業や際限のないMTGに疲弊しつつも、周囲からの評価を守りたいと考えているなら、いくつか「仕事をしているように見せる」ための戦略が存在します。ただし、これはあくまで最終手段。燃え尽きる前に、賢く立ち回るためのTipsを共有します。

「相手が明らかにAIの出力をコピペして議論しているな」と気づいたとき、しばらく様子を見てから、自分も同じように返して遊んでるよ（相手のAI出力を自分のAIに投げ込み、その返答をコピペして返す）。お互いが人間であることを忘れて、人間らしくコミュニケーションするコスプレをした機械同士がやり取りしているようなものさ。

この記事を読んで、『巨大テック企業でのプロジェクトのリリース方法』という記事を思い出した。「リリースというのは社内的な社会的構成概念に過ぎない。つまり、社内の権力者たちが『リリースした』と信じれば、それはリリースされたことになるんだ」っていうやつだね。

ここでの話は、自分の経験とすごく重なる。うちの会社も、何年もコードを書いていないマネージャーばかり。18ヶ月前に入ってきたアーキテクトは、全部AIで設計してさ。シニアエンジニアから見れば一目瞭然で、過剰設計の極みだったんだけど、もっともらしい専門用語を並べるから、現場を知らない上層部にはすごく有能に見えちゃったんだ。指摘しても個人攻撃で返してくる始末だし。
6ヶ月後には何人もの有能なメンバーが辞めて、残った連中はAIにどっぷり浸かった。辞めた社員の穴埋めに必死で、この1年ずっとエージェント型のワークフロー構築に明け暮れているよ。
結果として、過去18ヶ月で価値のあるものは一つもリリースされていない。適当な設計のせいでクラウドの計算コストを浪費しまくった挙句、今度は採用凍結でコストカット中。踏んだり蹴ったりだよ。

素晴らしい記事だね。仕事の成果物が「肥大化」しているっていう指摘には、深く共感するよ。高校の小論文で1000文字の制限を満たすために、意味もなく言葉を継ぎ足していた自分を思い出した。プロっぽい書式や長さ、洗練された文章は、もはや仕事の丁寧さや質を示す指標にはならないね（まあ、昔からそうだったかもしれないけど、せめて12ページの仕様書があれば、それだけの時間をかける熱意があることは分かった）。
結局、今の「生産性向上のボトルネック」って、手動でレビューをするという手間を惜しまない人たちになっているんだね。

ソフトウェアエンジニアリングがこういう状況になりやすいのには、いくつか理由があると思うな。

・多くのエンジニアは、キャリアを通じて「本当のエンジニアリング」を経験していない。大企業ならなおさら。歯車として巨大なシステムに組み込まれるだけだからね。出世のために誰かが作った設定言語を覚えたり、設定ファイルの整理やリファクタリングで「製品」を学んだ気になったり。そうやって5年経っても同じことを繰り返しているんだ。

・この業界には「エンジニアに近いけど違う職種」が多すぎる。「人と働くのが好きだからコーディングはやめた」とか、「製品やユーザー体験には興味がある」とかね。彼らが大企業や中小企業の隙間を埋めているんだ。

・特に大企業は動きが鈍い。コミットから本番反映まで数ヶ月かかるなんてザラだし、半年が標準なんてことも。大規模でクリティカルなシステムには、エージェント型のコードなんていまだに本番投入されていないからね。

つまり、AIはくだらない仕事を自動化している一方で、エンジニアに近い位置にいながらコードを書かない層が、いきなり「気分だけでコーディング」して、崩壊する前に逃げ切る。外から見ると生産性が爆上がりしているように見えるのが皮肉だよ。

AI導入の初期に気づいたんだけど、同僚の中には、AIを駆使して「超・先回りしてる感」を出して評価を上げようとする連中がいた。週替わりで新しいTODOリストを作ったり、最新のアルゴリズムで古い問題を解決しようとしたりしてさ。今やそれが倍増しているよ。AIによるレイオフを恐れるあまり、問題が定義される前から、その解決策を勝手に作っているんだ。
例えば、全社的なアーキテクチャの課題を調査するように頼まれた時、ちゃんとした解を出して評価されたいと思ってたのに、気づいた時にはインターンが勝手に解法を見つけてTODOリストにぶち込んでたんだ。もうね、競争する気力も失せるよ。

生産性の高いチームがLLMを活用する場合、以下の用途に絞るのが最強だと思うよ。

・インテリジェントなオートコンプリート：自分の思考の延長としてコードを書く「王道」の使い方。思考をLLMに外注せず、コードのコンテキストを自分で保持する。

・ブレインストーミング：ぼんやりした概念を広げて、新しいアイデアのヒントにする。

・トラブルシューティング：パッケージの競合や例外などのデバッグ。隣に相談できる人がいない時に、ヒントをもらう。

・コードレビュー：人間が見落とす細かい点を見つける、少し賢いリントツールとして使う。

・PoC（概念実証）：解決策のバリエーションを生成して、より良い設計のヒントにする。

これなら開発スピードは上がるし、何を作ってなぜ作るのかという責任もエンジニアが持ち続けられる。逆に、エージェント型のコーディングに全面的に依存するチームは、長期的には製品もチームも破綻させるんじゃないかな。

ドキュメントを作るコストはほぼゼロになったけど、読む側のコストは逆に上がっている。結局、AIが生成した中身のない文章の中から、本来の目的を探し出さないといけないからね。「短く書く」という努力を放棄して、AIに長文を吐かせておけば評価される風潮があるせいで、どれが本質的な情報なのか見失われている。
最近仕事をしたクライアントでもそうだった。たった1パラグラフで済む話なのに、13ページの資料を送りつけてきた人がいてさ。その瞬間、その人への信頼がゼロになったよ。相手の時間や思考を尊重する姿勢が全く見えない人と仕事をするのは、本当に疲れる。

元の投稿者の指摘で面白いのは「LLMが上司へのおべっかまで自動化した」という点だね。それって実はすごく大きな市場があるのかも。
ただ、メインの主張については少し違和感がある。投稿者が言及する「データアーキテクチャの訓練を受けていない人間が作ったシステムがひどい」というのは、結局はLLMの問題ではなく、単なる『社内システムの失敗事例』そのものじゃないかな。設計や目的が間違っていたなら、それは誰がどう書こうが失敗する。LLMが悪いというより、コンテキストや要件定義なしに道具を使わせる今の企業の管理体制に問題があると思うよ。

Claude 4.7で複雑なC++コードが編集できるのには驚かされっぱなしだけど、記事で指摘されているような切実な問題も感じ始めている。自分が書いた変更じゃないから、コードの細部まで完全に理解できなくなってきているんだ。能力がないわけじゃなくて、自分で書いていないから。スループットを上げる代償に、理解力、そして最終的には自分自身の判断力を失いつつあるんじゃないかという怖さがある。