プログラマの思索

【1】開発の殆どの現場はIT化されていない

「ソフトウェア開発をIT化する」という言葉は自己矛盾な気もする。
しかし、SIerの開発の現場をのぞくと、作業は実は殆どIT化されていない事実に気づく。

プロジェクトリーダーならば、顧客や上司から下記の報告をいつも求められているはずだ。

1-1・プロジェクトで開発する全機能のうち、今、進捗は何％で、後何％残っていますか？
1-2・システムテストで上がったバグは今いくつで、後いくつ残っていますか？
1-3・明日のリリースの前に、今残作業はいくつで、その優先度はどうなっていますか？
1-4・見積の工数と実績工数の差はどれくらいですか？

上記の数値を一瞬で出せる現場は、実は殆どないのではなかろうか？
理由は、顧客や上司が求める数値は引き算で要求されるので、一旦現状の数値をメモリに保持して計算しないといけないから。

プロジェクトリーダーは、上記の数値を毎日、彼の作業時間の殆どを使って計算して、翌日に報告しているだろう。

特に、システムテストで上がったバグ報告をリアルタイムに管理するのは至難の業だ。
普通は、最盛期に1日20件のバグが報告されるが、開発チームがバグ修正できる件数はおそらく1日最大8件ぐらい。

つまり、バグはどんどん溜まって増えていくので、そのバグに優先順位を付けて、いつ修正するか、を管理することがすごく重要になる。
この時に、BTSを使っていない開発チームは、膨大なバグに押し潰されて、システムの品質が歩留まりまでなかなか到達しない。

更に、XPが提唱する統合ビルド環境のない開発チームは更に状況が悪化する。
本番リリース前後では、たったソース1行の修正でも、テスト担当者、プログラム修正開発者、検証担当者の3人が加わるから、1時間で終わる作業でも、3人時間もコストがかかる。
つまり、たった1個のバグ修正を検証する作業に、すごくコストがかかってしまう。

プロジェクトファシリテーションが提唱する「プロジェクトの見える化」は、上記の現状をチーム全員が認識できる環境作りを重視している。
「プロジェクトの見える化」にIT化が使えないだろうか？

【2】IT化しやすい開発プロセスはどこ？

ソフトウェアの開発プロセスは普通、下記のフローだろう。

要件定義
↓
設計
↓
実装
↓
テスト

そして、それを支えるプロジェクト管理のいずれも、殆どの現場はIT化されておらず、マンパワーでカバーしようとしている。

XPでは、テスト駆動、統合ビルドという発想で、テスト作業をプログラムで自動化し、検証作業を自動化しようとする。

BTSは、システムテストの検証作業を一つの業務システムと見なし、バグ報告をチケット単位に管理して、状態をトレースしやすくする。
例えば、MantisやBugzilla。
つまり、BTSはソフトウェア開発のIT化そのもの。

また、Testlinkというオープンソースのテスト管理ツールを使うと、要件とテストケースの紐づけができて、要件とテストの両方を管理できる。

【3】Redmineがプロジェクト管理をIT化する

更に、Redmineは、単なるBTSの機能だけでなく、プロジェクト管理の機能も実現している。
つまり、下記の機能のように、チケットを色んな角度から評価している。

2-1.活動
　チケット更新やSVNリビジョンを表示。

2-2.ロードマップ
　マイルストーン単位のチケットの状態と進捗％を表示。

2-3.ガントチャート
　チケット単位の進捗％と作業開始・終了日を表示。

2-4.カレンダー
　チケットの開始終了日やマイルストーンを表示。

2-5.レポート(サマリ)
　トラッカー(バグ・仕様変更・仕様追加)、優先度、担当者、バージョン(マイルストーン)、カテゴリ(機能別)ごとに、チケットの状態(未完了・完了)の集計結果を表示。

2-6.経過時間
　 実績工数(単位：h)をトラッカー(バグ・仕様変更・仕様追加)、優先度、担当者、バージョン(マイルストーン)、カテゴリ(機能別)ごとに表示。

プロジェクト管理とは、プロジェクト内部で発生する作業や問題をPDCAサイクルで解決しようとすること。
Redmineでプロジェクト管理すると、下記のようなPDCAサイクルが発生するだろう。

Plan：チケットを新規作成し、アサインする。
↓
Do：チケットの作業を開発者が完遂する。
↓
Check：チケットの状態を様々な観点からチェックする。
↓
Action：起きている問題、又は予期できるリスクに対して対策を立てる。

つまり、Redmineが他のBTSよりも優れている点は、Check(評価)の機能が充実しているからだ。

チケットの集計結果を色んな角度から評価できるので、プロジェクトリーダーは、その集計結果から、様々なリスクを対処しやすくなる。
しかも、チケットさえ作業担当者が正確に入力すれば、リアルタイムにプロジェクトの現状を誰もが把握できる。

RedmineでCheckの機能が充実している理由は、チケットの情報が全てDBにあるから。
DBにあれば、Ruby on Railsという優れたフルスタックなWebフレームワークのおかげで、一瞬で集計結果の機能を実装できる。

そもそも、自動集計という機能は、SIerが顧客の業務のIT化で行う作業と同じ。
経営層への売上集計レポートは、「会社のキャッシュフローの見える化」そのものだ。
お客様の会社のために、月末に売上計上し、月初に色んな観点から売上集計した結果を経営層へレポート提出するバッチを作っていませんか？

その発想をソフトウェア開発にも応用してみよう。

【4】IT化されたソフトウェア開発スタイル

現在、運用できると考える開発スタイルは下記2つの観点からなる。

4-1.開発の流れ

要件定義←Testlink
↓
設計＝プログラミング
↓
実装←SCM(Subversion)
↓
テストケース作成←Testlink
↓
テスト実施・検証←統合ビルド環境
↓
テスト管理＆プロジェクト管理←Redmine

4-2.データの流れ

TestLinkのテスト実行画面にredMineの問題（チケット）へのリンクを張る機能がある。
つまり、Subversionと連携すれば、要件からソースまで一貫してトレースすることは理論上可能だ。

要件管理(Testlink)
↓↑
テストケース管理(Testlink)
↓
【チケット】(Redmine)
↓↑
ソース(Subversion)

上記の環境が運用できれば、プロジェクト進捗を手計算する作業を離れて、リスク管理するというプロジェクトリーダー本来の作業に集中できるようになるだろう。