ビットバンク流 アジャイル開発(Bentham)とプロジェクトマネジメントについて

はじめに

bitbankでは定期的な機能改善を実施しています
金融機関のシステム開発と聞くと、かなり厳格なWF（ウォータフォール）で推進しているようなイメージがあるかもしれませんが、弊社では一部アジャイル式の開発手法を用いて継続的な機能改善を実現しています

本記事ではそのように至った背景と実際の手法についてお話しします

対象読者

• アジャイル開発手法、スクラムについて概要を把握している
• bitbankでのアジャイル開発の手法が気になっている
• アジャイル開発が必要となった背景を知りたい

アジャイル開発とは

今回は詳細は割愛しますが、イテレーションと呼ばれる短い開発期間単位を採用することで、リスクを最小化しようとする開発手法のことです。
その中でも特にスクラム開発手法を参考にした開発を今回は「アジャイル開発手法」としています。

普段のbitbankでの開発について

普段のbitbankではいわゆるWF（ウォーターフォール）型の開発をおこなっています。

金融機関という特性上「監査の観点」から設計書や要件、あるいはリリース時の手順などを残す必要があり（もちろん必要以上のリスク管理を会社として自主的におこなっている側面もあります）独自のフローを組み、成果物を残して推進しています。

この独自フローはかなり洗練されており、基本的には無駄なく適応可能であり、いわゆるWFでありがちな認識不足による要件定義の手戻りや、「次何をやればいいかわからなくなる」という状態を防ぐことができます。
※利用しているフローについては別の機会にて説明します。

アジャイルが必要になった背景

ではそのようなフローがある中ではアジャイル式の開発は必要ではないように思えます、ではなぜ今回の取り組みが必要だったのか。

こちらは実際にあった要望です。

そしてこの要望に対し以下のように対応しました。

このように、使いやすさの観点で大事ではありますが非常に細かい修正です。
このためだけにわざわざ要件定義や設計書を作成するか！？と問われると・・・

いかに効率化されたプロセスといえどもやや冗長です。
修正範囲に対してコストが大きいです。

このような要望に、より素早いサイクルでユーザーの期待に応えるために、アジャイル開発チームが爆誕したのです。

アジャイル＝プロセスの省略化ではない

ここまで書くと、てっきり「厳格な要件や設計を端折るためにアジャイルを採用した」あくまで「アジャイルだから設計や要件は不要」という解釈はしていません。

要素は色々ありますが、一言で言うなら「よりユーザーと向き合うチーム」です

ユーザーと一口言ってもbitbankを利用されるにはさまざまなお客様がいます。
投資に慣れている方、初めて仮想通貨を始める方、法人のお客様...etc

そうしたユーザーの中で特に初心者〜中級者向けにUXをより改善させていくためのチームが必要だったのです

アジャイルチーム「Bentham（ベンサム）」の発足

上記の理由により爆誕したのがアジャイルチーム、（通称:「Bentham（ベンサム）」）です
「功利主義」を提唱したジェレミ・ベンサムという人にあやかってこの名前になっています

発生した課題

このようにして発足したBenthamですが、順調に成果を出していった・・・というわけにはいきませんでした。

実際に運用し始めて数ヶ月、より素早いサイクルでユーザーの期待に応えるという目的で結成したにも関わらず、リリースの頻度が上がらず、PDCAのサイクルが遅くなる・・・という課題が発生しました

理由として
・当時はメンバーの流動性を確保するためチケット駆動開発を採用していた

どういうことかというと

決められたイテレーションを厳守するのではなく、チケットの達成条件をクリアするまで開発を続ける。という手法によるもの。

これには背景があり、専属でチームメンバーがいたわけでなく各々WFでのプロジェクトを抱えてた状態でBenthamチームを兼任している状態でした。

その結果、1つのチケットで実装に想定より時間がかかり、リリースが遅れるといった事態が発生
→バグ対応などでスコープがどんどん拡大
→結果としてリリース頻度の低下を招き、PDCAのサイクルが遅くなる・・・という負の連鎖を招きました。

課題への対処

では、発生した課題にどのように対処したかというと・・・

まずはメンバーにヒアリングをしました。
全体にの場で聞くのではなく個別に1on1でじっくり話を聞きました。

無骨なやり方ですが、まずは課題を深ぼることが優先です。
特別なことは何もしていません。

その結果見えてきた問題点としてはプロダクトとして目指すべき目標、すなわち「プロダクトゴール」の浸透不足でした

そもそも社内外から上がるさまざまな課題に対し、継続的なアクションをおこなってきました。それはプラスの側面もあった反面、チームとしてどこを向いているのか、が分かりにくくなってしまっていました。

特にbitbankのサービスは販売所・取引所・貸して増やすなど多々あり、利用するユーザーも仮想通貨玄人から、今日初めてbitcoinを触る人などさまざまです

ゴールが固まらないまま進めてしまったことで、向かうべき方向がぼやけてしまっていたのでした。

改善アクション

そこでまずは向くべき方向を定め、「プロダクトゴール」を明確化し、各イベントでPO（プロダクトオーナー）より説明することで意識づけをしました。

さらにもう一つ、今までのスコープ重視のチケット駆動開発から、厳密にtimeboxを切ったスプリント駆動での開発に変更しました。

これには期日感を持って取り組む意義の他、強制的に期間を区切ることで、ゴール意識や課題を見直すタイミング、つまりより短いサイクルでPDCAを回すように変更した意図があります。

Benthamで扱っているイベントと役割

ここからは、どのようなイベントを扱っているか説明します。

原則3週間スパンで１スプリントを回しています。
bitbankに合わせた独自のイベントやルールなどもあります。

グルーミング

後述のプランニングの前提となるイベントである

• 目的
• PBIの要件とスコープを明確にする
• PBIをReady(着手可能)にする
• スクラムイベントの「バックログリファインメント」とほぼ同義
• 開催頻度
• 毎週

プランニング

いわゆるスプリントプランニングイベントである

• 目的
• スプリントのスコープ(対応PBI)を明確にする
• 開催頻度
• スプリント毎

Daily Stand UP(朝会)

毎朝の進捗報告と共有のイベントである

• 目的
• 毎日の進捗や課題の共有等
• 開催頻度
• 毎日(朝)

スコープ確定会

リリーススコープを確定させるイベントである

• 目的
• チーム全体で対応した内容を共有する
• 開催頻度
• リリース毎

ふりかえり

• 目的
• プロセスを振り返り、次にPDCAを回す
• ホワイトボード(Miro)を利用し、和気藹々と
• 課題は、必ず対応するアクションまで落とし込む
• 開催頻度
• リリース毎

※ある日の振り返りボード

Benthamの今後と実績

Benthamでは今まで27スプリントを回し、実際のUX改善に大きく貢献してきました。
社内外からもお褒めの言葉をいただきました

（ある日のTwitterより）

（ある日の社内Slackより）

数字としても販売所の売上向上に貢献したという結果が出ています。
まだまだ改善するポイントもありますが、引き続きアジャイルの良さを取り入れることでより加速していけると考えています

まとめ

柔軟さを取り入れながら推進しているbitbankのプロジェクト推進
参考になれば幸いです