カテゴリー別アーカイブ: DAD解説

軽量マイルストーンによるアジャイルプロジェクトリスク軽減

DADは、プロジェクト/リリースの進捗状況と健康状態を測定するために、ライフサイクルにいくつかのマイルストーンを組み込んでいる。

DADにはなぜマイルストーンがあるのか?

主流のアジャイル手法には、ガバナンスの考え方はほとんどなく、アジャイルにはマイルストーンは不要であると考える人は多い。スクラムは、最も価値の高い作業をバックログの一番上に位置付ける。そして各スプリント(反復)の終了時に、バックログ内の次の作業が十分な価値を生み出すかどうかによって、次のスプリントに予算をつけるかどうかが決まる。価値がないとみなされると、プロジェクトは終了する。基本的にこの戦略は理にかなっているが、ガバナンスの面で、以下のような欠陥がある:

  • 十分ではない
    プロジェクトへの予算割り当てをやめるタイミングで判断する以外に、はるかに効果的なガバナンスがあるのではないか。例えば、プロジェクトはどのように始まったのだろうか?
  • 現実的ではない
    実際問題、ほとんどの組織では、スプリントごとに予算配分の意思決定を行うわけではなく、複数の反復で構成されるリリース単位で判断をすることのほうが多い。
  • 効果的なマイルストーン
    スクラムはマイルストーンを持たないと主張しているが、本番移行するのに十分な機能があるかどうかを検討したり、今後の戦略を決定したりすることは、暗黙的なマイルストーンである。DADは、マイルストーンを効果的に適用するための指針を明示している。

アジャイルガバナンスはなぜ必要か?

多くの人が思い込んでいるのとは違って、アジャイル・イニシアチブの中で、ガバナンスは不要にはならない。スポンサーやその他の利害関係者には、彼らの投資に対する現在の状況を定期的に報告するべきである。彼らは以下のような質問への答えを期待している:

  • 投資から何が得られ、それにはどんな価値があるのか?
  • 最初の予算要求に沿って提供されているものは何か?
  • 未解決のリスクの状況は? そのリスクを緩和するために何が行われているか?
  • 現在のリリース予定は、元の予測と一致しているか?
  • 本番リリースのために十分な機能はいつできるか?
  • すべての利害関係者がリリース準備できているか?
  • プロジェクトはいつ完了するか?

「それはアジャイルじゃない」という主張は、上のような質問に答えないことで、アジャイルが時に無規律とみなされるゆえんである。事実、このような主張は、アジャイルがなぜ効果を発揮しないかという言い訳のひとつとして、よく利用される。幸いなことに、DADにはこれらの質問に答えるための仕組みがあり、多くの組織ではアジャイルの適用を拡張し、DADのガイダンスを組み込んでいる。実際、アジャイル性を保ちつつ、プロジェクトを管理する方法を模索している人にとっては、DADは非常に魅力的である。

マイルストーン・レビューは非公式なものとすべき

DADの目標で推奨されている戦略に沿った形で「チームミッション達成」マイルストーンをレビューする時には、軽量な形式にするべきである。アジャイル基本ライフサイクルを使用する場合、それは通常、反復もしくはフェーズの終了と一致する。DADになぜフェーズがあるか疑問に思われる場合は、このブログの関連記事にその情報がある。

マイルストーンの日付は伝達する必要がある

DADプロジェクトの各マイルストーンの日付をカレンダーにして、それを利害関係者に提供し、その利害関係者が関心のあるマイルストーンのレビューにあたる反復レビューに参加する予定を組めるようにすることは、良い習慣としておすすめできる。マイルストーンの日付が変更される可能性はあるが、すべての利害関係者へのロードマップとして、プロジェクトポートフォリオ全体にまたがった目標マイルストーンを表示するのは、大変有用だ。

DADマイルストーン

利害関係者のビジョン
方向付けフェーズの目標は、最低限のしかし十分な時間をかけて(通常1〜4週間で)、今回のプロジェクトに意味があり、よって構築フェーズに進んでよいという、利害関係者の合意を得ることである。DADの方向付けの各目標に取り組むことで、初期スコープ、技術、スケジュール、予算、リスクといった従来のプロジェクト情報を、できるだけ軽量な形でデリバリーチームが得ることになる。この情報は、「共通のビジョンを作る」ゴールに記述されているビジョン・ステートメントとして整理され、利害関係者に提示される。ビジョンの形式やレビューの公式度は、状況によって変わりうる。典型的なやり方は、方向付けフェーズの終了時に主要な利害関係者で数枚のスライドをレビューし、プロジェクトの意義とデリバリー手法に関して全員が同じものを確認していることを確実にすることである。

検証されたアーキテクチャー
プロジェクトのリスクを早期に軽減することは、よいプロジェクト管理手法のひとつである。「アーキテクチャーを早期に実証する目標が示すように、このためにはいくつかの戦略が採用できる。最も効果的なのは、技術的にリスクの高いビジネス要求を、エンド・ツー・エンドで動作するコードのスケルトンに実装してみることである。DADにおけるアーキテクチャーオーナーの重要な責務は、方向付けフェーズでリスクを特定することである。これらのリスクは、構築フェーズの1〜3回の反復の中で関連する機能を実装することで、軽減もしくは解消することが期待されている。この手法を適用した結果、初期の反復レビューやデモで、機能要件に加えて/もしくはその代わりに、非機能要件をサポートするソリューションの能力が示されることがある。このため、アーキテクチャーに関心を持つ利害関係者がこれらのマイルストーンレビューに参加する機会を与えられることが重要である。

プロジェクトの実行可能性
リリーススケジュールに含めるオプションのマイルストーンは、プロジェクトの実行可能性に関するものである。プロジェクトのあるタイミングで、利害関係者は、方向付けの終了時に合意したビジョンに沿ってプロジェクトが進行しているかどうかを確認するチェックポイントを要求することができる。これらのマイルストーンの予定を立てることによって、利害関係者は、プロジェクトの状況を評価し、必要があれば変更に合意するために、チームと一緒にいるべき重要な日程を認識することができる。ここで可能性がある変更としては、投資レベル、チーム構築、スコープ、リスクアセスメント、もしくはプロジェクト中止の可能性さえ含まれている。これらのマイルストーンは複数存在する可能性がある。もし利害関係者が変更に合意したら、ビジョンはそのタイミングで更新される。スクラムは暗黙的にこのマイルストーンを各スプリントの終了時に行う。DADはこれを明示的に選択し、その頻度を任意にしている。

十分な機能性
各反復の終了時に使用可能なソリューション(スクラムで「潜在的に出荷可能なインクリメント」と呼ばれるもの)をリリースすることを目標とする、ということもある一方、本番移行するのに十分な機能をチームが実装するために、構築フェーズの反復を複数回必要とする、というのもよくあることである。これは時として、最低限実行可能な製品(MVP)と呼ばれるが、これは技術的には正確ではない。古典的にMVPは最小限の本番移行可能な機能を示すものではなく、製品の実用性を確認するためのものである。このマイルストーンと対応するより正確な用語は、「最小限の機能セット」だろう。しかしながら、後者の意味でこの略語が使われていることが多い。

十分な機能が利用可能になり、利害関係者へのリリース移行コストが正当と判断された場合に、DADの「十分な機能性」マイルストーンは、構築フェーズ終了時に達成したとみなされる。例えば、使用可能なソリューションインクリメントは2週間の反復ごとにできるかもしれないが、高いコンプライアンスレベルが要求される環境では実際にそれを本番移行するのに2週間かかるかもしれない。この場合、より多くの機能が完成するまで、移行に要するコストは正当とはみなされない可能性がある。

本番準備完了
重要な場面では、利害関係者へのソリューションデリバリーの一環として最終準備を行うために、公式の移行フェーズが必要になることがよくある。十分な機能が開発され、テストされたら、その後通常必要なのが、データ変換、最終受け入れテスト、製造及びサポート関連の文書化のような移行関連の活動である。理想的には、これらの作業の多くが、機能の各インクリメントを作る一環として構築フェーズの間に継続的に行われている。いくつかのポイントでは、ソリューションを準備完了とするための決定が必要となる。もちろん、継続的デリバリーライフサイクルに従っている場合には、「移行フェーズ」は「移行作業」になるだろう。しかしながら、ソリューションをデプロイする前に、そのソリューションが使用可能であることを確認したい関係者は依然として存在する。

満足した利害関係者
ガバナンス組織やその他の利害関係者は、プロジェクトがいつ公式に終了するかを知りたいことがある。それによって次のリリースを開始したり、他に予算を振りかえたりすることができるからである。プロジェクトは、ソリューション本番開始の翌日に終了するわけではない。トレーニングや本番移行後のチューニング、サポート移管、実装後の再レビューなどのプロジェクト完了作業はしばしばあり、プロジェクトが完了したと判断される前に保証期間を設けることもよくある。リーンには「顧客満足」という用語があるが、これは「満足」の閾値が低すぎることを示唆している。一方DADは、プロジェクトが完了したと判断する前に、サポート担当などの顧客以外の利害関係者の満足を満たす必要もあると考え、マイルストーンの名前を「満足した利害関係者」としている。

マイルストーンを試してみる

アジャイルは、利害関係者に対する透明性と説明責任を促す。みなさんのプロジェクトで重要なマイルストーンの達成を共有し、お祝いしよう。

オリジナル:Reduce Agile Project Risk with Light-Weight Milestones

Reduce Agile Project Risk with Light-Weight Milestones


 (翻訳 中佐藤麻記子)

Pocket

アーキテクチャーオーナー

上の図でおわかりいただけるように、DADの基本的な役割はスクラムのものと似ている。スクラムでは、プロダクトオーナーは何をどの順番で構築するかを決定する。DADではアーキテクチャーをプロジェクトリスクの重要な鍵とし、チームがこれらのリスクに確実に対処することに責任を負う何らかの役割が必要と考えている。結果としてDADプロセスフレームワークには、アジャイルモデリングの役割であるアーキテクチャーオーナーを明示した。アーキテクチャーオーナーはチームのアーキテクチャー上の決定を行い、ソリューション設計全体の構築と進化をファシリテートする役割である。チームリードの役割にあたるメンバーがアーキテクチャーオーナーになることも多いだろう。これは大規模開発ではあまりないが、小規模なアジャイルチームではよくあるケースである。

アーキテクチャーオーナーの責務は以下のようなものである。

  • チームが開発しているソリューションのアーキテクチャー構築/進化をガイドする。アーキテクチャーオーナーは、単にアーキテクチャーに責任があるだけではなく、技術的な議論をリードする役割であることに注意すること。
  • アーキテクチャー上のプラクティスや課題について、他のチームメンバーに助言・指導を行う。
  • 組織のアーキテクチャー上の方向性や標準を理解し、チームがそれらを適切に順守できるようにする。
  • フレームワークやパターン、サブシステムのような企業内にすでに存在する資産を理解し、チームが適切にそれらを使えるようにする。
  • 技術的負債を最小限にするためによい設計とリファクタリングを奨励し、それによってソリューションのサポートが容易になるようにする。
  • ソリューションが定期的に、理想的には継続的インテグレーション(CI)のプラクティスによって、統合されテストされるようにする。
  • 最終的な技術的決定はしつつも、協調的にチームプレイでアプローチするため、アーキテクチャー的な方向性を「指示」することは避けようとする。アーキテクチャーオーナーは、チームリードと緊密に協力し、プロジェクトの重要な技術的リスクを軽減するための戦略を特定・決定する必要がある。
  • プロジェクト初期のアーキテクチャー検討をリードし、初期段階の要件検討を(特にソリューションの非機能要件を理解・進化させる点で)サポートする。

DADにおいてこのような役割を作っている主な理由のひとつは、作業項目一覧(スクラム用語でいうバックログ)に作業項目を追加し優先順位付けするにあたり、プロダクトオーナーと同様アーキテクチャーオーナーにも発言権があるという点である。確かにビジネス価値は優先順位を決定する際の主要な要因ではあるが、技術的リスクを緩和するための作業も同じように重要である。加えて、DADの目標は、単に動作するソフトウェアというだけではなく、使用可能なソリューションをデリバリーすることである。そのため、例えばエラーログや監視などの本質的に技術的な作業項目を追加することも必要になる。もしくは、継続的インテグレーション/デプロイのプロセスを改善するための作業項目を追加する必要もあるかもしれない。我々は、プロダクトオーナー・アーキテクチャーオーナー両方の概念があることで、使いやすさやサポートのしやすさのような機能要件・非機能要件の両方に適切に対処できることに気づいた。実際、私(原著者)の現在のプロジェクトでは、プロダクトオーナー・アーキテクチャーオーナーの双方と連携し、作業中のイテレーションに優先度の高いストーリーを入れるだけではなく、利害関係者にソリューションを提供する移行フェーズに入るための準備として、ソリューションを強化するための作業項目も含めるように、優先順位を交渉している。アーキテクチャーオーナーが役割として明確になっていなければ、作業項目一覧内で重要な技術的項目の優先順位を上げるのは難しいかもしれない。結果として、プロダクトオーナーの知識のみで優先順位付けが行われ、健全なプラクティスとならず、最悪の場合、低品質のソリューションに帰結してしまう。

スコット(原著者の一人)がアーキテクチャーオーナーの役割をより詳細に記述した良記事を書いているので、こちらもご覧いただきたい。

オリジナル:The DAD Role of Architecture Owner

The DAD Role of Architecture Owner


 (翻訳 中佐藤麻記子)

Pocket

DADとラショナル統一プロセス(RUP)の比較(パート2)

この投稿は、DADとラショナル統一プロセス(RUP)の比較(パート1)の続編である。パート1では、ディシプリンド・アジャイル・デリバリー(DAD)が “アジャイル版RUP” ではない理由を何点か記述した。DADはその取り組み方においても内容においても、全く異なるものである。しかし、アジャイル手法の主流ではないが、統一プロセス(UP)には含まれているもので、大変すぐれた原則もまた存在する。本投稿では、UPの中で、DADのプロセス・デシジョン・フレームワークに組み込まれたものをいくつか紹介する。

DADはRUPと同様、すべてのデリバリー・ライフサイクルを網羅している。アジャイルの文脈では否定されているが、DADでは実際のプロジェクトはいくつかのフェーズを経るものと考えている。RUPは、方向付け・推敲・構築・移行という、明確な4つのフェーズを持っている。以前の投稿で記述したいくつかの理由により、DADは明示的な推敲フェーズを持っていない。しかし、推敲のマイルストーンは依然DADの中に存在する。以下のDAD基本ライフサイクルの図にあるように、DADには、RUPの4つのフェーズのうち3つがある。

3 - DAD Lifecycle agile scrum

・方向付けフェーズ
プロジェクト初期の活動を方向付けフェーズという形で明示しているのは、DADの重要な特徴である。Scott Ambler(訳注:DAD本著者の一人)が自身の投稿の中で以下のように述べている。
”アジャイル・コミュニティの中では「フェーズ」という言葉はNGワードとして扱われがちであるが、現実問題として、ほとんどのチームではプロジェクトの初期段階で事前作業として行うべきことがある。この作業は、スプリントゼロ/イテレーションゼロという間違った認識をされることもあるが、一般的に想定されている以上に、通常この作業には時間がかかっていることは、容易に見て取ることができる(2009年アジャイルプロジェクト開始時に関する調査では、平均的なアジャイルチームは方向付けに3.9週間かけている)。”
そのため、DADの方向付けフェーズ(通常1回の反復)では、非常に軽量なビジョン作成の活動を行い、プロジェクトの枠組み作りが適切に行えるようにした。このフェーズのマイルストーンは、プロジェクトの進め方について「利害関係者の合意」を得ることである。DAD本では、方向付けフェーズをできるだけ素早く進めるためのさまざまな戦略、なすべきこと、利害関係者の合意をいかに得るかを記述した。

・構築フェーズ
このフェーズは、ソリューションのインクリメント(増分)を構築するイテレーション(スクラム用語ではスプリント)の集まりとして考えることができる。各イテレーションの中でチームは、スクラム、XP、アジャイル・モデリング、アジャイル・データ等のプラクティスをハイブリッドで適用し、ソリューションをデリバリーする。DADは、初期のイテレーションにおいて作業を優先付ける際に、リスク−価値駆動のアプローチを推奨する。これは、動作するソリューションとともにアーキテクチャーを提供することで、プロジェクトのリスクをできるだけ早期に軽減しようとするRUPの原則から来ている。そのため我々は、ビジネス価値の高い部分をデリバリーすることと、アーキテクチャーリスクを軽減するための作業とのバランスを取るようにした。初期のイテレーションでは、高いビジネス価値とリスク軽減の両方に関わるストーリー/機能をデリバリーすることが理想である(故に、DADは「リスク−価値駆動」である)。初期イテレーションの完了時に、本当に技術的リスクに対処できているかどうかを評価するためのチェックポイントを置くことには、意義がある。DADはこれを「実証されたアーキテクチャー」として明確なマイルストーンとしている。これはRUPの推敲フェーズのマイルストーンと類似しているが、RUPの実装においてしばしば混乱の原因になった推敲フェーズのリスクを冒さずにすむ。アジャイルの手法はすべて、利害関係者にできるだけ素早く価値を届けることをめざしている。ほとんどではないにしても多くの大企業では、イテレーション完了のたびにソリューションの新規追加分をデリバリーすることは、現状困難である。それゆえDADは、この現実を認識し、ほとんどの場合、ソリューションが実際に顧客にデリバリーされる前に、構築フェーズのイテレーションが複数回存在するだろうと結論付けた。DAD本の中で明確にしたように、これがDADの基本パターンではあるものの、「継続的デリバリー」の目標達成の精神をもって、今まで以上に頻繁にソリューションをリリースするように努めるべきだ。構築フェーズ完了のマイルストーンは、利害関係者へデプロイするのに「十分な機能」があることである。これはRUPの構築フェーズのマイルストーンと同じである。構築フェーズの間、方向付けフェーズで合意されたビジョンに沿ってプロジェクトが進捗しているかどうかを定期的に振り返り、時には方向性を修正するのは、意味のあることだ。これはDADの補足的なマイルストーンで、「プロジェクトの実現可能性検討」と呼ばれる。

・移行フェーズ
高度なエンタープライズ・アジャイルプロジェクトでは、利害関係者に頻繁にソリューションをデプロイすることはそう簡単なことではないと、DADは認識している。この現実を考慮して、DADはRUPの移行フェーズを組み込んでおり、通常1回の短いイテレーションを想定している。DADチームとしても、企業全体の流れとしても、このデプロイプロセスはより短縮され、継続的デプロイとなって徐々に消滅していくことが理想である。RUPの移行フェーズのマイルストーンは、顧客が満足し、自足することで達成される。DADではこれを「利害関係者の満足」に変更した。これはリーンでいう顧客満足に似ているが、エンタープライズにおいては、例えば製品サポートのような、顧客以上に幅広い利害関係者の満足が重要だと我々は考えている。RUPの移行フェーズの特徴のひとつは、このフェーズのどこでデプロイが行われるかが明確でないことである。明らかに利害関係者の満足が得られていない場合は、ソリューション開発は継続して行われている。通常このフェーズは、利害関係者のニーズを完全に満たすための安定化、調整、トレーニングなどの期間である。そのためDADには、移行フェーズの途中に「運用準備」と呼ばれるマイルストーンがある。時にはこれは「go/no go(進むか止まるか)」を判断するための正式なものになる。

まとめると、DADはエンド・ツー・エンドのリスク−価値駆動ライフサイクルの考え方の元、プロジェクトが適切に進捗しているかどうかを確認するためのマイルストーンによって、アジャイルプロジェクトに道筋をつける。これらのチェックポイントは、道順を変更し、適応し、プロジェクトを次フェーズに進めるための機会を提供する。このライフサイクルはRUPに似てはいるものの、パート1で述べたように、イテレーション内で行われる実際の作業は全く異なり、典型的なRUPのプロジェクトよりはるかにアジャイル的であることを理解することが重要である。

Scott Ambler + Associatesでは、RUPから、よりアジャイルな、しかしディシプリンドなDADの提供する手法へ移行するための助けをもとめる企業から、多くの問合せがある。

オリジナル:Comparing DAD to the Rational Unified Process (RUP) – Part 2

Comparing DAD to the Rational Unified Process (RUP) – Part 2


 (翻訳 中佐藤麻記子)

 

Pocket

DADとラショナル統一プロセス(RUP)の比較(パート1)

先日、私(訳注:Mark、DAD本原作者の一人)が初めての顧客とDADについて議論していた際、DADはRUPのアジャイル版なのか? という質問を受けた。ひと言でいえば、ノーである。DADは以下の図にあるように、複数の手法やプラクティスのハイブリッドで構成されたフレームワークである。ここには、スクラム、エクストリーム・プログラミング(XP)、アジャイル・データ&モデリング、そしてもちろん統一プロセス(UP)も含まれる。DADにはまた、これらの手法では示されていない、アジャイル・ガバナンスのような追加部分も含まれる。この図を見ていただければ分かるように、DADに最も大きく寄与しているのは、UPではなく、おそらくXPだろう。

hybrid-of-methods11

ラショナル統一プロセス(RUP)は、主に反復的なライフサイクルでのソフトウェア構築を想定し、扱いやすい小さなプロセスフレームワークとして始まった。しかしその後、ラショナル(そして後にはIBM)は、パッケージ実装、保守プロジェクト、J2EEや.Netのような技術特化のガイド、システムエンジニアリングなど、あらゆる種類のプロジェクトにRUPの適用可能性を拡張するべく、付加的なガイドや成果物を徐々に追加していった。結果として、重すぎて扱いづらく、正しく理解して適用するのが難しいプロセスとなってしまった。事実、RUPはしばしば間違って使用される(例えば、推敲フェーズがBRUF – “最初にまとめて要求定義する” フェーズとして扱われる)。このような誤った使い方を、Julian HolmesはRINO(名ばかりRUP)と言っている。誤解のないように言っておくと、RUPは正しい環境で適切に適用されればとても効果的だ。しかし、不幸なことに、その逆のことが頻繁に発生している。RUPフレームワークをさまざまなタイプのプロジェクトに適用する際の問題のひとつは、それが「ユースケース駆動」のアプローチとして示されることだ。要件をユースケースとして記述し、それらのユースケース実現からコンポーネントベースのアーキテクチャーを作成していくことは、RUPの基本である。これは、ユースケースを作ることがほとんど意味をなさない可能性のある保守プロジェクトやパッケージ実装では、大きな壁となる。

DADはユースケース駆動のアプローチを強いていないし、サービスやコンポーネントを構築する際に厳格にOOAD(オブジェクト指向分析設計)を適用することも主張していない。ユースケース駆動アプローチを適用することは可能だが、アジャイルに逆行するような包括的で詳細な要件定義につながる危険性は否定できない。我々はどちらかと言えば、皆さんのプロジェクトの状況下で道理にかなう範囲での、ユーザーストーリー駆動のアプローチをお勧めする。ユーザーストーリーも常に正しい選択とは限らない。もしかしたら皆さんは昔ながらのソフトウェア要件定義書(SRS)を要求されるような規制のある環境にいるかもしれない。重要なポイントは、皆さんが自身の置かれている状況に適応しなければならないということである。これが、ユーザーストーリーで構成されているスクラムのバックログではなく、(訳注:各項目をユーザーストーリーに限らない)作業項目一覧を、チームの作業の優先順位付けに使用するゆえんである。作業項目一覧を使うことで、バックログにあらゆる種類の作業を入れることができ、RUPやスクラムが理想的とするプロジェクト以外にも、多くの種類のプロジェクトにDADを適用することができるようになる。

DADはゴール駆動であり、成果物駆動ではない。特定の成果物やプラクティスも指定していない。むしろ、ライフサイクルのある時点で適用可能な代替手段を、それぞれのメリット・デメリットと共に提案するが、そのどれを選択するかは皆さんに任されている。

次の投稿では、統一プロセスのどの側面がDADに受け継がれたかということと、その理由を解説する。

オリジナル:Comparing DAD to the Rational Unified Process (RUP) – Part 1

Comparing DAD to the Rational Unified Process (RUP) – Part 1


 (翻訳 中佐藤麻記子)

 

Pocket

ディシプリンド・アジャイル・マニフェスト

このディシプリンド・アジャイルマニェストは、2001年に記されたオリジナルのアジャイルソフトウェア開発宣言を拡張し、DAフレームワークの背景となる哲学を反映させたものだ。

私達が認める価値

私達は次の価値を認める:

プロセスやツールよりも個人と対話
包括的なドキュメントよりも使用可能なソリューションを
契約交渉よりも利害関係者との協調を
計画に従うことよりも変化への対応を

 すなわち、左記のことがらに価値があることを認めつつも、ディシプリンド・アジャイリストは右記のことがらにより価値をおく。

ディシプリンド・アジャイルマニフェストの背後にある12の原則

  1. 利害関係者の満足を最優先し、価値のあるソリューションを早く継続的に提供します。
  2. 要求の変更はたとえ開発の後期であっても歓迎します。
    変化を味方につけることによって、そのお客様の競争力を引き上げます。
  3. 使用可能なソリューションを、2-3週間から2-3ヶ月という
    できるだけ短い時間間隔でリリースします。
  4. 利害関係者と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
  5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
  6. 情報を伝えるもっとも効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることです。
  7. 使用可能なソリューションこそが進捗の最も重要な尺度です。
  8. アジャイル・プロセスは持続可能な開発を促進します。スポンサー、開発者、そしてユーザは
    一定のペースを継続的に維持できるようにしなければなりません。
  9. 技術的卓越性と優れた設計に対する不断の注意がアジリティを高めます。
  10. シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
  11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
  12. チームがもっと効率を高めることができるかを定期的に振り返り、
    それに基づいて自分たちのやり方を最適に調整します。
  13. 組織のエコシステムの中でアセット利用を促進し進化させます。それらのアセットに責任を担っている人々と共に作業します。
  14. ワークフローを可視化することで、しかかり作業を最小に維持しながら一連のデリバリーフローがスムーズに流れることを助けます。
  15. 組織のエコシステムは、アジャイルチームの努力を反映しまたそれを高めるよう進化しなければなりません。また、非アジャイルあるいはハイブリッドチームを十分サポートできる柔軟なものでなければなりません。
http://www.disciplinedagiledelivery.com/disciplinedagilemanifesto/
 (翻訳 藤井智弘)
Pocket

ディシプリンド・アジャイル・フレームワーク

ディシプリンド・アジャイル2.0プロセスディシジョンフレームワークは、組織が自分達のITプロセスを、コンテキストに合わせた形で合理化することを助ける軽量なガイダンスを提供する。ソリューションデリバリーや運用、エンタープライズアーキテクチャ、ポートフォリオ管理、そしてそれ以外の多くの活動をどのように組み合わせて実践するかを提示する。このフレームワークは、これらのアクティビティが対処するものがなにかを説明し、それを為すために取り得るオプションと、各オプションに伴うトレードオフを説明する。

この記事では、次のトピックスを見ていこう:

なぜディシプリンド・アジャイル2.0なのか?

筆者達がソリューションデリバリーの域を超えてフレームワークを拡張したのには、以下に挙げるいくつかの理由がある:

  1. アジャイルデリバリーチームの成功を可能にするために
    ディシプリンド・アジャイル・デリバリー(DAD) 1.xのフォーカスは、ソリューションデリバリーにおける活動のすべて(分析、設計、テスト、アーキテクチャ、管理、プログラミング等々)がどのようにしてしっかりとかつ効率的に組み合わされるかを示すことで、アジャイル/リーンチームが初めから終わりまでどのように活動するかを説明することにあった。しかし、デリバリーを成功させるためには、チームはチーム外の人々(例えば、エンタープライズアーキテクト、運用のエンジニア、ガバナンスを司る人達、データ管理者、その他諸々)と共に働かなければならない。アジャイル/リーンチームがより効果的にあるためには、これら(チーム外)の人々も、アジャイル/リーンの作法で活動しなければならない。
  2. アジャイルITの首尾一貫した戦略を提供する
    もし読者がソフトウェア開発をキツい(hard)仕事だと考えているなら、IT部門のすべての活動はさらに大変だ。IT部門とは複雑適応組織 (complex adaptive organiation)なのだ。この言葉を使った意味は、ひとつのチームのアクションは他のチームに影響を及ぼし、それがどんどん伝搬していくということだ。例えば、読者のアジャイルデリバリーチームのやり方が、やり取りしている他のチームに影響を及ぼし、そのチームから影響を受けるだろう。もし読者が(おそらくDevOps戦略の一環で)運用チームと作業しているなら、各々のチームがお互いに効果的に共同作業出来るようなやり方を採用する必要がある。各チームは、他のチームから仕事のやり方を学び改善することが望ましい。この改善はさざなみように他のチームに伝わっていく。難しいのは、IT分野の各領域はひとつかそれ以上の知識体系(bodies of knowledge)を持っており(場合によっては“知識本(books of knowledge)”として出版されていたりするが)、この類いの体系は、各領域で働く人へのガイダンスを提供している。例を挙げると、管理者であればPMIBoKやPrince2、エンタープライズアーキテクトであればTOGAF やZachmanフレームワーク、ビジネスアナリストであれば、IIBA BoK、データ管理者でれば、DAMA BoK等々、といった具合だ。これらのインダストリーグループとそれに関連する知識体系は、お互いを否定しあい、アジャイル/リーンの学習曲線の異なる位置におり、時々アジャイル/リーンではない戦略を推奨したりする。ITのレベルでは、大きな混乱が起こり、機能不全に終わる可能性がある。DAフレームワークは、どのようにこれらすべてを柔軟に組み合わせて、複雑適応系において直面した現実をサポートするかを提示する。
  3. リーンエンタープライズのサポート
    リーンエンタープライズは、市場での変化を予測し、迅速に対応することを可能にする。これは、直面している状況に対応出来るように変化することを促す、組織の文化と構造によってなされる。リーンエンタープライズは主流のビジネスで学び続けるマインドセットと、イノベーションをドライブする底流に流れるリーンおよびアジャイルプロセスを必要とする。これは、アジャイル/リーンのやり方でIT部門が作業出来るということも意味している。
  4. コンテキストを考慮する
    すべての人、チーム、組織が、ひとつひとつはユニークなものだ。これが意味するところは、読者諸氏には、選択肢を提供したフレームワークが必要だということだ。それによって読者は現実に直面している状況に対処するためのアプローチをテイラリングでき、後々それを進化させることができる。SAFeやNexusのようにあらかじめ規定され(prescriptive) 1サイズですべてに適用させるフレームワークは、プロセスに関連する最初期のニーズに対しては魅力的で簡単なソリューションに思えるかもしれないが、現実は採用した組織に対して、良いことよりも害を及ぼすほうが多くなることがしばしば見られる。

なぜ名前を変えたのか?

フレームワークのスコープが、ITソリューションのデリバリーをどう効果的に進めるかから、IT活動全般をどう効果的なものにするかへと、進化している。結果として筆者達は、”ディシプリンド・アジャイル・デリバリー”という名称が、もはやフレームワークのゴールを表現していないと感じた。”ディシプリンド・アジャイル”のほうがより正確だ。

リリース戦略(※訳注:古い情報です)

 基本的な素材は2014年後半から2015年にかけてリリースを始め、最終的には、2015年8月リリースを予定している。つまりまだ終わっていない。2015年8月にDA2.0 のマテリアルを段階的にリリースしていく。

経緯・歴史

 このフレームワークは、3つのメジャーリリースをここまで重ねてきた。
  1. ディシプリンド・アジャイル・デリバリー 0.x     本フレームワークの起源は、IBM Rationalで2009年の始めから2012年6月にかけて開発された。 IBMチームは、ビジネスパートナーと密に協力してきたが、その中にMark Linesが参加し、Scott Amblerがリードしてきた。IBM Rational Method Composer(RMC)は、DADフレームワークの早期バージョン(バージョン0.5)をサポートしている。
  2. ディシプリンド・アジャイル・デリバリー 1.x     2012年6月の最初のDAD本”ディシプリンド・アジャイル・デリバリー”出版を以て、DAD1.0のリリースとしている。DADフレームワークの進化と公開は今ご覧のサイト上で2012年の8月から始まっている。DADフレームワークの知的財産は、Disciplined Agile Consortiumへ2012年10月に引き渡され、2014年6月IBMにより法的に確認された。
  3. ディシプリンド・アジャイル・デリバリー 2.0     これが現在のバージョンである。最初のリリースは2015年8月に行われた。前述したように、フォーカスはITプロセスへの柔軟でコンテキストに応じたアプローチへと進化している。

将来

今後もこのサイト上でマテリアルを開発し続けるつもりだ。アップデートの通知が必要であれば、このブログを購読してほしい。LinkedInのディシプリンド・アジャイルにフォーラムを開設しているので、進行中の議論に参加したければ、そちらにもご参加いただきたい。

 http://www.disciplinedagiledelivery.com/agility-at-scale/disciplined-agile-2/
 (翻訳 藤井智弘)
Pocket

全アジャイル・デリバリー・ライフサイクル

ディシプリンド・アジャイル(DA)プロセスディシジョンフレームワークの重要な側面の一つは、初期段階から最終段階までの完全なソリューションデリバリーライフサイクルにある。以下に掲げる図は、DAデリバリーライフサイクルのハイレベルな概要だ。3つのフェーズから成り、more on this in a minute, その期間に渡って利用可能なソリューション(ComsumableSolution)をインクリメンタルにビルドする。このハイレベルな観点から始めることで、詳細に入る前に、幾つかの重要なコンセプトを探っていくことにしよう。

最初に、DAライフサイクルは、3つのフェーズを明確に提示している:

  1. 方向付け   このフェーズでは、プロジェクトの立ち上げに必要な活動が行われる。”フェーズ”という言葉はアジャイルコミュニティの中では嫌われている言葉(swear word)だが、現実にはほぼ全てのチームでプロジェクトの初めの段階で先行するなんらかの作業が行われている。人によってはこの労力をスプリント(あるいはイテレーション)0と、やや誤解しているが、よく見られるのは1イテレーションよりも多くの時間を割いていることだ(2013Agile Project Initiation surveyでは、平均的なチームは方向付けに1カ月程度割いており、その一方で典型的なイテレーション/スプリント期間は2週間だった)。それ故、DADの方向付けフェーズは、ビジョンを明確にするための負担の非常に軽い活動を提唱しており、プロジェクトを適切に立てつけることができる。これが、「方向付けフェーズは短時間で」というディシプリンだ。
  2. 構築  このフェーズでは、デリバリーチームは潜在的に利用可能なソリューションをインクリメンタルに
    構築する。複数のイテレーション(スクラム世界
    スプリント)を1セットとして実装することもあるし、リーンのような継続フローアプローチ(ライフサイクルのバリエーションについては後述する)こともあるだろう。チームは、ソリューションをデリバリーチームするために、スクラムやxp、アジャイルモデリングやアジャイルデータ、その他様々なメソッドからのプラクティスを組み合わせたハイブリッドアプローチを採用する。
  3. 移行  DAプロセスは、洗練されたエンタープライズアジャイルプロジェクトにとって、利害関係者にソリューションをデリバリーことは、取るに足らないつまらない作業からはしばしば程遠いものになるとみなしている。デリバリーチームチームは、そしてエンタープライズ全般でも同様だが、デプロイメントプロセスを合理化しこのフェーズの時間を出来るだけ短くしようと試みるし、理想的には継続的デリバリーアプローチからこのフェーズが消えることが望ましい。これが、「フェーズから活動へ、移行を進化させる」というディシプリンだ。

 

 そう、読者がこの後見ていく図(システムライフサイクルを図示したものだが)にも見られるように、アジャイルSDLCには3つのフェーズだけに留まらない。第1に、ポートフォリオ管理にはプロジェクトに先行して作業する局面がある。そこでは、潜在しているプロジェクトやプロダクトが顕在化され、優先順位付けされ、方向付けフェーズの作業を開始するために十分な予算が採られる。さらに、チームをガイドするビジネス面とテクニカル面でのロードマップが開示されるかもしれない。移行フェーズの後では、本番の環境でソリューションが運用されサポートされる(商用製品であれば市場に供される)。結果的に、何十年か使われた後、ソリューションはリタイアされる(運用から外れる)。もしITの視点からこれらを見れば、エンタープライズレベルでプロダクト/プロジェクト横断的な関心事(例えば、エンタープライズアーキテクチャーやポートフォリオ管理、再利用エンジニアリングなど)があるし、DADフレームワークが現在サポートする以上のものがあるのだ。

3 - DAD lifecycle high level

 DAフレームワークは単一のライフサイクルをあらかじめ規定していない。これはスクラムのような他のメソッドとは異なる点だ。DAD本ではライフサイクルの2つのバージョン(基本/アジャイルとアドバンスド/リーンバージョン)にフォーカスを合わせたが、実は最初のバージョンが世に出て時に継続的デリバリーと探索的(リーンスタートアップ)ライフサイクルも記述していた。ポイントは、各々のチームは独自の状況にあり、DADフレームワークが有用なものであるためには、ライフサイクルの数種のバージョンを十分サポート出来るよう柔軟でなければならないということだ。
  では、それら4つのライフサイクルを順に見ていこう()
  • アジャイル/基本ライフサイクル
  • アドバンスド/リーンライフサイクル
  • 継続的デリバリーライフサイクル
  • 探索的(りーんスタートアップ)ライフサイクル

アジャイル/基本ライフサイクル:スクラムの拡張

下の図は、筆者達がアジャイル/基本DADライフサイクルと呼ぶものの詳細を記したモノだ。これはスクラムの構築ライフサイクルを拡張している。このライフサイクルの詳細に加えて、いくつか興味深い側面がある:

  1. イテレーションベースである。スクラムやXPを含む多くのアジャイルメソッドのように、ソリューションはタイムボックスを使ってインクリメンタルに構築される。これらのタイムボックスはイテレーションと呼ばれる(スクラムでスプリントと呼んでいるモノと同じだ)。
  2. スクラム用語は使わない。 ライフサイクルはスクラムをベースとしているが、筆者達はDAではブランド化された用語は使わないという選択をしている。この図の場合を例に取ると、スプリントの代わりにイテレーションを使っている。用語は実際には問題ではないので、読者がスクラム用語になれているのであれば、代わりにそれらを使って構わない。
  3. デリバリーライフサイクルの範囲外からのインプットを示している。前述の概要図ではデリバリーライフサイクルのみ示していたが、下の詳細図では、プロジェクトの方向付けより前になんらかの活動が行われ、しばしば運用後に新しい要求が(変更リクエストや不具合レポートという形で)アジャイルチームに投げられることが示されている。これらのインプットはデリバリーライフサイクル全体にかかわる重要なコンテキストを提供する。
  4. プロダクトバックログではなく、ワークアイテムリスト。 DAはスクラムよりもスコープが広く、読者がこのスコープを取り扱う場合には、スクラムのプロダクトバックログよりも、よりしっかりした変更管理アプローチが必要となることを初めに理解すべきだ。ワークアイテムは、要件、不具合、その他の非機能な側面(トレーニングや休み、他のチームのアシスト等)を含んでいる。これらの作業はすべて優先順位付けされる必要がある。要求を実装するだけではないのだ。この詳細については、Agile Best Practices: Prioritized Requirements(未訳)を参照いただきたい。
  5. 明確なマイルストーンを含む。 ライフサイクル図の底辺に沿って、ライトなマイルストーンが提示されているのが見えるが、デリバリーチームはこのマイルストーンに沿うように奮闘すべきだ。このようなマイルストーンはアジャイルガバナンス(※未訳)の重要な側面だ。

3 - DAD Lifecycle agile scrum

筆者達はこれを基本/アジャイルライフサイクルと呼ぶが、これは読者が着手するのに適した開始点となりそうだからだ。このバージョンのライフサイクルを適用する共通のシナリオはスクラムを読者のニーズを満たすよう拡張するか、あるいはRUPからディシプリンドアジャイルアプローチに移行するというものだ。

アドバンスド/リーンライフサイクル

下の図はアドバンスド/リーンライフサイクルと呼んでいるモノだ。このライフサイクルの特徴を挙げてみよう:
  1. 継続的なデリバリーフローをサポートしている。このライフサイクルでは、ソリューションは頻繁に、そして理にかなっているならいつでもデプロイされる。作業はそれに対応する余裕がある場合にチームにプルされ、イテレーションのような定期的なリズムに乗るわけではない。
  2. プラクティスは自身のケーデンスを則る。イテレーション/スプリントを使った開発では、多くのプラクティス(詳細な計画策定、ふりかえり、デモ、詳細なモデリング等々)は同じケーデンス、つまりイテレーションに効果的に配置される。リーンアプローチで見られるのは、何かをやる意味があるときにやり、読者がスケジュールした通りカレンダーが指し示す時にやるわけではないということだ。
  3. ワークアイテムプールを使う。すべてのワークアイテムは同じく作られるわけではない。ある種の作業を”標準的なお作法”ースクラムが提唱する価値駆動アプローチやらDAやRUPが提唱するリスクー価値駆動アプローチやらーに従って優先順位付けするという選択をするかもしれないが、他のモノもこの戦略にフィットするかもしれない。ある作業は、特に法令から発生した作業は期限が日付でドライブされる。ある種の作業は手早く片付けられなければならないに違いない。たとえば重要度トップの、稼働中の問題を解決するといったような作業の場合だ。だからワークアイテムプールなのであり、優先順位付けされたスタックではないのだ。現実が理解の進めば、これが持つ意味もわかるだろう。

3 - DAD Lifecycle Advanced

筆者達はこれをアドバンスド/リーンライフサイクルと呼ぶ。チームが時間をかけて進化しているのを見ている。彼らは前述した基本ライフサイクルで始めることが多いが、学ぶにつれ、自分達の作業を改善するにつれ、ライフサイクルはよりリーン度合いを増していく。

継続的デリバリーDADライフサイクル

下の図は、継続的デリバリーDAライフサイクルだ。基本的には、ひとつ前に説明したライフサイクルのさらにリーン化の進んだバージョンで、プロダクトが運用環境や市場へ定期的に出荷される。これは毎日の場合もあれば、週次だったり月次だったりがよく見られる。

3 - DAD Lifecycle Continuous Delivery

探索的(リーンスタートアップ)ライフサイクル

次の図は、DA探索的ライフサイクルだ。このライフサイクルは、利害関係者が新しいプロダクトのアイディアがありながら、ユーザにとってなにが必要とされているのかを自分達がまだ理解できていない状況にあると理解したスタートアップや研究段階のアジャイルやリーンチームによって採用される。結果として彼らは市場が何を求めているのかを、一連の学習体験を通してクイックに探る必要がある。このライフサイクルは他のDAライフサイクルにおける方向付けフェーズを置き換えとなり、ビジョンを検証しライフサイクル期間中を通して継続して実践され続ける。

3 - DAD Lifecycle Exploratory

では、探索的ライフサイクルがどのように機能するか見ていこう。6つのアクティビティがある:

  1. ビジョン化  チームはアイディアを探索し、アイディアを実装するための可能な戦略を特定する。これは、2,3人がひとつの部屋で、ビジネス面と技術的オプションについて ホワイトボードと紙を使ってモデルストーミングするくらいの簡単なモノで済むかもしれない。読者は、顧客が実際に欲するモノが何かに対する実現可能な仮説を見出すためのに十分な検討時間が必要だ。この仮説は、検証が可能である必要がある。ここで、検証可能が意味するのは、読者は作り出した新しい機能性がどれくらい効果的であったかを計測する方法を特定する必要があるということだ。
  2. 少しだけ構築する  仮説を検証するソリューションをビルドするのに十分なだけの労力を割くことに投資すべきだ。リーンの語法で言えば、読者は最小限の実行可能なプロダクト(MVP)として知られているビルドだ。労力の総量は異なる。数日から数週間にわたることもあるーあなたのゴールはなにか使えるモノをとても早く作って仮説を検証できるようになることだ。
  3. デプロイ  現在のソリューションが準備出来たら、仮説を検証できる環境にデプロイされる。このデプロイメントは様々なやり方(多くは”アルファ”や”ベータ”リリースとか呼ばれる)で顧客のサブセットに対して行われる。それにより、ソリューションが顧客の関心を惹くかを決定することが出来る。
  4. 観察と計測:
    ソリューションが運用に供されると、あなたはそのソリューションのどんな面が、それがあるとして、あなたのユーザー・ベースの興味を惹いているのか決定したくなる深い
    これを実現するには、内部で起きた重要なイベントに関するログデータを取得出来るようにあなたはソリューションにコードを挿入する必要があるだろう。
    たとえば、いつ特定の画面/ページがアクセスされるか、いつ販売されるか、特定の業務処理が進行中であるか等々。
    この考えはエンドユーザーがどの機能が役に立つと思っているか、どの機能が顧客保持に繋がるか、どの機能がより大きな売上高をもたらすか・・・ あなたにとって重要であるものは何でも理解したいということだ。
    データを生成することで、あなたは新しい機能がユーザベースからどれくらい有効と受け取られているか、モニターし、観察と計測することができる。転じて事実に基づいて先に進めるか否かの判断を下すことが出来る。もしその機能の評判が良ければ、今の戦略を続けたままで、なにか機能をさらに追加するという選択も出来る。あるいは、あなたの戦略はとてもうまくいったので、ソリューションを商用製品化する準備をしようと判断することができる。もし機能が受け入れられなかったら、貴方のチームは原点に立ち返って、別の方向性に則るか、完全に止めてしますという途を選択することもあり得る。
  5. キャンセル. プロダクトのアイディアが結局動かないことがわかる時がある。事実、スタートアップと同様に研究開発(R&D)で特によく見られる。これのよいところは、アイディアが失敗に向かっている場合に、それが失敗であると学習することで別の戦略にエネルギーを振り向けることができるということだ。
  6. プロダクト化:少しづつ実装しデプロイするイテレーションを複数回繰り返し、観察して計測するという過程を経て、プロダクトは市場で成功を収めるだろう(社内システムの場合には、ユーザベースで成功を収める)。上に述べたように、あなたはこのライフサイクルを使い続けるという選択もできるが、よくあるのは他のDAサイクルを適用すると決定することだー例えば、スクラムベースのアジャイルライフサイクル、カンバンベースのリーンライフサイクル、あるいは継続的デリバリーライフサイクルといったものだ。このライフサイクルを方向付けフェーズとして扱って時間を効果的に使っている。

さらに詳細な議論は、The Exploratory “Lean Startup” Lifecycle(※未訳)を参照いただきたい。

なぜ複数のライフサイクルをサポートするか?

Q)なぜ複数のライフサイクルをサポートするのか?
いい質問だ。第1に、明らかに一つのライフサイクルはすべてに適合するわけではない。チームは、自身の置かれた環境がユニークであることを知っている:チームメンバーは、一人一人がスキルと仕事のパフォーマンスが異なる代えがたい個であり、様々なスケーリング/テーラーリングファクター、たとえばチームサイズや地理的な分散、ドメインの複雑さ、組織の文化といったものは、チームに依って異なる。チームは自身の置かれた環境が様々な可変要因を有していることを知っているので、DAのようなフレームワークは、複数のライフサイクルをサポートすべきではないだろか?さらに言えば、様々なアジャイルのフォーラム、ユーザグループ、カンファレンス、そして組織内でひろく議論されていることから、現実はアジャイルチームは異なるタイプのライフサイクルに則っていることは明らかだ。
2番目に、筆者達は、事前に規定された単一のライフサイクルという考え方には、居心地の悪さを感じる。DAフレームワークの記述を始めるときに、筆者達はあらかじめ規定するということを避けたかった。スクラムコミュニティの中ではあらかじめ規定することの悪についてのレトリックがあるが、実際にはスクラムは明らかに”事前に規定されたもの”だ。筆者たちは、スクラムを「箱から出してそのまますぐに適用」できないような環境で、スクラム法の条文に従おうとしてトラブルになっているチームを数多く見てきた。
3番目は、筆者達はプロセス改善というものを固く信じている。もし読者が、学習しながら自身のプロセスを実際に改善しているなら、ライフサイクルが時を経て進化していくのは現実味がないのだろうか?もちろん、そんなことはない。現実味がある。最初は基本/アジャイルライフサイクルに近い形で開発を始めたチームが、時を経てアドバンスド/リーンや継続的デリバリーライフサイクルへと進化していくのを、筆者達は見てきている。

複数のライフサイクルをサポートすることのデメリット

複数のライフサイクルを明確にサポートすることには、明らかな欠点がある。そうすることによって、DAチームが自身の状況にもっとも合うプロセスのテーラーリングと、繰り返し可能なプロセスの記法にいまだにしがみついている組織においては真逆のものになりうるコンセプトに従うことを筆者達ははっきり認めている(ちなみにDAは”繰り返し可能なプロセスよりも繰り返し得られる結果”(※未訳)を推進している)。また、企業内の専門家―例えばエンタープライズアーキテクトやデータ管理グループ―はこれら複数のデリバリーライフサイクルに対応できるだけの十分な柔軟性が求められる。そのようなエンタープライズでのプロセスを次善のものにする(例えば、全プロジェクトチームが単一のデータ管理戦略に合わせるよう強制するといったような)代わりに、サポート対象のデリバリーチームに最適な方法でサポートするだけの十分なスキルと柔軟性をもった、エンタープライズチーム(※訳注:全社横断チーム、みたいな感じ)を立ち上げたいと思うだろう。最終的には成果物ベースではなく結果ベースのガバナンスが必要とされるのは明らかだ。よいニュースは、DAはフレームワークに”効果的なガバナンス”(※未訳)を組み入れていることだ<

関連する投稿(※訳注:これぜんぶ翻訳するのは、無理orz)
  1. Pingback: An Exploratory “Lean Startup” Lifecycle | Disciplined Agile Delivery
  2. Pingback: Evolving the Goals Overview Diagram | Disciplined Agile Delivery
  3. Pingback: A Full Agile Delivery Lifecycle | Disciplined Agile Delivery
  4. Pingback: Comparing DAD to the Rational Unified Process (RUP) – Part 2 | Disciplined Agile Delivery
  5. Pingback: Just a delivery lifecycle? | Disciplined Agile Delivery
  6. Pingback: Adopting a Full Lifecycle Requires Discipline | Disciplined Agile Delivery
  7. Pingback: Managing Requirements Dependencies Between Agile Teams | Disciplined Agile Delivery
  8. Pingback: Disciplined Agile Lifecycle Posters | Disciplined Agile Delivery
  9. Pingback: What is Disciplined Agile | Reedy Feggins Jr.
  10. Pingback: Managing Requirements Dependencies Between Agile/Lean Teams and Traditional/Waterfall Teams | Disciplined Agile Delivery
  11. Pingback: JIT – Just in time and Software Development | Agile Design = Adaptive Design
  12. Pingback: The Missing Pieces Of The System! | Seeding The Landscape….Agility For Agile Minds
  13. Pingback: Two dimensions: Just in time and Envisioning | Agile Design = Adaptive Design
  14. Pingback: Does your team own its process or merely rent it? | Disciplined Agile Delivery
  http://www.disciplinedagiledelivery.com/lifecycle/
 
(翻訳 藤井智弘)
Pocket

DADでよくある質問

最近はエンタープライズアジャイルの勉強会なるものも立ち上がってきたり、説明の機会をいただくことも多くなってきましたが、そこで「DADはこれまでとなにが違うの?」という質問を受けることが多く・・・でも、それは洋の東西を問わずいずこも同じのようで・・・

DADのUSサイトのほうにFAQがポストされたので、その翻訳をここに挙げておきます。
「みんな同じようなところがわからないのね」と、ある意味安心することでせう。また文化的に”比較広告”に慣れていない私達には、SAFeとの比較のあたりは「おいおい・・・」という感じもw                       (by Tomohiro Fujii)

—ここから翻訳—-

//original :  FAQ( http://www.disciplinedagiledelivery.com/faq/ )

ここでは、DADに対してよく受ける質問を取り上げていこう。これ以外にも新しい質問があれば大歓迎だ。

次のような構成で質問を採り上げていこう。
・DADライフサイクル
・DADと他のメソッド
・DADとスケーリング
・一般的な質問

DADライフサイクル

Q)DADは、ウォーター・スクラム・フォールの一例ですか?
 いいえ。ウォータースクラムフォール(WSF)は、Dave West氏(彼は、DAD本の推薦も書いてくれた紳士で、Foresterのアナリストだ)が定義した言だ。WSFや不幸なプラクティスだープロジェクトの早い段階でかなりの工数をかけてモデリングと計画づくりを行い、構築期間中はスクラムのアプローチを採る。その後には、多大な工数をかけて長時間に渡るデプロイプロセスが続く。WSFは、まだ完全にアジャイルに移行しきっていない組織に典型的に見られる病状であり、スクラムのライフサイクルを構築期間中に絞って適用してしまう(プロジェクトをどう始めどう終えるかはあなたにお任せのままにしておく)ことで、病状をさらに悪化させているように見える。DADは後述するように、デリバリーライフサイクル全体を提唱しているースクラムベースであり、アジャイルであり、継続的デリバリーやその他諸々ー。つまり、あなたの状況に合わせて適切な枠組みを作ることができる。
Q)なぜ、フェーズが3つなのか?
 DADはデリバリーライフサイクル全体を提唱しており、結果として3つのフェーズを明示的に定義している:方向付けはプロジェクトの立ち上げ、構築はソリューションの構築と構成、そして移行はソリューションを本番環境や市場へデプロイする。筆者達は、”楽しい”構築部分のみを取り扱う代わりに、デリバリーライフサイクル全体を扱うということを明確に位置付けているが、これは経験的に観察された事実から導き出されたモノだ。その事実とは、ほとんどのアジャイルチームが実際にはプロジェクト開始初期に先行してなんらかの作業をする必要があり、それに続けて構築作業に多くの時間を費やし、デプロイにあたって幾ばくかの作業を行うということだ。また多くのチームがライフサイクルのすべてにアジャイルであることに苦闘しておりー前述したWater-Scrum-Fallを参照いただきたいー、唯一責任を持てるのはデリバリーライフサイクル全体にアドバイスすることだけだと感じているところを目にした。この点についての詳細は、別ポストWhy are there Phases(※翻訳中)を参照いただきたい。
Q)推敲フェーズに何が起きたか?
 DADにおける3つのフェーズの名称ー方向付け、構築、移行ーは統一プロセス(UP)から来ている。筆者達は、安直に3つのフェーズを立ち上げ、構築、デプロイと呼ぶことも出来たかもしれない。あるいは開始、実行、リリースとも。または、スプリント・ゼロ、作成、出荷。または・・・。筆者達はなにか決めなければならなかったし、UPのフェーズ名が一番適切だった。
 しかし、UPに詳しい人達は、筆者達が4フェーズではなく3フェーズにしたことに注目した。DADには推敲フェーズがないのだ。筆者達は2つの理由から、推敲フェーズを外した。まず第1に、UPの4フェーズを採用したが、伝統的な要件−アーキテクチャープログラムーテストフェーズと誤って適用した多くの組織を見てきた。DADを適用する際に、いとも簡単に同じような過ちが引き起こされるのを避けたかった。2番目の理由として、推敲フェーズの成果である”実証されたアーキテクチャ”マイルストーンは、ハイリスクな要件を早期に実装しエンド−トゥーエンドで機能するシステムのスケルトンを構築することによって、プロジェクトの技術的リスクを早期に減少させることができた。が同時にフェーズをひとつ設けることに伴う官僚主義的な諸事にも対処しなければならなかったからだ。
 Q)移行フェーズからのフィードバックループはあるのか?
 ある。ハイレベルのライフサイクル図では示しているが、各論での詳細な図には示していない。この質問はよくいただくので、これらの図はアップデートされる可能性がある。

DADと他のメソッド

Q)DADとスクラムとの比較
 スクラムと異なる点として以下を挙げておこう:
  1. カバーするライフサイクルの幅が広い:DADはライフサイクル全体(※full delivery lifecycleは翻訳中)をフルにサポートする。つまり、スクラムでの構築ライフサイクルに留まらずに、アジャイルプロジェクトの立ち上げをどう効果的に進めるか、本番環境にどのように移行/リリースしていくかまでカバーする。言い換えると、実際に現場でアジャイル開発に携わるスタッフがどう振る舞っているかという疑問を払拭する助けとなっている。
  2. エンタープライズ対応にフォーカスしている:スクラムの強みはプロジェクトチームにおける振る舞いという内向きにフォーカスを合わせることで、集中を妨げる要因を最小化し、チームが利害関係者とコミットしたモノをデリバリーすることにフォーカスすることを可能にしている。様々な概念ープロダクト・オーナーという役割、同じ場所、ホールチーム(whole team)、デイリースクラム等ーによって、目的が達成される。しかし、この内向きなフォーカスと自立は、エンタープライズとして考慮しなければならない諸処ー基本となるガバナンスやアセットやパターン、テンプレートやガイドラインの再利用ーを無視して、チームがサイロ的な振る舞いをするよう進みがちだ。アーキテクチャとシステムとが、メンテナンスしづらい相容れないモノへとなっていくのが関の山だ。DADは、チームに対しエンタープライズの事情を意識するよう働きかけるし、アーキテクチャ・オーナーという役割を組み込むことを推奨し、エンタープライズでの良いプラクティスを無視せず必要に応じてプロジェクトとエンタープライズレベルの権威(訳補足:エンタープライズ・アーキテクトなど)とのコラボレーションを強く推奨している。
  3. より広範囲のプラクティス:DADは様々なソースースクラム、XP、アジャイル・モデリング、カンバン、アウトサイド・イン・デベロップメント(OID)、その他多くの手法ーから戦略を取り入れたハイブリッドなディシジョン・プロセス・フレームワークであり、それら戦略をどううまく組み合わせるかを提示している。(スクラムがやっているように)デリバリープロセス全体の中の極一部にフォーカスする代わりに、DADはより広いスコープを扱い、結果としてより堅牢で効果的なガイドをアジャイルチームに提供している。
  4. 少ない規定:DADはゴール駆動アプローチを推奨している。このアプローチでは、効果的なテーラリングやスケーリングを可能にしている。DADプロセルゴールにひとつ、”利害関係者のニーズの変化に対処する”を考えてみよう。スクラムが定めているたったひとつの方法はプロダクトバックログだが、DADはいくつかのオプション(プロダクトバックログ、ワークアイテムリスト、ワークアイテムプール、公式な変更管理プロセス)を提示している。この際、各々のストラテジーをいつ検討するかへのアドバイスも同時に提示している。また、DADはワークアイテムリストープロダクトバックログを強化したものだがーをデフォルトとしているが、これは良い開始点となる。別のゴール、”アクティビティを調整する”の場合はどうだろうか?スクラムは15分のデイリーミーティング(”デイリースクラムミーティング”や”デイリースタンドアップ”等と呼ばれる)を規定しているが、DADは適用可能な複数のオプションを提示し、読者にとって正しいアプローチをどうやって選択するのか、そのウォークスルーを示している。
  5. 少ないブランディング:DADを記述するときに筆者達が採った哲学のひとつは、アジャイルコミュニティにこれまで見られた”プロセスのブランディング”を避ける、というものだ。DADは出来た当初から用語について柔軟だった。例えば、”イテレーション”の代わりに”スプリント”を使いたければ、気にせずに使えばよい。DADは用語をブランド化していない。だから、筆者達は例えば”スクラムミーティング”ではなく”調整ミーティング”を使い、”スクラムマスター”ではなく”チームリード”を使い、”スプリントふりかえり”ではなく”ふりかえり”を使う。
 スクラムはこれからアジャイルを始めようとスタートラインに立っているチームには良いものだと考えている。しかし、スクラムを採用する組織は、これまで述べてきた類いのチャレンジに対処するためにスクラムを拡張することにかなりの労力を費やすか、あるいはDADを採用することでジャンプスタートを果たすのかのどちらかであると知ることになる。筆者達は、スクラムからよりディシプリンドアジャイルのアプローチへの移行をサポートすることができる。
Q)SAFeとの比較
 DADとSAFeは補完的な関係だ。SAFeはひとつの組織内でアジャイルをスケーリングすることにフォーカスを合わせている。一方DADは、複数からなる大きなチーム、分散した拠点、その他諸々のスケーリングファクターによって作り出される複雑さを扱うために、アジャイルをスケーリングする戦略の強固な基盤を提供することにフォーカスを合わせている。DADはSAFeにおけるプログラムレベルに容易にフィットさせることが出来る(SAFeはプログラムレベルではスクラムを提示しており、DADはスクラムを拡張しているからだ)。実際にエンタープライズ対応(enterprise awareness)とゴール駆動アプローチという明確な論点を提示しており、筆者達はこれらがDADをスクラムよりもSAFeに合わせやすくしていると考えている。面白いのは、DADとSAFeどちらも、統一プロセス(UP)をバックグラウンドに強く持っている人達から生まれていることだ。
Q) DADとラショナル統一プロセスとの比較
 DADはハイブリッドなプロセスディシジョンフレームワークであり、RUPがカバーしていた領域とその多くが重なる。DADは統一プロセス(UP)からいくつかアイディアを、特にガバナンスとリスク削減アプローチを採り入れており、同時にRUPの実装でよく見られたチャレンジの多くを避けている。不幸なことだが、RUPはあたかもウォーターフォールプロセスであるかのように誤解して実装されたことが珍しく無かったし、さもなければとても重量級のやり方として実装されたことも多かった(あるいはその両方も)。DADの立ち上げでは、(RUPの4フェーズに代わり)3フェーズライフサイクルとゴール駆動アプローチを通して前述の誤りを避ける。これらが重量級プロセスにまつわるチャレンジを解決する。より詳しい議論はDADとRUPを比較してPart1、同じくPart2(※訳注:どちらも未訳)をお読みいただきたい。筆者達はRUPからDADへ効果的に移行する手助けをすることが出来る。
Q)DADとIBMAgility@Scala戦略との比較
 DADはIBM Agility@Scala戦略から現れたもので、未だにAgility@Scale戦略の欠くことの出来ないパーツである。その上、DADフレームワークはIBMでその基礎が作られたが、現在ではディシプリンド・アジャイル・コンソーシアム(DAC)が提供している。
Q)DADとCMMIとは共に使えるか?
 筆者達はCMMIを、プロセスに対する仕様のように考えたい。CMMIは、SEIが信じる「プロセスに対するよく練られた要件のセット」であって、実装はあなた次第だということだ。だから、CMM-に準拠したプロセスは、ウォーターフォールのパラダイムにも(実際に頻繁にそうなる)、アジャイルのパラダイムにも(たまにそうなる)、その他のパラダイムにも準じる。CMMI-準拠のプロセスは重量級に始まることも(頻繁にそうなる)、軽量級で始まること(たまにそうなる)もある。あなた次第なのだ。
  その一方で、DADは、ソリューションのデリバリーw、アジャイル/リーンのお作法でどのように進めていくか、より具体的にアドバイスを提供する。またあなたが置かれているコンテキストに応じて適切なアプローチを採る助けとなるよう、より具体的なテーラーリングのアドバイスを提示している。あたなは、これを行うためにCMMI準拠のやり方をしてもよい。実際、筆者達はコンプライアンスを潜在的な助−リングファクターとして明確に位置付けており、DADをテーラリングするにあたっての意思決定を左右する要素とみている。
Q)PMI/Princeとは一緒に使えるか?
 DADのスコープはソフトウェアベースのソリューションである。だから、答はYesとなり、プロジェクト管理の一連の活動を包含する。よいニュースは、PMIやPrinceのような戦略はよりアジャイルへと移行しているということ。悪いニュースはそれがまだ道半ばであることだ。これが暗に意味するのは、組織にいるプロジェクト管理者達と一緒に仕事をするときには彼らがもっとアジャイルな仕事のやり方を理解し実践できるように、助けてあげなければならないということだ。

DAD とスケーリング

このテーマについては、Agility at scaleも併せてご参照いただきたい(※未翻訳)。
Q) DADは小規模で同一場所で作業するチーム向けか?
 イエス。事実、DADフレームワークのもっともありふれた構成がこれだ。DADのプロセスゴールで提案されている、そしてデフォルトの選択肢は事実このような構成で作業するチームをターゲットにしており、これにより読者が自身の置かれた状況とニーズに合わせて、より短期間でプロセスをテーラーリングすることを可能にしている。
Q) DADは大規模チームでも有効か?
 イエス。DADフレームワークは様々なサイズのチームに適用されつづけている。小規模なチームから数百人の人々からなる大規模プログラムのレベルまで。様々なチームサイズを扱うためにDADをどうテーラリングするかについての議論は、Large Agile Teams(※未翻訳)を参照いただきたい。
Q) DADは地理的に分散したチームでも機能するか?
 イエス。DADフレームワークは様々な分散体制に適され続けている。同じ場所で働くチームから一部かちりぢりに分散したチーム、さらに分散したチームで全体が構成されるチーム、サブチームが分散したりそれらの組み合わせ等々。このような状況でのテーラリングについての議論は、地理的に分散したアジャイルチーム(※未翻訳)を参照いただきたい。
Q)DADは、他のスケーリングを必要される状況にも対応できるか?
 イエス。チームサイズや地理的な分散にとどまらず、読者のチームが考慮すべきスケーリングファクターを複数挙げている。例を挙げると、ドメインの複雑さ、技術的な複雑さ、組織の分散度合い(アウトソーシングがその例)、コンプライアンス要件だ。これらのファクターに対してDADをどう扱うかについては、筆者達はその詳細を現在記事に起こしている。

一般的な質問

Q)なぜDADなのか?
 DADフレームワークに注意を払うべきと思う理由はいくつかある。
  • それはソフトウェアデリバリーをスケールさせる際の基礎を提供する。
  • すべての状況に対応するたった一つの戦略(例えばアジャイル/スクラム、リーン、SAFe)など存在しない。人々は成功のチャンスを最大限活かすために、様々なレベルで多くのプロセス上の意思決定を行う必要があるだろう。
  • 全員がプロセスのエキスパートというわけではない。DADは、よりよい意思決定をリードすることができる。
  • DADは実践的(Pragmatic)である。教条的(Dogmatic)ではない。
Q)他のフレームワーク/メソッドと、DADは何が違うか?
 他のオプションと異なるのは、DADが”規範的(prescriptive:あらかじめ規定されている)”フレームワークではないという点だ。DADはプロセスディシジョンフレームワークであり、ユーザの状況特有のコンテキストに対してより良い決定を下すことを助ける様々な戦略を提供している。
 筆者達はSAFeのような単一のフレームワークがスケーリングが必要とされるあらゆる状況に対してベストな解となるとは信じていない。例えば、大規模なアジャイルチームを編成する方法にはいくつかある(単一の大きなチーム、複数のフィーチャーチーム、複数のコンポーネントチーム、そしてそれらのハイブリッド)。DADは一つの戦略を規定する代わりに、与えられた状況で意味のある戦略を選択するためのガイドを提示する。同様に、読者は自身の戦略を進化させていくだろう、例えば地理的に分散したチーム体制であるとか、直面している複雑さの度合いや、チームの文化、コンプライアンス要件への対応や分散した組織でのチーム編成(アウトソースする場合がこれにあたる)、その他もろもろに応じて。kこれに関する詳細な考察については、Software Development Context Framework (SDCF)(※未翻訳)を参照いただきたい。
 DADのプロセスゴール駆動アプローチは、読者の選択をあいまいさのない明らかなものにする。その明快はガイダンスは、読者のプロセスでとりうるオプションを浮かびあがらせ、そのトレードオフを理解する助けとなる。これにより、ふりかえりでチームのムードを高める効果がある。このようなアプローチを用いることで、自身のプロセスを実際に所有するということがより簡単に実現できる。
 ゴール駆動戦略の興味深いところは、ほとんどの状況では疑わしい戦略を表に出していることだ。例えば、ライフサイクルの早い段階で詳細な要件仕様を作成するといったような。この戦略はある環境、例えばライフクリティカルな規制が存在する環境下では意味があるかもしれないが、ほとんどの状況では理想からは程遠い。DADフレームワークはこの戦略の有利な点(多くはない)と不利な点(たくさんある)を明確にし、望むらくは、そのアプローチをいまだに信じている人々に自分たちがとっているリスクへの洞察を提供できれば、と考えられている。 より重要な点はDADはより良いオプションへのガイダンスを提供し、プロセス改善へ着手するよう促すことができればよいと狙っている。
Q)なぜDADにはプライマリーロースとセカンダリロールがあるのか?
 プライマリーロール(チーム・リード、チーム・メンバー、プロダクト・オーナー、利害関係者アーキテクチャ・オーナー)は、ほとんどのアジャイル開発の現場で目にするだろう典型的なロールだ。セカンダリロール(ドメイン・エキスパート、テクニカル・エキスパート、スペシャリスト、インテグレータ、独立テスター)は、スケーリングが行われる状況で必要に応じて設けられる。
Q)それでもまだ間違いは犯しうる?
 イエス。保証などない。しかし、筆者達はDADフレームワークは、ライフサイクル全体のサポートとプロセス・ゴール駆動アプローチ、そして広範囲なソース(非アジャイルもふくめて)から得たアイディアのハイブリッドという事実は、これまでよりも情報に基づいたプロセス上の意思決定を行う助けとなると信じている。
Q) DADの”いけてないところ”はなにか?
 潜在的にある課題を以下に挙げよう。
  • DADは、ソリューションデリバリーにおける複雑さを明確にするが、それは「やることだけを教えてくれ」というシンプルなアプローチを探している人を圧倒してしまいがちだ。これに対処するため、DADは着手点となるデフォルトの選択をいくつか提案している。それらの多くはスクラムで推奨されているモノによく似ている。
  • DADはそれ自身まだ生まれたばかりであり、他のフレームワークほどよく知られているわけではない
Q) DADをサポートしているツールには何がありますか?
 Tool Support for DADに紹介しているので、参照いただきたい。
Pocket

DevOps戦略:エンタープライズ・アーキテクチャ − DDevOps#12

devops-practices-enterprise-architecture1
DADフレームワークは、アーキテクチャに関連する活動や、アーキテクチャ/オーナーという役割を明確に定義しており、エンタープライズ対応(Enterprise-aware)という哲学を前面に打ち出している。我々の経験では、ディシプリンドDevOpsの考え方を組織に適用するにあたって、アジャイル・エンタープライズ・アーキテクチャは、実現のための鍵となることが実証されてきた。
一般的なDevOps戦略に加えて、DevOpsをサポートするエンタープライズ・アーキテクチャの活動がいくつかあるので、以下に見ていこう。
  • 再利用のマインドセット エンタープライズ・アーキテクチャの労力が将来に実を結ぶために重要なことは、IT部門、そして組織全体に再利用のマインドセットを定着させることだ。再利用のマインドセットが定着したデリバリー・チームは、既存のデータソース、サービス、コンポーネント、フレームワーク、テンプレート、および他の多くの資産を活用するように努めている。このマインドセットは、エンタープライズ・アーキテクト(理想的には、アーキテクチャ・オーナーとしてITデリバリー・チームのアクティブメンバーであることが望ましい)による教育、コーチングとメンタリングを通して植え付けられる。また、ITデリバリー・チームが使うべき、あるいは使用すべきではない技術を示す技術ロードマップによって可能となる。そしてもちろん、発見しやすく理解しやすく、適用して真の価値を提供できる高品質なアセットの存在が再利用を可能にする。
  • 技術的負債のマインドセット エンタープライズ・アーキテクチャの取り組みでは、デリバリーチームが技術的負債を発見した時にその負債を返済するよう、彼らを動機付けるアプローチを推進すべきだ。さらに重要なのは、最初の段階でそのような負債をかぶらないようにすることだ。多くの技術的負債戦略が、DADフレームワークに埋め込まれているが、技術的負債のマインドセットなしでは、無駄に終わることが珍しく無い。エンタープライズアーキテクト(しばしば、デリバリー・チームのアーキテクチャ・オーナーとして機能する)は、技術的負債に関連する問題を中心に、開発者をコーチし、メンターとしての役割を果たす必要がある。同様に、この技術的負債にかかわってコラボレートする、よりシニアなマネージャーや利害関係者を教育するために役立つはずだ。技術的負債を回避し取り除くためには投資が必要であり、普通IT投資の判断は彼らの手にあるからだ。
  • 開発のガイドライン エンタープライズ・アーキテクチャの重要な側面は、ITデリバリー・チーム全体で共通の懸念に対処するためのガイドラインの開発である。組織は、セキュリティガイドライン、接続のガイドライン、コーディング標準、および他の多くを開発することがある。共通の開発ガイドラインに準ずることで、ITデリバリーチームはより一貫性のあるソリューションを構築し、それは転じて本番稼働時により簡単に操作できサポートできるソリューションとなり、DevOps戦略をサポートする。共通の開発ガイドラインの潜在的な欠点は、開発者がそれらによって制約を感じるかもしれないということだ。この問題への対抗策は、ガイドラインはデリバリーチームとのコラボレーションを通して開発され進化されるべきであり、上から課せられるべきではない。
  • 技術ロードマップ エンタープライズ・アーキテクチャでは、技術ロードマップの定義、サポート、そしてそれを進化させるという活動が含まれ、そのロードマップが組織の他の活動(同様に重要なビジネスのロードマップはプロダクトマネージメントの範疇)をガイドする。このロードマップは、本番環境に共通の一貫した技術的インフラストラクチャーを構築することを助ける。この技術インフラが共通のDevOpsプラクティス―継続的デプロイ、自動化されたエンドトゥエンドのリグレッションテスト環境、以前のブログでも議論した運用のモニタリング―を実現するのだ。
技術ロードマップの重要な側面は、既存のITインフラストラクチャと、そのインフラの将来ビジョンの両方を捉えることだ。ここでITインフラとは、ネットワーク、ソフトウェアサービス、サーバ、ミドルウェア、および主要な構成要素となる少数のデータ・ソースが含まれている。以下の図に見られるように、技術インフラへのビジョンを作る際、考慮すべき2つの問題があります。
  1. オーナーシップ あなたの組織は自身のインフラストラクチャを所有し運営するのか、あるいは外部の専門家にその一部または全部をアウトソースするのだろうか?アウトソーシングオプションには、他の組織(HPやIBMなど)が外部の組織(AmazonやGoogleのような)が提供するクラウド技術を使ってあなたの会社のデータセンターを運用するという従来のアプローチも含まれる。独自のインフラを所有することの利点は、かなりの部分をコントロールできることだ。これはITソリューションのセキュリティと整合性を保証しなければならないときに非常に重要だ。アウトソーシングは、潜在的に規模の経済からITインフラストラクチャとコスト削減を管理する上でより大きな柔軟性をもたらす。しかし、アウトソーシングは、より洗練されたガバナンスを必要とし、前述した従来のアプローチの場合には、アウトソーサーがあなたの要求にタイムリーに応答できない場合、潜在的なボトルネックになる。
  2. 仮想化 特定のソリューションのニーズを満たすために構築された、あるいは可鍛性(※訳注)と進化のしやすさを実現するためにソフトウェア化(softwarization)されたITインフラストラクチャの構成要素があるか?ソフトウェア化―ソフトウェア定義インフラストラクチャ(SDI)として知られている―では、ITインフラストラクチャの要素が完全に仮想化される。ソフトウェア化は、ソフトウェア定義データセンター(SDDC)、ソフトウェア定義(SDS)、およびソフトウェア定義ネットワーク(SDN)を包含したITインフラストラクチャモデルを含む。ソフトウェア化は、通常、ファイアウォールの両側で、クラウドベースのテクノロジを使って実装される。さらに進んだ仮想化のソリューションでは、ITインフラストラクチャの柔軟性とプログラマビリティを高めており、それによってリソースの最適化を可能にする。その一方で、仮想化がもたらすより大きな柔軟性は、あなたのテスト作業の複雑さを増加させ、運用での課題をシミュレーションすることをより難しくする。
    ※訳注 ”可鍛性”:原文では”malleable”。外的圧力を受けても破壊されることなく変形できる能力。ここでは、ビジネス等の外部環境の変化に呼応して変化できる柔軟性という意味。
ITインフラ戦略クアドラント
オリジナル:DevOps Strategies: Enterprise Architecture
(翻訳 藤井智弘)
Pocket

DevOps戦略:データ管理 – DDevOps#11

devops-practices-data-management1
 ディシプリンド・アジャイル・デリバリー(DAD)フレームワークにおけるデータ管理とは、データ指向アーキテクチャ、ポリシー、およびプロセスに焦点を当てた、実行(Run:運用)時の活動を意味する。組織の、データを核とした諸々の活動に対する長期にわたる計画作成の取り組みは、エンタープライズアーキテクチャの取り組みの一環であることに注意しよう。
 同様に、組織のエコシステムのデータまわりの開発は、ソリューションデリバリー・チームによって為される。
データ管理は運用業務の重要な要素なので、ディシプリンドDevOps戦略の影響を被る。経験によれば、以前紹介した一般的なDevOps戦略に、以下に挙げるようなDevOpsをサポートするデータ管理戦略を加える必要がある。
  • データと情報に関するのガイドライン 開発と、データや情報ソースの応用利用との間により高度な一貫性を確保するための直接的な方法は、チームが利用する共通のガイダンスを策定することだ。このガイダンスには標準ポリシーとガイドラインの両方が含まれる。利用者間のコラボレーションとオープンなやり方で定義され、サポートされ、そして時を経て進化し続ける。
  • 質の高いデータソース ファイル、データベース、およびデータフィードなど、本番のデータソースは、簡単に利用出来る高品質なアセットであるべきだ。データソースに記録された後、それらのレコードが高品質であることは特に重要で、それがあってこそそれらは簡単に利用され、進化するのだ。残念ながら、多くの組織では、これは空想の域を出ていない。ディシプリンドDevOpsの考え方では、チームはデータソース内の技術的負債を増やすことについては非常に注意を払い、彼らが見つけた技術的負債を返済するための払う労力に投資することがより重要である。
  • ITインテリジェンス ITインテリジェンスは、データウェアハウス(DW)/ビジネスインテリジェンス(BI)ソリューションの作成・サポートとその進化、そしてオペレーションという相対的な活動である。これにより、あなたの会社のIT活動全般の管理とガバナンスをサポートする。ディシプリンドDevOpsの観点から見ると、ITインテリジェンスには、2つの重要な側面がある:デリバリーチームがどのように機能しているかへの洞察を提供する開発インテリジェンスと、運用で何が起きているのかを提示するオペレーショナルインテリジェンスだ。多くの開発プラットフォームが提供する自動化されたチームのダッシュボードは、開発インテリジェンスの単純な形態だが、より洗練された(そして有用な)ものは、様々な開発ツールからの情報を統合し、統合ダッシュボードに表示するものだ。さらに有用なのが異なるデリバリーチームからの情報を集約/統合し提示するポートフォリオマネージメントダッシュボードだ。
    同様に運用チームも各々のソリューション毎に独立したダッシュボードを持っている。各々のソリューションによって生成された情報を結合し
    統合されたダッシュボードに提示したり、ITポートフォリオマネージメントビューで共有すればさらに有用なものとなる。
次回は、エンタープライズアーキテクチャに関連するDevOps戦略を検討する。
オリジナル:DevOps Strategies: Data Management
(翻訳 藤井智弘)
Pocket