CEDEC2022_グローバルモバイルゲームのためのパフォーマンス最適化にチームで向き合う方法/cedec-2022-performance-optimization

Transcript

1. 助けて！実機でFPSが1しか出ないの！ グローバルモバイルゲームのための パフォーマンス最適化に チームで向き合う方法 CEDEC2022 ワンダープラネット株式会社 吉谷幹人
2. © WonderPlanet Inc. 2 自己紹介 吉谷幹人（ヨシヤミキト） ワンダープラネット株式会社 CTO @mikito0521 テックリードとして複数プロジェクトのシステムアーキテクチャや、 技術課題マネジメント、組織運営を主導。その後、全社横断組織 EDMO（エドモ）のエンジニアリング担当かつCTOとして、社内の技 術課題管理や基盤整備、社内標準化などに従事。 主な著書 • Unity2021 3D/2Dゲーム開発実践入門 • Unityゲーム プログラミング・バイブル（共著）
3. © WonderPlanet Inc. 3 はじめに - 本セッションのコンセプト 「FPSが1しか出ない」って大袈裟な...と思いますか？ 今回の発表は、 パフォーマンスチューニングを完璧に行なったという事例や、 具体的なテクニックを紹介するものではありません。 • プロジェクトで度重なる問題がでた中で、それらにどのように対処してリリース までたどり着いたか • 新規にプロジェクトを始めるなら、どのようなポイントに注意し何を行うべきか を解説するものです
4. © WonderPlanet Inc. 4 セッション内容の補足 主にクライアントアプリケーションに関してのトピックにフォーカス • ＋普遍的な内容 サーバーアプリケーション・インフラ含めた取り組みは、以下のセッションでも紹介 2022/8/24(水) 11:20〜12:20 インフラからアプリまで！アリスフィクションを全世界で安定稼働させる開発チームの裏側に迫る
5. © WonderPlanet Inc. 5 セッションの流れ 本セッションの経緯・背景 1. ワンダープラネットのミッションとアリスフィクション 実際の問題 2. アリスフィクションの開発で実際に起きた問題 課題の整理 3. 大規模なモバイルゲーム開発とグローバル展開におけるパフォーマンスマネジメン トの難しさ 対応策と方法 4. チームでパフォーマンスに向き合うための4つのポイントと事例の紹介 今後の取り組みや発展内容 5. ワンダープラネットのこれからの取り組み
6. 6 ワンダープラネットのミッションと アリスフィクションについて
7. © WonderPlanet Inc. 私たちの使命は、世界中の一人でも多くの人々の日常に、家族や友達と「楽しい ね！」と笑いあえるひとときを届けることです。 国・言語・文化・年齢・性別などあらゆる壁を越えて誰もが楽しめるプロダクト・ サービスを創り、コミュニケーションを通じた「笑顔」を世界の隅々まで広げてい きます。 ワンダープラネットのミッション 7
8. © WonderPlanet Inc. 私たちの使命は、世界中の一人でも多くの人々の日常に、家族や友達と「楽しい ね！」と笑いあえるひとときを届けることです。 国・言語・文化・年齢・性別などあらゆる壁を越えて誰もが楽しめるプロダクト・ サービスを創り、コミュニケーションを通じた「笑顔」を世界の隅々まで広げてい きます。 ワンダープラネットのミッション 8 すぐに起動して、 ストレスなくプレイできる。 どんな時でも遊びたくなる！
9. CONFIDENTIAL 毎日の楽しさを全世界で 生み出す4つの技術領域を全て極め ユーザーとビジネスに最高の価値を届ける 究極の当たり前を世界規模でやる ユーザーにとって当たり前のことを全世界どんな時でも全てのプロダクトで実現する。 そのためには当たり前じゃないことにも挑戦する。 ワンダープラネットの目指す技術 Comfortable UX Emotional Art Integrated Globalization Reliable Operation 感動をもたらすビジュアルを実現する技術 最高の気持ち良さと快適さを実現する技術 世界同時配信を最高品質で実現する技術 高速改善と長期安定運営を実現する技術
10. アリスフィクションとは
11. アリスフィクションとは
12. © WonderPlanet Inc. 12 アリスフィクションの開発事情-様々なパフォーマンス問題が起きた 体制と環境 • 名古屋・東京オフィスの共同メンバー（リモート） • 最終的に100人を超えるチーム • Unityでの開発 / 初経験のメンバーの割合多 開発の進行 • ゲーム性やビジュアルの方向転換多数 • 途中で全世界同時配信・同時運営の方針にシフト
13. 13 アリスフィクションの開発で 実際に起きた問題
14. © WonderPlanet Inc. 開発マイルストーンとイベント 14 pre α β master プロジェクト開始 2021/2 ベータ開発開始 2022/2 CBTの実施 2022/7 リリース 技術課題チームがJoin （2021/4に吉谷＋Unityエンジニア1人） - 体制の急激な拡大 - ビジュアルやゲーム性のテコ入れ
15. © WonderPlanet Inc. 15 ジョイン直後のヒアリング状況（ベータ開発初頭） 端末チンチン問題（チンチン=めっちゃ熱いの意） • 描画量が多い • 特定Android機種でFPSが4 操作時にカクツキが多発 • オブジェクトプールなどが実装されていない クラッシュが多発 • メモリ and 原因不明 見えるところは修正・改修をしながらプロジェクト全体の分析を進める
16. © WonderPlanet Inc. 16 キャラクタースキル演出・背景描画しすぎ問題（ベータ開発初頭） キャラクターのスキルエフェクトがかなり厳しい作り • パーティクルの多用 • psdファイルを全画面レイヤーをそのまま何重にも表示 すでに量産が開始されている...!
17. © WonderPlanet Inc. 17 キャラクターのボーン数おおすぎ問題（ベータ開発初頭） 非活性モーションのボーンが全て計算に含まれるような作り • Spineを利用 • 1キャラクター800ボーンx8体 • CPUの計算負荷が高い状況に すでに量産が開始されている...!
18. © WonderPlanet Inc. 18 バトル画面エモ化計画（ベータ開発中盤） バトルの画面見栄えを向上させるためのムーブが実行された • ポストプロセスエフェクトの導入 • ライティング、ノーマルマップなどが導入 • ステージのリフレクションのロジックもfix Androidの特定端末でFPS30キープ→FPS1へ • ここでチューニングの目処が立っていたが再計画
19. © WonderPlanet Inc. 19 端末チンチン問題の再発（ベータ開発後半） パーティクル大画面大量描画事件 • 特定の背景アセットでパーティクルがとんでもない量出ていた バトル画面ダイナミック化計画 • バトルのカメラワークにもっと動きを出してビジュアルを改善するムーブ 改善後 (赤白いところがOverdraw発生領域）
20. © WonderPlanet Inc. 20 メモリ使用量やばい問題（ベータ開発後半） 必要のないアセットをロード • モックデータ • 意図しない依存アセット 一部のUI用プラグインが大量のテクスチャを確保 • すでに様々なところに組み込まれ済み 開発後半で本番アセットやレベルデザインが揃ってきてより深刻に • 一度達成に近づいた基準値も大きく上回る
21. © WonderPlanet Inc. 21 バトルロード長すぎ問題（ベータ開発後半〜マスター開発） バトル開始まで30秒以上かかる状態 • アセットのロード処理がボトルネック このタイミングまで本番のアセットパイプラインが整理できていない • 依存関係がやばすぎて、最低限の整理にベータ後半までかかった • ローカライズ関係のシステム構築も起因
22. © WonderPlanet Inc. 22 アリスフィクションでのパフォーマンス問題と対応 その他、相当の数の問題に対処 至る所のDrawCall/描画量の削減、 チャットロード時間短縮、スクロールリストのプール化、ア セットの開放管理、メモリアロケートの削減、不要アセットの削除、各種圧縮やフォーマットの調 整、etc.. 計画をたて、かなりの工数と時間をかけて長期的に取り組み • 一年間の改修計画と実行を経てリリース • それでも理想的な状態には全然なっていない 改修計画中にも新しい問題がたくさん起きた • ビジュアルの方向転換への対応 • 既存問題を優先することにより、新規問題の発生抑止が後手に
23. © WonderPlanet Inc. 23 パフォーマンス問題を軽視すると... 開発がストップする・リリース不能になる • 対象端末でメモリが足りずクラッシュしてしまう • 大量のアセットの作り直しが発生する 想定したプレイ体験を提供できないままリリース • 特定端末でアクション性が低下 • 演出やエフェクトを大幅にカット
24. 24 大規模なモバイルゲーム開発と グローバル展開における パフォーマンスマネジメントの難しさ
25. © WonderPlanet Inc. 対象デバイスや環境の幅広多さ 25 多様なモバイル（スマートフォン）端末 • 様々なスペックの端末が存在 • iOS: 50over、Android: 5000over • コストバランスの問題で発売日が最近でもローエンドモデルが存在 グローバル展開で対象端末や環境考慮がさらに広がる • 日本国内で販売されていない端末も存在 • 様々な地域の回線状況からアクセスがある 端末・環境次第で体感が大きくブレてしまう • 手元の最新端末では問題なかったという齟齬が起きてしまう
26. © WonderPlanet Inc. 規模拡大における状況把握と認識統一 26 多数のチームと関係者が存在 • 様々なスキルレベルのメンバーが所属・直接的作業をなかなか見れない • パフォーマンスをチェックする担当者が不在のまま進行してしまうことも 世界同時運営対応でパイプラインも増える・複雑化する • ローカライズチームのジョイン • ローカライズアセット、それらのビルドパイプラインの構築 • 翻訳スケジュール加味でいろいろなものが2、3ヶ月早く企画されていく 少人数チームでは出来ていた暗黙のルールはワークしない • 阿吽の呼吸・ツーカーの仲のようなものは効かない
27. © WonderPlanet Inc. 外注量産アセット制作ラインでのパフォーマンスの担保 27 納品完了後に修正・作り直しはできない • 修正には追加費用がかかる • 最後にパフォーマンスチューニングするという考えは効かない 検修作業がむずかしい • 発注・検修担当者はエンジニアでない場合も多い • 誰でも判定ができるような仕組みが必要 発注側・受注側で認識を合わせる必要がある • パフォーマンスの考慮も込みで制作が必要 • パフォーマンスの検修が必要
28. © WonderPlanet Inc. 28 大規模チームのパフォーマンスマネジメントにおけるすべきこと パフォーマンスという要素は曖昧になりがちで明文化されにくい • どのくらいの動作を目指すのか • 何がOKで、何がNGなのか グローバル展開への対応でその幅や規模がさらに広がる • 意図的に検証・考慮しないとフォローされない • 「いい感じに」ではうまくいかない パフォーマンスに関しても「非機能要件」として定義・言語化し チーム全体で開発初期から意識して取り組むことが必要
29. 29 チームでパフォーマンスに向き合う ための4つのポイントと事例
30. © WonderPlanet Inc. チームでパフォーマンスに向き合うための4つのポイント 30 4つのポイント 1. チーム全体の認識を揃える 2. 性能要件を策定する 3. レギュレーションを決め運用する 4. 全てを計測し記録する ポイントを整理しながら、アリスフィクションの開発の中で どのような動き・対応を行ったかの事例を紹介
31. 31 4つのポイントと実例 1.チーム全体の認識を揃える
32. © WonderPlanet Inc. アリスフィクションのアルファ開発までで問題だった点 32 担当者レベルでパフォーマンスが意識されていない • 機能要件・仕様が満たされればOKという流れ • マスター開発フェーズのみでのチューニング計画 • チューニングの分業的な考え • 実機での確認不足 開発・制作で考慮すべきポイントが認識されていない • 計算量、メモリアロケート • ドローコール • 圧縮フォーマット • 描写量・半透明の利用方法 • パーティクルの注意ポイント
33. © WonderPlanet Inc. チーム全体での意識と認識を揃える 33 チーム全体で取り組む必要性を明示 • 問題 vs 1人の担当者 → 問題 vs チーム シフトレフトな動きを目指す • 前の工程でいろいろ考慮してもらう • 可能であれば企画段階 TeamA TeamB TeamC チューニング担当者 パフォーマ ンス問題 発生してからの・相談・修正依頼 TeamA TeamB TeamC パフォーマ ンス問題 パフォーマンスの重要性・性能要件 エンジニア/TA 事前相談 認識 部分的対応
34. © WonderPlanet Inc. 34 事例1.1-パフォーマンスチューニング計画キックオフ 現状分析と中期計画レポートを作成 • 現状の問題と課題、どのくらいの値を目指すか • どのようなスケジュール（1年）で解消していくか ベータ開発の中盤で全関係者に現状と計画を説明 • デザイナー・プランナー・協業者さん全員（当時60名ほど） • プロデューサーから「パフォーマンスも超重要」と号令
35. © WonderPlanet Inc. 35 事例1.2-パフォーマンスチューニングハンズオンの実施 開発時に必要なパフォーマンス関連の基本知識を共有 • レンダリングの基本知識 • アセット制作時に考慮すべきポイント • パフォーマンス指標の見方やプロファイリングの仕方 全エンジニア・全デザイナ＋ディレクターに実施 • 資料化、録画（Zoom開催）で、あとから参画のメンバーでも見れるように
36. © WonderPlanet Inc. 36 最適化やチューニング作業で発覚する問題の経験則 発覚する問題の割合（主観） • 6-8割：無駄、浪費 • そもそもやらなくていいもの、即時削除していいもの • キャッシュしたりバッチ化/バルク処理したり • 2-4割：置換、調整 • 効率の良い方法・アルゴリズムに変更する • 人間の感覚ではわからない用データ量を下げる • 1-2割：トレードオフ • 保守性、空間計算量などを犠牲にする 全員が少しずつ気を付けることで、起きる問題の大半を回避できるはず • 例：無圧縮のモックデータが混入していた • 厄介なのはプロジェクト後半になると無駄な要素か判別がつかなくなること
37. 37 4つのポイントと実例 2.性能要件を策定する
38. © WonderPlanet Inc. 38 スマートフォンゲームにおける性能要件の重要性 どのくらいのパフォーマンスが出ればOKなのかを明示 • どの端末でどの値がどのような状態になっていれば良いのか • このあと全ての動きの基準になる 不必要なリダクション・クオリティ低下を防ぐ • どこまでやれば必要十分なのかを明示
39. © WonderPlanet Inc. 39 事例2.1-性能要件の決定（社内ドキュメント抜粋） 1.クオリティ・パフォーマンス・ビジネス要件 • ゲームビジュアル要件 • ターゲットFPSとゲーム操作要件 • ターゲット端末市場シェア 2.ハードウェア要求性能とベンチマーク端末 • 動作保証スペック・ベンチマーク端末 • 推奨スペック・ベンチマーク端末 3.ソフトウェア画面基準値、性能制御に関する機能要件、その他 • ターゲットDPI/最大Resolution • 開発基準アスペクト比とリファレンスサイズ • 品質オプションの機能要件（低・中・高など）
40. © WonderPlanet Inc. 40 段階別のデバイス性能要件 性能幅が大きいので数段階設けるべき ワンダープラネットでは最低2段階を決めている（以下は例） 動作保証スペック・端末 • メモリ不足でクラッシュせず、最低限ゲーム性を損なうことなくプレイできる • エフェクト時などにFPSの低下は認める 推奨スペック・端末 • ビジュアル要件とパフォーマンス要件を損なうことなくプレイできる • FPSの低下が無い、ロード時間が要件を満たす
41. © WonderPlanet Inc. 41 性能要件とベンチマーク端末選定方針 SoC（System on a Chip）ベースでの選定 • 発売日や世代で単純に性能を推定することは難しい • 使用しているSoCからデバイスの性能の把握が大体可能 Antutuベンチマーク値を活用 • Webに数多くのSoCや端末のスコア情報がまとめられている SoC - System on a Chip CPU、GPU、通信、インターフェースの制御などの機能がワンチップになっている集積回路のこと Antutu スマートフォンやタブレットなどのデバイスの標準的なベンチマークとして使用されている、中国のソフトウェア
42. © WonderPlanet Inc. 42 基準スペックの算出ロジック ワンダープラネットで事前に用意しているもの • 利用端末分布データ（社内類似プロジェクト基準） • 端末モデルと利用SoC表（Webから収集） • SoCとベンチマークスコア表（Webから収集） それぞれをマッピングしシェアとスコアを見る • スコアでソート • シェアを累計してビジネス要件とすり合わせ その他 • タブレットは別で選定する • ある程度主観なども交えて決める
43. © WonderPlanet Inc. 43 参考： 2022年時点でのグローバル端末の所感 iOS • 2018年以来の発売端末でシェア60%/スコア50万点以上 • iPhone7（スコア約29万点）付近でシェア85%以上 • 未だiPhone6s以下の世代のアクセスも2％程度ある Android（シェア上位300での測定） • 半数以上がSamsung(Galaxy) • 15%: Xiaomi(Redmi) • 12%: Oppo(OnePlus) • OnePlus 5-単独シェア圧倒的トップ • 4%: Google(Pixel) • 2%: HUAWEI、Motorola
44. © WonderPlanet Inc. 44 開発のタイムラインと選定項目の利用タイミング アルファフェーズ マスターフェーズ デザイン基準サイズや基盤技術選定 ベータフェーズ 継続的パフォーマンス計測・実機確認とチューニング クオリティラインや基本設計・各種レギュレーションの確定 パフォーマンス制御に関する機能要件の実装 総合的なパフォーマンスチューニング 不具合レポートの性能由来の問題解決・仕様切り分け 多端末検証などの項目作成 QAフェーズ 遅くともベータフェーズ から継続的に実機計測 と、ある程度の最適化に 取り組む ベータフェーズに入る前に アセットのレギュレーション を確定しチームに周知 性能要件や選定端末は以下のようなタイミングで多用
45. © WonderPlanet Inc. 45 事例2.2-性能要件ベースの品質設定オプション 品質設定オプションを導入 • 設定画面等でユーザーがクオリティバランスを選べるようにする機能 • 性能要件に合わせて基準値や目標を決める • 端末性能の幅が広い（10万〜80万点）ので基本導入すべき 対応項目例 • 画面レゾリューションや各種テクスチャサイズ制限 • スクリーンエフェクトのon/off • その他ライティング関係の設定
46. © WonderPlanet Inc. 46 端末レゾリューションとDPI(Dots per Inch) 異常に大きいレゾリューションの端末が存在する • 自身の端末性能に追いついていない場合も • ゲームとしては大きすぎるケースも多い 制限をかける前提で事前に決めたおいた方がいい • 最大DPI 326、1334x750程度あれば十分だとおもう • タブレットは別DPI制限かレゾリューションサイズに制限もうけた方がよい 参考 • Nintendo Switch: 1280x720（DPI 238) • Apple iPhone 11: 1792x828（DPI 326） • Samsung Galaxy S8: 2960x1440（DPI 640）
47. © WonderPlanet Inc. 47 ベンチマーク端末を決めたら 手配or購入してメンバーやチームに配布 • 開発中の検証に恒常的に利用してもらう • 中古端末などでOK • 少なくともリードエンジニアにはiOS/Android双方手配
48. 48 4つのポイントと実例 3.レギュレーションを決め運用する
49. © WonderPlanet Inc. 49 性能要件を満たすための詳細方針を決める 量産される箇所のレギュレーションをつくる • どのような指標を満たしていればOKかを決める • どのように作れば良いかを明確化する 外注制作・納品検収時の定義にする • レギュレーションに従い問題が起きないように作ってもらう • 検収時にレギュレーションを守っているかの情報も提出してもらう • ビジュアルのみではわからない
50. © WonderPlanet Inc. 50 レギュレーションに含まれる指標の例 静的指標（再現性がある） • アトラスサイズ • メッシュ数 • ボーン数 • ファイルサイズ • DrawCall（Runtime） • FillRate（Runtime） • Allocate量（Runtime） • 単体使用メモリ（Runtime） 動的指標（動作環境・状況によって変わる） • CPU処理時間（Runtime） • 総使用メモリ（Runtime） • ロード時間（Runtime）
51. © WonderPlanet Inc. 51 事例3.1 - アセットパフォーマンスレギュレーションの策定 問題の量産物に新たにレギュを設定 • それに合わせて作り直し • 利用コンポーネントの指定、その他実装に関しての守るべきこと含む 本来デザインレギュレーションの一部 • TA(Technical Artist)のようなポジションがあるとやりやすい
52. © WonderPlanet Inc. 52 決めるだけでなく運用する: 指標の確認、チェック自動化 静的指標計測の自動化 • ファイルを走査・静的解析すればわかるものが多い • デイリーで回してSlackでレポートなど 動的指標の見える化 • FPSやその他指標のデバッグ表示 • レギュレーションを超えた時のアラート表示 • 指標の収集とレポート バリデーションや設定の自動化 • 意識しなくても守られるようにする
53. © WonderPlanet Inc. 53 事例3.2 - QAとの連携 QAチームにパフォーマンス指標チェックを依頼 • 一部アセットの納品時のチェックを依頼 多端末検証時にパフォーマンス検証を実施 • ベンチマーク端末と動的指標のレギュレーションに沿ってテスト仕様書を作る • 指標を画面に表示する専用ビルドでテスト
54. 54 4つのポイントと実例 4.全てを計測し記録する
55. © WonderPlanet Inc. 55 これでパフォーマンスは完璧？ これまでの話：発生する問題を最小限にするための動き • チームのマインドを統一する • 基準を決めて目標の状態を明確化する • 作り方の決まりと確認フローを作る それでも問題が起きる • 組み込み実施の複合的な影響 • プロジェクト方針の転換 • 細部の考慮漏れ →パフォーマンスチューニングを行う
56. © WonderPlanet Inc. 56 パフォーマンスチューニング時の心得 計測していないものをチューニングしてはいけない • 改善したのかわからない、もしかしたら悪くなっているかも • ボトルネックがわからない • 個人の職人作業になってしまう • 結果をビジネスサイドに説明できない 例：ロード時間が遅いという問題 • どの端末でどのくらい改善すべきかの課題に変換する • どのくらい遅いのか→iPhone7で20秒 • それをどのくらい早くすべきなのか→iPhone7で10秒 • どの処理をどう変えるべきなのか→APIリクエストを並列化する
57. © WonderPlanet Inc. 57 事例4.１-メモリ使用量定点観測 数ヶ月間のメモリチューニング • ボトルネック・要点になっている指標をKPIとして記録 • 開発も並行しているので悪化するケースもあるがきづける
58. © WonderPlanet Inc. 58 事例4.2-何がなんでも計測する 発熱問題のケース • 端末が熱いのは主観でしかない • エネルギー消費値やProcessInfo.ThermalStateでは判定が難しそうだった • 関連指標改善では効果の推定ができても実証ができない • 現象発現までに時間がかかる 仕方ないので温度計で測った • 温度計をスマホに巻きつける • 同一条件・時間でAuto/放置プレイ
59. © WonderPlanet Inc. 59 事例4.3-プロデューサー満足度 パフォーマンス満足度を測った（0〜100%） • 開発中の定性的な指標として計測 • 2週間おきに8ヶ月ぐらい継続（チューニングレポート時に口頭で聞く） 満点からの差分で課題を明確化 • どこがマイナスポイントで気になるのか • どのあたりがリリースレベルに達しないのか
60. © WonderPlanet Inc. 60 計測したものは記録して保存する 日付・条件などつけてアーカイブ • 数値、プロファイルリザルト、キャプチャ • 分析レポート、改修計画、比較資料 • 条件などを明記しておく（利用キャラ・ステージなど） あとで利用できることがかなり多い • 問題再発時の分析 • 他プロジェクトでの比較 • 改修プロセスの参考、学習
61. 61 ワンダープラネットのこれからの 取り組み
62. © WonderPlanet Inc. 62 全社標準ガイドライン化 ガイドラインをプロジェクト開始時に読み合わせ・実行する • 開発初期から意識を合わせる • 選定に利用するデバイス情報・シェアなどのデータを集約
63. © WonderPlanet Inc. 63 オブザーバビリティ(可観測性)への取り組み Real User Monitoring（RUM） • フロントエンドモニタリングで実際のユーザーの状態を観測する • バックエンドのみ→全体の観測性をあげてトレースする • リリース後の実際のユーザーの体感も測定（特に海外リージョン） New Relicサービスとの連携 • 料金体系や目的にマッチ • Unityはまだ未サポートなのでネイティブSDKの連携を実装 2022/8/24(水) 11:20〜12:20 インフラからアプリまで！アリスフィクションを全世界で安定稼働させる開発チームの裏側 に迫る 詳しくは下記の発表で
64. © WonderPlanet Inc. 64 計測指標の標準化、プロジェクト横断化 社内標準SLO（Service Level Objective）の策定 • プロジェクト横断で計測すべき指標の明確化 • 社内標準値の設定
65. 65 まとめ
66. © WonderPlanet Inc. 66 まとめ 複雑化したモバイルゲーム開発ではパフォーマンスは問題になりがち • 特にグローバル対応を目指すとコントロール難易度も増す • ビジネスに大きな影響を及ぼす可能性ある 4つのポイント：非機能要件として明文化してチーム全体で取り組む • チームvsパフォーマンスで認識を統一する • 性能要件や要求スペック、基準デバイスをしっかり決める • 量産箇所はレギュレーションを決めて重要指標をチェック • どんな時も計測して、記録に残しておく 今後 • ガイドライン化で全プロジェクトでの再現性を担保（できる人だけに任せない） • オブザーバビリティ(可観測性)の向上で超横断的な計測と継続改善へ
67. © WonderPlanet Inc. 67 楽しいね！を、世界中の日常へ。 Thank you!