こんにちわ！ wrbssです。オールアバウトでスマホアプリの開発を担当しています。今回はオールアバウトでどのようにスマホアプリ開発を進めているかにフォーカスして紹介したいと思います。主に新規でのアプリ開発にておこなっているやり方なので、それだけ留意いただければと！

はじめに

最初にどのようなチーム構成で開発しているかが分からないと想像もしづらいと思うので、現在のアプリ開発チームの構成を軽く紹介します。

どんなチーム構成でやっているか

6人でチームを組んで開発しています。構成は以下のような感じです。

企画3人
エンジニア3人

1つのジャンルに対して、広くアプローチしようとしているため企画側は営業も兼ねています。またエンジニア側はiOS / Android / サーバーサイドと必要になればなんでもやる人材で固められております。そんなチーム構成でどのようにアプリを開発しているかを今回は紹介します。

開発の進め方

進め方で最初に紹介するのは、どんなプロダクト開発でも重要なタスク管理です。

タスク管理

企画とエンジニアで管理方法が違いますが、エンジニア側はタスク管理にTrelloを使っています。気持ち良い操作感のカンバンライクなツールです。タスクを作る側として、一番意識していることは1つのタスクの作業時間です。最大でも16hに収まるような単位でタスクを切るようにしています。出来るだけ細分化してタスクを作るようにしています。例えば、「A」という要件の機能実装があった場合、以下のように分割して登録しています。

「A」機能設計
「A」サーバーサイドAPI実装
「A」 iOSクライアント実装
「A」テスト

なぜ小さい単位でタスク管理をしているか

小さい単位で管理することのメリットは問題が発生した時に、やっていてよかったと感じることが多いです。小さい単位で報告することによって、ダメだった時の戻りが少なくて済むからです。 1ヶ月実装してみてやっぱりダメでした、なんてことになったら目も当てられないですよね。逆にデメリットとしては、タスクが増えすぎて管理できなくなる問題があったりします。それを解決するため、毎週終わりに定例でタスクを整理する会議を取るようにしています。

タスクのプロセス分類

先ほど記載した通り、Trelloはカンバンライクなツールなのです。縦のラインとなるプロセスには以下のように定義して使っています。（ちょいちょい変えているので、現在の状態です）

Backlog (低)
Backlog
ToDo
InReview
Release（日付）
Done

割と一般的なものなので説明はいらないと思いますが、Backlogのみレベルを2段階に分けています。 Backlogは結構溜まりがちなので、ずっと着手されず残っているBacklogに関してはBacklog（Low）に下げるようにしています。 ToDoには主に直近のスプリントでやることを移動するようにしています。

f:id:allabout-techblog:20170330191349p:plain

タスクを追加するタイミング・追加する人

タスクの追加は誰でもやって良いことにしています。問題に気づいた人がBacklogに追加しています。制限として追加できるのはBacklogのみに限定しているくらいです。スプリントは2週間で回しています。スプリント計画時にBacklogから選別してToDoに移動するようにしています。

毎日の進捗共有

これも一般的な手法ですが、朝会/夕会を毎日1回行っています。チームによってやるメンバーは変わりますが、現在のスマホアプリ開発チームは立ち上げということもあり、企画メンバー、エンジニアメンバー全員集まってやるようにしています。どうしてもプロジェクト立ち上げ時は方針の転換が発生しやすいので、メンバー全員の問題意識を共有するためにそのような形をとっています。職種が違うため、初期の頃は言葉の違いに壁がありましたので、積極的に翻訳することを意識するようにしていました。最近は慣れてきたこともあり、エンジニア側の話を理解してもらえるようになっている感じがします。もちろん逆も然り。根気よく説明していれば、言語の壁は割と時間が解決してくれます。

1週間に1度のプロダクト定例会議

メンバー全員集まって、プロダクトのことについて話す会議です。主に以下の項目について話し合っています。

アプリの現状確認、KPI進捗
企画側の1週間の動きダイジェスト
エンジニア側の1週間の動きダイジェスト
1週間で起きた問題点、相談事の深堀

問題点、相談事とは主に朝会/夕会ではまとまらなかった内容をここで議論するようにしています。定例としての会議があるおかげで、日頃議論が白熱した時に「長引きそうなので、プロダクト定例で話しましょう」と一旦落ち着かせるための役に立っています。頭を冷やした状態で再度議論の場を設けたい場合によく使われている感じです。

定期的なドッグフーディング会

スマホアプリに限らず、どこでも言われていることですが、サービス開発を行なっている場合日頃から開発しているアプリを触ることはとても大切です。日頃自分で使っていないアプリの改善事項なんてなかなか出てこないものです。本当は自分の生活サイクルで使う場所があることがベストですが、どうしてもターゲットとなるユーザーとは違う人がプロジェクトにアサインされることも結構あると思います。そのような人にも、アプリを触ってもらう入り口として、チームで一箇所に集まってアプリを一緒に触ってみるドックフーディング会を定期的に開催しています。

具体的には30分という時間制限で以下のようなやり方で実施しています。

参加可能なメンバーで会議室に集まる
前半の15分はひたすらアプリを触ってもらう
気づいた点は随時スプレッドシートに記入
後半の15分は記載した内容をメンバーに共有する

内容については、誰がみてもそうした方がいいよねって点で改修が2h以内に終わりそうなものに関しては、その場でタスク化しています。時間がかかりそう or 議論が必要な項目に関してはプロダクト定例で議論するようにしています。

1週間に2時間の改善タスク消化会

他の企業では朝lintと呼ばれている場合もありますが、小さめの課題・細かい技術的な負債を改善するための時間を1週間に1回取っています。改善の時間は意識的に取らないと、日々の業務タスクが優先されて負債が徐々に溜まっていってしまいます。そのため、プロジェクトの立ち上げ時から毎週時間を取るようにしています。

主にやっていることは以下の通りです。

コード内のTODO潰し
コードlintチェックで引っかかっている箇所の修正
ドッグフーディング中に出た細かい課題対応
クラッシュレポートで報告されている問題の修正

どうしてもリリーススケジュールなどの関係上、後回しになってしまっているタスクもここで消化できます。アプリを健全な状態に保つためにはこういう小さな改善が欠かせません。

定期的な振り返り

こちらもサービスの立ち上げ時期ってこともあり、企画・エンジニア混じってやっています。やり方は付箋を利用してKPT方式で行なっています。

現在のプロダクトを始める前まではエンジニアのみでやっていました。その時は技術的な課題が多く出てそれはそれでもとてもよかったです。しかしサービスの立ち上げ時はサービス自体の課題を出すことの方が重要だったりします。そのため最近になって企画側も混ざってやるようになりました。現段階では正直うまく言っているとは言い難い感じです。正直エンジニアのみでやっていた方がまとめるのがすごい楽でした。うまくいっていない主な原因は、企画側とエンジニア側ではお互いの課題感が結構バラバラなことが挙げられます。技術的な課題が多いエンジニアに対して、企画側はクライアントワークや運用周りの課題が多い傾向があるように思えます。ただそれでも課題の共有の場としては、とてもうまく機能しています。現段階では、企画側が課題と感じている箇所を聞くことができるので、そこを大事にしています。今後の相互に課題の解決策を出し合えるような場にしていきたいと思っています。

さいごに

以上、オールアバウトのスマホアプリを開発しているチームでの進め方の現状でした。定期的に行うタスクをサイクルとして組み込むことによって、継続的にプロダクトを改善するフローが生まれているような気がいます。以前までは、エンジニアサイドのみでこのようなフローを行なっていたのですが、最近はできるだけ企画側も巻き込んで進めるようにしています。もちろんその分ファシリテートは大変になりますが、プロダクトベースで進める場合は意識を合わせることのメリットの方が大きいため、現在は少し無理してやるようにしています。徐々にですが、チーム内の職種間の壁は薄くなっているような気がします。プロダクトが解決するべき課題に対して一丸と向き合えるチームにしていきたいですね！