BASEプロダクトチームブログ

こんにちは。バックエンドエンジニアの岡本です。
ネットショップ作成サービス「BASE」の新規機能開発や既存機能の改修・運用を担当するShop Groupに所属しています。

今回は私が入社後初めてアサインされたプロジェクトであるメールマガジンApp（※）のアップデートを通して経験したこと・考えたことをバックエンドエンジニアの視点から振り返っていこうと思います。

※ネットショップ作成サービス「BASE」の拡張機能であるBASE Appsの機能の一つ f:id:okamotoshuhei-base:20200226102339p:plain

プロジェクトメンバー構成

・プロジェクトマネージャー
・デザイナー
・フロントエンドエンジニア
・バックエンドエンジニア(私)

メールマガジンAppアップデートの場合、上記4つの役割に対して1人ずつメンバーがアサインされました。1人ずつと言ってもそれぞれの担当を全て1人でやるということではなく、入社間もないメンバーにはメンターがアサインされるなどフォロー体制が整っています。設計レベルからメンターや所属グループメンバーにアドバイスをもらいつつ、プロジェクトの主担当として作業を進めて行きます。

プロジェクトの流れ

プロジェクトの流れとしては大きく下記の7つのフェーズに分けられます。

キックオフミーティング
設計・見積もり
実装
QAテスト
リリース
KPT(振り返り)
プロジェクトお疲れ様会

1. キックオフミーティング

プロジェクトの始まりにまずプロジェクトマネージャー(以下、PM)からプロジェクトの方向性・意味・想定仕様についての説明があります。PMが事前に用意したドキュメントをベースにざっと説明を行い、その後プロジェクトメンバー全員で不明点の確認や仕様の妥当性を議論していきます。もちろん1度のミーティングでは仕様が確定しないことがほとんどなので、都度メンバー間でコミュニケーションを取りながら議論を深めていきます。

2. 設計・見積もり

大方の仕様が確定したタイミングでエンジニアは設計と見積もりを行います。BASEでは基本的にフロントエンドとバックエンドで実装担当が分かれているので、APIのレスポンス形式やバリデーションロジックについてそれぞれ意見を出し合い実装の方向性を決めていきます。

実装の方向性が決まった後、次は見積もりも含めた設計ドキュメントの作成に取り掛かっていきます。APIドキュメントについてはAPI blueprintを利用し、その他バリデーションやDB関連の設計資料等はKibela記事にまとめていきました。設計ドキュメントが完成したタイミングで所属グループのメンバーにレビューしてもらいます。レビュー後のフィードバック対応が完了したらいよいよ実装フェーズに進みます。

3. 実装

実装フェーズは、

API実装
プルリクエストを作成し所属グループメンバーにレビュー依頼
フィードバック対応
レビュアーからLGTMを貰いレビュー完了

という作業をひたすら繰り返していきます。設計においても同様ですが実装フェーズにおいても所属グループメンバーからAPI単位で都度レビューしてもらえる環境があり、所属グループが支えてくれる感覚が実感としてありとても心強かったです。

4. QAテスト

開発が一通り完了し、プロジェクトはいよいよ佳境に入ります。QAテストはプロジェクトメンバー全員で分担し、それぞれが最終的なチェックを責任を持って行っていきます。比較的大きなデザインの課題が発見されたりするなど多少の問題は生じましたが、それぞれのメンバーがMove Fastに対応することで大きな滞りなくQAテストを完了させることができました。不具合の修正が完了したら後はリリース予定日を待つのみです。

5. リリース

そして遂に2月3日(月)に本番環境へリリースし、特に大きなトラブルはなく無事に完遂することができました。リリース後は自分自身が関わったサービスを通してユーザー(オーナーズ)の活動を支えることができたという実感があり、エンジニア冥利に尽きるいい仕事だなとしみじみ感じました。

6. KPTでプロジェクトを振り返り

余韻に浸りたいところですがリリースが完了してもまだプロジェクトは終わりません。今回のプロジェクトから学びを得るべくKPTを行いました。内容としてはKPT(Keep・Problem・Try)ごとに一定時間(20分くらい)で意見を出し合い、最終的に皆で共有し今後のプロジェクトに生かせるようにドキュメントにまとめました。

＜メールマガジンAppアップデートのKPT＞

Keep
- スケジュール通りリリースを完遂できたこと
- メンバー間でスムーズなコミュニケーションが取れたこと
Problem
- QAテストで比較的大きい仕様の修正が入ってしまったこと
Try
- 仕様のマスタドキュメント更新を全てのメンバーが責任を持って都度行う
- QAテストの段階で大きい修正が入らないようにできるだけ早い段階でテスト環境に動くソースをデプロイし、全てのプロジェクトメンバーが現状の実装状況を把握できるようにする

7. プロジェクトお疲れさま会

BASEには懇親会費用の補助制度があり、プロジェクト完遂後の打ち上げにもこの制度を利用することができます。プロジェクトの打ち上げは社内でも恒例となっており、今回は鉄板ステーキ屋に食事に行きました。入社後初プロジェクトをやり切った達成感からかはたまた高級店だった為か、お肉がとても美味しかったです。

プロジェクトを通して特に印象深かった事

改めてコミュニケーション大事

開発において手戻りを無くす為にエンジニア間のコミュニケーションは大事ということはもう周知の事実だと思いますが、やはり1番大事だなとプロジェクトを通し改めて感じました。コミュニケーションを密にとることの効用は何も認識齟齬だけではなく、信頼関係の構築という意味においてもプロジェクトの成功にとって避けては通れないものだと思います。

上記を意識してコミュニケーションを取った結果、今回のプロジェクトマネージャーからは下記の発言があり、プロジェクトを通して一定の信頼関係が構築できたと感じています。

f:id:okamotoshuhei-base:20200226102510p:plain

またプロジェクトを通して弊社のSpeak Openlyという行動指針は何度も私の背中をそっと押してくれました。「ここで確認するのはちょっと余計かな？」「この仕様少し疑問が残るけどどうしよう。」などと思った際、この行動指針を思い出すことで発言できる機会がいくつもありました。そして私のその発言に対してプロジェクトのメンバーはいつも真摯にHRTの精神を持って向き合ってくれました。

f:id:okamotoshuhei-base:20200226102530p:plain

＜HRTの精神＞

謙虚（Humility）
世界の中心は君ではない。君は全知全能ではないし、絶対に正しいわけでもない。常に自分を改善しよう。

尊敬（Respect）
一緒に働く人のことを心から思いやろう。相手を一人の人間として扱い、その能力や功績を高く評価しよう。

信頼（Trust）
自分以外の人は有能であり、正しいことをすると信じよう。そうすれば仕事を自分以外の誰かに任せることができる。

出典： Team Geek ―Googleのギークたちはいかにしてチームを作るのか

オーナーシップを持ってプロダクトを開発できるエンジニアは幸せ

BASEには役割に関係なくプロダクトをより良いものにする為に仕様やデザインに対して積極的に意見することができる環境があります。今回のプロジェクトでの最も大きい個人的な気づきとして、エンジニアがオーナーシップを持って開発に取り組むことの楽しさがありました。前職では受託開発を中心に担当していた私からすると、この自由でかつ責任感が伴う開発の現場はとてもスリリングで心地良いものでした。

サービスを自分自身の課題として捉えることは開発に対しての強いモチベーションにもなり得ると私は思います。そして何よりエンジニア・PM・デザイナーなどの役割を超えて1つのチームとして同じ課題を解決していく過程はとても楽しく幸せなものです。

最後に

BASEを一緒に支えてくれるエンジニアを絶賛募集中です！より良いプロダクトの開発の為に一緒に働きませんか？

herp.careers