@ledsun blog

Hのキーがhellで、Sのキーがslaveだ、と彼は思った。そしてYのキーがyouだ。

builderscon tokyo 2018 で得たもの #builderscon

一ヶ月前の話ですが、やはり印象深かったので書きます。

植山類さんのセッション

大変良かったです。 僕は類マニアなので、以上に高いテンションになっている可能性があります。 その辺は差っ引いて読んでください。 新しい知見が得られたというか、目の前で人間が喋っているのが聞けたのが良かったです。

主な内容は以前のブログ記事と大体同じです。 note.mu

動画も公開されているようです。 builderscon.io

ハートが撃ち抜かれた

特に印象的だったのは「カーゴ・カルト・プログラミングを徹底的に避ける」話です。 勝手な想像ですが、カーゴ・カルト・プログラミングを避けた結果、ソースコードを理解していない部分がなくなり、アドバイスをくれる誰よりも自分がソースコードを理解している自信になり、定石破りが(自分のシチュエーションでは定石が有効でないことを喝破)できたのではないかと思います。

それでlldの性能と開発効率が上がって、多くのOSSプロダクトに採用されるようになった実績を、目の前の人間が喋っていることがすごいです。 ハートが撃ち抜かれた。

Turing Complete FMで何度も聞いている声ですが、実際に喋っているのをみると、最初から天才プログラマだったわけじゃなく、本人の努力で今があるのがわかって良いです。ブログ記事には上手く行った話を書くことが多いので、ブログだけ読んでいると「超天才か!」と思うのですが、「人間、天才みたいな属性だけで雑に説明できるわけねえよ」が実感できて良いです。

カーゴ・カルト・プログラミングを避ける

それで、感銘を受けて、「遅い処理を非同期化する」タスクに取り組んでいる時に、

  1. 「遅いのはわかるけど、どこが遅いか計測すべき」と計測し、データ作成でなく、データ送信に時間が時間がかかっていることを確認
  2. データ送信の振る舞いをみるとデータの送信量に依存せずに遅くなることがあるので、厳密にはデータ送信ではなく、コネクション確立に時間がかかっている
  3. ソースコードにコネクションを使い回す修正を入れて計測してみる
  4. 既存のソースコードには修正を邪魔する、不要な抽象が挟まっている。自分で書いたし、書いたときは良かれと思って書いています。まずは、この抽象をはずす

それから「コネクションを使い回す実装をいれ、それで再度計測して効果があるか確認する必要があるな」と、のたうち回っているところです。

当初は「非同期化するだけなら、スレッドかActiveJobを使えばいいだけ」と軽く見ていたタスクでした。それでも、「カーゴ・カルト・プログラミングを避ける」気持ちで見ると、既存の実装の良くない点(コネクションを使い捨てている)と、設計の良くない点(不要な抽象がある)が、見つかり新たな知見が得られます。

まだ調査中なので、本当にこの方針で実装するのが正しいのかはわかりません。例えば、送信先に依存しているかもしれない。そうならば送信先を制限した方がいいかもしれません。それでも、この調査で得られた知見はより正しい判断につながるでしょう。すくなくとも、不要な抽象(本当に何の役にもたってなさそう)が見つかったのは、この先ソースコードに技術的負債を抱えて進んでいくより良いでしょう。この辺は、時間的プレッシャーに負けそうな自分に言い聞かせている理由付けです。

そういうお気持ちでプログラミングを進めていきたい。

メンバーの教育を(有期の)プロジェクトリーダーの責務に入れてはいけない

t.co

を読んで考えた話です。

30歳近くになっても無能、ということは、そいつはほとんどの場合、一生無能だ

と刺激的な言葉が使われています。 状況を限定すれば、一理あると感じる点があります。 表題の「メンバーの教育を(有期の)プロジェクトリーダーの責務に入れてはいけない」です。

結論

プロジェクトリーダーの最大の責務はプロジェクトを成功です。 メンバーの教育は、プロジェクト成功の阻害要因になっているときだけやります。

無能なやつには、意見を聞いても、ろくな話は出てこない。時間がもったいない

の例では、「意見を聞かない」という簡単な回避策があります。 回避策があるときは、教育の手間を掛けてはいけません。

そうは言っても、一緒に仕事する仲間はできるだけ賢くあって欲しい、自分の足を引っ張らないで欲しいと思うのが人間です。

教育は誰がやればいいのか?

ティーチングとコーチン

メンバーの教育は上司(ライン上の上司)がやります。 ここで、教育を大きく2つにわけます。 ティーチングとコーチングです。

プロジェクトに直結したティーチングはプロジェクトリーダーの責務です。 例えば「gitの操作に不慣れなメンバーに、gitの使い方を教える」(または教える人を割り当てる)のはプロジェクトリーダーの仕事です。

コーチングでは、本人に思考を促し、失敗に対して工夫し、何度か失敗を繰り返すのを見守り、成功まで導きます。 要はPDCAサイクルを回すサポートをします。 これは上司の責務です。

コーチの責務

コーチングの目的は、未知の問題にぶつかった時に、自ら工夫してチャレンジしていく能力と自信を身に着けさせることです。 本人が試行錯誤して成功にたどり着く必要があります。 時間が必要です。 またコーチ役は「教えちゃえば簡単なのに」を我慢する必要があります。

一人の人間が同時に、プロジェクトの成功を急ぐのと、メンバーの成長を待つのをやるのは無理です。 人を分けましょう。 プロジェクトリーダーが安心して、教育を手放せるように、他に教育を責務とする人を用意しましょう*1

*1:コーチングを上司の責務にして、プロジェクトリーダーの責務から引き剥がすのが、組織を作る人(CTO、VP of Engineering、人事部門)の責務です。