Stg2015 1c-1プレゼン資料 いまココにある請負アジャイル開発現場の実態 ～4年で4億弱売上20案件以上の実践経験から語る～
•
1 recomendación•2,061 vistas
2015年2月28日にRegional Scrum Gathering Tokyo 2015にて発表したスライドです。
Recomendados
Más contenido relacionado
Destacado
Similar a Stg2015 1c-1プレゼン資料 いまココにある請負アジャイル開発現場の実態 ～4年で4億弱売上20案件以上の実践経験から語る～
Similar a Stg2015 1c-1プレゼン資料 いまココにある請負アジャイル開発現場の実態 ～4年で4億弱売上20案件以上の実践経験から語る～ (20)
Stg2015 1c-1プレゼン資料 いまココにある請負アジャイル開発現場の実態 ～4年で4億弱売上20案件以上の実践経験から語る～
- 1. いまココにある請負アジャイル開発現場の実態 ～4年で4億弱売上20案件以上の実践経験から語る～ Regional Scrum Gathering Tokyo 2015 1C-1セッション 2015年2月28日 株式会社 アドヴァンスト・ソフト・エンジニアリング 技術開発部 シニアマネージャー 渡会 健
- 2. 1965年6月17日生まれ。49歳。ふたご座のO型。 茨城県南部の田舎にマイホームを構える遠距離通勤者。多感な高校 生の親でもある。 休日はPTA活動、地域の自治会副会長、地域の子ども会連合の本部 役員として、地域に密着したボランティアを行う。 趣味はゴルフ。と言いたいところだが大分ご無沙汰してます。 その他の趣味は、写真、日曜大工、映画鑑賞等。 新しいもの好き。まずは何でも試してみるのが信条。 一人で仕事するよりもチームとして仕事をするのが好き。 若い後輩を育てるのも好きで、毎年新入社員をチームに加えている。 人と話をするのも大好きである。 日本PMI アジャイルPM研究会、アジャイルプロセス協議会所属 まずは、自己紹介から 2
- 3. 某工業大学機械工学科を卒業後、某財閥系の宇宙分野のソフトウェ ア開発会社に入社。 最初の3年は何故か防衛系のハードウェア開発に従事。その後現 JAXA（当時はNASDA)のソフトウェア開発に従事する。 1996年～2000年にかけてJAXAに出向し、発注側の立場でシステ ム開発に関わる。その時にProject Managementに興味を得る。 出向から戻ってきた後は受注側としてJAXA向けのシステム開発に 従事。この頃にPMP資格を取得した。 2007年1月、PMP資格を有効に生かすためにProject Management を専門とするコンサル会社に転職。この頃にAgileに出会う。 2009年10月にやっぱり現場のモノづくりが恋しくなって現在の株 式会社アドヴァンスト・ソフト・エンジニアリングに転職。現在に 至る。 3
- 4. 社名 株式会社アドヴァンスト･ソフト･エンジニアリング 設立 1986年8月 資本金 9,500万円 社員数 104名 ＊札幌本社34名、東京支店70名 2014/10/1現在 本社 札幌市厚別区下野幌テクノパーク1-2-16 支店 東京都中央区銀座1-28-13 ASEビル 事業 （1）ソフトウェア受託開発 ＊技術者派遣を含む （2）システム開発、及び導入コンサルティング （3）ソフトウェアパッケージ開発、及び販売 認証 ISO27001 ＊2008年6月取得 Pマーク ＊2013年4月取得 4
- 6. アジャイル開発 事業 4年程前から取 組みを開始 現在十数名体制 ベースとなる大手ベンダー系事業 （バリバリのウォーターフォール開発） 【社会インフラを支える事業】 • 航空管制システム • 警察通信指令システム • 消防通信指令システム • 自治体システム • ＥＴＣシステム 等々 現在売上の85％ 現在売上の15％ 6
- 7. アジャイル開発 事業 4年程前から取 組みを開始 現在十数名体制 ベースとなる大手ベンダー系事業 （バリバリのウォーターフォール開発） 【社会インフラを支える事業】 • 航空管制システム • 警察通信指令システム • 消防通信指令システム • 自治体システム • ＥＴＣシステム 等々 現在売上の85％ アジャイル開発事業 対応できる技術者を増やし て体制強化し拡大する計画 現在売上の 15％ 全体売上30％以上を目標売上規模は変えずに現状維持 7
- 8. 8 Ⅰ タイプ別Agile PJ事例 Ⅱ プラクティスの適用及び改善事例 Ⅲ これからAgileに挑む方へ
- 9. Agenda 9 Ⅰ タイプ別Agile PJ事例 Ⅱ プラクティスの適用及び改善事例 Ⅲ これからAgileに挑む方へ
- 11. 11 対象 ISP業向けバックボーン情報発信ポータルサイト 契約形態 一括請負 契約範囲 要件定義、基本設計、詳細設計、製造、単体試験、 結合試験、総合試験、サービスイン 納品物 要件定義書、基本設計（画面設計書、DB設計書込）、 詳細設計書、テスト計画書兼報告書、マニュアル 開発期間 3か月 スプリント単位 2週間 スプリント回数 4回 開発メンバー数 4人
- 13. 13 Agileで開発することを事前にお客様と合意する 契約前が望ましいが、始まってからでも必ず最初に合意する Agileだと何が通常と異なる（詳細は下記）かも事細かく説明し、合意する 要件定義の意味合いをW/F時とは変える お客様の真の目的を探り、方向性が決められる粒度にする 変更を受け入れる。但し逐次修正ではなく、最後に要件定義書に反映する ドキュメントは真面目に作成する システムがほぼできた段階で、ドキュメント作成専用のスプリントを設けて実施 作成するドキュメントは後の運用・改変に必要な情報をまとめたものと位置付ける 可能な限りツールで自動生成できるものとする オンラインマニュアルでOKな時は、紙のマニュアルを割愛できるか調整する テストも真面目に行います 単体は基本自動テスト、結合も可能な限り自動テストにし、スプリント内で行う 自動テストのものはツールが出力したものをエビデンスとする 総合テストは、専用のスプリントを設けてW/Fとほぼ同じ様に実施
- 15. 15 対象 医療系向けイントラSNS 契約形態 一括請負 契約範囲 RFPに示したイメージのシステムがサービスインできる こと 納品物 要件定義書、設計書（運用に必要なレベルの記述）、 ソースコード、テスト計画書兼報告書、マニュアル （オンラインのみ） 開発期間 6か月 スプリント単位 2週間 スプリント回数 8回 開発メンバー数 6人
- 16. 16 1ヵ月 2ヵ月 3ヵ月 4ヵ月 5ヵ月 6ヵ月 要件定義 開発環境構築 （スプリント0） スプリント１ （機能A、B） スプリント２ （機能B、C） スプリント３ （機能B、D） スプリント４ （機能D、E） スプリント５ （機能F、G） スプリント6 （機能H、I、J） スプリント７ （文書作成、総合試験） スプリント８ （文書作成、総合試験） 試運用 （データ投入） 納品、検収 （最後のフィードバック）
- 17. 17 Agileで開発することのお客様メリットをアピールして勝ち抜く 動くものを実際に触って確認しながら開発を進めていくので、利用イメージを掴みやすい 仕様変更を積極的に受け入れるので、明確に仕様が決まっていなくても始められる コンペは勝率よりも提案件数をこなす（10件に1件取れれば良いくらいの気持ち） 「この開発によるお客様の価値/利益を一緒に追求します。」と言うスタンス 「仕様通りに作ります」では足りない お客様の価値観ベースで考えるからこそ、信頼が得られる 仕様変更は受け入れるが、優先順位を重視する（仕様変更≠追加作業） 本当に重要な機能から着手することで、システムの根幹をぶらつかせない 限られたリソースの中で、仕様変更を含め優先順位の高いものから実施 場合によっては優先順位の低いものは作らない（＝価値の低いものは作らない） これらは真の信頼関係を築けてこそ、バランスのとれた調整ができる 考え抜いたスプリント計画を立てる 開発の中で時間がかかりそうな機能は複数スプリントに渡って徐々に完成させる ドキュメントは最後に出来上がったものを元に作成 試用期間後に余裕を持たせ、最後のフィードバックを入れられる余裕を持つ
- 19. 19 対象 海外留学者と中小企業を結ぶ就職支援サイト （Est Navi URL https://www.est-navi.jp） 契約形態 レベニューシェアー 契約範囲 ビジネスの変化に柔軟に対応しながらのシステム開発 納品物 動くシステム（稼げるシステム） 開発期間 初期リリース（2014年7月1日）までは1か月半 その後は概ね2週間ごとに追加機能をリリース スプリント単位 2週間（後に4週間） スプリント回数 現時点で13回（今後も増加） 開発メンバー数 3人
- 20. 20 ちょっとだけ宣伝 1. 登録されている求職者は4 週間以上の海外生活経験者 のみ 2. 利用できる企業は中小・ ベンチャー企業のみ 3. 写真･ブログ･動画などでレ ジュメには表れてこない 【人物】や【行動】を確認 してスカウトしていく 4. 海外生活経験者専門のキャ リアカウンセラーが渡航前 からの成長を言語化し求職 者と企業のミスマッチを防 ぐ URL https://www.est-navi.jp ご用命の方は、以下にお問い合わせください（私へでも可） 株式会社エストレリータ 03-5348-1720 est-navi@estrellita.co.jp https://www.facebook.com/estrellita.estnavi
- 21. 21 1ヵ月 2ヵ月 3ヵ月 ・・・ Nヵ月 N+1ヵ月 N+2ヵ月 初期開発 （スモールスタート） スプリント１ スプリント２ スプリント３ 品質強化期間 （一時的に要員増） ・ ・ ・ スプリント11 スプリント12 スプリント13 スプリントN 重大なバグ 発生 ビジネス変化 による大きな リリース項目 変更
- 22. 22 スモールスタート 色々な事情があり、最短でサイトを公開する必要があったので、カウボーイコーディングで まずは最初機能をリリース その後通常のスプリントと並行して一時的に要員を追加し、初期開発分の品質強化を実施 Agileでメリットを最大限に生かす スプリント毎に追加機能をリリース 納入するものではないので、ドキュメントは作成していない 但し、Redmineでバックログ、プロダクトログを記録し、全メンバーで共有 リリースする機能も、ビジネス的な観点から有効に顧客を獲得できるものを臨機応変に優先 度を変えて実装している 一度リリースした機能も、ユーザからの声を元に短期間で改善しリリースしている
- 23. 23 スプリント単位の変更（品質担保重視へ） 当初は機能の充実が最優先であったため、ビジネスパートナーとも合意の上で敢えて品質担 保に費やすリソースを削り、機能リリースに費やしていた しかし、重大なバグが発生してしまい、一部のユーザにご迷惑をお掛けしてしまった これを契機に、2週間単位のスプリントを4週間に変え、十分に品質担保をできるプロセスを 再構築した（途中で状況に応じてやり方を変えるのもAgile） ただし、2週間毎のリリースは変えたくなかったので、4週間で作ったものを2回に分けてリ リースする形で両立させた スプリント途中の仕切り直し（ビジネス変化への柔軟な対応） スプリントを開始した半ばごろ、ビジネスパートナー側の営業戦略の変化に伴い優先すべき リリース機能が変わってしまった そこで、それまでに行っていた機能の成果を記録に残してそのスプリントを中断 新たに優先度が上げられた機能をリリースするためのスプリントをその時点から仕切り直し で開始した
- 24. Agenda 24 Ⅱ プラクティスの適用及び改善事例 Ⅰ タイプ別Agile PJ事例 Ⅲ これからAgileに挑む方へ
- 25. IPAが定義している「アジャイル型開発におけるプラクティス活用リファレン スガイド」で定義している全49のプラクティスを尺度に、私たちがどれだけ 試したことが実際に有るかを確認してみました。 25 リリース計画ミーティ ング バーンダウンチャート ユニットテストの自動 化 バグ時の再現テスト チーム全体が一つに イテレーション計画 ミーティング 柔軟なプロセス 受入れテスト 紙・手書きツール 組織に合わせたアジャ イルスタイル イテレーション ユーザーストーリー システムメタファ 顧客プロキシ 共通の部屋 プランニングポーカー スプリントバックログ スパイク・ソリュー ション オンサイト顧客 人材のローテーション ベロシティ計画 インセプションデッキ リファクタリング プロダクトオーナー インテグレーション専 用マシン 日次ミーティング プロダクトバックログ シンプルデザイン ファシリテータ（スク ラムマスター） ユーザーストーリー マッピング ふりかえり 迅速なフィードバック 逐次の統合 アジャイルコーチ 「完了」の定義 かんばん ペアプログラミング 継続的インテグレー ション 自己組織化チーム 楽しい工夫 スプリントレビュー 自動化された回帰テス ト 集団によるオーナー シップ ニコニコカレンダー 組織のバウンダリをゆ るめる タスクボード テスト駆動開発 コーディング規約 持続可能なペース
- 26. IPAが定義している「アジャイル型開発におけるプラクティス活用リファレン スガイド」で定義している全49のプラクティスを尺度に、私たちがどれだけ 試したことが実際に有るかを確認してみました。 26 リリース計画ミーティ ング バーンダウンチャート ユニットテストの自動 化 バグ時の再現テスト チーム全体が一つに イテレーション計画 ミーティング 柔軟なプロセス 受入れテスト 紙・手書きツール 組織に合わせたアジャ イルスタイル イテレーション ユーザーストーリー システムメタファ 顧客プロキシ 共通の部屋 プランニングポーカー スプリントバックログ スパイク・ソリュー ション オンサイト顧客 人材のローテーション ベロシティ計画 インセプションデッキ リファクタリング プロダクトオーナー インテグレーション専 用マシン 日次ミーティング プロダクトバックログ シンプルデザイン ファシリテータ（スク ラムマスター） ユーザーストーリー マッピング ふりかえり 迅速なフィードバック 逐次の統合 アジャイルコーチ 「完了」の定義 かんばん ペアプログラミング 継続的インテグレー ション 自己組織化チーム 楽しい工夫 スプリントレビュー 自動化された回帰テス ト 集団によるオーナー シップ ニコニコカレンダー 組織のバウンダリをゆ るめる タスクボード テスト駆動開発 コーディング規約 持続可能なペース
- 29. 総タスク数 残タスク数 理想の残タスク 総タスク数 残タスク数 消化タスク数 タ ス ク 数 タ ス ク 数 経過時間 経過時間 良くあるバーンダウンチャート 弊社のバーンダウンチャート 29
- 30. 実際のバーンダウンチャート 30
- 32. 32 全員が発言することでメンバが考えていることが良くわかり、コミュニケー ションの充実と、改善の洗い出しにはとても良いプラクティスです ただ、漫然と続けていくと途中でマンネリ化することが多いのも確かでした そこで、様々な工夫を行いました（今でも継続して改善中） KPTにThanksを加えてKPTTとする ファシリテータを当番制にする 前回のTryを踏まえてKeep、Problemを洗い出す Tryの前に今回出てきたProblemを分類し、Tryの元ネタとする 個人レベルのKPTTも同時に行う （To be Continue…）
- 35. Agenda 35 Ⅲ これからAgileに挑む方へ ～Agileで悩んでいる方へ～ Ⅰ タイプ別Agile PJ事例 Ⅱ プラクティスの適用及び改善事例
- 37. 37 アジャイルソフトウェア開発宣言の精神に乗っ取ってさえいれば、所謂 代表的なプラクティスを導入していなくてもAgileです 合わなければ自分たちに合うようにやり方を工夫する そういうチームを育成するためにプラクティスがある 仕様を満たすだけでは不十分 AgileをやるようになってW/Fの良い部分が見える様になった Agileに興味を持ったのであれば、まずは自分たちの出来る小さな範囲から試 してみましょう。そこから工夫を重ねれば、おのずと道は開かれます。
- 38. 38 目標=価値 発注者 開発者 仕様 成果物 全部出来てみないと目的に 即しているかわからない 出来たもののイメージが 違ったら仕様変更せざる得 ない 仕様のみが唯一の情報 発注者の言われるままに作 るしかない 仕様変更が出されても何で 変更になったかわからない 上位下達の仕組み 変化の無い決まった ものを作る際にはと ても有効
- 39. 39 発注者 開発者 目標=価値 目的を共有しているので何 故この仕様が必要なのかを 伝えやすい 動くもので逐次確認でき、 イメージがずれづらい 価値志向なので、仕様変更 も受け入れられやすい 対話と調和を基本 価値志向なので、変 化はそのための手段 目的が見える形で参画 自律的に仕様を考えられる 疑問があれば発注者とすぐ 対話できるので迷わない 具体的に自分たちが作った 物がどう役立つのかが見え るので、モチベーション大 調和と対話 価値志向 価値志向
- 41. 41
- 42. 42 ご清聴ありがとうございました。 この発表で、Agileに今一つ踏み出せない方々の背中を 少しでも押すことが出来れば、望外の幸せです。 ご質問・ご用命などございましたら、 下記までお願いいたします。 渡会 健 （わたらい たけし） Twitter @ase_watarai Web www.ase.co.jp