成果物・文書管理にすぐ使えるオープンソース〜効果的な成果物・文書管理手法〜：明日からできるプロジェクト管理（2）（3/3 ページ）

[高野敦，＠IT]

PMの独り言

　これらの説明をしたうえでPMの石出さんに感想を尋ねてみました。

石出さん　なるほど、成果物をこのように管理すれば便利そうだ。特に、Wordのサブ文書機能を利用して成果物を分割する方法と構成管理ツールを利用してリビジョンとバージョンを管理することでレビューなどを正確にできる気がするよ。でもソースコードは別な気がする。ソースコードも成果物だけど……。ソースコードの管理やビルドはどうするのだろうか。

　成果物の定義、管理はできるようになったようですが、次にソースコードの管理を悩んでいるようです。ソースコードはほかの文書と違って、ビルドすることが重要です。次回はこのようにソースコードを管理したうえでビルドをどのように行っていけばよいかを説明することにします。また、ビルドとともに単体テストを自動実行するとソースコードの品質などを評価する方法を紹介します。

［ムダのない開発］

石出さん　円津さん、この前教えてくれた『リーンソフトウェア開発』（M. ポッペンディーク著、平鍋健児訳、日経BP社）についてもう少し詳しく教えてもらえませんか。

円津さん　そうだね。石出君はアジャイルやスクラム、XP（eXtream Programming）っていう開発方法を聞いたことがあるよね。

石出さん　ええもちろん。特にオブジェクト指向開発では騒がれている方法ですよね。

円津さん　でも実際はアジャイルっていう開発方法論があるわけではないんだ。1990年ごろからいろいろな人が取り組んだベストプラクティスを集めたものがアジャイルといわれているんだ。アジャイルの代表的な『XP』には最近20近いベストプラクティスが定義されている。実は『リーンソフトウェア開発』もソフトウェア開発におけるベストプラクティスが考えられたものなんだ。

石出さん　それってどういうものなんですか？

円津さん　「リーンソフトウェア開発」には7つの原則がある。

1. ムダを排除する
2. 学習効果を高める
3. 決定をできるだけ遅らせる
4. できるだけ速く提供する
5. チームに権限を与える
6. 統一性を作り込む
7. 全体をみる

　これらの原則に思考のためのツールと呼ばれるプラクティスが含まれている、これが『リーンソフトウェア開発』と呼ばれるものなんだ。ちなみに、これらの基本的な考えは実は製造業、とりわけ日本的生産方式から学んだものなんだ。

石出さん　『ムダを排除する』のが原則といわれても、なんか当たり前過ぎてピンと来ません。

円津さん　そうだよね、普通はムダだと承知で作業することなんかないはずだ。ただ結果的にそれがムダとなったのなら、なぜムダになったのかについて分析し、次にそれを排除しなければいけないよね。例えば石出君は今回の開発では設計を完全にFixしてから実装に入ったよね。でも開発がだんだん進むにつれいろいろな要件が変わってきた。それにより設計も影響を受けたことがなかったかい？

石出さん　ええ。実は最初にDB設計を結構しっかりやったんですが、どうでもいいと思っていた帳票の出力が大きく変更になり、そのため登録系の処理を含めて大きく見直さなければならなくなりました。

円津さん　なぜ変更が発生したんだい。

石出さん　なぜっていわれても……。

円津さん　それって設計をFixしたことがムダになっていないかい。

石出さん　それはそうですけど、じゃどうすればよかったんですか。

円津さん　僕も分からないさ。でもそれを考えるために『リーンソフトウェア開発』は7つの原則にそれぞれツールを用意したんだ。いいかい、プロジェクトはPMBOKがいうように、ユニークな成果物を作るための活動だよね。いい換えればプロジェクトはユニークだから、ほかのプロジェクトがうまくいったからってそっくり同じことをしても駄目なんだ。なぜうまくいったのか、なぜ失敗したのかを考えることが必要だろう。そのためにはまずムダを見直すことが必要なんだ。

石出さん　なんとなく分かる気がします。円津さん、ムダを排除するためのツールって何ですか。

円津さん　『リーンソフトウェア開発』の実践っていうのはまずムダを排除することから始めるんだ。そのためにはムダを認識することが必要だ。ソフトウェア開発には“7つのムダ”があるといわれていて、“未完成の作業のムダ”“余分なプロセスのムダ”“余分な機能のムダ”“タスク切り替えのムダ”“待ちのムダ”“移動のムダ”“欠陥のムダ”というものなんだ。これらは見つけにくいムダを発見する視点を与えてくれるものなんだよ。

石出さん　“7つのムダ”がムダを発見するツールというんですね。例えばどんなことなんですか。

円津さん　そうだな、製品の価値に直接影響を与えるものでないということでいえば、『管理作業』にはムダが多いかもしれないね。例えば、君は成果物の進ちょくを見るために毎週担当者からメールで報告させていたよね。一方で担当者は作業結果を構成管理ツールに登録している。だったら君自身が構成管理ツールの状態を分析できれば、担当者はわざわざメールで報告する必要はないよね。これって余分なプロセスのムダじゃないかい。作業上の問題だったら、毎朝の朝会で確認しているし。つまり当たり前と思ってやってきたことも、実は意味も考えずにムダなことをやっているんだよ。

石出さん　なるほど。こうしてみると結構ムダな作業ってあるかもしれませんね。

円津さん　そのとおり！ ただし小さいムダに気を取られ過ぎてはいけないよ。制約理論でも部分最適の総和は必ずしも全体最適につながらないといっているとおり、まずは大きなムダを見つけることが大切なんだ。それとムダを認識するということは「本当に必要なもの」について考え続けていくことなんだ。これって継続的改善プロセス、つまりCMMみたいだろ。CMMのレベル5の状態というのはアジャイルのような開発をいうんじゃないかと僕は思うんだ。

石出さん　円津さん、アジャイルからCMMレベル5ですか、今日は飛ばしますね。

円津さん　そうだね、じゃあ今日はこれぐらいにして、次回は実際にムダについて一緒に考えてみようか。

石出さん　よろしくお願いします。

「明日からできるプロジェクト管理」バックナンバー

• ビルド管理を楽にするオープンソースツール一覧
• 成果物・文書管理にすぐ使えるオープンソース〜効果的な成果物・文書管理手法〜
• デスマーチを止める進ちょく管理の現実解:GanttProjectの導入で進ちょくをコントロールする