@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

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

投稿者投稿内容
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-05-25 09:28
はにまるです。

なぜ?なぜ?シリーズ第3段(管理版)です。
今回は、「スケジュール(計画)」

これまた、基本的な話ですので、どなたでも、個人的見解を述べれると思います。
1,2年目でも「スケジュールを引け」と言われていますよね?
理由は何と伺いましたか?貴方はどう思いましたか?
また、3年目以降の方々も後輩に何度も
「スケジュールを引け」「スケジュールを引け」と言っていませんか?

完璧な返答は要りまん。

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

では、教えてください。
なぜ「スケジュール」を立てなきゃ、いけないのですか?

【当スレッドでの注意事項】
各工程やポジションで意味合いや求められる説明が大きく異なると思います。
簡単で結構ですので背景の補足説明御願い致します。

 例:1年目PGです。それ言われて辛いです。
 例:僕は、開発工程のリーダですが...
 例:情シスとの打合せにて、
 例:実は私、神様ですが意見述べて宜しいですか?..

追記:
 開発プロセスの観点から、IT Architectコーナーにしました。
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-05-25 09:37
管理系スレッドで、あれこれ偉そうな事を言っているのに
管理能力が無い事を暴露しちゃいます。

私は、業務系SEで偶にリーダらしき事やっています。

正直な話し、半分本音で「何故?」と伺っています。
それは、新入社員時代から振りかえれば、
詳細な計画管理の労力に対する効果がトントンである事。
求められているから規定の計画書を提出している実状があります。

私の場合、直感的な計画管理の方が費用対効果は各段に高いです。
予定と結果の情報をリサイクルすれば詳細計画の意味があるでしょうが、
派遣をしている為、リサイクルした結果の情報は、次の派遣先で、ほぼ利用出来ません。
また、リサイクル行為を組織的に行っている企業はありませんでした。

ただ、「設計手法」を「計画」に持ち込んでから話しは大きく変りました。
言わば、計画書の形式的な技術では無く、計画を立てるプロセスの変更です。

現状をイン、計画をプロセス、プロジェクトの最終納品物をアウトとして、
要件定義の手法で納品物を定め、各種設計手段でプロセスを決めるのです。
簡単に話せば「計画設計書」を記述してから作業工程の漏れが発見出来る様になりました。

正直、この手段を身に付けて、今まで言われ、書籍に記述されていた
計画云々とは何だったのだろう?と思い始めました。

勿論、現段階で完璧ではありませんが、ただ一般に言われる計画技法に
何とも言い難い疑問を持ち始めました。

上級レベルの方は、「詳細計画の効果性」で御話をして頂ければ
宜しいかと思います。

では、雑感レベルで結構ですので、ご返答御待ちしております。 m(_ _)mぺこり
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2004-05-25 09:45
るぱんです。

だいたい、開発チームのの裏方で、サブリーダ的な仕事してます。

計画を申告する事の意味は、申告される側の人を安心させる為と考えています。
計画の詳細を話したところで理解されない現場が多いと思います。

仕様書は概要部分だけを客先に提出するように、
「金額的な収支の予測をつけ易くするための道具」として計画を提出する。
責任回避の為にある。と考えています。

つまり、詳細部分の仕事が完璧にこなせると仮定してですが・・・。
納期を守る、予算内で作成、いわゆるプロジェクトの成功が必然と言う前提条件にたった、
簡易的な説得手法である・・・と考えています。

しかし、今、現状のように、プロジェクトの成功率が約3割と言う状況では
逆に用いない方がいい物なのではないか?と考えています。

話をこじらせる事が多いわけですし。
kossy
会議室デビュー日: 2004/04/09
投稿数: 5
投稿日時: 2004-05-25 09:50
開発歴15年です。
プロジェクトリーダーを経験してきました。

まず、大きな話からすると、
・仕事にはすべて期限があります。
・仕事は一人でやっているわけではないので、自分がやっている仕事の進捗が
 他の人に影響を与えます。よってその仕事がいつ終わるかはっきりしないと
 他の人の予定が立てられません。

個人レベルの話をすると
・スケジュールは目標設定です。
 たとえば、「この仕事を18時までに終わらせないと、デートに行けない。」
 という気持ちでするのと、「1週間以内にすればいいや」というのとでは、
 取り組み方が違うと思います。

でも、システム開発は工事現場のように単純作業の積み重ねではないので、
なかなかスケジュール通りにはいきません。


[ メッセージ編集済み 編集者: kossy 編集日時 2004-05-25 09:54 ]
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-05-25 11:59
引用:

るぱんさんの書き込み (2004-05-25 09:45) より:
計画を申告する事の意味は、申告される側の人を安心させる為と考えています。
  (中略)
納期を守る、予算内で作成、いわゆるプロジェクトの成功が必然と言う前提条件にたった、
簡易的な説得手法である・・・と考えています。


私は、るぱんさんの意見を計画書を求める方の問題点を突いている様に受け留めました。

例えば、1年目PGに開発依頼をした場合、PGは経験が無いため、
計画が立てられません。この場合、「計画」は「目標」となります。
勿論、目標=計画とはせずに依頼者は計画上にバッファを持つでしょう。

しかし、依頼者と開発者の間で「計画」の意味が「目標」から「約束」に変るタイミングが
明確で無い事が多いです。言わば依頼者の勝手な判断で「約束」とされる事が多いのです。

そして大きな問題が、開発者が何時まで経っても「約束」する手段を身に付けず
依頼者もそれを要求せず、「依頼作業にどの位時間が掛るか経験しなさい」の
要求のみで済ませています。

確かに経験則は、納期見積時に重要なウェイトを占めますが、
直接的に「約束」という行為には、意味を成さない筈です。

「計画」を立てる為に、必要なスキルとは何か?を考え直せば、
「計画」の効果性を強める手段が明確になり、
また計画能力向上の手順が身に付くと考え始めました。
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-05-25 17:04
引用:

kossyさんの書き込み (2004-05-25 09:50) より:
・仕事にはすべて期限があります。


依頼者の要求事項に大抵存在する「期限」を守る事は、受託側に取って明確な「サービス」となる為、不動の物と捉えがちと思うのです。

「期限」とは平たく言えば「依頼結果を効果的に受けれる時期」であり、そうでなければ「期限」は、計画の結果値として捉えないとオカシイと考えます。

つまり「期限」は、本来は絶対的な物では無く、「要求」や「設計」の間違いが有る様に、依頼者が提示する「期限」の設定も間違っている事があります。

これは「そんな期間では出来ません」と言う意味は今回置いといて、指定時期では、依頼者が最終目的は果せないスケジュールだったり。逆に、依頼者の次工程を開始する必要条件が満たない時期だったりします。
# 依頼経験がある方は、過去を振りかえれば思い当たる節が幾つもあると思います。(私は一杯あるぞ!)

これに対する意見として、前者には「最終目的を果せないのは依頼者のミスだ!ワシャ知らん!」、後者には「早めに対応して不利益は無い」と言う単純な考えが私には浮かびますが。
しかし、最初に記述した通り、「期限」を守る事が「サービス」であるならば、「依頼者のミス」で済ませる考え。「期限」が「効果的なタイミング」であるならば、「不利益は無い」と言う考え。それぞれに矛盾すると考えます。

実際の所、受託側から依頼側へ「期限」設定に注文を付けれない立場で、また契約の重要項目である為、企業間での変更は非常に難しいと思いますが、PMなり、依頼者は「期限」に対する考えを再考する必要があるのでは?と思います。
zaxx_MD
大ベテラン
会議室デビュー日: 2003/04/21
投稿数: 204
お住まい・勤務地: 千葉県柏市
投稿日時: 2004-05-25 17:48
「スケジュール」って随分大きいですね、
夏休みの宿題スケジュールと
危機管理スケジュールを同じ土俵で討論していませんか?

システム開発におけるスケジュールとは、大きく3種類あると思います。
1.顧客との調整のためのマスタースケジュール
2.開発グループ内部のリソース管理スケジュール
3.開発者個々の作業スケジュール
どれも、各関係者との意思疎通を確認するために非常に重要なものです。
それぞれのスケジュールに一貫性がある必要はありません。
顧客・管理者・作業者それぞれがそれぞれのシーンでどこまでお互いの意識が合っているか
確認するための有効な手段だと思います。
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2004-05-25 18:27
るぱんです。

些細な疑問が沸いて来ました。

まず、前提条件として、お伺いしたいのですが、
計画は達成しなくても良い?
計画は達成しなくてはならない?
二種類の考えがあると思うんですね。

計画は達成させる為に必要な物。。。僕は、必要十分で捉えているのですが、
まず、皆さんは、どちらの立場に立つものでしょうか?

引用:
zaxx_MDさんの書き込み(2004-05-25 17:48)より:
1.顧客との調整のためのマスタースケジュール
2.開発グループ内部のリソース管理スケジュール
3.開発者個々の作業スケジュール



いろいろ有ると思うのですが、
それぞれで変わってくる物なのでしょうか?

宜しくお願いします。

引用:

それぞれのスケジュールに一貫性がある必要はありません。
顧客・管理者・作業者それぞれがそれぞれのシーンでどこまでお互いの意識が合っているか
確認するための有効な手段だと思います。


確認する為の手段・・・と言うことは目的ではないわけですよね?

目的ではない場合、強制するべき事柄ではない・・・となってくるのですが、
僕の捕らえ方が間違ってますでしょうか・・・?

スキルアップ/キャリアアップ(JOB@IT)