＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
なぜ「スケジュール」を立てなければ行けないの？
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-05-29 19:38
1.対外的な面 製造のスケジュールが決まらないことには使用者が導入・運用のスケジュールが立てられません。 2.社内組織面 １人が作業できる量は決まっています。過不足なく仕事の割振りを行うにはプロジェクトの実行スケジュールが必要です。 3.プロジェクト内 PLAN->DO->CHECK->ACTION(->PLAN...) 計画(PLAN)は実行(DO)にとって目標です。 計画(PLAN)は確認(CHECK)にとって基準です。 計画(PLAN)は必要あらば見直し(ACTION)されることがあります。 ※「CHECK結果でだされるACTIONは "メンバーに気合を入れる" しかないのでやってられません」等の愚痴系を出すとまとまりませんよ。 | ||||||||||||||||
|
投稿日時: 2004-05-31 09:58
脱スレです。
当スレッドとは直接関係ありませんが、当スレッドの性質上から 投稿した方が良いと思い、記述します。 【注意】 下記に記述する事は私が立場的に気付き易く、先に気付いた為、 知識共有として御知らせする物です。 勿論、私自身も過去に何度もやっています。個人宛てで無い事に注意して下さい。 １．議論中の愚痴に対して。 愚痴（ポイも含め）は、読み手にとって気分を損ね、下手すれば意味自体を 逸らす行為ではあります。 ただ、前向きに進む者にとって阻害条件を説明する時は愚痴っぽくなる事は 十二分にあります。この際に危険な行為は、書き手の技量不足により 愚痴っぽくなった説明を「愚痴」と捉えて反論する事です。 （愚痴と思い切捨てる事は、良いと思う） 「愚痴」に聞こえる事を「阻害条件」として捉え、その理由説明、回避策、対応策等 を伝えれば宜しいですが、 そうで無い場合、話の親展は、阻害条件を目の当たりした「前向きに進む者」に 委ねる状態になります。 もし委ねた場合、阻害条件を実体験した状況から、その人が余程の優秀な人で無い限り、 愚痴と捉えた反論は、「状況説明を理解しない人の発言」と捉えてしまいます。 これは下っ端の時、誰もが経験している事なので過去を振り返れば理解して頂けると思います。 ２．前提条件の違いによる勘違い ＡさんとＢさんが前提条件を認識し合わ無い状態で議論をし、 意見の食い違いが発生した場合、「勘違い」はＡさんとＢさん両方にあります。 例えば、Ｂさんのみが勘違いしている場合、Ａさんはそれを指摘出来るはずです。 Ａさんが前提条件の違いに気付き指摘した場合でも、それはＡさんＢさん共に 勘違いしていたのであって、Ｂさんだけが勘違いしていた状態では無いのです。 だから、前提条件の違いを悟った場合に両者共に「相手の勘違い」と思う事は 前提条件の勘違いより、大きな勘違いと思います。 ３．相手の間違いを指摘する行為について。 「相手の間違いを指摘する行為」は素晴らしい事と考えています。 これは指摘する行為は自分への見返りが少なく、下手すれば厄介者と認識されるからです。 ただ、「相手の間違いを指摘する行為」は１つの問題を含みます。 それは、指摘する人が勘違いしている時です。 この状態では、互いに訳のわかんない変な人と写るでしょう。 これを回避する１つの手段として、間違いを具体的に指摘する事です。 抽象的に指摘すると間違いは「対人」になり「対理論」になりません。 それでは、話の親展が無いと思います。 ４．詰める行為は、「人」でなく「論理／文書」へ No３との関連性が強い話です。 「詰」とは悪い言葉で、解り易く言えば、「追込む」事です。 例えば、Ａさんが、Ｂ、Ｃ、Ｄの理由からＥという結論の文書を投稿し、 それを読んだＦさんが「理由Ｂ」が変だったと思い反論の投稿をします。 この時に起こり易い問題は、反論のターゲットが、 理由Ｂのみなっていない事です。 その為、Ａさんはその対処として、理由ＢＣＤを包括的に反論に 対する反論材料としてしまいます。 これでは、議論は有益な物とはなりません。 以上が気付いた事です。ただ、解ったとは言え直ぐに出来ない事と思います。 私は、今から直すとは約束できません。 
議論スレッドには「その様な性質が存在する物だよ」という事を一人一人が 頭の片隅でもいれておけば、今までに比べちょっとは有益な議論が 出来るかもしれませんね。 【編集】 理解し難いところがあったので、修正した。 【編集】 漢字間違い、命令文を修正した。 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-05-31 16:41 ] | ||||||||||||||||
|
投稿日時: 2004-05-31 10:30
そうですね、、、「はたまた」です。  （欲張りでごめんなさい）
「（１）スケジュールを作成することの意義」を列挙して、 スケジュールの性質、目的を考える。その性質の一つの問題として、 「(２) 組織間をわたった文書に対しての立場による認識の違い」と 「(３) Sierと外注との間のプロジェクトに関してのかかわり方」を 考えて、どうしたら良いのかという、 「おいおい、そんな広大な話を会議室でするなよ！」と多数の意見を 頂く事が解り切っている事を望んでいます。 なので、一旦、中間まとめとして、 「（１）スケジュールを作成することの意義」の視点でマトメ投稿を 考えています．．． 何時になるか不明．．．
| ||||||||||||||||
|
投稿日時: 2004-05-31 14:27
こんにちは。
じゃあ、はにまる さんがまとめやすくなることを祈って、オバチャンの 勘違い を書いておきましょう。 # ツッコミも歓迎です☆ (1) 依頼者と開発者の間で 「計画」 の意味が 「目標」 から 「約束」 に変わるタイミング A さん： 「（スケジュール表を出して）こんなカンジで行きますので」 B さん： 「（スケジュール表を見て）分かりました、よろしくお願いします」 …このとき、A さんは 「カンジ」 を強調したいのでしょうが、B さんは 「行きます」 と捉えます。 また、B さんが見ているのは、スケジュール表のほんの一部分です。 そこが守られない（守られなくなりそうだ）と 「約束が違う！」 と怒ります。 （そこが ”マイルストーン” なのでしょう） さて、タイミングって、いつなんでしょうね？（よい発言が既にいくつも出ていますよ） (2) 打ち合わせで保留事項ばかり持ってきたり、開発者が仕様を気にすることについて これは 「スケジュール」 の中の 「タスク管理」 にあたると思います。 ”風が吹けば桶屋が儲かる” と一緒で、途中のタスクが達せられないと、次のタスクが完了できません。 （これが ”クリティカルパス” なのでしょう） 「スケジュールの遅れ」 という目に見える形で跳ね返ってくるので、「スケジュールが悪い」 とすぐに 思いがちですが、原因は 「タスクが完了していない（タスクの役割（責任）が不明瞭/完了したかの判断がない、など）」 ことにあります。（これも先によい発言がいくつも出ています） つまり、その点を誰も分かっていない（分かっているのに何もしない）のが原因です。 進捗 会議で 責任 の擦り合いに何時間もかけているようなプロジェクトは、生産性が上がることは ありません。 (3) 作業工程が漏れることについて これには (1),(2) のような例はありません。 漏れているのですから、漏れているのです。 ただ、プログラマの視点から、どういうモノが漏れるのかは例を出せます。 ・ 打ち合わせやレビューの 準備 （仕様書の査読なども含む） ・ プログラムテスト（プログラマがやらなければならない場合） （テスト仕様書やデータ、テスト結果レポートの作成/レビュー等も含む） ・ 本番（テスト）データの作成/登録 ・ ユーザ教育（資料作成/レクチャーなど） ・ ハードのセッティング（インストールなど） …ザッと思いついただけでも、このくらいあります。 これらは、いずれも時間のかかるものばかりです。 考慮されない場合は、「残業（や休出）」 という形で跳ね返ってきます。 （「打ち合わせは 1時間だから、7時間はコーディングできる」 と考えてはいけません） つまり、「出費」 です。 (4) どうして 「見積り」 と 「スケジュール」 が別なのか 先のポストで、私の視点についてはご説明しました。 しかし、現実ではそんなきれいにスケジュール表が出てくることは稀です。 また、そのスケジュール表どおりに遂行できるかといえば、必ずしもそうではありません。 だからこそ 「このタスクは○日には完了しますので、その場合は次に着手してもいいですか？」 「あと×日は必要です。こちらやそちらのタスクも同様だと思われます」 と私は声をかけます。 「この打ち合わせで△△が決まらなかったから、これとこれに影響が出るな…」 とマネージャはスケジュールを再考します。 それが 「プロジェクトを管理する」 ということであり、「プロジェクトに参画（協力）する」 という ことだと思うのです。 （予定や実績の ”線” が延びていくのをただ眺めているのか、そうじゃないのかは見極めてください。 でないと、”本当にがんばっている” マネージャやリーダが不憫です） …さて、「なぜ「スケジュール」を立てなければ行けないの？」 でしょう？ Beatle さんへ＞ ひとつ気がつくことができました。 「表現されたものは、すべてチェックを受けるべき」 仕様書しかり（いっぱいあるなぁ…）、プログラムしかり、スケジュール表しかり。etc. ありがとうございました。m(_ _)m ラフィン さんへ＞ でも多いんですよね、「残業で何とかなるだろ（体力勝負）」 な現場（苦笑）。 生産性はどんどん落ちていくんですけど…（疲労が溜まれば頭も回らなくなるでしょう） | ||||||||||||||||
|
投稿日時: 2004-05-31 14:39
いや、私の周りでも多いですよ（笑） プロジェクトの成功と採算面のウエイトを見誤っているというか．．． 採算重視しすぎというか．．． 「愚痴云々」は、社会人１年目向けの基本という前提もありますしそこらは一旦おいといて一旦まとめに入った方がいいですよ、くらいの意味合いです。 本当は愚痴っぽいところに問題の多くはあるんでしょうけど。 | ||||||||||||||||
|
投稿日時: 2004-05-31 16:32
では、オジチャンの 勘違い を返答します。 (1) 依頼者と開発者の間で 「計画」 の意味が 「目標」 から 「約束」 に変わるタイミング 多分はゆるさんのは、１つのプロジェクトにて「計画書」が「契約書」に変る瞬間を 言われているのかな？と思いました。 元の意味は、一人が複数のプロジェクトを経験するに辺り、最初の内は 「目標」（見積の経験）で済んでいたのが、経験を積む毎に何時の間にか 「約束」に変っていて、「約束」の仕方を知らずに「約束」してしまう。 または、「目標」（見積の仕方）の技法と「約束」（問題点の洗出し方）の技法を 混同してしまう問題です。 （あ！これは、ゆるさんの「見積とスケジュールの違い」の意見と一緒ですね。 ）
多分、はゆるさんの意見であろう質問を、他者の言葉をお借りして返答すると そのタイミングとは「レビュー」行為ですね。 愚痴交じりで一つ付け加えると、レビューを進んで行う組織は宜しいですが、 自ら「レビュー」依頼をしなければ行けない状態では、相手が乗り気で無いと レビュー効果が半減するので、その際のポイントとしては、、 「相手と作業がリンクする工程（打合、検証など）」、 「状態／工程の切替（システム開発工程の変わり目）」を集中的且つ具体的に 話すと良いと考えました。 (2) 打ち合わせで保留事項ばかり持ってきたり、開発者が仕様を気にすることについて これは、おっしゃる通り相手の進捗送れもありますね。 元の意味は、相手の工程作業が物理的（成果物が存在するが）に終わっているが、 次工程担当者として受け入れ難い状態と（これがタスク判断の事か．．） 相手に依存し、受身状態で「打合」に挑んだら、成果が無かったという問題です。 タスクの完了判断についての良い発言は思いつきませんでしたが、 まとめ時に気付くと思います。気付かなかったら、再質問致します。
ただ、タスクの完了判断は次工程責任者が承認する事が自然な流れだなと考えました。 # 設計仕様を元に開発依頼した時点で設計完了としていた．．． # プログラムを納品して開発完了と認識していたのと一緒だ．．． って事は、仮完了（工程担当者から見た完了）と実完了（次工程担当者の検証）が ある事を認識しないといけないですね。 (3) 作業工程が漏れることについて おっしゃる通りです。泣けて来ます。 工程一覧表を再利用する事で工程自体の漏れは激減しましたが、 工程を分割した詳細工程はまだ、漏れが多いです。 ただ、詳細工程はパターンが多すぎるのが悩みの種で、実際には 仕様から洗い出した方が早いので別途考慮が必要な様です。 (4) どうして 「見積り」 と 「スケジュール」 が別なのか お伝えする事を忘れていました。失礼しました。 「見積り」 と 「スケジュール」 は言葉の定義の違いであると判断しました。 はゆるさんの仰る 「スケジュール」 とは工程一覧とその関連図なのですね。 私は、それに対し期日情報（個別見積）をつけた「ガントチャート図」（全体見積）を 想定していました。
失礼しました。マトメ頑張ります。 
# 過去のなぜ、なぜシリーズに比べ相当大変そう。 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-05-31 16:45 ] | ||||||||||||||||
|
投稿日時: 2004-05-31 16:50
るぱんです。
約束にしたい人：「約束にしていいですか？」と聞く 目標にしたい人：懸念点を伝えた上で「以上の理由で目標段階と考えますが、この後いかが致しましょう？」と聞く。
何故保留事項になったかが明確でないので、細かい事が好きな技術者は非常に気になるでしょう。 「○○（役職・人名）の責任を持って保留になっています。」と伝えていく事が必要ではないでしょうか？
調べてないからですよね？ 調べましょう？洗いなおしたら終りと思いますが？ 必要であればフロントのＳＥにお客を説得してもらう必要があるのではないでしょうか？ それを敢えてしないと言うのであれば、技術者は免責になって終りじゃないですか？ 技術者が上位工程から指示を受けた内容を仕事しつづければ良いんではないですか？ 末端の一技術者が「判断」するのって原則的にＮＧですよね？
「時間軸」と「金額軸」と言う主軸の違いであってますか？ | ||||||||||||||||
|
投稿日時: 2004-05-31 18:05
(1) 依頼者と開発者の間で 「計画」 の意味が 「目標」 から 「約束」 に変わるタイミング プログラマの視点で、 「○日に××の詳細設計が出ます（線がそこで終わっている）」 とスケジュール表にあれば、それが 「約束」 です。 また、 「この機能のコーディングは○日から×日までです」 とスケジュール表に線を引けば、それが 「約束」 です。 ですが、その通りにいかない場合が多いです。だから 「修正」 されます。 出ない（できない）ものは、出ない（できない）のです。 そして、B さんに影響がなければ、B さんからは怒られません。 つまり、「約束」 が守られていると見做されています。 (2) 打ち合わせで保留事項ばかり持ってきたり、開発者が仕様を気にすることについて 「タスクの役割認識や完了判断の甘さ」 と 「スケジュール」 は、影響を受けますが土俵が違うと 思うのです。 (3) 作業工程が漏れることについて 「タスクの洗い出しの甘さ」 と 「スケジュール」 は、影響を受けますが土俵が違うと思うのです。 (4) どうして 「見積り」 と 「スケジュール」 が別なのか 「逆算か積み上げかの違い」 との指摘がありましたよね。 分割された ”線” にも、期日情報はあるでしょう。 # 「時は金なり」 と言いますよね。 
(5) おまけ 私は スレタイについてのハッキリとしたレスはしていません。 それは、同じような（というか、もっとすばらしい）意見が既に出ているのと、これだけいっぱい レスしちゃうと、私の意見が鵜呑みにされてしまいそうだからです（苦笑）。 ”紙っぺら” と言ったのは 「why じゃなくて how を話し合いたいの？」 という意味も含んでいます。 そこには 「なぜ？」 の思考がありません（そこを心配してるだけです）。 のらりくらりとチャチャを入れているわけではなく、鼻っ柱に人差し指を突きつけているのです。 「じゃあ、スケジュールを立てなかったら、どうなるんでしょうね？」 # 喧嘩腰なつもりではありませんよ。(^^; [ メッセージ編集済み 編集者: はゆる 編集日時 2004-06-01 02:31 ] | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.