[#TiDD] チケット駆動開発の開始タイミング - 良いプロダクトはふさわしいプロセスが生む -
かつてCMMがブームの頃「良いプロダクトは良いプロセスが生む」といわれていました。いわゆるステージドモデルの高いレベルが良いとされていましたが、その後、SPICEのマトリックスモデルを取り入れて、組織にあったプロセス改善がより容易にできるようになりました。このことからも分かるように、プロセスは開発組織のものであり、開発対象、開発メンバー、文化等によってふさわしい「良いプロセス」は異なり、「ふさわしいプロセス」と考えた方が良いと思います。
CMMの憂鬱
CMM/CMMIはそれまでのソフトウェア工学を体系化して、体系化した人たちの基準で良いプロセスを実現することをまとめたものです。その基準はDoD(米国国防総省)によって設立されたSEIの視点です。つまり、信頼性の求められる大規模開発で、どのような開発が行われたかが確認できることです。そして、CMMの本として知られる「ソフトウェアプロセス成熟度の改善」の序文には“「ソフトウェア危機」は死んだ”とまで書かれています。
この言葉はある意味正しく、ある意味で不正確です。この本の書かれた当時(英語版が89年、日本語版が91年)は、「ソフトウェア危機」(リンク先はWikipedia)は「人月の神話」に示された大規模開発システムの対策が中心だったからです。
しかし、リンク先のWikipediaを見てもらえれば分かるように、「ソフトウェア危機」中小規模開発においても生じうる問題です。すべてのプラクティスの実施にこだわらなければ、小規模プロジェクトでも有効です。亡くなられた坂本さんは、CMMのレベル到達でなく、現場の問題を解決するプラクティスをCMMから探し出して、プロセスを改善されていました。また、この改善の仕方を当時のCMMのアセッサに確認されたところ、それはCMMによる改善法として正しいとのコメントを得られたそうです。
つまり、プロセス改善とは「プロセスの問題を改善すること」で、CMMでもそれを否定していなかった。しかし、ステージドモデルが分かりやすく、レベルの達成がプロセス改善と多くの人が誤解した。あるいは、レベル達成を営業的に利用したことで、話しがややこしくなったのだと思います。
ハードなプロセス、ソフトなプロセス
ソフトウェア開発の歴史を振り返ると、ソフトウェアはハードウェアの開発にあこがれていたと思います。各社が「ソフトウェア工場」を作り、ソフトウェア開発の工業化を目指していました。
工業化における品質とは主に信頼性です。計画された仕様が満たされたかどうか、設計どおりに実現されているか、それが求められます。当初定められた計画通りにできることを重視する、それをここではハードなプロセスと呼びます。
しかし、近年のソフトウェアに求められるものは、そのようなハードなプロセスでは実現が難しい柔軟な対応です。作ってみないとわからない仕様や、日々変化する実行環境とビジネスに対応できるソフトウェアです。
アジャイルソフトウェア開発は、そのような変化に対応できる開発法です。ここでは、ソフトなプロセスと呼んでみましょう。XP(eXtream Programming)の最初の本である「XPエクストリーム・プログラミング入門」のタイトルには「ソフトウェア開発の究極の手法」とされています。あたかも、このソフトなプロセスによれば、すべてのソフトウェア開発がうまくいくようにも読めます。
しかし、ソフトなプロセスはそんなに簡単ではありません。「アジャイルと規律」の5つの重要要因にあるように、人、文化、対象による判断が必要ですし、「リーンソフトウェア開発」の決定をできるだけ遅らせるというプラクティスで分かるように、イテレーションをどのように構成するか、単純な優先順位だけではうまくいかないのです。
ふさわしいプロセス
様々な要因を考慮するなら、純粋主義者の解釈のような二元論にはなりません。CMM/CMMIをベースにすることも、アジャイルのプラクティスを徐々に導入することもあるでしょう。いずれにしろ、すべての要素を考えてプロジェクトにふさわしいプロセスを実現しないといけないのです。
チケット駆動開発は、このいずれにも有効です。細かなタスクの管理、見える化やコミュニケーションの支援、をするとともにアジリティを高めるからです。詳しくは「Redmineによるタスクマネジメント実践技法」に書いていますが、その元になった記事と補足を紹介しておきます。
チケット駆動開発を開始するタイミング
プロセスの変更は危険なものです。安易にプロセスを変更すると、予期しない問題が生じる場合が多く、注意深く変更すべきです。本来なら余裕のあるプロジェクトで、試行してから実施すべきです。上の「元気が出るチケット駆動開発」の元となったプロジェクトでも、当初はチケット駆動開発を導入しない予定でした。しかし、細かな問題が発生し、このままではうまく行かない状況になって導入を決意しました。BTSの利用にはすでに慣れていましたので、副作用もあまりなくメリットの方が大きいと判断しました。
このように「確信をもてたとき」が導入するタイミングだと思います。ソフトウェア開発は個人のものではありません。顧客、開発会社、開発者のすべてがWin-Win-Winになる事が目標です。正しく理解し、ルールを守り、慎重に、そして的確に導入してください。
#こんなごく小さな事さえできないのに、
#なぜ、ほかの事まで思い悩むのか。
#(日本聖書協会新共同訳 ルカ12・26)
« [#TiDD] 出版裏話5:「Redmineによるタスクマネジメント実践技法」 詳細目次 | トップページ | [#TiDD] ソフトウェアプロセスも複雑なソフトウェアである »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
この記事へのコメントは終了しました。
« [#TiDD] 出版裏話5:「Redmineによるタスクマネジメント実践技法」 詳細目次 | トップページ | [#TiDD] ソフトウェアプロセスも複雑なソフトウェアである »
コメント