コドモン Product Team Blog

株式会社コドモンの開発チームで運営しているブログです。エンジニアやPdMメンバーが、プロダクトや技術やチームについて発信します!

コードより行動、ちょうど良い協働

こちらは「コドモン Advent Calendar 2025🎄」の25日目、つまり最終日の記事になります。

こんにちは、昭和61年生まれ、エンジニアリングマネージャーの松浦です。

今年は昭和100年のアニバーサリーイヤーです。記念すべきこの年のアドカレの最後を担当できることになり、大変誇らしい気持ちです。

さて、アドカレが終わりということは、西暦2025年もあと少しで終わりということですね。

昭和101年となる西暦2026年は、娘が小学生になります。入学おめでとう。

小学校入学、イベントとしての「おめでたさ」はあるものの、親の率直な気持ちとしては

「嬉しいけど、嬉しいだけじゃない」

です。

日を追うごとに出来ることが増えてきて、成長を感じるものの、どことなく寂しい。

今年、仕事でも似たような気持ちになることがありました。

「便利になったはずなのに、物足りない。」

そんな最近の考えごとを、ちょっと書いてみたいと思います。

2024年まで、それは「楽しみ」だった

私のファーストキャリアは、SIerでした。2009年にキャリアが始まり、10年弱、受託システムの仕事、つまりSIをしていました。当時はJavaを使っていました。

「クラウド」という言葉がまだ一般化する前の時代です。開発用のサーバーも本番環境も、オンプレ環境のLinuxにsshして作業するのが当たり前でした。何らかのエラーが出れば、自分で調べ、自分でなんとかするしかない。AIはもちろん、Stack Overflowすら今ほど充実していなかった頃の話です。

コマンドラインのターミナルで、UIのない黒い画面に向かって華麗にコマンドを打つ先輩の姿に憧れました。自分もああなりたいと思いながら、viの操作を覚え、少しずつできることを増やしていきました。viを使えるようになったあとは、いつの間にかEmacsに惹き込まれ、長く使うようになりました。

日々の学びの中で、Dependency Injection(DI)を知りました。依存関係を外から注入できるようになると、テストが書きやすくなりました。テストが書きやすくなると、それを継続的に実行したくなります。そのためにContinuous Integration(CI)を整備し、継続的に品質をチェックできるようにしました。そしてソフトウェアが安定して動くようになると、今度はそこで蓄積されたデータを分析し、事業に活かすBusiness Intelligence(BI)の重要性が見えて来るようになりました。

DI → CI → BI。この流れの中で、私は「開発者としての成長」を実感してきました。コードを書くことが楽しかった。エラーを解決できたときの達成感、設計がうまくハマったときの快感、動くものができあがったときの喜び。それは、私の「趣味」にも近く、「楽しみ」の一つでした。

2024年まで、ずっとそうでした。難しいこともあったけど、だからこそ自分で解いたときの手応えがありました。そう、楽しかった。

2025年、ゲームが変わった

DI → CI → BIと来ると、次はAIですね。(これが言いたかった)

「コードをAIに生成させる」ということは、開発者として大きな転換点だったと思います。仕事でも、プライベートでも、AIを活用することで作れるものの幅は広がり、かかる時間は縮まりました。

使っているエディタもEmacsからClaude Code MAXになりました。

便利になった。生産性も上がった。それは間違いないと思います。

けれど、どこかで虚しさを感じる自分もいました。

その虚しさの正体は何なのか?あらためて考えていました。AIに質問すると、「いい質問ですね!」とか「いい観点ですね!」とか「すばらしい!」とか、表面的な回答をするからでしょうか?

部分的にはそうかもしれないと思いつつ、本質はこういうことだったのかもしれません。以前は、エラーと格闘し、試行錯誤し、やっと動いたときに「自分で解いた」という感覚がありました。

会社で遭遇したエラーや不具合が、帰り道でも頭から離れない。電車の中でスマホを開き、似たような事例がないか調べる。「もしかして、これが原因かも?」という仮説が浮かぶ。家に着いてからも気になって、頭の中でコードを追いかける。翌朝、出社してすぐに試してみる。ダメだった。また別の仮説を立てる。そして何度目かの挑戦で、やっと動く。そのときの「解けた」という感覚。

それが今は、AIに指示を出し、生成されたコードを確認し、それで終わりということも多くなりました。問題は解決しているのに、「解いた」という手応えが薄い。会社と自宅を往復する間も気になって仕方がないという、あの感覚がない。

以前は、もっと謎解き要素があったように思います。悩んで、調べて、試して、という失敗を繰り返しました。難しかったけれど、だからこそ意欲を掻き立てられる部分もありました。

AIの発展により、すぐに解ける問題は明らかに増えました。「うぅー、苦しいけど頑張って挑戦してみよう」ということは減り、相対的に「AIに聞けば良いだけのこと」が増えました。ワクワク感は薄れ、「あとはやるだけ」化しました。それ自体は悪いことではないはずなのに、どこか物足りない。

趣味として楽しんでいたはずのコードを書く行為が、いつの間にか「いかにAIに正しく指示を出すか」というタスク管理に変わっていました。根本からゲームが変わってしまった。

AIの楽しさ、頼もしさ、その逆も然り

意外なことに、仕事においては新しい楽しさも生まれました。

仕事では「コードを書くこと」は目的ではなく手段と言ったほうが良いでしょう。チームで議論し、設計を練り上げていく過程で、書くべきコードが明確になることがあります。そういう場面では、AIがすぐにコードを生成してくれるのは素直にありがたいですし、楽しい時間となります。 そして、気持ちや時間のゆとりが生まれ、いままでよりもユーザーの価値に向き合いやすくなった気もします。

とはいえ、残念ながら、楽しくない時間もあります。

CLAUDE.mdに書いておいたルールを、AIが無視して進んでしまうことがある。「このディレクトリ構成で」「この命名規則で」と決めておいたはずなのに、気づくと勝手に別の設計に変わっている。指示していないリファクタリングが始まっていることもある。こちらが意図した方向と違うところに、どんどん進んでいってしまう。

長い作業の途中で「Compacting conversation」が走り、それまでの文脈が圧縮されてしまうこともある。レートリミットに引っかかって、作業が中断されることもある。こういう待ち時間が不定期で訪れるのは、なんだか気分がよくありません。じゃ、自分で書いたらどうか?と思わなくもありませんが、結果的にAIでやったほうが速いんだろうなという劣等感を感じることもあります。

このプロセスは「AIと人間のペアプロ」とも言えそうですが、私にとってはどこかしっくり来ない部分もありました。相談相手がいない感じがしますし、なんとなく集中力も維持しにくいという実感でした。

AIは「行動」を生成できるのか?

結局、機能ができて、チームメイトに共有し、そこで得られるフィードバックのほうがずっと嬉しいのです。

「これいいですね」「これって、どうやってやったんですか?」というシンプルな言葉。それだけで、やってよかったと思える。

もちろん、ユーザーから得られるフィードバックのほうが大事ではありますが、まずはチームからの小さなフィードバックだけでも、刺激になるものです。

AIに期待通りに動いてもらえなくて困っているとき、「まあ、切り替えてやってみましょうか」と言ってくれるチームメイトがいる。その一言で、また前に進める。

「これどうしようかね?」とチームで悩んでいるとき、「わたし、とりあえず◯◯の方法でやってみますよ!」と手を挙げてくれる人がいる。その姿勢、その行動に、こちらも背中を押される。

「コード」はAIが生成できる時代になりました。でも、こういう周りを刺激するような「行動」はAIには生成できないものの一つなのではないでしょうか。

そして皮肉なことに、私自身も「行動」できないことが多い。だからこそ、先日読んだチームメイトの記事が刺さりました。

やりゃ良いだけのことがやれない、私たち

チームメイトの郡司さんが書いた「やりゃ良いだけのことがやれない私へ」という記事です。

内容について、強く共感しました。私も同じように「やりゃ良いだけのことをなかなかできない」ということは日常で多くあります。それこそ、「ただAIに指示を出せば良いだけなのに」、そう思いながら手が動かないこともあります。

この記事を読んで、やる気というか、勇気というか、「私もやらねば」という気持ちが湧いてきました。

私は郡司さんと同じチームで働いています。だから、記事には書かれていない普段の振る舞いも知っています。PHPカンファレンスに登壇するまでの準備、社内LTでの発表、日々の仕事での姿勢。言葉の裏側にある、実際の行動を見てきました。

その行動を知っているからこそ、記事の言葉が響くのかもしれません。

なぜだろうと考えました。AIに褒められても、AIに励まされても、こういう気持ちにはならない。でも、一緒に働く人間の行動や言葉には、心が動く。

きっかけを作ること。背中を押すこと、押されること。刺激を与え合うこと。こういう雰囲気は、誰かの行動から生まれるものなのではないかと思います。郡司さんだけでなく、チームのみなさんがそういう雰囲気を作ってくれていることに、私はすごく感謝していますし、このような雰囲気作りを続けているみなさんの姿勢だったり、仕事への向き合い方を尊敬しています。

コードよりも行動

DI → CI → BI → AI。

技術の進化を追いかけてきた先に、私がいま重要だと感じているのは、結局のところ人間同士の敬意なのかもしれない。漠然とこんなことを考えています。チームとして一緒に酸いも甘いも経験し、成長してきたからこそ、その実感が伴います。一緒に悩んだこと、乗り越えたこと、失敗したこと。そういう共有された時間のストックがあります。ここにはAIの薄っぺらい「いいですね」「いい観点ですね!」を遥かに超える「重み」があります。

コードよりも行動。AIだけでなく、一緒に働く者同士の敬愛(KI)も大事なのではないでしょうか。「行動を起こす」という気持ちの源泉は、意外とこういうものなのかもしれません。周りの人々との、ちょうど良い協働。そして、そこから生まれる刺激。

そんなことを思いながら、レビュー締切後にこのブログを書いています。決して高度なタスクではないはずなのに、締切を守れないのはナゼなのでしょう。やりゃ良いだけなのに。

最後になりますが、チームのみなさんへ

2025年、困難に負けず、コツコツと経験を積み重ねるストイックな姿勢、すごくステキでした。

2026年もたくさんの経験をストックしていきましょう。

おしまい

ここまでお読みいただき、ありがとうございました。

(蛇足ながら、「ストック」という花の花言葉は「求愛(QI)」らしいです。)