アウトプットの遅いエンジニアの仕事をちょっとだけ早くする
グループに投稿された話題に、
一人のエンジニアがずっとアレコレと仕様を悩んでいてコードをなかなか手をつけないのだがどうしたらいいか（要約）
というのがあった。コードに限らず資料作りでも同じようなエンジニアは見かけるし、逆に何も考えていないじゃないかと思うくらいに、いきなりスライドを書き始めて構成が支離滅裂になるエンジニアもよく見かけるのでどっちもどっちだな、と思う。
冒頭の仕様に悩んでなかなかコードを書かないエンジニアを観察している立場のリーダやコーチの立場で見れば、これはこれで焦れったいものだ。ついつい、自分ならこう進めてしまうのに、とコードを書くエンジニアを自分に置き換えて、自分がコードを書くならああすればいいとかこうすればいいとかと段取りを組み立て、それと比較をしてしまうからだ。
違う頭を持っていることを認識する
リーダやコーチ役こそ、悩んでいるエンジニアと自分が違う頭を持っていることを最初に気づかなければならない。
自分のやり方を押し付けてはいけない。やるのは悩んでいるエンジニアの仕事だからだ。それを奪ってしまってはいけない。奪われてしまったらそのエンジニアは自信をなくすだろうし、チームでの存在意義も失ってしまう。
リーダやコーチは、メンバのパフォーマンスを最大限に引き出すのも仕事の一つだ。
違う頭を持っていることを認識する行為は、悩んでいるエンジニアの存在を認めるということだ。
ここが解決のスタートポイントである。
世界観を教えてもらう
仕様で悩んでいるエンジニアは、多分、いや確実に、リーダやコーチより多くの不安を感じ取ってリーダやコーチ役よりより広い範囲でこれから書くコードの仕様についてどう決定すればいいかをあぐね居ているのだ。
それに比べ、リーダやコーチ役は仕様の界面をスパッと決めているはずだ。だから、次々と段取りが思いつくのだ。
だったら、悩んでいるエンジニアがどんな世界観で悩んでいるのかを教えてもらおう。
この際、リーダやコーチは聞き役に徹しなければならない。使っていい言葉は2つだ。
- なるほどねー
- こっちはどうなっているの
同意すること。関心を持っていること。この2つを示しながら聞けばいい。とにかく、頭で考えていることを図式化することだ。
界面を引かせる
次にすることは、悩んでいるエンジニアに仕様の界面を引かせることだ。言い換えれば、インタフェースを決めるわけだ。
書き出された図の中に悩んでいる仕様の範囲がどこまでが入るかをぐるっと線引させる。
もし、全部を線で囲ったとして、その図式が妥当な仕様だとすれば、デザインは頭の中でできていたということだ。ただ、具体化していないなかったから、頭の中で整理できずに決めきれていなかっただけだ。そうであれば、それでいいと背中を後押しすればいい。
線引が仕様の機能を超えていたら、別の機能仕様を引き合いに出してどちらが機能を実装したら良いか、アーキテクチャとして見直したらいい。実は悩んでいるエンジニアのアイデアの方が正しかった、ということもないではないのだから。
ちょっとだけ早くするには
悩み始めたら、ホワイトボードに描くことをチームのルールにしよう。全員でやるのだ。
利点は２つ。
１つは悩んでいるエンジニアの頭の中を図式で可視化し、それをリーダやコーチが気づける。
２つ目は、全員でやることで学習することができないエンジニアのアーキテクチャのデザインスキルを共有できることだ。ホワイトボードに描くことでそれが視界に入る他のエンジニアがなぜ、どうして、と思えればこれで十分なのである。
