開発チームの新しいエンジニアメンバーがうまくやるには

こんにちは、2021/12/09に開催されたペパボECテックカンファレンスにて、記事名と同じタイトルで発表をしました。 当日のスライドはSpeaker Deckで公開しています。

今日はその発表の内容を記事として紹介します。

開発チームの新しいエンジニアメンバーがうまくやるには

私は4月に新卒でWebアプリケーションエンジニアとして入社し、今は10人弱のチームに配属となってから3ヶ月ほどが経ちました。 会社のGitHub Enterprise Server上では、配属からこれまでで約60のPull Requestを開き、マージし、デプロイされました。 Pull Requestの数と成果は必ずしも一致しませんが、配属から今日までの間、昨日を細かく分割して実装しデプロイするということを続けています。

チームメンバーが私を迎え入れるにあたってしてくれたことは、業務経験の無い自分が開発に取り組むにあたってとても役に立つものでした。 以下では自らが意識的に取り組んだことと合わせて「新しいメンバーが〇〇するには」という題目で紹介します。

1.新しいメンバーが業務知識を素早く獲得するには

Webサービスのアプリケーション開発において、業務知識への理解は欠かせません。 ここでいう業務知識とは、そのサービスを成立させるためのアプリケーションの構成やそれらのアプリケーション固有の仕様などをはじめとした、エンジニアが業務を進める上で必要なそのサービス特有の知識のことを指しています。

このような知識は開発チームに参加したのちに獲得する必要があり、素早く獲得すればより早く広範囲のタスクを扱えるようになるでしょう。

アプリケーションの構成に関する共有会を開く

(チームメンバーが私にしてくれたこと)

チームメンバーに業務知識の共有会を開いていただいたことは、業務知識の獲得に直接的に大きく影響を与えました。 独自のアーキテクチャを持つアプリケーションのディレクトリごとの構成や各レイヤの関係性をざっくりと説明をしてもらったことでその後のコードリーディングが捗ったように思います。

他にもリレーショナルデータベースの重要なテーブルの関係性についてレクチャーをいただいたことも良い機会でした。 私の開発するサービスは多数のロールがデータベースを介して連携をしています。即ち特定のロールの処理を見てもそれ自体がサービスの動作を表しているわけではなく、他ロールでどのように使われているかを知る必要があります。 こういった広い範囲の挙動を把握するためには、全体感をつかむ説明を受けた方がアプリケーションの挙動を把握するのが楽になります。

少しずつ取り組む領域を広げる

(チームメンバーが私にしてくれたこと)

配属初期にいただいたタスクに関連するコード上の領域が少しずつ広がっていったことも業務知識を素早く獲得するに寄与しました。私は元々フロントエンド寄りのスキルセットであったので、Webフロントエンド領域のテンプレートやVueコンポーネントの実装からはじめて、次にWebサーバサイド領域のController層、Model層の開発に関わり、さらに他のロールや外部APIとの通信、バッチといった部分へ手を広げていきました。 大きなコードベースの中で少しずつコードリーディングの範囲を広げられたことはスムーズに開発に参加できた要因のひとつでした。

チームに回ってくるタスクに「やります」と言う

(自らが意識していること)

業務知識を素早く獲得するために私が心掛けていることの1つとして、チームに回ってくるタスクに積極的に「やります」と手を挙げることがあります。 開発チームにおいて、お問い合わせやパートナー (社員のこと) からの依頼に起因して、もともとの計画に含まれない突発的なタスクが発生することがときどきあります。 こういったタスクの中には配属後少し時間が経ち慣れてくればある程度対応できそうなものもあります。 自らのできることが少ないからこそ、できることは積極的に巻き取ることでチームに貢献しようとしています。

チームとしての生産性を高めるという点だけでなく、こういったタスクはときに自らの知っている領域を広げるきっかけになることがあります。 例えば私はあるロールのDockerを用いた開発環境を作成するタスクに取り組みましたが、これはまさに自らの知っている領域を広げるものでした。

普段はコードベースの大きい中心的なロールに対して開発を行なっており、CI/CD環境が整備され、Gitの操作やSlackとの連携によって、深く知らずとも簡単にデプロイできる環境が整っています。

一方開発環境の作成では、そのようなCI/CD環境が普段どのようなことを行なっているのかを一定程度追う必要がありました。 また、Webアプリケーションのエントリポイントに到達する前に、インフラレベルでHTTPリクエストがどのようにルーティングされているかといったことについても一定程度理解する必要がありました。 これらの知識は中心的なロールを含む他のロールにも適用でき、ブラックボックスとして扱っていたサービスを構成する要素の一部がどんなことをしているかを知ることができました。

手を挙げてタスクを受け取ることで、こういった毛色の違うタスクに触れる

2.新しいメンバーがチームに馴染むには

昨今は心理的安全性という言葉が取り沙汰され、開発チームのメンバー同士の関係もプロダクトの提供する価値に影響を与えることが広く知られていることと思います。 私の所属するチームにおいてもチームメンバー同士の関係を良好に保ち、意見を積極的に交換できるような関係性を築くような取り組みがなされています。

お互いの強み/弱みを知る

(チームメンバーが私にしてくれたこと)

チームメンバーがお互いの強み/弱みを知るために「ドラッカー風エクササイズ」という手法のチームビルディングのためのワークショップを開催していただきました。これは私がチームメンバーと相互理解を深めることに役立った出来事の1つでしょう。 「ドラッカー風エクササイズ」はお互いの特徴の自己認識と他者認識を書き出して、期待値をすり合わせるための手法です。 自らの思っている強み/弱みを伝えるきっかけになりますし、自分以外のチームメンバー同士でどのような関係が築かれているかを知る機会になります。 ペパボにおけるドラッカー風エクササイズの取り組みは会社のブログに紹介がありますので以下の記事をご覧になると良いかと思います。

参考: 「ドラッカー風エクササイズ」で期待をすりあわせて安全なチームに - ペパボテックブログ

コミュニケーションの場を用意する

(チームメンバーが私にしてくれたこと)

• フードコート

私の事業部のいくつかのチームにはフードコートという取り組みがあります。いつでも開かれているビデオミーティング会場で、お互いが好きな時に入ることができます。私の所属するチームのメンバーの多くは予定がない時などはここにいて、チームメンバーに話したい時にマイクをonにするといった運用がなされています。 フードコートに居る義務はなく、集中して業務に取り組みたいときなどには入らないという選択肢をとることもできます。 仕事を始めたて且つチームに参加したての自分にとって、発話のハードルが下がったのでありがたい取り組みでした。

• 事業部お茶会

リモートワークの中では、偶発的な同期コミュニケーションの機会はあまりありません。 このためチームメンバーが事業部の人を招いた座談会を定期的に開催してくれています。 他チームの人と業務に関係あるかどうかに関係なくいろいろな話をする機会が生まれることは、視野が広がる機会となっています。

日報を書く

(自らが意識していること)

チームメンバーとの相互理解を深めるために大事なことの一つに自己開示があります。 日報を書くことで、自らがどんなことを考えて仕事をしているか、どんな感情であるか、何を理解していて何を理解していないのかを知ってもらう機会となります。¹ また、チームメンバー以外の人が見てコメントをくれることもあります。

日報のフォーマットとしては「今の気持ち」「やったこと」「わかったこと」「次にやること」の4つに分けて記述するようにしています。

3.新しいメンバーが開発の提案をするには

複数の選択肢を挙げる

(自らが意識していること)

開発において、要件を達成する手法を自分で決められない/決めないとき、複数の選択肢を提案することで、自らに足りない業務知識や技術的知見を補ってもらえるようにしています。

このとき、あわせて自分が最も良いと思う選択肢を1つ選ぶよう心がけています。 自分が選んだものと実際に選ばれたものの差異が学びになるので、自分で1つ選ぶことはこれからも続けていきたいと思っています。

テストコードを書く

(自らが意識していること)

Pull Requestを開発における実装の提案の場として考えると、Pull Requestも新しいメンバーが開発の提案をうまくやる必要のある場の一つでしょう。 適当なPull Requestを投げてばかりではレビュアーの負担は増大するばかりです。

レビューしやすい Pull Request にするという意味でテストコードは有用です。 コードの一定の質が担保されるだけでなく、入出力が明確になったり、依存が明らかになったりするという利点が考えられるでしょう。

ちなみにテストコードの書き方については新卒研修の中でのカリキュラムがとても役に立ちました。 ペパボの2021年度の新卒エンジニア研修では、Railsチュートリアル内でのMinitestによる自動テスト、RSpec書き方講座、TDDワークショップなど、ソフトウェア開発における自動テストがどのような役割を持ちどのように作るべきかを学ぶことができました。 今はRSpecだけでなくPHPUnitやJestを用いたテストコードを書く機会がありますが、これらのテストフレームワークを使う上でも研修で学んだ内容が役に立っています。

おわりに

以上のような取り組みを通して、開発チームに新しくエンジニアとして加わったメンバーが、業務知識を素早く獲得し、チームに馴染み、開発の提案をして、ユーザへの価値提供に取り組んでいます。 チームメンバーが新しく私を迎え入れるためにしてくれたことが今の開発に生きていると感じています。

これらの事例が、チームに新しく加わる人や、新しい人を迎えるチームにとって参考になれば幸いです。また、チームに加わった3ヶ月で自分がどのように感じ何が役に立っていたかの取り組みを残しておくことで、将来チームメンバーを迎え入れる側になったときにこれを見返してよい環境を提供できるようになれればと思います。

Footnotes

1. 同時にこれら (どんなことを考えて仕事をしているか、どんな感情であるか、何を理解していて何を理解していないのか) を言語化することで自らに対して明らかにする機会ともなります。 ↩