読者です 読者をやめる 読者になる 読者になる

Always All Ways Archive

Archive Imported from Always All Ways on Plala

ぷららのブログサービス(Broach)終了に伴い

お知らせ

ぷららのブログサービス(Broach)上に置いていた過去のブログ記事をこちらにインポートしました。

Blog引っ越しました The Blog has been moved.

お知らせ
今月(2012年2月)より、このブログと並行して「はてなブログ」を使い始め、しばらくは両方のブログに同じ記事を投稿してきましたが、さすがに面倒になってきたので、一旦、「はてなブログ」の方に一本化したいと思います。今後、いろいろ使ってみて、こちらに戻すかもしれませんし、場合によってはテーマに応じて2つのブログを使い分けるようなことをするかもしれませんが…。 はてなブログは、こちら↓ (You can find my new blog here!) Always All Ways -Apologies, Glances and Messed Up Chances-

アジャイルやリーンのパイロットプロジェクトに関する考察

IT
先日、id:kent4989さんが 「アジャイル手法によって生産性が上がりプロジェクトは成功するか?(いいえ) - 勘と経験と読経」 というエントリを書いていました。 まぁ、「いいえ」と言い切ってしまうのもどうかと思いますが(笑)、もとの疑問文に「必ず」とつければ概ね合意です。 さて、上記のエントリはパイロットに限って書かれたものではありませんが、ここでちょっとパイロットについて考えてみたいと思います。アジャイル開発の導入にあたってよく言われることに、「まずはパイロットプロジェクトをやってみて、成功事例を示していきましょう。そして小さな成功体験を積み重ねて全体に展開していきましょう。」というのがあります。 しかし一方で、たとえパイロットとして部分的に始めるにしても、「全体を見る」ことを忘れてはいけないということも言われています。 その一例として、Alan Shalloway氏のNetObjectivesにより一昨日YouTUBEにアップされている、少し衝撃的なタイトルのビデオを紹介します。 「パイロットの成功がアジャイルな組織をダメにすることもある」- これは我々がアジャイルやリーンの導入をする際にパイロットプロジェクトを実施し、またその結果を考察するにあたって念頭においておくべきことだと思います。 これと併せて、是非見ておいていただきたいのが、同じくAlan Shalloway氏がRon Jeffries氏ほか何名かとtwitter上で関連したテーマで意見交換しているものです。トゥギャッターで以下に抜粋してまとめておきました。 「パイロットプロジェクトについて」- Togetter また、ご参考までに、2年近く前にDonやAlanたちの全体最適部分最適についてのtweetのまとめにも目を通しておくとよいかもしれません。 「Global optimization vs. Local Optimization」 - Togetter "Optimize the Whole"みたいな話は、これらに限らず昔からAlanの本("LEAN-AGILE SOFTWARE MANAGEMENT")を読んでいても随所で感じられる話です。Agile Japanに来日した割には、イマイチこの本もメジャーにならず、訳書も出ていないのですが、私はこの本、大好きです。多分、アジャイルやリーンの文献の中でこの本を一番読んでます。ご興味があれば是非ご一読をおすすめします。 部分的には、以前のブログにも少しだけ書いてます。 Always All Ways: [IT] Alan ShallowayのLean-Agile(その1) Always All Ways: [IT] Alan ShallowayのLean-Agile(その2) そしてもう一つここで重要な概念が「ホリスティック」(Holistic)です。ギリシャ語のホロス (holos=全体) に由来し、「部分を積み重ねても全体にはならない、 全体は一つの有機的なつながりで、部分の和とは異なる」みたいな考えがベースにある…らしいです。これについてはまた、別の機会に書くかもしれませんが、参考文献をひとつだけ示しておきますね。
ホリスティック・クリエイティブ・マネジメント―21世紀COEプログラム:エージェントベース社会システム科学の創出
木嶋 恭一 マイケル・C. ジャクソン 小林 憲正 根来 龍之 高橋 真吾 中條 尚子 吉田 武稔
丸善
売り上げランキング: 156992
Lean-Agile Software Development: Achieving Enterprise Agility (Net Objectives Lean-Agile Series)
Alan Beaver, Guy Trott, James R. Shalloway
Addison-Wesley Professional
売り上げランキング: 392771

Business ValueとCustomer Value

IT
アジャイル開発に限らず、システム開発やそれ以前のビジネス戦略の話なども含めて、いろんな場面で「ビジネス価値」(Business Value)という言葉が出てきます。要求開発宣言でも「情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである」という表現が出てきますし、要件の優先順位を考える時にもビジネス価値はしばしば最重要ファクターとして取り扱われます。 しかしながら、私自身、「ビジネス価値ってなんだっけ?」とか「ビジネス価値ってどうやって定量化できるの?」とか、さらには「ビジネス価値だけで物事を決めていいのだろうか?」といった問いに対する明確な解を持たないまま、その言葉を便利に使い続けてきた感があります。 一方で、ビジネス価値と一緒によく使われる言葉としては、他に「顧客価値」(Customer Value)などもあります。また、かなり以前に(何の研修か忘れましたが)とある研修で、「Win-Winの関係を形成するにあたっては、"Business Win"だけでなく"Personal Win"も考えることが必要」みたいな話を聞いたこともあり、そのあたりもなにか併せて考えないといけないのではないかと思ったりもしていたことも事実です。結局それら(顧客価値や"Personal Win"みたいな概念)も含めたものが「ビジネス価値」に収斂されるという考え方もあるでしょうが、それでも戦略を考える上では、そこは分けて考えなければいけないのではないかと…。 そして、最近、改めてそこをちゃんと考えてみたいと思い始めたきっかけが、Bob Marshall氏の以下のtweetです。 彼がどういう意図をもってこのtweetをしたのか私にはわかりません。でも確かに私自身をふりかえってみても、ビジネス価値の実現のために仕事や生活をしているかというとそうでもないような気がします。 そんな中で、考えるヒントとなりそうな資料がありましたので、ここで共有しておきたいと思います。ここで埋め込んでいるプレゼンテーション2つは、Dennis Stevens氏による"What to Build"を考えるにあたってのBusiness Analysisの手法に関するものです。重複する部分もありますが、それぞれに重要な要素が含まれていますので両方ともご覧になることをおすすめします。 これらのプレゼンテーションの中では、ビジネス価値について"Business Value Goal Model"を、顧客価値について"Customer Value Profile"を使って可視化し、それらを"Capability Model"につなげていくといったフレームワークを提示しています。これはなかなかよいですね。そのうち、これらを実業務でどのように適用できるか、しっかりと検討してみたいと思います。 また、余談ではありますが、上のプレゼンテーションに出てくる"Customer Value Profile"を見ていて思い出したのが、ブルーオーシャン戦略で使われる「戦略キャンバス」(Strategy Canvas)です。これは、前職の会社への入社時にもらった本があるので、改めて目を通してみたいと思います。なんとなく、このあたりからアジャイル開発におけるBusiness AnalysisやRequirements Developmentに関するいい感じのフレームワークが見つかりそうな気がしています。

BABOKのAgile Extensionが生む(かもしれない)誤解

IT
Modern Analystのサイトに"3 misconceptions I would like to see removed from the Agile Extension to the BABOK®"という記事が掲載されていました。 ざっと斜め読みしたところ、この記事の筆者は、Agile Extensionのもたらす価値については認めながらも、大きく3つの点において誤解を招くこと、およびその誤解が続くことを懸念しているようです。そしてそれぞれについて、BABOKのAgile Extensionの中の記述から例を示しています。 曰く、
1. 世の中にはアジャイルウォーターフォールしかない、つまりアジャイルを採用しなければ、全て計画駆動で要求フェーズが1回きりのモデルに従わなければならない、という誤解。 2. 要求をJust-in-Timeで定義することが他の全てのモデルよりすぐれているという誤解。 3. ドキュメンテーションは、直近のチームのニーズを満たす最小限のものを自動化しておけばよいという誤解。
確かに、そういう風に読もうと思えば読めなくもないですね。そして、その部分に対して読者が誤解をしないように警鐘を鳴らしてくれるのはありがたい話でもあります。(特に、BABOKのAgile Extensionが、主に従来型のトラディショナルなやり方を得意とし、アジャイル開発への理解が乏しい場合には、そういう誤解を生んでしまうおそれは十分にあると思います。) でもね、それこそこの前のエントリに書いたように「自分の頭で考えようよ」という話ですよ。できるだけ誤解を避けるような書き方をすることの重要性を否定するわけではないですが、同時に、コンテキストを理解して自分の頭で考えるということがアジャイルな開発にとって重要であるということにフォーカスを当てた方がいいのではないかというのが、元記事を読んだ私の率直な感想です。「BABOKにこう書いてあるからこうしなければいけない」と妄信・固執する人には、そもそもアジャイルは向いてないよ、とか言っちゃうと問題ありそうだからそこまでは言わないですけど。 元記事の筆者が、記事で主張している内容についてIIBAに直接伝えたかどうかわかりませんが、このあたりの内容については、現在のAgile Extensionのドラフト版が今後どのように変わっていくかは注目したいところです。 併せて読みたいBABOK/Agile Extension関連の過去エントリ: BABOK(アジャイル拡張)の歩き方 Business Analysis in Agile Life-Cycles

仕事のやり方を考える時に心がけたいこと

Life
世の中便利になったもので、今や、ちょっと検索すればアジャイル開発の事例やその他いろんな仕事のやり方に関する情報を見つけることができます。また、イベントや勉強会なども相変わらず活発に開催されており、他の人の仕事のやり方や考え方に触れる機会も多いと思います。今朝も、ITproで「第1回 3割減の工期で「いつもの疲弊が無い」 - 実践!CCPMで工期3割短縮:ITpro」という記事が掲載されており、ついつい「やっぱり、CCPMだね!」などと思いたくなってしまいます。 ただ、そんな時代だからこそ、しっかりと心に留めておきたいことがあります。それは - 自分の関わる組織や業務のコンテキストをちゃんと認識すること - その上で自分の頭で考えること です。 そしてそれを私自身も肝に銘じて忘れないようにするために、開発手法や方法論の説明やプレゼンテーションを行う際にしばしば引用する言葉をここで紹介しておきたいと思います。以下に紹介する2つのフレーズは、どちらも「ジョーカー・ゲーム」(柳広司)の中で結城中佐が語った言葉だったと記憶しています。私自身は、一つ目をプレゼンテーションの冒頭で「今日のメッセージ」として紹介し、二つ目を最後に「今日のまとめ」として紹介するパターンが多いです。
「貴様が何を信じていようがかまわん。キリストだろうがマホメットだろうがイワシの頭だろうが、勝手に信じるがいい。もし本当に自分の頭で考え抜いたすえに、それを信じているのならな」
「何かにとらわれて生きることは容易だ。だが、それは自分の目で世界を見る責任を放棄することだ。自分自身であることを放棄することだ」

アジャイルの成功確率はウォーターフォールの3倍?

IT

Mike Cohn氏が今週月曜日(2月13日)のブログで、Standishグループのレポートからアジャイルウォーターフォールの成功確率に関する部分を引用・報告しています。 Mike Cohn's Blog - Succeeding with Agile "AGILE SUCCEEDS THREE TIMES OFTEN THAN WATERFALL" まず、そこで引用されているグラフをここにも転載させていただきます。 

f:id:tmaegawa:20140420095700j:plain

(Source URL: http://blog.mountaingoatsoftware.com/agile-succeeds-three-times-more-often-than-waterfall ) 確かにこのグラフを見ると、SUCCESSFULの割合がウォーターフォールで14%に対してアジャイルでは42%と3倍になっています。但し、この結果についてはそのまま鵜呑みにするわけにはいきません。いくつかの疑問や懸念点についてはブログ記事のコメント欄で読者とMike Cohn氏の間でも活発に議論されている通り、いわゆる「突っ込みどころ満載」状態です。 まず、統計の元データの詳細が明らかにされていないためわからないことが多く残されています。"SUCCESSFUL"の定義をどう捉えるかというのも大きなポイントですし、ウォーターフォールと称しているものが、元々のRoyce論文にあるようなものを指すのか、その後DoDでスタンダードとして採択された際に曲げられてしまった以降のものを指すのか、そもそもウォーターフォールとは名ばかりの「なんちゃってウォーターフォール」をも含んでいるのかというあたりにも疑問はあります。 それから、レポートの中で"Agile Process"という呼び方がされていますが、そもそもアジャイルってプロセスだっけ?というのもありますね。前述の"SUCCESSFUL"の定義についても記事の中では、"The Standish Group defines project success as on time, on budget, and with all planned features. "と書かれていますが、"all planned features"というくだりは、そもそもアジャイルな考え方と相反するものでは?という気がしないでもありません。 というわけで、このレポートについては話題としては面白いけど、これだけでどうこう言えるものではないし、方法論やプロセスの優劣というよりは、組織やプロジェクトのコンテキストに応じて最適なやり方を自分たちでちゃんと考えることの方が大事だということには変わりはないということだと思います。 ちなみに似たようなテーマの調査としては、Scott W. Ambler氏の 2011 IT Project Success Rates Survey Results というものもあります。 対比してみると面白い(かもしれない)ので、結果のグラフのみ、転載しておきます。 

f:id:tmaegawa:20140420095715j:plain

(Source URL: http://www.ambysoft.com/surveys/success2011.html ))