本記事はBASEアドベントカレンダー2024の9日目の記事です。

はじめに

初めまして、BASEでフロントエンドとバックエンドの開発を担当しているkondoと申します。この記事では、私自身が開発エンジニアとしてプロジェクトを成功させるために心掛けていることを紹介します。日々プロジェクトを進める上でどのような取り組みを行なっているのか、参考になる事例紹介となれば幸いです。前提として、私はBASEではスクラム開発・ほぼフルリモートで働いております。

プロジェクトを成功させるための工夫

スクラム開発でベロシティを計測して、ストーリーポイントから逆算してリリース日がいつか可視化する

スクラム開発でチームがスプリントでいくらベロシティを消費できるのか計測して、残りのストーリーポイントが何スプリントで終わるのか計測する取り組みをしています。リリース時期を予測しておくことで、自分たちはもちろん、マネージャーやビジネスサイドとも会話しやすくなります。またベロシティが向上し、チームが成長できているかなどの指標も計測することができます。

振り返りで良かったこと、改善したいこと、そのアクションを決める

振り返りの場では、チーム全員でスプリント中に良かったこと、改善すべき点を共有し、それを基に具体的なアクションを決めます。例えば、良かったこととしてペアプロの実施が挙げられた場合はペアプロを継続して、改善すべき点で細かい仕様が不透明であると挙げられたら、仕様書をより詳細に記載していきます。このプロセスを繰り返すことで、改善点は徐々に改善されて、良かったことが継続されていきます。

チームメンバー全員がフロントエンド・バックエンド・インフラの対応をできるようにする

チームメンバー全員ができる領域を増やしていくことで、タスクが個人に依存しない強いチームになっていくと考えています。自分たちのチームではバックエンドエンジニアがReact、Typescriptに取り組んだり、フロントエンドも書くしSQLも書くエンジニアがいるなど、各々が領域拡大に取り組んでいます。ペアプロなどを通じてサポートすることで、無理なくできることを増やすことができています。

コードレビューより自分のタスクを優先しない

コードレビューは、機能をリリースするためには必須事項です。チームが機能を素早くリリースすることは、顧客への価値提供を早めると考えています。そのため、自分が終わらせたいタスクがあり、コードレビューを先延ばしにしてしまうと、その分チームが機能をリリースできる時間が伸びてしまいます。したがって、コードレビューは優先して見るようにしています。

前提の考えや知識、立ち位置のギャップを埋めるため、同期的コミュニケーションを活用する

私のチームでは、フルリモート環境でSlackやGitHubを使い、非同期で開発を進めています。しかし、非同期のやり取りでは、前提知識や経験則、問題に対する温度感が伝わりにくく、議論が平行線になることもあります。この課題を解消するために、同期的なコミュニケーションを取り入れています。例えば、Aさんは効率性を重視し、Bさんは分かりやすさを優先している場合、意見がすれ違うことがあります。このような時、オンラインミーティングでお互いの思考プロセスや背景を共有することで、認識のギャップが埋まり、新たな解決策を見つけることができます。このプロセスを通じて、相互理解が深まるだけでなく、議論を通じてメンバー同士の新しい視点の獲得にもつながっています。

不確実性の高いタスクから取り組んで、PJの不確定要素を減らしていく

プロジェクトの序盤で、不確実性の高い仕様や技術課題から優先的に取り組むことで、リスクを早期に発見し、解消するようにしています。特に外部APIとの連携や、今まで活用したことのない技術などは、実際にそれが必要になるより前に調査して、不確実性を取り除くようにしています。後半になるほど不測の事態の対応は大きくなってしまうので、早めの対応が肝心と考えています。

ストーリー・タスクの優先度を明確化する

全てのタスクに明確な優先度を設定することで、チームが今どのタスクを最優先で取り組むべきか明確にしています。こうすることで重要なタスクの抜け漏れを防いだり、優先度の高いタスクからリリースをすることができます。

仕様書を明確に記載する

仕様書を詳細に記載することで、プロジェクト全体の透明性を高め、チームメンバーや将来の関係者が迷うことなく作業を進められるようにします。また、テストケースが仕様書から明確に導き出せるようになるため、テストの効率化やバグの早期発見にもつながります。これを怠ってしまうと、Slackのどこかで会話した記憶があるとか、どこかのミーティングでこうなった気がする、といった情報が流れてしまう事象が発生してしまいます。仕様書を書く手間より情報を掘り起こしていく手間の方が高い場合も多いため、なるべく書くようにしています。