こんにちは。早いものでもう6ヶ月もnanapiでお世話になっているデザイナーのたけお@ottieeです。
独身をこじらせたブログを時々更新しています。
Amigoというアプリを作りました
Amigoは動画とトークを軸にしたシンプルなコミュニケーションアプリです。2015/10/14にGoogle Playに公開しました。Android版先行リリースです。iOSの方は今しばらくお待ちください。
nanapiでの開発は弊社CCO上谷の記事、新しい開発スタイルの導入とデザイナーに求められる役割に書かれているように、アジャイルとUXDなど、様々な手法をミックスした開発手法を取っています。また、nanapiのデザイナーはビジュアルのデザインはもちろん、体験設計・仕様決め・ファシリテーションなど、開発工程の中でチームリーダーとして様々な業務に携わります。
今回はAmigoのファーストリリースまで、少人数のチームでどうサービスを開発していったかを紹介して、最後にスモールチームの開発の良かった点や課題などをまとめます。
開発で大事にしていた考え方
開発スタイルとしてはLEAN UXに近しいやり方です。チームとして大事にしていた考えは以下のようなところです。
- サービスの仮説検証のために不要なことは削ぐ
- 初期のデザインは間違っているという認識を持つ
- ユーザー体験を判断基準として物事を決める
小さく作り、フィードバックを得て、素早く直すスタイルで進めています。
nanapiの中でも、比較的LEAN UX的な考え方が濃い方だったかと思います。
チーム構成
このうち、プロダクトマネージャーとインフラエンジニアは他のサービスも担当しているため、開発が本格化してからは、手を動かしているのは僕を入れて3名、ということになります。
ざっくりとしたリリースまでの流れ
4月 UX設計
- プロダクトマネージャー
- デザイナー
5月 初期の仕様設計・主要画面のUI作成
- プロダクトマネージャー
- デザイナー
6月 本格的に開発開始
- デザイナー
- Androidエンジニア
- サーバーサイドエンジニア
9月頭
社内α版リリース
10月14日
ストア公開
ざっとこんな感じでした。当初タスクの積み上げで算出していた公開予定日が10/19だったので、少し早くリリースできたことになります。
初期フェーズでやったこと
4月、5月にはエンジニアがアサインされていなかったこともあり、体験設計と主要面のUIデザインを作っていました。
ちょっとイレギュラーなやり方ですが、かなり早い段階でPhotoshopとFLASHを使ってかなり完成系に近い状態のモックを作りました。
こちらは制作時のUIをまとめてみたものです。振り返ってみるとけっこうエッジの効いたものもあったりします。
初期段階でUI作り始めたのは、前提仮説・価値仮説・ペルソナなどは共有できていたものの、各ステークホルダーごとに、もやっとでも想像している完成形が違ってるんだろうな、と感じたからです。実際見てもらってコンセンサス取るのが早い、という発想です。
前回紹介したテクニックを使えば、Photoshopでもものによってはペーパーで作るより早く作れます。
副次的な効果でしたが、ここである程度パターンを用意して詰めていたので、あとからアサインされるエンジニアも「あ、こういうものを作るのか」と理解しやすかったかな、と思います。
本格的に開発開始
開発サイクル
本格的に開発がスタートした6月以降は、木曜日スタート1週間でイテレーションを回していくことにしました。
開始する曜日については、クックパッドさんのこちらの記事がすごく腹おち感があったので、参考にさせていただきました。
イテレーション終わりの水曜日に、タスクの確認・現状見えている課題の共有などを行うようにしました。とはいっても、日々話をしながら進めていくため、各々のタスクも把握できているし、その場で出てくるものはあまりなく、開発のリズムを作る役割の方が強かったように思います。
進め方
アプリのリリースまで、すべてパラレルで進めました。
- 調査・検証
- 仕様の変更・修正
- ワイヤー作成・更新
- UI作成
- ビジュアルデザイン策定
- インタラクションの作成
- アプリの実装
- API作成
- 環境構築
などなど
仕様は決めているものの、実装段階での気づきから仕様変更を行ったり、ユーザー体験に関わる大きな機能追加をしたり、少人数だからこそできる柔軟さと速さがあります。
例えば、ワイヤーフレームを見たエンジニアが先んじてざっとViewを作り、あとでデザイナーがAndroid StudioでXMLを変更したり、逆に口頭でパラメータをエンジニアに伝えて調整してもらったり、仕様がふわっとしてるところをその場で話し合って決めてすぐ実装して、そのあと社内のQiitaに仕様をまとめる、といった具合です。
開発が本格化してからは、仕様や構成の決定、UIの調整などは基本3名で話し合い進め、ユーザー体験に大きく関わる機能追加や変更がある場合には、プロダクトマネージャーを交えるという形で進めました。
まとめ
最後に、この小規模の開発を行って、良かった点、悪かった点をまとめます。
良かった点
開発の速さ
なんといっても一番良かったな、と思ったのはこの点です。10年以上Webやアプリを作り続けてきますが、今回のチームの開発速度は過去最速でした。これは後述するいくつかの要因があると思っています。
意思決定が早い
人数が少ないため、コミュニケーションロスが少なく、全員がユーザー体験をのことを考えながら仕様や構成を決めていくので、そもそも意思のずれは少なかったように思います。
ミーティングが少ない
迷いや疑問が出てきた時はつど相談できるので、本格的に開発が始まった6月からは、ユーザー体験に大きく関わる仕様変更や機能追加がある時や、入り組んだタスクを整理する時以外は、ミーティングをしませんでした。作業を分断することもなく、開発速度を落とさなかったのは良い点だったと思います。
柔軟に仕様や構成を変えながら作れた
これも少人数ならではのメリットだったように思います。また、実際にユーザーからのフィードバックを得ない状態で正しいものは作れないというチームの思想も柔軟さにつながったと思います。
意外にみんな普通に帰る
ここまでのスモールチームは初めての経験で、もっと苛烈な開発になると思っていましたが、おのおのが勉強会でたりとか、割と普通に帰れてました。これは、タスク管理に使っていたPivotal Trackerがうまくチームにはまったのも要因かなと思います。
悪かった点
検証が不十分だった
ここでいう検証は、アプリの実機検証と体験の検証という2種類があります。
実機検証
人数が限られているため、人海戦術でわーっと触って、多くの検証端末での実機確認というのはできませんでした。なにか仕組みで解決できると良いな、と思います。
体験検証
こちらは小規模チームでの開発だからというわけではないですが、実際に想定されるシーンでチームメンバーが実際使って検証し始めたのが、開発の後半になってしまったことは反省ポイントです。
これは機能追加や次回の新規開発では繰り返さないように気をつけようと思いました。
気づきや課題
メンバーが大事
当たり前といえば当たり前なのですが、少ない人数で開発を回すため、
- 得意分野がきちんとある
- 得意分野以外の周辺知識がある
- 主体性がある
- ユーザーのことを考えながら開発できる
こういうメンバーでないとそもそも成り立たないと思います。幸運にもメンバーに恵まれたわけなのですが、スモールチームの新規開発はメンバーがフィットするかが一番重要だと思います。
メンバーが増えた時どうしよう
ユーザーが増えていけば、複数デバイスの対応や品質担保の面で、メンバーも増やさなければならないフェーズがあると思います。そのタイミングで、どれだけ勢いを殺さずに回していけるか、というのが当面の課題になるかな、と思います。
終わりに
いかがだったでしょうか。スモールチームでの開発が必ずしもすべてのプロダクト・サービスに適しているかと言われるとそうではないと思いますが、これから新規開発しようとしている方に少しでも参考になれば幸いです。
nanapiは11月よりSupershipに生まれ変わりますが、引き続きスピード感を持って新たな価値を生み出したいメンバーを募集しています。
お読みいただきありがとうございました。