＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
上流工程改善が注目される理由について
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-03-03 13:44
ソフトウェア開発の危機とは、どのようなことをさしているのでしょうか？ 上流・下流の区別をしない場合は危機が起こらないとも解釈もできますが、その理由は？ | ||||||||||||
|
投稿日時: 2004-03-03 14:55
こんにちは。七味唐辛子さん。
そういわれると，返答が難しいですね。 「ソフトウェア開発の危機」と言う言葉はIT Architect設立の広報ページから引用させていただいたので，私の認識が全てではないですし，個人で捕らえ方が異なるでしょう。 私は今，現場を離れてアカデミックな立場にいるので，間違ったことを書くかもしれませんが，あえて挙げるとすれば・・・・。 ・残業200H/月以上の人がいる ・大規模化(人員面，コードサイズ) ・納期短縮 ・顧客要望の変化へ対応 ・運用コスト削減 などなど･･･。 また， ・技術の多様化 ・海外への外注 ・フレームワーク依存度の拡大 ・セキュリティ面への対応 ・余剰要員 ・技術スキル などなど････。 実は単純に，「残業200H/月以上の人がいる」と言う点が最も気になっていたりします。日経さんのWEBで取り上げられていたこともあるぐらいですから，決して少なくないと思われます。本人の意思ならば仕方ないのですが，それは考えにくいでしょう。なぜ，こういうことが起こるのでしょうか。 もちろん，上流・下流の区別をしないからといって，"危機"がなくなる事はないと思います。ただ，顧客要望への変化に柔軟に対応するには，開発側も柔軟な開発プロセスを踏んだほうが，良い結果に結びつくのではないかと思うのですが，いかがでしょうか。 | ||||||||||||
|
投稿日時: 2004-03-03 17:31
みずみずさん こんにちは 広報ページをよく読んできました。
これを読まずに質問してしまいました。すいません 個人的に危機感を感じているといえば、上流・下流が企業の階層構造をあらわしている 場合が多く技術の継承とか技術者をそだてるとかは普通の企業とはちがうなという点では 危機感を感じています。 | ||||||||||||
|
投稿日時: 2004-03-04 10:13
はにまるです。
顧客要望への柔軟な対応は、商売の姿勢として必要と考えますが、 現状のレベルでは「個別契約前の話」の前提条件を付けます。 「柔軟な開発プロセス」を取上げる記事や本で疑問に思う事は、 変更に対する許容範囲の境界線と範囲外について話がされていない事で、 非常に危険な扱いと思います。 利害が一緒のチームの話であれば良いですが、 今はまだ、利害の異なる組織間では、許容範囲の境界線と範囲外について 取決める必要があります。 全体のサービス品質の向上を考えた場合、 「障害（変更）を受入れる」、「障害（変更）を取り除く」の両アプローチを 常に考える必要があり、どちらも片手落ちでは一方的な話に陥る危険性を感じます。 私の理想論を語らさせて頂けるのであれば、 みずみずさんの仰る「上流・下流の区別をしない」を 組織、企業、工程間の利害関係を一致させるマネージメントの話とし、 プロジェクト内のメンバーが組織や会社の立場を超え協調し合える関係を作る為に、 それぞれの利害関係を見直す考えも必要と考えます。 つまり、ＩＴのサプライチェーンです。 その時、「柔軟な開発プロセス」はより一層の効果を発揮出来ると考えます。 | ||||||||||||
|
投稿日時: 2004-03-08 12:10
どもも、がるともうします。
ちょいと先週バタついていて見逃していたので、遅れ馳せながら。 非常に個人的主観的な意見ですが :-P
これについては私は「違う」と思います。 もうちょっと正確には「上流工程の改善が必要なもの」と「それ以外の改善が 必要なもの」の双方が存在していると考えています。
ん〜、これについては「そうだなぁ」と納得する部分も多々(苦笑 正確には「現場を無視した上流工程の議論」が多いように感じるのは私も 同感です。 実際には「現場ありき」だと思うのですが。 ただ、見方を変えると「現場を意識した上での上流工程の議論」は 非常に有益であると考えています。
んと、「上流工程によって改善が見込めそう」な内容は ・残業200H/月以上の人がいる スケジューリングの改善でなおる(かもしれない) ・大規模化(人員面，コードサイズ) 事前設計を見誤らなければ途中でいきなりサイズが膨れ上がる、 という自体は避けられる場合もある ・納期短縮 上流工程というよりはさらにその手前の「営業レベル」の 問題って気もしますが… ・顧客要望の変化へ対応 「変更に強い設計」というものが存在します ・運用コスト削減 これも「運用コストを見据えた設計」が。 ・余剰要員 これもまぁ「スケジューリング」部分でのミスがなければ大分 回避しやすいですね。 一方で「上流工程による改善以外の」部分としては、結局「各個の スキルの上昇」ってのが少なからず出てくるか、と。 この場合のスキルは単にコーディングのスキルだけではなく、管理 スキルや学習スキルなど色々な意味合いを防ぐのですが。 基本的に問題点は常に多岐にわたるので、個々について別々に 分析/解決をしていくのが一番かなぁ、と。 ただ、多くの、特にSOHOさんとかそういうレベルのところを見ていると、 確かに「コーディングスキル」に対して「設計スキル」への意識の薄さ を感じるところは多々あります。 かつ、コーディングスキルは「そのまま実践に」使うことができることが 多いのですが、設計スキルはさもすると「実践とはかけ離れた学術的理論」 に始終一環してしまい、結局のところ「机上の空論を振り回す学者」と 「力技で片付けていく現場」という状況に陥ってしまい。 そういう意味で「現場で有効に用いることが出来る」上流工程の議論 というのは、確かにいま非常に重要なのではないかなぁ、とか 思っております。 そういう意味で、IT Architectが「現場の現場による現場のための」 上流工程への考察が出来る場所になればなぁ、とか思っております。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.