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

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

従来の開発法

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

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

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

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

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

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

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

単価の低下

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

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

リスクの増加

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

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

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

技術のオープン化

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

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

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

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

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

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

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

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

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

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

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

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

おまけ(勝手な予想)

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

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

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

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

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

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

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

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

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

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

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

Thinkin abouttid dwithtaskmanagement

View more presentations from Makoto SAKAI

[#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祭り関西も、先駆者の集まりからプロセス・チャンピオンの集まりになったのだと思いました。今後、より本質的な議論が行われることを楽しみにしています。

[#aj12] コマンドコントロールではなく、メンバーを守るでもなく、協調へ！

Agile Japan 2012 では、発表準備もあってあまり発表を聞けなかったのですが、印象に残るセッションが“「アジャイルのあるとき、ないとき」 ～アジャイルは関西ビジネスをどう変えられたのか？そしてこれからどこに向かうのか？～”です。

関西ながらのコテコテのテーマですが、内容は充実していました。最も印象的だった議論は、「ある時と感じたのはいつですか？」というものでした。そこで出た言葉を並べると

「アジャイルには2つあり、アジャイル・プラクティスとアジャイル・マインドだ」
「やっぱり考えるようになった時、自主的に振り返りをするようになった。」

これがアジャイルなのでしょうね。プラクティスそのものよりも、マインドが大切で、メンバーが自律的に行動する組織になることが、アジャイルなのでしょう。そして驚いたのが、この発言です。

「プロジェクトファシリテーションのきっかけは、土屋さん！」

これはちょっと解説が必要ですね。XPJUG関西の2代目代表をされた土屋さんが、XPのテストの考え方を開発と関係のない部門に適用された話を聞いて、平鍋さんがプロジェクト・ファシリテーションを始められたそうです。ファシリテーションの視点は一般化にあったのですね。

アジャイルがマインドであるなら、それは開発だけでなく様々な場面で利用可能なものです。実際、従来型の開発においても応用可能だと思っています。しかし、そんな思いを打ち砕く一言が、、

「カンバンをお客様と見ることで、問題と、お客さんを含めた私達の関係に持ち込む！」

この一言には、参りました。私はアジャイル開発でなくても、アジャイル・マインドが実現できると思っていました。リーダーやマネージャがコマンド・コントロール しようとせず、チームを守ることで自律的な組織というのは、実現できると思っていました。

しかし、アジャイルではチームを守る必要がなかったのです。仕様変更やお客様の無理難題からチームを守って、開発に集中でき、自律的に行動できる環境を作ることだと思っていましした。これはファシリテーションにつながるとても大切な考え方だと思っています。しかし、お客様と同じ方向を向くことがアジャイルだったのですね。

また、前の記事に関わるコメントもありました。

「なんのためにAgileするのか？」

やっぱり、これが本質なのでしょうね。現場に問題があり、それを解決するために新しい技術やプロセスを導入することがポイントなのでしょうね。

それに反して、組織の運営をハンコ中心に運営する

「ハンコ駆動開発(HDD)」

では、ビジネススピードがアがrわけがありませんし、Redmineを導入しても

「Redmineがハンコになっている！」

という状況では、未処理のトレーとRedmineの両方を見なければいけない分だけ、不便になるだけです。

アジャイルはすでにブームを過ぎて、本格的な普及期に入ってきたと思います。そしてアジャイルに関しても、より本質的な議論が始まって来たという印象を受けました。今後の本格的な発展に期待しています。

[#TiDD] チケット駆動開発もAgileもより本質の議論に #aj12

Agile Japan 2012 でパネルディスカッションをしました。

プロジェクトを成功に導く チケット駆動開発のビジョン

View more presentations from Makoto SAKAI

まず、あきぴーさんの「チケット駆動開発の課題と展望」、次に中村さん「Redmineと守破離」で、最後に私が発表しました。

あきぴーさんがチケット駆動開発を展開する際の課題を話され、中村さんがRedmine導入の守破離を話されました。そして私が、最近はチケット駆動開発が難しいとか、うまくいかないというお話を聞くようになったので、成功のためにはビジョンが必要だというお話をしました。

3人で共通のポイントは「形骸化を恐れる」ということです。チケット駆動開発は広く普及しだしています。今回150名ほどの参加者のうち、半分近くの方がすでに実践されているようでした。

今回の発表内容も、ちょうどCMMが本格的に普及しだした頃に似ています。それまでの一般論から、組織に対する実践の議論に向かいました。どのように普及させるか、「守破離」などと言う言葉もそのころに出ていました。いかに現場に浸透させるか、以下に根付かせるか、そのような議論が行われていました。

出てきた質問で興味深かったのは、それが具体的なことです。CMMではどのように取り組むか方針の議論が多かったですが、チケット駆動開発だと取り組みは簡単ですが、いざ実践となると考えることが多いのです。なので、きちんとしたビジョンが必要になるのです。

色々と考えさせるパネルディスカッションでしたが、やはり2時間～2時間半はないと、盛り上がらないですね。いつか、本格的なパネルディスカッションがしてみたいと思います。

アジャイルに関しても同じように本質的な議論になってきたと思っています(別に書きます)。

[#devsumibook] 誰もが本を読んで学んできた「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」

インターネットの普及に伴い、本を読む機会が減っていないでしょうか？日々仕事に追われる中で問題の解決を優先し、休憩時間に雑誌を見る程度でじっくり本を読む機会が減っていないでしょうか？

私の場合も例にもれず、かつては読書タイムだった通勤時間もスマートホンでTwitterやFacebook、たまにメルマガを読む程度で、なかなか本を読む時間がとれなくなりました。

去年のデブサミであきぴーさんとチケット駆動開発について発表して、二人で優秀スピーカー賞をいただきました。そのご縁から「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」にご協力させていただきました。

私の書いた内容はSEA関西プロセス分科会でTさんから教えていただいた「TSPガイドブック:リーダー編 (IT Architects'Archive)」です。

著者の面々を見ると、アジャイルや方法論の紹介は十分と思われたので、少しひねってハンフリーさんによるハンフリーさんらしくない内容も載っているこの本を選びました。詳細はいつか書こうと思いますが、私のリーダー像を一変させた一冊です。

今日、私の手元に見本誌が来ましたので、読み始めています。誰しもが、本を読み、ソフトウェア開発について、開発者の生き方について、多くの人生の出来事の中で学んできたのだと思いました。そして、また本を読む時間を作りたいと思いました。

ぜひ、皆さんも書店で手に取ってみてください。

[#TiDD] 個人のタスク管理からチケット駆動開発の特徴を考える ＃RxTstudy

小川さんとの共著「Redmineよるタスクマネジメント実践技法」には、個人タスクの管理方法として2つの話を載せています。

• 松下幸之助氏の仕事術：多忙な松下幸之助氏は1日の仕事を書きだしてから仕事を始めることで、収まりそうにないタスクを実践できていた(という伝聞)。
• 個人のタスク管理はメールを使え！：Redmineを個人のタスク管理に使ったが、楽しくなくてすぐにやめた話。

これらは、チケット駆動開発の特徴を示していると思います。まず、松下幸之助氏の話は、

• 仕事の可視化によって全貌が把握できる
• ゴールを明示することで、計画的に達成できる

ということを示しています。これはチケット駆動開発と共通する特長です。

もう一方のメールには、以下のような特長があります。

• メールに作業書くことで、作業の漏れを防止できる(未来の自分への作業指示)
• 未読、優先順位、フォルダ分けなどの属性を管理に用いることができる
• 日常的に確認している

これらも、チケット駆動開発と共通する特長です。
同じ特徴を持つ方法にも関わらず、一人でRedmineを使っても楽しくないのは、チケット駆動開発が以下のような特長があるのに対して、個人のタスク管理ではメリットを感じられないからです。

• ゴール(マイルストーン)が共有されて、同じ方向に向かう一体感が感じられる
• 全体のタスクが常にレビューされ、緊張感を感じながら問題と解決策を共有できる
• チケットのやり取りで作業を助け合える
• チケットがコミュニケーション手段であり、常時確認することが習慣になっている(もしくは通知設定をしている)。

このように考えると、日常のリズムの中でチケット駆動開発が情報共有、コミュニケーションを支援し、メンバーの能力を最大限に発揮する支援をしていることがわかると思います。チームでチケット駆動開発をするからこそ、BTSの様々な機能が役に立つのでしょう。

なお、これ以外にもチケット駆動開発には

• 構成管理(バージョン管理ツール)との連携

という大きな特長があり、個人でも開発など、成果物と関連するタスク管理であれば、チケット駆動開発のメリットが感じられるでしょう。

【告知】

このような内容で、4月21日に行われる第4回RxTstudy(Redmineやタスク管理を考える勉強会＠大阪)で発表させていただくつもりです。

今回のテーマは「タスク管理大特集!!」で、全員参加も企画や懇親会もありますので、ぜひご参加ください。

[#TiDD] プロセスモデリングにおけるチケット駆動開発の可能性

プロセスモデリングの目的は、プロセスを他の人に示し、伝達し、教育することです。また、モデルを元に問題点を明らかにして改善することができます。また、シミュレーションによる予測も可能になります。チケット駆動開発におけるBTSのチケットは、タスクの計画であり、履歴です。この情報は非常に価値のあるものです。

近年、注目されている研究分野にリポジトリマイニングというものがあります。リポジトリとはソフトウェアの開発基盤のデータのことです。具体的には構成管理ツール、障害管理ツール(BTS)、メールサーバなどのデータを分析する研究です。ソースコードのメトリクスを元に障害の含まれていそうな(フォルトプローン)モジュールを探す。構成管理ツールのコミット履歴から、別の障害と関連(ロジカルカップリング)するモジュールを探す。あるいは障害履歴からプロジェクトの今後の予測を行う。など、多くの研究が行われています。

1990年代半ばにプロセスモデリングの研究が盛んなころ、タスクの分割や新たなタスクの追加、あるいはタスクの削除などはプロセスの動的な変更と呼ばれ、それをどのようにモデリングするかが研究の対象でした。そのゴールはシミュレーションでしたので、すべてを記述できる必要があったのです。

しかし、記述力やシミュレーションといった研究を目的とした場合、実際の履歴データを利用する際に変換が必要です。なにか機械的に変換できる方法があればよいのですが、そもそも履歴を収集する方法がありませんでした。

プロセスの動的な変更にはノウハウの素が詰まっています。プロセスを動的に変更するということは、何らかの計画外の事象が発生したということで、追加されたタスクはその解決法と予想できるからです。

かつて私は、この動的な変更を収集しようと試みたことがあります。その際はデータを収集するために週報をすべて読んで、手作業で収集しました。

多くのノウハウを得ることができましたが、いつ使われるかわからないノウハウ収集を日常的に実施することは現実的ではありませんでした。

ところがチケット駆動開発をしていると仮定したなら、すべてのタスクはチケットに記録されています。さらに原因となった問題のほか、解決に至る議論、そして解決法を実践した具体的な成果であるソースコードに関連付けられています。

それらはノウハウそのものです。しかも、それらを無理に変換する必要はなく、利用可能です。知りたいノウハウがあれば、そのキーワードを元に開発中に発行されたチケットを検索すればよいのです。それだけで過去の課題や議論、具体的なソースコードまで入手できるのです。

貴重なデータを入手できるようになるのですから、研究的には色々と可能性が考えられます。チケット駆動開発のリポジトリは研究に必要な情報が記録されていて、マイニングの対象として向いていると言えるでしょう。そして、その研究成果はプロセスモデリングが目指していた課題にも生かせます。

このように、チケット駆動開発が今後のプロセスモデリングの研究を大きく変えることになる可能性を感じています。

[#TiDD] チケット駆動開発はプラクティス？プロセス？それともアジャイル？

チケット駆動開発はプラクティスですか？プロセスですか？アジャイル開発ですか？

そういった疑問を抱かれる方もおられるでしょう。この答えは人によって違います。これをテスト駆動開発(TDD)の例を使って説明してみましょう。

テスト駆動開発はJUnitを用いて開発する方法(プラクティス)です。実行コードを書く前にテストコードを書くことで、テストが実行された実行可能なコードを徐々に増やしていく方法です。テスト駆動開発は従来型の開発においても有効で、多くの開発現場で利用されています。

ここで、JUnitがCIツールの機能が追加されたことをイメージしてください。JeninsのようなCIツールは、TDDの単体レベルのテストを常に実行できるほか、結合テストや静的解析、デプロイまでできます。もちろん、従来型の開発においても有効ですが、アジャイル開発の様に繰り返して開発やリリースを行うことで、より効果を実感することができるでしょう。このようにツールが多機能になればなるほど、プラクティスというよりもプロセスに近くなります。

これと同じ混乱がチケット駆動開発にもあります。チケット駆動開発はBTSのチケットを利用してタスクを管理する方法です。このチケットは構成管理ツールと関連付けられています。

ここまでの説明は比較的単純です。しかし、実践してみると、チケットの利用だけを捉えても、WBSとして利用も可能ですし、それをガントチャートで示すこともできます。

個人の忘備録としても使えますし、本来の機能であるプロジェクトの課題や不具合を管理することもできます。また、一覧はタスクボードですし、バーンダウンチャートを示すプラグインもあります。

さらに便利なことに、BTSには複数回のリリースを想定したマイルストーンやバージョンと呼ばれる属性があります。

このように、チケット駆動開発は従来法からアジャイル開発に至るまで、様々な利用が可能です。このため、プロセスを補完するプラクティスでもありますし、プロセスの根幹をなす仕組みとしても利用可能なのです。

さらに、アジャイルの定義は人それぞれです。もちろんアジャイル宣言がアジャイルの定義であることは誰もが認められるところです。しかし、アジャイル宣言の背景にあるものを満たしていれば、必ずしもすべてを満たしていなくてもアジャイル開発と呼ばれているのが現実でしょう。

そこにもまた幅があり、ユーザへの価値の提供、ビジネスモデル、オフェンシブな開発、さらにはソウル、ロック、パッションという言葉でアジャイルを語る方もおられます。このような幅がアジャイルの議論を混乱させる要因ではありますが、この幅こそがアジャイルのすそ野を広げることになっているとも思います。

チケット駆動開発をどう定義するか、それは難しい問題ですが、必ずしも解決しなくてよい問題だと思います。できればそのままに広く情報交換して、それぞれのプロジェクトにふさわしい形でチケット駆動開発が実践できるようになればと思っています。

[#TiDD] プロジェクトを成功に導くチケット駆動開発のビジョン

巷では「ソフトウェア開発では○○％のプロジェクトが失敗している」と言うことが語られることがあります。ありがちな成功の定義では、ＱＣＤ、つまり、品質が高く不具合の数が見積もり以下、予算内で収まる、納期までにリリースできる、といったところでしょうか。請負開発はもちろんのこと、準委託であっても、予め計画される場合ならば、発注元の観点からはこのような基準かもしれません。

一方、アジャイル開発では顧客の価値を生み出すことが目的ですから、より顧客のビジネスに利益をもたらせるソフトウェアをリリースできたか、信頼性ではなく広い意味の品質という意味のＱとして、より良いＱＣＤのバランスが取れたかどうかによって、成功を判定すべきでしょう。

しかし、これらの成功の基準はプロジェクトをブラックボックスとして見た場合のものです。実際のプロジェクト(開発の現場であるリーダーやメンバ)にとっての成功とは必ずしも一致しません。プロジェクトの成功とは、開発者の能力を最大限に発揮できたかどうかではないでしょうか？

この「開発者の能力を最大限に発揮する」というのは、プロジェクトファシリテーションの目的そのものですが、チケット駆動開発の求めているものもこれだと思っています。

成功したプロジェクトを見ていると、そこに共通するチケット駆動開発のビジョンがあると思います。それは、ツールの導入や型にはめるのが目的ではなく、プロジェクトの問題を明確にした上で、ツールを道具としてふさわしいプロジェクトを目指していることだと思います。

チケット駆動開発の導入によってできることは、だいたい以下のようなものでしょう。

・プロセスの自動化(チケットと更新の関連付け)
・プロセスに制約を加える(ワークフロー)
・オンライン化による情報共有とコミュニケーションの迅速化
・問題点とゴールの見える化による安心感の増加(バージョンやマイルストーン)
・変更の節目を作ることによる作業への集中

これらをどのように取り入れるか、そこにはとても大切な視点があります。一つは、上述のようにプロジェクトの問題を明確にして解決することです。その際に重要なもう一つの視点は、オスターワイル氏が言ったように「プロセスはソフトウェア」であると考えることです。コードをレビューするときの様に、シンプルでわかりやすく、論理的かつ合理的で、必要不可欠なものでなくてはなりません。運用ルールを決めたり、場合によっては今までの文化に合わせることも必要かもしれません。

つまり、開発者を疲弊させず楽にする、単純な仕組みでリズムを与える、割り込みをコントロールする、不安感を減らしてゴールを明確にする、運用ルールを明確にして作業に集中できる、そんなプロセスを実現すること、それが大切なビジョンだと思います。

[#TiDD] アナログ重視のアジャイルとチケット駆動開発の違い #RxTstudy

Redmineとタスクマネジメントの勉強会であるRxTstudyの第3回勉強会に参加しました。

「Redmineプラグインの作り方(仮)」：@agilekawabataさん
残念ながら懇親会費の集計やお釣りの準備などで、川端さんプラグインのお話はあまり聞けませんでしたが、キチンとフックを使ってプラグインが完成したようです。あとでお勉強しようと思います。

webサイト「Redmine.JP」 4年4ヶ月： 前田 剛さん
2番目の前田さんは、私も色々とお世話になっているRedmine.jpというサイトのお話でした。アンオフィシャルではありますが、多くのRedmineユーザがお世話になっていると思います。 nanocというテキストベースのCMSで管理されているそうです。Redmineの普及とともにドンドン稼いでいただいて、今後もさらに良いサイトにしていただきたいと思います。

Backlog の開発で大事にしていること：@tksmdさん
どのようにより良いUiを作るか、「仕事を楽しくして何が悪い！」と、どのように開発者の能力を発揮させるかという熱い発表でした。技術者として、より良いものを作るという姿勢がうらやましく思えました。発表の中でサブタスキングの要望に対して、説明できないものは導入しないとの姿勢でしたが、Rubyの松本さんの名言「ある種の制約は自由を増す」という側面もあるのではないかと思いました。

チームにRedmineを適用せよ：@daipresents 藤原 大さん
先日も品川Redmineで発表された藤原さんですが、今回は別の内容でお話ししていただけました。今回は品川で、疑問だったRedmineのタスク管理をやめてアナログにされたことについて、ヒントをいただきました。Scrumを進めているうちに、Redmineのチケットがの更新が負担なったこと、タスクは2-3日ぐらいの粒度にそろえているというお話でした。あと、Doingのチケットは2枚までにされているとのことでした。

メリットから考えるアジャイルとチケット開発の違い

チケットの粒度は良く議論されるところです。私は細かなチケットがBTSへの依存を増し、仕事のミスを減らしてくれると思っています。XPJUG関西で議論した際も、チケットは付箋、備忘録のように使う、という議論がありました。これは、ライフハックのGTD(リンク先はWikipedia)のような考え方です。作業の大きさではなく、リスクに気付けば、チケットを切り、プロジェクトのリスクを共有していく開発法だと思っています。

一方、Scrumのようなアナログ重視のアジャイル開発ではタスクの粒度をそろえて、プロジェクト全体を見渡せるようにします。プロジェクト全体でゴールを共有し、作業を進めていきます。

チケットあるいはタスクカードの粒度を除けば同じようなことをしているのですが、重視するものが違うように思います。タスク(チケット)の粒度をそろえられるということは、そこに含まれる細かな問題は把握されていることがある程度前提とされていると思います。つまり経験値の高い熟練者なのでできると思います。もちろん、細かな問題はあるでしょうから、それは、それは早めに小さく失敗するということなのでしょう。

一方のチケット駆動開発は、そんなに安心できない未経験なことが多く発生するプロジェクトに有効です。わからないことが多いから気付いた人がチケットを登録し、問題点をを皆で共有し、協力します。これは次々と色々なアプリケーションを色々な環境で開発する独立系の会社や、新規性の高い戦略的な開発などに有効なのかもしれません。

この辺りは懇親会で皆さんと議論していたところなのですが、残念ながら藤原さんとはあまりお話しできなかったので、いつか議論させていただきたいと思います。

Agile Japan 2012でお話しします。

さて、3月16日（金）に大阪のATCホールでAgile Japan 2012が開催されます。これまでAgile Japanは東京で開催され、大阪はサテライトの扱いでしたが、今年は初めて大阪で開催されます(RxTstudyも後援してます)。

この中のセッション「チケット駆動開発の課題と展望」で、小川(あきぴー)さん、中村 洋さんと共にお話しさせていただきます。チケット駆動開発の背景にあるビジョンについてお話しするつもりですので、今回の議論にも少し触れると思います。

なお、今回のキーノートスピーカーは、アジャイルサムライのJonathan Rasmussonさんです。ぜひお越しください。　

[#TiDD] チケット駆動開発で困難を乗り切ろう！ #47redmine

ソフトウェアの開発対象は色々あります

1) 大規模で大変な開発
2) 時間がかかっても安く仕上げないといけない仕事
3) 短期開発が必要な小規模開発あるいはその組み合わせ

このうち、1)はゼネコン的な会社の従来型の開発によってそれなりに安定してきているでしょうし、2)はオフショア開発が実践されるのでしょうね。そのように考えると、中小のSIerが受注できるのは3)の短期開発プロジェクトなってしまいます。

そこでは、競争が過熱し易いので、期間が短いだけでなく、コストの厳しいものになりがちです。それなりに仕事がいきわたっている間は良いのですが、景気が冷え込みだすと無理をする会社が現れます。社員を遊ばせるよりはマシだからと、利益が出せないような金額で受注する会社が出てきます。

そのように無理な金額で受注した際に取れる方法は以下の3つです。

1) 赤字覚悟で普通に開発する
2) 手を抜く
3) 効率化する

無理な受注が1回だけなら1の方法も可能です。しかし、企業である限りは利益が必要なので、安易に2番の方法が取られがちです。手を抜くと言っても機能が実現できなければ納品できないので、どうしても品質確保に必要な作業を端折ろうとしてしまいます。しかし、これが最悪の選択であるのは皆さんご存知でしょう。ひとまず納品できても、バグの対応で大変な作業が発生して、利益が開くなってしまうからです。

そこで、唯一の方策が3)の効率化です。以下のような方法が考えられるでしょう。

・全体の作業を明示して、やる気を維持する
・知恵を出し合える環境を用意する
・作業の優先順位付けと計画・担当の見直し
・コミュニケーションを効率化し、遅延を減らす
・作業漏れが発生しないようなワークフローを実現する
・管理作業を電子化して効率化する
・トレーサビリティを高め、障害発生時の対策を容易にする

これらは、すべてチケット駆動開発で実現できることです。困難な時だからこそ求められる、効率化への果敢な挑戦です。それは良さそうだからと博打を打つのではなく、明確なビジョンを持って、論理的に導入して効率化を図るべきものです。

第2回品川Redmineが開催されました。充実居た内容に興味深くUstreamで見させていただきました。ブログを書くまでが勉強会とのことですが、今回はLTしたかった内容を書かせていただきました。

[iPhone4] 失った写真の復活

iPhone4のiOSを5.0にバージョンアップをしたところiPhoneでとった写真やビデオが見れなくなりました。試行錯誤でわかったのは、

「今までなかったアルバム(写真の同期元のフォルダ名)が見えていたら、フォルダ名を変更して同期させるとなおるかも」

という結論です。

症状：

iOS5.0にバージョンアップしたところ、アルバムが増えていました。フォトライブラリと見慣れないアルバムのファイル数が同じで、サムネイル(一覧)をみたところ以前の写真が入っていました。何かおかしくなったとは思いましたが、サムネイルが見えていたので気にしていなかったのですが、最近になって写真を見ようとすると別の内容が表示され、動画を見ようとすると

「要求されたURLはこのサーバー上に見つかりません。」

等と出て内容を見ることができませんでした。

やったこと：

ネットワークを検索すると以下のページが見つかりました。

Apple サポートコミュニティ：ミュージックビデオURL 見つからない
https://discussionsjapan.apple.com/thread/10099470?start=0&tstart=0

どうも同期関係の問題のようなので、上記を参考に写真の共有をOFF⇒ONに変えながら、何度か同期を試みました。しかし、なにも変化せず。

試しに同期元のフォルダにあるキャッシュを消すと、再構築するものの変化なし。

そこで、「ビデオ含める」だけをOFF⇒ONに変えながら、同期を試みました。すると、ビデオだけが復活しました。

解決策：

最後に試したのは写真の共有元に指定していたフォルダを変更したことです。私の場合、見慣れないアルバムは「iPhone4]となっていて気付かなかったのですが、実は共有元のフォルダ名だったのです。そこで、もしやと思って試したところうまくいきました。

上の「やったこと」に書いている作業を始める際に写真フォルダのコピーを作っていたので、それを指定しました。キャッシュのフォルダもそのままに、このフォルダを共有元に指定するとすべての写真とビデオが同期され直して、ようやく復活しました。

ただ、新しいフォルダ名と同じアルバムに、フォトライブラリと同じ写真が表示されるのはそのままです。大切な写真が復活したのでヨシとしています。

以上の結果から、フォルダ指定をされていたためにうまくいかなかった方は、フォルダ名を変更して同期しなおすとなおると思います。ただ、念のため、共有元のファイルのバックアップを取っておかれた方が良いと思います。

[#TiDD] ２つのアダプタブル・ウォーターフォール開発

従来型の開発をチケット駆動開発によって補完するアダプタブル・ウォーターフォールには、大きく分けて２つのパターンがあります。

１）全工程2重管理型

これは上流工程から下流工程までチケット駆動開発するものです。すべてのタスクをチケットで管理しますが、既存のプロジェクト管理と併用します。既存のプロジェクト管理では、ベースラインごとに計画が定められてそれを基準にプロジェクトの予実が管理されます。チケットに登録されるタスクはベースラインで定められたタスク、あるいは、より詳細化したタスクから始めますが、必要に応じて計画が変更されます。

この方法はすべての管理をチケットを中心に実施する完全型チケット駆動開発に似ています。チケットは階層構造を持っていますので、WBSをそのまま表現することができます。BTS/ITSのガントチャートによる進捗報告が許されるなら、管理を一元化できますので、多くのメリットが生まれるでしょう。

気を付けないといけないのは、完全型を目標にすると失敗する危険があることです。チケット駆動開発における成功とは活用されることです。現場における想定外の問題や忘れてしまいそうな作業をチケットにしておくことで、混乱状態からプロジェクトを救います。しかし、チケットの計画を柔軟に変更するとプロジェクト全体の予実管理が困難になることから、開発者による計画の変更が制約される可能性が出てきます。工事進行基準が適用される場合など柔軟に計画を変更できない場合には、あえて2重管理した方が良いでしょう。チケットは動的な管理、エクセルはスナップショットの管理に向いていますので、うまく使い分けてください。

なお、上流工程からチケット駆動開発すると、チケットが膨大になりがちです。計画変更時に各チケットを修正するのは大変です。そんな場合は、エクセルと連携して修正後にインポートする方が効率的でしょう。MS-Projectのような日程調整ができるようにマクロを書かれている方もあるようです。

最近は、チケットの修正が大変だからと日程を入れない方も多いようです。この場合はRedmineのBacklogsなどアジャイル用のプラググインが使われる場合が多いようです。標準の環境でも、マイルストーン(バージョン)を定義しておき、ロードマップなどの一覧で見ることによって、日程を入れないで管理することができます。これは、比較的短い期間にやらないといけない作業が順序を決めずに置かれている状態です。ガントチャートでいうならば、マイルストーンまでの期間に平行に複数のタスクの線を引いているのと同じです。

作業の順序を決めておくことが作業計画に役立つのであれば日程を入れればよいですし、それよりも計画の柔軟性が重要であれば、マイルストーンによる管理が有効でしょう。

２）下流集中管理型

名前のとおり、テスト工程以降(下流)においてタスクを集中管理するチケット駆動開発です。

テスト工程では、準備とテスト種目毎の計画が立てられて、それぞれの消化項目数で管理されることが一般的だと思います。しかし、実際には準備期間はもちろんのこと、テストごとにも細かな準備があり、作業の実施順序や作業漏れの有無によって効率が大きく変わります。

そこで、テスト実施に必要となる作業をチケットとして登録しておきます。これらは、元の計画にない作業ですのでチケットが元の計画を補完していることになります。開発者はチケットによって作業を計画し、日々、全貌をチケッでを確認しながら作業を進めることができます。

この事例は、先日、RxTstudyで発表しましたので、よろしければそちらの記事をご覧ください。

[#TiDD] チケット駆動開発で自律的な組織を目指す

自律的な組織とはリーンソフトウェア開発で「海兵隊」で示されたような、自己決定のための裁量権を持っていて、課題や問題を自らの判断で解決できる組織です。集中体制は変化に弱く、想定外の事象によって独裁国家の様に一気に崩壊する危険性をはらんでいます。これに対して自律的組織は、オブジェクト指向のメタファに用いられる多くの細胞の組み合わせからなる生命体のような構造です。各細胞に対する攻撃は、各細胞やその近隣の細胞で解決されますので、想定外の事象にも比較的強い構造といえます。

自律的組織を実現するには自己決定権を実現するための見積もり技術が不可欠ですが、ここでは単に裁量権の観点で議論してみます。

１．アジャイル開発における自律的な組織

アジャイル開発においては、開発組織とユーザとの間で、優先順位したがって各イテレーションのスコープが決定され、開発組織の裁量で開発作業のタスクが実施されていきます。タスクはタスクボードで可視化され、状況と課題が共有され、開発者たちの決定をコミットすることで開発が実施されます。

注目すべきは、アジャイル開発のプロセスとして決められているルールの中に自己決定のための裁量権が明示されていることで、自律的な組織を実現している事です。

２．従来法における自律的な大規模組織

アジャイル開発によって実現される自律的組織ですが、従来型、いわゆるウォーターフォール開発においても自律的な組織が構成されることがあります。それは開発対象が複数のサブシステムに分割されて、それぞれのチームに裁量権が与えられている場合です。各チームにおいて、課題や問題を自らの判断で解決することができます。

しかし、従来型の開発においてはその裁量権の多くをリーダーが独占しています。他のチームに対してのみ自律的であり、開発者はチーム内の状況をリアルタイムに知ることができず、問題や課題の解決を検討することすらできません。

３．自律的な小規模チーム

小規模なチームの場合は、従来法による開発であっても、ある程度は自律的な開発を行うことができます。大規模開発において、自律的な開発の最も大きな障害は、最新の状況をリアルタイムに知ることができないことです。状況を知らなければ、その解決ができないからです。

小機御組織においては、全員の状況を互いに知ることが可能です。日々の打ち合わせにおいて、(1)コミュニケーションを活発にして状況を共有する、(2)その解決策をチームで検討する、(3)協力して解決する、という状況を作り出せれば、チームは自律的な開発を行えるようになるでしょう。

しかし、その状況を作り出すには、リーダがあまり口を出さないこと、開発者の技術力とコミュニケーション能力の高いことが求められます。また、会議は口頭で行われますので、時間がかかること、声の大きい人が勝ってしまう危険性のあること、に注意が必要です。

４．チケット駆動開発による自律的な開発

チケット駆動開発においては、2種類の自律性があります。タスクはチケット化され、個人の作業管理に役立つ粒度にまで分割され、開発者によって担当チケットが自律的に管理されています。また、チームの課題や問題もチケットを介して共有されますので、アジャイル開発はもちろんのこと、従来法においてもリーダの運営次第でより自律的な組織運営が可能です。

チケット駆動開発で得られる自律性は、リーダの権限を委譲して開発者に裁量権を与えていることに注意する必要があります。開発者は、リーダの指示に従うだけではなく、同じゴールに向かって協力し合う必要があります。

自律的な組織では「アジャイルと規律」で言われてるように、開発者には高度な技術者が求められます。少なくとも状況を把握して判断できる能力が必要であるからです。また、互いに協力して作業するには、ある特定の技術ができる専門工ではなく、一通りの作業のできる多能工であるほうが、作業を柔軟に割り当てられるので有利です。

５．まとめ

このように自律的な組織を実現するには、ルールの中に自律的に計画変更する要素が含まれるアジャイル開発がが有利です。しかし、小規模な開発であれば自律的な開発を進めることもある程度可能ですし、チケット駆動開発においてはより有利になります。もし可能であるならアジャイル開発を、そうでなければチケット駆動開発を検討してみる価値があると思います。

自律的なチームを構築できたなら、開発者の能力を最大限に引き出せる可能性があります。チケット駆動開発は自律的な組織に必要となるリアルタイムの情報共有を可能にし、プロジェクトを支援します。その適用可能な分野は広く、様々なプロジェクトがあるでしょう。

ソフトウェア開発を成功させる秘訣は、そのプロジェクトにふさわしいプロセスを実現することです。チケット駆動開発には多くのバリエーションがありますので、多くのプロジェクトに役立つ可能性があります。今後、どのようなテーラリング(カスタマイズ)が可能であるか、整理していきたいと思います。

レビューを考える - SEA関西プロセス分科会 - #seakansai

森崎先生のレビューの講演に参加しました。
個人的には＠ITの記事のようなことを期待していたのですが、そのような記事ではわからない議論をすることができてとても有用な講演でした。

議論を通じて感じたことは以下の点です。

(a) 開発者は項目の抜けに敏感

　実践していなくても頭の中がWモデルになっているのかもしれません。テスト項目の源泉を仕様書に求めるので、どうしても項目の抜けが気になるのでしょう。

(b) レビューに優先順位をつける

　優先順位というとリスクベーステストを思い浮かべてしまい、全てをしないでどうするのかと思われるかもしえません。しかし、極限までレビューすることは困難で、時間の制約や体力の限界で終わってしまうので、優先順にレビューのフォーカスを変えていくことが有効だと思いました。

(c) レビュー道の極意は、レビューをせずにバグをとる

　私が勝手にN先生のフロントローディングの話をまねました。すべてをレビューできなければ、その対象を減らすために、ドキュメントのひな型を用意する、ワープロの文章チェック機能を使う、エディタの自動整形機能を使う、静的解析ツールを利用するなど、効率化や自動化は有効でしょう。

(d) レビュー技術の研鑽には経験を積むことも重要

　ドメイン知識がソースコードになっていることから、コードを良く知っているというのも、抽象化できる人なら高度な技術者なのだろうと思います。理由もなく、これまでそうしていたからというのは統一性には役立ちますが、将来役に立たなくなるでしょう。

(e) レビューの特性を生かせ

　テストで見つかると工数がかかるからということがレビューのモチベーションになっていますが、それだとどれだけ時間をかけても良いことになってしまいます。しかし、欠陥の種類によってはテストの方が早く見つかるものも少なくないでしょう。懇親会ではテストは積み上げという議論があり、それからするとレビューの特徴はトップダウンです。レビューに向いているトップダウンでしかわからない所を攻めるべきでしょう。ボトムの細かなところは、なるべくほかの手段で済ませたいですね(それには(c)が有効でしょう)。

つらつらと書きましたが、このようなことを考える良いきっかけになりました。

[#TiDD] デジタル化の効果をファシリテーションに利用する

第2回RxTstudyの講演ではお話しできませんでしたが、コーチングについて少し触れたいと思います。
コーチングに関しては、以前「チケット駆動開発とコーチング」でも少し触れていますが、コーチングは性格を変えるものではなく、それぞれのタイプにあった対応をするそうです。たとえば、スライド中の性格の分類で一番気の弱いアナライザなら、直接お話しするよりもメールでやり取りをするようです。

このことは、デジタル化の特長を利用したものだと思います。デジタルはアナログと違って1か0です。同じ文章であるなら積極的な人も消極的な人も受け取る人の印象は同じになうからです。また、口に出しては言えなくても、文章でなら言いやすいというのもあるでしょう。

掲示板やTwitterなどで強気の発言や毒のある発言をする人に、実際に会っってみると意外と優しい感じの人だったという経験をされた方も多いと思います。それは、このようなデジタル化の効果だと思います。

さて、プロジェクトファシリテーションの目的は、メンバーの能力を最大限に発揮させることです。ファシリテーションの能力が求められる立場の人は、口頭でモチベーションを高めたり、説明する機会も多いでしょう。そこで、ファシリテーションを勉強すると、自分には出来そうもないことも中にはあると思います。それは本当にできる様にならないといけないかというと、必ずしもそうでないと思っています。

「メンバーの能力を最大限に発揮させる」といった時、そのメンバーは誰なのかと考えると、そこにはリーダーも含んで良いと思います。もちろん、最低限のことはできなければいけないとは思いますが、自分の個性を知って、できないところは、デジタル化の力や他の人(メンバーや上司など)の力をうまく使えば良いと思います。

もちろん、メンバーの中にはリーダーはこうあるべきというイメージで評価する人もいるでしょう。プロジェクトを成功させるには、その様な人の能力、リーダー本人の能力、全て含めて最大の能力が発揮できるようにすることが大切なのだと思います。

そして、そのような考慮は、プロジェクトの特性やメンバー構成を考慮して配員する際にも有効だと思います。

[#TiDD] アダプタブル・ウォーターフォール開発の事例 ～想定外の作業はチケットで補完せよ!～ #RxTstudy

第2回 RxTstudy(Redmineやタスク管理を考える勉強会＠大阪)で講演をしてきました。

これまで、補完型チケット駆動開発と呼んでいたもののうち、従来型の開発に提要したものをアダプタブル・ウォーターフォール開発と呼んでいます。今回はその事例を紹介します。

講演で少ししかお話しできなかったコーチングのお話は、別の記事に書きました。

アダプタブル・ウォーターフォール開発の事例 ～想定外の作業はチケットで補完せよ!～

View more presentations from Makoto SAKAI

要求開発はアジャイルのフロントローディング #redajp

要求開発アライアンス 西日本の10月勉強会に参加しました。

これまで、XPJUG関西のMLなどで名前は知っていたもののよく理解していませんでした。今回はチュートリアル編と言うことでお勉強のために参加しました。

まずは稲田さんの概要説明です。感想を交えながら主要なキーワードを説明されました。後半は「要求開発~価値ある要求を導き出すプロセスとモデリング」の共著者の萩本が、要求開発への思いを要求開発、そして匠メソッドに至った経緯を含めて説明されました。

１．全体の感想

最も印象的だったのは

「開発時にモデリングしていては遅すぎる」

と言う言葉でした。アジャイル開発では、顧客に価値を提供するために優先度の高い仕様から実現しますが、要求開発はバックログとして仕様を具体化する前にも、IT技術者が関わって価値の高い者を提供しようというものです。いわば、アジャイル開発のフロントローディングです。

このことが実現できるなら、仕様をあらかじめ決めざるを得ない、アジャイル開発の効果が少ない場面でも有効だと思いました。スコープが変更できない場面でアジャイルは、段階的に開発することで、技術的に未知な部分やUXのリスクを低減できるものの、価値を想像するという感覚は生まれません。そのような開発においても、IT技術者が要件定義の最初から関与することで、戦力的な価値を提供可能な要求を開発することができると思います。

２．要求開発が提供するもの

要求開発は、必要な事と、選択して整備する仕組みを提供します。

その基本は、こたつモデルと呼ばれるもので、戦略的(将来の価値)、業務問題解決(現在の価値)、技術活用の視点、この3つでこたつを囲むように進めていきます。価値、戦略、業務、IT活用、IT実現、に分けて、それらをつなげて、同時並行に回します。早くつなげて価値を創造するのです。戦略と実現の線上にしか価値は存在しないのです。

これらはWHATとHOWの関係です。実装(HOW)に対する要求(WHAT)のように、要求(HOW)に対する業務(WHAT)、業務(HOW)に対する戦略(WHAT)という関係です。これらを、トップダウンに決めるというよりは、HOWを手さぐりしながら開発していきます。そこでは、ものを作る力ではなく、描く力(価値・要求を手さぐりでデザインする)が重要です。要求開発で用いる「プロジェクトシート」は将来の価値と短期的視野で表します。

要求開発で実施することは、フェーズ(準備、立案、デザイン、シフト)とPDCAのマトリックスで表され、「プロセスキャビネット」と呼ばれます。これらは選択的に実施されるのですが、プロセスセルという枠組みがあり、必要と思われるものを組み合わせてプロセスフローを実現します。稲田さんは、この仕組みを「詳細に走らないように用いています」とのことでした。

３．要求開発への思い

要求開発は、萩本さんをはじめとする、今世紀の初めの頃の豆蔵の方達が提唱されました(豆蔵は、オブジェクト指向、RUP、アジャイル開発などで有名な会社です)。ビジネスの開発方法論の必要性から、BDA(ビジネス・ドリブン・アーキテクチャ)、そして要求開発の方法論に発展したそうです。要求開発はカスタマイズ可能で、目的と手段を連鎖させ、プロセスセルはPDCAの慣習化として実現され、無駄なものを作らない方法です。そこには、分析モデルを開発で作るのはおかしい、という思いがあったようです。

要求開発では価値のあるものをつくります。要求開発の4象限はRUPと同じで、HOWはWHATに、つまり価値の高いものを作るためにITエンジニアが手さぐりの協力をします。システム開発以降でIT技術者が協力してももう遅いのです。業務を変えないといけないので、開発はビジネスのところでします。ビジネスの中でアジャイルするのです。

ビジネス戦略を決める際に予想することはは難しいです。やっていないとわからないところがあるので、それをアジャイルでやってみます。そのために、「こたつモデル」は重要で、知識のカスケードをするためにこたつを実現します。ただ、立場の違う人が集まるだけでは空中戦になりがちで、声の大きいものが勝ってします。そこで、ファシリテーションとマネジメントが重要になってきます。

このような萩本さんのお話を聞いて、なぜXPJUG関西の人たちが注目しているかがわかったような気がしました。

４．まとめ

ソフトウェア開発は、単純なウォーターフォールモデルで実現できるような簡単なものではなく、自分たちの能力とその限界を知った上で最高のパフォーマンスを実現しなければうまくいきません。そのための一つの答えがアジャイル開発であったのです。しかし、システム開発を最初からアジャイル開発だけで実現できないので、従来のV字モデル(あるいはW字モデル)の実装部分だけを、アジャイル開発に置き換えている会社も多いでしょう。でも、それではだめだったのです。

価値の高いソフトウェアを開発するには、要求は定義するだけではだめで、開発しないといけないということなのです。要求開発は、いわば「アジャイル開発のフロントローディング」だったのです。

(聞きかじりを個人的な思いでまとめました。間違い等ありましたらご指摘ください)

アジャイルを考える - Agile Tour Osaka 2011 -

去年は自宅で見ていたAgile Tour Osaka 2011ですが、今年はLTに出番がいただけたので朝から参加しました。講演を聞く中で、多くの刺激をいただくことができました。

１．インパクトのあった言葉

アジャイルを標榜しながらもチケット駆動開発で現場を改善しようとしている私にとって、最もインパクトのあった言葉は、

・アジャイル開発ができない理由として「制約」と言われるものは「解決すべき妨害事項」

・「守破離」と言われるが、「守」をせずに「破」をしてしまう

という@ryuzeeさんのお話でした。@ryuzeeさんのほか@smorisaki先生のお話にあったように、何かをするには説明責任が伴いますし、何かをせずにおくことも

・変化しなければ緩やかに滅びる、という背任！(@ryuzeeさん)

であるなら、安易にプロジェクトを進めるのではなく、解決すべき妨害事項が現時点においては制約であることを説明する必要があると思いました。

２．アジャイル開発導入への妨害リスト

私から見えている「妨害リスト」は以下のようなものだと思います。

契約
まずはこれでしょう。準委任でなく一括請負になる場合には、減価償却したいという場合があって、ちょっと厄介です。また、藤井さんの講演にあったように、信頼関係を築かないと始まりません。

多能工を増やせない
複雑で先進的なシステムの場合、すべてを把握・実現できる多能工ではなく、専門工になりがちです。いずれは多能工化したくとも、新しい技術を順次取り入れたり、新しい人が入るような状況だと、実現が困難になります。

システムの並行開発
連携する複数システムを並行して開発する場合など、あらかじめインタフェースを決めて開発します。インタフェース汎用的でない場合などは仕様が限定されてしまい、段階的にリリースする場合も、スコープの変更ではなくリスク低減が目的とされます。

危機感の共有
実は、組織やチーム内の合意形成が最も困難ではないかと思っています。様々なステークホルダーのいる中で、プロジェクトの目標は、価値、利益、信頼性、QOLなど様々ありますので、プロジェクトの問題点が共有でき、解決法としての合意が必要になります。

それぞれ程度の問題で、簡単な問題や長期的に効果が見込める問題であれば解決すべきでしょう。

しかし、現実を見ると目の前にはプロジェクトがありそこで求められていることは、アジャイルを実践することだけではありません。すぐに求められていることは、アジャイルを実践した先にあることなのだと思います。

２．アジャイル開発導入をあきらめてみる

アジャイルを一旦あきらめて、すぐに解決したい問題の観点で、各講演を見直すと、以下のような項目があがります。

任せること(設楽さん)
そのために細分化、見える化、自動化する。見える化は変化を検出可能にすること。チケットをうまく使えばできそうです。

説明すること(森崎先生)
事例とシミュレーションを組み合わせて説明する(Exsample scenario)。全てを実績で説明することが困難な場合、過去の実績と未来の予測を組み合わせて利用する方法です。メトリクスサーバをうまく利用できそうです。

見積もりと計画(藤井さん)
処理されるデータを中心に見積もるCOSMIC法は興味深いと思いました。ファンクションポイント法も表面的な機能だけでなく、内部のデータも見積もりに加える事例もあるようですので、分野によっては効果的だと思います。また、ベーム先生のアンカー留めスパイラルモデル(1994)は、マイルストーンをしっかり決めて守る事なのだと思います。この他にも、アジャイルＵＰ、ＡＭＤＤ、southernSCOPEといったキーワードは参考になると思います。

自己組織化(吉羽さん)
トップダウンの外科医チームのような組織は、構造化プログラミングされた巨大なプログラムだと思いました。頑張れば何とかなるかもしれませんが、外乱に強い安定した組織にするには、オブジェクトの能力が発揮できる自律分散型の組織が必要だと思いました。

これらは、成功したアジャイルにより得られるものではありますが、危機感の共有と工夫によってある程度実現できるのではないかと思っています。そして効率化していけば、その先にアジャイル開発に近いものが見えてくるのではないかと思っています。

謝辞

このように多くの刺激をいただけたAgile Tour Osaka 2011のスタッフのみなさま、発表者の皆様に感謝いたします。