プログラミングに向いてないかと思ってたけどなんとかなっている話

note.mu

バズってる記事への便乗記事。

僕自身がもともと絶望的にプログラミングに向いていないと思っていた人間だったので語りたくなった。

【お話をする内容】

• 現在の私のスペック
• なぜプログラミングが向いていないと思ったのか
• どのようにして書けるようになってきたのか

現在の私のスペック

• 24歳で文系卒（隠すと良くないので補足すると高校の頃は情報学科的なところにいた）
• 都内のWeb企業でWebエンジニアをしている
• 普通にWebエンジニアとして仕事する分には特に支障がない程度には書ける（と思っている）

なぜプログラミングが向いていないと思ったのか

ひとことで言えば、まったく「書ける気がしなかった」からだ。
特にコードの意味がわからなかった。
プログラミング言語やフレームワークの教科書を開くと、サンプルコードが書いてあると思う。
それを見るたびに、「え、世のソフトウェアエンジニアはこれ全部を暗記してんの？無理じゃね？」とか思っていた。

ましてや、高校の頃に情報学科にいて3年間もプログラミングについて学んだにもかかわらず、いま思うとコピペプログラマくらいの力しかついていなかった。*1
他人のコードをコピペして動くまで勘で書き換えていくことくらいしかできなかったのだ。

どのようにして書けるようになってきたのか

僕にとっての転換点はいくつもある。
ざっくりまとめると以下の4つだ。

• リーダブルコードに出会う
• コーディングを支える技術に出会う
• コードリーディングをするようになった
• オブジェクト指向設計を勉強した

リーダブルコードに出会う

最初の転機は「リーダブルコード」に出会ったことだ。
この本は「プログラムは読めるモノ」だという認識を僕に与えてくれた。
それまでは記号の羅列にしか見えなかったコードが、この本との出会いを境に読めるものに変わった。

この本を読むまでは関数が「よくわからん記号で名付けられたブラックボックス」に見えていた。
しかし、関数は実は「つけられた名前のとおりに振る舞う道具」だったのだ。
これは、当時の僕には衝撃的で世界が変わるようだった。

この本をキッカケに知らない英単語が使われている関数名は、辞書で調べて意味を把握するようにしている。

また、私が書くコードにも「意図」が込められるようになった。
aやtestと名付けられていた変数名や関数名が、userやfollow_userに変わったのだ。

コーディングを支える技術に出会う

リーダブルコードを読み終わってあとでも、いまいちよくわかっていない概念があった。
それは各種言語機能とライブラリの関数の違いだった。
classやfor、puts、raise StandardErrorの違いがわかっていなかったのだ。
それを解決してくれたのが「コーディングを支える技術」だった。

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)

本書はある言語機能はどういったものでなにを解決するために現れたのかを解説している本だ。
この本もまた僕のプログラミングへの視点を変えてくれた。
それまでごった煮だった概念が各種の言語機能とその他で見分けが付くようになったのだ。

そして、この本はプログラミング言語の違いは言語機能の違いにあるという認識を与えてくれた。

コードリーディングをするようになった

大学2年生の春に、Webアプリ開発を学ぼうとRailsチュートリアルを3回ほど繰り返した。
チュートリアルを終え、意気揚々とアプリケーションを作り始めると数多くの壁にぶつかったことを覚えている。
チュートリアルで学んでないことができなかったからだ。

その結果として「XXXはどうやってやるのだろうか？」というヒントを得るべく、Railsで作られたOSSのソースコードを参考にするようになった。

これは非常に正解だった。
洗練されたOSSは、素晴らしいレシピブックだったからだ。
「どうすれば読めるコードになるのか」がそこにあるのだ。
見事な処理の分割の仕方を目の当たりにして、僕に「設計」の存在を意識させるキッカケとなった。

オブジェクト指向設計を勉強した

コードリーディングをするようになると、OSSを開発している人たちは「なぜ、こんなコードを思いつくのだろうか」と考えるようになった。

思いつき方がまったくわからない僕は「やはりプログラミングの才能がなかったのだ」と思い始めていた。
なんとかわかる方法がないかと一生懸命調べ続けた。
迷走して「プログラマ 思考法」とかで調べてた気がする。

そんなこんなである時に、たまたま「どうやら多くのクラスはデザインパターンというものを参考作られているらしい」ということがわかった。
そして、その概念がオブジェクト指向設計の延長にあることを知り、その勉強をしようと考えた。

以下の記事を読んで、「オブジェクト指向のこころ」を買った。*2

takatoshiono.hatenablog.com

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

この本ははじめて読むオブジェクト指向の本としては非常に難しくて、読み終えるのに1ヶ月半くらいかかった。
蛍光ペンをめちゃくちゃ引いて読み直したり、付箋を付けて解釈して自分の言葉に直したりを繰り返した覚えがある。

この本で学んだもっとも重要なモノは「責務」という概念だ。
オブジェクト指向設計とは「責務を分割したり組み合わせてデザインすることだ」という認識を得られた。
本書によって、僕の見る世界がまた変わったのだった。

そして、この本を読み終えたあとも、オブジェクト指向をいまいちよくわかってない部分も多く、補足をしてくれる本を探していた。
そんな矢先に以下の記事に出会って「オブジェクト指向実践ガイド」を購入した。*3
tango-ruby.hatenablog.com

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

(当時はまだ日本語版が出版されていなく、すがる思いで原著を買った。)

この本は徹頭徹尾「実践」に重きをおいた本で、非常にわかりやすい。
小さく粗く作って、綺麗で柔軟な強い設計に改善していく過程を追っていける。
そのため、「設計しながらコードを書く」方法を学べる。
これはまさに僕がわかっていなかった「コードの書き方」への明確なアンサーだった。

そして、この本で最も学んだことは「長く生きるアプリケーションは変更されていく」ことと、「変更に強い設計とはなにか」ということだった。

この本を読み終えたあたりでようやく意図してコードを書くことができるようになったと自覚できるようになったと思う。

まとめ

かくして、少しずつ視点の変化を積み重ねることで、Webエンジニアとしてなんとか働ける程度の技術力にはなったのである。

ちなみに「どのようにして書けるようになってきたのか」のすべてを達成するのに数年くらいかけている。
それくらいプログラミングは苦手だったのだが、プログラミングが好きだったこととできるようになることを楽しめたのが大きかった。
一歩前進するだけで、自分は実はプログラミングの才能があったんじゃないと錯覚するくらいには単純な人間だったため、ここまで勉強をし続けられたのだ。

「才能がなくて『プログラミング』を諦めよう」と考えている人も、時間さえ投資すれば最低限のプログラミングくらいはできるようになるんだよと思っていただけたら幸いである。

*1:末恐ろしいことに、この頃の僕も「プログラミングはできる」と思っていた。すぐにその幻想は崩れて才能がないとうなだれるのだが。

*2:当時は読めるような技術力がついたら記事を読もうとブクマしておく癖があったので、マイブックマークでオブジェクト指向と検索したら上の方に来たのだ

*3:ちょうど、Rubyで書かれていたのも買う理由になった。