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年８月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＆不具合修正で）
１年間で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