FAKELOG

思うがままに書き殴るブログ

スギ薬局のパビリオン開発裏話!

やぁやぁ!

ごっこランドに、また新しいパビリオンが追加されました!なんと、今度は、スギ薬局の薬剤師さんごっこです!薬剤師さんのお仕事を体験出来ちゃいます!

今回は、このスギ薬局のパビリオン開発の裏話をしようかな〜と思います。

新しい開発パートナーさん!

今回のスギ薬局パビリオンは、前回の ECC パビリオンの開発パートナーさんである @komagata(駒形さん) さんに続いて、新しい開発パートナーさんとして @milkcocoa(増田さん) さんに開発を主担当して頂きました!

増田さんは、元々、iOS アプリや Rails を得意としているエンジニアさんで、駒形さんと同じく、Unity 経験は一切ありませんでした。それでも、声を掛けたのは、前職で一緒に働いたことがあり、彼なら出来る!と踏んでいたからです。

前職のときは、お互いフルリモートという環境の中で、Rails アプリの開発を一緒にしていました。多分、リアルで会ったことがあるのは数回くらいで、チャットで話した時間の方が圧倒的に多かったと思います。それでも、結構長い期間一緒に働いていたので、話しやすさややりやすさ、技術力の高さや突破力の高さも知っていたし、また一緒に仕事したいな〜!と考えていたので、ちょうど良い機会でしたね!

これまた、本当にたまたまなんですが、増田さんと駒形さんは、昔、同じ職場で働いていたことがあるそうで、知り合いだったんですよね〜!世間は狭いですね!

ドンピシャなパビリオン!

今回のパビリオンは薬剤師さんごっこだったんですが、実は、増田さんは、薬剤師の資格を持っていて、実際に、薬局で働いたことがあるんですよね!スゴイ!偶然!このパビリオンの話しが出て来たときに、私の中ではもう彼にお願いするほかないと思っていました、正直。

開発を始める前に、その辺の話しをダラダラとしていた様子がこちらになります。

f:id:fakestarbaby:20180623012512p:plain f:id:fakestarbaby:20180623012516p:plain f:id:fakestarbaby:20180623012520p:plain

プロジェクトが始まる前からワクワクしてました。

社内監修によるブラッシュアップ!

毎週の定例で進捗を確認しつつ、増田さんが社内監修的なことをしてくれて、実際の薬局の現場ではね、こうなんですよね!みたいなことを細かく教えてくれたりして、へー!ほー!そうなんだー!となっていました。

この画面にある機械は分包機と言い、粉薬を入れると袋に包んでくれるんですよね。

f:id:fakestarbaby:20180629014944j:plain

最初は、粉薬を入れたとき、こういう感じになっていました。

f:id:fakestarbaby:20180629015351g:plain

でも、本来はもっとこう、分包機の中に溜まってから、徐々に減って行く感じなんですよね〜!という増田さんの社内監修を受け、最終的にはこうなりました。

f:id:fakestarbaby:20180629015415g:plain

なるほど、スゴイ、圧倒的説得力ですね。さらに、軟膏を入れる画面でも、こんな指摘がありました。

f:id:fakestarbaby:20180629012859g:plain

実はもっとこう、軟膏をケースに入れたあとは空気を抜くために、ケースをトントントン!ってやるんですよ〜!と。ほうほう、なるほど、やりましょう!ということで、こうなりました。

f:id:fakestarbaby:20180629013127g:plain

確かに、それっぽさある。

基本的には、クライアントさまの監修済みの企画になっているので、ここまで、現実に寄せる必要性はないっちゃないんですけど、現場のひとがそこに居て、そのひとが良くするための情報を持ってて、良くする時間があるんならやりましょう!やりましょう!現実的に実現可能な対応かどうかの判断は入れた上で、やりましょう〜!という感じです。

こういう感じのブラッシュアップは今までなかったので、とにかく、新鮮で楽しかったです。

相手の顔が見えるの、ヨサある

今回は、週3日、キッズスターに出社する感じで開発を進めて頂きました。弊社としては、全然、リモートでも構わないのですが、出社した方が捗る!ということでこうなりました。

昔、一緒に働いていたときと同じ感じだなぁって思いつつも、やはり、お互いが隣り同士に座っていて、表情を見て話せる、同じ画面を指差しながらあーだこーだ話せるっていうのは、ヨサがありますね。一緒にランチに行って、他愛もない話しをする感じも、なかなか、リモートでは味わえないやつですね、楽しい。

まとめ

以上、スギ薬局のパビリオン開発裏話でしたっ!

Unity の知識ゼロから、アプリをリリースするまでの軌跡

先日、リリースされたごっこランドの ECC パビリオンは、もう遊んで頂けましたでしょうか?

youtu.be

実は、このパビリオンは、キッズスター初の開発パートナーさんによるパビリオン開発、そして、リリースになるんですよね〜!っていうことで、今回は、開発パートナーさん探しをしているころから、リリースに漕ぎ着けるまでの一連の話しをしたいなぁ〜と思います!

開発パートナーさん is なんなの 🤔

キッズスターの正社員ではないんだけど、同じくらいの志を持ちながら、ごっこランドのパビリオン開発に協力して頂けるエンジニアの方たちのことを「開発パートナーさん」と呼んでいます。正確に言えば「パビリオン開発を委託している」ということにはなるんですが、せっかく、一緒に仕事をするんだし、お互い何かしらの恩恵を受けられるような特別な関係性になれたらいいな〜!という思いから、開発パートナーさんと呼ぶことにしています。一緒に開発をするパートナーとして、お付き合いをしたいんですよね。

開発パートナーさんには、ごっこランドのパビリオンを Unity で実装する、という部分を主担当して頂いています。それに加えて、毎月開催している開発合宿にも任意で参加して頂いて、お互いの Unity 力を高めたりもしています。

monry.hatenablog.com

まずは、開発パートナーさんを探そう! 👀

Unity を触ったことがなくても、ある程度、Web をやって来たという実績があり、Unity をやりたい!という強い気持ちさえあれば、パビリオンを開発出来るようになるはず!という思惑があり、ある方に白羽の矢を立てました。

その方とは、合同会社フィヨルド@komagata (駒形さん) です。

駒形さんは、普段は Rubyist として Rails をバリバリ使いこなして Web アプリの開発をしている方なんですが、ちょうど、お互いのタイミングが合いまして、Unity に興味を持ってくれていたこともあり、開発パートナーとしてパビリオン開発をお願い出来ないか、前向きに検討しようと動き始めました。

去年末くらいのことですかね。

もぐらたたきで Unity に慣れる! 🕳🔨

とは言え、その時点では、駒形さんは Unity を触ったことがありませんでした。そのため、お互い、いきなり実戦で開発をお願いすること、受けることに不安を感じていました。

色々と模索した結果、一つの解決策として考え出したことが「もぐらたたき」のゲームアプリを Unity で開発して頂くことでした。「もぐらたたき」のゲームアプリとは、ごっこランドで利用されている必要最低限の Unity の機能を駆使して作る最小のゲームアプリのことで、キッズスターのエンジニアたちで考えた、ただの雑な仕様になります。

esa-pages.io

今、改めて読み返してみても、本当に雑ですね。

ただ、画面遷移を挟んでいたり、uGUI を使ったり、Animator や Animation でもぐらを表示したり、スコアをストレージに保持したり、Scene を跨いで BGM を再生したり、色んなところにつまづきポイントがあるので、このアプリを最初の課題としてチャレンジしてもらうことで、開発に必要となる前提知識が身に付くのではないか?という算段です。

また、Unity でまともなアプリを作ろうとしたときに、どうすれば可読性が良く、メンテナンスしやすく作れるんだろう?何かイイカンジのプラクティスはないんだろうか?という壁に誰しもがぶち当たると思うんですが、その辺の感覚値を感じて欲しかったという思いもありました。というのも、その辺のもやもやした気持ちを起点として、キッズスターでは、Clean Architecture を Unity に適用した CAFU という OSS を利用しているんですが、これを導入することの意味合いをより深く理解してもらえるのでは!と考えていたからです。

駒形さんには、平日の夜と休日のスキマ時間だけでもぐらたたきに挑戦して頂きました。どうやって進めていたかと言うと、Slack 上で色々と質問が出来るホットチャンネルを作り、随時、そこでやり取りをしていました。そのときの様子がこちらになります。

f:id:fakestarbaby:20180508003323p:plainf:id:fakestarbaby:20180508003326p:plainf:id:fakestarbaby:20180508003330p:plainf:id:fakestarbaby:20180508003334p:plainf:id:fakestarbaby:20180508003337p:plainf:id:fakestarbaby:20180508003342p:plainf:id:fakestarbaby:20180508003345p:plainf:id:fakestarbaby:20180508003348p:plainf:id:fakestarbaby:20180508003352p:plainf:id:fakestarbaby:20180508003356p:plainf:id:fakestarbaby:20180508003400p:plainf:id:fakestarbaby:20180508003404p:plainf:id:fakestarbaby:20180508003407p:plainf:id:fakestarbaby:20180508003413p:plainf:id:fakestarbaby:20180508003417p:plainf:id:fakestarbaby:20180508003421p:plainf:id:fakestarbaby:20180508003425p:plainf:id:fakestarbaby:20180508003429p:plain

@monry (もんりぃ) と駒形さんのマンツーマンレッスンのような濃厚なやり取りがされていました。読んでいるだけで自分たちも勉強になる良スレッドですね。

さてさて、そして、最終的に完成したもぐらたたきはこんな感じになりました!

youtu.be

まさか、オリジナルのイラストでもぐらたたきを作ってくれるとは想定していなかったので、最初に見たときは、腰を抜かしました。もぐら、かわい〜! 😍

駒形さんのブログにも、時々、進捗が書かれていましたね。

docs.komagata.org docs.komagata.org docs.komagata.org docs.komagata.org docs.komagata.org

実際のもぐらたたきのリポジトリはこちらになります。

github.com

ECC パビリオン開発始動だっ! 😎

もぐらたたきの開発のやり取りを経て、実装に関する勘所のヨサや、スポンジのような吸収力でどんどん Unity が出来るようになっていく様子を見て、一緒にやりたみが高まり、ぜひ、一緒に開発をしたいです!というお話しをしまして、ECC のパビリオン開発をお願いすることになりました。

駒形さんには、基本的にはリモートで作業して頂いて、日々のやり取りは Slack or Issue で、毎週、定例をするときは Slack Call で、というスタイルで開発を進めました。込み入った実装の話しをするときや、ペアプロが必要なときには、来社して頂くという感じでしたね。

振り返ってみると、ほとんどは、Slack によるやり取りだったように思います。質問をばーん!とチャンネルに投げると、キッズスターの気付いたエンジニアがどーん!と返信するスタイルで、バンバンコメントが飛んでいました。サポートが手厚く感じるかもしれませんが、キッズスターのエンジニアにとっても有益な情報がやり取りされることも多く、へー!ほー!勉強になるー!という感じで、ヨサがありました。

開発期間としては、1月末から3月末まで、約2ヶ月間、ECC パビリオンの主要な部分の実装を全て担当して頂きました。一部、録音機能やごっこランド繋ぎ込みの部分などは、キッズスターのエンジニアも入ったりしていましたね。

キッズスターとして、開発パートナーさんと一緒に開発を進めることが初めてということもあり、色々とご迷惑をお掛けしたと思いますが、無事にリリースが出来て本当に良かったなぁ〜と思います。駒形さんには感謝感謝!の気持ちでいっぱいです!ありがとうございますっ!

ふりかえってみよう! 👀

開発後期、駒形さんと一緒にふりかえりを行い、ざっくりと、以下のような KPT が出て来ました。良かったこともありますが、もっと、カイゼンして行くべきだなと思うところもたくさん出たので、もっと精進したいと思います!直近で、プロジェクトメンバー全員でふりかえりをやる予定もあるので、そこでも、また何か出るかもしれませんね。

KEEP 😙

  • 色んな学びがあって良かった
    • Unity
    • C#
    • Rider
    • Clean Architecture
    • 開発合宿
  • めちゃくちゃ質問出来て良かった
  • 仕様書が細かく書かれていてやりやすかった

PROBLEM 😭

  • 初見ということもあり、工数感が掴めなかった
  • スケジュールに対する温度感がよく分からなかった
  • 仕様書(Spread Sheet)が重たかった
  • Android 検証機が手元になくて、検証が出来なかった
  • 一部機能において、どちらがどこまで実装するのか不明瞭だった
  • Clean Architecture は、ファイル数が多くなる傾向にあるので、ジェネレーターが欲しかった
  • もんりぃ依存度が高過ぎる気がした
  • Entity 周りの命名が雑になりがちだったので、命名規約があると良かった

TRY 😤

  • ジェネレーターを作る
  • 開発が始まる前に、どちらが何をどこまでやるのか定義する
  • 初見の場合は、スケジュールにバッファを持ちつつ、サポートエンジニアを付ける

開発パートナーさんと一緒に戦う姿勢! 😋

有り難いことに、途切れなく、協賛企業様からお声掛けして頂けていることもあり、パビリオン開発自体も次から次に始まっていて、既に、3名の開発パートナーさんたちにお手伝いして頂いています。

まだまだ、至らないところが多くてやりにくさもあると思うので、都度、ふりかえりをしてカイゼンして行けたらいいな〜!と考えています。

開発パートナーのみなさま、引き続き、宜しくお願い致しますっ!

合わせて読みたい 😍

docs.komagata.org

アニメーター大募集中! ✨

キッズスターでは、Unity 上で素材を配置したり、アニメーションを作成出来るアニメーターを大募集しております!少しでも興味を持たれた方がいましたら、ぜひぜひ、お話ししましょう〜!

www.wantedly.com

スシローパビリオンの開発裏話

先月、ごっこランドに追加された「スシローのおすしやさんごっこ」はもう遊んで頂けましたでしょうか?

www.youtube.com

まだ遊んでないよっ!っていう方は、ぜひぜひ、こちらから DL して遊んでみてください〜!

iOS はこちらから!

ごっこランド

ごっこランド

  • KidsStar Inc.
  • 教育
  • 無料

Android はこちらからどぞっ!

play.google.com

さてさて、今回は、このスシローパビリオンの開発中に起きたあんなことやこんなことの中から、特に、私が印象に残っている出来事について、ゆるゆる〜っと書いて行こうかな〜と思います。

ワークフロー的な観点 👀

デザイナーとエンジニアの協業 👯

今までは、Scriptable なオレオレフレームワークを採用していたこともあり、デザイナーが Unity を触ることはほとんどありませんでした。デザイナーから、画面に配置する素材と座標を受け取り、エンジニアが指定位置に素材を配置して画面を構成していく、というワークフローになっていました。

f:id:fakestarbaby:20180414003859p:plain (デザイナーによる細かい指示書を見ながら実装していた)

このワークフローは、デザイナー、エンジニア、双方にとってつらみがありました。デザイナー目線で言うと、素材一つ一つに対して全て座標出しする必要がありとても時間が掛かること、エンジニア目線で言うと、座標位置を確認しながら素材を配置する必要があることです。また、アニメーションなども Script ベースで書く必要があったため、表現の幅に制限があったり、そもそも、エンジニアがアニメーション部分を担う必要があったりして、ここもつらみの一つとなっていました。

しかしっ!

オレオレフレームワークを捨て去り、Clean Architecture というアーキテクチャに乗っかることによって制約が取り除かれ、デザイナーが直接 Unity 上で素材を配置したり、アニメーションを設定するというワークフローに生まれ変わりました。

初めて Unity を触るデザイナーも居ましたが、予め、社内勉強会を開いて Unity や git に関する前提知識を身に付けたあと、実際の業務にあたり、最終的には、GitHub 上でプルリクを出すところまで出来るようになりました。プルリク上で議論を重ねて更にコミットを積む、ということも当たり前のように出来るようになり、スゴイ〜!の一言です。

f:id:fakestarbaby:20180414003600p:plain

本人の努力によるところもありますが、このワークフローが確立出来たことはとても大きいです。今までの作業は何だったんや!っていうくらいに作業工数が圧縮出来て、マジいいじゃん!っていう感じです。

社内勉強会自体は、Unity が使えるデザイナーが主導してくれて、薄い本が出来るのでは?と思うくらいの仕上がりの資料が用意されていました。

f:id:fakestarbaby:20180414004743p:plain (チラ見せ)

公開してもいいか聞いてみたんですが、内容が諸々古くてちょっと今は!ということだったので、その内、整ったら公開するかもしれないし、しないかもしれません。(どっちだよ)

git に関しては、この書籍が最適ですね!主導してくれたデザイナーの自席にも、いつもポン!と置いてあります。

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

このワークフローを確立出来たのは、協力的に、かつ、果敢に挑戦してくれたデザイナーたちによる功績が大きく、ほんと、どうもありがとう!という感じですね。

技術的な観点 👀

Timeline でアニメーション 💃

今回から、新しく Unity の Timeline を取り入れるようになりました。流れるようなアニメーションは、Timeline で実現するとイイカンジにシュッと出来ます。例えば、スシローパビリオンのタイトル画面の Timeline はこんな感じになっています。

youtu.be

些細なことですが、キャラクターの息遣いが聞こえてくるようですね。

このように Timeline を利用すると、アニメーションがどう構成されていて、どう流れて行くのか視覚化されていて分かりやすい!というメリットがありますが、それ以上に、デザイナーが思い描くアニメーションを、デザイナー自身がそのまま Unity 上で再現出来るっ!っていうところがヨサの極みですね。

エンジニアは、デザイナーが作成してくれた Timeline のトリガー(発動条件)と、再生したあとに何をするかという実装に集中出来るので楽チンです。上手いこと分業が出来ていると言えますね。

せっかくなので、ほかの Timeline についても貼っておきましょう〜!

youtu.be youtu.be youtu.be

キッズスターでは、Clean Architecture を Unity に落とし込んだ CAFU という OSS を利用して開発していることもあり、Timeline を扱いやすいようにした CAFU 用のライブラリを利用してこれらを実装をしています。

github.com github.com

興味がある方は、ぜひ〜!

Anima2D でリアリティを!

Anima2D is Unity の機能のことで、2D のキャラクターなどに骨や関節の設定をすることで、リアリティのあるイイカンジの動きを実現出来るようになるんですよ。弊社のもんりぃが Schoo の授業で喋っているので、こちらを見てみるとより理解が深まると思います。

schoo.jp

では、実際に、スシローパビリオンの中で Anima2D を使っているところを見てみましょう〜!

youtu.be

はいっ!分かりますか?

まずは、この画面の説明から始めましょうかね。

寿司ネタって、魚を捌いたあとの姿なので、子どもたちは、実は、元の魚の姿を知らないんですよね。いつも食べてるあの赤いマグロは、実は、海で泳いでる大きな魚なんだぞ〜!という認識がないわけです。なので、まずは、漁に出て寿司ネタになる前の魚を捕まえに行きましょう〜!という意図で作られた画面で、通称、漁画面と呼ばれています。

漁画面では、魚やタコ、イカ、貝たちが自由に泳いでいます。よく見ると分かりますが、活きがイイっ!そう、ぴっちぴちしてると思いませんか?それでは、更に、魚たちを捕まえたときのアニメーションを見てみましょう〜!

youtu.be

ぴっちぴちぃ〜!生きてるぅ〜!

デザイナーの魚に対する愛情が伝わって来ますね。全ての魚に Anima2D で骨を通しているので、まるで、生きているかのようなぴっちぴちの動き方を実現しています。もうタコとかスゴイです。よく分からないです。

youtu.be youtu.be youtu.be

子ども向けアプリという観点で言うと、Anima2D を適用出来るシーンはなかなか見当たらないんですが、ここぞ!というところでは、今後も使っていけたらリアリティが増していいなぁ〜と考えています。

ブラッシュアップ的な観点 👀

キッズスターでは、より良いものを子どもたちに届けたい!じゃないと作る意味がない!というものづくり精神が根底にあり、よく仕様をブラッシュアップします。

プロジェクトメンバー発案でブラッシュアップをすることもありますが、開発途中で必ず子どもテストを実施しているため、そのフィードバックを受けてブラッシュアップを行なったりもします。想定通りになることあれば、そうならないこともたくさんあり、現実は手厳しいですね。

さて、ここでは、スシローパビリオンで実際に発生したブラッシュアップの事例について紹介します。

漁画面 🐟

魚が泳ぐ位置が気になるんすよ! 👀

開発初期のころは、魚たちが泳ぐ位置(高さ)のコントロールがまだ出来ていませんでした。仕様を決めた時点では、魚たちの泳ぐ位置については、誰も言及していませんでしたが、いざ、動いているところを見てみたら、もやもやとした気持ちが生まれました。そのため、そのもやもやを Issue に書いて共有しました。

f:id:fakestarbaby:20180414020006p:plain

どうしたらいいかをみんなで考えていきます。

f:id:fakestarbaby:20180414020134p:plain f:id:fakestarbaby:20180414020414p:plain

なるほど、この案はいいですね!魚の種類を分類して、泳ぐ位置をゾーン分けしよう!というものです。この仕様案を適用したものがこちらです。

youtu.be

画面下部の方には、大きな魚が泳がないようにし、逆に、エビなどの小さい魚は、下の方だけを泳ぐようにしました 🦐

貝、浮いてるのでは? 🐚

まずは、どういうことか、見てみましょう!

https://user-images.githubusercontent.com/29030415/35335642-764af942-0159-11e8-8e44-c1ab7a3f1a9a.gif

???

貝、浮いてますよね?

仕様では、貝は、ぴょこぴょこ定位置で動くだけなんですが、ほかの魚たちと比べても、少し違和感があります。ということで、このもやもやした気持ちを Issue にしたためて共有しました。

f:id:fakestarbaby:20180414021135p:plain

海中だから遠近感を出したりするのも難しそうだしなぁ〜とか思いつつ、議論が重ねられ、背景を変えてみるのはどうか?というアイデアが出ました。試しにハメて見てみたところ、こんな感じになりました。

f:id:fakestarbaby:20180414021533p:plain

貝、浮いてない!ように見える〜!(大事)

こういうもやもやとした気持ちを表明しないまま先に進むと、そのあと、その画面を見るたびに何度ももやもやすることになり、精神衛生上よくありません。あとになればなるほど、今更感が出て来て言いにくい状況を自分で作り出すことにもなります。なので、一旦、そのお気持ちを表明してみんなにももやもやを分け与えておくと、こうして良い結果を招くことにも繋がることがあるのでもやもやの言っていきは大事にしたいところです。

正解パネルの魚が視認しにくい 👀

魚って、薄目で見るとね、大体、一緒に見えるんすよ。

f:id:fakestarbaby:20180414021926p:plain

どうです、見分けが付きますか?どうしても、魚の見た目が酷似しているものがあって、正解パネルを見たときに、パッと見でどの魚か特定出来ないんですよね・・・難しい。

これもメンバーの中で議論を重ねて、出来る限り大きく表示しようということになりました。

f:id:fakestarbaby:20180414022006p:plain

最初と比べると少し大きく見やすくなっています。それでも、完璧とは言えないんですが、魚を知ってもらうという意味合いでも、似てるけどここが少し違うんだよね!みたいな要素もあっていいかな?という妥協点に落ち着きました。

寿司ネタ画面 🍣

タップしてね!が伝わらない 😭

漁に出て魚を捕まえたら、魚を捌いて寿司ネタにします。ここでは、魚をタップすることで寿司ネタに変身していくところなんですが・・・

f:id:fakestarbaby:20180414022110p:plain

子どもテストを実施したところ、何をしたらいいのか伝わらず、戻るボタンをタップして離脱してしまうという事件が発生しました。実際には、魚たちが拡縮していてぽわぽわさせて、タップしてね!を伝えようとしていたのですが、伝わっていなかったようです。

そこで、タップ出来る対象をもっと大げさに拡縮させることで、タップしてね!を伝えることにしました。

youtu.be

現時点のバージョンではこうなっています。しかし、大人でもタップすべきことが分からなかったというフィードバックを頂いたので、今となっては、タップガイド(ここをタップしてね!という意味合いで三角矢印を置き、ここだよ〜!感を出す)を出した方が良かったかな?とも思っています。今、開発中のパビリオンに関しては、タップガイドを出す方向で進めています。

一応、ボイスによるナビゲーションを入れてフォローしてるつもりではありますが、音声自体をオフってる可能性もあるし、聞き逃す可能性もあるので、画面を見て伝わる UI を心掛けたいものですね。

寿司ゲーム画面 🍣

お寿司が捌ききれない 😵

いよいよ、寿司ネタでお寿司を握っていきましょう!

f:id:fakestarbaby:20180417075544p:plain

画面下部にある寿司ネタをドラッグして、画面中央にあるシャリの上にドロップすることで、お寿司が握れます。寿司ネタは全部で10種類あり、お客さんが欲しがっているお寿司に合わせて、左右にスワイプして寿司ネタを探してあげる必要があります・・・という仕様で実装して操作してみたら、ドラッグとスワイプの組み合わせが良くないことに気が付きました。この辺は、Slack 上で議論をしたあと、Issue を立てました。

f:id:fakestarbaby:20180417075749p:plain f:id:fakestarbaby:20180417075949p:plain

ドラッグとスワイプの操作を両立させることが難しいと判断した結果、寿司ネタを切り替えるときは、画面左右にページャボタンを用意して、タップして切り替えるという仕様に変えてみました。

f:id:fakestarbaby:20180417080136p:plain

この仕様であれば、操作が干渉してしまうようなこともなくなるし、一応、ゲーム自体は成立しているように見えますよね。

ということで、子どもテストを実施してみました。

f:id:fakestarbaby:20180417080614p:plain

私が子どもテストを実施する場合は、大体、子どもたちに2回ずつくらいプレイしてもらって、このぐらいの粒度とボリュームで気付いたことを書き出して共有しています。事実ベースで起きたことと、自分の考えをごっちゃにしてしまうと客観的な判断がしにくくなるため、セクションを分けて説明をするように心掛けています。

さて、子どもテストを実施した結果、一番下に記載があるように、そもそも、寿司ネタの数が多過ぎて難易度が高過ぎるっ!ということに気が付きました。お寿司が全然握れず、スコアも伸びない・・・なんということでしょう!ということで、緊急会議を開きました、Issue 上で。

f:id:fakestarbaby:20180417081133p:plain

最終的には、ページャボタンは取り、寿司ネタは、画面内に表示出来る個数に限定してしまうことで、お寿司を簡単にたくさん握れることを目指してこうなりました。

f:id:fakestarbaby:20180417081245p:plain

うん、シンプル。

想定外とは、まさに、このことです。一度、実装したものも、遊んでもらえなければ意味がありません。工数的には色々と無駄にした感はありますが、最終的なクオリティはグッと上がりました。もっと手前で(実装前に)何かしらの手段で検証出来ていたら、更に、良かったかもしれないですね。

寿司ネタから握られるお寿司を連想出来ない 🤔

寿司ネタの素材と、握られるお寿司の素材は別撮りとなっていたこともあり、微妙に形状が違っていたんですよね。どういうことかと言うと・・・

f:id:fakestarbaby:20180417081437p:plain

つまりはこういうことです。

寿司ネタをシャリの上に乗せてお寿司にする必要があるんですが、お客さんが注文してくるのはお寿司のため、寿司ネタからどのお寿司が出来上がるのか、連想出来るようになっている必要があります。ぱっと見で分かるようになっていないとそこに無駄な悩みが生じてしまい、イライラする原因にもなりますし、難易度もグッと高くなってしまうんですよね。

ということで、寿司ネタと寿司は形状を揃えるようにして、見たままの寿司ネタを乗せれば良い、というところに落とし込みました。素材の更新は必要となりましたが、どの寿司ネタからどのお寿司が出来るんだろう?という無駄な悩みはなくなり、たくさんお寿司を握ることに集中出来るようになったと思います。

まとめ: パビリオンリリースの道のりは険しい 😎

会社として、ある程度、子ども向けアプリに対する知見はあるものの、まだ、それが明文化されておらず、一部の社員の中にしかなかったりするので、この辺は、今後、もっと何かしらの手段で共有をしていきたいと考えています。

と書いたそばから、社内の esa に「子ども向けデザイン」という記事と「子ども向け文言リスト」という記事を書いて投稿しました。

f:id:fakestarbaby:20180417082759p:plain f:id:fakestarbaby:20180417082823p:plain

この記事が、知見の共有と蓄積の第一歩となればいいですね。本気を出して書き過ぎた点については、そこは反省しています・・・雑に書けるくらいの敷居の低さ目指して、カイゼン、カイゼン〜!

あと、最近は、社内の有志で集まって「子どものための UX デザイン」の読書会を始めました!子どもってこうだよね、それそれー!みたいな話しや、この考え方をプロダクトに反映するためにはどうしたらいいんだろう?と頭を悩ませたり、こういうアプリもあってね、ココがこう!で、こうなんだよ〜!みたいにワイワイしたあと、それらをきちんとまとめてみんなの知見に昇華出来るような読書会にして行きたいですね。

f:id:fakestarbaby:20180417082953p:plain

こういう活動をもっとやっていきたいな〜と思います。

パビリオン開発は、いつも異なる企業様のコンテンツとなるため、常に、未知との戦いにはなりますが、ものづくりしている感があって楽しいですね。

快適な開発環境で楽しいリモートワーク!

やぁやぁ!皆さん、今日も最強の開発環境でコード書いてますか〜!

最近、開発環境を一新して、より一層、コードを書くことが楽しくなってきたので、そこまでに至った背景や、紆余曲折して、最終的にどんな開発環境に落ち着いたのかを簡単にご紹介したいと思います。

ちなみに、ここで言う開発環境とは、物理的な開発環境のことで、主に、リモートワークをしているときの開発環境の話しになります。

旧開発環境 💻

まずは、以前の開発環境を紹介しておきましょう!と言いたいところなんですが、紹介するまでもなく、以前は MBP 一台のみ!というシンプルな開発環境でした。

f:id:fakestarbaby:20180306225700p:plain

リモートワークをしているパパやママに話しを聞いてみよう!という企画に参加して色々と話したこともあるんですが、コレがないとリモート出来ないんすよっ!みたいなモノも、本当に何も無くてですね・・・。

fledge.jp

特に、何も不自由していなかったんですよね。MBP 一台で開発は出来ていたし、つらみを感じることも全然ありませんでした。

画面一枚のつらみ 😭

ところがですよっ!

ここ最近になり、UnityRider を同時に複数起動して、あるプロジェクトを参考にしながら、あるプロジェクトのコードを書くという場面に遭遇しまして、まぁ、コレが本当につらくてですね・・・。

特に、「コードを書く」という部分に関しては、画面をチラチラすることで、自分の頭に余計な負荷が掛かっているのを強く感じていました。

俺は、画面をチラチラしたいんじゃないっ!コードを見たいだけなんだよっ!うおー!とつらみが一気に高まり、何とかしなければ!という一心で開発環境を変える決意をしました。

サブディスプレイにチャレンジ 🖥

こうなったら、画面を増やすしかあるまい!ということで、まずは、サブディスプレイについて調べました。

どのブランドがいいのか、どのくらいのサイズがいいのか、全く知見が無くて見当も付かなかったため、とりあえず、会社で隣りの席に座ってる @monry(もんりぃ) と同じサイズならいいか〜!という感じで、会社で使うサブディスプレイを経費で買うことに決めました。

コレですね。

ちょうど、値下がりしていた時期っぽくて、最安値で買えたのはラッキーでしたね、経費だけど。

とりあえず、サブディスプレイを繋げてみたものの、まだ、何かしっくりと来ないものがあります。解像度をどうするかとか、画面をどう連結させるかとか、どっちの画面でどのアプリを表示するかとか、まぁ、色々と悩みは尽きないんですけど、一番の悩みはコレでした。

そう、会社と自宅の開発環境に差が出来てしまうというところなんですよね。いつでも、同じ環境で同じように開発をする、ということが難しくなってしまったのです。会社でコードを書くときはいいけど、リモートワークするとき、コードを書くのつらいままやんか!くっそー!

これはいけません!揃えなくっちゃ!

こうして、ここからは、一旦、リモートワークの開発環境の快適さを求めていく感じになります。

自宅にも、サブディスプレイを買うぞ 🖥

会社のサブディスプレイは 4K にしたんですが、解像度 Max にしてみたところ、フォントが小さくなり過ぎておじさんにはつらい感じがしたため、実は、Full HD でもイケるのでは!という思いがありました。しかし、いざ、買う!となると失敗出来ないからな・・・と二の足を踏んでいると、もんりぃが、家のテレビも Full HD なら、試しに画面を写して見てみたらどう?という神懸かり的なアドバイスをくれました。

なるほど!もんりぃ、頭いいなっ!(褒めてます)

それを聞いて、早速、家のテレビに HDMI で繋げて Full HD で画面を確認してみました。若干の荒さはあるものの、全然許容範囲じゃん!ヨサソウ!ということで、27 inch & Full HD に決め、アマゾンをフラフラと歩いていると、たまたま、イイカンジのやつを見つけました。

そもそも、29 inch だし、更に、ワイドなら、左に Unity を右に Rider を表示出来るのではないか!そしたらもう、画面移動しなくていいじゃん!フー!サイコー!などという思惑があり、すぐさま、購入に至りました。会社のサブディスプレイと同じ LG というところもポイント高いですね。

さて、画面の具合はこんな感じです。

f:id:fakestarbaby:20180414000756p:plain

うん、広いっ!開発しているときに、画面チラチラしなくて済むので、とても快適です。むしろ、ワイドなので、会社より快適感があり、引きこもりが加速します。

スタンドで高さを稼ぐ 💪

ここで一つ問題を見つけました。

サブディスプレイの手前に MBP を置いて開いてみると、サブディスプレイと MBP の画面がこう重なるんですよね。もっと手前に引いて作業すればいいのかもですけど、なんとも不便です。

ということで、サブディスプレイを置くスタンドを探し始めました。

デスクの奥行きが狭いため、出来るだけ奥行きが浅めのモノにして、圧迫感をなくそう!という条件で、欲を言えば、スタンドの下にスペースを作って、そこにコード類を隠せたりしたらいいな!という思いもありました。

そして、こちらを購入しました。

田窪工業所 パソコンラック 幅80cm ブラック PCR-80KM

田窪工業所 パソコンラック 幅80cm ブラック PCR-80KM

よく見ると、グリッター感があり、キラキラと輝いているように見えて美しいです。作りもガッチリしていて、サブディスプレイを乗せても、しなったりしません。ヨイ〜!

そして、手前に MBP を置いてもこの通り!

f:id:fakestarbaby:20180414000921p:plain

画面が重なることもなく、イイカンジです。これで、ストレスフリー!

USB ハブを飼おう 🐶

iPhone 充電したいじゃないですか〜!ポケット WiFi の充電や、イヤフォンの充電もしたいよね!というワガママな希望を叶えるため、USB ハブを飼うことにしました。サブディスプレイスタンドの下に飼い慣らせば、イイカンジに目隠しされてヨサソウ!という下心がありました。

ポートもたくさんあって、充電し放題な感じがヨサソウです。実際には、このように、サブディスプレイのスタンドの下に飼い慣らしています。ゴチャゴチャせずに、スッキリと隠せてイイカンジです。

f:id:fakestarbaby:20180215105724j:plain

iPhone どこに置くか問題 📱

iPhone をゴロッと置くのもアレだしね、ということでスタンドを買いました。

スタンドにケーブルが付いていて、差し込むと充電出来るタイプもあるんですが、横でもんりぃがそのタイプを使っていて割りと短い期間で壊れていたのを見ていたので、まぁ、まずは、置ければいいかと。

f:id:fakestarbaby:20180215105624j:plain

弊社のアプリは横向きなので、スタンドに横向きに置いたまま、検証したりすることもあります。

充電用ケーブルたちを定位置に置いておきたい 👆

USB ハブから伸びたケーブルたちは荒ぶりがちです。出来るだけゴチャゴチャしないようにしておきたいものです。基本は、WiFi の充電とイヤフォンの充電が出来ればヨサソウだったので、二本のケーブルたちを定位置に置こうとコレを買いました。

ケーブルをパクッと挟み込み、磁石の力で位置を固定します。奇跡的に、サブディスプレイスタンドが磁石でくっ付く材質になっていたので、このようにして、定位置にピタッとくっ付けて置けるようになりました。

f:id:fakestarbaby:20180215105503j:plain

うむ、収まりがヨイ。

MBP 電源の取り回し 🔌

MBP の電源って、割りと大きくて取り回しが良くないんすよね。コンセントにバシッと差し込んで、そこから充電ケーブルを伸ばしたりすると、まぁ、ケーブルが邪魔だし、そもそも、コンセントの抜き差しが面倒臭い。

そこで、延長ケーブルを買おうと探してみたんですが、まぁ、純正は高いですね。

Apple 電源アダプタ延長ケーブル MK122J/A

Apple 電源アダプタ延長ケーブル MK122J/A

ということで、メルカリの力を借りて、なんと、破格の ¥500 でゲットしました!この延長ケーブルを使うことで、電源タップの口を取って差し替えれば・・・

f:id:fakestarbaby:20180215105854j:plain

ワンタッチで楽に接続出来るようになりました。しかも、電源自体もサブディスプレイのスタンド下にイイカンジに隠れてくれるので、煩わしさもありません。

ミニタイムタイマーで時間を意識する ⏰

ポモドーロをしているわけではなく、どちらかというと、時間を意識するために使っている感じになりますね。

ミニタイムタイマーについては、以前、記事にも書いたりしたので、興味があればこちらをどうぞ!

blog.fakestarbaby.com

各種電源周りをキレイにごまかしたい 😎

ここまでで、サブディスプレイ、MBP、USB ハブの電源を確保する必要があるわけなんですが、何も考えずに配線するとゴチャゴチャになることが目に見えているので、何とかして目隠ししたいと思うわけですよ。

そこで、家に眠っていたコレを引っ張り出して来ました。

各種電源周りはこの中に集約して、キレイにごまかしちゃおうという作戦です。

うん、スッキリ!

f:id:fakestarbaby:20180215105916j:plain

フタを開けるとこうなっています。

f:id:fakestarbaby:20180215105929j:plain

横から伸びた配線は、サブディスプレイスタンドの裏手から伸ばしているので、表向きはスッキリしているところがごまかしポイントです。

f:id:fakestarbaby:20180215105936j:plain

電気毛布 ⚡️

さすがにもう暖かくなってきたのでしまおうかなぁ〜っていう感じなんですが、冬はこれを導入することで、かなり暖かい思いをさせて頂きました。

Sugiyama 【水洗いOK】 敷き毛布 140×80cm NA-023S

Sugiyama 【水洗いOK】 敷き毛布 140×80cm NA-023S

椅子の上にあぐらをかいて座るスタイルなので、ファサッと足の上を覆うようにして使っていました。

f:id:fakestarbaby:20180215110450j:plain

@llminatoll(みなちゃん)@shokolateday(ショコタン) も、全く同じ柄の電気毛布を持っているらしくて、もはや、流行ってます。持ってないひとに、無駄に勧めまくったりもしてましたけど、コスパ抜群です。

最終的なリモートワークの開発環境

f:id:fakestarbaby:20180414002205p:plain

ヨイ。

このスペースは元々、スタディエリアというネーミングが付いていて、リビングからも、二階からも見渡せる位置にあることから、誰でも自由に使えるデスクだったんですけど、開発環境を整えてしまったせいで、パパの作業スペースとなってしまいました。

ゴメンよ〜!

でも、開発に関しては、もう何も文句はないなというレベルで快適にリモートワークが出来て幸せです。環境って大事ですね。

ネガティブに感じることがあれば、それはカイゼンするキッカケになる

毎日向き合う開発環境だからこそ、不便だと感じることをどんどんと無くしていき、快適に作業が出来る環境を整えましょう〜!と、今の今まで全く開発環境を整えて来なかったマンが開発環境を整える戦いの記録でした。

イイカンジの Issue 運用を求めて

先日、スシローパビリオンのふりかえりを実施しました!プロジェクトのふりかえり自体、久し振りだなっ!という感じでしたが、今回は、ファシリテーターとして @lycoris102(ととちゃん) を迎え入れたことにより、とても濃ゆいふりかえりをすることが出来ました〜!ととちゃん、どうもありがとう!

ととちゃんによるふりかえりに関するまとめ記事、オススメなので貼っておきますね。

lycoris102.hatenablog.com

さて、このふりかえりの中で良かったことも悪かったこともたくさん出てきたんですが、その中でも Keep として挙がり、みんなの共感を得た Issue の運用周りのことについて書いてみたいな〜と思います。

ところで、スシローパビリオン is なんなの?

私が所属しているキッズスターで開発している社会体験アプリ「ごっこランド」では、実在する企業様に協賛して頂いて、その企業様独自の子ども向けコンテンツを企画・開発して無料で配信しています。その子ども向けコンテンツの一つとして、先月、「スシローのおすしやさんごっこ」をリリースしました!

www.youtube.com

2018年4月現在、全国各地のスシローさんの実店舗にて告知もしていますので、お近くにスシローの店舗があるみなさまは、ぜひ、美味しいお寿司を食べに行って満腹になったあと、子どもと一緒にプレイしてもらえたら嬉しいですっ!

で、このスシローパビリオンの開発を私が担当していて、無事にリリースしたあと、ふりかえりを実施したよ!というお話しですね。はい、前提、終わりっ!

それでは、Issue 運用に関するアレコレについて書いていきます。

カンバンスタイル

キッズスターでは、Waffle を導入しています。そのため、全社員、パートナーさんが、この Waffle を通して Issue にアクセス出来るようになっています。

f:id:fakestarbaby:20180410214304p:plain

Waffle を導入してから一年くらいが経ち、少しずつやりやすい型みたいなものが見えてきた感じです。

まずは、それぞれのリストの役割について確認してみましょう!

リスト名称 説明
Backlog 直近ではやらないよ
ToDo 直近でやるよ
ディレクター作業中 ディレクターが作業しているよ
デザイナー作業中 デザイナーが作業しているよ
監修中 協賛企業様が監修しているよ
エンジニア作業中 エンジニアが作業しているよ
ビルド待ち 対応完了してビルド待ちだよ
社内検証中 ビルド完了して社内検証しているよ
社外検証中 社内検証完了して社外検証しているよ
Done 検証完了したよ

基本的には、手戻りが無ければ、左から右に Issue が流れて行き、対応されて、ビルドされて、検証されて、クローズするという弊社の開発のワークフローに沿った流れになっています。

アサインと指示を明確にする

スシローパビリオンの開発では、アサインと指示を明確にすることを心掛けていました。

ここでは、運用の一部を例に挙げて説明します。

例えば、ビルド待ちリストには、対応済みだけどまだビルドされていない Issue たちが並んでいます。エンジニアがビルドする必要があるため、このときのアサインはエンジニアになっています。

f:id:fakestarbaby:20180412095254p:plain

エンジニアがビルドすると、DeployGate に IPA / APK がアップロードされます。この時点で、ビルド待ちリストに待機していた Issue たちを、社内検証待ちリストへ移動します。社内検証は、ディレクターのタスクとなります。そのため、このタイミングで、アサインをエンジニアからディレクターに漏れなく変更します。

f:id:fakestarbaby:20180410215419p:plain

このとき、アサインされただけでは、当人は何をすればいいのか不明瞭なので、きちんと、そのひとにして欲しい指示を書きます。ここでは、検証をして欲しいのですが、DeployGate にアップロードされているどのビルドで検証すればいいのか、指示を出してあげる必要があります。指示を出さなかった場合は、ディレクターからどのビルドで検証すればいいのか?という質問が飛んで来ることになるし、そのころにはもう、どのビルドに対応が入っていたか思い出せなくなっているかもしれないので、すぐ指示を出した方がいいですね。

アップロードされたビルドには、バージョン番号が付与されているため、そのバージョン番号を添えて Issue に追記します。更に、メンションも添えています。

f:id:fakestarbaby:20180412003635p:plain

手動で全部やるの大変なんですけど、こうして一つ一つ Issue を開いてコメントして行くことにより、検証するポイントや、やり方などの細かい指示出しをする必要があることに気付けたりもするので、自動化することだけが解決策じゃないかもな、という印象もあったりします。(これは今後の課題)

とにかく、自分の手を離れて、誰かに何かをして欲しいときは、アサインを変える、指示を出すということを徹底していました。

気付ける仕組みを整えておく

キッズスターでは、自分が Issue にアサインされたり、メンションされたりすると、Slack に通知が飛んでくる仕組みを導入しています。これにより、アサインを適切に切り替えていくことで、自分に何かのタスクが割り当てられたことに気付けるようになっています。

f:id:fakestarbaby:20180412095455p:plain

この仕組みは、技術顧問の @ppworks(こっしー) 作のこちらのツールを利用しています。

github.com

ノーアサイン is 放置されがち

たまに、誰もアサインされていない Issue を見かけることがありますが、放置される原因になり得るので、その時点でボールを持っているべきひとをアサインしておくといいですね。

今、誰が、何をしているかを可視化する

自分が作業するときに、Issue をちゃんとリストへ移動する、という基本的なところも大事ですね。今、誰が、何の Issue を抱えているのか可視化出来て便利です。たまに、リストへ移動しないまま Issue に取り掛かるひとが居ますが、自分の Issue を管理するという意味合いでも、きちんとリストへ移動してから着手する、ということを意識した方がヨサソウです。

あと、誰しも人間なので、たまに、Issue を移動することを忘れてしまうこともあります。そういうときは、それに気付いたひとが「あれ、これもう作業中でしたっけ?」と声掛けして「ああ、忘れてたよ、ゴメンゴメン〜!」みたいなフォローが出来ると、なお、ヨイですね!

気付いたらすぐ Issue を立てる

検証に回す前に気付いたことがあれば、躊躇なく、Issue を立てるようにしていました。

例えば、この画面のこの部分はまだ未実装である、ということが分かっているなら、それを Issue として立てておくようにしていました。

こうすることで、ここはまだちゃんと動いてないですよ!という事前共有になります。ここが事前共有されていない状態で検証を始めてしまうと、ちゃんと動いてないけど、バグかな?という Issue が立てられて心配されてしまいます。事前共有さえ出来ていれば、検証する際に、その部分はまだ未実装であるという体で検証を進められます。

また、事前共有することで、今は未実装だけど、これから、実装する意思があるよ!という表明にもなります。遅かれ早かれ Issue として立てられるのなら、気付いたひとがすぐ立てようという話しです。

あと、すぐ書いておかないと、すぐひとは忘れる。

もやもやした気持ちを表明する

なんかちょっと気になったんですよね!っていう、ちょっとしたもやもやの気持ちを表明するため、勝手に、もやもや Issue を立てていました。

f:id:fakestarbaby:20180410221020p:plain

あ〜、もやもやするー!

自分の中に明確な答えや対応方法が思い付いてるわけじゃない、でも、なんかこう、ここがもやもやするんすよ!っていうとき、あるじゃないですか。そういうときに、ゆるく立ててみて、まずは、みんなの意見を伺ってみるという感じで利用されていました。

f:id:fakestarbaby:20180410221621p:plain

するね、するね、もやもやするねー!

私以外のひとも、結構、もやもやしてましたね。

f:id:fakestarbaby:20180410221154p:plain

分かるー!見えるー!左寄りに見えるよー!もやもやするー!

f:id:fakestarbaby:20180410221334p:plain

いいねー!いいもやもやだね〜!

という感じです。

このもやもや Issue から、ブラッシュアップに繋がっていった事例もたくさんあるので、もやもやの表明は大事です。ポイントは、何でも言っていいんだぞ!という心理的安全性が築けているかどうかですかね。

社外検証も同じ Waffle 上で進める

世間には、社内で検証するには足りないくらいの端末がリリースされていることもあり、他端末検証は、外部の会社に委託して検証して頂いています。

そこで上がってくるバグ報告なども、我々が利用している Waffle をそのまま公開していて、そこに直接書き込んでもらうという運用にしています。

最初は書き方などが分からず、Issue のタイトルで事象を全て言い切ってしまうということも見受けられましたが、Issue はこう書いて欲しいですという要望や、運用方法について記事にして共有することで、次第に精度は高くなり、社内と同じレベルで Issue のやり取りが出来るようになって来ました。

以前は、バグ報告専用のツールを導入していたため、運用につらみを感じていましたが、今はツールが統一されてムダの無い社外検証が出来るようになったと思います。

タイトルには、画面名とシンプルな事象だけを書く

スシローパビリオンの Issue の一部は、こんな感じになっていました。

f:id:fakestarbaby:20180410221855p:plain

先頭に該当する画面名を、そのあとに続いて事象を書き出すスタイルに統一されていて、どこの話しをしているのかが一目瞭然で分かりやすかったですね。プロジェクトメンバーの中に一人でもこれを意識しないで Issue を書くひとが居たりすると、統一感が無くなってしまうため、そういうときは、定例などで周知するといいかもしれません。

まだまだ、改善の余地はある!

Keep で出て来た良い側面だけを取り上げてみましたが、当然、もっとここをこうしたいな!という課題も色々とあります。

例えば、ビルド待ちリストから内部検証中リストへ手動で移動させる手間だったり、DeployGate のバージョン番号を調べて記載する手間だったり、Issue のフォーマットが不明瞭だったり、まぁ、色々とあります。

ここはもう日々、改善だと思うので、無理なく自然に仕事が進められるよう、今後も定点観測して行きたいな!と思います。