BTSをBusiness Intelligenceとして使う
チケット駆動開発の戦略part3として、BTSをソフトウェア開発のBusiness Intelligenceとして使うアイデアをメモ。
#走り書きなので後でまとめる。
元ネタは、下記の記事。
【1】Web2.0の重要機能「足跡」をプロジェクト管理に応用できないか?
ソフトウェアメトリクスの測定には、大きな障害がある。
それは、メンバーがプロジェクトに関する様々なデータを「入力する手間」が発生することだ。
ソフトウエア開発プロジェクトはただでさえ忙しいから、入力するデータの質は落ちやすい。
だから大手SIや銀行では、上からの命令で15分おきに生産性を入力させるような運用もしている。
つまり、彼らは従業員の実績をリアルタイムに管理したがっている。
でも、ソフトウェア技術者である僕らは奴隷じゃない。
トイレに行く時間まで管理されたくない。
Web2.0システムは、作業ログを自動収集して、色んな観点から統計結果を見せる機能がふんだんにある。
つまり、緩やかに作業ログを収集する仕組みが洗練されている。
しかもRSSなど、収集したログを集計した最新情報を自動配信する機能さえある。
この機能は、小売系WebシステムやMixiなどのSNSでは当たり前の機能だ。
データマイニングをマーケティングの一手法として使う。
例えば、レコメンドエンジンとは、eコマースサイトでよく見られる「これも一緒にいかがですか?」と関連商品を表示する機能を実現したものと言える。
特に、Amazonの最大の特徴は強力なレコメンデーション機能にあると言ってよい。
例えば、Amazonのレコメンデーション機能は協調フィルタという有名なアルゴリズムが使われている。
PVや画面遷移の履歴は簡単に採取できる。
例えば、PVや画面遷移の履歴、購入履歴から、購入画面や注文画面へ誘導するする設計を取ることもできる。
これを使って、購入履歴から売れ筋の商品をリンクさせる機能も追加できる。
この機能は、商品購入時に関連商品を表示させて、商品のレビュー履歴から関連商品をお勧めさせたいのだ。
Googleの検索エンジンのアルゴリズムpageRankも同様の発想だ。
つまり、どのHPが一番検索されて有用か?を検索履歴から集計して最新情報を常に反映させる。
これによって、商品を検索した時、特定のHPに誘導することさえできる。
mixiのようなSNSの足跡機能も同様。
特定の人へのアクセスログから、友人関係の距離を計算できる。
ここから、「スモールワールド」「世界中の任意の人とは6人の人間関係を経由すれば必ずアクセスできる」などのような社会科学の研究にもつながる。
しかも、これらの機能は、Google、Amazonのように、マッシュアップのおかげで多様なWebサービスが誰でも簡単に作れる。
この機能を更に進化させた概念がいわゆるBI(Business Intelligence)だ。
業務システムに蓄積される企業内の膨大なデータを、分析・加工して、企業の意思決定に活用しようとする手法。
ERPパッケージやCRMソフトなどからもたらされるデータの分析を専門家に依存せず、経営者や社員が必要な情報を自在に分析し、経営計画や企業戦略などに活用することを目指す。
この機能は、マーケティングを生かした商品開発、ビジネス上の経営判断に使える。
この機能をプロジェクト管理にも使えないだろうか?
【2】BTSのチケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にする。
ソフトウェアメトリクスを採取する話では、いつも「計測できないものは制御できない」というケルビン卿の話が良く出る。
つまり、ソフトウェア工学とは、ソフトウェア開発プロセスの定量化が目的の一つなのだ、と。
ソフトウェア・リポジトリ・マイニングは、ソフトウェア開発履歴からのお宝発掘。
SVNコミットログ
BTSチケット履歴
ビルド履歴
メーリングリスト
から、プロジェクトの状態、ソースの状態、作業の状態をリアルタイムに見える化する。
管理者がやりたいことは、BTSのチケット集計結果にソフトウェア工学の知識を応用して、プロジェクトのリスクをいち早く感知したいこと。
Redmine/Tracのようなプロジェクト管理機能を持つBTSは、プロジェクトのセンサー。
プロジェクトリーダーは、リアルタイムに出力されるBTSのソフトウェア・リポジトリ・マイニング機能を使いこなせれば、プロジェクトをモニタリングしながら、リスクを即座に察知できるはず。
チケット集計結果から、信頼度曲線を出力できれば、後どれくらいの工数で品質が歩溜まりに達するか分かる。
garyoさんのRubyプログラムを使うと、Mantisの出力CSVから、信頼度曲線を作ることができる。
更に、SRATSというフリーの信頼性評価ツールにチケット集計結果を食わせると、下記を出力できる。
2-1.Total: 対象とするソフトウェアに潜在する総フォールト数
2-2.FFProb: 現時点で対象とするソフトウェアにフォールトが存在する確率
2-3.MTBF: 次のフォールトが発見されるまでの時間
2-4.Be X Life: 次のフォールトが発見される確率が0.9となる時間
(その時間までに1つ以上のフォールトが発見される確率が9割)
情報処理試験で習ったMTBFの概念は、ハードウェア障害だけでなくソフトウェアの障害まで当てはめることができる。
この数値をプロジェクト終了後にメンバーと一緒にKPTを行えば、何が問題だったのか、次のプロジェクトでは何を試せばいいか、メンバー自身を自然にプロセス改善に誘導できる。
BTSを有効活用すれば、プロジェクトをこなすたびにメンバーを成長させるきっかけにできるはずだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
コメント