はじめに

最初に簡単な自己紹介です。私は理系（非情報系）の大学を学部で卒業し、新卒でWeb制作会社に入社して、現在２年目（今年４月で３年目突入）のサーバサイドエンジニアです。

あくまで私個人の経験を通して感じたことですが、プログラミングが上達するうえで大切なことは、以下の３つの軸を持つことだと思います。

常に師匠を持つ
自分のこだわりを作る
自分のこだわりをいつでも捨てられるというプライドを持つ

本題に入る前に『プログラミングの上達』が指すイメージを述べておきます。
今回の記事では、『たくさんの言語・技術を扱えるようになる』というよりは、『プログラムを設計する力や、新しい技術を学ぶときの理解力の向上』などの問題を解決するために自分で考える力をつけるということを『プログラミングの上達』と捉えています。

1. 常に師匠を持つ

師匠と言えば大げさかもしれませんが、いわゆるメンターを持つことです。これは会社などで用意されたメンターというよりは、自分の中で勝手に師匠を作って、その人の考え方やコードの書き方を真似していくということです。

残念ながら私は今でもわからないことだらけですが、入社当時はもう本当に何一つわかりませんでした。そんな中で理解を深めていくには、実際に理解している人のやり方を見よう見まねで真似するしかありません。

別に師匠は人に限りません。技術書も師匠ですし、後述しますが「オブジェクト指向」や「新しく学ぶ言語・フレームワーク」なども立派な師匠です。

師匠は自分にはない（とは違う）考えを持っている人であれば、誰でも構いません。
大事なのは、なにか学びを得るときに師匠のこだわりを盗んでやるというモチベーションを持って取り組むということです。
そうすれば、上っ面の知識ではなく、より深い感覚の部分まで習得できると思います。そういった知識は、たいてい応用が利きやすいです。

また、師匠は複数持ってもいいです。むしろ、複数持った方がいろんな人の感覚を自分の中で持てて、より多角的に問題を見られるようになります。そして、その複数の感覚の集合が自分自身のこだわりを形成します。
私自身、設計の師匠や、フロントエンドの師匠、インフラの師匠などたくさんの師匠を持っています。

抽象的な話が続きましたので、私の経験に基づいた少し具体的な話をします。

とりあえず現場で働く

プログラミング初心者が技術力を上げる一番手っ取り早い方法は、現場で働くことだと思います。

私自身、就職するためにpaizaで自学自習したり、成果物を作っていた時期、入社して外部研修（プログラミングスクール）を受けた時期、実際現場で働きだした時期と、プログラミング初心者として３つの時期を経験しました。
その中で圧倒的に成長を実感したのは、実際に現場で働きだしてからです。

私は運良く、新卒という隠れ蓑を使え、環境にも恵まれたので、たくさんのことを丁寧に教えてもらうことができました。

プログラミングの勉強を始めようとしている方の中には、いきなり個人で仕事をやっていこうと考えている方も少なくないかと思います。
しかし、プログラミングの上達という観点では、初めはどこかの現場で働くことをおすすめします。
なぜなら、現場の方が圧倒的に師匠を見つけやすいですし、師匠との距離が近く、よりこだわりを吸収しやすいからです。また、現場の生の声・知識というのは、イチから本で学ぶよりも体に入ってきやすいです。

上記の環境がそろっている方や、天才は初めから個人でやっても問題ないと思いますが、私のような身寄りのない凡人には現場で働くことが一番学習効率が良かったです。

初心者なりのレビューをしまくる

レビューは師匠のこだわりを盗む絶好の機会です。
人が書くコードには必ずこだわりがあります。こだわりというと仰々しく感じるかもしれないので言い換えると、そのようなコードを書くに至った思考プロセスが必ず存在します。

レビューを行うという大義名分で、師匠との技術的な対話の機会が得られます。その対話を通して、師匠の思考プロセスを聞き出し、自分の中にインストールしていくのです。

しかし、初心者がレビューを行うにはいろいろな心理的ハードルがあると思います。
私自身、そもそも初心者がレビューを行っていいものなのか、初歩的な質問をしてレビュイーの時間を奪っていいのかなど、最初は躊躇していました。

ただ恵まれたことに、私が所属したチームではレビューは挙手制で、初心者がレビューを行うことを推奨していました。チームとしては、初心者に早く戦力になってもらうことがなにより効率的なのです。
最初は、上司がいろいろ取り持ってくれて、レビューを回してくれたりしました。おかげさまで、レビューに対する心理的なハードルが下がり、自分から積極的にレビューしていくようになりました。

私がレビューする上で心がけていたことは、

必ず一点は質問する
質問するときは、必ず自分で考えた形跡を見せる

ということです。
具体的には、「なんで〇〇と書いたんですか？」ではなくて、「〇〇と書いたのは✕✕だからですか？」のように、質問だけを丸投げするのではなく、見当違いでもいいので今できる自分の解釈を添えます。
そうすることで、自分で相手の思考プロセスをたどる練習にもなりますし、レビュイーも質問の意図を把握しやすく、より建設的な答えが返ってきやすいです。

2. 自分のこだわりを作る

師匠たちのこだわりをたくさん集めて、それらを自分のこだわりにしていきます。
ここで注意が必要なのは、「〇〇さんがこう言ってたから」とするのではなく、完全に自分の意見とすることです。
師匠同士の意見が食い違うことはよくあることです。そのときに、どっちの師匠の意見を採用するかを決めるのは自分です。
間違っても、師匠の名を使って他の師匠と意見を交えてはいけません。そのような場面では、必ず自分の意見として議論すべきです。
そうすることで、発言が自己責任になり、師匠が言っていることについてより深く考えるようになります。そうやって師匠のこだわりを自分のものにし、自分のこだわりを形成していきます。

私が思う『自分のこだわりを作る』ことのメリットで代表的なものは、以下の２つです。

自己満足できて、プログラミングが楽しくなる
いろいろな人・技術のこだわりを相対化できる

まず、こだわりを持ってプログラミングをするとプログラミングが楽しくなります。どういうことかと言うと、自分のこだわり通りになるように工夫しながらコードを書くと、「単に動くだけのコードではなく、良いコードが書けた！」と達成感が違います。（実際、半年後とかに見るとクソコードに感じることは往々にしてありますが）
この達成感は自己肯定感を高め、「次も良いコードを書いてやるぞ～」とプログラミングがどんどん楽しくなります。

また、自分のこだわりを持っていると他者のこだわりと比較できます。この『ものさし』を持つことは、他者のこだわりを理解するときや、新しい技術を学ぶときに大変役に立ちます。
自分がこだわりを持って問題解決に当たっていると、「実現したい共通のゴールに対して、自分ならAをするけど、〇〇さん（or このフレームワーク）はBをしている」といった状況に直面します。これはAがあるからこそBに気づくことができるのです。
そして、この差分を理解することで、他者のこだわりを理解でき、また自分のこだわりがアップデートされます。

また少し、私の経験について話します。

オブジェクト指向を学ぶ

前章でちらっと書きましたが、「オブジェクト指向」や「新しく学ぶ言語・フレームワーク」も師匠です。
これらには必ずなんらかのこだわり（思想）が存在します。しかも、これらの技術は一般的に受け入れられていることがほとんどなので、より多くの人たちがこれらのこだわり（思想）に共感しているということになります。
つまり、こういった技術は人類の英知の集積であり、たくさんの学びがあります。

私は現場で働きだして、業務で使っているフレームワークについて簡単な修正作業ができる程度に理解した段階で、オブジェクト指向の勉強を始めました。
この段階では、まだ何が良いコードで悪いコードなのか自分では判断できませんでした。しかし、オブジェクト指向の考え方を学ぶことで、目指すべきコードの形というのが初めて自分の中でぼんやりと姿を現しました。
なにか一つの指標を手に入れた感覚です。これこそが自分のこだわりの一つなんだと思います。
今ではこのような指標が当時に比べてたくさん集まり、自分のこだわりもかなりアップデートされてきています。

実際、オブジェクト指向からどのようなことを学んだかというと、しつこいようですがそれはこだわり（思想）です。
この記事ではオブジェクト指向についての詳しい話は控えますが、よくある「クラスが車の設計図で、インスタンスが実際の車で、、」ということではなく、「単一責任の原則」や「依存関係を減らす」などなどのこだわりです。
こういったこだわりは、変更に対して柔軟なソフトウェアを開発するために役立ちます。

特にサーバサイドエンジニアの方には、技術を勉強する第一歩として、オブジェクト指向を学ぶことはおすすめです。
以下の記事は、私がオブジェクト指向の概観をつかむのに大変参考になったものです。

3. 自分のこだわりをいつでも捨てられるというプライドを持つ

よく言われすぎている話ですが、現代はとても変化が速い時代です。その中でも、IT業界は特に速く、毎年のように新技術が発表されています。
それはつまり、毎年のように新たなこだわりが生まれているということになります。
この新たなこだわりが、自分の持っているこだわりとコンフリクトしたとき、上手い具合にマージしてあげる必要があります。

ここで言いたいのは、新技術をすべて取り入れろということではなくて、自分が持っていないこだわりに直面したとき、そっちのこだわりの方が良いと自分で納得できるなら、自分のこだわりを捨ててでも取り入れるべきだということです。
こんなことは当たり前だと思うかもしれません。
しかし、経験を重ね、自分のこだわりへの依存度が高くなればなるほど、自分のこだわりを捨てるハードルが高くなり、新たなこだわりに対して排他的になりがちです。
これは仕方がないことだと思います。なぜなら、自分のこだわりを捨てると、今まで積み上げてきたものを否定された気分になり、精神衛生上よくないからです。

ただ、自分のこだわりを捨てるということは、そのこだわりを自分の中から完全に消すというわけではありません。あくまでこだわりの優先順位が変わるだけで、問題に対するそのこだわりからの視点というものは生き続けます。

とはいっても、メンタルへのダメージはなかなか消えないと思います。
そこで私が提案する~~まやかしの~~メンタルハックが、『自分のこだわりをいつでも捨てられるというプライドを持つ』ことです。
これはプライドです。変化を素直に受け入れられることはすごいことです。十分、周囲に誇ることができます。
このようにして、私はできる限りフラットに相手の意見が聞けるようにマインドコントロールしています。

後輩も師匠

入社して１年くらい経つと、業務未経験の方がちらほら入社してきました。いわゆる、後輩です。
それまでの私は、何もわからない顔をして先輩のこだわりをひたすら吸収するだけでよかったのですが、今度は自分がこだわりを伝える側にも回る必要が出てきました。

最初は、頼れる先輩であろうと変に気負ってしまって、空回りばかりでした。
そんな中、ある日自分が書いたソースに対する後輩のレビューコメントで素直に勉強になったことがありました。
このとき、初めて後輩から学ぶこともたくさんあるんだなと実感しました。

それ以降は、後輩も師匠であると考えるようして、先輩としての余計なプライドは持たずに、後輩にもいろいろ質問するようになりました。
そして、後輩の良いこだわりはどんどん取り入れることにしました。

私がそういったある種弱腰の姿勢を見せることで、後輩側にも心理的安全性が担保され、どんどん意見を言ってくれるようになり、意見交換の良い循環が生まれるようになりました。

ただここで重要なのが、後輩の全てを肯定するのではなく、しっかりと自分の意見も伝えて、議論をするということです。
全肯定するのは、一見優しいようですが、後輩にも自分のためにもなりません。
議論をして初めてお互いのこだわりを深く理解することができるのです。

さいごに

最後にこんなことを言ってしまっていいのかとは思いますが、私はまだ１社しか経験していない井の中の蛙です。
ただ、『自分のこだわりをいつでも捨てられるというプライド』は持っています。
どうか師匠のみなさんのこだわりをご教授ください。