こんにちは。ものづくり推進部下地と申します。

もう試されている方もいらっしゃるかと思いますが2020年1月29日に毎日ポイント をリリース致しました。

5つのミッションをクリアし成果報酬としてau WALLETポイントがもらえるサービスとなっており、au キャリア外の方も auID は発行できますのでこれをきっかけに試して頂けると幸いです。

※推奨環境は、Android：5.x以上(Chrome51以上)、iOS：10.0.x以上になります。

本稿ではこの”毎日ポイント”の開発の取り組みについて説明させて頂きます。 なお、毎日ポイントは“ものづくり” の為の開発プロセス試行を踏襲しております。

チーム構成

初期メンバーはフロンエンド2名、バックエンド3名、インフラ1名、スクラムマスタの計8人でした。途中入れ替わりがあったものの最終的には以下の構成となりました。

正直な所、全体アーキテクチャ設計、システム設計からリリースまでをスクラムで回した知見がなかったのでチームに最適化した結果、開発メンバーのみで構成された変則的なスクラムチームとなりました。

※品管、デザイナー、アナリスト、プロダクトオーナーはプロジェクトに参画していたものの、開発によった話が多かったので必要な場合のみスポットでスクラムイベントに出てもらっていました。 現在は品管、デザイナー、アナリスト、プロダクトオーナーをメンバーに加えスクラムを回しています。

課題

課題を個人の問題ではなくチームの問題にしたかったこともあり、課題をある程度明文化する事から始めました。 大小様々な課題があったものの、その中でもDeveloper eXperience （以下DX）が上がる課題を主に抽出しました。

• ミーティングが多い
  • ミーティングが多いと単純に開発時間が短くなりますよね。開発チームは開発に集中するのが理想です
• 属人化
  • スーパーマンになるのは気持ちいいものの組織として個への依存はできるだけ取り除きたい
• DXの向上
  • DXが向上すると、開発効率やベロシティが向上し、結果ユーザーにいち早く価値を届けることができるのではないかと考えています

改善方法とアクション

課題に対するアクションは図の通りです。

詳細は下記になります。

• 開発コアタイム
  • 13:30 〜 16:30の3時間は開発以外のミーティングを禁止にしました
    • ミーティングを入れられる時間が午前中のみになるので入れる側もより精査しメンバーを選定するようになりました
  • ただしスクラムマスタはステークホルダーとの会話があるので特例としました
• モブプログラミング
  • ものづくりプロセスからモブプログラミングを導入。フロントエンド2チーム、バックエンド1チーム、インフラ＋スクラムマスタの系4チームで稼働しました
  • 原則チームで動くので人からチームへの依存になり結果、属人化排除に成功
  • ユーザーストーリーによってバックエンドチームがフロンエンドチームに参画したりとシームレスに開発を行う事ができ良い体験ができました
• 設計フェーズを手厚く
  • バックエンド、インフラメンバーを中心にアーキテクチャ設計からメンバー全員で行いました
    • メンバー全員参加なのでコストは高いもののアーキテクチャを1から設計する機会は少ない + アーキテクチャ設計に腹落ちして開発に臨んで欲しいと思い決行。
    • 設計の知見も伝搬でき学びがとても多かったです
  • ユースケース、シーケンス設計に時間をかけた
    • 約1ヶ月程設計していました。メンバー内からも設計にコストをかけ過ぎではないのか？と指摘を貰いましたが結果かけてよかったと強く思います
• タスクの完了定義を変更
  • 今まで完了の定義が実装のみだったがUnitTestを追加。追加した事でUnitTestを書く文化が浸透しました
    • メンバーで協議し書かなくていいと判断したものもあります
• 仕様の相互確認会の実施
  • 成果物の乖離があってはいけないのである程度実装及び設計後ステークホルダーを呼びメンバー全員で仕様及びユースケースの確認を行いました

結果、プロジェクトにどう影響があったの？

結果は・・・。

スケジュール遅延0回

開発効率、体験向上の影響なのかリリース日はもちろんの事、これまであってないようなものだったコードフリーズ日も遅延なし。

品質が凄く良い

技術の習熟度等他にも要因はあったものの、これはモブプログラミング + 設計フェーズを手厚くした事による影響だと思っています。

性能試験では高負荷をかけても落ちないから面白くないというメンバーが出たり(私の事です)、 総合試験に関してはメンバー全員が試験項目書が間違っているのではと？逆に不安になる程バグが少なかったです。

実装期間が3ヶ月と短かったのですが不具合も少なく全体的に高品質だったと思います。

※因みにバグ件数ですが、機能バグ0件、デザイン崩など軽微なバグが27件でした。

仕様の相互確認会で安心し開発に尽力できた

要所要所で行った事でステークホルダー、開発メンバー共に成果物への安心感が得られ想像以上に体験がよくとても好評でした。

良い事ばかり！？とは言え課題も・・・

良い事ばかり記述していますが課題もあり、、

ものづくり推進部はmedibaにおけるものづくりのプロセスを醸成する組織です。 今回実施したものづくりプロセスを組織に伝搬したいものの方法等を見いだせていないのが現状です。

良い体験等をどのように伝搬、醸成していくのもミッションの1つなので 引き続き試行錯誤して行きたいと思っています。

まとめ

巷ではアジャイル開発では設計不要説等ありますが、設計は大切だと再認識できたり DX向上の為チームに寄り添いチームとして成長していく事で、一体感はもちろんの事 高揚感も得られとても良い成功体験を得ることができました。

今後は課題解決とチーム全体の体験向上をより一層改善したいと思っています。

余談

スクラムを回していると気になるバーンダウンチャート。 プロジェクト開始時はきれいなバーンダウンではなかったものの最終的にはキレイなバーンダウンを描くことができました。