AI時代、チームの基準は「下」ではなく「上」に置け
はい、どうもこんにちは佐藤です！
このブログを読んでくれている方には、痛いほどわかる話だと思います。
先日、AI を使えば開発フローすら変えられるぞという話をしてきました。
結果は……。
あまり刺さらず、でした。
うーん、悔しい！ でも、刺さらなかった理由もなんとなくわかるのです。チーム開発には「チームが対応できるレベルに作りを下げる」という、長年の暗黙のルールがありますからね。
ただ、そのルールはもう通用しなくなると思っています。AI 時代には、下に合わせる理由がなくなるからです。
その理由を書いていきますね！
テストが書きやすいアーキテクチャを提案したが、刺さらなかった
何を提案したのか、から始めましょう。
エンジニアのみんなに向けて、テストコードが書きやすいアーキテクチャを提案しました。AI にコードを書かせるなら、テストで動作を確かめられる作りにしておくほうが圧倒的に楽です。AI が書いて、テストが通れば信頼する。人間が 1 行ずつ読まなくて済むわけですよね。
でも、共感は得られませんでした。
提案の中身が悪かったのでしょうか？ 私はそうは思っていません。刺さらなかったのは、提案が「今のチームのレベル」より上にあったからです。
チーム開発では、作りをチームに合わせて下げるのが当たり前でした。その当たり前の中にいると、上に引き上げる提案はどうしても「現実的じゃない」に見えてしまうのです。
チーム開発では、作りをチームのレベルに下げてきた
チーム開発をするときは、チームが対応できるレベルにシステムの作りを下げる必要があります。
ここに書くのは、全部私の実体験です。
- テストコードを無くす。メンテできなくなる可能性があるから
- ストアドアーキテクチャにする。チームの戦力がそこにあるから
- 既存のアプリからのコピペ実装にする。新人の学習工数を減らすため
- 設計書からコードを作る、ワンクッション入れた作りにする。誰が書いても同じものになるように
どれも、SI の現場にいた方なら見覚えがあるのではないでしょうか？
テストコードの件は、以前 AI で伸びるのは、もともと強いチームだけだ でも書きました。回せない仕組みは、無いよりも悪い。当時はそう判断して、あえてテストを外したのです。
こうする理由は明確だった
なぜ作りを下げるのか。理由ははっきりしています。
保守フェーズで負債が発生するとしても、開発フェーズでの実装スピードを重視するからです。
チームの半分が理解できないアーキテクチャを採用したら、どうなるでしょう。理解できる人に仕事が集中し、それ以外の人は手が止まります。納期に間に合わない。だったら全員が書ける作りにして、全員で手を動かしたほうが早いですよね。
負債は後で返す。まずはリリースまで辿り着く。
このトレードオフは合理的でした。少なくとも、これまでは。
エンジニアだけでなく、SI の現場にも変化を嫌う人は必ずいる
これはエンジニアだけの話ではありません。
SI の現場でも、変化を嫌うステークホルダーは必ずいます。
要件定義で新しい業務の流れを提案しても、最終的には今までの運用になることが絶対だったりしますよね。システムを入れ替えるのに、業務は一切変えない。画面の並びも、帳票の形も、手順もそのまま。
「それ、新しくする意味あります？」と言いたくなった経験、ありませんか？
私はあります。何度もあります。
ただ、ここでもトレードオフは合理的でした。運用を変えれば、現場の教育コストがかかる。問い合わせが増える。移行のリスクも上がる。だから「今までどおり」に寄せる。下に合わせるという判断は、エンジニアの世界でも業務の世界でも、同じ理屈で正当化されてきたのです。
AI 時代には、下に合わせる理由がなくなる
さて、ここからが本題です。
このようなトレードオフは、今後発生しにくくなると思っています。
なぜでしょうか？
下に合わせることのメリットが、なくなるからです。
下に合わせてきた理由を、もう一度見てみましょう。
- 理解できない人がいると、手が止まる
- 新人が慣れるまで、時間がかかる
- 全員で手を動かさないと、納期に間に合わない
これ、全部「人間が手を動かしてコードを書く」前提の話なのです。
AI がコードを書く時代に、その前提は崩れます。テストが書きやすいアーキテクチャは、理解できる人が方針を決めれば、実装は AI が追いかけてくれる。新人が既存コードをコピペして覚える必要もありません。設計書をワンクッション挟まなくても、AI が意図をコードに落としてくれますよね。
つまり、その程度のことができない人は、AI で代替すれば良いのです。
厳しい言い方に聞こえるかもしれません。でも、現実はもうそちらに動いています。
変化を嫌うことが、迫害される側に回る
ここで立場が逆転します。
これまでは、上に引き上げようとする人が「現実的じゃない」と言われる側でした。これからは違います。変化を嫌う人のほうが、できるエンジニアや経営者から迫害される可能性があるのです。
経営者の目線で考えてみてください。AI を使えば、少ない人数で、テストの効いた作りを、速く作れる。それなのに「チームが対応できないから」と作りを下げ続けるチームがあったら、どう見えるでしょうか？
下に合わせるコストだけが残って、メリットが消えている状態ですよね。
チームの基準を上に置き直し、全員のレベルを上げる
じゃあ、どうするのか。
チームの基準を、上に置き直すしかありません。
下に合わせて作りを落とすのではなく、上の作りを基準にして、全員がそこに届くようにする。テストが書きやすいアーキテクチャを採用して、書けない部分は AI に助けてもらいながら、全員のレベルを上げていくのです。
ここで大事なのは、これが他人事ではないということ。
私自身も、テストを外した側の人間です。コピペ実装を選んだこともありますし、設計書をワンクッション挟む作りにしたこともあります。その判断は当時は正しかった。でも、今も同じ判断をしていたら、それは「変化を嫌っている」のと変わりません。
変化を嫌うようなことを、自分も含めてしてはいけないのだろうなと思うのです。
まとめ
というわけで、AI 時代にチームの基準は下に置いちゃだめだよ！って話でした！
あ。正確には、下に合わせる理由がもうないって感じですねっ。
チームのレベルに作りを下げるのは、人間が手を動かす前提での合理的な判断でした。その前提が AI で崩れた今、下に合わせることはメリットのないコストになります。変化を嫌う姿勢そのものが、チームにとっても自分にとっても一番のリスクなのです。
提案が刺さらなかったのは悔しいですが、諦めるつもりはありません。ぜひみなさんも、チームの基準を上に置き直して、全員で一段上に行ってみてください！