Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (17)
Similaire à AbemaTV Developer Conference 2016
Similaire à AbemaTV Developer Conference 2016 (20)
AbemaTV Developer Conference 2016
- 1. 炎上プロジェクトの立て直しの風景 2016.10.15 AbemaTV Developer Conference
- 2. @yasitashiki ● 板敷 康洋 (Yasuhiro ITASHIKI) ● フリーランスのエンジニア兼開発コンサルタントとして、プロジェクト立ち上げや立て直 しの手伝いなど ● 2013年、(株)サイバーエージェントにサーバサイドエンジニアとして入社 ● 現在は、エンジニアリングマネジメントをメイン ● AbemaTVでは、開局前の障害対策／負荷対策を担当 自己紹介
- 3. 今日話すこと
- 7. では何を話すのか
- 10. 風景その1
- 11. 権力者の厄介な介入がある風景
- 12. それは突然の依頼でした。
- 13. ● 現在開発中の某ソーシャルゲーム ● 開発中の成果物を確認したところ、iOS/Android間で仕様が違う。 ● また、αバージョンでリリース予定の機能も違う。 ○ iOSのみβリリース予定の機能が搭載されている、逆にαリリース予定の機能 が入っていない ● 状況整理し、軌道修正を手伝ってほしい。 依頼(初期情報)
- 16. 普段の開発風景 プロデューサ iOSエンジニアAndroidエンジニア 普段は介入してこない。 複数PJかけもち。 開発チーム 過去ヒット作を産みだしてして おり、社内権力者。 チーフプロデューサ
- 28. 仕様決定、伝達フローの整備 ● 仕様はプロデューサとチーフプロデューサの間で決定する。 ● 開発チームの窓口はプロデューサとする。 ● 全ての仕様、修正依頼はプロデューサからエンジニアへ。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 仕様の共有 開発チーム 仕様の共有 仕様のずれなし ● 仕様決定、集約場所が明確に ● エンジニアへの情報伝達フローを一本化
- 29. 定期的な成果物レビュー会の実施 ● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。 ○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。 ○ プロデューサも同席することでその場で仕様変更の決定を行えるようにする。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 微妙なニュアンスを 直接伝える 定期レビュー会
- 30. 定期的な成果物レビュー会の実施 ● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。 ○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。 ○ プロデューサも同席することでその場で仕様変更の決定を行えるようにする。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 同時に聞くことで 認識のずれなし 微妙なニュアンスを 直接伝える その場で仕様変更決定 定期レビュー会
- 31. 定期的な成果物レビュー会の実施 ● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。 ○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。 ○ プロデューサも同席することでその場で仕様変更の決定を行えるようにする。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 同時に聞くことで 認識のずれなし 微妙なニュアンスを 直接伝える その場で仕様変更決定 チーフプロデューサ介入の場を意図的に作ることで、 介入の影響を局所化した。 定期レビュー会
- 32. 学んだこと ● 意思決定、情報の集約は一元化しよう ○ 複数箇所で行うのは混乱のもと。意思決定者が複数いる場合、最終決定は 同じ場で行うことが望ましい。 ○ また決定した内容の情報集約も一元化し、どこに最新の情報があるか分かる 状態にする。 ● 権力者とはうまく付き合おう ○ 介入が避けられない場合、影響を局所化する、限定的にするなど仕組みで 解決する。
- 33. 風景その2
- 34. 要件がいつの間にか進化する風景
- 35. それは突然の依頼でした。
- 36. ● 某アパレルチェーンの在庫管理システム ● ウォーターフォールで進めているが、詳細設計で大幅に遅れている。 ● 状況整理し、立て直し案を提出してほしい。 ● ちなみにチェーンの10周年に合わせるのでリリースタイミングは絶対動か せない。 依頼(初期情報)
- 44. クライアント お客様から在庫の問い合わせが来たら、その場で迅速に回答したい。 対象商品の在庫に加え、色違い在庫、近隣他店の在庫情報も回答したい。 要件進化の過程 この時点で見積もり終わり開発スタート。
- 48. やったこと ● プロジェクトゴールの再設定 ○ 本来の目的である在庫管理に注力。レコメンドは第二期開発とすることにし た。 ○ 本来の目的「お客様からの在庫問合せに迅速に回答する」 ● やらないことの停止。第二期開発への引き継ぎ。 ○ 幸い在庫、レコメンドシステムともいい設計で、戻りはほぼ発生しなかった。 ○ レコメンドの設計は区切りのいい段階までやりきり、第二期開発用に引き継 ぎ資料として残した。
- 49. 学んだこと ● このプロジェクトで何を解決したいのか？目的を常に考えよう ○ 仕様が少しずつ追加される状態は危険なフラグ ● 目的が変わるようであれば仕切り直し or 別プロジェクトとし、 スコープを明確にしよう。 ○ 途中で出てきたアイデアが良いものであればあるほど、クライアントはそこを ゴールとみなし、それ以下のアウトプットには物足りなさを感じてしまう。
- 50. 風景その3
- 52. それは突然の依頼でした。
- 53. ● 某SNSサービスで、2ヶ月後の年末年始に大規模プロモーションをやること が決まった（CMなど) ● システムキャパが心配である。今も高負荷で頻繁にダウンしている。 ● プロモーションに耐えられるよう、100万同時接続にまでキャパを上げてほ しい。 ○ 当時のキャパは1.5万同時接続程度だった ● ちなみに、CMはもう決まったのでスケジュールは絶対守らなければならな い。 依頼(初期情報)
- 56. ● 耐障害性、可用性に大きな問題がある ○ 会員登録に関わる外部サービス障害時のバックアップがない ○ 特定機能の障害に引きずられて全体がダウンする 新たに判明した2つのこと
- 57. ● 耐障害性、可用性に大きな問題がある ○ 会員登録に関わる外部サービス障害時のバックアップがない ○ 特定機能の障害に引きずられて全体がダウンする ● プロモが大成功しても100万同時接続は行きそうにない ○ アクセス傾向とCM計画(ユーザ増予測)を検証した結果、最大でも30万 同時接続程度と推定された。 新たに判明した2つのこと
- 58. やったこと ● プロジェクトゴールの再設定 ○ 「100万同時接続」→「耐障害性、可用性、性能性とも、プロモーション に耐えるのに必要な状態にする」 ■ 同時接続数は30万目標 ■ 耐障害性、可用性で問題ある部分の解消 ● ゴール再設定に伴うプロジェクトスコープの再定 義
- 62. 学んだこと ● あらかじめゴールが設定されている場合、まずはそのゴール が最適かの確認をしよう ○ 局所的な問題にとらわれず、全体を俯瞰して満たすべき要件を見極める ● 炎上している時ほど、やることとやらないことの線引を明確に しよう ○ 周囲(社内など)がいくら盛り上がっていても現場だけは冷静でいることを心が ける
- 63. まとめ
- 64. ● 権力者の厄介な介入がある風景 ○ 役割分担(責任範囲)を明確にする ○ 権力者とはうまく付き合う。介入の影響を局所化、限定的にする 3つの事例で学んだことまとめ
- 65. ● 権力者の厄介な介入がある風景 ○ 役割分担(責任範囲)を明確にする ○ 権力者とはうまく付き合う。介入の影響を局所化、限定的にする ● 要件がいつの間にか進化する風景 ○ プロジェクトのゴールを明確にし、それにそった要件であるか常に意識する ○ ゴールが変わる場合は別プロジェクトとし、スコープを明確にする 3つの事例で学んだことまとめ
- 66. ● 権力者の厄介な介入がある風景 ○ 役割分担(責任範囲)を明確にする ○ 権力者とはうまく付き合う。介入の影響を局所化、限定的にする ● 要件がいつの間にか進化する風景 ○ プロジェクトのゴールを明確にし、それにそった要件であるか常に意識する ○ ゴールが変わる場合は別プロジェクトとし、スコープを明確にする ● 大規模プロモ直前なのにシステムが落ちまくってる風景 ○ 具体的なゴールが設定されている場合でも、そのゴールが最適かの確認を改めて する ○ 炎上している時ほど、やることとやらないことの線引を明確にする 3つの事例で学んだことまとめ
- 67. よくある炎上パターンは他にも ● 組織的要因 ○ 主に人間関係などが原因でチーム崩壊 など ● 技術的要因 ○ 実現できなかった、品質が上がりきらなかった など
- 70. 炎上
- 71. 炎上 ある意味
- 72. 炎上 祭りある意味
- 73. そういう意味では、
- 76. ご清聴ありがとうございました。