『破壊的スピード開発ラジオ』のカバーアート

破壊的スピード開発ラジオ

破壊的スピード開発ラジオ

著者： オオバ
無料で聴く

ゲーム開発歴12年・エンジニア歴15年のオオバが、「もっと速く作れるようになりたい」クリエイターやエンジニアのために「開発スピードを上げるための思考法」をお届けします。 便利なテクニックではなく、迷いを減らし、判断を早くし、手を止めずに作り続けるための「環境整備」にフォーカス。 ・なぜ手が止まるのか ・どうすれば迷いが消えるのか ・速い人が無意識にやっている習慣 ・壊しながら前へ進む開発とは何か 短い時間で、制作に向き合うための「核」が整う番組です。 ✔️「この番組は、制作に悩むあなたの“迷いを減らす場所”です。」
エピソード
  • 破壊的スピード開発 #7｜通知UIで現れた判断の本質

    破壊的スピード開発 #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の判断軸をアップデート

    破壊的スピード開発 #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起動前の無駄が速さを奪う理由

    破壊的スピード開発 #5｜Unity起動前の無駄が速さを奪う理由
    2025/12/10
    今回の破壊的スピード開発ラジオでは、 「Unity を開く前に発生する “たった数十秒の無駄” が、なぜ未来の開発スピードを奪うのか」 というテーマでお話ししています。 Unity を立ち上げるとき、こんな経験ありませんか？ ・Hub の起動が遅い ・どのプロジェクトで作業するか毎回確認 ・ブランチが合っているか気になる ・開始する前にすでに疲れている こうした “開始前の小さな迷い” は、 実は開発の後半に大きなダメージとして返ってきます。 作業とは関係のない待ち時間や確認作業が続くと、 脳のエネルギーが奪われ、集中力の寿命が短くなり、 開発のスタートダッシュが遅れてしまう。 破壊的スピード開発の視点では、 「作業中の迷い」より 「作業を始める前の迷い」 のほうがはるかにパフォーマンスに影響すると考えます。 速い人は例外なく、 作業前の流れが “異常にスムーズ” です。 椅子に座る ↓ すぐ作業に入れる ↓ 確認作業ゼロで着火できる この “着火スピード” が、 その日の集中力の質と持続力を大きく左右します。 今回の放送では、 ・開始前の迷いがなぜ危険なのか ・なぜ毎日の数十秒が積み重なると大きな差になるのか ・速い人が“前工程”にこだわる理由 ・環境整備が脳と集中力の寿命を伸ばす話 といった、ツールよりも本質的な部分を深掘りしています。 具体的な環境改善の方法や、 Unity の起動プロセスをどう最適化するかといった実践部分は note にて詳しく解説しているので、 興味のある方はぜひあわせてチェックしてみてください。 未来の遅さを、今の工夫で潰す。 破壊的スピード開発の核心に触れる回です。 --- stand.fmでは、この放送にいいね・コメント・レター送信ができます。 https://stand.fm/channels/66588cbb316143a771aa74c5
    続きを読む 一部表示
    5 分
adbl_web_anon_alc_button_suppression_t1
まだレビューはありません