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

CMM1以下の職場を改善したい。

投稿者投稿内容
二等兵
会議室デビュー日: 2004/12/18
投稿数: 6
投稿日時: 2004-12-18 21:06
とあるメーカーの情報シス部門に常駐して
情報システムの設計と実装のお仕事をさせて頂いてます。
プロパーの方は管理や基本計画などの上流工程を担当しています。
目的は各部門バラバラに運用しているシステムのデータ統合です。

ここからが本題です。
現場で感じたプロパーに対するプロジェクトの問題点を上げます。

■プロパーの方が全てシステム開発未経験者。
■プロジェクトの定義が出来ていない。
 職場の職制と年齢で役割分担を決めている。
■メンバーが誰なのか分からない。
 開発をプロパー新人研修の課題として
 その成果物を実運用に載せようとしている。
■プロジェクト的な話や技術的な話が出てこない。
 開発プロセスって何?要件定義って何?というレベル。
■要件定義をプログラマに口頭で説明してプログラム作成を要求。
■飲み会で仕様が決まる。

プロジェクトとは何かからはじめて
範囲やWBS、役割分担、成果物定義などの枠組みを大まかに説明したのですが
「それを何とかするのが仕事でしょ?」という回答を頂きました。

愚痴ばかりになってしまいましたがこのような職場が存在します。
意識付けから変えていかなくてはならないのですが
どうしたらよいものか途方に暮れております。
なにかアドバイスを頂けないでしょうか?
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2005-01-03 23:20
2つ3つ、デスマーチを行えば、少しは変わるんじゃないですか?

っつうか、外部の人間がいくら言っても聞きやしない。プライドとか、偏見とかいうやつ。せいぜい自分に飛び火しないように、うまく立ち回って、2〜3の失敗があった後に上のほうの人間に「こんな管理のしかたがあるんですよねぇ」と、それとなく口にする。または書籍の類を机の隅に積読(積んでおいて読んだ気になること。ここでは積んでおいて読ませること)。
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2005-01-06 00:59
管理とは監視でも規定書を作る事ではなく、より良い状態にする為の連続的な行為であり、つまり今が駄目だと嘆くのは管理行為や考える事を放棄する事です。

また、職場の状態をより良い状態にすると言う事は信頼関係が必要最低限の条件になりますから、管理とは時間の掛かる事でもあります。

結局の所、管理技法とは目先の目的を達成する為に如何行動するかべきか、如何考えるかべきか、如何発言すべきかは教えてくれず。自ら行動する人に反省材料を適切にあたる手段を提示してくれるだけです。


本に記載されいる管理技法を唱えた位で人が動くならば誰も苦労はしませんし。今、何をしていいのか解らないのであれば、それはまだ経験が足りないという事です。今から起こる事の全てを直視して一人一人の言動を頭に叩き込む位の姿勢であれば、次の同じ様な機会に今回の経験を生かした意見が言える様になります。その時、周囲の人は貴方の意見に耳をかすかもしれません。

これが私の考えです。

_________________
人生変わっちゃうかもよ?OFF会参加者募集中今考えるな、参加してから考えろ。
masuda
会議室デビュー日: 2005/01/21
投稿数: 12
投稿日時: 2005-01-24 11:56
引用:

二等兵さんの書き込み (2004-12-18 21:06) より:
プロジェクトとは何かからはじめて
範囲やWBS、役割分担、成果物定義などの枠組みを大まかに説明したのですが
「それを何とかするのが仕事でしょ?」という回答を頂きました。



正攻法としては、過去のプロジェクトの成果物(要求仕様書〜運用試験、保守まで)を使って一揃いのフォーマットを作ってしまうのもいいと思います。CMMやISO9001的には「文書」を基準にしてプロジェクトを管理していくので、そういうエビデンス(証拠)の必要性を実物に沿って解説していきます。この場合、プロパーが上流工程を担当するでしょうから要求仕様あたりからひとつひとつ実践するとか。

あと、
引用:

■要件定義をプログラマに口頭で説明してプログラム作成を要求。
■飲み会で仕様が決まる。


っていうのであれば、いっそのことXPとか如何でしょう
CMM的に仕様書を厳格に書くのは止めて、ホワイトボードとストリーカード、ちょっとしたUMLを使ってプログラミング。コーディングは新人でしょうから、JUnitなりCppUnitなりを導入してしまってテストファースト。
敢えて「管理手法」にこだわらずに、この際、進捗管理も短期リリースに準じてしまって、とか。

# 既に「慣習型」に移行してしまった組織の場合、アジャイル手法って
# 導入し辛いんですよねぇ。管理し辛いという理由で。
おばけ
ぬし
会議室デビュー日: 2002/11/14
投稿数: 609
お住まい・勤務地: 東京都江東区
投稿日時: 2005-01-24 12:51
引用:

2つ3つ、デスマーチを行えば、少しは変わるんじゃないですか?


そうそう。

二等兵さんがおっしゃっていますが、プロパーの方は未経験なんですよね?
一度通してやってみて、大失敗して痛い目見て、(必要ならばそれを繰り
返して)そこで初めて色々なことが身に染みて分かるんじゃないでしょうか?

悲しいかな、経験しないと分からないってこともありますよ。
冷たい言い方に聞こえるかもしれませんが、そのお客さんにとってベストな
「学び方」が「失敗すること」であることもあるわけです。

# 二等兵さんご自身としては、くれぐれも巻き添えを食わないように、
# うま〜く逃げる必要があるでしょうけれど。

まぁ、所詮は他人事だから言えるんだろ!と言われると身も蓋も無いのですがね。
話半分で聞いて頂ければと思いますよ
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-01-24 16:49
どもでふ。がるです。
建設的な意見が色々出ているので、ちょりっと天邪鬼的
見解を一つだけ。
引用:

Jittaさんの書き込み (2005-01-03 23:20) より:
2つ3つ、デスマーチを行えば、少しは変わるんじゃないですか?


んっと、おっかない現場がありまして。
デスマーチをさせた結果(いやまぁきっちり地獄を見ていただいたのですが)、
彼らが学んだのは「生贄の作り方」と「つるし上げ方」。総じて
「責任転換の技術」だけ、でした。
ちなみに、建設的な提案は、ことごとく「**(生贄の名前)さんが
きちんとやってくれれば問題はおきないんですけどねぇ」で終わり。

基本的には「プライドを傷つけないようにこっそりと知恵をつける」
ってあたりには諸手を上げて賛成なのですが。
必要に応じて「見切りをつける」選択肢も、一応持っておいて損は
ないと思います :-P
おばけ
ぬし
会議室デビュー日: 2002/11/14
投稿数: 609
お住まい・勤務地: 東京都江東区
投稿日時: 2005-01-25 12:52
引用:

デスマーチをさせた結果(いやまぁきっちり地獄を見ていただいたのですが)、
彼らが学んだのは「生贄の作り方」と「つるし上げ方」。総じて
「責任転換の技術」だけ、でした。


うっぷ。そう来ましたか(笑)。
まあ、そういう「他人に責任を擦り付ける人」が「ダメ人間」として認識
される職場であれば、まだ救いはあるかもしれません。しかし、職場が
「責任を擦り付ける人」の集まりだったりすると、もはや救い様は無いです
よね。。。そういう職場からはさっさとおさらばするのが得策かと。
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-01-25 15:21
どもでふ。がるです。
引用:

うっぷ。そう来ましたか(笑)。


そう来たんです(笑
ちなみにその現場はおばけさんのおっしゃるところの「職場が
「責任を擦り付ける人」の集まりだったり」しました(苦笑
気づいた瞬間に、可能な限り穏便に常識的に、且つ最速で辞めました(笑

戦略の一つに撤退があることの意味をとても深く考えさせられた
ものです(笑

以上、雑談でした m(_ _)m

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