Visual Studio 2013

[アーティクル]
06/15/2015

Visual Studio 2013 で Office 365 クラウドビジネスアプリを構築する

Heinrich Wendel
Jim Nakashima
Mike Morton

現代のビジネスアプリに関する要件、期待、および重要性は、これまでにないほど高まっています。最新のビジネスアプリでは、社内社外を問わず使用できるデータにアクセスし、会社全体の従業員どうしを結び付けて、機能豊富かつ興味深い方法でのコラボレーションを促進する必要があります。アプリ自体も、さまざまな画面サイズのスマートフォン、タブレット、ノート PC、デスクトップなど、複数種類のデバイスやフォームファクターで使用できる必要があります。

開発者には、こうしたアプリの主要要件を満たす一連のサービスを提供するプラットフォームが必要です。また、会社全体の既存の DevOps プロセスと統合しながら、これらのアプリを生産的に構築できるツールセットも必要になります。

この記事では、このような最新のビジネスアプリを構築するうえで、Visual Studio 2013 がどのように役立つかを説明します。求人情報と応募者を管理する人材採用アプリを作成しながら、Office 365 と Windows Azure プラットフォームをシームレスに拡張し、ID やソーシャルといった Office 365 サービスを使用する方法を紹介します。

また、構築、実行、テストから発行や継続的インテグレーションの使用に至るまでのクラウドビジネスアプリのライフサイクル全体で、生産性の確保に Visual Studio がどのように役立つかを説明します。

新しいプロジェクトを作成する

まず Visual Studio 2013 を起動し、[ファイル] メニューの [新規作成] をポイントして [プロジェクト] をクリックします。Visual Basic と Visual C# のどちらの言語でも、[Office/SharePoint] ノード、[アプリ] ノードを順に展開すると、クラウドビジネスアプリテンプレートが表示されます (図 1参照)。この分類は、中間層で使用する言語に基づいています (クライアントは HTML と JavaScript です)。

図 1 Visual Studio 2013 における新しいクラウドビジネスアプリプロジェクトの作成

クラウドビジネスアプリは、4 つのプロジェクトで構成されています。

Server プロジェクト: テーブルの追加とデータソースへの接続に使用する基本的な ASP.NET プロジェクト。
標準的な SharePoint 用アプリプロジェクト: Office 365 への接続を提供するプロジェクト。
HTMLClient プロジェクト: アプリの UI (画面) を定義する JavaScript プロジェクト。
クラウドビジネスアプリプロジェクト: すべてのプロジェクトを 1 つにまとめるプロジェクト。図 2は、Visual Studio プロジェクトの構造を示しています。

図 2 クラウドビジネスアプリの構造

各プロジェクトの使用方法については、これから説明します。

データモデルを定義する

データは、あらゆるビジネスアプリの中心です。クラウドビジネスアプリを使用すると、さまざまな方法でこのデータを操作できます。まずは、テーブルデザイナーを使って新しいデータモデルを定義しましょう。このデータモデルは、後で Windows Azure SQL データベースに配置します。テーブルデザイナーを使って、Candidate エンティティを定義します。図 3は、データモデルの詳細を示しています。エンティティはプロパティで構成され、プロパティはシンプルなデータ型 (String や Integer など) またはビジネス型 (URL、Email Address、Person など) になります。Visual Studio ツールとランタイムには、具体的な検証ロジックと独自の外観が組み込まれています。

図 3 Candidate エンティティの詳細

プロパティ名	データ型
Name	String
Phone	Phone Number
Email	Email Address
ReferredBy	Person
InterviewDate	Date (必須ではない)

クラウドビジネスアプリは、SharePoint 用アプリです。このアプリでは、アプリを実行する Office 365 テナントのデータにアクセスできます。インフォメーションワーカーは日常的に SharePoint を使って、コラボレーション環境でデータを作成、管理、および共有します。今回のシナリオでは、募集中の求人情報を追跡するために SharePoint リストを使用していると想定しています。図 4は、入力されたデータが含まれたこのリストを示しています。

図 4 SharePoint での求人情報リスト

Data Sources フォルダーのコンテキストメニューで [データソースの追加] をクリックして、このリストにデータをアタッチします。ウィザードの 1 ページ目で [SharePoint] を選択し、開発を行う SharePoint サイトの URL を入力します (開発用の SharePoint サイトをお持ちでない場合は、dev.office.comで作成できます。MSDN サブスクリプション会員の方は、1 年間無料で利用できます)。次のページには、指定した SharePoint サイトで使用できるすべてのリストとドキュメントが表示されます。求人情報リストを選択し、ダイアログボックスを閉じてリストをインポートします。

2 つのデータソース (今回は SharePoint と SQL) のデータを関連付け、その両方で機能するビジネスロジックを記述することは、クラウドビジネスアプリの構築で利用できる最も強力な機能の 1 つです。テーブルデザイナーを使用して、応募者と求人情報リストとの間にリレーションシップを設定しましょう。テーブルデザイナーの [リレーションシップの追加] アクションを使用して、一対多のリレーションシップを作成します。ここでは、各応募者が 1 つの求人情報にのみ応募できるように指定します。図 5に、リレーションシップの正確な構成を示します。これでデータモデルを定義できたので、今度はアプリの UI 作成に目を向けましょう。

図 5 応募者と求人情報の間の一対多のリレーションシップ

UI を設計する

現在では、動作するだけの UI を作成しても十分とは言えません。ユーザーは、スマートフォンやタブレットから従来のデスクトップに至るまで、幅広いデバイスに対応するアプリを求めています。また、タッチでも、大量のデータ入力用にキーボードでも使用できるアプリも期待されています。アプリには、全社で一貫した外観と、明確なブランド化が必要です。クラウドビジネスアプリには、こうした重要な課題を簡単に達成できるテンプレート、レイアウト、およびコントロールが用意されています。

3 つの画面を作成して、画面間のナビゲーションフローを定義します。1 つ目の画面には、データベース内のすべての応募者を参照できるタイルリストを表示します。この画面から、2 つ目の画面に移動して新しい応募者を追加したり、3 つ目の画面で既存の応募者に関する詳細情報を確認したりすることができます。

HTMLClient プロジェクトで、Screens フォルダーのコンテキストメニューで [画面の追加] をクリックし、1 つ目の画面を追加します。画面テンプレートのダイアログボックスに、作業の出発点として使用できる 3 つのテンプレートが表示されます。1 つ目の画面には、"データの参照画面" テンプレートを使用します。[画面データ] ボックスで Candidate エンティティを選択して、ダイアログボックスを閉じます。

図 6 に示す画面デザイナーは、2 つの部分で構成されています。左側のサイドパネルには画面にバインドされるデータが表示され、メイン領域には画面が階層表示されています。

図 6 [Browse Candidates] 画面が表示された画面デザイナー

画面デザイナーで [リスト] を選択し、プロパティウィンドウで項目のタップアクションを設定します。メソッドは、JavaScript コードで独自に作成しなくても、一般的に使用される定義済みの一連のメソッドから選択できます。[Candidates.viewSelected] を選択し、ウィザードに従って詳細画面を作成します。最初の画面に戻り、[コマンドバー] を選択して新しいボタンを追加します。今度は Candidates.addAndEditNew メソッドを使用して、"詳細画面の追加/編集" 画面を作成します。

これで基本の画面と画面間のナビゲーションを定義したので、次はこれらの画面の外観を調整します。エンティティのリストをレンダリングする手段には、標準的なリスト、テーブル形式での表示、およびタイルリストの 3 つがあります。リストは複雑なレイアウトに適しており、テーブル形式での表示はデータ中心のタスクに最適化されています。

今回はタイルリストを使用します。タイルリストでは、より効率的に画面領域を使用して、それぞれの画面サイズに最適な大きさで表示できます。タイルリストノードから、Name、Phone、および Email を除くすべての子項目を削除します。最後に、プロパティシートで [アイコン] プロパティを変更して、表示される一連のアイコンのうちコマンドに適した外観を選択します。

アプリを実行する

次は、実行中のアプリを見てみましょう。Visual Studio で F5キーを押して、アプリをブラウザーで実行します。SharePoint 開発者サイトにアプリを初めて配置するときは、一連のアクセス許可を承認するように求めるダイアログボックスが表示されます。2 回目以降は、ソリューション内の SharePoint プロジェクトを変更しない限り、F5キーを押してもこの手順はスキップされます。

アプリは、UI がクライアント側のコードで完全にレンダリングされる、単一ページアプリ (SPA) のアーキテクチャを使用して読み込まれます。サーバーとの通信は、非同期呼び出しを使用して行うので、高速かつ滑らかなエクスペリエンスが実現します。このような処理を確認できる例としては、ホーム画面に表示される応募者のリストが挙げられます。このリストでは、インクリメント方式のスクロールを使用しています。リストの最後に達すると項目の次のセットがバックグラウンドで動的に読み込まれるため、ユーザー操作がブロックされることはありません。

すべてのレイアウトは、レスポンシブデザイン手法を使用して、さまざまなフォームファクターに適切に適合します。スマートフォンやタブレットにおけるアプリの外観は、ブラウザーウィンドウのサイズを変更すると簡単に確認できます (図 7参照)。どの機能もタッチ向けに最適化されていますが、デスクトップでもキーボードやマウスを使用して同じように操作できます。

図 7 モバイルデバイスで実行しているクラウドビジネスアプリの 3 つの画面

今度は、新しい応募者を追加しましょう。表示されるダイアログボックスには、想定されている一連の入力フィールドと、アタッチされている SharePoint リストからユーザーが役職を選択できるピッカーが表示されます。会社のユーザーディレクトリ (Active Directory など) に基づいて候補が表示されるオートコンプリートボックスを使用して、ReferredBy 値を選択します。

詳細画面ではさらなる Office 365 の統合機能として、各従業員のプレゼンス情報を確認できます。Lync の連絡先カードで詳細情報を確認でき、IM 会話の開始、電子メールの送信、会議のスケジュール設定など、豊富な操作を実行できます。

エンティティの作成や最終変更を行った時刻とそのユーザーを追跡するフィールドは、自動的に追加されます。このため、コードを記述しなくても、一般的な監査要件を満たすことができます。これらの要件が実際のシナリオに不要な場合は、アプリを停止せずに画面デザイナーに切り替え、フィールドを削除して画面を保存できます。ブラウザーを更新すると (Visual Studio でアプリを再起動する必要はありません)、変更がその場でアプリに反映されます。

ビジネスロジックを追加する

ここまでに説明した生産的な開発エクスペリエンスのおかげで、開発者はアプリ固有の価値、つまりビジネスロジックに労力を集中できます。応募者の面接スケジュールを設定できるユーザーを、人事部門の従業員だけに限る必要があるとしましょう。通常、このような組織情報は、Active Directory に格納されます。

Office 365 では、User Profile Service を通じて開発者が Active Directory を参照できます。厳密に型指定された API には、ユーザーが所属する部門など、最もよく使用されるプロパティが用意されています。SharePoint 管理センターを使用すると、会社固有のカスタムプロパティを User Profile Service に追加できます。また、直接 User Profile Service と通信する標準的な SharePoint API を使用して、コードでこれらのカスタムプロパティを取得することもできます。

ビジネスロジックは、このソリューションの Server プロジェクトが表す中間層に記述します。テーブルデザイナーの [コードの記述] ドロップダウン矢印をクリックすると、アプリのデータパイプラインへのエントリポイントが多数表示されます。今回は検証イベントを処理し、Application オブジェクトを使用して、現在ログオンしているユーザーの部門を問い合わせます。

if (entity.InterviewDate !=
   null && Application.Current.User.Department != "HR") {
   results.AddPropertyError("Only HR can schedule interviews",
   entity.Details.Properties.InterviewDate);
 }

アプリを再び起動するか、アプリを停止していない場合はブラウザーを更新します。今度は、人事部門のメンバーでないため、応募者の面接日を設定しようとするとエラーが発生します。このロジックは中間層で実行されるので、クライアントからサービスへの接続方法に関係なく、検証規則が実行されます。

エンタープライズソーシャルを統合する

コミュニケーションとコラボレーションにはソーシャルネットワークを使用します。ユーザーは、最新のビジネスアプリがこうしたソーシャルネットワークに統合されていることを期待しています。クラウドビジネスアプリでは、SharePoint Newsfeed 機能を使用して、わずか数回のクリックでソーシャル統合を実現できます。この最初のバージョンでは、Yammer ではなく SharePoint Newsfeed を使用するように SharePoint を構成する必要があります。

デザイン時のオプション: テーブルデザイナーで Candidate エンティティを開き、プロパティウィンドウを表示します。[ソーシャル] セクションには、エンティティの作成時および更新時にニュースフィードへのポストを生成するオプションが 2 つ用意されています。この両方のオプションを有効にします。[ポストトリガーの選択] リンクを使用すると、ソーシャル更新をトリガーするプロパティを制御できます。ここでは [InterviewDate] ポストトリガーだけを選択します (図 8参照)。概要プロパティでは、エンティティに関するデータのうちどれをポストに表示するか選択できます。

図 8 ソーシャルプロパティとポストトリガーのダイアログボックス

実行時のニュースフィード: アプリを実行して、構成したソーシャル統合を確認します。右上隅に [ニュースフィード] リンクと [フォロー] リンクが表示されます。[ニュースフィード] リンクをクリックすると、新しいウィンドウが開き、アプリのアクティビティを示すページが表示されます。これは、アプリ内部のソーシャルフィードと考えることができます。[ニュースフィード] ページには、新しく作成された各応募者のエントリと、面接日が変更された各応募者のエントリが表示されます。ポストをクリックすると、その応募者の詳細画面に直接移動できます。また、ユーザーは新しい会話を始めたり、任意のポストに対して "いいね" や返信で応答したりすることができます。新しい応募者を追加するか、既存の応募者の面接日を変更すると、[ニュースフィード] ページに生成されているこのアクティビティの例を確認できます (図 9 参照)。

図 9 クラウドビジネスアプリの [ニュースフィード] ページ

[ニュースフィード] オプションは、アプリ内からアクティビティを確認する場合に便利ですが、もっと簡単な方法で、定期的にアプリのアクティビティを追跡できます。ホーム画面の [フォロー] リンクをクリックすると、同じソーシャルポストや会話を、ユーザー個人のニュースフィードに投稿できます。このため、ユーザーは、このアプリや他のクラウドビジネスアプリ、ユーザー、またはドキュメントの状況を 1 か所で把握できます。

発行する

アプリをローカルで構築してテストしたら、社内の他の従業員に向けてアプリを配置します。ソリューションエクスプローラーで、クラウドビジネスアプリプロジェクトのコンテキストメニューにある [発行] をクリックします。発行ウィザードのダイアログボックスには、SharePoint のホスト方法、アプリサービスのホスト、データ接続、SharePoint 認証など、クラウドビジネスアプリを発行する際に使用できるオプションが表示されます。

アプリサービスをホストする Windows Azure Web サイトと、データベースをホストする Windows Azure SQL データベースを使用して、クラウドビジネスアプリを Office 365 に発行する最適な方法を紹介しましょう。

アプリは、Office ストアまたは会社のアプリカタログに発行できます。一般公開するアプリを作成することが目標の場合は、Office ストアが適しています。社内での内部使用だけを予定しているアプリの場合は、アプリカタログを使用します。アプリカタログを使用すると、アプリを自動的に多数のサイトに発行できます。このため、エンドユーザーや管理部門がアプリを簡単に入手できるようになります。ユーザーはさまざまなサイトからアプリにアクセスできますが、実際に存在するアプリのインスタンスは 1 つだけです。

SharePoint のホスト方法: [プロバイダー向けのホスト型] オプションを選択すると、アプリのさまざまな部分の配置方法を、より細かく制御できます。また、パフォーマンスについてより詳しく把握でき、さまざまな層の拡張が容易になって、アプリのデータの有効期間を完全に制御できます。

アプリサービスのホスト: 次に、Windows Azure と IIS サーバーのどちらでアプリサービスをホストするかを決定します。Windows Azure の場合、ホスト環境を最も簡単かつ短時間で構築できます。コンピューターのセットアップや IIS の構成も必要ありません。Windows Azure によって自動的に行われます。

次に、使用する具体的な Windows Azure サブスクリプションを選択します。Windows Azure アカウントにサインインしている場合は、使用するサブスクリプションを選択します。サインインしていない場合は、サインインして、使用可能なサブスクリプションを確認する必要があります。

[Service Type] (サービスの種類) タブ (図 10 参照) には、Windows Azure Web サイトまたはクラウドサービスを使用するオプションが表示されます。ここでは [Web Site] (Web サイト) オプションを選択します。このオプションは、アプリをすぐに発行でき、ホストのコストが低く、アプリの人気が上昇した場合に簡単に拡張できるため、クラウドビジネスアプリには最適です。Windows Azure の [Web Site] (Web サイト) オプションでも、SQL データベース、キャッシュ、BLOB ストレージ、サービスバスといったその他の Windows Azure サービスにアクセスできます。

図 10 発行ウィザードのダイアログボックス

次に、使用する具体的な Windows Azure Web サイトを選択します。Windows Azure Web サイトが表示されない場合、または Windows Azure Web サイトを新しく作成する場合は、リンクを使用して Windows Azure ポータルにアクセスします。最後に、通信が安全に暗号化されるように HTTPS オプションを選択します。

データ接続: アプリで使用するデータベース接続を構成します。既に SQL データベースを Web サイトにリンクしている場合は、適切な接続文字列が入力されます。リンクしていない場合は、Windows Azure ドキュメント (bit.ly/151m3GM) の記事「Web サイトの構成方法」に示されている適切な手順に従って、リンクされたリソースを新しく作成します。既存の SQL データベースの接続文字列も使用できます。[Attached Data Sources] (アタッチされたデータソース) タブで、適切なエンドポイントが接続先に指定されていることを確認します (多くの場合、アプリを運用環境に発行するかその他の環境に発行するかによって、接続エンドポイントが異なります)。

SharePoint 認証: 最後に、使用する SharePoint 認証の種類を構成する必要があります。この作業は、Web サーバー (この場合は Windows Azure) でホストしているアプリサービスと SharePoint との間で通信できるようにするために必要です。ここでは Office 365 を使用しているので、[SharePoint 認証] タブでは [クライアントシークレットを使用する] オプションを選択する必要があります。この種類の認証を使用するには、クライアント ID とクライアントシークレットを取得する必要があります。これらの情報は、基本的にはアプリに使用するユーザー ID とパスワードです。アプリ認証のオープン標準である Open Authorization (OAuth) を使用するには、クライアント ID とクライアントシークレットが必要です。

今回は、アプリのユーザーを社内の従業員のみに限定するので、アプリをアプリカタログに発行します。したがって、クライアント ID とクライアントシークレットを取得するには、次の手順を実行します。

アプリを配置する Office 365 SharePoint サイトにサインインし、http:///_layouts/15/appregnew.aspx にアクセスします (図 11 に AppRegNew.aspx ページを示します)。
クライアント ID とクライアントシークレットの、両方の [生成] ボタンをクリックします。
[タイトル] ボックスにアプリの名前を入力し、[アプリドメイン] ボックスに Windows Azure Web サイトのドメインを入力します。
[リダイレクト先の URI] ボックスを空欄のままにして [作成] ボタンをクリックします。

図 11 AppRegNew.aspx ページ

Visual Studio の発行ウィザードのダイアログボックスに戻り、AppRegNew.aspx 確認ページからクライアント ID とクライアントシークレットをコピーします。次に表示されるタブには、Windows Azure Web サイトの URL が自動的に入力されています。

クラウドビジネスアプリの発行: この時点で、[概要] タブには、先ほど構成したオプションの概要が表示されています。[発行] ボタンをクリックすると、複数のエンドポイントにクラウドビジネスアプリが発行されます。配置が完了すると、エクスプローラーが開いて .app ファイルが表示されます。これは、アプリカタログにアップロードする必要がある SharePoint アプリパッケージです。詳細については、Microsoft Office サポートの記事 (office.microsoft.com/ja-jp/sharepoint-help/use-the-app-catalog-to-make-custom-business-apps-available-for-your-sharepoint-online-environment-HA102772362.aspx#_Toc347303049) で手順を参照してください。

この時点で、アプリがアプリカタログに発行され、1 つ以上のサイトにインストールできるようになります。

継続的インテグレーション

継続的インテグレーションでは、開発プロセス全体を通じてアプリを自動的に発行することで、開発者の時間を節約できます。複数の開発者が絶えず変更を加えるチーム環境では、継続的インテグレーションを使用すると、自動的で一貫性のある方法でアプリをコンパイル、パッケージ化、および発行できます。

Team Foundation Server: クラウドビジネスアプリで継続的インテグレーションを利用するには、オンプレミスにインストールされた Visual Studio Team Foundation Server (TFS) 2013 またはクラウドの TFS、つまり Team Foundation Service (tfs.visualstudio.com、英語) を使用する必要があります。オンプレミスの TFS 2013 を使用する場合は、必ず TFS のビルドプロセステンプレートをダウンロードし、チームプロジェクト用にインストールしてください。現在、新しいプロセステンプレートでサポートされているのは、Office 365 でホストされている SharePoint サイトにクラウドビジネスアプリの SharePoint 部分を配置することだけです。オンプレミスの SharePoint サイトは、まだサポートされていません。

ビルド定義の作成: ビルド定義は継続的インテグレーションプロセスを表し、ビルドプロセステンプレート (ワークフローを表す .xaml ファイル) と、環境に固有の構成データで構成されています。Visual Studio で新しいビルド定義を作成するには、必ず TFS コンピューターに接続し、ソースコード管理にアプリをチェックインしてください。チームエクスプローラーの [ビルド] パネルで、[新しいビルド定義] を選択します。

ここからは、ビルド定義の主要な機能を示し、クラウドビジネスアプリ固有の新しいパラメーターについて詳しく説明します (新しいビルド定義を作成するためにクリックすると、左側に 6 つのタブが表示されます)。

全般: ビルド定義の名前、説明、およびキューの処理規則を指定します。
トリガー: ビルド定義を開始するタイミングを指定します。このタブは、ビルド定義が意図したとおりに動作することを確認するまで、[手動] に設定しておくことをお勧めします。
ソース設定: ビルドの対象を指定します。
ビルドの既定値: ビルド定義を処理するビルドコントローラーと、出力の配置先を指定します。
プロセス: 使用するビルドプロセステンプレートと、ワークフローに渡すパラメーターを選択します。
アイテム保持ポリシー: ビルド出力を保持する期間を指定します。

クラウドビジネスアプリのビルド定義に使用する 3 つの新しいパラメーターは、[プロセス] タブにあります。まず、クラウドビジネスアプリ用に作成されたビルドプロセステンプレートを選択します。[詳細の表示] をクリックして、TfvcContinuousDeploymentTemplate.12.xaml テンプレートと GitContinuousDeploymentTemplate.12.xaml テンプレートのいずれかを選択します。[Deployment Settings] (配置設定) セクションを展開し、以下の新しいパラメーターを構成します (図 12 参照)。

Path to Deployment Settings (配置設定のパス): このパラメーターには、クラウドビジネスアプリに関する発行情報 (組み込みデータベースのデータベース接続文字列、アタッチされているすべてのデータソースのエンドポイントなど) が格納された XML ファイルのパスを指定します。
SharePoint Deployment Environment Name (SharePoint 配置環境名): このパラメーターには、アプリを発行する SharePoint サーバーに接続するための SharePoint URL、ユーザー名、およびパスワードを指定します。
Windows Azure Deployment Environment Name (Windows Azure 配置環境名): このパラメーターには、Windows Azure サブスクリプションに接続するために必要な情報を指定します。

図 12 [ビルド定義] ダイアログボックス

ビルド定義のキューへの配置: 継続的インテグレーションを利用するために必要な構成データを用意したので、ビルドを開始しましょう。[ビルド] パネルで作成したビルド定義を見つけて、コンテキストメニューの [新しいビルドをキューに配置] をクリックします。表示されるダイアログボックスの設定をそのまま使用して、ビルドをキューに配置します。ビルドは、ビルドコントローラーによって、その空き時間に処理されます。

ビルドエクスプローラーでビルドを確認するには、[ビルド] パネルの [操作] ボックスで [マイビルドの表示] を選択します。ビルドエクスプローラーには、2 つのタブがあります。片方のタブには、キューに登録されたビルド、実行中のビルド、および最近完了したビルドが表示され、もう片方のタブには、以前完了したビルドが表示されます。ビルドエクスプローラーで任意のビルドを選択すると、そのビルドのログを確認できます (ビルドが失敗した場合は、追加の診断情報も表示されます)。

今すぐ始めましょう

この記事では、アプリをすぐに運用できる、生産性の高いデータと画面の定義方法を紹介しました。アプリは、SharePoint と調和した本格的な外観の UI を備え、一連の Office 365 サービス (Lync のプレゼンスと連絡先カード、個人ピッキング、ソーシャルなど) と統合されています。また、この記事では Microsoft .NET Framework を使用してアプリをカスタマイズする方法と、(用意ができたら) 開発プロセスの一環としてアプリを発行したり継続的インテグレーションを構成したりする方法についても説明しました。

今すぐクラウドビジネスアプリの構築を始めましょう。必要なものは、Visual Studio 2013 と、サンドボックス開発環境として使用する Office 365 Developer のサブスクリプションだけです。MSDN サブスクリプション会員の方は、1 回限りで 12 か月間有効なシングルユーザー Office 365 Developer のサブスクリプションをご利用いただけます。詳細については、bit.ly/1fvYeAT(英語) を参照してください。

Mike Morton は、マイクロソフトの Information Technology グループと製品グループの両方に、開発者やアーキテクトとして長年携わってきました。現在は、Microsoft Office 用アプリ、SharePoint 用アプリ、および新しいクラウドビジネスアプリの開発ツールを作成する Visual Studio チームで、プログラムマネージャーを務めています。最近では、全面的にブラウザー内で動作する "Napa" ツールを構築しました。

Jim Nakashima は、Visual Studio のクラウドプラットフォームツールチームの主任 PM であり、主に Microsoft Office と SharePoint に関する優れたエンドツーエンドの開発エクスペリエンスの構築に取り組んでいます。現在の担当に就く前は、何年もの間 Windows Azure の仕事をしてきました。この経験からクラウドサービスや開発者サービスに抱いた関心を、現在では Visual Studio に活かしています。

Heinrich Wendel は、マイクロソフトで Visual Studio チームのプログラムマネージャーとして、クラウドビジネスアプリツールを構築しています。製品グループに参加する以前は、SharePoint プラットフォームを利用するユーザー向けにビジネスソリューションを設計するコンサルタントを務めていました。Wendel は、最新の UX に情熱を注いでおり、開発者とエンドユーザーが得るメリットを近付けるために尽力しています。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Joe Binder と Brian Moore に心より感謝いたします。

Joe Binder は、Windows Azure、Office 365、およびビジネスアプリ開発用の Visual Studio のツールに従事する主席プログラムマネージャーです。彼は Visual Studio LightSwitch チームの創設メンバーの 1 人で、チーム設立当初から開発と方向性の形成に携わってきました。Binderは、ビジネスアプリと生産性の高いアプリ開発における優れたユーザーエクスペリエンスの構築に熱心に取り組んでいます。マイクロソフトに入社する前は、ロチェスター工科大学でコンピューターサイエンスを学んでいました。

Brian Moore はプログラムマネージャーとして、現在は Office 365 と Windows Azure を使用したクラウドビジネスアプリを Visual Studio 製品ラインに統合することに取り組んでいます。Visual Studio で全バージョンの LightSwitch プロジェクトに従事した経験を持ち、この 20 年間では、マイクロソフトのすべての主要部門 (国外の部門や国内のキャンパスを含む) に携わっています。VB 開発者としての性分から、現代の基幹業務アプリの簡略化に情熱を傾けています。

次の方法で共有