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

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

投稿者

投稿内容

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

投稿日時: 2004-06-01 21:39

るぱんです。

意識改革まで話を飛躍させた張本人です。
ＰＬＡＮのチェック。。。大事ですよね。

顧客が「早く早く」なんですよ。
いったん立ち止まってチェックして漏れを見つけるのが一番なんですよね。。。
(-。-) ボソッ

zaxx_MD: 大ベテラン; 会議室デビュー日: 2003/04/21; 投稿数: 204; お住まい・勤務地: 千葉県柏市

投稿日時: 2004-06-02 11:27

WBSをIBM用語といっているのには訳があります。

今となっては一般的になってきましたが、
むかしむかしは
「プロジェクトのスケジュール」＝現在のWBS＋マイルストーン付きスケジュール
を指していました。

PMBOKやCMMは元々舶来品で外資系SIerがシェアを拡大するまで
それぞれの単語がそのまま使われることは少なかったのです。

ソフトウェアの開発手法は建築関係や電気工事関係に由来を持つ物が多いのですが、
私はその抽象化自体に疑問を持っています。
電気工事にウィルスや脆弱性は無いですし、コンポーネントを買ってくるというのも
ソフトウェア業界では成功していません。

じゃあ、MS-OfficeやSAPがいいかというと、全てがそれらでカバーできないほど
ITは日々変化していきます。

だから.NetやStrutsなどに藁をつかむ思いですがっているようにしか見えないです。

Planに対してPlan/Do/Check/Actionをしようかなどと思わないような
IT業界にしていく必要があるのに、SIerやイノベータは互いのパイを食い合うばかり。

XP＋JSF（対応のIDE）が救世主としてMATRIXを救うことを願います。

uk: ぬし; 会議室デビュー日: 2003/05/20; 投稿数: 1155; お住まい・勤務地: 東京都

投稿日時: 2004-06-02 14:20

引用:
zaxx_MDさんの書き込み (2004-06-01 19:21) より: 数日休んでいる間に長いスレッドになってしまっていてびっくりです。

ですね

個人的には、長文が(書くのも読むのも)苦手なので流れを追えている自信がありません。

引用:
結局WBS（IBM用語）をちゃんと作れてないのが問題の本質なのでしょうか・・・

私が思うには、「合理的な理由に基づかない見積もりを元にした計画」と「予実の管理と
遅延時のリソースの追加投入しかしない稚拙な管理手法」が問題ではないかと。
＃WBS云々は前者に関係ありますね

引用:
「「スケジュール」を立てる」ことから「プロジェクトの意識改革」にまで話が飛躍しているところも「？」なのですが・・・

モチベーションなどの人間系に話が飛ぶと広がりすぎだと思います。

引用:
立てたスケジュールを守るように動くのは大前提です。でも、色々な要素があって遅延することが多いのもこの業界の特徴です。

というか、どんな業界でも様々な要因で計画通りにはいかないものです。ソフトウェア開発
では不確定要素が大きいだけに、そのブレが大きくなるだけでしょう。それだけに管理者の
能力が求められるのですけどね。

引用:
これらを実行するのが究極のプロジェクト管理だそうです。ご存知の方も多いと思われますが、有名な方法（レベル３）です。

有名な方法? レベル3ってCMMですか? CMMはそもそもプロジェクト管理手法ではありませんが…

引用:
＃私は確か１０年前の学生時代に習った気がします、＃そうでなければ、５年前のアプリケーション管理システム構築時ですね。

学校で習うんですか。いいなあ、私は完全に独学です

Jitta: ぬし; 会議室デビュー日: 2002/07/05; 投稿数: 6267; お住まい・勤務地: 兵庫県・海手

投稿日時: 2004-06-02 15:29

引用:

はにまるさんの書き込み (2004-05-25 09:28) より:

　あなたの答えは、今年社会人になった方の為の返答です。
　あなたの答えは、基礎的な仕事の仕方を飛ばしてきた方の為の返答です。
　あなたの答えは、これから管理者、リーダを目指す若しくは成る方への基本的アドバイスです。
　あなたの答えは、小難しい管理技術論に追われ基礎的な事を忘れた方の為の返答です。

なぜ「スケジュール」を立てなきゃ、いけないのですか？

　スケジュール（ここでは"納期"の意）が決まっているから。必要なものをリストアップして、それぞれの依存関係を明確にし、期日を決めて仕上げようとしないと、納入日当日に「あれがありません、これもありません」ってなことになるから。

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

投稿日時: 2004-06-02 15:55

引用:
zaxx_MDさんの書き込み (2004-06-01 19:21) より: 結局WBS（IBM用語）をちゃんと作れてないのが問題の本質なのでしょうか・・・

そうですね。詳細の作業工程（ＷＢＳ）が全て列挙出来れば、
現状の計画問題の多くは解決出来ると思います。

ただ実際の所、詳細の作業工程を列挙する行為は「仕様」や「仕様確定の進捗状態」に
強く依存しますので、工程の列挙技術自体を考えるより、「仕様技術」の向上を起点とし、
その結果、計画がどうあれば効果的か？を考える事が自然な流れだと、今は考えています。

それまでは、過去の工程一覧を再利用、レビューが解決手段ですかね。

引用:
立てたスケジュールを守るように動くのは大前提です。

私も「倫理」上、「スケジュールを守る」意識は大切だと考えています。
「スケジュールを守る」意識が無い人には植付ける事が必要ですが、

もう１歩、現場の問題に踏み込んで考えると「スケジュールを守る」事だけに
注意した結果の問題が生まれています。

　１．前提条件が必要な為、依頼者（前工程担当者）に依存する（突っ込めば責任転換）
　２．範囲が必要な為、担当責務を守るが故に部分最適に陥ります。
　３．余裕が必要な為、チェックポイント／人の増加により余裕率が増える。

つまり、「スケジュールを守る」の意識を満たした（強制含める）タイミングで
「サービス向上」という意識に変更しなければ、
「約束を守る」意識が「自己保身」に変ってしまい非効率な状況を生む恐れがあると考えます。

これは、計画自体の話ではありませんが、
過去の私が投稿した愚痴に対する返答です。

引用:
ITプロジェクトの管理は今も進歩しています、新しい技術が都度でてくるので、完熟することは無いと思いますが、お互い、がんばりましょう。

は～い！。まとめが大変です。

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

投稿日時: 2004-06-02 16:37

引用:
Jittaさんの書き込み (2004-06-02 15:29) より: 　スケジュール（ここでは"納期"の意）が決まっているから。必要なものをリストアップして、それぞれの依存関係を明確にし、期日を決めて仕上げようとしないと、納入日当日に「あれがありません、これもありません」ってなことになるから。

余談です。

（納品前日）
　　リーダ「よっしゃ！納品一覧に対する社内検証も終わりだ。これで完璧だ。」
　　メンバ「あの～仕様書は、電子と紙の両方で提出と議事録に書いてありますが。」
　　リーダ「あ、それ今日やるんだよ、今日、印刷くらい別にね。」

（数時間後）
　　管理者「だれだ！プリンターを独占しているバカは！」

（数時間後）
　　メンバ「あの、紙を閉じるバインダーが在庫切れです。」

（数時間後）
　　メンバ「あの、Ａ４用紙が在庫切れです。」

（前日深夜）
　　リーダ「がび～ん。会社に止まる事になるとは．．．」

（おしまい）

zaxx_MD: 大ベテラン; 会議室デビュー日: 2003/04/21; 投稿数: 204; お住まい・勤務地: 千葉県柏市

投稿日時: 2004-06-02 17:33

引用:
ukさんの書き込み (2004-06-02 14:20) より: 有名な方法? レベル3ってCMMですか? CMMはそもそもプロジェクト管理手法ではありませんが…

その辺をぼかしたのはソレ系のSIerからの単純な受け売りだからです。
しかもL3じゃなくてL5だと思うんだけどなぁ・・・

zaxx_MD: 大ベテラン; 会議室デビュー日: 2003/04/21; 投稿数: 204; お住まい・勤務地: 千葉県柏市

投稿日時: 2004-06-02 17:46

引用:
はにまるさんの書き込み (2004-06-02 15:55) より: 　１．前提条件が必要な為、依頼者（前工程担当者）に依存する（突っ込めば責任転換）　２．範囲が必要な為、担当責務を守るが故に部分最適に陥ります。　３．余裕が必要な為、チェックポイント／人の増加により余裕率が増える。

ようやくスレッドのスタート地点に立てた気がするのは私だけでしょうか。
（タイトルとは違うけど）
「大人数でのシステム開発の場合に陥りやすい行程遅延について」
・人数が増えると管理オーバーヘッドが大きくなり、管理者の管理閾値を越えた時点で管理ミスが加速度的に増えます。
・多数の外注や複数の部署の人間がかかわるため、派閥争いや作業転化など本質とは無関係な問題が発生します
・開発者間のスキル差が大きくなりがちなので、コミュニケーションコストが加速度的に増えます。
・責任者/担当者が不明確な部分が増えます。
・ネゴする回数が増えることでコストが増えます。
・WBSが必要以上に細分化されるため、システム自体にオーバーヘッドが増えます。
・システムが巨大化するため、チューニングが困難になります。
・システムが巨大化するため、結合テスト用のテストデータの作成が困難になります。
・システム全体で品質がバラバラになります。

それらの問題を全てプロジェクト管理やスケジュール管理で解決しようとするのは無理だし、
人間系に頼ってもトテモとても呪われたサレコウベです。

じゃあ、どうするの？おしえて偉い人

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

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

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