はじめに
ITの現場で、次の質問を聞いたことはないでしょうか。
「どう書けばいいですか？」
最初は普通の質問に見えます。
しかし同じ人から、同じタイプの質問が何度も繰り返されることがあります。
どう書けばいいですか？
↓
教えてもらう
↓
理解していない
↓
また同じ質問
この状態になると、次のことが起きます。
- 同じ質問が繰り返される
- 技術議論が成立しない
- ベテランがすべて判断する
そしてチームには、静かに次の構造が生まれます。
考える人
↓
答える人
↓
聞く人
本記事では、この
「教えて君エンジニア」
という現象を、個人ではなく構造として整理してみます。
教えて君エンジニアの進化図
現場でよく起きる成長の分岐を図にすると、次のようになります。
ここで重要なのは
どちらも最初は同じ地点から始まることです。
わからない
違いが生まれるのは、その次です。
エンジニアの成長が止まる瞬間
多くのエンジニアは、次のループで成長します。
しかし、ある瞬間から
別のループに入ることがあります。
ここで一つの現象が起きます。
「どう書けばいいですか？」が増えたとき、
そのチームでは技術ではなく“答え”が共有されています。
エンジニアのタイプ分類（1枚図）
現場のエンジニアを観察すると、
行動パターンはだいたい次の3種類に分かれます。
特徴を整理すると次の通りです。
| タイプ | 特徴 |
|---|---|
| 設計できるエンジニア | 仕組みを理解する |
| 作業エンジニア | 答えを覚える |
| トラブル要因 | 問題を放置する |
重要なのは、
最初の地点は全員同じということです。
わからない
違いを生むのは、
わからないときに
何をするか
です。
なぜこの状態が生まれるのか
この問題は、個人の問題に見えます。
しかし多くの場合、開発現場の構造が影響しています。
つまり現場によっては
理論より納期
という文化が生まれます。
その結果
理解する
より
答えを知る
という行動が合理的になります。
現実的な対処
経験上、比較的うまくいく方法があります。
答えではなく「入口」を渡す
悪い例
このSQLを書けばいい
良い例
トランザクションの分離レベルを調べてみてください
冪等性という概念があります
つまり
答え
ではなく
考える入口
を渡します。
設計レビューを技術議論の場にする
レビューを
バグ探し
ではなく
設計議論
にします。
例えば次の質問です。
この処理は冪等性を考えていますか？
並列実行された場合どうなりますか？
障害時のリトライはどうなりますか？
こうするとレビューが 技術共有の場になります。
構造ポエム
多くのエンジニアは
最初から理論を理解しているわけではありません。
誰でも最初は
わからない
から始まります。
問題は、その次です。
わからない
↓
調べる
↓
理解する
↓
応用する
このループを回す人は
少しずつ成長していきます。
一方で、現場によっては
別のループが生まれます。
わからない
↓
人に聞く
↓
正解を知る
↓
理解しない
↓
またわからない
このループは
とても効率が良く見えます。
すぐに答えが手に入るからです。
しかし長い時間が経つと
少しずつ差が生まれます。
理解するエンジニア
↓
応用できる
↓
設計できる
答えだけ知るエンジニア
↓
応用できない
↓
また聞く
そしてチームには
次の構造が生まれます。
考える人
↓
答える人
↓
聞く人
この構造が固定されると
技術は共有されなくなります。
だからこそ重要なのは
答えを教えること
ではなく
考える入口を渡すこと
なのかもしれません。
最後に
エンジニアの成長を止めるのは、
知識不足ではなく、
「答えだけを求める習慣」なのかもしれません。