Ubie のスクラムチームで Web フロントエンドエンジニアがフルスタック開発している話
はじめに
Ubie Advent Calendar 2020 13日目の記事です。
私はもともと Web フロントエンドエンジニアとしてフロントエンドの設計・実装を担当していましたが、Ubie のスクラム開発チームの一員となってからはバックエンド開発にも携わるようになり、日々楽しく技術の幅を広げています。
外部の人にそのことを話すと「どうやっているのか」と聞かれることが多かったので、Ubie のスクラム開発の様子や、フルスタックに開発するためにやっていることなどを紹介したいと思います。
Ubie のスクラム開発について
Ubie の病院向けサービス開発チームでは LeSS を導入して大規模スクラム開発を行っています。
スクラム開発では顧客へ価値提供できる最小単位 = プロダクトバックログアイテムが開発の単位になるため、チームメンバーは皆フロントエンドからバックエンドまで丸ごと開発できることが望ましいです。実際、今いるチームメンバーはスキルの幅が広く、全員 React フロントエンドと Rails, Kotlin バックエンドを丸ごと開発しています。
前職以前の職場では開発組織が職能で分かれていることが多かったため、Ubie のチームメンバー全員フルスタックという環境はなかなかユニークだと思います。
バックログアイテムに自分をアサインしてから、どう実現するか考える
スクラム開発においては、プロダクトバックログアイテムに受け入れ条件 (Acceptance Criteria、以下AC) が定義されており、その条件を満たすことで開発が完了します。
スプリント開始時にはプロダクトオーナーとスクラムマスターがバックログアイテムを優先度順に並べ、チームメンバーがバックログアイテムに自分をアサインし、着手していきます。
ユーザーへの価値提供、ひいてはプロダクトの成長と事業の成功のためには、優先度の高いアイテムをなるべく早く完了させることが最も大切です。なので、自然とバックエンド開発を含むアイテムに自分をアサインすることになります。
(もちろん、大規模なバックエンド設計が必要だったり詳細なドメイン知識が必要な開発の場合は、いったん全社視点で考えて最適解を決めます。得意なメンバーに任せた方が良い時は任せ、自分のできる範囲で対応します。)
最近開発した例だと、病院での問診時に頭痛や腹痛などの場所を伝えるシェーマ質問というものがあるのですが、この質問を特定条件下では表示しないよう調整するものがありました。
この質問はDBの特定のカラムの値を参照して表示するかどうか決めているため、当初はDBの値を削除する予定で進めていました。
その後、DBの値を直接削除してしまうと別のサービスに影響が出ることがコードレビュー中に判明したため、バックエンドのロジックを調整してAPIレスポンスからフィルタするようにしました。
ACをどう達成するか考えるときに考えること
スクラム開発において大事なのはユーザーに届けたい価値が実現できていることと、素早く検証可能であることです。そのため、最速かつミニマムな形で価値提供でき、かつメンテナブルなコードを維持するためにはどのレイヤーの責務にすると良いかを検討し、実装方針を決めます。開発内容によっては詳細なドメイン知識が必要で、かつ自分が詳しくないこともあるので、詳しいメンバーに方針を相談したりもします。
方針が決まったら、実装を進めます。Rails なら Rails、Kotlin なら Kotlin のベストプラクティスを調べ、実装して試してみます。経験が足りず微妙な実装になることもありますが、チームメンバーのレビューが手厚いので安心して失敗しにいけます。
フルスタックに開発するために日々やっていること
開発を始める時は、まずは目の前にあるプロダクトコードを読み込みます。現場のコード以上に勉強になるものはありません。
ドメイン知識や実装の経緯を知らないと理解しづらいコードも中にはあるので、詳しいメンバーにレクチャーしてもらうこともあります。
あとは、技術の幅を広げるために興味ある技術書を片っ端から読み漁ってみたり、Webの技術記事を読んだり、専門家のブログを覗いたりしています。
個人開発で新しい言語を触ってなにか作ってみたりもします。このあたりは特に変わったことはなく、皆さん普段からやっていることだと思います。
私はもともとコンピュータが好きで、Webフロントエンドに限らずコンピューティングの知識は拾い漁っていました。それが今になって活きているなと思います。
CPU やメモリ、ストレージ、ネットワークなどのハードウェア構造から OS やネットワークの仕組み、Web を構成する技術あれこれ、プログラミング言語がやっていること、データベースの仕組みやデータ型など。どれも「チョットワカル」とは言えない程度ではありますが、折に触れて知見を深めアップデートすることで、開発する時にシステムの全体像をイメージしやすくなり、より早く最適解を出せるようになります。
先人がオススメしている技術書や名著と呼ばれている本はやはりためになることが多く、一度読んで理解しきれなくても、なにかの折に読み返すことで地力がついた気がします。
「クリーンコード」、「CODE COMPLETE」,「リファクタリング」、「リーダブルコード」、「コーディングを支える技術」、「Webを支える技術」などなど。なかでも、「達人プログラマー」と「UNIXという考え方」はとても好きです。
「プログラマが知るべき97のこと」も良かったですね。優秀なエンジニアの考え方の片鱗を覗けた気がします。
かの有名なガウディ本も眺めてみました（買うと高い、かつ一度で理解できなさそうな本は試しに図書館で借りることが多いです。）
欲を言えばもっとプライベートで手を動かしてバックエンド開発の経験量を増やせると良いのですが、家族がいて子どもがまだ小さいので、週末はバランスを取るようにしています。
もちろん得意分野を活かすことも
バックログアイテムによってはフロントエンド実装のみになることもありますし、他のメンバーのフロントエンド実装をレビューすることもあります。
React & TypeScript での状態管理のベスプラやアンチパターンなど、他のメンバーにアドバイスできることも多いので、もともとの得意分野は活かしてチーム全体のスキルアップを手助けしています。
おわりに
Ubie でのスクラム開発の一例と、自分なりのコミットのしかたをご紹介しました。
今回紹介したのは自分が今関わっている病院向けAI問診サービス開発の例であり、チームやメンバー構成によって開発領域の分担は微妙に異なります。ですが、スクラム開発の大まかな流れやメンバーの基本的なスタンスはどのチームも同じです。
Ubie のチーム開発では、各々が得意分野を活かしつつ、ユーザーにいち早く価値を届けるために全員が最善を尽くしています。
皆がユーザーとプロダクトに向き合い、Ubie の行動指針である「Launch & Launch」を胸に、技術的に完璧であるよりもユーザーのための最善を良しとする。そんなチームなので、私は日々楽しく成長できています。
Ubie では技術の幅を広げてプロダクトの価値にコミットしまくりたいエンジニアの皆さんをお待ちしています。
We are hiring!