APIが用意されていないようなサービスは選択肢から真っ先に除外しましょう
APIが用意されていないサービスは選択肢から真っ先に除外しましょう この記事の内容 計算量（オーダー）の考え方を、ソフトウェアだけでなく業務運用にも適用すべきという話です 顧客数やコンテンツ数が増えると、手作業の運用は O(n²) 的に破綻することがあります 「とりあえず動けばいい」で最初の仕組みを作ると、後から運用する人が苦労します APIがあるサービスを選ぶことで自動化が可能になり、スケール問題を回避できます サービス・プロダクトを選定する際は、APIの有無を最初の判断基準にしましょう 計算量（オーダー）の話 今回は少し雑談ベースでお伝えします。話したいテーマは大きく2つあります。1つ目は作業や計算のオーダー（計算量）を考えましょうという話、2つ目はAPIを持っているサービスやプロダクトを必ず選択しましょうという話です。 どちらも当たり前すぎる話ではあるのですが、目の前の「とりあえず最初の一歩」だけを考えて「うまく動いているからこれでいいじゃん」となりがちな部分があるため、改めてお伝えしたいと思います。 まず、計算量やオーダーについての話です。ソフトウェアのアルゴリズムを勉強した方なら常識かと思いますが、愚直に処理を書いてしまうと計算量が O(n²) のオーダーになってしまうことがあります。 グラフで示すと、O(n)（線形） の場合は数が増えてもそれに比例してゆるやかに増加していきます。一方で O(n²)（二乗） の場合は、小さいうちはほとんど問題ありませんが、数が増えるにつれてあっという間に計算量が爆発的に増え、処理時間が膨大になっていきます。 ソフトウェア開発においては「良いアルゴリズムを選ぶ」「高速なアルゴリズムを採用する」というのが常識ですが、この考え方は普段のシステム設計や業務運用にも同じように当てはまります。 業務運用における「オーダー」の問題 わかりやすい例として、人間が手作業で運用をカバーするケースを考えてみましょう。 スケールしやすいケース（O(n) に近い） お客さんが1件増えるたびに決まった作業を1回だけ実施して、それで完結する場合、お客さんの数が増えてもその分だけ同じ作業をすればよいだけです。これはいわば O(n) のイメージ で、そこまで破綻しません。 スケールしにくいケース（O(n²) に近い） 一方で、次のような状況を考えてみましょう。 顧客数が増えると、既存のすべての顧客にも追加の作業が発生する コンテンツが更新されるたびに、すべての顧客にそのコンテンツを配布しなければならない 顧客数もコンテンツ数も両方増えていく このような場合、コンテンツを1つ更新するだけで「全顧客 × 全コンテンツ」の展開作業が必要になります。これは O(n²) 的に作業量が増えていく構造 です。 最初は顧客が1〜2件、10件程度であれば全く問題ありません。しかし50件になり、100件になると、手作業の量はものすごい勢いで積み上がっていきます。 「とりあえず動けばいい」が後から苦労を生む こうした状況は、最初に仕組みを作る人が、後で運用する人のことを考えないことで生まれがちです。 「とりあえずこれで動いているからいいでしょ」という状態で最初の仕組みを作ってしまい、その後どう変化していくか、数がどう変わっていくかを考慮しないまま設計してしまうのです。その結果、何年もその仕組みを使い続ける運用担当者が苦労することになります。 月次レポートの作成なども典型例です。管理するシステム数が増えるたびに作成するレポートの数が増え、さらにカスタマイズ要件が入ってきたらすべてのシステムに対してその変更を適用しなければならない——こうした状況が積み重なっていきます。 解決策はAPIのあるサービスを選ぶこと では、どうすればいいか。結論はAPIがあるものを使いましょうということです。 APIがあるということは、自動化ができるということです。人間が手作業でやっている作業は、APIがあればすべてプログラムに置き換えることができます。 逆に言えば、APIがないと人間がすべてを手作業でやることしかできません。 手作業を自動化しようとすれば、RPAのような話になってきます。RPAで自動化すること自体を否定するわけではありませんが、APIがある場合に比べて汎用性や安定性に課題が出てくることが多いです。 サービス選定時にAPIの有無を最初に確認すべき理由 サービスやプロダクトを選定する際、機能の豊富さや画面の使いやすさに目が向きがちです。しかし、APIが用意されているかどうかは最も最初に確認すべき条件の一つです。 APIがないサービスは、業務が拡大するにつれて必ず運用の壁にぶつかります。最初は小さな規模だから問題なく回っていたとしても、顧客数やデータ量が増えた瞬間に手作業の工数が爆発的に増え、人員を増やすか、仕組みを作り直すかという選択を迫られることになります。 そうした将来的なコストを避けるためにも、APIが用意されていないサービスは選択肢から真っ先に除外するという判断基準を持つことが大切です。 まとめ 計算量（オーダー）の考え方は業務運用にも当てはまります。 O(n²) 的に作業が増える仕組みは、規模が小さいうちは問題なくても、成長とともに必ず破綻します。 最初の設計が後から運用する人の苦労を決めます。 「とりあえず動けばいい」で作られた仕組みは、長期的に大きな負債になります。 APIがあるサービスを選ぶことで自動化が可能になり、スケールの問題を根本から解決できます。 サービス・プロダクトを選定する際は、APIの有無を最初の判断基準に置くようにしましょう。APIがないサービスは、原則として選択肢から外すくらいの意識が重要です。