PR

カブドットコム証券は新サービスの開発でアジャイル開発手法を全面採用した。開発中は進捗の可視化によって関係者の信頼を得ることに力を注いだ。その結果、ウオーターフォールよりも開発期間を10カ月短縮し、開発費を6割削減できた。

 カブドットコム証券(カブコム)の新サービスとなるアプリ開発プロジェクトの続きを解説します。要件定義セッションの合宿を終えた翌週の2018年5月14日から早速、開発チームを招集しました。6月末から7月頭に実施する予定の社長・副社長向けのデモンストレーションに向けて、全員で課題を洗い出しました。

 開発基盤の構築からスプリント計画まで、多岐に渡る項目を決めました。具体的には下記のようなものです。

  • 見える化と大部屋の方針、ファクトコントロールの徹底
  • スクラムマスターや開発チームとしてのミッションの確認
  • 合宿での未決項目の逼迫度合い(合宿のおさらい、設計とアプリのおさらい)
  • 6月末までに実現する機能の確認(ゴールイメージの確認)
  • サーバー側とフロント側の技術検証ポイントの確認と実施計画(スプリントへの配置)
  • アプリ実行環境と基盤の構成やコンテナ基盤の要件出し
  • 開発言語やデータベース(DB)環境、開発ツールの確認
  • 既存連携や認証方法の確認
  • 開発チームと現場に必要な備品
  • 直近計画と7月頭までのスプリント計画

 6月末~7月初旬に計画した、社長・副社長向けのデモが、最初のリリースポイント(締め切り)です。2週間のスプリントで開発を進めました。

 開発チームは実装すべき課題(プロダクト・バック・ログ)だけでなく、事前準備(開発環境やテスト環境、バージョン管理の仕組みづくり)も同時並行で進めました。このため、最初のスプリントでは環境構築が大きなウエイトを占めました。

 加えて、今回のサービスは自社以外の他システムとの連携が必須でした。開発チームはリスクヘッジのために、外部連携を早めのスプリントで実装・確認しました。

改修要求に費やす時間を把握

 外部連携で仕様の間違いによる動作不良が発生すると、内部要因(自責)と外部要因(外部他システムへの改修要求)に切り分け、全てをバックログとして明確にして、外部チームと即座に共有しました。外部への改修要求がどれ程の時間(期間)で解決されるかを把握するよう努めました。こうして次第に、仕様の間違いの解決にどれだけ時間的な影響があるのかが分かるようになっていきました。

 開発を依頼した電算システムのチームは数多くの基幹系システムをアジャイル手法で開発した経験があるので、このように遅延リスクを軽減させながら作業を進めることができたのです。スプリントの作業状況を示すバーン・ダウン・チャートで計測していくと、開発チームがこのサービスや環境に慣れるに従って、生産性が上がっていくのがよく分かりました。

 初期のころはスプリントで課題を多く残してました。ですがプロジェクトを管理するシステム統括のメンバーに「経験とともに生産性は上がるはずです。現時点で悪くても見守ってください。彼らが毎日の振り返りで何に気付き、どう改善しているかに着目してください」と話し、開発チームへの信頼が損なわれないように努めました。

 バーン・ダウン・チャートとは別に、開発実績をトラッキングしたデータを見ると、イテレーションを経るごとにタスク数が増えていました。これは、タスクの粒度を精緻にしたためです。100時間当たりの消化タスク数は、精緻化によって短くなった1タスク当たりの時間に反比例していました。

図 「100時間当たりの消化タスク数」と「1タスク当たりの実績時間」
図 「100時間当たりの消化タスク数」と「1タスク当たりの実績時間」
トラッキングデータで分析
[画像のクリックで拡大表示]

 これらの事実から、この開発チームは1つのタスクにかける時間が一定であると分かります。いわば、一定のリズムを刻みながら作業を「流して」いるのです。このことは、現場の雰囲気にも好影響を与え、関係者への信頼感にも影響するのです。