エピソード

  • 破壊的スピード開発 #7|通知UIで現れた判断の本質
    2025/12/12
    今回の放送では、先日行った開発ライブで実装した「通知メッセージUI」を題材に、 その裏側にあった “スピード開発における判断の本質” を深掘りしていきます。 通知UIは一見シンプルに見えるパーツですが、 プレイヤー体験を大きく左右し、他のUIロジック全体にも影響を与える重要な仕組みです。 そして通知を実装する際には、最初に必ず決めておくべきポイントが2つあります。 通知表示中に他のUIを触れるようにするのか? 通知が連続で実行されたとき、どう扱うのか? この2つを曖昧にしたまま進めると、後からUIロジック全体を巻き戻す必要が出てきます。 今回の放送では、実際のライブ制作で下した判断をもとに、 なぜ「通知中でも他UIを触れる」方針にしたのか なぜ「連続通知はキュー方式」を選んだのか なぜ「大量通知問題」は“あえて今はやらない” と判断したのか こうした判断の背景をわかりやすく解説していきます。 また、通知UIを実装する中で改めて感じた アニメーションは最初から入れておくべき理由 序盤で“体験の違和感”を潰すことが後半の開発速度を大きく上げること 方向のズレを序盤で直さないと積み木が崩れるように後半で破綻してしまう話 といった「高速開発に欠かせない思考」についても触れています。 破壊的スピード開発の本質は、 “未来の遅さを、今の判断で潰す” ということ。 通知UIのような小さな機能でも、その判断プロセスには高速開発のエッセンスが詰まっています。 通知UIの実装に興味がある方はもちろん、 UI設計全般や、日々の判断スピードを上げたい人にも役立つ内容になっています。 ぜひ最後まで聞いてみてください。 次回はサウンド周りの基礎実装に入る予定です。音の仕組みは体験の気持ちよさに直結する重要パートなので、そちらもお楽しみに。 ↓↓オオバのnote https://note.com/ohbashunsuke --- stand.fmでは、この放送にいいね・コメント・レター送信ができます。 https://stand.fm/channels/66588cbb316143a771aa74c5
    続きを読む 一部表示
    5 分
  • 破壊的スピード開発 #6|Addressablesの判断軸をアップデート
    2025/12/12
    ## 放送タイトル 破壊的スピード開発 #6|Addressablesの判断軸をアップデート ## 放送説明 Unity のオフラインイベント「U/DAY TOKYO 2025」に参加してきました。 今回の放送では、その中でも特に僕の思想「破壊的スピード開発」に直結した学びをお話しします。 テーマは Addressables。 といっても、技術的な使い方やチュートリアルの話ではありません。 今回のイベントで強く感じたのは、 Addressables とは “判断のフレームワーク” である ということでした。 現場で実際に起きている課題。 Unity 公式ロードマップの意図。 複数タイトルの運用から見えた成功例・失敗例。 そしてそれらが「高速開発」へどう影響するのか。 ネットの記事では絶対出てこない“実戦”の視点が多く、 僕自身の判断軸が大きくアップデートされた内容でした。 今回の放送で話していること なぜ今 Addressables を選ぶ判断は「正しい」と言えるのか 昔と今で変わった「アプリ容量とユーザー体験」の常識 Addressables が高速開発の思想と完全に噛み合う理由 パッキング/グルーピング設計がなぜ速度を生むのか 「正解はないが、間違いはある」設計判断の本質 ツールの話ではなく“迷いを削る仕組み”の話 特に印象的だったのは、 「どのアセットをどこでロードするか」ではなく、 “何を基準に判断すべきか” を言語化しておくべき という視点。 これはまさに破壊的スピード開発の中心にある思想で、 今日の判断が明日のスピードを決める、という話そのものです。 Addressables を技術ではなく “思想” として扱う 今回の内容は、技術Tipsではありません。 もっと根本的な、「高速で作る人が見ている景色」の話です。 どこまで内包するか。 どこから分離するか。 ロード順をどうデザインするか。 更新頻度をどこで最適化するか。 これらがすべて“開発スピード”に跳ね返ってくる。 イベントを通して、 Addressables はただの仕組みではなく 高速開発を実現するための判断フレームワーク であると再認識しました。 補足:具体的な内容は note に詳しくまとめています 今回のラジオでは抽象度高めの内容に絞っています。 パッキング設計、バージョンの使い分け、 実際のトラブル例や個別質問の回答などの“実務寄り”の情報は note のレポートで詳しく解説しています。 あなたの開発速度を上げるヒントになれば嬉しいです。 ぜひ本編をお楽しみください。 ▼ 今日の深掘りnote https://note.com/ohbashunsuke/n/nb6cf708f1ccf --- stand.fmでは、この放送にいいね・コメント・レター送信ができます。 https://stand.fm/channels/66588cbb316143a771aa74c5
    続きを読む 一部表示
    8 分
  • 破壊的スピード開発 #5|Unity起動前の無駄が速さを奪う理由
    2025/12/10
    今回の破壊的スピード開発ラジオでは、 「Unity を開く前に発生する “たった数十秒の無駄” が、なぜ未来の開発スピードを奪うのか」 というテーマでお話ししています。 Unity を立ち上げるとき、こんな経験ありませんか? ・Hub の起動が遅い ・どのプロジェクトで作業するか毎回確認 ・ブランチが合っているか気になる ・開始する前にすでに疲れている こうした “開始前の小さな迷い” は、 実は開発の後半に大きなダメージとして返ってきます。 作業とは関係のない待ち時間や確認作業が続くと、 脳のエネルギーが奪われ、集中力の寿命が短くなり、 開発のスタートダッシュが遅れてしまう。 破壊的スピード開発の視点では、 「作業中の迷い」より 「作業を始める前の迷い」 のほうがはるかにパフォーマンスに影響すると考えます。 速い人は例外なく、 作業前の流れが “異常にスムーズ” です。 椅子に座る ↓ すぐ作業に入れる ↓ 確認作業ゼロで着火できる この “着火スピード” が、 その日の集中力の質と持続力を大きく左右します。 今回の放送では、 ・開始前の迷いがなぜ危険なのか ・なぜ毎日の数十秒が積み重なると大きな差になるのか ・速い人が“前工程”にこだわる理由 ・環境整備が脳と集中力の寿命を伸ばす話 といった、ツールよりも本質的な部分を深掘りしています。 具体的な環境改善の方法や、 Unity の起動プロセスをどう最適化するかといった実践部分は note にて詳しく解説しているので、 興味のある方はぜひあわせてチェックしてみてください。 未来の遅さを、今の工夫で潰す。 破壊的スピード開発の核心に触れる回です。 --- stand.fmでは、この放送にいいね・コメント・レター送信ができます。 https://stand.fm/channels/66588cbb316143a771aa74c5
    続きを読む 一部表示
    5 分
  • 破壊的スピード開発 #4|時間設計が迷いを生む理由
    2025/12/09
    今回の破壊的スピード開発ラジオでは、 「時間の扱いが曖昧だと、なぜ開発の後半が一気に苦しくなるのか」 というテーマでお話ししています。 ゲームでもアプリでも、開発が進むほど“時間”という概念は じわじわと複雑さを増していきます。 最初はシンプルに動いていたのに、 機能が増えるたびに矛盾が出てきたり、 スロー演出やポーズ処理を入れた瞬間に UIやエフェクトが意図しない動きを始めたりする。 こうした現象の裏側には、 「時間をどう分離し、どう扱うか」 という設計の曖昧さがあります。 実は、時間の扱いはゲームの根本構造に近い部分で、 キャラの動き、UIアニメーション、エフェクト、物理挙動、 ありとあらゆる処理が時間を前提にしています。 だからこそ、時間の取り扱いを誤ると 後半になればなるほどバグ調査に時間がかかり、 調整ではなく“作り直し”になることも珍しくありません。 今回のラジオでは、 ・時間の扱いで迷いが生まれるメカニズム ・なぜ後半で調査コストが跳ね上がるのか ・時間のグルーピングという考え方 ・未来の自分を助ける「時間設計」という視点 ・若手や現場で起きがちな落とし穴 などを、具体的なコードや知識には触れず、 あくまで「速さを作る思想」として掘り下げています。 破壊的スピード開発において最も大事なのは、 “迷う場所をなくすこと”です。 時間の扱いを丁寧に設計しておくだけで、 後半の開発スピードは驚くほど変わります。 実装テクニックや時間種類の詳細な使い分けについては、 noteの深掘り記事でより具体的に解説していますので、 関心のある方はそちらもチェックしてみてください。 ▼ 今日の深掘りnote https://note.com/ohbashunsuke/n/nd513c543464d 今回のラジオが、あなたの開発スピードを上げる ひとつのヒントになれば嬉しいです。 --- stand.fmでは、この放送にいいね・コメント・レター送信ができます。 https://stand.fm/channels/66588cbb316143a771aa74c5
    続きを読む 一部表示
    7 分
  • 破壊的スピード開発 #3|なぜログで開発が遅くなるのか
    2025/12/08
    今回のテーマは「ログが開発スピードを奪う理由」です。 ゲーム開発でもアプリ開発でも、ログは欠かせない存在です。 ただ、気づかないうちに“スピードを落とす原因”にもなっていることがあります。 ログが増え続けると、僕らの思考は「判断モード」から「探索モード」に切り替わります。 本来必要なのは前に進む判断なのに、膨大なログの中から正しい情報を探すだけで 集中力が削られ、判断が遅れ、ミスが増えていく。 これは誰でも経験があるのではないでしょうか。 僕自身、これまでの現場経験の中で、 ログが整っている環境と整っていない環境では 後半の開発スピードがまったく違うことを痛感してきました。 ログは「未来の自分を助ける道具」です。 未来の迷いを今の自分が先回りして潰しておく。 破壊的スピード開発の核心は、この“未来の遅さを減らす姿勢”にあります。 今回の放送では、 なぜログが迷いを生み、思考の体力を奪い、 開発スピードに直結するのかという背景を丁寧にお話ししています。 具体的な実装方法やログ設計のテクニックは noteで深掘り解説していますので、 気になる方はあわせてチェックしてみてください。 あなたの開発スピードを上げるきっかけになれば嬉しいです。 ▼ 今日の深掘りnote https://note.com/ohbashunsuke/n/n33808e9dcefb ラジオでは語りきれない“ログ設計と具体テクニック”はこちらで詳しく解説しています。 --- stand.fmでは、この放送にいいね・コメント・レター送信ができます。 https://stand.fm/channels/66588cbb316143a771aa74c5
    続きを読む 一部表示
    4 分
  • 破壊的スピード開発 #2|画像プレビューを自動化する理由
    2025/12/07
    【今回のテーマ】画像プレビューを自動化する理由(ShowAssetPreview) どうも、オオバです。 この番組「破壊的スピード開発ラジオ」では、ゲーム開発歴12年・エンジニア歴15年の僕が、 「もっと速く作れるようになりたいクリエイター・エンジニア」のために、 開発速度を上げるための考え方や習慣、仕組み作りについてお話ししています。 ■今回の内容:ShowAssetPreview は“ただの便利機能ではない” Unity を使っている人なら誰でも一度は感じたことがあると思います。 「このテクスチャ、どれがどの画像だっけ?」 Inspector に画像をセットしたのに中身が見えない。 似た名前のアセットが並ぶと間違える。 UI やアニメーションの素材を扱うときに、意外とこの“1秒の迷い”が積み重なっていく。 実はこれ、すべて 開発のスピードを落とす原因です。 今回取り上げる NaughtyAttributes の ShowAssetPreview は、 ただ画像をプレビュー表示してくれるだけの小さな機能に見えますが、 「迷いを減らす仕組み」そのものです。 速く作るための本質は、派手なテクニックではなく、 未来の自分が迷いそうな場所を先に潰しておくこと。 ShowAssetPreview はまさにこの思想を体現している機能です。 ■“迷い”は開発速度と精神力を静かに奪っていく 開発が遅くなる瞬間の多くは、 手が止まっている時です。 どれが正しい画像か確認する 間違えて差し替えて、また直す ファイル名を見比べて判断する 思い出すために脳のリソースを使う これらはすべて「迷い」によって発生する無駄。 迷いはただの時間ロスではなく、 判断疲れや集中力の低下を引き起こし、 プロジェクト全体を重くします。 だからこそ、速い開発者は地味でアナログな習慣を持っています。 「未来の自分が迷わないように、環境を先に整えておく」 ShowAssetPreview を導入するのは、 まさにこの習慣の象徴なんです。 ■仕組みを整えるだけで、プロジェクト全体が軽くなる 僕が過去にチーム開発をしていた時、 UI アイコンの差し替えで毎回誰かが 1〜2 個ミスするのが当たり前になっていました。 技術不足でも、経験不足でもない。 単純に **「見えないことによる迷い」**が原因でした。 今思えば、ShowAssetPreview のような仕組みがあれば、 その問題はかなり減らせていたはずです。 速さは才能ではありません。 迷いを減らす工夫の積み重ねで作られるものです。 こうした「未来への投資」の積み重ねが、 破壊的スピード開発の本質だと思っています。 ■まとめ ShowAssetPreview は単なる小技ではない “迷い”を減らすことで開発速度は劇的に改善する 速い人は未来の迷いを潰す仕組みを作っている 仕組みづくりは開発チーム全体にも良い影響を与える たった 5 秒の導入で、 毎日の開発スピードが確実に変わります。 「速く作れる人」ではなく、 「速さを作れる人」になる。 そのための第一歩として、ぜひ ShowAssetPreview を試してみてください。 ではまた次回。 --- stand.fmでは、この放送にいいね・コメント・レター送信ができます。 https://stand.fm/channels/66588cbb316143a771aa74c5
    続きを読む 一部表示
    6 分
  • 破壊的スピード開発 #1|破壊的スピード開発の基本思想
    2025/12/07
    制作や開発がなかなか前に進まない。 考えてばかりで手が止まってしまう。 作り始めても、迷いが積み重なってスピードが出ない——。 そんな経験を持つクリエイターやエンジニアに向けて、 この番組「破壊的スピード開発ラジオ」は生まれました。 僕はオオバ。 エンジニア歴15年、ゲーム開発歴12年。 数多くのプロジェクトで、スピードが武器になる場面も、 逆にスピードがないことで破綻してしまう瞬間も見てきました。 その中で確信したことがあります。 開発の速さは“才能”ではなく、 「考え方」と「環境整備」で劇的に変わる。 どれだけ優れた技術やツールを持っていても、 迷いが多ければ手は止まり、 そして手が止まった瞬間にスピードは消える。 逆に、特別な技術がなくても 迷いを減らし、壊しながら進める環境を作れれば 誰でも“速く作り続けられる開発者”になれる。 この番組で扱うテーマは、 単なる効率化テクニックではありません。 「どうすれば迷わず作れるのか?」 「なぜ人は制作で手が止まるのか?」 「速い人の判断基準はどこにあるのか?」 「壊しながら前へ進むための環境とは何か?」 こういった“根本的な部分”にフォーカスしています。 多くの人が、開発の遅さを 「技術不足」や「経験不足」のせいにしてしまいますが、 本当の原因はもっと別のところにあります。 たとえば—— ・判断材料が散らかっている ・何から作るかが決まらない ・壊した時のリスクが怖い ・選択肢が多すぎて迷ってしまう ・作業の導線が整っていない ・試せる状態が作られていない こうした環境の問題が、 あなたの開発スピードを奪っている最大の要因です。 この番組では、それらを1つずつ解きほぐし、 「迷いを潰す」 → 「判断が速くなる」 → 「手が止まらない」 という流れを作るための思考法と習慣をお話しします。 テーマはゲーム開発に限りません。 エンジニア、デザイナー、動画クリエイター、作家、個人開発者など、 “何かを生み出すすべての人”に共通する話です。 制作のスピードは、人生のスピードを変えます。 速く作れるようになると、 挑戦できる機会が増え、 フィードバックの回転が増え、 経験の量が一気に積み上がっていく。 その結果、 「速く作れるからこそ、さらに良いものが作れる」 という好循環に入っていきます。 僕自身、毎日ショート動画を作り、 個人ゲームを開発し、 クライアントワークもこなしながら 高速で制作を続けています。 その中で気づいた “現場に根ざしたリアルな視点”も 躊躇なく全部共有していきます。 ■この番組で得られるもの ・制作で迷わないための判断基準 ・速く作れる人の思考パターン ・手が止まらない環境整備のコツ ・壊しながら進むためのノウハウ ・習慣としてのスピードを身につける方法 ・現場で実際に使われている開発アプローチ 制作に向き合うあなたの“核”を整える内容です。 ■配信スタイル 毎回5〜10分。 忙しいクリエイターでも無理なく聴けて、 その日の制作にすぐ活かせるように設計しています。 ■最後に この番組は、 「速く作る」ための番組ではありません。 “迷わず前へ進むための番組”です。 制作に向き合う人が、 もっと軽く、もっと速く、 もっと前へ進めるようになるための思考と環境を これからも丁寧に届けていきます。 破壊的スピード開発を、あなたの日常に。 --- stand.fmでは、この放送にいいね・コメント・レター送信ができます。 https://stand.fm/channels/66588cbb316143a771aa74c5
    続きを読む 一部表示
    5 分
  • 業界で使われるテクノロジーを先取りして使わないといけない理由
    2024/06/03
    #ゲーム開発 #unity #git #エンジニア --- stand.fmでは、この放送にいいね・コメント・レター送信ができます。 https://stand.fm/channels/66588cbb316143a771aa74c5
    続きを読む 一部表示
    13 分