Improvement_process_for_providing_ongoing_value
- 1. 継続的な価値提供の ための改善プロセス RICOH IT SOLUTIONS 北海道ソリューション部 前鼻 毅 12年7月25日水曜日
- 2. 12年7月25日水曜日 北海道
- 3. 目次 • 背景：基幹系業務システムとコンシューマ向け サービス開発の違い • 課題：価値を届けるということの理想と現実 • 対応：わたしたちのチームの実装 • 知見：経験知から再び形式知へ 12年7月25日水曜日
- 4. 目次 • 背景：基幹系業務システムとコンシューマ向け サービス開発の違い • 課題：価値を届けるということの理想と現実 • 対応：わたしたちのチームの実装 • 知見：経験知から再び形式知へ 12年7月25日水曜日
- 5. 基幹系業務システム （個別開発） • リコー北海道株式会社 • 開発チームリーダー、全工程を担当 • 定義済みの重いプロセスあり • 営業が強い文化 • Access, VisualBasic, C#, SQLServer • 約６年間従事 12年7月25日水曜日
- 6. 基幹系業務 コンシューマ 顧客企業の 顧客 システム担当者 案件ごとに集める チーム 技術力はパートナー依存 大きな障害は賠償問題 保守 保守先が増えていく ベンダー依存 技術 バージョンアップ対応 12年7月25日水曜日
- 7. 基幹系業務 コンシューマ 完成品 品質 仕様通り 決定済み、固定が多い 納期 終わりがある 見積りを先に提出 コスト スコープ依存 価格勝負 見積時に大まかに決定 スコープ 受注後に詳細を確定 12年7月25日水曜日
- 8. 基幹系業務 コンシューマ 要件定義 外部設計 プロセス 詳細設計 実装 テスト 業務効率化 コスト削減 目的 顧客満足度向上 保守・維持可能 12年7月25日水曜日
- 9. 当時の私の悩み •あいまいな見積り依頼 •要件の食い違い、抜け漏れ •複雑で長大な重複したコード •低品質に起因する障害対応の多さ •保守による負荷・割込みの増大 12年7月25日水曜日
- 10. 改善したこと •見積り仕様書の様式作成 •要求 → 実装 → テスト のヒモ付け •スコープの明確化 •設計書の項目見直し、可能なものは生成 •問題領域特化のフレームワーク作成 •保守契約書の様式を作成 12年7月25日水曜日
- 11. 更なる課題 •要件定義に膨大な時間 •やり過ぎのワナ •技術不足による展開の失敗 •テストコードのない複雑なコード •保守による負荷・割込みの増大 •顧客との利害不一致 12年7月25日水曜日
- 12. コンシューマ向け サービス開発 • リコーITソリューションズ • 既存サービスのクライアント開発 • 新規サービスの構築 • 厳密なプロセス定義はない • iOS, Objective-C, Ruby, Rails • 約２年半従事（2009年末∼） 12年7月25日水曜日
- 13. In My 多くの違い Cas e 顧客 技術 スコープ プロセス 目的 保守 納期 コスト 品質 チーム 12年7月25日水曜日
- 14. 基幹系業務 コンシューマ 顧客企業の 発注元・グループ会社 顧客 システム担当者 エンドユーザー 案件ごとに集める 基本的に継続 チーム パートナー依存 育てることが大切 障害は賠償問題 24x365 保守 保守先が増えていく 保つではなく改善 ベンダー依存 オープンソース 技術 バージョンアップ対応 サポートは無い 12年7月25日水曜日
- 15. 基幹系業務 コンシューマ 完成品 α,βサービス 品質 仕様通り 変更前提 テストフェーズ 評価チーム 決定済み、固定が多い ベストエフォート 納期 終わりがある 終わりはない 見積りを先に提出 チーム規模で固定 コスト スコープ依存 機器等は随時 競争あり 見積時に大まかに決定 優先度は変化する スコープ 受注後に詳細を確定 柔軟性が必要 12年7月25日水曜日
- 16. 基幹系業務 コンシューマ 要件定義 大きな期間の目標 外部設計 短い期間の計画 プロセス 詳細設計 リリース前評価 実装 企画・デザイン テスト 業務効率化 魅力的なサービス コスト削減 目的 ビジョンの実現 顧客満足度向上 事業・収益化 保守・維持可能 12年7月25日水曜日
- 17. 目次 • 背景：基幹系業務システムとコンシューマ向け サービス開発 • 課題：価値を届けるということの理想と現実 • 対応：わたしたちのチームの実装 • 知見：経験知から再び形式知へ 12年7月25日水曜日
- 18. 基幹系業務 コンシューマ 業務効率化 魅力的なサービス コスト削減 目的 ビジョンの実現 顧客満足度向上 事業・収益化 保守・維持可能 達成方法 12年7月25日水曜日
- 19. 基幹系業務 コンシューマ 業務効率化 魅力的なサービス コスト削減 目的 ビジョンの実現 顧客満足度向上 事業・収益化 保守・維持可能 速度向上 必要な帳票 フローの簡素化 達成方法 検索強化 情報活用 質の向上 12年7月25日水曜日
- 20. 基幹系業務 コンシューマ 業務効率化 魅力的なサービス コスト削減 目的 ビジョンの実現 顧客満足度向上 事業・収益化 保守・維持可能 速度向上 必要な帳票 正解 達成方法 フローの簡素化 検索強化 ない は ！ 情報活用 質の向上 12年7月25日水曜日
- 21. 何をすべきか？ • 目標に到達するための一般解がない • なにをもって魅力的か • サービスのビジョンはなにか • 如何にして けるか •企画や起業家の領域 12年7月25日水曜日 •価値をどう生み出すか
- 22. 以前の課題 • 要件定義に膨大な時間 • やり過ぎのワナ • 技術不足による展開の失敗 • テストコードのない複雑なコード • 保守による負荷・割込みの増大 • 顧客との利害不一致 12年7月25日水曜日
- 23. 以前の課題 • 要件定義に膨大な時間 決定論的 • やり過ぎのワナ • 技術不足による展開の失敗 • テストコードのない複雑なコード 労働集約的 • 保守による負荷・割込みの増大 • 顧客との利害不一致 事業継続性 12年7月25日水曜日
- 24. 課題解決？ • 要件定義に膨大な時間 決定論的 変化前提 • やり過ぎのワナ • 技術不足による展開の失敗 労働集約的 • テストコードのない複雑なコード 人重視 • 保守による負荷・割込みの増大 事業継続性 • 顧客との利害不一致 持続可能 12年7月25日水曜日
- 25. 開発メイン の領域 Product Strategy 依頼元が メインの 領域 Vision 12年7月25日水曜日
- 26. 変化前提 人重視 持続可能 Product 価値 Strategy 変化前提 人重視 持続可能 Vision 価値 12年7月25日水曜日
- 27. What? Product Strategy How? Vision Why? 12年7月25日水曜日
- 28. Golden Circle 「人は「何を」ではなく 「なぜ」に動かされる」 Why How What サイモン・シネック 優れたリーダーはどうやって行動を促すか http://www.ted.com/talks/lang/ja/simon_sinek_how_great_leaders_inspire_action.html 12年7月25日水曜日
- 29. 理想 そのための 下３つ •価値を生み出す、届ける • 変化に適応する • 人を重視する • 持続可能な状態を作る 12年7月25日水曜日
- 30. 優先 価値を 順位 変化に 無駄が 適応 必要な なくなる 生む 時に 知恵が 密な 信頼 出る 人大事 交流 関係 いきいき 学習 技術力 と働く 持続 重要 多能工 可能 長期の 自動化 視点 12年7月25日水曜日
- 31. 課題 • 生み出すべき価値とは？ • 変化に対応する • 人を重視した 〇〇〇作り • 持続可能な 12年7月25日水曜日
- 32. 課題 • 生み出すべき価値とは？ • 変化に対応する • 人を重視した チーム作り • 持続可能な 12年7月25日水曜日
- 33. 目次 • 背景：基幹系業務システムとコンシューマ向け サービス開発 • 課題：価値を届けるということの理想と現実 • 対応：わたしたちのチームの実装 • 知見：経験知から再び形式知へ 12年7月25日水曜日
- 34. 依頼元の要求 • 目的のひとつ：コンシューマー事業を作る • 技術のある人・チーム • 一緒に面白いことが出来る • オンラインストレージサービスを運営中 • そこに参加し価値づくりに貢献すること 12年7月25日水曜日
- 35. 全体 業務 サービス ~2009 2010 2011 2012 Online web α iPad iPhone App Strage サービス App 2人 3人 4人 5人 イベント New 新規 写真投稿 Service Web iPhone 12年7月25日水曜日
- 36. 全体 業務 サービス ~2009 2010 2011 2012 Online web α iPad iPhone App 1 Strage サービス 2 4 App 2人 3人 4人 3 5人 New イベント 5 新規 写真投稿 Service Web iPhone 12年7月25日水曜日
- 37. 1.web αサービス 2名 • αサービスという位置づけのWebアプリ開発 • まだチームになっておらず個別に作業を実施 • 提示された目標を学習しながら、手探りでなん とかこなしている状態 • 類似画像検索、顔認識等の技術を用いて新しい 発見体験を提供できるかを実験的に行う 12年7月25日水曜日
- 38. 1. 目的 • 新しい地方開発拠点の立ち上げ • Webサービスの経験、関連技術の習得 • 新規技術への挑戦 • ユーザーからのフィードバックを得る 12年7月25日水曜日
- 39. 1. 課題 • 経験・技術不足 • web, Linux, Ruby, Rails, HTML, css, javascript • αサービスを使ってもらうこと • フィードバックを得ること 12年7月25日水曜日
- 40. 1. 対応 • 主に書籍で学習 • 記録をWikiに残す（作業、技術情報） • 1週間単位でふりかえりと計画 • やったことの確認とKPT • ソースコード管理にgitを用いる • 顧客担当とはIRCで密にやりとり • 会員へのmail, Twitter, ニュースサイトで告知 12年7月25日水曜日
- 41. 1. 結果 • 予定の機能実装を達成 • 経験、技術を得たが、不足 • wiki, git, IRCはうまく機能 • フィードバック、盛り上げ策は苦戦 12年7月25日水曜日
- 42. 2. iPhone App 初期 3名→４名 • 正式なプロダクト開発へ、他社開発のiOSアプリ のバージョンアップに着手 • iOS開発が盛り上がりはじめているところ • 他部署から若手を一名引きぬく • その後、問題領域の知見があるメンバーを確保 • パートナーさん、完全常駐。チームの一員 12年7月25日水曜日
- 43. 2. 目的 • iPhoneアプリのバージョンアップリリース • 他社製から自社製へ • トレンドであるiOS開発技術の習得 • 札幌拠点のチームとしての確立 • メンバー間のスキル伝達 12年7月25日水曜日
- 44. 2. 課題 • 圧倒的経験・技術不足 • Objective-C, iOS, WebAPI • 元コードが低品質 • 人数が増えて作業の可視化が必要に • 一週間ごとの作業計画の質向上 • 技術の伝達をどのように行うか 12年7月25日水曜日
- 45. 2. 対応 • 知見のある人を探す → 奇跡的に獲得 • 解析した結果、大部分のつくり直しを決断 • 朝会を開始 • ストーリー、タスクの管理ツール導入 • Pivotal Tracker • 計画ゲーム、ストーリーポイントの導入 • コードレビュー実施 • チーム内勉強会の導入（ライトニングトーク） 12年7月25日水曜日
- 46. 2. 結果 • 進捗を率直に伝え、リリースまでの作戦を協議 • 作業の可視化達成 • 技術的卓越性の獲得 • メンバーのスキル向上速度が早く • 計画ゲームでメンバーの意見取り入れ • チームの速度算出が可能に 12年7月25日水曜日
- 47. 朝会ログ 反復(イテレーション)計画 12年7月25日水曜日
- 48. ストーリーポイントと速度 UserAは〇〇をXXできる 2stp 14 stp/ite 管理者は〇〇をXXできる 18 stp/ite 3stp 20 stp/ite UserBは△△を検索できる 1stp 平均は17stpだね！ 各ストーリーは相対的 反復ごとの速度 な大きさ、全員で見積り 12年7月25日水曜日
- 49. 3. イベント写真投稿サービス 5人 • プロダクトを無事リリース、バージョンアップ を数回重ね、一定の信頼を得た • パートナー1名を更に追加 • 新サービス立ち上げ、複数拠点横断のスモール チームでの開発を行う。自チームはiPhone App • 実装機能やデザイン、やり方などについて 「進みながら考える」で進める 12年7月25日水曜日
- 50. 3. 目的 • 新規サービスの立ち上げ、素早いリリース • ソーシャルサービスとの連携実験 • 多数のユーザー獲得 • 素早い立ち上げ、リリース • 軽いプロセスで回す • 継続した技術向上 12年7月25日水曜日
- 51. 3. 課題 • 「進みながら考える」方法 • 盛り上げるための施策 • 素早く回せるプロセス • 学習速度のさらなる向上 • メンバー間のコミュニケーション促進 • 集中できる時間の確保 12年7月25日水曜日
- 52. 3. 対応 • IRCやTV会議などを駆使して打合せを行う • 各種イベントとタイアップ企画 • 最小限の仕様 • テストコードの導入 • ペアプログラミングの導入 • ２週間単位の計画、ふりかえりに変更 • ポモドーロ（２５分単位で集中）の導入 12年7月25日水曜日
- 53. 3. 結果 • 「考える、決める」のに多くの時間 • 根本的な目的や目指したい姿の統一が困難 • 常時ペアプロは「疲れる」→ ペアレビューへ • iOS環境でのテストコードは非常に時間がかか り、一部に絞っての実装に（単純実装の４倍） • KPT + Happy ”幸せになる、楽をするために” の 視点を追加 • ポモドーロは向き不向きがある。１ストーリー あたりにどれだけ、という単位として残る 12年7月25日水曜日
- 55. 4. iPad App • 20%ルールで開発を行っていたオンラインスト レージサービスの iPad Appを正式リリースする ことに • 関連会社にてiPadの導入が決定されたことや、 市場でビジネス向けにiPad活用が行われている ことが追い風に • 企画の介在なし、評価は別チームで行う 12年7月25日水曜日
- 56. 4. 目的 • iPad Appのリリース • ユーザーの獲得 • 使用時間（アクティブユーザー）の増加、 ダウンロード数に指標を設定 • ビジネス向け用途でも活用できる様に 12年7月25日水曜日
- 57. 4. 課題 • 目的の共有をどのように行うか • このアプリは何を目指すのか？ • デザインについて • 共通機能の扱い(iPhone, iPad) • 個人の20%からチームのプロダクトへ 12年7月25日水曜日
- 58. 4. 対応 • 目的を明確にし、意識統一のためにインセプ ションデッキを作成。特にサービスについて のエレベータピッチを重視して開発を行う • シンプルなデザインを指向するとともに、地 場企業にパーツ作成を依頼 • iPhone, iPad間の共通機能をモジュール化 • 20%ルールで作成していたメンバーからチーム のものへ。デザイン等について対立もあり、 それぞれの価値観を聞くために面談を実施 12年7月25日水曜日
- 59. 4. 結果 • インセプションデッキが効果を発揮、迷ったと きの指針になり、チーム外への説明にも活躍 • リリース時にApp Storeで 仕事効率化カテゴリ 1位を獲得！ • 地場企業にデザインを依頼した実績を作れた • モジュール化はテスト工数の増大やgitを使う 上での複雑性の増加などがあり、一長一短 • 面談などを行って話した結果チーム内で手ごわ い質問をしやすくなった 12年7月25日水曜日
- 60. 12年7月25日水曜日
- 61. 目的の共有 https://github.com/agile-samurai-ja/support 12年7月25日水曜日
- 62. 目的の共有 https://github.com/agile-samurai-ja/support 12年7月25日水曜日
- 63. 5. 新規Webサービス • ついに企画段階から自チーム発 • これまでにチーム内でアイデアを出したり、 議論してきた内容からサービスを提案 • サーバサイドも含めての実装 • ニュースレコメンドサービス • Ruby, Rails 再び 12年7月25日水曜日
- 64. 5. 目的 • 新規サービスの開発 • 方針：多産多死 • 提案から実装、評価、運用まで行う機会 • 開発チームがプロダクトオーナーを兼ねる 12年7月25日水曜日
- 65. 5. 課題 • レコメンドアルゴリズム、機械学習など知見 を持っていない領域 • 実現できる保証はない、発注元からも心配す る声があがる • 大きなインフラが必要、はじめから費用をか けることはできない • 企画、設備調達、顧客開発、製品開発、品質 評価、運用等、多岐に渡る領域 12年7月25日水曜日
- 66. 5. 対応 • なにを解決したいか？等の目的を明確にする • 様々な機械学習法を調査 • 具体的な計算方法を提示する • クラウドを活用 • 社外コミュニティ活動でインタビュー • 再びのRuby/Rails開発を機にTDD/BDD 12年7月25日水曜日
- 67. 5. 結果（途中） →改善中 12年7月25日水曜日
- 68. 目次 • 背景：基幹系業務システムとコンシューマ向け サービス開発 • 課題：価値を届けるということの理想と現実 • 対応：わたしたちのチームの実装 • 知見：経験知から再び形式知へ 12年7月25日水曜日
- 69. End of Methodology • 方法論の終焉 • “この通りにやれば誰でもできる” 経典はない • ふりかえり改善フレームワーク • (Reflective Improvement Framework) • プラクティスは方法論でもプロセスでもない • “自分たちのための方法論”は必要 http://alistair.cockburn.us/The+end+of+methodology 12年7月25日水曜日
- 70. •変化に適応する • 人を重視する • 持続可能な状態を作る • 生み出すべき価値とは 12年7月25日水曜日
- 71. 変化に適応する • 必要なときに必要な分だけ • 1 2週間の反復毎の計画 • 発注元と優先順位を決める • 変化に強い構造 • シンプルなコードに保つ • テストコードの記述、自動テスト環境構築 • 現状を把握しておく • チームの速度を計測 12年7月25日水曜日
- 72. • 1 2週間の反復毎の計画 • 調査、学習も計画に含める • スパイク、砂場、壊していいおもちゃ • 失敗が成功の元を許容 • 小さな改善をタスクとして取り込む • ふりかえって終わりではない • 改善リストに残しておく • 成果を届ける • 動くソフトウェアのリリースが一番 • 出来なかったことも見せる 12年7月25日水曜日
- 73. • シンプルなコードに保つ • 品質を織り込む • ペアレビュー、ペアプログラミング • コードレビュー • ストーリ完了承認前にレビューゲート • コーディングスタイル定義 • 改善する時間を取る • リファクタリングのための時間 • 技術的負債を積極的に返す • 発注元に理解してもらうことが必要 12年7月25日水曜日
- 74. • チームの速度を計測 • ストーリポイントを皆で見積もる • 相対的な大きさを見積もる • ストーリーのゴールを共有 • 経験と勘を机の上に、バラつきの理由を共有 • 大きい物は分割する(10超えたら大きすぎ) • 速度を2段階に計測する • ストーリーポイント/1反復 • ポモドーロ/1ストーリーポイント • チームの速度と見積りの精度を記録 • 違っていてOK、違った理由を共有 12年7月25日水曜日
- 75. 人を重視する • 技術力 • 学習を織り込む • 学ぶ時間を確保する • コミュニケーション（メンバー） • 話す • 任せる • 信頼貯金を貯める 12年7月25日水曜日
- 76. • 学習を織り込む • 継続的に勉強会を開催 • ライトニングトークと言って敷居を下げる • 本人の興味がある内容をやってもらう • ペアプログラミング • フルタイムでやると疲れる、向き不向きもある • 詰まったとき、学習目的、など必要に応じて • ペアレビュー化 • スパイク、砂場、壊していいおもちゃ • 学習するためのストーリー • 調査作業用のリポジトリ 12年7月25日水曜日
- 77. • • 話す（勇気！） みんなで • 朝会、ふりかえり、計画 • くだけた話題でもOKな項目 • 全員揃わないときは基本延期（朝会は除く） • カフェタイム 15:00〜16:00の間に不定期開催 • 「期待マップ」いいところと期待することを、 全員が全員にむけて書いて、皆で話す • 個別に • 気になることがあったら個別に話す • ちゃんとダメな所は指摘する • 話を聞く、理由を聞く、価値観を聞く 12年7月25日水曜日 • 基本、人がなにを考えてるかは分からない
- 78. • 信頼貯金を貯める • 発注元にも顧客にもメンバーにも • 「正直は割に合う」 • 真 に、誠実に • ごまかし続けるコストは高い • 「まず自分が相手を信頼する」 • その人にとって価値があるものを届ける 12年7月25日水曜日
- 79. 持続可能な状態を作る • 技術 • ソースコード管理(git) • 自働化(CI, Jenkins) • テストコード(RSpec, kiwi) • 事業 • 兵站 12年7月25日水曜日
- 80. • 兵站 • 作戦活動以外のすべては兵站の活動 • 正直、影響の輪の外の部分も大きい • 「素人は戦術を語り、玄人は戦略を語り、プロは 兵站を語る」 • 軍隊だと約半分は兵站用の部隊・人員 • 「戦争という仕事の10分の9までは兵站だ」 マーチン・ファン・クレフェルト 戦史家 • 人、繋がり、出来ることを増やしておく 12年7月25日水曜日
- 82. 顧客の目的を達成できる •みんなでバスに乗る •インセプションデッキ •目的・理由の共有(Why?) •てごわい質問をちゃんと出来る 12年7月25日水曜日
- 83. 12年7月25日水曜日
- 84. 顧客の目的を達成できる •顧客は本当の目的を知らない •Pivot, 曳光弾, フィードバック •顧客開発 - 発見, 実証, 開拓, 組織構築 •望む物/世界を作る •フィードバックを得て回すのは同じ •可能な限り、小さく早く回そう 12年7月25日水曜日
- 85. サービス化により変わる システム開発 http://www.jisa.or.jp/seminar/SPES_index.html プロジェクトという形態 からプロダクト開発へ 非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 http://sec.ipa.go.jp/reports/20120611.html 12年7月25日水曜日
- 86. 12年7月25日水曜日
- 87. 船をつくろうと思ったら、 まず人々に、材料を集め、作業を分割し、 そして指示をあたえようとしてはならない。 最初にすべきことは、 果てなき広大な海へのあこがれを語ることだ サン=テグジュペリ 12年7月25日水曜日
- 88. 参考図書 • 『アジャイルな見積りと計画づくり』 • Mike Cohn (著), 安井 力 (翻訳), 角谷 信太郎 (翻訳), 毎日コミュニケーションズ (2009/1/29) • 『アジャイルサムライ−達人開発者への道−』 • Jonathan Rasmusson (著), 西村 直人 (翻訳), 角谷 信太郎 (翻訳), 近藤 修平 (翻訳), 角掛 拓未 (翻訳) , オーム社 (2011/7/16) • 『リーンソフトウェア開発と組織改革』 • Mary and Tom Poppendieck 著、 依田光江 翻訳、 依田智夫 監訳 (著) , アスキー・メディアワークス (2010/10/9) • 『達人プログラマー―システム開発の職人から名匠への道』 • Andrew Hunt (原著), David Thomas (原著), 村上 雅章 (翻訳) , ピアソンエデュケーション (2000/11) • 『ソフトウェア開発を成功させるチームビルディング』 • 岡島 幸男 (著) , ソフトバンククリエイティブ (2009/3/26) • 『アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得』 • Dave H. Hoover (著), Adewale Oshineye (著), 柴田 芳樹 (翻訳) , オライリージャパン (2010/7/8) • 『ペアプログラミング―エンジニアとしての指南書』 • Laurie Williams (原著), Robert Kessler (原著), 長瀬 嘉秀 (翻訳), 今野 睦 (翻訳), テクノロジックアート (翻訳) 、ピ アソンエデュケーション (2003/03) • 『リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす』 • エリック・リース (著), 伊藤 穣一(MITメディアラボ所長) (解説), 井口 耕二 (翻訳) , 日経BP社 (2012/4/12) 12年7月25日水曜日