hacomono TECH BLOG

フィットネスクラブやスクールなどの顧客管理・予約・決済を行う、業界特化型SaaS「hacomono」を提供する会社のテックブログです!

プラットフォーム部のこれまでを元VPoPEと雑談してみた


こんにちは。プラットフォーム部所属のまこたすです。このテックブログは各部の当番制で執筆していますが、プラットフォーム部の回はこれが最後になります。7月から組織編成があり、プラットフォーム部という部が再編成されるためです。

私はこの部に初期から参画してきました。最後に「プラットフォーム部のこれまで」を、立ち上げ初期から牽引されてきた やじさん(基盤本部 元VPoPE) と当時のOKRや議事録を見返しながら、対談(というか雑談)形式で振り返ってみます。約4年分の試行錯誤の記録です。

聞き手(=私)まこたす:2022年8月入社。開発基盤部〜現在のプラットフォーム部に在籍。本記事の書き手であり、今回の聞き手です。

話し手やじ:基盤本部 元VPoPE(VP of Platform Engineering)。プラットフォーム立ち上げ初期からのメンバー。

VPoPEとは https://note.hacomono.jp/n/nf62210bfced5


プラットフォーム部の構成

現在のプラットフォーム部は、次の4つのグループで構成されています。

プラットフォーム部
├─ hacomono基盤グループ
├─ 共通基盤グループ
├─ データ基盤グループ
└─ FitFits基盤グループ

この対談で主に振り返るのは、「hacomono基盤 / 共通基盤グループ」とその前身にあたる旧プラットフォーム部の範囲です。

組織規模の推移

本編に入る前に、簡易年表をおいておきます。

時期 人数
2022年8月(開発基盤部) 5人(正社員4・業務委託1)
2023年7月(部発足 - 11期) 3人(正社員2・業務委託1)
2024年1月(11期下期) 4人(正社員3・業務委託1)
2024年7月(12期) 5人(正社員5)
2025年7月(13期) 6人(正社員6)
2026年1月(今期) 8人(正社員8・うち育休2)

部としては3名から始まり、最終的に正社員8名規模になりました。


第1章 基盤っぽい人があつまる「開発基盤部」から始まった

2022年8月(まこたす入社〜)

この期の体制:開発基盤部 5人

まこたす:そもそもプラットフォームって、いつからあったんでしょう?

やじ:「プラットフォーム」って言葉が使われ出したのはわりと最近かと思ってたんですよ。でも調べたら2021年後半くらいから出ていました。まこたすが入社する一年前からありました。

まこたす:当時は「開発基盤部」という名称で、コードネームが“プラットフォーム”だったんですよね。私が入社したのが2022年8月で、その時の所属が開発基盤部でした。インフラ保守の人、フロント/バックの共通モジュールを整備する人、中長期アーキを検討する人……と、ある意味ごった煮の部でしたね。

そのなかで私が最初に任されたのが、「組織規模拡大に向けてマイクロサービス化を進めたいからなんとかしてくれ」というオーダーで。モジュラーモノリス構想を進めていました。

https://techblog.hacomono.jp/entry/2023/08/22/110000

https://techblog.hacomono.jp/entry/2025/08/15/110000

やじ:当時のOKRを見ると、こんな目標を掲げていました。

KR1: SLOとして主要機能の稼働率 99.5% 達成
KR2: メンバーが開発時間として週30時間確保できる
KR3: hacomono開発合算で1日1デプロイできる仕組みをつくる

早期から「開発に集中できる環境」「早く開発して価値を届ける」を意識し、その延長線上で設定したOKRでした。


第2章 大きな障害が教えてくれた「説明責任」

2023年前半、大きな障害が起きる

この期の体制:開発基盤部のまま(5人体制)

まこたす:2023年前半は順調とはいきませんでしたね。当時のOKR振り返りを見ると大きな障害が起きていて、暫定対応・恒久対応に追われてOKRが進まなかった、という記録が残っています。当時はデプロイフローも特に決まっておらず、一人で動作確認してデプロイし、証跡を残すフローもありませんでした。それが障害のきっかけになって、お客様にも多大なご迷惑をおかけしてしまいました。

事業の成長で社会的責任の割合も大きくなってきたので、「価値を届ける早さ」より「安定性」を一層追うべきだ、という流れになりました。具体的には、

  • 監視体制の強化:手薄な時間帯は外部委託先に監視に入ってもらう
  • 手順チェックの強化:リリースはダブルチェック必須・証跡を残す・リリース前のレビュー&承認
  • 切り戻し対応の強化:feature-flags を導入し、問題機能を即時切り戻し

OKRを意識して動くというより、起きた障害を二度と起こさない/起きても軽減する、という対応をタスクフォース的に進めていた時代でした。

まこたす:やじさんは、この時期をどう振り返ってますか?

やじ:あの時は、「我々の説明責任をちゃんと果たさなきゃいけない」ってことを痛感したタイミングだったかもしれません。障害を防ぐのもあるんですけど、何が起きたのかをちゃんと話せるよう準備しておくことも大事で、これからも永続的に必要なんだろうなと思います。やっと会社としてエンタープライズレイヤーに踏み込んだタイミングに見えるかもしれないですね。

まこたす:これをきっかけに、会社全体としても「安全性に振り切ってやっていくぞ」という空気になった気がします。


第3章 3人で10個のKR ── プラットフォーム部、発足

2023年7月、開発基盤部が3チームに分かれた

この期の体制:3人(正社員2・業務委託1)

まこたす:そして2023年7月、組織が分かれました。メンバーも責務も増えて、「分割した方が動きやすいよね」と。開発基盤部が SRE部・プラットフォーム部・イネーブリング部 の3チームに分かれました。今のhacomono基盤・共通基盤グループの前身がこのプラットフォーム部です。各チームの期待値は、議事録だとこう書いてありました。

■ プラットフォーム
- 開発チームが利用できる共通基盤の提供
- モジュラーモノリス → マイクロサービス
- 決済 / 認証認可 / データ / ログ / AI・ML 基盤
- SRE・セキュリティ向け社内サービス(Prometheus×Grafana / Haconiwa)
- ドキュメンテーション

■ SRE
- 運用の自走化(Elastic DevOps)
- クラウドコスト見える化・改善 / 監査・認証・セキュリティ担保

■ イネーブリング
- 開発チームとの伴走 / テックリードを量産
- 社内プロダクト創出(大きくなったらプラットフォームへ移管)
- 外部露出を出せる開発組織へ

プラットフォーム部は メンバー3人(正社員2名・業務委託1名) から始まりました。2023年2月ごろに新インフラ「マルチテナントインフラ」が誕生していて、その運用を業務委託の方から引き継ぐミッションもありました。当時の実際のKRはこれです。

※%はKRの達成率
KR1: 既存の決済サービスのシステム分離           → 55%
KR2: データ分析基盤のための仕組みが動いている    → 77%
KR3: マルチテナント環境の優先度高チケット13件対応 → 100%
KR4: モジュラーモノリスを開発チームが能動的に    → 100%
KR5: バッチの非同期化推進                       → 0%
KR6: 管理サイトのコンテナ化(方式決定+検証)    → 70%
KR7〜KR10: やらなかったものがちらほら            → 0%

やじ:……KRを3名で、10個。もうひどいですね。このメンバーでこんなに掲げちゃいけなかったですね。

まこたす:(笑)。 マルチテナント引き継ぎ系とモジュラーモノリスは進んだのですが、その他はあまり進みませんでした。当時の振り返りで進まなかった要因は以下と書いていました。

  • 人数に対してKRが多すぎる
  • 仕様・目標の確定遅れ。具体がつまらないままKRを積んでしまった
  • マルチテナントが新規インフラで構成が複雑。理解が進まないうえ差し込みも多い
  • データ基盤プロダクトの保守運用も差し込みで入ってきた

やじ:今見るとKRの数がどう見ても多いよなって思うのに、当時思わなかったのが不思議です。今見たら絶対こんなにコミットできないからやれないですよね、って。

まこたす:ストレッチ目標とはいえ、3倍くらいに背伸びしすぎですね。差し込みがとにかく多かったので、それがなかったら終わっていたのかもしれません。それくらい「差し込みがずっと続く」気配を、この期から感じ始めていました。


第4章 背伸びをやめ、引き継ぎに向き合う

11期下期(2024年1月〜6月)

この期の体制:4人(正社員3・業務委託1)

まこたす:この時期は正社員が1名増えて、正社員3名・業務委託1名に。ただマルチテナントを牽引していた業務委託の方が退任されることになって、「急いで引き継がないとまずい」という時期でした。前期の反省を活かしてKRは4つに絞りました。

KR1: リアーキテクチャ3つ完了                          → 🟢 70%以上
KR2: SOD(スケーラブル/ディベロッパー/オーガナイゼーション) → 🔴 0〜19%
KR3: マルチテナント完成                               → 🔴 0〜19%
KR以外                                               → 🟢 70%以上

ラベルだと抽象的でよくわからないですが、中身をみるとKR1向け新規プロダクト3件、KR2向け4件、KR3も3件……と中規模開発が大量にありました。前期から成長していないようにもみえます。成長した点は、運用負荷を下げるべくメンバー全員で定期勉強会をやって、引き継ぎが無事できたことです。自チームで閉じた開発/運用は進捗が良かったんですが、他チームを巻き込む横断事例はうまくいきませんでした。

まこたす:この期のいちばんの学びってなんでしたかね。

やじ:たぶん一番の学びは、「作る人」と「運用する人」が分かれている構造そのものがしんどい、ということですね。当時は開発を業務委託の方にお願いしていて、その方々は力のあるメンバーで、開発自体はしっかり前に進めてくれていました。難しさはそこではなくて、引き継ぎ先のチームがないまま開発だけが進むと、できあがったものをプラットフォーム部が受け取り、設計意図のキャッチアップから運用までを引き取ることになります。その受け入れコストが大きかったんです。

まこたす:受け入れは自分が担当していましたが、ドメインのキャッチアップと運用を丸ごと持つ形になって、かなり大変でした。ただこれは委託の方の問題ではなく、「本来は内製で持つべきものを外に切り出してしまった」という、発注側=我々の体制設計の問題でしたね。社員でも委託でも、退任すれば知識はどうしても個人に紐づいたまま離れていきます。引き継ぎを前提に体制を組めていなかったことが反省点でした。

やじ:そうですね。逆に今うまく回っているのを見ると、作ったメンバーがそのまま運用しています。“作る人が運用する” という形が、結局いちばん強かったんだなと思います。

まこたす:失敗から学べたのはよかったです。実際これ以降は、「自分たちで作って、自分たちで運用する」形に寄せていきました。


第5章 インフラV2始動と、品質が上がった日々

2024年7月、12期へ

この期の体制:5人(正社員5)

まこたす:2024年7月から、12期に入ります。この期は インフラV2計画 を始動した時期です。まだ現在のhacomono基盤と共通基盤に分かれておらず、プラットフォームとして一つの部でした。

まこたす:この時に取り組んでいたインフラV2について説明お願いします。

やじ:当時データベース移行のプロジェクトを何千件と進めていたのですが、一部データが大きなお客様に関しては移行が難しいことがわかりました。そこで「データベースはそのままに、アプリケーション層を変更できる仕組み」を作ろう、というプロジェクトを進めていました。それがインフラV2の簡単な概要です。あわせてこの期は以下も取り組んでいました。

  • ARM化の推進(前期からのコスト削減の続き)
  • 非基盤ジョブマネージャー開発(ECSのランタスクを減らしてコスト減)
  • ジョブマネージャーと feature-flags を寄せて利用率を向上
  • データ基盤の転送システム(ニアリアルタイム転送。データ基盤チームへ引き継ぎ)
  • シングルテナント環境を減らしてマルチテナントへ統合

やじ:ARM化をみると、そろそろ「収益を考えていこうぜ」ってなったフェーズですね。

まこたす:ですね。当時の成果は、振り返るとかなり良かったんですよ。

  • ARM化・コスト削減・マルチテナント移行が着実に進んだ
  • 毎週リリースしていたのに インシデント件数がほぼ0件
  • シングルテナント環境を大幅に削減。インスタンス数が半分近くに、EC2まわりの故障も減ってサービスレベルが向上

やじ:電話が鳴る数が減ってった時代かもしれないですね。EC2の故障が減って、品質がだいぶ上がってった時期でした。

まこたす:これを5人くらいのメンバーで回していました。あの障害をきっかけに「手順書を作って検証してから出す」をやっていたから、障害も少なくなっていったのかもしれません。


第6章 2グループ分割、そして大きな障害

2025年7月、13期上期 ── 2グループに分割

この期の体制:6人(正社員6・2グループ合計)

まこたす:2025年7月の13期で、プラットフォームが hacomono基盤グループ と 共通基盤グループ に分かれて、それぞれミッションを立てました。

[hacomono基盤グループ]

  • インフラV2のサービスイン
  • SLO 99.5% の達成(3年ぶりの再掲)
  • AI実行基盤の構築 /(+α)開発生産性の向上

[共通基盤グループ]

  • マルチプロダクト基盤の構築(EKS)
  • プラットフォーム運用の効率化 / AI の活用・貢献

やじ:AI全盛期でしたから、各グループにAIの目標を入れていこうぜ、っていう流れがあった頃ですね。

まこたす:この時期の目標に対する結果は、正直に言うと厳しいものでした。大きなパフォーマンス系の障害が並行して起きてしまいましたね。

やじ:ですね。そこでインフラV2のような新しいアーキテクチャを安全に適用するのが難しいんじゃないか、ってことでプロジェクトを止めよう、っていう話になりました。この障害は、部署横断でさまざまな形で協力してもらいながら、2ヶ月以上改善に取り組んでいました。

まこたす:以降は新アーキテクチャの受け入れ条件がより厳しくなりましたね。今回の障害点になってしまったのはServerlessなDBのスケール速度が、弊社のサービス特性にあわないところに起因していたかとおもいます。サポートに確認していただいて内部のスケールの仕様を教えてもらい、ボトルネックがわかった感じだったと記憶しています。

やじ:クラウドは聞かないと分からない部分もあって、受けてる恩恵が大きいぶん仕方ない部分もあります。一気にスケールする魔法はさすがにありません。見えてる範囲じゃないところでもスケーリングする部分があって、我々で調整できないところもありますね。

まこたす:今回のhacomono基盤の目標を振り返るとインフラV2のサービスインは一旦休止。SLO 99.5%の未達。障害に引っ張られる形になりました。一方で、成果もありました。

  • AIハブ基盤:プロダクト初のAI製品を、POCですが一部のお客様に使っていただく実績ができた
  • マルチプロダクト基盤が誕生:社内ではじめてのEKSマルチプロダクト基盤を稼働できるレベルまで開発

まこたす:マルチプロダクト基盤(EKS)は会社としても初めての挑戦でしたね。当時をどう振り返りますか?

やじ:マルチプロダクト基盤(EKS)は、この時点ではまだ準備しておかなきゃいけないけど、やらないと進まないからやっていこう、って感じでしたね。今のhacomonoが掲げているマルチプロダクト戦略の状況を考えると、進めておいてよかったと思います。投資のような部分もあり、勝率五分でしたが、未来にアラインできてよかったなと思います(苦笑)


第7章 守りを固めて、やりきった現在地

今期(2026年1月〜6月・13期下期)

この期の体制:8人(正社員8・うち育休2)

まこたす:そして今期。育休でメンバーが2名減、期の途中で新入社員が2名という状況で、hacomono基盤/共通基盤グループが手を取り合ってやっていく体制になりました。

主要なKRの進捗は、期中のスナップショットでこんな感じです(🟢 順調・達成/🟡 道半ば/🔴 これから)。

主要な成果(KR) 進捗
マルチテナント移行 🟢 達成
hacomaru 本番稼働・開発者体験の最適化 🟢 順調
シングル刷新(旧: EC2削減・リアーキ) 🟢 順調
RDSアップデート 🟢 順調
Platform AI基盤の創出 🟡 道半ば
hacomono AI基盤の機能拡充 🟢 順調

やじ:まだ期中ですが、戦力不足のなかではかなりやりきれた印象を持っています。プラットフォーム部内のデータ基盤グループの体制がガラッと変わるなかでなんとか乗り越えましたし、マルチプロダクト基盤もうまくスタートできたのが良かったです。KRを見返すとだいぶ守り的な成果でしたが、やりきれたに近い気がします。

まこたす:育休で一時的にメンバーは減りましたが新入社員も入って増強され、進みも良くなりました。あと大きな障害が発生しなかったのが大きいですね。

やじ:障害が起こってしまうと復旧・再発防止でかなりの時間がかかります。障害があるかないかでKRに使える時間が全然違います。あと今期はAIがかなり活用されましたね。コードを読んでたらすごく時間がかかるものも、AIがgit履歴・リリースから探してくれます。最近では4年前のコードの原因特定もできます。利用者としてはかなり浸透してきた印象です。

まこたす:一方で「プロダクトとしてお客様に価値提供する」側面でのAI活用は、今期はあまり進んでませんね。ここは今後の課題ですね。

やじ:プラットフォームとしては、AIをまるごと提供するというより、モジュール/パッケージ的に、アプリ周りに必要な共通レイヤーを挟んで、プラットフォーム側の課金システムとして提供できると使いやすいだろうな、と考えています。


最終章 プラットフォーム部とは、何だったのか

2026年6月、再編成を前に

まこたす:質問します。VPoPEとして率いてきた立場から、「プラットフォーム部とは何だったのか」。やじさんの答えは?

やじ:プラットフォームは、組織におけるインフラ屋さんみたいなポジションでありつつ、会社で一番技術投資するところでもあります。その2軸を一つのチームがやっていた、っていうところが、大変さもあったけど責任感を持ってやれていたんじゃないでしょうか。POC側はやりっぱなしになりがち、インフラ側は何も改善できなくなりがち——そこを、本来のDevOpsとは違うけど、あるレイヤーではできていたのかなと思います。

まこたす:4年を通算しての戦績は、どうでしたか?

やじ:データ基盤は今うまくいっています。失敗は……モジュラーモノリス(組織にうまく浸透できなかった)と、インフラV2(休止)。この2つは負けましたね。一方で、マルチテナント化は、本来なら継続が困難だった事業を延命させるために有効だった、とも思います。途中の失敗も含めて、投資としてはうまくいっていると思います。

まこたす:マルチプロダクト基盤のことなども考えると、3勝2敗ぐらいってことですね。プラットフォーム部としては組織編成でなくなりますが、プラットフォームという概念はなくならないとおもいます。今後のhacomonoのプラットフォームについて考えていることがあれば教えてください。

やじ:プラットフォーム全体で見たら、一生いっぱいやることがある、って感じなのは変わらないかなと思います。また世の中の変化も会社の将来も、3年後どうなっているか予測できません。臨機応変に対応できる体制を作り続けながら、先読みで道具を用意していく——そういう動きが今後もできるといいなと考えています。

まこたす:最後に一言あればお願いします。

やじ:組織が立ち上がった時に思い描いていた絵——僕の中ではあれはスタートラインだと思ってたんですよ。目指していたことがゴールのように見えるけど、やっとスタートに立った、みたいな感覚です。ここまで乗り越えてこられたのは、巻き込まれながら一緒にやってくれた皆さんのおかげです。感謝ですね。


7月からプラットフォーム部は再編成されまた別の部に生まれ変わります。背伸びしすぎたOKRも、休止したプロジェクトもありました。それでも、マルチテナント化という事業継続の鍵を握り、品質を底上げし、マルチプロダクト基盤を作り——なんとかここまで乗り越えてこられました。

先はまだまだ一生ぶんくらいやることがありますが、少しずつ前進していると感じています。ここまで一緒に戦ってくださった皆さん、本当にありがとうございました。それでは、また別の形でお会いしましょう。