Profile image

AI時代に考えるプログラマーの不便益

#読書

先日、「不便益」というキーワードに惹かれて、この本を読んだ。

不便益と便利の害

まず、この本で語られている「不便益」について、軽く説明しておきたい。

「不便益」とは、不便であるからこそ得られる効用、と定義されている。

例えば、次のようなものが挙げられる。

  • アクセスしづらい場所にある秘湯は、たどり着くまでの手間も含めて魅力になる
  • 鍵穴に差し込むタイプの車のキーは、ちゃんと閉まったかが分かりやすい
  • 紙の辞書では、調べている言葉のまわりの単語も自然と目に入る
  • 安宿では、他の宿泊客と話すきっかけが生まれやすい

一方で「便利であること」にはマイナスに作用する側面、つまり「便利の害」もある。

  • 車の安全装置が、かえって無理な運転につながることがある
  • バリアフリー化によって、体を使う場面が減り、弱ってしまう
  • 洗濯機はブラックボックス化されていて、操作や故障時に困る
  • 飛行機の自動操縦によって、操縦士が退屈になってしまう

便利は常に良いものとは限らず、不便であっても、それが良い結果につながる場面がある。

印象に残った言葉

単線的に手間を省くことを便利と呼び、これを求めるだけではいけない（p.27）

「便利」という言葉は、基本的にポジティブな意味で使われることが多い。 効率が重視される現代では、タイパや生産性の向上が自明の価値として扱われている。

ただ、それを突き詰めた先にあるものが、本当に望ましい体験なのかは立ち止まって考えたい。 極端な例だが、富士山にエレベーターが設置されたら、それは本当に「便利でうれしい」ことなのだろうか。

「楽だけど楽しくない」から「楽じゃないけど楽しい」へ（p.45）

日常生活の多くは、無意識のうちに「楽であること」を優先して選択されている。 しかし、その結果として体験そのものの手応えや満足感が薄れている場面も少なくない。

不便が与える益の一つは「手間をかけ頭を使わされるという不便は、自分を変えてくれる」ということ（p.124）

手間がかかり、考えさせられる状況は、確かに効率的ではない。 しかし、その過程で得られる理解や成長の実感は、簡単に置き換えられるものではない。

「便利」によって、そうした機会が失われているとしたら、それは果たして幸福と言えるのか。

AI時代のプログラミング

ここからが本題。

毎月のように新しいLLMが発表され、それに合わせてエンジニア向けのAIツールも次々と登場している。 コード生成、レビュー、設計支援など、AIがカバーする領域はこの1年で急速に広がった。 こうした状況を背景に、「AI疲れ」という言葉が使われるようになったのも自然な流れだろう。

実際、日々の開発においてAIを使わずにコードを書くことは、もはや珍しくなりつつある。 自分自身も例外ではなく、設計の壁打ちや実装、レビューなど、さまざまな場面でAIを活用している。

この1年で、プログラミングの進め方が大きく変わったことは間違いない。 AIを活用することで生産性は向上し、ユーザーに価値を届けるまでの時間も短縮された。 レビューで助けられた場面もあれば、AIがなければ解決が難しかったであろう問題もあった。

一方で、こうした変化の中で、作業が順調に進んでいるにもかかわらず、どこか割り切れない感覚を覚えることもある。効率は確実に上がっているが、それだけでは説明しきれない違和感が残る場面がある。

プログラマーの「便利の害」

ライン生産方式とセル生産方式の対比も、本書で紹介されている「不便益」の例の一つだ。

ベルトコンベアを使った流れ作業によるライン生産方式は、大量生産に向いた効率的な方法である。一方、少人数のチームが一つの製品を最初から最後まで組み立てるセル生産方式は、大量生産には不向きだが、作業者が工程全体に関わることで、製品への理解や愛着が生まれやすい。結果として、モチベーションやスキルの向上につながるとされている。

この対比は、AIを使ったプログラミングにも当てはめて考えることができる。

AIを活用することで、一定の品質を保ちながら、効率よく開発を進めることができる。 その一方で、コードを自分の手で書いていたときに比べると、プロダクトとの距離が少し遠くなっていると感じることがある。

一行ずつコードを書き、試行錯誤しながらデバッグし、ようやく動いたときの達成感は、AIが生成したコードをそのまま採用する場合には得にくい。結果として、プログラミングの「楽しい」という感覚が薄れてしまうことがある。

AIエージェントやMCPの登場によって、問題の調査は格段に楽になった。 しかし、公式ドキュメントを読み、GitHubのIssuesを追い、試行錯誤しながら理解を積み重ねていく過程で得られるものも、確かに存在する。

効率化の裏側で、プログラマーとして考え、迷い、理解する機会が減っているとしたら、それは成長の機会が失われているとも言える。

これは、AIによって生まれたプログラマーにとっての「便利の害」の一側面だ。 自動操縦のコクピットに座るパイロットの感覚に近い。

プログラマーの「不便益」

ここまでの話を踏まえると、最も分かりやすい不便益は 「AIを使わずに開発すること」 なのかもしれない。

AIを使わずにコードを書くことで、設計に悩み、調べ、試し、失敗する時間が増える。 その過程で得られる理解や達成感は、確かに不便益と呼べるものだ。

ただし、仕事の開発において、常にAIを使わないという選択は現実的ではない。 品質やスピードが求められる場面では、AIの支援は大きな価値を持つ。 結果として、「AIを使わない」という不便を意図的に取り入れられる場面は、個人開発や学習用途など、どうしても限定的になる。

そこで発想を変える必要がある。

不便益は、「AIを使うか使わないか」という二択ではなく、 AIをどう使うかの中にも見出せるのではないだろうか。

例えば、

  • いきなり完成形を生成させるのではなく、設計の壁打ちに使う
  • 答えを求めるのではなく、別案や反例を出させる
  • コードを書かせる前に、自分の考えを言語化する

こうした使い方では、考える主体はあくまで自分に残る。 AIは作業を肩代わりする存在ではなく、思考を刺激する相手になる。

AI時代のプログラミングにおける「楽しさ」は、 単に手を動かすことから、考え方や使い方を工夫することへと移りつつあるのかもしれない。

便利さの中に埋もれてしまいがちな不便を、どこに、どの形で残すか。 その設計自体が、これからのプログラマーにとっての新しい腕の見せどころになりそうだ。

まとめ

「不便益」という考え方は、便利さを否定するものではない。 便利がもたらす価値を認めたうえで、それだけを追い求めることの限界に目を向ける視点だ。

AIによってプログラミングは確実に便利になった。 品質は安定し、開発は速くなり、以前よりも多くのことが短時間でできるようになった。 一方で、考え、迷い、理解する過程が省かれ、成長や達成感を実感しにくくなっている側面もある。

仕事の開発において、AIを使わないという選択は現実的ではない。 だからこそ重要なのは、「使うか使わないか」ではなく、どう使うかを考えることだ。

すべてをAIに任せるのではなく、あえて自分で考える余地を残す。 手間のかかる部分を完全に消さず、学びにつながる不便を意図的に残す。

便利さの中に埋もれてしまいがちな不便を、どこに置くか。 その判断こそが、AI時代のプログラマーに求められている姿勢なのかもしれない。