• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Improvement_process_for_providing_ongoing_value
 

Improvement_process_for_providing_ongoing_value

on

  • 699 views

 

Statistics

Views

Total Views
699
Views on SlideShare
698
Embed Views
1

Actions

Likes
2
Downloads
3
Comments
0

1 Embed 1

https://si0.twimg.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Improvement_process_for_providing_ongoing_value Improvement_process_for_providing_ongoing_value Presentation Transcript

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