- - PR -
セル生産方式は大規模ソフトウエア開発に適用可能か？
1
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2003-07-18 00:17
カメラやパソコン等の製造の現場ではライン生産方式(ベルトコンベア生産)からセル生産方式への転換が行われある程度の成果をあげています。セル生産方式とは屋台方ともいい、一人もしくは少人数で１つの製品の全工程を担当する方法で、作業者のやる気がでる、商品のカスタマイズが可能(カスタムメイド)、仕掛品が減る、完成品在庫が減る、ライン式で発生するボトルネックが生じない等のよい点があります。
そこで思ったのは、現在、上流工程、下流工程で担当者を分けるのが主流の大規模システム開発において、このセル生産方式を適用することはできないかなと思いました。 大規模システム開発においてのシステム開発のパターンは元請が上流の要件定義、設計等を行い、下流工程のPGを単価の安い外注に出します。しかしながら、この方法は旧来のウオーターフォールには適したやり方ですが、昨今取り入れつつある、RUP等のイテレーション型ではどうも無理があります。UMLなどではクラス図とコーディングがラウンドトリップで開発できますが、これが有効なのは上流も下流も一人で担当する場合です。 J2EEでの開発ではフレームワーク等の利用によりかなりPG部分の負荷が少なくなってきたため、JSPからサーブレット、セッションビーン、エンティティビーンをユースケース単位で一人で完成させることもまんざら夢物語ではないと感じます。 | ||||
|
投稿日時: 2003-07-18 17:21
判断が難しいと思うのですが。
システム開発といっても昔からプログラミングレベルではある意味で「セル生産 方式」になっていますよね。ウォータフォールであれスパイラルであれプログラ ミングの段階では「あるひとりの人がある範囲を生産する」という形で。 ただその範囲が、クラスや関数単位、画面単位、機能単位、サブシステム単位、 システム全体なのかという面で規模により変わってくるのが現状だと思うのです。 ただシステム開発とハードウェア生産で言うセル方式と違うのは、ハード ウェアのセル生産というのは隣で作っている生産物と自分の生産物はあまり関係 を持たない場合が多いです。つまりカメラ１台を一人の人がセル生産で作成する 場合、隣で同じようにセル生産している人の作るものは別のカメラだということ です。（ただ部品をセル生産する場合、次の組み立て会社のセル生産とは関連す るのですが。） 一方システム開発の場合、大規模であれ小規模であれシステム（製品）としては ひとつのものを作るという面があって、同じ物を複数の人が作ることはあまり無 いと思われます。ですからセル生産で作成されたものはすべて何らかの関係が持 たれることになります。ですから、関係性を持つことはある人の生産の遅延等が 他の人のスケジュールに影響するということになるので、これではセル生産とは 呼べないですよね。 つまり、あえてシステム開発にセル生産方式というものをあてはめるというのは 何かかなり無理があるように思えるのですが。 | ||||
|
投稿日時: 2003-07-18 19:19
Beatle様
ご意見ありがとうございます。だれも反応してくれないと思ってました。 私の文章が少しおかしかったのですが、上流と下流、つまり設計と実装を一人で行うか、設計と実装が別の人物もしくは別の会社で行うか、どちらがよいのか(もちろん顧客にとってでSIerではありません。) 小規模なショッピングサイト程度ですとひとりで要件定義からテストまで行いますが、大規模開発でもユースケース単位に分けることで可能なのか？ということです。 たしかにいくらユースケース単位でも共通部品とか依存関係がありますのでうまくはいかないと思いますが。 | ||||
|
投稿日時: 2003-07-19 01:10
工場のライン生産方式はなぜ産まれたんでしょう？
セル生産方式はなぜ見直されてるんでしょう？ ライン生産方式における分担と、システム構築における役割分担とは 目的が違うのではないかと思います。 効率を目的にしているために同じ作業を並列で行っているのか、 全体が大きすぎて個人では作業ができないから分担しているのか。 プリンスさんは要件定義からテストまでと書かれていますが、セル生産方式では それはそれぞれどのあたりでしょう？ 私の考えでは、比較できるフェーズがないんじゃないかと。 | ||||
|
投稿日時: 2003-07-19 11:30
まりり様
なるほど。セル生産方式では実装フェース(組み立て)しかやってないわけですね。 ということはやはり設計者と実装者は切り分けるのがベストでしょうか？ ただ、セル生産方式では旧来の単能工から多能工へ、個々のスキルアップが要求され、組み立て段階で感じた設計の矛盾点のフィードバックやクラフトメード的な職人的発想が要求されます。中国やインドにおける単価の低いソフトハウスに打ち勝つ意味でもなにか日本のゼネコン的工程別開発プロセスとでもいうのでしょうか？なにか、新しい方法はないものかと日々考えています。みなさんも今のやり方では日本の未来は無いと感じてますよね？そんなことない???何かいいアイデアがありましたら教えてください。 | ||||
|
投稿日時: 2003-07-19 13:17
> ということはやはり設計者と実装者は切り分けるのがベストでしょうか？
というのはまた結論が早いかという気もしますが。 私が言いたかったのは目的が違うものは適応できないのではってことだけです。 現在のディスクリート製造業のプロセスがシステム開発のプロセスに応用できないかと いうことはぼんやりと考えています。 システム開発における実装フェーズというのは実際には試作くらいのフェーズじゃ ないかという印象も持っています。 どこかでコンパイルくらいが工場のラインに相当しそうだと読んだ記憶があるのですが、 元はどこだったか・・・ システム開発なんて高々20年30年程度の歴史しかないのですから、他の業種に学べる ところはあるのではないかなとは思います。 | ||||
|
投稿日時: 2003-07-19 13:24
unibon です。こんにちわ。
セル生産方式との対比として言われるライン生産方式のベルトコンベアの流れは、 見かけはたしかに直列的ですが、 これは、部品を組み合わせて作る製品の流れが直列的なだけであり、 これをソフトウェアの生産に当てはめるのはギャップがあるように感じます。 ベルトコンベアの上流でおこなう作業の抽象度が高くて、 ベルトコンベアの下流でおこなう作業の抽象度が低い(具象化されている)、 ということは必ずしもないと思います。 たとえばプラモデルで部品を接着する順番が、 部品の抽象度に依存するわけではなく、 おもに部品の物理形状の内包関係で左右されるのにたとえられると思います。 ベルトコンベアに載せられたものや、屋台に置かれたものは、 ソフトウェアでいえばもうすでに実装が済んだモジュールであり、 そのようなライブラリファイル的なものはいくらでもコピー可能ですから、 どっちのやりかたでやるかという違いはそう大きくないと思います。
以下、漠然とした考えですが、 ソフトウェアの世界ではこれに対応するのは、上記の利点を多く含むものとして、 ペアプログラミングかもしれません。 でもペアプログラミングだと2人に増えてしまいますね。 
| ||||
|
投稿日時: 2003-07-19 22:23
セル生産方式云々の話とは別に、
>上流と下流、つまり設計と実装を一人で行うか、設計と実装が別の人物もしくは >別の会社で行うか、どちらがよいのか という点に関してですが、どちらがよいかと言われると答えが出ないと思います。 まず、上流と下流を設計と実装と定義されているようですが、なかなかそうはいか なくて、設計にも論理設計、実装設計等の分かれ目があることもあります。 また、業務系のシステムと制御系のシステム、ゲームソフトの開発等でもかなり工程 も異なるし、上流、下流の定義もかなり変わるのではないでしょうか。 でも実際には、基本設計までＡ社、詳細設計以降はＢ社というような体制のプロジェ クトも数多くあります。（うまく行かない場合も、成功する場合も） もっと大規模になると、コンサルテーション、ＳＩ、基本（論理設計）、実装という 単位で別々の会社があたることもあります。 で、良いか悪いかということではなく、それぞれの事情（売り上げ、パワー等）に よってどうするかというのを決定するというのが現実的ですね。 具体的に言えば、すべてをこなせる人材（能力）、人数、経験と最大のリスクに対し ても対応できる経営基盤が合致すればその案件は自社ですべてを引き受けても良い と思いますが、どこかが欠けているのであれば補うために他社に出すしかないという ことです。 それと大規模なシステムになると上流の方が売り上げ的には低くなります。確かに 単価は高いのですが、実装部分に大量な人数と期間を投入したときの売り上げとを 比較すれば、やはり後者のほうが売り上げは高くなります。（利益は別として） ですから、超上流を専門としているようなコンサル会社でも開発に手を出したくなる のですね。 まぁそういう事情はともかく純粋に考えると、私見ですが、ある条件で上流と下流は 分かれる（別にするべき）と思っています。（他社になる場合もあるし、自社でも別 部門等の何らかの区別があると。）それが一人の頭の中でこなせるとかこなせないと かの問題ではなく、たとえこなせたとしても分けるべき時は分けると。 それがどのような条件かと言われると難しいのですが、［システム要件］と［規模］ という２つの次元のかかわりであると私は思うのですが。（数値化するのはすごく 難しいので．．．） | ||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。