メニュー
合格体験記
全国ソフトハウスデータベース
□地域で探す
[北海道・東北]北海道 | 青森 | 秋田 | 岩手 | 宮城 | 山形 | 福島
[北陸・甲信越]
新潟 | 長野 | 山梨 | 富山 | 石川 | 福井
[関東]
東京 | 神奈川 | 千葉 | 埼玉 | 栃木 | 茨城 | 群馬
[東海]
愛知 | 静岡 | 岐阜 | 三重
[近畿]
大阪 | 京都 | 兵庫 | 滋賀 | 奈良 | 和歌山
[中国]
広島 | 岡山 | 島根 | 鳥取 | 山口
[四国]
愛媛 | 香川 | 徳島 | 高知
[九州・沖縄]
福岡 | 佐賀 | 長崎 | 熊本 | 大分 | 宮崎 | 鹿児島| 沖縄
バックナンバー
Movable Type Publishing Platform 4.01
プロジェクト管理
納期に間に合わない場合にする方法 その4
さて、この同じテーマで書き続けて4回目となりました。
大きなプロジェクトであればあるほど、納期に間に合わない、
スケジュールが遅れてしまうという事態は常にあるように思います。
それは、小さな遅れの積み重ねである場合もありますし、
緊急課題が突発的に生じての遅れである場合もあります。
自社でなんとか出来る場合もありますし、こちらがどうやったとしても、
他の開発会社や顧客側の問題である場合もあります。
ただ、遅れてしまった様々なシステム開発を振り返ってみると、
「遅れます」という報告が顧客側にあがるのには、
思ったよりも時間がかかっているようです。
その原因としては、開発当初からの「納期厳守」「絶対条件」といった言葉だけが、
営業や開発サイドの隅々にまで行き渡っているからという理由もあるでしょう。
(納期厳守という言葉の裏には、品質は良くて当たり前、という前提があるのですが・・・)
また、技術者特有の性格として、
「頑張ればなんとかなるかもしれない」
と思ってしまう人が多い、ということもあるのでしょう。
こういうことを言うのは心苦しいのですが、システム開発というプロジェクトで、
「絶対に遅れない」という前提条件はないのです。
つまり遅れるリスクは、常にある。
むしろ遅れるほうが多い、と言っても過言ではありません。
スケジュールをきちんと引く。
ある時点で遅れをチェックすると決める。
そして遅れた場合には、どうするのかも最初に決めておく。
つまり遅れた場合を予測しておく。
そういった当たり前のリスクに対処するルール作りが、あってしかるべきだと思うのです。
それが、ひいては、開発側だけでなく、顧客の会社の面子を守ることになるのだと信じます。
しかし、SEという人種は、一生懸命真面目に働く、システム設計にはとことん頭をつかうけれども、
どちらかといえば、顧客の会社の事情や思惑といったものには疎い、
関心が薄いといった性質があるのです。
遅れるとわかったときに、「報告して謝る。対処方法を顧客も含めて考える」
という選択を考えもせずに、出来ると信じ込み、
とにかく精一杯頑張ることに没頭してしまうことがあるのです。
そしてシステムテストや運用テストといった、顧客に見せるときになって初めて、
遅れていたということが分ったりします。
大問題です。
では、これを防ぐのには、現在の経過を報告させる会議を(定例会と称して週に一度行います)
持つだけで大丈夫なのでしょうか?
例えば、開発会社でいえば、1チーム5人から7人のプログラマで毎日、
開発の会議を持っているとします。
各プログラマが、現在は何をやっていて、スケジュールと比べてどうなっているかを
報告するとします。
こういうときに「遅れています」と言わない人がいるのです。
その人は、嘘をついているわけではありません。
実は本人は遅れていると分っていないのです。
自分がやるべきことは「終わった」と信じて、次の作業に入っているのです。
ところが他人がみれば、終わっていないことがあるのです。
彼が終わった作業について、直ぐさま誰か他人がチェックしているのであれば、
この仕事が終わったのかどうかは分るのですが、
スケジュールの組み方でそれが出来ないことがあるのです。
そして1ヶ月以上も前の仕事が終わったと報告を受け、信じていたが、
実は70%しか作りこんでいなかったという衝撃の事実がわかったりするのです。
これはコミュニケーションの問題だけでも、仕事の手順の問題だけでもないのです。
実際に、プログラマ個人個人だけでなく、会社対会社でもありうる話なのです。
こういったリスクに備えるためには、なるべく早く、
小刻みに他人なり他社がチェックするしかないのです。
ほったらかしにして作業に専念させない・・・これだけです。
それでは顧客・営業・開発会社といったすべてのプロジェクト関係者によって、
会議の報告だけではなく、途中経過を確認するといった作業を行えばよいのでしょうか。
実際に、これは、ドキュメントの山を提出されることよりも有効でしょう。
顧客は、開発側をスポットで訪問したほうがいいでしょう。
そして現状、どこをどうやって開発しているのか、
スケジュールの中間時点で確認すべきなのでしょう。
素人が途中で見てもわからない。
全部出来上がってから見たほうがいい。
本当にそうでしょうか。
今回は、納期に間に合わない場合にする方法ではなくなってしまいました。
納期に間に合わないことを、なるべく早く察知する方法となりました。
PMやPLには常に「部下の報告をそのまま伝えるな」と言い続けています。
5分でも時間をとって仕事内容をチェックすることが、大きな見逃しを防ぐのです。
それは、ほんのちょっとの手間のはずです。
会社対会社といった関係で、「会議」「検査」といった名目をつけずに行うことができれば、
大事に至る前に現状チェックすることができれば、それが一番望ましいと思うのです。
トラックバック(0)
このブログ記事に対するトラックバックURL: http://www.softhouse-senmon.com/mt/mt-tb.cgi/24
制作・運営会社:
株式会社アイロベックス
〒160-0022
東京都新宿区新宿5-17-5
ラウンドクロス新宿5丁目3F
TEL : 03-3232-2525
FAX : 03-3232-2520
お問い合わせ
個人情報保護方針について