＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
なぜ「スケジュール」を立てなければ行けないの？
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-05-27 09:11
るぱんです。
プロジェクトの成功すら手段のような気がしてきました。 プロジェクトを成功させる事によって、 「顧客に利益をもたらす」事が目的なのではないかと・・・。 顧客に利益をもたらすから商売できる・・・？ | ||||||||||||||||||||||||
|
投稿日時: 2004-05-27 12:51
これは、私から再度、NAL-6295さんへ返答させて頂いてからが宜しいかと思います。
再考しました。どうすれば良くなるかは、今でも解りません。 ただ、仰る通り「思考停止」で手段の模索を行っていませんでした。 当時の私がやるべき事は、メンバー（リーダ）の間違いを指摘する事では無く、 なぜ、それをするのか理由を確認して、最適な代案を提示すべきでした。 言わば、「要件定義をせずにシステム開発をし、顧客の要求が変だ！」と 言っているのと同レベルな訳です。 自分の事を能動的だと思っていましたが、 個別で見ると受身になっている箇所もありますね。要注意です。 で、まりりさんの質問に戻ります。 管理がしっかりされ、「計画」や「スケジュール」の目的意識合わせをしている 組織では、問題無いと思います、しかし私の経験（または他ＰＲＪを見て）上では １．実現場にて「計画」という言葉はあまり利用されず、「スケジュール」や「見積」と言う 言葉が頻繁に利用される。 それは「計画」の認識が薄いからと思います。認識薄ければ、能力は低い筈です。 ２．外部打合の結果、保留事項ばかりを持って帰る人が多い。 つまり「スケジュール」を応用して、打合せ行為に「計画技法」を用いて無いからと思います。 ３．開発工程にて平行稼動から本番初回起動までの計画がずさん。 ４．複数チームが依存するスケジュールにて、全体のクリティカル・チェーンが 提示された事が無い。 プロジェクトマネージメントの本で乗っている、ＷＢＳ一覧表、パート図、ガントチャート図を 作成すれば、「理由」は後付けでも、ある程度の効果を持ちます。 しかし、その一部の効果により、「計画」や「スケジュール」の重要性を 見失っており、その現象が上記４つと思うのです。 質問自体の「計画の定義」は説明出来る程、思考していないので辛いですが、 副題として、 管理者以外に取って効果的な「スケジュール技法」、「計画技法」の基本を 教えて下さい。また技法を効果的にし、継続的に身に付けるべく考え方も教えて下さい。 で如何でしょうか？ もしかすると、「計画の定義」が現場で認識合わせされていない事が 根本の問題かもしれませんね。 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-05-27 12:54 ] | ||||||||||||||||||||||||
|
投稿日時: 2004-05-27 13:56
計画の定義？ それをぼかして受注している組織体制そのものが問題なのではないかと考えてしまいました。 目的が何か・・・と言うより、目的の目的たる理由・・・じゃないでしょうか？ 本当にメリットあるの・・・？ってな所です。 それがわかりやすい仕様書があれば技術者はそんなに必要ないとも言えるわけですが・・・。 「ベンダーが出来そうな事は全部やらせる」って言う人を営業が見抜けないことに 根本があるような・・・。 だから、ＳＯＡとかって概念が台頭する・・・？ | ||||||||||||||||||||||||
|
投稿日時: 2004-05-27 15:34
最近の話で行きます。 １．打合の事前通達。 これは教えて貰ってから、打合の開催主になった場合に実施しています。 打合目的、出欠確認、出席者の事前確認事項等を通達します。 あと「事前通達」を書く事で、打合せまでにやるべき事も リストアップ出来ます。 これで意味のない打合せは、減りました。 ２．依頼を受けた時の日数見積。 ＰＧの「スケジュール」と一緒で、約束的な意味合いが強いですが、 私の場合、「スケジュールの前提条件」と「約束を守れない懸念事項」 を列挙する事が結構重要です。 この「前提条件」は、社内用と社外用に別ける事もあります。 「約束が守れない懸念事項」を早めに潰しに掛る時に利用します。 ３．作業前の作業計画（ＷＢＳ一覧作成） 工程（ＷＢＳ）の洗い出しです。開発工程自体の洗出しは苦労しませんが、 良く環境整備回りの工程に漏れがあります。 
「リソース依頼」の元ネタとNo４とNo５の生成元ネタです。 下記のNo４とNo５は物件毎に書きなおしていますが、 これは、リサイクルしています。 ４．作業前の作業手順書（なんちゃってＰＡＲＴ図作成） これは最近作り始めました。工程の前後関係を記述しています。 ・矢印が工程間の完全依存の関係 ・効率的なスケジュールが組めそうな工程群は丸で囲み ・顧客、別チーム、外部委託チームとの関連ポイントは、色づけしています。 これが今の私にとって「本当のスケジュール計画書」です。 ５．作業前の日程予定表（ガントチャート図） 荒目の日程予定表です。 「列」に相当する期間を、１週間単位。 「行」に相当する工程も、重要度が低ければグロス表記しています。 重要日程（納期等）は、表内に日付を記述しています。 進捗状態の認識で利用しています。 ６．特定作業の作業手順書 ここに記述していますが、１回しか作成した事がありません。 「初回の開発環境作成」、「平行稼動準備」、「本番切替」などの手順が ごちゃごちゃし易い工程の計画書です。 以前、稼動中アプリケーションの変更業務で作成して 効果があったので、機会があれば他でもやって見様と思いますが．．． ただ、初回の開発環境作成、平行稼動準備、本番切替どれも、 忙しい時期だからな．．． [追記] ７．テスト前の環境スケジュール テスト環境とテストスケジュール（チーム）の関連図を書きます。 昔、テスト環境の空待でプロジェクトがストップした事がある。 今、Ｏｒａｃｌｅの様に環境別で個別のフォルダーを 持たせる構成にすればテスト環境に困ら無い事にやっと気付いた。（遅い） [ メッセージ編集済み 編集者: はにまる 編集日時 2004-05-27 15:51 ] | ||||||||||||||||||||||||
|
投稿日時: 2004-05-27 16:21
疑問形ばかりで答えてますが、問題点を整理できるといいなと期待しています。
そのスケジュールや見積もりには何が記載されていますか？ （資料になっていないのなら何が含まれているものとして会話されていますか？） 納期だけ？フェーズの終了日だけ？作業工数の見積もり？ 根拠のないできるできないの判断はだれも信用しません。 だから、根拠が欲しいという意味でスケジュールを要求します。 はにまるさんは、そのスケジュールには何が載っていて欲しいですか？
ここだけ読むと計画がどうとかあんまり関係ない気がしてきます。 保留事項に対していつまでに回答を出して、いつまでに解決するかの管理が出来ていないのですよね？ それをもって「計画技法」が用いられていない、とおっしゃってますか？ おそらく問題は技法の話ではなく、両者のタスク管理についての前提が 甘いのだと思われます。 この点は計画ではなく、プロジェクトを運用するための技法です。
平行稼動は試行期間のように捉えたらよいでしょうか？ この点は移行におけるタスクが整理できてないという意味ですよね。 計画一般の話ではなく。 ずさんであるのは、タスクの洗い出しが不十分であるせいではないかと。 あるいは、タスクに対する責任の所在が不明確であるか。
クリティカル・チェーンが提示されないから失敗するのでしょうか？
とりあえずはっきりしているのは、スケジュール（計画）は守るつもりで 作って周知徹底しないと無意味です。 （そこをはにまるさんは疑問視しているのですよね？） 守るつもりがなく作られたスケジュールは無理があるかタスクが漏れているか なので、どこかで破綻をきたします。 なんとなく計画をアウトプットにするということが、タスク（WBS）の洗い出しを 含んでいないように見えるのが気になりますが・・・
ということで、私が新人のころから心がけているのは
くらいです。 プロジェクト管理ツールの使い方や、ダイアグラムの描き方はさまざまでしょうが ベースは上で書いたことのはず。 個人的には上記がはっきりわかれば自分で使う計画表になると思ってます。 | ||||||||||||||||||||||||
|
投稿日時: 2004-05-27 16:51
ん〜と、スケジュールってのも荒→詳までいろいろあって、マスタースケジュールや
工程表、作業予定表等いろいろありますね。 ただ、作成する目的というのは、 １．見積りまたは交渉時の資料 ２．進捗の確認、管理 ３．教育 ４．共有実績資産 というぐらいでしょうか。 確かに、「本当にスケジュールが必要か？」と言われると、必要ない物や場合があると 思います。 例えば、熟練者１人で１年くらいかかって作成するようなものですと、自分の頭でマイル ストンぐらいがあれば、あとは顧客との打合せ用に、荒い物があれば十分だと思います。 が、そんな仕事ってめったに無いわけで．．． １．見積りまたは交渉時の資料 まずこれは、開発開始する際の折衝時のスケジュールですから、できる、できない とかが盛り込まれている。また、仕様変更や遅れの際の「こうなります」「こうさ せてください」というような説得用の物です。俗に言うマスタースケジュール。 ２．進捗の確認、管理 これが、もっとも良く見ているスケジュールで、工程の計画や作業計画もすべて含 まれます。実績も記入され、進捗状況がわかるものです。 と、ここでうまくONスケジュールで進んでいれば、単なる管理者の満足度を上げる だけのものですが、なんらかの理由で遅れやリスケジュール等が発生する事があり ます。（よくある。）例えば、PG個人の遅れというものは作業計画というような 一番詳細のスケジュールに現れます。がそれによって全体がどのように影響を受け るのかというところを見極める必要がありますね。その際により広域なスケジュー ルのほうに影響度を反映し、一番ポイントとなるのはマイルストンのポイントの 変更があるかどうかを見極める事になるわけです。 バッファとか別途追加要員を考える際にもここがベースになるので、リスクマネー ジメントの意味も含みます。 ３．教育 これが、「１年目の社員にスケジュールを立てろとは．．．」に対するもので、 実際に１年目の社員が立てたスケジュールをそのまま実行することはあまりない でしょうが、私はよくメンバーにスケジュールを立てるように言います。 その目的というのは、いろいろドキュメントや口頭で説明しても本当に理解でき ているのかどうかというのは、立てたスケジュールにわりと顕著に表れます。 指示した人が想定しているスケジュールとあまりにもかけ離れたものを作った場合、 何か忘れていたり、変な手法で作成しようとしていることがよくありますね。 そんな場合には、どういう風に作ろうと思っているのか、現段階でレビューしたり すればすぐわかります。（もちろん指示するほうが全くわからん言語やシステムの 場合、これはできませんが） ４．共有実績資産 これは、あんまりできているとは思えないのですが、最後まで終わったプロジェク トのスケジュールというかその予実というものが、次回とか別プロジェクトの見積 やスケジュール作成の「過去の実例」という意味で、精度を上げる為の材料になっ たりもするんですが、なかなかね．．． という風に思います。２．の中でどこまで詳細のスケジュールで管理するかということ であれば、ケースバイケースでしょうし、目的も同じようなものなので会社やプロジェ クトまたはメンバーのスキルなんかで変わるんではないでしょうか。 | ||||||||||||||||||||||||
|
投稿日時: 2004-05-27 17:15
これだけのことをしたくないという感じなんでしょうか？ 項目だけ見たら（6,7はいらないかもしれませんが）プロジェクトを運営するにはどれも必要ですよね。 となると「なんで作らなきゃいけないの？」ってのは規模に見合わないからでしょうかね？ 個人の1週間の予定を毎度毎度作るのはさすがにオーバーヘッドが大きそうですが、1ヶ月くらいのものであれば妥当ではないかと思います。 | ||||||||||||||||||||||||
|
投稿日時: 2004-05-27 17:20
計画はなんのためにするのか、ということですが、
プロジェクトにはゴールと期間が必ずあり、通常は使用可能な予算とリソースが決められています。 計画は、決められた期間内に決められた予算とリソースでゴールを達成するために行うものです。 計画もせずに「できます」というのは、そもそもゴールそのものが計画を立てなくてもよいほど 小さいか、単なる空手形に過ぎません。 また、計画がなければプロジェクトの管理ができません。つまり、進行中のプロジェクトがうまく いっているのかどうか、このまま進めていって期間内にゴールを達成できるのかどうかを判断する ことができません。であれば、対策を取ることもできないということです。 はにまるさんがおっしゃっている「計画」とはズレているかもしれませんが、どうでしょうか。 | ||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.