@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
開発プロセスの導入
投稿者 | 投稿内容 | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-05-14 11:48
お世話になります。
プロジェクトに開発プロセスの導入を推進しています。 導入の効果をバックアップする数字を示したいのですが どういう手法がありますか? 常駐先のプロジェクトリーダーに その価値を理解していただけず苦戦している状態です。 基本設計がないので想定外の仕様変更が頻繁に発生して プログラマが徹夜で対応に追われています。 第一段階としてシステム化のコンセプトを明確にすることからはじめています。 システムの軸を決めて以下のように分類します。 ・システムの機能として受け入れるもの ・業務プロセスの見直しから行うもの | ||||||||||||||||||||
|
投稿日時: 2006-05-14 13:04
えっとあえて「プロジェクトリーダ」の立場から見てみると、、
「プロジェクト」に?会社にではなくて。
全社的にやることを決定しているのであれば「バックアップ」も何も 一気に上(経営者)が「えいっ」て強制することになると思いますが。 それ以外には手法としてはありますが、役に立ったところを見たことがありません。 「試行プロジェクト」を用意して、その効果を数値化する。 のもありかとは思いますが。 そのプロジェクトでは、ある効果を測定する「だけ」でプロジェクトの 評価には含めない。 でも結局、その先の「実際プロジェクト」の導入には、経営者が「えいっ」 とやる以外は、尻つぼみに終わります。
でしょうね。価値なんかありませんから。 だって開発プロセスを導入すると給料上がるのですか?評価が上がる? なんか良くなる?従業員なのに何が良くなるんです?しかも開発プロセス を導入して残業代が減ったら給料減るのでは。意味ないじゃん。 しかも、常駐先って、自社にいない(別の会社にいる)という意味ですか。 それとも自社にいるけど別会社(協力社員)という意味ですか。 どちらの意味にせよ至難の業です。価値を理解したとしても、 実際導入できないでしょう。
「基本設計」があっても、プログラマが徹夜で対応することになります。 #経験者は語る。 「想定外」の仕様変更(仕様変更はすべて想定外なのだが)は、 顧客側の要因ですから、「基本設計」があっても無駄です。 そういう意味では、本質的には、起こりえます。 ただし、「仕様変更」が起こらないように、「要求」の段階から「仕様」を 作りこむこと、ついでに「基本設計」設計での「想定外」を相対的に 減らす「かもしれない」、のは可能です。 この「かもしれない」がくせもので、実際上、効果がないことは多いです。 私の経験上では、はっきりいって「全く」効果がありませんでした。 開発プロセス用の文書が多くなるだけで、さらに残業が増えるだけです。 しかも、「開発プロセス」があるから大丈夫なはずだ、と上は思い込むらしく プロジェクトリーダの評価はさらに低くなります。 で、評価が低くなってプロジェクト解散。経験値もゼロに戻る。というの の繰り返しです。
そのコンセプトと、問題解決は関連がないかとも思います。 関連がないことが分かるからこそ、開発プロセスの導入なんてのに 興味がないのでしょう。 否定的に書いてますが、私は別に開発プロセスの導入に反対しているのではありません。 全くないよりはあったほうがいい。 普通に考えるなら、なんらかの手順があったほうがいいことは明らかです。 でも「開発プロセス」は本来、各プロジェクト要員の「経験値」を高める のに効果的な方法であって、外部から導入の効果を計るのは、 おそらく無理があると思います。 各プロジェクトで解決すべき課題が異なるからです。 そこらへんを経営者以外の人が何とかできるとも思わないんですがね。。。 | ||||||||||||||||||||
|
投稿日時: 2006-05-14 16:00
私は、開発プロセス導入に異を唱えます。
実践とかけ離れ無駄だからです。 臨機応変に対応するのが一番よいです。 UMLだとかCMMだとか騒ぐのは馬鹿なPGだけ。 | ||||||||||||||||||||
|
投稿日時: 2006-05-14 16:03
僕もUMLには結構反対。
理由は開発員全員が知らなきゃ余計に混乱するから。 アジャイルとかも同様。 ちゃんと知っているメンバーばかりのところでやってほしい・・。 | ||||||||||||||||||||
|
投稿日時: 2006-05-14 23:30
まぁ、UMLの話は元記事の人はしてませんが、、 UMLって、真っ当に使ってるとこってあるんですかね。 「ユースケース図」しか見たことがない、、あんなのだけなら無駄じゃんとか思い。 今実際の開発は派遣に任してるから、 実装者がわからない記述で書いても無駄なんですよね。 開発プロセスも同様に無駄なんですがね。。上は分からない。。。 | ||||||||||||||||||||
|
投稿日時: 2006-05-15 00:23
プロセスとか手法にこだわる前に効果的かどうかを見てからにしなさいってことが言いたかったのね。
| ||||||||||||||||||||
|
投稿日時: 2006-05-15 08:30
それじゃ、このスレ主にには、どういうアドバイスがあるのでしょう?
まさか、死ぬ気で働け、とも言えないでしょう。 | ||||||||||||||||||||
|
投稿日時: 2006-05-15 11:00
UMLの導入経験があります。 初版を作るのは、たしかにUMLを記述しないほうが早いです。 しかし、仕様変更が発生したときの対応の早さはUMLを記述したほうが迅速ですね 業務を図式化したものがないと、ソースコードを追っかけなくてはなりませんので。 しかしそれも、基本設計があっての話で、それがなければ余計に混乱してしまいます そのあたりから検討してみてはいかがでしょうか? |