SHOEISHA iD

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

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

“アジャイル”の次へ:IBMの開発プロセス戦略の今(AD)

第1回 RUPはどこに消えたのか?

“アジャイル”の次へ:IBMの開発プロセス戦略の今(1)

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

 “開発プロセス”と聞いて、何を思い浮かべますか? 分厚い文書の塊? 神聖にして不可侵な聖典? あるいは、アンチテーゼとしてのアジャイル“革命”か……。ビジネスへの貢献を今まで以上に求められている開発組織にとっては、今や“静的なプロセス定義”だけでは意味がない、とIBM Rationalチームは考えます。開発プロセスを“実現可能なモノ”にするIBM Rationalのプロセス戦略を、本連載ではご紹介します。

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

RUPはどこに消えたのか?

 ……なんて始まり方は少々扇情的に過ぎるでしょうか?

 震災以降、いまだにおさまらない円高等々さまざまな要因があいまって、コスト削減という言葉に「抜本的」「聖域なき」という枕詞が付くようになりました。

 もちろんソフトウェアの開発に携わる組織も、無関係ではいられません。「やり方を根本的に変えてでも」という言葉にも、今までにない真剣味がくみ取れるようになった昨今、昔からRationalの名前を知っている方から、「そういえばRUPはどうなったの?」と訊かれることが少なくありません。

 開発技法の多様化やITの重要性がどんどん増している現実を受けて、RUPそれ自身も、そしてRationalのプロセスを核としたソリューションも大きく変貌しています。

 ベンダーの記事は、どんなに繕っても所詮提灯記事の域を越えることはないわけで、この連載もその例外ではありません。しかし、ソフトウェア開発改善の現場に長く関与してきたRationalチームが、どういう問題意識を持ち、それをどのように解決しようとしているかを提示しておくことは、これから「自分達のやり方を見直す」ことを求められる方々に何らかの参考になるのではないか?…そういう想いのもとに、書くことにします。

そもそもRUPとは?

 RUP(ラップと発音します)の名前を耳にしたことがあっても、それがどういうモノかご存じない読者も今となっては多かろう…ということで、簡単にポイントをご紹介しておきます。

3つのアプローチと6つのベストプラクティス

 RUPは、短期間のウォーターフォールを繰り返しながら、製品の機能を段階的に高めていく、いわゆる反復型プロセスに分類されます(図1)。開発単位として、反復のたびに1つ以上のユースケース(あるいはそのインスタンスであるシナリオ)を実装していきます(ユースケース駆動のアプローチ)。プロジェクトの早い段階では、技術的なリスクの高いユースケースを優先して実装します(リスク駆動のアプローチ)。これにより、早い段階でアーキテクチャを確立することを狙っています(アーキテクチャ中心のアプローチ)。ウォーターフォール型開発では、開発期間後期のシステム統合段階でトラブルが頻発することが多く(って、いまでも多いですよね?)、それへの解決策としてこのリスク駆動&アーキテクチャ中心のアプローチがあります。

図1 Rational Unified Process
図1 Rational Unified Process

 これらのアプローチを現実にどうやって実行していくか? そのために、次の6つのベストプラクティスを提唱していました。

  • 反復的に開発すべし
  • 要求を管理すべし
  • ビジュアルモデリング
  • コンポーネント・アーキテクチャ
  • 変更を管理すべし
  • 品質の継続的な検証

 RUP登場以前にも多くのメソドロジーやプラクティスが提唱されていました。その多くがオブジェクト指向の観点からシステムをどう捉えるかを説明したものだったといってもよいでしょう(ちょっと乱暴ですかね)。しかし、実際にそれをプロジェクトに適用する段になると、どれをどう組み合わせ、どのタイミングで何をするべきかを考えることに頭を悩ましているような状態でした。まして、ある程度の規模のプロジェクトで開発者が増えてくると、なんらかの進め方の規範なしには、進まなくなってしまいます。

 そこで、RUPの登場です。RUPが評価された1つのポイントは、それが何かの大発見や大発明ではなく、プロジェクトに適用するにはどうするか?という利用者視点で、乱立するメソドロジーを、整理・統合・体系化し、さらに作業ステップまでブレークダウンしたことにあります。それによって、「始めたい」と思った開発者に「どう進めていくか」を提示することができた、という点が重要です。

関連リンク

次のページ
変わり続けるRUP

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

  • X ポスト
  • このエントリーをはてなブックマークに追加
“アジャイル”の次へ:IBMの開発プロセス戦略の今連載記事一覧

もっと読む

この記事の著者

藤井 智弘(フジイ トモヒロ)

日本アイビーエム株式会社 ソフトウェア開発研究所 Rationalエマージング・ビジネス・サービス。ソフト開発ってホントはもっとおもしろかったはず!という思いのもとで、”管理管理!”でも”開発者の自由!”でもなく、その程よいバランスこそが解と、啓蒙活動...

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

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

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

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/6423 2013/04/10 15:38

おすすめ

アクセスランキング

アクセスランキング

イベント

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

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

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

メールバックナンバー

アクセスランキング

アクセスランキング