OpsNowでは、FinOpsを中心に製品とサービスを構築しています。しかし、私たちが提供するものについて説明する前に、「私たちはFinOpsの意味を本当に理解しているのか」という根本的な質問を自問する必要があります。
次のようなフレーズが聞こえます。 「FinOpsは不可欠です」、「必須です」、 そして 「それなしでは生きていけない」、これらは内部で頻繁に投げかけられます。しかし、「FinOps は本当に必要なのか？」と尋ねることから始めるのが適切かもしれません。
OpsNow のメンバーとしても、「クラウドのコストを削減するには OpsNow FinOps が本当に必要なのか」と自問してきました。正直なところ、私の答えは「いいえ」ですが、FinOpsは絶対に必要だとも思います。
矛盾しているように聞こえるかもしれませんが、その理由を理論ではなく経験に基づいて説明します。私はすべての答えを持っていると主張しているわけではありませんが、私をここに導いた考えや教訓をいくつか紹介したいと思います。
この投稿は個人的な経験に基づいています。これは絶対的な真実でも、万能の解決策でもありませんが、現実のものです。そして時々、実際の経験から、理論上の完璧さよりもさらに多くのことが明らかになることがあります。
2012年以来、私は韓国で最も有名な企業の1つでクラウドチームの開発と運営を率いてきました。このチームは、会社の将来の成長を促進するために設立されました。クラウドの世界に対する私の第一印象は、まるでユートピアのように感じられたということでした。
クラウドチームの開発と運用を統括する前は、カーネルシステムエンジニアとして働いていました。メモリの一バイト一バイトを奪い合い、パフォーマンスの向上を毎秒追求していました。私は見過ごされがちな、影の多い低レベル開発の世界で立ち往生していました。しかし、クラウドコンピューティングの世界に入ると、すべてが変わりました。メモリの問題が生じた場合、解決策は深く掘り下げて根本原因を解決することではなく、ただサーバーを追加することでした。パフォーマンスに問題があった場合は、単にスペックをアップグレードしただけです。まったく新しい世界に足を踏み入れたような気がしました。このような「楽園」に入る喜びを真に理解できるのは、低レベル開発の最前線で働いてきた人だけです。
私たちが最初にクラウドチームを立ち上げたとき、私自身を含め、誰もクラウドの経験があまりありませんでした。私たちは、他の場所でクラウドテクノロジーを扱ったことのある数人の新しいチームメンバーとともに、ゼロから始めました。私たちが一緒に成長するにつれて、チーム、組織、さらには会社全体も成長しました。私はいくつかのコスト効率化タスクフォースを率いて、生産性を高めるための社内ソリューションを導入し、最終的には会社の大幅な経費削減を支援したことを覚えています。
それらの経験を生かして、当時私たちがどのようにコスト最適化に取り組み、業務を合理化したか、そしてそれらの実践が現在「FinOps」と呼ばれるものとどのようにつながっているかを振り返りたいと思います。私たちの取り組みがクラウド支出の効率を高めただけでなく、チームや部門を超えた幅広いコラボレーションにどのように影響したかを探ります。
2011年から2013年の間、「FinOps」という用語すら存在しませんでした。クラウドに移行するにつれ、コストが大幅に上昇し始めたという変曲点に達しました。当時、クラウドは安価な代替手段として認識されていました。しかし、独自のモジュールを使用して大規模なインフラストラクチャを管理し始め、1 時間あたり数百万件のデータトランザクションを処理し、ペタバイト規模の環境で運用するようになると、クラウドはすぐに高価になりました。
そして、私たちはそれに疑問を呈しませんでした。私たちは単に「これが現実だ」と思っただけです。2015年頃まではその前提で運営していたと思います。
しかし、これらの高額なコストにつながったのは、単にクラウドに関する知識が不足していただけなのでしょうか。
実際には、開発と運用の両方を行いながら、数千万人のユーザーのファイル転送と画像配信を管理することは、大きな技術的課題でした。それには、大規模システムとデータ処理に関する深い専門知識が必要でした。当時、業界は急速にクラウドに移行していました。誰もがパフォーマンス、スケーラビリティ、可用性を試していました。お金が優先されるのではなく、スケーラビリティが優先されました。何を構築しているのか完全には理解していなくても、「とにかくやってみよう」という黄金時代でした。
そしてうまくいきました。正直なところ、まだ誰もクラウドを本当に理解していなかったからです。予算を管理するチームはインフラストラクチャーを完全には理解していませんでした。エンジニアは財務を完全には理解していませんでした。このギャップにより、経営幹部と財務チームの両方から承認を得ることが容易になりました。
マイクロサービスアーキテクチャの概念がなかったことを今でも覚えています。問題が発生したときには、サーバーを増やしたり、スペックを上げたりしていました。データベースがなぜ重要なのかよくわかりませんでした。時代は 「ある問題を別の問題でカバーする」
痛ましい教訓と運用上の成熟
当時はいろいろな経験をしてきました。大量のトラフィックを、次のような単純でナイーブな仮定で処理しようとしたことを覚えています。 「正しいクエリを実行すればいいんじゃないですか？」 私たちはしばしば、開発だけでどんな問題も解決できると信じていましたが、運用はほとんど無視していました。
最も忘れられない瞬間の1つは、大規模なサービス開始の直前でした。誰かが何の調整もせずにコード変更をプッシュしました。発売日になってもサービスは安定していませんでした。その結果は？3 日間続いた本格的な停電。このサービスは、誕生する前からほとんど機能しなくなっていました。
はい、コードの問題はすぐに修正されました。しかし、受信トラフィックのバックログが解消されるまで問題を引き起こし続けることに気づきませんでした。その時、私は重要な教訓を学びました。本当の運用スキルは、サービスをいつオフラインにし、いつ復旧させるべきかを知ることにあります。その電話をかけるのに丸3日かかりました。
振り返ってみると、それらの辛い経験が今日の私を形作りました。私はクラウドの「エキスパート」ではありませんが、堅実な実践者になりました。私は数え切れないほどのサービスを運営し、維持してきました。規模の拡大という名のもとで過剰支出をしてしまうのはいかに簡単か、そしてそれらの決定を承認するよう上層部を説得する方法を学びました。
2014年から、世界経済の不確実性などの要因により、「コスト削減」という包括的なテーマのもと、全社的なクラウドコスト削減の取り組みが本格的に始まりました。当時、主な目標は単に予算と比較してコストを 30% 削減することだったことを覚えています。これにより、より体系的なコスト削減活動が始まりました。
このようなコスト削減の取り組みの中で、クラウドの複雑なコスト構造がより明確になり始めました。これは、クラウドが従来の会計や財務の慣行とはまったく異なる原則のもとで運営されていたためです。会計や財務では通常、コストは年間予算内で管理されますが、クラウド環境では使用量がリアルタイムで変動するため、コストと予算を正確に予測することは困難です。クラウドの使用率とコストが急増していた時代には、この特徴から、サービス品質を確保するために過度に高い仕様を維持したり、コスト改善のための構造変更が困難なため、初期設計を最適化せずに運用を継続したりするという課題が繰り返し発生していました。
当時、経営幹部や財務部門はこれらの費用を「避けられない支出」、いわゆる「グレーゾーン」と呼び、避けられないものとして受け入れていました。漏れやすいバケツに水を注ぎ、実質的な見返りを得ずに絶えず支出しているような感じでした。財務部門は、すべてがうまくいくことを前提に予算を設定しますが、いったん支出が始まると、予想外のコストが発生し続けました。そのとき初めて、事態の深刻さが明らかになった。当時はまだこれらは「投資」だという認識が強く、クレームがあったとしても、ただ先に進んで受け入れるというのが一般的な姿勢でした。
そんな中、「緊急事態管理」というキーワードのもと、組織全体で徹底的なコスト削減を求める圧力が高まった。当時私はクラウドチームの一員でしたが、FinOpsという概念はまだ存在していませんでした。代わりに、経営革新とコスト削減という一般的な目標の下で、全体的に 30% の削減を実現するよう求められました。この目標を達成できないと経営幹部の KPI や評価に影響が及ぶことが明らかになったとき、圧力が高まり、組織はコストにさらに注意を払うようになりました。
コスト削減の取り組みの最初のステップは、現在の状況を評価することでした。まず、コストとリソースを管理する責任者がいるかどうか、またそれらのリソースがどのように使用されているかを特定することから始めました。部門間の関係は複雑だったため、この情報収集プロセスには数か月かかりました。当時、クラウドサービスプロバイダー (CSP) でさえ、コストやリソースの使用状況に関する詳細な情報をユーザーに明確に提供することができませんでした。
社内の能力には限界があることを認識し、外部評価にも取り組むことにしました。その結果、私たちは外部のクラウド管理プラットフォーム (CMP) の実装と、いくつかの類似ツールの概念実証 (POC) トライアル、および社内開発を開始しました。マッキンゼーやアクセンチュアなどのコンサルティング会社が参加し、300～400種類の指標を検討して包括的な評価を行いました。それは私たちが何百ものExcelファイルを配布し、その使用方法の詳細について部長に執拗に質問していた時期でした。振り返ってみると、これらのアクションにはまったくメリットがなかったわけではありませんが、特に問題のサービスを完全に理解していなかった場合は、会話が一方的に感じられることがよくありました。このアプローチは、診断部門と他の部門との格差も深めました。という気持ちがこもった時代でした。 「このサービスわかる？」 とても宙に浮いていた。
先に述べたように、コスト削減の取り組みの第一歩は、現状を理解することでした。組織内でクラウドを使用したことがある人なら誰でも、管理されていないクラウド環境ではコストの請求書を確認することしかできないため、詳細な洞察を得ることが難しく、大きな混乱を招くことを知っています。このような背景を踏まえて、私たちは最初のステップとしてこの情報を収集して整理することから始めました。
この過程で、「定着した利益」という概念が形成され始めました。状況をいち早く把握して経営幹部に報告した組織が、より大きな影響力を持つようになり、事実上「支配的」な地位を占めるようになりました。この構造がより確立されるにつれて、信頼が失われ、分断が深まることがありました。この展開を目の当たりにしたことは、当時非常に興味深い経験でした。
情報収集が完了すると、次の重要な質問に移りました。 「これらの費用を効果的に使っているか？」 理論的には、メモリ、I/O、CPUなどのリソースの使用状況を分析しました。使用率の低いリソースはすべて無駄とみなされ、効果的に削減または削除するための措置を講じました。しかし、当初の設計はクラウド運用に適切ではなかったため、サービスとそのドメインに関する知識を深く理解せずにリソースを削減すると、サービスが大幅に停止する可能性があります。特に、サービスの本質を十分に理解せずに設計に取り組むことが、予期せぬ問題を引き起こす主な原因となりました。前述のように、この問題はしばしば、ある問題が別の問題によって隠されてしまうという悪循環を引き起こしていました。
リソースを大幅に削減した後、サービスが停止し、部門長は予算管理チームに強く反対しました。「コストを削減すれば、こうしたサービス停止の責任を取れるだろうか？」というのがよくある質問で、頻繁に意見が対立していました。結局、組織は2つの選択肢のどちらかを選択せざるを得ませんでした。適切な妥協をしてコスト削減を行うか、抵抗に屈するかです。
そんな中、比較的成功していたサービスが中止になるという事件がありました。一方、コストが最も高かった別のサービスは、将来の投資価値とさまざまな利害関係者の利害関係により、削減できる領域が多数あるにもかかわらず、維持され続けました。このサービスは今日も順調に運営されていると理解しています。
2015年から2018年の間に、サービスに対する理解の欠如と利害関係者の複雑な利害関係により、コスト削減のアプローチは変化し始めました。これらはすべて「コスト」という言葉を中心としたものでした。これはあくまで私の個人的な意見ですが、この変化は 2 つのアプローチに分けることができると思います。
最初のアプローチは、クラウドサービスプロバイダー（CSP）と割引を交渉することでした。これは、これらの割引によって内部管理上の問題の一部を相殺するのに役立ちました。大企業が CSP に大きな収益をもたらしていたため、これは実行可能な戦略でした。
2 つ目のアプローチは、リザーブドインスタンス (RI) を通じて割引を適用することでした。これは貯蓄プラン (SP) が導入される前のことで、中央チームが RI を管理し、コスト削減策として各部門に分散していました。しかし、RI管理の複雑さと、給付対象から除外された部署の不満が大きな問題となりました。特に当初は、適切な専門知識がなく、RI の管理が不十分だったり、対象範囲が狭かったりすると、コストが爆発的に増加することがありました。この経験から、現在の FinOps プラクティスでは RI や SP などの項目を自動的に管理することが重要である理由が明らかになっています。
最終的に、コスト管理戦略は、マルチクラウドによるコスト配分とクラウドサービスプロバイダー（CSP）との交渉へと発展しました。このアプローチは今日のFinOps戦略と一致していますが、当時、クラウドとコスト管理における従業員の成熟度が不十分で、多くの苦情が寄せられていました。
さらに、新しいサービスを導入する際にAWSなどの大手CSPが提供するクレジット特典のおかげで、一部の組織はソリューションの切り替えを試みることもありました。この一連のイベントは、これまでに経験したことのないさまざまな新しいソリューションやマルチクラウド環境に出会い、技術的に成長する絶好の機会となりましたが、個人的な観点から見ると、最大の受益者はCSPだったと思います。その理由は、当時、実際に大規模なトラフィックとデータを運用している企業はほとんどなかったため、CSP にとっては実社会での経験を積む絶好の機会だったからです。こうした経験をもとに、CSPは急速な進歩を遂げました。
一方、クラウドサービスの利用とデータは増加し続け、さまざまなコスト削減の取り組みにもかかわらず、コスト上昇の現象が再び現れ始めました。最終的に、主要サービスを除き、MAU (月間アクティブユーザー数) が一定レベルを下回るか、収益貢献度が低いサービスのコスト削減圧力が高まりました。その結果、運用チームと開発チームは生き残るためにアーキテクチャとパフォーマンスの改善を集中的に検討するようになり、インフラストラクチャと開発の革新は限られた予算の制約の中で行われるようになりました。(業務も含まれていました)。
この時期から、ChatOpsの採用、EKSベースの高度な構造、Terraformの活用、外部SaaSソリューションの使用、サーバーレスアーキテクチャへの移行など、より高度なクラウドアーキテクチャへの本格的な移行を開始した組織もあります。パフォーマンスを確保しながらコストを削減しようとする取り組みは、文字通り「狂ったレベルの粘り強さ」でした。
それまでは、この組織はほとんどが数人の技術リーダーによって主導され、組織全体でクラウドの成熟度に大きなギャップがありました。しかし、この時期から、開発、運用、コスト管理の観点から、サービスオーナーの全体的な成熟度が急速に上昇し始めました。ダウンタイムゼロの運用、ユーザーからの苦情、新機能やソリューションの採用の失敗、運用上の失敗による深夜、財務チームからの要請など、絶え間ないプレッシャーの中、チームは生き残りを重視した真の戦略を策定し始めました。つまり、開発は運用重視のエンジニアリングへとシフトし始めたのです。
そして、私たちが前進し続けるうちに、私たちは資源と人的資源をいかに非効率的に使用していたかに自然に気づきました。その認識が、最終的に「無慈悲な自動化」と呼ばれるものへと私たちを導きました。これにより、自動化のための技術と運用の両方における本格的なイノベーションが始まりました。理由は単純でした。自動化しなければ、作業負荷は耐え難いものになり、最終的にはその重みで崩壊してしまうからです。
これらの苦労して得た経験は、生き残るためのより深い技術交流と、チーム間の冗談めかして「テックショーボート」と呼ばれるものにつながりました。それはやがて部門間の競争と圧力へと発展しました。チームは、「私たちの方がうまくやっている」、「より少ない人員で安定したサービスを運営している」、「より低いコストで運営している」などの主張で競争し始めました。
数年後、経営幹部の命令として、クラウドの大幅なコスト削減のための全社プロジェクトが開始されました。簡単に言えば、それは「支出が多すぎるからコストを削減する」という指令でした。これが本格的なFinOps活動の真の始まりとなりました。最初は圧倒されたように感じましたが、最適化、効率の向上、RI/SP の採用、EDP の交渉など、可能な限りの手段を講じました。
部署間の利害の対立によりイニシアチブが課題に直面したため、私たちは二面的な戦略を実施しました。まず、クラウドの専門家チームが結成され、各サービスのアーキテクチャを徹底的に見直しました。次に、財務チームは透明性の高いデータ収集を実現するために Finops のようなツールの使用を強制し始め、そのインサイトに基づいた診断作業を開始しました。
最初は、未使用のリソースを削除したり、適切なサイジング手法を適用したりするなど、一般的な方法で問題に取り組みました。これは典型的なFinOps手法です。しかし、組織のクラウドの成熟度が高まり、サービス品質に対する説明責任が高まるにつれ、これらの基本的なアプローチはやがて壁にぶつかりました。データがどれほど説得力があるように見えても、サービスに対する深い理解とオーナーシップを持つチームに直面した瞬間、コスト削減の圧力は勢いを失いました。
新しいアプローチが必要であることが明らかになりました。そこで、リソーススケジューリングとスポットインスタンス管理のための内部機能の開発を開始しました。これらの機能は、現在ほとんどのCSPが標準で提供している機能です。
これらのツールを検証するために、私たちは本質的に試験的なプロジェクトを立ち上げました。これは「犠牲の子羊」であり、物事がうまくいくかどうかをテストするためのベースラインデータの準備に3か月を費やしました。正直なところ、それがうまくいくかどうかは重要なポイントではありませんでした。私たちが本当に必要としていたのは、組織全体でFinOpsの採用を促進するための手段でした。短期間で堅実なソリューションを構築するために最善を尽くしましたが、ご存知の方も多いように、このような迅速な構築には下流での課題が伴うことが多く、安定させるには多大な忍耐が必要です。
それでも私たちは、カスタムビルドのスケジューリングシステムやスポットインスタンス管理機能 (当時の spot.inst のようなオープンソースツールから大幅に変更された) など、さまざまな最適化ツールを開発しました。その後、私たちのチームが社内で開発、運営しているプロジェクトで積極的にテストしました。3 か月にわたる徹底的な最適化の後、得られたデータを使用して他のチームにもツールを採用してもらいました。これはまた、サービスアーキテクチャの根本的な再設計と人員配置効率の評価にもつながりました。
これらの成功はFinOpsツールの功績を公に認めましたが、実際のコスト削減は、データ構造の変革、近代化の取り組み、労働力の再編など、より深いアーキテクチャの変更によってもたらされました。最終的に、この移行により、以前はクラウドサービス開発のみに注力していた私が、本格的な運用職に就くことになり、「攻撃者」の立場に移行するターニングポイントとなりました。
この経験から、組織全体を一度に移動する必要はないことに気づきました。その代わり、私たちはいくつかの主要チーム内で変化を推進することに重点を置きました。その成功事例をケーススタディとして、コスト削減の成果と予測モデルを上級管理職と財務チームに提示しました。次に、各部門長にコスト削減 KPI を割り当て、参加を効果的に義務付けました。診断チームは、クラウドサービスに関する深い専門知識の構築と技術的信頼性の確立に重点を置きました。この基盤をもとに、より上位の部署に合わせた戦略とツールを提供しました。このアプローチは、今日のFinOpsの核となる理念と密接に一致しています。
実際には、最も大幅なコスト削減は、FinOpsツール自体の使用によるものではなく、アーキテクチャの近代化や労働力の最適化など、それらのツールによって引き起こされたより広範な組織変更によるものです。私たちが直面した最も困難な課題の 1 つは、絶え間ない疑問でした。
「これはRI/SPよりも節約できるのか？」 そして 「このアプローチは、EDP割引よりも本当に効果的ですか？」
場合によっては、数字が実際には逆になり、従来の価格設定モデルと比較して悪い結果が見られました。しかし、本当に重要なのは現在ではなく、将来の構造変化によってもたらされる長期的なコスト削減でした。これが激しい議論につながり、賛同を求める激しい戦いが繰り広げられました。これらの変化の影響は徐々に明らかになってきました。
しかし、継続的な経営に裏付けられなければ、結果は簡単に崩壊する可能性があります。ワークロードを管理する適切なタイミングを逃すと、古い方法への回帰、技術的負債の蓄積、コストの不安定化につながる可能性があります。チームがそのような失敗を経験すると、不信感が引き継がれます。このような状況を経験した組織は、将来の FinOps イニシアチブ、特に外部から提案されるイニシアチブに強く反対する傾向があります。
ヨーヨーダイエットのようなものです。継続的な努力と規律がなければ、システムは回復します。これはFinOpsエコシステムにおける最も重要なポイントの1つです。
社内でどれだけうまくコストを管理していても、外部要因によって努力が意味をなさないことがよくあります。最も一般的な例としては、為替レートでしょう。
たとえば、2021年までに、効率の最適化と構造変更への取り組みにいくらかの見返りが見えてきました。しかし、通貨の変動などの要因により、こうした取り組みが希薄化されることもありました。
1か月あたり10億ウォンのコスト削減に成功した後、為替レートの上昇によりその節約分が逆転することがよくありました。その結果、コスト削減が実際に達成されたかどうかを疑問視する一方的な財務部門からのコミュニケーションが頻繁に発生することになります (このような状況では、レイオフという悪循環につながることがよくあります)。現在の世界経済の状況と韓国の為替レートの変動を考えると、同様のケースが再び見られるようになると思います。歴史は繰り返される傾向がある。
とにかく、これまでの話は過去の経験に基づいています。まとめると、それは常に指導部の危機感から始まり、それが圧力と説明責任を引き起こしているということです。組織が行動を起こさないと、KPI と予算の管理下で動き始めます。もちろん、自らをうまく管理している組織もあります。そのような場合は、外部のツールや方法を強制する必要はありませんでした。すでに素晴らしい仕事をしているので、その勢いを邪魔したり混乱させたりしないほうがよかったのです。
さらに、コスト分析、異常検出、推奨事項、リソース比較、マルチクラウド比較、パフォーマンス分析、ネットワーク診断などのさまざまな機能的手法が標準化され、問題に取り組む際の出発点として私たち全員に親しまれてきました。
それでは、過去の経験を踏まえて、実際にコスト削減がどのように行われているのかを見てみましょう。私たちはこのプロセスを本当に理解しているのでしょうか？ここから物語の始まりです。
前述のように、トリガーは常に存在します。それが経営陣によるものであろうと他の誰かによるものであろうと、誰かがコストとリソースの使用について懸念を表明します。運が良ければ、問題が指摘されたときにそれを正しく理解し、自発的に対応することができます。しかし、残念ながらほとんどの場合はそうではなく、人々は通常それを避けがちです。
その理由は明らかです。仕事が増え、批判される可能性があるからです。さらに、支出は簡単ですが、コスト削減は非常に難しいことは誰もが知っています。
したがって、このタスクは最終的に、実行する人、診断と分析を行う人、評価して決定する人の3つの基本的な柱を中心に展開します。これをさらに発展させると、FinOps Foundationが概説している現在のペルソナのように、役割はより詳細になります。
それでは、例を挙げましょう。
「今月の予算を 20% 削減しなければならないなら、まずクラウドのコストから始めましょう。」
このような指令が出たら、チームはまず何をしますか？
「過去 3 か月、6 か月、1 年間のクラウド支出データをすべて持ってきてください。」
通常、そこから始まります。実際にコストが増加したかどうかに関係なく、会話はデータから始まります。
この時点では、組織が単一のサービスを運営しているのか、複数の事業部門を運営しているのかによって、アプローチが異なります。
サービスが 1 つしかない組織の場合、最初のステップは、どのリソースが最もコストを消費しているかを分析することです。次に、「これを今すぐ実際に削減できるか」という疑問が浮かびます。
通常、データベースやネットワークの料金など、コストが高い領域は予測可能です。対策を講じるために、ほとんどのチームはまず未使用のリソースをチェックすることから始めます。しかし実際には、このアプローチによるコスト削減は、多くの場合、予想よりも小さいです。運が良ければ、管理されていない高価なリソースが見つかることもありますが、それは戦略というよりは運の問題です。
次はリストを生成する作業です。どのリソースを最新化できるか、つまり適切なサイズであるかを慎重に判断します。
「これを減らせば、いくらかコストを節約できたと言えるかもしれない」と考えてデータを掘り下げます。それを念頭に置いて準備を進めると、疑問が浮かび上がってきます。
「これではRI/SPのカバレッジが不足するのではないか？」
「EDPの条件を破り、不足分に見舞われたらどうなるでしょうか？」
「RI または SP はいつ期限切れになりますか?この変更を間に合うように行うことはできますか？」
このような懸念が持ち上がると、これまでの選択肢は難しすぎると感じ始めるので、プロダクション、開発など、使用しているすべてのアカウントを見直します。
順序は異なる場合がありますが、最終的にはすべてのアカウントが1つずつ審査されます。
アカウントがある程度整理されると、レポートは通常、誇らしげに次のようになります。
「このように削減を続ければ、効果的にコストを削減できます。」 これは通常の1次元のレポートです。しかし実際には、20% 以上削減するのは簡単ではありません。そして今、あなたは岐路に立っています。
「本当に不要なサービスを停止すべきか？」 または 「彼らに割り当てられた労働力を減らすべきか？」
しかし、いずれにしても、どちらの選択も簡単なものではありません。
そこで、開発と運用の両方の経験がある人は、ここで中心的な問題について考え始めるでしょう。
「これは収益と結びついているので、ROIの観点から、アーキテクチャや設計を再考すべきではないでしょうか？」
この時点で、開発と運用の構造的変化が始まります。この議論が行われなければ、最終的には「避けられないコスト支出」のグレーゾーンにとどまり、組織はその現状を維持し続けることになります。
__________________________________________________________________________________________________________________________________
複数のサービスを管理する組織の場合、フローは似ていますが、開始点は少し異なります。
ほとんどの組織は、次の質問から始めます。 「最も支出が多い組織はどれですか？」
このアプローチは、コストが最も高い組織とその管理責任者に直接つながります。たとえ高額な費用が正当化されたとしても、全体的な目標を達成するためには、比較的よく管理された組織が、最終的に削減されることもあります。
ほとんどの場合、リストの作成、リソースの整理、アカウントの確認など、前述のアプローチが採用されています。ただし、この場合でも、RI/SP 管理や特定の組織に対する好意といった運用上の違いが、チーム間の対立につながりやすくなります。実際、これらの問題はしばしば、責任が特定の人物に移る状況へとエスカレートします。
この時点で、組織はコスト配分構造の再評価を開始し、各部門の予算編成と配分の詳細について議論が始まります。もちろん、全員が不満を抱いているわけではありません。実際、一部の組織はこの変更を歓迎しているかもしれません。
____________________________________________________________________________________________________________________________________________________________________
しかし、開発と運用の両方の経験を積むと、根本的な疑問が生じます。これは収益に直接つながるため、ROIと、アーキテクチャや設計自体を根本的に削減する必要があるポイントがあるかどうかを検討することから始めます。この時点で、開発と運用の変化が始まります。そうでない場合は、「避けられないコスト支出」として残り、現在の状態が続き、長期的なグレーゾーンへと発展する可能性があります。
一方で、「やむを得ない経費支出」という口実のもと、そのような配慮をせずにそのまま現状を維持するだけでは、ますます根強いグレーゾーンに入り、問題はさらに複雑になるだけです。
____________________________________________________________________________________________________________________________________________________________________
上記のシナリオは、おそらく誰もが少なくとも一度は経験したことがあるものです。
変更を実施する部署は、物事を隠そうとしたり、頑張ったりするかもしれませんが、受け取り側は数字だけを見ることになります。彼らは努力を気にしません。数字が目標を達成するかどうかがすべてです。
この時点で、組織内に不調和が生じ始めます。
万全の努力にもかかわらず、数値のみに基づいて意思決定を行う場合、2つの選択肢になります。将来のコスト削減を見越して数値を膨らませるか、現在の状態を維持する方法を考え出すかです。
この時点で、組織は現在の状況に合わせてリソースとコストの分析を調整し始めます。
この例からわかるように、FinOpsはコスト削減だけではありません。むしろ、まずは、物事がうまく行っているか、適切なレベルの効率で運営されているかを評価することから始まります。目標は、現状を把握し、関係部署を納得させることです。このプロセスは、メビウスの帯状の連続したループのようなものです。
さて、絶え間ない疑問は、「適切な規模」、「未使用リソース」、「近代化」などのデータを使って、どの程度コストをかけているかを本当に評価できるかということです。
答えは「はい」です。
ただし、実行中のサービスにこれをすぐに適用できるかどうか尋ねられた場合、答えは「いいえ」です。これは、運用やサービスを担当していない部署にとっては話しやすい話題であることが多いです。
サービス業務は非常に保守的であり、業務で発生する問題には常に「責任」という重い言葉が伴います。単により多くのお金を使うほうが簡単だと感じることがよくあります。その結果、インフラの拡張によってコストが高くなるケースもあります。
このサイクルは繰り返されます。これを回避するには、サービス業務に影響を与えずにコストを節約するために、EDPやRI&SPなどを事前に購入するしかありません。さらに高度なシナリオでは、未使用のサーバーを営業時間外にシャットダウンするようにスケジュールしたり、スポットインスタンスのような安価なリソースに切り替えたりするなどの選択肢も検討されます。
ただし、これは依然としてサービス業務に関連する責任によって制約されています。もちろん、より成熟した組織では、これらの側面を自動化して、人々がより戦略的なタスクに集中できるようにすることができます。
次のアプローチは責任の割り当てです。コントロールであろうと投資であろうと、責任を担当部門に委任することが課題です。なぜ？それが一番簡単な方法だからです。「できないなら責任を取れ」と言うことほど便利なことはありません。じゃあ、どうやってやるの？Excel を使用して各リソースを 1 つずつ確認し、文書化して整理することができます。これは、リソースや組織が小さい場合に実行可能です。
これをうまく管理するために、すべてを明確に分類して管理するためのタグが導入されています。こうすることで、どの組織がリソースを効果的に使用しているかを分析しやすくなり、膨大な量のデータとはっきり区別できるようになります。
しかし、これがコスト削減に直接つながるかどうか尋ねると、答えは「はい」と「いいえ」の両方です。結局のところ、どのような行動をとるにしても、すべての行動には人間の関与が必要であり、個人がもはや責任がないと感じると、その努力は途中で放棄されることがよくあります。そこで、組織は KPI を結び付け、ミッションや予算管理と連携させるようになりました。適切な管理を行わなければ、これらのイニシアチブは無意味なものになりかねません。そのため、多くの組織は測定可能な成果に結び付けることに重点を置いています。
失敗につながるケースをたくさん見てきたので、焦点は組織内のパフォーマンスに移ります。そのような状況では、いかにコストを削減するかについて社内の議論が始まります。どうすれば最小限のコストでサービスを提供できるのか？運用管理を効率化するにはどうすればよいか？
そのためには、サービスに対する理解と、利用している資源がどれだけ高価であるかを認識することが必要であり、それが最終的に単位経済につながります。
そして、ある時点で、人間の効率性に関する議論が浮かび上がってきます。最終的には、誰かが責任を持って行動しなければなりません。しかし、責任を取るだけでは円滑な運営は保証されません。その人の権限や意欲によって、結果は異なります。さらに、これらの取り組みは短期的な場合もあれば、結果が出るまでに長い時間がかかる場合もあります。
ただし、組織文化が確立される前に組織的に動くことは難しいため、責任を分散させようとする傾向があります。ポジティブな見方をすれば、人は戦いたくないとき、「一緒に働いて協力しよう」と言う。しかし、ライバルになると、言い訳をするようになります。
これが、最近のFinOpsフレームワークがテクノロジーベースから企業の業績指標に焦点を当てるものへと移行している理由だと思います。
また、財務を担当する部門にとって、このデータと作業プロセスの信頼性を理解することは非常に重要です。予算計画と予測に基づいて、どの程度支出がうまく行われているかを組織に説得することがますます重要になっています。このデータの信頼性にもよりますが、各部署の自主性が高まる可能性があります。さらに、このプロセスが発展するにつれて、共通のミッションと実行を共有する部門間のコミュニケーションが最も重要な側面となるでしょう。
「うまく使うには理解する必要がある」ということわざがあります。サービスを開発、運用、管理する部門こそが、サービスを最もよく理解している部署です。先に述べたように、FinOps Foundationのフレームワークの最近の変化はこれを反映していると思います。つまり、あまり詳しくないと、なぜ何かがよく使われているのか理解できないということです。かつて「コスト」という言葉が出てきた時、財務的な観点からは経費削減の余地がありました。しかし、今日では、サービスを管理および開発するチームがそれを最も理解する必要がある主な理由の 1 つが、この点です。
つまり、FinOpsの前提の下では、さまざまな部門が表面的に廃棄物を特定して改善していますが、最終的には、ROIの観点からリソースをより効果的に使用するために、これを理解して改善する必要があります。この文脈では、FinOpsツールは、時間、労力、複数のユーザーを結びつける、共通の言葉でコミュニケーションするための基本的な手段だと思います。
支出額だけを見る人もいれば、専門用語のみに注目する人もいれば、KPIの達成数値だけに関心を持つ人もいます。しかし、これらの目標を達成するために使われる基本データはすべて同じです。それが何であれ、サービスの支払いは変わっておらず、これらのサービスの費用を計算するロジックも同じです。
OpsNowのように、FinOpsのツールにはそれぞれ異なる機能がありますが、これらの機能は1つの目的のために作成されたものと見なすべきではありません。その代わり、それらは統一された言語を提供する手段として機能する統合システムの一部です。これらのツールの機能の使い勝手は大きく異なり、生成されるレポートは各部門が追跡しようとしている内容によって異なる場合がありますが、最終的な目標は変わりません。それは、組織がリソースを効果的に使用しているか、改善の余地があるかどうかを組織が評価できるようにすることです。さまざまな観点から見ると、データはさまざまな方法で解釈される可能性がありますが、結局のところ、データはまとまりのあるストーリーを伝える必要があります。重要なのは、私たちがリソースを適切に使用していること、そして最も重要なのは、私たちが同じ言語を話していることについて、全員が同意していることを確認することです。
そのため、OpsNowは現在、組織のFinOpsの理解と導入を支援できる立場にあります。ツールの選択は二の次です。重要なのは FinOps の概念がどれだけ正確に理解されているかということです。FinOps を成功裏に導入するには、まず、組織が FinOps の原則をどの程度理解しているかを評価することが重要です。そうして初めて、このプロセスを促進する手段として何らかのツールを導入すべきです。
先ほどの個人的な例でも触れましたが、FinOps理論を知らなくても試してみました。その過程で数え切れないほどの失敗や成功を経験しましたが、今は「FinOps」という言葉で表現しています。ほとんどの組織にとっての問題は、理論的な知識の欠如ではなく、社内の経験、課題に取り組む意志、運用上の洞察、各サービスの中核に対する理解、チームの連携方法についての深い考察の欠如です。Google では理論はよく整理されていますが、理論を知って理解しているふりをするだけでは限界があります。
幸いなことに、OpsNowは、MSPの親会社であるBespin Globalを通じて遭遇した豊富な運用経験と顧客の要求に基づいて成長してきました。この基盤を土台に、OpsNowはFinOpsの分野で統一された声で話すことを目標に、進化を続けています。まだ長い道のりがありますが、プラットフォームは実社会での経験という貴重な資産のもと、サービスを着実に進化させています。
ただし、FinOpsの取り組みを社内で管理している人にとっては、特にコスト管理と効率が危機に瀕している場合には、FinOpsで働く人々のうち何人が開発に真に関与しているかを調べることが不可欠です。物事は順調に進んでいると言うのは簡単ですが、その経験を本当に経験した人と経験していない人の間には明らかなギャップがあります。
これまで、OpsNowのクラウドコスト削減の取り組みは、主に製品の機能を紹介することに重点を置いていました。しかし現在では、より深いものへと進化しつつあります。つまり、各機能の背後にある必要性と背景を明確に伝え、組織が信頼できるデータに基づいて有意義な行動を取れるようにするストーリーを構築するプロセスです。以前は機能主導型のソリューションでしたが、今では組織全体で共通の言語を話す統合サービスになりつつあります。理解と明確なコミュニケーションが技術的能力と同じくらい重要になる方向に向かっています。
私たちは岐路に立っています。そこで、効果的なクラウド分析、コスト管理、そして組織内の有意義な節約を可能にする環境を本当に構築したかどうかを自問することが重要です。製品やサービスを提供する観点からは、この分野に関する深い理解と実務経験が不可欠です。OpsNow FinOpsは、単に機能を紹介するだけではありません。FinOpsを十分に理解し、実践し、継続的に評価し、組織をその道のりに導くことが大切です。
FinOpsの基本的な出発点は、管理されていないクラウドコストを理解して管理することです。多くの組織は、コスト削減を最大化することを期待してFinOpsを採用していますが、実際には、FinOpsは中核的な必需品というよりはオプションのツールとして扱われることが多いです。実のところ、ほとんどの企業はすでにさまざまな方法でコスト削減策を実施しています。私たちが行っていることは、特にユニークでも例外的でもないかもしれません。
コスト削減にはさまざまな方法があります。クラウドサービスプロバイダー (EDP) との大規模な割引交渉、リザーブドインスタンス (RI) または貯蓄プラン (SP) の活用、リソースの最適化と効率改善の実施はすべて基本的なアプローチであり、これらはすべて FinOps ツールがなくても実行できます。場合によっては、単純に手作業に置き換えることもできます。しかし、これらのプロセスは、時間と労力、そしてビジネスドメインとサービスに対する深い理解によって支えられれば、はるかに効果的になります。組織に適切な能力があれば、サービス構造を再構築し、パフォーマンスを最適化することで、コスト効率と運用全体の両方を根本的に改善できます。
では、なぜFinOpsの理念が必要なのか、そしてOpsNowのようなツールが不可欠なのはなぜでしょうか。この質問には根本的な反省が必要です。クラウド環境がより複雑になり、組織の規模が拡大するにつれて、コスト管理はますます困難になります。多くの場合、責任が不明確になり、クラウドの利用が軽視されてしまうことがあります。クラウドのコストという性質上、問題は状況が悪化して初めて発見されることが多く、修正には多大な時間と労力が必要になります。FinOps が効果的に機能するためには一貫した取り組みが不可欠であり、それこそが FinOps がそもそも必要な理由です。FinOps は、そのような継続的な規律を始めるための基盤となります。
FinOpsでは、コストとリソースを定期的に監視できるため、問題の早期発見とリスクの最小化が可能になります。これは資源効率とコスト最適化への第一歩です。このプロセスでは、コストの流れを明確に理解するために、透明性の高いデータ管理、予算管理、ガバナンス、および包括的なレポートを組織内に用意することが重要です。この段階を超えて、FinOpsの本質は、効率的で体系的な管理のための方法論と協調的枠組みの構築にあります。
理想的な段階は、自動化を導入し、組織全体が統一された言語でコミュニケーションできるようにすることです。さらに、継続的なサイクルを確立する必要があります。1 回限りの作業であれば、FinOps や FinOps ツールは不要です。OpsNowのFinOpsは、単に機能を開発して「私たちにもその機能がある」と言うのではなく、継続的なアクティビティをサポートする方法でこれらの問題を解決することに重点を置く必要があります。
やるべきことはまだたくさんあり、取らなければならない道もたくさんあります。テクノロジートレンドは過去と比べて急速に変化しており、これらの変化に対応できるかどうかは私たち次第です。しかし、組織内の機能やテクノロジーだけにとどまらないものの本質を理解しなければ、AI のような最先端のツールを採用しても裏目に出る可能性があります。新しいAI時代では、私たちが追い越される逆転に直面するかもしれません。そして、これはすでに起こっていると思います。さらに、クラウドの成熟度が以前と比べて均等に発展している現在、高品質のサービスや製品で競争力を維持するには、まずこの本質を内部から深く理解する必要があります。
OpsNowは、国内のCMPの中でFinOpsのリーダーとしての地位を確立しつつあります。以前はテクノロジーのみに焦点を当てていましたが、さまざまなFinOps資格を取得し、FinOps認定プラットフォームを取得することで、実際のメッセージを効果的に伝える方法を反映したソリューションとサービスへと進化しました。
サービスが進化して便利になるにつれて、ほとんどの人は、以前とは異なり、物事の仕組みや実装方法を理解しなくなり、そのまま使用しています。前述のように、以前はリソーススケジューリングとスポット機能は基本的な機能ではありませんでしたが、現在ではデフォルトのサービスと見なされています。つまり、テクノロジーの進歩によりユーザーの利便性が向上した一方で、ユーザーは基盤となる操作を理解したり管理したりすることから遠ざかっています。クラウドサービスの利便性が向上した現在でも、人々は目に見えるものだけに集中する傾向があり、舞台裏で物事がどのように機能するのかを理解しようとすることはほとんどありません。これは、サービスプロバイダーである私たちが掘り下げる必要がある分野です。
知れば知るほど見えてくる。現在、AIがより便利になる世界に住んでいますが、これらのプロセスを理解し、正確な情報を提供する人々の役割は減少しています。OpsNow FinOpsの出発点はここにあると私は信じています。私たちが当たり前と思っていたことが、いつもそうだったわけではありません。RI/SPの自動管理が標準機能になりつつあるように、新しいサービス標準を作成して提供する必要があるのは私たちだと思います。
OpsNowがクラウドをさらに活用するのにどのように役立つのか知りたいですか？私たちはまさにそのものを手に入れました。
OpsNowでは、FinOpsを中心に製品とサービスを構築しています。しかし、私たちが提供するものについて説明する前に、「私たちはFinOpsの意味を本当に理解しているのか」という根本的な質問を自問する必要があります。
次のようなフレーズが聞こえます。 「FinOpsは不可欠です」、「必須です」、 そして 「それなしでは生きていけない」、これらは内部で頻繁に投げかけられます。しかし、「FinOps は本当に必要なのか？」と尋ねることから始めるのが適切かもしれません。
OpsNow のメンバーとしても、「クラウドのコストを削減するには OpsNow FinOps が本当に必要なのか」と自問してきました。正直なところ、私の答えは「いいえ」ですが、FinOpsは絶対に必要だとも思います。
矛盾しているように聞こえるかもしれませんが、その理由を理論ではなく経験に基づいて説明します。私はすべての答えを持っていると主張しているわけではありませんが、私をここに導いた考えや教訓をいくつか紹介したいと思います。
この投稿は個人的な経験に基づいています。これは絶対的な真実でも、万能の解決策でもありませんが、現実のものです。そして時々、実際の経験から、理論上の完璧さよりもさらに多くのことが明らかになることがあります。
2012年以来、私は韓国で最も有名な企業の1つでクラウドチームの開発と運営を率いてきました。このチームは、会社の将来の成長を促進するために設立されました。クラウドの世界に対する私の第一印象は、まるでユートピアのように感じられたということでした。
クラウドチームの開発と運用を統括する前は、カーネルシステムエンジニアとして働いていました。メモリの一バイト一バイトを奪い合い、パフォーマンスの向上を毎秒追求していました。私は見過ごされがちな、影の多い低レベル開発の世界で立ち往生していました。しかし、クラウドコンピューティングの世界に入ると、すべてが変わりました。メモリの問題が生じた場合、解決策は深く掘り下げて根本原因を解決することではなく、ただサーバーを追加することでした。パフォーマンスに問題があった場合は、単にスペックをアップグレードしただけです。まったく新しい世界に足を踏み入れたような気がしました。このような「楽園」に入る喜びを真に理解できるのは、低レベル開発の最前線で働いてきた人だけです。
私たちが最初にクラウドチームを立ち上げたとき、私自身を含め、誰もクラウドの経験があまりありませんでした。私たちは、他の場所でクラウドテクノロジーを扱ったことのある数人の新しいチームメンバーとともに、ゼロから始めました。私たちが一緒に成長するにつれて、チーム、組織、さらには会社全体も成長しました。私はいくつかのコスト効率化タスクフォースを率いて、生産性を高めるための社内ソリューションを導入し、最終的には会社の大幅な経費削減を支援したことを覚えています。
それらの経験を生かして、当時私たちがどのようにコスト最適化に取り組み、業務を合理化したか、そしてそれらの実践が現在「FinOps」と呼ばれるものとどのようにつながっているかを振り返りたいと思います。私たちの取り組みがクラウド支出の効率を高めただけでなく、チームや部門を超えた幅広いコラボレーションにどのように影響したかを探ります。
2011年から2013年の間、「FinOps」という用語すら存在しませんでした。クラウドに移行するにつれ、コストが大幅に上昇し始めたという変曲点に達しました。当時、クラウドは安価な代替手段として認識されていました。しかし、独自のモジュールを使用して大規模なインフラストラクチャを管理し始め、1 時間あたり数百万件のデータトランザクションを処理し、ペタバイト規模の環境で運用するようになると、クラウドはすぐに高価になりました。
そして、私たちはそれに疑問を呈しませんでした。私たちは単に「これが現実だ」と思っただけです。2015年頃まではその前提で運営していたと思います。
しかし、これらの高額なコストにつながったのは、単にクラウドに関する知識が不足していただけなのでしょうか。
実際には、開発と運用の両方を行いながら、数千万人のユーザーのファイル転送と画像配信を管理することは、大きな技術的課題でした。それには、大規模システムとデータ処理に関する深い専門知識が必要でした。当時、業界は急速にクラウドに移行していました。誰もがパフォーマンス、スケーラビリティ、可用性を試していました。お金が優先されるのではなく、スケーラビリティが優先されました。何を構築しているのか完全には理解していなくても、「とにかくやってみよう」という黄金時代でした。
そしてうまくいきました。正直なところ、まだ誰もクラウドを本当に理解していなかったからです。予算を管理するチームはインフラストラクチャーを完全には理解していませんでした。エンジニアは財務を完全には理解していませんでした。このギャップにより、経営幹部と財務チームの両方から承認を得ることが容易になりました。
マイクロサービスアーキテクチャの概念がなかったことを今でも覚えています。問題が発生したときには、サーバーを増やしたり、スペックを上げたりしていました。データベースがなぜ重要なのかよくわかりませんでした。時代は 「ある問題を別の問題でカバーする」
痛ましい教訓と運用上の成熟
当時はいろいろな経験をしてきました。大量のトラフィックを、次のような単純でナイーブな仮定で処理しようとしたことを覚えています。 「正しいクエリを実行すればいいんじゃないですか？」 私たちはしばしば、開発だけでどんな問題も解決できると信じていましたが、運用はほとんど無視していました。
最も忘れられない瞬間の1つは、大規模なサービス開始の直前でした。誰かが何の調整もせずにコード変更をプッシュしました。発売日になってもサービスは安定していませんでした。その結果は？3 日間続いた本格的な停電。このサービスは、誕生する前からほとんど機能しなくなっていました。
はい、コードの問題はすぐに修正されました。しかし、受信トラフィックのバックログが解消されるまで問題を引き起こし続けることに気づきませんでした。その時、私は重要な教訓を学びました。本当の運用スキルは、サービスをいつオフラインにし、いつ復旧させるべきかを知ることにあります。その電話をかけるのに丸3日かかりました。
振り返ってみると、それらの辛い経験が今日の私を形作りました。私はクラウドの「エキスパート」ではありませんが、堅実な実践者になりました。私は数え切れないほどのサービスを運営し、維持してきました。規模の拡大という名のもとで過剰支出をしてしまうのはいかに簡単か、そしてそれらの決定を承認するよう上層部を説得する方法を学びました。
2014年から、世界経済の不確実性などの要因により、「コスト削減」という包括的なテーマのもと、全社的なクラウドコスト削減の取り組みが本格的に始まりました。当時、主な目標は単に予算と比較してコストを 30% 削減することだったことを覚えています。これにより、より体系的なコスト削減活動が始まりました。
このようなコスト削減の取り組みの中で、クラウドの複雑なコスト構造がより明確になり始めました。これは、クラウドが従来の会計や財務の慣行とはまったく異なる原則のもとで運営されていたためです。会計や財務では通常、コストは年間予算内で管理されますが、クラウド環境では使用量がリアルタイムで変動するため、コストと予算を正確に予測することは困難です。クラウドの使用率とコストが急増していた時代には、この特徴から、サービス品質を確保するために過度に高い仕様を維持したり、コスト改善のための構造変更が困難なため、初期設計を最適化せずに運用を継続したりするという課題が繰り返し発生していました。
当時、経営幹部や財務部門はこれらの費用を「避けられない支出」、いわゆる「グレーゾーン」と呼び、避けられないものとして受け入れていました。漏れやすいバケツに水を注ぎ、実質的な見返りを得ずに絶えず支出しているような感じでした。財務部門は、すべてがうまくいくことを前提に予算を設定しますが、いったん支出が始まると、予想外のコストが発生し続けました。そのとき初めて、事態の深刻さが明らかになった。当時はまだこれらは「投資」だという認識が強く、クレームがあったとしても、ただ先に進んで受け入れるというのが一般的な姿勢でした。
そんな中、「緊急事態管理」というキーワードのもと、組織全体で徹底的なコスト削減を求める圧力が高まった。当時私はクラウドチームの一員でしたが、FinOpsという概念はまだ存在していませんでした。代わりに、経営革新とコスト削減という一般的な目標の下で、全体的に 30% の削減を実現するよう求められました。この目標を達成できないと経営幹部の KPI や評価に影響が及ぶことが明らかになったとき、圧力が高まり、組織はコストにさらに注意を払うようになりました。
コスト削減の取り組みの最初のステップは、現在の状況を評価することでした。まず、コストとリソースを管理する責任者がいるかどうか、またそれらのリソースがどのように使用されているかを特定することから始めました。部門間の関係は複雑だったため、この情報収集プロセスには数か月かかりました。当時、クラウドサービスプロバイダー (CSP) でさえ、コストやリソースの使用状況に関する詳細な情報をユーザーに明確に提供することができませんでした。
社内の能力には限界があることを認識し、外部評価にも取り組むことにしました。その結果、私たちは外部のクラウド管理プラットフォーム (CMP) の実装と、いくつかの類似ツールの概念実証 (POC) トライアル、および社内開発を開始しました。マッキンゼーやアクセンチュアなどのコンサルティング会社が参加し、300～400種類の指標を検討して包括的な評価を行いました。それは私たちが何百ものExcelファイルを配布し、その使用方法の詳細について部長に執拗に質問していた時期でした。振り返ってみると、これらのアクションにはまったくメリットがなかったわけではありませんが、特に問題のサービスを完全に理解していなかった場合は、会話が一方的に感じられることがよくありました。このアプローチは、診断部門と他の部門との格差も深めました。という気持ちがこもった時代でした。 「このサービスわかる？」 とても宙に浮いていた。
先に述べたように、コスト削減の取り組みの第一歩は、現状を理解することでした。組織内でクラウドを使用したことがある人なら誰でも、管理されていないクラウド環境ではコストの請求書を確認することしかできないため、詳細な洞察を得ることが難しく、大きな混乱を招くことを知っています。このような背景を踏まえて、私たちは最初のステップとしてこの情報を収集して整理することから始めました。
この過程で、「定着した利益」という概念が形成され始めました。状況をいち早く把握して経営幹部に報告した組織が、より大きな影響力を持つようになり、事実上「支配的」な地位を占めるようになりました。この構造がより確立されるにつれて、信頼が失われ、分断が深まることがありました。この展開を目の当たりにしたことは、当時非常に興味深い経験でした。
情報収集が完了すると、次の重要な質問に移りました。 「これらの費用を効果的に使っているか？」 理論的には、メモリ、I/O、CPUなどのリソースの使用状況を分析しました。使用率の低いリソースはすべて無駄とみなされ、効果的に削減または削除するための措置を講じました。しかし、当初の設計はクラウド運用に適切ではなかったため、サービスとそのドメインに関する知識を深く理解せずにリソースを削減すると、サービスが大幅に停止する可能性があります。特に、サービスの本質を十分に理解せずに設計に取り組むことが、予期せぬ問題を引き起こす主な原因となりました。前述のように、この問題はしばしば、ある問題が別の問題によって隠されてしまうという悪循環を引き起こしていました。
リソースを大幅に削減した後、サービスが停止し、部門長は予算管理チームに強く反対しました。「コストを削減すれば、こうしたサービス停止の責任を取れるだろうか？」というのがよくある質問で、頻繁に意見が対立していました。結局、組織は2つの選択肢のどちらかを選択せざるを得ませんでした。適切な妥協をしてコスト削減を行うか、抵抗に屈するかです。
そんな中、比較的成功していたサービスが中止になるという事件がありました。一方、コストが最も高かった別のサービスは、将来の投資価値とさまざまな利害関係者の利害関係により、削減できる領域が多数あるにもかかわらず、維持され続けました。このサービスは今日も順調に運営されていると理解しています。
2015年から2018年の間に、サービスに対する理解の欠如と利害関係者の複雑な利害関係により、コスト削減のアプローチは変化し始めました。これらはすべて「コスト」という言葉を中心としたものでした。これはあくまで私の個人的な意見ですが、この変化は 2 つのアプローチに分けることができると思います。
最初のアプローチは、クラウドサービスプロバイダー（CSP）と割引を交渉することでした。これは、これらの割引によって内部管理上の問題の一部を相殺するのに役立ちました。大企業が CSP に大きな収益をもたらしていたため、これは実行可能な戦略でした。
2 つ目のアプローチは、リザーブドインスタンス (RI) を通じて割引を適用することでした。これは貯蓄プラン (SP) が導入される前のことで、中央チームが RI を管理し、コスト削減策として各部門に分散していました。しかし、RI管理の複雑さと、給付対象から除外された部署の不満が大きな問題となりました。特に当初は、適切な専門知識がなく、RI の管理が不十分だったり、対象範囲が狭かったりすると、コストが爆発的に増加することがありました。この経験から、現在の FinOps プラクティスでは RI や SP などの項目を自動的に管理することが重要である理由が明らかになっています。
最終的に、コスト管理戦略は、マルチクラウドによるコスト配分とクラウドサービスプロバイダー（CSP）との交渉へと発展しました。このアプローチは今日のFinOps戦略と一致していますが、当時、クラウドとコスト管理における従業員の成熟度が不十分で、多くの苦情が寄せられていました。
さらに、新しいサービスを導入する際にAWSなどの大手CSPが提供するクレジット特典のおかげで、一部の組織はソリューションの切り替えを試みることもありました。この一連のイベントは、これまでに経験したことのないさまざまな新しいソリューションやマルチクラウド環境に出会い、技術的に成長する絶好の機会となりましたが、個人的な観点から見ると、最大の受益者はCSPだったと思います。その理由は、当時、実際に大規模なトラフィックとデータを運用している企業はほとんどなかったため、CSP にとっては実社会での経験を積む絶好の機会だったからです。こうした経験をもとに、CSPは急速な進歩を遂げました。
一方、クラウドサービスの利用とデータは増加し続け、さまざまなコスト削減の取り組みにもかかわらず、コスト上昇の現象が再び現れ始めました。最終的に、主要サービスを除き、MAU (月間アクティブユーザー数) が一定レベルを下回るか、収益貢献度が低いサービスのコスト削減圧力が高まりました。その結果、運用チームと開発チームは生き残るためにアーキテクチャとパフォーマンスの改善を集中的に検討するようになり、インフラストラクチャと開発の革新は限られた予算の制約の中で行われるようになりました。(業務も含まれていました)。
この時期から、ChatOpsの採用、EKSベースの高度な構造、Terraformの活用、外部SaaSソリューションの使用、サーバーレスアーキテクチャへの移行など、より高度なクラウドアーキテクチャへの本格的な移行を開始した組織もあります。パフォーマンスを確保しながらコストを削減しようとする取り組みは、文字通り「狂ったレベルの粘り強さ」でした。
それまでは、この組織はほとんどが数人の技術リーダーによって主導され、組織全体でクラウドの成熟度に大きなギャップがありました。しかし、この時期から、開発、運用、コスト管理の観点から、サービスオーナーの全体的な成熟度が急速に上昇し始めました。ダウンタイムゼロの運用、ユーザーからの苦情、新機能やソリューションの採用の失敗、運用上の失敗による深夜、財務チームからの要請など、絶え間ないプレッシャーの中、チームは生き残りを重視した真の戦略を策定し始めました。つまり、開発は運用重視のエンジニアリングへとシフトし始めたのです。
そして、私たちが前進し続けるうちに、私たちは資源と人的資源をいかに非効率的に使用していたかに自然に気づきました。その認識が、最終的に「無慈悲な自動化」と呼ばれるものへと私たちを導きました。これにより、自動化のための技術と運用の両方における本格的なイノベーションが始まりました。理由は単純でした。自動化しなければ、作業負荷は耐え難いものになり、最終的にはその重みで崩壊してしまうからです。
これらの苦労して得た経験は、生き残るためのより深い技術交流と、チーム間の冗談めかして「テックショーボート」と呼ばれるものにつながりました。それはやがて部門間の競争と圧力へと発展しました。チームは、「私たちの方がうまくやっている」、「より少ない人員で安定したサービスを運営している」、「より低いコストで運営している」などの主張で競争し始めました。
数年後、経営幹部の命令として、クラウドの大幅なコスト削減のための全社プロジェクトが開始されました。簡単に言えば、それは「支出が多すぎるからコストを削減する」という指令でした。これが本格的なFinOps活動の真の始まりとなりました。最初は圧倒されたように感じましたが、最適化、効率の向上、RI/SP の採用、EDP の交渉など、可能な限りの手段を講じました。
部署間の利害の対立によりイニシアチブが課題に直面したため、私たちは二面的な戦略を実施しました。まず、クラウドの専門家チームが結成され、各サービスのアーキテクチャを徹底的に見直しました。次に、財務チームは透明性の高いデータ収集を実現するために Finops のようなツールの使用を強制し始め、そのインサイトに基づいた診断作業を開始しました。
最初は、未使用のリソースを削除したり、適切なサイジング手法を適用したりするなど、一般的な方法で問題に取り組みました。これは典型的なFinOps手法です。しかし、組織のクラウドの成熟度が高まり、サービス品質に対する説明責任が高まるにつれ、これらの基本的なアプローチはやがて壁にぶつかりました。データがどれほど説得力があるように見えても、サービスに対する深い理解とオーナーシップを持つチームに直面した瞬間、コスト削減の圧力は勢いを失いました。
新しいアプローチが必要であることが明らかになりました。そこで、リソーススケジューリングとスポットインスタンス管理のための内部機能の開発を開始しました。これらの機能は、現在ほとんどのCSPが標準で提供している機能です。
これらのツールを検証するために、私たちは本質的に試験的なプロジェクトを立ち上げました。これは「犠牲の子羊」であり、物事がうまくいくかどうかをテストするためのベースラインデータの準備に3か月を費やしました。正直なところ、それがうまくいくかどうかは重要なポイントではありませんでした。私たちが本当に必要としていたのは、組織全体でFinOpsの採用を促進するための手段でした。短期間で堅実なソリューションを構築するために最善を尽くしましたが、ご存知の方も多いように、このような迅速な構築には下流での課題が伴うことが多く、安定させるには多大な忍耐が必要です。
それでも私たちは、カスタムビルドのスケジューリングシステムやスポットインスタンス管理機能 (当時の spot.inst のようなオープンソースツールから大幅に変更された) など、さまざまな最適化ツールを開発しました。その後、私たちのチームが社内で開発、運営しているプロジェクトで積極的にテストしました。3 か月にわたる徹底的な最適化の後、得られたデータを使用して他のチームにもツールを採用してもらいました。これはまた、サービスアーキテクチャの根本的な再設計と人員配置効率の評価にもつながりました。
これらの成功はFinOpsツールの功績を公に認めましたが、実際のコスト削減は、データ構造の変革、近代化の取り組み、労働力の再編など、より深いアーキテクチャの変更によってもたらされました。最終的に、この移行により、以前はクラウドサービス開発のみに注力していた私が、本格的な運用職に就くことになり、「攻撃者」の立場に移行するターニングポイントとなりました。
この経験から、組織全体を一度に移動する必要はないことに気づきました。その代わり、私たちはいくつかの主要チーム内で変化を推進することに重点を置きました。その成功事例をケーススタディとして、コスト削減の成果と予測モデルを上級管理職と財務チームに提示しました。次に、各部門長にコスト削減 KPI を割り当て、参加を効果的に義務付けました。診断チームは、クラウドサービスに関する深い専門知識の構築と技術的信頼性の確立に重点を置きました。この基盤をもとに、より上位の部署に合わせた戦略とツールを提供しました。このアプローチは、今日のFinOpsの核となる理念と密接に一致しています。
実際には、最も大幅なコスト削減は、FinOpsツール自体の使用によるものではなく、アーキテクチャの近代化や労働力の最適化など、それらのツールによって引き起こされたより広範な組織変更によるものです。私たちが直面した最も困難な課題の 1 つは、絶え間ない疑問でした。
「これはRI/SPよりも節約できるのか？」 そして 「このアプローチは、EDP割引よりも本当に効果的ですか？」
場合によっては、数字が実際には逆になり、従来の価格設定モデルと比較して悪い結果が見られました。しかし、本当に重要なのは現在ではなく、将来の構造変化によってもたらされる長期的なコスト削減でした。これが激しい議論につながり、賛同を求める激しい戦いが繰り広げられました。これらの変化の影響は徐々に明らかになってきました。
しかし、継続的な経営に裏付けられなければ、結果は簡単に崩壊する可能性があります。ワークロードを管理する適切なタイミングを逃すと、古い方法への回帰、技術的負債の蓄積、コストの不安定化につながる可能性があります。チームがそのような失敗を経験すると、不信感が引き継がれます。このような状況を経験した組織は、将来の FinOps イニシアチブ、特に外部から提案されるイニシアチブに強く反対する傾向があります。
ヨーヨーダイエットのようなものです。継続的な努力と規律がなければ、システムは回復します。これはFinOpsエコシステムにおける最も重要なポイントの1つです。
社内でどれだけうまくコストを管理していても、外部要因によって努力が意味をなさないことがよくあります。最も一般的な例としては、為替レートでしょう。
たとえば、2021年までに、効率の最適化と構造変更への取り組みにいくらかの見返りが見えてきました。しかし、通貨の変動などの要因により、こうした取り組みが希薄化されることもありました。
1か月あたり10億ウォンのコスト削減に成功した後、為替レートの上昇によりその節約分が逆転することがよくありました。その結果、コスト削減が実際に達成されたかどうかを疑問視する一方的な財務部門からのコミュニケーションが頻繁に発生することになります (このような状況では、レイオフという悪循環につながることがよくあります)。現在の世界経済の状況と韓国の為替レートの変動を考えると、同様のケースが再び見られるようになると思います。歴史は繰り返される傾向がある。
とにかく、これまでの話は過去の経験に基づいています。まとめると、それは常に指導部の危機感から始まり、それが圧力と説明責任を引き起こしているということです。組織が行動を起こさないと、KPI と予算の管理下で動き始めます。もちろん、自らをうまく管理している組織もあります。そのような場合は、外部のツールや方法を強制する必要はありませんでした。すでに素晴らしい仕事をしているので、その勢いを邪魔したり混乱させたりしないほうがよかったのです。
さらに、コスト分析、異常検出、推奨事項、リソース比較、マルチクラウド比較、パフォーマンス分析、ネットワーク診断などのさまざまな機能的手法が標準化され、問題に取り組む際の出発点として私たち全員に親しまれてきました。
それでは、過去の経験を踏まえて、実際にコスト削減がどのように行われているのかを見てみましょう。私たちはこのプロセスを本当に理解しているのでしょうか？ここから物語の始まりです。
前述のように、トリガーは常に存在します。それが経営陣によるものであろうと他の誰かによるものであろうと、誰かがコストとリソースの使用について懸念を表明します。運が良ければ、問題が指摘されたときにそれを正しく理解し、自発的に対応することができます。しかし、残念ながらほとんどの場合はそうではなく、人々は通常それを避けがちです。
その理由は明らかです。仕事が増え、批判される可能性があるからです。さらに、支出は簡単ですが、コスト削減は非常に難しいことは誰もが知っています。
したがって、このタスクは最終的に、実行する人、診断と分析を行う人、評価して決定する人の3つの基本的な柱を中心に展開します。これをさらに発展させると、FinOps Foundationが概説している現在のペルソナのように、役割はより詳細になります。
それでは、例を挙げましょう。
「今月の予算を 20% 削減しなければならないなら、まずクラウドのコストから始めましょう。」
このような指令が出たら、チームはまず何をしますか？
「過去 3 か月、6 か月、1 年間のクラウド支出データをすべて持ってきてください。」
通常、そこから始まります。実際にコストが増加したかどうかに関係なく、会話はデータから始まります。
この時点では、組織が単一のサービスを運営しているのか、複数の事業部門を運営しているのかによって、アプローチが異なります。
サービスが 1 つしかない組織の場合、最初のステップは、どのリソースが最もコストを消費しているかを分析することです。次に、「これを今すぐ実際に削減できるか」という疑問が浮かびます。
通常、データベースやネットワークの料金など、コストが高い領域は予測可能です。対策を講じるために、ほとんどのチームはまず未使用のリソースをチェックすることから始めます。しかし実際には、このアプローチによるコスト削減は、多くの場合、予想よりも小さいです。運が良ければ、管理されていない高価なリソースが見つかることもありますが、それは戦略というよりは運の問題です。
次はリストを生成する作業です。どのリソースを最新化できるか、つまり適切なサイズであるかを慎重に判断します。
「これを減らせば、いくらかコストを節約できたと言えるかもしれない」と考えてデータを掘り下げます。それを念頭に置いて準備を進めると、疑問が浮かび上がってきます。
「これではRI/SPのカバレッジが不足するのではないか？」
「EDPの条件を破り、不足分に見舞われたらどうなるでしょうか？」
「RI または SP はいつ期限切れになりますか?この変更を間に合うように行うことはできますか？」
このような懸念が持ち上がると、これまでの選択肢は難しすぎると感じ始めるので、プロダクション、開発など、使用しているすべてのアカウントを見直します。
順序は異なる場合がありますが、最終的にはすべてのアカウントが1つずつ審査されます。
アカウントがある程度整理されると、レポートは通常、誇らしげに次のようになります。
「このように削減を続ければ、効果的にコストを削減できます。」 これは通常の1次元のレポートです。しかし実際には、20% 以上削減するのは簡単ではありません。そして今、あなたは岐路に立っています。
「本当に不要なサービスを停止すべきか？」 または 「彼らに割り当てられた労働力を減らすべきか？」
しかし、いずれにしても、どちらの選択も簡単なものではありません。
そこで、開発と運用の両方の経験がある人は、ここで中心的な問題について考え始めるでしょう。
「これは収益と結びついているので、ROIの観点から、アーキテクチャや設計を再考すべきではないでしょうか？」
この時点で、開発と運用の構造的変化が始まります。この議論が行われなければ、最終的には「避けられないコスト支出」のグレーゾーンにとどまり、組織はその現状を維持し続けることになります。
__________________________________________________________________________________________________________________________________
複数のサービスを管理する組織の場合、フローは似ていますが、開始点は少し異なります。
ほとんどの組織は、次の質問から始めます。 「最も支出が多い組織はどれですか？」
このアプローチは、コストが最も高い組織とその管理責任者に直接つながります。たとえ高額な費用が正当化されたとしても、全体的な目標を達成するためには、比較的よく管理された組織が、最終的に削減されることもあります。
ほとんどの場合、リストの作成、リソースの整理、アカウントの確認など、前述のアプローチが採用されています。ただし、この場合でも、RI/SP 管理や特定の組織に対する好意といった運用上の違いが、チーム間の対立につながりやすくなります。実際、これらの問題はしばしば、責任が特定の人物に移る状況へとエスカレートします。
この時点で、組織はコスト配分構造の再評価を開始し、各部門の予算編成と配分の詳細について議論が始まります。もちろん、全員が不満を抱いているわけではありません。実際、一部の組織はこの変更を歓迎しているかもしれません。
____________________________________________________________________________________________________________________________________________________________________
しかし、開発と運用の両方の経験を積むと、根本的な疑問が生じます。これは収益に直接つながるため、ROIと、アーキテクチャや設計自体を根本的に削減する必要があるポイントがあるかどうかを検討することから始めます。この時点で、開発と運用の変化が始まります。そうでない場合は、「避けられないコスト支出」として残り、現在の状態が続き、長期的なグレーゾーンへと発展する可能性があります。
一方で、「やむを得ない経費支出」という口実のもと、そのような配慮をせずにそのまま現状を維持するだけでは、ますます根強いグレーゾーンに入り、問題はさらに複雑になるだけです。
____________________________________________________________________________________________________________________________________________________________________
上記のシナリオは、おそらく誰もが少なくとも一度は経験したことがあるものです。
変更を実施する部署は、物事を隠そうとしたり、頑張ったりするかもしれませんが、受け取り側は数字だけを見ることになります。彼らは努力を気にしません。数字が目標を達成するかどうかがすべてです。
この時点で、組織内に不調和が生じ始めます。
万全の努力にもかかわらず、数値のみに基づいて意思決定を行う場合、2つの選択肢になります。将来のコスト削減を見越して数値を膨らませるか、現在の状態を維持する方法を考え出すかです。
この時点で、組織は現在の状況に合わせてリソースとコストの分析を調整し始めます。
この例からわかるように、FinOpsはコスト削減だけではありません。むしろ、まずは、物事がうまく行っているか、適切なレベルの効率で運営されているかを評価することから始まります。目標は、現状を把握し、関係部署を納得させることです。このプロセスは、メビウスの帯状の連続したループのようなものです。
さて、絶え間ない疑問は、「適切な規模」、「未使用リソース」、「近代化」などのデータを使って、どの程度コストをかけているかを本当に評価できるかということです。
答えは「はい」です。
ただし、実行中のサービスにこれをすぐに適用できるかどうか尋ねられた場合、答えは「いいえ」です。これは、運用やサービスを担当していない部署にとっては話しやすい話題であることが多いです。
サービス業務は非常に保守的であり、業務で発生する問題には常に「責任」という重い言葉が伴います。単により多くのお金を使うほうが簡単だと感じることがよくあります。その結果、インフラの拡張によってコストが高くなるケースもあります。
このサイクルは繰り返されます。これを回避するには、サービス業務に影響を与えずにコストを節約するために、EDPやRI&SPなどを事前に購入するしかありません。さらに高度なシナリオでは、未使用のサーバーを営業時間外にシャットダウンするようにスケジュールしたり、スポットインスタンスのような安価なリソースに切り替えたりするなどの選択肢も検討されます。
ただし、これは依然としてサービス業務に関連する責任によって制約されています。もちろん、より成熟した組織では、これらの側面を自動化して、人々がより戦略的なタスクに集中できるようにすることができます。
次のアプローチは責任の割り当てです。コントロールであろうと投資であろうと、責任を担当部門に委任することが課題です。なぜ？それが一番簡単な方法だからです。「できないなら責任を取れ」と言うことほど便利なことはありません。じゃあ、どうやってやるの？Excel を使用して各リソースを 1 つずつ確認し、文書化して整理することができます。これは、リソースや組織が小さい場合に実行可能です。
これをうまく管理するために、すべてを明確に分類して管理するためのタグが導入されています。こうすることで、どの組織がリソースを効果的に使用しているかを分析しやすくなり、膨大な量のデータとはっきり区別できるようになります。
しかし、これがコスト削減に直接つながるかどうか尋ねると、答えは「はい」と「いいえ」の両方です。結局のところ、どのような行動をとるにしても、すべての行動には人間の関与が必要であり、個人がもはや責任がないと感じると、その努力は途中で放棄されることがよくあります。そこで、組織は KPI を結び付け、ミッションや予算管理と連携させるようになりました。適切な管理を行わなければ、これらのイニシアチブは無意味なものになりかねません。そのため、多くの組織は測定可能な成果に結び付けることに重点を置いています。
失敗につながるケースをたくさん見てきたので、焦点は組織内のパフォーマンスに移ります。そのような状況では、いかにコストを削減するかについて社内の議論が始まります。どうすれば最小限のコストでサービスを提供できるのか？運用管理を効率化するにはどうすればよいか？
そのためには、サービスに対する理解と、利用している資源がどれだけ高価であるかを認識することが必要であり、それが最終的に単位経済につながります。
そして、ある時点で、人間の効率性に関する議論が浮かび上がってきます。最終的には、誰かが責任を持って行動しなければなりません。しかし、責任を取るだけでは円滑な運営は保証されません。その人の権限や意欲によって、結果は異なります。さらに、これらの取り組みは短期的な場合もあれば、結果が出るまでに長い時間がかかる場合もあります。
ただし、組織文化が確立される前に組織的に動くことは難しいため、責任を分散させようとする傾向があります。ポジティブな見方をすれば、人は戦いたくないとき、「一緒に働いて協力しよう」と言う。しかし、ライバルになると、言い訳をするようになります。
これが、最近のFinOpsフレームワークがテクノロジーベースから企業の業績指標に焦点を当てるものへと移行している理由だと思います。
また、財務を担当する部門にとって、このデータと作業プロセスの信頼性を理解することは非常に重要です。予算計画と予測に基づいて、どの程度支出がうまく行われているかを組織に説得することがますます重要になっています。このデータの信頼性にもよりますが、各部署の自主性が高まる可能性があります。さらに、このプロセスが発展するにつれて、共通のミッションと実行を共有する部門間のコミュニケーションが最も重要な側面となるでしょう。
「うまく使うには理解する必要がある」ということわざがあります。サービスを開発、運用、管理する部門こそが、サービスを最もよく理解している部署です。先に述べたように、FinOps Foundationのフレームワークの最近の変化はこれを反映していると思います。つまり、あまり詳しくないと、なぜ何かがよく使われているのか理解できないということです。かつて「コスト」という言葉が出てきた時、財務的な観点からは経費削減の余地がありました。しかし、今日では、サービスを管理および開発するチームがそれを最も理解する必要がある主な理由の 1 つが、この点です。
つまり、FinOpsの前提の下では、さまざまな部門が表面的に廃棄物を特定して改善していますが、最終的には、ROIの観点からリソースをより効果的に使用するために、これを理解して改善する必要があります。この文脈では、FinOpsツールは、時間、労力、複数のユーザーを結びつける、共通の言葉でコミュニケーションするための基本的な手段だと思います。
支出額だけを見る人もいれば、専門用語のみに注目する人もいれば、KPIの達成数値だけに関心を持つ人もいます。しかし、これらの目標を達成するために使われる基本データはすべて同じです。それが何であれ、サービスの支払いは変わっておらず、これらのサービスの費用を計算するロジックも同じです。
OpsNowのように、FinOpsのツールにはそれぞれ異なる機能がありますが、これらの機能は1つの目的のために作成されたものと見なすべきではありません。その代わり、それらは統一された言語を提供する手段として機能する統合システムの一部です。これらのツールの機能の使い勝手は大きく異なり、生成されるレポートは各部門が追跡しようとしている内容によって異なる場合がありますが、最終的な目標は変わりません。それは、組織がリソースを効果的に使用しているか、改善の余地があるかどうかを組織が評価できるようにすることです。さまざまな観点から見ると、データはさまざまな方法で解釈される可能性がありますが、結局のところ、データはまとまりのあるストーリーを伝える必要があります。重要なのは、私たちがリソースを適切に使用していること、そして最も重要なのは、私たちが同じ言語を話していることについて、全員が同意していることを確認することです。
そのため、OpsNowは現在、組織のFinOpsの理解と導入を支援できる立場にあります。ツールの選択は二の次です。重要なのは FinOps の概念がどれだけ正確に理解されているかということです。FinOps を成功裏に導入するには、まず、組織が FinOps の原則をどの程度理解しているかを評価することが重要です。そうして初めて、このプロセスを促進する手段として何らかのツールを導入すべきです。
先ほどの個人的な例でも触れましたが、FinOps理論を知らなくても試してみました。その過程で数え切れないほどの失敗や成功を経験しましたが、今は「FinOps」という言葉で表現しています。ほとんどの組織にとっての問題は、理論的な知識の欠如ではなく、社内の経験、課題に取り組む意志、運用上の洞察、各サービスの中核に対する理解、チームの連携方法についての深い考察の欠如です。Google では理論はよく整理されていますが、理論を知って理解しているふりをするだけでは限界があります。
幸いなことに、OpsNowは、MSPの親会社であるBespin Globalを通じて遭遇した豊富な運用経験と顧客の要求に基づいて成長してきました。この基盤を土台に、OpsNowはFinOpsの分野で統一された声で話すことを目標に、進化を続けています。まだ長い道のりがありますが、プラットフォームは実社会での経験という貴重な資産のもと、サービスを着実に進化させています。
ただし、FinOpsの取り組みを社内で管理している人にとっては、特にコスト管理と効率が危機に瀕している場合には、FinOpsで働く人々のうち何人が開発に真に関与しているかを調べることが不可欠です。物事は順調に進んでいると言うのは簡単ですが、その経験を本当に経験した人と経験していない人の間には明らかなギャップがあります。
これまで、OpsNowのクラウドコスト削減の取り組みは、主に製品の機能を紹介することに重点を置いていました。しかし現在では、より深いものへと進化しつつあります。つまり、各機能の背後にある必要性と背景を明確に伝え、組織が信頼できるデータに基づいて有意義な行動を取れるようにするストーリーを構築するプロセスです。以前は機能主導型のソリューションでしたが、今では組織全体で共通の言語を話す統合サービスになりつつあります。理解と明確なコミュニケーションが技術的能力と同じくらい重要になる方向に向かっています。
私たちは岐路に立っています。そこで、効果的なクラウド分析、コスト管理、そして組織内の有意義な節約を可能にする環境を本当に構築したかどうかを自問することが重要です。製品やサービスを提供する観点からは、この分野に関する深い理解と実務経験が不可欠です。OpsNow FinOpsは、単に機能を紹介するだけではありません。FinOpsを十分に理解し、実践し、継続的に評価し、組織をその道のりに導くことが大切です。
FinOpsの基本的な出発点は、管理されていないクラウドコストを理解して管理することです。多くの組織は、コスト削減を最大化することを期待してFinOpsを採用していますが、実際には、FinOpsは中核的な必需品というよりはオプションのツールとして扱われることが多いです。実のところ、ほとんどの企業はすでにさまざまな方法でコスト削減策を実施しています。私たちが行っていることは、特にユニークでも例外的でもないかもしれません。
コスト削減にはさまざまな方法があります。クラウドサービスプロバイダー (EDP) との大規模な割引交渉、リザーブドインスタンス (RI) または貯蓄プラン (SP) の活用、リソースの最適化と効率改善の実施はすべて基本的なアプローチであり、これらはすべて FinOps ツールがなくても実行できます。場合によっては、単純に手作業に置き換えることもできます。しかし、これらのプロセスは、時間と労力、そしてビジネスドメインとサービスに対する深い理解によって支えられれば、はるかに効果的になります。組織に適切な能力があれば、サービス構造を再構築し、パフォーマンスを最適化することで、コスト効率と運用全体の両方を根本的に改善できます。
では、なぜFinOpsの理念が必要なのか、そしてOpsNowのようなツールが不可欠なのはなぜでしょうか。この質問には根本的な反省が必要です。クラウド環境がより複雑になり、組織の規模が拡大するにつれて、コスト管理はますます困難になります。多くの場合、責任が不明確になり、クラウドの利用が軽視されてしまうことがあります。クラウドのコストという性質上、問題は状況が悪化して初めて発見されることが多く、修正には多大な時間と労力が必要になります。FinOps が効果的に機能するためには一貫した取り組みが不可欠であり、それこそが FinOps がそもそも必要な理由です。FinOps は、そのような継続的な規律を始めるための基盤となります。
FinOpsでは、コストとリソースを定期的に監視できるため、問題の早期発見とリスクの最小化が可能になります。これは資源効率とコスト最適化への第一歩です。このプロセスでは、コストの流れを明確に理解するために、透明性の高いデータ管理、予算管理、ガバナンス、および包括的なレポートを組織内に用意することが重要です。この段階を超えて、FinOpsの本質は、効率的で体系的な管理のための方法論と協調的枠組みの構築にあります。
理想的な段階は、自動化を導入し、組織全体が統一された言語でコミュニケーションできるようにすることです。さらに、継続的なサイクルを確立する必要があります。1 回限りの作業であれば、FinOps や FinOps ツールは不要です。OpsNowのFinOpsは、単に機能を開発して「私たちにもその機能がある」と言うのではなく、継続的なアクティビティをサポートする方法でこれらの問題を解決することに重点を置く必要があります。
やるべきことはまだたくさんあり、取らなければならない道もたくさんあります。テクノロジートレンドは過去と比べて急速に変化しており、これらの変化に対応できるかどうかは私たち次第です。しかし、組織内の機能やテクノロジーだけにとどまらないものの本質を理解しなければ、AI のような最先端のツールを採用しても裏目に出る可能性があります。新しいAI時代では、私たちが追い越される逆転に直面するかもしれません。そして、これはすでに起こっていると思います。さらに、クラウドの成熟度が以前と比べて均等に発展している現在、高品質のサービスや製品で競争力を維持するには、まずこの本質を内部から深く理解する必要があります。
OpsNowは、国内のCMPの中でFinOpsのリーダーとしての地位を確立しつつあります。以前はテクノロジーのみに焦点を当てていましたが、さまざまなFinOps資格を取得し、FinOps認定プラットフォームを取得することで、実際のメッセージを効果的に伝える方法を反映したソリューションとサービスへと進化しました。
サービスが進化して便利になるにつれて、ほとんどの人は、以前とは異なり、物事の仕組みや実装方法を理解しなくなり、そのまま使用しています。前述のように、以前はリソーススケジューリングとスポット機能は基本的な機能ではありませんでしたが、現在ではデフォルトのサービスと見なされています。つまり、テクノロジーの進歩によりユーザーの利便性が向上した一方で、ユーザーは基盤となる操作を理解したり管理したりすることから遠ざかっています。クラウドサービスの利便性が向上した現在でも、人々は目に見えるものだけに集中する傾向があり、舞台裏で物事がどのように機能するのかを理解しようとすることはほとんどありません。これは、サービスプロバイダーである私たちが掘り下げる必要がある分野です。
知れば知るほど見えてくる。現在、AIがより便利になる世界に住んでいますが、これらのプロセスを理解し、正確な情報を提供する人々の役割は減少しています。OpsNow FinOpsの出発点はここにあると私は信じています。私たちが当たり前と思っていたことが、いつもそうだったわけではありません。RI/SPの自動管理が標準機能になりつつあるように、新しいサービス標準を作成して提供する必要があるのは私たちだと思います。
OpsNowがクラウドをさらに活用するのにどのように役立つのか知りたいですか？私たちはまさにそのものを手に入れました。
OpsNowでは、FinOpsを中心に製品とサービスを構築しています。しかし、私たちが提供するものについて説明する前に、「私たちはFinOpsの意味を本当に理解しているのか」という根本的な質問を自問する必要があります。
次のようなフレーズが聞こえます。 「FinOpsは不可欠です」、「必須です」、 そして 「それなしでは生きていけない」、これらは内部で頻繁に投げかけられます。しかし、「FinOps は本当に必要なのか？」と尋ねることから始めるのが適切かもしれません。
OpsNow のメンバーとしても、「クラウドのコストを削減するには OpsNow FinOps が本当に必要なのか」と自問してきました。正直なところ、私の答えは「いいえ」ですが、FinOpsは絶対に必要だとも思います。
矛盾しているように聞こえるかもしれませんが、その理由を理論ではなく経験に基づいて説明します。私はすべての答えを持っていると主張しているわけではありませんが、私をここに導いた考えや教訓をいくつか紹介したいと思います。
この投稿は個人的な経験に基づいています。これは絶対的な真実でも、万能の解決策でもありませんが、現実のものです。そして時々、実際の経験から、理論上の完璧さよりもさらに多くのことが明らかになることがあります。
2012年以来、私は韓国で最も有名な企業の1つでクラウドチームの開発と運営を率いてきました。このチームは、会社の将来の成長を促進するために設立されました。クラウドの世界に対する私の第一印象は、まるでユートピアのように感じられたということでした。
クラウドチームの開発と運用を統括する前は、カーネルシステムエンジニアとして働いていました。メモリの一バイト一バイトを奪い合い、パフォーマンスの向上を毎秒追求していました。私は見過ごされがちな、影の多い低レベル開発の世界で立ち往生していました。しかし、クラウドコンピューティングの世界に入ると、すべてが変わりました。メモリの問題が生じた場合、解決策は深く掘り下げて根本原因を解決することではなく、ただサーバーを追加することでした。パフォーマンスに問題があった場合は、単にスペックをアップグレードしただけです。まったく新しい世界に足を踏み入れたような気がしました。このような「楽園」に入る喜びを真に理解できるのは、低レベル開発の最前線で働いてきた人だけです。
私たちが最初にクラウドチームを立ち上げたとき、私自身を含め、誰もクラウドの経験があまりありませんでした。私たちは、他の場所でクラウドテクノロジーを扱ったことのある数人の新しいチームメンバーとともに、ゼロから始めました。私たちが一緒に成長するにつれて、チーム、組織、さらには会社全体も成長しました。私はいくつかのコスト効率化タスクフォースを率いて、生産性を高めるための社内ソリューションを導入し、最終的には会社の大幅な経費削減を支援したことを覚えています。
それらの経験を生かして、当時私たちがどのようにコスト最適化に取り組み、業務を合理化したか、そしてそれらの実践が現在「FinOps」と呼ばれるものとどのようにつながっているかを振り返りたいと思います。私たちの取り組みがクラウド支出の効率を高めただけでなく、チームや部門を超えた幅広いコラボレーションにどのように影響したかを探ります。
2011年から2013年の間、「FinOps」という用語すら存在しませんでした。クラウドに移行するにつれ、コストが大幅に上昇し始めたという変曲点に達しました。当時、クラウドは安価な代替手段として認識されていました。しかし、独自のモジュールを使用して大規模なインフラストラクチャを管理し始め、1 時間あたり数百万件のデータトランザクションを処理し、ペタバイト規模の環境で運用するようになると、クラウドはすぐに高価になりました。
そして、私たちはそれに疑問を呈しませんでした。私たちは単に「これが現実だ」と思っただけです。2015年頃まではその前提で運営していたと思います。
しかし、これらの高額なコストにつながったのは、単にクラウドに関する知識が不足していただけなのでしょうか。
実際には、開発と運用の両方を行いながら、数千万人のユーザーのファイル転送と画像配信を管理することは、大きな技術的課題でした。それには、大規模システムとデータ処理に関する深い専門知識が必要でした。当時、業界は急速にクラウドに移行していました。誰もがパフォーマンス、スケーラビリティ、可用性を試していました。お金が優先されるのではなく、スケーラビリティが優先されました。何を構築しているのか完全には理解していなくても、「とにかくやってみよう」という黄金時代でした。
そしてうまくいきました。正直なところ、まだ誰もクラウドを本当に理解していなかったからです。予算を管理するチームはインフラストラクチャーを完全には理解していませんでした。エンジニアは財務を完全には理解していませんでした。このギャップにより、経営幹部と財務チームの両方から承認を得ることが容易になりました。
マイクロサービスアーキテクチャの概念がなかったことを今でも覚えています。問題が発生したときには、サーバーを増やしたり、スペックを上げたりしていました。データベースがなぜ重要なのかよくわかりませんでした。時代は 「ある問題を別の問題でカバーする」
痛ましい教訓と運用上の成熟
当時はいろいろな経験をしてきました。大量のトラフィックを、次のような単純でナイーブな仮定で処理しようとしたことを覚えています。 「正しいクエリを実行すればいいんじゃないですか？」 私たちはしばしば、開発だけでどんな問題も解決できると信じていましたが、運用はほとんど無視していました。
最も忘れられない瞬間の1つは、大規模なサービス開始の直前でした。誰かが何の調整もせずにコード変更をプッシュしました。発売日になってもサービスは安定していませんでした。その結果は？3 日間続いた本格的な停電。このサービスは、誕生する前からほとんど機能しなくなっていました。
はい、コードの問題はすぐに修正されました。しかし、受信トラフィックのバックログが解消されるまで問題を引き起こし続けることに気づきませんでした。その時、私は重要な教訓を学びました。本当の運用スキルは、サービスをいつオフラインにし、いつ復旧させるべきかを知ることにあります。その電話をかけるのに丸3日かかりました。
振り返ってみると、それらの辛い経験が今日の私を形作りました。私はクラウドの「エキスパート」ではありませんが、堅実な実践者になりました。私は数え切れないほどのサービスを運営し、維持してきました。規模の拡大という名のもとで過剰支出をしてしまうのはいかに簡単か、そしてそれらの決定を承認するよう上層部を説得する方法を学びました。
2014年から、世界経済の不確実性などの要因により、「コスト削減」という包括的なテーマのもと、全社的なクラウドコスト削減の取り組みが本格的に始まりました。当時、主な目標は単に予算と比較してコストを 30% 削減することだったことを覚えています。これにより、より体系的なコスト削減活動が始まりました。
このようなコスト削減の取り組みの中で、クラウドの複雑なコスト構造がより明確になり始めました。これは、クラウドが従来の会計や財務の慣行とはまったく異なる原則のもとで運営されていたためです。会計や財務では通常、コストは年間予算内で管理されますが、クラウド環境では使用量がリアルタイムで変動するため、コストと予算を正確に予測することは困難です。クラウドの使用率とコストが急増していた時代には、この特徴から、サービス品質を確保するために過度に高い仕様を維持したり、コスト改善のための構造変更が困難なため、初期設計を最適化せずに運用を継続したりするという課題が繰り返し発生していました。
当時、経営幹部や財務部門はこれらの費用を「避けられない支出」、いわゆる「グレーゾーン」と呼び、避けられないものとして受け入れていました。漏れやすいバケツに水を注ぎ、実質的な見返りを得ずに絶えず支出しているような感じでした。財務部門は、すべてがうまくいくことを前提に予算を設定しますが、いったん支出が始まると、予想外のコストが発生し続けました。そのとき初めて、事態の深刻さが明らかになった。当時はまだこれらは「投資」だという認識が強く、クレームがあったとしても、ただ先に進んで受け入れるというのが一般的な姿勢でした。
そんな中、「緊急事態管理」というキーワードのもと、組織全体で徹底的なコスト削減を求める圧力が高まった。当時私はクラウドチームの一員でしたが、FinOpsという概念はまだ存在していませんでした。代わりに、経営革新とコスト削減という一般的な目標の下で、全体的に 30% の削減を実現するよう求められました。この目標を達成できないと経営幹部の KPI や評価に影響が及ぶことが明らかになったとき、圧力が高まり、組織はコストにさらに注意を払うようになりました。
コスト削減の取り組みの最初のステップは、現在の状況を評価することでした。まず、コストとリソースを管理する責任者がいるかどうか、またそれらのリソースがどのように使用されているかを特定することから始めました。部門間の関係は複雑だったため、この情報収集プロセスには数か月かかりました。当時、クラウドサービスプロバイダー (CSP) でさえ、コストやリソースの使用状況に関する詳細な情報をユーザーに明確に提供することができませんでした。
社内の能力には限界があることを認識し、外部評価にも取り組むことにしました。その結果、私たちは外部のクラウド管理プラットフォーム (CMP) の実装と、いくつかの類似ツールの概念実証 (POC) トライアル、および社内開発を開始しました。マッキンゼーやアクセンチュアなどのコンサルティング会社が参加し、300～400種類の指標を検討して包括的な評価を行いました。それは私たちが何百ものExcelファイルを配布し、その使用方法の詳細について部長に執拗に質問していた時期でした。振り返ってみると、これらのアクションにはまったくメリットがなかったわけではありませんが、特に問題のサービスを完全に理解していなかった場合は、会話が一方的に感じられることがよくありました。このアプローチは、診断部門と他の部門との格差も深めました。という気持ちがこもった時代でした。 「このサービスわかる？」 とても宙に浮いていた。
先に述べたように、コスト削減の取り組みの第一歩は、現状を理解することでした。組織内でクラウドを使用したことがある人なら誰でも、管理されていないクラウド環境ではコストの請求書を確認することしかできないため、詳細な洞察を得ることが難しく、大きな混乱を招くことを知っています。このような背景を踏まえて、私たちは最初のステップとしてこの情報を収集して整理することから始めました。
この過程で、「定着した利益」という概念が形成され始めました。状況をいち早く把握して経営幹部に報告した組織が、より大きな影響力を持つようになり、事実上「支配的」な地位を占めるようになりました。この構造がより確立されるにつれて、信頼が失われ、分断が深まることがありました。この展開を目の当たりにしたことは、当時非常に興味深い経験でした。
情報収集が完了すると、次の重要な質問に移りました。 「これらの費用を効果的に使っているか？」 理論的には、メモリ、I/O、CPUなどのリソースの使用状況を分析しました。使用率の低いリソースはすべて無駄とみなされ、効果的に削減または削除するための措置を講じました。しかし、当初の設計はクラウド運用に適切ではなかったため、サービスとそのドメインに関する知識を深く理解せずにリソースを削減すると、サービスが大幅に停止する可能性があります。特に、サービスの本質を十分に理解せずに設計に取り組むことが、予期せぬ問題を引き起こす主な原因となりました。前述のように、この問題はしばしば、ある問題が別の問題によって隠されてしまうという悪循環を引き起こしていました。
リソースを大幅に削減した後、サービスが停止し、部門長は予算管理チームに強く反対しました。「コストを削減すれば、こうしたサービス停止の責任を取れるだろうか？」というのがよくある質問で、頻繁に意見が対立していました。結局、組織は2つの選択肢のどちらかを選択せざるを得ませんでした。適切な妥協をしてコスト削減を行うか、抵抗に屈するかです。
そんな中、比較的成功していたサービスが中止になるという事件がありました。一方、コストが最も高かった別のサービスは、将来の投資価値とさまざまな利害関係者の利害関係により、削減できる領域が多数あるにもかかわらず、維持され続けました。このサービスは今日も順調に運営されていると理解しています。
2015年から2018年の間に、サービスに対する理解の欠如と利害関係者の複雑な利害関係により、コスト削減のアプローチは変化し始めました。これらはすべて「コスト」という言葉を中心としたものでした。これはあくまで私の個人的な意見ですが、この変化は 2 つのアプローチに分けることができると思います。
最初のアプローチは、クラウドサービスプロバイダー（CSP）と割引を交渉することでした。これは、これらの割引によって内部管理上の問題の一部を相殺するのに役立ちました。大企業が CSP に大きな収益をもたらしていたため、これは実行可能な戦略でした。
2 つ目のアプローチは、リザーブドインスタンス (RI) を通じて割引を適用することでした。これは貯蓄プラン (SP) が導入される前のことで、中央チームが RI を管理し、コスト削減策として各部門に分散していました。しかし、RI管理の複雑さと、給付対象から除外された部署の不満が大きな問題となりました。特に当初は、適切な専門知識がなく、RI の管理が不十分だったり、対象範囲が狭かったりすると、コストが爆発的に増加することがありました。この経験から、現在の FinOps プラクティスでは RI や SP などの項目を自動的に管理することが重要である理由が明らかになっています。
最終的に、コスト管理戦略は、マルチクラウドによるコスト配分とクラウドサービスプロバイダー（CSP）との交渉へと発展しました。このアプローチは今日のFinOps戦略と一致していますが、当時、クラウドとコスト管理における従業員の成熟度が不十分で、多くの苦情が寄せられていました。
さらに、新しいサービスを導入する際にAWSなどの大手CSPが提供するクレジット特典のおかげで、一部の組織はソリューションの切り替えを試みることもありました。この一連のイベントは、これまでに経験したことのないさまざまな新しいソリューションやマルチクラウド環境に出会い、技術的に成長する絶好の機会となりましたが、個人的な観点から見ると、最大の受益者はCSPだったと思います。その理由は、当時、実際に大規模なトラフィックとデータを運用している企業はほとんどなかったため、CSP にとっては実社会での経験を積む絶好の機会だったからです。こうした経験をもとに、CSPは急速な進歩を遂げました。
一方、クラウドサービスの利用とデータは増加し続け、さまざまなコスト削減の取り組みにもかかわらず、コスト上昇の現象が再び現れ始めました。最終的に、主要サービスを除き、MAU (月間アクティブユーザー数) が一定レベルを下回るか、収益貢献度が低いサービスのコスト削減圧力が高まりました。その結果、運用チームと開発チームは生き残るためにアーキテクチャとパフォーマンスの改善を集中的に検討するようになり、インフラストラクチャと開発の革新は限られた予算の制約の中で行われるようになりました。(業務も含まれていました)。
この時期から、ChatOpsの採用、EKSベースの高度な構造、Terraformの活用、外部SaaSソリューションの使用、サーバーレスアーキテクチャへの移行など、より高度なクラウドアーキテクチャへの本格的な移行を開始した組織もあります。パフォーマンスを確保しながらコストを削減しようとする取り組みは、文字通り「狂ったレベルの粘り強さ」でした。
それまでは、この組織はほとんどが数人の技術リーダーによって主導され、組織全体でクラウドの成熟度に大きなギャップがありました。しかし、この時期から、開発、運用、コスト管理の観点から、サービスオーナーの全体的な成熟度が急速に上昇し始めました。ダウンタイムゼロの運用、ユーザーからの苦情、新機能やソリューションの採用の失敗、運用上の失敗による深夜、財務チームからの要請など、絶え間ないプレッシャーの中、チームは生き残りを重視した真の戦略を策定し始めました。つまり、開発は運用重視のエンジニアリングへとシフトし始めたのです。
そして、私たちが前進し続けるうちに、私たちは資源と人的資源をいかに非効率的に使用していたかに自然に気づきました。その認識が、最終的に「無慈悲な自動化」と呼ばれるものへと私たちを導きました。これにより、自動化のための技術と運用の両方における本格的なイノベーションが始まりました。理由は単純でした。自動化しなければ、作業負荷は耐え難いものになり、最終的にはその重みで崩壊してしまうからです。
これらの苦労して得た経験は、生き残るためのより深い技術交流と、チーム間の冗談めかして「テックショーボート」と呼ばれるものにつながりました。それはやがて部門間の競争と圧力へと発展しました。チームは、「私たちの方がうまくやっている」、「より少ない人員で安定したサービスを運営している」、「より低いコストで運営している」などの主張で競争し始めました。
数年後、経営幹部の命令として、クラウドの大幅なコスト削減のための全社プロジェクトが開始されました。簡単に言えば、それは「支出が多すぎるからコストを削減する」という指令でした。これが本格的なFinOps活動の真の始まりとなりました。最初は圧倒されたように感じましたが、最適化、効率の向上、RI/SP の採用、EDP の交渉など、可能な限りの手段を講じました。
部署間の利害の対立によりイニシアチブが課題に直面したため、私たちは二面的な戦略を実施しました。まず、クラウドの専門家チームが結成され、各サービスのアーキテクチャを徹底的に見直しました。次に、財務チームは透明性の高いデータ収集を実現するために Finops のようなツールの使用を強制し始め、そのインサイトに基づいた診断作業を開始しました。
最初は、未使用のリソースを削除したり、適切なサイジング手法を適用したりするなど、一般的な方法で問題に取り組みました。これは典型的なFinOps手法です。しかし、組織のクラウドの成熟度が高まり、サービス品質に対する説明責任が高まるにつれ、これらの基本的なアプローチはやがて壁にぶつかりました。データがどれほど説得力があるように見えても、サービスに対する深い理解とオーナーシップを持つチームに直面した瞬間、コスト削減の圧力は勢いを失いました。
新しいアプローチが必要であることが明らかになりました。そこで、リソーススケジューリングとスポットインスタンス管理のための内部機能の開発を開始しました。これらの機能は、現在ほとんどのCSPが標準で提供している機能です。
これらのツールを検証するために、私たちは本質的に試験的なプロジェクトを立ち上げました。これは「犠牲の子羊」であり、物事がうまくいくかどうかをテストするためのベースラインデータの準備に3か月を費やしました。正直なところ、それがうまくいくかどうかは重要なポイントではありませんでした。私たちが本当に必要としていたのは、組織全体でFinOpsの採用を促進するための手段でした。短期間で堅実なソリューションを構築するために最善を尽くしましたが、ご存知の方も多いように、このような迅速な構築には下流での課題が伴うことが多く、安定させるには多大な忍耐が必要です。
それでも私たちは、カスタムビルドのスケジューリングシステムやスポットインスタンス管理機能 (当時の spot.inst のようなオープンソースツールから大幅に変更された) など、さまざまな最適化ツールを開発しました。その後、私たちのチームが社内で開発、運営しているプロジェクトで積極的にテストしました。3 か月にわたる徹底的な最適化の後、得られたデータを使用して他のチームにもツールを採用してもらいました。これはまた、サービスアーキテクチャの根本的な再設計と人員配置効率の評価にもつながりました。
これらの成功はFinOpsツールの功績を公に認めましたが、実際のコスト削減は、データ構造の変革、近代化の取り組み、労働力の再編など、より深いアーキテクチャの変更によってもたらされました。最終的に、この移行により、以前はクラウドサービス開発のみに注力していた私が、本格的な運用職に就くことになり、「攻撃者」の立場に移行するターニングポイントとなりました。
この経験から、組織全体を一度に移動する必要はないことに気づきました。その代わり、私たちはいくつかの主要チーム内で変化を推進することに重点を置きました。その成功事例をケーススタディとして、コスト削減の成果と予測モデルを上級管理職と財務チームに提示しました。次に、各部門長にコスト削減 KPI を割り当て、参加を効果的に義務付けました。診断チームは、クラウドサービスに関する深い専門知識の構築と技術的信頼性の確立に重点を置きました。この基盤をもとに、より上位の部署に合わせた戦略とツールを提供しました。このアプローチは、今日のFinOpsの核となる理念と密接に一致しています。
実際には、最も大幅なコスト削減は、FinOpsツール自体の使用によるものではなく、アーキテクチャの近代化や労働力の最適化など、それらのツールによって引き起こされたより広範な組織変更によるものです。私たちが直面した最も困難な課題の 1 つは、絶え間ない疑問でした。
「これはRI/SPよりも節約できるのか？」 そして 「このアプローチは、EDP割引よりも本当に効果的ですか？」
場合によっては、数字が実際には逆になり、従来の価格設定モデルと比較して悪い結果が見られました。しかし、本当に重要なのは現在ではなく、将来の構造変化によってもたらされる長期的なコスト削減でした。これが激しい議論につながり、賛同を求める激しい戦いが繰り広げられました。これらの変化の影響は徐々に明らかになってきました。
しかし、継続的な経営に裏付けられなければ、結果は簡単に崩壊する可能性があります。ワークロードを管理する適切なタイミングを逃すと、古い方法への回帰、技術的負債の蓄積、コストの不安定化につながる可能性があります。チームがそのような失敗を経験すると、不信感が引き継がれます。このような状況を経験した組織は、将来の FinOps イニシアチブ、特に外部から提案されるイニシアチブに強く反対する傾向があります。
ヨーヨーダイエットのようなものです。継続的な努力と規律がなければ、システムは回復します。これはFinOpsエコシステムにおける最も重要なポイントの1つです。
社内でどれだけうまくコストを管理していても、外部要因によって努力が意味をなさないことがよくあります。最も一般的な例としては、為替レートでしょう。
たとえば、2021年までに、効率の最適化と構造変更への取り組みにいくらかの見返りが見えてきました。しかし、通貨の変動などの要因により、こうした取り組みが希薄化されることもありました。
1か月あたり10億ウォンのコスト削減に成功した後、為替レートの上昇によりその節約分が逆転することがよくありました。その結果、コスト削減が実際に達成されたかどうかを疑問視する一方的な財務部門からのコミュニケーションが頻繁に発生することになります (このような状況では、レイオフという悪循環につながることがよくあります)。現在の世界経済の状況と韓国の為替レートの変動を考えると、同様のケースが再び見られるようになると思います。歴史は繰り返される傾向がある。
とにかく、これまでの話は過去の経験に基づいています。まとめると、それは常に指導部の危機感から始まり、それが圧力と説明責任を引き起こしているということです。組織が行動を起こさないと、KPI と予算の管理下で動き始めます。もちろん、自らをうまく管理している組織もあります。そのような場合は、外部のツールや方法を強制する必要はありませんでした。すでに素晴らしい仕事をしているので、その勢いを邪魔したり混乱させたりしないほうがよかったのです。
さらに、コスト分析、異常検出、推奨事項、リソース比較、マルチクラウド比較、パフォーマンス分析、ネットワーク診断などのさまざまな機能的手法が標準化され、問題に取り組む際の出発点として私たち全員に親しまれてきました。
それでは、過去の経験を踏まえて、実際にコスト削減がどのように行われているのかを見てみましょう。私たちはこのプロセスを本当に理解しているのでしょうか？ここから物語の始まりです。
前述のように、トリガーは常に存在します。それが経営陣によるものであろうと他の誰かによるものであろうと、誰かがコストとリソースの使用について懸念を表明します。運が良ければ、問題が指摘されたときにそれを正しく理解し、自発的に対応することができます。しかし、残念ながらほとんどの場合はそうではなく、人々は通常それを避けがちです。
その理由は明らかです。仕事が増え、批判される可能性があるからです。さらに、支出は簡単ですが、コスト削減は非常に難しいことは誰もが知っています。
したがって、このタスクは最終的に、実行する人、診断と分析を行う人、評価して決定する人の3つの基本的な柱を中心に展開します。これをさらに発展させると、FinOps Foundationが概説している現在のペルソナのように、役割はより詳細になります。
それでは、例を挙げましょう。
「今月の予算を 20% 削減しなければならないなら、まずクラウドのコストから始めましょう。」
このような指令が出たら、チームはまず何をしますか？
「過去 3 か月、6 か月、1 年間のクラウド支出データをすべて持ってきてください。」
通常、そこから始まります。実際にコストが増加したかどうかに関係なく、会話はデータから始まります。
この時点では、組織が単一のサービスを運営しているのか、複数の事業部門を運営しているのかによって、アプローチが異なります。
サービスが 1 つしかない組織の場合、最初のステップは、どのリソースが最もコストを消費しているかを分析することです。次に、「これを今すぐ実際に削減できるか」という疑問が浮かびます。
通常、データベースやネットワークの料金など、コストが高い領域は予測可能です。対策を講じるために、ほとんどのチームはまず未使用のリソースをチェックすることから始めます。しかし実際には、このアプローチによるコスト削減は、多くの場合、予想よりも小さいです。運が良ければ、管理されていない高価なリソースが見つかることもありますが、それは戦略というよりは運の問題です。
次はリストを生成する作業です。どのリソースを最新化できるか、つまり適切なサイズであるかを慎重に判断します。
「これを減らせば、いくらかコストを節約できたと言えるかもしれない」と考えてデータを掘り下げます。それを念頭に置いて準備を進めると、疑問が浮かび上がってきます。
「これではRI/SPのカバレッジが不足するのではないか？」
「EDPの条件を破り、不足分に見舞われたらどうなるでしょうか？」
「RI または SP はいつ期限切れになりますか?この変更を間に合うように行うことはできますか？」
このような懸念が持ち上がると、これまでの選択肢は難しすぎると感じ始めるので、プロダクション、開発など、使用しているすべてのアカウントを見直します。
順序は異なる場合がありますが、最終的にはすべてのアカウントが1つずつ審査されます。
アカウントがある程度整理されると、レポートは通常、誇らしげに次のようになります。
「このように削減を続ければ、効果的にコストを削減できます。」 これは通常の1次元のレポートです。しかし実際には、20% 以上削減するのは簡単ではありません。そして今、あなたは岐路に立っています。
「本当に不要なサービスを停止すべきか？」 または 「彼らに割り当てられた労働力を減らすべきか？」
しかし、いずれにしても、どちらの選択も簡単なものではありません。
そこで、開発と運用の両方の経験がある人は、ここで中心的な問題について考え始めるでしょう。
「これは収益と結びついているので、ROIの観点から、アーキテクチャや設計を再考すべきではないでしょうか？」
この時点で、開発と運用の構造的変化が始まります。この議論が行われなければ、最終的には「避けられないコスト支出」のグレーゾーンにとどまり、組織はその現状を維持し続けることになります。
__________________________________________________________________________________________________________________________________
複数のサービスを管理する組織の場合、フローは似ていますが、開始点は少し異なります。
ほとんどの組織は、次の質問から始めます。 「最も支出が多い組織はどれですか？」
このアプローチは、コストが最も高い組織とその管理責任者に直接つながります。たとえ高額な費用が正当化されたとしても、全体的な目標を達成するためには、比較的よく管理された組織が、最終的に削減されることもあります。
ほとんどの場合、リストの作成、リソースの整理、アカウントの確認など、前述のアプローチが採用されています。ただし、この場合でも、RI/SP 管理や特定の組織に対する好意といった運用上の違いが、チーム間の対立につながりやすくなります。実際、これらの問題はしばしば、責任が特定の人物に移る状況へとエスカレートします。
この時点で、組織はコスト配分構造の再評価を開始し、各部門の予算編成と配分の詳細について議論が始まります。もちろん、全員が不満を抱いているわけではありません。実際、一部の組織はこの変更を歓迎しているかもしれません。
____________________________________________________________________________________________________________________________________________________________________
しかし、開発と運用の両方の経験を積むと、根本的な疑問が生じます。これは収益に直接つながるため、ROIと、アーキテクチャや設計自体を根本的に削減する必要があるポイントがあるかどうかを検討することから始めます。この時点で、開発と運用の変化が始まります。そうでない場合は、「避けられないコスト支出」として残り、現在の状態が続き、長期的なグレーゾーンへと発展する可能性があります。
一方で、「やむを得ない経費支出」という口実のもと、そのような配慮をせずにそのまま現状を維持するだけでは、ますます根強いグレーゾーンに入り、問題はさらに複雑になるだけです。
____________________________________________________________________________________________________________________________________________________________________
上記のシナリオは、おそらく誰もが少なくとも一度は経験したことがあるものです。
変更を実施する部署は、物事を隠そうとしたり、頑張ったりするかもしれませんが、受け取り側は数字だけを見ることになります。彼らは努力を気にしません。数字が目標を達成するかどうかがすべてです。
この時点で、組織内に不調和が生じ始めます。
万全の努力にもかかわらず、数値のみに基づいて意思決定を行う場合、2つの選択肢になります。将来のコスト削減を見越して数値を膨らませるか、現在の状態を維持する方法を考え出すかです。
この時点で、組織は現在の状況に合わせてリソースとコストの分析を調整し始めます。
この例からわかるように、FinOpsはコスト削減だけではありません。むしろ、まずは、物事がうまく行っているか、適切なレベルの効率で運営されているかを評価することから始まります。目標は、現状を把握し、関係部署を納得させることです。このプロセスは、メビウスの帯状の連続したループのようなものです。
さて、絶え間ない疑問は、「適切な規模」、「未使用リソース」、「近代化」などのデータを使って、どの程度コストをかけているかを本当に評価できるかということです。
答えは「はい」です。
ただし、実行中のサービスにこれをすぐに適用できるかどうか尋ねられた場合、答えは「いいえ」です。これは、運用やサービスを担当していない部署にとっては話しやすい話題であることが多いです。
サービス業務は非常に保守的であり、業務で発生する問題には常に「責任」という重い言葉が伴います。単により多くのお金を使うほうが簡単だと感じることがよくあります。その結果、インフラの拡張によってコストが高くなるケースもあります。
このサイクルは繰り返されます。これを回避するには、サービス業務に影響を与えずにコストを節約するために、EDPやRI&SPなどを事前に購入するしかありません。さらに高度なシナリオでは、未使用のサーバーを営業時間外にシャットダウンするようにスケジュールしたり、スポットインスタンスのような安価なリソースに切り替えたりするなどの選択肢も検討されます。
ただし、これは依然としてサービス業務に関連する責任によって制約されています。もちろん、より成熟した組織では、これらの側面を自動化して、人々がより戦略的なタスクに集中できるようにすることができます。
次のアプローチは責任の割り当てです。コントロールであろうと投資であろうと、責任を担当部門に委任することが課題です。なぜ？それが一番簡単な方法だからです。「できないなら責任を取れ」と言うことほど便利なことはありません。じゃあ、どうやってやるの？Excel を使用して各リソースを 1 つずつ確認し、文書化して整理することができます。これは、リソースや組織が小さい場合に実行可能です。
これをうまく管理するために、すべてを明確に分類して管理するためのタグが導入されています。こうすることで、どの組織がリソースを効果的に使用しているかを分析しやすくなり、膨大な量のデータとはっきり区別できるようになります。
しかし、これがコスト削減に直接つながるかどうか尋ねると、答えは「はい」と「いいえ」の両方です。結局のところ、どのような行動をとるにしても、すべての行動には人間の関与が必要であり、個人がもはや責任がないと感じると、その努力は途中で放棄されることがよくあります。そこで、組織は KPI を結び付け、ミッションや予算管理と連携させるようになりました。適切な管理を行わなければ、これらのイニシアチブは無意味なものになりかねません。そのため、多くの組織は測定可能な成果に結び付けることに重点を置いています。
失敗につながるケースをたくさん見てきたので、焦点は組織内のパフォーマンスに移ります。そのような状況では、いかにコストを削減するかについて社内の議論が始まります。どうすれば最小限のコストでサービスを提供できるのか？運用管理を効率化するにはどうすればよいか？
そのためには、サービスに対する理解と、利用している資源がどれだけ高価であるかを認識することが必要であり、それが最終的に単位経済につながります。
そして、ある時点で、人間の効率性に関する議論が浮かび上がってきます。最終的には、誰かが責任を持って行動しなければなりません。しかし、責任を取るだけでは円滑な運営は保証されません。その人の権限や意欲によって、結果は異なります。さらに、これらの取り組みは短期的な場合もあれば、結果が出るまでに長い時間がかかる場合もあります。
ただし、組織文化が確立される前に組織的に動くことは難しいため、責任を分散させようとする傾向があります。ポジティブな見方をすれば、人は戦いたくないとき、「一緒に働いて協力しよう」と言う。しかし、ライバルになると、言い訳をするようになります。
これが、最近のFinOpsフレームワークがテクノロジーベースから企業の業績指標に焦点を当てるものへと移行している理由だと思います。
また、財務を担当する部門にとって、このデータと作業プロセスの信頼性を理解することは非常に重要です。予算計画と予測に基づいて、どの程度支出がうまく行われているかを組織に説得することがますます重要になっています。このデータの信頼性にもよりますが、各部署の自主性が高まる可能性があります。さらに、このプロセスが発展するにつれて、共通のミッションと実行を共有する部門間のコミュニケーションが最も重要な側面となるでしょう。
「うまく使うには理解する必要がある」ということわざがあります。サービスを開発、運用、管理する部門こそが、サービスを最もよく理解している部署です。先に述べたように、FinOps Foundationのフレームワークの最近の変化はこれを反映していると思います。つまり、あまり詳しくないと、なぜ何かがよく使われているのか理解できないということです。かつて「コスト」という言葉が出てきた時、財務的な観点からは経費削減の余地がありました。しかし、今日では、サービスを管理および開発するチームがそれを最も理解する必要がある主な理由の 1 つが、この点です。
つまり、FinOpsの前提の下では、さまざまな部門が表面的に廃棄物を特定して改善していますが、最終的には、ROIの観点からリソースをより効果的に使用するために、これを理解して改善する必要があります。この文脈では、FinOpsツールは、時間、労力、複数のユーザーを結びつける、共通の言葉でコミュニケーションするための基本的な手段だと思います。
支出額だけを見る人もいれば、専門用語のみに注目する人もいれば、KPIの達成数値だけに関心を持つ人もいます。しかし、これらの目標を達成するために使われる基本データはすべて同じです。それが何であれ、サービスの支払いは変わっておらず、これらのサービスの費用を計算するロジックも同じです。
OpsNowのように、FinOpsのツールにはそれぞれ異なる機能がありますが、これらの機能は1つの目的のために作成されたものと見なすべきではありません。その代わり、それらは統一された言語を提供する手段として機能する統合システムの一部です。これらのツールの機能の使い勝手は大きく異なり、生成されるレポートは各部門が追跡しようとしている内容によって異なる場合がありますが、最終的な目標は変わりません。それは、組織がリソースを効果的に使用しているか、改善の余地があるかどうかを組織が評価できるようにすることです。さまざまな観点から見ると、データはさまざまな方法で解釈される可能性がありますが、結局のところ、データはまとまりのあるストーリーを伝える必要があります。重要なのは、私たちがリソースを適切に使用していること、そして最も重要なのは、私たちが同じ言語を話していることについて、全員が同意していることを確認することです。
そのため、OpsNowは現在、組織のFinOpsの理解と導入を支援できる立場にあります。ツールの選択は二の次です。重要なのは FinOps の概念がどれだけ正確に理解されているかということです。FinOps を成功裏に導入するには、まず、組織が FinOps の原則をどの程度理解しているかを評価することが重要です。そうして初めて、このプロセスを促進する手段として何らかのツールを導入すべきです。
先ほどの個人的な例でも触れましたが、FinOps理論を知らなくても試してみました。その過程で数え切れないほどの失敗や成功を経験しましたが、今は「FinOps」という言葉で表現しています。ほとんどの組織にとっての問題は、理論的な知識の欠如ではなく、社内の経験、課題に取り組む意志、運用上の洞察、各サービスの中核に対する理解、チームの連携方法についての深い考察の欠如です。Google では理論はよく整理されていますが、理論を知って理解しているふりをするだけでは限界があります。
幸いなことに、OpsNowは、MSPの親会社であるBespin Globalを通じて遭遇した豊富な運用経験と顧客の要求に基づいて成長してきました。この基盤を土台に、OpsNowはFinOpsの分野で統一された声で話すことを目標に、進化を続けています。まだ長い道のりがありますが、プラットフォームは実社会での経験という貴重な資産のもと、サービスを着実に進化させています。
ただし、FinOpsの取り組みを社内で管理している人にとっては、特にコスト管理と効率が危機に瀕している場合には、FinOpsで働く人々のうち何人が開発に真に関与しているかを調べることが不可欠です。物事は順調に進んでいると言うのは簡単ですが、その経験を本当に経験した人と経験していない人の間には明らかなギャップがあります。
これまで、OpsNowのクラウドコスト削減の取り組みは、主に製品の機能を紹介することに重点を置いていました。しかし現在では、より深いものへと進化しつつあります。つまり、各機能の背後にある必要性と背景を明確に伝え、組織が信頼できるデータに基づいて有意義な行動を取れるようにするストーリーを構築するプロセスです。以前は機能主導型のソリューションでしたが、今では組織全体で共通の言語を話す統合サービスになりつつあります。理解と明確なコミュニケーションが技術的能力と同じくらい重要になる方向に向かっています。
私たちは岐路に立っています。そこで、効果的なクラウド分析、コスト管理、そして組織内の有意義な節約を可能にする環境を本当に構築したかどうかを自問することが重要です。製品やサービスを提供する観点からは、この分野に関する深い理解と実務経験が不可欠です。OpsNow FinOpsは、単に機能を紹介するだけではありません。FinOpsを十分に理解し、実践し、継続的に評価し、組織をその道のりに導くことが大切です。
FinOpsの基本的な出発点は、管理されていないクラウドコストを理解して管理することです。多くの組織は、コスト削減を最大化することを期待してFinOpsを採用していますが、実際には、FinOpsは中核的な必需品というよりはオプションのツールとして扱われることが多いです。実のところ、ほとんどの企業はすでにさまざまな方法でコスト削減策を実施しています。私たちが行っていることは、特にユニークでも例外的でもないかもしれません。
コスト削減にはさまざまな方法があります。クラウドサービスプロバイダー (EDP) との大規模な割引交渉、リザーブドインスタンス (RI) または貯蓄プラン (SP) の活用、リソースの最適化と効率改善の実施はすべて基本的なアプローチであり、これらはすべて FinOps ツールがなくても実行できます。場合によっては、単純に手作業に置き換えることもできます。しかし、これらのプロセスは、時間と労力、そしてビジネスドメインとサービスに対する深い理解によって支えられれば、はるかに効果的になります。組織に適切な能力があれば、サービス構造を再構築し、パフォーマンスを最適化することで、コスト効率と運用全体の両方を根本的に改善できます。
では、なぜFinOpsの理念が必要なのか、そしてOpsNowのようなツールが不可欠なのはなぜでしょうか。この質問には根本的な反省が必要です。クラウド環境がより複雑になり、組織の規模が拡大するにつれて、コスト管理はますます困難になります。多くの場合、責任が不明確になり、クラウドの利用が軽視されてしまうことがあります。クラウドのコストという性質上、問題は状況が悪化して初めて発見されることが多く、修正には多大な時間と労力が必要になります。FinOps が効果的に機能するためには一貫した取り組みが不可欠であり、それこそが FinOps がそもそも必要な理由です。FinOps は、そのような継続的な規律を始めるための基盤となります。
FinOpsでは、コストとリソースを定期的に監視できるため、問題の早期発見とリスクの最小化が可能になります。これは資源効率とコスト最適化への第一歩です。このプロセスでは、コストの流れを明確に理解するために、透明性の高いデータ管理、予算管理、ガバナンス、および包括的なレポートを組織内に用意することが重要です。この段階を超えて、FinOpsの本質は、効率的で体系的な管理のための方法論と協調的枠組みの構築にあります。
理想的な段階は、自動化を導入し、組織全体が統一された言語でコミュニケーションできるようにすることです。さらに、継続的なサイクルを確立する必要があります。1 回限りの作業であれば、FinOps や FinOps ツールは不要です。OpsNowのFinOpsは、単に機能を開発して「私たちにもその機能がある」と言うのではなく、継続的なアクティビティをサポートする方法でこれらの問題を解決することに重点を置く必要があります。
やるべきことはまだたくさんあり、取らなければならない道もたくさんあります。テクノロジートレンドは過去と比べて急速に変化しており、これらの変化に対応できるかどうかは私たち次第です。しかし、組織内の機能やテクノロジーだけにとどまらないものの本質を理解しなければ、AI のような最先端のツールを採用しても裏目に出る可能性があります。新しいAI時代では、私たちが追い越される逆転に直面するかもしれません。そして、これはすでに起こっていると思います。さらに、クラウドの成熟度が以前と比べて均等に発展している現在、高品質のサービスや製品で競争力を維持するには、まずこの本質を内部から深く理解する必要があります。
OpsNowは、国内のCMPの中でFinOpsのリーダーとしての地位を確立しつつあります。以前はテクノロジーのみに焦点を当てていましたが、さまざまなFinOps資格を取得し、FinOps認定プラットフォームを取得することで、実際のメッセージを効果的に伝える方法を反映したソリューションとサービスへと進化しました。
サービスが進化して便利になるにつれて、ほとんどの人は、以前とは異なり、物事の仕組みや実装方法を理解しなくなり、そのまま使用しています。前述のように、以前はリソーススケジューリングとスポット機能は基本的な機能ではありませんでしたが、現在ではデフォルトのサービスと見なされています。つまり、テクノロジーの進歩によりユーザーの利便性が向上した一方で、ユーザーは基盤となる操作を理解したり管理したりすることから遠ざかっています。クラウドサービスの利便性が向上した現在でも、人々は目に見えるものだけに集中する傾向があり、舞台裏で物事がどのように機能するのかを理解しようとすることはほとんどありません。これは、サービスプロバイダーである私たちが掘り下げる必要がある分野です。
知れば知るほど見えてくる。現在、AIがより便利になる世界に住んでいますが、これらのプロセスを理解し、正確な情報を提供する人々の役割は減少しています。OpsNow FinOpsの出発点はここにあると私は信じています。私たちが当たり前と思っていたことが、いつもそうだったわけではありません。RI/SPの自動管理が標準機能になりつつあるように、新しいサービス標準を作成して提供する必要があるのは私たちだと思います。
OpsNowがクラウドをさらに活用するのにどのように役立つのか知りたいですか？私たちはまさにそのものを手に入れました。
