システム開発の進捗が思わしくない場合、その予兆を知りたいものである。コンピュータネタ、目次へ
慣れてくると雰囲気で分かるようだし、残業時間やレビューの不備項目増加、会議の日程変更が増える、なんて指標もあるだろう。その辺は経験豊かで能力のある皆さんに任せておこう。ふと気になったことがある。OA化の進展とともに、開発ドキュメントはみーんなファイルサーバーのフォルダーに収められるようになった。ってことは「全部見れば全部わかる」。
しかし現実的にそれは不可能である。そこで、と考えた。たとえばＵＴ（単体テスト）のドキュメントが収められたフォルダの中身が、ＳＴ（システムテスト）の段階になっても増え続けていれば、それは手戻りが発生しているということではないかな？人類が二本足で立って以来、後悔が先に立ったことはないといわれている。
ファイルサーバのフォルダの作成ルールを先に決めておけばよかった。少なくとも新規メンバーが増えた時なんぞは説明が楽だって理由付けて。
\組織名\業務名\案件名\フェーズ名\ドキュメント種類
なんてルールがあるととても分かりやすい。結局は「個人フォルダ」なんぞを作ってそこに溜め込む奴がいたりするんだが。。。仕方ないので現状でどうできるかやってみた。
ファイルを片っ端から拾ってフォルダのパスを見たあと指定キーワード、例えば「ＵＴ」なんてのがあればチェックしてカウンター１つアップ。過去にさかのぼっての推移を見たいから、例えば「2014年4月」と指定するとその月から今日まで一カ月毎に件数/ファイルサイズを集計する。途中ちょっと困ったことが「ＵＴ」を指定したが「ＩＮＰＵＴ」「ＯＵＴＰＵＴ」がヒットしちゃうんだよな。なので「ＰＵＴ」「ＯＵＴ」といった語句を指定して除外してやる。「ＵＴのＯＵＴＰＵＴ」なんてのがあってもお手上げにならないようにロジックをいじったが・・・完全にはできないけどもまだ調整の余地はあるな。（ＩＴ：結合テスト、とＩＴ：情報技術の分離はムリだ。）手近なところでDirをとって、編集（もちろんこれ用のツールも書いた）。試しに集計。
おお！結構メリハリがある。
これはイケるか？と「ＳＴ」をキーワードにしてもう一回実施。グラフで重ねると。見事に複数あるピークの山に４か月のインターバルができるのがみえる。そしてＳＴのピークに先立ってＵＴ関連のファイル数は殆どゼロまで減っている。中身見てないから詳しくはわからんが手戻りなし。これは成功プロジェクトだな。（各人が個人仕様のフォルダ内にファイルを隠しこんでいたとしても「UT」なんて文字列を使おうものなら分かる。バックアップをとってます、でもファイルの更新日付だから件数はともかくピークの月がずれることはない。）
ということは現行プロジェクトのＳＴフェーズでＵＴに戻っての手戻りがあるか、は把握できそうだ。検索キーワードを複数指定可能として案件名入れるとさらによくねえか。
Googleでこういうプロジェクト管理をやって遅延の予兆を見つけている、というと「なるほど、さすがはGoogle」と思い込んじゃう人がいそうだ。そうなんだよね。ビッグデータ的な発想である。細かいところまで踏み込まなくてもデータの数が多ければ、束ねることによって見えなかったものが見えてくる。もうひとつ、仮説に沿ったデータを集めるべくただでさえ忙しい開発陣に体力を割いてもらう必要がない。動いた痕跡を見ているだけでいい。プロジェクト管理にビッグデータ革命が起ったのだ。
ついでに申しあげますと、直近一週間のファイル更新状況なんぞをチェックしますと、ありゃ、なぜこのタイミングで？というのは見つかったりするかもしれない。ならば問い合わせることによって「実は」が分かってくる可能性は十分ある。さて、効果はありそうだとして（断言すると守秘義務違反と文句を言われるかもしれない）使ってもらえるだろうか。
開発者側に立ってみると、手戻り部分、きっちりとフォルダを分けをやっていれば、管理者が気が付いて「おい、大丈夫か？」と声をかけてくれるだろう、という仕組みだ。これは自分から言い出すより気分的には楽じゃないかな。管理者としても早期発見は悪い話ではない。
ところが・・・これがシステム開発の受注者と発注者（ようするに下請けと元受け）だとすると話が変わってくるかもしれない。ようするに組織が違っていると組織の中でなんとかしてほしいわけ。もっと露骨に言うと自分が問題点を発見したくないわけ。先に発見してしまうと対策取らなきゃならないじゃないの。スポンサーへのいいわけとしては「下請けの問題報告が遅れまして」と言いたいにちがいない。
というわけでこの手の「予兆発見ツール」使い方を含め、完成したとしても使ってくれないかもしれないな。かといって進捗遅れの予兆があれば発見したい、という要望がないわけがない。雑誌でも特集されているのを見た覚えがある。しかし実は気が付きたくないわけだから、そこでトピックとなる進捗遅れの予兆は、ユーザーの仕様を確認したときの回答時間の長期化、という比較的対象にしやすい、システム部門に関係のないものだったりするわけだ。
この「悪いことには気が付きたくない」という志向が、案件の問題点拡大を助長するわけで、対策としては案件管理を「進捗管理」と「機能管理」を分離させた複合管理が必要ではないかと・・・そういえば１５年くらい前に似たようなことを主張した記憶があるなあ。その場の思い付きに近かったが。