『コーディングを支える技術』の西尾泰和と考える、エンジニアが学ぶべき技術の原理原則

池田　僕がこの本を初めて読んだとき「プログラミングに初心者だったあの頃に知りたかった！」という項目が並んでいるなと思いました。多くのエンジニアがつまずきがちな要素が正確にピックアップされていますが、どうやってこういった要素を抽出したのですか？

西尾　自分のまわりのエンジニアや、大学生などプログラミングに詳しくない人に「プログラミングを初めて学んだときにつまずいたところは何ですか？」と、実際に悩んでいたことは何かをヒアリングしたんです。

C言語を始めたばかりの人は「for文とwhile文の違いが分からない」、すでに経験が長い人でも「オブジェクト指向が何か分かるまですごく時間がかかった」というようにエンジニアが抱えがちな課題を解決する、というコンセプトの本にしています。

池田　「はじめに」でも「本書の目的はみなさんの『なぜ？』を解決することです」と書かれていますよね。プログラミング言語の概念を幅広く網羅されていて、初心者から中級者の境目にいる方にフィットしそうな内容かなと思ったのですが。

　読者のみなさんは、きっと今までにいろいろな本を読んで「なぜ？」と思ったことがあるでしょう。本書の目的はみなさんの「なぜ？」を解決することです。

（『コーディングを支える技術』p.iii はじめに より）

ご執筆時にも、初心者から中級者の方を読者として想定していましたか？

西尾　想定読者、という考え方はあまり好きではないんです。ターゲットを絞ってしまうと、「このレベルの人はこの知識を学ばないだろう」という決めつけになってしまう。例えばエンジニア2～3年目の方向けの本では、for文とwhile文の違いは割愛されるでしょう。

プログラミングに触れた期間が同じでも、人の知識レベルは違うもの。それなのに、「想定読者」として知識に境界線を引くことにあまり意味はありません。実際の反響を見ても「自分が初心者の頃にこの本があればよかった、後輩に勧めよう」という人がたくさんいる反面、「これは初心者向きではない」という人もいる。このように、「初心者」という言葉のイメージも、人によって異なります。

僕はとにかく、この本を長く読まれる本にしたかった。あえて想定読者を作らないことで、簡単なところから難しいところまでくまなく伝えられるだろうと考えたのです。

10年たっても読まれる本にしたかった

西尾　長く読まれる本にしたい、と考えたのは、処女作『Jythonプログラミング』での、ある苦い経験があったからです。実は本の執筆中にJython処理系のバージョンが上がり、急いでサンプルコードを書き直したんですよ。出版後も言語のバージョンは上がるから、日を追うごとに情報が陳腐化してしまう。古い情報の本だと思うと恥ずかしくて、人には「僕が書いた本だよ」と見せられませんでした。せっかく時間をかけて書いた本なのに。

だから次の本は、5年、10年と時間がたっても陳腐化しないことを目指しました。

池田　確かに、技術書を買う側としても、いつ発行された本なのかはチェックしてしまいます。

西尾　技術は移り変わるもので、情報の陳腐化は避けられません。でも『コーディングを支える技術』は2013年に発売されてから5年近く（2018年4月現在）たっても高く評価されています。

さまざまな反響を感じますが、多くの人に刺さった理由は、技術そのものの解説でなく、「この概念は実際のところ何なんだろう？」という多くの人が抱えがちな疑問にフォーカスしていたからでしょうか。それらの中でも、特に陳腐化しにくい部分を言語化したのです。『コーディングを支える技術』には、情報が古くなることを避けるためのこだわりがあるんですよ。例えば、IBM、HPという略語が読者に伝わらなくなってしまう可能性を想定して注釈を書いた部分もあります。

略語を避けた理由は、前例があるからです。僕がこの本を書くときに調査した80年代の文献にはよく「RR」という略語が出てきたのです。レミントンランドという会社です。当時のレミントンランドは、略語で書いても伝わる超有名なコンピュータメーカーでしたが、今知っている人は少ない。こうした知識の風化が当たり前にあるんです。

技術の本質を知るべし

池田　『コーディングを支える技術』は言語をまたぐ原理原則を紹介しています。

特に12章「継承」にある知識は、現場で役立つなと思いました。継承は正しく使えばコードを整理できますが、「なぜ？」を理解しないまま乱用してしまうと逆にメンテナンスを難しくしてしまいますね。

原理原則を知る必要はあるのか？

池田　しかし、エンジニアになりたての頃の自分がこの本を読んでも「この知識、いつ役に立つのかな？」と感じたんじゃないかなと思います。実際に、ライブラリを使ったりコピペをするだけでも最低限動くものは作れるようになる。 エンジニアが知識・技術力を身に付けなくても、ある程度のアウトプットを出せるようになった今、原理原則を学ぶ意義をどのように考えますか。

西尾　技術が進歩すれば、原理原則を知らなくてもよくなります。例えば今の時代に、トランジスタの仕組みを知らなくてもコンピュータを使って仕事ができますよね。

ではいま現在、オブジェクト指向や継承を知らなくても仕事ができるでしょうか。まだ「知らなくても問題ない」と言えるほどには技術が進んでいない。もっと文明が進むと、誰でも適当に書くだけできれいなコードが生成されるようになるかもしれませんが、それはまだ先の話なのです。

池田　原理原則という意味では、「型」の章ではメモリ上での表現方法とそれに伴うデータ保存の効率など、これまで意識していなかった点を学べました。

　本章では、型とは何なのか、どうして必要となったのかを学ぶために、まず数をどうやって表現するかについて学びました。

（中略）

　コンピュータの中の値が整数なのか浮動小数点数なのか、どんな種類の値なのか。この情報をコンピュータに管理させるために、型が生まれました。当初、型には値の種類の情報だけを入れていますが、やがて多種多様な情報を型に入れるようになりました。たとえば、その値に対してどんな操作が可能か、この関数はどんな例外を投げるのか、などの情報を型に入れるようになりました。

今では、静的型付けと動的型付けのように、情報の場所や使われるタイミングが違うものまで含めて「型」と呼ぶようになり、型が何であるかのイメージがつかみにくくなってしまったように思います。どんな情報がどこにあって、どういうタイミングで使われるか、と言う視点で見るとわかりやすいのではなないでしょうか。

（『コーディングを支える技術』p.133-134 8.7）

しかし、知識をいかに実務で活用するかというイメージができにくい章でもありました。なぜ『コーディングを支える技術』では型を取り上げたのですか？

西尾　ここ10～20年ぐらいは型を強く意識しないプログラミング言語がブームでした。PythonやRubyが盛り上がってきたのもこの頃です。しかし今は揺り戻しが起こり始め、Closure CompilerのようにJavaScriptに型情報を付けたり、TypeScriptのように静的型付けの言語で実装してJavaScriptに変換したり、という動きが盛んです。

型というと「CやJavaだと宣言しないと変数が使えなくて不便、なんで宣言が必要なの？」という疑問を持つ人がいます。このように「型があると面倒くさい宣言が必要」といった表面的な理解では、なぜ型を取り戻そうとしている人たちがいるのかを理解できません。

そこで、型とは何かを根本から説明することにしたのです。

コピペだけでは生き残れない

池田　「概念としての型」のように、技術の本質を知っていれば、変更に強くて堅牢なコードを書けるようになれますね。こうした原理原則や概念を知っているかどうかで、エンジニアの成長速度は変わると思いますか。

西尾　成長速度に違いがあるどころか、コピペする“だけ”の仕事はどんどん価値を失います。Google検索するだけで問題の解決方法が見つかり、それをコピペで多くの問題を解決できるようになりました。この流れは今後も進み、コピペだけでできることはどんどん増えるでしょう。

コピペの進化を個人の成長と考えるのは大きな誤解です。誰もが同じように底上げされています。もし、エンジニアがキャリアを重ねてもコピペすることしかできないままだったら、キャリア初期と問題解決能力が大差ないことになる。

だからこそ、検索して答えが見つからない問題を解くことが大切なんです。成長とともにその能力を身に付けていかなければ、情報集積と検索のシステムが進歩するにつれて個人の価値がどんどん下がっていくでしょう。

どうしたら変化に適応できるか、という問いの答えは「新しいことを学び続ける」になるんじゃないでしょうか。

どうやって学び続ければいいのか

自分がやりたいと思える分野を突き詰めよう

池田　新しいことを学ぶとなると「自分の興味とはすこし離れた分野でも挑戦しないと、エンジニアとして生き残れないんだろうか？」というようなプレッシャーもあります。今だと「機械学習をやっておかないと、今後職に困るのでは？」のように。

西尾　英語を勉強しないといけないんじゃないか、みたいなやつですね（笑）。機械学習を知らないといけない……関数型言語を勉強しないといけない……、こうした不安感をあおってくるコンテンツはいっぱいありますよね。

僕は自分が「楽しい、やりたい」と思えるものを突き詰めるようにしています。

マイナーな分野でもいいので、検索で見つからない知識を得られれば、誰かと知識を交換できるようになります。自分の知識を必要としている人に提供する代わりに、不得手な部分は他の人から教えてもらう、という知識の交換ができる。

西尾　「他の人が勉強しているものを自分も勉強する」というスタンスだと、常に後追いなので知識が交換できるようになりません。一方、「人と違うことを学ばなきゃ」と考えるのはプレッシャーになります。だから、自分が心を動かされる、楽しいと思えるものを見つけて、それを学ぶのです。そして他人がそれを学ぶことに価値を見出さなくても「でも、自分はこれが面白いと思うんだ」と突き進めば、自然と他人と違う知識を持った人材になっています。面白くないものを頑張って勉強しても身に付きませんし、誰か必要だと言われて面白くないものを学んで、予想が外れて役に立たなかった時に残念な気持ちになります。どんなに悩んでも、「○○を学んだら成功ですよ」と教えてくれる人はいない。誰も未来を予測できないのですから。

でも、自分が学びたいことだったら、仮に実務の役に立たなかったとしても「面白かったからいいか」とポジティブに終わることができます。

まずは1週間やってみる

池田　何か新たな技術を学びたいとき、例えばプログラミングだったら、PCなど基本的な環境があれば、お金は必要ないですよね。しかし、腰が引けてしまうのは、「はたしてこの言語は時間的投資をするに値するか？」といった迷いがあるからだと思います。西尾さんはどのようにお考えですか。

西尾　学び始めるときは投資対効果を考えるより、勢いが大事です。俺はこれが好きで、これを学んでみたいと思うから学ぶんだ。リターンがあろうがなかろうがどうでもいい。例えば、カメラが好きな人は「買いたい！」と思うからレンズを買う。そのとき、「このレンズで将来の自分の収入がどれくらい上がるか」と考えて買わないでしょう？

好きという気持ちが、投資対効果の計算を圧倒的に凌駕して、勢いで始める。進むうちに知識が貯まる。知識が貯まってから振り返ると、学んで良かったかどうか、もっと掘り下げるべきかどうかが分かるんです。

池田　まずやってみることは大切ですね。

新しいプログラミング言語を使っていると、周りの人から「自分のチームでも導入してみたいけど、大丈夫か」と相談を受けることがあります。そんな時は1週間使ってみるといいですよ、と答えるようにしています。1週間でも真剣に学ぶと、エンジニアは言語や技術の面白さに気付くことが多い印象があります。はじめは1週間と言っていたのに、自分から積極的に使うようになるケースが多いですね。

西尾　1週間と区切るのはいいですよね。失敗としても時間のロスは1週間分だから、損失も限られます。1週間でダメだと思ったらやめて、別のことをやったらいい。

学ぶ前に悩んでいても何も見えてこないから、まず一歩進んでみようよと。一歩進むとよく見えて、もっと進むともっとよりよく見えて、となる感じですね。

池田　最初の一歩を踏み出せないという若いエンジニアには「最初は分かる範囲でやればいい、分からないところを無理に分かろうとしなくていいよ」と声を掛けたりしています。

アウトプット～フィードバック～修正のサイクルを回して知識を深める

池田　私がエンジニアになりたての頃は、技術への純粋な興味というよりも、周囲の活躍している人たちへの憧れと、追いつきたい気持ちが学ぶモチベーションになりました。でも学び続けているうちにだんだん楽しくなって、以前より技術そのものに純粋な興味を持てているように思います。

西尾　楽しくなったきっかけはあるんですか？

池田　学ぶ前よりもコードがきれいに書けたり、早く作れるようになったりするのはもちろん、世に出す成果物の品質が上がったなと感じられるようになってきたからですかね。

西尾　やっぱり。「自分が学んだことで、このように良くなった」という実績が見えると、もっと学ぼうという気持ちになると思います。本を読んで、ただひたすらインプットだけを繰り返していたら楽しくなかったはず。実際にアウトプットしてみて、結果が出たから楽しいんですよね。

池田　確かに、そうですね。

西尾　アウトプット、大事です。他の人と話をしているうちに、自分の学んだことを整理できたり、分かっていないことが発見できたりする。

　あなたが何かを勉強して「理解できた」と思ったとしましょう。それは「本当に理解できた」のか、それとも「『理解できた』と勘違いしているだけ」なのかどちらでしょうか？

　それはあなた一人が考えてもわかりません。理解が正しいかどうかを確認するためには、アウトプットが必要です。自分の理解をもとに何かを組み立てて、それを第三者に検証してもらうしかありません。英語を勉強したのなら、その英語を使ってみて、ほかの人の反応を確認しなければ、自分が本当に英語を理解できているのかどうか分かりません。

（『コーディングを支える技術』p.23 Column「理解を確認するためにはまずアウトプット」 ）

プログラミングを学ぶ時にも、書く～実行する～結果を見てバグを直す、というプロセスがあると思います。この「アウトプット～フィードバック～修正」というサイクルをぐるぐる回していくことによって、徐々に自分の中の知識が研ぎ澄まされていくのだと思っています。

モチベーションをいかに保つか

池田　西尾さんはエネルギッシュにいろいろと学び続けられていますが、モチベーションを保ち続けるための工夫はありますか？

西尾　僕だってやる気が起きなくてダラダラしていることがあるんですよ（笑）。ごろごろ寝たり、ゲームしたりして。

そんなときは友人から刺激を受けると、スイッチが入ることが多いです。「退職して時間ができたからイギリス留学に行ってくる」という友達を見ると、「ヤバイ、僕留学したことがない！」と焦ると同時に、もっと自分にやれることがあるよなと思います。

池田　留学は私には遠いですが……（笑）。しかし、私も周囲の人が自分よりレベルの高いことを始めると、焦りを覚えます。例えば、同期のエンジニアがプロダクトマネジメントに挑戦したり、転職してもっと専門的な仕事を始めたり。刺激になるような友達や同士がいるのは重要なんですね。

西尾　友達で「博士課程を修了したので医学部に入り直します」と言った人がいて、マジかと（笑）。「大学に籍を置きたいから」といって情報科学で博士出た直後に医学部に入る、IT系なのに。

池田　それはすごいですね。

学びの方法はレベルによって変わる

西尾　僕もこの春から、民法を学ぶために法学部の聴講生になる予定です。

民法は、個々人の間の契約を司る一番重要な法律です。つまり、社会における人間個々の取引のシステムのプログラミング言語は民法なんです。「それを知らないままエンジニアとしていられない、ヤバイ」という思いがふつふつと湧いてきたんです。

池田　モチベーションに圧倒されました。民法も本とネットでもある程度学ぶことができそうですが、わざわざ聴講生になる理由はなんでしょうか。

西尾　誰もが新人の頃は自分の周りの人に聞いて教わる状態だったでしょう。そこから、成長とともに、自分で本やネットなどを使って勉強できる段階に進みます。しかし、本や既存の書かれたものだけから学べる情報も、知識の幅としてはまだ狭い。さらに理解を深め、上に突き抜けていこうとしたときに、専門家に教えを請いに行くというフェーズがあるんじゃないかなと思います。

池田　なるほど。例えば街で自分の知らない何かに出会ったときにも、まずは「ちょっとGoogleで調べてみよう」となりますが、そこからさらに掘り下げるというわけですね。

西尾　そうそう。興味のあることは、まずGoogleで調べてみる。Googleで調べて足りなくて、さらにもっと知りたいと思ったときには本を買って読む。本を買って読んでも、さらに足りなくて、もっと教えてほしい、もっと知りたいとなったときに「よし、じゃあ、大学に行くか」という感じです（笑）。

プロダクトを通じて「社会にどんな価値を提供できるか」という視点を持とう

池田　西尾さん自身は、お仕事中に、この本の知識が必要だと感じる状況はありますか。

西尾　『コーディングを支える技術』から学べる情報の範囲も、実は狭いんです。

本来、僕の本に書いてあるような細かいことは、考えないで済む未来が正しいはずです。エンジニアがコードの美しさや、よいコードのための原理原則を考えるのではなく、コンピュータがよしなに処理してくれればそれでいい。

エンジニアにとって一番大事な原理原則は、プロダクトを作ることによって、社会にどんな価値を提供しているのかという視点です。社会人として初心者から中級者にステップアップするためには、マクロな視点で物事を見られることが絶対的に必要だと思っています。

世の中の人間はエンジニアだけではありません。営業やカスタマーサービス、総務など、多くの人がそれぞれの価値を出すことで、会社の利益が出て、給料が払われ、食べていくことができます。「自分はエンジニアだから」といって、コンピュータの中の狭い世界に閉じこもるのは「1つの言語しか使えないプログラマ」と同じです。

エンジニアが社会への目線を持つためには、経済や哲学を学ぶ必要があると考えています……ということを本の最初に書いたら、カットされてしまい「幻の0章」となってしまいました（笑）。

池田　まるで企業経営者のような視点に聞こえます。

西尾　実はエンジニアと経営者はレイヤーが違うだけであって、本質的には同じだと考えています。

エンジニアは、コンピュータの中のプログラムのコンポーネント同士がどう連携して、より効率的に出力をできるかシステム設計を考える。経営者は、人間がどう連携して、より効率的に社会に価値を提供できるかシステム設計を考える。システムを設計していくという点ではエンジニアも経営者も同じなんですよ。

エンジニアは与えられた問題を解くだけじゃなくて、その問題はそもそも解く必要があるのか？ という疑問を持ったり、技術的な方法で解くんじゃなくて、個々の部署のコミュニケーションや人間関係を改善することで解けるんじゃないかと考えたり、そういう、より広いシステムの上での最適化を考えられるようになることが大事なのかなと思います。

まとめ

1. エンジニアとして成長を続けるための秘訣
2. 技術の本質を知ろう
   1. 自分がやりたいと思える分野を突き詰めよう
   2. まずは1週間やってみよう
3. アウトプット～フィードバック～修正のサイクルを回して知識を深めよう
4. モチベーションは外部からの刺激
5. 適切な学びの方法を取ろう
6. プロダクトを通じて「社会にどんな価値を提供できるか」という視点を持とう

取材・執筆：村山早央里（ZINE）