作成者別アーカイブ: 藤井 智弘

藤井 智弘 について

DADの推進がほぼ本業のようになっている私。自由すぎるぞ!

【告知】PMI日本支部主催研修「ディシプリンド・アジャイル基礎」開講

昨年8月にDAがPMIに買収されてから早8ヶ月、日本での啓蒙策についてPMI日本支部の方と相談してきましたが、晴れて新年度から、基礎編の1日研修を開講する運びとなりました。
初回開催は4月22日を予定しており、すでに申し込みサイトが立ち上がっています。

”PMI日本支部主催アジャイルPM研修「ディシプリンド・アジャイル基礎」”

講師は私(藤井)が担当させていただきます。

アジェンダは以下のように考えています。

  • ディシプリンド・アジャイル概要
  • DAステップバイステップ:方向付けと移行
  • DAステップバイステップ:構築フェーズ
  • DAステップバイステップ:スケーリング

1日研修ですから、DAの初学者を対象に、全体像とアジャイルライフサイクルを通して、DAを理解するという立て付けになっています。

この類いのイベントはコロナ騒動の関係で開催されるか否かがなかなか難しいところはありますが、この記事を書いている3月14日時点では開催する方向で進めていますので、興味をある方は受講をご検討ください。

 

注意:このコースはPMIの公式コースなので、PDUは交付されます。ただし、DAの認定取得用の教育ではありませんのでご注意ください。

藤井 智弘 2020.03.14記

Pocket

Mark Lines氏によるオンラインセミナーが開催されました。

3月14日、PMIのDAバイスプレジデントであり、DAの創設者の一人であるMark Lines氏による、オンラインセミナーが開催されました。

https://www.pmi-japan.org/event/open_seminar/pm/2020_03_03_da20200314.php

元々は、3月上旬に来日されるはずでしたが、現在のコロナウィルス騒動の関係で急遽変更されたモノです。

土曜日の午前中にもかかわらず、2百数十名の方が参加されました。参加されたみなさん、お疲れ様でした。

今回のセミナーは、PMI会員以外にも広く門戸を開いて行われ、録画もされています。今後、以下のようなフォローが行われるとのことです。

  • 動画の公開
  • セミナー中にはチャットで質問が寄せられましたが、すべてに回答することは時間的に難しかったので、後日回答が公開されます。

動画と質問回答の公開に合わせて、ごくごく私的な補足解説をこちらでブログにアップしようかと思っておりますので、ご用とお急ぎでない方、コロナショックで暇つぶしの方策が尽きた方、ご利用いただければと思います。今しばらくお待ちください

藤井 智弘 2020.03.14 記

Pocket

PMIとDisciplined Agile最新情報(2019.11)

Disciplined Agile コンソーシアムが運営する会員向けメーリングリストでは、定期的にレターが配信されるのですが、去る11月6日のレターでいくつか情報が提供されたので、こちらにご紹介します。

その前に・・・

【新しいロゴ】

  • DAの新しいロゴマークが出来ましたw。それがぁ〜こちら!

pmi_prdsrv_pmp_logo_hrz_fc_rgb

・・・はい、次行きますw。

【PMIの現時点でのプランや意向】

  • PMIからは推進プランがいろいろ出てきているみたいです。ざっと挙げると・・・
    (“※”印は、翻訳者による補足です)

    1. 現行のDAパートナー制度が、新しい形(※詳細は不明)でPMIへと統合されます。
    2. 2020年末までに、DAのインストラクターを全世界で200人以上に増やします。
    3. PMIの世界中の支部(300に及ぶ)で、DAのエキスパートを育成する”DAチャンピオンプログラム”が導入されます。
    4. 新しい認定プログラムが予定されています。まずは、2020年1月からDAリーンスクラムマスター(DASLM)、それ以降DAリーンプロダクトマネージャー、DAプログラムマネージャーが予定されています。
    5. 最近PMIが獲得したFLEX(バリューストリームの最適化し、SAFeチームを進化させたり、他のスケーリングアプローチを含む)のコンテンツを統合させます。
    6. 2020年1月以降、世界中でDAワークショップを企画しています。
      (※:このワークショップはDAコンソーシアムのころから行われており、Web上でスケジュールも公開されていましたが、それを継続していくという意味。いまのところアジア圏での現地開催は予定されていませんが、ネット上でのバーチャルな会は予定されています)。
    7. 3タイプのトレーニングが1月以降提供される予定です。
      • ILT(※講師が対面で行う、いわゆる”教室での講義”)
      • ヴァーチャルライブトレーニング(※:ネットで参加する、録画ではない講義)
      • コンピュータベーストレーニング(※:録画のオンライン教育)
    8. DAの知識ベースがリファクタリングされます。デリバリーチームの周囲の利害関係者や非IT分野での利用を意識して、拡張しやすいものにすることが目的です。
    9. キャリアパスやスキル開発のための、長期視点での認定プログラム制度が提供されます。
    10. 上記のイニシアティブをサポートできるよう、(※DAコンソーシアムが所有している)バックエンドのシステムやWebサイトをPMIのシステムに統合する。

 

【日本では・・・】

DAD本の翻訳を起点にこのDAD2.0に合わせてボランティアで翻訳を進めてきたこのサイトですが、上記の方針を受けて、PMI日本支部の方と顔合わせの会を持ちました。詳細はまだ開示できませんが、大まかに言うと、次のような感じ

  • DAの日本での紹介・導入について、PMI日本支部と筆者(藤井他)は、今後協力を密にしていくことで合意しました。可能性としては、セミナー、教育コース、書籍等々いろいろ考えられますが、まだ話が始まったばかりなので、今後詰めていきつつ、いろいろ決まり次第告知させていただきます。
  • 当サイトの維持管理については、まだ会話が始まっていません。上記8にあるように、DAの知識ベースのリファクタリングが始まっており、おそらく書籍も変わってくると思われるので、それらの様子を見ながら、日本語版サイトの同期については、(誰がやるかも含めて)今後PMI日本支部と相談になると思います。
  • 当サイトの更新の方針が決まるまでは、このまま公開を続けておきます。プロセスコンテンツそのものにはあまり手を入れるつもりはありませんが、最新情報は出来る範囲(=許される範囲)で投稿していきます。

 

【個人的な所感】

上記の計画を見ても「がっつりやる気だな」という感じが伝わってきますが、今回それをさらに実感したのが、PMI日本支部と(おそらくその上位の)アジアパシフィック(以降AP)の反応の早さでした。

買収されたばかりで知財の扱いについては日本支部側でもまだ把握しきれていないご様子。

  • 「セミナーで使う資料が厳密に指定されて改変はまかりならん」とかなんとか
  • 「認定を受けていないやつが、公の場で好き勝手話したらあかん」とかなんとか

なんてことをこちらは心配し、日本支部の方に確認したところ、「APのほうに確認する必要あり。ただし返事が来るのは2〜3週間」と言われていたのですが・・・確認の問い合わせをしていただいたところ、APからは即日の返信で、しかも、

  • ”協力歓迎”
  • ”日本でどんどん進めて良い”
  • ”全面的にサポートするよ”

的なキラキラ美しい文言が。

どうやらScott Ambler氏/Mark Lines氏がAPの担当者と話を通していてくれたらしく、筆者が予想していた以上に(そして心配とは真逆に)、スムーズ&前向き&サポーティブでした。

・・・ということで、PMI日本支部と密に協力しつつ、DAのメリットを享受する人をさらに増やすべく、微力ながらお手伝いさせていただこうと、想いを新たにした昨今でございますmOm

藤井智弘 2019.11.16記

 

 

Pocket

PMIがDisciplined Agileを獲得(Acquire)しちゃったとは:当サイトへの影響諸々

当サイトを主宰している藤井です。

ご無沙汰しております。

長い拘束時間の案件も一段落し、すっかりほったらかしになっていた当サイトのメンテナンスも、USに合わせた4.0化へと動き始めたばかりの8月9日、こんなニュースが・・・

Project Management Institute Announces Acquisition of Disciplined Agile.
Expands Offering for Project Managers and Teams to Choose Their “”Way of Working”

いやぁ、世の中、なにが起きるか分かりませんね。

詳細はまだ分かりませんが、当面起こりそうな当サイトへの影響はつぎのものかと。

1)一部のコンテンツは、4.0版への更新に着手していました(すでに作業予定表があったりする)。もっとも、そもそもアナウンスもしていませんし、このサイトをご利用のみなさんへの影響は低いかと。

2)それよりも、そもそもメンテナンス出来なくなるかもしれない。
個人的にPMIとのつながりがないので、どういう考え方をするみなさんかわからないのですが、DAがPMIの持ち物となったことで、PMI所有のサイト以外での翻訳が禁じられるかも(根拠はありません。ただ、最近アジャイルも、認定や権利がビジネスになっているので、可能性はあるかなと)。

3)ちょっと画策していたDAD本第2版(WoW本ですね)の翻訳はますます難しくなったかな。

ま、しばらく様子見つつ、つてを使っていろいろ情報収集(→このサイト継続の可能性も探る)しようかと思います。だめになったらなったで、そのときはそのときだぁあ。

藤井智弘 2019.08.11記

 

 

Pocket

DAD説明会は、”怖い”のか?

さる10月24日、縁あってQConTokyo2016で、ディシプリンドDevOpsをネタにしたセッションの機会を頂戴しましたが、その後の懇親会の場である方に言われたのが、
DAD説明会への申込みは、”怖い”と思われているのではないか?
という点。すでに数件依頼をいただいていたので、
へ? ”怖い”?
って感じだったのですが、その方曰く、どうやら怖いと思われる要因は以下の2つのようで・・・

  1. ベンダーに勤めている人がただで説明会に来てくれるってこと自体が、なんだか”怪しい”。その後どどどって、営業がやってくるのではないか?
  2. 講演料とか払わなくてもいいのだろうか?なにか魂胆があるのではないか?

「うーむ、みんなそんなに筆者のことを理解しているのか」・・・じゃなくて、「おじさんは、怖くないんですよ〜」と理解していただくために、ちょっと補足説明しておきます。

まず、1について。
ご依頼いただいた場合には、基本的には筆者(ヒューレット・パッカード所属)が伺いますが、スケジュール等合わない場合には、DAD本翻訳メンバー(ゼンアーキテクツさんとか豆蔵さんとか)に依頼することもありえます。その意味でも特定のベンダーやツールに依存した話はありません。
説明会の趣旨はあくまでもDADをご理解いただくことにあり、DADを売りに伺うわけではありません。DADの有効性を理解いただきチャレンジする方が増えていけば、自然とビジネス機会が増えていくという捉え方です。ですから、筆者もこの活動に関する限り、交通費等のコストはすべて自前でやってます。

で、2.の費用面について
まず、講演料を頂戴することを前提条件にしてはいません。あくまでもボランディアですから、無料でも全然結構です。もちろん、「払いたい」と言っていただいたものをむげにお断りするような非人道的な振る舞いに及ぶことはありません。その額の多寡によって講演者の熱意・集中力・説得力等が影響を受けることは、たぶん、おそらく、あまりめったにありません(と予想はしていますが、確信となると・・・)。

ただし、以下の場合には、費用負担をお願いする可能性が高いです。
・ちょっと交通費がかかっちゃう場合
一応、都内(23区周辺)を前提に考えているので、交通費がやや多めにかかる場合、実費程度のご負担をお願いする可能性は高いです。あらかじめご承知おきください。

・宿泊が必要になる場合
例えば、時間帯によっては講演後宿泊が必要になる場合もあるでしょう(大阪で午後8時開始みたいな)。交通機関の発達した日本ですから、日帰りできるエリアはかなり広くなっていますが、そういうセッティングはできるだけご勘弁を。

あ、もうひとつ。これまで、「ボランティアなので出来れば夕方で・・・」と申込みページに書いていましたが、「一緒に開発するベンダーさんも含めて聞きたいから、早い時間で出来ないか」とリクエストされることもあり、今後午後の早い時間での開催リクエストにも対応させていただくことにします。

 

・・・ということで、敷居は低く設定していますので、ぜひ遠慮なさらずに気軽にお声がけくださいませ。

記)藤井智弘

Pocket

QCon Tokyo2016で、ディシプリンドDevOpsの講演やります。

来る10月24日 QconTokyo2016(http://www.qcontokyo.com/)というイベントで、ディシプリンドDevOpsについて講演する機会をいただきました。

タイトルは、「DevOps導入&実践の落とし穴ーDisciplined DevOpsに見る体系的アプローチ」

DADのDevOpsについては、すでにブログのほうで連載モノを翻訳&公開していますが、DA2になって正式なコンテンツとして組みいれられています(現在翻訳中)ので、それと連動した内容にしようと思っていますので、ご興味のある方は是非。

いちおう筆者の所属する会社(日本ヒューレット・パッカード株式会社)の人として出るので、一部会社の戦略やアプローチが入りますが、基本はDADベースで。

Pocket

DA2.xサイト リニューアルにあたり。

書籍「ディシプリンド・アジャイル・デリバリー エンタープライズアジャイル実践ガイド」を翻訳した流れで立ち上げたこのサイトですが、DADが無事2.0(そしていまは2.x)へとバージョンが上がったのを受けて、本サイトもそれに合わせてリニューアルしました。

「なるべくたくさんのコンテンツを翻訳してお届けしたい」とは思いつつ、ボランティア活動の悲しさ、すべては無理だと思っています。当面、次の観点から翻訳対象を決めています。

  • メニュー項目から直接リンクされているコンテンツ(これを1stレベルとする)をターゲットとし、1stレベルのコンテンツ内に他投稿へのリンクが貼られている場合には、リンク先は翻訳対象とはしない。
  • ただし、DADの根幹にかかわる概念を説明する投稿については、その重要性を鑑みて翻訳することもある。
  • 書籍で提示されているコンセプトよりも、DA2として拡張されたコンテンツの翻訳を優先する。

ということで、まだまだ未成熟ですが、「DADは進化する」を言い訳にご容赦いただきつつ、ぜひご活用あれmOm

(藤井智弘)

 

 

 

 

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