内部ツールの年

内部ツールの年

Geocodioがbashスクリプトからフル機能の内部アプリへと移行した経緯、それらを保守可能に保つシステム、そして「構築」と「購入」の線引きについて。

Geocodioでは、時間を節約し、より効率的になるために、プロセスを自動化し、独自のツールやヘルパーを構築することが常に重要でした。ほぼ10年間、Geocodioは私たち二人だけで運営されていました。自動化は、それが可能になった大きな要因の一つです。

これらのツールは、長年にわたり私たちに数え切れないほどの時間を節約してくれました。開発環境をセットアップしたり、ジオコーディングに必要な特定のデータファイルをダウンロードしたりするためのローカルbashスクリプト。ロードバランサーの健全性をチェックしたり、データを同期したりするインフラスクリプト。オンプレミスのリリースプロセスを、手動の手順を減らし、人的ミスの余地を少なくして、より迅速かつ効率的にする小さなスクリプト。

AI時代のはるか前に登場した、より大きなものの一つがありました。私たちは独自のデプロイメントツールを構築しました。これはデプロイメントプロセスを視覚化するため、デプロイがどの程度進んでいるか、現在何が稼働しているかを簡単に確認できます。何か問題が発生した場合は、それを見てロールバックできます。デプロイメントの凍結や、手動プロセスではるかに煩雑で透明性の低いものになる多くのことを処理します。

デプロイメントツール。パブリッククラスターの各ノードには、実行中のリリースがマークされており、デプロイダイアログでスコープを選択し、結果をSlackに投稿できます。

これらの小さなスクリプト、ヘルパー、さまざまなツールは、長年にわたり役立ち、良い影響を与えてきました。しかし、2026年の現在、私たちができることと比較すると、それはかすんでしまいます。

何が変わったか

今年は内部ツールの年です。私たちは、あちこちに小さなbashスクリプトを作成したり、Laravelでartisanコマンドを使ったり、レポートを生成するコードを含む小さな独立したリポジトリを使ったりすることから、野心を高め、本格的な内部アプリを作成できるようになりました。モバイルフレンドリーで、優れたUX、素晴らしいテストカバレッジを備えています。

それを可能にしたのは、AIとフロンティアモデルの登場であり、これらは以前よりもはるかに高いレベルで構築することを可能にしました。

正直に言うと、当初はこれらのより大きなプロジェクトに着手することに躊躇していました。より大きく、より野心的なアイデアの邪魔になるのは、常に構築そのものではありませんでした。AI以前でも、数日で素晴らしい内部ツールのようなものを作り出すことができたかもしれません。しかし、その後のメンテナンスの負担があります。メンテナンスしなければならない、動作させ続けなければならない、最新の状態に保たなければならない、見つかったバグを修正しなければならないという事実を考慮しなければ、ツールを作り続けることはできません。

それはコインの裏側であり、AIが解決を可能にした側面でもあります。これらの内部ツールをすべて構築し、メンテナンスすることについて心配していません。なぜなら、AIを使ってメンテナンスにも追いつくことができるからです。

システムができました

新しい内部ツールを迅速にスキャフォールドし、作成できる特定のシステムが整っている段階に達しました。最近、console-uiパッケージをリリースしました。これにはTailwind CSSトークンと共有Reactコンポーネントが含まれているため、これらの内部アプリはそれぞれが独自のものを成長させるのではなく、単一のコンポーネントライブラリを共有します。

また、AIに関する十分な経験を積み、これらのツールに強力な基盤を与えるための確固たる原則をいくつか持っています。これにより、長期的に構築できるようになります。

• 作業に着手する前に、かなりの量の計画を行うこと。
• エンジニアリングスパイクを含め、まず概念を証明する多くのリサーチを行うこと。
• Matt Pocockの素晴らしいGrill Meスキルを使用して、弱点が見つかるまで計画を徹底的に検討する数多くのGrill Meセッションを実施すること。
• UIモックアップを繰り返し検討すること。これにより、実際のものを構築する前に、驚くほど多くの質問に答え、問題を解決できます。
• Fableのような強力なモデルを計画プロセスで使用し、構築しているものが、持続可能で適切に設計された方法で、解決しようとしている問題を解決していることを確認すること。

それに加えて、これらのプロジェクトには高品質な内部標準も構築しました。テスト、CI、静的コード解析、認証のベストプラクティスなどです。

時間もそこに費やされます。計画と仕様には数週間かかります。実装には数時間または数日かかります。これらのアプリの中には、数年前に考え始めていたものもあり、仕様は主にメモや会議にあったものを収集してプロジェクトにまとめることでした。Atlasが最も明確な例です。それは何年も私の頭の中にあり、仕様が存在すれば、構築は速い部分でした。

すべてのツールには独自のドキュメントが付属しています

これらのツールのそれぞれには、完全なドキュメントサブサイトがあります。ツールの使用方法と各機能の動作方法に関する実際のガイドで、スクリーンショットと例が含まれています。

Bullpenのドキュメントサブサイト。すべてのツールには、ユーザーガイドと内部ドキュメントに分かれたものがあります。

その多くは、少なくとも初期ドラフトはAIによって生成されています。それでも、すべてのツールに一貫性があるのは非常に良いことです。READMEよりもはるかにうまく、ツールの機能と使用方法を伝えています。

予想外の問題も解決します。数週間かけて大きな仕様や計画を作成していると、構築したものとのつながりを失うことがあります。ドキュメントを作成することで、それが再び焦点に戻ります。

これらのリポジトリのそれぞれには、CLAUDE.mdに、ドキュメントに影響する変更にはClaudeが関連部分を更新、追加、または削除する必要があるというルールがあります。まだ人間の目が必要な部分もありますが、最新の状態を保つための堅実な基本ルールです。最新でないドキュメントは役に立ちません。

これはAtlasリポジトリからのルールで、軽くトリミングされています。

構築したもの

私たちは、独自のカスタマーサポートプラットフォームの構築など、より大きな課題に取り組んでいます。

• Atlas：カスタマーサポート用。構築済みで、現在展開中です。
• Bullpen：スプリントの管理、整理、計画用。
• Yak：ペーパーカット（些細な問題）のためのコーディングエージェント。Slack、Linear、Sentry、GitHubから小さなタスクを取得し、プルリクエストをレビューのために返します。Yakはオープンソースなので、誰でもダウンロードして独自のレポで実行できます。
• 私たちのデプロイメントツール。
• コンプライアンスプラットフォームで対応できない部分をカバーし、結果をプラットフォームにプッシュバックするコンプライアンスツール。
• Treehouse：各gitブランチに独自のworktreeとdocker-composeスタックを提供し、複数のブランチまたはエージェントセッションがポートで衝突することなく同時に実行できるようにします。これもオープンソースです。

Linearからのタスクを完了した後のYak。リクエスト、変更点の概要、ステップバイステップのアクティビティログ、結果の記録されたウォークスルー。

私たちのインフラエンジニアは、インフラストラクチャを管理し、依存関係のCVE（共通脆弱性識別子）を処理し、GitHub Actions上のCDジョブで定期的なメンテナンスを容易にするツールも開発中です。これは、上記のメンテナンスのポイントをよく示しています。一部のツールは、他のツールを健全に保つために存在します。

サポートプラットフォームを自社で構築する価値

自社で構築する最大の利点は、ワークフローとデータに非常にうまく統合できることです。

現在、1人の顧客を支援するには、必要な情報を得るために3つまたは4つの異なるツールにアクセスする必要があります。現在のサポートツール。管理ツールが2つあり、1つはセルフサービス用、もう1つはエンタープライズ用です。請求ツール。分析。セルフサービスとエンタープライズの両方の顧客がいるため、ほとんどの企業よりも複雑な状況になります。

サポートプラットフォームを自社で構築する目的は、これらすべてを1つの場所に集めることです。顧客に応対する担当者は、その顧客の状況、アカウントの種類、最近の出来事を、Geocodioのワークフローに合わせて最適化されたUIで正確に把握できます。彼らは必要な情報とアクションを指先で操作できるため、問題をより迅速に解決できます。

構築しないもの

これらすべてが、使用しているすべてのSaaS製品を独自のツールに置き換えることを意味するわけでも、数十もの新しい内部アプリを構築することを意味するわけでもありません。限界があり、「社内にあるべきもの」と「既製品で十分なもの」の間には明確な線引きがあります。

メールはBentoのままで、それに満足しています。独自のメールインフラストラクチャを実行することは、私たちにとって意味のない責任です。リスクが高すぎ、経験もありません。Twilioはコミュニケーションワークを担います。社内でSlackを書いていません。市場には多くの優れたツールがあります。

次の3つの質問が、それを私たちにとって明確にします。

1. このドメインに実際の経験がありますか、それとも実務で学ぶことになりますか？
2. このシステムが1日ダウンした場合、ビジネスはどうなりますか？
3. 価値は、独自のデータやワークフローとの統合から生まれますか、それとも既製品のツールでも同じように機能しますか？

ツールがメンテナンスしやすくなったからといって、50個ものツールを引き受けることができるわけではありません。それらを構築する方法については、慎重かつ思慮深くある必要があります。だからこそ、共有インフラストラクチャ、共有UI、共有原則の上にそれらを構築し、メンテナンスを容易にし、可能な限りコードを共有できるようにしています。また、マイクロ内部ツールサービスアーキテクチャを作成しようとしているわけでもありません。アイデアが浮かぶたびに新しいサービスを発明するのではなく、機能セット全体をカバーするツールを求めています。

構築するすべてのツールは責任です

そのトレードオフは毎回現実であり、忘れがちなのはアップタイムです。内部ツールも信頼性がなければなりません。変更をデプロイして何かを壊したために、1日中カスタマーサポートのリクエストに応答できなくなったら、私たちのビジネスはどうなるでしょうか？

最近、その小さな味を経験しました。アドレスデータをインポートして操作するための内部ETLツールがあります。それを大幅にアップグレードしましたが、デプロイメントに関するいくつかの問題を解決している間に1日利用できなくなりました。この場合、それは「明かりを灯し続ける」ことには影響しませんでした。もし同じことが忙しい日にAtlasに起こっていたら、話は違っていたでしょう。

その日は、意図的に行ったトレードオフの結果でした。これらのツールにはステージング環境がありません。すべての内部ツールのステージング環境は、実行し続け、同期し続けるためのもう一つのものです。そして、私たちだけが使用するツールの場合、そのコストを支払う価値はないと判断しました。変更は本番環境にデプロイされ、ローカルQA、テストカバレッジ、CIが、ステージングが本来持つべき重みを担います。ETLの停止は、その決定がうまくいかなかったときの姿であり、私たちはそれを行ったときにそれを受け入れました。

責任のもう半分はアクセスです。Atlasは顧客アカウントや請求情報を見ることができるため、誰がそれにアクセスできるかは、それが稼働しているかどうかと同じくらい重要です。これらのツールを自社でホストする大きな利点の1つは、それらが完全にプライベートネットワーク内に存在することです。パブリックインターネットからは一切到達できません。サインインページがロードされる前にVPNに接続する必要があり、その後で通常の認証ルールが適用されます。

現状

将来どうなるかはわかりません。大量の内部ツールを維持することになったり、ツールを作るためだけにツールを作成したりしないように注意する必要があります。

しかし、これらのツールが私たちの仕事をより良く行い、効率を高め、手動プロセスからの人的ミスの可能性を減らすのに役立つなら、より良い製品を構築し、顧客に優れた体験を提供し、チームの生活の質を向上させることができます。

もしあなたの会社でこれを考えているなら、小さく始めてください。毎週手作業で2つのツールの間のギャップを埋めているプロセスを見つけ、それを閉じるものを作成してください。そこで最も早く価値を得られ、SaaS製品をゼロから再構築する必要があるとは誰も信じないでしょう。