アップロードしてから配布可能になるまでが遅い。分ぐらいかかっている印象があります。3.8.0.1)お分かりいただけるでしょうか。アップロード完了しているのにまだ処理中となっています。テスト可能になってました。サポートしたバージョンのものは、対象となるデバイスの種類が減った事により、テスト開始までの時間が短縮されたんだと思います。リリースサイクルに関わる部分なので、まだ対応されていない方は是非対応してみてください。使って、アプリの申請まで自動化したいなぁと思う今日この頃です。ドンキーかフォックス使いです。名ぐらい有志が集まって開催されました。ぶっちぎりの優勝でした。誇らしい気持ちになりました。紹介するのがここ最近の野望です。番印象に残っているものを書きたいと思います。リニューアルは、アプリの初回表示画面をマップ表示から変更し、より普段使い出来るアプリを目指して改修したプロジェクトになります。良かった点は、今後の開発でも引き続き継続してやっていく事になります。日々の運用で行う改修は、解決したい課題が明確で、改修内容をイメージしやすいものが多いと思います。「天気が晴れか雨かで、遊びの候補は大きく変わるから、雨の時にパッと遊び場の候補を切り替えられるようにしたい」といった要望があった場合、解決したい課題は「外は雨なのに、公園とか紹介されてもノイズにしかならない」といった具体的な内容になり、課題を解決する為のアプローチとしては「雨の日で絞り込めるボタンを用意する」「現在の天気から紹介する遊び場を変える」とかいったものが出てくると思います。解決したい課題が具体的なので、改修案はある程度限られてきます。それに対して、リニューアル規模の改修では、解決したい課題がアプリのコンセプトに近く、より抽象的なものになる事が多いと思います。今回のトップページのリニューアルの目的は、かなりざっくり言ってしまえば「近場の新しい遊び場がもっと簡単に見つかるようにする」と言ったもので(実施には、どんなターゲット層に、どのような経験をしてほしいかといった細かいストーリーがあります)、扱うテーマが大きくなると、それだけ、それを解決する為のアプローチは多くなるので、多種多様なアイデアが出てきます。それらのアイデアは、頭の中でシミュレートして絞り込まれ、チームとの話し合いの中でさらに絞り込まれ、色々な過程をとって厳選されていき、ある程度絞り込まれると、デザインが作られます。個人的には思っています。案であって、完成ではありません。実際に実装してみて、使って見て、何度もブラッシュアップを繰り返したり、時には、全く別のアプローチを取る為に白紙に戻したりをしながら、最終的に完成形が見えてくるものです。実際に本番と同じぐらいのデータ量で、実機で確認してみないと判断がつかない事も多く、自分の端末でいつもと同じようにお出かけ先を探してみて、初めて見えてくるいい点や悪い点などの発見があり、その発見からまた新しいデザイン案が生まれたりします。最終的な完成形に向かって試行錯誤を繰り返していくフェーズで大事なのは、もらったデザインの細部まで実装を模写する事ではなく、荒削りの動くベータ版を作って、実際に触ってもらっていい点と悪い点を探ることにあります。ここで「もらったデザインが完成品だと思ってました」みたいな意識で開発を進めていると、「ここを変更してほしい」といった要望に対して快く受け入れる事が出来なかったり、「ここのデザインどう思う?」といった相談に対して、「今のままがいいと思いますよ(もう実装しちゃっているからな)」とか言っちゃったりして、もうプロジェクト終了です。週間で実装できるところまで荒削りの状態でもいいので行い、実際に子どもと遊ぶ場所を探してみて、良し悪しを確認するといったことをほぼ毎週末行いました。週間でさらにブラッシュアップするといった事を繰り返し、とても疲れましたが、納得感を高めながら完成形まで持っていくことができました。アイデアを全て形にする意気込みモードの時は、自分の場合は、コードの品質は全て捨て、動くモックを完成させる事に全ての注力を注ぎます。その時は、利用できるライブラリがあれば、迷わず組み込んで、まずは動くものを最短で作れる事を優先します。最終的にこれで行こう!といった方針が決まったら、ライブラリの選定をやり直したり、用件に合わない場合は、ライブラリを利用しないように作り直します。コードの品質を捨てていた部分のリファクタリング、作り直しを行うようにしています。この記事で語られている「楽しい!喜んで!」の部分です。悪かった点は、今後の開発で、同じ失敗をしない為の備忘録です。良かった点で挙げたように、リニューアル規模のプロジェクトを進める場合は、最初のデザインは完成されたデザインではありません。ブラッシュアップを重ねる事で完成度が高まっていくので、何度もデザインの作り直しと実装の変更が発生する為、完成までのスケジュールの見通しが非常に悪くなります。そのような中で、スケジュールの遊びとなる部分は「あれば嬉しい機能」の開発期間です。必要な機能から開発を進め、納得の行くところまで作り、完成後に「あれば嬉しい機能」の実装に入れば、あれば嬉しい機能がスケジュールに間に合わなければ、後日対応に回すだけですむ為、ブラッシュアップに集中する事ができます。今回は、必要な機能とあれば嬉しい機能の振り分けをきちんとしていなかった為、両方の機能の実装を並行して進めていました。ブラッシュアップに時間がかかった為、リリースまでの期間が短くなり、あれば嬉しい機能の中から、いくつかの機能はリリースを見送る事になりました。割ぐらい完成しているものがあったりと、あれば嬉しい機能で使った時間を必要な機能の方に最初から回せていれば、もっと効率的に良いものが作れたはずです。事で、これは今後も続けていきたいと思います。事で、これは今後は、適切なタイミングで振り分けを行うように気をつけたいと思います。年間積み重ねてきたチームメンバー同士の信頼関係があるからこそ、出来上がった環境だと思います。良いチームに巡り会えて本当に感謝しています。来年も頑張って、いこーよアプリを更にいいものにしていきたいと思います。2018、1日目の記事です。Androidアプリエンジニアのhondaです。実は今日でactindi勤続3年になります。3年間、いこーよのモバイルアプリを担当してきました。今回は軽く3年間どのようにモバイルアプリ開発をしてきたのか振り返ってみたいと思います。actindiにジョインした理由そもそもactindiにジョインした理由ですが、前職で一緒に仕事したことがあり、先にactindiにジョインしていたディレクター兼デザイナーのsuzukiから「一緒にいこーよのモバイルアプリを作らない?」というお誘いを頂いたことがきっかけでした。いこーよは世の中のパパ、ママに向けて子供とのお出かけ先情報を提供する情報サイトです。当時のいこーよはモバイルアプリはなく、いこーよからファンのもとへお出かけ先情報を提供していくためにモバイルアプリを作ろうというフェーズでした。カジュアル面談や面接を受けて、以下の点でジョインを決めました。actindiは当時から個人の自主性を重んじたり、ルールでがんじがらめにするのではなく、自分たちで「一番アウトプットを出す方法は何か?」を考え、実践することを大事にしていました。そこに強く共感することが出来ました。会社のホームページにも掲載されています。実際に入社してからもちゃんと文化として定着していて、リモート勤務や何時から何時まで働くか?ということが自分で判断して決めることができるので子持ちの身としてはとても助かりました。いこーよは当時知らなかったのですが、1歳の娘がいたので、サービスにとても魅力を感じた。最初はiOSアプリを作るがAndroidアプリも作る予定なので今までのAndroid開発経験を活かせる。開発スタートモバイルアプリ開発は私を誘ってくれたディレクター兼デザイナーと私の2名体制でスタートしました。前述した通り、いこーよユーザはAndroidよりiOSが多いため、iOS開発から取り掛かりました。最初の1ヶ月はモバイルアプリの目的を明確にしてペルソナの設定、盛り込む機能/盛り込まない機能の決定、UIの検討&調査に費やしました。最初のGitHubリポジトリへのコミットは2015年12月28日でした。技術選定も一任されていました。方針としては凝ったことをせず、シンプルに作ることを心がけました。アーキテクチャはMVCライク、データベースはRealm、ネットワーククライアントはAlamofireというような実績のあるものや使いやすいものを採用しました。開発言語はSwiftを採用しました。Objective-CでiOSアプリを作っていたことがあったのでSwiftの書きやすさに感動したものです。CIはサーバサイドがJenkinsを使っているのでモバイルアプリでもJenkinsを使おうか?とも考えましたが、環境構築に時間をかけたくなかったので、bitriseを使うことにしました。qiita.comiOS版開発にWebエンジニアがジョイン年明けからWebエンジニアでiOSアプリ開発経験もあったnamikataがアプリチームに参画し、チーム3名体制になりました。チームメンバー全員でのデザインの共有や議論はProttを使って行いました。実装は私とnamikataで作業を分担して、お互いにコードレビューしながら進めました。二人ともSwiftはほぼ初心者の状態でしたが、コードレビューで議論しながら開発を進めて行けたことはとても有意義でした。Swiftに興味のあるWebエンジニアの方からもコードレビューをしていただける機会があったのでとてもありがたかったです。このようなエンジニアがプラットフォームを超えて、プロダクトに対してバリューを出せるのはactindiの強みだと思います。アプリチーム全員が子持ちのお父さんだったこともあり、「親としてどういうアプリだと嬉しいか?」というようなユーザ目線でのサービス開発が出来ました。actindiに入社する前はチーム全体でユーザ目線で開発するという経験が少なかったので大変でしたがとても楽しかったです。iOS版いこーよリリースそして、2016年7月にiOS版いこーよがリリースされました。2018年11月現在、iOS版のダウンロード数は11万強に到達しました!上の画像はバージョン1.0.0のUIです。最初のころのUIは自宅や現在位置、お出かけ先でのスポットを直感的に見つけられるようにマップをメイン画面にしました。行きたいスポットを見つけたら保存しやすくするためボタンを大きめにしたり、行ったスポットの口コミを書きやすくるために入力エリアをわかりやすくしたり、書きやすくするような配慮をUI設計で行いました。Android版開発スタートiOSがリリースした後、2016年8月からAndroid版の開発がスタートしました。基本的にはiOSで実装したUIや機能をAndroid版に移植するような流れでした。Android版ではiOS版をそのまま移植してしまうとAndroidアプリらしさがないものになってしまいます。Designに則ったUIにするようにしました。アーキテクチャはiOS版の開発で出てきた課題を鑑みつつ、最初はMVC+レイヤードアーキテクチャーのようなものにしました。データベースはiOSで使い慣れたRealm、ネットワーククライアントはRetrofitを採用しました。Android版でもシンプルな設計を目指しました。言語は私の提案でKotlinにしました。Kotlinはいいぞ。tech.actindi.netCIはAndroid版でもbitriseにしました。現在、iOS版とともにbitriseでプルリクごとにビルドして、deploygateで社内配信する構成になっています。私事ですが、Android版開発中に息子が誕生しました。この頃から自宅でのリモート勤務が多くなってきましたが、前述した通りチームメンバーがみんな子持ちなのでメンバーがお互いを考えながらフォローしあえました。actindiはコアタイムの無いフレックス制を導入しています。子供の風邪などの急な対応がしやすくとてもありがたかったです。いう時、「周りに迷惑をかけて申し訳ない・・・」と思いがちですが全社的に「お互い様」の考え方が定着しているので、安心してリモート勤務や勤務時間を変更したりすることができました。アウトプットも極端に低くなったということはなく、チームに貢献することができたと思います。Android版いこーよリリース2017年2月にAndroid版いこーよがリリースされました。2018年11月現在、Android版もダウンロード数が11万強に到達しました!Android版はiOS版よりシンプルなUIになっていますが、スポットの検索性や口コミのユーザ体験はiOSと同じになるように実装しました。アプリの成長Android版リリース後、iOS版、Android版ともにFirebaseAnalytics、GoogleAnalyticsを使ったユーザ行動解析、アプリ内でのユーザアンケート、などなどいろいろな角度からいこーよユーザにとっての使いやすいアプリを目指し改修を進めていきました。毎週月曜日は定例ミーティングを開き、上記のデータやKPI、KGIをチーム全体で確認しあい、アプリとしてどういった成長が必要なのかを話し合っていきました。そのミーティングでエンジニア、ディレクターの垣根を超えて、施策の提案なども行い、チームメンバー全員が施策に対してポジティブな意見で肉付けをしていき、具体的にサービスづくりに落とし込んでいきました。小さいチームならではの動き方ではあると思いますがactindiらしい良いチームの動きだなと感じています。下の画像は2018年11月現在のAndroid版、iOS版のメイン画面です。リリース当時に比べてだいぶ変わりました。Android版はマップベースですが、iOS版はさらに普段遣いができるアプリを目指すため、週末に子供とのお出かけ先をすぐに見つけられるように季節、イベント、口コミ、クーポンなど様々な角度からおすすめのスポット情報を提供できるUIにしました。アーキテクチャーアプリのアーキテクチャーも最初のころとは変化していきました。namikataがブログでiOS版の実装について触れていますのでぜひ御覧ください。Componentsをベースにしたものに設計方針を変え、よりテスタブルで追加実装しやすい設計に変更しています。ConsoleやFirebaseをチェックしていち早く不具合に対応するように心がけていました。今ではクラッシュ通知をslackに通知するようにして、より早く不具合に対応できる体制にしています。段階的リリースの利用やリリースタイミングなどを臨機応変に変えていきながら、安全にサービスを提供できるように心がけています。評価これまでお伝えしたアプリの成長によって、いこーよユーザの方々からAndroid版、iOS版ともに4.4の評価をいただきました。ありがとうございます!これからのモバイル版いこーよアプリ上記の現状のiOS版のUIでいい結果を残せたのでそのUIをベースにした新UIを目下開発中です。iOS版のUIでの反省点や改善点を踏まえつつ、Androidらしい新UIを目指していきます。iOS版、Android版ともにこれからもいこーよユーザにとって使いやすいアプリを目指すために成長させていきます。ご期待下さい!まとめactindiでの3年間のモバイルアプリ開発の中でチームメンバー同士助け合い、より良いアプリを作るために議論し、いこーよモバイルアプリを成長させてきました。読んで設計の勉強をしていますが、設計っていつ考えても難しいですね。猫型蓄音機さんがまとめてくれている実況シリーズを何度も読み直させてもらってます。以外のアーキテクチャの導入を検討するのがいいのかなぁと悶々と考えています。今回は、設計に関わらず、開発を続けて行く上で意識しているコードのメンテナンスに関わる事について、つらつらと書いて行きたいと思います。共通化する事も、コードのメンテナンス性の向上の一貫だと思っています。詳細を語るようにしています。撮影して、コメント欄にリンクを貼る事にしました。利用されているシーンを実際に見てから、コードに目を通す事で、理解しやすいのではないかと思っています。そのまま渡したりしている箇所は多々ありますが...)。層の単体テストがとてもやりやすくなります。言語のバージョンが上がった時に、利用しているライブラリの対応を待つ必要がある。等)、いこーよアプリでは、各種ライブラリを積極的に利用させてもらっています。独自実装を減らして、コードのメンテナンス性が上がる」点が挙げられると思います。今回はコードのメンテナンス性をあげる為に利用しているライブラリを紹介したいと思います。まとめてくれているライブラリ。定義されていないものを適宜追加するようにしています。慣れておくと、他のプロジェクトでも、ライブラリを入れれば、慣れているメソッドで開発を進める事ができます。SwiftDate日付に関する処理をまとめてくれているライブラリ。扱いやすくしてくれるライブラリ。利用する際の書き方を統一してくれる目的で利用しています。github.comgithub.comgithub.comライブラリを利用する際には、ライブラリの利用をいつでも辞められる覚悟を持てるものだけ採用するようにしています。頻繁に言語のアップデートが行われるので、利用しているライブラリが対応してくれないと開発が止まってしまうリスクがある為です。あり、多くの記事でベンチマークによる速度比較や、機能の比較を行っており、将来、利用するライブラリを変更する可能性があります。利用していますが、こちらに関しても同じ事が言えます。将来ライブラリを変更する可能性のあるものを利用する時には、ライブラリを包むラッパーを用意して、コードの各所で利用する時は、ラッパー経由で利用するようにしておくと、ライブラリの変更が用意に行えるようになります。箇所のみで、簡単に切り替える事ができました。バージョンの見直しを行います。最新と一つ前のバージョンです。以降とすることが決まりました。バージョンアップしてもらおうという方向性です。スムーズに利用を開始する事ができました。アジェンダに記入し、相談として挙げて、削除するか残すかを毎週検討しています。完成して動作しているので、ユーザーにデメリットが無ければ残していいかもと思ってしまいそうですが(実装に時間がかかった部分なら尚更)いりません。泣きながら削除します。これより以下は他の人には全くオススメできませんが、自分のスタイルに合っているので、おまけ程度に載せておきます。ビルドエラー駆動開発1人で開発しているので、コンフリクトの心配はほとんどなく、改修が入る度に、気になった所はリファクタリングを行っています。目をつぶるのように自分では区分けをしていて、テストでカバーできる範囲は結構少ないです。検証にどっぷり浸かっています。ビルドエラーになっているところをチェックして改修するといった事をやっています。大々的にリファクタリングした時は、リリース前の目視による動作確認で担保します。画面数も少なく、規模の小さいアプリなので出来る技だと思うのですが、これが一番早いです。このやり方には問題点が沢山ありますが、いいところもちょっとあります。それは、ビルドを何度も行うので、常にビルド時間は短く保とうといった意識が芽生える事です。こまめにビルドを行うので、差分ビルドの時間が一番重要になってきます。実装する方法を紹介したいと思います。色々な機能の実装を進めていく上で、こう書いたら使い回しきくしいいんじゃないかなぁ、と考えながら辿り着いた実装なので、まだ見えていない問題点があるかもしれませんが、自分の中では、開発効率が上がっていい感じで機能しています。サンプルに書いて行きたいと思います。ここの処理から始まりました。)では以下のアクションを行っています。以下のような感じで実装を開始しました。パターンで実装しました。こんな風になっています。押すと口コミに参考になったができるようになる。追加された感じになっています。愚直に実装すると以下のようになりました。同じように遊び場施設の詳細画面に遷移するアクションです。口コミされた施設に遷移するユーザーをタップしたらユーザー画面に遷移する一覧の場合は、口コミ本文をタップしたら口コミ詳細が見れる口コミにいいねができるといったアクションは、口コミに対するアクションとして、口コミを表示している他の画面でも使いそうに思えてきます。実装してあげれば、色々使い回せるんじゃないかと思いました。採用する事で、口コミに対する振る舞いを手に入れることができるようになりました。関する記述が消え、以下のようになりました。