関西モバイルアプリ研究会#12で発表してきました

3/30に関モバこと関西モバイルアプリ研究会#12で発表をしてきました。 http://kanmoba.connpass.com/event/28411/

■発表資料

 

■所感

関モバには3回目の参加になり、そろそろ聞くだけではなくて何かアウトプットできたらなと考えていたので発表枠に登録したところ、見事に抽選で選ばれました。 ※厳選なる抽選の結果、まさかのトリになってしまいちょっと焦りましたが…。 内容としては、ｔry!Swiftに参加して様々な方の発表を聞きながら、もやもや考えていた事の１つを言葉にしてみたという内容です。 DDD×Swiftは最近はどちらも流行っているようなのでこれからも色々な方が言及されていく分野だとは思いますが、自分が思うところはまだまだいろいろありそうなので今後もこのような機会にアウトプットしていければと思います。

企業におけるiOSデバイスの管理方法

※本記事はNCデザイン&コンサルティング㈱のブログに私が記載したものを転載・修正したものです。

企業システムにスマートデバイスが活用される機会は年々増えてきていると思います。 スマートデバイスを利用するシステムが増えるほど、企業内で利用される端末台数は増えていきますが、セキュリティやサポートの観点で、企業内で利用しているデバイスを管理する必要があります。 今回は、そのデバイス管理をフォーカスし、どのような要求があるのか、それに対するソリューションにどのようなものがあるのかをまとめてみたいと思います。

各種設定・ポリシーの統一

企業内で社員に端末を配布する場合、その企業内のネットワークやシステムを利用するための設定や、企業で策定されたセキュリティポリシーに応じた設定を全ての端末に施す必要があります。しかし、管理対象の端末が複数台存在する場合は、1台1台手動で設定するのは手間がかかります。 企業内の端末で統一させた設定・ポリシー

  • WiFiの接続設定
  • メールクライアントの設定
  • パスワードポリシー
  • 端末の機能制限
  • etc…

この問題を解決するためにiOSでは構成プロファイルという仕組が提供されています。

構成プロファイル

構成プロファイルは、iOSデバイスに対して施す各種設定を、XMLファイルとして定義し、その定義ファイルを各種iOSデバイスに適用するという仕組になります。 この仕組を利用して企業内の全ての端末をセットアップすることにより、企業内で各種設定・ポリシーを統一する事が可能です。 スクリーンショット 2015-10-24 10.53.14  

構成プロファイルを作成する

この構成プロファイルは、XMLファイルをテキスト編集して作成する事も可能ですが、iPhone構成ユーティリティというツールを使ってGUIで設定する事が可能です。  

構成プロファイルの端末に適用する

作成した構成プロファイルを端末に適用する方法はいくつか存在します。

  • iPhone構成ユーティリティを起動したPCで構成プロファイルを開いて、端末を有線接続して適用する
  • メールに添付する形で配信し、メールクライアントから添付ファイルを実行する形で適用する
  • Webサーバーで公開し、端末のブラウザ経由でファイルのURLを実行して適用する

iPhone構成ユーティリティ

構成プロファイルの説明の中でも登場していますが、iOSではiOSデバイスを簡易的に管理するためのツールとしてiPhone構成ユーティリティというツールを無償提供しています。 iPhone 構成ユーティリティ 2.2 (Mac) iPhone構成ユーティリティ  

iPhone構成ユーティリティでできること
  • 複数台の端末の基本情報の管理（UDIDやオーナー名など）
  • 構成プロファイルを作成・編集・iOS端末への適用
  • iOS端末にインストールされているプロビジョニングプロファイルと認証済みアプリの追跡、またはそのインストール
  • iOS端末からクラッシュログを抽出

小規模の企業や組織であれば、このiPhone構成ユーティリティを利用して組織内のデバイスの管理を行なう事ができます。したがって、iOSデバイスの運用をこれから始めようと考えている組織や小規模の企業の場合は、無償でデバイス管理の運用を始める事が可能です。

多数の端末の統制とリモート制御

企業や組織の規模が大きくなり、管理対象となる端末が数百・数千に及ぶようになった場合、前述の構成プロファイルとiPhone構成ユーティリティだけでは管理する事が難しくなります。 具体的には、

  • 管理者が端末を一台一台管理するにはコストがかかりすぎる
    • 構成プロファイルの適用にiPhone構成ユーティリティを用いると、全ての端末を直接管理者のPCに接続して作業を行なう必要があります
  • 管理を個人に任せると統制がとれない
    • 構成プロファイルをWebサーバーからのダウンロード形式や、メールによる配信を行った場合、実際に端末に適用するかどうかは端末利用者の手に委ねられてしまい、本当に適用してくれているかは端末を個別に確認するしかありません
    • また、構成プロファイル適用後に利用者自身がその設定を任意に変更する事も可能です
  • 管理者は全ての管理端末に物理的にアクセスする事が難しくなるため、リモートで全ての端末を統制・管理する仕組が必要になります
    • 企業が保有している端末を現在だれが利用しているのかの管理
    • 管理対象の端末の設定・ポリシーをリモートから強制的に制御
    • 管理対象の端末にインストールされているアプリケーションをリモートから強制的に制御
    • etc…

MDM（Mobile Device Managment）の利用

このような、ある程度の規模の企業・組織のデバイス管理を効率的に行なうためのソリューションとして、MDMというツールが存在します。 MDMでは、iPhone構成ユーティリティで運用していたような管理を、リモートからそれぞれの管理端末に適用する事が可能になります。 また、MDMはiOSだけではなく、AndroidやWindows Phoneも同様に管理する事が可能であるため、モバイルデバイスを導入されている大企業の多くで利用されています。  

MDM for iOS

各ベンダーが提供するMDM製品は、それぞれの製品で設定を端末に適用する仕組を作りこんでいるわけではなく、各OSが用意しているデバイス管理用のAPIを利用して機能を実現しています。

つまり、MDMがマルチOSに対応しているといえども、管理できる内容は、OSに毎に異なります。 また、同じOSに対する管理であれば、MDM製品が異なっても出来ることはほとんど同じになります。 iOSデバイスに対応しているMDMは上述のAPIを利用している事になりますが、その実体は、構成プロファイルの仕組の上で実現されています。 このため、MDM for iOSで実現できる事は、基本的にはiPhone構成ユーティリティとおなじになり、iPhone構成ユーティリティで実現出来ていたことをリモート（無線）で、多数の端末に適用できるようになったということだけになります。  

MDM for iOSの仕組
  • リモート環境において構成プロファイルを配信・適用する
  • OTAを利用したアプリケーションの登録・更新・削除
  • リモートでの各種端末情報の収集

iPhone構成ユーティリティと違うところは、MDM登録時以外にはユーザーの確認をすることなくアプリや設定をサイレント・インストールする事が可能となります。 また、ユーザーが意図的に設定やポリシーを変更する事ができないよう制限をかけることも可能です。  

MDM for iOSの主な機能
  • 構成プロファイルの管理
    • 構成プロファイルをインストール、更新と削除をリモートで実施
  • アプリの管理
    • 自作アプリとApp Storeから購入したアプリの削除
    • 自作アプリのインストール（ユーザーの承認が必要）
    • アプリのデータを削除
    • iTunes、iCloudへのバックアップの制御
  • 端末の初期化／ワイプ
    • 事故時のリモートでの設定情報、アプリ及び関連情報の削除
  • リモートワイプの実施で全てのデータとアプリを削除し初期状態に戻す
    • 端末のリモートロック
    • 端末のパスコードの一時的な解除（ユーザーがパスワードを忘れた場合）

一般汎用アプリや私有端末を業務に活用する

モバイルデバイスを有効的に活用する方法は、独自のアプリを開発し利用するだけではありません。

  • AppStoreに一般公開された汎用アプリを利用して業務を効率化させる
  • ユーザー自身が最適化した私有端末を業務利用する事で業務を効率化させる
    • BOYD（Bring Your Own Device）の運用

しかし、これらのような活用方法を実現しつつ、企業内のデバイスを管理するには、既存のMDM製品の機能だけでは課題があります。  

MDMの課題
  • アプリの利用可否しかコントロールできない 一般汎用アプリは、端末や他のアプリデータへのアクセスの有無や、自身のデータの保存先が特定できないため、情報漏洩のリスクが有あります。このため、どんなり便利な機能が備わっているアプリでも、問題となる機能以外も含めそのアプリの利用そのものを不可にするしかありません。
  • 私有端末を利用する場合にプライバシーが保護されない MDMは基本的に端末全体の管理を行います。私有端末の利用（BOYD）の場合、MDMに登録するとその端末の全ての情報がMDM管理者に公開されてしまいます。

 

MAM／MCMの利用

この問題を解決するためのソリューションとして、MAMやMCMという製品が注目されています。これらの製品は、端末全体を管理するのではなく、保護する領域と自由に利用出来る領域を定義し、保護すべき領域だけを企業の管理者がセキュア管理する仕組を提供するというものです。こうすることで、セキュリティを確保しつつ、汎用アプリの利用制限を撤廃し、スマートデバイスの利便性を引き出す事ができます。また、業務データを保護しつつも、個人のプライバシーにも配慮する事も可能になります。

MAM（Mobile Application Managment）

MDMがデバイス全体の管理を行うツールであったのに対し、MAMはアプリケーション毎の管理ポリシーを設定するツールになります。 MAMは以下のような機能をアプリケーション単位に設定する事が可能です。

  • アプリ毎の認証
  • データの暗号化
  • 通信の認証と暗号化
  • データの共有・コピーなどの制御
  • アプリケーションを特定したワイプ
  • アプリケーション毎のVPN

 

MAMの概略アーキテクチャ

スライド1  

実現方式

MAMはその実現方式が大きく3つに別れます。 実現方式に応じて、MAMの適用方法が変わります。

  • ラッピング型 対象アプリをMAMがラップ（プロキシ）してセキュリティポリシーを適用します。 ラッピング型は一度作成したアプリを特殊なツールで加工することにより、アプリにセキュリティポリシーを適用します。
  • コンテナ型 対象アプリとそのデータを専用領域（コンテナ）に格納し、コンテナ外のアプリと相互に干渉できなくします。 コンテナ型はSDKが提供され、主に開発中のアプリに組み込むことでセキュリティポリシーを適用する仕組が組み込まれます。 アプリ自体を改変するため、セキュリティポリシー以外にもログや製品独自の設定が行えるケースがあります。
  • リモートアクセス型 仮想デスクトップやセキュアブラウザを利用したアプリ実行を行い、端末に一切データを残さなくする仕組です。

MCM（Mobile Contents Managment）

MAMがアプリ毎の管理を行うツールであったのに対し、MCMはコンテンツ（ファイル）毎の管理ポリシーを設定するツールになります。 モバイルに特化したCMSのようなイメージになります。 MCMは以下のような機能をアプリケーション単位に設定する事が可能です。

  • コンテンツアクセス時の認証
  • コンテンツのアクセス制御と権限管理
  • コンテンツの暗号化
  • コンテンツの配信・同期・回収

 

MCMの概略アーキテクチャ

スライド2 MCMは専用のファイル共有アプリとして提供されているケースが多いです。また、コンテンツの種類毎に応じてモバイルに特化した専用ビューアが用意されています。

EMM（Enterprise Mobility Management）

MDM、MAM、MCMはそれぞれ競合するソリューションではなく、補完し合うものです。目的に合わせてそれぞれの機能を適切に組み合わせて利用する事になります。 例えば、Aの端末は私有端末なのでMAMとMCMだけ適用し、Bの端末は社有端末なのでMDMで管理する。などになります。 一方で、MDMの機能は先に述べたとおり、OSが提供するAPIを利用しているだけなので、製品ごとで差別化が難しくなっています。そこで、多くのMDM提供ベンダーが、差別化要因として、MAMやMCMの機能の提供を始めています。 こうした流れの中で、企業のデバイス管理は、MDM、MAM、MCMの全ての機能が必要不可欠になりつつあるため、これら３つの機能を総合的に提供するソリューションの名称として、EMMというキーワードが利用され始めています。  

EMM製品の選定基準

ここまでで説明してきた情報を踏まえ、EMM製品を採用するに当たりどのようなポイントで製品選定を行ったら良いかを考察しました。

  1. 提供形態がクラウドサービス、オンプレミスのどちらを望むかを確認する
  2. MDMの機能だけでは差別化は難しいため、EMM製品として、MAM、MCMの機能をどれだけ提供しているかを確認する
  3. MAMやMCMはその仕組上、アプリ提供方法や自社の運用方式によってはサポートできないものもあるため、見極めが必要
  4. 管理コンソールなど使用性など、独自の作りこみ機能を比較する

BYODからCOPE、CYODへ

BYODとは、社員が持っている個人のデバイスを利用して社内の業務を行うことを指します。 このメリットは、

  • 使いやすい端末を利用して業務効率を向上
  • 端末の調達や基本使用料のコストを削減

というものが上げられ、数年前から注目されていますが、日本国内では普及したとは言いがたい状況です。 この背景にあるのは、

  • IT部門があらゆるOS／機種の端末をサポートしきれない
    • あらゆるOS／機種向けの問い合わせ対応、アプリの開発
  • セキュリティポリシーの徹底が難しい
  • 実はBYODのほうがコストがかかる傾向がある
    • 社員間は通話料無料で通信量もシェアできる
    • BYODではそういった特典が得にくい

という課題が上げられます。 これを解決するアイデアとして、最近でCOPEやCYODという方法が提唱されています。  

COPE（Corporate Owned, Personally Enabled）

会社で支給するデバイスを個人で利用する事を許可するという方法になります。 仕事で使う電話代や通信料は会社負担とし、個人利用分は個人が払う形をとります。  

CYOD （Choose Your Own Device）

私有端末の利用を許可する変わりに、会社が選別した機種から選定させるという方法です。 MAM/MCMを導入してセキュリティリスクを軽減した上で、COPEやCYODを活用により、従来BYODで達成したかった目的を実現する事が可能になってきています。

iOSアプリリリースのポイント

※本記事はNCデザイン&コンサルティング㈱のブログに私が記載したものを転載・修正したものです。

今回はiOSアプリのリリースについて書いてみたいと思います。 iOSアプリのリリースやiOS Developer Programへの登録、証明書の発行、プロビジョニングファイルの準備や審査への対応など、WebシステムやAndroidアプリのリリースに比べて、その作業内容は複雑難解な印象があります。 初めてリリース作業をする人にはとてもハードルの高い作業の様に思えますので、その内容やポイントをまとめることで、これからリリース作業をされる方の役に立つ情報になればと思い記事を書きました。 まずは、アプリが一通り完成してから、リリースするまでの大まかな流れをまとめてみます。  

アプリ配信までの流れ

    1. iOS Developer Program登録
      iOSアプリを本番で利用するには基本的にはiOS Developer Programに登録する必要です。法人で契約する場合はD-U-N-S Numberが必要になり企業審査があります。D-U-N-S Numberの発行と企業審査には2週間程度の時間がかかるので注意が必要です。以降の手続きで登録後に利用できるMemberCenterを利用する必要があります。Xcode7以前はアプリ開発開始前に登録を済ませている場合もあります。

 

    1. iOS Distribution用の証明書を発行
      アプリを配布するための証明書を発行します。1つの証明書で複数のアプリを発行できるので、通常は１つあればOKです。MemberCenterのCertificatesにて発行手続きを実施します。

 

    1. App IDの登録
      リリースするアプリを登録します。Xcodeでアプリに指定したBundle Identifierを指定します。MemberCenterのIdentifiersにて登録手続きを実施します。

 

    1. オプションサービスの指定と証明書発行
      アプリで利用している機能に応じてオプションサービス（Push通知やiCloudの利用など）とそれを利用するための証明書発行を行なう必要があります。証明書の発行をMemberCenterのCertiricatesで行い、Identifiersにて登録したAppleIDに対して利用するサービスを有効化する設定を行ないます。

 

    1. Provisioning Profileの作成
      アプリのプロビジョニング用のプロファイルを作成します。プロビジョニングファイルは同じアプリでも配布形態毎（AppStore / AdHocなど）に作成する必要があります。プロビジョニングファイル作成では、前述のDistribution証明書とApp IDの登録が必要になります。 AdHoc配信の場合は、別途Device登録も必要になります。MemberCenterのProvisioning Profilesにて作成手続きを実施します。

 

    1. Build & Archive
      XcodeやCIサーバーを利用してモジュールをビルドし、ipaファイルにアーカイブします。App Storeにてモジュールを配布しない場合は、この時点で作成したipaファイルをエクスポートして端末に配布する事が可能です。エクスポートする際は、アーカイブ時に配布形態に合わせてDistribution証明書とProvisioning Profileの指定が必要になります。

 

    1. iTunesConnectへのアカウント登録
      iOS Developer Programへの登録が完了すると、登録に使用した管理者のAppleIDで iTunes Connectにサインインできるようになります。他のIDで作業したい場合は、そのIDへの招待が必要になります。ただし、同一IDで複数の企業のiTunes Connectへの登録は不可能です。（iOS Developer Programは同一IDで複数企業への登録が可能）

 

    1. iTunesConnectにアプリを登録
      アプリの情報をiTunesConnectに登録し、作成したipaファイルをiTunesConnectにアップロードします。アップロード時には配布形態に合わせてDistribution証明書とProvisioning Profileの指定が必要です。アップロードはXcodeにて実施します。

 

    1. Apple審査
      iTunesConnectに登録したアプリ情報に、審査に必要な情報を追記し、Appleの審査に提出します。審査は実際に人手で行われるため、審査員が操作するためのアカウント情報（IDやパスワードなど）を記述しておきます。審査をパスするとメールにて通知がきます。審査のステータスはiTunesConnectにて確認可能です。

 

  1. AppStoreへリリース
    審査をパスした後、Apple Storeに公開する情報の最終チェックを行い、Storeに公開します。一度公開すると公開情報は修正できず、修正するには新しいバージョンの提出（再審査）が必要になるので注意が必要です。


リリースまでの流れは以上になります。 次のページではアプリの配布形態についてまとめて見たいと思います。

次に、アプリの配布形態についてまとめてみます。   配布の話を始める前に、前提知識としてDeveloper Programのメンバーシップ形態について説明しておかなければなりません。

Developer Programのメンバーシップ形態

iOSアプリを開発・配布するためには、Appleが提供するDeveloper Programを契約（購入）しなければなりません。 Developer Programの契約形態には次の4つがあります。

    • iOS Developer Program（個人）
      個人、または個人事業主の場合のメンバーシップ形態です。 年間登録料：$99

 

    • iOS Developer Program（法人）
      法人としてプログラムを利用する場合のメンバーシップ形態です。D-U-N-Sナンバーによる法人登録と、審査が必要です。アプリの販売に法人名が利用可能です。 年間登録料：$99

 

    • iOS Developer Enterprise Program
      法人として従業員にのみ配布するアプリを作成する場合のメンバーシップ形態です。D-U-N-Sナンバーによる法人登録と、審査が必要です。AppStoreに公開せず従業員にアプリを配布することが可能です。 年間登録料：$299

 

  • iOS Developer University Program
    iOS用の開発をカリキュラムに取り入れることを検討中の高等教育機関のお客様を対象とした、無料のメンバーシップ形態です。教職員や学生はだれでもApple製デバイス用のアプリの開発とそれに必要なリソースの利用が可能です。 年間登録料：無料

 

アプリの配布形態

目的に合わせて幾つかの配布形態が用意されています。

    • Development（開発用配布）
      開発中に実機に配布する形態です。Xcode端末と有線で接続してインストールする必要があります。

 

    • AdHoc（評価用配布）
      開発中のアプリを複数の実機端末に評価用に配布するための形態です。AppStoreを介さずに、最大100台の実機端末に配布可能です。アーカイブしたipaファイルを各端末に配布します。配布対象端末のUDIDをMemberCenterにて管理する必要があります。

 

    • In-House（組織内配布）
      組織内だけで利用するアプリを対象の組織のみに配布するための形態です。契約している組織内だけに限り、AppStoreを介さずに、台数無制限で配布可能です。アーカイブしたipaファイルを各端末に配布します。AdHocとは異なりMemberCenterでのUDIDの管理は不要です。ただし、契約主体法人以外にアプリ配布があった場合はiOS Developer Programのライセンスを取り消され、法的な罰則が課せられます。

 

    • AppStore（一般公開）
      Apple Storeにアプリを公開し、iOSユーザー全てに一般公開する配布形態です。特定ユーザー、組織への配布という設定は不可能です。

 

  • VPP（Volume Purchase Program）
    第三者が特定の組織に限定したアプリ（カスタムB2Bアプリ）を配布する場合の配布形態です。詳細は後述。

 

VPP（Volume Purchase Program）

システム開発者が特定の企業向けに開発したアプリを配布するにはVPPを利用する必要があります。 一般的にSIerがDeveloper Programに登録していない特定の顧客企業からアプリ開発を受託して開発した場合に、その企業だけにアプリを配布する場合に利用します。
VPPには以下の様な特徴があります。

  • Appleが用意した専用ストア（VPPストア）でアプリを配布可能
  • VPPストアはVPP契約者毎にプライベートなApp Storeが用意され、契約者が発行したアカウントを持った人だけがアクセスできるようになる
  • 企業に導入されたMDMソリューションとの連携も可能
  • アプリ提供者はiOS Developer Programへの登録が必要
  • アプリ利用者はVPPへの登録が必要
  • 登録は無料だが、D-U-N-Sナンバーによる法人登録が必要

VPPによるアプリ配信の仕組 iOS_AppRelease_VPP  

配布形態のユースケース

先に述べたように、契約しているメンバーシップ形態に応じて、利用できる配布形態が異なります。 その相関関係をまとめたものが下記の図になります。 iOS配布形態ユースケース@2x   この相関関係を踏まえた上で、ユースケースに応じた配布形態を整理してみます。

  • 自社で社内アプリを作成・配布する
    • 配布対象デバイスが100台以内の場合、AdHocで配布
    • 配布対象デバイスが100台以上の場合、In-Houseで配布
  • SIerが特定の顧客企業内で利用されるアプリを作成・配布する
    • 顧客がiDPに登録していない場合は、VPPを利用
    • 顧客がiDPに登録済みの場合は、iDPに開発メンバー登録させてもらいAdHocかIn-House形態で配布
  • SIerが特定の顧客企業が一般公開するアプリを作成・配布する
    • 顧客名義でアプリを配布する場合は、顧客にiDPに登録してもらい、App Storeで配布
    • SIer名義でアプリを配布しても良い場合は、SIerでiDP登録し、App Storeで配布

 

ipaファイルのOTA配布

iOSアプリをアーカイブして作成したipaファイルを配布するには、AppStoreを利用せずに配布する方法は、AdHocやIn-Houseが利用されます。 ただし、通常、作成したipaファイルは、端末をPCに接続しiTunesやiPhone構成ユーティリティを使ってインストールする事になります。 この方法だと、遠隔地にある複数の端末にipaファイルをインストールするにはとてもコストがかかります。 この問題を解決する方法として、OTA（Over The Air）という仕組が有ります。

OTA配布の仕組

OTA配布では、インストール用のplistファイルを作成し、ipaファイルと一緒にWeb上に公開する事で、端末からはそのURLにアクセスするだけでアプリをインストールする事ができるようになります。 具体的には、以下の様な専用のURLスキームを利用してiOSからURLリンクを叩く事になります。 　urlの例 : itms-services://?action=download-manifest&url=<plistのURL> メールなどで上記URLを連絡し、端末ユーザーにリンクを実行してもらうことでインストールを促します。 多くのMDM製品は、このOTA配布を利用して、AdHocやIn-House形式で作成したipaファイルを配信し、リモートからインストールするようにしています。
以上がアプリの配布形態についてになります。 最後のページでは、Apple審査のポイントについてまとめたいと思います。

最後にAppleの審査のポイントについてまとめたいと思います。  

Apple審査のポイント

Apple審査のステータス（概略）

審査中の代表的なアプリのステータスは以下のように変化します。 Waiting For Review → In Review → Rejected or Pending Developer Release

Apple審査に必要な期間

審査にはおおよそ1週間〜2週間程度の時間がかかります。 内訳として、Waiting For ReviewステータスからIn Reviewステータスになるまで約1週間程度です。 In ReviewステータスからRejectedステータスまたはPending Developer Releaseステータスになるまで約1日です。 もしリジェクトされた場合、問題解決センターでコメントが返ってくるまでの期間が3日〜1週間程度になります。

Rejectされた時の対処法

問題解決センターでレビューアとテキストのやりとりが可能です。 Rejectedの場合は、ここに指摘が書かれるので、それに対しての説明やフォローをテキストで返します。 指摘された内容に応じて、アプリ情報やアプリモジュールを修正します。

Rejectの原因

Appleよりレビューのガイドラインが出ているのでそちらを参照してください。 App Store Review Guidelines : https://developer.apple.com/app-store/review/guidelines/ まずはガイドラインを確認する事が重要になります。 また、最も多い原因として"More information needed"が上げられており、iTunesConnectのアプリ情報を丁寧に記述することがポイントとなります。 「App Reviewに関する情報 > メモ」という入力項目があるので、ここに懇切丁寧な情報を書き込んでおくほうが良いです。

Apple審査に必要な期間の見積もり

平均待ち時間を確認するサービスがありますので、これを利用すると審査期間の見積もりがしやすくなります。 Average App Store Review Times : http://appreviewtimes.com/ また、1度はRejectされることを前提に見積もった方が良いでしょう。 混み合っている場合は"More information needed"を理由に意図的に1度Rejectされることもありました。（私の体験談で、修正せずに再提出したら通ったアプリが幾つかあります）

TestFlightによる審査モジュールの検証を行なう

TestFlightは実際に審査に提出しているモジュールを配布し動作させる事ができるというメリットがあります。 シミュレータや、テスト用のAdHoc配布モジュールでは正しく動作していても、審査に提出する際のアーカイブに失敗している可能性があります。 Rejectされた場合は実際に審査に出しているモジュールをTestFlightで配布し検証する事をおすすめします。 また、審査は通過してもビルドオプションを間違っており、配布モジュールが意図した動作をしていない可能性があるため、iTunesConnectアップロード後に必ずTestFlightで配信したモジュールを検証しましょう。 （私は間違った設定で審査に提出してしまい、審査が通過したあとアプリを起動してその間違いに気付いたことが有ります。その間2週間の時間が立っていました…）

特急申請（Expedited Review Request）

どうしても急ぎでアプリをリリースしたい場合に、待ち行列を無視してレビューをしてもらえる方法があり、それを特急申請と呼びます。 ただし、利用回数には制限があり、あまり高い頻度で利用しているとアカウントをロックされてしまう可能性がありますので注意してください。

利用方法
  1. iTunesConnectのContact Usから特急申請を選択
  2. 特急申請を利用する理由を記入して申請を送る
  3. Appleより承諾のメールが届くと審査がスタートする

 

申請理由

理由が適切でない場合は却下されることもあります。 以下の様な理由の場合に利用してください。

  • 緊急バグフィックの場合
  • 時期が差し迫っているイベントに関係しているアプリの場合

 

審査期間

およそ1〜2日で審査が完了します。 Reject後の再レビューも優先的に審査してもらえます。   以上が、iOSアプリのリリースについてのまとめとなります。 この記事を読んでいただいた方のiOSアプリリリース作業の助けになれば幸いです。

京アジャでエッセンシャルスクラム読書会をやってます

勉強会 アジャイル
※本記事はNCデザイン&コンサルティング㈱のブログに私が記載したものを転載・修正したものです。

10月から、京都アジャイル勉強会（京アジャ）でエッセンシャルスクラムの読書会をやらせてもらえることになりました。
10/1(水)に第1回をやったのですが、やろうと思った経緯などをまとめておこうかなと思います。

京アジャ エッセンシャルスクラム読書会とは

京アジャとは

京都アジャイル勉強会（https://www.facebook.com/KyotoAgile）

内容

アジャイル・スクラムを実践しようとしている（もしくは実践中の）方で、進め方に疑問がある人を対象とした勉強会。
「エッセンシャルスクラム」を読み進めながら、みんなで疑問を共有し、 時にはワークを行いながら、理解を深める。

書籍：エッセンシャルスクラム アジャイル開発に関わるすべての人のための完全攻略ガイド

エッセンシャルスクラム書籍画像
Amazon.co.jp で詳細を見る

進め方

  1. Github Wikiを用意しているので、参加者が事前にそこに疑問やディスカッションしたいネタを書き込んでおく
  2. 当日は、対象範囲の各章毎に書き込まれた内容を見てディスカッション

第一回のイベントページ

http://connpass.com/event/8760/

開催の動機

きっかけ

最近よく「この本いいぞ！」って話を耳にするようになっており、内容を見ると基本だけでなく具体的な実践のためのエッセンスが書かれたものなので、より実践的な知見が増えるのではないかと思っていました。
でも、仕事が忙しかったりして一人で読もうとするとなかなか進まない状況でした。それなりにボリュームもあるし…。
また、本からだけでなく、いろいろな有識者からのフィードバックが欲しいとも考えていました。

大阪でもやっているけど…

大阪はテーマ抜粋のディスカッション形式でした。でも、自分は書籍として章毎に順番に読んで、一つ一つの章で深いディスカッションがしたいと思っていました。そして大阪は滋賀から遠い…。

今の仕事へのフィードバック

今の会社のサービスは、お客様の事業の立ち上げからその中で必要となるシステムの開発までをコンサルティングする事が多いです。特に今引き合いが多いUXによる事業の検討・検証のコンサルティングから入ると、システム開発もリーンやアジャイルのマインドセットを持ち込んで取り組んだ方が進めやすい。そうすると必然的にシステム開発にアジャイルな進め方を導入していくことになります。しかも、コンサルティングと言いながら、かなり具体的な作業までお客様と一緒にやっています。色んな物をデザインし、それをレビューしたり一緒に検証したりする。
デザイン対象の例： なので、より現場に近い実践的なこの本の内容はアジャイルコンサルタントやコーチを専門にやっているわけではないですが、必須な知識だったので仕事にフィードバックできると考えました。

京アジャでやる意味

主催を手助けしてくれる、一緒に主催してくれる素地や仲間が必要だった

前職に比べると場所も時間も流動的なワークスタイルなので、主催しても絶対に参加できる保証ができないので、それを助けてくれる仕組が必要でした。また、京アジャの主催者である前川、大友コンビと一緒にやると、ネタに悩むことがない、やりたいことをテーマに上げると勝手に盛り上げてくれるという安心感もあります。

京アジャに何かコミットしたい

京アジャは自分のアジャイルの原点であり、一緒に育ってきた家のような感覚があります。だから、個別開催より京アジャブランドへの貢献がしたいと思っていました。また、最近は東京や大阪でも活動していますが、各都市でアジャイルの話題になった時に、「京アジャに出入りしています」というと、割りとその存在を知っている方が多く、どこか誇らしく感じると同時に、その周囲の評価にふさわしい活動に貢献したいとも思っていました。

京都のテクノロジーに対するアイデンティティへの思い

前職が京都母体の会社であり、その活動の中で、技術部隊の自分たちが京都で何ができるのか、京都に技術部隊を置く意味は何なのかを考える機会がありました。
京都は、大企業でもITベンチャーでも面白くて元気のある企業が多い。また、京都のIT勉強会も元気があるし、尖っていると思います。自分自身も京都DDD(ドメイン駆動設計)勉強会を主催してみて、邦訳が出てからという意味では、全国的に見ても取り組みは早い方だった気がするし、お会いする人に聞く上では、他の地方からも興味を持って見てもらっている事も確認できていました。
そんな京都のテクノロジーに対するアイデンティティの一部に貢献したいと思っていました。
※滋賀出身滋賀在住ですが…。

そんな大きな勉強会でもないし、少し大げさな表現になっているかもしれませんが、概ねこんな感じです。

第１回をやってみて

流れとかを考えてネタを出しているの？

第１回は基本的に私が考えたネタを中心にディスカッションしたのですが、その中で、「参加者の層や、進行上の流れとかを考えてネタを出しているの？それとも単純に自分が知りたいことだけ？」的な質問を受けたのですが、そこまでいろいろ考えて準備はしてなかったです。でも、次のような事を念頭においてはいるなと思ったので、文章にしてみました。

参加者にはアジャイル初心者の方からベテランの方までいるだろう。その中で、自分は比較的中級からベテランの位置にいる。その自分がアジャイルを始めた頃に疑問だったことに対して、今は自分なりの解釈を持っている。だから、今からアジャイルを始める人には、当時の疑問をネタに上げて、その疑問と解釈を共有したら、立ち上げを支援できるのではないか。一方で、自分みたいな中堅やベテランとしては、当時の疑問に対する今の解釈が本当に正しいものなのかを、より経験の深い人からフィードバックをもらえるはず。
また、中堅やベテランに対しては、より具体的な実践を積んで生まれた疑問をネタにする事で、疑問を共有し、解決している人や解釈を持っている人の意見を聞く事で得られるものがあるのではないか。

京アジャの特徴は現場で具体的に困っていることの質問が多いこと

懇親会の席で京アジャ主催者の大友さんを中心に話していたことです。京アジャは立ち上げの頃からの風土ですが、アジャイルをやろうとしてなかなかうまく行かなくて困っている人の生きた疑問のディスカッションが多い傾向があります。発表形式ではなく、少人数でのワークショップやディスカッションが多いからだと思いますが、キレイに体系化・抽象化された答えでは解決されない、具体的な実践の現場での疑問のディスカッションになります。
このディスカッションからのフィードバックは、コンテキストが異なっている人に対してでも、議論が深くなる分、他の場では得られないものも多いですし、何より議論していて楽しい。

ただし、ベテランと初心者の温度感の差など、反省点もいくつか見えてきているので、徐々に改善していきたいと思います。

まとめ

ということで、開催にあたり、いろいろ考えていたことや感じたことをまとめてみました。
第２回も予定していますので、興味がある方は是非参加してください。
第２回イベントページ：http://connpass.com/event/9066/

XP祭り2014に参加してきました（２）

勉強会 アジャイル
※本記事はNCデザイン&コンサルティング㈱のブログに私が記載したものを転載・修正したものです。

9/6にXP祭り2014に参加してきましたので印象に残った事をまとめたいと思います。
まとめていたらかなりのボリュームになってしまったので、２回に分けて記述したいと思います。 今回は後半戦です。
xp2014  

関連記事


参加したセッション


システムテストも自動化していこう 永田 敦さん

永田さんは、STARと呼ばれるテスト自動化研究会(STAR: Software Test Automation Research Group Jp)に参加されておられます。今回はこのSTARで取り組んでいるシステムテストの自動化とはどういう事かという講演でした。具体的な手法は、2014/12/14に開催されるシステムテスト自動化カンファレンス 2014で話があるそうです。

STARのスコープは、JSTQBでいう所のシステムテスト/受け入れテストです。狩野モデルでは、製品の品質は魅力的品質（充足されれば満足、不充足でも仕方がない）と当たり前品質（充足されれば当たり前、不充足で不満）で成り立っているとあります。魅力的品質も重要だけれども、もう一方の当たり前品質を落とさない事がとても難しい。また、製品の進化は早く、少し前の魅力的品質は、次の魅力的品質の実装に推移すると当たり前品質になってしまう。そのため、当たり前品質を検証のスコープはどんどん広がり、それを落とさないための技術が必要。

アジャイルのようなインクリメンタル開発のリスクはデグレード。アジャイルは新規プロダクトでも初回のイテレーション以外は派生開発でありデグレがつきものです。だから回帰テストの自動化が注目を集めます。

アジャイルを採用しているプロジェクトでも、システムテストや受け入れテストは全てのイテレーションが終わってから場合が多い。そして、結局プロジェクトの終盤でバグが発生してその修正に追われます。イテレーション後のシステムテストは最終局面であるため、バグはチームにフィードバックされないし、プロセスも改善されない。計画ゲームとプロセスの改善を続けていても、結局最後がパワー勝負。これって本当にアジャイルなのか？フィードバックループを早くするなら、システムテストもイテレーション内でやるべきではないか。
という事で、STARではシステムテスト/受け入れテストの自動化を研究されているようです。

また、システムテストの自動化に伴ってテストエンジニアのロールが変わるとの事。従来のテストエンジニアのロールは、テスト計画・設計・結果の分析と報告であった。しかし、自動化に伴って、テストオートメータというロールが必要。テストオートメータは、自動テストの計画・設計・開発・運用を行うロールで、その結果を随時開発チームにフィードバックする。開発チームも新しいストーリーに着手したり、完了したらその内容をテストオートメータに共有する。アジャイルでは、イテレーションを繰り返しながら徐々に機能をくみ上げて行くため、テストできる箇所が徐々に増えたり、途中で変わったりする。そのため、WFの時よりテスト設計が高度であり、設計と運用に柔軟性が必要になる。それを解決するためには、特別な役割を設け、常に開発者とコミュニケーションを取りながら進める必要があるとの事でした。

これは私の私見ですが、アジャイルを実践しているプロジェクトでも、最後にシステムテスト/受け入れテストを実施されている案件が多い気がします。私もそういう風に運営したプロジェクトが多かったです。アジャイルだとイテレーション中はショーケースで動く物を見せるために力を注ぐ傾向があるため、システムテストフェーズでは細かな不具合や、イレギュラー処理の実装漏れが多数発見されます。そのため、リリースイテレーション（リリーススプリント）みたいな機会を計画しておき、帳尻合わせをする事が多かったのです。今後このような問題を解決するために、このイテレーションの中でシステムテスト/受け入れテストを行うという方法は重要になってくるのだろうと思います。

国際会議 Agile2014の風 ～とある参加報告～ 鷲崎 弘宜先生、伊藤 宏幸さん、山本 洸希さん

私は、世界のアジャイルの情勢を確認するために、このセッションを聞きにいきました。
今年のAgile2014では、2年前のAgile2012に比べ、アジャイル/スクラム/リーンの基礎はもう周知である事を前提に、基礎セッションは少なくなっているとのこと。
世界を代表するカンファレンスでも、もう基礎を理解している事は前提になってきているようで、その上で現在のトレンドは以下の３つとのこと。

 

エンタープライズアジャイル

エンタープライズアジャイルは、企業全体レベルでのアジャイルを実現しようという考え方です。伊藤さんのブログ(Agile2014に参加してみて分かった昨今の世界のアジャイル事情)に書かれていますが、私もこのエンタープライズアジャイルを「大規模プロジェクトでのアジャイル」と誤解していました。
内容としては、マインドやスピリチュアルな話しかなく、「でどうするの？」という部分の話があまりないのが気にかかったとの事。それでも、方法論よりそういうマインド系の話のほうがアメリカ人には受けるらしく、一方で諸外国の参加者はしらけているようです。一方で、アメリカではこのような方法論やビジネスを無視したマインドだけのアジャイルコンサルタントにプロジェクトを失敗に追い込まれる事例が多いのだとか。そのため、アメリカではアジャイルコンサルタントは信用されていないらしいです。鷲崎先生がその理由の考察として、アメリカのような多民族国家では、プロセスや方法論の前にマインドを合わせる事が最大の課題になっているため、このようなマインド的な話が受けるのではないかと話されていたのが印象的でした。Agile Japan 2014の基調講演で水野さんが単一民族国家のアドバンテージとして、文化・価値観・習慣が揃っている事で意思疎通がスムーズに行える点を挙げて、日本はこのアドバンテージを生かすべきとおっしゃっていましたが、日本のアジャイル業界やソフトウェア業界は、まさしくこの点をうまく活用すべきなのでしょう。

テスト手法

日本でもBDDやATDDは注目されつつありますよね。私は昨年受講したCSM研修の講師がJim Coplienであり、Scrumの研修中にも関わらずTDDの是非の議論が盛り上がっていたので、BDDやATDDには興味を持っていました。そんな中で、今回紹介があったのが以下の２点。

  • Exploratory Testing（探索的テスト）
    特別新しいものではないですが、従来の記述的テストだけでなく探索的テストが注目されている。いわゆる、テストをしながら次のテストケースを考えていくというやり方です。テスト時にはテストチャーターと呼ばれる原則・方針を決めて実施します。テストチャーターによって、フィーチャや複雑性、苦情、構成、ユーア、テスト性、可変性、相互性、データ構造、シナリオ等が限定され、限定した領域をテストで分析していきます。
    今回はどのような場面でこの探索的テストを活かすのかまでは話を聞けなかったですが、想像するに、テスト用の部隊を用意する、またはテストを集中的に実施する時間を用意して、そこで、品質を分析したい、または品質が低い機能や事象に対して適用する事で、あらかじめテストケースを定義する記述的テストでは発見できない問題の抽出や分析を行うのではないかと考えています。これは、基調講演であった忍者式テストのメリットに通じる部分があり、１つのプロダクトを継続的にエンハンスしていく事を念頭においているアジャイルにおいて、注目されるべき領域なのだと感じました。

  • Mutation Testing
    テストコードが正しく作られているかを確認する手法です。具体的には、対象のプロダクトコードの一部を機械的に書き換えて、わざとバグを含ませたコードを作ります。そして、改変前の正しいプロダクトコードに対して作られたテストコードを、改変してバグの含まれたプロダクトコードに対して流した時に、正しくバグを検知するかという事を検証するというものです。一般的に、バグが多く含まれる部分というのは分岐や符号部分にあるため、プロダクトコードの分岐条件や符号を意図的に改変する事で実施するようですが、これを人手でやるのは大変なので、基本的には機械（ツール）にやらせます。このツールが進化しオープンソース化された事で注目を浴びて来ているようです（代表的なオープンソースツールにPITという物があるようです）。
    確かに、TDD等、xUnitを使ったテストコードを書く機会が増えてきましたが、そのテストコードの妥当性を機械的に検証する方法が、カバレッジくらいしか無かったので、このテストコードの品質を自動検知してくれるツールの導入はおもしろと思いました。

メトリクス

メトリクスの話は時間が無くなった事と、発表者の伊藤さんが最後LT大会のネタにされており、ネタバレするという事で割愛になりました。しかし、LTの中で発表があった内容を簡単にまとめました。


Agile2014で人気のあったメトリクス
  • Cumulative Flow Diagram(CFD)
  • スループット（ある一定時間で、どれだけのチケットが終了しているのか？）
  • サイクル・タイム（チケットが次のフェーズに移動するのに、どれだけ時間がかかっているのか？）
  • リード・タイム（チケットが開始してから終了するまで、どれだけ時間がかかっているのか？）

印象的だったのは、バーンダウンチャートを書くだけで見える化していると考えていないか？バーンダウンが落ちないのはなんで？理由を計測しないとダメだよねという話。私自身、バーンダウンチャートの先にあるものを可視化する事を考えられていなかったと反省しました。そして、それをチーム内のコミュニケーションの手段として活用する事で、改善のサイクルをより良くまわす事ができるんですね。

所感

基本、関西勤務の私は、東京開催であるXP祭りに参加するのは今回が初めてでした。XPはどことなくScrum人気に押されがちで少し下火になっているのかなと思っていましたが、東京のXP祭りはにぎやかでした。そして、Scrumの話は出てくるものの、XPを中心に話をされる方が多かったのでScrumがベースの私にはいろいろと新鮮でした。
多くの刺激を貰えたので、この活気を関西にも持って帰りたいなと思います。

XP祭り2014に参加してきました（１）

※本記事はNCデザイン&コンサルティング㈱のブログに私が記載したものを転載・修正したものです。

こんにちは。NCDCの北村（@chipstar_light）です。 9/6にXP祭り2014に参加してきましたので印象に残った事をまとめたいと思います。
かなりのボリュームになってしまったので、２回に分けて記述したいと思います。
今回は前半戦です。

xp2014

関連記事


参加したセッション


XPの俺 / XP再考を再考する【基調講演】 関 将俊さん


TDDと忍者式テスト

忍者式テストは結構前（2005年くらい？）から提唱されているようですが、私は初めて知りました。また、追い込まれた案件で似たような事をやった経験がありますが、その内容がこのように洗練され体系化されていることに驚きました。

TDDの良さは、完了をテストで定義しその完了に向けて動作を確認しながら実装を進められる事と、過去の完了も常にテストしながらコードの変更がプロダクトを壊していないかを確認できる事だと思います。一方で、xUnit等を用いたテストの自動化は、あくまでもTDDの副産物であり、テストの自動化自体がTDDの良さではありません。
この論理を中心に、TDDをxUnitを使わず手動テストで実践する方法が忍者式テストです。また、コンポーネントテストレベルではなく、システムテストや受け入れテストレベルでTDDやろうという側面もあります。

具体的には、
１．毎日新しく完了したストーリーのテストケースを追加
２．前日までに積み上げたテストケースは毎日実行し、実装にフィードバック
３．テストケースが増えてくると運用が回らなくなるので、テストケースを整備する。テストケースの重複を排除し、手順の簡略化や作業の効率化を行う。
４．それでもテストが増えるので、テストに閾値を設けて一定の閾値を超えたテストはやめてしまう

テストを削るのは怖いですよね。けれども、そこを思い切って削る事がコツだそうです。これって別に忍者式テストだけの話じゃないですよね。xUnitで書いた自動テストでも、テストが肥大化し、実行に時間がかかったりメンテナンスに苦労したりします。従ってxUnitテストでも同様に、この閾値を設けて思い切ってテストを削除する必要があるかと思いました。閾値は、テストが落ちなかった期間や、品質目標に対する乖離度になるかと思います。このように自動テストでも使える考え方であるならば、発表の中であったiTunes風テストケースリコメンドシステムは広い範囲で適用できるとても面白い発想だと思いました。また、こうして常にテストを見直す事で、テストケースが洗練される事も大きなメリットです。
さらに、忍者式テストの特性として、日々テストケースをアレンジする事で、既知の情報の確認だけではなく新しい情報の発見ができる、いわゆる攻めるテストになる点も効果がありそうです。 忍者式テストは、最近注目されてつつある、システムテストレベルでの自動化や、TDDよりBDDやATDDの流れに通じるものを感じました。

計画ゲーム

「衝撃」というタイトルのスライドに"事実を使って計画していいなんて！"、"「変更」「わからない」「間違える」が前提になっている"という言葉が出てきていましたが、私も初めてアジャイルに出会った時は同じ衝撃を受けた事を思い出しました。

アジャイルでは、欲しい物が何かをあらかじめ正確に定義する事は難しいので、動くものを少しずつ作って、確認しながら開発を進めようという考え方があります。しかし、分からないのは欲しいものだけじゃなく、「作り方がわからない」という事もありますよね。だから、開発内部でも計画ゲームを使おうという話がありました。実装していく過程で見えてくる事もあるので、実装の未知の部分を確かめるタスクをストーリーとして切り出して、それもイテレーションの中で取り組み、ショーケースで確認すれば良いとのこと。
前職で実装方法が見えていない機能がたくさんあり、その扱いに悩んでいた事があるので参考になりました。

チームビルディングのためのワークショップ ～アジャイルの導入の勝算は、チームビルディングにあり！～【ワークショップ】 うえだ まさみさん


ダニエル・キムの成功の循環モデル

成功の循環モデル

  • 互いに尊重し、結果を認め、一緒に考える（関係の質）
  • 気づきがあり、共有され、当事者意識を持つ（思考の質）
  • 自発的・積極的にチャレンジ・行動する（行動の質）
  • 成果が出てくる（結果の質）
  • 信頼関係が高まる（関係の質）
  • もっと良いアイデアが生まれる（思考の質）
 成功する組織はこの循環モデルがうまくできているそうです。この中でも、まずは「関係の質」を変えていこうという話があり、「毛糸のワーク」というワークショップをやりました。そこで印象的だったのは、「関係の質の改善はリーダーだけがやるべきものじゃない」という事。
私は前職で管理職をしていましたが、チームビルディングを行うためにはリーダーである自分の行動や発言で何とかしないといけないと思い込んでいました。そのため、チームの目標の共有や話しやすい場や環境作りなどに試行錯誤していました。しかし、それである一定までの関係作りはうまくいくのですが、学生時代の部活や文化祭の準備の時のような一体感を生む事はできませんでした。今でも、何が原因だったのかなと考える事がありますが、その１つの解がここにある気がします。
Agile Japan 2012の中で「一人一人はいい仕事をしたいと思ってる」という事を学びましたが、これが前提にあるのであれば、チームビルディングとはリーダーが一人で取り組むのではなく、成功の循環モデルのような考え方をチーム全員で学び、一人一人が実践する事が重要なんじゃないかと気づかされました。

では、関係の質を上げるにはどういう事を学んだら良いか。
少し深堀がありました。

ジョン・ゴッドマン博士の関係の中にある四毒素

関係の質を下げる要因です。
  • 非難 批判。とげとげしさ。弱いものイジメ。押し付け。乱暴な攻撃。イヤミ。
  • 侮辱 見下し。こき下し。敵意あるうわさ。間接的攻撃。無礼。軽視。屈辱的なことば。
  • 防御・自己弁護 他者からの影響に心を閉じる。話題をそらす。向き合わない。かたくなになる。
  • 無視・逃避 回避。非協力。消極性。上の空。追従。遠慮。
人との関係を作る上で、この四毒素をなくす事は不可能だそうです。相手への期待があるから毒がでる。期待がなければ毒素もでない。だから、毒に毒をかぶせてはいけない。
そこで、この毒を中和するために、8つの態度を持ち込むのだそうです。

関係性を良くするために持ち込む良い8つの態度

  • 思いやり
  • 小さな声に耳を傾ける
  • 遊び心
  • 尊重
  • 恊働・パートナーシップ
  • 好奇心
  • 本気
  • その他
特に、いつも一番やらない要素をやってみるのが改善の近道との事でしたので、私も実践してみたいと思います。

講師のうえだまさみさんはリーダー塾というものをやられている様です。関西にいるからかあまり存じ上げていませんでしたが、入塾してみたいと思いました。
関西で何かイベントをやられないかな。

今回は、いったんここまで。
続きはXP祭り2014参加報告（２）で書きたいと思います。

京アジャ アジャイル１日体験ワークショップに参加してきました

アジャイル 勉強会
※本記事はNCデザイン&コンサルティング㈱のブログに私が記載したものを転載・修正したものです。

8/9(土)に京アジャ主催のアジャイル１日体験ワークショップに参加してきたのでその報告をしたいと思います。

イベント紹介

京アジャとは

京都アジャイル勉強会の略称で、京都で活動するアジャイルコミュニティです。 京都にアジャイルを根付かせ、IT開発をもっと楽しくできることを目標に、勉強会を行なっておられます。

アジャイル１日体験ワークショップとは

makedoという工作ツールを使ったモノづくりを通じ て、一日かけてアジャイル開発のプロセスを体験するイベント http://connpass.com/event/7562/ 私は、京アジャの前身となったアジャイルサムライ京都道場に参加しており、その時の縁でイベントのサポーターとしてお手伝いさせて頂いきました。 今回は、私はサポーターとして事前のスパイクへの参加と、本番のワークショップに参加しました。

イベント内容

宇宙資源基地作成という一貫したテーマを元に次のワークショップが行われました。

エレベーターピッチ作成のワークショップ

宇宙基地開発の予算取りのため、予算権限を持つ国の大臣にプロジェクトをPRするというシチュエーションでエレベーターピッチを作成しました。 エレベーターピッチ

ユーザーストーリー作成のワークショップ

宇宙基地開発に必要なユーザーストーリーを記述しました。 4つのストーリーはあらかじめ用意されている状態で、5つ目のストーリーを考えるという内容でした。 ユーザーストーリー

スプリント運営のワークショップ

makeDoを使って実際に宇宙基地を作成しました。 計画-デイリースクラム-振り返りというスプリントのイベントを実際に運営しました。 makedo

気づき

エレベーターピッチの背景を捉える

製品のコンセプトを顧客やオーナーに伝える時に、エレベーターピッチをそのまま読み上げてもあまり響かず、自分の言葉で表現できるくらいでないとダメだよね、という話がありました。エレベーターピッチをまとめておく事によって、製品やプロジェクトの目的やコンセプトを後から振り返る事ができます。しかし、エレベーターピッチの作成に関わっていない人がその短いその文章だけを見て、そのプロダクト作成の意図を全て掴む事は難しいと思います。もちろん、「我々は何故ここにいるのか」など他のインセプションデッキと合わせて読む事である程度の理解を深める事はできますが、やはりエレベータピッチの作成に携わっているか、その作成の背景を十分に共有されている必要があると思います。そういう意味では、後からチームに参加する人に「インセプションデッキを見といて！」だけでは不十分であり、デッキを使って背景まで含めた説明・共有ができていなければ、自己組織化は難しいと感じました。

ユーザーストーリーのNegotiableの重要性

良いユーザーストーリーには"INVEST"の特徴があるといいます。
  • I – Independent : 独立して優先順位がつけられる
  • N – Negotiable : 何をつくるかの案が調整可能である
  • V – Valuable : ビジネス価値のある
  • E – Estimable : 見積り可能である
  • S – Small : チームで扱いやすい手頃なサイズである
  • T – Testable : テストできる
しかし、Negotiableについては実際にプロダクトオーナーとの交渉を経験していないと重視する事が難しいと思います。私のワークショップのチームでは、価値を明確にし、具体的な機能性や実現方法にフォーカスしないようにユーザーストーリーを考える事でNegotiableを担保するストーリー作りを意識して行いました。さらに、このストーリーについて、実際にプロダクトオーナーと交渉が行えた事も良い経験だったと思います。また、Negotiableを意識する事で、必然的に受け入れ基準もシステム的・機能的なものではなく、価値を満たしているかを検証しやすい項目が洗い出せるようになるのではないかと感じました。

自然発生する役割分担の尊重

私が所属したチームは、自発的に作業を取りにいったり、アイデアを提案してくれるメンバーばかりでした。このような恵まれたチームの中で、うまく協調してチームの作業を行うためには、無理にリーダーシップをとって、作業分担をするよりも、メンバーの中から自然発生的にうまれる役割分担を尊重する事がうまく行く秘訣だなという事を体感する事ができました。もちろん、全体の協調性をコントロールする役割は必要だと思いますが、その役割すらも自然発生的にうまれ、チーム内の役割は固定されず、ケースバイケースで最適化されます。このような状態が、自己組織化として目指すべき状態なんだと言う事がよく分かりました。

参加しての感想

私は事前のスパイクから参加しており、いくつか大きな課題を抱えている状況を知っていたため、当日はどうなるかなと思っていましたが、蓋を明けてみると、とても完成度の高いイベントとなっていました。これは事前準備を行っていた事もありますが、昨年春に行った同イベントの経験とフィードバックがうまく活かされている事と、これまでの京アジャを通して、主催者である大友さんと前川さんのワークショップ運営の経験値がとても高くなっているからなのだろうなと思います。イベントの最後では、頭の使い過ぎでヘトヘトでしたが、とても有意義な時間を過ごせました。大友さん、前川さんありがとうございました。