「EMはコードを書くべきか」は、たぶん問いが違う

「EMはコードを書くべきか？」。EMをやっていると定期的にぶつかるこの問い、自分はたぶん、問いの立て方の方がズレていると思っています。

自分はマネージャーをやってきたなかで、コードを書く時期と、ほとんど書かない時期を何度か行き来してきました。書いているときと書いていないときの行き来で、自分に"見えているもの"が変わることを、ちょくちょく感じてきました。今回はそこでの気づきをアウトプットしてみます。

先に言ってしまうと、「書くか書かないか」を軸にしている限り、一番見たいものは見えない気がしています。

コードベースは、組織の開発プロセスの成績表だ

スタートアップでCTOをやっていた頃から今まで、何度も同じ光景を見てきました。事業のスピードに対して、技術負債の返済が追いつかない。症状を挙げると、たとえばこんな感じです。

• 機能ごとに、設計のアーキテクチャがバラバラになっている

• 誰かが入れた負債が、合意を取る前にリリースされていて、後から「あ、これ負債だったな」と気づく

• レビューしても設計意図に踏み込めず、「既存踏襲です」で押し切られて、負債がまた一つ増える

「コードが汚い」「レビューが甘い」の話として処理していたこともあります。個人の力量の問題にしていた時期もあります。

ただ、チームで改善の対話をしていると、こうした症状の話が、いつのまにか開発プロセスの改善の話にすり替わっていることがしばしばあります。人が入れ替わっても、チームが変わっても、同じ症状が繰り返し出てくる。だとすると、原因はコードの手前にあります。

つまり、 組織のヘルスは、最終成果物であるコードに表れる ということかと思います。コードベースは技術の成果物であると同時に、組織のヘルスを映すモニタでもある。個人的には、そう捉えるようになってから、コードの見え方がかなり変わりました。

アーキテクチャの乱れは、設計の問題ではなく、前段の開発プロセスの問題だ

さっき挙げた3つの症状、実は一本の線でつながっています。

まず「機能ごとに設計アーキテクチャが異なる」。
ここで一番まずいのは、「設計のセンスがない」で終わらせることです。たいていは前段のプロセスに穴があります。チーム横断で設計方針を揃える場が無かったり、ADRが機能せず、毎回その場で局所最適に決まっていったり。方針を揃える仕組みが無ければ、機能ごとに違う設計が生まれやすい状態になっています。

次に「合意を取る前に負債がリリースされて、後から気づく」。
これは前職で、複数のチームがリリース優先で高速に開発していたときの話です（社名や時期は伏せます）。各チームが並行で、とにかく速くリリースしていく。一つ一つは動くし、レビューも通る。でも「これは負債を受け入れる判断です」という合意を、チームをまたいで取る間もなく、マージされ、リリースされていく。しばらくして別の作業でそこを触ったときに、「あれ、これ負債じゃん」と後から気づく。誰かが意識的に選んだわけじゃない負債が、暗黙的に積まれていくような感覚でした。

つまり、 走る速度に、合意の仕組みが追いつかなくなる という状態です。速く走れること自体は強いのですが、そのぶん、合意を飛ばして負債が入るスピードも上がる。

最後に「レビューで設計意図にコメントできず、既存踏襲ですで負債が増える」。
これがいちばん厄介かもしれません。レビューアーが設計に踏み込みたくても、周りの既存コードがすでにバラバラなので、「既存に合わせました」と言われると強く止められない。しかも、レビューでアーキテクチャの指摘を入れると大量の手戻りになるので、負債を受け入れざるを得ないことが多い。既存踏襲するほど、バラバラな設計が"正しく"複製されて広がっていく。負債が自分でコピーを増やしていくような状態です。

こうして並べると、この3つが噛み合ったときに、負債が勝手に増えていくのが見えてきます。

ここで言いたいのは、 コードの乱れは症状であって、原因ではないことがある ということです。症状をコードで潰しにいっても対症療法にしかならない。見るべきは、その手前のプロセスの側だと思っています。

EMが見るべきなのは、コードそのものより「コードベースのヘルス」

EMがコードベースから遠ざかって困るのは、「自分の技術が鈍ること」そのものというより、コードベースの症状を通して、組織の異常を検知できなくなることなんじゃないかな、と思っています。

だから自分がコードベースを見るときは、実装そのものより、こういう「ヘルスのサイン」が出ていないかを見ています。明日からでも見れる粒度で挙げると、こんな感じです。

• 機能ごとに、設計の流派が割れていないか

• 合意なく入った負債が、静かに生き残っていないか

• レビューで「既存踏襲です」が増えていないか

とくに最後の「既存踏襲です」が増えているなら、レビューアーの頑張り不足ではなく、そもそも踏襲すべき"正しい既存"が定義されていない、という仕組みの問題を疑います。個人の頑張りで埋めている時点で、どこかが壊れているので。

つまり、自分のなかで問いはこう置き換わりました。

「EMはコードを書くべきか？」ではなく、「EMはコードベースの状態を読めているか？」

書く/書かないは手段の話であって、本当に握っておきたいのは、コードベースを通して組織の同期が崩れていないかを読めているか、の方だと思っています。

AI時代、コードベースを「観測」するのはむしろやりやすくなった

規模が大きくなってくると、EMが一人でコードベースの隅々を目視で追うのは、正直きついです。とはいえ、ここでもClaude Codeのようなツールが効いてくる。実装者としてだけでなく、コードベースを観測するセンサーとして使える感覚です。

最初のうちは、「この機能とあの機能で設計方針がズレていないか」みたいな問いかけを、都度Claude Codeに投げて観測していました。ただ、都度手で問いかけるのは属人的だし、抜けも出ます。なので今は、そもそもアーキテクチャを先に定義しておいて、それに沿っているかを自動でレビューできる形に寄せています。ローカルではClaude Code Skillsを使ったhooksで、マージ前にはCIで引っかける。観測を、自分の思いつきの問いかけから、仕組みの側に移した、という感じです。

もちろん、どう直すかを決めるのは人間の仕事です。ただ、「どこがヘルスを崩していそうか」を見つける観測の手前は、かなり任せられます。

言い換えると、 AIは実装者としてだけでなく、コードベース観測の補助線にもなる ということかと思います。AI時代にEMが持つべき技術的な営みは、「自分でどれだけ書くか」より、AIも使ってコードベースのヘルスを読み、そこから問いを立てにいくことに寄っていく気がしています。

おわりに

自分の結論としては、握るべきなのは「書くか書かないか」ではなく、 EMがコードベースの状態を読めているか の方だと思っています。コードベースは技術の成果物であると同時に、組織の開発プロセスの成績表でもある。そこに出た乱れは、技術の問題である前に、開発プロセスやチーム連携の問題かもしれない。しかもこの負債は、コスト表には出てきません。数字に見えないぶん、いちばん検知が遅れる組織の負債だと思っています。

だからEMは、コードを書くかどうかに関わらず、コードベースの状態から遠ざからず、そこに出た異常を前段のプロセスまで遡って見にいく。それができているなら、書く/書かないはどっちでもいいんじゃないかな、と思っています。

AI時代に組織として速く走り続けられるかは、速さそのものより、崩れた同期をどれだけ早く読み取れるかで決まる気がしています。そして、その同期が一番正直に出てくる場所の一つが、コードベースなんじゃないかな、と思っています。