SHOEISHA iD

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

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

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

第4回 「定義」から「運営」へ:短期化する改善サイクルそのものと標準化の姿

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

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

 開発プロセスを“実現可能なモノ”にするIBM Rationalのプロセス戦略を紹介している本連載。今回は、Rationalチームが提供している3つのアプローチを軸に、開発プロセスをどのように運営していくべきかを解説します。

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

前回からちょっと時間が…

 …空いてしまいましたが、この連載でも取り上げているIBM Rational Team Concert(以降RTC)とIBM Rational Method Composer(以降RMC)が、共に6月にバージョンアップし、ツール間の連携度合いが高まりました。実はこれを紹介したかったから、わざと間を空けていたのであって、決して目先の仕事に嵌まって原稿提出が遅れたわけではなく……(編集担当:「バシッ」)。

 今回は、「開発プロセスを運営する」という観点でのお話しです。この話がしたかったから、わざわざ間を空けて……(編集担当:「ドスッ」)。

「開発プロセスを運営する」ということ

 開発プロセスといえば標準化、これまで……いやいや、今でも、次のような進め方を目にするのではないでしょうか?

  • 半年かそれ以上かけて開発現場の問題点を洗い出す
  • 同時にCMMIやCOBIT、PMBOK、SWBOKと必要とおぼしき知識の習得に励む
  • さらに半年かそれ以上かけて、標準となるべき手順、仕様書の書式の詳細を決める

 かくして、着手してから1年半後から2年後くらいに、「これから10年使う開発標準や基盤環境」ができあがる……はずが、実際には現場の実態とかけ離れたルールブックができあがるという具合です。

 ビジネスの変化に即応するスピード感やアジリティが強く求められる昨今、開発現場でのプロセスに対するアプローチも変わっていかねばなりません。

 昨今のアジャイル開発の一般化を契機に、開発プロセスの定着と改善について、Rationalチームでは、次に紹介する3つのアプローチを提唱し、RTCとRMCとの連携によって、それを実現しようとしています。

プロセス運営の3つのアプローチ

1. 受動的アプローチ

 まず最初に挙げるべきなのは、開発者の振るまいを「受動的」アプローチに変えたいという点です。

 品質やコストに問題意識を持っているIT組織の多くが、(1)プロジェクト管理、(2)標準化を強化施策として挙げています。「より高品質&より低コスト」を求めて、作業手順を詳細に定義し体系づけて、結果として水も漏らさぬ「百科事典」を作り上げるのです。

 しかし、その手順にのって開発を進める方は地獄です。社内イントラネットやファイルサーバーで共有された標準規定書に準ずるための活動はすべて人に任されます。今着手しようとしている作業の詳細を手順書で探しだし、完了基準を達成しているかどうかを人が判断し、マスターソースの更新作業の条件を確認し……(少々大げさですが)あらゆる箇所でその手順を意識しなければなりません。

 このように、これまでの開発プロセスの運営は、常に『適用される側がプロセスに準ずるために「能動的」に関わること』を求めてきました。

 それに対して、「受動的」とは「必要があればツールがガイドしてくれる」という意味です。

 具体的には、RTC単独あるいはRMCとの連携で次のようなサポートを実現しています。

  • RMCで標準として定義された活動は、RTCのタスクとして登録される(図1)。開発者は、タスクの説明を見たければ社内イントラネットで公開されたプロセス定義の該当箇所を、RTCから直接参照することができる。このように必要なときに必要なガイドを最小限の手間で照会することができる
  • 事前条件/事後条件を設定しツールに自動チェックさせる(図2)。例えば、ソース管理で共有領域を更新する場合には、「変更理由を明記するタスクが関連づけられていないと、ツールの側が更新を拒否」し、「その場合の対処法をガイド」してくれる
  • タスクとソース(の変更部分)が常に関連づけられていることによって、CI時の各ビルドがどんなタスクの結果を反映しているのかの報告(ビルドレポートあるいはリリースレポート)を自動化してくれる
図1 定義(RMC)と実行エンジン(RTC)との連携
図1 定義(RMC)と実行エンジン(RTC)との連携
図2 RTCの振る舞いに対する役割別の事前条件設定
図2 RTCの振る舞いに対する役割別の事前条件設定

 これまで「開発」という文脈で自動化というと、テストやコード生成の自動化が語られることが多いと思います。RTC+RMCでは作業の流れやそれに関わる条件判定をツール側に任せることによって、「何か齟齬があったときに開発者に教えてくれる」受動化アプローチをとれるようにしているのです。

次のページ
まとめ:整理体系化することは「非アジャイル的」か?

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

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

もっと読む

この記事の著者

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

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

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

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

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

この記事をシェア

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

おすすめ

アクセスランキング

アクセスランキング

イベント

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

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

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

メールバックナンバー

アクセスランキング

アクセスランキング