メルマガ ソフトウェア業界 新航海術 |
ホーム |
バックナンバー |
2010年のシステム開発 |
航海術 |
||
バックナンバーの全文検索 全バックナンバー(古い号が先) 全バックナンバー(新しい号が先) ●:5年後のシステム開発 ●:ブルックスの法則 ●:グーグルの衝撃 ●:保存できないエディタ |
●:製造業の呪縛 ●:請負と派遣 ●:永久運動の設計 ●:大きくなるか、小さくなるか ●:ゴーイング・コンサーン ●:金持ちソフト会社、貧乏ソフト会社 |
●:経営の基準となる数字 ●:借入れと連帯保証 ●:ソフトウェア振替という麻薬 ●:賃金決定の仕組み ●:SE・プログラマの資質 ○:その他 |
************************************************************** _/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/ ************************************************************** 第72号 2005/04/25 ▼ まえがき ▼ [保存できないエディタ] ウォータフォール型のまとめ(計画・設計) ▼ [保存できないエディタ] ウォータフォール型のまとめ(製造) ▼ [保存できないエディタ] 仕様変更のコストは誰が負担するのか? ▼ [保存できないエディタ] ウォータフォール型に対する批判への反論 ▼ [保存できないエディタ] 低価格化・短納期化圧力とウォータフォール型 ▼ お奨めメルマガ情報 ▼ 次回以降の予告 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= まえがき *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= こんにちは、蒲生嘉達(がもう よしさと)です。 第57号から「まぐまぐ!」での読者数が急に増えてきました。 第56号までは200名だったのに、今では354名です。 読者も「日本のソフトウェア請負開発は何かおかしい」という思いを お持ちなのだと思います。 第57号を書いたときは3,4回のシリーズにするつもりでしたが、 請負契約や開発プロセスについては話題が尽きず、今回でシリーズ 16回目となります。 「5年後のシステム開発」シリーズから独立させて、「保存できない エディタ」シリーズとしました。 まとめて読みたい方は下記URLを参照してください。 http://www.kei-it.com/sailing/back_editor.html 本メルマガの内容に興味を持つであろう方をご存知なら、是非 本メルマガの存在を教えてあげてください。 (以下をそのまま転送するだけです。) --------------------------------------------------- 【お勧めメルマガ ソフトウェア業界 新航海術】 ⇒ http://www.mag2.com/m/0000136030.htm または http://www.kei-it.com/sailing/ --------------------------------------------------- *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= [保存できないエディタ] ウォータフォール型のまとめ(計画・設計) *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 長かったこのシリーズもいよいよ、まとめの段階となりました。 あと2,3回、おつきあいください。 本号では、ウォータフォール型開発プロセスについてまとめてみます。 図 http://www.kei-it.com/sailing/pdf/72-050425.pdf を参照し ながら読んでください。 ウォータフォール型開発プロセスでは、次に示すように、計画・設計・ 製造を明確に分割して開発を行います。 【計画】 まず最初に、ユーザと請負業者は協同で要求仕様をリストアップし、 凍結します。 この作業は必ずしも請負契約によるものではなく、業者からの営業提案 として無償で行われる場合もあります。 【設計】 次にユーザと請負業者は仕様設計のための請負契約を結びます。 仕様設計は、外部設計・内部設計・プロトタイピングにより行われ、 それらは並行して行われます。 外部設計はユーザの視点で製品を記述する作業、内部設計は製品内部の 仕組みを記述する作業です。 外部設計と内部設計については、第68号を参照してください。 http://www.kei-it.com/sailing/68-050328.html プロトタイピングは、第69号を参照してください。 http://www.kei-it.com/sailing/69-050404.html 上記作業によって完成した仕様を顧客がレビューし、それらの検収、 署名(日本では捺印)後に、請負業者は製品の製作費用について見積もりを 作成します。 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= [保存できないエディタ] ウォータフォール型のまとめ(製造) *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 【製造】 ユーザと請負業者は製造に関する請負契約を結びます。 その内容は、設計作業で完成した仕様どおりに請負業者が製品を作り、 ユーザがその対価を支払うというものです。 その際、受け入れテスト項目を契約で規定しておきます。 (受け入れテスト項目の詳細までは必要ありません。) 請負業者は、詳細設計、コーディング(ホワイトボックステストを含む)、 ブラックボックステストを行い、製品を完成させます。 これらの手順は請負業者に任せられます。 製造を、詳細設計、コーディング、テスト計画書作成、テスト仕様書作成、 ・・・という具合に細かく工程を区切り、工程の単位でドキュメント を完成させ、各工程が終了してから次の工程に進むというやり方でも 構わないし、Cem Kanerが「基本から学ぶソフトウェアテスト」で強く 薦めているように、プロジェクト全体としてはウォータフォール型で あってもブラックボックステストは漸増型風にやるという方法でも 構わないのです。 プロジェクトの難易度・納期・予算・人的リソースなどを考慮して、 プロジェクトマネージャが決めてよいのです。 ウォータフォール型をウォータフォール型たらしめている最大の 特徴は、「製造前に仕様設計が完了している」です。 それさえあれば、製造以降を部分的に漸増型風に進めても、プロジェクト 全体としてはウォータフォール型だと言えるのです。 そして、製造前に仕様設計が完了しているが故に、その完成仕様に基づく 請負契約が可能となり、ユーザによる最終受け入れテストが必須となる のです。 最終受け入れテストについては、第71号を参照してください。 http://www.kei-it.com/sailing/71-050418.html *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= [保存できないエディタ] 仕様変更のコストは誰が負担するのか? *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 「ウォータフォール型では製造前に仕様設計を完成させる」と言っても、 設計フェーズで完成された仕様が、製造フェーズで変更になり、手戻り が発生することはよくあります。 この手戻りのコストは、設計承認した以上、発注者が負担しなければ なりません。 ただし、その仕様変更が設計時の仕様バグによるものであるなら、 請負業者は設計フェーズの請負契約についての契約責任(瑕疵担保責任) を問われる可能性があります。 しかし、そこで求められることは、設計書を無償で書き直すことであり、 コーディングのやり直しまで無償で行わなければならないということ ではないのです。 仮に、それが非常に重大な仕様バグであり、損害賠償を求められた としても、その損害賠償額は設計の請負のために既に支払われた金額を 超えることはないでしょう。 したがって、第57号の設問の答えの半分は、「ウォータフォール型で 行われたのなら有償追加」なのです。 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= [保存できないエディタ] ウォータフォール型に対する批判への反論 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 仕様変更は必ず発生します。 上流工程で下流工程の全てを見通すことは不可能だからです。 そして、ここから「ウォータフォール型は製造前に仕様設計が完了する ことを前提としているから非現実的だ」という批判が生まれます。 しかし、確かに上流工程で下流工程の全てを見通すことは不可能ですが、 全てがやってみないと分からないということもありません。 見通そうとすれば見通せる部分も大きいのです。 ウォータフォール型開発プロセスとは、ユーザと請負業者に先を見通す 努力を強制する仕組みでもあるのです。 また、「ウォータフォール型はプロジェクトの最終局面にならないと ユーザが完成イメージをつかめないが故に、仕様変更が多発する」 という批判もあります。 しかし、だからこそ、設計時にプロトタイプを作成し、早期にユーザに 完成イメージを提示するのです。 また、「ウォータフォール型はプロジェクト後半にならないとテストを 開始できず、テストと修正の工数が予測できない」という批判もあります。 しかし、ホワイトボックステストはプログラミング工程の一部として 行えばよいし、ブラックボックステストもインクリメンタルに行えば よいのです。 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= [保存できないエディタ] 低価格化・短納期化圧力とウォータフォール型 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= グローバル化と標準化に起因する強烈な低価格化・短納期化圧力が 存在します。 (第8号 http://www.kei-it.com/sailing/08-040126.html 参照) そして、ウォータフォール型はこの強烈な低価格化・短納期化圧力に 対応できないという批判もあります。 確かにこれらの圧力に対応する一つの方向は、現在マスコミが喧伝 しているアジャイルやセル方式などかもしれません。 しかし、もう一つ、「得意分野に特化した会社同士の効率的な分業」 という方向もあります。 そこには、国際的な分業、つまりオフショアも含まれます。 そして、会社間の請負契約による分業には、本号で解説した柔軟で 正しいウォータフォール型開発プロセスが不可欠なのです。 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= お奨めメルマガ情報 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 読者の末富昌幸氏から「実は、私もこのたび、下記のメルマガを創刊 しました」というメールをいただきました。 ◆●◆ 中国オフショア開発最前線-中国ソフトウェア産業の実像 ◆●◆ 中国でのソフトウェア開発をお考えの方、悪戦苦闘中の方は必見! 本メルマガでは、中国ソフトウェア産業の実像に迫る情報や中国オフショア 開発に関する生きた情報、成功ポイント、契約・交渉実務関連情報、中国 現地企業の人材育成情報等々を満載して、上海現地からタイムリーにお届け しています! 中国オフショア開発サポートサイト→http://www.jp-snic.com 中国オフショア開発Q&A50問50答→http://www.jp-snic.com/q&a/Q&A.html 購読登録はこちら→http://www.mag2.com/m/0000153053.html 先に書いたとおり、私は強烈な低価格化・短納期化圧力に対応する 一つの方向としてオフショアは大きな可能性があると思っています。 また、ここのところ日中関係が緊張しているので、私も最近は新聞を 読んでもまず中国関係の記事に目が行ってしまいます。 実際に中国で活躍されている末富氏からの中国情報は非常に参考に なります。 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 次回以降の予告 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 次回以降は下記の項目について書いていきます。 ・漸増型開発プロセスのまとめ ・「全体がウォータフォールでもテストは漸増型で」の詳細。 ・納品時の最終受け入れテストはどうあるべきなのか、検収とは何なのか。 ・オーダーメイド開発の多い日本での漸増的開発はどのように考えたら よいのか? 次号は、5月2日発行予定です。 乞うご期待!! *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 本メルマガについて *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 本メルマガは2003年12月8日に創刊されました。 創刊号 http://www.kei-it.com/sailing/01-031208.html で述べたとおり、 本メルマガのコンセプトは「読みものとしても面白い慶の事業計画」であり、 目的は「事業計画の背後にある基本的な考え方を語ること」です。 したがって、第一の読者としては、慶の社員(正社員・契約社員)及び 慶と契約している個人事業主を想定しています。 彼らには慶社内のメーリングリストで配信しています。 また、多くのソフトウェア会社・技術者が直面している問題を扱っているので、 ソフトウェア会社の経営者、管理者、技術者にとっても参考になると思い、 第33号(2004年7月19日号)からは「まぐまぐ!」で一般の方々にも公開する ことにしました。 このメルマガに対するご感想・ご質問はこちらにお寄せください。 office@kei-ha.co.jp -------------------------------------------------- このメールマガジンは『まぐまぐ!』 http://www.mag2.com/ を利用して 発行しています。配信中止はこちら http://www.mag2.com/m/0000136030.htm (但し、web@kei-ha.co.jp it@kei-it.com には直接配信しています。) 発行者Webサイト: http://www.kei-it.com/sailing/ (発行者Webサイトではバックナンバーの全文検索も可能です。) -------------------------------------------------- 発行: 株式会社 慶 代表取締役 蒲生 嘉達 y_gamou@kei-ha.co.jp Webシステム開発事業部 http://www.kei-ha.co.jp ITサービス事業部 http://www.kei-it.com 人材コンサルティング事業部 http://www.k-bank.jp TEL:03-5951-8490 ☆ コピーや配布をされる時はご一報ください ☆ |
|
(c)Copyright Kei Co.,Ltd All Right Reserved |