Improvement_process_for_providing_ongoing_value

継続的な価値提供の
ための改善プロセス
RICOH IT SOLUTIONS
北海道ソリューション部
前鼻毅

12年7月25日水曜日

北海道

目次
• 背景：基幹系業務システムとコンシューマ向け
サービス開発の違い

• 課題：価値を届けるということの理想と現実
• 対応：わたしたちのチームの実装
• 知見：経験知から再び形式知へ


基幹系業務システム
（個別開発）
• リコー北海道株式会社
• 開発チームリーダー、全工程を担当
• 定義済みの重いプロセスあり
• 営業が強い文化
• Access, VisualBasic, C#, SQLServer
• 約６年間従事

基幹系業務コンシューマ

顧客企業の
顧客
システム担当者

案件ごとに集める
チーム
技術力はパートナー依存

大きな障害は賠償問題
保守
保守先が増えていく

ベンダー依存
技術
バージョンアップ対応



完成品
品質
仕様通り

決定済み、固定が多い
納期
終わりがある

見積りを先に提出
コストスコープ依存
価格勝負

見積時に大まかに決定
スコープ
受注後に詳細を確定



要件定義
外部設計
プロセス詳細設計
実装
テスト

業務効率化
コスト削減
目的
顧客満足度向上
保守・維持可能


当時の私の悩み

•あいまいな見積り依頼
•要件の食い違い、抜け漏れ
•複雑で長大な重複したコード
•低品質に起因する障害対応の多さ
•保守による負荷・割込みの増大

改善したこと
•見積り仕様書の様式作成
•要求 → 実装 → テストのヒモ付け
•スコープの明確化
•設計書の項目見直し、可能なものは生成
•問題領域特化のフレームワーク作成
•保守契約書の様式を作成

更なる課題

•要件定義に膨大な時間
•やり過ぎのワナ
•技術不足による展開の失敗
•テストコードのない複雑なコード
•保守による負荷・割込みの増大
•顧客との利害不一致

コンシューマ向け
サービス開発
• リコーITソリューションズ
• 既存サービスのクライアント開発
• 新規サービスの構築
• 厳密なプロセス定義はない
• iOS, Objective-C, Ruby, Rails
• 約２年半従事（2009年末∼）

In
My
多くの違い Cas
e
顧客技術
スコープ
プロセス
目的
保守
納期コスト
品質チーム


顧客企業の発注元・グループ会社
顧客
システム担当者エンドユーザー

案件ごとに集める基本的に継続
チーム
パートナー依存育てることが大切

障害は賠償問題 24x365
保守
保守先が増えていく保つではなく改善

ベンダー依存オープンソース
技術
バージョンアップ対応サポートは無い



完成品 α,βサービス
品質仕様通り変更前提
テストフェーズ評価チーム

決定済み、固定が多いベストエフォート
納期
終わりがある終わりはない

見積りを先に提出
チーム規模で固定
コストスコープ依存
機器等は随時
競争あり

見積時に大まかに決定優先度は変化する
スコープ
受注後に詳細を確定柔軟性が必要



要件定義
大きな期間の目標
外部設計
短い期間の計画
プロセス詳細設計
リリース前評価
実装
企画・デザイン
テスト

業務効率化
魅力的なサービス
コスト削減
目的ビジョンの実現
事業・収益化


目次
• 背景：基幹系業務システムとコンシューマ向け
サービス開発

• 課題：価値を届けるということの理想と現実
• 対応：わたしたちのチームの実装
• 知見：経験知から再び形式知へ


業務効率化
コスト削減
事業・収益化

達成方法


業務効率化
コスト削減
事業・収益化

速度向上
必要な帳票
フローの簡素化
達成方法
検索強化
情報活用
質の向上


業務効率化
コスト削減
事業・収益化

速度向上
必要な帳票
正解
達成方法
フローの簡素化
検索強化ないは
！
情報活用
質の向上


何をすべきか？
• 目標に到達するための一般解がない
• なにをもって魅力的か
• サービスのビジョンはなにか
• 如何にしてけるか
•企画や起業家の領域

•価値をどう生み出すか

以前の課題

• 要件定義に膨大な時間
• やり過ぎのワナ
• 技術不足による展開の失敗
• テストコードのない複雑なコード
• 保守による負荷・割込みの増大
• 顧客との利害不一致


以前の課題

• 要件定義に膨大な時間決定論的
労働集約的
• 顧客との利害不一致事業継続性

課題解決？

• 要件定義に膨大な時間
決定論的変化前提
労働集約的
人重視
事業継続性
• 顧客との利害不一致持続可能

開発メイン
の領域
Product

Strategy 依頼元が
メインの
領域
Vision

変化前提
人重視
持続可能
Product 価値

Strategy 変化前提
人重視
持続可能
Vision 価値

What?
Product

Strategy How?

Vision Why?


Golden Circle
「人は「何を」ではなく
「なぜ」に動かされる」
Why

How
What
サイモン・シネック優れたリーダーはどうやって行動を促すか
http://www.ted.com/talks/lang/ja/simon_sinek_how_great_leaders_inspire_action.html

理想そのための
下３つ

•価値を生み出す、届ける

• 変化に適応する

• 人を重視する

• 持続可能な状態を作る

優先
価値を
順位
変化に無駄が
適応必要ななくなる
生む
時に
知恵が
密な
信頼出る
人大事交流
関係
いきいき
学習技術力と働く
持続重要多能工
可能長期の
自動化
視点

課題
• 生み出すべき価値とは？
• 変化に対応する
• 人を重視した〇〇〇作り

• 持続可能な


課題
• 生み出すべき価値とは？
• 変化に対応する
• 人を重視したチーム作り

• 持続可能な


依頼元の要求
• 目的のひとつ：コンシューマー事業を作る
• 技術のある人・チーム
• 一緒に面白いことが出来る
• オンラインストレージサービスを運営中
• そこに参加し価値づくりに貢献すること

全体
業務サービス

~2009 2010 2011 2012

Online web α iPad
iPhone App
Strage サービス App

2人 3人 4人 5人

イベント
New 新規
写真投稿
Service Web
iPhone

全体
業務サービス

~2009 2010 2011 2012

Online web α iPad
iPhone App
1
Strage サービス 2 4
App

2人 3人 4人 3 5人

New
イベント
5
新規
写真投稿
Service Web
iPhone

1.web αサービス 2名

• αサービスという位置づけのWebアプリ開発
• まだチームになっておらず個別に作業を実施
• 提示された目標を学習しながら、手探りでなん
とかこなしている状態

• 類似画像検索、顔認識等の技術を用いて新しい
発見体験を提供できるかを実験的に行う


1. 目的

• 新しい地方開発拠点の立ち上げ
• Webサービスの経験、関連技術の習得
• 新規技術への挑戦
• ユーザーからのフィードバックを得る


1. 課題

• 経験・技術不足
• web, Linux, Ruby, Rails, HTML,
css, javascript

• αサービスを使ってもらうこと
• フィードバックを得ること


1. 対応
• 主に書籍で学習
• 記録をWikiに残す（作業、技術情報）
• 1週間単位でふりかえりと計画
• やったことの確認とKPT
• ソースコード管理にgitを用いる
• 顧客担当とはIRCで密にやりとり
• 会員へのmail, Twitter, ニュースサイトで告知

1. 結果

• 予定の機能実装を達成
• 経験、技術を得たが、不足
• wiki, git, IRCはうまく機能
• フィードバック、盛り上げ策は苦戦


2. iPhone App 初期
3名→４名

• 正式なプロダクト開発へ、他社開発のiOSアプリ
のバージョンアップに着手

• iOS開発が盛り上がりはじめているところ
• 他部署から若手を一名引きぬく
• その後、問題領域の知見があるメンバーを確保
• パートナーさん、完全常駐。チームの一員

2. 目的

• iPhoneアプリのバージョンアップリリース
• 他社製から自社製へ
• トレンドであるiOS開発技術の習得
• 札幌拠点のチームとしての確立
• メンバー間のスキル伝達

2. 課題
• 圧倒的経験・技術不足
• Objective-C, iOS, WebAPI
• 元コードが低品質
• 人数が増えて作業の可視化が必要に
• 一週間ごとの作業計画の質向上
• 技術の伝達をどのように行うか

2. 対応
• 知見のある人を探す → 奇跡的に獲得
• 解析した結果、大部分のつくり直しを決断
• 朝会を開始
• ストーリー、タスクの管理ツール導入
• Pivotal Tracker
• 計画ゲーム、ストーリーポイントの導入
• コードレビュー実施
• チーム内勉強会の導入（ライトニングトーク）

2. 結果
• 進捗を率直に伝え、リリースまでの作戦を協議
• 作業の可視化達成
• 技術的卓越性の獲得
• メンバーのスキル向上速度が早く
• 計画ゲームでメンバーの意見取り入れ
• チームの速度算出が可能に

朝会ログ

反復(イテレーション)計画


ストーリーポイントと速度
UserAは〇〇をXXできる
2stp 14 stp/ite
管理者は〇〇をXXできる
18 stp/ite
3stp
20 stp/ite
UserBは△△を検索できる
1stp 平均は17stpだね！
各ストーリーは相対的
反復ごとの速度
な大きさ、全員で見積り


3. イベント写真投稿サービス
5人
• プロダクトを無事リリース、バージョンアップ
を数回重ね、一定の信頼を得た

• パートナー1名を更に追加
• 新サービス立ち上げ、複数拠点横断のスモール
チームでの開発を行う。自チームはiPhone App

• 実装機能やデザイン、やり方などについて　
「進みながら考える」で進める

3. 目的
• 新規サービスの立ち上げ、素早いリリース
• ソーシャルサービスとの連携実験
• 多数のユーザー獲得
• 素早い立ち上げ、リリース
• 軽いプロセスで回す
• 継続した技術向上

3. 課題
• 「進みながら考える」方法
• 盛り上げるための施策
• 素早く回せるプロセス
• 学習速度のさらなる向上
• メンバー間のコミュニケーション促進
• 集中できる時間の確保

3. 対応
• IRCやTV会議などを駆使して打合せを行う
• 各種イベントとタイアップ企画
• 最小限の仕様
• テストコードの導入
• ペアプログラミングの導入
• ２週間単位の計画、ふりかえりに変更
• ポモドーロ（２５分単位で集中）の導入

3. 結果
• 「考える、決める」のに多くの時間
• 根本的な目的や目指したい姿の統一が困難
• 常時ペアプロは「疲れる」→ ペアレビューへ
• iOS環境でのテストコードは非常に時間がかか
り、一部に絞っての実装に（単純実装の４倍）
• KPT + Happy ”幸せになる、楽をするために” の
視点を追加
• ポモドーロは向き不向きがある。１ストーリー
あたりにどれだけ、という単位として残る

ふりかえり


4. iPad App

• 20%ルールで開発を行っていたオンラインスト
レージサービスの iPad Appを正式リリースする
ことに
• 関連会社にてiPadの導入が決定されたことや、
市場でビジネス向けにiPad活用が行われている
ことが追い風に
• 企画の介在なし、評価は別チームで行う


4. 目的

• iPad Appのリリース
• ユーザーの獲得
• 使用時間（アクティブユーザー）の増加、
ダウンロード数に指標を設定
• ビジネス向け用途でも活用できる様に


4. 課題

• 目的の共有をどのように行うか
• このアプリは何を目指すのか？
• デザインについて
• 共通機能の扱い(iPhone, iPad)
• 個人の20%からチームのプロダクトへ

4. 対応
• 目的を明確にし、意識統一のためにインセプ
ションデッキを作成。特にサービスについて
のエレベータピッチを重視して開発を行う
• シンプルなデザインを指向するとともに、地
場企業にパーツ作成を依頼
• iPhone, iPad間の共通機能をモジュール化
• 20%ルールで作成していたメンバーからチーム
のものへ。デザイン等について対立もあり、
それぞれの価値観を聞くために面談を実施


4. 結果
• インセプションデッキが効果を発揮、迷ったと
きの指針になり、チーム外への説明にも活躍
• リリース時にApp Storeで仕事効率化カテゴリ
1位を獲得！
• 地場企業にデザインを依頼した実績を作れた
• モジュール化はテスト工数の増大やgitを使う
上での複雑性の増加などがあり、一長一短
• 面談などを行って話した結果チーム内で手ごわ
い質問をしやすくなった

目的の共有

https://github.com/agile-samurai-ja/support

5. 新規Webサービス
• ついに企画段階から自チーム発
• これまでにチーム内でアイデアを出したり、
議論してきた内容からサービスを提案

• サーバサイドも含めての実装
• ニュースレコメンドサービス
• Ruby, Rails 再び

5. 目的

• 新規サービスの開発
• 方針：多産多死
• 提案から実装、評価、運用まで行う機会
• 開発チームがプロダクトオーナーを兼ねる


5. 課題
• レコメンドアルゴリズム、機械学習など知見
を持っていない領域

• 実現できる保証はない、発注元からも心配す
る声があがる

• 大きなインフラが必要、はじめから費用をか
けることはできない

• 企画、設備調達、顧客開発、製品開発、品質
評価、運用等、多岐に渡る領域


5. 対応
• なにを解決したいか？等の目的を明確にする
• 様々な機械学習法を調査
• 具体的な計算方法を提示する
• クラウドを活用
• 社外コミュニティ活動でインタビュー
• 再びのRuby/Rails開発を機にTDD/BDD

5. 結果（途中）

→改善中


End of Methodology
• 方法論の終焉
• “この通りにやれば誰でもできる” 経典はない
• ふりかえり改善フレームワーク
• (Reflective Improvement Framework)
• プラクティスは方法論でもプロセスでもない
• “自分たちのための方法論”は必要
http://alistair.cockburn.us/The+end+of+methodology

•変化に適応する

• 人を重視する

• 持続可能な状態を作る

• 生み出すべき価値とは


変化に適応する
• 必要なときに必要な分だけ
• 1 2週間の反復毎の計画
• 発注元と優先順位を決める
• 変化に強い構造
• シンプルなコードに保つ
• テストコードの記述、自動テスト環境構築
• 現状を把握しておく
• チームの速度を計測

• 1 2週間の反復毎の計画

• 調査、学習も計画に含める
• スパイク、砂場、壊していいおもちゃ
• 失敗が成功の元を許容
• 小さな改善をタスクとして取り込む
• ふりかえって終わりではない
• 改善リストに残しておく
• 成果を届ける
• 動くソフトウェアのリリースが一番
• 出来なかったことも見せる

• シンプルなコードに保つ

• 品質を織り込む
• ペアレビュー、ペアプログラミング
• コードレビュー
• ストーリ完了承認前にレビューゲート
• コーディングスタイル定義
• 改善する時間を取る
• リファクタリングのための時間
• 技術的負債を積極的に返す
• 発注元に理解してもらうことが必要

• チームの速度を計測
• ストーリポイントを皆で見積もる
• 相対的な大きさを見積もる
• ストーリーのゴールを共有
• 経験と勘を机の上に、バラつきの理由を共有
• 大きい物は分割する(10超えたら大きすぎ)
• 速度を2段階に計測する
• ストーリーポイント/1反復
• ポモドーロ/1ストーリーポイント
• チームの速度と見積りの精度を記録
• 違っていてOK、違った理由を共有

人を重視する
• 技術力
• 学習を織り込む
• 学ぶ時間を確保する
• コミュニケーション（メンバー）
• 話す
• 任せる
• 信頼貯金を貯める

• 学習を織り込む
• 継続的に勉強会を開催
• ライトニングトークと言って敷居を下げる
• 本人の興味がある内容をやってもらう
• ペアプログラミング
• フルタイムでやると疲れる、向き不向きもある
• 詰まったとき、学習目的、など必要に応じて
• ペアレビュー化
• スパイク、砂場、壊していいおもちゃ
• 学習するためのストーリー
• 調査作業用のリポジトリ

•
•
話す（勇気！）
みんなで
• 朝会、ふりかえり、計画
• くだけた話題でもOKな項目
• 全員揃わないときは基本延期（朝会は除く）
• カフェタイム 15:00〜16:00の間に不定期開催
• 「期待マップ」いいところと期待することを、
全員が全員にむけて書いて、皆で話す
• 個別に
• 気になることがあったら個別に話す
• ちゃんとダメな所は指摘する
• 話を聞く、理由を聞く、価値観を聞く
• 基本、人がなにを考えてるかは分からない

• 信頼貯金を貯める

• 発注元にも顧客にもメンバーにも
• 「正直は割に合う」
• 真に、誠実に
• ごまかし続けるコストは高い
• 「まず自分が相手を信頼する」
• その人にとって価値があるものを届ける

持続可能な状態を作る

• 技術
• ソースコード管理(git)
• 自働化(CI, Jenkins)
• テストコード(RSpec, kiwi)
• 事業
• 兵站

• 兵站

• 作戦活動以外のすべては兵站の活動
• 正直、影響の輪の外の部分も大きい
• 「素人は戦術を語り、玄人は戦略を語り、プロは
兵站を語る」

• 軍隊だと約半分は兵站用の部隊・人員
• 「戦争という仕事の10分の9までは兵站だ」
マーチン・ファン・クレフェルト戦史家

• 人、繋がり、出来ることを増やしておく

生み出すべき価値とは


顧客の目的を達成できる

•みんなでバスに乗る
•インセプションデッキ
•目的・理由の共有(Why?)
•てごわい質問をちゃんと出来る

顧客の目的を達成できる

•顧客は本当の目的を知らない
•Pivot, 曳光弾, フィードバック
•顧客開発 - 発見, 実証, 開拓, 組織構築
•望む物/世界を作る
•フィードバックを得て回すのは同じ
•可能な限り、小さく早く回そう

サービス化により変わる
システム開発
http://www.jisa.or.jp/seminar/SPES_index.html

プロジェクトという形態
からプロダクト開発へ
非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書
http://sec.ipa.go.jp/reports/20120611.html


船をつくろうと思ったら、
まず人々に、材料を集め、作業を分割し、
そして指示をあたえようとしてはならない。
最初にすべきことは、
果てなき広大な海へのあこがれを語ることだ

サン=テグジュペリ


参考図書
• 『アジャイルな見積りと計画づくり』

• 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)

Improvement_process_for_providing_ongoing_value

Recommandé

Recommandé

Contenu connexe

Similaire à Improvement_process_for_providing_ongoing_value

Similaire à Improvement_process_for_providing_ongoing_value (20)

Plus de Maehana Tsuyoshi

Plus de Maehana Tsuyoshi (16)

Dernier

Dernier (9)

Improvement_process_for_providing_ongoing_value