[#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] プロセスアスペクトでプロセス改善 | トップページ | スクラムを味方につけろ! - SEA関西プロセス分科会 - »
「私のアジャイル」カテゴリの記事
- 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] プロセスアスペクトでプロセス改善 | トップページ | スクラムを味方につけろ! - SEA関西プロセス分科会 - »
コメント