強いITエンジニアになるには
大場寧子氏（以下、大場）：「強いエンジニアという灯（あかり）」というタイトルで話します、株式会社万葉の大場と申します。よろしくお願いします。
（会場拍手）
まずは軽く自己紹介します。大場寧子と言って、@nay3というアカウントでTwitterをやっています。プログラマー歴がかれこれ32年ぐらいになってきました。「Ruby」と「Rails」が大好きなプログラマーです。今は株式会社万葉の創業者兼代表取締役社長ですが、7月からは株式会社レトリバの取締役も務めています。また、小学1年生の娘がいる一児の母でもあります。
ちなみに今日は103枚もスライドがあるので、1枚あたり（スライドの表示時間が）17秒なんですが。出だしを考えると10秒ぐらいずつで進まないといけないので（笑）。
（会場笑）
（スライドを指しつつ）これを書きました、というのと、『IT人材ラボ』で採用の話とかを2018年ぐらいに書いて、ちょっとバズりました。
今日のテーマが「強いITエンジニアへの道について」ということで、少し原則的なことを紹介していきたいと思います。
強いエンジニアとは何か。私が思うに、まず技術を使った問題解決がうまい。先ほど「問題の発見と解決」という話がありましたが、やっぱり問題の発見と解決はすごく大事だと思っていますあとは折れない心でエンジニアリングができるというのも重要で、さらに骨太で、柔軟かつ広い。こんなイメージを持っています。
前半は、強いエンジニアになるためには、どんな練習法がいいのかという話をしようと思います。
失敗こそ最高の学習方法
（スライドを指しつつ）これは万葉で、新人教育などを何回もやっている中で、感じていることをまとめたものです。
同じようなことに取り組み、同じような本を読むといったカリキュラムで進めるにしても、スキルの伸び方には個人差があると感じています。スキルを早く伸ばすための要素とはなんだろう？ そんなことを考えるわけですね。これはみなさんが自身のスキルを伸ばすため、もしくは後輩を育てるためにという観点でも聞いてもらえると。
私の考える効果的な学習というのは、自分の頭で考える、覚える、信念を積み上げる、自分のやったことを評価する。失敗は最高の学習法であり、うまくいっている状態をパターンで認識する方法です。
まずは、自分の頭で考える。例えばスクラッチでコードが書けるということは、すごく大事だと思います。サンプルコードを見ながらなんとか動いても、やっぱりキツイなということですね。この会場で、自分のアプリを開発したことのある人はどのくらいいますか？
（会場挙手）
ありがとうございます。開発経験がない方も相当いらっしゃるので、ぜひチャレンジしてほしいと思います。やっぱり自分のアプリを開発するのは最強だと思っています。私も「Rails」を始めたときにWeb家計簿「小槌」というものを作って、今でも運用して使っています。
次に、覚えることは意外に大事という話。毎回APIリファレンスで調べたり、エディタの補完機能を利用するのもいいんですが、調べる時間はなるべく短くして、その分考える時間を増やしたほうがいいものができると思います。
覚えるというのは速さの根源だと思うんですね。調べる時間を短くするためにどんどん覚えるほうがいいと思います。
でも「暗記は苦手なんだよね」ということもあると思いますので、そんな方には裏技を紹介します。例えばメソッド名。名前を覚えるのではなくて、名前づけの法則を覚えます。何かのオブジェクトについたコメントを取りたくなったら「.commentsがあるんじゃないかな？」と、予測すればいいわけですね。そうすれば、「このクラスには.commentsというメソッドがあります！」ということを覚えておく必要はなくなります。
名前の法則がわかれば、「.comments」があるかないかだけを確認できます。名前づけの法則を覚えていれば、名前を覚えているのと同じなんですね。レバレッジが効くというか、とても効率がいいんです。これについて抽象化すると、結果を覚えるのではなくて、結果を生み出す法則を覚えるということです。
これはコードでも同じ。いつも同じように書くならば、コードのことを忘れてしまっても、同じ課題について考えることがあれば、まったく同じコードが書き上がるはずなんですね。まぁ人間は変化するので、実際には多少の揺れはあるんですけど……「こういうことをしたいから、こうなっているはず」という推測で、コードを覚えているのと同じように早く問題解決できます。
なので、既存コードの出来にもよりますが、ある程度法則に従っているコードの場合は、初見でも速く見つけ出せるんじゃないかなと思います。結局そういうことが「Ruby」や「Rails」の気持ちがわかることにつながるわけですね。
「きっとRailsならこういうふうにしているだろう。あったあった」みたいな感じで進められるので、覚えているのと同じように、サクサク作っていけるということですね。
そうなると、書くときも法則を意識してコードを書く必要があります。そうしないと、全部調べないとメンテナンスができないコードになってしまいます。自分で法則を考えて、常にそれに従って書いておく。そうすると後々ラクになります。
自分のやることに信念を持つ
次は信念を積み上げる話をします。エンジニアリングでは物の性質や挙動を利用すると思います。一方プログラミングは、メソッドの挙動や言語の仕様などを利用しているかと。ですが、このときに物の性質や挙動をフワッと理解したまま先に進んではいけない鉄則があると思っています。万葉では、新人教育のときにすごく指導が入る部分で、グラグラした土台の上に次の土台を積まないということですね。
例えば「AまたはBのように動く」と思っているものがあったとして、それを前提に次に「CまたはDのように動く」というものを組み合わせると、実際に起きていることについて4つの可能性が出ます。可能性が4倍になったら、4倍考えないと正しい成果に当たらなくなってしまいます。
これはすごいハンディキャップで、大抵の人は4倍の量を同じ速度で考えられないと思うので、成果がうまく出せなくなってしまいます。3つ、4つと積んだら、どんどん増えていくので、当てずっぽうみたいな感じになってしまいます。なので、一つひとつの性質や挙動に対して、信念を持ちましょうということを万葉ではよく言っています。
信念がある場合とない場合ではこういう違いになります。（スライドを指しつつ）信念がない場合は「あれ、動かない。このメソッド、こんなふうに動くものなのかも……？」みたいに、メソッドの動き方を見て自分の理解が違っていたかもしれない。と考えて「そうだったらこんな風にしたら直るかな？」みたいなアプローチをしてしまいます。
これは典型的に信念がないケースです。本当の信念があれば「あれ、動かない。このメソッドは絶対こう動くはずなのに、何かがおかしい。何が起きているのかな？」という発想になるわけですね。そうすれば、的を絞って無駄な時間を使わないで問題を解決していけます。
自分がやろうとしていることにも、信念を持つことが大事だと思っています。とくに初心者は取り組んでいる最中に「自分にできるかな、書けるかな、コードが動くかな？」というのを心配する人が多いと思いますが、信念があればこういう心配をする必要もありません。
「あなたのコードは必ず動きます！」……ということなので、信念を持つというのはすごく大事だと思っています。折れない心で、目の前のことを一歩一歩理解して進む、あるいは目の前の現実に冷静に対処することが必要なのです。
この台詞は、ちょうど弊社の忘年会で「こういう話をするんだけど」と、ネタを集めていたところ、こういうのをすごく得意な人が言っているのを聞き、「これだ！」と思いました。
自分の仕事を評価する
次に別の話として、自分のやったことを評価するということが大事だとという話をします。これは成長速度にすごく関わるキー・ファクターで、初心者だけではなくて、社会人としてもそうだと思います。エンジニアとして仕事をする、プロとして成長するときのキー・ファクターですね。
よく見かける光景で、コードを書き、仕事が終わって「ふぅ、よかった」だけだと学習効果が薄いように感じます。仕事をする、それがどうだったかを評価する。そこから学ぶみたいにできると、効果的に経験を積めると思っています。同じ1年の経験をしてもすごく伸びる人と、そうでない人はそこに差があるんじゃないかなと見ています。
「評価って何？」ということですが、ある仕事をしてうまくいったか、いかなかったかを考える。そして自分なりの結論を出す。その中で、どんなことを失敗したか見つける。うまくいっていれば、成功している形を覚える。といったことをしていけばいいと思います。
失敗は最高の学び
失敗は最高の学習法だと思います。ここでいう失敗とは、予期しない、うまくいかないことです。必ずしも仕事中にしくじって怒られたとか、お客さんに間に合わなかったとか、そういったことだけでなく、「こう動くと思ったけど違った。こうなんだ」とか「こういう例外が出るのか」なども、ここでは全部失敗と呼んでいいと思っています。
よくある失敗の例として、思い通りの動作をするコードが書けない、バグがあった、時間が掛かり過ぎた、期待されたのと違うことをした、もっといいやり方があった、他の人にとってわかりづらかった……とかいろいろあると思います。先ほどのコミュニケーションの失敗もそうですよね。失敗はすごい学びの宝庫。失敗をするとすごく学べます。
失敗には、それにつながる「失敗の芽」があって、成功するということは逆に言うと、この失敗の芽にうまく対応できることなんですね。仮に失敗の芽に気づかないでたまたま成功が得られたとしても、そういう成功はただのラッキーパンチで、再現性がないんじゃないかと思ってます。
例えば「Rails」で、1対多のモデルデータを扱うような文脈で「has_many :task」とかの定義があった場合、どれだけ失敗の芽を思い浮かべることができますか？一個一個は紹介しませんが、失敗の芽の例をあげていくと、こんな感じです。
例えば親モデルを削除したいときに、子モデルを連動で削除するのを忘れてゴミが残ってしまうことがあるかもしれない。同じミスを起こさないように「ちゃんと連動削除の指定をしておかなくちゃ」となります。そういったことの積み重ねです。失敗の芽を知っているから、それを回避できる。だからうまくいくようになると思っていて、この失敗の芽を蓄えることが、強いエンジニアになることにつながるんじゃないかなと思っています。
そのためにはどうすべきなのか？ 結論から言うとたくさん失敗することです。たくさん失敗するには、たくさん書き、たくさん試す。そしてどんどんやる、新しいことを試す、難しそうなこともやる。あとは失敗できる環境に身を置く。これも先ほどの忘年会で出た話で、その新人だった人は配属されて、けっこう無謀な「issue」の取り方をしていました。「こんな難しいものを取るの？」みたいな感じで。果敢に挑んではコメントが100つくみたいな（笑）。
でもそれについて、本人は「終わらないプルリクはない」みたいなことを言っていました（笑）。それは結局、彼が無茶なことをしても、一緒にいる先輩が全部レビューしているから、おかしなことにはならない環境なんですね。「だからあえて難しいのをやった」と言っていましたが、そういう戦略もありだと思います。なので、そういった先輩がサポートしてくれる環境でなければ、自分からそんな環境に飛び込むのも大事かなと思います。
パターンを覚える
あとはうまくいっている状態をパターンで認識するという手があります。（スライドを指しつつ）これはキレイな部屋をイメージした写真で、私はうまくいっている状態ってキレイな部屋みたいなものかなと思っています。ふだん散らかった部屋に住んでいると部屋がおかしくても気づかない。でもキレイな部屋に住んでいれば、少しでも汚れていたり違和感があれば、おかしいって気づきやすいですよね。何事もおおまかなパターンを覚えて活用すると、ラクができると思っています。
コードがうまくいっているときは、シンプルなコードに見えるとか、どこにコードを書けばいいかが判断しやすく、要所だけにコメントがあり、コードだけを読んでも意味がわかるといった、予測どおりにコードが来る状態なんですね。
チームがうまくいっているときは、仕事をチームで共有できているので連携がしやすい。今日も話があったと思いますが、1on1や振り返りなどのコミュニケーションの仕組みが回っている。よい雰囲気で助け合いからペア作業やモブ作業、雑談。こういうのがうまくいっているときの光景なんですね。
うまくいっている状態をパターンとして覚えておいて、現状と比較します。これは一度うまくいかないと覚えられないので、まずはうまくいかせるという感じなんですけど（笑）。うまくいって気持ちのいい状態がわかると、比較したときにいろいろ気づきやすくなります。それでパターンと違うときに違和感を覚えて、気になって、そこを注意するという感じです。
少し話が脱線しますが、これはコードレビューのときにすごく重宝します。コードレビューのアプローチとして、仕様との整合性を見る、動作を確認する、または書かれたコードに反応していくというのがあります。もう1つ、書かれるべきコードがないことに気づくことも必要なんですよね。こちらはわりと難しいと思っています。
この内容がパターンの話と紐づいていきます。最後の2点だけに絞って説明すると、まず、書かれたコードに反応していくときは、行とかメソッド、クラスといった単位で失敗の芽を潰すように見ていきます。「この書き方でこの方法を使うときは、こういう失敗があり得るけど、問題なくできているかな？」というような確認をしていきます。そうすると失敗の芽が見つかったりします。
それからコードの全体像を、脳内でうまくいくパターンと比較して、違和感があるところの改善を考えます。例えば明らかにモサーッとして読みにくいブロックがあったら「これはもうちょっとキレイになるんじゃないか」と考えますよね。それで「どうすればいいのかな？」みたいに手順を考えていく感じですね。
次に、書かれるべきコードに気づくという話があります。これはフォーカスを大きくして、コードでなく仕様や挙動を思い浮かべて「こういう仕様や挙動のときに失敗の芽としてはどういうのがあるだろう？」と見ていきます。話題になった『7pay』の問題も、これをやっていたら事前に発見できたかもしれませんんね。
それから、課題を思い浮かべて、うまくいくパターンとコードを比較します。例えば「注文をキャンセルする場合には返品」とか「それをやるときには必ずこういう処理を考える必要がある」みたいなパターンが自分の中にあれば、コミットの中にそれに関する変更がないと「ん？ 何かがおかしい」と感じるでしょう。そういう「課題とパターン」のセットをいっぱい持っていると、書かれるべきコードがないことに気づきやすいので、おすすめです。
