こんにちは！2015年もパンとインターネットが大好き、デザイナーのmura24です。
最近はemosiというAppや、nanapi.jpの改善を担当しております。emosiチームは最大でも3名（エンジニア2名・デザイナー1名）の小さなチームで開発を行っております。
今回は、emosiの開発を通して、小さいチームで、新規開発・数値改善・サービス運用を行うためにやってよかったことをいくつかご紹介いたします。
イメージボードを共有する
emosiチームは、口頭やチャットで、UIやインタラクションについてよく話をするのですが、あとでキチンと内容を追えるように、チームでイメージボードを共有するようにしました。
イメージボードはPinterestのボードで管理し、デザイナー・エンジニアを問わず、気になったものはこのボードにポイポイ投げておき、イメージのすり合わせや、デザインの会話のたたき台にしています。
イメージボードを共有で管理することで、デザイナー以外のメンバーも積極的に情報収集をするようになり、より活発な議論が行えるようになりました。
会議とドキュメントを極力減らす
時間は有限です。限られた開発期間内で、デザインやプログラミングなど創造的な時間を確保するために、仰々しい会議は行わないように気をつけました。
以前は、丸1日全員で話し合うといった我慢大会も存在したのですが、わざわざ時間を取らなくても、あとで各自がドキュメントを確認すれば済むような会議はどんどん廃止し、現在は、週一での定例ミーティングと2週に一回行うイテレーションミーティング以外の話し合いは、自席でパパっと済ますようにしております。
会議は報告ではなく議論を
会議の内容も、誰かが一方的に報告し、それを他の参加者が聞くスタイルではなく、事前にアジェンダや会議の内容を共有し、全員が議題を持ちより、活発な議論が行えるようなスタイルに変更しました。
会議全体の進行はファシリテーターが行いますが、発表者はそれぞれ議題ごとにの担当者を割り振るように変えた結果、ファシリテーターは事前資料の準備など会議に臨む際の負担が減り、他の参加者は会議により自分事として参加できるようになりました。
ブレストを行う際も、その場で「よーいドン」とアイデアをひねり出すのではなく、あらかじめ各人でアイデアを持ち寄って、そこからコラボレーションしていくようにしました。
そのドキュメント、誰のためのもの？
ついデザイナーの手癖で、アプリ実装に必要なデザインガイドラインや、数値や施策のドキュメントなど、いわゆる中間成果物を、ゴリッゴリに作りこんで、開発前に勝手に疲弊していたのですが、メンバーに「資料立派に作りすぎ」と指摘を受けてからは、チーム間で合意が取れていれば、必要最低限のもののみ残し、なるべくドキュメント化作業を省略するようにしました。
ワイヤーフレームはペーパープロトタイプを流用したり、簡単な実装であれば、口頭ベースでエンジニアさんにお願いするようにしています。
ユーザーによりよいものを、より早く届けることを意識し、開発フェーズの無駄はバッサバッサカットしていきましょう！
ペーパープロトは全員でやる
emosiではペーパープロトタイプをなるべく全員で行うようにしています。
ペーパープロトタイプからエンジニアに参加してもらうことで、実装を見据えたUIの検討ができ、早い段階でアンチパターンをつぶすことが出来ます。
ペーパープロトタイプを書くのに特別なテクニックは必要ありません。紙とペンさえあれば誰でも行え、プロトタイプをたたき台に、UIの活発な議論を交わすことができるようになりました。
KPIは全員で追う
通常、数値目標はチームのリーダーが持つことが多いですが、emosiチームでは全員が同じKPIを持ち、改善サイクルを回すようにしています。
数値解析もそれぞれ施策ごとに分担を決め、仮説検証を行うことで、数値に基づいた改善策を全員が提案できるようになりました。
施策を打つ場合は、どういった仮説によるものなのか、解決される問題（見るべき数値）はなんなのかを事前に全員で握っておき、実施後は、数値結果とそこからどんな学びがあったのかを、全員で共有し、議論するようにしました。
例えば、初回チュートリアルの改善では、全員でファンネル分析し、離脱ポイントを確認しながら、メンバー全員でUIの改善案を出しあい、チュートリアルの踏破率を向上させることができました。
解析ツールを日常的に確認する習慣がメンバー内に浸透していない場合は、全員で数値を共有する時間を設けたり、解析ツールを触る時間を作ったりしてフォローするとよいでしょう。
実際emosiチームも、こういった時間を設けてから、数値を根拠とした施策を議論する回数が増え、結果的に有用なアイデアの総数を増やすことができました。
未来の話をする場を設ける
1〜2週間の短いサイクルで開発を進めていると、つい、目の前のタスクや問題にばかり集中して、視野が狭くなり、インパクトの小さい施策に終始しがちです。
emosiチームでは、月に1度チームメンバーで、ランチ+コーヒーミーティングを設定し、サービスの未来の話をする時間を作りました。今後のサービスの方向性や、これからやりたい施策、盛り込みたい機能などをリラックスしながら自由勝手に話し合う時間を設けることで、いつもと違った視点でサービスを検討することができます。
※ちなみに、ランチミーティングだけにしてしまうと、食べることに夢中になり、気がついたら「カレーおいしい！」で話が終わってしまうのを防ぐために、ランチ後にカフェタイムを設けています。
なお、その場で出たアイデアは、忘れないうちに各人がアイスボックスに入れ、イテレーションミーティングで議題に上げ、再度検討したり、空き時間に手を動かしたりするようにしています。
まとめ
小さいチームで開発するということは、メンバー一人ひとりがチームに与える影響が非常に大きくなることを意味します。
全員が同じ目線で会話をし、手を動かすことで、メンバー一人ひとりが、それぞれの職能を持った上で、主体性を持ちながらサービス開発に携わるよう心がけております。
今回のエントリが、同じような体制でサービス開発をやっている方、ご興味のある方の一助になれば幸いです。
あわせて読みたい
わたしや、エンジニアのkozytyがemosiチームで開発した際の知見をまとめたスライドもご紹介いたします。ぜひ補足としてご覧くださいませ！