ガントチャートでスケジュール管理ができない

オープン系のソフトハウスでシステムエンジニアをしています。
昨年くらいから上司の意向で、ガントチャートによるスケジュール管理を取り入れることになりました。社内のいろいろな部署のスケジュールをガントチャートに表して情報共有を図ろうという話です。

部署によってはガントチャートで綺麗に表わせるところもあるのですが、私が所属しているIT部門では、なかなか綺麗に表すことができず、困っています。

IT部門の業務は、半分が開発、残り半分が保守・サポートといった感じで、開発案件については工数から日数を算出してバーを引くことはできますが、TODOリストを横に並べただけのようなものになってしまっています。

また、トラブル対応は突発的なものなのでチャートに表すことができません。トラブル対応も1時間以内に終わる軽微なものから、1日以上かかるものまでいろいろあります。どんなトラブルが起きるか予測はできないのですが、だいたいいつもチャートに書かれているバー（TODOリスト）の半分近くは消化されずに次の週に持ち越されてしまいます。

開発案件についても締め切りは決まっていますが、毎日のように関連作業が発生したり、仕様が追加されるような状況なので、チャート通りに進めるのは無理という状況です。

突発事項をあらかじめ想定しておくと1日の予定がスカスカになってしまいます。この機能を作るのに1週間はおかしいだろう、といわれます。だからといって細かく予定を入れておいても予定通りには終わらないので、終わらせるためには家に帰れない、という状況になってしまいます。

上司はガントチャートに取り組む真剣さが足りないからだ、他の部署ではできているではないか、と一蹴するのですが、やはりきちんと見積もりできない、見積もり通りに作業できない、など、私のやり方に問題があるのではないかと思いますが、改善するには、どのような方法があるでしょうか。

No.1 ベストアンサー 回答者： lv4u 回答日時： 2008/11/01 06:22

>>また、トラブル対応は突発的なものなのでチャートに表すことができません。

そのとおりですね。ハードウエアがらみだと、ＣＥさんといっしょに障害対応していた当時は、「今夜から本格的な夏で（冬で）暑く（寒く）なるという。季節の変わり目だから、しばらくハード障害の対応が増えそうだな」なんて予想ができたものです。（季節の変わり目の障害は人間と同じですね）
でも、ソフトウエアバグや運用がらみのトラブルは、突発的でスケジュールなんてできませんからね。


要求仕様の探検学／Ｇ．Ｍ．ワインバーグの中に「保証印ゴキブリ退治器」ってのが紹介されています。

この退治器は単なる鉄の円盤２枚で、「ゴキブリを下の円盤に乗せ、もう１枚でたたき潰す。」というものです。確かに、ゴキブリが円盤の上に乗り、叩き潰されるまでじっとしていてくれれば、絶対確実にゴキブリを殺せます。
でも、その２枚の鉄製円盤が、ゴキブリ退治器として機能しないことは誰でも想像できるでしょうね。

つまりは、「ガントチャートにスケジュールをしっかりと書き上げろ！」とは、「保証印ゴキブリ退治器の一方の円盤の上に、ゴキブリを乗せ、叩かれるまでじっとさせておけ！」と命令されているということだと思います。

質問者さんの上司は、開発や保守・サポートで発生する問題の本質・仕事の本質が解っていないのだと思います。（悪く言うなら、無能？）

解決方法は、問題事象を記録・収集し、時間がかかる原因を分析して、影響の大きいものから、ひとつひとつ地道に考え、対策をしていくことかな？なんて思います。そして、その問題の要因は、会社の環境や社員のレベルによってさまざまであり、自分たちで考えるしかないように思えます。

ＣＥさんたちの例では、障害記録データベースを構築して、自分たちのトラブル解決経験の共有、新人の戦力化を計っていました。データベースがそれなりに使えるレベルになるまでは数年の時間がかかったようです。こういう地道な手法もあれば、ちょっとしたソフトウエアツールやマニュアルを用意することで解決できることもあるでしょう。「トラブルの常連顧客の仕事は断る」って方法があるかもしれません。


って、これだけだと、「あまり役にたたない回答」って思われそうで、もう少し。

プロジェクト管理ソフト（フリーウエア）で「ＴＲＡＣ］ってものがあります。以下の記事を参照してください。

http://itpro.nikkeibp.co.jp/article/COLUMN/20080 …

ソフト開発から保守に至るまで、Ｗｅｂを使ってガントチャートよりも、ずっと有効に利用できると思います。ただ、ＴＲＡＣは１つのプロジェクトをサポートするにはいいのですが、小規模・中規模の案件がいくつも発生するようなケースでは使いにくいようです。複数プロジェクトの管理を行う場合は、以下の記事で紹介されているredMineがいいかもしれません。個人的には、こちらのほうがお勧めです。

http://gihyo.jp/dev/serial/01/redmine/0001

この回答へのお礼

回答ありがとうございます。
RedMineについては部門内で検討が進められていますが、有効活用できるかどうかは、まだ不明のようです。

お礼日時：2008/11/19 16:13

No.2 回答者： don_go 回答日時： 2008/11/02 11:47

ガントチャートはスケジュールの進み具合を把握するには

便利ですが、それを使うだけでスケジュール管理ができる
と言う訳ではありません。
それと、保守・サポートのトラブル対応までスケジュール
管理に組み込もうとしておられる様ですが、発生の有無や
作業量共に全く予想できない物までスケジュールに組み込
もうとする事は、本来管理すべき開発作業のスケジュール
を狂わせてしまうので、別に分けて対応するべきだと思い
ます。
＃日毎、週毎に変わる様なスケジュールは、管理できている
＃とは言えません。

＞毎日のように関連作業が発生したり、仕様が追加される
＞ような状況なので、
処理をする必要のある作業の洗い出しや内容の検討を十分に
しないまま、見切り発車で作業をしていませんか？
今は決まっていない(決められない)事であっても、いずれは
やるべき作業として作業リストに上げられているのといない
のとでは格段の差が有ります。

仮りに1000ステップのプログラムリストがあれば、それを
入力するのにどれだけの時間がかかるでしょうか？
極論を言えば、それだけの時間があればプログラムを作る
事ができるのです。
できるだけ早めの内からコーディングにかかっておきたい
という気持ちは判らない事ではありませんが、あせる必要
は有りません。

中途半端な仕様のままで作業を行うと、作っているうちに
あれこれと不具合が出てきて、結局作りなおしといった事
になり、却って時間がかかるだけです。
＃ビルの建設途中で鉄骨のサイズが合わないとか足りないと
＃いう事になって、慌てて発注し直したり、設計をやり直し
＃たりする様な物です。

この回答へのお礼

回答どうもありがとうございます。
開発業務と保守サポート業務を分けてスケジュールを立てることが出来れば、かなりスッキリするのではないかと思いますが、現状ではすべてのメンバーが両方にかかわらなくてはならないので、なかなか難しいです。

お礼日時：2008/11/19 16:09