1. はじめに はじめまして！電通総研の武田嵩史（たかふみ）と申します。テックブログを執筆するのが初めてで怯えながらの投稿ですが、全2回に渡り本テーマについて発信できればと思います。簡単に私の自己紹介をしてから本内容に移りたいと思います。 自己紹介 改めまして武田嵩史と申します。普段はクラウドを用いたシステム開発や運用のプロジェクト・マネージャーをしております。 その中でも最近ではクラウドHPCの基盤を構築することが多く、様々なクラウドベンダー様とお仕事をさせていただいております。 ”クラウドHPC”？なんじゃそりゃ？という方は弊社が公開している以下記事をご覧いただければと思います！ SDGsの達成にも貢献！？クラウドHPCについてもう一度考えてみる 電通総研のクラウドHPCサービスがもたらす革新とメリット 扱うクラウドはAWS, Azure, OCIの3つが主でして、それぞれのクラウドプロバイダーの強み・特徴を活かして最適な環境をお客様に提供することを得意としております。 モチベーション さて、そんな私がクラウドHPCの中でも最近特に注目しているのが、AWSの "hpc8a" インスタンスです。 AMD社の最新プロセッサであるTurin（EPYC 9R45）を搭載したインスタンスタイプでして、 ap-northeast-1（東京） リージョンで利用ができることが1つの特徴です。 このインスタンス、AWS公式のページを引用すると以下のパフォーマンスを発揮するとのこと。 前世代の Hpc7a インスタンスよりも 最大 40% 優れたパフォーマンス、42% 広いメモリ帯域幅、最大 25% 優れた料金パフォーマンス を実現します。 （引用元） 第 5 世代 AMD EPYC プロセッサを搭載した Amazon EC2 Hpc8a インスタンスの一般提供開始 HPCワークロードの特徴上、解析データサイズも大きかったり、多くのI/Oが発生したりするので、データとコンピューティングリソースは可能な限り近い場所に置く方がパフォーマンスを発揮できます。そのため、日本のお客様は日本で利用できる高性能なマシンはあればあるだけ嬉しいので、このインスタンスタイプに私自身もとても興味があり、実力はどんなものかと調査すべく今回のベンチマーク実施に至りました。 本題 本記事は以下の流れとなっております。 目次 はじめに ←終了 ベンチマーク概要 Ansys Fluentベンチマーク結果 Cradle MSC scFLOWベンチマーク結果 おわりに（次回予告） 2. ベンチマーク概要 2.1 ベンチマークに利用したインスタンスタイプ ベンチマークと言ってもhpc8aだけで解析実行しても仕方ありません。ということで、今回は以下のEC2インスタンスタイプを選定しベンチマークを実施しました。 Instance type Spec Cost $ (instance/h) Cost $ (core/h) hpc6id.32xlarge (Intel) CPU：Intel Xeon Ice Lake 64cores Memory：1024GB NIC：200Gbps EFA $5.70 $0.09 r8i.96xlarge (Intel) CPU：Intel Xeon 6 Granite Rapids-AP 192 cores Memory：3072GB NIC：100Gbps EFA $26.67 $0.14 c7a.48xlarge (AMD) CPU：AMD EPYC 9R14 Genoa 192 cores Memory：384GB NIC：50 Gbps EFA $9.85 $0.05 hpc7a.96xlarge (AMD) CPU：AMD EPYC 9R14 Genoa 192 cores Memory：768GB NIC：300 Gbps EFA $7.20 $0.04 m8a.48xlarge (AMD) CPU：AMD EPYC 9R45 Turin 192 cores Memory：768GB NIC：75 Gbps EFA $11.69 $0.06 c8a.48xlarge (AMD) CPU：AMD EPYC 9R45 Turin 192 cores Memory：384GB NIC：75 Gbps EFA $10.35 $0.06 hpc8a.48xlarge (AMD) CPU：AMD EPYC 9R45 Turin 192 cores Memory：768GB NIC：300 Gbps EFA $7.92 $0.04 c8g.48xlarge (AWS) CPU：AWS Graviton4 192 cores Memory：384GB NIC：50 Gbps EFA $7.63 $0.04 ※Costはオハイオリージョンでの単価です。 ※Cost $ (core/h), Cost $ (instance/h)においては小数点3桁を四捨五入した小数点以下2桁で表記しております。 ※一部ベンチマークについては結果がないインスタンスタイプもございます。 選定の基準としては3つの観点で行いました。 ” 1. 会社 " CPUの製造元として代表的なIntel, AMDを選定。また、AWSも独自でプロセッサを開発しているので、Gravitonもノミネートしました。 " 2. 世代 " 各CPUの世代が上がると性能も向上するのか、どの程度向上するのか、という指標をみるために複数世代を選定しました。 " 3. インスタンスの用途 " AWSは同じCPUを搭載していても、ワークロードによって最適化されたインスタンスタイプを準備しています。基本的にはコンピューティング最適化インスタンス（cシリーズ）とHPC特化インスタンス（hpcシリーズ）を選定していますが、メモリ最適化（rシリーズ）、汎用（mシリーズ）も選定しているものもあります。 2.2 ベンチマーク実施内容 ここではどのような条件、ソルバでベンチマークを行ったかをご説明いたします。 2.2.1 ベンチマーク実施ソルバ 今回ベンチマークを実施したソルバ・ベンチマークモデルは以下です。 Solver Version Benchmark Model Ansys Fluent 2025R2 f1_racecar_140m Fluent benchmark model Ansys LS-DYNA 2025R2 Car2Car LS-DYNA benchmark model Siemens STAR-CCM+ 2506.0001 Golf_140M [Original Model] Cradle MSC scFLOW 2025.1 Common Research Model この中で第1回となる今回は Ansys Fluent と Cradle MSC scFLOW のベンチマーク結果を皆様に共有いたします！ 2.2.2 ベンチマーク実施環境情報 ベンチマークを実施した環境情報は以下のとおりです。 項目 内容 OS Red Hat Enterprise Linux 8.10 ストレージ Amazon FSx for Lustre （SSD / 250 MB/s-TiB ） *4.8 TiB ネットワーク EFA 有効化 ジョブスケジューラー Slurm MPI Intel MPI 2021.13 MPI （Arm プロセッサ利用時） Open MPI 4.1.7 また、これらの環境の準備にはAWS ParallelClusterを利用しており大変便利なサービスでしたので、こちらも別途ご紹介できればと思います。 （参考） AWS ParallelCluster 2.2.3 ベンチマーク評価項目 ベンチマークの評価項目は以下の3つの指標で評価を行いました。 1．実行時間 各ソルバーの実行時間を秒単位で計測。 2．コスト 各ベンチマークジョブを完走するのに必要となるインスタンスの費用を計算。ここでは起動/停止にかかる費用やデータの保管費用、通信にかかる費用は含んでおらず、あくまでベンチマークジョブを完走するのにかかったコンピューティングリソースのみの費用を算出しています。 3．コストパフォーマンス 「計算速度が速くても値段が高いと簡単には利用できない。」というのが実情だと思いますので、今回はコストパフォーマンスという指標も準備しました。コストパフォーマンスは以下式で定義します。 今回は簡単のために、Genoaプロセッサを搭載したコンピューティング最適化インスタンスタイプ "c7a.48xlarge"を"1.0"として正規化したスコアで評価しました。 3. Ansys Fluentベンチマーク結果 それではAnsys Fluentのベンチマーク結果がこちらです。Ansys Fluentでは256並列から2048並列までの並列数で実施しました。 3.1 実行時間 ソルバー実行の経過時間比較 同一並列解析数の場合、全ての場合でTurin (m8a, hpc8a) のインスタンス性能が良い結果となりました。 前世代とのパフォーマンス比較 全並列数で3割程度のパフォーマンス改善がみられました。AWS公式によると、 最大40%の優れたパフォーマンス とのことだったので、今回の結果はそれに近い結果が得られました。 Gravitonの計算スケール c8g (Graviton4) については、並列数が増加するにつれ、他インスタンスタイプとの経過時間の差は縮小傾向にあり、大規模並列計算において計算時間のスケールメリットが出ることが確認できました。 3.2 コスト コスト比較 hpc8aが全ての並列数で一番コストが低い結果でした。 Ansys Fluentの今回のベンチマークモデルにおいては512並列が一番コストに優れた並列数となりました。 前世代とのコスト比較 全並列数で2割程度のコスト改善がみられました。AWS公式によると、 最大 25% 優れた料金パフォーマンス とのことだったので、こちらも公式に近い結果が得られました。 3.3 コストパフォーマンス コストパフォーマンス比較 hpc8aが一番コストパフォーマンスに優れた結果になりました。 同CPUスペックで比較するとHPCインスタンスはコストパフォーマンスが高い結果がみられます。 c8g (Graviton4) は2048並列になると、c7aのコストパフォーマンスを上回る結果になりました。 以上がAnsys Fluentのベンチマーク結果となりますが、いかがでしたか。 実行時間・コスト・コストパフォーマンス全てにおいてhpc8aが良いパフォーマンスを示していたことがみてとれたのではないでしょうか。 4. MSC scFLOWベンチマーク結果 続いてはCradle MSC scFLOWのベンチマーク結果です。scFLOWでは128並列から1024並列までの並列数で実施しました。 scFLOWにおいては一部実施できていないインスタンスタイプがあることご了承ください。 4.1 実行時間 ソルバー実行の経過時間比較 同一並列解析数の場合、全ての場合でhpc8aの性能が良い結果となりました。 前世代とのパフォーマンス比較 こちらもAnsys Fluentと同様、全並列数で3割程度のパフォーマンス改善がみられました。 4.2 コスト コスト比較 hpc8aが全ての並列数で一番コストが低い結果でした。 前世代とのコスト比較 こちらもAnsys Fluentと同様、全並列数で2割程度のコスト改善がみられました。 4.3 コストパフォーマンス コストパフォーマンス比較 上記の結果からも分かるとおり、hpc8aが一番コストパフォーマンスに優れた結果になりました。 以上、scFLOWのベンチマーク結果でしたが、大きな方向性としてはAnsys Fluentと変わらず、実行時間・コスト・コストパフォーマンス全てにおいてhpc8aが良いパフォーマンスを残していました。 5. おわりに（次回予告） というところで今回はAnsys FluentとCradle MSC scFLOWにおけるhpc8aのベンチマーク結果をご紹介いたしました。 次回は衝突系ソルバのAnsys LS-DYNAと流体系ソルバSiemens STAR-CCM+のベンチマーク結果もご紹介いたしますので、そちらもお楽しみにお待ちいただけますと幸いです！ 末筆になりましたが、本ベンチマーク実施にあたりご協力いただきました各社様、ご関係者の皆様に厚く御礼申し上げます。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @takeda.takafumi レビュー： @kobayashi.hinami （ Shodo で執筆されました ）

はじめに 株式会社タイミーでデータアナリストをしている平野です。 タイミーキャリアプラス (以下、タイキャリ)という新規事業に、リードDAとして半年あまり伴走してきました。 タイキャリは、タイミーの スキマバイトのデータを起点に、長期就業(正社員採用)を支援する サービスです。タイミーで得た就業実績・バッジを"職務経歴書"として活用できるのが特徴で、2024年2月に開始されています。 新規事業DAの面白さ 0→1のフェーズで、データと事業を一緒に育てていく感覚 を味わえる仕事です。 自分の分析が 事業の意思決定に直結 する瞬間が日常的にある 事業責任者・GM・PdMと机を並べて、 事業の方向づけにデータで参加できる データ基盤・モニタリング・分析テーマを ゼロから設計 できる この記事で書くこと 一方で、新規事業ならではの難しさもあり、半年の間に"知っていれば避けられた"失敗 を数多く経験しました。同時に 再現可能な"型"が存在するとも確信しています。 本記事では、私が踏んだ落とし穴とそこから抽出したアクションを 時系列で整理 します。これから新規事業に入るDAの参考になれば嬉しいです。 Part 1: 新規事業DA特有の3つの難しさ 💡 難しさはPart 2の予防アクション、Part 3の原則とセットで読むと"克服可能な型"として見えてきます。 私が実際に踏んだ落とし穴を3つ共有します。どれも 新規事業DAが共通して直面しうる構造的な問題 で、「誰かが悪い」ではなく、立ち上げ期に起きやすい"あるある"です。DA側がどう動くと摩擦や手戻りを減らせるか、という観点で整理します。 ① 統制構造の有無で難易度が桁違いに変わる DAへの依頼を集約する"要望窓口"(bizops的人材)がいるかどうかで、伴走の難易度が大きく変わります。立ち上げ初期は役割や導線が固まりきっていないため、集約は"自然発生"しないことも多いです。 集約役がいる事業 : 要望が一本化、定義の議論は1対1で済む 窓口体制が立ち上がる前の事業 : DA側が複数の現場と直接やり取りし、 定義確認を個別に進める必要が出てくる 人材紹介領域はbizops担当の方がいてスムーズだった一方、DR領域では 複数の現場と直接やり取りしながら同じ定義の議論を繰り返す ことになりました。 ② DA介入前にプロダクト開発が進んでしまう プロダクト駆動型の新規事業では、スピード重視で DAが合流する前に実装が固まる ことが起きやすく、後から計測設計を整える負担が大きくなります。 DRサービスでは、私が伴走を始めた時点で、 計測設計にDA観点を反映する場がない 状態でした。一気通貫のファネル分析のため、 計測設計の整理を提案する ところから始める必要があったのです。 新規事業の速度感を考えれば自然なこと。だからこそ DA側から早期に合流する関係性を作りに行く ことが重要だと痛感しました。 ③ DA側が組織横断の優先順位付けの場を提案できていない 立ち上げ期は、各担当者が自分の領域の進捗を重視するのは自然(むしろ健全)です。一方で、全体の優先順位を議論する場は用意されていないことも多く、 DA側から立ち上げないと、横断の判断軸を持って動くのが難しくなる と感じました。 私も最初の数ヶ月は会議体を提案できず、 腰を据えるべきテーマに集中しきれない期間 を過ごしました。 Part 2: 時系列アクションリスト 新規事業にDAが入るとき、いつ何をやるべきか を時系列で整理します。各アクションに「なぜそう思ったか」のエピソードを添えました。 🔵 Day 0: アサイン前の意思決定 アクション 内容と効くポイント 🧗 DAをディープダイブ(兼務させない) 新規事業は定義変更・指標追加が高頻度で、半コミットでは事業理解が追いつかない。 特にリードアナリストは他案件と兼務させない ことが、後の伴走の質を大きく左右する 💡 最初からディープダイブ前提でアサインされたことが、信頼関係構築 → 中長期伴走パートナー化につながりました。 🟢 Week 1-4: 関係性構築・PJ立ち上げ 🎯 特に効いた3つ : 関係者ヒアリング / 要望窓口の確認 / ログ設計レビュー合流(プロダクト駆動型) アクション 内容と効くポイント 📋 関係者ヒアリング 事業責任者・GM・現場メンバーに事業の目的・課題・関心事をひとりひとり丁寧に聞く。 この時間投資が後の伴走の土台 になるため、急ぎたい気持ちを抑えても話を聴く価値がある 💬 依頼チャンネル合意 Slack・依頼フォーム等を事業側と合意して「どこに・どの形式で依頼を投げるか」を明確化。受け手のオペが回り、依頼の取りこぼしが減る 🔁 週次定例の継続参加 事業の解像度を大きく上げる手段。 ただし参加だけでは何も変わらない 。「この定例から何のアクションを生むか」を常に自問する姿勢が大事 🚪 要望窓口の確認/提案 集約役不在のままだとPart 1 ①の状況に陥りやすい。いない場合は、GMや事業部のミドルマネージャーに 集約役を担ってもらう依頼導線の設計 をDA側から提案 🔍 ログ設計レビュー合流 プロダクト仕様検討・ログ設計レビューの場にDAが入れるよう、 開発開始前から合流 しておく。これを逃すとPart 1 ②の罠にはまる 📚 ナレッジのGit管理 AIコーディングツール(Claude Code・Cursor・Devin等)が参照できる形でナレッジを蓄積。 分析の壁打ち・クエリ作成の工数が劇的に削減 されるため、アサイン初期の最優先投資 ⚠️ 前任期に「定例参加だけでアクションに繋がらない」時期がありました。 参加は手段、目的ではない 。 🟡 Month 1-3: 目先の困りごと解決期(信頼残高を貯める) 🎯 特に効いた3つ : 爆速対応+問い返しの両立 / 要件定義を向き合いと一緒に言語化 / 基盤整備のタイミング評価 アクション 内容と効くポイント ⚡ 爆速対応 + 「なぜ/必要性/定義」の問い返し 初動の爆速対応は信頼関係構築の重要戦略。「このDAは価値がある」と認識されると、後のポジション変更が楽になる。 ただし依頼対応に留まり続けると"依頼を捌く人"として固定 されるため、「なぜやるか/本当に必要か/定義は適切か」を毎回問い返す姿勢を早期から取り入れる。 信頼関係構築と「言うべきことを言う」は両立可能 ✏️ 要件定義は向き合いと一緒にテキスト化 ダッシュボードやレポート作成の依頼時、「どの目的で、どの観点で、なぜ見るのか」を 向き合いと一緒に書き残せるレベル で整理。これを省くと要件が固まる前に着手することになり、双方にとって手戻りが発生しやすい 🏗️ データ基盤整備のタイミングを常に評価 早すぎても空振り、遅すぎても移行コストが跳ね上がるのが基盤整備の難しさ。 スプシ主体のモニタリングが積み上がってから着手すると、現行オペとの二重管理で身動きが取りにくくなる 🎁 外注保守カット案件は中長期運用主体を確認 「外注の保守費用削減のためにDA側で巻き取る」相談は、一度立ち止まって 中長期の運用主体を一緒に確認したい 類の案件。自分が異動・退職したときの移管コストが高く、長期の保守タスクとして残り続けやすい。 特にdbt等が絡むものは要注意 💡 私はこの切り替えが遅れ、後から上流に意見を出し始めた際に向き合いとの期待値調整が必要になりました。 ⚠️ 整備のタイミングをDA側から提案しきれず、暫定的な参照・運用が一部残っています。 軽いうちに議論を持ち出す ことが重要。 🟠 Month 3-6: 中長期伴走パートナーへのギアチェンジ 🎯 特に効いた3つ : 事業責任者+GM+bizops週次MTG立ち上げ / OKR策定シンクロ / 能動的価値発揮へシフト アクション 内容と効くポイント 🗓️ 事業責任者+GM+bizops 週次MTG立ち上げ 組織全体で優先順位を棚卸しする会議体をDA側から提案して立ち上げると、 横断の判断軸を持って動けるようになる 。この会議体は、2事業目が入ったときの司令塔にもなる 🎯 OKR策定タイミングにシンクロ 期初のOKR策定に合流して、事業側と「何を課題と捉えるか」をすり合わせ。これをやると、その後の依頼について 目的を事前にすり合わせた状態 で動けるようになる 🔀 GM経由のコミュニケーションフロー 現場の複数メンバーからは似た観点の依頼がそれぞれ届くため、個別にすり合わせていると工数が膨らむ。 GM(またはbizops・集約役)経由のフローに整える と、定義の議論が一つの場に集約され、双方のコミュニケーションコストが抑えられる 🎤 能動的価値発揮へシフト 受け身で依頼を捌くフェーズから、 DA起点で価値を提案するフェーズ へ。例: 現場担当者(CA等)へのインタビュー設計で定性課題を抽出 / 事業責任者・GMが意思決定に使う経営ダッシュボードをDA起点で設計・提案 💡 ここからが 新規事業DAの本領発揮ゾーン 。事業の意思決定に直接関われるようになり、 自分の分析・提案が事業の方向づけにつながる手触り感 を強く感じられます。 🔴 2事業目が追加されるタイミング 🎯 特に効いた3つ : 熱量シグナル検知→能動介入 / ログ設計レビュー最優先 / 要望窓口の最初からの設計 アクション 内容と効くポイント 🌡️ 熱量シグナル検知 → 能動介入 新しい領域が熱を帯びる瞬間(目標変更・予算変更等)を DAが能動的にキャッチして動く ことが重要。待っていると後手に回り、Part 1 ②の罠(介入前に実装が固まる)にはまる 🔍 ログ設計レビューを最優先 プロダクト駆動型事業なら必須。 Part 1 ②を2度繰り返さない ためにも、最初期から計測設計のレビューに入る関係性を作りに行く 🚪 要望窓口の体制を最初から設計 1事業目の学び(GM経由フロー)を即座に転用。人材紹介領域で「GM経由フロー」が効くと学んだので、DR領域では 初期から意識的にGM経由フローを設計 した 🗓️ 横断の優先順位会議体を再設計 2つ目以降の事業が入るタイミングを 会議体再設計のトリガー にする。1事業目向けの会議体を拡張して、横断優先順位を扱える形に変えていく 💡 DR領域で目標が跳ね上がる動きを検知し、自分から事業責任者+PdMに働きかけて週次定例への参加を勝ち取りました。 これがなければ今の伴走体制は立ち上がっていません 。 Part 3: 全体を貫く2つの原則 これまでの話は 2つの原則 に集約できます。 原則① 未来を見据えた動きをせよ 「今が楽に回るから」で意思決定しない。 半年後のオペレーション・組織・関係性を想像して、初動で先手を打ちます。 データ基盤整備のタイミングを早めに見定める 初期から事業責任者との接点を作る KPIや優先順位の構造を、組織が大きくなる前に整理する 「目先の困りごと解決 → 中長期伴走パートナー」の移行を意図的にデザインする 新規事業は成長スピードが速く、 "今困っていないこと"が半年後に大きなコスト として返ってくることが頻繁に起きます。 原則② 統制構造(要望窓口)を早期に組め 現場にbizops相当の集約役がいるかで、新規事業DAの難易度は桁違いに変わります。 いなければDA側から「誰が集約役を担うか」を提案するのが、DAの重要な仕事です。 統制構造が組めると、依頼フロー・優先順位付け・コミュニケーション工数の すべてが好転 。逆にここが組めないと、どんなに優秀なDAでも個別対応だけで手が回りきらなくなります。 おわりに 落とし穴を中心に書きましたが、新規事業のDA伴走は半年経った今、 自分のキャリアで最も学びと手触り感のあるフェーズ だと感じています。「新規事業DA、ちょっと面白そう」と感じてもらえたら本望です。 最後に改めて、本記事の失敗エピソードはすべて、 私自身(DA)の動きで改善できる余地について書いたもの であり、事業側の皆さんを批判する意図はありません。 急成長する新規事業の中で常に最善を尽くしてくださっているCareer Plus部の皆さんと、前任のDA・bizopsの方々に深く感謝 しています。 この役回りに関する再現可能なノウハウはまだ少ない領域です。 多くのDAが同じ試行錯誤を繰り返している 現状が変わるきっかけになれば嬉しいです。 最後に、タイミーでは一緒に働くメンバーを募集してます！ご興味があればぜひお話しましょう！ プロダクト採用サイトTOP カジュアル面談申込は こちら

みなさんこんにちは！ワンキャリアのプロダクト開発部 ワンキャリア転職チームの越川（X： @kosshii_ ）です。 突然ですが、みなさんは最近技術書を読んでいますか？