SHOEISHA iD

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

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

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

第5回 ソフトウェア開発にビジネス・インテリジェンスを

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

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

管理者層は?

 私はIT部門の管理者層(IT部門長などの組織管理者、プロジェクト・マネジメント・オフィスなど)の方と話しをする機会が多くあります。複数のプロジェクトをまとめてみる立場の管理者層の方は、以下のような悩みを持たれているケースが多いです。

  • たくさんあるプロジェクトの中で、結局どのプロジェクトに問題があるのか分からない
  • 問題に気づいたときには手遅れになっているケースがある

 例えば、管理者層がつぶさに各チームのダッシュボードをみる、もしくは各チームで毎朝行われるスタンドアップミーティングなどに参加してヒアリングすれば解決されるかもしれません。しかし、プロジェクトはたくさんあり、そもそも管理者層は多忙です。

 さらにお話を伺うと、以下のような方法(図3)で報告を受けているケースが一般的です。

図3 一般的な報告の流れ
図3 一般的な報告の流れ

 マネジメントへの報告のために、まずプロジェクト・メンバーからの報告をPMがとりまとめ、さらにPMOなどがそれをとりまとめ全体報告を作成します。

 とりまとめと報告が何層にも及んでいます。プロジェクト・メンバーの報告から全体報告までに1週間~2週間はかかっています。

 手作業でのとりまとめによる間違いも起こるし、報告内容の「いわゆる調整」も入るかもしれません。これでは、2週間前の情報で判断することになり、そもそも正しくない情報によって判断せざるをえません。

 管理者層は、組織としての目標を達成する、リスクを察知して早期に対応する、場合によってはプロジェクトを早期に中止して費用の浪費を抑えるといった対応をとりますが、そのためには、正しい情報に基づいて、「一目」ですぐに「結局どのプロジェクトに問題があるの?」に気づけることがなにより重要です。

管理者層を支える開発インテリジェンス

 各プロジェクトの細かく大量な実績データ(タスク、障害、課題、ソースコード、テストケースなど)をもとに、意思決定できる情報に変える。切り口を変えて分析する。この考え方は、膨大な業務データをもとに経営面での意思決定を支援するビジネス・インテリジェンスの考え方と同様です。ビジネス・インテリジェンスのコンセプトをソフトウェア開発に適用するという意味で、Rationalではこの考え方と仕組みを「開発インテリジェンス」と呼んでいます(図4)。

図4 開発インテリジェンスの仕組み
図4 開発インテリジェンスの仕組み

 この仕組みでは、人手を介することなくプロジェクトで使用しているRTCなどのツールから直接データを取得し、データウェアハウスに取り込みます。そのデータをビジネス・インテリジェンス・ツールのレポート・エンジンにより意思決定のできるレポートとして表示し、必要に応じて問題のあるプロジェクトを掘り下げて分析します(図5)。

図5 開発インテリジェンスのレポート
図5 開発インテリジェンスのレポート

 この仕組みにより、開発者は普段の開発作業を行い、RTCのダッシュボードによってプロジェクトの予測性が高められる一方で、管理者層はクリアな定量的データをもとにした開発インテリジェンスにより、一目で問題に気づき、原因の分析ができるのです。

そして継続的改善へ

 そろそろこの連載も終わりに近づいてきました。

 第1回で、RUP(IBMプラクティス・ライブラリ)は『「開発プロセス」から「開発組織のためのプロセス」』へ進化しているという話がありました(未読の方はこの際にぜひ!)。

 プロセスは、決めること自体に意味はなく、適用されて効果がでて初めて価値があります。クイックにプロセスを定義し、適用し、展開して、これを繰り返すことで継続的な改善につながります。

 効果をどのようにみるか。開発インテリジェンスの仕組みにはあらゆるデータが蓄積されているため、これもまたクイックに効果をみることができます。

 IBMプラクティス・ライブラリでは、プラクティスと測定をマッピングして体系化し、適用するプラクティスと効果測定がセットで定義されていますが、Rational Insightには、この測定レポートがあらかじめ含まれています。

 開発インテリジェンスの仕組みを使用することで、効果を測るために新たな運用や作業、測定の仕組みを変えることなく効果をみることができるのです。

 少々手前味噌ですが、IBM Rationalは組織改善のためのノウハウとその仕組みをもっています。

 多くのお客様のプロセス改善をお手伝いしてきた経験に加え、自らそのプラクティスを実践しツールを使用し組織を変革することで、IBMプラクティス・ライブラリ自体もツールもRationalの組織自身も進化しています。今、変革を求められる方々にとって、これらのソリューションが少しでもお役に立てればこれほど嬉しいことはありません。

 お付き合いいただきありがとうございました。

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

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

もっと読む

この記事の著者

江木 典之(エギ ノリユキ)

  日本アイ・ビー・エム株式会社 Rational事業部 テクニカルセールス。プログラマ、SE、プロジェクトマネージャーを経験し、現在はポートフォリオ管理エリアのソリューションを中心にセールス活動、導入支援・コンサルティングに従事。ソフトウェア開発にたずさわる人と組織の明るい未来を目指し...

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

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

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

この記事をシェア

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

おすすめ

アクセスランキング

アクセスランキング

イベント

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

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

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

メールバックナンバー

アクセスランキング

アクセスランキング