無料ブログはココログ

« 2012年3月 | トップページ | 2012年6月 »

[#TiDD] アジャイル開発が注目される理由

最近、大手ベンダーのアジャイル開発への取り組みがニュースになっています。アジャイル開発がいよいよ普及期に入ってきたという印象を受けました。それと共に、それがこれまでのアジャイルコミュニティの言っていたアジャイルと同じものなのか、あるいは別のものなのか、とても気になるところです。それはそれで大切ですが、ここでは、なぜ大手ベンダーがアジャイル開発に取り組もうとしているかを考えてみたいと思います。

従来の開発法

いわゆるウォーターフォール開発では、あらかじめ要件となる仕様を確定して、そのシステムの実現を請け負う方法です。「不確実コーン」(リンク先はAct as Professional)で考えていただければわかりますが、これはリスクの高い方法です。

リスクの高い場合には、保険のビジネスが成り立ちます。大きな問題の起きる可能性のある場合には、個別のリスクを抱える顧客に対して平均的なリスク(発生確率×被害)よりも高い金額でサービスを提供できれば、サービス提供側はその差額を利益とすることができますし、顧客はその差額で安心を買うことができます。

ソフトウェア開発で考えれば、見積もりの総額は以下のように表せます。

  見積もり総額=開発見積もり+リスク見積もり(Σ(各リスク発生確率×被害))

この式から考えると、開発側は利益を得る2つの方法があります。

1) 顧客の許容する開発見積もりよりも少ない開発費用で開発する
2) 顧客の許容するリスク見積もりよりも低いリスク費用(発生した問題の対策費)で開発する

近年、この2つの方法の実現が困難になっているのではないかと考えています。

単価の低下

上の式にある見積もり総額は、発注(顧客)側、受注(開発)側それぞれで見積もりますが、見積金額がそれで決まるわけではありません。開発側はより高く受注したいと思いますが、発注側はより安く発注しようとするからです。その結果、需要と供給で見積もり総額は決まります。

不景気な状況や競争が激しい場合、見積もり総額の低下によって開発の単価が下がってしまいます。場合によっては不確実コーンの中央値、あるいはそれ以下で受注せざるを得なくなります。そうなると、様々な努力をしてもなかなか利益は出ませんし、想定外の問題の発生や、統計的に扱えるだけの数量の開発案件がなければ、短期的に赤字になってしまいます。これは、株主の利益が重視される中では、許容できなくなってしまいます。

リスクの増加

ソフトウェア開発におけるリスクは増加し続けています。規模の増大による複雑化のほか、業務要件の変動、実装しないと確認できないほど多様化した実現方法、オープン化による開発基盤の組み合わせ、など多くのリスクが存在します。そして、それらはソフトウェアの開発技術の発展と適用範囲の広がりによって、日々リスクは増えています。

リスクが増加すると見積もりは困難になりますし、利益を得ることは難しくなります。たとえば、安定した株や証券であれば、バブル崩壊のような暴落がなければある程度の利益を継続的に得ることは可能でしょう。しかし、投機的な株や証券を取引では、高度なコントロールが必要ですし、よほどの規模で取引をしなければ安定した利益を得ることは困難でしょう。

プロセス改善によって開発費用を抑えることができても、リスク費用(発生した問題の対策費)が増加すれば、利益が得られなくなってしまいます。

技術のオープン化

競争が激しく、利益を得ることが困難になっても、技術力を向上して生産性を高めたり、リスクを低減することができれば、他社以上に利益を確保することができます。

しかし、近年の技術はオープン化が進んでいます。すべてを独自技術で実現することはできませんので、少なからずオープンな技術に引きずられます。また、類似のオープンな技術が出てくれば、それに合わせる必要が出てしまいので、逆効果になってしまいます。自社の開発に役立つ新しい技術があるならば、囲い込まずに公開技術として業界に貢献する方がその技術に詳しい分だけ、ほんの少しだけ他社よりも有利になります。

結局、技術がオープン化してしまっている限り、独自技術で大きな利益を得ることは困難だと言えます。

リスクの低減が求められる

アジャイルが注目されるのは、ここに挙げた理由で従来型の開発が困難になっているからだと思います。

まず、アジャイル開発は繰り返し型開発です。予測可能な短期間の開発とリリースの繰り返しによって段階的に開発できるので、発生した問題への適応力が増します。

また、プロジェクトファシリテーションの活動に見られるように、メンバーの能力を最大限に生かします。コマンドコントロールではないので、メンバの気付いたリスクや問題を共有することで、プロジェクトのリスクを低減できます。

しかし、アジャイル開発では変更を受け入れる反面、開発のスコープを変更しますので、一括請負とは相性が悪く、準委任契約が多いようです。開発側は利益率が低いもののリスクを取らなくて済みますので、(額は少ないかもしれませんが)安定した利益を確保できます。それ以外にも、繰り返しの単位であるイテレーションごとに請負契約をするという方法もあります。その場合には契約が煩雑になりますが、不確実コーンの狭い範囲で開発できますので、発注・受注双方のリスクを下げることができます。

チケット駆動開発への期待

チケット駆動開発で使われるチケットはアジャイル開発のタスクとみなすことができ、
「アジャイル開発の親和性が高いらしい」(まちゅダイアリー)と言われています。また、リスク管理を考えると前の記事にあるような特長があります。

- 細かなリスクの管理が可能
- リアルタイムな通知
- 過去の問題のトレースが可能
- 複数イテレーションの管理ができる(決定をできるだけ遅らせることを支援)

これらを生かすことでアジャイル開発+αの効果を期待しています。

おまけ(勝手な予想)

大手ベンダーの動向を見ていて、最も気になったのは契約でした。準委任契約だと利益は安定しますが、リスクをとらない分だけうまみが減るからです。だからといってイテレーションごとに契約をやり直すのは、大手ベンダーにとっては面倒でしょう。

私が大手ベンダーの経営者なら、発注側がリスクを取ることで得られる利益を狙います。よく言われる方法は、顧客の得た利益に対して成功報酬を受け取る方法です。これまでは、納品後は保守と運用を除いては、瑕疵対応でお金が出るばかりでしたが、顧客の利益の中から一定額の報酬が得られれば、大きなメリットです。

しかし、顧客の利益を確認することは必ずしも容易ではないので、利用期間に対して一定の報酬を得るようになるかもしれません(そう考えると、アジャイルで有名な某社の契約となんとなく似てきますね)。

それ以外にありそうなのが、資本参加です。発注元である顧客の情報システム子会社に資本参加する、あるいは顧客と共同で情報システム子会社を設立するのです。安定した受注が得られるほか、リスクを取った情報システム子会社の利益を折半できるようになります。資本参加はこれはお金だけかもしれませんし、出向という形かもしれません。

いずれにしろ、これまでの業界の構図が大きく変わるきっかけになる様な気がします。そのような中で、チケット駆動開発は重要な技術として、きっと大きな役割を果たしてくれると思っています。


[#Tidd] #RxTstudy 発表資料「個人のタスク管理からチケット駆動開発の特徴を考える」

第4回 RxTstudy(Redmineやタスク管理を考える勉強会@大阪)で発表してきました。

今回は「タスク管理」大特集ということで、関西ライフハック研究会女子部さん & 関西ライフハック研究会さん からゲストスピーカーをお招きして、アナログ・デジタル入り乱れての「タスク管理祭り!」が行われ、興味深いお話を聞くことができました。

また、グループディスカッションでは、チーム&デジタルに参加して、現場での体験談や苦労話を聞けて、とても興味深かったです。

さて、このタスク管理とは何か?
個人活動を対象と売るライフハックだと「やらないといけないこと」をタスクと呼んでいますが、ソフトウェア工学的にはプロセスを呼応精する要素でるだけで、管理するのは「スケジュール」あるいは「予実」(予定と実績の差)です。それをなぜ共著「Redmineによるタスクマネジメント実践技法」のタイトルになったのか、著書の中では個人のタスクがどのように語られているか、ぜひスライドをご覧ください。

なお、著書の中ではチケット駆動開発の類似点を中心に書きましたが、発表では特長の違いを中心に整理しました。


[#xpfes12] 先駆者の集まりから、プロセス・チャンピオンの集まりに - XP祭り関西2012 -

ついにアジャイル開発は普及期に入りました。そんなことを、今年のXP祭り関西(リンク先はtogetter)で実感しました。

たぶん最初のXP祭り関西は、ワッハ髪型で行われたXP祭り2006です。私も赤いハッピを着て、スタッフをさせていただきました。リンク先を見ていただいても分かると思いますが、XPのプラクティスを試してみた人やXPを実践中の先駆者が、興味のある人やこれから始めようとする人に体験を踏まえて説明する集まりでした。

今回のXP祭り関西は、その内容も参加者もより実践的に感じました。私のつぶやきは上のリンクで見ていただくとして、変化を感じた3つの発表の感想を書きます。

【基調講演】「アジャイル開発の計画と管理」~アジャイルのプロジェクトマネジメント~
梅田 弘之氏 /株式会社システムインテグレータ 代表取締役社長

これまでどのようにアジャイル開発を導入するか、あるいは、アジャイル開発を前提に契約はどうあるべきか、という議論が多かったと思います。しかし、この講演では、より現実的な解決法が示されました。

これまで現状の請負契約を前提に、これまでウォーターフォールで開発されてきました。しかし、アジャイル開発だと満足度の高いシステムの出来上がることから、海外の最近のトレンドは、ウォーターフォールとアジャイルのハイブリッドだそうです。基本設計と結合テストの間をアジャイルにします。

この発表では、請負契約の中で行うハイブリッド開発で、プロジェクトをどのように管理すれば良いかを、自社ツールのデモを交えて説明されていました。

アジャイル開発では品質、コスト、納期、スコープのうち、スコープを変更しつつ、ある意味ではスコープを犠牲にしながら開発します。しかし、請負開発ではスコープを犠牲にできないので、コストが犠牲になってしまいます。

アジャイル開発の請負での課題の一つはスコープの確定で、常駐することや、モックで仕様確認が重要です。また、アジャイル開発は顧客の負担が増えるので、理解を得ることが重要だそうです。

この他にも、「アジャイルになると急に良い人になることはない!(笑)」など、経験に基づく興味深いお話満載の基調講演でした。

「大規模なゲーム開発をスクラムで」田口 昌宏氏 /株式会社ディンプス

100名規模の大規模ゲーム開発における現場主導によるスクラムの導入の経緯のお話でした。

特長的なのは、プラクティスを工夫しながら徐々に導入されたところです。失敗もあったものの、その経験を生かし、スクラム開発に参加する(サブ)チームを徐々に拡大されたことです。

特にタスクボードへの工夫は興味深かったです。関連するチームのタスクボードを横に並べると、お互いに見るようになったというお話は、すぐにでも使えそうな手法ですね。

また、キャラクタ制作は職種間の連携が複雑で大人数なので、タスクボードを連携する各パートをフローに合わせて左から右に並べたお話がありました。キャラクタごとに付箋で管理すると、作業の進捗がわかるようになり、待ち時間も減少したそうです。

このように、アナログであることを最大限に生かして、コミュニケーションを改善した興味深いお話でした。デジタルであるチケット駆動開発もコミュニケーションを効率化しますが、このお話を聞くと、遠距離でのコミュニケーション、履歴や検索、関連付け、ワークフロー、自動化などが特徴なのだと思いました。

【ライトニング・トークス】 XP祭り関西2011から2012の 狭間で 中村 洋 (@yohhatu)氏

積極的に勉強会に勧誘するお話が印象的でした。様々な連絡方法で、勉強会に誘うだけでなく、参加すると質問されるかどうかなど、初めての人の不安を無くす等の工夫をされているようです。

人によって伝える内容を変えるという工夫は、ファシリテーションやコーティングにつながるお話ですね。

なお、マネージャーの勧誘は難しいというお話でした。

CMM/Iがいつか来た道

これまで、私はアジャイル開発をプロセス改善ととらえていましたが、今回のXP祭り関西のサブテーマにあるように、技術志向のお話が中心でした。しかし、アジャイル開発が普及期を迎えた今、課題となる内容はプロセス改善が中心の議論になってきました。

今回取り上げた3つのお話は、ビジネスとプロセスの整合、実践する際の工夫、組織内への展開という、CMM/Iの普及が進みだしたころに議論された内容です。

当時、守破離とか、段階モデルの罠などが議論され、経験を元に多くの工夫が発表されていました。そのころに最も印象深かったのが、ボーイングのYamadaさんのお話です。関連するお話としては、

・経営層のコミットメントが重要
・組織内にプロセス・チャンピオンが必要

ということでした。プロセス・チャンピオンとは、知識が豊富なだけでなく、プロセス改善に積極的で、組織を引っ張っていく人です。今回の基調講演の梅田さんは経営層ですし、田口さん、中村さんはプロセス・チャンピオンそのものです。

ついにアジャイル開発も普及期に入って、XP祭り関西も、先駆者の集まりからプロセス・チャンピオンの集まりになったのだと思いました。今後、より本質的な議論が行われることを楽しみにしています。

« 2012年3月 | トップページ | 2012年6月 »