プログラミングを通して考える「帰納」と「演繹」、そしてAI
今年、新卒で社会人エンジニアになりました。
当然なんですが、新しい技術を勉強する機会が一気に増えたんですよね。
それに合わせて、社会人になってからは前よりもちゃんと本を買って読むようになりました。
- テスト駆動開発（TDD）の本
- ソフトウェアアーキテクチャの本
この2つを読んで
- 「あれ、TDDってめちゃくちゃ“帰納的”だな」
- 「逆にアーキテクチャの本って、かなり“演繹的”な発想だよな」
と感じるようになって、
プログラミングと「帰納・演繹」の関係について考えるきっかけになりました。
この記事は、そのあたりのことについて考えたことを整理したものです。
ざっくりおさらい：帰納と演繹
本文に入る前に、軽くだけ整理しておきます。
帰納（inductive）
- いろんな 具体例 を見たり試したりして
- 「どうやらこういうルールっぽいぞ」と パターンを抽出する やり方
プログラミング的には：
- 実際にコードを書いて動かして、「あ、このライブラリはこういう動き方をするのか」と体で覚える
- エラーを踏みながら、「このフレームワークでは、この順番で初期化しないとダメなんだな」と学んでいく
演繹（deductive）
- 先に 一般的なルールや原則 を知っておいて
- それを 個別のケースに当てはめる やり方
プログラミング的には：
- アーキテクチャやコーディング規約といった「ルールセット」を基準に
- 実装場所・書き方を機械的に決めていくこと
どちらが偉いという話ではなくて、
「どの場面でどっちをどれくらい使うか」 がポイントになります。
帰納的アプローチ：コードを書いて動かして学ぶ
まずは、新しいことを学ぶときに自然とやっている方の話から。
実際に書いて動かして、挙動から理解する
新しい言語・ライブラリ・フレームワークを学ぶとき、
いきなり仕様書を全部読むことってあまりないと思います。
たいていは：
- チュートリアルをコピペして動かす
- 引数を変えたり、ログを仕込んでみる
- 「あ、このオプションつけるとこう変わるんだ」と試行錯誤する
- 何回か試すうちに、だんだん挙動が頭の中でまとまってくる
つまり、
具体的な動く例 → パターンを発見 → なんとなくの「ルール感」ができてくる
という流れ。これはかなり 帰納的 な学び方です。
「文章としてルールを説明できる前に、なんとなく使えるようになっている」状態って、
プログラミングでもよくありますよね。
TDDも、かなり“帰納寄り”の考え方
TDD（テスト駆動開発）も、発想としてかなり帰納的です。
- まず 小さなテスト を書く
- そのテストを通すための最小限の実装を書く
- それを繰り返していくうちに、結果として より一般的なロジックや設計が浮かび上がってくる
全体の仕様を完璧に把握してから実装するというより、
テストという「具体例」を積み重ねることで、仕様や抽象がはっきりしてくる。
私はこれを読んだときに、
「あ、これってプログラム版の“帰納法”っぽいな」
と感じました。
演繹的アプローチ：ベストプラクティス／アーキテクチャに従う
一方で、すでにある程度ルールが分かっている領域では、
演繹的な進め方の方が圧倒的に強い とも感じています。
ここでいうルールとは、
- ソフトウェアアーキテクチャ
- コーディング規約
- フォルダ構成やレイヤー分割のパターン
- 「このプロジェクトでは〇〇は必ずここに書く」といったチームの合意
みたいな ベストプラクティス全般 のことです。
クリーンアーキテクチャは、その中のひとつの例にすぎません。
Output（実装）の面でのメリット
クリーンアーキテクチャのようなベストプラクティスに従っていると、
- 「この処理はドメインのルールだから、ここに書く」
- 「これはインフラ依存だから、この層に閉じ込める」
といった判断を、ほぼ自動的に 下せます。
その結果：
- 実装場所で迷う時間が減る
- 「とりあえずここに書いちゃえ」という場当たり実装が減る
- 一度決めたパターンに沿って、ガンガン手を動かせる
つまり、Output がめちゃくちゃ速くなる。
Input（インプット）の面でのメリット
それだけじゃなくて、インプット側にもかなり大きなメリットがあります。
- 既存コードを読むときに、「この責務ならだいたいこの辺にあるだろう」と当たりがつく
- 新しい機能を理解するときに、まず「このプロジェクトのレイヤー構造」を頭に読み込んでしまえば、その後の理解が一気に楽になる
- 参考コードを探すときも、「この処理に近いのはこの層」と範囲を絞れるので、欲しいサンプルにすぐたどり着ける
つまり、ベストプラクティスやアーキテクチャは、
「書く」ときだけじゃなく、「読む・学ぶ」ときの地図にもなってくれる
というインプット面の意味でも、強力な“演繹のための土台”なんだと思います。
新しいことは帰納で、既知のものは演繹で
ここまでをまとめると、自分の中ではだんだんこう整理されてきました。
未知の技術や分野に触れるとき
- とにかく動かしてみる
- 例を書いてみる
- エラーを踏んで挙動から理解する
- → 帰納的アプローチで「感覚」をつかむ
すでに構造やルールが分かっている領域
- アーキテクチャやベストプラクティス、チームの合意に従って
- 実装場所や書き方をサクッと決める
- → 演繹的アプローチで「スピード」と「一貫性」を上げる
そして、これはプログラミングだけじゃなくて、
勉強全般にも当てはまりそうだな、と思うようになりました。
勉強における「フェーズ」と、帰納／演繹の比率
英語でも数学でも、あるいは他の分野でも、
学習のフェーズによって、帰納と演繹の比率は変わる と感じています。
初期フェーズ：帰納多め
最初は正直、ルールを聞いてもピンと来ません。
- プログラミングなら、とりあえず書いて動かして崩してみる
- 数学なら、具体的な数字を入れて計算して、「この式ってこういう動きをするんだ」と体感する
- 英語なら、「なんとなくこのフレーズはこの場面で使うんだな」という感覚を増やしていく
この段階では、
帰納：演繹 ＝ 7：3 くらい
のイメージで、例や体験を多めにする方がしっくりきます。
慣れてきたフェーズ：半々くらい
ある程度なじんでくると、
「なんとなく分かるけど言語化できてない」ことが増えてきます。
そこで、
- 分からないところは、また例をいじって帰納的に理解を深めつつ
- 分かってきた部分は、ルールとして整理したり、用語で押さえたりする
このあたりは、
帰納：演繹 ＝ 5：5
くらいのバランス感覚がちょうどいい気がしています。
上級フェーズ：演繹多め
上級になってくると、
- 抽象的な話を聞いても、すぐ具体例が頭に浮かぶようになります
- 理論や原則の方を先に知ったほうが話が早い場面も増えます
このあたりでは、
帰納：演繹 ＝ 3：7
でも十分やっていけるし、
むしろ演繹的な学び方のほうが効率がいいことも多いと思います。
ただし、まったく新しいジャンルに手を出した瞬間だけは、また帰納に戻る。
この行ったり来たりが、人間の学習っぽいなと感じています。
そしてAIの話：本当に「何でもやってくれる存在」なのか？
最後に、どうしても触れておきたいのが AIとこの話の関係 です。
よく言われるフレーズに、
「AIが発達したら、プログラマの仕事はなくなる」
みたいなものがありますよね。
これについて、今のところ私は、
「少なくとも、全部が全部そうではないだろう」
と感じています。
AIはどちらかというと“演繹的な使い方”に向いていると思う
AIそのものの内部はともかく、
仕事での使い方 という意味では、AIはかなり演繹寄りのツールだと感じています。
- 既知のベストプラクティスやパターンを組み合わせてコードを出してもらう
- あるアーキテクチャやフレームワークの前提条件を守ったうえで、サンプルを作ってもらう
- 既存のコードに沿ったスタイルで実装の「ひな形」を生成してもらう
こういう
「ルールや文脈がすでにある程度決まっているところに対して、それを当てはめていく」
みたいな仕事は、AIがものすごく得意です。
一方で、
- そもそもどんなプロダクトにするのか
- どんなユースケースが本当に価値があるのか
- このチームや領域にとって、どんなアーキテクチャやルールがふさわしいのか
みたいな “まだ形が定まっていないところ” を探るのは、
やっぱり人間の帰納的な試行錯誤が必要だと思っています。
プログラマの仕事・生き方としての「帰納」と「演繹」
私は、帰納的なアプローチで新しいことに挑戦していく時間が好きです。
- よく分からないライブラリを触り倒して、「あ〜こういう思想か」とつかむ瞬間
- テストを書きながら仕様を整理していく過程
- まだチームとしてのルールが固まっていないところで、一緒に形を考えていくプロセス
そういう意味で、TDDのような 帰納寄りのプラクティスには少しずつでも挑戦していきたい と感じています。
一方で、新卒として企業で職業プログラマとして働き始めてみると、
「この先、仕事の多くは演繹的な比率が高くなっていくんじゃないか？」
という危惧も、正直なところあります。
- 既存サービスの保守
- 既に決まっているアーキテクチャに従った機能追加
- チームの規約に合わせた実装修正
こういった仕事は、どうしても演繹寄りになりがちです。
そこにAIも加わってくると、なおさら「演繹の高速化ツール」としての側面が強くなるでしょう。
だからこそ、あえて問いたいのは、
「自分は、帰納と演繹のどんなバランスで生きていきたいのか？」
「挑戦と堅牢さを、どのあたりで両立させたいのか？」
という、プログラマとして・エンジニアとしてのスタンスの話です。
私は、
- 演繹的なベストプラクティスやアーキテクチャの力も借りながら
- それでもときどきは、TDDや新しい技術への挑戦といった 帰納的な“探検”の時間 をちゃんと持ち続けたい
そう思っています。
そして、
演繹と帰納、挑戦と堅牢のあいだで、
いい感じのバランス感覚を保ちながらエンジニアとして生きていけることを願う。
これが、今のところの素直な結論です。
Discussion