こんにちは、eiyuuです。最近、プロジェクト内の作業や研修などで後輩に技術的な何かを教えるという機会が増えてきました。本記事では、その際に意識しているいくつかの心がけを書いていきたいと思います。今までは漠然と脳内で考えているばかりでしたが、今回初めて文章にするにあたってこの心がけに名前を付けることにしました。技術者の心がけというと色々なものが該当しますが、その中でも個人的にお世話になっている The Zen of Python に因んで The Zen of Mentoring と名付けました。今後もっと洗練していって、立派な Zen（禅） を目指したいと思います。

概要

大まかに言うと、以下3つのことを意識しています。この後の各項目で、それぞれについて詳しく解説していきます。

• 知識の3レイヤを意識する・させる
• 論拠を示す
• 不安を減らす

知識の3レイヤとは知識の分類に関して僕が個人的に呼称し、使っている言葉です。もし内容を見て気に入っていただけたら、ぜひ使ってあげてください。また、これらを意識することで到達できるであろう漠然としたゴールも常に考えています。そのことについても、記事の最後に解説します。

知識の3レイヤを意識する・させる

例えば何かのツールについて知る（教える）とき、そのツールに関する知識は以下の3レイヤに分けられる。

1. そのツールが属するカテゴリーの利点
2. そのツールが属するカテゴリー内での、他のツールと比較したそのツールの利点、逆に、他のツールの方が優れている点
3. そのツールの使い方

よく使われるのはレイヤ3だが、設計段階やベストプラクティスの検討の際にはレイヤ1やレイヤ2の知識が必要になる。情報ソースごとに得られる知識のレイヤが偏りがちなため、意識しないとどれかのレイヤに知識が偏ってしまい、十分な理解に繋がらない。大体3に偏る。

具体的な例え

Terraformというツールについて考える。TerraformはIaCツールであるため、レイヤ1は「IaCツールの利点」となる。IaCツールには他にも、AWS CloudFormationや、Ansibleなどがある。これらと比較したTerraformの利点と、AWS CloudFormationやAnsibleなどの方が優れている点がレイヤ2となる。そして、Terraformの.tfファイルの文法や実行方法、また、.tfstateファイルをS3で管理する方法などが、レイヤ3となる。

情報ソースと知識レイヤの関係

レイヤ1

まずそのツールが属するカテゴリーが何なのかを知る必要があるが、これは大体公式ページのトップやドキュメントの一番最初に書いてある。 "What is <ツール名>?" みたいな項があって、そこに書いてある。次に、そのカテゴリー名でググると、そのカテゴリー自体の利点に関する記事が出てくるのでそれを読む。

レイヤ2

レイヤ1でカテゴリーの記事を読んだときに、そのカテゴリーに属する他のツール名が列挙されている。記事内で比較されていることもしばしばあるので、そこを読む。"<ツール名> vs <競合ツール名>" でググると、比較記事が多くヒットするので、それらを読む。公式ページ内、特にドキュメントの序盤で、カテゴリー内でのそのツールの立ち位置について言及している場合がある。また、代表的な競合ツールに関しては公式ページ内で直接言及して比較していることもある。

レイヤ3

公式ページ内にもレイヤ3に関する解説はあるが、より具体的な例や実践的な例については、個人・企業の技術ブログや Qiita, Stack Overflow などの知識共有サービスが詳しいことも多い。

小まとめ

普段はエラーメッセージでググったり「あれってどうやるんだっけ？」を調べたりなど、レイヤ3の知識に触れる機会が多い。その一方で不足しがちなレイヤ1, 2の知識は公式ページを読むことで得られることが多い。初めから公式ページを全部読むのは（実体験が伴わないという意味で）少し難しいため、「最近このツールよく使うなあ」と感じたときに、公式ページにも目を通してみるよう指導するのがバランスが取れていると考えている。

論拠を示す

「同じアウトプットを得るために複数の手段が存在して、その中から最適な手段を選ぶ」というのは仕事の中でよくあることだが、教える側が常に論拠を持って教わる側に接することで、これを意識するきっかけになると考えている。

論拠の例

• 経験則
  • 個人
  • 格言
    • DRYとかそういうの
• 慣例 (convention)
• ルール
  • ローカル
    • 自社
    • プロジェクト
  • グローバル
    • RFC
    • ISO
    • サービス / フレームワーク / ツール
• 物理法則 (4割冗談)

所感

• 経験則にはそう感じるだけの合理性や解釈が存在する。経験則を論拠とする場合、それらも併せて示す。わからない場合、論拠として採用しない。
• 慣例には慣例になるだけの理由が存在する。慣例を論拠とする場合、その理由も併せて示す。わからない場合、論拠として採用しない。
• ルールが生まれる原因は多岐にわたり、技術的視点ではない場合もある。そのようなルールを採用する場合、「もしそれを採用しない場合」の技術的視点のみの立場も同時に伝えておくのが良い。「技術的にやれない」ではなく「技術的にやれるけどやらない」という立場を守らせる。
• 技術的な合理性のあるルールもある。これを論拠とする場合、その合理性も併せて示す。わからない場合、調べる。
• 構造を持つ文字列（URL / 変数名 / 関数名 / ファイル名）、フォルダ構造、データ構造などは慣例を論拠とすることがしばしばある。

小まとめ

適切な論拠の提示、そしてその論拠の合理性や背景に関する知識こそが、「教わる側」が「教える側」の技術的能力を評価する大きな指標になると考えている。教わる側が今後目指していく目標を大きく左右する、とも表現できる。また、経験則や慣例をその背景の理解無く濫用してはいけない。これらをいつ論拠として適用できるのかを教える側が意識し、教わる側に注意して説明する必要がある。

不安を減らす

よく言うところの、心理的安全性の確保に関連する心がけを挙げる。

言葉から感情を消す

• 言葉の裏を考えさせる時間、思考リソース、ストレスを省く。
• 技術者が技術と向き合うとき、言葉の裏を読まない技術が求められる。
  • ドキュメントを書いてあるとおりに読む / 仕様どおりに書く。
  • プログラムは思った通りには動かない。書いたとおりに動く。

所感

• 言葉の裏を読む技術も教える場合はそれ専用の時間を設けたほうが良い。
• ちくちく言葉から棘を抜くのもそうだし、良い感情も抜く。フラット。
• 技術者が普段考えていることをざっくばらんに綴った文章を「ポエム」と呼ぶことがあるが、これは言葉の裏を読むにあたっての良い教材になるかも知れない。うまく読み解ければ、そして良いポエムであれば、合理性を伴う経験則や、レイヤ1, 2の知識を得る機会にもなりうる。

教わる側への質問は回答範囲を絞る

• はい / いいえ で答えられる質問。
• 回答の選択肢をいくつか提示して、どれに近いかという質問。

それぞれの選択肢に対して、そう答えた場合何が起こるかを先に宣言しておくと、安心して答えられる。

NGワード

あなたはなぜ

• 優位に立ちたい感情、もしくは自分を理解して貰えないことへの不満が入っている。
• 回答範囲が広い。

小まとめ

こちらは「教わる側」から「教える側」への信頼を左右する。能力・信頼、両方揃わないと良い学びに繋がらない。

ゴール

良い質問をさせる。

• 知識の3レイヤを意識した良い疑問を抱ける（「良い質問を」の部分に対応）。
• 「こいつには質問する価値がある」と思われている（「させる」の部分に対応）。
  • 根拠ある回答が得られると思われている。
  • 弱みを見せる行為（質問する行為）に付け込んでこないと思われている。

まとめ

「良い質問をさせる」というゴールが最初にあって、そこにどう至るか？という問いから

• 知識の3レイヤを意識する・させる
• 論拠を示す
• 不安を減らす

ことが重要だろうと考えるようになりました。恐らくまだ気づけていない良い質問に至るための要素があって、それもまた The Zen of Mentoring の一要素になるのだと思います。