スピード優先の自由なスタイルで開発がスタート

数回にわたり、そろタッチ開発の進化の話や現場の話を少しお伝えしていこうかなと思います。

子育てママが集まってアプリをリリース！どうやって開発した？

もともと、そろばん教室からスタートしている当社（株式会社Digika）は子育てママが集まって、どのようなやり方をすれば子どもたちが暗算を習得できるかということを考え、いろんな教材・手法を試行錯誤しながら何度も作り直し学習方法を発展させてきたという歴史があります。
Webサイト参照→ https://www.sorotouch.jp/company/mama.php

そんなわけで、当初からタブレットアプリで暗算学習方法をつくっていこうと思っていたわけではないので、ソフトウェアエンジニアが会社のスタートから所属していたわけではありません。実現したい動きと結果を考えながら「こんなアプリにしたい！」とアイデアを出すことはいくらでもできますが、それを実際に開発できるメンバーはいませんでした。ということで、多くのスタートアップと同じように、外部の開発会社に協力いただいて2014年にアプリ開発をスタートしました。

まずはどんな機能が欲しいのかエンジニアがヒヤリングしてドキュメントにしつつ開発を進めていくわけですが、最初からゴールのイメージが見えている訳ではありません。できたものを見て、浮かんできたアイディアを入れ込み、改良を重ねていき、ダメだったらやっぱりやめて他の方法を探すといいたかたちの進め方で、まさにアジャイル開発（プロトタイピングに近い）ですね。

そして2016年にAppleのAppStoreでiPad用アプリの初期バージョンをリリースました。

利用者がどんどん増えて開発リソースを増員していきます

リリースしたサービスは紆余曲折もありながら軌道に乗り、ユーザーが増え、改善のリクエストも多くなり、盛り込みたい新しい機能がどんどん増えていきます。アウトプットのスピードを上げていきたいので、どんどんエンジニアを増員していきました。また、スタート時はエンジニアは全員外部依存でしたが、徐々に採用を行って少しずつ社内に開発者を確保していきました。
作った機能はいち早く使ってもらいたいので、リリースのタイミングは機能実装ができた時に随時。チケットベースで開発タスクを分けて、かんばん方式で進捗管理をしていました。

最初から後先を考えた拡張性のある設計にしていたわけではないので、継ぎ接ぎ的にシステムに機能追加をしていきます。

リリースサイクルを短くできる「ラボ校」という素晴らしい仕組み

そろタッチには「ラボ校」という枠組みの特別な直営教室があります。ここでは一般にリリースする前のバージョンの新機能を搭載したアプリが最優先で提供され、その効果を一番最初に体験してもらっています。新機能を十分試して、ここで実際に使って学習をしている生徒たち得たフィードバックを反映した後にAppStoreに提供するというかたちをとっているため、ラボ校ではアグレッシブにいろんな新機能や微修正などチャレンジを積極的に行っています。
そろタッチを開発するエンジニアは、基本的にラボ校の先生兼務を経験しており、肌感としてこどもたちにマッチするアプリ動きや機能の感覚を持っています。

これはなかなか他ではできない、そろタッチ開発の大きな強みの一つです。

継続的に発展するプロダクト開発としては、うまくいかない部分がでてきた

スピードを最優先で開発し、一刻も早いリリースをしていきますが、内部的にはいろいろと解決したい問題が発生してきます。
・すべてが「なる早」でリリース計画がなく、いつ何ができるかわからない
・要望が多くバックログが積み重なり、いつになったらどれぐらい消化できるかかわらない
・共通認識された開発の優先順位がない
・基本的に自分のタスクだけを扱うので、隣のエンジニアが何をしているか把握していない
・バグが発生した際にいつのどのリリースで発生したかトレースすることが困難
・開発のパフォーマンスはまったく計測することができない
・リソースボリュームが適切であるかわからない
・開発と改修が属人的になっていく
おそらく、同じような課題を経験している開発チームは多いでしょう。この生い立ちでサービス開発をしていくと必ずこうなるのが、WEBサービス開発のあるあるですね。
細かいことも、もっと大きいことも課題は書ききれないほどたくさんでてきました。

リリースから数年たち、我々が提供する暗算学習アプリの「そろタッチ」は、生徒・先生・教室運営管理者などを合わせると数万人が利用するシステムに成長しました。モバイルアプリとWebアプリと連携しながら提供されるB2B, B2C SaaSプロダクトで、見た目よりも中身はかなり複雑な機能や動きがあります。

開発をうまく回していくにはフレームワークが必要になった

ソフトウェアプロダクトの開発をスタートして6年ほど経過し、たくさんの暗算名人を世界中に排出し、サービスは順調に伸びています。これは何より素晴らしい成果で、チームとして誇れる実績です。しかし、開発としてはターニングポイントを迎えており、いろいろな面で改善の必要性が感じられていました。ここまでは自然な流れでしょう。

そしてスクラム開発の導入へ

2023年から、開発の進め方をガッツリとスクラムのフレームワークでやろうということにしました。スクラム開発がマッチするプロダクトには、以下のような特徴があります。

1. 不確実性が高い
2. • 要求や市場の変化が頻繁に起こる場合、スクラムは短期間のスプリントで進行するため、柔軟に対応できます。これにより、顧客のフィードバックを迅速に反映し、プロダクトの方向性を調整することができます。
2. 中身のしくみはけっこう複雑
3. • 大規模で複雑なシステムやソフトウェア開発において、スクラムはチームのコミュニケーションと協力を促進し、複雑な問題を小さく管理しやすい部分に分割して取り組むことができます。
3. 継続的な改善が必要
4. • スクラムは定期的な振り返り（レトロスペクティブ）を重視するため、チームはプロセスやプロダクトの改善点を常に見つけ出し、次のスプリントで改善を図ることができます。
4. ユーザーのフィードバックが重要
5. • ユーザーからのフィードバックを頻繁に受け取り、それを基にプロダクトを進化させる必要がある場合、スクラムはそのフィードバックを次のスプリントに組み込みやすく、迅速な対応が可能です。

といったことがあり、特に我々のようなウェブアプリケーションやモバイルアプリケーションなどのソフトウエア・サービス開発に向いていて、スクラムの持つ柔軟性と適応力を活かして、迅速な変化に対応し、プロダクトの価値を最大化することができます。

今やWeb系のサービス開発ではデファクトスタンダード的に採用されている手法であるということや、このとき新任CTO（私）が以前から経験があり、進め方を理解していたということも大きな理由ではあります。

導入にあたり、最初にやったこと

スクラムの導入にあたり、下記のような準備をしていきました。

• メンバー全員に一番ベーシックな書籍を配布（本家のスクラムガイド、SCRUM BOOT CAMP THE BOOK、アジャイルサムライ）
• 社内にスクラムの説明と協力の要請
• 開発部の週イチの勉強会で理解を深め
• チケット管理ツールとして使っていたYouTrackをスクラム開発で利用できるように準備を行い
• パイロット運用として2ヶ月ほどスプリントを回しながら練習

メンバーには不安もあったようですが、旗振り役の私としては最初はいろいろ慣れないので質問も多くなるかなとは思いましたが、不安は全くありませんでした。

振り返ってみると、導入して絶対によかった！という実感

今となってはとてもスムーズにスクラムが回っています。

もちろん、スクラムは開発をコントロールするやり方の一つではありますが、あらゆることを包括したフレームワークではないので、問題のすべてが解決されるわけではありません。

導入1年あたりで振り返った際にはチーム全員からスクラム開発にしてよかったという意見が聞かれています。

これから何回かに分けて、そこからの取り組みやチームのラーニングを書いていこうと思います。