こんにちは、myTOKYOGAS フロントエンドチームを担当している中嶋です！
本稿では、myTOKYOGASの内製開発に取り組むウェブアプリのエンジニアチームがどのように他チームと連携しながら新規機能の開発を行なっているかをご紹介させて頂ければと思います！
新規機能開発について
我々が日々開発や保守・運用を行っているmyTOKYOGASは、現在たくさんのお客さまからご質問やご要望を頂いております。それらを受けてエンジニアチームは、ビジネスチームと密にコミュニケーションを取りながら、開発工数、提供できる価値、期待されるコスト削減効果などを考慮して取り組むべき課題の優先度について議論しています。新規機能開発を進めていく際には、前提としてそもそもなぜこの機能を追加する必要があるのか、お客さま視点でどのような不便を解消するものなのかといった背景や動機をビジネスチームと双方に認識を合わせながら進めていくよう努めています。モダンな技術を採用しても、ビジネス上価値に繋がらないものを生み出していては本末転倒です。同じ事業部内に内製開発チームを立ち上げた背景の1つとして、所属するチーム間の垣根を無くしメンバー全員がサービスや事業の価値を念頭に置きながら、チーム横断的に連携して機能開発を行なう体制を作る必要があったことが挙げられると思います。ビジネスチームからの要望に応えて、ただ闇雲に言われた通りのものを開発するのではなく、プロダクト志向で自社サービスの開発にコミットしていける環境ではないかと考えております。
ビジネスチームとの連携
我々エンジニアチームは、スクラムイベントの中でスプリント・プランニングやデイリースタンドアップなどの場でビジネスチームと連携しながら開発を行なっています。それぞれのスクラムイベントの中で、どのように開発を進めているかを簡単にご紹介させて頂ければと思います！
スプリント・プランニング
まず最初に、開発が必要な背景、開発するスコープの整理、機能の概要、などについて、スプリント・プランニングの場でビジネスチームから説明して頂きます。
このスプリント・プランニングの段階で本機能が実際に使われるユーザーストーリーの全体イメージ、myTOKYOGASサポート窓口やお客さまの視点でどのような不便や業務負荷などを解消する機能なのかといった業務的な内容に対する解像度が上がります。また、画面ごとに詳細な機能要件や非機能要件なども一緒に確認していきます。
また、優先度を検討する上で本機能が追加されることでどのくらいの改善効果が見込めるのかといった費用対効果の観点でも議論します。エンジニアチームは必要な開発工数を大まかに見積もり、ビジネスチームはどのくらいの改善効果を見込めるか試算します。エンジニアチームでは、開発タスクの相対見積もりにHatjitsuというプランニングポーカーシステムを利用しています。相対化の基準となるタスクについてチームのメンバー間で開発工数の認識を合わせた上で、新規機能のタスクに対する見積もりの精度を高められるよう改善しながら取り組んでいます。
デイリー・スタンドアップ
いざ、新規機能開発を進めていく段階に入ると、デイリー・スタンドアップの場で開発の進捗確認を行いながら、要件の再確認なども同時に行なっていきます。
実際に開発を進めていく中で要件の不足や考慮漏れが明らかになることもあるかと思いますが、そのような場合でもビジネスチームと連携しながら業務的な観点やお客さま視点での影響を考慮しながら迅速かつ柔軟に対応方針を判断し、開発効率を下げないよう双方に連携しやすい体制が整っていると思います。また、デイリー・スタンドアップの中では、毎回雑談の時間を設けることで心理的安全性を下げないよう自由に発言しやすい雰囲気作りも行なっています。我々のエンジニアチームでは基本的に在宅で開発業務を行っているため、雑談をする機会を意図的に作らないと会話する機会があまりありません。そのような課題意識から日々のデイリースタンドアップの場で軽い雑談の時間を設けて、話したいネタがあれば事前に記載して頂いたり、特にない場合は今日の気分を5段階で入力してもらって体調が悪くないかなどを確認するようにしています。
リファインメント
スプリント・プランニングの段階では要件が決まっていなかった機能や差し込みのタスクなどに対応しなければならないことがあるかと思います。我々のチームではそのようなタスクについてリファインメントの場で開発工数の相対見積もりや優先度の順位づけを行うようにしています。突発的な差し込みのタスクなどに対応する必要があった際でも、プランニング当初に描いたスケジュールを大きく崩さないように優先度を調整しながら開発を進めていきます。
スプリント・レビュー
スプリント・レビューでは、ビジネスチーム以外のメンバーも交えながら全員でレビューを行います。この段階で機能開発が完了していれば実際に開発環境で実装した機能を動かしてもらいながら、機能面やデザイン観点で不備がないかを確認していきます。また、複数のスプリントにまたがって実施するような大型の案件については、途中までの経過を確認しながら、今後改善できる点や他に検討すべき項目がないかを議論することで、プロダクトをより良いものに仕上げていきます。
レトロスペクティブ
スプリントの最終日は、メンバー全員でレトロを開催して振り返りを行います。問題があったことの振り返りや議論はもちろん重要なことですが、感謝のコメントやポジティブなフィードバックについても、積極的に書いて頂いているように思います。また、問題として取り上げられた中で特に優先して解決すべきものについてメンバーで投票を行い、次回までに実行する対応策について議論し、具体的なアクションに落とし込んで取り組むようにしています。
おわりに
今回はスクラムイベントを通じてエンジニアチームがどのようにビジネスチームと連携しながら内製開発を行っているかをご紹介させて頂きました！スクラムはアジャイルな開発を実現するための手段の1つであって、目的ではありません。エンジニア個人としての成長機会を重視しながらも、チーム全体としての生産性を最大化できるよう、今後も試行錯誤しながら改善をしていきたいと思ってます。直近では、日々の開発業務がマンネリ化してモチベーションを下げないようにするために業務時間の一部を利用してリファクタリングを行ったり、技術書を輪読する会を開催するなどの取り組みを検討しています。
私たちのチームでは、ともに働く仲間を積極的に募集しています。少しでも興味をお持ちいただけましたら、ぜひカジュアル面談からご応募ください！
Application Developers
www.wantedly.com
SRE
www.wantedly.com
最後までお読みいただきありがとうございました。また次回の記事でお会いしましょう！
