こんにちは、すーみんこと、日比谷です。

良いモノを作ろうとした時、作るモノ以前にチームでどう取り組めるか、ということがまず重要だなと実感する今日このごろです。具体的には、そもそものプロセスやチームのあり方として「Lean Startup」「Lean UX」といった「Lean」という考え方を意識したり、サービス開発におけるデザイナーについても役割やどの部分に責任を持つのかを再考しようといった流れもありますよね。

今日はそもそもBtoBの企業でありアプリ開発も初めて、アプリ開発の熟練者がいたわけでもない弊社の、「それでもなんとかチームをいい感じにしたいし、いいプロダクトを作りたい」とトライアンドエラーを繰り返した結果をいくつか書こうと思います。

プロジェクト発足後の状況と課題

弊社ヴォラーレ株式会社アプリ発見サービスである「Appliv」を2012年より開発・運営しています。Applivは目的のアプリを今よりもっと見つけやすくする「アプリを探すため」のサービスです。

今回取り組んだのはそのApplivのiOSアプリ。ブラウザ版のApplivが「見つける」に特化しているのに対し、iOSアプリ版はアプリをDLした後に「アプリを楽しむ」ためのサービスを提供しています。

メンバー構成

  • 当初、チームはデザイナー兼ディレクター1名、エンジニア2名の3名体制(+プロデューサーに社長)
  • プロジェクト発足後半年でデザイナー兼ディレクター1名、エンジニア4名の5名体制へ(+プロデューサーに社長は変わらず)

iOSアプリ開発経験者はいなく、(Androidアプリ開発経験者は1名いる)デザイナー兼ディレクターの私は新卒入社1ヶ月目。また会社自体もアプリ開発プロジェクトが初めてでした。

プロジェクト開始後顕在化した問題

Applivブラウザ版を開発・運営していく2年間の間でWebサービス作りのノウハウやフローなどはある程度社内にありましたが、 「申請」があるため一度出してみて数字見てすぐ変えることがしにくいのには悩まされました。またその申請には(2014年2〜3月当時)10日ほどかかるのも、これまでの開発フローの感覚だとやりづらいなと感じる大きな要因に。(※現在は2週間近くかかる上、リジェクトされたらもっと時間もかかるので前よりもやっかいだなーと思います。)

また、私自身がサービス開発のデザイナー経験がほぼ初めてに近い上ディレクターをしたことがなかったため、ディレクターとして何をすればいいのかを考える暇を作ることすら出来ず、なんとなしにプロデューサーである社長からの要件を伝えたり社内調整をすることしか出来ていませんでした。(当時のメンバーには本当にごめんなさいの気持ち…)

その中で顕在化した問題は多々ありましたが、特に大きな問題だったのは以下に挙げたようなものです。

  • エンジニア側が何をどう実装していいか分からない
  • 限られたリソースの中で何を優先して作るかの意思決定がしにくい
  • エンジニアが工数算定しづらいため、計画の精度が低い

こういった実務レベルでの課題に気付くと同時に、全ての大元をたどると大体2つの問題にぶつかるなということを発見しました。

  • プロジェクトの全体像がチーム間で共有されていない
  • お互いの得意分野を活かすワークフローになっていない

前置きが長くなりましたが、どうにかしてこれを解決できないか、と試行錯誤した結果が以下のワークフロー等です。

改善後ワークフロー

開発フロー

※画像クリックで大きくなります

いくつかのポイントを挙げるとするならば以下のような感じでしょうか。

  • 全メンバーが企画に参加する(リリース後しばらくしてからは数値もとれるようになり このKPIがこうだから次はこの施策をしよう、とエンジニアもデザイナーも関係なく言えるように)
  • エンジニアのUI提案や全体のUX提案が取り入れられる、FBを言えるフローである
  • デザイナーが最終の見た目や使い心地のアウトプットに責任を持つ(psdやaiを渡して「はい、終わり」はしない。)
  • ユーザーテストをやるのはデザイナーだが、(プロジェクト外の人間でさえ上長の許可を得れば)いつでも参加してOK

現在はアプリの規模が大きくなり社内でも関わる人間が開発側だけではなくなったためもっと違うフローですが、課題がいっぱい山積している状況の改善策として、当初はこういったフローで開発を進めていました。

具体的にやって良かったこと 5つ

上記のポイントともかぶる部分がありますが、このフローを実施するにあたって並行して行ったチーム内での施策をいくつか紹介します。

1.朝礼・終礼で各自の作業進捗状況を報告する

そもそもヴォラーレでは全社朝礼、部署朝礼と朝礼が2回あるため プロジェクト開始後数ヶ月はプロジェクトごとの朝礼・終礼を行っていませんでした。Backlogのガントチャートやバーンチャートはあるものの、その日に誰がどんなMTGに出て何をするかまでは不透明で 一体このスプリント内にきちんと開発が終わるのかというのが明確ではありませんでした。朝礼で大体のタスクをざっとメモし、終礼でその進捗を確認することによりお互いのタスク把握がよりしやすくなりました。

またただ単純にタスク確認だけじゃなく、その場で仕様変更や気付いたことなども話せて、朝礼・終礼が良いコミュニケーションの場になりました。

(画像はある日の朝礼のメモ 完了と○がついているのは終礼時での追記です。)

朝礼メモ

2.Storyboardでデザインの調整をデザイナーが出来るようにする

開発初期のころは、仕上がりイメージを見てエンジニアが実装→あれ、これなんか違う…→差し戻しでエンジニアがいちいち1px単位や色修正で余計な作業ロスが発生していました。

そもそもデザイン指示書をデザイナーが作ればいいという話ですが、iOSの場合Storyboardでデザイナーが色指定や大きさ指定、レイアウト調整などするほうが自社プロジェクトでは圧倒的にスピードが早いねという結論に至っています。

制約やAutoLayoutの概念をつかむコストはかかりますが、自分でいじれる分ガシガシ試しつつ「制約のエラーがどうしても消えない…」というところはエンジニアに都度聞きつつそこまでハードルは高くないなと感じました。慣れてからはほぼ全ての最終デザインをStoryboardでデザイナーが調整するようになり、この次で説明する更に効率の良い開発フローを行えるようになりました。

3.ワイヤーフレームを見てエンジニアが実装する間にデザイナーが仕上がりイメージを作成

エンジニアとデザイナー間での待ち時間を極力減らすようにフローを組んでいます。

最初はデザイナーが仕上がりイメージを作ってからエンジニア実装をしていましたが、それだとどうしてもエンジニア側に待ちが発生してしまうため、デザイナー側でできるだけ精度の高いワイヤーフレーム(以下WF)を作成し、それを元にエンジニアに実装をしてもらいます。実装してもらっている間にデザイナーは最終仕上がりイメージを作成するか他の機能のWFを作成し エンジニアが実装完了次第、上述通りStoryboardをいじって仕上がりイメージに従ってデザインの最終調整をします。

また、WFを元に実装してもらう場合、画像やアイコンはまだ出来てないことが多いので、過去に使ったアイコンやラフで作ったアイコンをアテでいれてもらいつつ、その後デザイナーが自分で画像を差し替えています。

弊社で使うWFはこのようなもの。(アプリの実際のWFです。)要素に抜け漏れがなく、押した後の導線や表示ルールを漏れ無く明記することを心がけています。

WF

4.WFを作った後には開発チーム全員に参加してもらいWF説明会を行う

説明会という言い方はあまりそぐわないかもしれませんが、できたWFはどんな機能で何のためにあってどういう見た目なのかの説明を行います。デザイナ視点で作っている時には気づかなかったパターンの抜け漏れをこのタイミングでエンジニアから指摘されて作り足すことや、「こういう風なUIのがいいんじゃない?」とFBをもらって修正することもあります。

5.申請が終わったり、新しいメンバーが入ったりしたあとの申請直後にはメンバーそれぞれでKPTを話す

そもそもがベンチャーで2,3人で作り始めたApplivというサービスだったため、KPTなど取り組んでもいなかったのですが デザイナーとエンジニアでもっと作業しやすくなるようにとKPTを話す会をやってみると意外と色々出てくるんですよね。

出た意見としては

  • デザイン制作物のスケジュールをもっと正確に教えて欲しい(アテで入れているダミー画像の本番用アイコンはいつ出来るのか?等)
  • WF作成後に仕様変更があったらチーム全員に共有すること
  • JSON仕様書作成は継続しよう
  • Backlogのタスク登録ルールを設定しよう(親タスクと小タスクの関係、マイルストーンの設定等ですね)

などでした。

まとめ

最初に以下の2点を問題点として挙げました。

  • プロジェクトの全体像がチーム間で共有されていない
  • お互いの得意分野を活かすワークフローになっていない

これって結局、チーム内でメンバーそれぞれの役割と得意不得意をお互い理解した上で、役職や職種に留まらず全員が相互作用出来るようなフロー作りという、すごく大雑把にまとめると「コミュニケーション」で解決でき、あとはそれをディレクターなりプロデューサーがいかに仕組み化できるかに尽きるなという結論に至りました。そう、結局すごく当たり前なことばかりなんですよね。でも、日々の業務に追われる中でその当たり前は容易に崩れてしまうし、意識の片隅からさえも追いやられるほど、その実践は難しいのも現実かなと。

仕組みづくりにも繋がりますが、実践が難しいからこそ 誰か一人が作るのを待つのではなくチーム全員が「あれこれもっとこうしたほうが良くない?」と発見・言えるフラットさというのも確実に必要なことだと思います。

ヴォラーレではこんなかんじで0→1のサービス開発をしたいデザイナー・エンジニアを大募集中です。話だけでも聞きたいかも!と思った場合、是非こちらのエンジニア・デザイナーランチページより気軽にコンタクトをとっていただければと思います。