無料ブログはココログ

« 2011年4月 | トップページ | 2011年7月 »

[#TiDD] ソフトウェア開発と時間 - 小特集「時間とコンピュータ」 -

情報処理学会の雑誌「情報処理」2011年6月号にエッセイを書きました。6月10日が時の記念日ということで、小特集「時間とコンピュータ」が組まれて昔の研究ネタ関係のことを頼まれました。とはいえ、その分野は詳しくないので「ソフトウェア開発と時間」というタイトルで、アジャイルやチケット駆動開発のことを書きました。著作権は譲渡していますが、本人及び会社での公開は許されていますので、ここで公開します。

ソフトウェア開発と時間

ソフトウェア開発は時間との闘いである.最大の敵はリリースの時である納期である.古くから,ソフトウェア開発においてQCD(品質,コスト,納期)は,重要であると言われていた.近年は,ソフトウェアがビジネスと強く結びつくようになり,より納期が重視されるようになっているほか,リリース時に最新の状況に合わせたソフトウェアであることが求められている.本稿では,このような中で再び注目され本格的な導入が進みつつあるアジャイル開発と,BTS(障害管理ツール)によるタスクマネジメント技術であるチケット駆動開発に触れながら,ソフトウェア開発の現場でどのように「時間」が重視されているかを述べる.

ソフトウェア開発には時間によって変動する以下の要素がある.

・ソフトウェアによって得られる価値
・ソフトウェアに必要とされる機能
・実行環境

従来,ソフトウェアは既存の業務を置き換えるものが多く,納期はそれほど厳しいものではなかった.リリースが遅れることよりも,必要な機能が不足していることや,ソフトウェアの欠陥(いわゆるバグ)によって正常に動作しないことが問題視されていたからである.また,リリース後に従来の処理と並行で運用される期間がとられることが多く,若干の遅れは許容されることもあった.

近年のビジネスはソフトウェアによって実現されており,ソフトウェア開発の遅れが,ビジネスチャンスを失わせることになる.同業他社にマーケットを奪われてからソフトウェアが動作しても価値がなくなってしまうのである.そこで,ソフトウェアによって得られる価値を守る目的で,機能の取捨選択,いわゆるスコープの変更が行われる[1].

このような開発対象となる機能の取捨選択,すなわちスコープの変更は開発開始時に一度だけ行われていた.しかし,近年は以下のような理由から,スコープの変更が必要になる場合が多くなっている.

・競合他社や社会の変化など,ビジネス環境の変化
・UX(ユーザエクスペリエンス)の向上

ソフトウェア開発の早い時点ですべてを決めてしまうと,ユーザの要望を満たすことができず,ソフトウェアの価値を下げてしまうのである.そこで,できるだけ短期間で[2],複数回リリースしてその都度スコープを変更する必要がある.

一方,ソフトウェアの実行環境も時間と共に変化する.使い込まれたソフトウェアは信頼性が高いというメリットがある.しかし,新しいソフトウェアほど一般に多機能であり,同じソフトウェアでも新しいバージョンであるほどセキュリティホールがふさがれている,サポート期間が長い,というメリットがある.このように,ソフトウェアはなるべく新しいものが好ましいが,実績の少ないソフトウェアの場合は,信頼性を確保する必要がある.そこでソフトウェアの実行環境などは,できるだけ決定を遅らせた方が良いが,信頼性を確保する期間が残せるような時(最終責任時点とよばれる[2])を守る必要がある.

このようにソフトウェア開発と時間を考えると,ソフトウェア開発の計画は容易ではないことがわかっていただけるだろう.ソフトウェアを開発するには,上述の時間による変動要素だけでなく,

・開発の順序性
・開発者の習熟

をさらに考慮する必要がある.ソフトウェアをどのように実装して結合していくか,テストの戦略を含めて計画を立てる必要がある.また,近年の技術は変化が激しいので,経験者であっても,ある程度の技術習得期間が必要になることが多く,どのように技術者を習熟させるかということも考慮する必要がある.

ここまで述べたように時間と関係するこれらの条件をを踏まえた上でソフトウェアを開発しなければならない.しかし,近年のソフトウェア開発では,時間による変動要素の影響によって,従来の段階的に詳細化して最後に一度だけ リリースするという,いわゆるウォーターフォール型の開発は困難になってきている(もちろん,その度合いは開発するソフトウェア によって大きく異なる).

そこで,スコープを変更しながら段階的に開発するという「アジャイル開発」が注目されている.アジャイル開発は,あらかじめすべてを決めておくのではなく,段階的にリリースし,どこまで実現するかを順次決定することで,変化に対応するからである.

ソフトウェア開発とビジネスの関係で考えると,アジャイル開発では部分的ではあるものの,常にソフトウェアが実現されているので,ビジネスチャンスを失うことなく,スコープの調整によって最適な時期にソフトウェアをリリースすることができる.従来は最終リリースまではビジネス上の価値を得ることはできなかったが,アジャイル開発では価値の得られない期間を短くし,メリットが得られる期間を延ばすことができるのである.

技術的に見ても,一度にすべてを作って失敗するのではなく,早めに小さく失敗することで,失敗を取り戻し易くすることができる.小さく始めて,後になるほど完成度を高めていくことができるのである.

アジャイル開発は少人数での開発が基本であり,コミュニケーションが向上し,効率的な開発が可能である.近年は,その効果が認識されるようになり,より大規模な開発にも適用されるようになっている[3].

さらに近年は,従来開発やアジャイル開発法を効率化するものとして、障害管理ツールをタスク管理に用いる「チケット駆動開発」が注目されている.

チケット駆動開発は,従来法の開発の中で生まれた.近年の小規模かつ多機能なソフトウェア開発では,細かな作業が多くあり,その効率化の目的で障害管理ツールのチケット(障害票)をタスクマネジメントに用いたのである[4].

チケット駆動開発には,以下のような特徴がある.

・構成管理ツールと連携してトレーサビリティを確保する
・リアルタイムに見える化してコミュニケーションを向上する
・作業のワークフローを管理する

さらに,チケット駆動開発では,チケットの一覧から優先順位の高いものを選ぶことで,スコープを変更することが可能である.そこで,従来法による開発の柔軟性を高める目的に用いられるほか,アジャイル開発においても,タスク管理をディジタル化して効率化する目的にも用いられている.

このようにチケット駆動開発は,従来開発やアジャイル開発法をさらに効率化し,リアルタイム性を高める技法として,注目されているのである[5].

本稿で述べたように,時間を重視したソフトウェア開発には様々な開発法が必要である.

ビジネスの多様化に伴い,すでにソフトウェアは欠かせないものであり,その重要性は高まっている.ソフトウェアに対する多様な要望に応えるべく,1990年代後半から開発技術や開発環境は急速に発展し,少人数でも多機能なソフトウェア開発が可能になってきた[6].その反面,様々な変化への対応が必要になり,時間を重視したソフトウェア開発が求められている.

多様なソフトウェアが求められている様に,その開発方法にも従来の開発法だけでなく,アジャイル開発やチケット駆動開発といった,様々な開発法が必要とされているのである.

1) Alan M. Davis: Just enough requirements management, Dorset House(2005).
2) Mary. Poppendieck, Tom. Poppendieck: Lean software development, Addison-esl
ey(2003).
3) Dean Leffingwell: Scalling software agility: Best practices for large enter
prises, Pearson education(2007).
4) まちゅ: チケット駆動開発 … ITpro Challenge のライトニングトーク (4), まちゅダイアリー, http://www.machu.jp/diary/20070907.html#p01(2007).
5) 小川, 阪井: Redmineによるタスクマネジメント実践技法, 翔泳社(2010).
6) Makoto Sakai, Ken-ichi Matsumoto, Koji Torii: A new framework for improving
software development process on small computer systems, International Journal
of Software Engineering and Knowledge Engineering, vol.7, no.2, pp.171-184(19
97).


[#TiDD] プロセスアスペクトでプロセス改善

プロセス改善という言葉が普通に使われていますが、そのポイントはどこにあるのでしょうか?私はプロジェクトの実践ノウハウにプロセス改善の本質が隠れていると思います。それをプロセスプログラミングに当てはめるなら、クラスである標準プロセスではなく標準プロセスで記述しきれないクロスカッティングコンサーン(横断的関心事)であるプロセスのアスペクト(ノウハウ)の蓄積がプロセス改善のポイントだと思うのです。

開発標準に感じる違和感

CMM以降、プロセス改善というと標準プロセスの規律(開発標準)を中心に語られることが多くなりました。標準プロセスの規律とは以下のような考え方に基づくものです。

  • 良いプロダクトは良いプロセスから生まれる
  • 良いプロセスのメトリクス(測定値)は一定の範囲に収まる
  • 基準を満たさないプロジェクトには対策を実施する

このような考えから、標準プロセスではそこで実施すべき作業と共に、合格ラインが定められてその条件を満たすように開発することが求められてきました。これはハンフリー氏が言われるような、訓練によって安定した開発ができるような組織を構築すること、を目指していました。

標準プロセスが実現するのは、作業の漏れの防止と組織の未成熟です。ソフトウェア開発では納期のプレッシャーが強く、品質確保のための作業(たとえばコードレビューなど)を端折ってしまうことを考えてしまいがちです。しかし、そのような作業のショートカットは目先の課題に目をつむって未来のリスクを増大するだけです。

標準プロセスを定めてそのメトリクスの基準を決めることで、端折ることなく作業が実施され、しかもそれが想定された程度の作業であることが確認できます。レビュアーが未熟であったり、チェックリストが整備されていない場合には、メトリクスは合格ラインに達しません。そこで、再レビューの実施などの対策が行われて、プロダクトを一定の品質に保つと共に、求める品質が保たれる組織に成熟するように訓練されるのです。

この方法は、類似のソフトウェアを開発する組織には、とても有効でした。すべてのプロジェクトに品質保証作業が手抜きされることなく、一定の品質で実施されるのですから、組織の底上げが実現できました。また、新しい技術を組織的に導入することも可能で、組織を成熟させることができます。

CMMのブーム以降、多くのプロセス改善の集まりができました。最初は勉強のための情報収集が目的だった企業も、成果を発表することで先人のコメントを得るようになりました。具体的な成果が発表される中で気づいたのは、議論の中心が開発標準ではなかったことです。

そもそも良いプロセスというものが定義できるなら、標準プロセスで定めるべき開発標準の話になったはずです。しかし、標準プロセスをどう広めるか、とか、さらに品質を良くするにはどのように取り組めばよいか、といった人にまつわる話や品質にまつわる技術的な話が議論の中心を占めていました。

インスタンスの個別性

このような違和感は、ソフトウェアプロセスとコンピュータ言語の違いからくるものです。コンピュータ言語であれば、クラスをインスタンス化する際のパラメータは限定的であり、インスタンスごとの違いも限定的です。しかし、実際にプロセスのパラメータともいうべき、対象業務の差、構成メンバーの個人差、集団になった際の特徴の差、は大きなものだからです。

インスタンスの個別性を生むものの最も大きなものは対象業務の差でしょう。それ以外にも、個人の特性のほか、その関係であるコミュニケーション、技術力、そして結果としてのモチベーションです。これらはプロセスのコミュニティでたくさん議論されています。

プロセスをある程度の品質に保つには開発標準は有効でした。しかし、さらにプロセスを改善するには、標準プロセスに表しにくい内容を充実させる必要があります。標準プロセスの開発標準は、プロセスが一定の範囲からはみ出さないようにコントロールするものでした。しかし、その範囲の中でそのように実践するか、より良いプロセスへの方向付けが必要だったのです。

クロスカッティングコンサーン

より良いプロセスへの方向付けは、関心事(コンサーン)ごとに議論されています。プロジェクトファシリテーションやテスト技術などがそれにあたります。

プロジェクトファシリテーション(PF)とはチーム作りhttp://www.objectclub.jp/community/pf/のことです。プロジェクト内のコミュニケーションやモチベーションと言っても良いかもしれません。PFは特定の方法論のものではなく、あらゆるプロジェクトにおいて応用が可能です。

テスト技術というと下流工程だけの議論のようにも聞こえます。しかし、より良いテストを実施して品質の高いソフトウェアを開発するには、プロジェクトの開始時から品質向上に向けての取り組みをしなければなりません。対応する上流工程でテスト設計をするWモデルではもちろんのこと、そうでなくてもプロジェクト計画時にきちんとテストのことを計画しておかないと、品質の向上はできません。

すでに、PFとテスト技術、それぞれにコミュニティがあります。PFがプロジェクト全体を対象とするほか、テスト技術の議論においても、テストの方法論を議論しているように見えて、仕様をどのように分析するかという議論が行われていることもあります。

プロジェクトの成功は、プロジェクトのイメージが描けるかどうかにかかっていると言われています(アジャイル・チャリティイベントの前川さんの発言)。従来の方法では、標準プロセス(クラス)から実際のプロジェクトの計画(インスタンス)を作成する際にテーラリングといわれる開発標準の手直し作業が行われ、その際にイメージできるかが重要でした。

しかし、プロジェクトは生き物であり、メンバーの状況や外部環境の変化によって、様々な対応が必要になります。作業の入れ替えや計画の見直し、など動的に計画を変更する必要が出てくるでしょう。その際にもやはり全体のイメージをきちんと描けるかどうかがプロジェクトの命運を握ります。

このプロジェクトのイメージをきちんと描くということは、プロジェクトの主要な関心事の観点で、すべての工程、すべてのメンバーについて、イメージが描けるということです。

残念ながら主要な関心事で考えられる作業をすべて実施することは困難です。プロジェクトのリソースには限界があるからです。そこで、どこにどの程度注力するかを決める必要がありますが、うまくいくかどうかは関心事の知識に依存します。多くの対処法の知識や経験によって勝敗が決まるのです。

そのような標準プロセスとすることが困難な、従来はノウハウと呼ばれたものを、私はプロセスアスペクトと呼んでいます。工程や作業をまたがる横断的な関心事(クロスカッティングコンサーン)だからです。

チケット駆動開発は複合的なプロセスアスペクト

ここでチケット駆動開発を見てみると、多くのクロスカッティングコンサーンを内包することに気づきます。

チケット駆動開発は

  • タスクをBTSのチケットで管理する
  • チケットのないコミットを許さない(No Ticket, No Commit!)

という2つのルールによって、プロジェクトをチケット中心に回します。そして構成管理ツールと障害管理ツールが連携することで、チケットを通して作業の結果である成果物の状況を、様々な視点によって確認することができるようになります。

その結果、プロジェクトを通して実現すべき関心事が支援されます。

  • タスクマネジメント(計画の動的な変更と進捗管理)
  • 見える化(プロジェクト内の情報共有と問題の明確化)
  • ツールによる自動化
  • 外乱の除去(作業への集中とリズム)

プロセスアスペクトを中心としたプロセス改善

CMMブーム以降、プロセス改善はプロセスのクラスである標準プロセスの整備を中心に進められてきました。その結果、多くの企業で開発標準が整備され、その実践ノウハウがコミュニティで共有されました。そのノウハウは技術的な内容のほか、コミュニケーションやモチベーションなど、工程や作業を横断した様々な関心事です。

このようなプロセスアスペクトに注目して議論をし、ノウハウを蓄積すれば、プロセスの動的な変更を容易にし、柔軟かつ堅牢なプロジェクト運営を可能にします。すでにプロジェクトファシリテーションやテスト技術はコミュニティができており、実績を上げています。今後はチケット駆動開発に関しても多くの議論を通じてノウハウを蓄積していけば、たくさんの実績をあげることができると思っています。

« 2011年4月 | トップページ | 2011年7月 »