なぜ「スケジュール」を立てなければ行けないの？

«前のページへ 3|4|5|6|7|8|9|10|11|12|13 次のページへ»

投稿者

投稿内容

NAL-6295: ぬし; 会議室デビュー日: 2003/01/26; 投稿数: 966; お住まい・勤務地: 東京

投稿日時: 2004-05-28 15:44

引用:
はにまるさんの書き込み (2004-05-28 13:29) より: 簡単に出来る事を「試行錯誤」とは言いません。 NAL-6295さんも、簡単に出来ない事を知っているから「試行錯誤」と仰ったのでは無いでしょうか？

NAL-6295です。

ここだけ誤解されているので答えておきます。
試行錯誤する事はその人にその気があれば、簡単に出来ることだと思います。
という事を言いたいわけです。

試行錯誤とは・・・

引用:
さまざまな試みを繰り返し失敗を重ねながら目的に近づく事。

です。

ホールインワンは無理だけど、刻んでいくことは出来るかなと・・・。

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-05-28 16:05

引用:
NAL-6295さんの書き込み (2004-05-28 15:44) より: ホールインワンは無理だけど、刻んでいくことは出来るかなと・・・。

そうですよね。
例えば既出の話ですが、もう少し具体的に話をすると。

-------------------------------------------------------------------------
２．『外部打合の結果、保留事項ばかりを持って帰る事』の問題について
-------------------------------------------------------------------------
打合アポイント（日程）の取決めは「約束の為の計画」です。

打合とは顔と顔を合わせる、互いの意志疎通を測る大切な時間であり、
スケジュールの観点から見た場合でも、互いの計画が紐付く重要なポイント
（工程）となります。つまり、「打合」自体が計画対象に十分なりうるのです。
（全てとは思いませんが、判断出来ない間は、「全て」で見た方が良いと思います）

その行為（打合せ）を如何にして効果的にするかを準備する為に
計画が必要だと思う訳です。

つまり、保留事項ばかりを持って帰る行為は、
打合せを打合せ開始前から計画的に進めておらず、
「打合開始日時」から打合せを行ってしまっているのです。

「遠足」は、家に帰るまでが遠足と同じ様に
「打合」は、打合の必要性を感じた時点から始まっているのです！
（ちょっと違う？）

この様な生きた計画が、「効率的な計画」と思っています。

結構、これやってからバッファの食潰しが減り。
計画のぶれが少なくなりました。

って具体例をどんどん、出せば通じるかな？（個人的には嫌な流れだけど）

はゆる: ぬし; 会議室デビュー日: 2004/02/16; 投稿数: 1008; お住まい・勤務地: 首都圏をウロウロと

投稿日時: 2004-05-28 16:05

引用:
はにまるさんの書き込み (2004-05-28 12:26) より:

まずは、はにまるさんの疑問（「見積り」と「スケジュール」の違い）についての回答から。
「○×タスクに△日かかる」がスケジュールなのではなく、「タスク同士の並び」がスケジュールです。
…と言えば通じるかしら？ (^^;

順を追って、私の考えをお話しましょう。
最初に申しておきますが、私はプロジェクトを仕切ったことはありません。
管理云々も学んでいません。
WBS などの単語も、このスレで知りました（笑）。
つまり、”（プロジェクトへの）一参画者” としての経験からお話をしていきます。
# 「スケジュール」に重点を置きますね。
# あ、ツッコミ歓迎です！私も勉強させてください☆

まず、プロジェクトの成り立ちから。
はじめにあるのは「お客さまの要望」です。
その要望を叶える手段として「システムの導入」が決まり、プロジェクトが立ち上がります。
（つまり、お客さまの要望を叶えることが本当の意味でのゴール。モノを納めれば OK、ではない。が、プログラマとしての範囲は決められたモノを納めるまででよい）
この段階で、予算やら期限やら大まかなシステム構成などは、だいたい決定しています。

次に、システムを導入するにあたって決めた＆決められたことをリストアップします。
主に絶対に外せないイベントを指します（＝みなさんの言う「約束」かな？）。
本稼動や試運転の開始日。検収タイミングなど。
ハードの搬入やネットワークの張り替え時期など。
それらを ”線” 上の ”印” として表現します。これが「スケジュール表」の最初の段階です。
印と印の間（やスタート位置から印までの間）が、それぞれの期限となり、線として表現されます。
そして、それを ”項目” という縦軸に分割していきます。

そして今度は、分割された ”線” の中で行わなければならないことを考えます。
現状のシステムがあれば、それの分析。設計。仕様書の作成。テスト計画の策定など。
業者や人員の手配など。
これも、先のように線に印をつけ、項目に分断していきます。
…という風に、どんどんドリルダウンした結果、「このタスクにかかる（かけられる）日数」が割り出されます。
また、タスク同士の並び（前後関係 ←”項目” 的に見れば上下関係）が重要なものなども割り出されます。
（例： DB アクセスロジックが決まらないと、画面のコーディングが完了しない）
それが、壮大な「スケジュール表」となって眼前に出てくるのです。
この「スケジュール表」には、「予定」と「計画」、「手順」が書かれています。

では、実際にこの「スケジュール表」を「使って」みましょう。
プロジェクトの進行中は、予定通りにコトが進んでいるかを「既に引かれている線とは別の線」で記述していきます。
つまり、「予定」ではなくて「実績」です。
また、それを「確認」する場所が「進捗会議」です。
そして、この「予定」と「実績」に差異が生じようとしているときが、「スケジュールを再考する」タイミングなのです。
だって、元々は 1本の ”線” だったのですから、分割された 1本に狂いが出たら、全体に影響するかもしれませんよね？
再考した結果、他のタスクに影響が出ると判断されたら、そこで初めて「どうするか？」となります。
タスク担当者の再配置（注：タスク自身を再配置すると、トンデモなコトになります）や残業要請、増員…。
それらでダメな場合に、はじめて「スケジュールの引きなおし（本番を延ばそう etc.）」となり、その結果 「スケジュール表が引きなおされ」ます。
# 前倒しできれいればいるで「空き工数を作るな！」というお達しからスケジュールが引きなおされることも…

…というのが、私の視点です。(^^;
先のポストで ”紙っぺら” と言ったのは、スケジュール表を軽視しているわけではなくて、「スケジュール」と「スケジュール表」を混同してほしくないなぁ、という思いからだったのでした。
また、その ”紙っぺら” には「予定」以外のものが含まれていないようにも感じました。
# 難しい漢字を使われても、オバチャン分かんないわ（爆）
そして、「予定」しかない（「実績」があっても「確認」をしない）プロジェクトで、成功したためしは経験上ないのでした。
# 失敗の方が多い（っつーかほとんどだ）わよ～悲しいかな（涙）。
# ちなみに、「どうせ社内だし～」となぁなぁで済んでしまう現場も、失敗にカウントされます。
# お金のあるところはいいわね（嫌味）。
かっこよくお仕事しようよ…。

ぜひ、このスレをはじめから見直してみてください。
キラリと光るものがたくさんあります。

スレ本題：
「なぜ「スケジュール」を立てなければ行けないの？」

# は～長かった～（疲）

るぱん: ぬし; 会議室デビュー日: 2003/08/01; 投稿数: 1370

投稿日時: 2004-05-28 16:17

引用:
はゆるさんの書き込み (2004-05-28 16:05) より: スレ本題：「なぜ「スケジュール」を立てなければ行けないの？」

るぱんです。

スケジュールを立てることの意味。（かなり個人的な主観）

１．漠然と大まかに計画する事で、
全体の作業量と、整合性と、連携箇所を簡易的に見抜くことが出来る。

２．計画に狂いが生じても、計画の建て直しをし易くする為の道具として活用できる。

こんな感じで捉えています。

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-05-28 16:19

引用:
はゆるさんの書き込み (2004-05-28 16:05) より: ぜひ、このスレをはじめから見直してみてください。キラリと光るものがたくさんあります。

どこに、キラリと光るものを感じましたか？
今日は御疲れでしょうから、時間が許せば、また今度御願い致します。

御願いする理由は当スレッドで多くの投稿は、計画やスケジュールでは無く、
私の考えが議論の中心になっている事が多いからです。そして起動修正の連発です。
自業自得かも知れませんが、どちらにしろ普通の視点で見る事が出来ません。

御疲れ様でした。m(_ _)m

Beatle: ぬし; 会議室デビュー日: 2003/06/09; 投稿数: 394

投稿日時: 2004-05-28 16:59

引用:
はゆるさんの書き込み (2004-05-28 16:05) より: # あ、ツッコミ歓迎です！私も勉強させてください☆

ということなので、ひとつだけ。

引用:
では、実際にこの「スケジュール表」を「使って」みましょう。

この前にレビューをしたほうがよろしいかと。
プロジェクトレビューという形になるかと思いますが、スケジュールの妥当性や
実現度、項目抜け、そして予算との兼ね合い、リスクヘッジ等、PM（サブPM）が
主催となって、品質管理関係者、営業関係者、主となるプロジェクトメンバー
（リーダー）とでレビューをしっかりとしないと、後で出来上がったスケジュール
が単なる押し着せの「約束」「目標」としてのみ捕らえられてしまいがちですね。

たぬきそば: 会議室デビュー日: 2004/05/28; 投稿数: 12; お住まい・勤務地: 世間は広いようで狭い

投稿日時: 2004-05-29 18:50

お初にお目にかかります。たぬきそばといいます。
このスレは、いろいろな意味で参考になりますね。
立場の違いや意識の違い、ふるまいについて・・・
で、この一連のスレッドを見て感じたのですが、このスレッドの本題は
　　(１)　スケジュールを作成することの意義
　　(２)　組織間をわたった文書に対しての立場による認識の違い
　　　　　(例スケジュール、進捗管理資料)
　　(３)　Sierと外注との間のプロジェクトに関してのかかわり方
のいずれでしょうか？それともはたまた・・・・・
どうもそんな気がします。

　

たぬきそば: 会議室デビュー日: 2004/05/28; 投稿数: 12; お住まい・勤務地: 世間は広いようで狭い

投稿日時: 2004-05-29 19:30

一つ前の投稿だとただのあおりに見えますんで、自分のスケジュールを立てることについての認識を書きます。私自身は、SIerとしてもその下の外注としても振舞ったことがありますが、リーダとしての立場になったのはここ1，2年の話です。(ですからマネージャの経験はないです。マネージャと一緒にそういう打ち合わせには出ますが(汗)マネージメントの交渉はあまり経験がないです)
　私のスケジュールを立てることに対する認識は
　「見せる人に対する自分の見解の表明」
です。とりあえずのスケジュール立ても、結局自分と利害が一致するひとに見せるための整理立てというのが私の認識です。だからこそ、見せる対象により内容の違うのが当然と思っています。
　「スケジュールを他人に見せ相手が納得した場合、修正は見せた人と合意しない限り成立しない」
というのが、私の認識です。なぜなら、見た人はそれを元にその人のスケジュールを立てていくので、特に利害関係のある間では納得なしには変更はありえないです。(だからこそ、スケジュールの遅れは遅れた人が説明しなければならないですし、立場から来る責任が発生します)
　この認識がありますから、リスクを考慮してないようなスケジュールを他人(お客や外注先、利害がことなる自社の他部署)に対して見せたり、他人の引いたスケジュールに合意するというのは自殺行為以外何者でもないと私は思ってます。(実際、迷惑掛けまくりましたから・・・ごめんなさい＞プロジェクトのときのまとめの立場の人(いっぱいいる)　m(＿)m )

«前のページへ 3|4|5|6|7|8|9|10|11|12|13 次のページへ»

なぜ「スケジュール」を立てなければ行けないの？

スキルアップ／キャリアアップ（JOB@IT）