＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
上流工程改善が注目される理由について
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-03-03 02:00
はじめまして。素人ながら投稿させていただきます。
IT Architect設立の広報ページに次の1文があります。 『「ソフトウェア開発の危機」へ最も対処が急がれる分野が、分析・設計に代表されるソフトウェア開発の「上流工程」にあるとの観点』 ソフトウェア開発の危機を早期に脱するために，まず上流工程の改善が必要という結論は，既に多くの議論の下に結論付けられたものなのでしょうか？ 私はベテランと呼べるほど経験豊富ではありませんが少し疑問を感じます。 同様なテーマの講演会などに参加しても，設計や分析など上流工程の議論が中心であり，ますます開発現場から遠ざかっている気さえします。 とは言え，私は断言できるほど的確な意見を持ち合わせていません。 そこで，皆さんのご指摘，ご意見などを伺いたいと思っております。 よろしくお願いします。 | ||||||||
|
投稿日時: 2004-03-03 02:19
すみません。自己レスです。
開発プロセスについてもさまざまな議論が行われていますので，その点は承知しております。開発プロセスそのものの近年の動きについては，私も納得できる点が多く実践投入を含めて興味あるところです。 ただし，『「ソフトウェア開発の危機」へ最も対処が急がれる分野が、分析・設計に代表されるソフトウェア開発の「上流工程」にあるとの観点』となると，少し疑問を感じるもので，その点でご意見をいただけると幸いです。 よろしくお願いします。 | ||||||||
|
投稿日時: 2004-03-03 07:50
上流工程（業務分析、要件定義）が失敗していると、開発の後半に入って「やっぱこの機能いらないから、こっちをできるようにしてよ。簡単でしょ、2〜3日でできるよね？」とか「実はこの業務はこうじゃなくて、かれこれこういうことなんだよ。」いわれて、いきなりやり直しになるからでしょう。変更は突っぱねるべきだ、とかよく言われますが、何だかんだ言ってもお客さんとは継続してお付き合いしたいので、弱い立場であるシステム屋は要望を聞きとどけざるを得ないのが現状です。
とまぁ、結局のところシステム開発の成功は最終的にお客さんがどれだけ満足してくれるかにかかっているので、早い段階で現実に即した正しい業務分析と要件定義を行うことが重要なわけです。（逆に納品したシステムがぼろぼろでもお客が満足すれば成功です。）上流工程が失敗したためプロジェクトが失敗した割合のほうが、技術がなくて失敗したプロジェクトよりもはるかに多いはずです。（少なくとも私はそうです。） | ||||||||
|
投稿日時: 2004-03-03 08:42
unibon です。こんにちわ。
カスタムアプリケーションかパッケージで、異なるだろうと思います。 いわゆる○○社向けシステムのようなものだと、労力の大半は上流工程になりそれに比べれば下流などはさしたるものではないのではないでしょうか。 一方、パッケージのようなものは、上流も大事ですが下流も大事でしょう。 しかし、エンジニアの人口の大半はカスタムアプリケーションに従事しているので、上流が重視されるのでは、と考えます。 | ||||||||
|
投稿日時: 2004-03-03 09:59
るぱんです。
ちょっと穿った見方をしています。 ◆カスタムの場合 目的：業務を効率化 期待：業務を正確に反映出来るように作成して欲しい。 備考：現在の「現場の人・物・金・情報の流れ」が正しいかどうかからスポットを当て、 よりよい方法探したい。 開発：「顧客企業の関係者」協力の下、仕事を請負った企業 ◆パッケージ 目的：汎用化された商品（概念）の普及 期待：概念を普及する事で便利な考え方を啓発 備考：コンセプト重視、特定状況ではなく汎用→初心者には敷居が低い 開発：発売元企業 それぞれ開発がはじまると子受け孫受けが出ます。 カスタムとパッケージでは次の点の違いが出ると思います。 ★カスタムをメインに書きます。 システムを理解してない人が発注に回る事から、 意思の疎通の齟齬が噛み合わない。 顧客が自分のしたい事を表現しきれていない。 顧客が自分のしたい事を表現しきれていない事から、 機能をたくさん詰め込んでしまえと言う発想。 →どれかで必ず満足できるだろうという親受け企業の満足感 より上流へ行けば何とかできるのではないだろうか？ ★パッケージをメインに書きます。 システムを多少理解している人が発注企業である。 何かしらの仕様書を作ろうと言う雰囲気は有る。 かといって、デスマーチが無いわけではない。 つまり、上流企業にいわゆる「出来る人」が行けば行く程、 下流工程は安定する。 →上流工程へ行け 個人の観点から見ても、上流のほうでもまれれば何かしらミスをしても誰かが後で フォローできるのではないかと考えてるからではないでしょうか？ でも、これは落とし穴があると考えてます。 「出来ない人」が上流に行ったところでトラブル引き起こすだけなので、 意味が無いと思うからです。 上流工程へ行け・・・ではなくて、「出来る人を」正しく「評価」する人がいない と言うのが一番の問題だと考える次第です。 「出来る人を」正しく「評価」できれば、 「出来る人」は勝手に上流を目指すと思うんですよね。。。 あぁ・・・またひねくれてる・・・。（涙） | ||||||||
|
投稿日時: 2004-03-03 11:10
はにまるです。
私もベテランではなく、ＳＥでは若い方と思いますが．．．（本当に？） 先投稿文書と被りますが、 １．システム開発で利益ロスを排除する考え。 実装工程の効率化なぞ一発で吹き飛ばす程、 御客様の企画を含め上流工程のミスは大きいです。 人月で吹っ飛びます．．． 
開発工程のみを商いとしとしているソフトウェアハウスでも ベンダーから「設計工程からやって見ない？」と言われたら躊躇すると思います。 設計能力が無いよりも、責任とリスクの問題として．．． ２．個々のシステムの投資額が下がった事による要因 システムのライフサイクルの観点で、全コストを考えた場合、 企画や初回設計が重要視されるのは、システムだからというより 製品（ＩＴ企業）及び道具（ユーザ）として必然と考えます。 ３．システム用途の高度化 コンピュータ・システムが「単純作業効率化」の道具から 「業務効率化」、「企業情報管理」、「全社効率化」の道具へと用途が高度化し、 ユーザ自身もシステム要件を掴み難くなっている為、 何を作りたいのか不鮮明に成って、要件不一致が多発している。
私は、逆と考えています。 今まで、全体的に無駄な作業をしていても各工程、各企業で利益を生み出せる程、 システム開発は非効率であったと考えます。まさしくゼネコン。 発注額が下がった当初、責任転換し易い実装工程（実装企業）へ生産性を求めていたが、 実装工程の生産性は日々、上がっており、 ボトルネックは上流工程や上流企業に存在した事を認め出した結果と考えています。 つまり、「開発現場と近づいた」と考えます。 商売として考えた場合、 世間は上流工程から話をしていますが、 実装工程から全体工程を見なおすアプローチもありと思います。 | ||||||||
|
投稿日時: 2004-03-03 11:13
藤村です。私の署名で書いたリリースについてですので、簡単なコメントを以下に。
みずみずさんに投稿いただいた2つのコメントの趣旨を、「分析・設計の理論が重要なのではなくて、もっと現場に近い議論が重要なのではないか」と受け止めました。 私は専門家でもなく、またなにかの権威に頼った返答をするつもりもありませんので、私なりに素朴に書かせていただきますね。 私は“開発の現場”を重視するからこそ、開発の出発点で顧客要求（デマンド）の分析と確定、それを満たす設計・それを実現する開発方法と設計を用意していくことが重要なのだと認識します。 詳細設計を、実装を、そしてテストから運用といった、それぞれの“現場”に従事する方々にとって、現在、なにが大変なのか、なにが正されると嬉しいか...などをそれなりに考えてきたひとつの結論のつもりでもあります。 こう書いても「現場から遠く離れた議論」と響くでしょうか? そう思われないことを願います。 もちろん、だからといって「設計・分析上記以外は重要ではない」などと主張しているつもりは毛頭ありません。 開発という全体プロセスで最も進化の遅れている部分は、いまどこなのか、どこを攻めると全体最適が進むのかと問いたいと思っています。 その仮説が「設計・分析が弱いのではないか」と受け止めていただければありがたいです。 そのような観点で情報を追いかけていきますので、これからも「IT Architect」をぜひご注目ください。 _________________ アイティメディアの藤村からでした。 | ||||||||
|
投稿日時: 2004-03-03 13:23
To:みなさま
ご意見ありがとうございます。 予想以上に多くの方のご意見をいただきまして，大変感謝しております。ある程度は返答内容を予想していたのですが，それ以上のご意見大変参考になります。 確かに多くの方が仰るように，最初のステップのベクトルが方向違いだったりしたときの影響と言う点で，分析・設計の議論が重要であるとは認識しております。 以下，一部引用させていただきます。(って，どうやって引用するんだっけな･･･(汗）)
いいえ。そこまで現場から離れているとは言っていません。 私の意見を書かなかったので誤解を招いてしまったかもしれません。申し訳ありません。 顧客の要望が開発中に変わると言うのは疑いの無い事実だと思います。それに対応できる設計方法を私も望んでいるので，「IT Architect」は大変有意義だと思っています。今後も注目したいです。
実は，私はるぱんさんのご意見に共感するところがあります。 問題が発覚しやすい下流工程は，外注先が担当していることは良くあります。外注先からすれば，上流工程のしわ寄せを繕うことになるようなものです。逆に，外注先から進捗があがってこないだとか，報告が正確でなく納期間近で問題が発覚することもあります。このような点はCMMなどが浸透していけば改善されるかもしれません。しかし決定的な解決になるかどうかは疑問ですが，どうでしょうか。 私はXP信者ではありませんが，むしろ上流・下流の区別がソフトウェア開発の危機を導いていると言えないだろうかと考えています。(どこから上流で下流？という話もありますが) その観点で，XPのような悪く言えば「ごちゃごちゃ」した開発プロセスに興味があるのですが，大規模開発には不向きであることはよく指摘されます。顧客に応じて敏捷に対応できるところに利点があると思っているのですが・・・・。（最終的にはコミュニケーション能力だとも思っています。） 長文失礼しました。 追伸： アットマーク・アイティ藤村さん＞ かえって失礼な投稿で申し訳ありませんでした。@ITは毎日利用させていただいております。今後も活用させていただきます。どうぞよろしくお願いします。 ちなみに，私は日高在住です。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.