Sota Iguchi

Claude Code 周りでよく出てくるのは Boris 氏だけど、その上司の方が出ているエピソードで、良い話が大量にあった。 以下は、順番を変えての自分用メモ。内容が良かったので分量多め。 ・マネージャーが見るべきなのは、メンバーがどれだけコードを書いたかではない ・その仕事が顧客や事業にどのような成果をもたらしたかどうか ・コード行数、PR数、トークン使用量などは活動量を示すだけ（意味がない） ・ClaudeにSlack、リポジトリ、指標、顧客からのFBや意見を確認させる ・そうすれば、マネージャーは大量の情報を横断してチームの状況を把握できる ・AIによる要約は報告書の代わりにするだけでなく、メンバーとの対話を始める材料として使う ・マネージャー自身も一定期間はICとして働き、チームのコードベース、ツール、プロダクト、リリース手順を直接経験することが望ましい ・新任マネージャーが最初からマネジメントだけを始めると、現場を理解しないまま、以前の会社で覚えた手法を持ち込む危険がある ・マネジメント責任を持つ前にICとして働けば、チームメンバーとの信頼関係を築きやすくなり、現実に即した判断もできるようになる ・また、マネージャーがPRを作る目的はプロダクトや開発環境の手触りを失わないことにある ・自分でプロダクトを使えるマネージャーは、資料や指標だけでは見えない不便、品質低下、顧客体験の問題に気づきやすい ・自分ではプロダクトを使いにくい場合もある ・その場合は、顧客への訪問や利用状況を観察させてもらい、現場との距離を意識的に縮める必要がある ・AIによって一人で多くの仕事を進められるほど、チーム内の会話が減って孤独になりやすい ・なので、共同作業の機会を意図的に設計すると良い ・ペアプログラミングやハッカソンは、親睦のためだけでなく、メンバーごとに異なるAIの使い方を共有する学習機会になる ・計画の立て方も6か月のロードマップではあっさり陳腐化する ・だから、1か月単位の軽量なJITプランニングにして、役に立たなくなったプロセスは積極的に捨てる ・月単位で軽く計画し、毎週優先順位を確認する ・長期的な方向性は示しつつ、具体的な実行内容は短い周期で更新すれば、チームは一貫性と柔軟性を両立できる ・Anthropicの社員は2025年と比べて四半期あたり約8倍のコードを生み出している ・その結果、仕事の重心は書くことから検証すること、つまり、生成された大量のコードが本当に正しく動き、品質が高いかを確かめることへ移った ・モバイルの専門家でないエンジニアがClaudeを相棒にしてモバイル開発をこなすように、自分の専門外の領域にも踏み出せるようになった ・コードを書く人がエンジニアだけでなくなった ・デザイナーもPdMも全員がコードをコミットする、誰もがビルダーの時代 ・職種の境界が溶けてきている ・エンジニアはよりプロダクト志向に。PdMやデザイナーはより技術的に ・採用で求められるのは二種類 ・プロダクトに情熱を注ぎ端から端まで磨き上げる創造的なビルダーと、深いシステムの専門家 ・モデルは優秀だが完璧ではないので「信頼せよ、しかし検証せよ」という原則が貫かれる ・ここで、専門家による検証が必要な領域へ投資する ・この時代にうまく適応できる人と、恐れて抵抗する人の間にギャップが広がりつつある → これは社会全体の分断にもつながりかねない深刻な問題 ・適応の鍵は成長マインドセット youtube.com/watch?v=Ybrl4FYM…