imog

主にUnityとかの事を書いています

2020年ふりかえり

ふりかえり

あっという間の1年だった。

今年やれたこと

リモートワーク

自分の意志でチャレンジしたというか、コロナ情勢下での新しい働き方が生まれたという感じ。 個人的にはリモートは凄くやりやすい。ただコミュニケーション問題をどう解決していくかは常に考えてかないといけないと思う。 個人的にはセカンドライフなりの空間でコミュニケーションとれると最高なんじゃないかと考えている

スクラムマスター

仕事では、4月からクライアントエンジニア兼スクラムマスターとしてあれやこれやとやっておりました。元々スクラムそのものには興味がありモチベーションとしては高かったものの、実際にロールとしてスクラムマスターを担ったときに自分が何をすべきかというのは結構悩みが多く、書籍を漁ったり人と会話するなどして模索しています。 幸いにも自分の部署はスクラムマスターが自分含めて3人ほどおり、スクラムマスター同士で情報を共有したり雑な相談などを定期的に行えるようにしていたおかげで精神的な負荷がかなり軽減されました。 この辺はなんか別で書きたいところ。

副業

副業で、某会社さんでUnityでテストを書いていくお手伝いをさせていただいてます。ハンズオンしたり、実際のコードを見ながらテストを書いて問題を見つけたりなどなど。テストを書くというか、基本はTDDをやって行けるチームにしましょうという目的でお手伝いしてます。 初めての副業で且つ、あんまり他でやっていることではないのでお互いに模索している段階ですが、今のところは継続させていただいてます。 メンバーの方々は自分より全然キャリアが長い方々なので僕自身も学ばせてもらっています。みんなモチベーションと技術力が凄い。

今年やれなかったこと

アウトプットの減少

コロナで勉強会系イベントが減ったということはあるけど、それを加味してもかなり少なくなったなあという感覚。

ゲーム開発時間の減少

全然ゲーム作ってねえ！ゲーム作りてぇ！

技術記事を書くのも大事だし、執筆して知の高速道路を作っていくのは超大事なんだけど、そもそも完成させるサイクルを増やしていかないと非常に危ないと思っている。自分の持っている知識がよいものとして使えるかどうかはやっぱり実際に使うしかない。それはAPIを触りましたではなく、作り切ってリリースすること。最近だとよく設計論を考えるのだけど、それこそ作るゲームのドメイン領域を突き詰めないと何がベターかを考えることは非常に難しいと思う。つまり、設計が綺麗だけど面白くないゲームというものじゃそもそも失敗なんじゃないかと考えるようになりはじめた。じゃあ面白い面白くないの評価ってなんぞとなるとそれは出すしかないのでリリースしていくべき。で、現状はリリースしてもないのに知識だけを出していっても仕方ないんじゃないか？と思い始めた年なのでした。

今年もお疲れ様でした

正直、とても自分の将来が不安になる一年でした。 まあなんとかやっていきましょう。

よいお年を

UnityでTDDハンズオンしたお話

Unity 雑記

Unityゲーム開発者ギルド2 Advent Calendar 2020 24日目のエントリです。2時間オーバーしちゃったごめんなさい

adventar.org

今月の頭くらいにUnityゲーム開発者ギルドの人たちを対象にTDDハンズオンをやってみました。

何故やったのか

TDDというのはなんとなくわかったのだけど、Unityでのゲーム開発を行うときにどう始めたらいいのかわからないということが最近あったのでどうしようかと悩んでいて。 FizzBuzzをTDDでやってみようなどは既にいっぱいあるけどやはりUnityというものと直接紐づいた事例がないので、もっと現実にありそうなテーマでTDDハンズオンをやってみようと考えたのでした。 何度も繰り返してブラッシュアップしていきたいなと思ったのでどこかで話を聞いてくれる人がいないかなあとギルドで募ったら意外とみなさん手を挙げてくださったので、感謝の正拳突きをしながらzoomでTDDハンズオンをしたのでした。

abe

その時の画像。参加者の方にはモザイクをかけています。僕はアバターで参加しました。

二日連続でやったのですが二回参加された方もいて圧倒的感謝。 2時間超えの長丁場にお付き合いいただきありがとうございました。

UnityでのTDDは特殊なのか

特に何も変わらないと思っています。MonobehaviourがUnityレイヤにべったりで書きにくいというのはその通りですがそれはAndroidのActivityも大体そんな感じだしWebにおけるViewレイヤもそうであるのでUnityが特殊ということは無いでしょう。

どんなことをしたのか

名前変更機能を作ろう

ユーザーが自分の名前を変更できるようにしたい、というストーリー

  • 開いたときに画面に現在の名前を表示させておきたい
  • ユーザが入力フォームから入力できるようにしたい
  • 名前はアルファベットのみで1~8文字以内にしたい
  • 変更に成功したら変更成功したことを表示したい
  • 変更に失敗したら変更成功したことを表示したい
  • 現在の名前が変更後の名前に変わってほしい
  • 名前の変更が保存されててほしい

画面には、自作コンポーネントの貼られていない、それっぽく作ったUIだけを添えています。

image

一切スクリプトがない状態か、これを実装していこう！みたいなストーリーです。

入力と加工と出力

要件は一杯あるので、まずはざっくりと入力と加工と出力に分類してみる。 基本的には出力はテストが難しい。出力はプラットフォーム固有の機能を利用することが多いのでテストに組み込みにくい。ログが吐かれていることをテストするのは若干骨が折れる。また、正解を定義しにくいのもある。「ゲームクリア！」と表示されていればいいのか？「GameClear!」になるとテストとして間違っているのか？みたいなところ。

加工部分は一番簡単である。何らかのインプットをすることで何らかのアウトプットが返ってくることを期待するのはプログラミングの基本だから定義しやすい。

入力

  • ユーザが入力フォームから入力できるようにしたい

加工

  • 名前はアルファベットのみで1~8文字以内にしたい

出力

  • 開いたときに画面に現在の名前を表示させておきたい
  • 変更に成功したら変更成功したことを表示したい
  • 変更に失敗したら変更成功したことを表示したい
  • 現在の名前が変更後の名前に変わってほしい
  • 名前の変更が保存されててほしい

と思ったら出力ばかりでつらいですね。みたいなところから始まるTDDハンズオンです。

伝えたかったこと

大体この2点です

  • 思考を書き出す
  • 不安になったら書きましょう

大きな問題に大きいまま挑むとだいたい返り討ちに合います。メインのゲームを実行できるようにするぞと意気込むと、GameManagerでGodなClassが生まれて無限に連なるゲームを開始するメソッドが生えるでしょう。ゲームを実行するという言葉の解像度を少し上げてみると実はいろんな意味が含まれていたりします。

  • 利用するアセットをロードする
  • 敵キャラクターの生成
  • プレイヤーの生成
  • ゲームタイマーの設定 etc...

コードを書くその前に、対象を観察して問題を細かく分割していくことは大事です。これらは特別なスキルではなく、皆さん割と脳内で無意識に考えているはずです。その結果なんらかのクラスが生まれたりメソッドが生えたりするわけなので。その無意識に行っている分割と思考の整理をテストケースとして書き出すといいのではないかなと考えてます。テストを書くために特別な思考をというよりも、普段の脳内を垂れ流したらテストできてたみたいなイメージ。これを繰り返していくと手癖で書けるようになるのかなあとは思ってます。

不安になったら書きましょうはかなり抽象的な話ですが、自分自身こうしているので・・。すくなくとも全てのコードにテストを書く気はないしテストファーストじゃないといけないことはないです。なんかちょっと怖いな～と思ったら書きます。 怖いなー不安だなーをもっと具体的にするなら、コードの循環的複雑度が高そうなら書くといいのかなと思います。一切のif文のないまっすぐなコードを書くときに不安を感じる人はあまりいないでしょう。

また、不安の元をきちんと整理することも大事です。不安でテストを書きたいけどUnityが提供しているAPIが挟まってて書きにくいという状況もままあるでしょう。しかし一旦整理すると、その不安要素にUnity関係ある？みたいなこともあるかもしれません。僕はTransform.SetParentが正しく動くか不安だと感じたことはあまりありません。そこは想定したインプットをすれば想定したアウトプットをしてくれると期待しているからです。(もし期待通りに来なかったらUnity ForumにPostしましょう)

でも、Transform.SetParentの呼び出しに至るまでに自分で書いたロジックが大量に挟まっているなら不安になるかもしれません。その際は分離をしてみるか、みたいなアプローチを考えて書き直すのもアリかもしれません。

余談ですが、1メソッド単位でテスト書くのは僕は推奨しません。テストを書くためにカプセル化された機能が表に出るのは勿体ないし、メソッド名の変更だけでも修正の恐れがあるのはちょっと辛いからです。メソッドのテストを書くのではなく期待している振る舞いに対してテストを書く方が好きです。

反省

前半は簡単なテストから始めていったけど、後半は出力に近い領域のテストを書くためにinterfaceを挟んでモックを作るなどして一気に加速したのでそこからついていけないということが起きてました。この辺は今後改善していきたいところ・・・。

あとは、題材とした名前変更機能は昨今のスマホゲームなら確かにあり得るテーマだけど、リアルタイムなレスポンスがあったり、オブジェクト同士がぶつかり合ってメッセージングし合うとかいわゆる「ゲーム」みたいな場面とは少し離れているなぁと思った。なのでそのあたりをケアできるといいなあと考えている。

おまけ：欲しいのはテストかイテレーションか

ゲーム開発でテストコードを書くときに度々話題になることとして、Viewのテストが書きたいというモチベーションとの向き合い方があると思う。ここでいうViewは実際に画面に情報を出力する役割を持つクラスと定義する。 前述したが、出力に近い部分のテストは大抵書きにくい。

  • 正常系の定義を定めにくい
  • 変更頻度が多いのでメンテナンスコストが高い
  • 出力部分の機能はテスト上で動かないことが多い

こういう理由があって割に合わないことが多いから自分はあまり出力部分をテストコードでカバーしたいと考えておらず、エディタとか実機で見ようぜ！みたいな考えがあるんだけどやっぱり声は聞いたりする。果たしてその気持ちはどこから溢れてくるのかというのを聞くと、こういうものがあった。

  • 毎回実行して任意の画面まで遷移するコストが高い

コードを書いてPlayMode再生して、ログインしてホーム画面を通って目的の画面へえんやこら。これがアプリケーションの成長につれて時間がかかるようになる。なのでPlayせずに見たいし調整したい。テストコードでなんとかしたい！

凄く気持ちは伝わったけど、多分これはトライアンドエラーのイテレーション速度を上げたい欲求の話で、そこに対してテストコードで正常系を担保というのは目的と合ってなくて難易度が高そうだなと感じた。そもそもトライアンドエラーでいい感じに画面調整するために毎度毎度テストコード書き直すの辛いし。 これの実際の問題は直接画面を開くことができない設計になっていることで、何故直接開けないかというとその画面に必要な情報だけじゃなくてログインしたユーザデータとかその他諸々がシングルトンに鎮座していることが多いから。キャラクタのフレーバーテキストを見る画面でもユーザのインスタンスがないといけないとか稀に良くある。

そのあたりを改善するには、外から最低限のパラメータ流し込むだけで画面が単体で立ち上がるみたいなモジューラビリティの高い設計にしないといけなくて、それはコードを書き直していくしかなさそう。難易度が高いのはよくわかる・・。

なので、Viewのテストが書きたいとなったときは一旦立ち止まって見るのがいいなと思いました。

おまけのおまけ

人間の温かさに包まれました

東方ゲームジャムに参加してゲーム作った

Godot イベント

東方二次創作限定のゲームジャムが開催されてたので参加してみた。

touhougamejam2020.web.app

木曜昼から日曜昼の72時間で開発・・というイベントだが、普通に仕事だったので木曜日に軽く触ってから土曜日から本格的に開発始めました。

作ったゲームの話

そんなわけで、「イブキン」というちび萃香で戦うアクションゲームができました。

touhougamejam2020.web.app

ざっくり言うと、ピクミンに弾幕要素を足したゲームという感じです。最小の犠牲で倒してよりちび萃香を増やして強い敵を倒す。そんな感じです。デザインを整える時間がなかったので中々に厳しいUIをしていますが、ゲーム部分は歯ごたえあると思うので騙されたと思ってやってみて！

進捗の流れ

木曜日

土曜日の夜

日曜日の朝

締切2分前

おもむろにプレイ動画を上げる

www.youtube.com

久しぶりに徹夜での開発をしたが、もう二度とやりたくないなと思った。

「2010年かな？」と思うほど東方のゲームが上がってきてハチャメチャにテンション上がりました。やはり未だに愛され続けてる幻想郷。

ここからはGodotEngineの話

普段はUnityなんだけど今回はGodotEngineで作ってみました。趣味でちょこちょこGodotを触ってはいたのだけどちゃんとリリースまでやったことはなかったので、いい機会とGodotチャレンジをねじ込んでみたのでした。

よかったところ

2D周りの機能が使いやすい

例えば今回はちび萃香や敵の移動として経路探索が必要なんだけど、Navigation2Dとタイルマップ機能が非常に使いやすくサクッと実装できた。タイルにナビゲーションの設定して設置していったらNavigation2Dのパス取得API叩いてよしなに帰ってくるようになってる。

この動画見たらすぐに使えたくらいの手軽さだった。

www.youtube.com

2D用のカメラ機能もあるんだけど、キャラクターを注視しつつ左右の移動幅の限界を付けるとか移動時のスムージングとかその辺はデフォルトで備わってるので凄く助かった。 UI部分も2Dと同じ座標空間で扱えるのでキャラの頭の上にライフのサークル置くとかも脳死でできたり。

GDScriptが楽しい

今回はGDScript(pythonベースの言語)で書いたけど、動的言語ではあるのでダックタイピングがやりやすく開発終盤にはめっちゃ助かった。衝突検知したオブジェクトにDamageメソッドあったら問答無用でぶん投げるとかそういうことを後半にやりまくってた。やりすぎるとどんなオブジェクトがやり取りされてるのかカオスになるけど、型を付けることはできるので基本的には型付けして一部の部分だけ自由奔放なコードができてた。 あとシグナル機能が標準で付いてるのは楽しい。完全に忘れてたので数年前の自分の記事を見ていた。

adarapata.hatenablog.com

yieldとシグナルで非同期を待つのは手軽で便利だった。 Nodeに直接書く埋め込みスクリプトも、特定の部分だけ動かすためにさっと書くということができてうれしい。

イテレーションが早い

デバッグ実行までが異常に早く、コード書き直して1秒で再生できる。これのおかげでトライアンドエラーのモチベーションがかなり高く保ててる気がする。 GodotEngine内でコードを書けるというのも楽しい。当初はエディタは普通に多機能な外部IDEにした方が効率いいんじゃないかあと思ってたんだけど、ゲームエンジン <-> IDE画面を行ったり来たりすることがなくなると、集中が途切れにくくなるなと感じた。GodotEngine内蔵のエディタがちゃんと補完も利くしエラーとなりうる部分を教えてくれるのでそこまで不便ではないのも嬉しい。ドキュメント検索もしやすい。

大変だったところ

日本語記事の少なさ

本当に少ない、これはそう。素直に公式ドキュメントを見るかissueを見るかOSSなのでコードを読むか。今回は幸い近くにつよつよGodotエンジニアがいたので終盤の謎のクラッシュ問題の解消に協力してもらえたので何とか生き延びた。

逆に言えば日本語記事を考慮しなければyoutubeとかにも結構勉強になる動画が上がってるのでお勧めです。

www.youtube.com

おわりに

完成度は置いておいて、久々にちゃんと遊べるものとしてリリースまでもっていったので割と満足度高いです。やはり遊んでもらってナンボだなと思いました。 粗削りな部分が多いのでアップデートはかけていく予定です。

あと、30超えて徹夜で開発はするものではないなと思いました。

2月に読んだ本

読書ログ

今月は一冊のみ。読みかけのレガシーコード改善ガイドを読み終えた。

booklog.jp

レガシーコードに対してどう立ち向かっていくのかを具体的に書いている本。とにかく実例がリアルだった。大量のif文やswitchが継ぎ足されたコードやほにゃららManagerなどなんだか見たことあるもののオンパレードで、且つ章のタイトルが「時間がないのに変更しなければなりません」など胸に刺さる。それらに対してどう切り込んでいくか。テストのないコードはレガシーコードであるとこの本では語っているので、兎にも角にもテストを書く。如何にテストハーネスに入れるかというところが多く書かれていて参考になった。 スプラウトクラス、スプライトメソッドなどの手法は元々行ってはいたが名前はこの本で初めて知ったので非常にためになった。レガシーコードに機能を入れるとき、当たり前ではあるが「これ以上複雑なコードにしたくない」という気持ちが根っこにある。しかし、どうしたら今よりシンプルかつ動くものになるのかを考えるのは難しくて、本当にこれでいいのかな？と試行錯誤しながら恐る恐る修正している。そんな時に書籍に載っていたこの手法！という風に確立されていればかなりの後押しになると思う。そういった点で、この本で名前を知れたことは凄く自分の中でありがたいことだった。もちろん手法が使えるかどうかはケースバイケースだけど。

目の前のレガシーが辛い！となっている人がこの先生きのこるためのサバイバル本って感じでした。

三月はせめて2冊くらいいきたいところ・・

1月に読んだ本

読書ログ

年末から読書欲が高まったので結構読んだ。

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

booklog.jp

元々読みかけだったやつを読み終えた。 現場でプロダクトバックログがうまいこと消化できなかったりしたときにちょくちょく読み返している。本を読んだうえで今もよく感じるのは、見積りの精度を高めるために時間をかけすぎてしまうこと。精度を高めるためにPBIに書いてあることを深読みして実装方法を考え熟考してしまう。その実装方法かわからないのに考えて結局1時間とかかかってしまうこともままあるので、その都度本に書いてある労力と正確さの相関図を思い出すのだった。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

booklog.jp

これも元々読みかけだったやつ。計画づくりの事例よりももっと泥臭いストーリー展開が見れて面白かった。ほぼ小説なのでサクッと読めたのも良い。僕らは果たして江島さんになれるのだろうか。

アジャイルサムライ――達人開発者への道

booklog.jp

アジャイル開発のマインドセットとCI/CDやテストなどがアジャイルの両翼であることが書かれててよいなーと思った。イテレーション・ゼロはこの本で知ったので新規でやる分は参考にできそうだなと思った。ちなみにゲームジャムとかハッカソンの時は「まずはビルドできるようにするぞ！」って意気込んで、なにより最初にビルドが通る環境を作るんだけど、これがイテレーション・ゼロなのではとふと思った。 あとマスター・センセイとか図とかが凄くいい日本語訳されててじわじわ来た。

ファンベース　──支持され、愛され、長く売れ続けるために

booklog.jp

僕もガルパン限界オタクなので、ファンベースで定義されるファンの心理とか精神は非常に理解できた。「そう！それなんだよ！」と頷けるものがあるなら勝手に付いていくし勝手にガルパンはいいぞおじさんをする。新規を取得することは重要ではありつつもどうファンにしていくかは割と疎かになりがちなところなのでこの話は非常に面白かった。特にゲームはこのファン心理が強いものだと個人的に考えている。ファンは開発者を理解したがるし共にあろうとするのだ。

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

booklog.jp

そもそもどうしてレガシーコードになるのか、という話の本。コードレベルだけではなくアジャイルの話とかテストの話とかも割と多めに割いている。どうやって綺麗であるべきかという点が書かれているので、ここを目標として現状との乖離を分析したりするのもよさそう。逆に現在のレガシーコードと立ち向かう方法は書かれていないので、そのあたりはレガシーコード改善ガイドを読むのがおススメ。

www.amazon.co.jp

オブジェクト指向設計実践ガイド　～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

booklog.jp

会社の人にお勧めされ読んだ本。オブジェクト指向がメッセージングのやり取りであること、というのを常に中心に添えているという印象だった。こんなやり取りを行うからこのクラスはこう名付けられるのだという考え方の順序が逆転するのはなるほどなと感心して、これがダックタイピングなのだなあと参考になった。最近どうレイヤー分けするのかというところを考えることが多く、そのレイヤーの中でどう実装するかという名前付けに苦しんでいた。これはどんなUseCaseなのかとかこれは何のEntityなのかとかそういうところ。クリーンアーキテクチャで言うところの「叫ぶアーキテクチャ」になっていないのではないかと悩んでいた。しかしこれこそ、どういうメッセージングを行うかを考えずに名前を付けて役割を考えようとしたことが原因なのかなあと立ち返るきっかけになった。

普段三ヵ月に一冊くらいしか読まないので、自分でも頑張った方やなって思った。 勢い着いたのでもっと読む癖付けよう。

2019年ふりかえり

ふりかえり 雑記

毎年のやーつー

adarapata.hatenablog.com

仕事

相も変わらずテスト書こうぜ！って言ってたりする。新機能を作ったり細々とした改善を行ってたりします。今年は「ゲームのクレジットに載る」という実績を達成したので最高にテンション上がりました。とはいえスマホゲームは運用が続くので永遠に踏ん張りどころだなというお気持ちです。

社内ではクリーンアーキテクチャ本読書会を完走しました

これいい本だからやりたいね！みたいな話から9人くらいで始まって、週一の半年くらいで読み終えました。クライアントとサーバサイドエンジニアの両方が参加していたことで、話し合うときのバックボーンがバラバラになっていたことは結構面白ポイントでした。サーバサイドはこういう設計が行われる、なぜならこうだからだ。ゲームクライアントはこの設計を良しとする、なぜならこうだからだ。みたいな話を聞けるのは新鮮だったと思います。

現在はTDD本読書会やってます。

これは前回よりは人数少ないけど細々とやっております。読んだり、テストフレームワークを写経したりなど。

社内では現行のプロジェクトにかかりっきりで中々自分が横展開できていないのが悩みどころなので来年だなあ。

登壇・LTとか

Unityにおけるテスト&Zenjectみたいな感じで動いてました。 Zenjectに関しては、2019年はZenjectの情報をもっと増やして人口を増やすぞという計画を立てていたので意識的にZenjectのLT回数増やしてます。ブログもそんな感じで年初からZenjectで日本語で説明されているものがない部分を書いてたりしました。

Zenject カテゴリーの記事一覧 - imog

前半頑張りすぎて後半止まってしまった感が否めない。その代わり本書いたので許して・・(後述)

別件で、個人のお仕事として他社のエンジニアを対象にUnityのテストとDIについてお話しするということを行いました。人生初の、「お金をもらって喋る」ということをやったのでめっちゃ緊張しました。これはコンサルティングになるのだろうか・・・。まだ相手の会社さんが記事出してないのでその辺出たら紹介します。

書いたもの

mixiの合同誌「mixi tech note Vol1」で「幸せな開発のために考えていること」という話を10ページくらい書きました。

speakerdeck.com

コードの内側と外側の話を好き勝手書いてます。

9月の技術書典では、Zenjectの同人誌「ZenjectチョットワカルBook」を書きました。

booth.pm

個人誌は初めてなので死ぬかと思いました。こちらは物理本・電子本合わせて200くらい頒布できております。 割と好評いただいているようで、他社でこれ読んで作っておりますという話もいくつか聞いております。本当に感謝・・。 現在ぼちぼち後編も書き始めているので気長にお待ちいただけると幸いです。

ハッカソンとか

今年はPro Developers Game Jamの運営兼開発してました。

prodevelopers-gamejam.connpass.com

prodevelopers-gamejam.connpass.com

あと毎年恒例大八耐もやってました。

daihachitai.connpass.com

「本田君のリーゼントが！」という感じのパズルアクションを作ってました。塩漬けです。

最近ハッカソン系が疎かだったのでｼｭｯと作る能力が落ちてたけど、また勘が戻ってきた気がする

アニメ・映画

去年より意識して観る数増やした。 スパイダーマン・バースは表現にひたすら衝撃を受けたのを覚えている。クライマックスの何が起こってるかよくわからないんだけどなんかカッコいいしなんか分かってしまうバトルシーンは凄かった。 プロメアはTRIGGER節が炸裂していて痛快娯楽だった。滅殺開墾ビームという単語が出てきて劇場で変な声出た。天気の子は昔Windows版遊んでた幻覚を観ました。

でも今期もガルパンが最高でしたね。

ゲーム

正直、RPGはポケモン以外クリアできてないのでつらい。PS4のゲームを腰を据えて遊べなくなってきた気がする。 それ以外としてはシャンティが想像してたより面白かった。結構難易度高めのアクションだったので歯ごたえは十分だった。あとキャラが可愛い。 スパロボTはいつもより絶望感少なくて笑える感じだった。ガンダムファイターとかスパイクとかヴァンとか肉弾戦が強すぎるメンバーが多すぎたのが原因かもしれない。ガンソードが軸にあるからか復讐上等みたいなキャラが多くて後押ししまくってたのもある。最終的にはフル改造したスコープドッグ一機で全滅させてた。 東方鬼形獣で久々にSTGをやったんだけど、どんどん腕が衰えて弾幕が避けられなくなってて悲しかった。ノーマルクリアはしてEXをまだクリアできてないのでリベンジしたい。 ガルパンドリームタンクマッチはオンラインの過疎化が辛い。みんなやろう。

大洗

7月と11月に行ってきた。最高だった

その他

バズった

まとめ

ふりかえってみると去年より活発になっていた気がする。アニメ本数多いし。 意識的にやってたのもあり、この1年でUnity界隈において「Zenjectに詳しい人」という立ち位置にはなれたのかなと自負している。仕事のお話が出たのもそこからだったし。というか逆にそれ以外やってない。DOTS周りをもっと見たかったけどできてないし個人開発もあまり進んでないので全てはトレードオフなのだと実感する一年だった。 とは言え、個人で同人誌を出したり技術コンサル的活動をしたりと新しいことには取り組めたので割と良い2019年だった。来年は副業としてそういうお仕事をもっとやってみたい。お気軽にお声がけください。

仕事納めとスクラムの話

雑記

今日で仕事が納まった。それと同時にチームメンバーが一人チームを去ることになった。送別会もしたのでお別れはまあそれなりにしたんだけど、結構自分に影響を与えたのでなんとなくブログとして残しておくことにした。

 

うちの部署は複数のスクラムチームで構成されているスクラムオブスクラムという形を取っている。僕がこのチームに配属されたのは二ヶ月前くらいのことだ。部署内の別のチームからこのチームに異動したのがきっかけだ。チームメンバーの一人であり、今回お別れした人は認定スクラムマスターを持つエンジニアであり、このチームはちゃんとアジャイルなチームになろうとしているという話を事前に聞いていた。(以降、この人を彼と呼ぶ)

前職でもスクラム開発はやっていたつもりだったし、以前のチームでもスクラムを行なっていたのでなるほどなるほどという感じでチームのやり方に乗っかっていくことにした。見積もりをして、計画で洗い出し、ポイントを計測して振り返りでTRYを洗い出そう。そんな感じに思っていた。しかし、今まで自分が経験したやり方とはチームのやり方の違いに衝撃を受けた。特にこの2週間くらいの出来事を列挙する。

 

 並行してタスクをこなすことがなくなった

 

スプリントでやることはPBI(プロダクトバックログアイテム)を基にして計画で洗い出す。一つのPBIが大きいならどんどん分割していく。完了条件が定義しやすくなるまで細かく刻んでいく。そこから具体的に何が必要かを職種問わず洗い出して付箋に貼り出していく。この時に誰がやるかとかは一切考えない。

この時に、分割で複数のPBIが現れることになる。分割しなくても関係ない別のタスクがPBIとして存在することもある。(新機能追加と既存の改修が同時に存在したり)でも優先度は計画時点ですでに決まっている。ここで、今までだったら複数人エンジニアがいるのだから並行してやるのでは？と思ってたがそうはならなかった。必ず優先度の高いPBIを全員でこなす。それが終わらない限りは次のPBIには触れなかった。そもそもスプリントに入らなそうなら今スプリントでやるPBIから外した。理由を聞いたら「並行して個人で行う時点でそれはチームの意味があまりない」とのことだった。最初はなるほどな〜くらいの意識だったが、朝会夕会もしくは業務時間でこれどう進めようかという話を全員で行えるのは気持ちが楽なことに気がついた。なによりやることがシンプルで、眼前にあるPBIをどう完了するかを考えるだけでよかったのは脳のスタックの消費が少なかった。

 

 一人でコードを書かなくなった

 

このチームは自分を含めてエンジニアが3人いる。上記でPBIをこなす際に全員でという話をした通り、エンジニアも全員でこなす。つまりモブプログラミングの形式を取って実装を進めていた。一人が実際のコーディングを行い周りでやいのやいの話す形式だ。

 

tech.smarthr.jp

 

全員でPBIを見ながら改めてこの実装が必要では？という話をする。逆にその実装はこのPBIを完了させるのに必要ではないのでは？なんてことを喋りながら付箋にやることを書き出す。それぞれに得意分野は違う。一人はプロダクトのキャリアが長くドメインに詳しいので、その観点から現状の仕様を話してどう実装すべきかを提案する。自分はチーム内ではプロダクトのドメインに乏しいが技術的な観点での話はできるので、こういう実装方法ならテスタビリティが高いのでは？ということを提案して実装を進めていく。それをやいのやいの話しながら動くものを作っていった。

この作業は効果的に働いたと思う。全員で考えて作ることで発生しうる問題をある程度予測できたからだ。三人寄れば文殊の知恵というが本当にその通りだなと感じた。

副次的な効果としてコードレビューの手間が省けた。そもそもみんなで作っているので改めてレビューする部分が少ないからだ。(とはいえPRで俯瞰して見た時に微妙な書き方のツッコミはしたくなったので無ではない)

 

もう一つの効果としてQAとの関わり方が少し変わった。

ちょっと前までモブプロでエンジニアが作る -> ビルドしてQAに動作確認してもらう -> 不具合を見つけたら報告してもらうというフローを採用していたが、これだとスプリントの前半はQAが暇になって後半が詰まってしまうよねという問題が発生した。これを解決したいねーというのがチームの課題になった時に、「モブプロに入って貰えばいいのでは？」という話になった。所轄モブワークである。エンジニアが作ろうとしている時点でチェック項目が生まれるのだから、ビルドを待たずとも最初から入ってもらえればその時点でチェック項目を作成できるし、Unityエディタ上で動作チェックもできるだろうという考えだ。

このやり方は成功した。エンジニアがこういう実装が必要という段階でQAさんが「このパターンとか大丈夫ですか？」みたいなツッコミが入り初期段階で懸念点を潰すことに成功したのだった。エンジニアが複数人集まってもうっかり気づけない項目が結構あることを思い知らされた。プロフェッショナルはすごい。

加えて隣の席に座っていたプランナーも会話が聞こえるので普通に入りやすく、こういう感じでやりたいとかこういうデータで試しにやってみるねなどのコミュニケーションが円滑に行われた。目の前で動かすし、即座にこうしたいが入るので、少なくとも出来上がったものに認識のずれはなかった。

 

なにより単純に楽しかった。どう作っていくかを話し合うのはそれ自体が楽しいのだ。

 

チームで作っていくという認識を改めた

 

「チームで作っている」というのは仕事なら当たり前なんだけど、本当にできていたのだろうかと考えるきっかけとなった。仕様が固まってないのでできませんとか、実装したけどQAの手が空いてないので進んでませんとか、僕が書いたコードではないのでわかりませんとか、仕様の詳細は企画に聞いてくださいとか。

彼は「チームの成果物はチームが責任を持つべきだ」と強く言った。スプリントレビューに出すものは、みなさんどうしたらいいですかね？と周りに意見を求めるものではなく、うちはコレを作った！バーン！と責任を持って出してGood!Bad!みたいなフィードバックを貰わなければならないという話だった。そうしないとチームとして成長できない。そのかわり責任はチームでシェアしたいよねということも付け加えた。だからこそ個人で分担するのではなくチーム全員で立ち向かわなくてはならない。隣の人が今日何をしていたかわからないというのはチームとして動けているのか？それはslackにログを流していれば解決することなのか？とか。

 

しかしその逆に、チーム外に関してはもっと閉鎖的で良いと考えていると彼は話した。この話のキッカケになったのはコードレビューだ。チーム内コードレビューは簡単だが、別のチームのコードレビューはコンテキストが把握しきれないことも多くそれなりに大変だった。コレに対して、レビューの必要性そのものを考えるべきということだった。それぞれチーム内レビューで完結させて、そこで不具合が出るのならばそれがそのチームの現状であるので、チームで改善していくのが良いのではという話。その改善の過程で他のチームにレビューを求めるならそれは応じてあげればいい。

自分はわりとプロダクト全部のコードを知っておくべきだと考えていたし、レビューそのものが技術的な成長のきっかけだと考えていたのでこの考え方は新鮮だった。意見の是非ではなく素直に参考にしたいと思った。

 

 

年末年始はUnityのDOTSについて調べようかと思ってたんだけど、一回アジャイル開発の本を読み直そうと思った。それくらいこの2週間は衝撃で、楽しかった。見積りをしてポイントを出したスクラム開発であることは今までと変わらないけど、今までとは明らかに違う部分に触れられた。

来年からは彼がいない状態のチームでやっていくことになる。今までのようなチームを維持できるかはわからないけど、彼がいないから上手くいかなくなりましたというのはそれこそ自己組織化ができていないのでそうならないように立ち回っていきたい。

おつかれさまでした。