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

開発プロセスの導入

投稿者投稿内容
YES
会議室デビュー日: 2006/05/14
投稿数: 1
投稿日時: 2006-05-14 11:48
お世話になります。

プロジェクトに開発プロセスの導入を推進しています。
導入の効果をバックアップする数字を示したいのですが
どういう手法がありますか?

常駐先のプロジェクトリーダーに
その価値を理解していただけず苦戦している状態です。
基本設計がないので想定外の仕様変更が頻繁に発生して
プログラマが徹夜で対応に追われています。

第一段階としてシステム化のコンセプトを明確にすることからはじめています。

システムの軸を決めて以下のように分類します。
・システムの機能として受け入れるもの
・業務プロセスの見直しから行うもの
加納正和
ぬし
会議室デビュー日: 2004/01/28
投稿数: 332
お住まい・勤務地: 首都圏
投稿日時: 2006-05-14 13:04
えっとあえて「プロジェクトリーダ」の立場から見てみると、、

引用:

YESさんの書き込み (2006-05-14 11:48) より:
お世話になります。

プロジェクトに開発プロセスの導入を推進しています。



「プロジェクト」に?会社にではなくて。

引用:

導入の効果をバックアップする数字を示したいのですが
どういう手法がありますか?



全社的にやることを決定しているのであれば「バックアップ」も何も
一気に上(経営者)が「えいっ」て強制することになると思いますが。

それ以外には手法としてはありますが、役に立ったところを見たことがありません。

「試行プロジェクト」を用意して、その効果を数値化する。

のもありかとは思いますが。
そのプロジェクトでは、ある効果を測定する「だけ」でプロジェクトの
評価には含めない。

でも結局、その先の「実際プロジェクト」の導入には、経営者が「えいっ」
とやる以外は、尻つぼみに終わります。

引用:

常駐先のプロジェクトリーダーに
その価値を理解していただけず苦戦している状態です。



でしょうね。価値なんかありませんから。

だって開発プロセスを導入すると給料上がるのですか?評価が上がる?
なんか良くなる?従業員なのに何が良くなるんです?しかも開発プロセス
を導入して残業代が減ったら給料減るのでは。意味ないじゃん。

しかも、常駐先って、自社にいない(別の会社にいる)という意味ですか。
それとも自社にいるけど別会社(協力社員)という意味ですか。

どちらの意味にせよ至難の業です。価値を理解したとしても、
実際導入できないでしょう。

引用:

基本設計がないので想定外の仕様変更が頻繁に発生して
プログラマが徹夜で対応に追われています。



「基本設計」があっても、プログラマが徹夜で対応することになります。
#経験者は語る。
「想定外」の仕様変更(仕様変更はすべて想定外なのだが)は、
顧客側の要因ですから、「基本設計」があっても無駄です。
そういう意味では、本質的には、起こりえます。

ただし、「仕様変更」が起こらないように、「要求」の段階から「仕様」を
作りこむこと、ついでに「基本設計」設計での「想定外」を相対的に
減らす「かもしれない」、のは可能です。

この「かもしれない」がくせもので、実際上、効果がないことは多いです。
私の経験上では、はっきりいって「全く」効果がありませんでした。

開発プロセス用の文書が多くなるだけで、さらに残業が増えるだけです。
しかも、「開発プロセス」があるから大丈夫なはずだ、と上は思い込むらしく
プロジェクトリーダの評価はさらに低くなります。

で、評価が低くなってプロジェクト解散。経験値もゼロに戻る。というの
の繰り返しです。

引用:

第一段階としてシステム化のコンセプトを明確にすることからはじめています。

システムの軸を決めて以下のように分類します。
・システムの機能として受け入れるもの
・業務プロセスの見直しから行うもの



そのコンセプトと、問題解決は関連がないかとも思います。
関連がないことが分かるからこそ、開発プロセスの導入なんてのに
興味がないのでしょう。

否定的に書いてますが、私は別に開発プロセスの導入に反対しているのではありません。
全くないよりはあったほうがいい。
普通に考えるなら、なんらかの手順があったほうがいいことは明らかです。

でも「開発プロセス」は本来、各プロジェクト要員の「経験値」を高める
のに効果的な方法であって、外部から導入の効果を計るのは、
おそらく無理があると思います。

各プロジェクトで解決すべき課題が異なるからです。
そこらへんを経営者以外の人が何とかできるとも思わないんですがね。。。
UU
会議室デビュー日: 2006/05/14
投稿数: 7
投稿日時: 2006-05-14 16:00
私は、開発プロセス導入に異を唱えます。
実践とかけ離れ無駄だからです。
臨機応変に対応するのが一番よいです。
UMLだとかCMMだとか騒ぐのは馬鹿なPGだけ。
ぶさいくろう
ぬし
会議室デビュー日: 2005/11/22
投稿数: 1232
お住まい・勤務地: 川崎市(は俺も含めてロクな人間が住んでないよw)
投稿日時: 2006-05-14 16:03
僕もUMLには結構反対。
理由は開発員全員が知らなきゃ余計に混乱するから。
アジャイルとかも同様。
ちゃんと知っているメンバーばかりのところでやってほしい・・。
加納正和
ぬし
会議室デビュー日: 2004/01/28
投稿数: 332
お住まい・勤務地: 首都圏
投稿日時: 2006-05-14 23:30
引用:

ぶさいくろうさんの書き込み (2006-05-14 16:03) より:
僕もUMLには結構反対。
理由は開発員全員が知らなきゃ余計に混乱するから。



まぁ、UMLの話は元記事の人はしてませんが、、
UMLって、真っ当に使ってるとこってあるんですかね。
「ユースケース図」しか見たことがない、、あんなのだけなら無駄じゃんとか思い。
今実際の開発は派遣に任してるから、
実装者がわからない記述で書いても無駄なんですよね。

開発プロセスも同様に無駄なんですがね。。上は分からない。。。
ぶさいくろう
ぬし
会議室デビュー日: 2005/11/22
投稿数: 1232
お住まい・勤務地: 川崎市(は俺も含めてロクな人間が住んでないよw)
投稿日時: 2006-05-15 00:23
引用:

加納正和さんの書き込み (2006-05-14 23:30) より:
まぁ、UMLの話は元記事の人はしてませんが、、

ああーごめん。その上の人がしていたのでついね。
プロセスとか手法にこだわる前に効果的かどうかを見てからにしなさいってことが言いたかったのね。

引用:

開発プロセスも同様に無駄なんですがね。。上は分からない。。。

そう。わかっていれば無駄にはならんがわかってないから無駄になる。
ゆきち
会議室デビュー日: 2004/07/05
投稿数: 10
投稿日時: 2006-05-15 08:30
それじゃ、このスレ主にには、どういうアドバイスがあるのでしょう?
まさか、死ぬ気で働け、とも言えないでしょう。
ひら
ぬし
会議室デビュー日: 2005/03/04
投稿数: 260
投稿日時: 2006-05-15 11:00
引用:

YESさんの書き込み (2006-05-14 11:48) より:
基本設計がないので想定外の仕様変更が頻繁に発生して



UMLの導入経験があります。
初版を作るのは、たしかにUMLを記述しないほうが早いです。
しかし、仕様変更が発生したときの対応の早さはUMLを記述したほうが迅速ですね
業務を図式化したものがないと、ソースコードを追っかけなくてはなりませんので。

しかしそれも、基本設計があっての話で、それがなければ余計に混乱してしまいます
そのあたりから検討してみてはいかがでしょうか?


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