ジュニアなエンジニアを助けたクラスター社のメンタリング
はじめまして。クラスター株式会社でエンジニアインターンをやっています あのりく(@anoriqq) です。
この記事は クラスター Advent Calendar 2021 の23日目の記事になります! アドカレも終盤ですね!
昨日 22日目の記事は、sansuke さんの「clusterのUnity UI周りの開発紹介」でした!
clusterのワールドやイベントに入室してからのUIは体験に大きく関わります。clusterは今年も様々なUI改善を行ってきましたが、このような技術に支えられているのですね!
はじめに
さて、この記事では、「ジュニアなエンジニアを助けたクラスター社のメンタリング」と題して、私自身の実体験をもとにメンタリングについてお話します。
今回の内容は次のような方に役立てば嬉しいです
- 社会人経験が少ない and/or エンジニア経験が少ないといったジュニアなエンジニア
- 何をすればよいのか悩んでいる、ジュニアエンジニアのメンター
特に２つ目の状況には、「未来の自分がそうなるかもしれない!」というつもりで、メンティーは何を考えているのかも残せたらと思っています。
まず最初に、私の所属する部署の基本的なエンジニアのメンタリング体制をご紹介します。
新しく入社するエンジニアには、配属されるチームから1人がメンターを担当します。
メンターは1on1をはじめとした、メンティーのメンタリングを行います。
私は2020年10月に入社しまして、サーバーチームに配属されたので、同チームの kyokomi (きょこみ) さんがメンターを担当してくださいました。
この記事はkyokomiさんの同意を得たうえで、メンタリングで行ったこととその効果、メンティーの私が何を感じたのかなどをお伝えします。
ちなみに現時点のクラスター社は、エンジニアの新卒採用を行っておらず(インターンからの採用は実績あり)、研修制度等はありません。
なので私は、実際の業務を行いながら、仕事を覚えていく形で開発に取り組んでいました。
メンタリング施策
早速、実際に行ったメンタリング施策を見ていきましょう!
たくさんの施策をメンターのkyokomiさんに提案していただき、実践してきましたが、特にこれは話しておきたい! と思ったものをいくつかピックアップしてご紹介していきます。
心理的安全性を高めたこと
私が入社してからぶつかった1番の課題は、心理的安全性の確保です。
私自身は、他人とのコミュニケーションが得意な方ではありません。
なので、仕事を進めるためのコミュニケーションすらままならず、チームメンバーには非常にご迷惑をおかけしていました。
今では当時に比べると、ある程度コミュニケーションも取れている(はず...な)ので、今に至るまで起きた、「このチームでやっていけるかもしれない」と感じた出来事を振り返ってみます。
ほぼ毎日行ったメンター1on1
クラスター社では現在、基本的にはリモートワークで業務を行っています。そのため、コミュニケーションにはSlackを利用しています。
当時の私は、下手をすると誰とも話さずに1日が終わるみたいな状況でした。
誰ともコミュニケーションを取らなければ、心理的安全性は向上しないことは想像しやすいと思いますが、全くその通りでした。
そんな状況での週4回のメンター1on1は非常に助かりました。
私が担当するタスクで、私にできなかったこと、難しかったこと、困ったことなど、をポロッと話すと、アドバイスを示してくれたり、一緒に解決策を考えてくれたりした体験、そして、業務に全く関係のないアニメやゲームなど共通の趣味の雑談をした体験は、「この人なら安心できそう」と思うのに十分なものでした。
私のような、そもそも話すきっかけがないとコミュニケーションを取るのが苦手な方には、話す機会を作っていくという観点で、頻繁な1on1は有効だと思います。
1人でも安心してコミュニケーションが取れるメンバーがいると、そのメンバーの周りにいる他のメンバーともコミュニケーションしやすくなるものです。
まずはメンターとの信頼関係を築くことを目指すのはありかもしれません。
Slackでの発言数を振り返る
心理的安全性を高めるには、コミュニケーションをとってみて、「思ったより怖くないな」という経験を積むのもひとつの道です。
そこで、一定のコミュニケーションをとるようにする施策が"Slackでの発言数を振り返る"というものです。
この施策は矯正ギブス的なものになります。
SlackにはAnalytics機能があり、メンバーごとの発言数が見られるようになっています。
この機能を使って、Monthlyとかで発言数を振り返ります。
Slackで存在感のある方々は月に数千メッセージの単位で発言してたりします。(つよい)
かく言う私は、最初の数ヶ月は、月に300メッセージくらいの発言数でした。
その後、発言数の振り返りをするようにしたことで、900メッセージほどまで増えました。
当時は頻繁にコミュニケーションを取らないと進められないタスクを持っていなかった頃なので、900件のメッセージのほとんどは独り言でした。
当時は独り言を垂れ流していくことに意味はあるのだろうか...と思いつつ、SlackはTwitterだと思い込んで日々ツイートするように発言していました。
心境の変化はゆっくりですが確実にありました。
Slackで非常にどうでもよい発言や、しょうもない発言をしても、誰にも怒られないどころか、リプで話が広がることさえあることを知り、無事に「この会社の人とのコミュニケーションは全然怖くない」という感覚を掴むことに成功しました。
以降、社内のメンバーに限らず、変に障壁を感じずに対人コミュニケーションをとれるようになりました。
すこし話がそれますが、独り言は全くもって無意味ではなかったです。
今、当時の私の発言を見返してみると、「なんかダメそう」、「多分いけそう」のような発言をしていました。これらは、普段の開発業務においては状況をなんとなく把握するのに有用です。
何も発信されていないと、困りごとがあっても周りからは気づけません。
そういった意味でも、Slackでの発言が少ない場合は、とにかくSlackで発言してみて"Slackでの発言数を振り返る"のはやってみても良いかもしれません。
効果のあった振り返りと目標設定の期間
目標設定と振り返りの単位ですが、結論としては1日単位の短いサイクルで行うのが有効でした。
目標設定と振り返りは、1on1の時間を使ってを行っていました。
はじめはクウォーター単位の目標を立てていましたが、クウォーターの終わりに振り返りを実施しても、振り返り日の直近の反省点にしか対応できず、もったいない感じでした。
次に月単位で目標設定と振り返りを実施しましたが、クウォーターでやっていたときと同じ理由で更に短くしました。
最終的には数日単位まで細かくして、目標設定と振り返りを行うようになりました。
もちろん中長期の目標は立てますが、フィードバックループを頻繁に回せるようにすることで、成長の余地を見つけやすくなりました。
具体的な振り返りの内容は、基本的なKeep/Problem/Tryを出していくというものです。
記録としては、話しながらSlackに議事録を残していくよりも、miroのボードに書いていったほうが視覚的にイメージが湧きやすく効果的でした。
今日は何をやって、昨日立てた目標を達成できたか、明日はどのタスクを、何をトライしつつ行うのかを話していました。
以降の章で、この振り返りを通して発見した、良かったトライを紹介していきます。
自分だけのタスクの粒度と見積もり
クラスター社での日々の業務は、最も細かい単位ではJiraで管理されているタスクを実行していくことで進めています。
もう1段階大きな単位では、epicというまとまりである程度の規模の機能開発を行っています。
epicにはこの日までにリリースしたいという期限を設けています。
そして、epicにアサインされたメンバーそれぞれが、"自分の全てのタスクがその期限までに完了するかどうか"を事前に見積もっています。
(終わりそうになければリリース目標を調整したり、一部機能を削ってリリースを分割したりする)
例えば、"xxxを行うAPIを実装する” タスクなら、設計と実装とテストをやるから3.5時間で終わりそう。epicとしては、タスクの見積もり時間の合計は60時間なので、2人だと1週間くらいで終わりそう。というように見積もっています。
もちろん私も、自分の担当タスクを見積もる訳ですが、開発経験が少ないので「何もわからん」となったり、ガバガバ見積もりが生まれたりするわけです。(泣)
そこで、"できるだけ正確な見積もりが出せるようにする"という課題を考えました。
次に挙げるような発見がありました。
見積もりは希望ではない
見積もりは、希望でなく、見積もりです。
見積もりの時間が短いことは良いことですが、それは見積もりが正確だったときの話です。
1つのタスクに10時間かかりそうなら、それはそれで見積もりとしては良いです。
自分より技術力が高いシニアエンジニアなら0.5時間で終わるとしても、私は10時間かかる。それで良いのが見積もりです。
(見積もりって残酷ですね...泣)
チーム開発においては正確な見積もりのほうが、チームメンバーに喜ばれるので、希望は個人の趣味開発で叶えるのが良さそうです。
正確な予知は諦める
残念ながら私には(そして多分ほとんどの人類は)未来が分からないので、正確な予知は不可能です。
我々がやろうとしてるのは、"見積もり"なので、未来予知は諦めようにする。
こう思うことで、私の場合はストレスが減りました。
メンターにも見積もりをしてもらい差分を可視化する
2点見積もりの可視化
私はもちろん見積もりをしますが、メンターにも同じタスクを見積もりしてもらいました。
メンターも多分おそらくきっと未来予知能力はないはずですが、見積もりは私より高精度です。
なので、私の見積もりとメンターの見積もりとの比率が安定していれば、見積もり時に考慮すべき観点がある程度揃っているだろうと判断できます。
例えば、メンターよりも見積もり時間が短くなった場合は、考慮すべき事項が足りてないかもしれないと気づくきっかけになります。
私は、最初のうちはメンターの見積もりと私の見積もりに5時間くらいのギャップがありましたが、後に述べるような対策を行い、毎回1時間程度に抑えることができるようになりました。
一定以上の見積もり時間になったタスクは分割する
例えば私は、2時間を超えるタスクは作らないようにしました。
APIを作成するタスクを、実装とテストに分割して、実装を設計と作業に分割して、テストをテストケース作成とテスト実装に分割して...といったようにして、2時間を超えたら分割を繰り返します。
やることが少なければ少ないほど、見積もりの確度は上がるとされてます。
タスクを分割するのは、見積もりを行う上でやるべきことを分かりやすく可視化していることになりますね。
設計レビューしてもらってから見積もりする
レビュー済みのdesign doc
やろうとしていることが何時間で終わるのかを考えなければならないのに、やろうとしていることが想像てきていないことがよくありました。
何をやるのか分からないのに見積もるのは、epicをやるかどうか未確定な初期なら有用ですが、epicをやると決定したあとでは、より正確な見積もりが求められます。
そこで、設計を完了させ、コードベースのどの部分にどんな変更をするのかまで考えを巡らせたあとで、見積もりを行います。
これにより、見積もりの確度を向上させました。
この取り組みの副次的な効果として、プルリクエストを開いてからコードレビューにかかる時間や労力を減らす効果もありました。
事前に設計段階でレビューされているので、プルリクエストの内容がひっくり返るなんてことは起きにくくなります。
どれくらいかかるのか分からなければとにかくバッファをつむ
やってみたら思ったより早く終わった よりも やってみたら思ったよりも時間かかった のほうが多くないですか?
私はそうでした。
経験してないことは、経験しないと何時間かかるのか分からないことがほとんどです。
なので、分からなければ、分からない状態で出した見積もりを2倍とか3倍しておきます。
多分見積もり通りに終わりませんが、epicの期限を調整しなければいけない事態の発生確率は下げることができます。
リスクを抑えつつ、経験して、見積もりできる分野を増やしていくのが良さそうです。
タスク実行の速さ vs 丁寧さ
さて、見積もりも終わり、実際にタスクに取り掛かっていきます。
見積もり通りにタスクが完了する。これが理想的ですが、私の現実はそうなることがほとんどありませんでした。
見積もり以上に時間がかかってしまうことばかりです。
そうなると、どうしても焦ってしまい、丁寧に進めることをおろそかにしがちでした。
私は、焦って良かった記憶がありません。
具体的には、コードレビューで指摘されることは増えるし、考慮漏れに後から気づいて実装し直したりなどが起きました。
このように、チームメンバーに無駄な労力を使わせてしまいますし、落ち着いていればもっと早く終わったなと思うことばかりです。
白熱してしまったプルリクエスト
見積もり通りに終わらないのだとしても、終わらないのであれば、なにか見落としがあるのではないか?と視点を切り替えるきっかけになったと思うのが良いかもしれません。
レビュイー力
前章の"丁寧さ"と若干かぶるのですが、レビュイー力のお話です。
ジュニアなエンジニアに関わらず、チーム開発においては、エンジニア同士のレビューを行います。
例えば、プルリクエストや、design docsなどの設計文書のレビューです。
その際、次のようなレビュイー力が重要だと思います。
- 前提条件を明示する
- 決断の理由を明示する
- 理解の難しい概念については図表等を活用する
- 分かりやすい日本語の文章を書く
- レビュアーへのリスペクト
これらが十分でないと、レビューのハードルが高くなってしまう恐れがあります。
また、レビュイー:レビュアーは1:1…*の関係になることが多いです。
つまり、レビューのコストが高いと、レビュアー全員の労力を消費してしまうことになります。
しかしこれは、レビュイーが多少のコストを掛けて、レビューのハードルを下げることで、比較的簡単に回収できます。
レビューに必要そうな情報をdescriptionに入れる
これらのレビュイー力が低いために起きる、「プルリクエストの文章の意味が分からない」、「design docsでxxxが考慮されてるか知りたい」などのフィードバックを極力減らすことで、スムーズに開発を進めることができます。
チーム全体のためにも、レビュイー力を上げておくと、喜ばれると思いますし、自分自身の成長にもつながると思います。
レビュイー力を高めるには、レビュアーをたくさん経験する。文章をたくさん読み書きする。レビューで指摘されたことを次回のレビュー時に繰り返さないようにチェックリストを作るなどの工夫をする。などなどのトライを行うと効果が出るのではないかと思います。
私はまだまだレビューで指摘されることが多いですが、同じことを言われ続けるというよりは、指摘されることのレベルが上がっているような気もするので、多少の効果は出ていると思います。
ジュニアなうちは「読みにくい文章だ」などの指摘をしてもらいやすいので、レビュイー力を高めるチャンスだと思います。
ひとりで考えないプロダクトの設計
計算機ってすごいですよね。(唐突)
ですが、計算機には物理的制約がありますし、プログラミング言語にも制約はあります。
とはいえ、制限がゆるすぎると思うのです。
"技術的には可能"なことが無限に出てくる気がします。
しかし、なんでもはやらないわけじゃないですか。その理由は、"これはやりません"ということを、人やチームや文化や時間などが決めているからだと思います。
clusterにも、作っている人やチームがいて、チームや会社には文化があって、全てには歴史があります。もっと言うと未来もあります。明日クローズするつもりで今日clusterを作っているつもりは全くありません。そういったものが、clusterでやること/やらないことを決めている気がします。これは大変ユニークな状況が生み出されているということになると思います。
このような非常に細かい視点で見れば、我々がclusterに対して行っているあらゆることは、世界で初めて行われることです。
つまり、毎回毎回、世界で唯一設定された問題を解き、答えを出さなければなりません。
似たような問題も、微妙な違いで、ベストな設計は変わります。
前置きが長くなりましたが、毎回異なる問題を解き続けなければならないとき、できるだけ高確率でベストな設計を出し続けるには、どうすれば良いのでしょうか?
プロダクトの知識を使う
ひとつは、プロダクトのドメインを良く知る人に聞く(作者など)、自分がプロダクトのドメインの作者になる、などがあると思います。
そのドメインについて深い造詣があれば、考慮漏れが減らせたり、既存の設計思想に則った設計がやりやすくなります。
仮設計や、大方針を出したら、レビューしてもらい。なんだかよく分からなくてお先真っ暗でも壁打ちさせてもらいに行き。設計文書を書いたらレビューしてもらう。
などなど、チームに蓄積された知識を余すことなく設計に反映させるようにできると良いのではないのかと思います。
素振りをする
やはり、実際にやってみるのが、一度に多くのことを学べます。
時間とタイミングが許せばできることではありますが、新しい設計をシニアエンジニアと同時にやってみて、後で答え合わせをするのが良かったです。
自分で実際に考えることで、多くの気付きを得られる上、シニアエンジニアの設計と照らし合わせて、自分の考えが至らなかった部分を発見できます。
もちろん個人の趣味開発で設計するのも良いと思います。
似た設計を勉強する
実際に経験するのが一番学びがあるとはいえ、我々が経験できることには、ある程度限界があると思います。
検索エンジンの設計も、ショッピングサービスの設計も、OSの設計も、クラウドコンピューティングの設計も経験しました! なんて人はなかなかいないと思います。
そこで、先人の経験を知識として得ることを地道に行っていくのもひとつの方法です。
世界には、多くのプロダクトが存在し、それらプロダクトの設計事例が公開されていたりします。
インターネットや書籍や先人から、そういった設計事例を学ぶことで、似た設計をするときのガイドになります。
例えばclusterのメッセージ機能の設計をした際には、世界のメッセージングサービスの仕様や、公開APIの仕様を調査したりしたことで、設計の助けになりました。
進行役で気づく、話すことの大切さ
最後の章になります。
私は最近になって、epicの進行役であるepic ownerを引き受けるようになりました。(とはいえ、まだ小規模のepicしか担当していませんが)
進行の役割は、epic memberの能力を最大限に発揮してもらうための雑用をやったり、全体の状況を把握してepicのアップデートを無事にリリースさせることなどです。
実際にepic ownerをやってみて気づいたのですが、epic memberとのコミュニケーションはもちろん、プロダクトマネージャーや、QA、epicを管轄するチームのマネージャーとのコミュニケーションなど、喋ってばかりです。
どうしてそんなに喋っているのだろうと振り返ると、epic ownerはepicのリリース目標までに、無事リリースできるかを判断するための情報を集めているのだと気づきます。
epic memberしかやったことがなかった頃の私は、epic ownerへの報告を怠ってしまうこともしばしばでした。
しかし、ownerとしては少なくとも日単位で状況を把握したさがあるので、これまでのepic memberの動きでは心配をかけてしまっていたなと反省しました...
epic ownerが責任を持って判断せなばならないことはたくさんあります。
例えば、epicのタスクに予定よりも時間がかかっているとき、残りのタスクをやれる人をアサインできないか、そもそもタスクをやらなくても良いようにできないか、epicのリリース日を遅らせることはできないかなどなど。
その判断を下すために、epicがどんな状況にあるのかを把握しないことには、ベストな判断になる確率は上がりません。
私の失敗例としては、ある機能について、本当はリリース目標日に間に合う作業量だったのに、タスク進行の不確実性を考慮して、リリース日を1週間遅らせたことがあります。
万が一、リリース目標日に間に合わない場合のリスクを考えて安全側に倒す判断は良いのですが、これはベターな判断でした。
この場合のベストな判断は、"タスク進行の不確実性"を取り除き、高確率でリリース目標に間に合うだろうという状況を把握して、予定通りリリースする判断です。
正確なepicの状況を把握できていれば、ユーザーの皆様に1週間早く価値を届けることができていました。
このように、ベストな判断をするための十分な情報を集められるように、密にコミュニケーションしていくことを忘れたくないですね。
epic ownerなら、epic memberに聞きに行き、epic memberなら、発信していく。これらをやっていくために、Slackにリマインダーを仕込んだり、dailyでsyncする時間をおさえたりするのが効果的だと思います。
おわりに
ここまでお読みいただき、本当にありがとうございます。
技術的なお話は、クラスター社の尊敬できる優秀なメンバーにおまかせして、私が書くことに意味がありそうな内容にしてみました。
1on1で何を話しているかはオープンにされないので、今回の内容は挑戦的だと思いましたが、何かの役に立てば幸いです。
私自身にとっては、クラスター社でのこれまでの振り返りができた非常に良い機会でした!
そして、この場を借りて、私をサポートしていただいた方々への謝辞を述べさせてください!
この記事に登場したメンターのkyokomiさんには、大変感謝しています。私が行き詰まったときに相談に乗っていただいたり、私がインシデントを起こしたときに気を使っていただいきました。ありがとうございます🙏🙏
そしてここに名前はかけませんが、一緒にclusterをつくっているクラスター社のメンバーの皆さん! たくさん助けてられましたし、見守っていただきました!
clusterを使っていただいているユーザーの皆様! 皆様の反応はいつでも新鮮で、励みになります!
ありがとうございます!!
私はまだまだ、助けられてばかりですが、この恩を忘れずに、いつか恩送りしていきます。
少しだけ広告を。
人類の想像力を加速させたい方は、クラスター社で働くのにぴったりです!
こちらのクラスター社の総合採用サイトをぜひご覧ください!
そして、私がソフトウェアエンジニアとして成長する支えになった書籍を紹介します!
『アプレンティスシップ・パターン ――徒弟制度に学ぶ熟練技術者の技と心得』は、メンターとメンティーの関係に似た徒弟制度を考えの起点にして、アプレンティス(指導を必要としている人)が、成長のために実践すると良いことが紹介されています。
社内での立ち回りなどをどうするか決めるときなどに、非常に役立ちました。
明日24日は、tharaさんの「clusterのserverについて（2021応用編）」です!
私もclusterのAPIサーバーはよく触りますが、ワールドやイベント内の体験を司る部分はほとんど未知なので、とても楽しみです!
Discussion