【入門】駆け出しエンジニアに薦める、最初に読むべき至高の技術書

どうも、初心者からたったの7年でエンジニアになった三井です！
システムチームでテックリードやってます！よろしくお願いいたします！！！

最近この「初心者からたったの〇ヵ月でエンジニアになった」的な謳い文句流行ってますね。ノってみました。

さて今回は、エンジニアを志す初学者に最初に手に取ってもらいたい参考書籍の紹介です。
さっそくいきましょう、それがこれ、

サイゼリヤのまちがいさがし

はい、『サイゼリヤのまちがいさがし』です。
サイゼリヤに行くと子ども用メニューの裏面が間違い探しになってますよね？あれです。

冗談きつい？
いえ、真面目にやってます。

今回は『サイゼリヤのまちがいさがし』に込められたエンジニアスピリットについて語り尽くします。

誰でもプログラミングを学び始められる恵まれた時代

今回はプログラミング初学者向けの投稿なんですが、
実のところ、現代においてプログラミングを学び始めることはそこまで難しい事ではありません。
本屋に行けばさまざまなプログラミング言語・フレームワークの入門書が売られていますし。Web 上でも無料のチュートリアルや解説記事が多く公開されています。

それらに書かれた手順通りにやれば、新しいプログラミング言語を学び始めるのはそう難しくありません。

ただし...

手順通りに進んでいるうちは、ね。

初学者に立ちはだかるデバッグの壁

初学者がつまずくポイント、それは 入門書の手順通りにやっているのにエラーが出て思い通りにいかない そんな時です。
たいていの人はこの時初めて プログラミングにはデバッグに多くの時間をとられる ことに気付きます。

ではここで質問。
世にあふれる入門書には デバッグの方法 が丁寧に書かれているでしょうか？

書かれていないんですよ、恐ろしい事に。

でも大丈夫！
デバッグに必要なスピリットは全てこの本に書かれています。

もう少し細かく、『サイゼリヤのまちがいさがし』が教えてくれるデバッグの極意について解説していきましょう。

デバッグの極意①：デバッグは間違い探しに似ている

デバッグは間違い探しに似ています。

間違い探しでは左右に似たような絵が並んでいて、左右の絵の 異なっているところ「間違い」を探します。
「間違い」はたいてい簡単なものから見つけづらいものまで複数あって。それらを全部見つけるまで頑張るんです。

デバッグととても似ていますね。「間違い」を「バグ」に読み替えます。

• 上手く動くプログラムと上手く動かないプログラムの間には異なっているところがある。それが「バグ」
• 「バグ」は一つだけとは限らない
• 「バグ」が全部見つかるまで頑張る

ね？

デバッグの極意②：間違い探しに「専門知識」は不要

プログラミング初学者からのデバッグにまつわる相談を聞いていると、デバッグが苦手な人は共通して「デバッグに必要な専門知識を探し求めている」事に気付きます。
そして、「自分には専門知識が足りないからデバッグできないのだ」と思っているフシがあるのです。

デバッグをするには専門知識が必要というのは本当でしょうか？

私が言うには答えは No 。デバッグにおいて専門知識は必ずしも必要なものではありません。

『サイゼリヤのまちがいさがし』には「オリーブの生産地」や「チーズの製法」など毎回さまざまなテーマについて詳しく面白く書かれています。
では、サイゼリヤの子ども用メニューを見て間違い探しするには「オリーブの生産地」や「チーズの製法」についての専門知識が要るのでしょうか？

そんなことはありませんね？
デバッグだって同じなんですよ。これホント。

デバッグに専門知識が必要だと思い込むことの本当の問題は別のところにあります。
人の脳は「できない」と感じた瞬間に できる方法 ではなく できない理由 を探し始めるのです。そして本当にできなくなってしまう。

プログラムをジッと見つめてバグを探しているつもりが、バグを見つけられない理由 を探してしまっている。そんなことが起こりえるのです。
サイゼリヤで間違い探しに挑む子どものように、気負わず、楽しみながらデバッグに集中しましょう。専門知識はいりません。

デバッグの極意③：間違い探しは「正解」探しではない

『サイゼリヤのまちがいさがし』ではよく似た2枚の絵が左右に並んでいますが。2枚のうちどちらか一方が正しい絵というわけではありません。

サイゼリヤ公式サイトより引用

デバッグにも同じ事が言えます。自分が書いた プログラム と、入門書に載っているサンプル、どちらが正解ということは無いのです。

これは意外な事かもしれませんが、バグの原因は自分が書いたプログラムの中だけにあるとは限りません。
入門書にも誤植がありサンプルプログラムが間違えていることもありますし。プログラミング言語の動作自体にバグがあることだってあるのです。

バグの原因は「左側の絵」にも「右側の絵」にも潜んでいます。
「正解」を見つけようとすると難易度はとたんに高まります。

打開策は「正解」を探さずに「違い」を探すことです。
ただシンプルに「違い」だけを探すようにしてみてください。

いきなり正解を掴もうとするのは、ときに遠回りになります。

デバッグの極意④：間違い探しには「全体の俯瞰」と「大局観」が必要

間違い探しをはじめるとき、いきなり細部から見ていく人は少ないのではないでしょうか。
まずは全体を俯瞰してどんな絵が描かれているか把握しますよね。ときには『間違い探しの作者がネタを仕込むとしたらどの辺だ？』と想像してみるかも知れません。

デバッグのときも同じようにします。

まずプログラムの全体を俯瞰して内容を把握します。間違いが隠れているとしたらどの辺か、想像してみることも重要です。
前者が 「全体の俯瞰」、後者が「大局観」というやつです。

デバッグの極意⑤：問題を部分に分解して、根気強く見比べる

極意③でデバッグのポイントは「ただ違いを探すこと」と書きました。
それは嘘ではないですが。実際には、全体を俯瞰して内容を把握したあとには全体を部分に分けて、細部を見比べてくことをオススメします。

間違い探しでも、間違いがありそうな部分にアタリを付けたらその部分に視野を絞って集中して見ていくでしょう？

フランスの哲学者 デカルトはこう言いました「困難は分割せよ」と。
でもフランスの哲学者の言葉を引用しなくたって子どもだってやることなんです。「違い」を見つけるなら細部を見比べていく。

デバッグの極意⑥：自ら違いを作り出すことだってできる

ここまで『サイゼリヤのまちがいさがし』にこじつけて5つの極意を伝授してきました。
ですが、この世には 『サイゼリヤのまちがいさがし』からは学べないこともあるのです。残念ながら。

せっかくなので一つ紹介しましょう。

実は「違い」は自ら作り出すこともできるのです。

入門書通りに書いたはずのプログラムが思った通りに動かない。
画面に表示されるのは無残な(見慣れないアルファベットで書かれた)エラーメッセージだけ。

そういうとき、私はこうアドバイスします。「これまでに書いたプログラムを全て消して、空っぽの状態にして実行してみて」と。

これまで一所懸命に書いたプログラムをまっさらな状態にリセットしてみる。そして実行してみる。
当然ながらそんなことで思った通りに動くようになるわけではありません。

しかし、プログラムを全て削除したにもかかわらずエラーに変化が無いとしたら？

そういうときにはこう結論づけます。
「そのファイルは読み込まれていないね。読み込まれるべきファイルが読まれない状況自体がバグ」と。

ここから学べることはなんでしょうか？

精一杯 頑張っても「違い」を見つけられないときだって悲観することはありません。
「違い」は自ら積極的に作ることができるのです。

わざと間違える。確実に間違える。
それが最も原始的な違いの作りかたです。これまで正しくしようと行動してきたのを、逆に、間違えようと行動してみる。

そうやって自ら作り出した「違い」を注意深く観察することで得られる情報も多くあります。
『サイゼリヤのまちがいさがし』で得られた観察眼はここでも役に立つのです。

まとめ

いかがでしたか？
エンジニアをやっていて、『コレって サイゼリヤのまちがいさがし じゃん！』と思うことがあまりにも多かったので思い切って筆を取りました。

サイゼリヤはおいしい食事だけでなく、大切なエンジニアスピリットを教えてくれる。
さぁサイゼリヤに行きましょう。大いに語り合いましょう。

我々エンジニアには、その技術を使って世界をもっと良くしていく責任がありますから。

私からは以上です。

サイゼリヤのまちがいさがし