背景
社内でツールを運用していると、次のようなやり取りが定期的に発生します。
「そのリンク、どこから取ってきました？」
「esa に貼ってあった URL、遷移できなくないですか？」
いずれも致命的な問題ではなく、業務が止まるわけでもありません。
そのため長い間、「まあ困るけど仕方ない」という扱いのまま放置されてきた類の問題です。
ツール自体は正しく動作している一方で、
URL を共有することが不安定、という状態でした。
画面や機能が増えるにつれて、
- 条件付きパラメータを含む URL が増える
といったことが日常的に起きていました。
大きな障害ではありませんが、
違和感だけが残り続ける状態です。
「ちゃんと作るほどでもない」問題への向き合い方
この手の問題を正面から解決しようとすると、だいたい次の案に行き着きます。
専用のリダイレクト API
管理画面
ルール化された運用
実際に要件を書き出し、構成図を描き、検討もしました。
しかし整理すればするほど、コストと問題の重さが釣り合わないことが明確になります。
URL のパターンは多くても十数種類
利用者は社内メンバーのみ
権限や認可は遷移先ですでに担保されている
重要なのは柔軟性より「迷わず使えること」
つまり、
解決策は軽くあるべきという性質でした。
ここで方針を切り替えました。
増えたら足せる
壊れにくい
説明しなくていい
「きれいに作る」のではなく、
雑でいられる構成を目指すことにしました。
URL を「人が読める形」に戻す
やりたかったこと自体は非常に単純です。
esa や Slack に貼ったときに
見ただけで用途が分かり
間違えにくいこと
そのために用意したのは、次のような形式の URL です。
/共通パス/[用途]?意味のあるパラメータ
設計方針は以下の通りです。
[用途]でリンクの種類を明示するパラメータ名は省略せず、人が読める名前にする
内部で既存の複雑な URL に変換する
プロジェクト指定、メンバー指定、複数条件の集約なども、
そのまま貼っても安心できる URLとして扱えるようになりました。
AI の使い方
この仕組みを作る過程で AI も利用しましたが、
コード生成と設計の壁打ち役として使っています。
具体的には次のような点を確認しました。
サーバーは本当に必要か
静的な構成で完結しないか
設定ファイルに逃がせる部分はどこか
同じ歪みを将来また生まないか
長く放置された問題は、
「前提」だけが固定されたままになっていることが多いです。
それを一つずつ疑う相手として AI を使いました。
結果として、
実装は最小限
設定追加で拡張可能
既存運用に自然に混ざる
という形に落ち着きました。
「また増やして」と言われても破綻しないために
こうした改善で避けたいのは、
一度整えた結果、触りづらくなることです。
そのため、次の点だけは意識しました。
触る場所は 1 箇所に集約する
書き方に迷わない構造にする
実装者以外でも触れる
完成度よりも、
雑に増やせる余白を優先しています。
社内ツールは、その方が長く生きます。
まとめ
今回の仕組み自体は目立つものではありません。
ただ、
esa に貼るときに迷わなくなった
Slack で説明文を書く頻度が減った
それだけで十分な効果がありました。
長く存在してきた不便さは、
派手に改善するよりも
考えなくていい状態に戻すことで解消されることがあります。
社内改善とは、新しいものを足すことではなく、
見て見ぬふりをしてきた違和感を片づけることなのかもしれません。
