企業内専用iOSアプリに絡んだ情報をまとめるシリーズ。第2回目はOTAと構成プロファイルについて書いてみようと思います。

With Stripes © 2011 Dmitry Shakin, Flickr

■ OTA = Over The Air

OTAはもう既に多くの方がご存知だと思いますので詳しい説明は省きますが、WiFi経由でiOSアプリをインストールできる仕組みの事です。USBケーブルも、iTunesやiPhone構成ユーティリティも、もう要りませんから！…って事なので大変幸せになれます。

昔から企業向けの仕組み、iDEP(iOS Developer Enterprise Program)じゃないと使えないと思われていたのですが、実はそうではなく Standard なライセンスの AdHoc 版配布にも使えますので皆さん使いましょうね…という話はさておき、企業向けiOSアプリでは「絶対に」OTA環境を用意しましょう。

というのも、個人とは違って法人の場合は平気で50台とか300台とか1000台ってな規模になるからです。1台1台、有線でインストールしていたらアプリのインストールだけで日が暮れます(日が暮れても無理かも)。万が一頻繁にアップデートされなくちゃいけない専用アプリだったら…想像もしたくないですね(笑)

という訳でエンタープライズiOSアプリでは空間的束縛の無いOTA配布が必須となります。このOTAにiDEPによるInHouseを組み合わせる事で初めて

• ケーブルからの開放
• 台数制限からの開放

という企業内iOSアプリ展開の理想形が実現します。必要なモノは、

1. Webサーバ
2. InHouse の provision profile を使用してビルドされた .ipa ファイル
3. アプリの情報を記述する .plist ファイル
4. インストールする為の呪文リンクタグを含む html ファイル

の4点(詳しい事はこちら)。上記4のhtmlを設置したURLにiOSデバイスでアクセスして、呪文リンクタップするとアプリインストールが始まります。こんな感じ。

後は「インストール」をタップすると完了です。AdHoc版のOTAの場合は .ipa に適正なUDIDが設定されていないと途中でエラーが発生してしまいますが、iDEP の InHouse 版であればデバイスのUDIDチェックは入りませんので心配無用です。どんなデバイスでもok。

でもそれだけに、InHouse版のOTA環境へのアクセスは厳重に管理されなければいけません。企業内ネットワークからのみアクセスを許可、外部からのアクセスは拒否、外出先からはVPN経由…といったアクセス制御は必要です。

39/52 – Signs © 2011 Scott Akerman, Flickr

万が一、InHouseのアプリが公開状態となってしまって、iDEP契約主体企業の中の人以外が自由にインストール出来るようになると規約違反になりますのでご注意を。Appleからかなりキツイ措置が予想されますので、InHouseのOTA環境の運用は慎重に慎重を期した方が良いと思います。

デバイス制限も無いアプリ配布環境は Apple の AppStore の世界から逃れ出る事とほぼ同義である事を考えれば、事態の大変さは想像頂けると思います。なので、エンタープライズなOTA環境に関係者以外へのアクセスを絶対に許してはいけません。

■ 構成プロファイル

無償で使えるiPhone構成ユーティリティで、OTA用のリンクをWebクリップとして含む構成プロファイルを作成すると便利です。(iPhone構成ユーティリティやWebクリップについてはGoogle先生に聞いてみて下さい)

1. 新規デバイスを導入する
2. 当該デバイスでSafariを開きURL開く
3. 構成プロファイルのインストール(ここでWebクリップも一緒に入る)
4. HOME画面に企業内アプリのインストール/アップデート専用のアイコンが出来る

ってな事が出来てしまいます。アイコンを押せば社内アプリのインストールもアップデートも自由に出来ますよ〜的な。

上図は弊社のiPadの画面ですが、このアイコンがOTA環境へのWebClipになってます。タップすると、

こんな風になってます。ってさすがに詳細はお見せ出来ないので何が写ってるかよく分からないですが、アプリ名とインストールボタンがダーっと並んでて、いつでもどんなデバイスでも、自由にインストール出来るから選んでねってサイトになってます。言うなれば弊社専用のAppStoreみたいなもの。無論、このサイトへのアクセスは厳重に守られています。(仮に弊社端末が盗まれても当該リンクは操作できない)

こんな感じで、OTA環境へのURLをWebクリップとして用意してあげると大変便利です。各自にSafariでアクセスして貰ってHOME画面にブックマーク登録…をさせても良いのですが、構成プロファイルでいっきに配布した方が情シス担当者への問い合わせ数も少なくなるので合理的。

ちなみに、もし社内アプリが1つに限定されるのであれば、インストール用の、itms-services://?action=download-manifest&url=http%3A%2F%2Fexample.com%2sample.plist ってな感じのリンクを直接指定してあげるのもアリです。

そうすると、iPad側ではWebクリップを1タップするだけで最新版をインストールする事が出来るようになります。しかも「取り除きを許可」のチェックを外しておけば、誤って削除される事も無いので完璧です。

という訳で、OTAと構成プロファイルを使った配布環境の構築についてご説明しました。OTA環境はホント便利ですので、SIerさんは面倒臭がらずにお客様に作って差し上げて下さい。また、iOSデバイス導入企業の担当者様は、後々の楽をする為にSIerさんに「OTA環境を用意してねぇ〜」とお願いするようにして下さい

■ 本連載の過去エントリ

• エンタープライズiOSアプリことはじめ(1) 〜iDEPとDUNSナンバー〜(2011.10.6)

たまにはプライベートな事も書きましょうか。…って最近ブログ更新頻度が上がっているので「たまには」になってない気もしますが

原則、僕のオフタイムは土曜日の 13:00〜就寝 の間のみという事になっています。先週末は少し秋らしくなってきたという事もあり、たまには屋外でどこかいってみようと万博記念公園に行ってきました。哀しいかな封鎖されたエキスポランドを通り過ぎてやってきたのは、

でーん。と太陽の塔。お約束ですね。でもよくよく考えると大阪生まれの大阪育ちながら、眼前にこれを見据えたのは初めてかも知れません。まぁ元来、太陽が誰よりも似合わない(笑)と言われて36年ですのでそんなもんかもですが。

川のせせらぎ、

森の中(のベンチ)、

ちょっと理解が難しい現代美術を眺めながら

どこまでも続く道を歩いて辿り着いた先

強制的に作られた水流で永遠と回され続ける水車に寂寥感を感じて、

進軍する太陽の塔!!!…的なアングルを経て

抹茶アイスを締めに散策終了。

そのまま家路に付き2人電車でうたた寝しながら帰り着き、録画してた番組の消化、晩ご飯、風呂ときて明日に備えて早めの就寝 22:00 頃と。実に平和だー。

と言いつつ結局オフの時も何かしら考えてるんですよね。オンの時は目下のタスクやプロジェクトに意識を集中していますが、オフの時はこう何ていうか漠然と違う視点で考えてしまう感じでしょうか。

太陽の塔を見て当時の経済成長が今後は決して見込めない中どう立ち振る舞うかとか、一部閑散としていた森の一角を見てここにお客さんを呼び寄せるには何をすれば良いのかとか、抹茶アイスを見ながら原価は幾らで一日何個売れてるのかとか、店員の対応はもっとこうしたら売上が上がると思うけどなとか、録画してたカンブリア宮殿を倍速視聴しながら高付加価値商売の秘訣は何かとか、そんな事を考えてます。

まぁ、全然オフちゃうやんという事なんですが。

オフであっても絶対に仕事の事やら色々と考えてしまうので厳密なオフ状態って有り得ないのですが、こんなふうな机にかじりつく事を前提としないまったり(?)時間は、思考を深めたり、将来について思い巡らしたりするのに持って来いなんですよね、自分的に。

Circuit Board © 2011 Interop Events, Flickr

平日のオンな状態では絶対に働かない思考回路が動き出す感覚…でしょうか。

なのでオフも重要なんですよね、当たり前だけど。最近、椅子に座り過ぎ過ぎちゃうかとか休み少な過ぎちゃうかと言われる事が多いので、誕生日の日帰り旅行だけじゃなく一度思い切って奥さんと丸一日まったりオフタイム過ごしてみましょうかね。そんな事を改めて思った公園散策でした。

弊社の取り組みを御紹介するシリーズ。今回はTwitterの話。

Twitter Bird Logo © 2009 Scott Beale, Flickr

ウチは社内でTwitterの利用を推奨してまして、エンジニア全員が何かしらのTwitterクライアントを入れてます。もちろん経営者である僕も。新しいツールを取り敢えず禁止するのは日本企業の悪い所ですが、何でこう巧く「活用」する事を考えないかなーと不思議に思います。

新しいモノは新しい価値があるから広まる訳で、それはつまり企業にも価値をもたらす可能性がある訳で。どんどん使ってみりゃ良いんです。問題が出てきたら調整したら良い。

やらない機会損失の方が勿体無いって発想に何故ならないのか…なんて思いながら弊社がTwitterの活用を通して得ている価値は例えば以下。

1. 情報収集能力の劇的な向上

   個人としても上がりますが、情報を共有する下地があればチームとしても上がります。そりゃそうです。のべ4桁を越える情報源から日々何かしらの情報が入ってくる訳ですから。もちろん共有しなければ意味は無い訳で、それを可能にする仕組みは以前御紹介した夕方ミーティングです。各々が情報収集源を持ち、各自の判断で厳選したものが社内共有されるという形を取ってます。

2. 機会損失を回避

   情報収集能力にも関係ありますが、以前にこんな事がありました。数時間でチケットが売り切れるというWWDC2011。いつ発表されるんだろうとヤキモキしてましたが、とある日の夜21:00頃に弊社@nakiwoから「出てますよ」とDM。まだ仕事中だった僕は即効で2枚(弊社@itok_twitと@nakiwoの分)を購入した訳です。翌朝にはもう売り切れと。Twitterという個人が使うツールを会社での情報伝達インフラとしても利用しているからこそ出来た事です。

3. 強力な口コミネットワーク

   弊社スタッフののべfollowersは普通に数千ですから、何か告知したり宣伝したりする時の媒体にもなります。しかも follow するという行為はその人の情報に興味があるという事ですから、リーチ先からコンバージョンする率は非常に高い。2009年にメビック扇町で開催したiOS関連イベントでは顕著に表れました。僕がtweetしてエンジニアがRTする事で拡散し、1週間でキャパ100人を優に越える申込がありました。

4. 発信した情報のフィードバック

   これは最近気づいた事ですが、会社として発信した情報がRTされてエンジニアのタイムラインに現れる…そんな現象の数が多ければ多い程、それは反響があったという事を意味しています。直近の例では、エンタープライズiOSアプリことはじめ(1) 〜iDEPとDUNSナンバー〜というブログエントリ。RTされる事で反響の大きさを把握し、シリーズとして続けようという意思決定をする事が出来ました。

とまぁ幾つか列挙して見ましたが、他にもまだまだありますよ。情報の入りと出が重要な業界こそTwitterを全社導入すべきと僕は考えます。

We trust you with the children but not the Internet © 2009 Scott McLeod, Flickr

この話をするとですね、「社員がずっとTwitterをやって仕事しなかったらどうするの？」って、お約束的なコメントを頂く事が多いんですがそれがそもそも疑問なんですよね。

冷静に考えればその手の「常識」を理解出来ていない人が生み出すリスクをヘッジする為に、新しいツールを全面禁止にして便益を享受できない状態を作る事ほど非合理的な事はありません。それをやってたらウチは上記のような利は得られなかったでしょう。-1 を気にする余りに +10 を失うのは損。

そんな心配するよりも、まずそんな心配をしないといけない状態にあること、つまりそんな人材を雇い入れてしまった経営者/マネージャの責任を追求すべきちゃうんかと。面白いのは僕の経験から言える事だけど「人事部」相当の人事担当部署がある会社は禁止する傾向にあるように思います。(採用を完全な現場権限にしていないと結局人的リスクが高くなるという僕的組織論の仮説根拠)

Doubt? © 2009 Sergio Patiño, Flickr

ウチはそのへん、人を見極めてるつもり。経営者の仕事だと思っているので。だからそんな心配は全然ありません。万が一 Twitter をずっと眺めて仕事が進まないようなら、それに大きな罪悪感と開発時間が確保出来なかったという後悔を感じるような常識的感性を持っているエンジニアにjoinして貰っていますし、何より信じている訳で。だから -1 なんて気にせず、というかそもそも -1 なんて存在しないので気にする必要もなく、Twitter からは +10 の恩恵を受けています。

Twitterを禁止してる会社を見ると、「勿体無い事やってるなぁ」「信じられてなくて可哀想だなぁ」と思っちゃいます、やっぱり。

この世の中全体は性善説では成り立ちませんが、入ってくる人をしっかり見極めれば組織内は性善説でokな筈なんです。性善説が合理的で最も生産性が高い事は誰しもが共感出来る事でしょう。それを国家レベルでやってるのがモナコだったりアジアのモナコを目指すシンガポールですよね。やっぱり性善説稼働出来る組織・社会はパフォーマンス高いんですよ。

Reflections © 2011 Dmitry Shakin, Flickr

と、またしても横道にそれそうになったので軌道修正。何が書きたかったかというと、Twitter を使いこなせる人だけを集めてTwitterを社内活用するのはお勧めですよという事でした。次回はTwitter使用を前提に独自開発した社内情報共有ツールについて紹介したいと思います。

■ 過去に紹介した弊社の取組み

• 開発室と非開発室、分離のススメ(2011.9.30)
• 毎日欠かさない朝ミーティングのススメ(2011.9.22)
• 毎日欠かさない夕方ミーティングのススメ(2011.9.21)

弊社内の取り組みや制度について御紹介するシリーズ。先のエントリではエンジニアの集中力維持の為に開発室を分離、つまりハード的な分離について書きました。今回はハードではなくソフト的な分離について。

Cc/Bccにエンジニアのメアドが入ったメールは諸悪の根源

あくまで社内のエンジニアに対してという意味ですが、僕は開発プロジェクトにおいてはこれが真理だと思っています。

メールでエンジニアに割り込みが入るのは基本避けた方が良くて、Toはともかく特にCcやBccは最悪です。とりあえず知っといて的なCc/Bcc活用はよくありますが要点がまとまっていないやりとりを、開発行為を寸断してまで共有する価値は全くありません。ネットワーク帯域とストレージの無駄遣いです。

多くの場合10回行き来したメールも大概3行でまとまるもんですから、そのまとめ役とまとめ先とがあれば十分なんですよね。

弊社では基本的にこんな組み合わせでやってます。

すべての情報は僕に入り、社内システムに整理して書き込みます。エンジニアはそれを自分の都合の良いタイミングで確認します(その為にRSSを活用。更新された事が分かる)。重要なのは、エンジニアへの情報の「入り」が push ではなく常に pull であるという点。

エンジニアが意図しないタイミングで1本1本の矢が断続的に外から飛んでくるよりも、束ねられた合計10本の矢をパッと見で確認できる状態になってる方が良いんです。断続的な中断が発生しませんから。

Write © 2011 J. Annie Wang, Flickr

世の中の風習なのか(?)、マネジメント役である僕をToとするメールのCc/Bccにエンジニアのメアドを入れて頂く事もあったりするのですが、「この内容はきちんとまとめて責任持って共有しますので、以後ウチのエンジニアにCc/Bccはやめて頂けますか。開発に集中させたいので」とお願いするようにしています。それぐらい徹底してます。

理由は簡単で、エンジニアのゾーンタイム(開発に集中している時間)を中断したくないからです。これは経験者にしか分かりませんが、ゾーンに入ったエンジニアの5分は凄まじい価値を生み出します。これを失うのは関係者全てにとって不幸せなんですよね。だから「とりあえず知っておいてよ」的なCc/Bccは厳禁です。皆の幸せの為に。

これも、この本の影響が強いですね。トム・デマルコの本、エンジニアを manage する人はすべからく読むと良いんじゃないかなと思います。ソフトウェアは人が作ります。ピープルウェアなんです。

って本の話はさておき、エンジニアにCc/Bccが入っているメールをマネジメント役が許容しているとすれば、それは、まとめたり整理したりする責務を放棄してないかと自問しても良いかもなーって最近思います。Cc/Bcc入れてたら楽ですよ、そりゃ。でも、組織における苦楽はゼロサムゲーム。効率を重視するなら根っこで苦を取るに越した事は無いのです。

まぁそんな考え方なもんですから、僕は毎日対外的に大量のメールを書いて、対内的には社内Wikiを更新して、Redmineにひたすらチケットを発行しています。これが会社というチーム全体の生産性を考えた時に最も合理的という経営判断です。

Cc/Bccに限らず、関係者全員が入っているメーリングリスト開設とかも同様に最悪ですね。仮に作られる事があってもエンジニアは入れて貰わないようにして、僕がまず全部受け取って整理したものをエンジニアが社内サーバから pull 出来るようにしています。

ついでながら電話も push という意味では似たようなものかも知れません。割り込まれますのでね。だから電話の支給は有り得ませんし、内線も有り得ません。エンジニアに電話を繋ぐという事も基本的にNGです。まず僕が受け止めます。

IMG_0974.JPG © 2006 Brandon Titus, Flickr

こんな感じでマネジメント役だけが矢面に立つ事により、開発室をソフト的にも分離しています…というお話でした。昨日御紹介した、物理的に部屋を分けるというハード的な分離も併せると、ほっとんどエンジニアにノイズが入らない環境が構築でき、文字通り没頭出来るようになります。

そうすると結果的に、間に1時間休憩を挟んだ7時間ぶっ通し開発が一日の限界って事が分かります。それ以上続けても生産効率は上がらないんですよね。だからウチはエンジニアの残業は基本無しです。年間残業時間合計が5時間もない。メールの数も、電話の数も限りなくゼロに近い。ただひたすらに「開発」なのです。

紛れも無くPureな開発のためだけの「開発室」を作り出すこと、それが開発を生業とする企業経営者の役割じゃないかと僕は考えています。

弊社内の取り組みや制度について御紹介するシリーズ(勝手にシリーズ化)。以前にエントリで朝夕のミーティングを必ずやっている事について書きました。(詳しくは以下のリンク先をご参照下さい)

• 毎日欠かさない夕方ミーティングのススメ
• 毎日欠かさない朝ミーティングのススメ

朝夕と共に30分のミーティングにあてますので、9:30〜17:30 の休憩時間1時間を除いた合計7時間が開発の為の時間になります。エンジニアにはこの限られた時間を全力疾走して開発をして欲しい。他の要素すべてを廃してただひたすらキーボードを叩き続けて欲しい。なぜなら、没頭して開発出来てる(ゾーンに入っていると言います)有限な時間が一番生産性が高いからです。

欲しいのは最高のパフォーマンス。

そこで、生産効率を最大化する為に開発行為を阻害する全要素を執拗なまでに徹底排除してまして、その一つが部屋の分離です。大きな会社さんなら当たり前かも知れないですが、ウチは5人と小規模ながら敢えてやっています。

下の図は弊社が借りてる階の一部。

同じフロアで2部屋借りてまして、緑色が非開発室、ピンク色が開発室です。役割は明確に。

こんな風に、開発以外のすべての要素を非開発室に閉じ込めるようにしてます。僕が社外の方と打ち合わせる場合は来客頂く場合が多いのですが、話し合いの声がエンジニアの集中力を削がないように別室でのミーティングを徹底してます。お茶入れも今はエンジニアにやって貰う事はありません。人がいない場合は僕がやったりします。これもエンジニアの開発行為を阻害しない為。

社内ミーティングも全員参加でない場合は基本的に非開発室へ。もちろん来客受付も非開発室へ。電話も非開発室です。僕の携帯に電話がかかってきた場合は、僕は部屋を出て非開発室に移動して話をします。

とにかく全てにおいて気にかけているのは開発室を集中できる環境として維持する事。

こんな感じの扉のマグネットを確認せずに飛び込み営業がこようもんなら、「読めませんかね？」と即刻出入り禁止宣言する勢いの如く僕の逆鱗に触れます。まぁこれは極端な例ですけども、とにかくエンジニアの没頭時間(ゾーンタイム)がなるべく長くなるよう徹底しています。

著名なトム・デマルコのピープルウェアという書籍に感化され過ぎてる感は否めませんが、実際、非開発的な要素を全て開発的な空間と分離する事で、集中力維持が可能な環境は容易に作れます。つまりエンジニアにとってのノイズを取り除くということ。

これにより生産性が高まるのは弊社内で実証されていて、iOSアプリ実績数が70以上と人数の割に多かったり、企業向けソリューション SYNCNEL でもサーバ側・クライアント側が怒涛の勢いでバージョンアップしていたり…等々に現れています。

エンジニアリングと非エンジニアリングの物理的な分離(ハード的な分離)はホントお勧めです。会社の規模に依らずですね。加えて更にソフト的な分離も徹底すると効果的です。主にはメールだったりタスク管理だったりするのですが、少し長くなってきたので次回書いてみたいと思います。