“トーレルーフ”の裏側で何があったのか。「ティアーズ オブ ザ キングダム」開発陣が語る，一貫した実装と効率化の重要性［CEDEC 2024］
“トーレルーフ”の裏側で何があったのか。「ティアーズ オブ ザ キングダム」開発陣が語る，一貫した実装と効率化の重要性［CEDEC 2024］ ライター：高橋祐介 ゲーム開発者向けカンファレンス「CEDEC 2024」にて，2024年8月23日に開催されたセッション「『ゼルダの伝説 ティアーズ オブ ザ キングダム』におけるフィールド制作とQA 〜トーレルーフの裏側で〜」を紹介しよう。 登壇したのは，任天堂の企画制作部でQAエンジニアリングを担当した大礒 琢磨氏と，エンバイロメントプログラミングを担当した朝倉 淳氏。そして地形リードアーティストの竹原 学氏だ。同セッションでは同作のプレイヤーなら必ずお世話になっただろう「トーレルーフ」をテーマに，本作の開発がどのように進められたかが，3人の登壇者によって解き明かされた。 任天堂の企画制作部の大礒琢磨氏（前列左）と朝倉 淳氏（前列右），竹原
開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する
この記事は前作 開発生産性の可視化サービスから何を見いだして何ができるのか、あるいはすべきで無いこと に続き、開発生産性へのスタンスを整理したい2作目です。 効果・成果よりも効率を優先することは生産性か？ 開発生産性と言いながら単なるアクティビティの量や時間を見て効率改善を志してしまういくつかの状況、一部の風潮に対して疑問を呈したい。 例えば、PRやイシューの起票数などアウトプット量の高低に一喜一憂する 例えば、変更のリードタイムやデプロイ頻度の増進を過度に重視する 例えば、サイクルタイムの各時間を人間の努力のみで短縮しようとする それにも関わらず、開発がもたらしたユーザーへの効果やビジネス上の成果に無関心というのは順序おかしいよね、という話。 などと考えていたら開発生産性カンファレンス2024 - 登壇資料まとめ｜610を見る限り、近しい主旨の論説を散見するに至り、もしかしたら世間の議論
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
7. リソース効率性とフロー効率性 A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C A A A A A A A A A A A A A A A B B B B B B B B B B B B C C C C C C C C C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リリースまでのリードタイム 約2w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w A機能、B機能、C機能の実装それぞれ15人日かかる場合 A A A B B B B B B
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
個人開発を加速させる効率アップ戦術
事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering
