SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

グラス片手にアジャイル開発

グラス片手にアジャイル開発 第3回
- アジャイル開発における計画と運営サイクル

  • X ポスト
  • このエントリーをはてなブックマークに追加

 ソフトウェア開発において、重要かつ難しい作業の1つが「計画」です。アジャイル開発では、継続的に計画を立てていくことが肝要です。本稿では、アジャイル開発における計画と運営サイクルに焦点を当てて解説します。

  • X ポスト
  • このエントリーをはてなブックマークに追加

アジャイル開発における計画と運営サイクル

 ソフトウェア開発において、重要かつ難しい作業の1つが「計画」です。アジャイル開発では、計画を立てずに実装を始めるイメージがあるかもしれませんが、実際には計画を立ててから実装します。ただし、“すべてを事前に予測はできない”という前提で、継続的に計画を立てていくことが肝要です。本稿では、アジャイル開発における計画と運営サイクルに焦点を当てて解説します。

アジャイルにおけるプランニング

 アジャイル開発を導入すると、一般的にプロジェクトの初期品質は良くなりますし、要求の充足率も高くなります。何より開発者のモチベーションの向上にもつながります。しかし、プロジェクトを上手く運営できないときもあります。

 プロジェクトが上手くいっている場合もそうでない場合も、開発者は各関係者に計画と進捗を説明する責任があります。実際のプロジェクトには、開発のみでなく計画/構想のフェーズ、UIデザインの外注、翻訳、性能テスト、環境テスト、トレーニングなど多くのタスクがあり、上司や顧客をはじめ、これらのタスクに携わる多くのステークホルダー(※注1)がいます。

※注1

 直接/間接を問わず、利害関係を有する人たちのこと。

 アジャイル開発でも適切に進捗状況を把握し、プロジェクト周辺のタスクを考慮に入れながら各ステークホルダーに説明することが重要になります。

ウォーターフォール的な部分

 アジャイル開発では、設計と実装とテストは同時に進行します。しかし、常にすべてのタスクが同じペースで進むわけではありません。システム全体のコンセプトや採用する技術の方向性が決まらないうちに、開発をはじめるわけではないですし、すべての画面が完成する前に全体的なユーザビリティ検証はできないかもしれません。

 また、セキュリティなどの共通機能は、実装後半になって横断的に各機能に影響を及ぼすかもしれません。テストには、機能をテストする以外にも稼動環境テスト、性能テストなどがあります。もちろんすべて自動化できればそれに越したことはありませんが、手動の部分が多く残ります。

 プロジェクトのスタートから製品リリースまでを考えると、アジャイル開発でもウォーターフォール的(一方向的)な部分がありそうです。

スコープ(機能)の柔軟化

 ソフトウェア開発において、すべてが計画どおりに進むことはまずありません(威張って言えることではありませんが……)。そのようなときに“リスケ”(リスケジューリング)を行ないます。

 アジャイル開発において、リスケはどのように行なわれるのでしょうか。そもそも、アジャイル開発ではウォーターフォールほど厳密に事前に見積もりませんし、リスケとまではいきませんが計画を変更することもあります(むしろ、計画は頻繁に変更します)。

 アジャイル開発においてウォーターフォールと最も大きく異なる点は、何を固定するかにあります。図1に示すように一般的に計画の3大要素には、次の3つが挙げられます(時に、これらに「品質」を加えて4大要素とすることがあります)。

  • スケジュール
  • スコープ(機能)
  • リソース(人/金)
図1:計画の変動要素
図1:計画の変動要素

 アジャイル開発ではスケジュールとリソースは固定し(品質も固定)、スコープを変動要素とします。ここにアジャイル開発の計画における最も大きな特徴があります。これについてはアジャイル開発の流れにおけるいくつかの重要な原則とも深く結びついています。

まめ知識「ウォーターフォールの元祖」

 開発の“一方通行”は、ウォーターフォール方式の最も大きな特徴であり、アジャイル開発にとって大きな弊害と言われています。

 実は、その原典とされるWinston W. Royceの論文“Managing the Development of Large Software Systems”(1970)ではイテラティブ(反復的)に開発することの重要性が述べられています。しかしながら、その部分は時を経て抜け落ちてしまいました。

 その後、彼の息子であるWalker Royceらを中心に、「RUP」(Rational Unified Process)が提唱され、父の思いは息子によってようやく具現化されました。

 RUP自体は大規模なプロジェクトに対して適用され、直系の“アジャイル”手法ではありませんが、多くの部分で共通します。Open UPや、Agile Unified Process といった発展形もあり、XPやスクラムとともに参考となる開発プロセスの1つです。

次のページ
XPとスクラム、RUPにおける計画

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
グラス片手にアジャイル開発連載記事一覧

もっと読む

この記事の著者

株式会社ディーバ 小林 達(コバヤシ サトシ)

2004年に株式会社ディーバ入社。連結会計システム「DivaSystem」の大規模プロジェクトに参加した後、ビジネスインテリジェンス分野を中心とした複数の製品/受託開発プロジェクトを技術面で主導。オフショア開発でのアジャイル開発経験などを経て、現在はディーバアメリカを含む多国籍メンバーと共に、次世代...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/5465 2010/10/18 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング