なぜ、ソフトハウス業は、超小規模企業のほうが、小規模企業より一人月売上高が高いのか？
http://blog.goo.ne.jp/xmldtp/e/9e7ff36b8ca009b8e4ee853c9a564a22
のアクセスが多いので、これに関するコメントを１つ。
上記エントリは、結局
「下請けだと単価安い」
「直接契約だと、発注元が小企業でも、下請けより単価高い」
ということを言っている。
そうすると、
「じゃあ、みんな、直接契約を取ろう！下請けからの脱却！！」
と思うかもしれないが、これは、実は難しい。
理由は３つ
１．（根本事情）
日本では、大規模システムを一貫して構築する方法を
学校でも、企業でも教えていない
２．（発注側の事情）
直接契約の場合、そもそも、誰に発注していいか分からない
３．（受注者側の事情）
中小企業は、SES・派遣などで毎月お金が入ってこないと回らない
以下、順番に見ていく
■1.日本では、大規模システムを一貫して構築する方法を教えていない
Webサイト程度であれば１人で構築できる。
したがって、受注システム、発注システム単体であれば、２００～３００万
程度でWebで作成可能である。
しかし、もっと大きい、（たとえ中小企業でも）１社全体のシステムの
開発となると、
・要件定義
・設計（外部・詳細）
・実装
・テスト
を一貫して行わないといけない。これを全工程一貫してできるという理論を
日本ではだれも教えていないし、全て分かっている人を見つけることも
とてもむずかしい。
企業において、トレーサビリティマップというのに、これが書かれている（ということになっている）が、
このトレーサビリティマップは社外秘になっている。そこで、どのように
一貫性を保っているのかは、ちょ～極秘事項だ（本当は、ないのかも？）。
この結果、日本では
・要件定義書を書ける人は居ます
・要件定義書が出来れば、設計が出来る人は居ます
・仕様書があれば、プログラミングできる人は居ます
・プログラムと仕様書があれば、テストできる人は居ます。
でも、全部を一貫して分かっている人はいません。
出来る人もごくわずかです。
なので、指示を出す人はテキトーに出しているか、丸投げです。
モレやヌケ、変更は、（一貫して分かっていない＝何が必要かわかっていないのだから）
当然、出ます。
もちろん、
・海外では、要件定義をゴール指向分析のKAOSで行った場合、
それをUML等に落とす方法は知られています。
→Lamsweerdeの
Requirements Engineering: From System Goals to UML Models to Software
に載っている。その本は、翻訳されていないし、大学ではこの方法は教えていない。
海外の大学では教えているらしく、大学でのプレゼンらしきものが、ネットで落ちている
・UMLに落ちれば、プログラミングの雛形まではいく
→
UMLシステム設計実践技大全―アッと驚く達人の技
しかし、これだけだと、プログラミングは出来ない。
理由は
・UMLは、クラス図でクラス名、アトリビュート、メソッドが確定する。
そしてシーケンス図でメソッド内で、どのメソッドを呼び出すかが確定する
→シーケンス図で呼ばれる側（メッセージを受信するほう）に呼ばれるメッセージ
ごとにメソッドを作成すると、メソッド呼び出しが確定する・・・
・・・って、何かいてるか分からないか、今度説明する。
・しかし、メソッドの呼び出しが確定するだけで、そのメソッドの引数（メッセージ）
をどう組み立てるか、メッセージの返答（返り値）をどう組み立てるのかは書いていない
＝処理の方法は書いていない
・また、画面は分からない。パフォーマンスも作ってみないとわからない
つまり、非機能要件は、UMLには書いていない。
これらを分かった上で、要求には何が必要なのかを知っていて、それを聞き出し、
矛盾があったら調整して・・・ということが出来る人は、まず、ほとんど居ない。
今の日本では、要求仕様書が十分に出来ないと、以降の工程の人は、要求仕様書が出来ているのが
前提で動くので、なにもできない・・・
ってことで、「大規模システムを構築する方法」の前提となる要求仕様書をどうまとめるか
が分かっていないので、実際には、適当な割り振りと無駄な作業を繰り返し、なんとなく作っている
この状態では、分割発注は無理だ→これが分割発注に失敗する理由
■２．直接契約の場合、そもそも、誰に発注していいか分からない
今の議論から分かるとおり、ユーザーが要求仕様をまとめる人、設計をまとめる人、プログラミングする人
と分割して発注し、管理することは難しい（SIerはできるとは言っていない。SIerでも難しいが、そこには
採算がとれるカラクリがある。ただし、このカラクリが失敗することもあるが・・
ユーザー企業ではそのカラクリが使えない）。
逆に、誰か一人が開発できるわけでもないのは、上述の議論のとおり。
ってことは、誰にも発注できないことになる。
・・・となると、SIerさんに発注するのが、一番無難となる。
そうすれば、面倒なことはSierさんが、全てやってくれるから・・・
■３．中小企業は、SES・派遣などで毎月お金が入ってこないと回らない
・・・まわりません。はい。
ということは、完成したら検収して、９０日後に現金払いとかは、できません。
そこで、毎月お金を払ってくれる会社が入る必要があります。
それがSier。つまりSIerは、人材バンクであると同時に、本当に銀行機能も
持っているといえる。
ここでおしまい。
あ～宿題２つのこってますねえ・・・
シーケンス図とプログラムの関係と、
SIerが採算が取れるカラクリ・・・
（実は、見積もりを類似事例ベースでやると、これができる）
気が向いたら、いつか書きます・・・
アクセス
トータル
ランキング
