ある製造業の情報システム部門で、新しい在庫管理システムの新機能を金曜日の夕方にリリースした。月曜の朝、全国の営業所と工場の現場担当者が一斉にログインすると、今まで慣れ親しんだ画面が急に変わり、入力手順も変わっていた。電話が鳴り止まない。「出荷登録ができない」「表示が崩れて数字が読めない」「昨日までの操作と違いすぎて仕事にならない」。情報システム部門の担当者は朝から詫びの電話をかけ続け、昼過ぎには経営陣の判断で機能を緊急停止することになった。開発に半年かけた機能は、公開からわずか半日で取り下げられ、現場の信頼も少なからず傷ついた。こうした光景は、決して特殊な話ではない。新機能を全利用者に一度に公開するという、ごく当たり前に思えるやり方そのものに、実は大きなリスクが潜んでいる。
なぜ新機能の一斉公開はリスクが高いのか
新機能を全社員や全顧客に同時に公開するやり方には、共通して三つの弱点がある。
一つ目は、全利用者に同時に影響が及んでしまうことだ。もし新機能に不具合や使い勝手の問題があった場合、それに気づくのも、被害を受けるのも、全員が同時になる。一部の部署だけで試すという猶予がないまま、いきなり全社が当事者になってしまう。
二つ目は、問題が起きたときに切り戻す手段がないことだ。多くの現場では、新機能をリリースするとそのままシステムに組み込まれてしまい、元の状態に戻すには開発会社に緊急対応を依頼し、修正版を作ってもらうしかない。その間、業務は止まったままになる。
三つ目は、現場の反応を見ながら調整するということができないことだ。実際に使ってみて初めて分かる使いにくさや、想定していなかった業務フローとのずれは、事前のテストだけでは拾いきれないことが多い。しかし全員に公開してしまうと、様子を見ながら少しずつ手直しするという余地がなくなる。
これを放置するとどうなるか
この課題に向き合わないまま新機能のリリースを繰り返すと、社内には「新しい機能はまずトラブルが起きるもの」という空気が根づいてしまう。現場は新機能のアナウンスが来るたびに身構えるようになり、便利な機能であっても使うのを避けるようになる。開発側も、失敗を恐れてリリースの頻度を落とし、結果として本来もっと早く現場に届けられたはずの改善が、何ヶ月も先送りされていく。一斉公開で一度でも大きな失敗を経験した組織ほど、この悪循環に陥りやすい。
フィーチャーフラグとは何か、何を解決するのか
この問題を解決する仕組みが、フィーチャーフラグと呼ばれる考え方だ。フィーチャーフラグとは、新機能に一つひとつスイッチをつけておき、そのスイッチのオン・オフによって、誰にその機能を見せるかをコントロールできる仕組みのことをいう。難しく聞こえるかもしれないが、実際にやっていることは、新商品を出す前に試験販売をしたり、限定エリアで先行導入したりするのと同じ発想だ。
コード修正なしでオン・オフを切り替えられる
通常、システムの機能を止めたり戻したりするには、プログラムを書き換えて、再度システム全体を作り直して配信し直すという作業が必要になる。これには時間もコストもかかる。フィーチャーフラグを使えば、管理画面のスイッチを切り替えるだけで機能の表示・非表示を変えられる。いわば、店舗の棚に商品を並べるか並べないかを、レジ横のスイッチ一つで決められるようなものだ。
一部の部署・店舗・顧客だけへの先行公開
新商品をいきなり全国発売せず、まずは特定のエリアや一部の店舗だけで試験販売してみるように、新機能もまずは一つの部署や一部の店舗、あるいは希望する顧客だけに先行して公開できる。実際に使ってもらいながら反応を見て、問題がなければ徐々に対象を広げていく。この段階的な広げ方こそが、フィーチャーフラグの一番の価値だ。
問題が起きた際に即座に元に戻せる安全弁
試験販売中の商品にクレームが相次いだら、すぐに棚から下げて仕切り直すのと同じように、フィーチャーフラグをオフに戻すだけで、その機能を一瞬で非表示にできる。プログラムの修正や再配信を待つ必要はない。何かあってもすぐに引き返せるという安心感があるからこそ、開発側も思い切って新しい挑戦をしやすくなる。
発注時に確認すべきポイント
システム開発を依頼する際は、次のような点を開発会社に確認しておくとよい。新機能のリリースに際してフィーチャーフラグの仕組みを標準的に使っているか。公開範囲を部署や店舗、顧客単位で柔軟に指定できるか。フラグのオン・オフを切り替えるのに開発会社への依頼が毎回必要なのか、それとも自社の担当者が管理画面から操作できるのか。また、フラグを戻したときに過去のデータや設定に不整合が起きないかどうかも、事前に確認しておきたい点だ。見積もりの段階でこうした話が一切出てこない場合は、一斉公開が前提になっている可能性があるので、遠慮せず尋ねてみてほしい。
現実的な進め方
フィーチャーフラグは、大がかりな仕組みを新たに導入しなければ使えないというものではない。まずは影響の大きい新機能のリリースからでよい。最初の一週間は情報システム部門やごく一部の店舗だけに公開し、問題がなければ翌週にはエリアを広げ、さらに問題がなければ全社に公開する。こうした段階を踏むだけでも、冒頭のような混乱を防ぐことができる。すべての機能に最初から完璧なフラグ管理を求める必要はなく、まずは影響範囲の大きいものから、小さく試して確かめながら広げるという発想を持つことが何より大切だ。
壁を越えて働く人たちへ
新しい挑戦には、必ず不確かさがつきまとう。だからといって挑戦をやめてしまえば、現場も会社も前には進めない。フィーチャーフラグは、失敗を恐れて立ち止まるためのものではなく、小さく試し、確かめながら、それでも前に進み続けるための道具だ。一斉公開の失敗に懲りて新しい挑戦そのものを避けるのではなく、慎重に、しかし着実に一歩を踏み出す。そうやって現場と向き合いながら壁を越えていく人たちを、オルアナはこれからも支えていきたい。