不合格の振り返り
今回の記事では、不合格についての話をしてみたい。同じ失敗を経験した人や、面接で話が長くなってしまうエンジニアなら、筆者が原因をどこまでたどり、何を変えることにしたのかを参考にできるはずだ。うまくいった点よりも、失敗した点を先に、そしてより長く書く。
最近、筆者がとても大切にしていた二つの選考が終わった。結果はどちらも不合格だった。悔しい気持ちは大きいが、その中で失敗したことと学んだことがはっきりあるので、記憶が薄れる前に書き留めておこうと思う。
長くなる回答
最初に目についた失敗は話し方だった。会話の中で自分の意見をはっきり伝えることが、思っていたより難しかった。たとえば、履歴書に書いた作業の一つについて、こんな質問を受けたとしよう。
「どのような理由でこの改善を進めたのですか？」
この質問に答えるには、まずその作業をなぜ行い、どう改善したのかを頭の中で一つの話としてまとめる。ここまでは難しくない。問題はその次だ。
質問は理由（Why）と方法（How）を尋ねている。だから「こういう理由で、このように改善しました」と結論から答えればよい。説明が足りないように思えるなら、選択肢は二つだ。その結論を支える根拠をもう一つ付け加えるか、相手が気になる部分を追加の質問で聞いてもらうかである。
筆者はこの二つ目の段階で崩れた。どんな作業も一、二行では終わらない。解決方法がいくつもあり、トレードオフを比べるうちに間違った直し方をしたこともあり、その末に結果が出た。そのすべてを短い質問一つに詰め込もうとしたせいで、回答はいつの間にか筆者一人の演説になっていた。聞く側はおそらく「で、結局何が言いたいんだろう」と思っていただろう。
人としては、答えはもう分かっている。初対面の場で筆者が惹かれるのは、自分の話を一人で並べ立てる人ではない。質問に答えながら、表情や態度まで含めて筆者に集中していると感じさせてくれる人だ。ところが、エンジニアとして自分の作業を説明する場に立つと、それがうまくできなかった。
説明する材料の不足
回答が長くなった理由をさらにたどってみると、話し方の形式だけの問題ではなかった。説明する材料が頭の中にしっかり残っていなかったのだ。筆者の場合、こんなときに回答がぶれた。
- 昔の作業で記憶が曖昧なのに、それをアピールしようとするとき
- 多くの人の助けで断片が組み合わさった成果物を説明しようとするとき
- 自分の問題解決のプロセスを技術的に語る視点が足りないとき
履歴書や職務経歴書は、一人の人間の長い時間を要約した文書であり、項目の一つひとつに語るべき話がたくさんある。だからその中に、自信を持って説明できない項目があってはならない。協業が基本の職種で、完全に一人でやった作業はまれだ。それなら、自分が担当した範囲と助けてもらった範囲を文書の段階から明確に分け、話すときもその境界を守らなければならない。
材料が足りなくなったのには、最近の仕事の進め方も一役買っていたと思う。以前は、一つの問題を解くのに何度も空振りをした。翻訳機を使い、検索し、他の人の文章を読みながら、さまざまな視点を頭の中と文章で整理していった。今は「やって」と言えば、AIが判断から結果まで勝手に出してくれる。
では、筆者はその途中のプロセスを開いて、一つずつ区切って読んだだろうか。そうではなかった。成果と結果が大事だったので、プロセスは要点だけをざっと見るか、結果だけを持ってきた。そうやって流したプロセスは、面接で取り出せる材料としては残らなかった。
AIがここまで発展したのだから、そんなプロセスはもう必要ない、その時間でもっと成果を出せと言う人もいるだろう。筆者はそうは思わない。これからも筆者は、自分自身がたどってきたプロセスと結果をもとに、さまざまな選択をしなければならない。プロセスなしに積み上げた成果は、数字は大きくなっても中身のない殻かもしれない。より多くをこなし、より多くを見せようとしてプロセスを削った時間が、結局は筆者に不利に返ってきた。今回の不合格でそれに気づいた。
だから変えることはこうだ。AIが出した結果を受け取る前に、プロセスを最後まで読む。問題を自分の言葉で整理し直し、その解釈が正しいかを自分で確かめる。この検証を経た作業であってこそ技術的な議論ができ、面接でも結論から話した一文の後ろに、それを支える根拠が生まれる。
測ってみた集中力
プロセスを最後まで読めなかったのには、もっと深い理由があった。集中力だ。今回の失敗を振り返って、最も強く感じたのがこれだ。
どれほど深刻なのかを知りたくて、何でもない週末にポモドーロをやってみた。40分の作業と5分の休憩を1サイクルとして、六回回した。測定を意識しないように画面を録画しておき、後で見返した。
結果はこうだった。作業時間中、意図とは関係なくメッセンジャー、ウェブサイト、スマートフォンに気を取られたのが16回だった。40分ごとに二、三回ずつ脇道にそれた計算になる。休憩は、決められた5分を超えた時間だけを合計して7分41秒だった。休むたびに1分ちょっとずつ多く休んだわけだ。
数字を見てから、普段感じていたことが重なって見えた。誰かと話している途中で論点を見失い、移動中はショート動画や音楽を休みなくスキップし続ける。筆者は、AIに多くの仕事を任せるうちに集中力が崩れたのではないかと疑っている。AIを使う前と比べて測ったことはないので、確かめた事実ではない。ただ、結果を待ち、ざっと目を通し、次のリクエストを送るという短いリズムに慣れてしまったのは確かだ。
集中力が低いので、複数のエージェントを走らせても、その成果物をきちんと読むのが難しかった。すぐに疲れ、判断が鈍った。会話でも、相手に集中するより自分の考えの中にとどまっていた。前に書いた長くなる回答も、ここから遠くないと思う。
Jin Yong-jinのチャンネルで、公務員試験の受験生の集中力を扱った動画を見たことがある。記憶に残っている内容はこうだ。人は自分の集中力を実際より高く見積もっていて、だから最初から一時間を超える目標を立て、守れずに諦めてしまうというのだ。
筆者の周りには、同じ時期に始めたのに技術的な理解がより深い人たちがいる。もっと賢くて誠実で、勉強しやすい条件がより整っているのかもしれない。それでも筆者から見て、最も大きな違いは集中と没入だ。
だから、大げさな計画の代わりに、短い集中を成功させるところから始めようと思う。エージェントを複数走らせるとしても、一時間には一つのことだけを見る。そして同じ方法でもう一度測り、16回と7分41秒が減るかを確かめる。
守り抜いたもの
失敗ばかりだったわけではない。少しはうまくいったことも書いておく。
退勤後の勉強習慣
仕事帰りに勉強するのは、やはりつらい。平日も週末も関係なく、勉強が自然な習慣になるまでは、なおさらだ。
一か月半のあいだ、勉強を何よりも優先した。飲み会や約束を減らし、毎日SparkPlusのラウンジに行って勉強した。誘惑は多かったが、ほとんどは振り切った。疲れにくくするために炭水化物を減らしたら体重が落ちて体調が良くなり、サプリメントを欠かさず飲む習慣もできた。
前で集中力が崩れたと書いたので、おかしく聞こえるかもしれない。筆者から見ると、席に座る習慣は作れたが、座った時間を余すところなく使う力はまだ足りなかったのだ。次に直すべきはその部分だ。
他人のコードに問う「なぜ」
以前は、他の人のコードを見ても特に感じるものがなかった。レビューも、たいていは理解できないロジックについて質問するところで終わっていた。コンベンションに合っていなかったり改善できる箇所が見えたりしても、軽く伝える程度だった。
今年は、コードを書くうえで自分なりの基準を持とうという目標を立て、さまざまな視点の文章を読んだ。その中で、技術的な根拠に基づいて判断する論理ができ、他人のコードを見るときに疑問を持てるようになった。
まだその視線は、筆者自身の作業には十分に届いていない。前に書いた失敗がまさにその部分だ。問題を見ても素通りせず、プロセスごとに「なぜ」を問いながら理解する習慣を、自分の作業にも当てはめていこうと思う。
一緒に勉強する人たち
今回勉強しながら、良い人がたくさんいることを知った。筆者が参加している勉強会の人たちは、自分の時間を割いて勉強し、そのエネルギーを分けてくれる。筆者が見落とした部分を積極的に指摘し、関心を向けてくれる。一緒に時間を過ごすたびに学ぶことが多い。
改めて準備しながら
振り返ると、今回の不合格は一つの流れだった。集中力が落ちたからプロセスを最後まで追えず、プロセスを飛ばしたから説明する材料が薄くなり、材料が薄いから回答が長くなった。だから改めて準備することも、その順番を逆にたどる。まず短い集中を取り戻し、AIが出した結果のプロセスを自分で確かめ、そうして積み上げた材料で結論から話す練習をする。
もし似たような場で話が長くなった経験があるなら、話し方を直す前に、その作業のプロセスを今どれだけ説明できるかをまず確かめてみてほしい。筆者にとっては、そこからが本当の原因だった。