この記事は、特定の技術や考え方を否定したいものではありません。
新しい技術を使うべき、古い技術を守るべき、という話でもありません。
エンジニアの世界で語られる「正しさ」が、思ったより時代や現場の前提、個人の経験や好みに左右されるな...という、自分の考えの整理です。
技術の話は宗教論争っぽくなりやすいので、あくまで自分にはこう見えている、くらいの温度で読んでもらえればと思います。
はじめに：技術の正しさは、何度も形を変えて戻ってくる
自分は、この業界でかなり長く働いてきました。
その中で見ていると、技術の世界では、同じような議論が定期的に形を変えて戻ってくるなと思うことがあります。
新しい技術を使うべきか。
枯れた技術を選ぶべきか。
この設計は正しいのか。
この書き方は古いのか。
今の時代に合っているのか。
もちろん、その時々で出てくる技術は違います。
でも、議論の構造はけっこう似ている気がします。
「あれ、またこの話をしているな」と思うことがあります。
ただ、それを他人事のように眺めているとか、達観して見ているということではありません。
むしろ、世の中って面白いなと思って見ています。
技術が変わるたびに、人間が考える範囲も変わる。
そのたびに、何が正しいのかをみんなで考え直す。
そして、似たような論争がまた別の形で出てくる。
この繰り返し自体が、エンジニアリングの面白さでもあるのかなと思っています。
技術の話をしていると、わりとすぐ価値観の話になりやすいところがあります。
- 新しい技術を使うべき
- 枯れた技術の方がよい
- この設計は古い
- この書き方は美しくない
- このフレームワークは思想がよい
- このやり方は保守しにくい
どれも分かります。
自分も長くプログラムを書いてきたので、「この書き方はちょっと嫌だな」と思うことはあります。
技術へのこだわりもありますし、昔から積み上げてきた感覚もあります。
ただ最近思うのは、そういう「正しさ」は、単体の技術だけでは決まらないんじゃないかということです。
- その技術が使われる現場
- そのプロジェクトの期間
- チームの人数やスキル
- 保守する人
- 障害が起きたときに戻せるかどうか
- それを判断する人の経験や好み
- そして、今ならAIをどこまで使えるのか
そういう前提によって、正しさはかなり変わる気がしています。
なのでこの記事も、「この考え方が正しい」と言いたいものではありません。
長くこの業界を見てきて、最近また同じような問いが、AIというかなり大きな変化と一緒に戻ってきたように感じている、という話です。
プログラミングは、ずっと抽象化されてきた
プログラミングの歴史は、人間が直接考える範囲を少しずつ変えてきた歴史でもあると思っています。
アセンブラを書いていた時代には、人間がかなり低いレイヤーまで意識していました。
C言語が出て、少し上の抽象度で考えられるようになりました。
その後、ライブラリ、API、フレームワーク、クラウド、各種開発基盤が出てきました。
そのたびに、人間が直接やることは変わってきました。
昔は自分で細かく書いていたものが、言語やライブラリに吸収される。
毎回考えていた構造が、フレームワークの作法になる。
何度も失敗して学ばれてきた形が、デザインパターンとして名前を持つ。
こう考えると、技術の進化って、単に便利な道具が増えたというより、人間がどこまで考えるべきかを変えてきた歴史にも見えます。
フレームワークやパターンも、先人の知識の固まりだった
フレームワークやデザインパターンは、ただの流行ではないと思っています。
そこには、過去の失敗や工夫が入っています。
同じような問題を何度も解いてきた人たちの知識が、再利用しやすい形になっている。
だから、それ自体はすごく価値があります。
ただ、難しいのは、それが常に良い方向に働くとは限らないことです。
- ある現場では助けになる
- 別の現場では重くなる
- ある言語では自然に見える
- 別の言語では不自然に見える
- あるチームでは守れる
- 別のチームでは形だけになってしまう
このあたりが、技術の難しさだと思っています。
「これは良い設計です」と言われるものでも、それが今の現場に合っているかは別です。
「これは古いです」と言われるものでも、その現場では一番安全な選択かもしれません。
新しい技術が正しい、でもない
新しい技術を積極的に使うべき、という意見は分かります。
新しい技術には、新しい前提があります。
昔は大変だったことが、かなり簡単になることもあります。
古い制約を引きずらなくてよくなることもあります。
一方で、枯れた技術の方がよい、という意見も分かります。
- 運用実績がある
- 情報が多い
- 困ったときに調べやすい
- メンバーが理解している
- 採用や保守の見通しが立てやすい
たぶん、どちらも正しいです。
ただし、条件つきで。
- その現場で許されるのか
- そのメンバーで運用できるのか
- 保守する人が理解できるのか
- 障害時に戻せるのか
- プロジェクトの期間や予算に合っているのか
そこを抜きにして、技術単体で「新しいから良い」「古いから悪い」と言うのは、少し雑なのかなと思っています。
正しさには、流行だけでなく経験や好みも混ざる
ここまで「流行」という言葉を使ってきましたが、エンジニアの正しさを作っているのは、流行だけではないと思っています。
そこには、個人の経験もかなり入ります。
- 過去にうまくいったやり方
- 逆に、過去に痛い目を見た設計
- 長く触ってきた技術
- 自分が保守しやすいと感じた構造
- 障害対応で苦労した記憶
こういうものは、その人の判断基準になります。
さらに、そこには個人の好みも入ります。
- この書き方は読みやすい
- この構成はしっくりこない
- このフレームワークの思想は好き
- この命名はしっくりこない
- この分け方はなんとなく落ち着かない
こういう感覚も、技術者にとってはけっこう大事です。
ただ、難しいのは、本人の中では、流行、経験、好みがきれいに分かれていないことです。
「これは正しい」と言っているとき、その中には、
- その時代の流行
- 過去の経験
- 個人の好み
- 今いる現場の制約
が混ざっていることがあります。
それ自体は悪いことではありません。
むしろ、エンジニアの判断って、そういうものだと思います。
ただ、それを全部まとめて「正義」として出してしまうと、少し扱いが難しくなります。
自分にとって自然な判断でも、別の人には好みの押しつけに見える。
過去の経験から来る注意でも、今の現場では過剰に見える。
時代の流行として正しそうなものでも、そのチームではまだ扱いきれない。
だから、技術の話をするときは、「これは本当に今の現場の正しさなのか」「それとも自分の経験や好みが強く出ているのか」を少し分けて見たいなと思っています。
整理すると、エンジニアの「正しさ」には、次のようなものが混ざっているのだと思います。
| 正しさを作るもの | 具体例 | 注意点 |
|---|---|---|
| 流行 | 新しい設計思想、人気フレームワーク、ベストプラクティス | 今の現場に合うとは限らない |
| 経験 | 過去にうまくいった方法、痛い目を見た設計 | 過去の前提を引きずることがある |
| 好み | 読みやすい書き方、しっくりくる構成 | 他人には押しつけに見えることがある |
| 現場の制約 | 人数、スキル、納期、保守体制 | 理想より現実が優先されることがある |
| 道具の変化 | フレームワーク、クラウド、AI | 正しさの粒度が変わることがある |
こう見ると、「正しさ」は単純な正解というより、いくつかの前提が混ざった判断に近いのかもしれません。
レビューで怖いのは、正しさが固定されたままになること
レビューでは、この問題がかなり見えやすいと思っています。
こだわりの強い人が、自分の中の正しさを持っている。
それ自体は悪いことではありません。
むしろ、経験から来る判断基準があるのは大事です。
何でもいい、動けばいい、という話でもありません。
ただ、その正しさが更新されていないと、レビューを受ける側はけっこうつらいです。
昔は正しかった。
その現場では自然だった。
その技術では妥当だった。
でも、今の現場や今のチームに当てはまるとは限らない。
ここを見ないまま「これは正しくない」と言われると、技術レビューというより、価値観の押しつけに近くなってしまうことがあります。
ただ、これは他人事として言っているわけでもありません。
自分もレビューをする側に回ったとき、自分の中の「こうあるべき」を相手に押しつけそうになったことはあったと思います。
その時点では、良いレビューをしているつもりなんですよね。
経験から見えているリスクを伝えたいし、あとで困らないようにしたい。
でも、それが今のプロジェクトや相手の状況に合っているのかまでは、ちゃんと見ないといけない。
そこを外すと、自分の考え方を正しさとして渡してしまうことになる。
そう考えると、自分も気をつけないといけない話だと思っています。
たぶん、レビューで本当に見たいのは「自分の好みに合っているか」ではなく、
- 今のプロジェクトに合っているか
- 将来の保守で困らないか
- チームが扱えるか
- リスクが増えていないか
- 目的に対して過剰ではないか
というあたりなんだと思います。
AIによって「正しさの入口」が変わり始めている
そして今は、ここにAIが入ってきました。
AIを使うと、設計方針やレビュー観点、ベストプラクティスのようなものを、すぐに整理してもらえます。
これ自体はかなり便利です。
何かを判断するときに、まずAIに聞く。
設計方針も、レビュー観点も、実装方針も、AIに整理してもらう。
そういう使い方は、今後もっと自然になっていくと思います。
その意味では、AIは「正しさを判断する入口」になり始めているようにも見えます。
これまでは、新しい技術の流行や考え方は、いろいろな場所から入ってきていました。
- 書籍
- 技術ブログ
- SNS
- 勉強会
- 現場の会話
- 他のプロジェクトでの経験
- 検索してたどり着いた記事
そういうものが混ざり合って、「今はこういう考え方が自然らしい」と感じていたのだと思います。
でも今は、その入口がAIにかなり寄ってきています。
AIは、かなり強い集合知のようにも見えます。
大量の情報を踏まえて、それなりに妥当な答えを返してくれる。
だから、AIが出す答えは正しく見えますし、実際に役に立つことも多いです。
一方で、少し気になるところもあります。
みんなが同じようにAIへ聞き、同じような答えを受け取り、それを「今の正しさ」として扱うようになると、これまで自然に起きていた議論や寄り道が減る可能性があります。
昔なら、人によって読んでいる本が違ったり、追っている技術ブログが違ったり、経験してきた現場が違ったりして、そこで議論が生まれていました。
その議論は面倒でもありましたが、正しさを更新するための揺らぎでもあったのかなと思います。
でも、流行の入口がAIに寄りすぎると、AIが返す答えがそのまま「正しさ」になってしまう場面も出てくるかもしれません。
AIが言っているから正しい。
今のベストプラクティスとして出てきたから正しい。
そう見えることは、かなり増えていきそうです。
それは便利ですし、たぶん多くの場合は助かります。
ただ、そこに人間側の経験や現場の違い、個人の違和感が入りにくくなるとしたら、それは少し気になるところです。
AIレビューは、人間の好みを少し薄められるかもしれない
AIによるレビューには、少し期待しているところもあります。
もちろん、AIが完璧だとは思っていません。
前提を渡さないと一般論で返してきますし、的外れな指摘をすることもあります。
ただ、人間の好みや過去のこだわりに引っ張られすぎないレビューができる可能性はあります。
人間のレビューでは、現場によっては声の大きさや関係性が影響することがあります。
その人が言うと通る。
別の人が言うと通らない。
正しいかどうかより、誰が言ったかで空気が変わる。
そういう場面を見ると、機械的に観点を出してくれるAIレビューの方が、むしろ健全に見えることがあります。
ただし、AIにもプロジェクトの前提は読ませる必要があります。
- このプロジェクトで守るべきこと
- 使っている技術
- 変更してよい範囲
- 重視する品質
- 逆に、そこまで気にしなくてよいこと
こういう前提を渡したうえでレビューさせるなら、個人の経験や好みだけで進むより、少し健全になる場面もあるのかなと感じています。
AIレビューが人間より常に正しい、という話ではありません。
むしろ、人間の正しさに混ざりやすい「好み」や「声の大きさ」を、少し外から見直すための道具として使えるのかもしれない、という感覚です。
AIは、抽象化の次の段階なのかもしれない
AIエージェントが出てきたことで、プログラミングの抽象化は一気に進んだように見えます。
これまでは、人間がフレームワークやライブラリを選び、コードを書いていました。
でもAIを使うと、「こういうものを作りたい」と伝えるだけで、実装の多くが形になります。
これはかなり大きいです。
人間がプログラムを書くレベルから、やりたいことを伝えるレベルへ移っている。
そう考えると、AIはかなり強烈な抽象化なのかもしれません。
アセンブラからC言語へ。
C言語からフレームワークへ。
フレームワークからAIエージェントへ。
この流れの中で、人間が直接見る場所は変わってきました。
昔はメモリや命令を見ていた。
その後、関数やクラスを見ていた。
今は、成果物の振る舞いや、AIに渡す前提を見る時間が増えている。
そう考えると、AI時代に「何が正しいコードか」を以前と同じ粒度で考え続けるのは、少しズレていくのかもしれません。
もちろん、コードを見なくていいという話ではありません。
品質、セキュリティ、保守性、責任の所在は、今まで以上に大事になります。
ただ、人間が直接見るべき場所や、レビューで重視する場所は変わっていくのだと思います。
宗教論争が少し変わっていくのかもしれない
考えてみると、今までの技術的な宗教論争って、人によって情報の取得元が違っていたから起きていた部分もあるのかもしれません。
- 読んでいる本が違う
- 追っている技術ブログが違う
- 経験してきた現場が違う
- 信じてきた設計思想が違う
だから、それぞれの中に別々の正しさが育っていく。
その正しさ同士がぶつかるから、議論になる。
でも、これから多くの人がまずAIに聞くようになるなら、そういう技術的な宗教論争は、案外起きにくくなるのかもしれません。
みんなが同じような入口から、同じような「今の正しさ」を受け取るようになる。
それはそれで、平和な気もします。
ただ、ちょっと不思議な感じもあります。
あれだけ繰り返してきた宗教論争が、AIによって少しずつ薄まっていくのだとしたら、それはそれで時代が変わった感じがします。
宗教論争がなくなったらなくなったで、少し寂しい気もしますけど（笑）
ただ、議論が減ることが必ずしも良いことだとも思っていません。
面倒な議論の中に、前提の違いや現場の違いが見えることもあります。
違う考え方にぶつかることで、自分の正しさが更新されることもあります。
AIが便利な入口になるほど、人間側はむしろ、自分たちの前提や違和感を意識して持っておく必要があるのかもしれません。
おわりに：正しさは持つものではなく、見直し続けるもの
エンジニアの正しさは、固定されたものではないと思います。
- 言語によって変わる
- フレームワークによって変わる
- チームによって変わる
- 現場の制約によって変わる
- 個人の経験や好みによっても変わる
- そして今は、AIによっても変わり始めている
エンジニアの正しさは、流行だけで決まるものではない。
でも、流行や現場や道具の変化、そして自分自身の経験や好みによって、更新され続けるものではある。
大事なのは、自分の正しさを持たないことではなく、それが今の前提に合っているかを見直し続けることなのかなと感じています。
自分の中に判断基準は必要です。
過去の経験から来る違和感も大事です。
長く触ってきた技術への感覚も、簡単に捨てるものではないと思います。
ただ、その判断基準を何年も前のまま固定してしまうと、今の現場には合わなくなることがあります。
昔は正しかったこと。
その現場ではうまくいったこと。
自分にとって自然だったこと。
それが、今のチーム、今の技術、今の開発の進め方にそのまま合うとは限らない。
だから、技術単体で「これは正しい」「これは間違い」と言い切る前に、少し立ち止まりたいです。
これは本当に今の現場に合っているのか。
それとも、自分の経験や好みが強く出ているのか。
AIが出した答えを、そのまま今の正しさとして受け取っていないか。
そういうことを、ときどき見直したいと思っています。
自分の中に正しさを持つことは大事です。
でも、その正しさが、いつの時代の、どの現場の、誰の経験から来たものなのかは、たまに見直した方がいい。
今の自分には、そんなふうに見えています。