はじめに
前回の記事では、freee OSAKAのエンジニアリングマネージャーの竹田より、新規プロダクトの開発を成功に導くために何を大事にし、どういう考えで開発プロセスを設計していったのかをご紹介しました。
今回は、2名のエンジニアがゼロから始まった不確実性の高い新規プロダクトの開発で何をどこまで準備し、どのように開発を進めていったのかをエンジニアの目線でご紹介します。前半部分のアーキテクチャの選定とスクラム開発の準備を増田が、後半の開発フェーズを熊倉が担当します。
ユーザーに与える価値とアジリティを軸とした開発体制
プロジェクト管理freeeは、開発を始めてから約6か月でβリリースをすることができました。とはいえ、綿密な計画を立てて滞りなく進めたわけではなく、プロジェクト開始時点では大枠の画面イメージは決まっていたものの、機能詳細やMVPの範囲、開発体制、さらにはリリース時期も決まっていませんでした。
開発チームには裁量が与えられており、言語やフレームワーク、開発スタイルなど、何も決まっていない状態から、今の開発体制を構築しました。開発準備は3週間、開発からβリリースまで約6ヶ月を経た今、開発チームを一言で表すならば「マジ価値（ユーザーにとって本質的な価値があること）」を提供するためにアジリティを追求してきたと言えるでしょう。
「アジリティ（Agility）」には「機敏」「敏しょう性」「軽快さ」といった意味があります。新しい領域には、不確実性が高い状態が付きものです。そのような状況に対して、綿密な計画を立てるのではなく、「やってみて駄目だったら、また次の一手を考える」というフィードバックループを繰り返し高速に回し、私たちは新しいプロダクトを生み出しました。
マジ価値とアジリティとを意識しながら作り上げていった開発体制。それらはどのように組み立てられたのか、「開発準備」「スクラム開発」「リリース」3つの工程に分けて解説します。
新規プロダクトの開発準備
新規プロダクトの開発を行うには事前準備が必要です。今回は開発プロセスから開発言語、フレームワーク、実行環境まで、ゼロから考える機会が与えられました。期間は2週間。本格的に始まる開発にあわせ、気持ちよく開発できるよう、以下の観点でゴール設定と技術選定を行いました。
- DB設計から画面設計まで一気通貫で迷いなく作れること
- 誰がやっても同じように開発できること
- 非同期処理が行えること
- テストが迷いなく書けて、自動テストが実行されること
これらを実現するために、行った調査・判断を紹介します。
不確実性が高い中で、あえて「教科書通り」に立ち返る
もともとfreee OSAKAの開発チームはスクラム開発の型を崩した2週間スプリントで開発を回していました。具体的には、スプリントの会議体の中で、振り返りとプランニングの部分を省略し、ベロシティーの計測も行わず、開発の区切りを1時間のスプリントイベントのみとしました。スクラムを回すための会議体は、参加者の時間を確保せねばならないにもかかわらず、それに見合った効果が出せないと判断したためです。
今回、スクラムの回し方に課題意識を持っていた、新卒エンジニアがスクラムマスターの役割を買って出てくれました。他のチームからスクラムについて学び、教科書通りのスクラムを回すことに価値があることを提案してくれました。
freee社内にはチームにスクラムを導入するためのサポートをしてくれるコーチがいます。プロダクト開発開始の1週間前に、プロダクトオーナーとエンジニア全員が改めて基礎からスクラム開発の勉強を行い、省略していた会議の振り返りとベロシティーの計測を行うことで、理想と現実とのギャップを認識し、チームで改善していくことでチームが強くなることを学びました。
その後、2日間かけて、インセプションデッキを作成しました。メンバー全員でプロダクトの方向性を認識するだけでなく、メンバー同士の考え方や人となりを知ることができました。
スプリントの期間に関しては今回は不確実性がより高く、2週間サイクルの開発では、手戻りが発生してしまう恐れと、軌道修正のタイミングが空いてしまうため、1スプリントを1週間で回すスクラム開発を採用することにしました。
プロセスを変えたことによる効果としては、スプリントを重ねるごとに開発プロセスと生産性が改善され、アウトプット量が増加していくのを感じるようになりました。また、自分たちの生産性がどれほどのものか定量的に計測することで、新しい機能開発でもどのくらいの期間を変えれば完成するのか予測を立てることができ、決められたβリリースまでに何をしなければならないのかを逆算して考えられるようになりました。従来のやり方では、決められた期間の中でここまで順調に物事は進められなかったと思います。
インセプションデッキ完成記念の一枚。確固たるチームの合意が取れた瞬間でした。
実現過程での不確実性をなくす基本設計
おぼろげではありますが画面イメージは何パターンかあったので、システムの基本設計を行いました。新規プロダクトにおける設計では、手戻りが発生すると後々面倒になる部分、すなわちデータモデリングを中心に設計を行いました。きっちりとした型はないのですが、私はだいたい以下の流れで情報を整理し、設計を行っていきます。
- ユースケース図の作成
- オブジェクトの洗い出し
- ER図作成
UXチームでもOOUIに従い、オブジェクトの洗い出しを行っているので、抜け漏れがないかを確認を行うことができました。エンジニア観点では、データの関連性、状態の保持の方法、整合性の担保、データ量を加味した設計をしました。作成したER図を元に実際にクラスを作成し、オブジェクト間の操作に違和感がないかの検証を行うことで、実現過程での不確実性を潰していきました。
全員の納得を得るための言語・フレームワークの選定
言語、フレームワーク選びはとても重要です。プロジェクトの開発速度に直結しますし、メンバーのモチベーションや、運用が始まったあとの保守にも影響を及ぼします。さらに組織を大きくしていくうえでブランディングや採用にも影響するので、慎重に行いました。
弊社の既存製品はRuby on Railsで書かれており、エンジニアの構成もRubyエンジニが多数を占めています。しかし、freee OSAKA発足時からいるエンジニア4人のうち、2人は前職でGo言語を扱っていました。さらに関西のGo言語勉強会の運営メンバーでもありました。
メンバーのスキルマップを作ったり、技術検証を行ったりしましたが、その中でも一番重視したのは、コードを書くことに悩まず（フレームワークが提供してくれる部分に沿うことで、ベース部分は誰が書いても同じようなコードになる）、プロジェクトで達成したい世界観を高速に価値検証できるかということでした。その観点では、Go言語はベストな選択ではないということでRubyを採用することになりました。
一方で、Go言語のマルチプラットフォームで動くコードが生成できる特性を生かし、工数入力をサポートするアプリを作る際に必要となる、WindowsやMacといったOSにインストールする部分で利用しようということで、Go言語を扱っていたメンバーにも納得感が得られた状態でプロジェクトはスタートしました。
レビューを重視した開発環境
開発環境の整備では、スクラム開発が回し始められる状況を目指しました。そのためには、最低限以下の準備が必要と考え、準備を進めました。
- リポジトリがある
- 自動テストが実行される
- コードレビューが行える
- スプリントレビュー用の確認環境がある
この中でもスプリントレビューを行うための環境が、最初からあったのはとても良かったです。初期の段階で確認環境を用意するのは、割と大変なイメージがありますが、我々のチームはPaaS（Heroku）を活用して、最小限のコストで確認環境を用意しました。
pull Request単位でHeroku上に確認環境が立ち上がります。開発フェーズが始まったばかりの段階でエンジニアがレビューをする際、試行錯誤を繰り返している作業の合間に、手元に環境を用意しなくても動作確認が行えるのでコードレビューが捗りました。また、スプリントレビューの時点で動くものを参加者全員で見るのはテンションがあがりますし、レビューを行ったあとも、デザイナーのデザインチェックや、QAチームのテストケース作成場として活用されました。
実際のプロダクトはKubernetes上で運営されており、環境構築作業は後のスプリントタスクに積んで作業を進めました。環境構築ができた時点でHerokuの動作確認環境は役目を終えましたが、アジリティに寄与した良いアプローチでした。
これらの準備が整い、開発合宿にてチーム全体が目指すべきMVPの認識合わせを行い、本格的な開発を開始しました。
