[#TiDD] アジャイル開発への壁 #RxTstudy

ついに「Redmineでのタスク管理を考える勉強会＠大阪(RxTstudy)」が立ち上がりました。Twitterに話題が出てから約2日で企画され、募集から1日程度で30人の定員に達しました。しかも満員になってからも補欠(キャンセル待ち)が20人以上で鵜など、企画者側もびっくりの盛況ぶりでした。東京でもRedmineのコミュニティが発足するようですので、チケット駆動開発がいよいよ盛り上がると期待しています。

恥ずかしながら私も、今年のデブサミでベストスピーカ賞をいただいた発表を再演しました(資料、Ustream)。

勉強会の概要

今回お勉強会では、あきぴーさんのアンチパターンのお話(資料)、中村さんのRedmineの事例発表(資料)やLTのほか、Redmine本の著者4人によるパネル(Ustream)や、そのうちのお一人である倉貫さんの基調講演(資料、Ustream)もあり、活発な意見交換が行われました(Ustream @bufferingsさんによるtogetter　@akipiiさんによるtogetter)。

取り上げたい内容は多々あるのですが、ここでは以前から気になっているアジャイル開発への壁という観点で、最近考えていることをまとめたいと思います。

・契約

多くのソフトウェア開発は請負契約で行われていることから、契約時に仕様(スコープ)を決めた上で、開発が始まるといういかにも従来型開発向きな契約になっています。準委託契約、いわゆる期間契約であれば、スコープを後から変更することもできるのですが、一度に発生する費用を減価償却できないという問題が生じてしまいます。

この点、倉貫さんの基調講演の請負をクラウドで実現して、納品をなくすという方法は、一定額を常に払う契約ですので、顧客・開発双方にWin-Winの関係が築けるかもしれません。類似の契約には永和システムさんの「価値創造契約」がありますが、クラウドに限定することで納品をなくし、リリース後のサービス向上も容易になりそうです。

・レイヤ構造

これは先日のSEA関西でのスクラムワークショップで教わったことです。開発者が一つのタスクに集中できるように作業を割り振るには、作業分担がレイヤごとになってはいけないというお話から気づきました。

ワークショップでのお話の趣旨は、画面担当、ビジネスロジック担当、DB担当のように担当を分けると、常に作業を割り当てることが難しくなり、複数のプロジェクトを掛け持つ必要が出てくるというものでした。

このことを拡張して考えると、フレームワークなどしっかりしたアーキテクチャが別にあり、その上の薄くて広いところの開発だと開発する機能に単純な優先順位をつけることができますが、別のレイヤに分けてしまいがちな別サーバとの通信やハードウェアとの並行開発だと単純な優先順位をつけることが困難です。アジャイルリリーストレインやスクラムオブスクラムという方法があるものの、依存関係によって、スコープの変更に制約を受けてアジャイルのメリットを生かしにくいように思います。

・顧客との関係

最後に、一番難しいのは顧客との関係ではないでしょうか？ソフトウェアが企業の命運を握っていることは間違いないはずなのですが、やはり「おまかせ」のお客さんも多いように思います。また、協力的な顧客であっても、ステークホルダー(利害関係者)が多くて、意思決定が困難な場合などは、アジャイル開発が難しくなると思います。

これは、顧客の予算どりや契約とも関係しています。詳細な仕様を決めずに商品化(リリース)までの予算を決定できるかどうかが、難し意場合もあると思います。また、意思決定が遅れると、作業が止まってしまいますので、請負開発では開発側の大きな負担になります(その点、一定の金額をいただける契約は、開発側のリスクを減らしてくれる宇土思います)。

おわりに

チケット駆動開発は、残念なアジャイル開発と呼ばれることがあります。これはアジャイル開発がある程度有効だと思われるのにアジャイル開発できない、上記のような場合に有効であることを示している言葉だと思います。

関西の勉強会(RxTstudy)はRedmineだけでなくタスク管理がその名前に入っていることから、大いに期待しています。