ourlyでフロントエンドの開発を担当しています。ふぁるです。
私は2024年8月にourlyへ転職し、約5ヶ月が経ちました。
元々は10人程度の小規模なスタートアップに勤めており、ほとんどのプロジェクトの開発を単独で担当していました。単独開発の文化にどっぷり浸かっていた私にとって、ourlyでチーム開発に取り組んだ5ヶ月間には多くの学びがありました。
この記事では、チームメンバー間の良い関係と円滑なチーム開発を実現する上で、私が特に大切だと感じたことを5つ共有します。特にチーム開発の経験が少ない方にとって、学びに繋がることがあれば幸いです。
1. コミュニケーションは沢山取る
チーム開発では、複数のメンバーが同時に作業を進めるため、「特定のメンバーしか知らない情報」 や 「自分しか把握していない情報」 が往々にして発生します。
重要な情報に偏りが生まれていた場合、それはプロジェクト全体にとってのリスクとなります。
例えば、ユーザーの持つ権限に対して許可されていないAPIを叩き、403エラーとなってしまった出来事がありました。この原因は、APIを実行可能なユーザー権限に関して、バックエンドメンバーでは共有されていたものの、全体には共有されていないという情報の偏りによるものでした。(この件に関しては、その後OpenAPIの定義に権限情報も記載するルールとしたことで防いでいます)
そのため、メンバー間の認識のずれを埋めるために以下のようなことを意識しています。
- 自分だけが得た情報はすぐにチーム全体へ共有する
- 疑問点や不明点があれば、躊躇せずその場で確認する
- 情報はドキュメントに明文化しておく (タイムラインではなくドキュメントがおすすめ)
チーム開発においては、 「必要以上のコミュニケーション」よりも「コミュニケーション不足」によるリスクのほうが遥かに大きいです。積極的に情報共有を行い、認識のずれを最小限に抑えることを大切にしています。
2. レビューは最優先にする
チーム開発をしてきた方からすると「そんなの当然！」と思う話かもしれません。しかし、単独開発の環境で育ち、レビュー文化が根付いていなかった私にとって、これは大きな学びでした。
まず大前提として、チーム開発では個人の生産性ではなく、チームの生産性を上げることが重要です。単独開発で作業を途切れなく続けられるように、チーム開発では他メンバーの作業を滞らせないこと、つまりフロー効率をチームで最大化する意識が必要です。
私がフロー効率を上げるために意識していること、取り組んでいることを3つ紹介します。
「とりあえずレビューを待つ」を無くす
「レビュワーにアサインしたがレビューが行われていない時」 もしくは 「レビュワーにアサインされたがすぐに対応が難しい時」 速やかにコミュニケーションを取ることを意識しています。
速やかにコミュニケーションを取ることで、必要に応じて他メンバーにレビューを依頼するなど、次のアクションを迅速に取ることができます。
必要に応じて同期的なレビューを行う
レビューを非同期で行うというルールはなく、フロー効率を高めるために柔軟に工夫することが必要だと考えています。
特にレビュー難易度が高い場合には、直接実装者と会話しながらレビューを進めたほうがスムーズな場合もあります。
また、同期的なレビューを行う際には会話内容を記録として残すことも意識しています。他のメンバーが情報を参照できるようにし、チーム全体の透明性を確保するよう努めています。
PR粒度とレビュー観点を小さく保つ
レビュワー目線で、大量のコードをレビューすることは心理的な負担を感じやすく、見落としが発生しやすくなります。また実装者目線でも、レビュー観点が多すぎると指摘事項が増え、修正作業における心理的負担を感じやすくなります。
そのため、PR粒度を小さくし、レビューの観点を絞ることで、お互いの負担を減らすことを意識しています。
粒度の判断基準として差分行数 (100行以下など) もありますが、PRのタイトルが端的に表現できない場合は、PRを分割する余地があると考えています。(関数の責務が多すぎて適切な命名ができない現象と似ていますね)
3. 要望をする前に背景や意図を理解する
前提としてourlyのフロントエンドチームでは、共通化されたモジュール以外には基本的にコメントを書かないスタンスが採られています。
入社直後、プロダクトのコードをほとんど把握していない段階で引き継ぎが必要となりました。そのため、コード理解を早めるために、今後開発するコアなモジュールに概要補足のコメントを追加してほしいという旨の要望を出しました。
実際の文章
しかし今思えば、その時はまだチームメンバーとの信頼関係も十分でない状態です。そんな中で、チームの文化や方針の背景を理解する姿勢を示さず要望を出すことは、リスペクトに欠ける行為だったと反省しています。
いきなり要望から議論を始めると、相手に一方的な印象を与え、不快感を抱かれる可能性があります。(信頼関係が十分でない場合はなおさらです)
チームの文化や方針は、これまでの開発の中で議論を積み重ねた努力の結果でもあります。まずはそれらにリスペクトを持ち、背景や意図を理解した上で必要に応じて要望を提案することが大切です。
改善した文章
4. 悪いことほど早く知らせる
ourlyのプロダクトチームでは、毎朝進捗共有を行うミーティングがあります。これまで私は、スケジュールに影響が出そうな遅れが発生した場合、次の日の朝会で共有するというスタンスを取っていました。(そして私は指摘を受けました)
チーム開発において重要なのは、遅れが発生しているという状況をできるだけ早い段階で全体に共有し、ボトルネックを解消するためのアクションを迅速に取ることです。
開発には不確実性がつきもので、タスクやスケジュールの遅れが発生することは通常起こり得ます。そのため 「遅れること自体」は悪ではないと考えています。本質的に悪いことは、遅れを共有しないことによって、遅れを取り戻すためのアクションが遅れることです。
一方で、そのようなネガティブな出来事を自ら早く共有することは、心理的に負担のかかることだと思います。だからこそ、チームやメンバーがこの不確実性を受け入れる受容性を持つことが重要だと考えます。
5. 相手の話をまずは受け入れる
チーム開発において、ネガティブな意見や問題を安心して共有できる環境を作るためには、メンバーそれぞれが 「相手の話をまずは受け入れる」 姿勢を持つことが大切です。
私はパートナーから相談や悩みを聞いた際、理由や背景を尋ねたり、解決策を提案することを真っ先に行う癖がありました。(そして私はパートナーからも指摘を受けました)
そして、私自身がパートナーと同じ気持ちを業務の中で体感する機会がありました。目の前の課題に対して自分なりの考えを共有した際、「こうしたほうがいいのでは？」といきなり相手の意見を返されると、共有までに試行錯誤した過程をないがしろにされたように感じました。
相談や意見を受けた時、たとえ自分が否定的な意見を持ったとしても、相手はその考えに至るまでに思考を重ねてくれた可能性があります。まずは相手を尊重し、考えてくれたこと、共有してくれたことを承認することが大切です。
相手の話をまず受け入れることで、相手も他の意見を受け入れる心の余裕が生まれると思います。結果として、チーム全体の心理的安全性が高まり、より活発に議論が生まれる環境に繋がるのではないでしょうか。
まとめ
いかがでしたでしょうか。
私はチーム開発の世界に来て、主にコミュニケーション周りで多くの学びがありました。
チーム開発では、単に必要な情報だけをやりとりする合理性では乗り越えられない壁があります。互いに思いやりを持ち、心理的安全性の高い温かいチームを築くことが、チームメンバー間の良い関係と円滑なチーム開発を実現するのではないでしょうか。
本記事を通じて、皆さんの学びや気づきの一助となれば幸いです。
Discussion