請負開発のあるべき論の不在

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第58号 2005/01/17
▼ まえがき
▼ [保存できないエディタ]　第57号の反響
▼ [保存できないエディタ]　技術書、マスコミのウソ
▼ [保存できないエディタ]　請負開発のあるべき論の不在
▼ [保存できないエディタ]　マスコミの論調とそれに反する声
▼ 次回以降の予告

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
まえがき
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

こんにちは、蒲生嘉達（がもう よしさと）です。

・IT Proに「“倍速開発”掲げるソフトハウスの慶、自社フレーム
　ワークを社外提供へ」という記事が載りました。
　http://itpro.nikkeibp.co.jp/free/NC/NEWS/20050106/154491/　参照。

・ソフト人脈1月25日号に、慶の「倍速開発」の記事と、慶が加盟
　しているコンソーシアム「羅針盤２１」の記事が掲載される予定です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　第57号の反響
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第57号について多くの方々からご感想をいただきました。
例えば、次のような・・・。

「次回1月17日発行号、楽しみにしております」(ソフト会社営業マン)

「面白かったです。中国オフショアで似たようなことがあったんですよ。
当然あると思っていた機能がなくて、それを指摘したら、『仕様書に
書かれていない』なんと言われてしまって・・・。」
(ソフト会社取締役)

また下記のご意見をメールでいただきました。

○汎用機系SEのKMさんのご意見

> 私の意見は、請負契約でのことであれば、
> 基本は有償追加に賛成します。
>
> 仕様を決めるにあたってどちらに落ち度があったとしても、
> 合意してハンコをついたら、それをオーソライズして動くのが
> 基本だと考えます。
> 現在の（日本の？）ソフトウェア業界（とユーザー）の社会認識・
> 哲学がそうなっていないのなら、それは変えていかなければならない、
> と考えます。
>
> 商売上、「競争社会を生き残っていく」うえで、無償追加をする人・
> 会社が目の前にいたとしたら、その振る舞いの頭から尾までを非難する
> ことは自分は出来ません。
>
> でもそれは、少し前のガソリンスタンドがバタバタと倒産していくにも
> かかわらず売値を下げていった道・発想と同じものだと考えます。

○ERPコンサルタントのHNさんのご意見

> 合意した仕様書に明記されない機能付加についてですが、
>
> このケースで言えば最善の方法は、仕様書作成の時点で
> SEないしコンサルタント等が保存の機能について、本当に
> 必要がないかユーザーに確認すべきだったと思います。
>
> ユーザーが仕様書（詳細設計）段階で仕様の漏れについて
> 指摘できることはそうそうないと思います。
>
> こういった行き違いを回避するためには、概要設計書で
> そのシステムの目的を、誰が読んでも誤解が起こらない
> 文章でまとめることが大切だと思います。
> そして開発者も含めて概要設計を読んで内容を理解して
> いれば、必要と思われる機能が漏れていることに気が
> つくことがあるかもしれません。これは経験が物を言う
> ところかもしれませんが。
>
> こういう部分で付加価値をつけて顧客満足を得ることが、
> 会社または個人への信頼となり、次の取引につながって
> いくのだと思います。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　技術書、マスコミのウソ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

見出しを「技術書、マスコミのウソ」としましたが、記事を書いている
人々には嘘をつく意図はないと思います。
また、書かれていることの多くは、それ自体は事実です。
しかし、全体的に情報が偏るから、情報を受け取る側が注意しないと
判断を誤る可能性があるのです。

情報が偏っている典型的な例として、汎用機の扱いがあります。

「世界中で動いているプログラムの70%は今でもCOBOLで書かれている」
と言われます。この数字の根拠は不明ですが、汎用機が今でも重要な
存在であり、多くの分野でUNIXやPCの挑戦を退けているということは
事実です。
しかし、インターネットでも書籍でも世の中に流通している情報の中で、
汎用機が占める比重は極端に少ないのです。
したがって、汎用機の重要性を過小評価してしまう危険性があるのです。

それが原因かどうかは分かりませんが、国産メーカのいくつかは
汎用機から撤退し、残りも積極的な投資をしなくなりました。
一方IBMは逆に、汎用機を強化し、PCから撤退しました。
その結果、汎用機の世界は再びIBM寡占状態に向かっています。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　請負開発のあるべき論の不在
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

汎用機に関する情報が極端に少ないのと同様、「請負開発」も技術書や
マスコミにはほとんど登場しません。

エンピリカルやアジャイルなどの開発方法論はインターネットでも
書籍でも無数に存在するのに、請負開発のあるべき姿についての考察は
ほとんど存在しません。若干あるとしたら、「請負契約書の書き方」
といった類であり、これらは請負開発全体の中で極めて限定した部分を
扱っているにすぎません。
例えば、「アメリカで請負開発はどのように行われているのか」と
いったことを調査しようとしても適当な資料がなかなか見つからないのです。
（第10号　http://www.kei-it.com/sailing/10-040209.html　参照）

日経○○の記事も、請負業者の視点ではなく、発注者の視点で書かれて
います。
開発段階では実際には請負業者が主導権を握り、多くの提案をし、
非常に苦労したとしても、それは記事にはならないのです。
システム開発を企画し、発注した会社名と担当者の顔が華々しく
載るのに対し、請負会社は名前すら載らない場合がほとんどです。

確かに請負会社は発注者の意思を実現する下請け業者に過ぎません。
もともと華やかな存在ではないのです。
しかし、請負開発のあるべき姿が技術書や技術系マスコミで論じられない
理由は、それだけではないと思います。

日本の技術書や技術系マスコミは、アメリカ発の技術情報に基づいて
書かれています。そのアメリカ発の技術情報のほとんどがパッケージや
商品の開発を前提としているということが、もう一つの理由だと思います。
アメリカは日本以上にパッケージや商品が重視されているのかも
しれません。
また、アメリカでの情報発信者は学者か企業にいる研究者であり、
彼らは請負開発という、契約や金が絡む非技術的で世俗的な分野は
書きたがらないのかもしれません。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　マスコミの論調とそれに反する声
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

私は第51号で、WEDGEの12月号の「ＳＥ、プログラマー150万人　
大失業時代がやってくる」という記事を紹介しました。
http://www.kei-it.com/sailing/51-041129.html　参照。

その記事の内容は端的に言えば「日本のシステム開発はウォータ
フォール開発プロセスを引きずっているからダメで、海外では新しい
開発プロセスを導入しているから生産性が高い」というものでした。
実は、これは今の日本の技術系マスコミの代表的な論調でもあるのです。

下記は日経コンピュータ12月13日号の特集記事「日本のソフト
開発力を取り戻せ」からの引用です。
（http://store.nikkeibp.co.jp/mokuji/nc615.html　参照）

> 大規模ソフト開発技術は、いまだにハードウェアにおけるコンベヤ
> 式生産を目指している。工程を分断し、一部外注するケースも多い。
> これでは顧客からの変更に対応しにくいうえに、品質の低下や
> コストの上昇を招きかねない。
> この問題の解決策として、組み立て生産工程で採用されている
> セル生産方式の考え方をソフト開発に応用する手法を提案する。

WEDGEよりも複雑な書き方をしていますが、要するにWEDGEの記事と同じく
「日本はウォータフォールだからダメだ」と言っているのです。

しかし、マスコミのこのような大きな声にかき消されそうになり
ながらも、それとは正反対の次のような声も聞こえてきます。

・海外でもウォータフォールが主流です。
（WEDGEの記事に反発したインターネット上の書き込み）

・ウォータフォール開発プロセスはユーザとの取引関係において
　不可欠なものである。
（Cem Kaner,Jack Falk,Hung Quoc Nguyen「基本から学ぶソフトウェア
　テスト」より）

・（中国オフショアでは）ドキュメントが「主」、プロトタイプは「従」。
（幸地司氏のメルマガ「新・中国ビジネス入門」より）
　http://www.ai-coach.com/backno/cip0144.html　参照。

・中国オフショアでは、日本のソフトウェア会社よりもアメリカの
　ソフトウェア会社の方が厳密な仕様書を作ります。
（中国オフショアを行っているソフトウェア会社のSEから聞いた話）

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第57号での有償追加派と無償追加派の対立は下記の重要な問題を
提起しています。

・請負開発で納品したプログラムは商品かサービスか？
・商品かサービスかによって保証の差はあるのか？
・ソフトウェアのバグとは「仕様に合っていないこと」なのか？
　それとも「エンドユーザが期待しているような動作をしないこと」なのか？
・製造前の仕様凍結を前提としたウォータフォール型開発プロセスは、
　請負開発において不可欠なのか？

考察は次号に続きます。

次号は、1月24日発行予定です。

乞うご期待！！

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
本メルマガについて
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

本メルマガは2003年12月8日に創刊されました。
創刊号 http://www.kei-it.com/sailing/01-031208.html で述べたとおり、
本メルマガのコンセプトは「読みものとしても面白い慶の事業計画」であり、
目的は「事業計画の背後にある基本的な考え方を語ること」です。

したがって、第一の読者としては、慶の社員（正社員・契約社員）及び
慶と契約している個人事業主を想定しています。
彼らには慶社内のメーリングリストで配信しています。

また、多くのソフトウェア会社・技術者が直面している問題を扱っているので、
ソフトウェア会社の経営者、管理者、技術者にとっても参考になると
思います。
したがって、第33号(2004年7月19日号)からは「まぐまぐ！」で一般の方々
にも公開することにしました。

本メルマガの内容に興味を持つであろう方をご存知なら、是非
本メルマガの存在を教えてあげてください。

（以下をそのまま転送するだけです。）
---------------------------------------------------
【お勧めメルマガ　ソフトウェア業界　新航海術】
⇒ http://www.mag2.com/m/0000136030.htm　または
　http://www.kei-it.com/sailing/　
　
---------------------------------------------------

このメルマガに対するご感想・ご質問はこちらにお寄せください。
　　　　　　　　　　　 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サイトではバックナンバーの全文検索も可能です。）