[#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発

ウォーターフォール(WF)とアジャイルの議論はいつもかみ合いません。それは、モデルで考えるなら、1回だけか複数回かで複数回の方が変化に強いに決まっているものの、WFは決められた仕様どおりのものを作ることが目的で、アジャイルは変化に対応しながら顧客の要求に合ったものを作ることが目的だからです。目指すものが違うので、それを比較しても、どちらが良いということはありません(もちろん、あるプロジェクトにとって、どちらが向いているかはあります)。

ここでは、WFではなく「従来法」と呼ぶプロセスを考えてみます。具体的には、開発標準として、上流から下流までの段階的な工程に分かれ、各工程での作業、成果物、品質向上策のほか、メトリクスの基準が決められている。初めての技術に関しては、プロトタイピングが実施されて技術的な検証がされる。また、上流では少人数で、下流工程では増員されるようなプロセスを考えます。

このようなプロセスをWFであるとして、感情的な批判がされていることもあるようです。ここでは、感情的な議論ではなく、従来法の限界からアジャイルの利点を述べます。

「限界」としているのは、従来法がこれまではうまくいったが、近年増えつつある開発には向いていないと考えているからです。だからと言って、アジャイルが銀の弾丸とも考えていません。アジャイルが素晴らしいのは、従来法の限界を超えることができる要素を含んでいる点であり、その利点がアジャイルそのものではないからです。

そして最後に、ここで述べるアジャイルの利点について、チケット駆動開発がどのように支援するかを説明します。

１．統計・標準の限界

　従来型開発においては、多くの企業でプロジェクトのメトリクス(数値データ)が収集され、プロジェクトの管理に用いられています。また、大手の成果を参考に基準を決めている企業もあるでしょう。どこも同じような開発をしている場合には、これは非常に有効な方法でした。

1.1 母集団の変化

  しかし、近年のように多種多様な業務で、開発・運用環境の変化が激しく、実装の自由度も高くなってきた今日では、統計に基づくが故に生じる問題もあります。

• 母集団が異なると参考にならない
• 一定の比率(危険率)で、想定外にうまくいくプロジェクトが存在するはずだが、その芽をつぶす

　統計では一定の想定外が前提となっています。従来のように対象となる母集団が大きいならば、それほど問題ではありませんでした。しかし、最近のように開発対象が多岐にわたる場合は、そのプロジェクトが同じ母集団のものか、想定外のパターンになるかどうかが大きな問題となります。

1.2 技術の周回遅れ

　統計情報や経験に基づく開発標準は落ちついた技術でないと、利用できません。これは、数値基準だけでなく、チェックリストなども同じです。

• 経験のない新しい開発には標準がなく、絶対値で管理するには一定のデータが必要
• プロジェクト終了までは、その成否の結果が得られない
• 収集したデータの利用は、早くても周回遅れ(次のプロジェクトから)になる

　このように、統計を利用した開発標準による管理そのものにも、変化に対応ができないという問題があります。

  陳腐化した技術でなく、新しい技術を取り入れて言うには、データを収集したプロジェクトの中で、ノウハウを蓄積し、改善していく仕組みが必要になります。

２．リスク

　リスクは古くから「発生確率×影響」とされています。近年、開発環境が整備されることで、工数に対して多くの機能が実装されるようになりました。しかし、環境リスクはその影響は大きい場合が多くこれまでと異なるアプローチが必要です。

2.1 リスクの変化

  かつてのソフトウェア開発では、ある言語の標準ライブラリさえ熟知していればプロでした。UNIXアプリなら8分冊のマニュアルのうち、ライブラリの3章1冊で十分、システムコールの2章を知っていれば専門家です。シェルスクリプトが少し書ければ重宝されていました。そのころは外部で作られたソフトウェアが少なかったので、発生する問題の多くは、開発したプログラムに原因がありました。「発生確率×影響」で考えるとほどほどの大きさがありましたが、テスト工数にそのリスク分を上乗せしておけば、システムが動かないということはありませんでした。

  しかし、最近のソフトウェア開発、たとえばオープン系のソフトウェアなら、言語はもちろん、DB、ORマッパー、フレームワーク、などの足回りのほか、HTML、JavaScript、さらにはブラウザ固有の問題とハッキング方法まで知る必要があり、それぞれのバージョン固有の問題まで知っておく必要があります。そこで発生する問題は、開発したプログラムのほか、外部のソフトウェアの組み合わせやバージョン固有の問題などもあります。

　このように外部のソフトウェアで発生する問題は、発生頻度は低いですが影響範囲が広いので、影響度の大きいリスクです。「発生確率×影響」で考えるとそれほど大きくないリスクですので、あらかじめ担保しておける工数も少なくなります。しかし、このリスクが現実の問題となると、システムのアーキテクチャから見直す必要が生じることもあり、システムの実現そのものが危ぶまれる可能性のあるリスクです。

2.2 プロトタイプの限界

　以上のようにリスクの傾向が変化してきている中で、従来法では対応が困難になってきました。プロジェクトの後半になってから、システムの根幹を揺るがす問題が起きてしまうと、とりかえしがつかないからです。

　従来はこのような問題を解決するには、プロトタイピングが有効でした。単純な問題であれば、プロトタイプで発見することが可能ですが、特殊な組み合わせによる問題などでは、簡単なプロトタイプによる技術検証ではフォローしきれないこともあり、早くから本格的な開発を行うことが、重要になります。

３．配員・体制

  従来法のプロジェクトでは、上流でしっかりと文書化とその検証を行い、実装時に単価の安いプログラマで一気に作ってしまうという方法がとられてきました。この方法は、経験者の多くいる環境上で、文書化が比較的容易なシステムの場合には有効でした。

  しかし、経験者の少ない新しい環境や、上流で詳細な仕様を決定・凍結できない場合には多くの問題が出てきます。このような場合、メンバーは言われたことだけでなく、関連する技術や仕様を理解して、お互いに協力する必要があるからです。

  このように横のコミュニケーションが必要な場合、段階的に増員することは知識の習得やコミュニケーションに悪影響を当てます。段階的に増員すると、先に入った人が教える側になり、後から入った人が教わる側になりがちだからです。

3.1 知識の取得

  後から入った人は先に入った人に追いつくために、教育を受け、学習しなければなりません。人から教えられながら学ぶと、自分の担当の機能が中心になり、周辺の機能に関しては教わるだけで、あまり考えなくなりがちです。ドキュメントをもう少し広く読むだけでわかることなのに、問題が起きると「そんなの聞いていません」といった言葉が出てくるのは、プロジェクトの一員として問題を解決していく意識よりも、担当の作業をこなす意識の方が強いからでしょう。

3.2 コミュニケーション

　また、コミュニケーションにも上下関係が発生して、教える人と教わる人の関係では問題の発見が遅れてしまうことがあります。遠慮を知らない新人の方が問題を鋭く指摘したり、中堅メンバーが後になって「おかしいと思っていました」などと発言するのは、横同士のコミュニケーションがうまくいっていないからでしょう。

3.3 ドキュメント

　さらに、ドキュメントや設計が冗長になりがちです。経験の少ないメンバーにもわかるような言葉の定義は必須ですし、定義フィルを見るか変換をすれば十分な情報に関しても、後から参加するメンバーに説明するためにだけに書かれることもあるでしょう。場合よってはプログラムを書いた方が早いだろうというほど詳細なドキュメントが書かれることもあるでしょう。もちろん、ドキュメント化によってレビューが容易になるという良さはあるのですが、修正が入った際に変更しなければいけないドキュメントが増えてしまい、保守されないドキュメントを増やす一因になります。

　また、詳細化を考慮したきれいな設計を心がけるので、冗長な設計になることもあるでしょう。後から機能を増やすと契約上も問題になるので、詳細設計で十分に検討すれば不要かもしれないと思いつつも、ひとまず入れておいて詳細は下流工程で決定するということは、段階的詳細化に起因して発生しうる話です。

４．アジャイルの隠された利点

　これまで見てきた従来法の問題は、従来法の枠組みを超えてアジャイル開発の要素を加えることで解決できます。具体的には以下の点です。

4.1 繰り返しによるプロジェクト内の改善

アジャイル開発の特徴である繰り返し開発では、イテレーションという単位で開発が繰り返されます。1つのプロジェクトの中に複数のミニプロジェクトが含まれていることになり、イテレーションごとに振り返りを行うことで、プロセスが改善します。

この改善はプロジェクト固有の改善です。前のイテレーションで計測したメトリクスがあったとしても、それを参考にするだけで、以降のイテレーションの標準となる数値を定めることは少ないでしょう(大規模組織においての基準策定は、プロジェクトとは別の活動としてあり得ます)。

反面、プロジェクト内の改善活動として、メトリクスの相対的な利用が可能です。たとえば複雑度の高い部分や不具合の多い部分に対して、レビューやテストを強化することで、より信頼性を高めることができるでしょう。

4.2 実装優先＋優先順位によるリスク低減

　古くからプロトタイプにはいくつかの危険があると言われていました。それは、特定の機能の実現可能性や性能の確認を目的としたプロトタイプであったはずが、すでに完成したかのように錯覚してしまうからです。もちろん開発者はわかっていたはずなのですが、まず管理者が錯覚し、それに引きずられるように開発者までもが安易な計画を立ててしまうと言われていました。上述のようにプロトタイプによる検証をしたはずが、後工程になって問題が発覚することにも、このような錯覚が影響しているでしょう。

アジャイルにおいては、常に本物の実装です。このような錯覚や、後工程での問題発覚の可能性も減らせます。ただし、それにはふさわしい優先順位の決定が必要です。リスクの基本式である「発生確率×影響」は、

「発生確率×影響(t)」

となっていて、影響は時刻tによって変化するものです(より正確に言うと実装の順番によって変化する) 。より影響が小さくなるように実装の順番、すなわち、イテレーションを構成するならば、プロジェクト全体のリスクを低減することが可能です。

4.3 同一体制での開発＋見える化による情報共有

アジャイル開発においても、突発的なメンバーの増減はあり得るでしょう。しかし、YAGNIの原則がありますので、プロジェクトの途中での増員を前提としてドキュメントや設計を行うことはあまりないでしょう。

同じメンバーが継続して作業することは、教育やコミュニケーションに有効です。もちろんそれまでの経験によって、環境や業務の知識は異なります。しかし、同時期に参加することによって、その関係を上下でなく、「仲間」にします。上下関係のある学習では、教える側が考慮しない限り、教えられる側はプロジェクト全体を考えるようはなかなかできません。しかし、仲間であれば、お互いに助け合い、ふと疑問に思うことも情報交換するようになるでしょう。

また、「タスクボード」や「かんばん」と呼ばれる仕組みもプロジェクト全体に目を向けさせます。これらはプロジェクト全体の作業状況を示しますので、自分の作業だけでなくプロジェクト全体に目を向けるようになり、コミュニケーションのベースとなります。

ここに挙げたアジャイルの要素を従来開発に加えた開発をアジャイルと呼ぶべきか、呼ばないべきかは意見の分かれるところかもしれません。個人的にはどちらでもよいと思っています。プロジェクトの目標は、問題なくシステムが開発されることであり、それがなんと呼ばれようと関係ありません。

５．チケット駆動開発のソリューション

チケット駆動開発は、(1)BTSのチケットでタスクを管理する、(2)チケットのにコミットは許さない、(3)ツールと連携する、といった中心となるルールだけではアジャイル開発といえません。しかし、上述した従来法の問題を解決するには効果的です。

5.1 繰り返し＋データ蓄積

チケット駆動開発で利用するBTSには、「マイルストーン」あるいは「バージョン」という作業の期限を示す機能があり、各イテレーションの期限として設定・参照できます。また、チケット一覧の抽出条件としても利用できます。プロジェクトの全貌を示し、今注目すべきチケットを示すことで、繰り返し開発を支援します。

また、チケットはプロジェクトのデータの宝庫です。チケットに示されたタスクの内容だけでなく、実施に当たっての議論も蓄積されますので、イテレーションごとにプロジェクトを振り返る際の情報として活用できます。

5.2 チケットの優先順位

リスクを考慮した実装順序をチケットの実施時期や優先順位として示すことができます。時系列に示されるガントチャートで参照可能なほか、優先順位をチケット一覧のソートキーとして用いることで、計画や作業の優先順位を容易に確認できます。

5.3 コミュニケーション＋履歴

チケットはタスクボードであり、かんばんです。チケットの一覧やガントチャートによってプロジェクトの全貌を知り、コミュニケーションをとることができます。また、ソースの更新はチケットと関連付けられ、チケットに関する議論は、コメントとして履歴が残りますので、過去の作業に対しての情報共有もはかれます。

チケットの更新は、メールやRSS、eclipseのプラグインで知ることができます。日々の作用としてBTSで検索するまでもなく、瞬時にプロジェクトの状況を共有することができます。

5.4 チケット駆動開発に含まれないもの

チケット駆動開発の基本には、アジャイル開発にあった実装優先や同一体制は入っていません。しかし、従来法の問題を解決するならば、これらを取り入れた開発をする必要があります。

６．まとめ

従来法による開発で問題が生じるようなプロジェクトが、年々増えています。これはWFに問題があるのでありません。過去には大勢を占めていたプロジェクトを実践する目的で、WFをベースに発展させたものが従来法であり、近年のプロジェクトに対応できていないからです。

プロジェクトによっては従来法がふさわしい場合もあるでしょうし、ふさわしくない場合もあるでしょう。開発プロセスはプロジェクトに合わせて決めなければなりません。それには、プロジェクトの課題を知り、その解決法を考えなければなりません。

ここでの議論は、従来法かアジャイルの「どちらか」ではなく、従来法とアジャイルを参考に近年増えてきたプロジェクトを「どのように」実践するかという議論です。ソフトウェア開発に銀の弾丸はないと言われますが、それはアジャイル開発においても同じです。ソフトウェアをうまく開発する唯一の方法は「考える」ことです。ここに書いた内容が、みなさんの「考える」ことに少しでも役立てていただければ幸いです。