内部ツールの年

コードと座標に戻る Geocodioのエンジニアリング 内部ツールの年 Geocodioがbashスクリプトからフル内部アプリへと移行した経緯、それらを保守可能に保つシステム、そして構築と購入の線引きについて。 2026年9月 Mathias Hansen エンジニアリング AI Geocodioでは、プロセスを自動化し、自社でツールやヘルパーを構築して時間と効率を節約することが常に重要でした。約10年間、Geocodioは私たち二人だけでした。自動化は、それが可能になった大きな要因です。これらのツールは長年にわたり、数え切れないほどの時間を節約してくれました。 開発環境をセットアップしたり、ジオコーディングに必要な特定のデータファイルをダウンロードしたりするローカルbashスクリプト。ロードバランサーの健全性をチェックしたり、データを同期したりするインフラスクリプト。オンプレミスリリースプロセスを、より少ない手動ステップと人為的ミスの余地で、迅速かつ効率的にする小さなスクリプト。 より大きなものの一つは、AI時代のはるか前に登場しました。私たちは独自のデプロイメントツールを構築しました。デプロイメントプロセスを視覚化するため、デプロイがどの程度進んでいるか、現在何がライブになっているかを簡単に確認できます。何か問題が発生した場合、それを見てロールバックできます。デプロイメントの凍結や、手動プロセスではるかに煩雑で透明性の低い多くのことを処理します。 デプロイメントツール。 パブリッククラスターの各ノードには、実行中のリリースがマークされており、デプロイダイアログでスコープを選択し、結果をSlackに投稿できます。 これらの小さなスクリプトやヘルパー、さまざまなツールは長年にわたり役立ち、肯定的な影響を与えてきました。しかし、2026年の現在、そして私たちが今できることと比較すると、それはかすんでしまいます。 何が変わったのか 今年は内部ツールの年です。私たちは、あちこちで小さなbashスクリプトを作成したり、LaravelでArtisanコマンドを実行したり、レポートを生成するコードを含む小さな独立したリポジトリを作成したりすることから、野心を高め、フル機能の内部アプリを作成できるようになりました。モバイルフレンドリーで、優れたUX、素晴らしいテストカバレッジを備えています。 それを可能にしたのは、AIとフロンティアモデルの登場であり、これらはこれまで以上に高いレベルで構築することを可能にしました。 正直に言うと、当初はこれらのより大きなプロジェクトに着手することに躊躇していました。より大きく、より野心的なアイデアの常に障害となっていたのは、構築そのものではありませんでした。AI以前でも、数日で素晴らしい内部ツールをいくつか作成できたかもしれません。しかし、その後のメンテナンスの負担があります。メンテナンスしなければならない、動作させ続けなければならない、最新の状態に保たなければならない、見つけたバグを修正しなければならないということを考えなければ、ツールを作り続けることはできません。 それがコインの裏側であり、AIが解決を可能にした側面でもあります。AIを使ってメンテナンスにも追いつくことができるので、これらの内部ツールをすべて構築し、メンテナンスすることについて心配していません。 今では、そのためのシステムがあります 私たちは、新しい内部ツールを迅速にスキャフォールドして作成できる特定のシステムを導入する段階に達しました。最近、Tailwind CSSトークンと共有Reactコンポーネントを含むconsole-uiパッケージをリリースしました。これにより、これらの内部アプリは、それぞれが独自のものを成長させるのではなく、1つのコンポーネントライブラリを共有します。 また、AIに関する十分な経験を積み、これらのツールに強力な基盤を与えるための確固たる原則をいくつか確立しました。これにより、長期的に構築できるようになります。 作業に着手する前に、かなりの量の計画を立てること。 多くのリサーチ、まず概念を証明するエンジニアリングスパイクを含む。 Matt Pocockの素晴らしいGrill Meスキルを使用して、弱点が見つかるまで計画を徹底的に検証する多数のGrill Meセッション。 UIモックアップのイテレーション。これは驚くほど多くの質問に答え、実際のものを構築する前に問題を解決します。 Fableのような強力なモデルを計画プロセスで使用し、構築しているものが、持続可能で適切に設計された方法で、私たちが解決しようとしている問題を解決していることを確認します。 それに加えて、これらのプロジェクトのために高品質な内部基準も構築しました。テスト、CI、静的コード解析、認証のベストプラクティスなどです。 時間もそこに費やされます。計画と仕様には数週間かかります。実装には数時間または数日かかります。これらのアプリの中には、数年前に検討していたものもあり、仕様は主にメモや会議で収集したものをプロジェクトに変換する作業でした。Atlasが最も明確な例です。それは長年私の頭の中にあり、仕様が存在すれば、構築は迅速な部分でした。 すべてのツールには独自のドキュメントが付属しています これらの各ツールには、完全なドキュメントサブサイトがあります。ツールの使用方法と各機能の動作方法に関する実際のガイドで、スクリーンショットと例が含まれています。 Bullpenのドキュメントサブサイト。 すべてのツールには1つあり、ユーザーガイドと内部ドキュメントに分かれています。その多くはAI生成されており、少なくとも最初のドラフトはそうです。それでも、すべてのツールに一貫性があるのは非常に良いことです。READMEよりも、ツールが何をするのか、そしてそれらをどのように使用するのかをはるかに良く伝えます。 また、予期していなかった問題も解決します。数週間かけて大きな仕様や計画を書いていたとき、構築したものから離れてしまうことがあります。ドキュメントを書くことで、それが再び焦点に戻ります。 これらのリポジトリのすべてには、CLAUDE.mdに、ドキュメントに影響する変更はClaudeが関連部分を更新、追加、または削除する必要があるというルールがあります。まだ時々人間の目が必要ですが、物事を最新の状態に保つための確固たる基本ルールです。最新でないドキュメントは役に立ちません。 これはAtlasリポジトリのルールで、わずかにトリミングされています。 CLAUDE.md ### 両方のセクションをアプリと同期させてください 実質的な変更を加えるたびに、同じ変更でドキュメントを更新する必要があります。 ユーザーが見える変更はユーザーガイドに記載されます。アーキテクチャ、開発ワークフロー/ツール、インフラストラクチャ、デプロイメント、統合、パイプライン/ジョブ/スケジュール、スケジュールされたコマンド、デプロイ/シークレットの変更、またはEnvironment APIコントラクトのバンプへの変更は、内部ドキュメントに記載されます。 多くの変更は両方に影響します。 - **動作の変更** → そのものが現在どのように機能するかを説明するように、関連するページを編集します。古いスクリーンショットマーカー、手順、クラス名、パス、コマンド、または主張を残さないでください。 - **新機能または新しい保守者向けインターフェース** → そのセクションのディレクトリに新しい.mdファイルを追加し、対応するDocsManifest定数にそのスラッグとタイトルを登録します。マニフェストは、どのページが存在するか、その順序、およびサイドバーのグループ化に関する単一の真実の情報源です。 - **機能の削除** → ページとそのマニフェストエントリ、および他のページからのすべての内部リンクを削除します。 - **名前の変更/移動** → ファイル名とマニフェストの両方でスラッグを更新し、内部リンクを修正します。 私たちが構築したもの 私たちは今、独自のカスタマーサポートプラットフォームを構築するなど、より大きな課題に取り組んでいます。 カスタマーサポートのためのAtlas。 構築が完了し、現在展開中です。 スプリントの管理、整理、計画のためのBullpen。 ペーパーカットのためのコーディングエージェントYak。Slack、Linear、Sentry、GitHubから小さなタスクを取得し、レビュー用のプルリクエストを作成して返します。Yakはオープンソースなので、誰でもダウンロードして独自のレポに対して実行できます。 私たちのデプロイメントツール。 コンプライアンスプラットフォームでは対応できない部分をカバーし、結果をプラットフォームにプッシュするコンプライアンスツール。 Treehouse。これにより、各gitブランチに独自のワークツリーと独自のdocker-composeスタックが与えられるため、複数のブランチまたはエージェントセッションがポートを衝突させることなく同時に実行できます。これもオープンソースです。 Linearから入ってきたタスクを完了した後のYak。 リクエスト、変更点の概要、ステップバイステップのアクティビティログ、および結果の記録されたウォークスルー。 インフラストラクチャエンジニアは、インフラストラクチャを管理し、依存関係のCVEを処理し、G上のCDジョブの上に定期的なメンテナンスを容易にするためのツールも開発しています。