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

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/ﬁle28.html

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

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

RICOH UCS
いいらしいよ

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

よし
導入しよう

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

いずれにしてもお客様の

ビジネスに直結した
コミュニケーション
手段として利用されている

エンタープライズでの
コミュニケーションビジネス
↓
お客様のビジネスを止めてはならない
↓

エンタープライズ品質
ここにもビジネス
チャンスがある

2.

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

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.ﬂickr.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.ﬂickr.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.ﬂickr.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
僕たちは

ならない

再び...

それはお客様の業務に

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

僕たちは

最小限の機能で市場価値
を生み出せるのか
いまやるべきなのか後でもいいのか

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
シナリオ/
ステップ

一つの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
一つの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.ﬂickr.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

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


は一日にしてならず

リリースのリズムを作る

http://www.ﬂickr.com/photos/odolphie/2397582359

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

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

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

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

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

Último

Último (9)