リスクとチャレンジ

投稿者	投稿内容
tzk 常連さん会議室デビュー日: 2002/05/17 投稿数: 35	投稿日時: 2004-03-26 14:15 今日は標題の件について、みなさんにお伺いしたく投稿しました。システム開発のプロジェクトでは、常にリスクとチャレンジのバランスが問題になってくると思います。過去の実績を元に少しでもリスクを減らそうという人、そして、新技術を積極的に取り込むことでチャレンジングなシステムを作ろうとする人。この二種の人達の間で、どう折り合いを付けて行くかに非常に悩んでいます。現在、私の関わっているプロジェクトではマネージャクラスの人達が先進派で、担当SEレベルの人達が保守派という構造になっています。ただ、これには納期が迫っているという背景があり、担当SE（私を含む）はリスクを負って進むにしても、それに対する予備期間が欲しいという主張をしています。みなさんが今まで経験されたプロジェクトで、うまくいったのはどのパターンが多いでしょうか？ 1. 先進的マネージャ、先進的SE（超先進的） 2. 先進的マネージャ、保守的SE 3. 保守的マネージャ、先進的SE 4. 保守的マネージャ、保守的SE（超保守的）これ以外にもパターンがあると思い、投票にはしませんでした。私はこう考えています、という方がいらっしゃいましたら是非ご意見を頂戴したく思います。
ラフィンぬし会議室デビュー日: 2002/05/23 投稿数: 809 お住まい・勤務地: 外野	投稿日時: 2004-03-26 15:05 　経験談だけ。　自分が参加した中で過去一番うまくいったと思えるのは、 1. 先進的マネージャ、先進的SE（超先進的）＋先進的プロジェクトですね。　もう１０年以上昔になります。　プロジェクトの期間は１年たらず。メンバーは５人。全員プロジェクトの頭が取れる人で３人は管理職、いわゆるペーペーなし。３人が業務ＳＥで２人がテクニカルＳＥ、ＰＧ作業は５人でまかなう。　プロジェクトの目的は、　1.オブジェクト指向の理解　2.ＰＧ作業を経験することによるＳＥスキル向上といったところ。　私ともう一人が３ヶ月の期間をもらって、その間に行った作業はすべてクラス設計と標準化。３人の業務ＳＥが帰ってきて全員でＰＧ作業。　その時の資産は改良されていまだ現役なので大成功と言っていいのではないかと思います。
tzk 常連さん会議室デビュー日: 2002/05/17 投稿数: 35	投稿日時: 2004-03-26 15:18 ラフィンさん、ご回答ありがとうございます。なるほど。組み合わせがどうこうというよりも、プロジェクト参画者全員のコンセンサスが得られているかが重要ということでしょうかね。私の提示した１．～４．だと、２．と３．の状態がまずいという気もしてきました。
taro ぬし会議室デビュー日: 2003/10/20 投稿数: 316	投稿日時: 2004-03-26 15:20 ＞4. 保守的マネージャ、保守的SE（超保守的）過去一番（社内的に）うまくいったのはこれです。他社と技術力を比較すると恥ずかしいばかりですが、顧客にはよく分からない部分ですしね･･･。（自分は先進的PG？としてイライラしてましたが･･･。）
はにまるぬし会議室デビュー日: 2003/12/19 投稿数: 969 お住まい・勤務地: 誤字脱字の国	投稿日時: 2004-03-26 15:25 はにまるです。　確かに単発／短期で見れば、＞　4. 保守的マネージャ、保守的SE（超保守的）　に軍配が上がるのは目に見えている様な気がしますが．．．．ただ、「規則大好マネージ」のプロジェクトはボロボロでした．．．
tzk 常連さん会議室デビュー日: 2002/05/17 投稿数: 35	投稿日時: 2004-03-26 15:54 では、例えばこういう場合はどうでしょうか？マネージャ：プロジェクトAで実績あり下位SE：プロジェクトBで実績ありこの場合、プロジェクトにより文化が異なり、A方式とB方式での対決も起こり得ます（というか、事実起こっています）。同じ保守的にしても、違う文化を持つ人がそれぞれの実績を主張しあう場合、問題が起きるのではないかと思います。こういった経験をお持ちの方もいらっしゃるでしょうか。
Beatle ぬし会議室デビュー日: 2003/06/09 投稿数: 394	投稿日時: 2004-03-29 13:36 まぁ何か問題が起こった時に、それぞれの考え方や実績等で意見の対立が起こるのも良くあることですね。ただ、大きな意味では冒険的なチャレンジをするかどうかは、プロジェクト開始時に開発対象業務と工数（スケジュール）で決まってしまうと思うのですが．．．いくら先進的なPMやSEでも、開発内容が軍事や列車の運行管理というような安全性を最優先で考えた場合、Windows等は使わないでしょうし、JAVAもまだまだ使う事は無いと思いますよ。この場合にはとにかく検証できていてトラブルの少ない環境や言語を選択するはずですね。（極論ですが）一方、スケジュールも非常にタイトな場合、冒険的な事にトライして何か問題が発生した場合、対策を講じることができる日程を設けることができないのであれば、安全性の高い確実な手法で開発しますよね。そのプロジェクトが安全性を重視するものなのか、チャレンジ性を重視できるものなのかの見極めが難しいのでしょうけどね。使う側からはどんな状況でも両方を求められるのですが．．． ※個人的には、リスケジュール、リアサイン可能な日程や要員が確保できるなら、どんど　んチャレンジはしてもいいとは思うのですが。（無謀なチャレンジは別として）

投稿者	投稿内容
tzk 常連さん会議室デビュー日: 2002/05/17 投稿数: 35	投稿日時: 2004-03-26 14:15 今日は標題の件について、みなさんにお伺いしたく投稿しました。システム開発のプロジェクトでは、常にリスクとチャレンジのバランスが問題になってくると思います。過去の実績を元に少しでもリスクを減らそうという人、そして、新技術を積極的に取り込むことでチャレンジングなシステムを作ろうとする人。この二種の人達の間で、どう折り合いを付けて行くかに非常に悩んでいます。現在、私の関わっているプロジェクトではマネージャクラスの人達が先進派で、担当SEレベルの人達が保守派という構造になっています。ただ、これには納期が迫っているという背景があり、担当SE（私を含む）はリスクを負って進むにしても、それに対する予備期間が欲しいという主張をしています。みなさんが今まで経験されたプロジェクトで、うまくいったのはどのパターンが多いでしょうか？ 1. 先進的マネージャ、先進的SE（超先進的） 2. 先進的マネージャ、保守的SE 3. 保守的マネージャ、先進的SE 4. 保守的マネージャ、保守的SE（超保守的）これ以外にもパターンがあると思い、投票にはしませんでした。私はこう考えています、という方がいらっしゃいましたら是非ご意見を頂戴したく思います。
ラフィンぬし会議室デビュー日: 2002/05/23 投稿数: 809 お住まい・勤務地: 外野	投稿日時: 2004-03-26 15:05 　経験談だけ。　自分が参加した中で過去一番うまくいったと思えるのは、 1. 先進的マネージャ、先進的SE（超先進的）＋先進的プロジェクトですね。　もう１０年以上昔になります。　プロジェクトの期間は１年たらず。メンバーは５人。全員プロジェクトの頭が取れる人で３人は管理職、いわゆるペーペーなし。３人が業務ＳＥで２人がテクニカルＳＥ、ＰＧ作業は５人でまかなう。　プロジェクトの目的は、　1.オブジェクト指向の理解　2.ＰＧ作業を経験することによるＳＥスキル向上といったところ。　私ともう一人が３ヶ月の期間をもらって、その間に行った作業はすべてクラス設計と標準化。３人の業務ＳＥが帰ってきて全員でＰＧ作業。　その時の資産は改良されていまだ現役なので大成功と言っていいのではないかと思います。
tzk 常連さん会議室デビュー日: 2002/05/17 投稿数: 35	投稿日時: 2004-03-26 15:18 ラフィンさん、ご回答ありがとうございます。なるほど。組み合わせがどうこうというよりも、プロジェクト参画者全員のコンセンサスが得られているかが重要ということでしょうかね。私の提示した１．～４．だと、２．と３．の状態がまずいという気もしてきました。
taro ぬし会議室デビュー日: 2003/10/20 投稿数: 316	投稿日時: 2004-03-26 15:20 ＞4. 保守的マネージャ、保守的SE（超保守的）過去一番（社内的に）うまくいったのはこれです。他社と技術力を比較すると恥ずかしいばかりですが、顧客にはよく分からない部分ですしね･･･。（自分は先進的PG？としてイライラしてましたが･･･。）
はにまるぬし会議室デビュー日: 2003/12/19 投稿数: 969 お住まい・勤務地: 誤字脱字の国	投稿日時: 2004-03-26 15:25 はにまるです。　確かに単発／短期で見れば、＞　4. 保守的マネージャ、保守的SE（超保守的）　に軍配が上がるのは目に見えている様な気がしますが．．．．ただ、「規則大好マネージ」のプロジェクトはボロボロでした．．．
tzk 常連さん会議室デビュー日: 2002/05/17 投稿数: 35	投稿日時: 2004-03-26 15:54 では、例えばこういう場合はどうでしょうか？マネージャ：プロジェクトAで実績あり下位SE：プロジェクトBで実績ありこの場合、プロジェクトにより文化が異なり、A方式とB方式での対決も起こり得ます（というか、事実起こっています）。同じ保守的にしても、違う文化を持つ人がそれぞれの実績を主張しあう場合、問題が起きるのではないかと思います。こういった経験をお持ちの方もいらっしゃるでしょうか。
Beatle ぬし会議室デビュー日: 2003/06/09 投稿数: 394	投稿日時: 2004-03-29 13:36 まぁ何か問題が起こった時に、それぞれの考え方や実績等で意見の対立が起こるのも良くあることですね。ただ、大きな意味では冒険的なチャレンジをするかどうかは、プロジェクト開始時に開発対象業務と工数（スケジュール）で決まってしまうと思うのですが．．．いくら先進的なPMやSEでも、開発内容が軍事や列車の運行管理というような安全性を最優先で考えた場合、Windows等は使わないでしょうし、JAVAもまだまだ使う事は無いと思いますよ。この場合にはとにかく検証できていてトラブルの少ない環境や言語を選択するはずですね。（極論ですが）一方、スケジュールも非常にタイトな場合、冒険的な事にトライして何か問題が発生した場合、対策を講じることができる日程を設けることができないのであれば、安全性の高い確実な手法で開発しますよね。そのプロジェクトが安全性を重視するものなのか、チャレンジ性を重視できるものなのかの見極めが難しいのでしょうけどね。使う側からはどんな状況でも両方を求められるのですが．．． ※個人的には、リスケジュール、リアサイン可能な日程や要員が確保できるなら、どんど　んチャレンジはしてもいいとは思うのですが。（無謀なチャレンジは別として）

リスクとチャレンジ

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