株式会社FLINTERSの髙木です。現在は、プロダクトグロース本部に所属していまして、広告データ提供サービスのPMをやっています。

今回は、社内でClaude Codeの活用が活発になったことで感じたことをまとめてみました。

1. 便利になったはずなのに、なぜか忙しい

Claude Codeを本格的に業務に取り入れて数ヶ月が経った。導入前に思い描いていたのは単純な話で、「AIに任せられる作業を任せれば、その分自分の時間が空く」というものだった。

実際に触ってみると、たしかに時短できた場面はあった。ただ、それと同じくらいの熱量で「仕事が増えた」場面もあった。しかもこの二つは、思っていたよりくっきりと線引きできることに、しばらくしてから気づいた。

2. 「時短できた場所」と「仕事が増えた場所」

時短できたのは、チケット作成、障害関連の情報収集、Slack投稿の読み込みや要約といった、もともと正解がはっきりしていて、人間がやっても機械的な作業だった。多少の間違いがあってもすぐ気づけるし、被害も小さい。ここは実装した分だけ、素直にそのまま時短効果が返ってきた。

一方で、顧客に提出する文章や障害報告のように、業務の精度が求められる箇所は事情が違った。実装自体は思ったより簡単にできる。しかし「その出力を信用していいのか」を確かめる仕組みが必要になり、誤りが起きないためのガードレールを先回りで整備する必要が出てくる。一度作ったルールは増殖していき、新しいルールが既存のルールと矛盾していないかを確認する作業自体が発生するようになった。

つまり「実装は簡単、運用を安全にするのが大変」というギャップが、この領域にはあった。時短と整備コストは、タスクの性質によってきれいに分かれていたのだ。

3. 運用に乗せる段階で見えてくる"手探りコスト"

厄介だったのは、実装がうまくいっても、それを実際の業務フローに組み込む段階で改めて「どう運用するか」を手探りで確認する作業が発生することだった。

しかもこの確認作業のための時間は、最初から誰かが用意してくれるわけではない。「AI活用に使っていい時間」を新たに確保してくれるわけではなく、自分の中であくまでも優先度踏まえ取り組む必要がある。

なので実際にやったことは単純で、「手探りに時間がかかりそうな、移行コストの高いもの」を見極めて、その分だけ現状の業務を削る、という判断だった。削った分だけ短縮効果が生まれ、一見すると得をしたように見える。

正直、この手探りと移行のフェーズは今もまだ途中にある。ただ、この移行を終えたときに業務がどういう状態になっているのか、どれくらい変わるのかは、苦労している今だからこそ純粋に楽しみでもある。

4. でも短縮した分は"休み"にはならなかった

ところが、削減できた時間はそのままリソースの空きにはならなかった。その空いた時間で、別の作業を増やす方向に自然と回っていった。結果として、並行して進める作業の数自体が増えていった。

AIを使えていること自体は事実だ。ただ、「今どの作業をAIに任せていて、どこは自分で見なければいけないか」を常に把握しておく認知コストは、明らかに上がった。時短というのは「時間が浮く」ことだと思っていたが、実際には「浮いた時間にさらに仕事を積める」という構造だった。これに気づいたのは、だいぶ後になってからだ。

5. それでも投資として意味はあった

ここまで書くと苦労話ばかりになるが、整備にかけたコストが無意味だったわけではない。属人化していた作業が仕組みに乗り、再発防止が個人の記憶ではなく手順として残るようになった効果は、実際にあった。

「振り回された」という実感と、「投資として無駄ではなかった」という評価は、両立する。

6. それでも、個人の域に留まっていてはいけない

ただ、ここで満足するわけにはいかない。

認知コストを払って時短を成立させているのは、今のところ自分個人でしかない。その負荷や工夫、判断基準がチームや組織に共有されていない状態では、個人の中で帳尻を合わせているだけで終わってしまう。それでは、チームやビジネス全体の生産性向上にはつながらない。

本当に問われるべきは、「自分が楽になったか、忙しくなったか」ではなく、この時短と整備コストが最終的にビジネスのアウトプット——対顧客の質やスピード、チーム全体の工数——にどう跳ね返ったか、のはずだ。

今後の課題は二つある。一つは、浮いた時間を仕事で埋め続けないという、個人としての持続可能性の意識。もう一つは、この経験を個人の中で完結させず、仕組みやルール、判断基準として言語化し、チームや組織のインパクトへと変換していくことだ。自分が倒れたら止まってしまうようでは、投資としてはまだ不十分だと思う。