dotHatchスクラム開発について
今回は事業創造プラットフォーム「dotHatch」のスクラム開発についてdotHatchの開発担当（伊藤 明彦さん、遠藤 俊輔さん）にお話いただいた内容をご紹介いたします！
dotHatchとは？
dotHatchは、新規事業づくりを行う上で多くの企業が実現できていない「新規事業のプロセス化」「KPI管理」「経営資源の最適化」を実現するプラットフォームです。
新規事業のアイディエーションから、仮説作り、検証結果をチーム間で共有し、継続的改善を繰り返していきます。各プロセスにおける、KPI設定や達成状況、リソース管理を可視化し適切な管理を促すことで、新規事業の成功確率を向上させることができるツールです。
スクラム開発を学ぶ前に…
Agile Manifestoについて
スクラム開発を学ぶ前に Agile Manifesto を理解する必要があります。Agile Manifesto は2001年にアメリカのソフトウェア開発の研究者たちが提唱した文書で、以下を価値として定義しています。
プロセスやツールよりも個人と対話
包括的なドキュメントよりも動くソフトウェア
契約交渉よりも顧客との協調
計画に従うことよりも変化への対応
また、これらを価値とするために、
「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」などの守るべき12の原則が存在しています。
この文書で定義されている概念が一般に「アジャイル開発」と呼ばれるものです。
ただ、Agile Manifesto だけでは具体的にどう原則を遵守するのかが明確ではありません。そこで登場するのがスクラム開発です。
スクラム開発は、「アジャイル開発を実践するための手法の一つ」で、手法は一つではなく、カンバンやXP（エクストリーム・プログラミング）など多くの手法が一般的に存在しています。
スクラム開発の役割について
スクラム開発では、以下３つ役割が定義されています。
これら以外の役割が存在してはならない、というものではありませんが、上記３つがスクラム開発において必須な役割となります。
これらの役割を持ったメンバーをスクラムチームとし、この中でスプリントと呼ばれるサイクルを回して開発を進めていきます。
スプリントは「1ヶ月以内」という定義がありますが、1〜2週間程度がよく採用されるケースかと思います。
各スプリントでは、主に以下4つのイベントを実施します。
スプリントプランニング
デイリースクラム
スプリントレビュー
レトロスペクティブ（振り返り）
PDCAサイクルをスプリント単位でまわす、という表現でも理解しやすいかもしれません。
プロダクトオーナーは、プロダクトバックログと呼ばれる「改善が必要なもの」を一覧化し、優先順位を付けます。開発者はそのプロダクトバックログを詳細化し、スプリント内で開発を進めます。設計、テスト及びリリースのための作業もスプリント内に含まれています。スプリント毎にプロダクトをアップデート、リリースするように計画を立てる必要があります。
もう少し正しく理解したい型は、ぜひスクラムガイドをご参照ください。
なぜスクラム開発なのか？
dotHatch の開発では「全機能を作ってからではなく、できた機能から順次リリースすることで、実際に使ってもらったフィードバックを聞きながらプロダクトを育てていく」というメリットを見据えて、スクラムを採用しています。
スクラムはよくウォーターフォールとの対比で語られることが多いですが、ウォーターフォールと比較して良い手法だ、ということは全くありません。ケース・バイ・ケースで最適な手法を選択すべきものです。
例えば、（過去に同じようなプロジェクトをすでにやっているなどの理由で）不明確な要素が少なく、要件やスケジュールが十分に精査できるようなものであれば、むしろウォーターフォールの方が効率的に進められる可能性があります。
スクラムはスプリント毎にすべての工程を行うので、テスト・リリース作業のコストやスクラムイベントのためのコミュニケーションコストが掛かってしまいます。
ちなみに、テストやリリース作業のコストは自動化によって、コミュニケーションコストはコロケーション（ここではスクラム部屋などの同じ場所で開発をすることを意味しています）やスプリントのサイクル期間を長くする、などの対策によって軽減することは可能です。
但し、スプリントの期間を伸ばせば伸ばすほどリリースタイミングや振り返りの回数が減るため、結果として価値提供や改善の機会が減る、というデメリットもあります。
なおアジャイル手法の中でスクラムを選択した理由は、dotHatch の開発メンバーの多くが過去経験したことがあることと他の手法のノウハウがあまりないこと、からです。スクラムでなければならない強い理由はありませんが、今の所順調に開発を進められていますので、特に変更する理由はありません。が、機会があればどこかでトライしてみてもよいかもしれないとは考えています。
他にも、スクラムの実践によって以下のような暗黙的なメリットが享受できると考えています。
dotHatch開発におけるスクラムの実践
dotHatchの開発では、１スプリント１週間で行っており、月曜日にスプリントプランニングで今スプリントで各人がやるタスクを決め、金曜日に今スプリントで開発した機能をプロダクトオーナーにレビューしてもらうスプリントレビューを行い、その後開発チームで振り返りをするレトロスペクティブを行っています。
当初、ベロシティ（１スプリントで完了したストーリーポイント）がなかなか上がりませんでしたが、今では以前よりも1.5倍ほどベロシティとなっています。
ではなぜ、ベロシティが向上していったのか。
以下の4つが考えられます。
Gather（バーチャルオフィス）でのコミュニケーションの活性化
dotHatchの開発チームメンバは物理的に離れたメンバー（東京以外の居住者）がいて、オフラインで集まることはなかなか難しいため、Gatherを利用したコミュニケーションを取っています。
また、相談や雑談をしやすいように日中はメンバは一部屋に集まっていつでも会話できる状態にしました。
これにより、不明点なども即座に相談し解決できるようになっていきました。スプリントプランニングの時間を長く確保
当初開発時間をとるため、スプリントプランニングに時間を割かなかったのですが、曖昧な部分が残ったまま開発に入り手戻りや遅れが多々発生していました。
そこでタスク毎に設計する時間をとり、その後チームメンバー内で内容に曖昧な箇所がないよう徹底し、その結果、開発をスムーズに進められるようになっていきました。スプリントゴールの明確化
当初1スプリントで行なうことを明確にしておらず、タスクがずるずると次のスプリントに持ち越すことが多くありました。
スプリントプランニングで、まず最初にスプリントのゴールを定めることにしました。それによりやらなければならないタスクが明確になり持ち越してしまうタスクも少なくなっていきました。レトロスペクティブにて振り返りの方法を変えてみた。
最初は、KPTA（Keep・Problem・Try・Action）の手法で振り返りを行い、次にスプリントで具体的な改善まで考えられるようになっていったと思います。
次に、KPTAの要素に加え、感謝を入れるようにしました。普段直接口では言えなかったことでもここで感謝を伝えることができ、チームとしても全体としてまとまっていった気がします。
その次に、スプリント内で発生した障害の発生原因を考察し、要因と対策をチームで話し合い、次スプリントへのActionまで決めていきました。
気をつけなければいけないポイントなどが共有でき、品質向上につながっていきました。
振り返りの手法を定期的に変え、マンネリ化を防ぎ改善するために考えていく行いを続けられたことにより、ベロシティの向上にもつながっていったと考えます。
正直、2月初めまではとても間に合わないと思える絶望的な状況でした…。
が、2月中旬あたりから徐々に上手く回り始めた感覚を持ち始め、なんとか目標としていた4月にdotHatchはGAを迎えることができました🎉
今まで改善の施策をしてきましたが、まだまだ変える余地はあるので引き続き施策を色々と打っていき、高いベロシティを保ちつつdotHatchの開発を進めて行きたいと思います💻