スペースエージェントの開発組織が抱えていた問題をスクラムで改善した話① 〜導入編〜

はじめまして。スペースエージェントでエンジニアリングマネージャーを担当しております @kaiba です。ランチリーダー、CSO(Cheef Sake Officer)でもあります(自称)。

前職は100人規模に成長したスタートアップにいたのですが、より小さいチームの立ち上げから関わってみたいと感じるようになり、スペースエージェントに参画をしました！

（日本酒が大好きで、定期的に社内でエンジニアを中心とした日本酒会を開催しています。日本酒好きな方は是非遊びに来てください！日本酒とエンジニアリングを語らいましょう）

さて、始めての投稿になりますが、今回はこれまで問題だらけだったスペースエージェントの開発体制をスクラムを導入することにより改善していっている！というお話をさせていただきます。

これまでの開発体制

当時は、業務委託を含め、以下のチーム構成でした。

• フロントエンジニア 1 名
• バックエンド 兼 インフラ 1 名
• バックエンド 1 名
• iOS 1 名
• デザイナ 1 名
• 企画・ディレクション兼HTMLコーダー1名

なんとスタートアップのこのフェーズにも関わらず、僕を含め、新メンバーや未経験者がいて、正直綱渡り感半端なく、不安でしかありませんでした。。

スペースエージェントの開発体制が抱えていた問題点

僕は何社かスタートアップを見てきました。

スタートアップは限られたリソースの中で成長を目指さねばなりません。

どこの企業も優秀なエンジニアを雇うのが難しく、走りながら体制を整えている為、コード・設計・開発フローは滅茶苦茶なことは往々にしてあります。
私自身ジョインする時に覚悟はしておりましたが、悪い意味で想定通り僕たちスペースエージェントの開発体制も多くの問題を抱えていました。

• リニューアル作業中だったが本来の目標から何ヶ月も延期している
• 残作業が管理されておらず、ゴールが見えない
• 打合せは皆無で、現状や目指すべきものの共有がなく、不信感や不安感がある
• 企画サイドの人間が知らぬ間にがっつりとデザインを変更し、戸惑いやフロントコーディングに不備が起こる
• 意思決定が曖昧で、言った言わない戦争が勃発している
• 大きな設計ミスをしており、エンジニアがストレスを抱えながら開発している
• 教育体制がない

スタートアップにお勤めの経験がある方は、同じような経験が少なからずあるのではないでしょうか？

辛いところではありますが、自ら動いて改善に尽力できるのがスタートアップの楽しいところでもあると思いますし、改善した後のチームで開発を行うことの喜びはこのフェーズならではの楽しみです。

余談ですが、大手企業では過去の負債が手の届かないところまで浸透しており、新しい技術やフレームワークを入れる事が不可能、もしくは費用対効果を算出して、会議通して…と大変なプロセスを通さなければなりませんが、スペースエージェントはエンジニアドリブンで意思決定ができる為、課題に対して新しい技術を率先して導入し解決できることはとてもいい経験になります。

まずは導入しやすく！小さく小さく改善していく

そんな折、開発会社の立ち上げを行い、その後リクルートでフロントエンド組織のマネジメントを経験、現在はHRを担当しているスクラム経験者の木元がジョインしました。

僕には前職でほ同じ状況に陥った経験があり、幸か不幸か上長に教わりながらスクラムを導入して改善した経験がありましたので、木元と共に改善に着手しました。

しかし、最終的な目的は「チームにあった開発手法を見つけ出す」事なので、 なんかイケてるらしい！流行ってるから。といって 「右にならえでスクラムだ！」 といっても上記の問題は改善されません。

まずは、延々と伸び続けているリニューアル作業を終えることを目的にスプレッドシートでの残タスク管理を行い、「タスクマネジメントを行う」という事を導入していきました。

スプレッドシートを活用して以下をの管理を行います。

• タスク内容
• 再現環境
• 対応状況
• 見積もり(エンジニアが記載)　← スクラムでいうストーリポイント
• 優先度(経営陣が記載)　← スクラムでいうプロダクトバックログ管理
• 作業時期(リニューアル作業前にやる必要があるのか)

個人的には表計算以外に使われる Excel 状のものは大嫌いですが、誰もが慣れ親しんだ操作で記載できる、というのは大きなメリットです。

非エンジニアもすんなり受け入れてくれたので、既存バグを含め新たな修正依頼が次々に登録されていきました。その後、経営陣が優先度を記載し、エンジニアが予想工数を記載。

工数的に見送った方が良いものが見えてきたり、大まかな残作業とリリース可能時期が見えてきてきました。

ここまでくれば一つの成功です。
既存メンバーにもタスク管理や開発マネジメントの意味が浸透したので、スクラムを始めとした本格的なプロセス改善に踏み出す事ができます！

スプレッドシート管理を続けていくと、無尽蔵にカラムや書式が増え続け、情報量が多くなった時に管理が煩雑になってしまったりどんどん使いづらくなるものです。

いよいよスクラム開発を導入していく

開発手法はチームにあったものを選ぶべきで、ウォーターフォールがマッチするケースもあります。 別にスクラムに拘る必要はありません。

僕たちは上記の期間の事も考慮し、以下のポイントでスクラムを導入してみることにしました。

• エンジニアも企画段階から参加し全員でプロダクトを育てているという感覚を持ちたい
• データドリブンな開発体制を作りたい
• 作業の見える化
• 作業内容の共有と見積もり
• 小さく小さくリリースしていきしっかり効果を測定して意味のある開発を行っていきたい
• 疑心暗鬼だったチームを一つにしたい

スペースにはスクラム経験者のHR担当が１名、前職でスクラムマスターを経験していた私しかスクラムを知っている人間はいませんでした。

まずは「スクラム開発とは？」というところから始めます。

こんな時活躍するのが名著「スクラムブートキャンプ」！ 各々の役割が漫画付きでサクッと読めます。
会社で購入し開発メンバー全員が読み漁りました。 ( 僕は把握ちゃんが好きです。)

あるモノはセミナーに行きスクラムを勉強、あるモノは他スタートアップのCTOにヒアリングをしに行ってくれたり、みんなが協力して何度も何度も会議をして作っていきました。

次回

導入編の紹介はここまでにし、次回、実際どのように運用し何が得られたのかをフロントエンドのリードエンジニアの松田が紹介いたします。
お楽しみに！

おわりに

スペースエージェントでは一緒にスクラム開発を推進できる仲間を募集しています！
色々お話しましょう！お気軽にご応募ください！