「遅い」って何分？数値なき要件定義がもたらす炎上プロジェクトの悲劇

今日はちょっと昔話から始めます。

もしかすると、これは特定の業界だけかもしれませんが、いわゆる「炎上プロジェクト」の火消しサポートに入ると、揉めている原因のほとんどがある一つの共通点に集約されます。

それは、定量的な数値目標が決まっていないことです。

要件定義のフェーズにおいて、画面の挙動や業務フローといった「機能要件」ばかりが重視されすぎている現場をよく見かけます。その一方で、運用性や保守性といったオペレーショナルな側面である「非機能要件」や「アーキテクチャ特性」が蔑ろにされてしまうことは往々にして存在します。インフラアーキテクトとしては嘆かわしい事実です。

数値を定めないままテストフェーズに突入し、実際の動きを見たお客様と開発側の間で致命的なギャップが生まれる。これが私の体験してきた大炎上の典型的なパターンなのです。

「動けばいい」では済まない、アーキテクチャ特性に潜むノックアウト要因

なぜ非機能要件の数値を決めることが重要なのでしょうか。理由はシンプルで、非機能要件には「テクノロジーの限界によるノックアウト、実現不可能な状態」が現れやすいからです。

極端な話、機能的な未実装であれば、力技でコードを書けば期限までに帳尻を合わせられることも少なくありません(できないこともたくさんあるよ!!)。しかし「現在の予算とテクノロジーでは物理的に不可能な数値」を後から突きつけられてしまうと、どれだけ優秀なエンジニアが集まってもシステム構造上どうにもなりません。

要件定義や顧客交渉の本質とは、テクノロジーの選択によって何がトレードオフになるのかを見極める作業に他なりません。数値を一つ忘れるだけで、それまでの努力がすべて水泡に帰す恐怖がここにはあります。

わたしが直面した「DB切り替えが遅い！」という大炎上の記憶

わたしが以前に担当した炎上プロジェクトのサポートで、今でも鮮明に覚えている事例があります。それは、冗長化構成を組んだデータベースで、障害発生時の切り替え時間が「遅い」とお客様からクレームが入った事象でした。

ここでまず疑問が浮かびます。「遅い」とは、一体何分何秒を指しているのでしょうか。

残念なことに、要件定義書には「〇分以内の切り替え」といった目標値が一切書かれていませんでした。そのため、お客様側の最も声の大きい担当者の一存で「とにかく遅いから早くしろ！」と突き上げられていたわけです。

当時の技術的な背景をお話しすると、今のようにストレージをリアルタイムで同期するような仕組みは極めてレアケースでした。共有ディスクを使用した「切り離し(デタッチ)と再接続(アタッチ)」による切り替えが標準的だった古い時代のお話です。そのため、感覚的に数分から十数分かかるのはごく自然なことでした。

インフラエンジニアの視点からすれば、障害時にきれいにデタッチできないトラブルも多かったですし、アタッチする際にはストレージのチェックが走るため、容量が大きければ大きいほど時間がかかるのは「分かっていたこと」でした。もし当時、秒単位での超高速な切り替えを求めるのであれば、もっと莫大なコストをかけて別の特殊な仕組みを構築しなければならなかったのです。仕組みとしては存在していましたが、コストの桁が変わるレベル。

このときは、サポートに入ったわたしが真っ先に「結局、目標時間は何分ですか？」と定義し直しました。そこから逆算して、障害検知の時間を見直し、一部のパラメータ調整や仕組みの根本的な改善を行うことで、なんとか難を逃れることができたのです。

プロフェッショナルとして、顧客とともに抜け漏れのない数値目標を紡ぎ出す

「業界の常識だから言わなくても分かるだろう」という甘えは、システム開発において最も危険な罠だと言えます。

たとえば、災害対策において「データセンターは500km以上離すのが標準だよね」という都市伝説のようなお話を耳にすることがあります。しかし、現時点でFISCの安全対策基準には、そのような具体的な数値距離は謳っていません。企業自身が「何のために、どれほどの距離を持たせる必要があるのか」を、リスクに基づいて主体的に定めなければならないのです。

こうした数値目標を、知らぬ間に「裏の制約条件」として勝手に設けられてしまうと、プロジェクトは後半で確実に破綻へと向かいます。

ある程度の経験を積んだインフラエンジニアであれば、IPAが提唱する「非機能要求グレード」などをベースにして、抜け漏れなく数値を定めていく重要性を肌感覚で理解しているはずです。逆にお客様が言わなかったからといって「要求範囲外です」と逃げていては、お互いにハッピーな結末は迎えられません。

お互いにプロフェッショナルであるならば、両者で知恵を出し合い、抜け漏れのない目標数値を一緒に作り上げていくことこそが本来あるべき姿です。機能の実装よりも、このアーキテクチャ特性のトレードオフを上流工程できちんと見定められるナレッジこそが、これから「も」エンジニアに最も求められている能力です。