無料ブログはココログ

« 2011年5月 | トップページ | 2011年8月 »

[#TiDD] マイルストーンを定める - ソフトウェア開発で重要なこと その1 -

チケット駆動開発やアジャイル開発はもちろんのこと、オブジェクト指向もあまり知られていないころに、先輩技術者からソフトウェア開発で重要なことを色々と教わりました。今にして思うと、そのころ教わった古(いにしえ)の知恵は、チケット駆動開発やアジャイル開発の理解につながっています。

<マイルストーンとは>

マイルストーン(リンク先はWikipedia)とは距離標識の一種で、日本風にいうなら一里塚です。マイルストーンがあることで、全体の行程の中でどの場所にいるのかを知ることができます。また、目印にもなりますので、待ち合わせにも用いることもできるでしょう。

ソフトウェア開発に限らず、人は目標がないとうまく作業ができません。いつまでに何をするか、期限や成果物あるいは中間成果物を定めることで、目標ができるのでその目標に向かって作業を進めることができます。また、あらかじめ定められた行程のなかでそのマイルストーンの位置をあらかじめ知っていつなら、現在の状況を定量的に把握できるようになります。

<マイルストーンの教え>

作業をより進めやすくし、より詳細な状況を把握するには、小さな作業に分割してマイルストーンを定めます。細かに分かれた各マイルストーンに向けて作業を実施し、その状況を管理することで、作業がより明確になるのです。

一方、作業に依存関係がある場合は、マイルストーンに達するのを待って、次の作業を始めます(一里塚のメタファで言うなら駅伝のイメージでしょうか)。大きなマイルストーンは、工程の切れ目としての段階的な品質保証のタイミングや、他のチームと連携するためのリリースタイミングとして用いられ、開発全体の整合性が保たれていました。

<現代のマイルストーン>

現代風にいうならば、小さなマイルストーンはタスクカードやチケットの完了、大きなマイルストーンはスプリント(イテレーション)の完了、あるいは、アジャイルリリーストレインの連携ポイントとなるリリースにあたるでしょう。

本来のマイルストーンは、必ずしもプロジェクト全体で共通のものであるとは限りません。チケット駆動開発ではチケットの完了日を個別に定められることが細かなマイルストーンに当たります。もちろん全体のマイルストーンとして、BTSのバージョンやマイルストーンの機能によって、プロジェクト共通のマイルストーンを定めることもできます。

<マイルストーンで重要なこと>

昔も今もにおいてもマイルストーンで重要なことは変わりません。それは以下の3つです。

(1) タスクのゴールを明確にすること

何をいつまでに作成するのかを明確にしなければ、マイルストーンとして意味がありません。共通の理解が可能な明確なゴール(期日と成果物/中間成果物)を定める必要があります。

(2) 管理が容易なタスク粒度

詳細なマイルストーンは、作業に集中でき、管理が容易なように、一定の粒度以下に分割しなければなりません。具体的な粒度は、プロジェクトの規模や開発対象によって、スプリント(イテレーション)期間と共に決めればよいでしょう。

(3)リリース計画を定めて整合性を保つ

それがアジャイル開発であるかどうかにかかわらず、最終的なゴールに対してリリース計画の整合性が保たれていなければいけません。特に複数のチーム/タスク間で依存関係がある場合は、後続の作業に影響を与えないように計画しなければいけません。

<おわりに>

このようにマイルストーンの重要性は、昔から変わりません。どのようなプロセスで開発するか、どのようなツールを使うか、ということも、もちろん重要です。しかし、なぜマイルストーンが必要か、何が重要か、をきちんと理解して実践することも、ソフトウェア開発に重要なことだと思います。


スクラムを味方につけろ! - SEA関西プロセス分科会 -

SEA関西プロセス分科会であったScrumワークショップに参加しました。アジャイル開発プロセスであるScrumには、以前から興味がありました。しかし、かつてのCMMブームのトラウマから少し不安がありました。それは

「スクラムは敵か味方か?」

ということです。アジャイルの目指すものは大いに賛同できるものですし、合理的であると考えていました。しかし、スクラムが普及し、組織的な導入が増えるにつれて、「本当に大丈夫なのか?」とおぼろげな不安を抱いていました。

しかし今回のワークショップに参加して、その疑問は氷解しました。

<CMMブームのトラウマ>

敵か味方かという不安は、1990年代半ばにCMMが普及しだした頃にも感じていたことです。それまでのソフトウェア工学の成果を集大成し、組織の成熟していく道を示したCMMについて、ソフトウェア工学を学んだ人間として、必ずしも反対するものではありませんでした。

しかし、プロセス改善と言いながらも、そのアプローチはトップダウン的でした。現場を見て改善をするのですが、現場には定められたプロセスに訓練によって慣れることが求められました。プロセス改善は現場を幸せにするものでしたが、与えられたプロセスを実践できるように現場が努力し、それが組織に利益をもたらすことをつうじて、みんなが幸せになるというストーリーでした。

CMMによる改善活動では、管理できるような組織づくりが必要とされ、作成するドキュメントが増えることがあっても、減ることは少なく、開発が安定するという幸せはあったものの、開発現場は必ずしも楽ではありませんでした。

私が理想とするプロセスは、レベルといったどこにでもあるヘビーウェイトな管理プロセスではなく、組織や業務に最適なプロセスだったのです。

CMMブームのトラウマは、知名度の向上に伴って営業に利用されるようになったことです。組織のプロセス改善が目的でなく、レベル達成という知名度の向上を目的とした企業が増えるようになりました。

そこではじまったのは、トップダウンによるプロセス改善の形骸化です。開発者の能力が発揮できるという幸せではなく、果たすべき義務の増加による重圧感が増大しました。当時、プロセス改善には経営層コミットメントが必要だと言われていましたが、現場での改善活動なしにプロセスを変更するだけでは、組織や業務に最適化されたプロセスなど望みようがありませんでした。

<第2次アジャイルブームへの懸念>

近年、第2次アジャイルブームと言われています。XPを中心とした2000年代前半の第1次アジャイルブームは現場の技術者主導の、どちらかというとゲリラ的なものでした。しかし、近年のアジャイルブームは、現場主導というよりは組織的なプロセス改善のようです。どちらかというと「アジャイルをやっておかないとまずいのではないか」という、トップダウン的な検討・導入も多いように聞いています。

この第2次アジャイルブームは、マネージメントが明確なスクラムをベースにされることが多いようです。私はCMMのトラウマから、アジャイル2次ブーム、とりわけスクラムにどのように接するべきかを見極めたいと思っていました。

閑話休題、このような懸念からも、現場の改善に基礎を置くチケット駆動開発に期待しています。そのあたりの話は、Ultimate Agile Storiesという本に記事と対談という形で載せていただきました。8/14開催(東京ビックサイト)での夏コミのほか、アジャイル関係のイベントで販売されますので、よかったら買ってください(利益は、全額、東日本大震災の被災地支援として寄付されます)。

<スクラムワークショップ>

ワークショップは実習中心でしたが、解説もありました。それによると、スクラムが野中先生らの論文がもとになっている一方で、オブジェクト指向の有名人やKent Beckらアジャイル宣言の関係者も大きくかかわっているとのことでした(まずは一安心)。

実習ではマルチタスク(仕事の掛け持ち)の大変さを実感する、全員で見積もりをするといったことが行われ、それらをベースにスクラムが語られました。これらを通して、スクラムが現場を大切にしていることを実感できました。

懇親会では、講師のおひとりである原田さんとお話しできました(もう一人は山根さん)。率直なお話が聞けたので、理解が深まったように思います。

<感想>

ワークショップで印象的だったのは

「スクラムは常に改善する」

という言葉です。これはCMMでも同じはずなのですが、常に最適化を目指すのではなく、ひとまずレベル3とかいう発想を抱きがちであったことと比べると、大きな違いです。

スクラムはゴールではありません。改善のスタートの標準的なリファレンスプロセスとして、大いに参考になるものです。スクラムを起点に継続的な改善をすれば良いのです。

スクラムのワークショップで語られることには、現場で遭遇する問題への対処のような内容もあるようです。しかし、今回のように初めてのワークショップでは、まず理想論から入られるようです。仕事を兼任せずにシングルタスクに集中することや、全員で見積もることも、ある種理想論であるということなのでしょう。プロセス改善の集まりなどで「守破離」が語られることと似ているように思います。

スクラムがCMMと違うのは、はるか先にあるゴールではないということです。遠い先に理想的なプロセスがあるのではなく、すぐそこに標準的なプロセスとしてスクラムがあり、そこから継続的な改善が始まるのです。

そこには、現場で考えてコミットメントする仕組みがあります。皆で見積もっているようでいて、その見積もりを開発者がコミットしているのです。そして、開発の速度(べロシティ)を見える化して改善していく仕組みがあるのです。

また、現場は開発作業に集中できます。複数の作業を兼務しないだけでなく、スプリント(イテレーション)の間は作業を変更しないことで、開発に集中できる仕組みがあるのです。

<スクラムを味方につけろ!>

このように、スクラムは現場を重視した改善活動の標準的なトレーニングと考えることができます。その基本を大切にすれば、現場のプロセスは改善するでしょう。

スクラムが組織的に導入される場合においても、基本が重視されるなら形骸化せずにプロセスを改善し続けることができるでしょう。しかし、基本を忘れれば、ただの繰り返し開発、ただの見積もりごっこになってしまう可能性はあります。要はプロセスを改善するのは、開発者の理解と努力次第ということなのだと思います。

CMMのブームの時、私は形骸化の危険性を感じてあまり賛成しませんでした。それは図らずも多くの事例で証明されてしまいました。その一方で、CMMを正しくプロセス改善の道具として活用した組織は、多くのメリットを得ることができたのも事実です。ブームに乗らないことは、成功でもあり、失敗でもあったのです。

スクラムはそのプロセスの中に、現場のプロセスを直接改善する仕組みが入っています。正しく導入することができれば、形骸化を避けることができます。むやみに恐れず、スクラムを味方につけることが、改善への第一歩なのだと思いました。

« 2011年5月 | トップページ | 2011年8月 »