進行中からにじみ出ている、プロジェクトの失敗理由：情シスの本棚（4）

データで読み解く、開発プロジェクトの黄信号

●著者：神谷芳樹●オーム社●ISBN-10:4274504778●ISBN-13:978-4274504778●発売日：2013/11/29

　「ここで改めて『見える』とは何か考えてみよう」。「例えば40階建てタワーマンションの建設工事であれば、鉄骨が20階まで建てば、誰でも骨組みは『半分できた』と認識できる」。「しかし、ソフトウェア開発はこうはいかない」。「最も基本的な『どこまでできたか』という進捗率の把握もままならない」。「プログラムの分量にして全体の90％のモジュールが完成したように見えても、残り10％を加えたところで全体が動かなくなり、問題解決に長期間要する」ことは十分にあり得る。「何の工夫もしなければ、いわば『藪の中での工程進捗』となってしまう」――。

　本書「チケット＆計測でITプロジェクト運営の体質改善」は、開発プロジェクトを「計測し、グラフ等の形で可視化」することで、ソフトウェア開発の重点課題である「説明性と追跡性」を担保する手段を説いた作品である。

　ほとんどのビジネスをITシステムが支えている今、システム開発のステークホルダーの範囲は「飛躍的に広がっている」。しかし、コストと品質の両立、そして最も重要な「ビジネスへの寄与」というゴールが年々厳しく求められている今にあっても、プロジェクトそのものは依然として「藪の中」というケースは非常に多い。そうした中で、「働く人のモチベーション」も含めたさまざまな潜在リスクを抱え込み続けているケースも少なくない。本書はそうした点を受けて、チケット駆動開発を軸に「どこまで進捗しているか」「予定に対してどうなのか」「品質は確保されているか」といった点を見える化し、ブラックボックスを解消する意義と手法を説いている。

　中でも軸としているのが、IPA/SEC（情報処理推進機構／ソフトウェア高信頼化センター）が2012年に提供開始した、計測と可視化のためのオープンソースプラットフォーム「EPM-X」を使ったチケット駆動開発の在り方だ。チケット駆動開発は、「いうなれば課題追跡とバグ追跡を全行程に拡張し、すべての作業をチケットの発行のもとに実行し、管理していく手法」。この実践方法について、EPM-Xにプリセットされているオープンソースの課題追跡システム「Redmine」を使って解説。「チケットの集計方法」「チケットへの記入情報」「チケット集計結果のさまざまな表現」といった具合に、基礎から実践方法までを順序立てて説いている。

　また、やはりEPM-Xにプリセットされているオープンソースの構成管理・バージョン管理システム「Subversion」とRedmineの同期による「プロセス管理とプロダクト管理の連携方法」や、ソフトウェア開発プロセスを一貫して観測できる自動計測基盤の整備法も具体的に解説。Redmine、Subversionは多くのユーザーになじみ深いツールだけに、興味をそそられる向きも多いのではないだろうか。

　目を引くのは、見える化の手法を説くだけではなく、豊富な事例を通じて、データからプロジェクトの改善策を読み解くための“視点”を多数紹介している点だ。例えば「ソースコードの規模推移」の計測によって、コード行数がある日突然、数百行も急増していると分かったとする。この場合、「プログラム開発が階層的な開発組織の中で行われ」ており、「下位の組織でプログラムが作成され、ある日まとめてコードの計測拠点である上位組織にリリースされたために、コード行数が急増した」ことが疑われる。

　こうした開発体制が「関係者の合意のもとに計画されていれば問題は少ないが、これが秘匿された状態で」あったとしたら、当然ながら確実なプロジェクト管理は難しくなる。つまり、そもそも開発体制や情報共有体制から見直す必要があるのではないか？―― といった具合に、たった1つの計測データが物語る多数の真実を読み解くノウハウを紹介しているのだ。

　「チェックイン＆アウト頻度」が教えてくれる課題もある。例えば頻度をグラフなどで可視化した結果、チェックアウトがまったくない状態がしばらく続いていれば、「開発メンバー間で共有するプログラムがなく、作業が個々の開発者ローカルに進められている」ことが考えられる。この場合、「管理サーバを介さないローカルなファイル提供」などが行われていれば、「管理上の問題につながる」ことが懸念される。

　「メール投稿数」と「チェックイン契機数」をグラフ化すれば、コミュニケーションの在り方も見える化できる。例えばチェックインは毎日行われているのに、メール投稿数が極端に少ない場合、「他の手段でコミュニケーションが取られていれば問題ないが、作業手順、連携体制上の問題が」あることも考えられる。逆に、チェックイン契機数は変わらないのにメール投稿数が急増している場合、「計画されたイベントのタイミングと重なっている」などの手掛かりが見つからない場合は、何らかの問題が潜んでいる可能性が高い。本書では、こうしたプロジェクト状況の可視化は、「マルチベンダー体制でサブシステムごとの並行開発が進むような中・大規模開発」で特に有効だと指摘している。

　著者は「産業活動において、人が見えないものに納得し、見えないまま合意して共同作業を進めるのは至難だ。『見える化』は、プロジェクトに参加するすべての人が『納得して』その役割を果たすために必要である」と説いている。DevOpsの文脈でも語られることだが、ITがビジネスを直接的に支えている今、ソフトウェア開発の“全ステークホルダーの納得”をどう醸成するのか―― 本書を参考に考えてみると、これまで見落としていたようなプロジェクトの意外な問題点、改善策が浮かび上がってくるのではないだろうか。