麻倉光舟

コードを書くAIが、だんだん賢くなっている。 それなのに、長い仕事を任せると、なぜか途中で迷子になる。 テストに落ちているのに「直りました」と終わったり、同じ場所を何度も直したりする。 問題は、コードを書く力だけではないのかもしれない。 AlibabaのDreamXチームとUNSWの研究者は昨日、arXivで「LoopArena」（2608.28281）を公開した。これは、言語モデルが長時間動くCoding Agentの「司令塔」として、どれだけうまく振る舞えるかを見るベンチマークだ。 いまのClaude ...

会社を始める人というのは、ずいぶん変化に強い人に見えます。 安定した仕事を離れて、まだ存在していないものをつくる。 「普通はこうするでしょう」という道から、わざわざ外れていく。 ところが、おもしろいことに。 そんな人が半年、一年と会社をやっていると、今度は変化を嫌がることがあります。 商品を変えたくない。 市場を変えたくない。 ビジネスモデルを捨てたくない。 最初のアイデアが間違っていた、と言いたくない。 変化して会社をつくった人が、会社の中では保守的になる。 ちょっとした逆転現象です。 「つくったもの」 ...

最近、ひとつ考えていることがあります。 「良いコンテンツって、なんだろう？」 読みやすい文章でしょうか。 役に立つ情報が書いてあることでしょうか。 たくさん読まれて、反応が集まることでしょうか。 どれも間違いではないと思います。 でも、AIを使えば、その多くは以前より簡単に作れるようになりました。 文章を整える。情報をまとめる。アイデアを出す。コードを書く。 それどころか、自分がそれほど詳しくないことでも、かなり立派な形にできます。 そこで、少しわからなくなりました。 見た目がよくできていることと、良いコ ...

コードレビューという言葉には、少しこわい響きがあります。 書いたものを見られる。 まちがいを指摘される。 場合によっては、最初からやり直しになる。 レビューを受ける側だけでなく、する側にも、ちょっとした重さがあります。 けれど、本来のコードレビューは、答案に赤ペンを入れるような仕事ではありません。 まだ事故になっていない小さな違和感を、みんなで見つける時間です。 そして、ひとりの頭のなかにあったものを、チームの知識に変えていく時間でもあります。 大きな荷物は、開けるのもたいへんです 変更されたコードが50 ...

目標を立てても、気づけば日々の仕事に流され、期末に目標を書き始める事は多くのチームで見られる光景です。 チームで同じ方向を向いているつもりでも、実際には優先順位が少しずつズレていきます。 コレは当たり前で、個々人は秘めた方向感を持っています。 こんな状態に心当たりがある人にとって、「Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR」はかなり実用的な一冊です。 本書はOKR、つまり「Objectives and Key Results」をどう導入し、どう ...

コードレビューの停滞は、実装の速さよりPRの渡し方で起きることがあります。変更が大きすぎて意図を追い切れないなら、200〜400行や5〜10ファイルを目安に分割を考える余地があります。逆に、小さく分けても単独で動かず全体像が見えないなら、機能単位でまとめ直したほうが判断しやすくなります。レビュー待ちを減らしたいのか、手戻りを減らしたいのかで、見直す基準は変わります。

入社直後の混乱が多い職場なら、まず確認する対象は参加者ではなく受け入れ設計です。初日から質問が連発する状態なら情報整理と手順更新が優先です。学習ばかりで実務に入れないと感じる職場なら、最初の成果物を先に置く流れ。何を終えれば前進なのか曖昧な職場なら、初日・初週・初月の到達基準を分けて示す必要があります。

障害の発見が遅く、復旧に人手がかかる状態なら、リファクタリングより可観測性とロールバック整備が先です。操作回数の多さや待ち時間の長さで継続利用が弱いなら、体験改善を優先する判断になります。変更のたびに不具合が増え、開発速度まで落ちているなら、コード品質の立て直しが先行します。

Claude Codeのソース51万2千行が三重ミスで流出しました。npm公開、ソースマップ、クラウドバケットの扱いに少しでも不安があるなら、手順を見直す判断材料になります。すでに公開フローを厳密に管理できているなら過度に恐れる必要はありませんが、どれか一つでも曖昧なら点検を選ぶのが妥当です。

障害対応が常態化し、特定の人に業務が集中しているなら、まずは属人化の解消から着手すべきです。部門対立や承認待ちがボトルネックなら、共通指標の再設計が優先です。単なるツール導入で解決すると感じているなら立ち止まり、組織構造に原因があると感じているなら、本書の考え方は具体的な判断材料になります。