タグ: エンジニアの勉強法

このサイトの作業は、かなりの部分をAIと一緒に進めています。

気になっていたのは、それで自分に何か残るのかということでした。60本を超えた時点で、残ったものと残らなかったものがはっきり分かれています。

残らなかったもの

正直に書くと、手順は覚えていません。

ここは開き直っています。調べれば出るものを覚えておく理由が薄いからです。AIと組む前から、この手のものは毎回調べていました。

残ったもの

残ったのは、「なぜそれを選んだか」のほうでした。

たとえば、同意を取る仕組みを作ったとき。先に読み込んでおいて送信の可否だけ切り替える方法と、同意まで読み込まない方法があります。後者を選びました。

理由は、前者だと自分のコードを全部読んでも「送っていない」と言い切れないからです。判断が相手の設定に移ってしまう。

この判断は覚えています。手順は忘れても、何を基準に選んだかは残りました。

分かれ目は「確かめられるかどうか」だった

残るものと残らないものを分けていたのは、時間でも回数でもありませんでした。自分で確かめたかどうかです。

分かりやすい失敗があります。

読了の判定が正しく動いているかを、ブラウザを自動で動かして確かめました。記事を最後までスクロールさせても、読了として記録されない。「不具合がある」と結論を出しかけました。

念のためスクロールのイベント回数を数えたら、0回でした。自動で動かしているタブでは、そもそもイベントが発生していません。不具合が無くても同じ結果になります。

この一件は強く残りました。自分で数えて、自分で結論を取り下げたからです。

残す作業を、意識的にやっている

放っておくと残らないので、2つだけ決めています。

1つめは、コードに「なぜ」を書くこと。処理の説明ではなく、その選択をした理由と、選ばなかった案を書きます。書こうとすると、自分が理由を説明できるかが分かります。書けないときは、分かっていません。

2つめは、記事にすること。このサイトの記事は、ほぼ全部が詰まった話です。人に読める形にするには、何が起きて、なぜそうしたかを順に並べる必要があります。並べられない部分が、理解の穴です。

どちらも、AIには代わりにやってもらえません。説明できるかどうかを確かめているのは自分の理解なので、代わりに書いてもらった時点で意味が無くなります。

向き不向きはある

全部が同じようにうまくいったわけではありません。

手を動かして覚えるもの——たとえば攻撃の手順を実際に試すような学び方は、読んだだけでは半分しか入りませんでした。体で覚える部分は、代わりにやってもらうと何も残りません。

逆に、調べれば分かることを大量に集めてくる作業は、任せたほうが早い。分ける基準は「自分の判断が要るかどうか」でした。

今回の学び

まず、手順は残らないが、判断は残るということ。覚えているのは全部、2つの案を比べて片方を捨てた場所でした。捨てた理由が基準として残っています。

次に、確かめる手段を持っていないと、間違いも同じ速さで進むこと。早く答えが出ること自体は良いのですが、確かめずに進むと戻る距離が伸びます。速さの価値は、確かめ方とセットでした。

そして、残す作業だけは自分でやる必要があること。理由を書く、記事にする。どちらも「説明できるか」を試す作業なので、代わりにやってもらうと試すもの自体が無くなります。

手が止まっている時間の中身を振り返ると、書き方が分からない時間はそれほど長くありませんでした。

長かったのは、どこを調べればいいか決まらない時間のほうです。

3つのどれかは分かるのに、どれかが分からない

製品のベースがRailsの会社にいました。仕事は管理画面やフロントの改修です。

コードは目の前にあって、動いてもいます。それなのに読めない。理由を探していくと、こういう詰まり方でした。

目の前の1行が、Railsが用意した仕組みなのか、Rubyの文法なのか、製品独自の実装なのかが区別できない。

3つのどれかであることは分かります。どれなのかが分からない。結果として、調べ始める場所が決まりませんでした。

「読めない」では、対処が決まらない

この状態を「経験が足りない」で片付けていたうちは、何をすればいいか分かりませんでした。

分解して「言語かフレームワークかの区別がつかない」まで持っていくと、読むべき本は1冊に決まります。フレームワークの本ではなく、言語そのものの本です。

読んだあと、知識の量よりも先に変わったのは手が止まる回数でした。「ここは言語の書き方だ」と分かると、調べ先が決まるからです。

いまも、同じ構造で出てくる

これは過去の話ではなくて、今も形を変えて出てきます。

最近だと、記事を投稿しようとしてサーバーに弾かれました。403が返るだけで理由は出ません。ここで手が止まる理由は、Railsのときとまったく同じです。原因がどこにあるか分からないので、調べ始める場所が決まらない。

このときやったのは、本文を半分に割って試すことでした。知識を足したのではなく、「どこ」を絞り込んだだけです。2回割ったら、引っかかっている行が分かりました。

片方は知識で解決し、もう片方は手順で解決しました。共通していたのは、詰まりを「どこ」の問題に置き換えたことです。

教えていて気づいたこと

プログラミングを教えていると、同じ止まり方をよく見ます。

「動きません」と言われて画面を見ると、エラーは出ています。読めば書いてある。ただ、そのエラーが自分の書いた行の話なのか、道具の設定の話なのかが分からない状態です。

このとき答えを教えると、その場は進みます。ただ次に同じ形で止まります。渡すべきだったのは答えではなく、「いまのは3つのうちどれだと思うか」という問いのほうでした。

今回の学び

まず、いちばん時間を食うのは、探す時間ではなく探す場所を決められない時間だということ。答えを見つけるのは、場所さえ決まればそれほどかかりません。

次に、分解は「対処が1つに決まる」ところまでやること。「分からない」のままでは動けませんが、細かくしすぎても意味がありません。やることが決まった時点が止め時でした。

そして、同じ詰まり方は、分野を変えて何度も出てくること。言語とフレームワークの区別も、403の原因の特定も、困っている形は同じでした。1回分解できると、次はそれが型として使えます。