Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
炎上プロジェクトの立て直しの風景
2016.10.15 AbemaTV Developer Conference
@yasitashiki
● 板敷 康洋 (Yasuhiro ITASHIKI)
● フリーランスのエンジニア兼開発コンサルタントとして、プロジェクト立ち上げや立て直
しの手伝いなど
● 2013年、(株)サイバーエージェントにサーバサイドエン...
今日話すこと
炎上プロジェクト立て直しの事例を紹介
していくのですが、
AbemaTVの話はありません!
AbemaTVはあまり炎上してな
いですから。
では何を話すのか
過去経験した炎上プロジェクトの中から、
よくある業務系のSIer案件ではなく、
Web業界の炎上事例を主に紹介したいと思います。
Web業界の開発は自社内で完結することが多い分、
業務系のように契約等がはっきりしておらず、
柔軟な反面、あいまいな部分が炎上に結びつくケースがあります。
風景その1
権力者の厄介な介入がある風景
それは突然の依頼でした。
● 現在開発中の某ソーシャルゲーム
● 開発中の成果物を確認したところ、iOS/Android間で仕様が違う。
● また、αバージョンでリリース予定の機能も違う。
○ iOSのみβリリース予定の機能が搭載されている、逆にαリリース予定の機能
が...
なんで仕様にずれが生じているのか調べた。
普段の開発風景
プロデューサ
iOSエンジニアAndroidエンジニア
開発チーム
チーフプロデューサ
普段の開発風景
プロデューサ
iOSエンジニアAndroidエンジニア
普段は介入してこない。
複数PJかけもち。
開発チーム
過去ヒット作を産みだしてして
おり、社内権力者。
チーフプロデューサ
普段の開発風景
プロデューサ
iOSエンジニアAndroidエンジニア
普段は介入してこない。
複数PJかけもち。
開発チーム
仕様はプロデュー
サが決める。 チーフプロデューサ
過去ヒット作を産みだしてして
おり、社内権力者。
普段の開発風景
プロデューサ
iOSエンジニアAndroidエンジニア
仕様の共有
普段は介入してこない。
複数PJかけもち。
開発チーム
仕様はプロデュー
サが決める。
仕様の共有
チーフプロデューサ
過去ヒット作を産みだしてして
おり、社内...
普段の開発風景
プロデューサ
iOSエンジニアAndroidエンジニア
仕様の共有
普段は介入してこない。
複数PJかけもち。
開発チーム
仕様はプロデュー
サが決める。
仕様の共有
仕様のずれなし
普段は仕様の決定、情報共有が一元化されており...
チーフプロデューサ
チーフプロデューサが介入してくる風景
プロデューサ
iOSエンジニアAndroidエンジニア
開発チーム
チーフプロデューサ
チーフプロデューサが介入してくる風景
プロデューサ
iOSエンジニアAndroidエンジニア
開発チーム
(不定期で成果物を確認)
ほほぅ、今こんな感じで作ってる
のか
チーフプロデューサ
プロデューサ
iOSエンジニアAndroidエンジニア
開発チーム
サクッと
修正して。
成果物を見たチーフから
エンジニアに直接修正指示。
(しかもiOSのみ…)
チーフプロデューサが介入してくる風景
チーフプロデューサ
プロデューサ
iOSエンジニアAndroidエンジニア
開発チーム
サクッと
修正して。
成果物を見たチーフから
エンジニアに直接修正指示。
(しかもiOSのみ…)
了解いたしました!
チーフプロデューサが介入してくる風景
チーフプロデューサ
プロデューサ
iOSエンジニアAndroidエンジニア
開発チーム
サクッと
修正して。
成果物を見たチーフから
エンジニアに直接修正指示。
(しかもiOSのみ…)
了解いたしました!
プロデューサは
把握していない
チーフ...
チーフプロデューサ
プロデューサ
iOSエンジニアAndroidエンジニア
開発チーム
サクッと
修正して。
成果物を見たチーフから
エンジニアに直接修正指示。
(しかもiOSのみ…)
了解いたしました!
プロデューサは
把握していない
共有
...
やったこと
● 仕様決定、伝達フローの整備
● 定期的な成果物レビュー会の実施
仕様決定、伝達フローの整備
● 仕様はプロデューサとチーフプロデューサの間で決定する。
● 開発チームの窓口はプロデューサとする。
チーフプロデューサ
プロデューサ
iOSエンジニアAndroidエンジニア
開発チーム
仕様決定、伝達フローの整備
● 仕様はプロデューサとチーフプロデューサの間で決定する。
● 開発チームの窓口はプロデューサとする。
● 全ての仕様、修正依頼はプロデューサからエンジニアへ。
チーフプロデューサ
プロデューサ
iOSエンジニアAn...
定期的な成果物レビュー会の実施
● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。
○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。
○ プロデューサも同席することでその場で仕様変更の決定を行えるように...
定期的な成果物レビュー会の実施
● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。
○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。
○ プロデューサも同席することでその場で仕様変更の決定を行えるように...
定期的な成果物レビュー会の実施
● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。
○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。
○ プロデューサも同席することでその場で仕様変更の決定を行えるように...
学んだこと
● 意思決定、情報の集約は一元化しよう
○ 複数箇所で行うのは混乱のもと。意思決定者が複数いる場合、最終決定は
同じ場で行うことが望ましい。
○ また決定した内容の情報集約も一元化し、どこに最新の情報があるか分かる
状態にする。
●...
風景その2
要件がいつの間にか進化する風景
それは突然の依頼でした。
● 某アパレルチェーンの在庫管理システム
● ウォーターフォールで進めているが、詳細設計で大幅に遅れている。
● 状況整理し、立て直し案を提出してほしい。
● ちなみにチェーンの10周年に合わせるのでリリースタイミングは絶対動か
せない。
依頼...
自分:「在庫管理システムの設計が遅れていると伺ったのですが」
クライアントとの初回やりとり
自分:「在庫管理システムの設計が遅れていると伺ったのですが」
クライアントとの初回やりとり
クライアント:「えーと、在庫と連動したレコメンドサービス、ですね」
自分:「在庫管理システムの設計が遅れていると伺ったのですが」
クライアントとの初回やりとり
クライアント:「えーと、在庫と連動したレコメンドサービス、ですね」
自分:「レコメンドサービス?(聞いてたのと違うな・・・)」
お客様 店員
在庫問合せする
基本的なユースケース
店員
在庫問合せする
店員
対象商品の在庫、同種類の色違い在庫、近隣他店の
在庫情報を手元の端末で表示して見せる。
基本的なユースケース
お客様
お客様
店員
在庫問合せする
店員
対象商品の在庫、同種類の色違い在庫、近隣他店の
在庫情報を手元の端末で表示して見せる。
お客様 店員
対象商品の在庫がある場合、他在庫と組み合わせた、
「トータルコーディネート」一式を提示。
基本的なユースケース
お...
店舗にある在庫を組み合わせたレコメンドとは珍しいサービス
だなと思いヒアリングを続けていると・・・
クライアント
お客様から在庫の問い合わせが来たら、その場で迅速に回答したい。
対象商品の在庫に加え、色違い在庫、近隣他店の在庫情報も回答したい。
要件進化の過程
この時点で見積もり終わり開発スタート。
クライアント
クライアント
お客様から在庫の問い合わせが来たら、その場で迅速に回答したい。
対象商品の在庫に加え、色違い在庫、近隣他店の在庫情報も回答したい。
手元の端末に商品の詳細な画像も表示されるなら、お客様に見てもらえばより購
入に結びつ...
クライアント
クライアント
お客様から在庫の問い合わせが来たら、その場で迅速に回答したい。
対象商品の在庫に加え、色違い在庫、近隣他店の在庫情報も回答したい。
手元の端末に商品の詳細な画像も表示されるなら、お客様に見てもらえばより購
入に結びつ...
「これは・・・スコープクリープなんて
甘いもんじゃなくて仕様の進化・・・ッ」
やったこと
● プロジェクトゴールの再設定
○ 本来の目的である在庫管理に注力。レコメンドは第二期開発とすることにし
た。
○ 本来の目的「お客様からの在庫問合せに迅速に回答する」
● やらないことの停止。第二期開発への引き継ぎ。
○ 幸い在庫...
学んだこと
● このプロジェクトで何を解決したいのか?目的を常に考えよう
○ 仕様が少しずつ追加される状態は危険なフラグ
● 目的が変わるようであれば仕切り直し or 別プロジェクトとし、
スコープを明確にしよう。
○ 途中で出てきたアイデアが...
風景その3
大規模プロモ直前なのに
システムが落ちまくってる風景
それは突然の依頼でした。
● 某SNSサービスで、2ヶ月後の年末年始に大規模プロモーションをやること
が決まった(CMなど)
● システムキャパが心配である。今も高負荷で頻繁にダウンしている。
● プロモーションに耐えられるよう、100万同時接続にまでキャパを上げてほ
...
● 指示されたゴールは「100万同時接続」
● 社内的な注目度も高く、「今何万同時接続ですか?」と日々色
んな人に聞かれていた・・・(;´Д`)
100万同時接続を目指して調査するうち、
次の2つのことが新たに判明した。
● 耐障害性、可用性に大きな問題がある
○ 会員登録に関わる外部サービス障害時のバックアップがない
○ 特定機能の障害に引きずられて全体がダウンする
新たに判明した2つのこと
● 耐障害性、可用性に大きな問題がある
○ 会員登録に関わる外部サービス障害時のバックアップがない
○ 特定機能の障害に引きずられて全体がダウンする
● プロモが大成功しても100万同時接続は行きそうにない
○ アクセス傾向とCM計画(ユーザ増...
やったこと
● プロジェクトゴールの再設定
○ 「100万同時接続」→「耐障害性、可用性、性能性とも、プロモーション
に耐えるのに必要な状態にする」
■ 同時接続数は30万目標
■ 耐障害性、可用性で問題ある部分の解消
● ゴール再設定に伴うプ...
性能性
耐障害性、可用性
必要要件
(〜30万同接)
過剰要件
(30万同接〜)
必要要件 過剰要件
プロジェクト開始時のゴール
性能性
耐障害性、可用性
プロジェクト開始時のゴール
100万同時接続
過剰要件
(30万同接〜)
必要要件
(〜30万同接)
必要要件 過剰要件
性能性
耐障害性、可用性
スコープ再定義後のゴール
同時接続数は30万目標に訂正。
浮いたリソースで、耐障害性、可用性で
問題ある部分の解消にあてた。
過剰要件
(30万同接〜)
必要要件
(〜30万同接)
必要要件 過剰要件
学んだこと
● あらかじめゴールが設定されている場合、まずはそのゴール
が最適かの確認をしよう
○ 局所的な問題にとらわれず、全体を俯瞰して満たすべき要件を見極める
● 炎上している時ほど、やることとやらないことの線引を明確に
しよう
○ 周囲...
まとめ
● 権力者の厄介な介入がある風景
○ 役割分担(責任範囲)を明確にする
○ 権力者とはうまく付き合う。介入の影響を局所化、限定的にする
3つの事例で学んだことまとめ
● 権力者の厄介な介入がある風景
○ 役割分担(責任範囲)を明確にする
○ 権力者とはうまく付き合う。介入の影響を局所化、限定的にする
● 要件がいつの間にか進化する風景
○ プロジェクトのゴールを明確にし、それにそった要件であるか常に意識する...
● 権力者の厄介な介入がある風景
○ 役割分担(責任範囲)を明確にする
○ 権力者とはうまく付き合う。介入の影響を局所化、限定的にする
● 要件がいつの間にか進化する風景
○ プロジェクトのゴールを明確にし、それにそった要件であるか常に意識する...
よくある炎上パターンは他にも
● 組織的要因
○ 主に人間関係などが原因でチーム崩壊 など
● 技術的要因
○ 実現できなかった、品質が上がりきらなかった など
色々見てきた中で特に最悪な状態は、
○ ゴールがブレる、終わりが見えない
○ チームワークが崩壊
のどちらかかなと思います。
逆に言えば、
○ ゴールが明確で日々進捗がわかる
○ チームワークがいい
という状態であれば、
炎上
炎上 ある意味
炎上 祭りある意味
そういう意味では、
AbemaTVの
開局前もある意味祭りでした!
※個人の感想です
今回の発表が炎上プロジェクトの
防止、火消しに役立てば幸いです。
ご清聴ありがとうございました。
Upcoming SlideShare
Loading in …5
×

AbemaTV Developer Conference 2016

5,365 views

Published on

炎上プロジェクト立て直しについてのお話です。

Published in: Engineering
  • Be the first to comment

AbemaTV Developer Conference 2016

  1. 1. 炎上プロジェクトの立て直しの風景 2016.10.15 AbemaTV Developer Conference
  2. 2. @yasitashiki ● 板敷 康洋 (Yasuhiro ITASHIKI) ● フリーランスのエンジニア兼開発コンサルタントとして、プロジェクト立ち上げや立て直 しの手伝いなど ● 2013年、(株)サイバーエージェントにサーバサイドエンジニアとして入社 ● 現在は、エンジニアリングマネジメントをメイン ● AbemaTVでは、開局前の障害対策/負荷対策を担当 自己紹介
  3. 3. 今日話すこと
  4. 4. 炎上プロジェクト立て直しの事例を紹介 していくのですが、
  5. 5. AbemaTVの話はありません!
  6. 6. AbemaTVはあまり炎上してな いですから。
  7. 7. では何を話すのか
  8. 8. 過去経験した炎上プロジェクトの中から、 よくある業務系のSIer案件ではなく、 Web業界の炎上事例を主に紹介したいと思います。
  9. 9. Web業界の開発は自社内で完結することが多い分、 業務系のように契約等がはっきりしておらず、 柔軟な反面、あいまいな部分が炎上に結びつくケースがあります。
  10. 10. 風景その1
  11. 11. 権力者の厄介な介入がある風景
  12. 12. それは突然の依頼でした。
  13. 13. ● 現在開発中の某ソーシャルゲーム ● 開発中の成果物を確認したところ、iOS/Android間で仕様が違う。 ● また、αバージョンでリリース予定の機能も違う。 ○ iOSのみβリリース予定の機能が搭載されている、逆にαリリース予定の機能 が入っていない ● 状況整理し、軌道修正を手伝ってほしい。 依頼(初期情報)
  14. 14. なんで仕様にずれが生じているのか調べた。
  15. 15. 普段の開発風景 プロデューサ iOSエンジニアAndroidエンジニア 開発チーム チーフプロデューサ
  16. 16. 普段の開発風景 プロデューサ iOSエンジニアAndroidエンジニア 普段は介入してこない。 複数PJかけもち。 開発チーム 過去ヒット作を産みだしてして おり、社内権力者。 チーフプロデューサ
  17. 17. 普段の開発風景 プロデューサ iOSエンジニアAndroidエンジニア 普段は介入してこない。 複数PJかけもち。 開発チーム 仕様はプロデュー サが決める。 チーフプロデューサ 過去ヒット作を産みだしてして おり、社内権力者。
  18. 18. 普段の開発風景 プロデューサ iOSエンジニアAndroidエンジニア 仕様の共有 普段は介入してこない。 複数PJかけもち。 開発チーム 仕様はプロデュー サが決める。 仕様の共有 チーフプロデューサ 過去ヒット作を産みだしてして おり、社内権力者。
  19. 19. 普段の開発風景 プロデューサ iOSエンジニアAndroidエンジニア 仕様の共有 普段は介入してこない。 複数PJかけもち。 開発チーム 仕様はプロデュー サが決める。 仕様の共有 仕様のずれなし 普段は仕様の決定、情報共有が一元化されており問題ない。 チーフプロデューサ 過去ヒット作を産みだしてして おり、社内権力者。
  20. 20. チーフプロデューサ チーフプロデューサが介入してくる風景 プロデューサ iOSエンジニアAndroidエンジニア 開発チーム
  21. 21. チーフプロデューサ チーフプロデューサが介入してくる風景 プロデューサ iOSエンジニアAndroidエンジニア 開発チーム (不定期で成果物を確認) ほほぅ、今こんな感じで作ってる のか
  22. 22. チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 開発チーム サクッと 修正して。 成果物を見たチーフから エンジニアに直接修正指示。 (しかもiOSのみ…) チーフプロデューサが介入してくる風景
  23. 23. チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 開発チーム サクッと 修正して。 成果物を見たチーフから エンジニアに直接修正指示。 (しかもiOSのみ…) 了解いたしました! チーフプロデューサが介入してくる風景
  24. 24. チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 開発チーム サクッと 修正して。 成果物を見たチーフから エンジニアに直接修正指示。 (しかもiOSのみ…) 了解いたしました! プロデューサは 把握していない チーフプロデューサが介入してくる風景
  25. 25. チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 開発チーム サクッと 修正して。 成果物を見たチーフから エンジニアに直接修正指示。 (しかもiOSのみ…) 了解いたしました! プロデューサは 把握していない 共有 漏れ 仕様 ズレ チーフプロデューサが介入してくる風景
  26. 26. やったこと ● 仕様決定、伝達フローの整備 ● 定期的な成果物レビュー会の実施
  27. 27. 仕様決定、伝達フローの整備 ● 仕様はプロデューサとチーフプロデューサの間で決定する。 ● 開発チームの窓口はプロデューサとする。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 開発チーム
  28. 28. 仕様決定、伝達フローの整備 ● 仕様はプロデューサとチーフプロデューサの間で決定する。 ● 開発チームの窓口はプロデューサとする。 ● 全ての仕様、修正依頼はプロデューサからエンジニアへ。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 仕様の共有 開発チーム 仕様の共有 仕様のずれなし ● 仕様決定、集約場所が明確に ● エンジニアへの情報伝達フローを一本化
  29. 29. 定期的な成果物レビュー会の実施 ● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。 ○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。 ○ プロデューサも同席することでその場で仕様変更の決定を行えるようにする。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 微妙なニュアンスを 直接伝える 定期レビュー会
  30. 30. 定期的な成果物レビュー会の実施 ● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。 ○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。 ○ プロデューサも同席することでその場で仕様変更の決定を行えるようにする。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 同時に聞くことで 認識のずれなし 微妙なニュアンスを 直接伝える その場で仕様変更決定 定期レビュー会
  31. 31. 定期的な成果物レビュー会の実施 ● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。 ○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。 ○ プロデューサも同席することでその場で仕様変更の決定を行えるようにする。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 同時に聞くことで 認識のずれなし 微妙なニュアンスを 直接伝える その場で仕様変更決定 チーフプロデューサ介入の場を意図的に作ることで、 介入の影響を局所化した。 定期レビュー会
  32. 32. 学んだこと ● 意思決定、情報の集約は一元化しよう ○ 複数箇所で行うのは混乱のもと。意思決定者が複数いる場合、最終決定は 同じ場で行うことが望ましい。 ○ また決定した内容の情報集約も一元化し、どこに最新の情報があるか分かる 状態にする。 ● 権力者とはうまく付き合おう ○ 介入が避けられない場合、影響を局所化する、限定的にするなど仕組みで 解決する。
  33. 33. 風景その2
  34. 34. 要件がいつの間にか進化する風景
  35. 35. それは突然の依頼でした。
  36. 36. ● 某アパレルチェーンの在庫管理システム ● ウォーターフォールで進めているが、詳細設計で大幅に遅れている。 ● 状況整理し、立て直し案を提出してほしい。 ● ちなみにチェーンの10周年に合わせるのでリリースタイミングは絶対動か せない。 依頼(初期情報)
  37. 37. 自分:「在庫管理システムの設計が遅れていると伺ったのですが」 クライアントとの初回やりとり
  38. 38. 自分:「在庫管理システムの設計が遅れていると伺ったのですが」 クライアントとの初回やりとり クライアント:「えーと、在庫と連動したレコメンドサービス、ですね」
  39. 39. 自分:「在庫管理システムの設計が遅れていると伺ったのですが」 クライアントとの初回やりとり クライアント:「えーと、在庫と連動したレコメンドサービス、ですね」 自分:「レコメンドサービス?(聞いてたのと違うな・・・)」
  40. 40. お客様 店員 在庫問合せする 基本的なユースケース
  41. 41. 店員 在庫問合せする 店員 対象商品の在庫、同種類の色違い在庫、近隣他店の 在庫情報を手元の端末で表示して見せる。 基本的なユースケース お客様 お客様
  42. 42. 店員 在庫問合せする 店員 対象商品の在庫、同種類の色違い在庫、近隣他店の 在庫情報を手元の端末で表示して見せる。 お客様 店員 対象商品の在庫がある場合、他在庫と組み合わせた、 「トータルコーディネート」一式を提示。 基本的なユースケース お客様 お客様
  43. 43. 店舗にある在庫を組み合わせたレコメンドとは珍しいサービス だなと思いヒアリングを続けていると・・・
  44. 44. クライアント お客様から在庫の問い合わせが来たら、その場で迅速に回答したい。 対象商品の在庫に加え、色違い在庫、近隣他店の在庫情報も回答したい。 要件進化の過程 この時点で見積もり終わり開発スタート。
  45. 45. クライアント クライアント お客様から在庫の問い合わせが来たら、その場で迅速に回答したい。 対象商品の在庫に加え、色違い在庫、近隣他店の在庫情報も回答したい。 手元の端末に商品の詳細な画像も表示されるなら、お客様に見てもらえばより購 入に結びつくかも! 要件進化の過程 エンドユーザ向けにデザイン刷新が決定! この時点で見積もり終わり開発スタート。
  46. 46. クライアント クライアント お客様から在庫の問い合わせが来たら、その場で迅速に回答したい。 対象商品の在庫に加え、色違い在庫、近隣他店の在庫情報も回答したい。 手元の端末に商品の詳細な画像も表示されるなら、お客様に見てもらえばより購 入に結びつくかも! 店舗の在庫情報が全部わかるのであれば、在庫だけで組み合わせた 「旬のおすすめコーディネート」をセットで提案したい! クライアント 要件進化の過程 エンドユーザ向けにデザイン刷新が決定! 在庫連動したレコメンドサービスの開発が決定! この時点で見積もり終わり開発スタート。
  47. 47. 「これは・・・スコープクリープなんて 甘いもんじゃなくて仕様の進化・・・ッ」
  48. 48. やったこと ● プロジェクトゴールの再設定 ○ 本来の目的である在庫管理に注力。レコメンドは第二期開発とすることにし た。 ○ 本来の目的「お客様からの在庫問合せに迅速に回答する」 ● やらないことの停止。第二期開発への引き継ぎ。 ○ 幸い在庫、レコメンドシステムともいい設計で、戻りはほぼ発生しなかった。 ○ レコメンドの設計は区切りのいい段階までやりきり、第二期開発用に引き継 ぎ資料として残した。
  49. 49. 学んだこと ● このプロジェクトで何を解決したいのか?目的を常に考えよう ○ 仕様が少しずつ追加される状態は危険なフラグ ● 目的が変わるようであれば仕切り直し or 別プロジェクトとし、 スコープを明確にしよう。 ○ 途中で出てきたアイデアが良いものであればあるほど、クライアントはそこを ゴールとみなし、それ以下のアウトプットには物足りなさを感じてしまう。
  50. 50. 風景その3
  51. 51. 大規模プロモ直前なのに システムが落ちまくってる風景
  52. 52. それは突然の依頼でした。
  53. 53. ● 某SNSサービスで、2ヶ月後の年末年始に大規模プロモーションをやること が決まった(CMなど) ● システムキャパが心配である。今も高負荷で頻繁にダウンしている。 ● プロモーションに耐えられるよう、100万同時接続にまでキャパを上げてほ しい。 ○ 当時のキャパは1.5万同時接続程度だった ● ちなみに、CMはもう決まったのでスケジュールは絶対守らなければならな い。 依頼(初期情報)
  54. 54. ● 指示されたゴールは「100万同時接続」 ● 社内的な注目度も高く、「今何万同時接続ですか?」と日々色 んな人に聞かれていた・・・(;´Д`)
  55. 55. 100万同時接続を目指して調査するうち、 次の2つのことが新たに判明した。
  56. 56. ● 耐障害性、可用性に大きな問題がある ○ 会員登録に関わる外部サービス障害時のバックアップがない ○ 特定機能の障害に引きずられて全体がダウンする 新たに判明した2つのこと
  57. 57. ● 耐障害性、可用性に大きな問題がある ○ 会員登録に関わる外部サービス障害時のバックアップがない ○ 特定機能の障害に引きずられて全体がダウンする ● プロモが大成功しても100万同時接続は行きそうにない ○ アクセス傾向とCM計画(ユーザ増予測)を検証した結果、最大でも30万 同時接続程度と推定された。 新たに判明した2つのこと
  58. 58. やったこと ● プロジェクトゴールの再設定 ○ 「100万同時接続」→「耐障害性、可用性、性能性とも、プロモーション に耐えるのに必要な状態にする」 ■ 同時接続数は30万目標 ■ 耐障害性、可用性で問題ある部分の解消 ● ゴール再設定に伴うプロジェクトスコープの再定 義
  59. 59. 性能性 耐障害性、可用性 必要要件 (〜30万同接) 過剰要件 (30万同接〜) 必要要件 過剰要件 プロジェクト開始時のゴール
  60. 60. 性能性 耐障害性、可用性 プロジェクト開始時のゴール 100万同時接続 過剰要件 (30万同接〜) 必要要件 (〜30万同接) 必要要件 過剰要件
  61. 61. 性能性 耐障害性、可用性 スコープ再定義後のゴール 同時接続数は30万目標に訂正。 浮いたリソースで、耐障害性、可用性で 問題ある部分の解消にあてた。 過剰要件 (30万同接〜) 必要要件 (〜30万同接) 必要要件 過剰要件
  62. 62. 学んだこと ● あらかじめゴールが設定されている場合、まずはそのゴール が最適かの確認をしよう ○ 局所的な問題にとらわれず、全体を俯瞰して満たすべき要件を見極める ● 炎上している時ほど、やることとやらないことの線引を明確に しよう ○ 周囲(社内など)がいくら盛り上がっていても現場だけは冷静でいることを心が ける
  63. 63. まとめ
  64. 64. ● 権力者の厄介な介入がある風景 ○ 役割分担(責任範囲)を明確にする ○ 権力者とはうまく付き合う。介入の影響を局所化、限定的にする 3つの事例で学んだことまとめ
  65. 65. ● 権力者の厄介な介入がある風景 ○ 役割分担(責任範囲)を明確にする ○ 権力者とはうまく付き合う。介入の影響を局所化、限定的にする ● 要件がいつの間にか進化する風景 ○ プロジェクトのゴールを明確にし、それにそった要件であるか常に意識する ○ ゴールが変わる場合は別プロジェクトとし、スコープを明確にする 3つの事例で学んだことまとめ
  66. 66. ● 権力者の厄介な介入がある風景 ○ 役割分担(責任範囲)を明確にする ○ 権力者とはうまく付き合う。介入の影響を局所化、限定的にする ● 要件がいつの間にか進化する風景 ○ プロジェクトのゴールを明確にし、それにそった要件であるか常に意識する ○ ゴールが変わる場合は別プロジェクトとし、スコープを明確にする ● 大規模プロモ直前なのにシステムが落ちまくってる風景 ○ 具体的なゴールが設定されている場合でも、そのゴールが最適かの確認を改めて する ○ 炎上している時ほど、やることとやらないことの線引を明確にする 3つの事例で学んだことまとめ
  67. 67. よくある炎上パターンは他にも ● 組織的要因 ○ 主に人間関係などが原因でチーム崩壊 など ● 技術的要因 ○ 実現できなかった、品質が上がりきらなかった など
  68. 68. 色々見てきた中で特に最悪な状態は、 ○ ゴールがブレる、終わりが見えない ○ チームワークが崩壊 のどちらかかなと思います。
  69. 69. 逆に言えば、 ○ ゴールが明確で日々進捗がわかる ○ チームワークがいい という状態であれば、
  70. 70. 炎上
  71. 71. 炎上 ある意味
  72. 72. 炎上 祭りある意味
  73. 73. そういう意味では、
  74. 74. AbemaTVの 開局前もある意味祭りでした! ※個人の感想です
  75. 75. 今回の発表が炎上プロジェクトの 防止、火消しに役立てば幸いです。
  76. 76. ご清聴ありがとうございました。

×