FAKELOG

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

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 のフォーマットが不明瞭だったり、まぁ、色々とあります。

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

キッズスター入社3年間のふりかえり

f:id:fakestarbaby:20180331092230p:plain

春ですね 🌸 先日、キッズスターが入居している世田谷ものづくり学校に隣接している世田谷公園で、お花見ランチをして来ました。ちょうど、春休みの時期だったので、子どもたちがワイワイ遊んでいて、見ているだけで癒やされました。

さてさて、実は、2018年3月9日付けで、キッズスターに入社してから3年が経過していました。つまり、キッズスター4年生になったわけですね〜!ということで、入社3年間を駆け足でふりかえってみたいと思います 😎

❤️ 入社当時の思いと今の思い

入社当時に書いた記事がこちらです。

blog.fakestarbaby.com

今思い返してみても、運命的な出会いだったなと思うし、この選択は間違っていなかったなぁという思いがあります。

子どもたちを笑顔にするために、もっともっと突っ込んで、色々とやってみたい!という強い思いが今の自分を突き動かしています。

入社当時の思いはとてもシンプルですね!

驚くことに、入社して3年が経過した今でもこの思いは全く変わっていなくて、むしろ、まだまだ、やれるぞっ!もっともっと〜!という思いが溢れている感じすらあります。もはや、自分の中で「絶対に揺らがない決意」みたいなものになっていて、いつでも、この思いに突き動かされながら行動している自分が居ます。

💻 エンジニアとして取り組んだこと

普段、そこまで、エンジニアっぽさが出ていないこともあって、コードなんて書いていないのでは?と思われがちなフシがあるんですが、一応、コードも書いているんですよっ!

ということで、今までに携わったプロダクトを、ざっと書き出してみました。

Unity × iOS / Android アプリ

Unity × Kinect

  • 大激走!フリフリコースター > 新規開発

Unity × ScanSnap

  • ディノアミーゴス > 新規開発
  • ディノクラフト > 新規開発
  • ディノレース > 新規開発

Cocos2d-x × d キッズアプリ

サーバサイド

その他

  • 映画連動アプリ > 新規開発
  • TV 連動 AR アプリ > 新規開発

大小様々ではありますが、3年間ともなると、やはり、それなりのプロダクト数になりますね。

臨機応変に担当するプロダクトを乗り換えていたので、Unity と Cocos2d-x と Web API を行ったり来たりしていることが多く、なかなか、スキルが定着しなかったように感じています。

Unity に関して言うと、当時は、オレオレフレームワークを採用していたこともあり、Unity の本質的な部分の理解に踏み込まなくても、何となく動くものが作れてしまうという状況にあったことも、スキルの定着を遠回しにしてしまっていたような気がしています。オレオレフレームワークの習熟度だけが上がって行く、というイメージですね。

上記以外のところで言うと、属人性を減らして作業を分担出来るようにすることにも取り組んでいました。それでも、特に、もんりぃ(@monry) の属人性が高過ぎるせい(スーパーマンなせい)で、剥がしても剥がしても隠し球が出て来るので、未だに剥がしきれていないんですが・・・。

あとは、キッズスターでは、企画の初期段階からエンジニアも参加することが出来るため、プロダクトをゼロからみんなで作り上げて仕上げて行くところをたくさん経験出来た、というところは、自分的には大きな成果だったかなと思っています。1人で開発する壁みたいなところを打破するために、チームで開発出来る環境を選んだということもあったので。

やっぱり、一人で作るよりも、圧倒的に色んな意味で良いものが作れますね。前職のときに開発していた知育アプリと比べると、圧倒的にクオリティも良く、1人では到底作り得ないものを提供出来ていると思います。

😍 エンジニアとしての価値を実感する

そして、エンジニアとして大きな転機となる一日もありましたね。少しだけ、この記事でも触れています。

blog.fakestarbaby.com

自分たちで考えて作り上げたサイネージアプリをプレイするためにわざわざ並んでくれて、ドキドキワクワクしながら自分の番になるのを待ってくれて、一生懸命プレイして楽しんでくれて、笑顔がたくさん生まれる場所になっていたんです。本当に感動して涙が出そうになりましたよ、嬉しくて。あんなに疲れた仕事をしたことはなかったし、あんなに充実感に溢れた仕事をしたこともなかった。本当に最高の日でした。あのときの感動は、ずっと自分の胸の奥に刻まれていて、あのためにまた頑張ろう!という気持ちを今も持ち続けています。

今でも鮮明に覚えているんですが、自分が価値を提供出来る存在であるということを、リアルに自覚することが出来た瞬間でした。この仕事において、自分に自信を持てるようになったのも、このころからかもしれません。

🕊 エンジニアという枠組みの外に出る

さて、もちろん、私は、エンジニアとして会社に雇われているわけなんですが、いざ、この3年間を振り返ってみると、実に、色んな動き方をしていたような気がします。

基本的には「会社のためになることで、自分に出来ることがあるのなら、何でもやるぞ〜!」という精神です。会社にそういう役割や動き方を指示されたわけではなく、あくまでも、自発的に、出来る範囲のことをやって来ました。キッズスターという会社が好きなので、会社のためになることをしたい!良くしたい〜!という一心ですね。

技術はもんりぃが、それ以外全部を私がやる、みたいな役割分担が出来ていて、世間一般で言うと VPoE 的な役割に該当するかもしれませんね。役割として与えられているわけではないので、今はもう、みんなそれぞれが帽子を付け替えて臨機応変に動く、みたいな感じになっています。

というわけで、エンジニアとして仕事をする傍ら、会社、プロジェクト、開発チームをより良くするためにはどうしたらいいんだろう?なんてことを考えながら、ただただ、がむしゃらに色んなことに取り組んたことをふりかえってみます。

🏡 リモートワーク導入

リモートワークに対する理解ゼロの状態からリモートワークを導入して、今では、ほぼ全員が任意のタイミングでリモートワークをしている状態にまでなりました。

こんなインタビューを受けたこともありましたね。このころはまだ、リモートワークを試し始めたばかりで、社内に広めて行くぞー!と意気込んでいたフェーズですね。当時は、ここまで、リモートワークが浸透するとは夢にも思っていなかったので、本当、嬉しい限りです。リモートバンザイ!

fledge.jp

リモートワークに関しては、個人的に思うことがあり、こちらの記事でもまとめています。

blog.fakestarbaby.com

とは言え、最近では、みんなに会うために出社することも楽しくって、リモートの割り合いとしては、週の半分くらいになっているとバランスが取れていいのかなぁ〜と思います。

🌈 技術顧問就任

エンジニア採用を推し進め、エンジニアチームをより強くするために こっしー(@ppworks) に技術顧問として力添えをして頂くように尽力しました。

私とコモンの馴れ初めなどは、こちらで紹介しています。

blog.fakestarbaby.com

コモンのお陰で、エンジニアたちは圧倒的に成長している感があるし、中のひと目線じゃない外のひと目線でバンバン指摘してくれるので、色んな気付きがあります。

コモンと一緒に仕事を始めてから、まだ、1年と少ししか経ってないことに驚きを覚えつつも、それは濃ゆい1年を共にしたからだ!ということで、今年もまた楽しみですね。

会社としても、チームとしても、また、自分自身としても色んな課題が山積みで大変な状態ではありますが、これからも、エンジニアチームのメンターとして宜しくお願いしますっ!

🐥 esa 導入

esa を導入して社員全員分のアカウントを発行して、今では、業務で日常的に使われるまでになりました。

esa を導入してしばらくは、上手く情報共有を回すことが出来なくて、一人、自分の日報を眺めては涙で流していたという時期もありましたね。詳しくは、esa 社のインタビューで語っています。

docs.esa.io

ここでは余り語られてはいませんが、まだまだ、課題はたくさんあるので、一つ一つの課題と向き合いながら、ヨサ溢れる感じにして行きたいな〜と思っています。esa 楽しいよ、esa 🐥

👂 共有会

以前は、経営陣と直接対話する場はありませんでしたが、お互いの考えていることを知るための場として、色んなことを共有し合う会を隔週で設けて実施してきました。各セクションのコアメンバーが参加して、色んな課題に対する議論をする場になっています。経営に関する熱い議論がされることもありますが、何もなかったころに比べたら、議論が出来ている時点で全然マシです。

ただ、最近では、隔週では議題の議論が間に合わないくらいのスピード感になってきているため、今週からは、毎週、1時間ずつでやって行こうと考えています。お互いの距離感を保つためにも、会社の透明性を担保するためにも、課題に確実に向き合うためにも、隔週でやるより、毎週、短い時間でも開催する方がヨサソウなんですよね。これは、今後も継続して実施して行きたいなと思います。

エンジニア採用

今までは、チームがスケールするフェーズを経験したことがなかったこともあり、採用自体に関わることはありませんでしたが、キッズスターでは、エンジニアの採用を任せてもらえることになりました。まさか、自分が採用に関わる人生が訪れるとは、夢にも思っていませんでしたけどね。

知見も何もない中、恐れずに前に進めたのは、一緒に働く最高の仲間を見つけたい!という強い思いと、コモンの支援があったからこそだと思います。

コモンは、前職でこのような記事を書いており、採用に関する実績と知見があり、頼りまくりました。

japan.zdnet.com

採用活動を始めてからは、自分のこと、エンジニアチームのこと、会社のことを広く伝えるため、エンジニアの募集記事を書き起こしたり、たくさんのひとに出会って色んな話しをしまくりました。こんなに色んなひとと会って話したことって、ほかにないよなぁ〜という感じです。

大きな会社ではないので、募集に対して、そこまでたくさんのひとが来てくれるわけでもなく、もどかしい思いをする時期もありましたね。

採用は、ひととひとの出会いであり、お互いの人生に関わる重要なイベントなので、いつも、そわそわしてしまいます。どういうひとなんだろうな?という期待感とか、上手く会社のことを話せるかなとか、相手のことを理解出来るかなとか、我々のことを理解してもらえるかなとか、色んな気持ちが錯綜するんですよね。でも、そのくらいの緊張感がちょうどいいのでは、という気もしています。

キッズスター、気になるんすよね〜っていう Unity エンジニアな方が居ましたら、ぜひ、ご連絡をお待ちしています〜!

www.wantedly.com

プロデューサー、Unity デザイナーやイラストレーターも募集していますので、もし、周りに子ども向けプロダクトに興味あるひとが居たら、ご紹介して頂けたら嬉しいです!是非〜!

www.wantedly.com www.wantedly.com www.wantedly.com

👀 開発定例 / KPT

毎週の開発定例の中で、エンジニアと個人 KPT をする時間を設けて実施して来ました。コモンの導きによる影響が大きいのですが、この個人 KPT によって、エンジニア全員、大きく成長出来たのではないかな〜と思います。この短期間でここまでひとは成長出来るのか!と見違えるほど、成長したエンジニアも居ます。

また、この個人 KPT で出た課題を解決しようという動きもしていたため、その中の一貫として、リモートワークの推進だったり、GitHub & Waffle.io 導入の推進だったり、プロジェクトの KPT 実施だったり、業務改善のトリガーになるものもいくつかありましたね。

今は、最近、入社した ととちゃん(@lycoris102) の個人 KPT と、プロジェクトの KPT を実施しています。プロジェクトの KPT に関しては、その内、ととちゃんがブログ記事を書いてくれたらいいなぁ。(プレッシャー)

追記: 2018/04/05 (木)

どうやら、ととちゃんが記事を書いてくれたみたいなので、リンクを貼っておきます!(サンクス!勉強になります!)

lycoris102.hatenablog.com

🌟 そして、キッズスター4年生

上手く行ったことも、上手く行かなかったことも、たくさんあったけど、どれも今までの自分が経験したことがないことばかりなので、そういう意味では、スゴく貴重な時間を過ごせていたな〜と思います。

それを生かして、キッズスター4年生をどう過ごそうか、というところですね。

😋 今後、取り組んで行きたいこと

最近は、ごっこランドに標準を合わせて事業を進めていることもあって、スキルは、Unity に一本化されるようになってきました。また、オレオレフレームワークを捨てて Clean Architecture を採用することで、Unity 本来が持つ機能を活かしながら開発が出来る状況になりました。というわけで、やればやるだけ自分のスキルアップが望めるし、何より Unity に詳しいもんりぃが側に居て何でも悩みを聞いてくれるところに有り難みを感じているので、やるぞ〜!という気持ちでいっぱいです。

あとは、最近入社したととちゃんは、前職で KPT やふりかえりをガンガン回してファシリテーションしていた実績があるので、その辺も、彼から上手く盗んで自分のものに出来たらいいなぁと思っています。

一番成し遂げたいことは、やっぱり、うん、パビリオンをたくさん作って、もっともっと、たくさんの子どもたちに楽しんでもらいたいってことですね〜!

課題は山積みで考えなくちゃいけないことも、やりたいことも、やらなくちゃいけないこともたくさんあって、頭を抱えるシーンは多いけれど、それでも、今の仲間となら、乗り越えて行けるという確信があります。それくらい頼もしい仲間たちだと思っているので、協力して、より良いプロダクトを子どもたちに提供して行きたいなと思います。

より良く!より良くだー!

やるぞやるぞ〜っ!

✨そして、息子も小学生に!

入社日である3月9日は、息子の誕生日でもあります。当時は、フルリモートから出社するスタイルに切り替えたばかりだったので、「パパ!どこへ行くの!」と泣きわめいて、窓にすがりついていた光景を思い出しますね。

今ではもう随分と大きくなり、小学生になるとか、ちょっと時間の流れがよく分からない感じですが、息子の成長に負けないように、パパも頑張ろうと思います!