わからん時に躊躇せず聞いて生産性爆上げする話
自分の会社には一緒に働いている人に、自分へのフィードバックをお願いすることが出来る。かなりの技術イケメンである John にフィードバックをお願いしたらこんなことが書いてあった
自分的には質問しているつもりだったが遠慮があった
どれぐらいのタイミングで質問に答えてくれるかは人によるけど、John は大抵ものすごく早く丁寧な回答をしてくれる。だから、本当に困ったときは彼に質問をよくしていたのだけど、彼からすると自分はまだ遠慮しているっぽい。
今までは、自分は、ある程度調べて考えたうえで、ブロックされた場合に人に聞くという行動様式をとっていた。でも、このやり方は、今から振り返るとあまりチームの生産性的には良くないようだ。私は日本人なので、なんだかんだいっても、人に安易に聴くのにある程度抵抗がまだあったのだろう。
巨大なコードベースを理解するには時間がかかる
しかし、よく考えてみると、私がやっているような巨大なシステムの場合、一人の頭だけで簡単に理解できるものではない。いろいろなマイクロサービスや複雑に絡み合っているものなので、それを全部知ってる人など存在しない。
自分が振り返ったときも、新しいコードベースに挑戦するときは、自分が変更や機能追加する、限られた範囲を理解するために平気で1週間以上使っていた。自分の知らなかったことを調べ、構造や振る舞いのメンタルモデルを作り、コンテキストを理解する。そんなことをしていると1週間なんてあっという間に過ぎてしまう。
レガシィシステムのメンタルモデルの形成
ところが、一旦そういったものが頭に入ると、すぐに対応できるようになる。つまり、一番大変なのは、頭の中に「メンタルモデル」を作る行為だ。これは、多分どんな人でもある程度時間がかかるのだろう。
John からそのフィードバックを受けてから、自分が未経験の部分に関してのコード変更の必要性が生じた。いつもだったら、ある程度リポジトリを自分なりに読んでみて、ドキュメントを探して、みたいなことをやるところだが、今回は、速攻でエキスパートに聞くことにした。「この部分をこのように変えたいんやけど、コードポインターとか、プルリクエストとかない?」
Pragna の 作業 Box
私は解答を待っている間、全く別のタスクを進めていた。それは、自分のマネージャの Pragna が先日いいことを言ってくれたから。
とアドバイスをくれた。つまり1つのことに2時間以上ブロックされたなら、質問するなり、相談するなりして、寝かせておいて、他の仕事をやっとく方が生産性が良い。
今までだったら、その解答を待っている間も、その作業の為にリポジトリやコード調査をしていたところだけど、エキスパートの助言が来るまでは自分でやっても無駄と考えて、他のことをやっていた。このアドバイスは本当に効率を改善してくれている。
技術イケメンのスマートな情報提供
数時間後に、エキスパートの Glenna が解答をくれた。過去の似た Pull Request を送ってくれただけではなく、この変更をする場合は、こういう場面に注意してというアドバイスまでくれた。
もし、これは自分でやっていたらどうだっただろう?そのコードにたどり着くまで多分相当かかっているし、その変更が適切に最初から出来たかわからない。もしかすると、Glenna がアドバイスした部分が見つけられていないかもしれない。
結局私は Pull Request とアドバイスがとても有効だったので、全く知らない部分だったが、2-3 時間で Pull Request を作ることが出来た。そして、ちゃんと理解しながらやっているので、それと同時に、この種の変更に対すく「メンタルモデル」が形成された。
エキスパートに速攻頼るはベストプラクティス
特に既存システムがある場合は、あれこれ考えて調べる前に、まず「エキスパートに頼る」というのは黄金のベストプラクティスと思う。
日本には、ググレカスという言葉があるぐらい、調べてから人に聞くという文化だけど、少なくとも私のやっているようなクラウドの中身を作るみたいな複雑なシステムの場合どう考えても全体的効率が悪い。
ググレカスは無駄
効率を上げるためにはいかに「無駄なこと」をしないかだと思う。エキスパートから情報がシェアされたらそこから理解するフェーズに入れば、無駄な労力が不要でフォーカスしてしっかり理解できる。
日本人的には、どんな時に、どの程度頼るのか?が気になるかもしれない。それは多分こんな感じだ。
どの程度頼ればよいのだろう?
自分にその分野の「メンタルモデル」や「コンテキスト」が無い場合、何は無くともエキスパートに Ping してよい。すぐに無理なら、最初にミーテングを設定する。そうでないと、解法をものすごく間違えるケースもあるので、それを嫌がる人は自分の職場ではいない。
どの程度聞くのが良いのかは、場合によるとしか言えないけど、一つの目安としては、相手が労力を要せず解答できるものは聞いたら良い。相手にものすごく工数がかかるものだったら自分がすべきだろうが、例えば、PRをシェアする、そのシステムのコンテキストや勘所を説明するとかだと、慣れてる人だと簡単だろう。だから、その部分に関しては自分が不明確なら聞いたらいい。ただ、人手がかかるものは、そういうことを聞いたうえで、基本自分がやったらいいだろう。
そうやって、最初にコンテキストをエキスパートからロードできると、かなり爆速で物事が出来るようになる。もちろん自分がその技術に慣れていない場合、別個で勉強の必要がある場合もあるだろうが、それでも、エキスパートにファーストコンタクトをとることは、無駄な勉強も減らすことにも役立つ。
チームが強くなるために聞ける文化を作っておく
このようにチーム全体が強くなるためには、こうやって聞けるような文化が多分大切なのだと思った。だから、自分側も、聞かれるときの準備をしておくと、自分の聞かれる工数削減にもなる。何かの手順を OneNoteとか、Mdにまとめておく、ログのクエリーをいつでも取り出せるようにしておいて、コメントで説明を書いておく、重要な過去の Pull Request のリンクを保存しておく等、イケメンの技術者の皆さんは、実はやっている気がする。(だから解答が物凄く早くて正確)
陰キャの私が人に頼ることを覚えた
今回は、自分が得たフィードバックでもあるけど、イントラバートであまり人に頼るのがへたくそな自分が学んだことなのでシェアしてみました。私はそれ以降「人にたよる」ことを覚えて、ヴォイトレに行ったり筋トレのパーソナルコーチをつけたり、まず人に頼るということをするようになりました。最後に、筋トレのパーソナルコーチを面白いことを言っていたのでそれをシェアしたいと思います。
この記事が気に入ったらサポートをしてみませんか?