banken運用が組織事情で行き詰まった話

背景

数年前から社内プロダクトでbankenを採用し、他案件でも同じレールで権限管理を組んできました。cancancanやpunditの文化圏にいるRailsエンジニアにとって馴染みのあるDSLで、導入スピードも学習コストも申し分なく、当時の意思決定は間違っていなかったと今でも感じています。

導入初期は順調だった

• プロダクトごとにポリシーを共通化でき、複数サービスを横断するチームでも再利用が効いた
• ロールを追加するだけで新しい部署向け機能を素早く開放できた
• コード内で完結するため、エンジニアリングチームだけで運用を回せた

中小規模のチームで、リリースサイクルを重視していた時期はこの設計で十分でした。問題は、プロダクトだけでなく組織側の要件が膨らんでいったときに発生しました。

現場で生じた運用課題

取締役会・監査向け資料の整備

誰がどの機能を使えるのかを一覧化する資料を四半期ベースで作成する必要が出てきました。bankenの定義はわかりやすいものの、コードから人が読める形に落とす作業は手間が大きく、棚卸のたびにエンジニアが付きっきりになる状況が続きました。

組織改編に追従するロール管理

部署の統廃合やチーム編成の変更が頻繁に起きると、ロールの名前・粒度がすぐに陳腐化します。実態とズレたロールが増えると「誰向けの権限なのか」が曖昧になり、結果的に重複ロールや暫定ロールが増殖していきました。

人事異動と兼務が前提の利用シナリオ

新しいメンバーが都度入ってきたり、別部署に異動しても兼務を続けたりと、個人単位で必要な機能がめまぐるしく変わります。「この人は来週からこの機能を触れるようにONにしてほしい」「一時的にOFFに戻してほしい」といった細かなリクエストは多くないものの、発生するたびにロール定義をいじるのは現実的ではありませんでした。結果として、ロールベースの仕組みでは表現しきれないケースが増え、局所的な権限パッチが積み上がる一方でした。

業務フローとコードの乖離

現場で求められる機能セットは"画面/帳票/連携APIの組み合わせ"で語られるのに対し、bankenは"アクションを許可する"視点に寄っています。経営企画やCSが把握したい単位とコードが一致せず、権限運用が次第にブラックボックス化していきました。

運用破綻と判断見直し

このような非技術的な課題が蓄積し、権限棚卸や資料作成のために本来の開発リソースを圧迫し続ける状態になりました。銀行業界のような厳格なロール管理ではなく、中小規模の組織変動や属人的な運用が日常的に起こる環境では、bankenだけで完結させるのは現実的ではないと判断しました。

「設計が間違っていた」というより、組織側の要請が変化した結果としてbankenでは解決できない領域が増えた、というのが実感です。

Feature Flagへ切り替えた理由

最終的には、機能単位でON/OFFを制御できるFeature Flag運用へ舵を切りました。

• Flag一覧をそのまま共有すれば、エンジニア以外もどの機能が誰向けかをすぐ確認できる
• 異動や兼務が起きても、Flagの割り当てを変えるだけで日常運用を回せる
• Rails側の実装は「Flagが有効なら表示する」というシンプルな分岐で済む

Flagのライフサイクルを管理する手間は増えましたが、権限の棚卸しや意思決定プロセスがコードから分離され、運用のボトルネックが解消されました。

学び

• 技術選定は正しかったとしても、組織や業務プロセスが変われば前提は崩れる
• 権限情報をコードに閉じ込めると、資料化や棚卸しでエンジニアに過度な負担がかかる
• 日々のちょっとした入れ替わりに付き合うなら、Feature Flagのように機能粒度で管理できる仕組みの方が運用をシンプルに保ちやすい

既存コードに残るbankenの利用箇所は段階的に整理し、新規プロダクトでは採用しない方針です。誰がどの機能を使えるのかを日常的に見えるようにするため、Feature Flagファーストの設計を基本に進めていきます。