kugi's notebook

やったこと、思ったことなどつらつらと書きます

モーションブラーのレンダリング

はじめに

こちらの記事はレイトレーシング Advent Calendar 2021の18日目の記事です。

(大遅刻をしてしまいました...)

qiita.com

こちらのアドカレに投稿させて頂くのは初めてになります。

昨年までは広島で蛍光現象のレンダリングについて研究をしていて、 現在は東京でゲームプログラマをしています。

最近はレイトレを改めて一から勉強するため、１週間レイトレをベースに進めています。

github.com

RAY (Notionに残しているメモ)

今回は Ray Tracing: The Next Week から「モーションブラー」についての記事になります。

モーションブラー

モーションブラーは撮影のタイミングで被写体やカメラが移動することによって起きます。 シャッタースピードが速いカメラで動いている被写体を撮影すると、被写体が止まっているような写真を撮ることができます。

実験してみた

以下のように、左から右へ移動する赤甲羅を被写体にし、カメラのシャッタースピードを変えて撮影します。

iPhoneのカメラでは設定からシャッタースピードを変えることができないみたいなので、 「Mカメラ」というアプリを使って変更しました。

M=Camera

M=Camera

  • KANAME OHARA
  • Photo & Video
  • Free
apps.apple.com

シャッタースピード 1/15秒

シャッタースピード 1/500秒

変更したのはシャッタースピードのみなので、露光時間が短い 1/500 秒の方では少し暗めの画像になっていますが、赤甲羅のブレは少なく、くっきりとした輪郭が撮影できています。

逆に露光時間の長い、シャッタースピード 1/15 秒の方では、モーションブラーがつき、赤甲羅が横に走って行ったということ画像からがわかります。

モーションブラーのレンダリング

それでは、モーションブラーありの画像をレンダリングしていきます。

モーションブラーはシャッタースピードを変えることで表現することができます。 そのため、カメラとカメラから飛ばすレイに時間の概念を導入します。

このカメラではシャッターが t_0 から t_1 の間開いていることになり、シャッタースピードはt_1 - t_0 秒です。

get_ray()関数は時刻 $t$ においてカメラから飛ばしたレイを取得する関数です。 (ここで時刻 t は [t_0, t_1])

// カメラ
class camera {
  public:
    /// ...

    float _t0 {0.0f};
    float _t1 {1.0f};

    /// ...

    ray get_ray(float u, float v) {
        float time = _t0 + drand48() * (_t1 - _t0); // 時刻 t は t_0から t_1の間
        return ray(origin, lower_left_corner + u * horizontal + v * vertical - origin, time); // 時刻 t に飛ばしたレイを返す
    }
}

class ray {
 public:
  ray(const vec3& origin, const vec3& direction, float time = 0.0f) {
    _origin = origin;
    _direction = direction;
    _time = time;
  }
  vec3 origin() const { return _origin; }
  vec3 direction() const { return _direction; }
  float time() const { return  _time; }
  vec3 point_at_parameter(float t) const { return _origin + t * _direction; }

  vec3 _origin; // レイの原点
  vec3 _direction;  // レイの進む方向
  float _time; // 時間
};

そして、描画するオブジェクトに対しても時間の概念を持たせます。

Ray Tracing: The Next Weekではt_0からt_1の間でp_0からp_1に移動する球を実装します。

/// 移動球
class moving_sphere : public hitable {
 public:
  moving_sphere() {}
  moving_sphere(vec3 cen0, vec3 cen1,
                float t0, float t1,
                float r,
                material *m) :
                center0(cen0), center1(cen1),
                time0(t0), time1(t1),
                radius(r),
                mat_ptr(m) {};
  virtual bool hit(const ray &r, float tmin, float tmax, hit_record &rec) const;
  vec3 center(float time) const; // 時刻 t における球の中心位置
  vec3 center0, center1;
  float time0, time1;
  float radius; // 球の半径
  material *mat_ptr; // 球のマテリアル
};

/// time0 から time1の間で移動する球の
/// 時刻 t における中心座標
vec3 moving_sphere::center(float time) const {
  return center0 + ((time - time0) / (time1 - time0)) * (center1 - center0);
}

そして、レイと球の交差判定、散乱、反射を計算する際にはある時刻 t におけるレイの計算として処理を拡張します。 時刻tにおけるレイを用いて計算をすることで、時刻t_0から時刻t_1の間にカメラのセンサーが受け取った像の平均値としてシミュレーションすることができます。

描画結果

モーションブラーなし

モーションブラーあり

モーションブラーありの方では、時刻t_0から時刻t_1の間、左から右に移動する球を用いました。

まとめ

今回はじめてレイトレーシングアドベントカレンダーに参加させていただきました。 (にもかかわらず遅刻してしまい申し訳ないです...)

本当は研究もしていた蛍光現象の記事を書きたかったのですが、 準備が間に合いませんでした...。

来年こそはしっかり準備をして、蛍光現象についてのアドカレ記事を書きたいです。

頑張るぞ〜〜〜！

引用

https://raytracing.github.io/books/RayTracingTheNextWeek.html

週末レイトレーシング 第二週 (翻訳)

レッツクライム💪

はじめに

こちらの記事はUnityゲーム開発者ギルド Advent Calendar 2021の11日目の記事です。

adventar.org

今年もUnityゲーム開発者ギルドの皆さんには大変お世話になりました。 来年もどうぞよろしくお願いいたします！

今回はUnityの話...ではなく、 クライミングの話をします。

クライミングはいいぞ

さて、みなさん登っていますか？ 私は最近週２ペースで登りに行っています。

今回は以下の流れでクライミングについてご紹介したいと思います。

「クライミング」って？

東京オリンピックでも競技種目になりましたが、 「クライミング」よりも「ボルダリング」という言葉を耳にすることの方が多いかもしれません。

実はクライミング(ロッククライミング)は登ることの総称で、 ボルダリングはその一部です。

ロープを使わず、落ちても致命的なケガにならない通常3〜5m程度の高さの壁を登ります。

(CLIMBING-NETより引用)

クライミングの中にはロープを使って登る「リードクライミング」などもあります。

ロープをカラビナに引っ掛けていきながら登ります

私はボルダリングだけでなく、リードも好きなので言葉としては「クライミング」をよく使います。

ボルダリングの基本的なルール

今回はクライミングの中でも、ボルダリングの基本的なルールについてまずは説明します。

日本にもボルダリングジムはたくさんあるので、１度は登りに行ったことがあるという方もいらっしゃるかもしれません。

ボルダリングウォール

ボルダリングでは、クライミングシューズ以外はロープや手袋といった補助器具を使用せずに、ホールド(壁に取り付けられた突起物)や壁そのものを使って登っていきます。

しかし、ただ上に登れば良いというわけではありません。 登る際は、スタートホールドからゴールホールドまで決まったコース(課題)を登っていきます。

青ホールドの課題

画像のコースだと、青いホールドだけを使って登っていく課題になります。

また、スタートとゴールは静止した状態でないといけません。 (例えば、ゴールホールドにタッチするだけではゴールにならない。)

基本的な制約は以上で、コースのホールド使う手順や登り方自体は自由です。 もちろん壁に足を置いてバランスを取っても問題ありません。 (実はこれがとても重要)

コースの表記方法はジムごとによっても違い、ホールドの色で分けられていたり、テープで分類されていたりします。 また、コースごとに難易度(グレード)が「6級、5級、...、１級、初段、２段、...」と決まっていて、自分のレベルにあったコースを登ったり、難しめのコースに挑戦したりいろんな楽しみ方があります。

なんだかゲームみたいで楽しそう！！

ちょっとしたコツ

さて基本的なルールもお伝えしたので登る際のコツについて少しだけお話ししたいと思います。

実は握力はそこまで必要ない

握力が重要と思われがちですが、実はそこまで握力が強くなくても登れます。 (私自身も両手50kg前後)

ホールドにはペットボトルキャップよりも小さいものから、両手で抱え切れない大きさのものまであります。 「掌全体で握り潰す力」というより、「適切な持ち方を維持する力」の方が重要だと言えるかもしれません。

また、先ほどもありましたが、バランスや体感も非常に重要です。 腕で登るのではなく、体全体を使って登ると楽に登ることができます。

以下のことを意識して登ってみてください！

  • 腕をできる限り伸ばす
  • そのためには腰を低く落とす
  • 足を置く位置に意識して登る

登っていない時間も大切

ボルダリングジムに行くと壁をジッと見つめる人や、壁をみながら手を動かしている人がたくさんいます。

クライミングは登っていない時間も非常に重要です。 コースを見て、登る際のシミュレーションをすることを「オブザベーション」と言います。

実際に登ってみるとわかるのですが、オブザベーションをせずに登ると次のホールドの位置やコースが全体的にどう進んでいくのかが全く分からず、 身動きが取れなくなってしまいます。また、安全マットの外からコースをみていた時の視点と壁に取り付いている状態での視点は全く違うので尚更わからなくなります。

スタートとゴールの位置を確認することはもちろんですが、途中のホールドの位置や足場の位置、ホールドの持ち方についても入念に確認した上で登りましょう！ (という私もオブザベ不足でキョロキョロしながら登ってしまうことは多々あります...)

実際に登る前に、一度頭の中で登るべし！

日本代表クライマーの方々の動画もオススメです。

www.youtube.com

だからやめられないクライミング

私は中学3年の冬にクライミングに出会いました。 登らなくなってしまった時期もありましたが、 登り始めて以来、引っ越す先々で登ってきました。

私が思う「クライミングのここがいい！」というポイントについてもご紹介したいと思います。

自分の成長がわかる

ルールの部分でも説明しましたが、登るコースには難易度があります。 自分の目標となる難易度を目指して登ることでレベルが上がっていくことを実感することができます。

また仮に登れない壁(コース)にぶつかったとしても、 なぜ登れなかったのか考えて繰り返し挑戦することで、いつかは(きっと！)登ることができます。

「壁を通して自分自身と向き合い、成長を感じれる」のでとても好きです。

登れなかったときの悔しさをバネに壁と向き合おう！

行きつけのジム

ここまで読んできたみなさんはきっと

「早く登りにいきたい！」

と思っているはず！！

最後に私の行きつけのジムを紹介したいと思います。

TOKYO STONE SESSION

THE STONE SESSION TOKYO (@tsstokyo) • Instagram photos and videos

スカイツリーの近くにあるジムで、スカイツリーを見ながら登ることができます。 課題のグレードが隠されているのが特徴的です。(スタッフの方に聞けば教えてくれます！)

B-PUMP TOKYO 秋葉原

pump-climbing.com

４階建てで曲面壁やアウトドア壁もあります。 ショップの品揃えも豊富なのでシューズを購入する際はおすすめです！

Piglet

piglet-climb.com

最近はここで同期と退勤クライムしています。 とてもアットホームなジム！

まとめ

今回は趣味のクライミングについて書かせていただきました。 実は最近ギルドの方とも登りに行くようになり、クライミング好きが増えて嬉しいです。

「登ってみたい！」という方は是非お声掛けください。 一緒に登りに行きましょう〜！

unity1week「2」振り返り ~「Kani と Uni」に込めた想い~

はじめに

お久しぶりです。kugiです。 4月から社会人になり、慌ただしくも楽しい日々をおくっています。

さて、今回はゴールデンウィークで参加した Unity1週間ゲームジャム - お題「2」 の振り返りをしたいと思います。

f:id:kugi_masa:20210530114106p:plain

u1wの概要についてはコチラ

参加に踏み切るまで

実は今回のu1wはギリギリまで参加するかを悩んでいました。 というのも、

  • 社会人になった今、1週間のモチベーションと気力を保ったまま開発できるのか...
  • あらためて1人でゲームが作れるか不安...

といった気持ちがモヤモヤっと出てきたのです。

前回、前々回とチーム参戦だったので、今の力量でチャレンジするという意味でも、参加するならソロ開発にしようと思っていました。

前回の 「お題『回』」 でnattuhanさん、つっちーさんの３人で作成した NOA's Projectは学生として参加する最後のu1wで、自分の中では一つの区切りと捉えていました。

学生の頃はイベント駆動開発がほとんどで、ゆっくりインプットするということを次第にしなくなっていました。ちょうど社会人なり、時間もあるゴールデンウィークなので積読している技術書を読んだり、ゆったりStayHomeでハンティングライフに没頭するのもありだな〜と考えていました。

しかし、Twitterやギルド(Unityゲーム開発者ギルド)で参加している方達の進捗やワイワイ感を見たら自分は絶対 「参加すれば良かった...」と思うこともわかっていました。

私はu1wをゲームを１週間でつくる(今回は遅刻しましたが...)イベントというだけでなく、お祭りのようなものだと捉えています。

最近では200、300を超えるゲームが１週間で投稿されます。それの制作過程が進捗としてTwitterなどで共有される。そして1週間後に実際に遊べる。また、ぱふもどきさん、まっともぉんさんをはじめとするいろんな方が実況プレイしてくださる。そしてそして、u1wが終わった後も青木ととさんが主催されているu1w共有会で制作の過程や開発者の方の目標などを聞くことができる。

もちろんゲームを投稿せずに遊ぶ側にまわったり、実況や共有会を視聴するだけでも十分楽しめるお祭りだと思います。

それにプラスして、自分もゲームを投稿した場合、自分のゲームを遊んでもらえてレビューを貰えることもある。もしかしたら、今回自分のゲームを遊んでくれた方が、次回参加するときのチームメンバーになることだってあるかもしれません。

これはもう、参加するしかないでしょ...!!!

と気づいたらお祭りに参加したい欲がモヤモヤを上回っていました。

目標を決めよう

「モヤモヤを上回っていました」と書いたものの、モヤモヤが消え去ったわけではありません。 モチベーション維持と一人で作りきるために、まずは今回の目標を設定することにしました。

今回設定した目標は以下の2つになります。

  • オンラインゲームに挑戦する
  • kugiにしか作れないゲームを作る

一つ目の目標としてオンラインゲームを選んだのは、これまでに挑戦したことのないことだったからです。 これまでのu1wを振り返ってみても、何かしらやったことのないことに触れてみるようにしていました。

お題 作ったゲーム 挑戦したこと
さがす あにまるハンター ・就活で作成した企画書をベースにゲームを作ってみる
・u1wに初挑戦
密 密蜂〜Cluster Bee〜 ・自作モデルを使用して作る
・LightmapをベイクしたりLightingを調整してみる
・u1w共有会で発表
ふえる Groundwater ・URPでPost-processing、Shadergraph使ってみる
・Timelineでアニメーション
あける すきすきスキマん ・u1wでチーム参戦
・ドット絵アセット全て自前で
・CloudBuildの活用
回 NOA's Project ・学生以外の方とチーム開発
・設計を考えて分業する
　(スキマんの時はほとんどアセット要員だったのでw)
・DoTweenに触れる

お題がちょうど「２」ということで2人対戦や2人プレイなどが浮かび、オンラインゲームにすることにしました。

2つ目については、自分のキャラクター(chillballとkani-chan)を起用することで「kugiにしか作れないゲーム」を作ることにしました。

f:id:kugi_masa:20210530180643p:plain f:id:kugi_masa:20210530181023p:plain
chillballとkani-chan

chillballは私が日常を4コマで描いているkugi日記に登場したキャラクターです。

また、kani-chanは自分がまだUnityに触れたばかりの頃に大学の友人と2人でゲームを作ろうとした際に、その友人が打ってくれたドットです。 結局ゲーム完成には至りませんでしたが、Unityを使った開発の原点のような気持ちもあり、slackのstatusではkani-chanにいつも見守ってもらっています。 (勝手に借りてごめんよw🙏)

f:id:kugi_masa:20210530183737p:plain
Slackのユーザステータス

このように、挑戦したことのないオンラインゲームへ挑戦することでモチベーション維持を、また1人での開発だからこそできる自分らしさの盛り込みをすることで、モヤモヤは解消されました。

そして開発へ

そうして今回製作したのがKani と Uniです。 2分間の間でマッチングした2匹のKaniでUniをたくさん倒すゲームです。

unityroom.com

f:id:kugi_masa:20210530190125p:plain
Kani と Uni

オンラインゲームを製作するにあたって、私は今回オンライン対戦ではなく、オンライン協力で遊んでもらおうと思いました。 あえてオンライン協力を選んだのは、

u1wを通して偶然マッチングした人と一緒に協力をして楽しい体験が共有できたらめちゃくちゃエモいだろうなー

と思ったからです。

そういう意味でも今回はランキング機能を競わせるための要素ではなく、偶然マッチングした二人の名前が記録されるものという意味も込めて、メモリー(Memories)と名付けました。

f:id:kugi_masa:20210530185957p:plain
メモリー(Memories)

楽しさの共有ではEbiを収集アイテムとして散りばめて、Ebiをマッチングした二人で一定数集めたら無敵KaniになってUniを一掃するというEbi Dance機能をつけました。

chillballを起用したこともあり、全体的にchillな雰囲気を表現したのですが、EbiDance状態中は一変してUIを虹色に光らせてみたり、BGMもEDMっぽいものに変えたりと雰囲気をガラリと変えました。

この雰囲気の緩急とUniを一掃する気持ちよさを共有させたいという部分がこのKani と Uniに込めた私の想いです。

初めてのオンラインゲーム製作ではo8queさんの「PUN2（Photon Unity Networking 2）で始めるオンラインゲーム開発入門」にとても助けられました。 PUN2を初めて使う私でもオンラインゲームを作ることができたので、オンラインゲームに挑戦したい方にはおすすめの入門書です。 改めてこの場でお礼申し上げます。o8queさんありがとうございました!!!

zenn.dev

ちょうど最近4コマを描き始めたということもあり、画像アセットについては手書きで用意しました。

f:id:kugi_masa:20210530211533p:plain
手書きのアセット

バグから生まれる遊び

公開したはいいものの、マッチングしないと遊べない状態だととそもそも体験してもらいたいことを提供できないので、CPU(ドット絵kani-chan)を実装することにしました。

オンラインゲームでは通信の確認をするため、ゲームを2つ起動してテストをしなくてはなりません。 今回私は一度ビルドしたものとUnityEditor上で実行した2つのクライアントでテストをしていましたが、かなり効率が悪かったように感じます...。 この効率の悪さからも細かいところでバグを踏んでしまっていて、kani-chan実装にかなり苦労しました。

unity1week online共有会 #5のzizoさんの発表でもあったように、Unity Hub上で別プロジェクトとして登録してエディタを2つ起動することで快適に動作確認ができそうです👀

www.youtube.com

そして、なんとかkani-chanが投入でき、CPUモードでツイートした場合は

今度は Kani-chan 以外と遊びたいな...

の一文が追加されるようにしてみました。(気づいた人はいるだろうか...笑)

無事kani-chanも導入でき、事なきを得たかと思いきや...

部屋によってEbiが大量発生したり、Uniが無限に出たり、逆にEbiが全く出なくなったり

と、もはや誰かが「Kani と Uni」の生態系をいじっているのではという事態に...

しかし、ゲームの進行事態には問題がなく、部屋ガチャとして機能していたので 仕様としては残すことにしました。

Ebiの大量発生部屋は一部ではSSR部屋と呼ばれ、 盛り上がっていただけました笑

まっともぉんさんやぱふもどきさんのオンラインゲーム配信でも取り上げていただけて、 実際に遊んでる方の反応が見れたのはとても嬉しかったです。

youtu.be

また、nattuhanさんとつっちーさんにはNoa's ProjectのDiscordサーバーで通話をしながらテストプレイやデバッグをお手伝いしていただきました。 感謝です!!🙏

まとめ

参加するかどうかを最初は悩んでいましたが、やはり参加して本当に良かったです。 こうして毎回楽しく参加できているのも、主催のないちさんをはじめとする、u1wというお祭りに様々な形で関わっているみなさんあってこそだと思います。ありがとうございます!!!

私のKani と Uniへ込めた想いをしっかりとゲームを通して伝えることができたかは分かりませんが、 今回掲げていた2つの目標も大方達成できたと思います。 また、結果として初めて総合評価にランクインすることもできました。 プレイしてくださった皆さん、本当にありがとうございました！

次回もできる限り、前向きな気持ちで参加したいと思います。 それではまた！

2020年振り返り

はじめに

いよいよ年明けです。今年は特にはやかった気がします。

2020年の振り返りを書いていきたいと思います。

1月　〜ほとんど広島にいなかった〜

ちょうど就活の面接が始まった頃で、関東に行くことが多かったです。

友人が巣鴨に住んでいたので、いつも泊めてもらっていました。 ありがとう!!!!

enPiT2019のメンターをしていたので、広大チームの成果発表会のために筑波にも行きました。

kugi-masa.hatenablog.com

リアルタイムレンダリングについて学習するために、OpenGLのチュートリアルとかもこの時期から少しづつやっていましたね。

2月　〜研究、就活にBlender〜

1/31~2/2 で開催されたGGJ広島2020に参加しました。

Global Game Jam 2020 in Hiroshima - connpass

お題は確かRepairで、私たちのチームは

壺を割ってくる勇者に壺を割られる前に壺を「修復」するゲーム

を作りました。

私はモデルとアニメーションを主に作成しました。

ある程度できたけど、あともう少しという感じで少し不完全燃焼だった記憶があります。takさん(@bgdaewalkman)と一緒に開発できたのでヨシ!!!

研究では中間発表が2月でした。中間発表と就活の面接x2が同じ週にあるという鬼ハードなスケジュールでしたが、なんとか乗り切りました。

年度が変わる前でもあったので研究室の大改造が行われていて、Blenderで改造後のイメージ構図を作成しウォークスルー動画を撮ったりもしました。

(今見るとLighting雑雑の雑)

この時期ハマってたドラマはMR.ROBOT🤖

3月　〜さよならFishy〜

2月末に1社内定をいただくことができたので、就活は第一志望を残すのみでだいぶ落ち着きました。

Unity1Week「逆」に参加しようと思っていましたが、2月が割と立て込んでいたのでこの回はスキップすることにしました。

Unity 1週間ゲームジャム お題「逆」 | フリーゲーム投稿サイト unityroom

Fishyという魚になって「逆」に釣られないようにするゲームを作っていました。 絶賛unityNweek中です!!!おそらくお蔵入りです笑

あとはどう森買ったり、モンテカルロ法で円周率計算するやつ作ったりしました。

4月　〜オンラインでいろいろ〜

新年度が始まりM2になりました。コロナの影響でオンラインイベントが増え、いろんなイベントに参加するようになりした。

また、昨年度まではあまり顔を出せていなかったHiCoderも、オンラインになったことで参加するようになりました。

高校の同期とZoomでオンライン飲み会が毎週金曜日に開催されるようになったり(私はあまり参加できていませんが今でも続いてる👀!!)

OpenGLで作った三角形🔺で遊んでみたり

Cammelでの新プロジェクトのためにFlutterはじめたり

CammelでLT会(MomijiLTの全身)をオンラインで開いてYouTubeLiveで配信してみたり

kugi-masa.hatenablog.com

インプットとアウトプットがいい塩梅の年度始まりでした。

5月　〜ハッカソンとLTと〜

5月はハッカソン(ゲームジャム)とLTにたくさん参加しました

レッドハッカソンオンライン2020では特別審査員賞をいただけました🎉

kugi-masa.hatenablog.com

また、前回参加できなかったunity1weekに参加して、共有会でも発表ができたのもよかったです!!(unity開発界隈の知り合いが増えました🙌)

そして、未来掴みました👍

6月　〜スクラム、チーム開発インプット月間〜

アジャイル、スクラム界隈のイベントに参加しました。

『SCRUM BOOT CAMP THE BOOK 増補改訂版』出版記念イベント、そして4月ごろから数回参加していた分散アジャイルチームについて考える会に参加しました。

そして月末にはenPiTでお世話になったmiholoveさんのご厚意でいただいたスポンサーチケットでSCRUM FEST OSAKAに参加してきました。

kugi-masa.hatenablog.com

密度の濃ゆい凄まじいインプットばかりでした。

Cammelでの開発にも持ち帰って活かすことが少しはできたかな🤔

またこの時期からUUUOでのインターンも始まりました。

7月　〜就活と縄跳びの終わり〜

長かった就活が終わり、月初めに茶摘みをしました🍵 とてもいい経験になりました!!

また、4年半お世話になったMacBookAirとお別れをし、MacBookProを購入しました🎉

そして、縄跳びはこの日を境に途切れ、ZUMBAを家でするようになりました。(なお三日坊主)

8月　〜ハッカソン月間〜

8月はUnity1Week「ふえる」とOpen Hack U Vol.2に参加しました👨‍💻

github.com

この「ふえる」のu1wから他の方とランキングで競うことが多くなり、ハッシュタグを生やすなどしました。

あまりランキングに組み込めていませんが、真のu1wランカーズ目指して頑張りたいです😤

8月からCammel LTがHiCoderとコラボ開催になり、MomijiLTになりました!!🍁

youtu.be

9月　〜ハッカソン主催〜

9月はハッカソンを2つ(?)主催しました。

1つ目はカニハッカソン🦀

...という名目でインターン先のカニの在庫管理アプリの開発をスタートしました笑

kugi-masa.hatenablog.com

カニノケンカでも遊びました👍

ハッカソンは主催しましたよ!!笑👀

HU hackathon 2020 onlineというオンラインハッカソンを主催しました!!

kugi-masa.hatenablog.com

ISUCON10に出場したり、Unityゲーム開発者ギルドに参加したのも9月でした

scrapbox.io

10月　〜キーボード作った!!!〜

自作キーボード好きのラボメンの影響で、学生のうちに自作キーボードを作りたいと思っていたので、

ゆかりキーボードファクトリーさんのMint60を購入しました。

とても気に入っています😎

次のunity1weekに向けてaojilu君とSilCilさんとチームを組み始めたのもこの頃でしたね。

kugi-masa.hatenablog.com

10月からシェーダー芸の作品も少しづつ作っていきました。 また少しづつ学びながら作っていきたいですね〜

github.com

SPAJAM2020にも参加しました!!

11月　〜JPHACKSと学会〜

11月には今年からオンラインになったJPHACKSにCammel全員で参加しました🐫

kugi-masa.hatenablog.com

また、初の学会に参加し優秀論文賞をいただけました!!!🎉

12月　〜そして師走〜

Unityゲーム開発者ギルドの方の配信をみたりDiscordで雑談したり楽しい年の瀬でした。

Unity1Week「あける」には私たちチームaojiluも参加し、「すきすきスキマん」というゲームを作りました。

評価期間も1/10(日)までなので遊んでいただけると嬉しいです!!

unityroom.com

まとめ

今年もいろんな方に大変お世話になりました。

今年はコロナの影響でオンラインで何かをするのがとても多かったです。 オンラインになったことで、イベントに参加しやすくなってよかったです。 それでも来年こそはオフラインイベントにも参加したいですね。

来年からは社会人です!! 残りの学生期間、研究に開発、最後まで楽しみながら頑張りたいと思います💪

それでは来年もよろしくお願いいたします!!

カニから学んだこと

はじめに

こちらの記事は広島大学ITエンジニア Advent Calendar 2020 19日目の記事です。

私は今年の5月ごろから広島の株式会社ウーオという水産業界の流通をITで支える会社でエンジニアインターンをしています。

uuuo.co.jp

8月はじめから11月末にかけて、エンジニアインターン生の2人で始まったカニの在庫管理アプリプロジェクト「かにっこ」を一度クローズすることになりました。

こちらの振り返り記事ではプロジェクトの振り返りとかにっこを通して学んだことについて共有したいと思います。

かにっこ

「カニは鮮魚と違って、在庫として抱えることがあるから管理が大変」

この課題を解決するために「かにっこ」は始まりました。

まずはカニのオペレーション(商品をセリ落としてからお客さんに出荷するまでの流れ)について学ばないといけないので、管理がどう大変なのかを切り出して考えることにしました。

  • カニは鮮魚とは異なり、セリ落とした商品をその日に出荷するだけでなく、UUUOの在庫として確保することがある。
  • また、在庫として確保されたカニは急にいなくなったり(脱出...)水死して売れなくなる場合がある。
  • カニには様々な規格や状態がある。
    • 例)
    • めちゃくちゃ多いです🦀
    • 同じ1番2番でも港によって規格が微妙に異なります。
  • 出荷の際、松葉ガニは枚数、セコガニはcs数(規格によって決まった枚数を1ケースとしてまとめて出荷する)で管理する。
    • 雌のカニのことをメガニまたはセコガニと呼ぶらしいです。
    • カニの数え方は1匹、2匹ではなく、1枚、2枚と数えます。

これらのことから、カニの在庫管理は鮮魚でのオペレーションと異なり複雑で大変になっていることがわかりました。

システム設計

今回はインターン生の２人でプロジェクトの立ち上げから設計、そしてリリースまでを任せていただけるという機会をいただきました。実際に使っていただく広島のオフィスにいらっしゃるセールスチームや港でセリに参加して商品をセリ落し出荷作業を行うベースチームの方々に対してヒヤリングを行ったり、オペレーションフローの情報を元に「かにっこ」がオペレーションのどこで使われるかを考え設計を進めていきました。

f:id:kugi_masa:20201214143723p:plain
オペレーションフローとかにっこ

以前までのUUUOの業務では私がFlutterを用いたフロントエンド実装、もう一人のインターン生がrailsを用いたサーバーサイド実装を主にしていました。今回のプロジェクトではお互いのスキルアップのためにもロールを途中で入れ替えて取り組みました。モブプロ形式も取り入れ、お互いの得意な方を相手に教えることで得意な方の実装への理解も深まりました。

また、Miroを使ってタスクの見える化、言語化を行い、GitHub Issueで実際に着手する実装タスクの管理を行いました。

これまでCammelで行ってきた開発やハッカソンではFirebaseなどのBaaSを用いて実装していたので、バックエンド実装についてあまり考えずフロント実装に専念していました。しかし、今回APIの実装やデータベースの設計に触れることで、フロント側で呼び出したAPIのリクエストがサーバーサイドでどのように動くのかを知ることができとても良い学びになりました。

今後はサーバーサイドのことも考えてフロント実装に取り組んでいきたいと思います。

運用の難しさ

「かにっこ 」はファーストリリース(社内アプリなのでTestFlightでの内部リリース)まではできたものの、「かにっこ 」の運用までには至らず、結果としてプロジェクトをクローズすることになりました。

  • 実際にテスト運用してみると、モバイルよりPCでの入力の方が向いていた
  • 現在スプレッドシートで運用ができている
  • オペレーションのなかで変更の要望があったとき、アプリケーションでの実装よりも、スプレッドシートの修正の方が素早くカイゼンできる

以上の要因から今回クローズをすることにインターン生二人で決めました。

管理ができないままでは問題なので、セールスチームの方がスプレッドシートで管理シートを作成され現在はそちらでカニの在庫管理運用をしています。

カニのオペレーション以前から、ベースチームやセールスチームの皆さんにはお時間を取っていただいてアプリの壁あてにご協力いただきました。しかし、実際カニのオペレーションが始まりテスト運用をしていただく中で、現実的にオペレーションに組み込みづらい点や修正点が出てきました。そして、そこからの修正(主にデータベースの再設計)に時間がかかってしまいました。

今回得た学びは、課題をもっとシンプルに切り分けて小さい領域(MVP)でテストをする方が良いということです。実際にアプリを作っている段階では「一折、二折」といったカニの状態や松葉ガニとセコガニの枚数とcs数の違いまで実装に組み込んでいましたが、実際にテスト運用をしてみると、カニが生きているかと水死しているかが一番重要で、カニの状態までは確認と管理している時間はありませんでした。また、松葉ガニとセコガニでの違いは管理する単位だけなので、最初は松葉ガニのみに絞ってテストしてみる方が早く修正し次のテストに取り掛かれたと思います。

f:id:kugi_masa:20201214150200p:plainf:id:kugi_masa:20201214150204p:plainf:id:kugi_masa:20201214150209p:plain
This is かにっこ

おまけ(カニハッカソン🦀)

「かにっこ」が始まった直後にちょうどLTをする機会があったので、「カニをハックしてみた」という題で発表をしました笑。 スライドを以下に掲載します!!

speakerdeck.com

まとめ

結果としてはクローズしてしまったプロジェクトになってしまいましたが、実際に使ってもらえるユーザがいる状態で一からプロジェクトを立ち上げて実装する機会をいただくことができて本当によかったです。

また、プロジェクトのクローズと運用の難しさを学生のうちに経験することができました。 もちろん悔しさもありますが、その分学びも大きかったです。

サポートしていただいたUUUOエンジニアの土谷さんをはじめ、ヒアリング、壁あてにご協力してくださったセールスチーム、ベースチームの皆さんありがとうございました。

f:id:kugi_masa:20201214150352j:plain
Thank you Kanikko

やったこと

  • インターン生2人でプロジェクト立ち上げからクローズまで経験した。
  • カニについて学んだ。

わかったこと

  • 松葉ガニだけでもめちゃくちゃ分類される。
  • カニめちゃ高い...!!
  • 作る側も、使う側も実際に使う状況になるまでわからないことは多い

次やりたいこと

  • サーバーサイド実装の力もさらに付けていきたい。
  • Flutter for Web気になる。

JPHACKS2020参加レポート~Miro大活用とフラクタルスプリントへの挑戦~

はじめに

こちらは

の記事です。(片方遅刻してしました...ごめんなさい🙇‍♂️)

今回は10月末から11月末にかけて行われたJPHACKS2020の参加レポートになります。

昨年に引き続き、2年目の参加です!!昨年の参加レポートはこちら💁‍♂️

kugi-masa.hatenablog.com

昨年はCammelリーダーのtyanioと私の2人で出場していました。 今年度は私にとって学生最後の年、Cammelみんなでハッカソンに出たいという私の強い想いもあり、チーム7人で出場することになりました。

(完全に余談ですが、最近Cammelのページが公開されました🎉)

今年はオンライン

今年のJPHACKS(ジャパンハックス👈ジェーピーじゃないですよ!!ここ重要)はCOVID-19の影響もあり、フルオンライン開催でした。

今年に入ってオンラインのハッカソンに参加したり、主催したり(笑)オンラインハッカソンは初めてではありませんでしたが、参加者およそ400名のここまで大規模な学生ハッカソンをオンラインで実現できるのは、やはりJPHACKSだからこそだなと感じました。

オンライン開催とのこともあり、昨年とは異なり、Hacking Sprint(実際にプロダクトを開発する期間)は2Dayではなく1Weekに。そして、Hacking Spritの前には運営のみなさんによるLearning Sprintという環境構築やチーム開発などの学習イベントが開催されました。

アイディアソンワーク

私たちCammelはアイディアソンワークに参加し、Miroを使ってアイディアの分散・発散・収束について学びました。

f:id:kugi_masa:20201217000630p:plain
「ハッカソン」を中心にマンダラートを作成しました。（草が生えたw）

また、出たキーワードから9つのキーワード(転用、応用、変更、拡大、縮小、代用、置換、逆転、結合)を元にさらに発散させる「オズボーンのチェックリスト」はとても学びになりました。全く想像していなかったアイディアが出るので、既に出たキーワードやアイディアからさらに発展させる指標としてとても良いなと感じました。

オズボーンのチェックリストとは？｜経営キーワード集 | オンライン創業スクール・Zoomセミナーの講師をお探しならジャイロ総合コンサルティング

その後は、アイディアを収束へ。出たアイディアを元にイメージ図やターゲットユーザ(ペルソナ)について考えていきました。

f:id:kugi_masa:20201217001945p:plain
なんだこれは...

準備期間としてこのようなワークイベントを開いていただけてとてもありがたかったです。日程の関係で参加はできませんでしたが、他のワークにも参加してみたかったです。

1Weekの開発

Best Team Collaboration Award

受賞項目がたくさんあるJPHACKSですが、 今年からBest Team Collaboration Awardという賞が追加されました。こちらの賞は「チーム開発実践入門」という書籍を元に採点項目が設けられ、それらの合計点数の最高得点を獲得したチームに送られる賞でした。

アジャイルの理念を取り入れて開発すること目標として掲げ、これまで開発を行ってきたCammel。 そして、そこでスクラムマスターのような立ち位置でこれまでアジャイルをチームに共有してきた私としては非常に獲得したい賞でした。

採点項目として以下のようなものがありました。(以下の項目は一部)

  • [バージョン管理] チームメンバーの複数人がリポジトリに登録された(チームメンバー)
  • [バージョン管理] 一度でもチームの誰かがリポジトリのmain(master含む)にソースコードをコミットした
  • [チケット管理] Issueが登録されている
  • [CI/CD] SlackにGitHubやCIのログ等をインテグレーションしている

毎日その日までのチームの点数がslackのリーダーボードチャンネルに流れるようになっていて、コンテスト感がありとてもワクワクしました。

f:id:kugi_masa:20201217004340p:plain
slackのリーダーボードチャンネル

各チームのプロジェクトの情報は全てGitHub上に公開されています。 その日の上位のチームが何をしているかの調査をするためにも、上位チームのリポジトリ情報をチームのチャンネルに流すなどしていました笑

f:id:kugi_masa:20201217005057p:plain
前回からの変動に+をつけました

結果的には4位と受賞は逃してしまいましたが、今回のBest Team Collaboration Awardを期に挑戦してみた内容(CI/CDなど)もあったのでチャレンジできてよかったと思います。

Miroを活用してデザインのモックを作って共有したり、うさぎ組のkyonさんのフラクタルスプリントを参考に開発に取り入れてみたりしていたのでそういった点もアピールして評価してもらいたかったなとも思いました。 (自動採点で無くなったら運営のみなさんが鬼大変になってしまうとは思いますが...笑)

kyon-mm.hatenablog.com

Miroを活用

今年は各チームごとにMiroのボードを用意していただきました。 普段の開発でもMiroは使っているのでみんな使い方には慣れていましたが、1週間の開発でフラクタルスプリントにも挑戦してみたので、より使いやすいように以下のような決まりを作りました。

  • 付箋のサイズは基本的に「Mサイズ」!!!
  • 背景パネルは必ず「ロック」
  • 付箋の「色」に意味合いを持たせる
  • 「エリア」を分けて活用

f:id:kugi_masa:20201217011901p:plain
付箋のサイズはM!!!

Miroの付箋のサイズは任意に変更できますが、明示的にS・M・Lと固定することもできます。Miroは割と広めにスペースを取れるので、必ずMがいいというわけではありませんが、サイズに基準を作っておくことに意味があると感じました。これはボードを見ている時の倍率(右下の%)を自然と合わせるためです。Miroは簡単にマウスのスクロールなどでズームイン・ズームアウトができてしまいます。他のメンバーのカーソル位置は表示されているのでどの位置で作業をしているかわかっても、付箋のサイズがバラバラであれば、同じ視点から見たボードが共有しづらくなります。

f:id:kugi_masa:20201217012551p:plain
背景パネルはロック

普段Miroを使うときは領域を分けるために「背景パネル」を置いています。ここで重要なのが錠前マークでロック🔒することです。ロックをしておかないと付箋などの移動の際に背景が動いてしまってフラストレーションが溜まってしまいます😤。

f:id:kugi_masa:20201217012849p:plain
自分の色はコレダァァァァ!!!

１週間同じボードを使うため、毎回「コレ誰の？」とらないように自分の使う色を予め決めて付箋を使うことにしました。

f:id:kugi_masa:20201217015350p:plain
エリアを分けて活用!!

また、今回は進捗管理やモックの共有、バックログ管理などもMiroで統一して行ったので作業場所をわかりやすいように分けました。

フラクタルスプリントへの挑戦

基本的に開発はDiscordで通話をしながらGoLiveでのモブプロやペヤプロ、デザインチームはMiroを使ってモック作成を行いました。

f:id:kugi_masa:20201217020215p:plain
1Dayボード

今回のハッカソンでは、1WeekSprint >> 1DaySprint >> 1HourSprint のフラクタルスプリントで取り組んでみました。

1HourSprint

まずは最小単位の1HourSprintでは、1時間ごとにできそうだと見積もったタスクをTODOに列挙し、1時間終わったら振り返りします。ハッカソン中は学業との両立もあるのでこの1HourSprintは作業できる人ができる時間にバックログからタスクをとってやっていきます。

実はハッカソンの序盤が学会と丸かぶりしてしまい、最初の数日は開発できませんでした。 その分空いた時間でMiroを覗いたり、夜の進捗共有には参加して困り事を洗い出すなど、本当にスクラムマスターのような立ち振る舞いをしていました。(意外と見るだけならスマホ版のMiroも良さげでした👀)

今回1HourSprintに挑戦したいと提案してくれたメンバーからは以下のような前向きな意見がでています。

  • 1時間で強制的に手を止めるので気持ち新たに次の1時間に挑める
  • 途中で参加した人も何をやっていたかがすぐにわかる

1DaySprint

１日の区切りとしてだいたい18:00~18:30の時間でDailyScrum(朝会ならぬ夜会)を開きました。DailyScrumでは以下のようなことを行いました。

  • 進捗共有
  • 困り事、心配事の解消(ここでモヤっと🦠をスッキリに✨)
  • バックログリファインメント
  • 次の1DaySprintですることの確認

DailyScrum後にそのまま作業することが多かったですが、一応1Dayの区切りはDailyScrumとして、DailyScrum以降は次の日の1Dayボードに移動して作業しました。

1WeekSprint

この1DaySprintをHackingSprintの七日間繰り返すことで1WeekSprintとしました。

作ったプロダクト name_it

ここまではチームとしての1週間の取り組みについてでしたが、ここからは作ったプロダクトについてお話ししたいと思います。

まずは、デモ動画をご覧ください。

www.youtube.com

name-it-38fb8.web.app

name_itは自分が悩んでいる変数名やメソッド名を投稿し、 みんながアンケートに投票や更なる選択肢の追加などを行ってよりよいネーミングを共有していくエンジニア支援サイトです。

元々は気軽にコードレビューをもらえるサイトか感情日記という自分のその日の感情を色として日記に記録できるアプリの2つでアイディアがわれていました。そこで、挙げられていた3つの評価基準([問題着眼点・着想点]、[実行・実現可能性]、[完成度・動作性])に着目してさらに深堀をしていく中で、変数命名を投票で決めるというアイディアが生まれました。

「感情どこ行った...??」という声が聞こえて来そうですが、 感情日記はハッカソンで作るのではなく、時間をかけて普段の開発で作りたいねという話もありコードレビュー寄りのアイディアになったという裏話もあります。

f:id:kugi_masa:20201217022956p:plain
投票で最終的に変数命名投票サイトに

Twitterで実際に変数の命名などで時間をかける人がいるかなども予め調査をしました。

結果としては、予選落ちでFinalistAwardへは進出できませんでしたが、動くものを１週間で作りきれたこと、フラクタルスプリントという新しい取り組みに挑戦できたことは私たちチームとしてとても価値のあることだったと思います。

フィードバックでもいただいたように、「回答を投票する側のメリット」や「命名に悩む人はすぐに回答が欲しいのに待たなくてはならない」といったユーザの視点、実際使ってもらう人の視点を踏まえた機能を早い段階で取り入れるべきだったと思います。

f:id:kugi_masa:20201217024517p:plain
1週間のバックログ

まとめ

これまで2年間Cammelでアジャイルの手法を取り入れ開発を行ってきて、スプリントをまわす習慣やモブプロ、振り返りなどは身についてきたと今回のハッカソンで実感できました。そしてハッカソンを通して、私たちのチームの弱点は私たちのプロダクトを使うユーザがプロダクトをどのように、なぜ使うのかという点を踏まえて開発する力が弱いことだと感じました。開発が進んで行くにつれ、私たちのプロダクトのペルソナが「プロダクトを求めるユーザ」ではなく「プロダクトが求める、プロダクトありきのユーザ」になってしまっていたと感じます。(今回の例だと、私たちのユーザは「回答が来るまで辛抱強く待てる人」と思ってしまっていた)

これは特に最初のペルソナ定義が曖昧のまま開発が進んでしまうと、尚更陥りやすいことだとも思いました。 時間のないハッカソンの場合は最初に時間をかけて物事を決めたり、途中で手を止めてプロダクトの根幹の部分を見つめ直して手戻りするということはなかなかやりにくいと思います。しかし、使ってもらうものをユーザに届けるためにはプロダクトのペルソナを考えて開発することは非常に大切です。早い段階で一度手を止めてプロダクトについて見つめ直す時間(ドッグフーディング🐶)やユーザについて考える時間をとることがハッカソンでは重要になってくると改めて学ぶことができました。

また、今回挑戦したMiroの活用法やフラクタルスプリントのエッセンスは今の開発にも活かせていると思います。

Finalistに2連続で進出できなかったことは悔しいですが、結果が全てではありません。 今回メンバーには少々無理を言って全員参加に踏み切りましたが、全員参加できてよかったと言ってくれて嬉しかったです。 学生としてのCammel最後の年度に(先日引退はないよと言われました笑)本当にいい思い出ができたと思います。 メンバーには感謝です。

そして運営のみなさんも本当にありがとうございました!!! (オフ会わいわい楽しかったです笑)

私は今年度で修了しますが、残り５人は来年度まで学生です。 来年もJPHACKSに出場するかはわかりませんが、私としては出て欲しいですね笑

やったこと

  • チーム全員でハッカソンに参加してname_itといい思い出を作った

わかったこと

  • チームの弱点が見つかった

次やりたいこと

  • チームの弱点をチームで補っていく

unity1weekにチームで参戦するために2monthかけて準備した話

はじめに

こちらの記事は Unityゲーム開発者ギルド Advent Calendar 2020の11日目です。

(本日アドベントカレンダー２回目笑)

私はUnityゲーム開発者ギルド(通称: UGDG)に２ヶ月ほど前に参加しました。

ギルドに参加したことで今まで以上にUnityに触れる機会が多くなり、メンバーの方から刺激もたくさんいただいています。また、気軽に話しかけてくださる方が多く、コメントにスタンプで反応してくださったり、とても暖かいコミュニティだと感じています。また一緒にゲームしたりDiscordで雑談したりすることも増え、いいことづくしです！

UGDGのアドカレなので、この記事では「unity1weekにチームで参戦するために2monthかけて準備した話」について書きたいと思います。

チームaojilu

f:id:kugi_masa:20201210211427p:plain
チームaojilu

チームaojiluは同じ大学のaojiluくん、SilCilさんと私の3人からなるチームです。

aojiluくんのツイートがきっかけで集まりました。

f:id:kugi_masa:20201210202359p:plain
3人集まるきっかけとなったaojiluくんのツイート

aojiluくんとSilCilさんはGSD(大学のゲーム制作同好会)に所属していて、aojiluくんは私がメンターをしていたときのenPiT2019で一緒、SilCilさんはu1wでTwitterのFFという関係性でした。

初日はZoomで3人で顔合わせをしました。 Zoom無料プランの40分制限があったので、40×4回笑笑。「第4回ミーティングよろしくお願いします〜」と回を重ねるごとに初日で3人の心理的距離は縮まりました。

それ以降は主に以下のツールを使ってミーティングをしていきました。

  • Discord: 通話用
  • Miro: アイディアボックス(オンラインホワイトボード)
  • UDGDのScrapbox: 議事録とギルドへの知見共有
  • GitHub: コード共有、タスク管理
  • Slack: チームチャンネルでわいわい🙌

私たちは3人ともプログラマなので、ゲーム制作におけるプログラマ分業という修羅の道への旅が始まろうとしていました...。

unity1monthやってみる

一緒にチームで開発したことのない3人でいきなりu1w挑戦となるときっと大変だ!!と思ったので、まずは1weekを1monthにのばして3人でアイディア出しからゲームを作るところまでやってみることにしました。お題をTwitterで募集したところ、「重力」というお題をいただきました。 ひとまず次のミーティングまでに各々考えて、アイディアを持ち寄ることに...

f:id:kugi_masa:20201210203245p:plain
お題をTwitterで募集

aojiluくんとSilCilさんはこれまでGitHubあまり使ってこなかったとのことだったので、Miro & GitHubハンズオンを行いました。 その後、いただいたお題「重力」を元に持ち寄ったアイディアを深堀していく形で作るゲームの企画を固めていきました。

f:id:kugi_masa:20201210202720p:plain
アイディア出し

画像からもわかるようにMiroでわいわい絵や図を書いたりして盛り上がりました。 しかし、企画を決めるにあたって何を軸に決めたらいいかわからず、アイディアが分散してしまいかなり時間がかかってしまいました。 (アイディア出し自体はわいわいできてとてもよかったと思っています)

最終的に、「迷わずに答えられる面白さ」がはっきりしている企画、3人が話し合ってこのゲームの「面白さ」はここだよね、と言えるものを軸に考えることにしました。

f:id:kugi_masa:20201210204054p:plain
迷わずに答えられる面白さ

そうして決まったのが

「アイテムを集めながら星から星を飛んで移動しゴールの星を目指すゲーム」

Gravity Planet

です。

github.com

結論から先にお話しすると、このGravity Planetは最終的にゲームにはなりましたが、unityroomにリリースするまでには到達できませんでした。

ここでは最終的に出来上がったものと、取り組み方や反省点などを、unity1monthが終わったタイミングに戻った気持ちでKPT(KEEP・PROBLEM・TRY)で振り返りたいと思います。 (現在の振り返りではありません)

KEEP

  • モブプロベースで進めることで知見の共有ができた(Cinemachineはじめて使ってみた!!)
  • ミーティング中に疑問点や進め方にモヤッと感じたタイミングで疑問点の解消、モヤッとをすっきりにもっていく合意タイムが取れてよかった(aojiluくんモヤッと報告ナイスでした👍)
  • CloudBuildでビルドコストをなくせた
  • メンバー間の心理的距離が縮まった

PROBLEM

  • コーディング規約が曖昧で設計、依存関係が大変なことに...
  • 企画決めに決まった流れが欲しい
  • 今の感じだと1monthでも厳しかったので、1weekもつらいことになりそう...
  • Issueでタスク管理はコストの割に旨味がない(u1wだと特に)

TRY

  • 設計の指標がほしい(TRYか...??🤔)
  • Gravity Planetの設計を見直す会をしたい
  • 企画決めの流れを作りたい
  • 1週間をという期間を踏まえてもう一度企画からやってみたい

SilCilSystem導入

さて、Gravity Planetの振り返りが終わりTRYでも出た「設計を見直す会」をやりました。

SilCilさんが用意したクラス図をもとにSilCil'sオススメ設計を教えていただきました。

私たち3人の中では明らかにSilCilさんが設計マスターです。

f:id:kugi_masa:20201210213558j:plain
設計の話をしよう

それから何回かミーティングを重ね、SilCilさん主導で設計の指標となるテンプレートリポジトリ(Unityプロジェクトのテンプレート)SilCilSystemを作ることになりました。

なんとSilCilさんお手製のドキュメントもあります!!!!

u1w以降、落ち着いたタイミングでSilCilさんの方からもSilCilSystemの振り返りブログを書くとお聞きしているので詳しい内容はこちらでは割愛します。 (というより、私は説明しきる自信がありません...😂)

aojiluくんと私はというと、このテンプレートリポジトリを使って実際にゲームを作ってみて使い方に慣れようとしています。

実は別のイベント(LT駆動開発。発表はMomijiLT#3にて。12/13(日)18:30〜です。YouTubeLiveにて配信します)で作って昨日しれっとunityroomにアップしたこちらのゲームもこのSilCilSystemをテンプレートにして作ったものです✨

チームaojiluにおける理想的な一週間の流れ

そしてSilCilSystem制作と同時並行で残りのTRYである「企画決めの流れづくり」と「一週間を踏まえてu1wの素振り」に取り組んでいます。

まずは理想の1weekの流れについて話しました。

f:id:kugi_masa:20201210220452j:plain
チームaojiluにおける理想的なu1w

unity1monthでは、CloudBuildを使うことで、main(master)ブランチにマージされたタイミングでビルドが走りDiscordのCloudBuild用のチャンネルにビルドがアップされるようしたので、u1w本番でも同じようにするのが望ましいです。

f:id:kugi_masa:20201210221530j:plain
CloudBuildはいいぞぉ

しかし、それぞれ一週間ずっとつきっきりというわけにもいきません。 一週間の流れの画像にもあるように、チームaojiluでは毎日夜集まり以下の流れでu1wに取り組むことにしました。

  1. お題が出てから初日のミーティングまでにお互いアイディアを持ち寄る
  2. 初日のミーティングで企画を決め切りやるべきタスクを洗い出す
  3. 初日以降はそのタイミングでの最新のビルドを遊んでどうゲームをカイゼンしていくかを決める
  4. タスクを洗い出して次のミーティングまでコミット(コミット内容は同期が取れるようにslackで適宜共有)
  5. 最終日まで3. 4. を繰り返す

こう見てみるとなんかu1wやっていけそうな気がしますね!!!

とはなりませんよね笑

KPTのPROBLEMでも出たようにunity1monthのアイディア出しでは決まった流れがなく、話が分散し時間がかかってしまいました。そこで私たち3人は理想の企画決めの流れを探るべく、ジャングルの奥へと向かいました。

企画決めの流れ

まず前回お題の「重力」をもとにそれぞれ事前にアイディア出しをし出たアイディアを共有するということをやりましたが、フォーマットがバラバラでアイディアの説明も人によって時間をとったり取らなかったりとまちまちでした。

一週間しかないu1wにおける共同開発(チーム開発)では意思決定の早さが非常に大切になります。そこで私たちは、EMS フレームワークを持ち寄ってそれを共有することにしました。 (EMSフレームワークのついては以下を参照) gamebiz.jp

そして、素振りの試行錯誤を２回繰り返し、最終的にこれならいけそう!!という流れにたどり着きました。(ジャングルの奥に宝はあった！)

f:id:kugi_masa:20201210230515j:plain
割とうまくいったアイデア出しの流れ

付箋の左の時間は実際に素振りをやってみて妥当だと見積もった時間です。

f:id:kugi_masa:20201210230544j:plain
お題「打つ」でEMSフォーマットでアイディアを書いていき、共有、選定を行った図

EMSフォーマットを導入したことでアイディアを発散と収束させやすくなりました。 またオズボーンのチェックリストにならって事前に用意したEMSフォーマットからミーティングの時間で新たなEMSフォーマットを作る時間も用意しました!! jairo.co.jp

f:id:kugi_masa:20201210230524j:plain
１回目の素振り(お題は「はずす」)の振り返りをした図
この章の頭でも書いたように実は素振りは２回行いました。もともと初めに想定していた流れのもと進めていましたが、意外と早く決まり過ぎてしまいました。早く決まったけど、もやもやが残る状態だったので一度振り返りを入れ、今の流れにカイゼンされました。 (ナイスモヤッとストップaojiluくん)

このようにしてできたTETOR<I\E>VERのペライチ企画書が以下の画像になります。

f:id:kugi_masa:20201210232618p:plain
ペライチ企画書

パッとみるとあまりゲームシステムが伝わりづらい企画書ではあります。しかし、この企画書はあくまで3人の共通認識を揃えるためのものとしました。なので企画書の完成度よりは一緒に話しながらすり合わせをして企画書を作る時間に重きをおいています。

現在はu1wまでの残りの時間でこの企画書をもとに一週間の一部を切り取って(3. 4. の部分)SilCilSystemの運用練習も兼ねてTETOR<I\E>VERを制作しています。

kugiが思うこと

こうして2ヵ月を振り返ってみるといろんなカイゼンを行って来たなぁと感じます。

個人的によかったと思うのはaojiluくんがモヤッとしたときにすぐに言ってくれることです。

チーム開発の経験がある私が主にミーティングのファシリをしていたのですが、進め方に対する疑問点やモヤッとしたところをすぐに投げてくれるので、一旦手を止め(ここではミーティングの流れを止め？)3人で合意がとれるようになっていると思います。

また、SilCilさんからの学びも凄まじいです。3人のなかでUnity経験も知識も一番あるのでシステム面で引っ張っていただける分、私はチームビルディングに集中することができたと思います。

また、u1wのチーム開発で今までのチーム開発とは違うなと感じたのは、ユーザーストーリーベース([例]駒を盤面に置くことができる)でIssue(タスク)を立ててしまうとどこまで実装すればいいかわかりづらくなるという点です。このようなタスクだと「盤面はどこで用意すればいいの？」や「駒は何を置くの？Sphere？Cube？それとも...」といった疑問が生まれます。

Issue(タスク内容)を見ただけでチームみんながタスク内容を理解できるようにするにはタスクを具体的に書き出す必要があります。長期開発だと問題はなさそうですが、u1wではやはりスピードが大切。時間をかけてIssueを書いていてはゲームは完成しません。そのため、チームaojiluではIssueは雑めで、着手する人にある程度はお任せという方針でいこうと考えています。また、ユーザーストーリーベースよりはロジックベースのIssueが良さそうです。

まとめ

さて、u1wまであと一週間弱。 こうやって2monthかけて準備したことが全てうまくいくとは思いません。 むしろ、うまくいかないことの方が多いかも知れません。 良いチームが絶対良いゲーム(プロダクト)を作ることができるわけではないと思います。

ただ、この2month行ってきたカイゼンは決して無意味だとも思いません。カイゼンを重ねることで少しでも良いゲームが作れる可能性が増えるなら私は最後の最後までカイゼンを続けたいと思います。

と大きなことを言ってしまいましたが、 ゲームを評価するのはプレイをするみなさんです！

このチームaojiluからどんなゲームが生まれるか...!!unity1weekでお見逃しなく!!!

(今回は長い振り返りなのでYWTはお休み)