]project-open[ 座談会

あしたの研メンバーのともじさんが ]project-open[ の概要を紹介しました。

(2010年1月28日開催)

どう使う、プロジェクト管理ツール?

みやプロジェクト管理をするアプリケーションというのは欧米からかなり来てるじゃないですか。ただ、それはあるプロジェクト管理の手法とか方法論に基づいてて、よくできていると言われるものはそれをかなり正確に実装していて、かなり厳格なコストから請求までやられているんだけど、日本だと、どうしてもそれをすべて合わせられるプロジェクトというのは、バリバリの外資系の会社でもなければちょっと無理かなという気はしていて、結局会社としてはプロジェクト管理ツールの使い方って、その機能のどこの部分を全体のプロジェクト管理のここに当てはめて使うというような、全体をそれでカバーしようっていうのは、基本的に無理があるんじゃないかと僕は思っているのですが。

ともじ以前、Microsoft Projectを業務で使っている中でつくづく感じたのは、1つは使う人を選ぶところが若干あって、プロジェクトマネージメントの方法論とか考え方とかガントチャートとかPERTチャートとかクリティカルパスとか、そういった概念を理解していないとソフトもツールも使いこなせないということがあるんですね。PERTとか理解しているとある程度、そういった機能を効果的に使いながらリソースのムダとかボトルネックとかを見つけ出すことができるので、それは有効なんだと思うんですね。あと、もう1つは、特に翻訳の仕事の場合、ソフトをシステム開発に似たところがあると思うんですけど、タスクの単位が何時間とか何日とかっていうようなものには向かないなと。つまり、タスクの単位が1ヶ月とか最低1週間というような単位でタスクの期間を仕切れるようなものについては、タスクの期間が1日とか数時間で終わるようなタスクでガントチャートを組んでしまうと、余日管理だけでも日が暮れてしまう。けれども、もう少しタスクの期間が長ければ、例えば1週間に1回チャートを見直すとかリソースの配分を見直すっていう、もうちょっとゆとりが持てるんだろうと思うんですけど、そういった意味でタスクの期間とプロジェクト規模、プロジェクトは最低半年以上のプロジェクトで、また、マネージャがある程度プロジェクトマネジメントの手法の理解がある、この2つが重なると比較的有効に余日管理まで、Microsoft Projectとかそういったツールでできるなぁというのは何となく印象として持っているんですけど。

さそうツールで管理するところもやっぱり便利なところもあるんですけど、ツールで出るタスクの見積もりって言ったらいいんですかね、このエンジニアだと何時間だけどこっちのエンジニアだとまたちょっと違うとか、入れるべき見積もりの工数だったり対象だったりでマネージャはバランスを取ってあげる、ツールだけで全部管理するのではなく、管理する側が多少そのときの状況とか条件とか人を見て入れるっていうことをやってあげないと、やっぱり難しいのかなぁと。Microsoft Projectでやれる部分と、マネージャとかプログラマとかエンジニアがそれをどういう風に使わないといけないというところを、バランスを取ってツールを使うところが重要なのかなぁと。ただ、入れた後になってお客さんからの要望が変わって、作ってる途中でパフォーマンスが遅いなぁとか、パフォーマンス検証を助けたりとか、そういう変更に対応できるところが出てきたらツールにやってほしいかな。人間もやんなきゃいけないんですけど、ツールも1回引いた線を、ここにちょっとタスクを入れるとみんな崩れちゃって、そういうところを何とか便利にしてほしいなぁ。

みやヒューマンスキルというか、ツールに依存しなくても小さなプロジェクトが回せて、MSProjectに実装されている方法論を熟知した人でないとだめじゃないかなと僕は思うんですね。よくあるのが、プロジェクト側が上手くいかないと言うと、「じゃぁ、ツールを入れて上手くいかせよう」と。そういう問題じゃないんですよね。ガントチャートを書けばプロジェクトが上手くいくと思いこんじゃう人。今おっしゃったように、結局、人間系でいろいろやり繰りしながら「これが遅れたらこっちもちょっとずらして」って頭の中で想像を膨らませて、「何とかここで取り返そう」というのがあるはずなんだけど、ちょっとその辺、技術者は特にツールで解決しようとかね。「情報が共有化されていない」って言うとWikiを導入しようとか、ツールで解決しようとするんですよね。そこで話せばいいじゃん、っていう(笑)。

ともじ例えばMSProjectでも、前に某社のプロジェクトマネージャからMSProjectのガントチャートが送られてくるんですよ。でも、キックオフミーティングのときにしか使わないんですよね。キックオフミーティングのときに「向こう半年くらいこういう予定でこういう役割分担でやります」というためのお絵描きツールの1つとしてガントチャートが出てきて、そのファイル、キックオフミーティングの後はまず見ることはないですからね。そういった意味では、個人的な経験から言えば、MSProjectは最初のラフプランを作るためのツールみたいな。

かさい私が翻訳プロジェクトで経験したことですが、まだ新米のコーディネータ(翻訳者のスケジュール管理をやる人)がMicrosoft Projectで進捗のスケジュールを作ったんですよ。だけど、ものすごく簡単で、全体が何ワードで、いつが期限で、始めるのはここだから、その日数で単純に全体のワード数を割って、この日は何ワードっていう風なガントチャートを作ってみんなに配ったんですけど、当然それじゃ上手くいかないんですよね。やっぱり使う人がわかっていないと、特に翻訳の場合、最初は製品の理解とかにものすごく時間がかかるので、最初は遅いんですよ。だんだんスピードが上がっていって、最後はみんなペースに乗ってトップになるので、最初は少し少な目に設定してっていう風にやればいいんだけども、そういうところまでわかってないと、ただ単純にわり算してきれいにチャートができると、これでスケジュールができましたで終わっちゃうので、「それはないだろう!」と思うんだけれども、一応、立場的にコーディネータの方が上なので「わかりました」と言ってやるんだけどやっぱりできなくて、「すみません、できません…」「何でできないんですか!」ということがありました(笑)。

プロジェクトのボトルネック

ともじ『The Goal』という本を書いたエリヤフ・ゴールドラットが、プロジェクトマネジメントが何で失敗するのかというのを彼なりの発想で書いた本『クリティカルチェーン〜なぜ、プロジェクトは予定どおりに進まないのか?』があって、そもそも彼が言うにはプロジェクト管理についてはクリティカルパスという考え方そのものがナンセンスで、夏休みの宿題症候群は誰にでもあると、例えば1週間という期間を与えられたときに、3日で終わったから次の工程へ回すというのは、どんなプロジェクトでもまずないと。3日で終わったら4日間寝かしておいて、それから渡すと。3日で納めちゃうと次のプロジェクトも3日になっちゃうじゃないですか。1週間与えられたら1週間ぎりぎりまでちゃんと人は消化するようになっていて、遅れるときは遅れると。確率論的には5日間の期間があったら3日で終わることもあれば7日間で終わることもあるんだけれども、5日間より早く次の工程へ行くことはあり得ないので、遅れるときは遅れるしかないと。で、ガントチャートの考え方って、基本的には「平均的にはこの期間で終わっていくだろう」なんだけれども、平均にはならないので、結局必ず遅れていくと。だからクリティカルパスではなくてクリティカルチェーンで、ゴールドラットのコンセプトとしては、ボトルネックと同じ役割を果たす人がいて、この人を通過しないと終わらない、その人のプロダクティビティというか生産性でプロジェクトの生産性が決まってしまうというポイントがいくつかあるみたいで、そこだけ見ていればいいと。あとはそれほど注意深く見る必要はない。

かわのそれって、「“こいつが危ない”というところは決まっているから、コケそうなヤツをしっかり監視してろ」ということですよね。

ともじそう、そこだけ見てればいいと。

かわの本買って読むまでもないじゃないですか。何年かやっていればすぐわかる。

ともじただ、それを知識として理解していないと、どこかからマネージャが出てきて「いや、クリティカルパスだ」みたいな、いわゆるMicrosoft Prtoject的な考え方を持ち出して、「ツール導入してスケジュール管理しよう」みたいな感じになるんだろうと思うんですけど、現実はどこかの一人がボトルネックになっていて、その人をいかに有効活用していくか、その人じゃなくてもできることをいかに他の人に割り振っていくか。基本なんですけどね。

かわのなんてくだらない本なんだ!(笑)

(以上、インフォサイエンスにて)