AbemaTV Developer Conference 2016

炎上プロジェクトの立て直しの風景2016.10.15 AbemaTV Developer Conference

@yasitashiki

● 板敷康洋 (Yasuhiro ITASHIKI)

● フリーランスのエンジニア兼開発コンサルタントとして、プロジェクト立ち上げや立て直

しの手伝いなど

● 2013年、(株)サイバーエージェントにサーバサイドエンジニアとして入社

● 現在は、エンジニアリングマネジメントをメイン

● AbemaTVでは、開局前の障害対策／負荷対策を担当

自己紹介

今日話すこと

炎上プロジェクト立て直しの事例を紹介していくのですが、

AbemaTVの話はありません！

AbemaTVはあまり炎上してないですから。

では何を話すのか

過去経験した炎上プロジェクトの中から、

よくある業務系のSIer案件ではなく、

Web業界の炎上事例を主に紹介したいと思います。

Web業界の開発は自社内で完結することが多い分、

業務系のように契約等がはっきりしておらず、

柔軟な反面、あいまいな部分が炎上に結びつくケースがあります。

風景その1

権力者の厄介な介入がある風景

それは突然の依頼でした。

● 現在開発中の某ソーシャルゲーム

● 開発中の成果物を確認したところ、iOS/Android間で仕様が違う。

● また、αバージョンでリリース予定の機能も違う。

○ iOSのみβリリース予定の機能が搭載されている、逆にαリリース予定の機能

が入っていない

● 状況整理し、軌道修正を手伝ってほしい。

依頼(初期情報)

なんで仕様にずれが生じているのか調べた。

普段の開発風景

プロデューサ

iOSエンジニアAndroidエンジニア

開発チーム

チーフプロデューサ


プロデューサ


普段は介入してこない。複数PJかけもち。

開発チーム

過去ヒット作を産みだしてしており、社内権力者。



プロデューサ



開発チーム

仕様はプロデューサが決める。チーフプロデューサ



プロデューサ


仕様の共有


開発チーム

仕様はプロデューサが決める。

仕様の共有




プロデューサ


仕様の共有


開発チーム

仕様はプロデューサが決める。

仕様の共有

仕様のずれなし

普段は仕様の決定、情報共有が一元化されており問題ない。




チーフプロデューサが介入してくる風景

プロデューサ


開発チーム



プロデューサ


開発チーム

(不定期で成果物を確認)

ほほぅ、今こんな感じで作ってるのか


プロデューサ


開発チーム

サクッと修正して。

成果物を見たチーフから

エンジニアに直接修正指示。

(しかもiOSのみ…)



プロデューサ


開発チーム





了解いたしました！



プロデューサ


開発チーム






プロデューサは把握していない



プロデューサ


開発チーム






プロデューサは把握していない

共有漏れ

仕様ズレ


やったこと

● 仕様決定、伝達フローの整備

● 定期的な成果物レビュー会の実施

仕様決定、伝達フローの整備

● 仕様はプロデューサとチーフプロデューサの間で決定する。

● 開発チームの窓口はプロデューサとする。


プロデューサ


開発チーム

仕様決定、伝達フローの整備

● 仕様はプロデューサとチーフプロデューサの間で決定する。

● 開発チームの窓口はプロデューサとする。

● 全ての仕様、修正依頼はプロデューサからエンジニアへ。


プロデューサ


仕様の共有

開発チーム

仕様の共有

仕様のずれなし

● 仕様決定、集約場所が明確に

● エンジニアへの情報伝達フローを一本化

定期的な成果物レビュー会の実施

● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。

○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。

○ プロデューサも同席することでその場で仕様変更の決定を行えるようにする。


プロデューサ


微妙なニュアンスを直接伝える

定期レビュー会






プロデューサ


同時に聞くことで認識のずれなし


その場で仕様変更決定







プロデューサ


同時に聞くことで認識のずれなし


その場で仕様変更決定

チーフプロデューサ介入の場を意図的に作ることで、介入の影響を局所化した。


学んだこと

● 意思決定、情報の集約は一元化しよう○ 複数箇所で行うのは混乱のもと。意思決定者が複数いる場合、最終決定は

同じ場で行うことが望ましい。

○ また決定した内容の情報集約も一元化し、どこに最新の情報があるか分かる

状態にする。

● 権力者とはうまく付き合おう○ 介入が避けられない場合、影響を局所化する、限定的にするなど仕組みで

解決する。

風景その2

要件がいつの間にか進化する風景

● 某アパレルチェーンの在庫管理システム

● ウォーターフォールで進めているが、詳細設計で大幅に遅れている。

● 状況整理し、立て直し案を提出してほしい。

● ちなみにチェーンの10周年に合わせるのでリリースタイミングは絶対動か

せない。


自分：「在庫管理システムの設計が遅れていると伺ったのですが」

クライアントとの初回やりとり



クライアント：「えーと、在庫と連動したレコメンドサービス、ですね」



クライアント：「えーと、在庫と連動したレコメンドサービス、ですね」

自分：「レコメンドサービス？(聞いてたのと違うな・・・)」

お客様店員

在庫問合せする

基本的なユースケース

店員


店員

対象商品の在庫、同種類の色違い在庫、近隣他店の

在庫情報を手元の端末で表示して見せる。


お客様

お客様

店員


店員

対象商品の在庫、同種類の色違い在庫、近隣他店の

在庫情報を手元の端末で表示して見せる。

お客様店員

対象商品の在庫がある場合、他在庫と組み合わせた、

「トータルコーディネート」一式を提示。


お客様

お客様

店舗にある在庫を組み合わせたレコメンドとは珍しいサービスだなと思いヒアリングを続けていると・・・

クライアント

お客様から在庫の問い合わせが来たら、その場で迅速に回答したい。

対象商品の在庫に加え、色違い在庫、近隣他店の在庫情報も回答したい。

要件進化の過程

この時点で見積もり終わり開発スタート。

クライアント

クライアント



手元の端末に商品の詳細な画像も表示されるなら、お客様に見てもらえばより購

入に結びつくかも！


エンドユーザ向けにデザイン刷新が決定！


クライアント

クライアント



手元の端末に商品の詳細な画像も表示されるなら、お客様に見てもらえばより購

入に結びつくかも！

店舗の在庫情報が全部わかるのであれば、在庫だけで組み合わせた

「旬のおすすめコーディネート」をセットで提案したい！

クライアント


エンドユーザ向けにデザイン刷新が決定！

在庫連動したレコメンドサービスの開発が決定！


「これは・・・スコープクリープなんて甘いもんじゃなくて仕様の進化・・・ッ」

やったこと

● プロジェクトゴールの再設定

○ 本来の目的である在庫管理に注力。レコメンドは第二期開発とすることにし

た。

○ 本来の目的「お客様からの在庫問合せに迅速に回答する」

● やらないことの停止。第二期開発への引き継ぎ。

○ 幸い在庫、レコメンドシステムともいい設計で、戻りはほぼ発生しなかった。

○ レコメンドの設計は区切りのいい段階までやりきり、第二期開発用に引き継

ぎ資料として残した。

学んだこと

● このプロジェクトで何を解決したいのか？目的を常に考えよう○ 仕様が少しずつ追加される状態は危険なフラグ

● 目的が変わるようであれば仕切り直し or 別プロジェクトとし、

スコープを明確にしよう。○ 途中で出てきたアイデアが良いものであればあるほど、クライアントはそこを

ゴールとみなし、それ以下のアウトプットには物足りなさを感じてしまう。

風景その3

大規模プロモ直前なのに

システムが落ちまくってる風景

● 某SNSサービスで、2ヶ月後の年末年始に大規模プロモーションをやること

が決まった（CMなど)

● システムキャパが心配である。今も高負荷で頻繁にダウンしている。

● プロモーションに耐えられるよう、100万同時接続にまでキャパを上げてほ

しい。

○ 当時のキャパは1.5万同時接続程度だった

● ちなみに、CMはもう決まったのでスケジュールは絶対守らなければならな

い。


● 指示されたゴールは「100万同時接続」

● 社内的な注目度も高く、「今何万同時接続ですか？」と日々色

んな人に聞かれていた・・・(；´Д｀)

100万同時接続を目指して調査するうち、次の2つのことが新たに判明した。

● 耐障害性、可用性に大きな問題がある

○ 会員登録に関わる外部サービス障害時のバックアップがない

○ 特定機能の障害に引きずられて全体がダウンする

新たに判明した2つのこと

● 耐障害性、可用性に大きな問題がある

○ 会員登録に関わる外部サービス障害時のバックアップがない

○ 特定機能の障害に引きずられて全体がダウンする

● プロモが大成功しても100万同時接続は行きそうにない

○ アクセス傾向とCM計画(ユーザ増予測)を検証した結果、最大でも30万

同時接続程度と推定された。

新たに判明した2つのこと

やったこと

● プロジェクトゴールの再設定

○ 「100万同時接続」→「耐障害性、可用性、性能性とも、プロモーション

に耐えるのに必要な状態にする」

■ 同時接続数は30万目標

■ 耐障害性、可用性で問題ある部分の解消

● ゴール再設定に伴うプロジェクトスコープの再定

義

性能性

耐障害性、可用性

必要要件(〜30万同接)

過剰要件(30万同接〜)

必要要件過剰要件

プロジェクト開始時のゴール

性能性


プロジェクト開始時のゴール

100万同時接続




性能性


スコープ再定義後のゴール

同時接続数は30万目標に訂正。

浮いたリソースで、耐障害性、可用性で

問題ある部分の解消にあてた。




学んだこと

● あらかじめゴールが設定されている場合、まずはそのゴール

が最適かの確認をしよう○ 局所的な問題にとらわれず、全体を俯瞰して満たすべき要件を見極める

● 炎上している時ほど、やることとやらないことの線引を明確に

しよう○ 周囲(社内など)がいくら盛り上がっていても現場だけは冷静でいることを心が

ける

まとめ

● 権力者の厄介な介入がある風景 ○ 役割分担(責任範囲)を明確にする ○ 権力者とはうまく付き合う。介入の影響を局所化、限定的にする

3つの事例で学んだことまとめ


● 要件がいつの間にか進化する風景 ○ プロジェクトのゴールを明確にし、それにそった要件であるか常に意識する ○ ゴールが変わる場合は別プロジェクトとし、スコープを明確にする



● 要件がいつの間にか進化する風景 ○ プロジェクトのゴールを明確にし、それにそった要件であるか常に意識する ○ ゴールが変わる場合は別プロジェクトとし、スコープを明確にする

● 大規模プロモ直前なのにシステムが落ちまくってる風景 ○ 具体的なゴールが設定されている場合でも、そのゴールが最適かの確認を改めて

する ○ 炎上している時ほど、やることとやらないことの線引を明確にする


よくある炎上パターンは他にも

● 組織的要因 ○ 主に人間関係などが原因でチーム崩壊　など

● 技術的要因 ○ 実現できなかった、品質が上がりきらなかった　など

色々見てきた中で特に最悪な状態は、

○ ゴールがブレる、終わりが見えない

○ チームワークが崩壊

のどちらかかなと思います。

逆に言えば、

○ ゴールが明確で日々進捗がわかる

○ チームワークがいい

という状態であれば、

炎上

炎上ある意味

炎上祭りある意味

そういう意味では、

AbemaTVの開局前もある意味祭りでした！

※個人の感想です

今回の発表が炎上プロジェクトの

防止、火消しに役立てば幸いです。

ご清聴ありがとうございました。

AbemaTV Developer Conference 2016

Engineering

Transcript of AbemaTV Developer Conference 2016