Editor's Notes
- #2: はじめまして。リクルートの前田といいます。よろしくお願いします。12-A-5開発プロセスの実例紹介ということで、ユーザー企業責任の２５サイトをアジャイルに開発というタイトルでお話させていただきます。
- #3: 本日のテーマ
- #4: 開発プロセスのトラックのコンテンツをご担当されている永和システムマネジメントの角谷さんからこの観点でデブサミの準備の一環としてコンテンツ委員である私は次のようなアジャイル開発の事例を探す旅に出たのだった:完全内製ではないユーザ企業が、 自社システムのビジネス価値を高めるために、 アジャイル開発の考え方を自分たちの現場に適用させる試みを組織的に、 年単位(こんかいの事例では3年)で取り組んでいる 今回の事例が唯一無二の正解というつもりはないけれども、ましてや、自社のビジネスの根幹を真剣に考えて組織的に実践したひとつの事例として、発注者/受注者双方にとって考えるヒントは満載のはず。<number>
- #5: <number>
- #6: まず、リクルート、それから、私が所属しています、システム担当という部署のご説明をさせてください。ここをご説明しないと、その次のビジネス上の課題や、システム開発の中での役割がわかりにくくなってしまいますので、少々、お付き合いください。<number>
- #7: ◇リクルートの会社概要・広告媒体・広告、出版の業務を行っている。・2001年からNet展開をしている。・企画部門＝メディア・プロデユース◇システム担当の役割・ITの観点から・・<number>
- #8: 【システム担当の組織概要】システム担当は一般的にシステム情報部門と同じような業務ですが、唯一、事業部に張り付いて（同一フロアーにて）業務を行うのが特徴です。その中で、システム担当基盤推進室は全社的な視点から共通性の高いサービスを提供する部隊です。<number>
- #9: <number>
- #10: <number>
- #11: <number>
- #12: <number>
- #13: <number>
- #14: <number>
- #15: <number>
- #16: <number>
- #17: <number>
- #18: <number>
- #19: <number>
- #20: <number>
- #21: ●ビジネス検討時に事業部側からワイヤーを提出。 ワイヤーとは画面イメージみたいなもの◇特徴１・開発者が入る事で、システムの見えない部分からサポートできる。・仕様のキャッチアップを早くする。◇特徴２・要件定義をやりながら、画面を作成していきます。 登録系だとエラーチェックなどを入れない。・テストはチェックリストを作るようなテストでは無い。・ユーザー側からチェックする。◇特徴３・80％の意思決定でを行う。・◇特徴４・要件をカッチリと決めないで、並行稼動していく。<number>
- #22: ■ ビジネス検討PH1 ・ターゲット分析、商品・サービス設計、及びユーザ設計、フィーチャー＆ファンクションの検討を実施するPH2 ・KPI設計、業務・運用設計（大枠）の検討、及びワイヤーフレーム、グラフィックデザイン検討を実施する。C/Oに盛込むシステム化範囲の仮決定をする。■ 要件定義PH1 ・要件定義PH2の準備期間。PH2 ・サイクル1 ビジネス検討PH2で検討したシステム化範囲の要件を詳細に詰めていく。 ・サイクル2 サイクル1で作成したアプリの動作確認の結果、さらに要件を詳細に詰めていく。■ 設計・製造・動作確認・サイクル1 画面を正常系として、一通り製造し、動作確認を実施する。 仕様確認しながら確定していく目的の為の製造として、以下の実装はしなくても良い。 複雑な入力チェック（バリデーション以外）、異常系処理 特殊なログ実装・ メール機能 ・ バッチが絡んでいる機能 各種外部連携 特殊要件・サイクル2 サイクル1で作成したアプリを完成させ、動作確認を実施する。■ ユーザ動作確認 製造されたアプリを随時、企画部門、システム担当が動作確認をする。■ テスト 仕様書を作成し、単体テスト、セキュリティテスト、性能テスト、結合/総合テストを実施する。<number>
- #23: 1週間単位<number>
- #24: 一見、当たりまえのようにも見えるが、要件定義終了時の規模見積で、予算や決裁をすることになれているユーザー企業側からすると、ものすごい変化。このことをリクルート担当者に理解させるのが最も大事。<number>
- #25: <number>
- #26: ①開発パートナーアプリチーム 開発パートナーアプリチームで業務をやって頂く。②プロジェクト推進 プロジェクト編成とSWATスキームの運営の役割をする。③AP基盤 環境構築、構築、負荷試験等のサポートを行う。<number>
- #27: ドキュメントベースのやりとり・何をやるかという「決定事項」を後で言った/言わないにならぬよう、 それぞれのコミュニケーションで、確認にパワーと時間を使う。 ドキュメントも、「間違って理解されないための日本語の表現を、必死で修正したり、指摘したり」ということになる。こうすることは、各々の責任範囲をはっきりさせて、仕様細部を確定するためには、手堅いやり方ではありますが、我々は、「開発者が開発をスムーズに行いたいときに、やられると嫌がること」を排除すること、に一番、重視していました。この場合でいえば、「確認事項がいつまで経っても回答が帰ってこず、予定スケジュールは過ぎてゆくが、手戻りが怖いので開発が進められない」という状況、 これを排除したいと考えました。<number>
- #28: ・リクルート側から、企画部門といわれる企画担当者、とシステム担当、システム担当者が、週1回の要件確認会に出席し、仕様の詳細を詰めていきます。・開発チーム側は、SEとプログラマーの区別はなく、確認内容に関係する開発者は全員出席が原則です。・この週1回の要件確認会の場で、主に開発者側からリクルート側に確認の質問が投げかけられ、企画部門,システム担当は、原則、その場で回答、あるいは決定をしていきます。・もちろん、このためには、特に企画部門は事業の代表者として、サービス細部を決定する必要があるので、十分に権限を与えられていなければなりませんし、また、本人も重要な決定を事前に事業内で理解を得ておくなどのスキルが必要です。・ただし、このとき、この場で決定した一言一句が、全て、変更が利かない、100%の責任を追わなければいけないものであれば、 企画部門も、 そして、 開発者側も その場で決定することをためらいます。<number>
- #29: <number>
- #30: ・要件確認会では、短時間で多くの要件をＦＩＸする必要があるため、10分以上議論しても結論が出ない議案は、プロジェクト開発定例へエスカレーションし、意思決定できるメンバーで結論を出す。 ・要件確認会以外の場で担当者ベースで要件内容を変更すると、仕様齟齬が生じる可能性があるため、必ず要件については、要件確認会で決定する。 ・要件確認会での要件決定内容は、要件確認会に参加できなかった関係者にも迅速に展開する必要がある（要件確認共有会）。・PLが進行を行い、確認する画面の実装者が発表を行う。・出席メンバーは、PLチームと関係するユニットに限定する。 ※PLチーム、ユニットについては後述。・事業側、開発側共に80%ルール（仮決め）により意思決定を素早く行う（※）。・その他のポイントは、別紙要件確認会観点シートを参照。ーーーーーーーーーーーーー※80%ルールについて・企画部門・システム担当・開発パートナーとも８０％の精度でコミュニケーションをとり、間違いがあった場合はその都度3者でフォローするようにする。 ・判断に必要な情報を１００％そろえて判断するのではなく、８０％の情報で判断をして前に進む。 ・あいまいな状況の中で判断をして前にすすみ、間違えていたらその都度軌道を修正していく。※ただし、C/O時期を遵守するためチェックポイントを設け、仕様変更できる範囲を制限していく。<number>
- #31: <number>
- #32: <number>
- #33: <number>
- #34: <number>
- #35: <number>
- #36: <number>
- #37: <number>
- #38: <number>
- #39: <number>
- #40: ●ビジネス検討時に事業部側からワイヤーを提出。 ワイヤーとは画面イメージみたいなもの◇特徴１・開発者が入る事で、システムの見えない部分からサポートできる。・仕様のキャッチアップを早くする。◇特徴２・要件定義をやりながら、画面を作成していきます。 登録系だとエラーチェックなどを入れない。・テストはチェックリストを作るようなテストでは無い。・ユーザー側からチェックする。◇特徴３・80％の意思決定でを行う。・◇特徴４・要件をカッチリと決めないで、並行稼動していく。<number>
- #41: ●ビジネス検討時に事業部側からワイヤーを提出。 ワイヤーとは画面イメージみたいなもの◇特徴１・開発者が入る事で、システムの見えない部分からサポートできる。・仕様のキャッチアップを早くする。◇特徴２・要件定義をやりながら、画面を作成していきます。 登録系だとエラーチェックなどを入れない。・テストはチェックリストを作るようなテストでは無い。・ユーザー側からチェックする。◇特徴３・80％の意思決定でを行う。・◇特徴４・要件をカッチリと決めないで、並行稼動していく。<number>
- #42: ●ビジネス検討時に事業部側からワイヤーを提出。 ワイヤーとは画面イメージみたいなもの◇特徴１・開発者が入る事で、システムの見えない部分からサポートできる。・仕様のキャッチアップを早くする。◇特徴２・要件定義をやりながら、画面を作成していきます。 登録系だとエラーチェックなどを入れない。・テストはチェックリストを作るようなテストでは無い。・ユーザー側からチェックする。◇特徴３・80％の意思決定でを行う。・◇特徴４・要件をカッチリと決めないで、並行稼動していく。