不確実性とうまく付き合っていくためのQUANDO流開発手法
こんにちは！
クアンドでスクラムマスターをやっている新家（しんや）です。
今回はクアンドで実際に行なっている開発手法について紹介したいと思います！
現在、クアンドのエンジニアチームは社員6名で、パートナーやインターンを含めて約15名程度の組織となっております。同規模の開発組織で働かれている方や、弊社への参画を検討していただいている方への参考になれば幸いです！
💪開発手法
クアンドでは、スクラム開発を採用しています。
とはいえ、厳格なスクラム開発をしているかというとそうではないので、スクラム開発に至った理由も含めて、少し説明させていただきます。
😵💫スクラム導入前に感じていた不安
スクラム導入前のクアンドでは、プロダクトの開発において以下のような不安がありました。
予定しているアプリを完全に作りきってリリースしたとして、売れるかわからない
ビジネスチームが開発完了に合わせてすぐに販売できるように事前に動いておきたいが、開発の進捗が読めない
あまりにも開発完了のゴールが遠過ぎて進捗している実感がない
🤩スクラム開発手法の導入
そのような不安を解消し以下のような状態にするため、必要な要素をスクラム開発の手法の中から取り入れています！
ユーザー体験として必須な機能から開発していき、ビジネスチームが判断しさえすればいつでもリリースできる
機能の優先順位が変わったとしても、柔軟に対応できる
特定の期間内に自分達が開発できる量を知ることで、今後開発する機能を精度高く見積ることができる
実はクアンドとして、一番実現したかったのはいつでもリリースできる状態でした。 プロダクトとしてまだPMF(Product Market Fit)していない状況では、早い段階で実際にユーザーに使ってもらい軌道修正を重ねる必要があります。そこで、検証に協力してくれるユーザーが見つかったときに、ビジネスチームの判断ですぐにシステムを体験してもらうことができるようにしておけば、その後のプロダクト開発がとてもスムーズになります。
また、そのような状態にしておくことで、ビジネスチームから見るといつでも提供できるシステムがある安心感を得ることができるし、エンジニアチームから見ると不確実性の高い先々のスケジュール検討を減らすことができるようになると考えました。
💻実際の開発フロー
クアンドのスクラム開発は、1スプリントを1週間としています。（リリース頻度とは別）
スプリント内のイベントはこのような感じです。
定例で開催する会議としては上記のみで、他は開発を進めていく中で必要に応じて会議を設定するようにしています。
本来であれば、プランニングとリファインメント、レビューとレトロスペクティブは別で開催して、それぞれの時間をもっと長く取るべきだと思うのですが、まだ人数が小規模であり個々のコミュニケーションで補完できること、また会社のフェーズ的にも出来るだけプロダクト開発のピッチを上げたいという考えから、会議の時間は必要最低限に抑えるようにしています。
紆余曲折あって今の形に落ち着いたのですが、個人的にもこの規模の組織においては決まった会議体はこれくらいの量が適切かなと思っています。
🔖チケット管理
クアンドの開発は全てチケットベースで行なっており、管理ツールとしてはGithubのproject機能を使っています。
以前はBacklogやNotionでやっていたんですが、主に管理をする自分がGithubを使い慣れており（一応エンジニアだったので）、ユーザーストーリーの親チケットから開発子タスク、プルリクエストまでが同一ツール内で紐づいている方が情報の一覧性や検索性が良いという判断でGithubで行なっています。
↓こんな感じ
スプリントごとのベロシティ（完了したタスク総量）もGithub上で見ることができるので、この数値も見ながらスプリントレビューを行なっています。
スプリントを重ねるごとにベロシティが右肩上がりになっているのは良い傾向ですね😄
ここまで簡単ではありますが、クアンドの開発手法について紹介しました。
偉そうに紹介しましたが、まだまだ課題は山積みで改善の余地だらけなので、今の形をベースにその時々の状況に合わせて今後もどんどん変化させていきたいと思っています！
最後に
そんな全てが手探りで何事も自分達で作り上げていく必要がある私たちですが、一緒に作り上げてくれる仲間を大募集中です！
私が勤めている株式会社クアンドは、日本の産業をアップデートする事をミッションとして社会課題に取り組んでいます。
特に、今まさにSynQというプロダクト開発を進めており、様々な職種のメンバーを募集中です！
もしご興味を持っていただいてお話だけでも！という方もぜひご連絡ください！
▼ご連絡はこちらから