はじめに

私は某メガベンチャーで EM（エンジニアリングマネージャ）をしています

ある日、メンバーとの 1on1 で次のような場面がありました。

メンバー「 XXX ってどう学んだの？」
私「経験で学んだ！」

「経験で学んだ」のは間違いではないですが、メンバーにとって必ずしも 再現性があるものではない と振り返って自省しています。その理由は 2 つです。

同様の経験の機会を提供できる保証がない
仮に同様の経験をできたとして、同じように学べるとは限らない

前者は仕方のないことだと言えます。
会社として事業・利益を主目的としているため、メンバーの育成を目的とした経験の機会の提供は優先度が低くなりがちなためです。

後者はどうでしょう。
同様の経験をできたとき、その経験から学ぶことは人それぞれだと思います。より良く学ぶかもしれないし、そうじゃないかもしれないです。が、「学びを最大化する」方法はあると思います。

本記事では、私の周りの優秀なエンジニア・ビジネスパーソンに共通していると感じる 学びを最大化する方法を 3 つ紹介 します

仮説と検証を繰返す
説明可能にする
オーナーシップを持つ

1. 仮説と検証を繰返す

「世界一流エンジニアの思考法」という書籍にて、著者がマイクロソフト在籍時に出会ったポールという賢いエンジニアのエピソードが紹介されています。

ある日、私のプログラムが上手く動かないときがあった。もちろんこれを自力で直しても良いのだが、今までの経験からすると、原因究明に何時間、もしくは何日かかかるだろう。
ポールだったらどういうふうに思考するのだろうと思って、「ペアプログラミング」をお願いすることにした。

彼は最初の一つのログだけを見て「仮説」を立て始めた。手は一切動かさない。

「このログが出ているということは、自分の推測では、内部でこういうことが起こっている可能性が非常に高い。そこを鑑みると、調べるべきは……」とぶつぶつと独り言をいいながら、データベースを閲覧するソフトを起動し、クエリ（システムへの命令文）を一つだけ書いてこう言った。
「ここだろう」
なんとそのクエリの結果は、私のプログラムの問題の根本原因をズバリ指し示すものだった。

「障害を調査するとき、いきなり手を動かして、試行錯誤していろいろクエリを投げてはダメなんだ。ログを見て、自分で多分こういうことが起こっていると推測して、その推測に合ったクエリを投げてそれを証明するんだよ」
まずは、事実（データ）を一つ見つける→いくつかの仮説を立てる→その仮説を証明するための行動を取る。

世界一流エンジニアの思考法牛尾剛著より一部中略のうえ引用

本書内では「生産性の高いエンジニア」という文脈で語られていますが、私は 賢いエンジニアは仮説と検証を繰返している のだと逆説的に捉えました

「内部でこういうことが起こっている」という仮説を立てなくても、「障害原因」は学べたでしょう。しかし、仮説を立てることで「内部でこういうことが起こっているから障害原因になる」と 仮説を証明する試行 を重ねることもできています。

仮説と検証ができるのは、なにもデバッグ作業に限った話ではありません。調べても分からないことを人に尋ねる場面をイメージしてみます。

仮説を立てない場合

「 XXX って、何ですか？」
「 ◯◯◯ です」

（知っている事実から）仮説を立てる場合

「 XXX って、YYY から ◯◯◯ だと考えているんですが合ってますか？」
「合ってます」

このように仮説を立てる場合には、「 ◯◯◯ 」という答えに加え、「 YYY から ◯◯◯ 」だと考えた 仮説を証明する試行 を重ねることができています。

重要なのは、この試行の積み重ねにより 仮説を答えに近似させていく ことができるという点です。
言い換えると、勘所を磨く ことができます

2. 説明可能にする

自分がやったことに対し、そうやった理由 を説明できる状態にするということです

例えば、「ユーザーID」を下記のように実装した場面をイメージしてください。

type UserId int64

func NewUserId(value int64) UserId {
	return UserId(value)
}

func main() {
	ui := UserId(1)
	fmt.Print(ui) // 1
}

「なぜ、単純に下記のように実装せず、値オブジェクトを実装したの？」と質問されたらどう答えますか。

func main() {
	ui := int64(1)
	fmt.Print(ui) // 1
}

そうやった理由の具体レベル順に想定される答えを書いてみます。

レベル0「なんとなく」
レベル1「ほかの実装がそうなっていたので」
レベル2「ドメイン駆動の観点で値オブジェクトにすべきと思ったので」
レベル3「ドメイン駆動の観点で値オブジェクトにすることで、オブジェクトの関心ごとを隠蔽でき、再利用性が上がり、その結果保守性が上がるのでシステムとしてより早く価値提供できるようになるので」

レベル0、1 は、そうやった理由を説明できている状態とは言えません。
レベル2、3 は、そうやった理由を説明できている状態と言えます。¹

説明可能にすることは、本質を理解する ことに他なりません。

「本質を理解しろ」とよく言われますが、どうしたらいいのか分からないことが多いはずです。（私はそうでした。）
そのような場合、まずは自分がやったことに対し、そうやった理由を説明できる状態にすることがいい手引きになると思います。そして、説明可能にするため、とにかく 「なぜ」を繰返し自問する とよいでしょう

3. オーナーシップを持つ

そーだいさんの資料「仕事を前に進めるためのコツ」が、表題通り仕事をより前に進めるためのコツをうまく言語化されていると、一時 X で話題になりました。（ご覧になったことがない方はご一読されるとよいと思います。）
その資料のまとめに下記が書かれています。

仕事を終わらせるために必要なのは
自分がやるんだというオーナーシップ

仕事を前に進めるためのコツより引用

オーナーシップは、自分ごとにすること・当事者意識・自責とも捉えられるマインドセットです 🧠
オーナーシップを持った行動には以下のようなものがあります。

チーム内外からの問い合わせに率先して調査および回答する
プロダクトグロースのため必要があると感じユーザーヒアリングを実施する
技術的な意思決定をする

仕事を終わらせるために必要なオーナーシップは、学びを最大化する意味でも重要です。

なぜなら、オーナーシップを持っている方が 得られる経験の機会が多く、説明可能にする ことが自然発生的に求められるからです。即ち、オーナーシップは「仮説と検証」および「説明可能にする」チャンスを得るための土台になるからです

まとめ

本記事では、私の周りの優秀なエンジニア・ビジネスパーソンに共通していると感じる学びを最大化する方法を 3 つ紹介しました。

仮説と検証を繰返す
説明可能にする
オーナーシップを持つ

少しでも皆さんの学びに生かされると幸いです。

レベル2 はコンテキストによってはそうやった理由を説明できている状態とは言えないかもしれません。値オブジェクトがコードベース上初めての実装だったり、値オブジェクトの考え方が根付いていなかったりする場合です。コンテキストに応じ、そうやった理由の具体レベルは調整が必要です。 ↩