Web業界の「あるある炎上事例」
司会者：では、板敷さんによる「炎上プロジェクト立て直しの風景」ということで発表を行ってもらいたいと思います。よろしくお願いいたします。
（会場拍手）
板敷康洋氏（以下、板敷）：はい。では、「炎上プロジェクトの立て直しの風景」としてお話しさせていただきます。よろしくお願いします。
板敷といいます。もともとフリーランスのエンジニア兼開発コンサルタントをやっていまして、プロジェクトの立ち上げや立て直しの手伝いをやっていました。
2013年にサイバーエージェントにサーバーサイドエンジニアとして入社して、今はエンジニアのマネジメントをメインにやっています。AbemaTVでは、開局前の障害対策とか負荷対策を担当してました。
今日は、炎上プロジェクト立て直しの事例を紹介していきたいと思っていますが、AbemaTVの話ではなくてですね。というのも、AbemaTVはあまり炎上していないので。
（会場笑）
優秀なエンジニアが忙しく働いているおかげで炎上していないので、とくに話すことはないんです。
ではなにを話すのかというと、過去経験した、いわゆる炎上系プロジェクトのなかから、よくある業務系のSIerの案件ではなく、Web業界の炎上事例みたいなものを主に紹介できればと思います。
炎上事例1：権力者の介入による現場の混乱
Web業界の開発は自社内で完結することが多い分、業務系のように契約みたいなものがはっきりしていません。その結果、柔軟ではあるんですけども、曖昧な部分が炎上に結びつくケースはあると思います。
風景その1として「権力者の厄介な介入」があります。あの、弊社ではないんですけれども（笑）。
（会場笑）
突然、上司から依頼があります。「開発中の某ソーシャルゲームの成果物を確認していたところ、iOSとAndroidで仕様が違う」「αバージョンでリリース予定の機能も違う」「iOSのみβリリース予定の機能が先に入っていて、逆にαリリース予定の機能が入っていない」「優先度が変わっている」……といった状況なので、整理して軌道修正を手伝ってほしいという依頼でした。そこで、なぜ仕様にズレが生じているのかを分析するためのヒアリングなどを進めます。
ふだんの開発風景には、（スライド）左側のプロデューサーやAndroidとiOSのエンジニアがいる開発チームがあります。当然サーバーサイドもいますが、ここでは省略しています。
右側には、チーフプロデューサーがいます。この方は過去ヒット作を生み出していて、社内的にはすごく権力がある。ふだんは介入してこないような感じです。そのため、いつも仕様はプロデューサーが決めて、それをエンジニアに共有しています。情報共有も一元化されているので、仕様のズレもなく、問題はとくにない。
ところが、このチーフプロデューサーが不定期で介入してくるというパターンがあります。知らない間に、不定期で成果物を確認して「まあ、今こんな感じなんだね」、気になるところがいくつかあると「ちょっと直して」と、直接指示がくる。
しかもチーフプロデューサーはiPhoneユーザーなので、iOSエンジニアにしか指示が来ない。iOSのエンジニアは「了解いたしました」と直す。
この仕様変更に関する共有が漏れているので、プロデューサーも把握していない。その間に、iOSとAndroidで仕様がズレる……と、大まかにはこんなことが起こっていました。
この状況を立て直すためにやったことは、シンプルなんですけれども、仕様の決定と伝達フローの整備ですね。あとは、定期的な成果物レビュー会の実施をやりました。
まず仕様決定・伝達フローの整備です。仕様は、プロデューサーとチーフプロデューサーの間で決定する。そして開発チームの窓口は、プロデューサーで1本化。これによって、直接チーフプロデューサーからエンジニアに（指示が）いくことはなくなり、結果すべての仕様と修正依頼は、プロデューサーからエンジニアへ伝わります。
まずはこれで1つ手を打ちます。そしてもう1つ、定期的な成果物レビュー会の実施をやりました。これはチーフプロデューサーの微妙なニュアンスが、直接エンジニアへ届くようにするためですね。
ただし、プロデューサーもその場に同席し、仕様変更の決定を行えるようにします。プロデューサーとチーフプロデューサーで仕様を決定するので、必ず同じ場で仕様に対する議論が行われるかたちを作りました。エンジニア間も同時に議論を聞くので、認識のズレもない。
表向きは定期的な成果物レビュー会という建前だったんですけれども、実際は、このチーフプロデューサー介入の場を意図的に作ることで、その影響を極小化しています。介入自体はどうしても避けられないので、ならば「ここで介入してください」という場を作りました。
この一連の立て直しで学んだことは、「意思決定と情報の集約は一元化しましょう」ということでした。
複数箇所で行うのは、やはり混乱のもとです。今回のように意思決定者が複数いる場合、最終決定は同じ場、同じタイミングで行うことが望ましい。
あと、決定した内容の情報集約を一元化して、どこに最新の情報があるかが誰でもわかる状態にすることも大切です。もう1つは「権力者とはうまく付き合おう」ということですね。今回みたいに介入が避けられない場合、影響を極小化、もしくは限定的にするなど、仕組みで解決する。
「権力者」だと少し言い方が悪いんですけれども、実際に過去いろいろ経験されてきていいアドバイスをもらえるので、それが現場に混乱をもたらさないように、仕組みで解決するのが大事だと思っています。
炎上事例2：クライアント都合で要件が増えていく
次の事例は、要件がいつの間にか進化する風景ですね。これも当然、弊社ではないです。
（会場笑）
これも突然の依頼で、少し業務系よりの話なんですけれども。
某アパレルチェーンの在庫管理システムがありました。これはウォーターフォールで開発を進めているんですが、詳細設計のほうで大幅に遅れています。「この状況を整理して、立て直し案を提出してほしい」「ちなみに、設立10周年記念に合わせるので、リリースタイミングは絶対に動かせない」という依頼が来ました。
どういう状況かと思ってクライアントに「在庫管理システムの設計が遅れていると聞いたんですけれども……」というと、「いや、在庫と連動したレコメンドサービスですね」とクライアント側から返答がありました。僕としては「あれ？ レコメンドサービスだっけ？ ちょっと聞いてたのと違うな……」と思うわけです。
もう少しくわしくユースケースを聞いたところ、まずお客さまが店舗で店員に在庫問い合わせをします。店員は対象商品の在庫と、同種類の色違い在庫、近隣他店の在庫情報を手元の端末で表示して見せる。
ここまではふつうなんですけれども、加えて「対象商品の在庫がある場合、ほかの在庫と組み合わせてトータルコーディネート一式を提示する」というユースケースを想定している。
この「店舗にある在庫を組み合わせたレコメンド」はめずらしいサービスなので、難易度も高いんじゃないだろうかと思いながらヒアリングを続けていると、どうも要件が変わってきているようでした。
まず最初の要件が、「お客さまから在庫の問い合わせが来たら、その場で迅速に回答したい」でした。対象商品の在庫に加えて、色違い在庫や近隣他店の在庫情報も回答する……いわゆる在庫管理のシステムですね。この時点で見積もりも終わって開発をスタートしたんですけれど、日が経つにつれてクライアント側にちょっとしたひらめきが生まれました。
（会場笑）
「手元に端末の商品詳細が表示されるのであれば、お客さまにも見てもらうといいんじゃないか」と、エンドユーザー向けにフラットデザインにしてほしいという要件に変わりました。
まだこれだけならよかったんですけど、もう1つひらめきまして……。
（会場笑）
その店舗の在庫情報が全部わかるのであれば、在庫だけで組み合わせて「旬のおすすめコーディネート」もセットで提案しよう……となったんです。この瞬間、在庫連動したレコメンドサービスの開発が決定してしまったんですね。
こういう感じで仕様が膨らむのはよくあることだと思うんですが、スコープクリープと思うんですけれども、これは完全に仕様が進化している。
ということで、やったことは「プロジェクトゴールの再設定」ですね。本来の目的は、「お客さまからの在庫問合せに迅速に回答する」です。そこで、本来の目的である在庫管理に注力。レコメンドは、第2期開発とすることにしました。
あとは、最初の開発でリリースしないものを決めることと第2期開発への引き継ぎですね。うまく軟着陸させないといけなかったというのはあります。幸い、このケースでは在庫システムもレコメンドシステムもいい設計で、お互いに干渉していない、疎結合なものになっていました。そのため、戻りはほぼ発生しなかったです。
そこで、レコメンド設計は区切りのいい段階までやりきって、第2期開発用に引き継ぎ資料として残し、いったん方向の軌道修正はできました。
このプロジェクトで学んだことは、「このプロジェクトでなにを解決したいのか、目的を常に考えよう」です。
言葉にすると当たり前のことなんですけれども、実際は微妙にずれていたり、仕様が少しずつ追加されたり、スコープが変わってきたりするというのは、かなり危険なフラグかなと思います。これは常に考えるべきことだと思います。
あとは、目的が変わるようであれば、そのまま工数を延ばさずに、仕切り直すか別プロジェクトとして切り離して、スコープを明確にすることが大事です。納期と品質を保たないといけないですし、当然ながら開発すればするだけお金もかかってきます。ならば、ちゃんと明確にスコープを定めたほうがいいです。
とくに今回のように、途中でクライアントから出てきたアイデアがいいものであればあるほど、そこをゴールとみなし、それ以下のアウトプットには物足りなさを感じてしまう。そもそも在庫管理システムでよかったはずが、レコメンドじゃないと物足りなさを感じてしまうので、あくまでゴールを常に明確にしようということです。
炎上事例3：大規模プロモにシステムが間に合っていない
次は、「大規模プロモーションの直前なのにシステムが落ちまくっている風景」です。これも突然なんですけれども……。
（会場笑）
某SNSサービスで、2ヶ月後に迫る年末年始に大規模プロモーションとしてCMを放送することが決まりました。
しかし、システムキャパに心配がある。今も高負荷で頻繁にダウンしているので、これを大規模プロモーションに耐えられるようにしたい。当時は1.5万くらいだったキャパを、100万同時接続くらいまで上げてほしい。
（会場笑）
ちなみにCM放送はもう決まったので、スケジュールは絶対に守らなきゃいけない。指示されたゴールは「100万同時接続」です。
このプロジェクトは、プロモーション規模の大きさからも社内の注目が高くて、「今、何万同時接続ですか？」と日々会う人会う人に言われて、僕は「5万です」と言うのが毎日つらかったです。
当初、「100万同時接続をやらねば」と調査するうちに、新たに次の2つのことがわかってきました。
まず1つ目が、耐障害性とか可用性に大きな問題があること。キャパシティ以前の話ですね。例えば、会員登録に関わる外部サービス障害時のバックアップがない。
具体的にいうと、認証でSMS認証を使っていたのですが、業者がわりと不安定で、それが落ちたときのバックアッププランみたいなものがない。もし落ちてしまうと、会員登録はできない状態でした。
2つ目が、特定機能の障害が起きると全体がダウンするという、わりと弱いつくりになっていました。
最後にそもそもなんですが、もしプロモーションが大成功したとしても、100万同時接続は到達しないというのがわかって……。
（会場笑）
これは当時のアクセス傾向とCM計画ですね。これだけ予算をかけるので、これくらいのユーザーの新規獲得ができそうだとわかるのですが、それを検証した結果、最大でも30万同時接続くらいだとわかりました。
新たに判明したこの2つを踏まえて行ったのが、さっきの話と一緒なんですけど「プロジェクトゴールの再設定」でした。
100万同時接続でしたが、やはりそれだけでは足りない部分と過剰な部分があります。耐障害性と可用性、性能性、この3つを大規模プロモーションに耐えうる状態にしようというゴールに決めました。
同時接続数は30万を目標とします。その代わり、耐障害性と可用性で問題のある部分の解消に取り組むことにしました。
ゴール再設定に伴う、プロジェクトスコープの再定義ですね。（スライドを指して）当時、こういった感じで考えました。 縦軸が性能性で、下の必要要件とあるのが30万同接（同時接続）です。30万同接は、絶対に必要。この赤の部分の過剰要件は30万から100万です。これは過剰です。
横軸は耐障害性と可用性を一緒にしましたが、必要要件と過剰要件とあり、最初はこんな感じでした。
（会場笑）
100万を目指すあまり耐障害性と可用性に必要なものをカバーできてなくて、ただ性能性だけを過剰に対応しようとしてました。
同時接続数は30万を目標として訂正する代わりに、浮いたリソースで耐障害性や可用性で問題ある部分の解消にあてました。
このプロジェクトで学んだことは、とくに今回のように、あらかじめ具体的に100万といったゴールが設定されている場合、盲目的にそれを信じがちなんですけれど「まずはそのゴールが最適かをちゃんと確認しよう」ということです。
局所的な問題にとらわれずに全体を俯瞰して、プロモーションを成功させるためになにをやるべきか整理して、見極めることが必要だと思いました。
あとは、炎上しているときほど、やること・やらないことの線引きを明確にする。今回のように、社内や周囲がいくら盛り上がっていても、現場だけは冷静でいることを心がける……といいますか。
正直なところ、100万同時接続という目標をを訂正したのは負けた感じがして、複雑な気分ではありました。ですが、「プロモーションを成功させることが一番大事だ」という結論になりました。
「組織的な要因」と「人間関係が原因」な炎上事例も
以上が、各事例でのまとめです。この3つの事例で学んだことは、まず、権力者のやっかいな介入がある場合は「役割分担＝責任範囲だ」ということを明確にすること。そうは言っても、うまく付き合わないといけない状況はあると思うので、うまく付き合いましょう。「介入の影響を局所化・限定的にして、いいアドバイスをもらいましょう」ということです。
要件がいつの間にか進化する場合は、プロジェクトのゴールを常に明確にして、それに沿った要件であるか意識します。ゴールが変わる場合は、別プロジェクトにしてスコープを明確にします。
大規模プロモーションの直前なのにシステムが落ちることが多い場合は、具体的なゴールが設定されていても、それが最適かどうかの確認を自分たちで責任を持って行います。炎上してるときほど、やること・やらないことの線引きを冷静に明確にすることが大事だと思います。
今回挙げたもの以外でもよくある炎上パターンには「組織的な要因」があります。主に「人間関係が原因でチームが崩壊」です。あとは、意外にあるのが「技術的な要因」ですね。実現しようと思っていたことができなかった、品質が上がりきらなかった……というものです。
当然、AbemaTVでも新しい技術にチャレンジしたので、そのへんで詰まってしまうことも多かったんです。これをやりきれなかった場合は、炎上してしまうのだろうと思います。
いろいろ炎上プロジェクトと呼ばれるようなものを見てきましたが、個人的に最悪の状態だと思うのは、「ゴールがブレて終わりが見えない」「今、自分がどこにいるのかがわからない」です。あとは「チームワークが崩壊」のどちらかだと思います。
例えば、いくら炎上してても、まだチームワークがよければ、コミュニケーションをとって助け合うことができます。逆に言えば、ゴールが明確で日々進捗がわかっていて、チームワークがいい状態だと、炎上が起こっても、ある意味「祭り」と捉えられなくもないです。
（会場笑）
とくにチームワークがよくてゴールが明確だと、なんとなくそういった雰囲気になるようなこともあると思います。そういう意味では、「AbemaTV」の開局前もある意味「祭り」だった。
（会場笑）
やっぱり炎上の要因にもよりますが、これだけはちゃんと押さえておきたいという点がしっかりしていれば、まだ救いはあると思います。
今回の発表が、炎上プロジェクトの防止と火消しに役立てればうれしいと思います。以上です。ありがとうございました。
（会場拍手）
どうやって現場に炎上を伝えるのか
司会者：ありがとうございます。いやー、Mでポジティブな締めくくりありがとうございます（笑）。
たくさん質問もあるかと思うので、質問の時間に入りたいと思います。質疑応答がある方は挙手を……ありがとうございます。ではお願いします。
質問者1：「100万人〜」のところなんですけれども。100万人の目標を立てた人は「100万人来るぞ」という自信を持って出していると思っています。そこで「30万人しか来ないよ」と言われても、ちょっと納得ができないと思うんですね。
そういったときにどのようなテクニックで納得をしてもらったのかみたいなところを聞かせてください。
（会場笑）
板敷：まず前提として「100万」という数値が1人歩きしていました。
100万人と100万同時接続は、違うじゃないですか。100万人が同じサービスを同時に使っているのと100万リクエストが同時に来るのとは違う、ということを数字を見せて、非エンジニアにも理解してもらえるよう、丁寧に説明しました。
質問者1：なるほど。わかりました。ありがとうございます。
司会者：ほかにもご質問ある方、挙手をお願いします。では前の方、お願いします。
質問者2：炎上しているときに、1人で全部やるのは無理だと思うんですけど。例えば、エンジニアに、「まずは炎上している箇所を解決してから、エンジニアリングしてくれ」ということもあるんですか？
板敷：そうですね。軌道修正はしないといけないのですが、それをできる環境をつくるために乗り越えないといけない部分もあると思うんです。「軌道修正をする」もゴールだと思うのですが、それに向かってちゃんと進捗していくために、みんなで認識合わせをすることも大事です。
質問者2：納得してない人と思うんですが、「軌道修正しますよ」と言えば、みんなやってくれるんですか？
板敷：第三者的な立場でプロジェクトに入ると、案外、現場エンジニアは話を聞いてくれるものだと感じています。というのも、自分がジョインするプロジェクトでは、「プロジェクト内でなんとか立て直そうと試みたけど、これ以上はなかなか難しい」という状況だったんですね。そういった意味で、比較的みなさんが第三者的な意見を納得して聞いてくれたのかなと思います。
質問者2：ありがとうございます。
司会者：ありがとうございます。ではもうそろそろお時間なので板敷さんの発表はこちらで終わらさせていただきたいと思います。最後に大きな拍手をお願いいたします。
（会場拍手）
