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

梅原 直樹
Naoki UMEHARA
iOS EDC 2013: iOS Enterprise & Developers Conference 7/11/2013
僕たちは
価値のあるソフトウェアを
早く継続的にデリバリーし
お客様を満足させなくては
ならない
梅原 直樹
うめはら

なおき

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

#iosedc
Developers Summit 2013

http://www.slideshare.net/numeha/ricoh-ucs-for-ipad
株式会社 リコー
新規事業を生み出すために
クラウド関連とiOS関連の
ソフトウェア開発リーダとして
活動しています

※ちなみにiOS歴は約1年半です
よろしくお願いします
1.
RICOH UCS
(Unified Communication System)
2011年8月22日
ビデオ会議市場に新規参入
クラウドやビデオチャット市場を含めると
2020年8,000億円市場に

http://businessnetwork.jp/Detail/tabid/65/artid/1262/Default.aspx
簡単さ・使いやすさを追求した
少人数(約5名)向けの
ポータブル型のテレビ会議システム

P3000

http://www.ricoh.co.jp/ucs
ビデオ会議メーカシェア
2012年

5位!!

その他

リコー

ポリコム

パナソニック

シスコ

ソニー

http://www.seedplanning.co.jp/press/2013/2013032701.html
iPhone版
(2013/9/10 Release)

iPad版
iPad版

(2013/1/31 Release)

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

http://www.apple.com/ipad-mini/overview/
当日は
ムービーを流しました
各拠点間

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

外出先

自宅

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

他にもメンタルヘルスの支援の一貫でiPadを利用
お客様同士の横の繋がりによる導入

RICOH UCS
いいらしいよ

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

よし
導入しよう
近場の病院との情報共有
研修医の育成のための会議
本部+10拠点で定例会議
海外拠点との会議
・・・・・

いずれにしてもお客様の

ビジネスに直結した
コミュニケーション
手段として利用されている
エンタープライズでの
コミュニケーションビジネス
↓
お客様のビジネスを止めてはならない
↓

エンタープライズ品質
ここにもビジネス
チャンスがある
2.
iOSアプリケーションの
継続的デリバリー
iOS
iOS Apps :
Store Accounts :

900,000
575,000,000
2013年6月現在
Apps will Automatically Update
in iOS7
〜常に最新版のアプリをユーザが利用可能〜
Objective-Cの開発者が急増

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

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アプリはどのくらいの
スピードでリリース可能なのか
Package
Submit
XCode

App Review
Ave:7days
iTunes Connect

最高で

1ヶ月で約4回

1年間で約50回

アップデートが可能

App Store
(実際にリリースするかは置いておいて)

このくらい継続的にデリバリーが
可能な仕組みを作らなければならない
ただ、
2ヶ月半
(実際にやるかやらないかは置いておいて)
App審査にかかり
このくらい継続的にデリバリーが
可能な仕組みを作らなければならない
全く継続的にリリースで
きないケースもありますw
Me

Me

Me
Me
RICOH UCS for iOSのリリース
2013年
1
2
3
★
1.0.0

4

★
1.1.0

★
1.0.1

5

6

★
★
1.2.0 1.3.0

7

8

9

10

★
★
1.5.0 2.0.0

★
1.1.1

11

★
2.1.0

12

★
2.2.0

★
2.0.1

(機能UP&不具合修正で)

1年間で12回のリリース

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

リリースのリズムを作る

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/4737

http://cdn.morguefile.com/imageData/public/files/m/mconnors/preview/fldr_2003_06_18/file0002046882848.jpg
小さく・早く・簡単にリリース

• 軌道修正
不具合を減らす
•
• お客様、セールスの改善要求
• 突然のApp審査ルール変更!!
いつパイプラインを作るか
2012
5 6 7

8

●
プロジェクト
開始

9

10

11

12

2013
1
2

3

4

5

6

★
1.0.0

★
★
★
1.1.0 1.2.0 1.3.0
★
★
1.0.1
1.1.1

7

8

9

10

★
★
★
1.5.0 2.0.0 2.1.0
★
2.0.1

11

12

★
★
2.2.0 2.3.0

プロジェクト開始時に
ものがなくても仕組みを作る
そうすれば1stリリースまで
プロセスがテストされ
その後のアップデートの
リズムができる
僕たちははじめにリリースまでの
パイプラインを作った

http://www.flickr.com/photos/49547334@N02/4725090871
Feature
概要
Test Engineer

Feature
シナリオ/
ステップ

Feature
テスト
コード

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

実装

〜協調性を重視する〜

開発者
テスト

Developer

受け入れ
ビルド

早く継続的にデリバリー

Run
on
Device

受け入れ
テスト

〜完全自動化する〜

リリース
リリース
ビルド

単体
テスト

結合
テスト
僕たちは

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

設計

Feature
シナリオ/
ステップ

実装

Feature
テスト
コード

開発者
テスト

Developer

受け入れ
ビルド

Run
on
Device

受け入れ
テスト
リリース

リリース
ビルド

単体
テスト

結合
テスト
Team

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

Developer

Leader

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

Test Engineer
役割は違うけれども

価値のある
ソフトウェアを作る
〜協調性を重視する〜
のは同じ

Test Engineer

協力する
Developer
Feature
概要
Test Engineer

設計

Feature
シナリオ/
ステップ

実装

Feature
テスト
コード

開発者
テスト

Developer

受け入れ
ビルド

Run
on
Device

受け入れ
テスト
リリース

リリース
ビルド

単体
テスト

結合
テスト
これが

Feature
僕たちは

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

それはお客様の業務に

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

最小限の機能で市場価値
を生み出せるのか
いまやるべきなのか後でもいいのか
MMF
Minimum Marketable Feature
お客様に提供する
価値の優先度

Feature
1

Feature
2

Feature
3

Feature
4

Feature
5

Feature
6

Feature
7

Feature
8

これが

MMF
これだけで市場価値を生むことが出来るのか
RICOH UCS for iOSのMMF
モバイルユーザとして、
開催中のP3000
の会議に途中参加して
映像と音声で相手とコミュニケーションしたい、
それは会議の開催場所でなくても参加したいからだ
最初に書いたラフスケッチ
お客様に聞いてみた

結果:好感触
実装の優先度 < 顧客に提供する優先度
お客様に提供する価値の優先度

Feature
1

Feature
2

Feature
3

Feature
4

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

Feature
5

Feature
6

Feature
7

Feature
8

どこで
1st release
するかはビジネス判断
小さく作って
大きく育てる
Feature
概要
Test Engineer

設計

Feature
シナリオ/
ステップ

実装

Feature
テスト
コード

開発者
テスト

Developer

受け入れ
ビルド

Run
on
Device

受け入れ
テスト
リリース

リリース
ビルド

単体
テスト

結合
テスト
繰り返しながら改善する

Feature
シナリオ/
ステップ

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

Test Engineer

Feature
テスト
コード

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

はお客様視点を持って仕様を作りながら
それを受け入れるテストコードの自動化をする
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

|

iOS1とiOS2の
2台のデバイスが
コンタクトリスト画面
にいる

Scenario: "ios1" can join conference
iOS3のデバイスが
Given "ios3" go to contactlist view
コンタクトリスト画面
And the following accounts start conference:
にいて
| device |
iOS2とiOS3が会議を
始める
| ios2 |
| ios3 |
Then "ios1" should see the presence of "meeting" within row of "ios2"
When "ios1" touch the row of "ios2"
iOS1からiOS2は
Then "ios1" should be on video view
会議中にみえ
iOS1がiOS2をタッチ
And "ios1" should see 3 participants
すると会議に参加する
And "ios1" should not see the private meeting image
自然言語は非開発者でも読めるので
仕様書にもなって一石二鳥

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

https://speakerdeck.com/phodgson/beyond-uiautomation
Stepの部品化
素人でもかけるテストを目指して

組み合わせるだけで新たなシナリオに
ただし、iOS7だと実機では動かない

http://www.testingwithfrank.com/
FrankとCalabashを両方動かして良いとこどり

https://rubygems.org/gems/calabash-cucumber
当日は
ムービーを流しました
作りながら仕様を決める
Feature
概要
Test Engineer

設計

Feature
シナリオ/
ステップ

実装

Feature
テスト
コード

開発者
テスト

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

Developer
Kiwi
GHUnit
OCMock
etc

一つのFeatureを実現する設計
をして、シナリオ/ステップを
満たす実装をする
仕様はあくまで仮説であって
ゴールするときに決まる
最小単位のFeatureを
動かしながら価値を確かめる
コードに問題があれば都度発見される
Feature
概要
Test Engineer

設計

Feature
シナリオ/
ステップ

実装

Feature
テスト
コード

開発者
テスト

Developer

受け入れ
ビルド

Run
on
Device

受け入れ
テスト
リリース

リリース
ビルド

単体
テスト

結合
テスト
Feature
テスト
コード

Test Engineer

開発者
テスト

一つのFeature
一つのBug
毎にPull Request

Developer

人の世界
機械の世界

何か問題が
あれば通知
受け入れ
ビルド

リリース
ビルド

PUSHをトリガに
コードをpull
そして継続的デリバリーへ
git plugin
xcode plugin
最低限のビルドはこれだけでいける

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

設計

Feature
シナリオ/
ステップ

実装

Feature
テスト
コード

開発者
テスト

Developer

製品品質を確保する

受け入れ
ビルド

Run
on
Device

受け入れ
テスト
リリース

リリース
ビルド

単体
テスト

結合
テスト
受け入れ
ビルド

Run
on
Device

ビルドに成功すると自動でipaファイル作成
そして自動で複数のデバイスに自動でインストール
ビルドサーバ
fruitstrapで各端末のidentifierを指定してインストール
or
instruments
異なるiOSデバイス、異なるOS、異なるネットワーク環境
で受け入れテストを常に実行
Devices

iPad, iPhone, iPod Touch

×
OS

iOS6, iOS7

×
Network

Proxy, Low Bandwidth, etc

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

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

iPod Touch

iOS6 & 7

ビルドサーバ
当日は
ムービーを流しました
iOS Simulator Limitation

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

設計

Feature
シナリオ/
ステップ

実装

Feature
テスト
コード

開発者
テスト

Developer

受け入れ
ビルド

Run
on
Device

受け入れ
テスト
リリース

コード品質を確保する
リリース
ビルド

単体
テスト

結合
テスト
コードの内部状態
を徹底的に可視化
テスト件数
コード行数
カバレッジ
警告数
etc
Feature
概要
Test Engineer

Feature
シナリオ/
ステップ

Feature
テスト
コード

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

実装

〜協調性を重視する〜

開発者
テスト

これを繰り返す
Developer

受け入れ
ビルド

早く継続的にデリバリー

Run
on
Device

受け入れ
テスト

〜完全自動化する〜

リリース
リリース
ビルド

単体
テスト

結合
テスト
0.1リリース

0.2リリース

0.3リリース

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

http://www.flickr.com/photos/seanhobson/4272482225
2012
5 6 7

8

●
プロジェクト
開始

9

10

11

12

2013
1
2
★
1.0.0

3

4

5

★
★
★
1.1.0 1.2.0 1.3.0
★
★
1.0.1
1.1.1

6

7

8

9

10

★
★
★
1.5.0 2.0.0 2.1.0
★
2.0.1

11

12

★
★
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/4737

http://cdn.morguefile.com/imageData/public/files/m/mconnors/preview/fldr_2003_06_18/file0002046882848.jpg
僕たちははじめにリリースまでの
パイプラインを作った

http://www.flickr.com/photos/49547334@N02/4725090871
Feature
概要
Test Engineer

Feature
シナリオ/
ステップ

Feature
テスト
コード

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

実装

〜協調性を重視する〜

開発者
テスト

Developer

受け入れ
ビルド

早く継続的にデリバリー

Run
on
Device

受け入れ
テスト

〜完全自動化する〜

リリース
リリース
ビルド

単体
テスト

結合
テスト
役割は違うけれども

価値のある
ソフトウェアを作る
〜協調性を重視する〜
のは同じ

Test Engineer

協力する
Developer
MMF
Minimum Marketable Feature
最小単位のFeatureを
動かしながら価値を確かめる
コードに問題があれば都度発見される
異なるiOSデバイス、異なるOS、異なるネットワーク環境
で受け入れテストを常に実行
Devices

iPad, iPhone, iPod Touch

×
OS

iOS6, iOS7

×
Network

Proxy, Low Bandwidth, etc

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

ここまでやってエンタープライズ品質
そのリズムが継続的な
デリバリーを可能にする

http://www.flickr.com/photos/seanhobson/4272482225
iOSアプリケーションの
継続的デリバリー
〜 清聴ありがとうございました
ごエンタープライズ品質のiOSアプリケーションを目指して〜

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

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