テックリードの本業は、コードを書くことではなかった

2021年から半年ほど、社内連絡網をSaaSとして提供するWEBサービスの開発に参加した。

サーバレスとSPA、Ionicによるアプリ提供。

AWSのAmplifyを使ったサーバレス構成が、要求仕様の前提になっている案件だった。

体制は7名。

私の役割は、基本設計と実装方法の検討、サンプルプログラムの作成。

そして、もう一つ。

各メンバーへのレクチャーである。

AmplifyやLambdaの使い方を、チームのメンバーに教えて回る。

当時、Amplifyはまだ、触ったことのある人が少ない技術だった。

チームの誰も経験がない。

だから、誰かが先に理解して、みんなに配る必要がある。

その「誰か」が、私の仕事だった。

今日は、この「教える」という仕事の話をしたい。

「自分でやったほうが速い」の罠

新しい技術をチームに入れるとき、テックリードは必ずある誘惑に駆られる。

自分で書いたほうが、速い。

実際、速いのである。

メンバーに教えて、書いてもらって、レビューして、直してもらう。

この一周の時間で、自分なら3回書ける。

短期的には、教えるのは常に損なのだ。

でも、この誘惑に負けると、どうなるか。

私がボトルネックになる。

7人のチームなのに、難しいところが全部私に集まってくる。

私が倒れたら、止まる。

私が抜けたら、誰も保守できない。

チームの生産性は、7人分ではなく、1人分+アルファに縮んでしまう。

テックリードの成果は、自分が書いたコードの量ではない。

チーム全体が出せるようになった速度である。

頭では分かっていても、納期が迫ると忘れそうになる。

この案件では、役割として「レクチャー」が明示されていたのが、むしろありがたかった。

教えることが、サボりではなく仕事だと、最初から決まっていたからである。

教材は「最小の写経」がいい

半年間、教える側をやって、いくつかコツのようなものがつかめた。

まず、完成品のサンプルは、教材として役に立たない。

私が最初に作った立派なサンプルは、メンバーに丸ごとコピーされ、中身を理解されないまま使われた。

動いてしまうから、読む必要がないのである。

効いたのは、写経できる最小のサンプルだった。

認証だけ。

データの読み書きだけ。

ファイルのアップロードだけ。

一つの関心事だけを含む、小さな部品に分ける。

メンバーはそれを自分の手で組み合わせる。

手を動かした分だけが、身につく。

もう一つ大事なのが、地雷処理である。

新しい技術には、必ずハマりどころがある。

ドキュメント通りに動かない箇所。

エラーメッセージが不親切な箇所。

私は先回りしてそこを踏んでおき、「ここで爆発するので、こう避ける」という地図を配った。

技術を教えるというのは、知識を配ることというより、地雷の位置を配ることなのだと思う。

メンバーが止まる本当の理由

教える仕事をしていて、一番大きな発見はこれだった。

新しい技術の前でメンバーが止まるのは、知識が足りないからではない。

壊すのが怖いからである。

特にクラウドは、この恐怖が強い。

変な設定をしたら、請求が爆発するのではないか。

本番環境を壊してしまうのではないか。

怖いから、触らない。

触らないから、覚えない。

だから私がやったのは、知識の伝達よりも、恐怖の除去だった。

壊してもいい検証環境を、一人ずつに用意する。

「ここは何をやっても大丈夫」と宣言する。

実際に壊れたら、直し方を一緒にやってみせる。

安全に失敗できる場所ができた途端、メンバーの手は驚くほど動き始めた。

教育とは、勇気の供給なのである。

AIは先生になった。では私は失業か

さて、この話には現代的な続きがある。

いまや、技術の質問はAIにすれば、たいてい答えが返ってくる。

Amplifyの使い方も、Lambdaのハマりどころも、深夜だろうと聞き放題である。

あの半年間の私のレクチャーは、いまならAIで置き換えられるのだろうか。

半分は、置き換えられると思う。

知識の伝達の部分は、もうAIのほうがうまい。

私より根気強く、私より網羅的で、何度聞いても嫌な顔をしない。

でも、残りの半分は残る。

AIは、聞かれたことには答えるが、何を聞くべきかは教えてくれない。

このプロジェクトでは、どのやり方を選ぶべきか。

どこが地雷で、どこは安全か。

そして、「壊しても大丈夫」と言ってやること。

失敗したメンバーと一緒に直して、恐怖を勇気に変えること。

知識はAIから引き出せる時代になったからこそ、教える仕事の中身は、純粋に人間的な部分——判断の共有と、勇気の供給に蒸留されていくのだと思う。

一番長持ちする成果物

あの案件で私が書いたサンプルコードは、とっくに役目を終えているだろう。

Amplifyの仕様も、あれから何度も変わった。

でも、あのとき「サーバレスは怖くない」と体で覚えたメンバーたちは、その後もどこかで、新しい技術に手を出し続けているはずである。

コードの寿命は、せいぜい数年。

「新しいものを怖がらない」という感覚の寿命は、たぶんエンジニア人生と同じだけある。

教えるという仕事の成果物は、相手の中に残る。

30年やってきて、自分の書いたコードより長持ちしている成果物は、結局それだけかもしれない。