Improvement_process_for_providing_ongoing_value

継続的な価値提供のための改善プロセス

RICOH IT SOLUTIONS北海道ソリューション部

前鼻毅

12年7月25日水曜日

北海道12年7月25日水曜日

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

サービス開発の違い

•課題：価値を届けるということの理想と現実

•対応：わたしたちのチームの実装

•知見：経験知から再び形式知へ


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




目次


基幹系業務システム（個別開発）

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


基幹系業務コンシューマ

顧客顧客企業の

システム担当者

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

保守大きな障害は賠償問題

保守先が増えていく

技術ベンダー依存

バージョンアップ対応



品質完成品仕様通り

納期決定済み、固定が多い

終わりがある

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

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



プロセス

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

目的

業務効率化コスト削減

顧客満足度向上保守・維持可能


当時の私の悩み

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


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


更なる課題

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


コンシューマ向けサービス開発

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


多くの違い顧客

プロセス

品質コスト

チーム

技術スコープ

保守目的納期

In My Case



顧客顧客企業の

システム担当者発注元・グループ会社

エンドユーザー

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

基本的に継続育てることが大切

保守障害は賠償問題

保守先が増えていく24x365

保つではなく改善

技術ベンダー依存

バージョンアップ対応オープンソースサポートは無い



品質完成品仕様通り

テストフェーズ

α,βサービス変更前提

評価チーム

納期決定済み、固定が多い

終わりがあるベストエフォート終わりはない

コスト見積りを先に提出スコープ依存競争あり

チーム規模で固定機器等は随時

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

優先度は変化する柔軟性が必要



プロセス

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

大きな期間の目標短い期間の計画リリース前評価企画・デザイン

目的



魅力的なサービスビジョンの実現事業・収益化



サービス開発






目的




達成方法



目的




達成方法

速度向上必要な帳票

フローの簡素化検索強化情報活用質の向上



目的




達成方法

速度向上必要な帳票

フローの簡素化検索強化情報活用質の向上

正解はない！正解はない！


何をすべきか？•目標に到達するための一般解がない

•なにをもって魅力的か

•サービスのビジョンはなにか

•如何にして儲けるか

•企画や起業家の領域•価値をどう生み出すか



以前の課題



決定論的

労働集約的

事業継続性

以前の課題


課題解決？


決定論的

労働集約的

事業継続性

変化前提

人重視

持続可能12年7月25日水曜日

Vision

Strategy

Product開発メインの領域

依頼元がメインの領域


Vision

Strategy

Product

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

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


Vision

Strategy

ProductWhat?

Why?

How?


What

How

Why

Golden Circle

http://www.ted.com/talks/lang/ja/simon_sinek_how_great_leaders_inspire_action.html

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

サイモン・シネック優れたリーダーはどうやって行動を促すか






理想•価値を生み出す、届ける•変化に適応する•人を重視する•持続可能な状態を作る

そのための下３つ


価値を生む変化に

適応

人大事

持続可能

必要な時に

いきいきと働く学習

重要長期の視点自動化

知恵が出る

技術力多能工

優先順位

密な交流

信頼関係

無駄がなくなる


課題•生み出すべき価値とは？•変化に対応する•人を重視した•持続可能な

〇〇〇作り


課題•生み出すべき価値とは？•変化に対応する•人を重視した•持続可能な

チーム作り



サービス開発





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


全体業務サービス

~2009 2010 2011 2012

web αサービス iPhone App

イベント写真投稿iPhone

iPad App

新規Web

2人 3人 4人 5人

OnlineStrage

NewService


全体業務サービス

~2009 2010 2011 2012

web αサービス iPhone App

イベント写真投稿iPhone

iPad App

新規Web

2人 3人 4人 5人

OnlineStrage

NewService

1 23

5

4


1.web αサービス 2名

• αサービスという位置づけのWebアプリ開発

•まだチームになっておらず個別に作業を実施

•提示された目標を学習しながら、手探りでなんとかこなしている状態

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


1. 目的

•新しい地方開発拠点の立ち上げ

• Webサービスの経験、関連技術の習得

•新規技術への挑戦

•ユーザーからのフィードバックを得る


1. 課題•経験・技術不足

• web, Linux, Ruby, Rails, HTML, css, javascript

• αサービスを使ってもらうこと

•フィードバックを得ること


•主に書籍で学習

•記録をWikiに残す（作業、技術情報）

• 1週間単位でふりかえりと計画

•やったことの確認とKPT

•ソースコード管理にgitを用いる

•顧客担当とはIRCで密にやりとり

•会員へのmail, Twitter, ニュースサイトで告知

1. 対応


•予定の機能実装を達成

•経験、技術を得たが、不足

• wiki, git, IRCはうまく機能

•フィードバック、盛り上げ策は苦戦

1. 結果


2. iPhone App 初期 3名→４名

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

• iOS開発が盛り上がりはじめているところ

•他部署から若手を一名引きぬく

•その後、問題領域の知見があるメンバーを確保

•パートナーさん、完全常駐。チームの一員12年7月25日水曜日

• iPhoneアプリのバージョンアップリリース

•他社製から自社製へ

•トレンドであるiOS開発技術の習得

•札幌拠点のチームとしての確立

•メンバー間のスキル伝達

2. 目的


2. 課題•圧倒的経験・技術不足

• Objective-C, iOS, WebAPI

•元コードが低品質

•人数が増えて作業の可視化が必要に

•一週間ごとの作業計画の質向上

•技術の伝達をどのように行うか12年7月25日水曜日

2. 対応•知見のある人を探す → 奇跡的に獲得

•解析した結果、大部分のつくり直しを決断

•朝会を開始

•ストーリー、タスクの管理ツール導入

• Pivotal Tracker

•計画ゲーム、ストーリーポイントの導入

•コードレビュー実施

•チーム内勉強会の導入（ライトニングトーク）12年7月25日水曜日

•進捗を率直に伝え、リリースまでの作戦を協議

•作業の可視化達成

•技術的卓越性の獲得

•メンバーのスキル向上速度が早く

•計画ゲームでメンバーの意見取り入れ

•チームの速度算出が可能に

2. 結果


朝会ログ

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


14 stp/ite

18 stp/ite

20 stp/ite

平均は17stpだね！

反復ごとの速度

UserAは〇〇をXXできる2stp

管理者は〇〇をXXできる3stp

UserBは△△を検索できる1stp

各ストーリーは相対的な大きさ、全員で見積り

ストーリーポイントと速度


3. イベント写真投稿サービス 5人

•プロダクトを無事リリース、バージョンアップを数回重ね、一定の信頼を得た

•パートナー1名を更に追加

•新サービス立ち上げ、複数拠点横断のスモールチームでの開発を行う。自チームはiPhone App

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


3. 目的•新規サービスの立ち上げ、素早いリリース

•ソーシャルサービスとの連携実験

•多数のユーザー獲得

•素早い立ち上げ、リリース

•軽いプロセスで回す

•継続した技術向上


3. 課題•「進みながら考える」方法

•盛り上げるための施策

•素早く回せるプロセス

•学習速度のさらなる向上

•メンバー間のコミュニケーション促進

•集中できる時間の確保


• IRCやTV会議などを駆使して打合せを行う

•各種イベントとタイアップ企画

•最小限の仕様

•テストコードの導入

•ペアプログラミングの導入

•２週間単位の計画、ふりかえりに変更

•ポモドーロ（２５分単位で集中）の導入

3. 対応


•「考える、決める」のに多くの時間

•根本的な目的や目指したい姿の統一が困難

•常時ペアプロは「疲れる」→ ペアレビューへ

• iOS環境でのテストコードは非常に時間がかかり、一部に絞っての実装に（単純実装の４倍）

• KPT + Happy ”幸せになる、楽をするために” の視点を追加

•ポモドーロは向き不向きがある。１ストーリーあたりにどれだけ、という単位として残る

3. 結果


ふりかえり


• 20%ルールで開発を行っていたオンラインストレージサービスの iPad Appを正式リリースすることに

•関連会社にてiPadの導入が決定されたことや、市場でビジネス向けにiPad活用が行われていることが追い風に

•企画の介在なし、評価は別チームで行う

4. iPad App


4. 目的

• iPad Appのリリース

•ユーザーの獲得

•使用時間（アクティブユーザー）の増加、ダウンロード数に指標を設定

•ビジネス向け用途でも活用できる様に


4. 課題

•目的の共有をどのように行うか

•このアプリは何を目指すのか？

•デザインについて

•共通機能の扱い(iPhone, iPad)

•個人の20%からチームのプロダクトへ


•目的を明確にし、意識統一のためにインセプションデッキを作成。特にサービスについてのエレベータピッチを重視して開発を行う

•シンプルなデザインを指向するとともに、地場企業にパーツ作成を依頼

• iPhone, iPad間の共通機能をモジュール化

• 20%ルールで作成していたメンバーからチームのものへ。デザイン等について対立もあり、それぞれの価値観を聞くために面談を実施

4. 対応


•インセプションデッキが効果を発揮、迷ったときの指針になり、チーム外への説明にも活躍

•リリース時にApp Storeで仕事効率化カテゴリ1位を獲得！

•地場企業にデザインを依頼した実績を作れた

•モジュール化はテスト工数の増大やgitを使う上での複雑性の増加などがあり、一長一短

•面談などを行って話した結果チーム内で手ごわい質問をしやすくなった

4. 結果



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

目的の共有





目的の共有




•ついに企画段階から自チーム発

•これまでにチーム内でアイデアを出したり、議論してきた内容からサービスを提案

•サーバサイドも含めての実装

•ニュースレコメンドサービス

• Ruby, Rails 再び

5. 新規Webサービス


5. 目的

•新規サービスの開発

•方針：多産多死

•提案から実装、評価、運用まで行う機会

•開発チームがプロダクトオーナーを兼ねる


5. 課題•レコメンドアルゴリズム、機械学習など知見

を持っていない領域

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

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

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


•なにを解決したいか？等の目的を明確にする

•様々な機械学習法を調査

•具体的な計算方法を提示する

•クラウドを活用

•社外コミュニティ活動でインタビュー

•再びのRuby/Rails開発を機にTDD/BDD

5. 対応


5. 結果（途中）

→改善中



サービス開発





End of Methodology•方法論の終焉

• “この通りにやれば誰でもできる” 経典はない

•ふりかえり改善フレームワーク

• (Reflective Improvement Framework)

•プラクティスは方法論でもプロセスでもない

• “自分たちのための方法論”は必要http://alistair.cockburn.us/The+end+of+methodology


http://alistair.cockburn.us/The+end+of+methodology

http://alistair.cockburn.us/The+end+of+methodology

•変化に適応する•人を重視する•持続可能な状態を作る•生み出すべき価値とは


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


•1~2週間の反復毎の計画•調査、学習も計画に含める• スパイク、砂場、壊していいおもちゃ• 失敗が成功の元を許容

•小さな改善をタスクとして取り込む• ふりかえって終わりではない• 改善リストに残しておく

•成果を届ける•動くソフトウェアのリリースが一番•出来なかったことも見せる


•シンプルなコードに保つ•品質を織り込む• ペアレビュー、ペアプログラミング• コードレビュー• ストーリ完了承認前にレビューゲート• コーディングスタイル定義

•改善する時間を取る• リファクタリングのための時間• 技術的負債を積極的に返す• 発注元に理解してもらうことが必要


•チームの速度を計測•ストーリポイントを皆で見積もる• 相対的な大きさを見積もる• ストーリーのゴールを共有• 経験と勘を机の上に、バラつきの理由を共有

• 大きい物は分割する(10超えたら大きすぎ)

•速度を2段階に計測する• ストーリーポイント/1反復• ポモドーロ/1ストーリーポイント• チームの速度と見積りの精度を記録• 違っていてOK、違った理由を共有


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


•学習を織り込む• 継続的に勉強会を開催• ライトニングトークと言って敷居を下げる• 本人の興味がある内容をやってもらう

• ペアプログラミング• フルタイムでやると疲れる、向き不向きもある• 詰まったとき、学習目的、など必要に応じて

• ペアレビュー化• スパイク、砂場、壊していいおもちゃ• 学習するためのストーリー• 調査作業用のリポジトリ


•話す（勇気！）• みんなで

• 朝会、ふりかえり、計画

• くだけた話題でもOKな項目

• 全員揃わないときは基本延期（朝会は除く）

• カフェタイム 15:00〜16:00の間に不定期開催

• 「期待マップ」いいところと期待することを、全員が全員にむけて書いて、皆で話す

• 個別に

• 気になることがあったら個別に話す

• ちゃんとダメな所は指摘する

• 話を聞く、理由を聞く、価値観を聞く

• 基本、人がなにを考えてるかは分からない12年7月25日水曜日

•信頼貯金を貯める• 発注元にも顧客にもメンバーにも

• 「正直は割に合う」

• 真摯に、誠実に

• ごまかし続けるコストは高い

• 「まず自分が相手を信頼する」

• その人にとって価値があるものを届ける


持続可能な状態を作る

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


•兵站• 作戦活動以外のすべては兵站の活動

• 正直、影響の輪の外の部分も大きい

• 「素人は戦術を語り、玄人は戦略を語り、プロは兵站を語る」

• 軍隊だと約半分は兵站用の部隊・人員

• 「戦争という仕事の10分の9までは兵站だ」

• 人、繋がり、出来ることを増やしておくマーチン・ファン・クレフェルト戦史家


生み出すべき価値とは


顧客の目的を達成できる

•みんなでバスに乗る•インセプションデッキ•目的・理由の共有(Why?)

•てごわい質問をちゃんと出来る



顧客の目的を達成できる

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


“サービス化により変わるシステム開発”

“プロジェクトという形態からプロダクト開発へ”非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書

http://sec.ipa.go.jp/reports/20120611.html

http://www.jisa.or.jp/seminar/SPES_index.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)

参考図書


Technology

Improvement_process_for_providing_ongoing_value