Delivery、以下DAD)における時間軸の捉え方としてのフェーズという概念と、その前段階で行う「プロジェクト・オリエンテーション(DADで定義されているわけではありませんが)」に言及しました。記事公開後に、プロジェクト・オリエンテーションとアジャイル技法の説明の違いについて質問を受けたので、少しだけ補足しておきます。当然のことですが、一般的なアジャイルの説明はアジャイルそのものを理解してもらうことを主眼にします。「アジャイル・マニフェストをひも解きながら、アジャイルの魂を説明」したり、順を追って作業の流れを説明したりします。直感的にイメージしてもらうために、ウォーターフォール型プロセス(の一般的な形)と比較する形で説明することもあるでしょう。「うちは、4週間ごとにリリースしないんだけど」みたいな......どんなビジネスモデルなのか、またどんな課題が存在するのかという事情は、プロジェクトごとに異なります。その一方でアジャイル開発そのものも、さまざまなテクニックを取り入れて発展し続けています。その結果、個別の事情に合わせてさまざまな期待値が持たれることになります。目の前のプロジェクトが基幹系システムとの連携を前提としている、つまり統合リスクが高いようなケースでは、「小規模な統合を頻繁に行うことで、技術的なリスクに事前に対処できる」ことのほうが、「ユーザからの頻繁なフィードバックを得る」ことよりも重要とみなされるでしょう。一般的なアジャイルの説明が「アジャイルで実現できること」をカタログ的に見せるものだとすると、オリエンテーションは「今回のケースではこんなことが期待できそうだ」という点に絞ることで、アジャイルに対して持っているかもしれない誤解を解き、期待値を整理するのが目的です。残念ながら今でも、アジャイル開発に対して「早くて安い丸投げ開発手法」というイメージを持たれている方にはよくお会いします。プロジェクトに対してそれ相応の権限を持った管理職の皆さんに多かったりするので、そういう方々が抱きがちな過剰な期待や誤解を早めに解いておこうということです。Manager(以下、AGM)に設定しながら、方向付けフェーズに話を進めていきましょう。Managerに初期状態を作ろうAGMの評価版はインストールしていただいたでしょうか?ここでは、実際のAGM上にプロジェクトの情報をいくつか設定していきましょう。基本的な流れは次のようになります。手順1作業用領域(AGMではワークスペースと呼びます)にユーザを登録し、利用できるようにします手順2ワークスペースに開発対象となるアプリケーションを登録します手順3リリースを設定します手順4チームを設定しますツールとしてのAGMの概念や設定の手順については、弊社のブログで解説しています。上記の手順1〜3の詳細については、こちらをご覧ください。設定する内容としては、次のモノとしましょう。ワークスペース評価版には、デフォルトで[標準設定]というワークスペースが用意されていると思います。それを使ってもいいですし、追加してお好きな名前にしていただいても構いません。サイトユーザの一覧のところで、各ユーザに利用できるワークスペースを関連付ける必要がありますので、関連付けを忘れないようにしてください。アプリケーションお使いになるワークスペースに、アプリケーションを登録しましょう。言っても、[名前]と[説明文]だけでよいのですが。ちなみにこの連載では、インターネット上のショッピングモールをイメージしたアプリケーションをサンプルとして考えます。リリース:これは次のように設定してみましょう。開始日:本稿を読みつつ、皆さんが設定された日を開始日にしておきましょう。スプリント期間を決めて保存すると、自動的にスプリントを作成してくれます。開始日によっては中途半端な期間のスプリントができますが、後から調整が利くのでとりあえず先に進めましょう。チームチーム名はなんでもいいですが、アジャイルの特性を活かすために、数人で1チームにしましょう。ちなみに筆者の設定例は図1(アプリケーション)、図2(スプリント)の通りです。図1:アプリケーションの設定例(クリックで拡大)図2:スプリントの設定例(クリックで拡大)設定例を通して考えてみる一般的なアジャイルと「エンタープライズ・アジャイル」では、いくつか前提が異なります。例を挙げてみましょう。ゼロから作るよりも、既存システムへの改修のほうが多い独立した単一のアプリケーションよりも、バックエンドのシステムや、関連する他社のシステムとの連携が前提となっていることが少なくないしかも関連する他のシステム側は、アジャイルの時間軸で作られているとは限らない個々のプロジェクトの効率だけなく、組織的な効率化の観点で、共通化されたプラットフォームの利用や、開発標準への準拠が求められるXP(エクストリーム・プログラミング)を起点とするアジャイラ−の中には、アーキテクチャの取り扱いについて明言しなかったり、「作っているうちに『見えてくる』」というような話をしたりする向きもあります。Beck並の)がある開発者の集団であれば、それも可能かもしれません。先ほど挙げた前提は、アーキテクチャを早い段階で検討しないと開発が進められないという現実を表しています。なると、スケジュールを考える上でのポイントは、以下の点を考慮することです。開発のサイクル(リリース間隔、スプリント期間)が合うか?共通化されたプラットフォームに改修が必要か?図1は、プロジェクトのサブシステム構造を考慮した例です。「ショップサービス」は個々の店舗の機能性を実現しているのに対して、「Webモールサービス」は個々のショップに依存しないモール全体としての機能性を実現します。チームは、これに合わせて各サービスにマッピングする形で編成します。いわゆる「フィーチャーチーム」です。それに対してカード決済等の機能は、Webモール以外のシステムでも利用される「共通のサービス」と位置付けて、「共通サービス」として登録しています。こちらは、いわゆる「コンポーネントベースのチーム」編成です。エンタープライズアプリの場合は、このようなフィーチャーベースとコンポーネントベースの混成になることがめずらしくありません。このアプリケーション構成を踏まえたスケジュールのイメージが図2です。※AGMでリリースを定義すると、デフォルトでは「スプリント」が自動的に定義されますが、DADの仕様に準拠して、あえて「イテレーション」に変えました(個人的な趣味として......)。前回、DADでは「フェーズ」という概念が導入されていることを説明しました。DADの初期では、方向付けの期間については4週間程度を基本とし、個々のプロジェクト事情を考慮して調整するとあります。この4週間で順に以下の作業を行います。(2〜3時間)レビュー、ビジョンの合意この時期に方向性を決めるビジョン(開発構想と呼ばれます)を合意し、数ページの文書としてアウトプットします。詳細は、本稿の後半で取り上げます。すべてのチームが同じサイクル(リリースやスプリント)で開発している場合は、「頻繁に統合」することに無理はありません。現実にはウォーターフォール型で開発しているチームが混在していたり、共通プラットフォームも並行して開発改修が進んでいたりする場合があります。その場合には、以下の2点をスケジュール上意識する必要があります。各々が並行して開発を進める時期それらを統合するタイミング上記の例では、そのために「安定化」のスプリントを入れています。テクニカル・コンサルタントを務める。誤解の多い”ちょっと新し目の技術”を、きちんと咀嚼しお伝えして何ぼのこの世界、「アジャイルは品質が...」という若干の誤解に基づく不安にも、きちんと丁寧に答えをだしていこうと思う毎日。ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。VeloCloudが選ばれる理由SD-WANとはなにか。Linuxエンジニア育成への思いF5とNGINXの組み合わせで、サービス公開をよりセキュアに。ITがお届けするポッドキャストです。