Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (15)
Destacado
Destacado (20)
Más de devsumi2009
Más de devsumi2009 (20)
【12-A-5】 ユーザー企業責任で25サイトをアジャイルに開発
- 1. 実例：ユーザー企業責任で 25サイトをアジャイルに開発 12-A-5 前田 圭一郎 株式会社リクルート システム基盤推進室 アプリケーションソリューショングループ
- 2. はじめに 限られた納期の中、ユーザー部門の理解がなくて、でも成果物責任はある。 そんな環境でアジャイルに開発するのは難しいと思いませんか？ リクルートでは、ユーザー部門（サービス企画部門）とシステム部門と開発者 の3者が、開発中、密にコミュニケーションをとるスタイルで3年間、模索・実 践してきました。私達のビジネスの根幹である Web メディア開発のスピード UP のためです。 私達のやり方をご紹介することで、なんらかのヒントになればと思います。
- 3. どんな事例か？ ・完全内製ではないユーザ企業が、 ・自社システムのビジネス価値を高めるために、 ・アジャイル開発の考え方を自分たちの現場に適用させる試みを組織的に、 ・年単位(3年)で取り組んでいる ・素晴らしい正解ではないかもしれない （そもそもリクルートの中でも、いろいろなやり方があります） ・技術的に、特に新しいわけではない しかし、ビジネスの現場、開発の現場で、3年間、 「どうすればもっとよくなるか？」 を継続的に考えて実行してきた結果です。 特に、ヒトの考え方・習慣をポイントに、皆さんの考えるヒントになれば
- 4. Agenda 1．リクルートとは ◆リクルート概要とシステム担当の役割 ◆システム担当の組織概要 2．背景 ◆Ｗｅｂメディア・サービス設計・開発の課題 3．ＳＷＡＴとは？ ◆思想 ◆歴史（3年間の歩み） ◆開発体制 ◆特徴 ・開発プロセス ・リスクの考え方 ・コミュニケーション ・要件確認会 典型的ケース ◆まとめ
- 5. リクルートのご紹介
- 6. リクルートとは ◆リクルートの会社概要 ◆システム担当の役割 飲食 ショッピング 美容 カスタマー クライアント 車 部屋探し （利用者） （顧客） 就職 転職 人生軸 様々な マッチ メディア・ 営業 編集 営業 編集 進学 結婚 ﾏｲﾎｰﾑ 育児 ング数 サービス バイト 資格 旅行 企画部門：メディア・サービス企画 通販 コスメ 企画部門：メディア・サービス企画 カスタマーニーズに合わせた領域の拡大 色々なライフ・イベント＆ライフ・スタイル システム担当 システム担当 ライフイベント（節目）領域 ライフスタイル（日常）領域 人材領 教育 住宅 販促 販促 新領域 フ 情 リ ●企画部門と協働しながら、新メディアの開発と、既存 ー 報 ペ 誌 メディアの改善 ー パ ⇒ Webメディア・サービスを構築する役割 ー モ Ｗ ●メディアを開発する際に、ベンダーと協働しながら バ Ｅ イ Ｂ プロジェクトマネジメントをする役割 ル ・ そ の 他
- 7. リクルートとは ◆システム担当の組織概要 ●各事業担当部門 ・各事業に密着し、企画部門と協力して、システムの構築や保守を行なう。 ・システム構築プロジェクトのPMとして、マネジメントを行なう。 ●システム基盤担当部門 ・全社的な視点から、共通性の高いサービスを提供。 ・開発手法の検討・提供。 ・リクルートの開発の統括業務（コスト、生産性） ・新製品の検証 ・インフラの提供 ●センター ・社内業務システムの開発、管理、運営を主に行っている。 リクルｰト 事業 ｎ 事業 １ 事業 ２ 事業 ３ 本社スタッフ システム ・・・ （企画、営業) （企画、営業） （経企、財務、経理・・・） （企画・営業） (企画、営業) 基盤担当 ・ センター システム担当 システム担当 システム担当 事業2担当 事業3担当 事業１担当
- 9. 背景 ◆Ｗｅｂメディア・サービス設計・開発の課題 ●リクルートは、メディア立上げの文化。 従来の“メディア立ち上げ型“： ・新たなカテゴリを生み出し、世の中に提供。 ・スタート時に最大の効果を。 ・ビジネスであり、失敗は許されない。 ところが ●変化が激しいWEBの世界では、ビジネスの環境が刻一刻と変わっていく。 『実際に世に出してみないとわからない』というのがWEBの世界。
- 10. 背景 ◆何が起きる？ 機能・サービスの検討期 間が長期化する システム開発が大規模化 し、開発期間も長期化する 商品開発（ビジネス検討～ サービスリリースまで）の期 機能やサービスを一度にめいっ 間が長期化する ぱい投入しようとする 今回、機能を入れておかないと、 大きく機能・サービスを投入する 大規模化・ 大規模化・ 次のチャンスは1年以上先になる 長期化のスパイラル 長期化のスパイラル Webの世界は、 どれが当たるかわかりづらい が、サービス・商品をヒットさせ 、成功させる必要がある。 マーケットの変化、 競合との競争に勝つために もっと早くできないか、という声
- 11. 背景 ◆Ｗｅｂメディア・サービス設計・開発をとりまく状況 まとめ ●変化が激しいWEBの世界では、ビジネスの環境が刻一刻と変わっていく。 『実際に世に出してみないとわからない』というのがWEBの世界。 ●リクルートは、メディア立上げの文化。 ビジネス検討（サービス・広告商品設計） 背景 ●スタート時に漏れなく機能／要件を洗い出し ●仮説ベースのためリスク判断が難しい ●スタート時に最大の効果を求める ●失敗が許されないビジネス根幹のサービス システム開発 ●開発着手までに時間がかかるプロセス ●開発品質追求 メディア／サービスのリリースまで時間がかかる構造 「もっと“スピード”を」 の 要求
- 13. 背景 ◆もっと“スピード”を早くするために システム開発の、開発方法論やアーキテクチャーの変革により、 劇的にスピードアップを図る システム開発のみならず、サービス開発の考え方・やり方自体 を変え、その上でそれに即したシステム開発の工夫を行う必要 がある。
- 14. スピードを求めて ◆考え方 ・ やり方を変える 「一致団結し意思をもってスピードを追求した開発チーム」 SWAT （企画部門、システム担当、開発パートナーが一つのチーム） Speedy Willing Alliance Team ※本家SWAT（Special Weapons and Tactics）の意味も込めています。 本家SWAT（ Tactics） 意味も込めています。 新しいメディア／サービスにトライする際の『考え方や意思』を本気で変える 新しいメディア／サービスにトライする際の『考え方や意思』を本気で変える ＳＷＡＴ 従来のやり方 新しいやり方 C/O時点で100%の完成度を目指す スモールスタート （1000FP～3000FP） ビ ジ １ 『中途半端なものは世に出せない』という意識があり、サイト ネ スモールスタートし、カスタマやクライアントの反応を見なが ス 立ち上げ時点で多くを盛り込む。 ら、段階的にサービスを成長・適合させていく 検 討 ビジネスのコアおよびその周辺も漏れなく検討 ビジネスのコアに絞り込んで検討 手 ビジネスコアに直接リンクしない、よりリッチな機能や 法 ビジネスのコアに直結しない部分については、 ２ を ユーザビリティー、入稿機能、運用機能なども漏れなく 変 最低限の検討パワーに抑える。 検討し磨き上げていく。 え る やりたいことを積み上げて予算をとる 期間と投資上限をあらかじめ限定 ある程度時間をかけて積み上げたものに対して、予算と ビジネスの見立てがついた時点で、このプロセス ３ スケジュールを決める。 の適用判断を行い、ビジネス検討期間も含めて期間、 シ 投資上限を決定する。 ス ステークホルダーと調整・確認しながら進める テ 小規模チームに権限委譲 ム 開 ４ 検討の漏れや、混乱や不満が出ないように、関連部署や ステークホルダーとの調整は最小限に抑え、少人数 発 上長と確認・調整を繰り返していく。 手 の体制で意思決定していく。 法 ウォーターフォール型のシステム開発手法 独自のシステム開発手法 を 変 ５ え る
- 15. スピードを求めて ◆ビジネス・サービスのライフサイクルイメージ と使い分け SWAT 大規模開発 加 速 早く世に出して、 状況に適応しながら サービスを磨く 加 新たなビジネスへ 速 のトライ スタートUP 成長・拡大 最盛期 衰退
- 16. ＳＷＡＴとは？
- 17. ＳＷＡＴとは？ ◆ＳＷＡＴの歴史（約3年） 2006年1月～ 短納期開発ソリューション「Rapid開発」の誕生 ネットビジネスにおける“スピード”に対する課題の高まり ⇒Rapid開発（システム開発手法）を考案し、フィジビリティースタディー１号プロジェクト 2007年4月～ RapidからSWATへ昇華 全社展開が開始。 これに際し、システム開発手法という枠組であった“Rapid”に、考え方・理念を加え、名称も SWATに変更。 2008年10月～ SWATからSWAT2.0へ Rapid時代から含め、2008年末まで、計25サイトをC/O。 25サイトの経験を元に、全面的改善を実施（社内通称：SWAT2.0） 現在に至る
- 18. ＳＷＡＴとは？ ◆ＳＷＡＴの特徴 基本の特徴：スピード リクルートで実施している従来型よりスピードが早い。 特徴1：アジャイル的な開発プロセス ①開発工程 設計製造時点での動作確認によりドキュメントレビュー工程削除。 動作を確認しながら、仕様確定していく。 ②タイムボックス タイムボックスを利用。1週間単位。 計画・進捗の”見える化”，リスク状況を理解しあう道具 バッファ用のタイムボックスも用意 ③朝会、バーンダウンチャート、レトロスペクティブ 等 特徴2：コミュニケーション重視の開発スタイル ①敏速なユーザー確認 要件確認会で、企画部門、システム担当、開発パートナー3者が集まり、動くアプリ を活用した要件確認を行い、ドキュメントベースの多段階の仕様・設計レビューをカット。 又、実装したものを事業側に見せることで、即座にユーザー確認を実現。 ②会議体のモデルを作成 要件確認会進行、要件確認会のタイミング、頻度などモデルを作成。 特徴3：シンプルな開発ドキュメント ①レビューのためのドキュメントを極力減らし、開発者が必要なものだけ 簡易設計書、簡易設計書作成フローなど工程別作成ドキュメントを集約。
- 20. ＳＷＡＴとは？ ◆特徴 作業工程の変更による納期圧縮 ｳｵｰﾀｰﾌｫｰﾙ開発とSWAT開発の作業工程の比較（イメージ） 1～2週 3～4週 5～6週 7～8週 9～10週 11～12週 13～14週 15～16週 要件定義 基本設計 詳細設計 製造 つづく ①ｳｵｰﾀｰﾌｫｰﾙ 外部 外部 外部 要求 調査 定義書 内部 要求 調査 設計書 内部 調査 設計書 内部 コーディング 動作確認 内部レビュー 仕様 検討 作成 レビュー レビュー 仕様 検討 作成 レビュー レビュー 検討 作成 レビュー レビュー C/O 要件定義 単体試験 調査検討 要求仕様 設計 ユーザー 設計書作成 ②SWAT開発手順 早期C/Oの実現！ レ 結合試験 総合試験 検品 ビ 試験結果 仕様書 製造 作成 ュ 実施判定 ー コーディング 動作確認 ユーザ動作確認 事前のユーザー動作確認が密な 動くアプリによる仕様確認・確定のため ため ドキュメントレビュー工程の削除と 最終ユーザー確認期間の短縮 仕様齟齬の早期発見により手戻り期間の短縮 17～18週 19～20週 21～22週 23～24週 25～26週 14週 C/O 単体試験 ①ｳｵｰﾀｰﾌｫｰﾙ 総合試験 結合試験 ユーザー検品 試験 仕様書 内部 外部 試験 結果 立会/検品 つづき 計画 作成 レビューレビュー 実施 判定
- 21. ＳＷＡＴとは？ ◆特徴 作業工程の変更による納期圧縮 作業工程概要 ビジネス ビジネス 要件定義 PH2 要件定義 検討 検討 PH1 C/O サイクル2 サイクル1 PH1 PH2 結合・ 設計・製造・動作確認 単体試験 性能・ ユーザー 総合試験 アプリ保守・メンテ サイクル1 サイクル2 セキュリティ 検品 試験 ユーザ動作確認 概要 ■ ビジネス検討 PH1 商品・サービス設計、機能の検討。 PH2 細部検討。システム化範囲の仮決定。 ■ 要件定義 PH1 要件定義PH2の準備期間。 サイクル1 PH 要件・仕様を詰めていく。 2 サイクル2 サイクル1で作成したアプリの動作確認の結果、さらに要件を詳細に詰めていく。 ■ 設計・製造・動 サイクル1 画面を正常系として、一通り製造し、動作確認を実施する。 作確認 ※仕様確認しながら確定していくので、異常系の実装はまだ、しない。 サイクル2 サイクル1で作成したアプリを完成させ、動作確認を実施する。 ■ ユーザ動作確認 製造されたアプリを随時、企画部門、システム担当が動作確認をする。 ■ テスト 仕様書を作成し、各種テストを実施。
- 22. ＳＷＡＴとは？ ◆特徴 タイムボックス（週間サイクル） 1週目 2週目 3週目 4週目 5週目 6週目 7週目 8週目 作業工程概要 TB計画 TB計画 TB計画 TB計画 TB計画 TB計画 チューニング チューニング チューニング チューニング チューニング チューニング TB1 TB2 TB3 TB4 TB5 TB6 TB7 要件定義 PH2 要件定義 PH1 サイクル1 サイクル2 ビジネス検討 PH1/PH2 設計・製造・動作確認 サイクル1 サイクル2 製造 製造 製造 製造 製造 製造 TB計画 単体テスト 単体動確 単体動確 単体動確 単体動確 単体動確 単体動確 結合動確 結合動確 結合動確 結合動確 結合動確 結合動確 ユーザ動確 ユーザ動確 ユーザ動確 ユーザ動確 ユーザ動確 ユーザ動確 ユーザ動確 9週目 10週目 11週目 12週目 TB計画 チューニング C/O TB8 結合テスト テストBuffer システム総合テスト Buffer セキュリティ試験 性能試験 計画を後ろ倒ししていくと、バッ ユーザー総合テスト ファとして用意したタイムボック スが埋まっていきます。このタイ リリース準備 ムボックスの空き具合がバッファ 残量を示します。
- 23. ＳＷＡＴとは？ ◆リスクの考え方 ・予め高い精度で予測する事が難しい。最後まで、開発規模・仕様が確定されない。 ビジネス検討 要件定義 設計・製造・テスト 通常開発ウオーターフォール 仕様の 規模Ｆｉｘ ブレ幅 ＋ おおよその規模FIX 100% おおよその規模FIX － 仕様詳細を決定しながら、開発 規模Ｆｉｘ SWAT開発 要件定義 ph1 要件定義 ph2 ビジネス検討 ph1 ビジネス検討 ph2 設計・製造・テスト リリース日は予め決めた中で、プロジェクトの後半まで、量や難易度に応じ て調整していくので、開発規模や仕様の範囲は事前には予測できない。 →リクルートが責任を持つ 企画部門(ユーザー部門)、システム担当(システム部門)、開発者の３者が、 密なコミュニケーションを取りながら、開発をコントロールすることが、非常に大切。
- 25. ＳＷＡＴとは？ ◆ＳＷＡＴ開発体制（イメージ） ●プロジェクト体制 ① PLﾁｰﾑ ＰＬ、SL、ｱｰｷﾃｸﾄ 企画部門（企画） ④ 共通アプリ基盤 システム担当（事業）ＳＥ/ＰＧ ＳＥ/ＰＧ ＳＥ/ＰＧ ﾒﾝﾊﾞｰ ③ プロジェクト基盤 ② プロジェクト推進 インフラチーム ① アプリ開発チーム ☆PL、SL、ｱｰｷﾃｸﾄ、開発ﾒﾝﾊﾞｰ ・アプリ全般を担当。 ・事業側と要件定義、アプリの製造、テスト ② プロジェクト推進 ☆ＳＷＡＴスキームの運営 ・ＳＷＡＴスキーム・考え方の教育・指導 ・社内各種調整 ☆プロジェクトモニタリング ・プロジェクトの各種会議の参加、チェックポイントでの確認会の運営 ・環境構築、技術検証、負荷試験サポート等のインフラチームとの窓口 ③ プロジェクト基盤 ・高度なロジックやインフラ面も考慮した設計が必要な部分の実装サポート・確認 ☆共通フレームワークの保守・教育・拡張 ④ 共通アプリ基盤
- 26. ＳＷＡＴとは？ ◆要件・仕様の伝達・決定（旧来のやり方のイメージ） 開発 PM 事業による サービス システム担当 Doc. 企画部門 仕様検討 Doc. ・決定会議 開発 開発 開発 Doc. SE PG TS Doc. Doc. 仕様伝達の流れ 仕様 仕様 仕様 仕様 仕様 仕様確認の流れ 確認 確認 確認 確認 決定 回答 回答 回答 回答 ・決定・コミュニケーションの遅れが最も、開発現場を遅らせる。 ・ドキュメントベースのやりとり、が非常に重い
- 27. ＳＷＡＴとは？ ◆要件・仕様の伝達・決定 ◆SWAT開発 システム担当 事業による 確認内容に関係する 要件確認会 サービス 開発者は全員出席 意思決定 仕様検討 企画部門 開発チーム ・決定会議 Doc. 企画担当者が出席 仕様伝達の流れ 仕様 仕様 仕様確認の流れ 確認 決定 回答 ・企画部門（企画担当者）・システム担当（システム担当者・開発者が対面で要求・仕様を 伝達・確認。
- 28. ＳＷＡＴとは？ ◆要件確認会の内容 ■毎週、定例でシステム機能毎の具体的な要件・使用を確認・決定する。 ・ドキュメントではなく、プロジェクター上にて動くアプリと簡易設計書にまと めた確認事項を映し、仕様確認及びアプリのお披露目を行う。 ・確認した事項はプロジェクタ上で簡易設計書に随時記述し、 確認会参加者で共通認識する システム担当 要件確認会 意思決定 企画部門 開発チーム Doc. 確認内容に関係する 開発者は全員出席 企画担当者が出席
- 29. ＳＷＡＴとは？ ◆要件確認会のコミュニケーション原則 ・確認する画面の実装者自身が発表を行い、確認を行う。 ・他機能への影響をチェック・共有するため、周辺機能のメンバーは出 席する。 ・要件確認会以外の場で担当者のみで要件内容を変更すると、仕様齟齬 が生じたり、他機能への影響に気づかない可能性があるため、必ず要 件については、要件確認会で決定する。 ・10分以上議論しても結論が出ない議案は、プロジェクト開発定例へエ スカレーションし、意思決定できるメンバーで結論を出す。 ・事業側、開発側共に“80%ルール（仮決め）”により意思決定を素早 く行う。 ※80%ルールについて ・企画部門・システム担当・開発パートナーとも８０％の精度でコミュニケーションをとり、 間違いがあった場合はその都度、三者でフォローするようにする。 ・判断に必要な情報を１００％そろえて判断するのではなく、８０％の情報で判断をして 前に進む。 →あいまいな状況の中で判断をして前にすすみ、間違えていたらその都度軌道を修正。
- 30. SWAT 企画・事業担当者 向け心得（抜粋） ◆ケース １ 一度決めた内容が、難易度が高いことが判明した。 要件定義 ph1 要件定義 ph2 設計・製造・動作確認 ＢＡＤケース ③わっ、わかりました・・・ 開発 企画部門 システム ② えっ！困ります。 担当 できるっていったじゃないで すか。要件定義書にもこう書 いてありますし。なんとか頑 まいったなぁ、手戻りも ① この検索が複雑で、 張ってくれませんか。 大きいし。次からはちゃ 実装してみると、性能 んと時間をかけて調査 上、問題がありそうで しないと。 す。 これが積み重なると、 お互い、ジャッジが慎重になり、 どんどん効率が落ちていきます。 「持ち帰って検討します・・・」
- 31. SWAT 企画・事業担当者 向け心得（抜粋） ◆ケース １ 一度決めた内容が、難易度が高いことが判明した。 要件定義 ph1 要件定義 ph2 設計・製造・動作確認 開発 企画部門 システム 担当 ① この検索が複雑で、 実装してみると、性能 上、問題がありそうで ②そうですか・・・ す。 それでは別の仕様で目的を 果たす方法を考えましょう！ ＧＯＯＤケース 互いに１００％のジャッジ精度を相手に求めたり、変更が効かないと時間がかかる。 ８０％正しそうならジャッジして先に進めていくのと、ジャッジが間違っていたら、お互 い協力して、すぐにリカバリーしていくことが重要。（これが後からの“仕様変更あり” の意味。×「後で決めれば良い」 ○「ジャッジが間違っていたら正しく直せば良いの で、素早くジャッジする」 ＝８０％ルール）
- 32. SWAT 企画・事業担当者 向け心得（抜粋） ◆ケース 2 要件確認会にて、随時意思決定がなされない。 要件定義 ph1 要件定義 ph2 設計・製造・動作確認 ＢＡＤケース システム 開発 担当 企画部門 ③ わかりました。2,3日なら。 ②う～ん、ここは私では （とりあえず、他の機能を進める ①この機能はこれで 決められませんね。 かー。けど、後の工程がパツパ いいですか？ 次回の会議で聞いてみる ツだな。） ので、2,3日待ってもらえま す？ これが積み重なると、納期通りにC/O できない可能性があります。
- 33. SWAT 企画・事業担当者 向け心得（抜粋） ◆ケース 2 要件確認会にて、随時意思決定がなされない。 要件定義 ph1 要件定義 ph2 設計・製造・動作確認 システム 開発 担当 企画部門 ①この機能はこれで いいですか？ ②機能の目的・主旨は営業に確 認済です。詳細な仕様は未確認 ＧＯＯＤケース ですが、ほぼ間違いないので、こ れで進めてください。後で念のた め、営業に念押ししておきます。 ※ SWAT開発では、要件確認会にて随時意思決定する必要があるため、会議前にス テークホルダーに判断軸の確認しておきつつ、“80%ルール”で決定していく。
- 34. SWAT 企画・事業担当者 向け心得（抜粋） ◆ケース 3 開発中に規模が膨らみすぎていることが判明した。 要件定義 ph1 要件定義 ph2 設計・製造・動作確認 ＢＡＤケース ③ わかりました。 工数一覧を作成します ね システム 開発 担当 企画部門 ① 機能の絞込みをしないと ② それでは機能毎の 納期に間に合わないですね。 工数一覧を出してください。 それで優先順位が付けて 見積もり作業に手が取られ、 機能を絞ります。 大きくロスしてしまいます。
- 35. SWAT 企画・事業担当者 向け心得（抜粋） ◆ケース 3 開発中に規模が膨らみすぎていることが判明した。 要件定義 ph1 要件定義 ph2 設計・製造・動作確認 システム 開発 担当 企画部門 ① 機能の絞込みをしないと 納期に間に合わないですね。 ②わかりました。大きなくくりで後回しでも ＧＯＯＤケース 良い機能を再検討します。逆に、どこを 削れば想定規模に収まりそう、とか予測 があれば、教えてください。 ※ ウオーターフロー開発では、開発フェーズに入ってからは、想定しないケース。 ※ 開発フェーズ時に、調査や検討に時間をかけない。
- 36. SWAT 企画・事業担当者 向け心得（抜粋） ◆ケース ４ 開発中に、影響の大きそうな仕様変更要望があがってきた。 要件定義 ph1 要件定義 ph2 設計・製造・動作確認 ＢＡＤケース ③ わかりました。 影響範囲を確認します。 システム 開発 担当 企画部門 ② それをやると、テーブルに ① この画面に 変更が入るので影響が大き ○○の そう。持ち帰って影響範囲を 機能を付けたいで 本来であれば、持ち返って影響調査 調査してもらえますか？ すね。 をするべきシーンかもしれませんが、 これが積み重なると、スピードを大き く阻害して、調査などの工数もかさみ ます。
- 37. SWAT 企画・事業担当者 向け心得（抜粋） ◆ケース ４ 開発中に、影響の大きそうな仕様変更要望があがってきた。 要件定義 ph1 要件定義 ph2 設計・製造・動作確認 システム 開発 担当 企画部門 ① この画面に ○○の 機能を付けたいで ②それをやると、テーブルに変 すね。 更が入るので影響が大きそう。 それよりは、こちらの方法なら、 軽く済むと思うので、こちらで 行きませんか？ ＧＯＯＤケース ※ SWAT開発では要件確認会の場で、このようにリアルタイムで規模コントロール するためのコミュニケーションが求められる。
- 38. ＳＷＡＴ 全体図 まとめ
- 39. ＳＷＡＴとは？ ◆SWATの開発 まとめ ・80％の意思決定で行う。 ◆特徴 仮決め開発による意志決定のスピード化、納期圧縮 ビジネス検討 ビジネス検討 C/O （事業戦略立案） （事業要件の具体化） 開発工程完了 要件定義 要件定義 Phase1 Phase2 ◆特徴 単体 セキュリティ アプリケーション保守・改善 設計・製造・動作確認 テスト 性能テスト 開発パートナーのビジネス検討フェーズ参 加 設計書記述 ユーザ確認（テスト） 全件テスト ・開発当事者が入る事により、仕様 業務運用設計 業務運用設計 運用 のキャッチアップを早く行える。 Phase1 Phase2 テスト ・要件定義をしながら、画面を作成していく。 ◆特徴 ・製造期間中からユーザー側で動作確認を行う。 作業工程の変更による納期圧縮 ・徐々に仕様細部を決定しながら製造していく （タイムボックス）
- 42. ご清聴、ありがとうございました。
Notas del editor
- はじめまして。リクルートの前田といいます。よろしくお願いします。12-A-5開発プロセスの実例紹介ということで、ユーザー企業責任の２５サイトをアジャイルに開発というタイトルでお話させていただきます。
- 本日のテーマ
- 開発プロセスのトラックのコンテンツをご担当されている永和システムマネジメントの角谷さんからこの観点でデブサミの準備の一環としてコンテンツ委員である私は次のようなアジャイル開発の事例を探す旅に出たのだった:完全内製ではないユーザ企業が、 自社システムのビジネス価値を高めるために、 アジャイル開発の考え方を自分たちの現場に適用させる試みを組織的に、 年単位(こんかいの事例では3年)で取り組んでいる 今回の事例が唯一無二の正解というつもりはないけれども、ましてや、自社のビジネスの根幹を真剣に考えて組織的に実践したひとつの事例として、発注者/受注者双方にとって考えるヒントは満載のはず。<number>
- <number>
- まず、リクルート、それから、私が所属しています、システム担当という部署のご説明をさせてください。ここをご説明しないと、その次のビジネス上の課題や、システム開発の中での役割がわかりにくくなってしまいますので、少々、お付き合いください。<number>
- ◇リクルートの会社概要・広告媒体・広告、出版の業務を行っている。・2001年からNet展開をしている。・企画部門＝メディア・プロデユース◇システム担当の役割・ITの観点から・・<number>
- 【システム担当の組織概要】システム担当は一般的にシステム情報部門と同じような業務ですが、唯一、事業部に張り付いて（同一フロアーにて）業務を行うのが特徴です。その中で、システム担当基盤推進室は全社的な視点から共通性の高いサービスを提供する部隊です。<number>
- <number>
- <number>
- <number>
- <number>
- <number>
- <number>
- <number>
- <number>
- <number>
- <number>
- <number>
- <number>
- ●ビジネス検討時に事業部側からワイヤーを提出。 ワイヤーとは画面イメージみたいなもの◇特徴１・開発者が入る事で、システムの見えない部分からサポートできる。・仕様のキャッチアップを早くする。◇特徴２・要件定義をやりながら、画面を作成していきます。 登録系だとエラーチェックなどを入れない。・テストはチェックリストを作るようなテストでは無い。・ユーザー側からチェックする。◇特徴３・80％の意思決定でを行う。・◇特徴４・要件をカッチリと決めないで、並行稼動していく。<number>
- ■ ビジネス検討PH1 ・ターゲット分析、商品・サービス設計、及びユーザ設計、フィーチャー＆ファンクションの検討を実施するPH2 ・KPI設計、業務・運用設計（大枠）の検討、及びワイヤーフレーム、グラフィックデザイン検討を実施する。C/Oに盛込むシステム化範囲の仮決定をする。■ 要件定義PH1 ・要件定義PH2の準備期間。PH2 ・サイクル1 ビジネス検討PH2で検討したシステム化範囲の要件を詳細に詰めていく。 ・サイクル2 サイクル1で作成したアプリの動作確認の結果、さらに要件を詳細に詰めていく。■ 設計・製造・動作確認・サイクル1 画面を正常系として、一通り製造し、動作確認を実施する。 仕様確認しながら確定していく目的の為の製造として、以下の実装はしなくても良い。 複雑な入力チェック（バリデーション以外）、異常系処理 特殊なログ実装・ メール機能 ・ バッチが絡んでいる機能 各種外部連携 特殊要件・サイクル2 サイクル1で作成したアプリを完成させ、動作確認を実施する。■ ユーザ動作確認 製造されたアプリを随時、企画部門、システム担当が動作確認をする。■ テスト 仕様書を作成し、単体テスト、セキュリティテスト、性能テスト、結合/総合テストを実施する。<number>
- 1週間単位<number>
- 一見、当たりまえのようにも見えるが、要件定義終了時の規模見積で、予算や決裁をすることになれているユーザー企業側からすると、ものすごい変化。このことをリクルート担当者に理解させるのが最も大事。<number>
- <number>
- ①開発パートナーアプリチーム 開発パートナーアプリチームで業務をやって頂く。②プロジェクト推進 プロジェクト編成とSWATスキームの運営の役割をする。③AP基盤 環境構築、構築、負荷試験等のサポートを行う。<number>
- ドキュメントベースのやりとり・何をやるかという「決定事項」を後で言った/言わないにならぬよう、 それぞれのコミュニケーションで、確認にパワーと時間を使う。 ドキュメントも、「間違って理解されないための日本語の表現を、必死で修正したり、指摘したり」ということになる。こうすることは、各々の責任範囲をはっきりさせて、仕様細部を確定するためには、手堅いやり方ではありますが、我々は、「開発者が開発をスムーズに行いたいときに、やられると嫌がること」を排除すること、に一番、重視していました。この場合でいえば、「確認事項がいつまで経っても回答が帰ってこず、予定スケジュールは過ぎてゆくが、手戻りが怖いので開発が進められない」という状況、 これを排除したいと考えました。<number>
- ・リクルート側から、企画部門といわれる企画担当者、とシステム担当、システム担当者が、週1回の要件確認会に出席し、仕様の詳細を詰めていきます。・開発チーム側は、SEとプログラマーの区別はなく、確認内容に関係する開発者は全員出席が原則です。・この週1回の要件確認会の場で、主に開発者側からリクルート側に確認の質問が投げかけられ、企画部門,システム担当は、原則、その場で回答、あるいは決定をしていきます。・もちろん、このためには、特に企画部門は事業の代表者として、サービス細部を決定する必要があるので、十分に権限を与えられていなければなりませんし、また、本人も重要な決定を事前に事業内で理解を得ておくなどのスキルが必要です。・ただし、このとき、この場で決定した一言一句が、全て、変更が利かない、100%の責任を追わなければいけないものであれば、 企画部門も、 そして、 開発者側も その場で決定することをためらいます。<number>
- <number>
- ・要件確認会では、短時間で多くの要件をＦＩＸする必要があるため、10分以上議論しても結論が出ない議案は、プロジェクト開発定例へエスカレーションし、意思決定できるメンバーで結論を出す。 ・要件確認会以外の場で担当者ベースで要件内容を変更すると、仕様齟齬が生じる可能性があるため、必ず要件については、要件確認会で決定する。 ・要件確認会での要件決定内容は、要件確認会に参加できなかった関係者にも迅速に展開する必要がある（要件確認共有会）。・PLが進行を行い、確認する画面の実装者が発表を行う。・出席メンバーは、PLチームと関係するユニットに限定する。 ※PLチーム、ユニットについては後述。・事業側、開発側共に80%ルール（仮決め）により意思決定を素早く行う（※）。・その他のポイントは、別紙要件確認会観点シートを参照。ーーーーーーーーーーーーー※80%ルールについて・企画部門・システム担当・開発パートナーとも８０％の精度でコミュニケーションをとり、間違いがあった場合はその都度3者でフォローするようにする。 ・判断に必要な情報を１００％そろえて判断するのではなく、８０％の情報で判断をして前に進む。 ・あいまいな状況の中で判断をして前にすすみ、間違えていたらその都度軌道を修正していく。※ただし、C/O時期を遵守するためチェックポイントを設け、仕様変更できる範囲を制限していく。<number>
- <number>
- <number>
- <number>
- <number>
- <number>
- <number>
- <number>
- <number>
- <number>
- ●ビジネス検討時に事業部側からワイヤーを提出。 ワイヤーとは画面イメージみたいなもの◇特徴１・開発者が入る事で、システムの見えない部分からサポートできる。・仕様のキャッチアップを早くする。◇特徴２・要件定義をやりながら、画面を作成していきます。 登録系だとエラーチェックなどを入れない。・テストはチェックリストを作るようなテストでは無い。・ユーザー側からチェックする。◇特徴３・80％の意思決定でを行う。・◇特徴４・要件をカッチリと決めないで、並行稼動していく。<number>
- ●ビジネス検討時に事業部側からワイヤーを提出。 ワイヤーとは画面イメージみたいなもの◇特徴１・開発者が入る事で、システムの見えない部分からサポートできる。・仕様のキャッチアップを早くする。◇特徴２・要件定義をやりながら、画面を作成していきます。 登録系だとエラーチェックなどを入れない。・テストはチェックリストを作るようなテストでは無い。・ユーザー側からチェックする。◇特徴３・80％の意思決定でを行う。・◇特徴４・要件をカッチリと決めないで、並行稼動していく。<number>
- ●ビジネス検討時に事業部側からワイヤーを提出。 ワイヤーとは画面イメージみたいなもの◇特徴１・開発者が入る事で、システムの見えない部分からサポートできる。・仕様のキャッチアップを早くする。◇特徴２・要件定義をやりながら、画面を作成していきます。 登録系だとエラーチェックなどを入れない。・テストはチェックリストを作るようなテストでは無い。・ユーザー側からチェックする。◇特徴３・80％の意思決定でを行う。・◇特徴４・要件をカッチリと決めないで、並行稼動していく。