リーンスタック ―― なぜ私たちは大きなフレームワークではなく、「退屈で」目的特化のツールを選ぶのか

プロジェクトのキックオフでは、ほぼ必ずと言っていいほど「あの大きなフレームワークを使おう」という提案が出る瞬間があります。専用のカンファレンスがあり、認定資格コースがあり、「エンタープライズ」プランがあり、「これ一つで何でもできる」と謳うスライドがある、あのフレームワークです。そして多くの場合、それを選ぶことこそが、プロジェクトにおける最初の静かな過ちとなります。

十年以上にわたってエンタープライズ向けソフトウェアを提供してきたなかで、私たち Simplico には明確な志向があります。それは、目の前の課題を解決する、最も小さく、最も退屈で、最も目的に特化したツールを選ぶ、という姿勢です。最も高機能なものでも、最も人気のあるものでもありません。二年後に私たちが守り続けなければならない「面積」が最も小さいもの、それを選びます。

これは、ミニマリズムを気取っているわけではありません。反対の選択肢と実際に長く付き合ってきた末に、たどり着いた立場なのです。

「退屈」とは、実際に何を意味するのか

「退屈」と言うとき、それは古いとか時代遅れという意味ではありません。予測可能である という意味です。退屈なツールは、その名前が示すとおりのことを概ね行い、理屈で説明できる形で壊れ、深夜二時にあなたを驚かせたりしません。PostgreSQL は退屈です。一枚の紙で説明し切れるメッセージキューも退屈です。一つのことだけを行う 300 行の FastAPI サービスも退屈です。

退屈なツールには、いくつかの共通点があります。第一に、その障害モードは十分に文書化されています。あなたより前に、何千ものチームが同じ壁にぶつかってきたからです。第二に、抽象化が浅く、必要なときにソースコードを読んで理解できます。そして決定的に重要なのは、そのツールを運用するなかで培った知識が他へ応用できることです。Postgres のインデックスは、ERP の裏側にあろうとベクトル検索の裏側にあろうと、同じように振る舞います。

一方、「刺激的な」ツールは、この三点すべてが逆になります。障害モードは目新しく(おめでとうございます、その不具合を最初に報告するのはあなたです)、抽象化は深いため、デバッグとは自分で書いていない層を一枚ずつ剥がしていく作業になります。そして得られる専門知識は応用が利かず、そのツールを使わなくなった日に消えてしまいます。

フレームワークは「平均的な」課題を解く。しかし、あなたの課題は平均的ではない

大きなフレームワークとは、「あなたの課題が、その作者たちの想定した課題と同じ形をしている」という賭けにほかなりません。実際にそうである場合、フレームワークはまるで魔法のように働きます。設定ファイル一つの手間で、認証も管理画面も ORM もマイグレーションも、その他何十もの機能も手に入るのです。

問題は、クライアントの実際の業務が、その賭けの中心に位置することはめったにない、という点です。それらは往々にして「縁」に位置します。そしてこの縁において、フレームワークが与えてくれたあらゆる利便性は、こんどはあなたが闘わなければならない制約へと変わります。抜け道は使い勝手が悪く、フレームワークの考える「正しいやり方」は、あなたのやり方と合致しなくなります。こうしてあなたは、クライアントが対価を支払って依頼したまさにその仕事を、フレームワークに「させてもらう」よう説得することに、貴重なイノベーションの予算を費やすことになるのです。

私たちは、バックグラウンドジョブに関するフレームワークの「意見」や、リクエストのライフサイクルに関する前提と格闘することに、退屈なものを自前で書く以上の時間を費やすチームを、いくつも見てきました。フレームワークは作業を省いてくれたのではありません。作業を先送りにし、利息を付けて請求してきたのです。

これこそが、私たちの志向の核心です。目的特化のツールは、あなたの課題について置く前提が少ない。ゆえに、前提が外れる確率も低いのです。

私たちが実際に線を引く場所

この哲学の誠実な姿は、「大きなツールが勝つ」場面を認めることも含みます。実際、明らかにそうである場合もあるからです。私たちが実際にどう判断しているかを、ここに記します。

FastAPI を Django より優先する ―― ただし常にではなく、多くの場合において。 私たちの仕事の多くは、AI ミドルウェア、連携レイヤー、内部 API といった、無駄のない小さなサービスです。これらにとって、FastAPI の小さな表面積はまさに最適です。私たちの soc-integrator ミドルウェア ―― Wazuh を DFIR-IRIS、SOAR プラットフォーム、そしてページング通知へとつなぐ要の部品 ―― が焦点の絞られた FastAPI サービスであるのは、まさにそれが単一の役割だけを担い、インシデント対応の緊張下でも容易に理解できる必要があるからです。とはいえ、プロジェクトが Django の 得意とするもの を真に必要とするときには、私たちは喜んで Django を手に取ります。すぐに使える管理画面、成熟した ORM のマイグレーション、実在するユーザーとセッションを抱えるコンテンツ中心のアプリケーションなどです。過ちは Django を使うことではありません。反射的に使い、そのうえでその半分にも手を付けないことです。

中小規模の工場には SAP より ERPNext を。 製造業のクライアントが ERP を必要とするとき、会議室では最大手ベンダーの名前を挙げたくなるのが常です。しかし中小規模の工場にとって、重量級のエンタープライズ・スイートは、彼らが決して使わない機能のための、ライセンス費用とコンサルタントへの依存の塊にすぎないことがほとんどです。彼ら自身がホストし、カスタマイズし、真に所有できるオープンソースの ERP のほうが、投じた一バーツあたりに動くソフトウェアを多くもたらすのが通例です。導入、ホスティング、研修、二年目の保守という総所有コストの観点でも、この規模ではほぼ常に、より軽量な選択肢に分があります。

専用ベクトルデータベースより pgvector を。 RAG(検索拡張生成)システムには流行りの答えがあります。専用のベクトルストアを立てる、というものです。しかし私たちが構築するものの大半において、それは運用し、保護し、バックアップし、同期を保ち続けねばならないインフラがもう一つ増えることを意味します ―― しかも、すでに動かしている データベースで処理できる課題のためにです。埋め込みを他のデータの隣の Postgres に格納し、意味的検索と字句的検索を一つのエンジンで組み合わせれば、理解すべきシステムは二つではなく一つで済みます。専用ストアを手に取るのは、スケールが真にそれを要求するときだけ。そしてそれは、喧伝されるほど頻繁には起こりません。

商用 SIEM よりオープンソースのセキュリティツールを。 六桁(ドル)の商用 SIEM ではなく、Wazuh と OpenSearch の上に SOC スタックを構築することは、予算上の妥協ではありません。これも同じ原理です。すなわち、私たちが中身を検査でき、バージョン管理でき、クライアントの実際の検知ニーズに合わせて形作れるツールであること。そして、ギガバイト単位のライセンス課金メーターに、アーキテクチャ上の判断を代わりに決められてしまわないこと、です。

ここにある共通のパターンに注目してください。問われているのは「最も高機能なツールはどれか」ではありません。「この課題に能力が見合った、かつ私たちが完全に所有できる、最も小さなツールはどれか」なのです。

「表面積」が複利で積み上げる代償

採用するツールはどれも、システムの寿命が尽きるまで抱え続ける負債です。パッチを当てねばならず、CVE(脆弱性)を抱え、次のエンジニアにとっての学習曲線があり、いつか必ず壊れるアップグレードの道のりがあり、いつか必ず要件と衝突する「意見」を持っています。

小さなスタックは、構築が容易なだけではありません。生かし続ける コストが、はるかに安いのです。三年が経つころ、十分に理解された四つの構成要素から成るプロジェクトは健全なままですが、十四の構成要素を抱えたプロジェクトは、誰も引き受けたがらない保守の重税と化します。私たちはその三年目のために設計します。私たちのクライアントにとって、その三年目こそ、ソフトウェアが対価に値すると証明するか、あるいは誰もが触るのを恐れる代物へと静かに成り果てるかの、分かれ目だからです。

採用には、人材面の側面もあります。広く知られたツールから成る無駄のないスタックであれば、次のエンジニアは ―― 私たちのであれ、クライアントのであれ ―― 数か月ではなく数日で戦力になります。難解なフレームワークは、それを理解する特定の人物への難解な依存を生みます。退屈なツールは、チームの「バス係数」を健全に保つのです。

私たちがこの方針を採らないとき

この哲学にも失敗のかたちがあり、それを無いふりをするなら、私たちは何かを売りつけていることになるでしょう。

度を超せば、「リーン」は車輪の再発明に堕します。もし私たちが毎回、認証も ORM もマイグレーションの仕組みも管理画面も自前で書くなら、それは一行ずつ、より劣ったフレームワークを築いているにすぎず、回避したと称した表面積の代償を、ただ人知れず支払っているだけです。フレームワークの存在意義はまさに、一部の課題は本当に「平均的」であり、それらに対しては、共有され、実戦で鍛えられた解決策こそがリーンな選択である、という点にあります。

ですから原則は「常に小さなツールを」ではありません。「ツールを課題に合わせよ。そして、どの課題が本当に標準的なのかについて誠実であれ」です。ログインの仕組みは標準的な課題であり、実証済みのものを使うべきです。一方、クライアントのレガシーな機械コントローラと現代的な ERP とのあいだの特注の連携は、標準的な課題ではありません。それを差し出してくれるフレームワークなど存在せず、あると思い込むことは、あなたと仕事のあいだに一枚、層を増やすだけです。

肝心なのは、この二つを見分ける規律です。そして、ツールを正当化していた前提が真でなくなったとき、そのツールを削除する潔さです。

まとめ

退屈で目的特化のツールは、私たちが甘んじて受け入れる制約ではありません。意図して選び取った、競争上の優位性です。それらは、私たちが理屈で理解でき、より速く納品でき、きれいに引き継げ、そして何年にもわたって安く生かし続けられるシステムを生み出します。

次にキックオフで誰かがあの大きなフレームワークを提案したとき、問うべきは「これでこれができるか」ではありません。ほとんど何でも、ほとんど何だってできるのですから。問うべきは「これと、これから三年付き合うために、私たちは何を支払うことになるのか」です。そしてあなたが思う以上にしばしば、その答えはこうなります ―― 退屈なツールが求めたであろう代償より、多くを、と。

それが、私たちが繰り返し続けている賭けです。そして今のところ、三年目は、私たちが正しかったと証明し続けています。