この記事は、GLOBIS Advent Calendar 2024の16日目の記事です。
はじめに
ドーモはじめまして、GLOPLAチームでバックエンドエンジニアをしています @nyagatomo です。
GLOPLAチームではスクラム開発を行っています。
今回はめちゃくちゃ複雑な機能改修にスクラムチームで取り組んだ（取り組んでいる）話をお届けします。
まず複雑な機能があった
toBtoE向けのプロダクトとして、ユーザーの要望を叶えるために仕様が、設計が、実装が、時に複雑になることもあります。
ユースケースやユーザーのペインの変化、当時のプロダクト状況などもあり、実装された内容が今の状況にフィットしない、そういうことも往々にあるかと思います。
今回、私たちのチームが取り組むのもそういった性質を持つ 「めちゃくちゃ複雑な元の作りに機能を追加する」 という難しいミッションでした。
「めちゃくちゃ複雑な元の作り」が及ぼす影響を鑑みた結果「追加機能を盛り込んだ新しい概念でリプレイスする」という選択をとっています。
俺たちが倒す相手
今回戦うのはこんな感じの相手です。
例：図書館の貸し出しシステム。本と貸出履歴の取り扱いについて。
- 元の作り
- 個別のBookがあり、それをまとめるBookTitleがある。貸し出し履歴がBookに紐付いており、BookTitleごとの貸出履歴はBook経由で取得している。
- 課題
- 特定のBookを削除するとそこに紐付いた貸出記録も消えてしまう
- 改修案
- BookTitleに貸出履歴がぶら下がるようにした。Bookを削除しても貸出履歴は消えない。
- 細かく認識合わせのMTGを持つ
-
複雑かつ抽象的も多く、ただでさえ空中戦化しやすい状態だったため、非同期的なコミュニケーションではとてもではないが進められないものでした。そのため、同期的に話し合う場を積極的に持つようにしています。
エンジニアはgatherで常に同期的にコミュニケーションを取りながら話していますが、POとデザイナーを交えたすり合わせも最初の1週間ほどは毎日1〜2時間程度やっていました。
やらないと:
- 認識のズレが発覚するタイミングの遅延から、手戻りが大きくなる
- 解決すべき課題を箇条書きにして、目に見えるところへ置く
-
改修の規模が大きくなりそうだと分かった時点で受け入れ条件と優先度を再確認し、各種設計資料の傍には必ず「解決すべき課題」として記載するようにしました。
細かい工夫ですが、脳内メモリを大きく使う考え事において何がマスト要件だったかを意識の外、すぐ確認できる場所に出しておけたのは脳のリソース管理に役立ったと思います。
やらないと:
- 解決すべき課題を見失うことで、仕様が要件を満たさない、あるいはToo Muchなものになってしまう
- 軌道修正で手戻りが発生する
- ついやりたくなるあれこれについて「含める」「今回はやらない」を整理
-
既存機能の大改修になると、「そもそもの○○が良くないから変えたい」という議論になりがちです。プロダクト改善への熱い想いゆえではありますが、「今やるべきか否か」は冷静な判断が必要ですね。
「あれもこれも」と話が大きくなりそうになったら「これは今回の改修スコープとして適切ですか？」を都度POに確認するようにしていました。
やらないと:
- 「やった方が良いのは間違いないが、今取り組むべきでない課題」の議論に時間を割かれてリリースが遅れる
- 設計段階からチーム全員でmiroとNotionを睨めっこしながら進めた
-
Notionを使って言語化情報を整理しつつ、miroで視覚的に概念を整理することで認識のズレを最小に抑えるようにしました。
それでも発生した認識のズレは、別の人が作ってきたユースケースなどで発覚することがあったので、いろんな角度から視覚化することが大事だと再認識できました。
やらないと:
- 認識が揃ったつもりで進んだが実はズレていたことが後から発覚、軌道修正で手戻りが発生する
- あるいは軌道修正できず、本来作りたかったものと異なるものができてしまう
- 早いうちにER図を作って技術的に可能か、エンジニア目線で検討した
-
これも視覚化の一つだと言えます。エンジニア諸氏はER図を通して世界を見ることができるため、ER図に直した際「これっていらなくない？」「こっちが必要だった」という見直しも多数出ました。
やらないと:
- 実装時にER図を作った時に「あれが足りない」「これが足りない」が発覚する
- 場合によっては仕様設計レベルで手戻りが発生する
- 用語を整理した
-
例で言うところの「本」「書籍情報」「版情報」などの似た概念で会話がすれ違う可能性があったため、ユビキタス言語を制定しました。
やらないと:
- 同じものについて話していたつもりが別の概念について話していた、が発生する
- それに気付くタイミング次第で手戻りが大きくなる
- PO/デザイナーさんにもっと早く入って貰えばよかった
-
受け入れ条件にないところで「当然こうだろう」がPO&デザイナーさんとエンジニアでズレていた部分があり、開発側の設計が進んだ後にそのズレが発覚する、ということがありました。
miroで概念を具体化した時点からこまめに連携していれば、もう少し早くズレが発覚して手戻りが無かったかも、と思いました。
次回からは:
- 設計が形になり始めたら途中でも良いのでこまめに投げる
- 設計初期は何事もなくても定期的に同期的な時間を作ってみる
- 基本設計の段階から全員で取り掛かってしまったので手隙になるメンバーが出てしまった
-
チームメンバーの認識を揃えながら進めたいという意図から全員で基本設計を進めた。
認識を揃えながら進められたことは良かったが、それゆえ進行がブロックされるような事態になると手が空いてしまうメンバーも出てきてしまった。
次回からは:
- 他のタスクがある状態で、調査や基本設計は少数メンバーで始める
- チームメンバーの認識を揃えるのはその後でも大丈夫かもしれない
- 目標達成を一番に考えられるメンバー
- 「あれもこれも手を入れたい！」という気持ちを持っても目標達成のために優先度を考えられるメンバーばかり！その上で「ユーザー体験を考えるならこの設計はできない」という観点も忘れないのが素敵です ✨
- UXに強いこだわりを持つデザイナー
- デザイナー職の方はUIにこだわりを持つ方が多いと思いますが、GLOPLAチームにはPOと比肩するレベルでプロダクト目線に強いデザイナーが居ます。 作っている側でも整理が難しい概念はそのまま画面に出すとユーザーも混乱してしまいますが、設計に引っ張られているとなかなか思い付かないようなUIで解決された時は感動しました。 QCDバランスを考えつつユーザーに少しでも使いやすいプロダクトにしたいというプロフェッショナルな姿勢もGOOD！ 👍
- 視覚思考的なエンジニアと言語思考的なエンジニアの両方がチームに居た
-
自分はかなり論理的思考、構造的思考に偏った言語思考型ですが、同じチームにビジュアルで考える視覚思考型のエンジニアが居たことで、設計やユーザー体験を多角的に検証することができました。
多様な考え方のエンジニアが居ることの素晴らしいメリットですね！
※かなり簡略化したモデルで、実際にはここに三重くらい関連モデルが絡まっています。
倒すためにやった（やっている）こと
概念や関連付けが難しいため、「認識のずれを最小限にする」「要件を実現できるかを確認する」 ための工夫が多くありました。
もっとこうすればよかった
あってよかった素敵なメンバー
おわりに
現在もこの改修は進行中ですが、「あれ、ちょっとズレてる？ヤバいかも！」⇒すぐに集まって軌道修正する！という対応を機敏に取れるので、難しい案件でもむしろワクワクした気持ちで挑めています。
GLOPLAチームのコミュニケーションの強さ、アジャイルマインドの強さがgatherやmiro等のツールでブーストされており、ユーザーに価値提供できるプロダクト開発を技術負債やDeliveryも配慮しつつ進められる、合理的判断（≒整ったロジック）で肌が潤うエンジニアには最高の環境ですね！✨
そんなGLOPLAチームですが、絶賛採用強化中でございます！
コミュニケーションを重視し、顧客に価値提供できるプロダクトを柔軟に開発できるGLOPLAチームにご興味持たれた方はぜひカジュアル面談をしましょう！ 🙋