開発プロセスの導入

投稿者

投稿内容

m.ku: 大ベテラン; 会議室デビュー日: 2002/09/15; 投稿数: 184

投稿日時: 2006-05-15 13:32

作業の改善という視点で見るなら
・現状の把握とリストアップ
・理想となる作業方法のリストアップ
・徐々に(部分的に)移行可能かどうかの検討とスケジュール
・必要に応じて作業をパターン化し、省力化する為のツール選定
などを検討しますかね？

それらを現状に合わせて作業方法を少しずつ変えていく様にすると
意外と無理のない変更が可能です。
まあ一気に変えようとしないで積み重ねていく長い目でいくのが無難かと。

object: ぬし; 会議室デビュー日: 2002/03/20; 投稿数: 338; お住まい・勤務地: 香川県高松市

投稿日時: 2006-05-17 16:59

objectです。

確認なのですが、
「どんな開発プロセスの導入」
を考えていらっしゃるのでしょうか？

「基本設計がない」
というのは気になりますね。
#勿論、「基本設計」があれば充分という意味ではありません。

先ず
「開発＝プロセス」
と考える事は、大きな意味では、結局、
「開発＝(スタート地点⇒到達地点に至る過程)」
と考える事に相当すると思います。

そして、この中で
「何が重要なのか」
を
「各種プロセス手法を覚える事」
からでは無く、
「プロセス自体を適切に表現・理解する事」
という作業を通して知る必要があるのではないでしょうか？
#手法に振り回されると、先ず良い結果にはならないと私は思います。

>第一段階としてシステム化のコンセプトを明確にすることからはじめています。
>
>システムの軸を決めて以下のように分類します。
>・システムの機能として受け入れるもの
>・業務プロセスの見直しから行うもの
細かい部分を省略して言うと、
最も重要なのは、先ず
「システムとしての現在の対象を明確にする」
事ではないでしょうか？
「各部分を受け入れるか・見直すか」
は、少なくともそれ以降の問題だと私は思います。

よっしー: 会議室デビュー日: 2006/05/08; 投稿数: 3

投稿日時: 2006-06-05 18:16

まず、内容から考えますとこの書き込みは「プロジェクト管理」の方にされた方が適当な方の目に留まると思います。

プロジェクトに開発プロセスの導入…と書かれておられますが、仕事をどのように組み立てて、あるいは、段取りされていらっしゃるのか。非常に興味深いです。「場当たり的な段取り (Happy go lucky)」だとするとかなりお辛いかと思います

導入の効果をバックアップする数字…推進されるお立場であるならば、市販の書籍を読んでみて下さい。ケーススタディとして数値が載っていると思います

プロジェクトリーダーが開発プロセスの価値を理解していない…これも非常に興味深いです。プロジェクトリーダーの職責はどのように定義されているのでしょうか

基本設計がないので想定外の仕様変更が頻繁に発生して…基本設計とは上流の設計書だと思います。この設計書が無いことによる、後続の作業への影響が作成時点で正しく判断されていないことが分かります。どのような判断を行って、後続の作業に着手されたのでしょうか。これも非常に興味深いです

システム化のコンセプトを明確にすること…書かれていることから考えますと、まずはプロジェクト関係者全員が共有（合意）できる、「プロジェクトのゴール」を明らかにすることが重要ではないでしょうか。

察するにプロジェクトを始める前に明らかにしておかなければならないことが明らかにされないままプロジェクトを始めてしまっているのだと思います。プロジェクトを始める前には次のことを明らかにしていなければならないと思います。

1. プロジェクトのゴール
2. お客様のご要望
3. 成果物（設計書、ソースコードなどなど）
4. レビュー（ご検収）の内容、方法（誰が、どの成果物をレビューして、ご要望を満たしていることを確認するのか）
5. 段取り（タスク）（何をどの順番で行えばゴールにたどり着くのか）
6. スケジュール（どのタスクに何日を要して、何月何日に終わるのか）

ポイントは「成果物とレビュー」、「段取りとスケジュール」です。これら４つの要素について考え、実行可能なプランを作れなければ、残念ですが、プロジェクトリーダーとは言え無いと思います

Tacchang: ベテラン; 会議室デビュー日: 2004/09/05; 投稿数: 55; お住まい・勤務地: 川崎市

投稿日時: 2006-06-18 11:01

YESさん，こんにちは．

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

私は良いものを知りません．ただし，以前オブジェクト指向で考えUMLで表記することやUnifiedProcessを導入したいと考えた時，上の人間を説得するために同様な課題にぶつかったことがあります．

なんとか定量的に(客観的に)優れていることを証明(自分でも確認)したかったので，小さなプロジェクトで試行してみて，コスト面の評価，開発者の意見やリリース後の不具合件数を調査してみたことがあります．それまでに何度やっても失敗していたようなことや不具合が少なくなっているならばメリットがあるだろう，という考えです．

結果は”新しいパラダイムを導入するため注意力が増していた(あるいは熟練者が集まっていた)”のか”そのパラダイム自体が優秀だった”のか区別つきませんでした．唯一明らかだったのは，開発者が”スムースに開発できた”とか”こんなにきっちり設計したのは初めて”というコメントをしてくれたことでしたが，それも”開発者に優しい開発スタイル”が”お客様や経営者にやさしい開発スタイル”ではないという意見があって”あぁそうかもなぁ”と思った記憶があります．

厳密に効果を証明することは難しいと感じています．

«前のページへ 1|2

開発プロセスの導入

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