旧ブログのアーカイブ（アジャイル編）

はてなブログに移行する前の過去ブログについては、サイドバーのリンクから閲覧可能になっていますが、古い記事の一覧性が弱く、また記事内容も種々雑多なものが混在しているため、改めて、アジャイル関連のエントリについて主なものを抜粋してリンクのリストとして公開しておきます。

2009年

Always All Ways: [IT] PMIとScrum/Agileの動向

2010年

Always All Ways: [IT] 要求開発の３つのT
Always All Ways: [IT] Scrumと要求開発
Always All Ways: [IT] ScrumもKanbanも問題を解決してはくれないよ
Always All Ways: [IT] ふりかえりの話とアジャイルコーチマニフェスト
Always All Ways: [IT] 100語でScrumシリーズ
Always All Ways: [IT] CMMIベースの改善フレームワーク
Always All Ways: [IT] アジャイル、入っている...
Always All Ways: [IT] 認定スクラムマスターへの道（その１）
Always All Ways: [IT] 認定スクラムマスターへの道（その２）
Always All Ways: [IT] 第１回すくすくスクラム瀬戸内
Always All Ways: [IT] 認定スクラムマスターへの道（その３）
Always All Ways: [IT] 近頃じわじわ来るものについての雑感
Always All Ways: [Translation] "An Introduction to Planning Poker" by Bob Hartman
Always All Ways: [IT] Acceptance Testingを巡る議論　（備忘メモ）
Always All Ways: [IT] Alan ShallowayのLean-Agile （その１）
Always All Ways: [IT] Alan ShallowayのLean-Agile （その２）
Always All Ways: [IT] 認定スクラムマスターへの道（番外編）
Always All Ways: [IT] 第２回すくすくスクラム瀬戸内を開催した
Always All Ways: [IT] ウォーターフォールの興亡
Always All Ways: [IT] 『アプレンティスシップ・パターン――徒弟制度に学ぶ熟練技術者の技と心得』
Always All Ways: [IT] アジャイルなSIについて

2011年

Always All Ways: [読書] アート・オブ・コミュニティ
Always All Ways: [IT] 継続的改善フレームワークとしてのScrum
Always All Ways: [IT] エンタープライズ・アジリティについて考える (1)
Always All Ways: [IT] AgileにおけるBusiness Analyst
Always All Ways: [IT] BABOK（アジャイル拡張）の歩き方
Always All Ways: [IT] PRIMING KANBAN
Always All Ways: [IT] Business Analysis in Agile Life-Cycles

2012年

Always All Ways: [IT] Scrum GalleryはScrumの「心」
Always All Ways: [IT] Change Management 3.0

Business ValueとCustomer Value

アジャイル開発に限らず、システム開発やそれ以前のビジネス戦略の話なども含めて、いろんな場面で「ビジネス価値」（Business Value）という言葉が出てきます。要求開発宣言でも「情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである」という表現が出てきますし、要件の優先順位を考える時にもビジネス価値はしばしば最重要ファクターとして取り扱われます。

しかしながら、私自身、「ビジネス価値ってなんだっけ？」とか「ビジネス価値ってどうやって定量化できるの？」とか、さらには「ビジネス価値だけで物事を決めていいのだろうか？」といった問いに対する明確な解を持たないまま、その言葉を便利に使い続けてきた感があります。

一方で、ビジネス価値と一緒によく使われる言葉としては、他に「顧客価値」（Customer Value）などもあります。また、かなり以前に（何の研修か忘れましたが）とある研修で、「Win-Winの関係を形成するにあたっては、"Business Win"だけでなく"Personal Win"も考えることが必要」みたいな話を聞いたこともあり、そのあたりもなにか併せて考えないといけないのではないかと思ったりもしていたことも事実です。結局それら（顧客価値や"Personal Win"みたいな概念）も含めたものが「ビジネス価値」に収斂されるという考え方もあるでしょうが、それでも戦略を考える上では、そこは分けて考えなければいけないのではないかと…。

そして、最近、改めてそこをちゃんと考えてみたいと思い始めたきっかけが、Bob Marshall氏の以下のtweetです。

"Business value" is NOT what people want..

— Bob Marshallさん (@flowchainsensei) 2月 9, 2012

 彼がどういう意図をもってこのtweetをしたのか私にはわかりません。でも確かに私自身をふりかえってみても、ビジネス価値の実現のために仕事や生活をしているかというとそうでもないような気がします。

そんな中で、考えるヒントとなりそうな資料がありましたので、ここで共有しておきたいと思います。ここで埋め込んでいるプレゼンテーション２つは、Dennis Stevens氏による"What to Build"を考えるにあたってのBusiness Analysisの手法に関するものです。重複する部分もありますが、それぞれに重要な要素が含まれていますので両方ともご覧になることをおすすめします。

An introduction to agile business analysis

View more PowerPoint from Dennis Stevens

Deciding what to build

View more PowerPoint from Dennis Stevens

これらのプレゼンテーションの中では、ビジネス価値について"Business Value Goal Model"を、顧客価値について"Customer Value Profile"を使って可視化し、それらを"Capability Model"につなげていくといったフレームワークを提示しています。これはなかなかよいですね。そのうち、これらを実業務でどのように適用できるか、しっかりと検討してみたいと思います。

また、余談ではありますが、上のプレゼンテーションに出てくる"Customer Value Profile"を見ていて思い出したのが、ブルーオーシャン戦略で使われる「戦略キャンバス」（Strategy Canvas）です。これは、前職の会社への入社時にもらった本があるので、改めて目を通してみたいと思います。なんとなく、このあたりからアジャイル開発におけるBusiness AnalysisやRequirements Developmentに関するいい感じのフレームワークが見つかりそうな気がしています。

ブルー・オーシャン戦略 競争のない世界を創造する (Harvard business school press)

BABOKのAgile Extensionが生む（かもしれない）誤解

Modern Analystのサイトに"3 misconceptions I would like to see removed from the Agile Extension to the BABOK®"という記事が掲載されていました。

ざっと斜め読みしたところ、この記事の筆者は、Agile Extensionのもたらす価値については認めながらも、大きく３つの点において誤解を招くこと、およびその誤解が続くことを懸念しているようです。そしてそれぞれについて、BABOKのAgile Extensionの中の記述から例を示しています。
曰く、

1. 世の中にはアジャイルかウォーターフォールしかない、つまりアジャイルを採用しなければ、全て計画駆動で要求フェーズが１回きりのモデルに従わなければならない、という誤解。
2. 要求をJust-in-Timeで定義することが他の全てのモデルよりすぐれているという誤解。
3. ドキュメンテーションは、直近のチームのニーズを満たす最小限のものを自動化しておけばよいという誤解。

確かに、そういう風に読もうと思えば読めなくもないですね。そして、その部分に対して読者が誤解をしないように警鐘を鳴らしてくれるのはありがたい話でもあります。（特に、BABOKのAgile Extensionが、主に従来型のトラディショナルなやり方を得意とし、アジャイル開発への理解が乏しい場合には、そういう誤解を生んでしまうおそれは十分にあると思います。）

でもね、それこそこの前のエントリに書いたように「自分の頭で考えようよ」という話ですよ。できるだけ誤解を避けるような書き方をすることの重要性を否定するわけではないですが、同時に、コンテキストを理解して自分の頭で考えるということがアジャイルな開発にとって重要であるということにフォーカスを当てた方がいいのではないかというのが、 元記事を読んだ私の率直な感想です。「BABOKにこう書いてあるからこうしなければいけない」と妄信・固執する人には、そもそもアジャイルは向いてないよ、とか言っちゃうと問題ありそうだからそこまでは言わないですけど。

元記事の筆者が、記事で主張している内容についてIIBAに直接伝えたかどうかわかりませんが、このあたりの内容については、現在のAgile Extensionのドラフト版が今後どのように変わっていくかは注目したいところです。

併せて読みたいBABOK/Agile Extension関連の過去エントリ：
BABOK（アジャイル拡張）の歩き方
Business Analysis in Agile Life-Cycles

Agile Requirementsと「実施可能要件」

アジャイル開発で仕様をどこまで詰めるのか、あるいはどの程度詳細にドキュメント化すべきなのかというのは、よく議論になるポイントです。シンプル なWebアプリケーションなどであれば、カードや付箋に記述されたユーザーストーリーと受入条件で十分かもしれませんし、医療系のシステムで人命に関わる ようなものであれば、より詳細な仕様の記述や入念に作り込まれたプロトタイプが必要になるかもしれません。

この点について、Jeff Sutherland氏が知的財産権や特許などにおける「実施可能要件」（"Enabling Specifications"）を引き合いに出して説明する記事を書いています。
"Enabling Specifications: The Key to Building Agile Systems"

"Enabling Specifications"とはどういうことかというと、この記事で引用されているのを転載すると、

2-231 Obtaining Patent Rights § 2.07[6]
"A patent specification is enabling if it allows a person of ordinary skill in the art to practice the invention without undue experimentation."

ということになります。
日本では、特許法第36条第4項において、明細書の発明の詳細な説明の記載は、「その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載したもの」でなくてはならないとしています。

アジャイル開発における仕様のドキュメント化においても、この考え方を援用して適切なレベルの仕様の詳細化（これは文書化されないPOとの会話も含む）およびドキュメント化を行うことにより、ベロシティを極大化することができる（はず）というのがこの記事のポイント。
実際に、じゃあ、どれくらい書けばいいの？というところについては、非常にざっくりとした書き方ですが、メジャーな機能については３〜５ページくらいってところですかね。

このあたり、どこまで実際にドキュメント化するかという話については、元記事に対するコメント欄でのTobias Mayer氏とJeff Sutherland氏とのやりとりを参考にすると良いでしょう。