ビルド管理を楽にするオープンソースツール一覧：明日からできるプロジェクト管理（3）（5/5 ページ）

[高野敦，＠IT]

PMの独り言

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

石出さん　なるほど構成管理をきちんとやって、ビルドを管理すれば、ちょっとした「ムダ」を削減できそうだ。ツールを使っているので削減に掛ける工数も大したことはなさそうだ。確かにツールに慣れるまでは多少かかりそうだが、それは長い目で見れば必要なことだろう。

　次回は、このビルドの際に得られる情報について説明し、その情報を利用してプロジェクトを管理する方法について説明する予定です。前回予告し、今回説明できなかったソースコードの評価方法も併せて説明します。

コラム：ムダの見つけ方（「祝 ランス・アームストロング ツール・ド・フランス総合7連覇」）

円津　石出くん、ツール・ド・フランスって知っているかい？

石出　ええ、確かフランスの有名な自転車レースですよね。

円津　うん。ツール・ド・フランスは「フランス一周」という意味で、100年以上続く世界最高峰の自転車レースなんだ。今年は7月2日から24日までの21日間（途中2日の休みあり）で、189人の選手が3607 kmの距離を競い合ったんだ。ツールではその日のレースで1位を決めるステージ優勝と、21日間のタイムを積算して競う個人総合、いわゆるマイヨ・ジョーヌ（黄色いジャージ）があるんだけど、最後のパリのゴールでこのマイヨ・ジョーヌを着るというのはとても重要なんだ。そして今年のツールではなんとランス・アームストロングが総合で7連覇したんだよ。

石出　へえー、ランス・アームストロングって強いんですね。

円津　そうなんだ。でも彼は今年のツールでは1回しかステージ優勝していない。それでも総合優勝しちゃったんだ。これってどういうことか分かるかい？

石出　すごいってことですか？？

円津　今年はロビー・マキュアンという選手がステージで3勝したんだ。それでもその選手は総合で10位にも入れなかった。ツールで総合優勝するということは、必ずしも21日間のステージで多く勝つことではないんだ。ランスは毎日のステージではトップからあまり離れることなくゴールを続け、彼の得意とするタイムトライアルで一気にライバルたちとの差を広げた。つまり、総合優勝が全体最適だとすると、全体としての最高の結果を得る方法は、個々のタスクを最適化、つまりステージ優勝を狙うこととは一致しないということだよね。なんて偉そうなこといっているけど、これも「リーンソフトウェア開発（日経BP社）」の受け売りなんだ。まあプロジェクトなんて山岳ありスプリントありの、まさにツール・ド・フランスみたいなものだよね。ステージで勝つことよりも、最後に総合優勝を目指せばいい。ところで今日は「開発のムダ」について考える話だ。リーン開発の7つのムダはこの前紹介したよね。

石出　確か「未完成作業のムダ」「余分な機能のムダ」「余分なプロセスのムダ」「タスクの切り替えのムダ」「待ちのムダ」「移動のムダ」「欠陥のムダ」でしたよね。

円津　うん。まず「未完成作業のムダ」「余分な機能のムダ」なんだけど、納品しないもの、納品しても使われないものなんてまさにムダの極地だよね。でもこれって以外と気付いていないことが多いんだ。石出くんのプロジェクトでも、途中まで作業したのに何らかの理由で中断したり、作ったけど結局使われなかったことってあるだろう。

石出　そうですね。要件の勘違いから、無駄な機能を実装してしまったことがありました。途中の検収で発見して、結局そのコードは廃棄したことがあります。

円津　そう、恐いのは作業は連続しているから、ムダがムダを生むということなんだ。単純に考えても設計からコードとテストが派生するけど、その機能が納品されなければ、設計もコードもテストもムダになるだろ。だからこの手のムダは早い段階でつぶさなければいけないんだ。またよくいわれる生産性も、このムダな作業をカウントしている場合が多い。だから生産性を上げるには、まず「未完成作業のムダ」や「余分な機能のムダ」を見つけることなんだ。

円津　次に「余分なプロセスのムダ」なんだけど。忙しいとつい考えることを放棄して、誰かの仕事をそのまま模倣することってあるよね。例えば標準プロセスをそのまま採用しちゃうとか。これって標準化が悪いっていっているんじゃないんだ。ありがちなのは、お客さんに「何のためにこの作業をするんですか」と聞かれたとき、「うちの標準で決まっているからです」と答える人はこの“余分なプロセスのムダ”を生む典型だよね。

石出　恥ずかしいけど、僕もお客さんに「このドキュメント何のために作るの」と聞かれたとき、「オブジェクト指向開発で決まっているからです」って答えちゃいました。

円津　少なくとも自分のやるべき作業が何のためなのかを理解していないのは、恥ずかしいというよりもプロとして失格だよね。余分なプロセスは余分なアウトプットを生むから、計画する前にまずアウトプットに着目して、それが本当に必要かどうかを検討した方がいいよ。

石出　気を付けます。

円津　次は「タスクの切り替えのムダ」「待ちのムダ」「移動のムダ」、これは1人のリソースにマルチタスクを与える場合や、まとまった仕事を複数のリソースに与える場合に起こりやすいよね。特に1人にマルチタスクをアサインした場合は、クリティカル・チェーンでもいわれているように、一見効率よく見えるけど、実は生産性は下がる場合が多いんだ。「待ちのムダ」「移動のムダ」は、プロジェクトの作業環境によるところが大きいので見逃されやすいけど、あるプロジェクトでそれまでお客さんのところに毎週通って要件定義をしていたのを、お客さんの会社にプロジェクトルームを設けてもらって作業したら、それだけで生産性が5倍違ったということもあるからね。「移動のムダ」「待ちのムダ」もそうだけど、とにかくコミュニケーションに関するムダが大幅に削減されたんだ。

石出　へえーそうなんですか。

円津　最後に「欠陥のムダ」なんだけど、これは何でムダなのかはもう分かるよね。欠陥は修正するための手戻りが発生するからなんだ。その手戻りも、後工程に行けば行くほど大きくなってくる。上流の工程で欠陥を摘出するということは、ムダな作業をしないという意味で、すごい重要になってくる。上流でレビューやインスペクションをしっかりやっておけば、テスト時の修正工数も確実に減ってくるよ。

石出　よく分かりました。ところで最初のツール・ド・フランスの話は単なる円津さんの趣味で、今回の「開発のムダ」にあまり関係なかったように思えるんですけど、これこそがムダじゃないんですか。

円津　いやー石出くん、人間関係には時にはムダも必要なんだよ。

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

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