iosアプリケーションの継続的デリバリー ...

梅原 直樹iOS EDC 2013: iOS Enterprise & Developers Conference 7/11/2013

Naoki UMEHARA

iOSアプリケーションの継続的デリバリー

〜エンタープライズ品質のiOSアプリケーションを目指して〜

僕たちは価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなくては

ならない

梅原 直樹うめはら なおき

Twitter:@numehahttp://numeha.hatenablog.com/

#iosedc

Developers Summit 2013

http://www.slideshare.net/numeha/ricoh-ucs-for-ipad

株式会社 リコー

新規事業を生み出すために

クラウド関連とiOS関連の

ソフトウェア開発リーダとして活動しています

※ちなみにiOS歴は約1年半です

よろしくお願いします

RICOH UCS(Unified Communication System)

1.

2011年８月22日ビデオ会議市場に新規参入

クラウドやビデオチャット市場を含めると2020年8,000億円市場に

http://businessnetwork.jp/Detail/tabid/65/artid/1262/Default.aspx

簡単さ・使いやすさを追求した

少人数（約5名）向けの

ポータブル型のテレビ会議システム

P3000

http://www.ricoh.co.jp/ucs

ポリコム

ソニーシスコ

パナソニック

リコーその他

ビデオ会議メーカシェア

http://www.seedplanning.co.jp/press/2013/2013032701.html

2012年

5位！！

iPad版

http://www.apple.com/ipad-mini/overview/

iPad版(2013/1/31 Release)

iPhone版(2013/9/10 Release)

コミュニケーションの幅を拡大

⚠当日は

ムービーを流しました

ビジュアル・コミュニケーション

各拠点間

外出先 自宅 移動中

他にもメンタルヘルスの支援の一貫でiPadを利用

http://www.mitsubishicorp-foundation.org/reconstruction/case/file28.html

お客様同士の横の繋がりによる導入

RICOH UCSいいらしいよ

よし導入しよう

エンタープライズの世界でネットワーク効果の兆候

いずれにしてもお客様の

ビジネスに直結したコミュニケーション

手段として利用されている

近場の病院との情報共有研修医の育成のための会議本部＋10拠点で定例会議

海外拠点との会議・・・・・

エンタープライズでのコミュニケーションビジネス

↓お客様のビジネスを止めてはならない

↓

ここにもビジネスチャンスがある

エンタープライズ品質

2.iOSアプリケーションの

継続的デリバリー

iOS

iOS Apps : 900,000Store Accounts : 575,000,000

2013年6月現在

Apps will Automatically Updatein iOS7

〜常に最新版のアプリをユーザが利用可能〜

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Objective-Cの開発者が急増

http://www.tiobe.com/content/paperinfo/tpci/index.html

http://www.businessinsider.com.au/ios-is-the-platform-for-enterprises-2013-3

http://www.businessinsider.com/apple-is-winning-the-mobile-enterprise-2012-7

リーン・スタートアップによるライバルの増加

※ 大企業もやらないと死ぬhttp://thebln.com/wp-content/uploads/2011/09/Eric-Ries-The-Lean-Startup.jpg

どこで戦うのか

モバイルファースト×

クラウドファースト×

ビジネスモデル

それはお客様の業務に

なくてはならないものになっているか

特にエンタープライズ市場ではこのような状態に早く出来るのかが鍵。そしてその状態を維持できるのか

iOSアプリケーションの継続的デリバリー

〜エンタープライズ品質のiOSアプリケーションを目指して〜

僕たちは価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなくては

ならない

僕たちは価値のあるソフトウェアを

早く継続的にデリバリーしお客様を満足させなくては

ならない

iOSアプリはどのくらいのスピードでリリース可能なのか

XCode iTunes Connect App Store

App Review

Ave:7daysPackageSubmit

最高で1ヶ月で約4回

1年間で約50回アップデートが可能

（実際にリリースするかは置いておいて）

このくらい継続的にデリバリーが可能な仕組みを作らなければならない

（実際にやるかやらないかは置いておいて）このくらい継続的にデリバリーが可能な仕組みを作らなければならない

Me

Me

Me

Me

ただ、2ヶ月半

App審査にかかり全く継続的にリリースできないケースもありますw

★1.0.0

2013年 1 2 3 4 5 6 7 8 9 10 11 12

★1.0.1

★1.1.0

★1.1.1

★1.2.0

★1.3.0

★1.5.0

★2.0.0

★2.0.1

★2.1.0

★2.2.0

★2.3.0

RICOH UCS for iOSのリリース

（機能UP＆不具合修正で）

１年間で12回のリリース

リリースのリズムを作る

これが多いか少ないかは置いておいて

http://www.flickr.com/photos/odolphie/2397582359

http://www.amazon.co.jp/gp/product/images/4048707876/ref=dp_image_text_0?ie=UTF8&n=465392&s=books

ビジネスの主導権を得るために

http://www.allaboutagile.com/7-reasons-why-continuous-delivery-needs-to-be-a-business-initiative/

ユーザを早期に獲得する競争力あるプロダクトを早く実現する

http://www.flickr.com/photos/56155476@N08/6660135637

ビルド・デプロイ・テスト・リリース

ビルド デプロイ テスト リリース

小さく繰り返す

リリースまでのパイプライン

コードのコミットをしてからミスなく自動的に頻繁にリリースしたい

お客様に価値を継続的にデリバリーする唯一の方法

自動化

要するにとことん自動化する

(⚠App申請だけは手動)

http://morguefile.com/archive/display/4737http://cdn.morguefile.com/imageData/public/files/m/mconnors/preview/fldr_2003_06_18/file0002046882848.jpg

•軌道修正

•不具合を減らす

•お客様、セールスの改善要求

•突然のApp審査ルール変更！！

小さく・早く・簡単にリリース

いつパイプラインを作るか

★1.0.0

2012 2013 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12

★1.0.1

★1.1.0

★1.1.1

★1.2.0

★1.3.0

★1.5.0

★2.0.0

★2.0.1

★2.1.0

★2.2.0

★2.3.0

●プロジェクト

開始

プロジェクト開始時にものがなくても仕組みを作る

そうすれば1stリリースまでプロセスがテストされ

その後のアップデートのリズムができる

僕たちははじめにリリースまでのパイプラインを作った

http://www.flickr.com/photos/49547334@N02/4725090871

リリースビルド

単体テスト

結合テスト

受け入れビルド

Runon

Device

受け入れテスト

リリース

Feature概要

Featureシナリオ/ステップ

Featureテストコード

Developer

Test Engineer

設計 実装 開発者テスト

価値のあるソフトウェアを作る

〜協調性を重視する〜

早く継続的にデリバリー〜完全自動化する〜

僕たちは

価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなくては

ならない

リリースビルド

単体テスト

結合テスト

受け入れビルド

Runon

Device

受け入れテスト

リリース

Feature概要

Featureシナリオ/ステップ

Featureテストコード

Developer

Test Engineer

設計 実装 開発者テスト

Developer Test Engineer

Leader

Team

製品の品質について責任を持つお客様に提供する価値を考える受け入れテストを自動化する

コードの品質について責任を持つお客様に提供する価値の高い

ものから開発する

Developer

Test Engineer

協力する

価値のあるソフトウェアを作る

〜協調性を重視する〜

役割は違うけれども

のは同じ

リリースビルド

単体テスト

結合テスト

受け入れビルド

Runon

Device

受け入れテスト

リリース

Feature概要

Featureシナリオ/ステップ

Featureテストコード

Developer

Test Engineer

設計 実装 開発者テスト

僕たちは

価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなくては

ならない

これがFeature

それはお客様の業務に

なくてはならないものになっているか

特にエンタープライズ市場ではこのような状態に早く出来るのかが鍵。そしてその状態を維持できるのか

再び...

僕たちは

最小限の機能で市場価値を生み出せるのか

いまやるべきなのか後でもいいのか

MMFMinimum Marketable Feature

Feature1

Feature2

Feature3

Feature4

Feature5

Feature6

Feature7

Feature8

これがMMF

お客様に提供する価値の優先度

これだけで市場価値を生むことが出来るのか

RICOH UCS for iOSのMMFモバイルユーザとして、

開催中のP3000 の会議に途中参加して映像と音声で相手とコミュニケーションしたい、それは会議の開催場所でなくても参加したいからだ

最初に書いたラフスケッチ

お客様に聞いてみた

結果：好感触

ここでダメならそこで終了

Feature1

Feature2

Feature3

Feature4

Feature5

Feature6

Feature7

Feature8

お客様に提供する価値の優先度

実装の優先度 < 顧客に提供する優先度

どこで1st release

するかはビジネス判断

小さく作って

大きく育てる

リリースビルド

単体テスト

結合テスト

受け入れビルド

Runon

Device

受け入れテスト

リリース

Feature概要

Featureシナリオ/ステップ

Featureテストコード

Developer

Test Engineer

設計 実装 開発者テスト

Featureシナリオ/ステップ

Featureテストコード

はお客様視点を持って仕様を作りながらそれを受け入れるテストコードの自動化をするTest Engineer

一つのFeatureに対するお客様に価値を与えるシナリオを作る

それが実際に自動で動くコードを書く

繰り返しながら改善する

Background: Given the following contacts exist: | device | another_device | subscription | ask | | ios1 | ios2 | both | | And "ios1" go to contactlist view And "ios2" go to contactlist view

Scenario: "ios1" can join conference Given "ios3" go to contactlist view And the following accounts start conference: | device | | ios2 | | ios3 | Then "ios1" should see the presence of "meeting" within row of "ios2" When "ios1" touch the row of "ios2" Then "ios1" should be on video view And "ios1" should see 3 participants And "ios1" should not see the private meeting image

iOS1とiOS2の2台のデバイスが

コンタクトリスト画面にいる

iOS3のデバイスがコンタクトリスト画面

にいてiOS2とiOS3が会議を

始める

iOS1からiOS2は会議中にみえ

iOS1がiOS2をタッチすると会議に参加する

Featureシナリオ/ステップ

自然言語は非開発者でも読めるので仕様書にもなって一石二鳥

どういう条件で、どういう時に、どうなるのか

https://speakerdeck.com/phodgson/beyond-uiautomation

Stepの部品化素人でもかけるテストを目指して

組み合わせるだけで新たなシナリオに

⚠ただし、iOS7だと実機では動かない

http://www.testingwithfrank.com/

FrankとCalabashを両方動かして良いとこどり

https://rubygems.org/gems/calabash-cucumber

⚠当日は

ムービーを流しました

Feature概要

Featureシナリオ/ステップ

Featureテストコード

Developer

Test Engineer

設計 実装 開発者テスト

KiwiGHUnitOCMock

etc

作りながら仕様を決める

Featureテストコードでは実現できない内部ロジックのテストをする

一つのFeatureを実現する設計をして、シナリオ/ステップを満たす実装をする

仕様はあくまで仮説であってゴールするときに決まる

最小単位のFeatureを動かしながら価値を確かめる

コードに問題があれば都度発見される

リリースビルド

単体テスト

結合テスト

受け入れビルド

Runon

Device

受け入れテスト

リリース

Feature概要

Featureシナリオ/ステップ

Featureテストコード

Developer

Test Engineer

設計 実装 開発者テスト

Featureテストコード

開発者テスト

リリースビルド

受け入れビルド

一つのFeature一つのBug

毎にPull Request

人の世界

機械の世界

PUSHをトリガにコードをpull

そして継続的デリバリーへ

Developer

Test Engineer

何か問題があれば通知

git pluginxcode plugin

最低限のビルドはこれだけでいける

※ 使えるプラグインは少ないのでこれ以上は自分でスクリプトを作る 単体テスト、カバレッジ、レポートファイル変換等

リリースビルド

単体テスト

結合テスト

受け入れビルド

Runon

Device

受け入れテスト

リリース

Feature概要

Featureシナリオ/ステップ

Featureテストコード

設計 実装 開発者テスト

Developer

Test Engineer

製品品質を確保する

ビルドに成功すると自動でipaファイル作成そして自動で複数のデバイスに自動でインストール

fruitstrapで各端末のidentifierを指定してインストールor

instruments

受け入れビルド

Runon

Device

ビルドサーバ

×

Devices iPad, iPhone, iPod Touch

OS×

iOS6, iOS7

Network Proxy, Low Bandwidth, etc

異なるiOSデバイス、異なるOS、異なるネットワーク環境で受け入れテストを常に実行

※ お客様の様々なネットワーク環境を想定する

ここまでやってエンタープライズ品質

ビルドサーバ

iPhone

iPod Touch

iPad

iOS6 & 7

⚠当日は

ムービーを流しました

iOS Simulator Limitation⚠

シミュレータでは動くけど、実機だとxxxは防ぐ

リリースビルド

単体テスト

結合テスト

受け入れビルド

Runon

Device

受け入れテスト

リリース

Feature概要

Featureシナリオ/ステップ

Featureテストコード

Developer

Test Engineer

設計 実装 開発者テスト

コード品質を確保する

テスト件数コード行数カバレッジ

警告数etc

コードの内部状態を徹底的に可視化

リリースビルド

単体テスト

結合テスト

受け入れビルド

Runon

Device

受け入れテスト

リリース

Feature概要

Featureシナリオ/ステップ

Featureテストコード

Developer

Test Engineer

設計 実装 開発者テスト

価値のあるソフトウェアを作る

〜協調性を重視する〜

早く継続的にデリバリー〜完全自動化する〜

これを繰り返す

0.1リリース

0.2リリース

0.3リリース

0.4リリース

そのリズムが継続的なデリバリーを可能にする

http://www.flickr.com/photos/seanhobson/4272482225

★1.0.0

2012 2013 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12

★1.0.1

★1.1.0

★1.1.1

★1.2.0

★1.3.0

★1.5.0

★2.0.0

★2.0.1

★2.1.0

★2.2.0

★2.3.0

●プロジェクト

開始

先をみた開発ができている

iOSアプリケーションの継続的デリバリー は一日にしてならず

まとめ

僕たちは価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなくては

ならない

リリースのリズムを作る

http://www.flickr.com/photos/odolphie/2397582359

ユーザを早期に獲得する競争力あるプロダクトを早く実現する

http://www.flickr.com/photos/56155476@N08/6660135637

要するにとことん自動化する

(⚠App申請だけは手動)

http://morguefile.com/archive/display/4737http://cdn.morguefile.com/imageData/public/files/m/mconnors/preview/fldr_2003_06_18/file0002046882848.jpg

僕たちははじめにリリースまでのパイプラインを作った

http://www.flickr.com/photos/49547334@N02/4725090871

リリースビルド

単体テスト

結合テスト

受け入れビルド

Runon

Device

受け入れテスト

リリース

Feature概要

Featureシナリオ/ステップ

Featureテストコード

Developer

Test Engineer

設計 実装 開発者テスト

価値のあるソフトウェアを作る

〜協調性を重視する〜

早く継続的にデリバリー〜完全自動化する〜

Developer

Test Engineer

協力する

価値のあるソフトウェアを作る

〜協調性を重視する〜

役割は違うけれども

のは同じ

MMFMinimum Marketable Feature

最小単位のFeatureを動かしながら価値を確かめる

コードに問題があれば都度発見される

×

Devices iPad, iPhone, iPod Touch

OS×

iOS6, iOS7

Network Proxy, Low Bandwidth, etc

異なるiOSデバイス、異なるOS、異なるネットワーク環境で受け入れテストを常に実行

※ お客様の様々なネットワーク環境を想定する

ここまでやってエンタープライズ品質

そのリズムが継続的なデリバリーを可能にする

http://www.flickr.com/photos/seanhobson/4272482225

梅原 直樹iOS EDC 2013: iOS Enterprise & Developers Conference 7/11/2013

Naoki UMEHARA

iOSアプリケーションの継続的デリバリー

〜エンタープライズ品質のiOSアプリケーションを目指して〜ご清聴ありがとうございました