actindi Advent Calendar 2018、4日目の記事を担当する、一番得意なゲームは 64 のスマブラの namikata です。ドンキーかフォックス使いです。先日は、社内で Nintendo switch のマリオカート大会が、色んな部署から 10 名ぐらい有志が集まって開催されました。同じエンジニアチームの moriyama がぶっちぎりの優勝でした。とても誇らしい気持ちになりました。いつか tech ブログで、スマブラやマリオカートの tech を紹介するのがここ最近の野望です。
今年のアクトインディアドベントカレンダー 第 1 弾の記事 の一部で honda さんが iOS アプリの UI リニューアルの件を紹介してくれたので、せっかくなので、 UI リニューアルをエンジニアの視点で振り返り、良かった点、悪かった点で 1 番印象に残っているものを書きたいと思います。
はじめに
今回の UI リニューアルは、アプリの初回表示画面をマップ表示から変更し、より普段使い出来るアプリを目指して改修したプロジェクトになります。
==========>
良かった点
良かった点は、今後の開発でも引き続き継続してやっていく事になります。今回のプロジェクトで一番良かった事は アイデアを全て形にする意気込みで開発に臨めた 事です。
日々の運用で行う改修は、解決したい課題が明確で、改修内容をイメージしやすいものが多いと思います。例えば、「天気が晴れか雨かで、遊びの候補は大きく変わるから、雨の時にパッと遊び場の候補を切り替えられるようにしたい」といった要望があった場合、解決したい課題は「外は雨なのに、公園とか紹介されてもノイズにしかならない」といった具体的な内容になり、課題を解決する為のアプローチとしては「雨の日で絞り込めるボタンを用意する」「現在の天気から紹介する遊び場を変える」とかいったものが出てくると思います。解決したい課題が具体的なので、改修案はある程度限られてきます。
それに対して、リニューアル規模の改修では、解決したい課題がアプリのコンセプトに近く、より抽象的なものになる事が多いと思います。今回のトップページのリニューアルの目的は、かなりざっくり言ってしまえば「近場の新しい遊び場がもっと簡単に見つかるようにする」と言ったもので(実施には、どんなターゲット層に、どのような経験をしてほしいかといった細かいストーリーがあります)、扱うテーマが大きくなると、それだけ、それを解決する為のアプローチは多くなるので、多種多様なアイデアが出てきます。
それらのアイデアは、頭の中でシミュレートして絞り込まれ、チームとの話し合いの中でさらに絞り込まれ、色々な過程をとって厳選されていき、ある程度絞り込まれると、デザインが作られます。そして作られたデザインを元にエンジニアが実装を開始していくのですが、このフェーズで、エンジニアとして大事な心の準備が アイデアを全て形にする意気込みを持つ事 だと個人的には思っています。
作られたデザインは、数ある候補の中から、一番成功の角度が高そうだと思うデザインの 1 案であって、完成ではありません。実際に実装してみて、使って見て、何度もブラッシュアップを繰り返したり、時には、全く別のアプローチを取る為に白紙に戻したりをしながら、最終的に完成形が見えてくるものです。実際に本番と同じぐらいのデータ量で、実機で確認してみないと判断がつかない事も多く、自分の端末でいつもと同じようにお出かけ先を探してみて、初めて見えてくるいい点や悪い点などの発見があり、その発見からまた新しいデザイン案が生まれたりします。
最終的な完成形に向かって試行錯誤を繰り返していくフェーズで大事なのは、もらったデザインの細部まで実装を模写する事ではなく、荒削りの動くベータ版を作って、実際に触ってもらっていい点と悪い点を探ることにあります。
ここで「もらったデザインが完成品だと思ってました」みたいな意識で開発を進めていると、「ここを変更してほしい」といった要望に対して快く受け入れる事が出来なかったり、「ここのデザインどう思う?」といった相談に対して、「今のままがいいと思いますよ(もう実装しちゃっているからな)」とか言っちゃったりして、もうプロジェクト終了です。
いこーよアプリの場合は、週末に子どもと遊びに行く場所を探す事が多いので、1 週間で実装できるところまで荒削りの状態でもいいので行い、実際に子どもと遊ぶ場所を探してみて、良し悪しを確認するといったことをほぼ毎週末行いました。そこで得られた知見を踏まえて、次の 1 週間でさらにブラッシュアップするといった事を繰り返し、とても疲れましたが、納得感を高めながら完成形まで持っていくことができました。
アイデアを全て形にする意気込みモードの時は、自分の場合は、コードの品質は全て捨て、動くモックを完成させる事に全ての注力を注ぎます。その時は、利用できるライブラリがあれば、迷わず組み込んで、まずは動くものを最短で作れる事を優先します。最終的にこれで行こう!といった方針が決まったら、ライブラリの選定をやり直したり、用件に合わない場合は、ライブラリを利用しないように作り直します。また、コードの品質を捨てていた部分のリファクタリング、作り直しを行うようにしています。
まさに、この記事で語られている「楽しい!喜んで!」の部分です。
悪かった点
悪かった点は、今後の開発で、同じ失敗をしない為の備忘録です。今回のプロジェクトで一番悪かった事は 「必要な機能」と「あれば嬉しい機能」を、第 1 弾のデザインが上がってきた時から、振り分けをしていなかった 事です。
良かった点で挙げたように、リニューアル規模のプロジェクトを進める場合は、最初のデザインは完成されたデザインではありません。ブラッシュアップを重ねる事で完成度が高まっていくので、何度もデザインの作り直しと実装の変更が発生する為、完成までのスケジュールの見通しが非常に悪くなります。そのような中で、スケジュールの遊びとなる部分は「あれば嬉しい機能」の開発期間です。必要な機能から開発を進め、納得の行くところまで作り、完成後に「あれば嬉しい機能」の実装に入れば、あれば嬉しい機能がスケジュールに間に合わなければ、後日対応に回すだけですむ為、ブラッシュアップに集中する事ができます。
今回は、必要な機能とあれば嬉しい機能の振り分けをきちんとしていなかった為、両方の機能の実装を並行して進めていました。ブラッシュアップに時間がかかった為、リリースまでの期間が短くなり、あれば嬉しい機能の中から、いくつかの機能はリリースを見送る事になりました。見送った機能の中には、実装が 8 割ぐらい完成しているものがあったりと、あれば嬉しい機能で使った時間を必要な機能の方に最初から回せていれば、もっと効率的に良いものが作れたはずです。
まとめ
良かった点は アイデアを全て形にする意気込みで開発に臨めた 事で、これは今後も続けていきたいと思います。 悪かった事は 「必要な機能」と「あれば嬉しい機能」を振り分けなかった 事で、これは今後は、適切なタイミングで振り分けを行うように気をつけたいと思います。
こうやって、主体性を持ちつつ、いいものを納得いくまで作り上げていける環境は、3 年間積み重ねてきたチームメンバー同士の信頼関係があるからこそ、出来上がった環境だと思います。良いチームに巡り会えて本当に感謝しています。来年も頑張って、いこーよアプリを更にいいものにしていきたいと思います。
いこーよアプリチームでは、アプリの成長を加速させる為に、モバイルエンジニアを募集しています!
お気軽にご連絡お待ちしています!