風の谷のナウシカは、ソフトウェア業界の間違いを指摘している（２）原作のほう

風の谷のナウシカは、ソフトウェア業界の間違いを指摘している（１）
http://blog.goo.ne.jp/xmldtp/e/3073cf80603c4919a59f7049b31eea0c

は、映画のほうのナウシカだけど、原作は、もっと、現在のソフトウェア業界
をあらわしているようだ！
そして、ソフトウェア業界にいる人なら、原作の最後の結論を理解しやすいとおもう。

---

（１）では、ナウシカ→ソフトウェア業界について、こういう変換をするのでした

風の谷は、多分中国辺境→コンピューター導入辺境

火の７日間→汎用コンピューターを無理やり導入しようとした

「むし」→　汎用コンピューターを「無視」したExcelを使っている従業員

巨神兵→汎用コンピューターの時代の生き残りの「情報システム部」
巨神兵が使う武器→情報システム部のクラウド（使い切れず、解けていく）

胞子→バグ等から生み出された有害データ（毒なデータを生み出す）
土壌がよければ、毒をださない→システムがよければデータは、有益

トルメキヤのクシャナ→某SIerの●●●に所属する、コンサルタント
理想的な世界を作る→世界的に広がる企業データをEAによって世界統一

---

で、劇場版をソフトウェア業界に変換すると、結論は、こんなかんじでした。

従業員が怒り出すのね。Excelを使ったり、BYODを駆使して日常業務をこなして
いたのに、その一部を血祭りにあげて、見せしめにしたことにより・・・
　で、その怒りを、●●●に所属する、コンサルタントは、
（巨神兵である）情報システム部を使って、鎮めようとしたと・・・
（核兵器ならぬ）クラウドを使って・・・

でも、クラウドを使っても、従業員の怒りは静まらず、さらに、暴走
最終的には、情報システム部もクラウドを使いきれず、溶けていく・・

そこに、むかしから、BYODやExcelになれたコンピューターやさんが
現れて、BYODやExcelを認めたシステムを構築したわけだ。
現場の怒りはやがて静まり、そのコンピューターやさんにみんな賛同すると・・
彼こそは、実は救世主だったと・・・

---

今日は、原作。
原作は、風の谷のナウシカのWikipediaの内容を参考にしました。

まず変換ルール。劇場版のルールに以下のものを追加

巨神兵を正常に起動させる「秘石」
　→石・・・トランジスタ・・・ってことは、マシンですかね？
　　情報システム部を正常にさせるシステム、
　　クラウドや汎用コンピューターでないやつかな・・

「シュワの墓所」
　→汎用コンピューターを操っていたCIOがいる、窓際のお部屋
　→汎用コンピューターとクラウドをよみがえらせることを目的

---

で、原作をソフトウェア業界に変換すると、結論は、こんなかんじ。

ナウシカは、情報システム部（巨神兵）を正常起動するシステム、
社内サーバーをおき、BYODをMDMを使って無毒化し、
サーバーデータをアクセスするという、とても簡単なシステム
（秘策）を教わり、それを実行する。

その後、●●●のコンサル、クシャナが、その会社を先例事例とし、
自社のクラウドとあわせてシステムを作らせようと画策するが、
ユバにより征服は逃れるものの、モデルケースとして紹介させられる。

その後、アスペルががんばって、業務効率を上げるため、システムを
作ろうとするが、●●●のシステムに阻まれ、撃沈する。

システム作成のためにExcelデータと戦っていると、データは、どんどん
クレンジングされ、きれいになっていることを発見する。
そして、データをきれいにするために、BYODやExcelの利用が認められて
いることを知る。

劣勢の土どき軍は、Excelを神Excelとして使用することにより、●●●
を撃退することに成功したが、Excelマクロが暴走しはじめ、それを
察知したExcelを使っている従業員は、Excelマクロの大暴走と呼ばれる
暴走に発展して、Excelによる業務運営がおかしくなる。

ナウシカは、上記秘策を用いて、情報システム部を正常起動させて、
オーマとなずける

ナウシカは、謎の青年に会い、情報システム部だけでなく、Excelのマクロ
利用やBYODなどは、汎用コンピューターを導入しようとしたCIOによって
開発されたものであることを知り、

それらを使ってデータクレンジングされてデータが浄化されたら、
そのデータを汎用コンピューターが放棄された（火の７日間）
前にあったDBにクレンジングしたデータをいれて、システムをクラウド上に
移行して再生する計画であることを知る。

そのために、ExcelマクロやBYODが許されているのであって、
もし、汎用コンピューターをクラウド上に移行し、データクレンジング
されたデータをDBに入れたら、BYODもExcelも禁止、
会社の硬直化したシステムを使わせる気だよ！
という会社上層部の秘密をナウシカに教える。

それを聞いたナウシカは、CIOを封印するため、窓際の役員室に乗り込んでいく。
CIOは、データクレンジングが終わったあとの理想的な●●●によるEAが
なされたクラウド上のシステムについて語り、ExcelもBYODも共存できると
約束するが、

ナウシカは、悩んだ末、
そんなもの信用できるか！今の現場のシステムを生かすことが大事なんだ！
と言い切り、汎用システムをそのままクラウドに移行する上層部の考えを否定し、
情報システム部に、汎用システムをそのままクラウドに移行する案をたたきつぶす
ことを命じる。

---

SIerさんが語る、汎用コンピューターをクラウドへ移行、
そうすれば、クラウドからExcelデータも見れる！
なんていうことを、素直に信じちゃいけないよ！

もっと現場重視しなよ！っていうことですよね・・・

あ～そうだよねえ～～確かに！！

P.S　●●●に、漢字をいれるか、英字をいれるか（何種類か考えられるね）
　　　は、あなたの自由です。

うちにも来た！おかしな三菱東京UFJメール（＾＾）

これ

その、怪メールの文面

（以下太字が怪メールの文面）

こんにちは

これは「三菱東京ＵＦＪ銀行」から送信されたアカウント確認のメールでございます、お客様はアカウントがロックされないように定期的にチェックしてください。
以下のページより登録を続けてください。

https://entry11.bk.mufg.jp/ibg/dfw/APLIN/loginib/login?_TRANID=AA000_001

──■□Bank of Tokyo-Mitsubishi UFJ □■──

■編集・発行：株式会社三菱東京ＵＦＪ銀行
　　　　　　　東京都千代田区丸の内２－７－１
　　　　　　　［登録金融機関］関東財務局長（登金）第５号
　　　　　　　［加入協会］日本証券業協会
　　　　　　　　　　　　　一般社団法人　金融先物取引業協会
　　　　　　　　　　　　　一般社団法人　第二種金融商品取引業協会

■ご登録にお心あたりのない場合や電子署名についてのお問い合わせ
　＜インターネットバンキングヘルプデスク＞
　０１２０－５４３－５５５
　（または０４２－３１１－７０００（通話料有料））
　　受付時間／毎日　９：００～２１：００
　
■メールアドレスの変更方法
　「三菱東京ＵＦＪダイレクト　インターネットバンキング・モバイルバンキ
　ング」にログイン後、「その他」（スマートフォン・モバイルバンキングの
　場合は「各種手続」）から「Ｅメール通知サービス登録・Ｅメールアドレス
　変更」を選択し、お手続きを行ってください。
　http://direct.bk.mufg.jp/index.html

■個人情報保護方針について
　三菱東京ＵＦＪ銀行では、お客さまの個人情報を適切に保護するため、その
　取り扱いにつきましては細心の注意を払っています。
　http://www.bk.mufg.jp/kojinjouhou/houshin.html　

■本メールの送信アドレスは送信専用となっております。返信メールでのお問
　い合わせは承りかねますので、あらかじめご了承願います。

――Copyright(C)2013 The Bank of Tokyo-Mitsubishi UFJ,Ltd.All rights reserved――

日本人じゃないな・・・このメール作文したやつ・・・（＾＾；）

これは「三菱東京ＵＦＪ銀行」から送信されたアカウント確認のメールでございます、

って、「天下の三菱が、こんな、「、」と「。」、敬語がおかしなメール、送るわけない！」

って、日本人なら、気づくだろう・・・

ってか、メールが「こんにちは」で始まる銀行って、どんだけフレンドリーなんだよ（＾＾；）

ちなみに、このメールに関しては、

インターネットバンキングのパスワード等を騙し取る不審な電子メールにご注意ください（平成25年12月24日更新）。
http://www.bk.mufg.jp/info/phishing/20131118.html

を見てください！まったく同じメールが、不審なメールとして載っています。

P.S　もうひとつきていた

送信者・・・tw、転送先cn やっぱ・・・

って、twって日本じゃないってばればれじゃん（＾＾；

P.S アップデートしました！

うちにもまだ来てる！おかしな三菱東京UFJメール（＾＾） - ウィリアムのいたずらの、まちあるき、たべあるき

風の谷のナウシカは、ソフトウェア業界の間違いを指摘している（１）

昨日、「風の谷のナウシカ」をみたんだけど・・

数十分みたところで、舞台設定はわかった。

　風の谷は、多分中国辺境
　　→Wikipediaだと、中央アジアらしい。
　　　でも、あの絵は、照葉樹林文化圏のどこかっぽく見えたんだけど・・？

　多分、戦争は、核兵器からバイオに移っている時代・・
　　むしとか、おうむっていうのは、バイオによって作られたものだろう・・
　　　　→自然で、ダンゴムシとかが、あ～は、ならないだろう。

　　巨神兵とかいうのは、１０００年前とか言う話？だから、
　　核兵器とか使っているときの話？
　　　　→映画の後半でむしを撃っているとき、核兵器ぽかったですね。
　　　　　ただ、巨神兵も生物っぽいから、核兵器を使った、バイオなのかしら
　　　　　むしは、放射能、大丈夫なんだろう。たぶん

　　胞子は、放射能を持っているのかな？で、毒だと
　　　　→放射能のない土や水から作ると、毒をもたないのだろう
　　　　→ナウシカは、なんで、飛行機が落ちたとき、マスクしてなくて
　　　　　生きているのか？植物の中だと安全なの？ファイトレメディエーション？

　　トルメキアのクシャナは、技術によって、世界が変わると思っている人
　　　　巨神兵を使えば、世界は平和になると思っているので・・

うん、舞台設定はわかったぞ。で、結論は？

　むしが怒り出すのね。
　巨神兵を使ったクシャナの攻撃は、だめだめで、巨神兵が崩壊するのね。
　さいごには、むしを鎮めたナウシカが、実は救世主だったと・・・

---

すげ～、宮崎駿、コンピューター業界が進むべき道を
ここまで的確に予言するとは・・・・

風の谷は、多分中国辺境→コンピューター導入辺境
　汎用コンピューターを無理やり導入しようとした「火の七日間」
　から、かなりたった世界。

「むし」といわれる、汎用コンピューターを「無視」した従業員
　　→かれらは、Excelを使っているわけね！

ということは、汎用コンピューターの時代の生き残りの巨神兵は、
情報システム部ですか・・・

胞子は、バグやわけわからない仕様から生み出されたデータと・・
　こういうのを、むかしはガベージイン・ガベージアウト（＝ごみ）
　といってたけど、毒だよねえ。たしかに。
　土壌がよければ、データは、毒ではなく、有益なんだけど・・

トルメキヤのクシャナは某SIerの●●●に所属する、コンサルタントなわけね。
　世界的に広がる企業データをEAによって世界統一することで、理想的な世界
　が広がると・・

---

うん、舞台設定はわかったぞ、で、結論は？

　従業員が怒り出すのね。Excelを使ったり、BYODを駆使して日常業務をこなして
いたのに、その一部を血祭りにあげて、見せしめにしたことにより・・・
　で、その怒りを、●●●に所属する、コンサルタントは、
（巨神兵である）情報システム部を使って、鎮めようとしたと・・・
（核兵器ならぬ）クラウドを使って・・・

でも、クラウドを使っても、従業員の怒りは静まらず、さらに、暴走
最終的には、情報システム部もクラウドを使いきれず、溶けていく・・

そこに、むかしから、BYODやExcelになれたコンピューターやさんが
現れて、BYODやExcelを認めたシステムを構築したわけだ。
現場の怒りはやがて静まり、そのコンピューターやさんにみんな賛同すると・・
彼こそは、実は救世主だったと・・・

---

おお～、
●●●は、ナウシカ見たほうが、いいかも？

元旦に、システム入れ替えが、正しい？ーJR東日本、大晦日と元旦にクレカ取扱い一時停止

たしかに、年末年始と、ゴールデンウィークに大規模システムを入れ替えるのが、鉄則だ。
しかし、そのココロは、「みんなに迷惑をかけないため」という大前提がある。

今回、

Suicaチャージにも影響！JR東日本、大晦日と元旦にクレジットカード取扱い一時停止！
http://www.rbbtoday.com/article/2013/12/25/115351.html

ということだが、確かに、大規模システムの入れ替えなので、
年末年始ということはわかるが、
大晦日と元旦って、初詣とか、出かける可能性MAXのときだろう・・・
そのとき、チャージできない、切符買えないって・・・

２日夜から３日朝とかに、出来なかったのだろうか？

え、特急指定席なら、前もって買えるから、「問題ない！」って。。（＾＾；）

ま、現金払いの私にとって、なんにも「問題ない！」んですけど・・

バイドゥが見解発表より・・・SSLの文字列解析に興味津々！

バイドゥが見解発表、「利用規約に同意した場合のみ」……Simejiについては「実装バグ」
http://headlines.yahoo.co.jp/hl?a=20131226-00000011-rbb-sci


(以下太字は、上記サイトより引用）


バイドゥの「Baidu IME」および「Simeji」については、同日朝より、入力情報を無断送信していたとする報道がなされている。これに対して同社は、「ユーザーの入力情報を弊社サーバに送る場合は、ログ情報の送信に事前に許諾をいただいており、許諾が得られないユーザーについてはログ情報の取得を行っておりません」とし、あくまで利用規約に則っていると説明している。


まあ、その通りなんだろうな、たぶん・・
あの利用規約とかに書いてあるんだろうな、よく読むと・・

で、それよりも、上記記事に・・・


セキュリティ企業のネットエージェントは同日、「Baidu IME」および「Simeji」の解析結果を発表している。「Counter SSL Proxy」を利用し、SSLで暗号化され送信されている文字列を解析した。


のほうが、興味しんしん！
SSLの文字列解析？

みてみましょう・・・

http://www.netagent.co.jp/product/ssl/

コレってたぶん、自分が他人に送っている間のSSLを解析するんだよねえ。。
そうじゃないの？他人間のも、解析できちゃうの？
どっちなの？興味津々

技術ドキュメント規格S1000Dって、何？

メンターグラフィックスから来たメールを
テキトーに眺めていたら・・・

「技術ドキュメント規格S1000D」って出てきたんだけど・・・

何？これ？

ドキュメントの規約？

とりあえず、サイトをメモメモ！


Welcome to S1000D
http://public.s1000d.org/Pages/Home.aspx

パソコンに入力した文字列を全て外部に送信する「バイドゥＩＭＥ」が入っている大学

百度ソフト、便利で人気だが「まるでウイルス」
http://headlines.yahoo.co.jp/hl?a=20131226-00000267-yom-sci

(太字および表題の一部は上記サイトより引用）


パソコンに入力した文字列を全て外部に送信してしまう中国社製の日本語入力ソフト「バイドゥＩＭＥ」。国民の大切な情報を扱う役所や大学でも気づかないまま使われていたことに、関係者はショックを受ける。


はっ、はっ、はっ（＾＾）／～

うちの大学（院）も、「インストールが確認された大学」に入っていたよ（＾＾；）

でも、うちの計算機室は、インストールできないように、設定されていたから、
大丈夫なはず・・・はず・・・？？

---

ちなみに

hao123っていうのが、いきなり現れた！
http://blog.goo.ne.jp/xmldtp/e/97efe5c6d604aa580ef7c25cf5dd09fd

に書いたけど、 Baidu IMEをインストールすると、
hao123というのが、スタートページになることがあるらしい
くわしくは

hao123（jp.hao123.com） 削除アンインストール方法＆スタートページ無効化方法
http://www.geocities.co.jp/Playtown-Yoyo/6130/notes/baidu-hao123.htm

革新的な大規模システムは、受託では作れない

さ、やっと本題が書ける。表題の説明をする。

今まで、「ソフト受託ビジネスには、２つのビジネスモデルがある」ことを書いた。

１つは、単価を上げる戦略。
もう一つは、人数を増やす戦略
結果として（それを意図してるわけではないのだが）
　・前者は、設計に力を入れ、あらかじめリスクを回避する方法

　・後者は、とにかくやってみるので、開発後期にリスクが出る方法

となる。

---

　ここで、最近の最新技術？を導入した、革新的な大規模システムを開発することを考えよう。この場合、最新技術なので、全てを見通せない。そこで、後者の「とにかくやってみる戦略」を取ることになる。この結果、うまくいけば、開発できるが、まずい事が起こると、上記の「とにかくやってみる戦略」のように、テスト以降で問題が発覚、炎上することになる。

　これを回避するために、よく、「アジャイルで」ということになるが、

　アジャイルは

　　　　・革新的な小規模開発か
　　　　・漸進的な大規模開発

　に向いている手法である。

---

　アジャイルも、「とにかくやってみる戦略」なので、リスクはある。そのリスクを軽度に押さえるため、開発期間を短くし、細かく区切って確認しながらやっていく。そして、その結果を見て、取るべき手段を変えていく（アジャイルの文脈だとリーンのセットベース開発、経営の文脈だとリアルオプション）。

　リスクを制御するので、革新的なことはできるが、細かく区切って、（具体的には、１スプリントのレベルに）開発していくので、小規模開発ということになる。

　また、個々には革新的なことを行っても、それを長いスパンで継続的に行っていくので、全体的には、漸進的に見える。したがって、大規模開発に導入した場合、全体的に見ると、「漸進的な大規模開発」となる。

---

大規模開発を行う場合、リスクを押さえて行う必要がある。
ハイリスクの場合、ハイリターンにならずに、会社が潰れてしまう危険性が大きい。
リスクを押さえるためには、設計部分でリスクに対処しておく必要がある。
つまり、「設計に力を入れる戦略」となる。

しかし、この戦略は、リスクがある程度見えていないと使えない。
枯れた技術を使う場合は、リスクは見えるので、問題はない。
しかし、革新的な技術だと、リスクは見えない。なので、このパターンにはならない。

つまり、「設計に力を入れる戦略」は、　

　　　　・枯れた技術による大規模開発

には向いているのだが、革新的な大規模開発は、できない。
この開発方法は実はウォーターフォールに近い。
つまり、

　　　「ウォーターフォールでは、革新的な大規模開発はできない」

例えば、
　仕様がころころ変わってしまうような、クラウドのAPIや
　結局リリース時、できない仕様やバグがいっぱいあるOS
とかを使って、ウォーターフォールでは開発できない。
急にインターフェースが変わったりするから・・・

---

ということで、大規模開発は「受託で行う場合」

　　　・最新技術を漸進的に取り入れて行うか
　　　・枯れた技術を使って行うか

になる。前者はコアビジネスを行う場合、後者は、そうでないビジネスに対して（バックオフィス的な）有効な手法となる。

では、革新的な、大規模開発はできないか・・・

とは、書いていない。この場合、「とにかくやってみる戦略」でのテスト以降のリスクをすべて発注者が受け取ればよい。つまり、受託ではなく、発注者が情報システム部を使って行うか、請負受託ではなく、準委任契約をすれば、実現可能になる・・・理論上は・・・（ただし、そんなことをする会社はないが。。）

受託ビジネスは１人月いくらにすると儲かるか（３）戦略２：人を増やす

ソフト受託ビジネスには、２つのビジネスモデルがある話。
前回は、単価を上げる戦略。
今回は、人数を増やす戦略。

---

＜＜単価を上げる＞＞

人数を増やしても、もちろん、儲かる。
たとえば、１人月単価６０万でも、技術者数を２０人人にしたら・・・
１人月単価６０万だとしたら、１年で７２０万。
変動費が４００万だったので、
限界利益は７２０－４００＝３２０万
（１人あたり、３２０万、会社に入れられる）

固定費を３０００万と見ていたので、同じ７人でも、
３２０＊２０－３０００＝ざっくり３４００万くらい儲かる・・・

この場合、それで固定費大丈夫か？（部屋は足りるか？とか）
はあるけど、その分を増やしたとしても、まあ、前のモデルより結構儲かる。

---

ということで、この「低料金で、大規模化」というのは、
大手でよく取られる戦略になる。

この戦略のポイントは、固定費と人件費を抑えること。
そこで、
・固定費を抑えるため、実践教育中心。
　ネットで調べろ、実践で学ぶのが一番→体系的には教わらない

・人件費を抑えるため、出来ない人は切り捨てる
　そして、若い人をどんどん入れると、平均給与は下がる。
　離職率は上がるけど・・・

さらに、若い人をどんどん入れるため

・見栄えはよく
　　→そうすると、建物の固定費はあがるが、これは、たいしたことない。

こうすると、営業活動さえうまく行けば、会社はどんどん大きくできる。

---

じゃあ、これは、いいことづくめなのか？

実は、リスクが膨大になる！

教育を切って、実践中心になると、

・ネットで聞いた話で企画し、
・正常系を確認して設計し
　　→そもそも、聞いた話レベルなので、異常系がどうなるか、わからない
・そのまま実装にツッコミ・・・聞いてないよ状態になり
　　→ネットに書いてあることが、そのまま出来るとは限らない
・ITで異常系に耐えられず、設計をしなおし・・・
・STでパフォーマンスが出ず、さらにつくりなおし・・・

などということにもなりかねない。

たとえば、
・クラウドを使ってシステム作りたい
　　　→さいきんOpenStackって、きいた
　　　→監視はZabbixなの？
・正常系で設計し・・・
　　　→ネットがどうなるかなんて、知ったこっちゃない。
　　　　CAP定理をこよなく愛すので、トランザクションなんて考えない。
　　　　可用性のじゃま
・そのまま、実装にツッコミ
　　　え、zabbixで、OpenStackをどう監視する・・・
　　　ってか、そもそも、監視項目は何？
・ITで異常系に耐えられず・・・
　　　あ、やっぱり、トランザクションは必要でしたか・・・
　　　・・・そうですよね・・・
・STでパフォーマンスが出ず
　　　クラウド遅い（＞＿＜！）
なんてことにも、なりかねない。

こうなると、IT,STで炎上する。人は、こんな感じで必要。

この場合、大赤字。
しかし、こうならないでうまく行くプロジェクトも多い（多いと思いたい）。
なので、うまく行かなければ大赤字、うまく行けば利益。

というまさに、ギャンブル状態なのだ。

---

ギャンブルといってしまうと、対策ないのだが、
これを、リスクを保有する金融商品としてみれば、結構分かりやすい

つまり、短期化して、予測を立てやすくし、
自分が分からないものはやらないで
大量に、多種多様に保有する。

この点からも、短期勝負で、比較的開発規模の小さいアジャイルは、
有利なのだ。

なお、金融商品の場合、情報がオープンにならないと、判断を誤る
この開発の場合も、IT,ST段階で、情報がオープンにならず、
修正しやすいところから、修正していき、問題が後々まで残ると、
最終段階でとんでもないことになり、判断を見誤る

受託ビジネスは１人月いくらにすると儲かるか（２）戦略１：単価を上げる

先ほどの、

ソフト受託ビジネスには、２つのビジネスモデルがある。

話。
まず、儲け話の前に、損益分岐ライン。

１人月単価７０～６０万だと、技術者１０人くらいで、とんとん

という話になる。

ではここで、儲け話。
一つは、単価を上げる戦略。

---

＜＜単価を上げる＞＞

単価を上げれば、もちろん、儲かる。
たとえば、同じ技術者７人でも、
１人月単価８０万だとしたら、１年で９６０万。
変動費が４００万だったので、
限界利益は９６０－４００＝５６０万
（１人あたり、５６０万、会社に入れられる）

固定費を３０００万と見ていたので、同じ７人でも、
５６０＊７－３０００＝ざっくり１０００万くらい儲かる・・・


・・・とはならない。なぜか？

---

変動費は４００万とみたが、これは、若手の人だった。
でも、単価を上げる→一般には技術的に高い人→若手じゃないかも？
ってことで、原価も上がる可能性がある。
単価が１０万上がっても、原価が１０万上がってしまうと、
意味がない。


また、単価が高くなってくると、下流工程は、できなくなってくる。
実は、下流工程（PG、テスト）のほうが、上流工程（要件定義、設計）より、
単価がやすいのだ。

そこで、開発方法としては、上流に高い人を入れる場合、要件定義、設計
で例外条件など、あとあと問題になるところを上流でつぶし、下流工程に
工数をかけず（自動化やパターンの多用）に開発することになる。

→このやりかたは、全般的に、第２パターンより、人数は少なくて済む

上流で問題点をつぶしたり、下流工程の自動化を行うとなると、
そこそこ、技術的に高度でなくてはならず、そのための勉強を体系的に
行わないといけない。
このことから、２つの問題を生じる
（１）教育・研修コストがかかる
　　→本を読むにしても、それを確認する時間的、金銭的コストがかかる
　本を読んだだけで、試さないのは、技術的に意味がない。
　本のとおり、実践ではことが運ばず、まさにそれを知ることが、技術なのだから

（２）短期間に人を増やせない
　本を読めばすむ、ネットを調べれば済むという話ではなくなると、
　それ相応の経験＝時間が必要になるので、短期間に人を増やせない

---

結果として、会社は、小さめになる。
小さい会社で高い技術を持っているソフトハウスを作る場合に向いている
ビジネスモデルである。

受託ビジネスは１人月いくらにすると儲かるか（１）まず、損益分岐点

ソフト受託ビジネスには、２つのビジネスモデルがある。
それを説明するために、まず、損益分岐点近くの、まったく利益の出ない
モデルについて説明する。

---

＜＜受託ビジネスにおける直接原価計算＞＞

　受託ビジネスにおいては、人月で一般的には考える。
つまり、この計算において、技術者が商品（＝作成されるソフトウェアではない）で、この技術者に対して支払われるお金が、変動費になる。

　それが証拠に、技術者を増やせば、もらえるお金は、それに比例して増える。仕事があれば・・・（固定費だと増えないはず）。

　一方、経営者、事務員などのバックオフィスの人に払うお金は、固定費となる。
　（事務員を増やしても、もらえるお金は増えない）

　→普通の直接原価計算だと社員は固定費
　　（社員は商品ではないから。社員を増やしても、製品数が直接増えないから）

---

＜＜ざっくり計算をするために・・・＞＞

　技術者１人あたりに、毎年４００万かかるとする。
　コレは、交通費・社会保険費（会社が支払う分と、個人で支払う分）・福利厚生費なども含んでいるので、給与額面は、ボーナスなしで、３６０万になる。
　つまり、額面月３０万、手取りはもっと低くなる（ボーナス一切成し、残業代込みで）だから、若手の安い人を想定している。

　そして、技術者を１人月単価７０万で卸したとすると、（７０万で、SIer等など、取引先と契約するということ。したがって、ユーザー企業は、SIerと、もっと高い１人月単価で取引する）、１年あたり、７０＊１２＝８４０万

　つまり、１人当たり、１年間で、８４０－４００＝４４０万の限界利益がある。
　これで、固定費をまかなう。

---

＜＜固定費部分＞＞

　社長の給料を、月１００万とする。コレくらいないと、社長が銀行・その他もろもろから信用されないだろう
なので、年間１２００万

　会社の家賃＋光熱費＋通信費・・・その他、会社を維持して行くのに必要な経費を月６０万とする（小さい会社だと、ちょっと高めだけど、東京で、適当な広さなら、まあ、妥当か・・・大体、家賃＋管理費で、１坪１万円～１万５千円くらい？４５万で、３０坪）
で、年間７２０万

　総務のお姉さんは必要なので、年間２８０万くらい（計算しやすくした）

　他に、税理士、社労士へのお金、求人募集、採用活動、法務、経理ソフト・・・その他もろもろの、総務のお金がかかる。これを、８００万としよう（あきらかに、計算しやすくしてる・・＾＾；）

合計１２００＋７２０＋２８０＋８００＝３０００万、
なにもしなくても、年間、コレくらいのお金がかかってしまう。

---

＜＜何人で回収できる？＞＞

技術者１人当たり、会社に４４０万円入れられて、
会社は、３０００万かかるのだから、

３０００÷４４０＝およそ７

となる。つまり、

技術者７人、社長と総務のおねえさんで、１人月単価７０万が、
とんとんライン。


ちなみに、同じように１人月６０万にしてしまうと、
１人当たり、６０＊１２－４００＝３２０万なので、

３００÷３２０＝９～１０の間→損益分岐を超えるには１０人

となる。つまり、

技術者１０人、社長と総務のおねえさんで、１人月単価６０万が、
とんとんライン。

ということになる。

---

では、次にここから、利益を出すビジネスモデルを考える。

統計モデル その6 SEMの復習

違う授業なんだけど、続きみたいな感じなので、
「統計モデル」の話として続けます。

---

SEM（Structual Equation Modeling)
パス図：変数間の関係
　観測変数：四角で表されている
　潜在因子：因子間の関係が知りたい
２つの部分
　測定モデル：因子分析
　構造モデル：因子間の関係をみる

構成概念：因子
　構成概念：直接観測することはできない
　定義するとうまく説明できる
　イメージ、物事に対する態度
　　例：充実感、景気、パーソナリティ

因子分析とは
・変数間のまとまりを見つけるための統計手法
・相関の高い変数同士が同じ因子にまとまる
　　　１つ
　　　２つ＝文系、理系
２種類ある
　　確認的因子分析
　　探索的因子分析

確認的因子分析
　　変数と因子の関係が明らかなとき
モデルの適切さ：適合度で検討
　モデルが識別されている必要がある
　２つの間共変動
誤差：回帰分析の誤差と同じようなもの
　　決定係数
　　→回帰とのアナロジー
・別のモデルも考えられる
　　→識別できないとX
　　→いいモデルって、なんだろう？
　　　　モデル比較
適合度指標

SとΣの具体的表現
・適合度＝SとΣの近さ
・S＝データをあらわす共分散行列
　　対角要素　分散
　　非対角要素　共分散
・Σ＝パラメータであらわした
・SとΣを結びつけ、連立方程式を解く
　解けないけど、よさそうな値は考えられる
・よさそうな度合い：適合度

狩野本：グラフィカル多変量解析

大江アナ、日本初の「グーグルグラス」装着で生出演

「グーグルグラス」すげ～といわなきゃいけないはずだけど、
それ以前に「大江アナかわゆい！」と思ってしまう・・・

大江アナは、12月24日放送の『ワールドビジネスサテライト』（毎週月～金　後11：00）のワールドマーケットコーナーと、26日放送の『Newsモーニングサテライト』（毎週月～金　前5：45）で、同端末を身に付けて登場する。

とのこと

テレ東・大江アナ、日本初の「グーグルグラス」装着で生出演
http://news.goo.ne.jp/article/oricon/entertainment/oricon-2032228.html

（太字は上記サイトより引用）

孤独死は、手数料無料で審査無しで完全放置のクラウドファウンディング！で防げる？

３１歳・元社長令嬢はなぜ餓死したか…冷蔵庫にはマヨネーズの空容器だけ
http://headlines.yahoo.co.jp/hl?a=20131219-00000538-san-soci

いたましい事件だが、このような孤独死を防ぐ手段は、全くといっていいほどなかった・・・

しか～し、しかし、総裁が、すごいことをやらかしたのだ・・・

FreeStarter!
手数料無料で審査無しで完全放置のクラウドファウンディング
http://crazyworks.jp/freestarter/


理屈抜き、このページに行ってもらえば、どういうものかわかります。
はいそうです。もう無法地帯です。

お金ください・振込み待ってます

でも、OKかもしれません（＾＾；）

---

これなら、上記記事のような人でも、このクラウドファウンディング
に書けるかも・・・

・・・そうすると・・・

これでお金がもらえるなんて、甘いことは考えていない・・・

そういう人が、生活の実情を書けば、
この人は、困っている！ということはわかる。
そこで、だれかが、地方自治体に報告すれば、
救いの手は差し伸べられるかもしれない・・・

・・・たぶん、みんな、このサイトを作った総裁を
バカにするかもしれないが、
意外と、これって、すご～～～いことに、なるかもよ？


【参考文献】

村上福之の「ネットとケータイと俺様」
手数料無料・無審査・放置のクラウドファンドFreeStarterを作りました。
http://blogs.itmedia.co.jp/fukuyuki/2013/12/freestarter-a8be.html

JQueryのajax()でのエラー時の返り方－IEとChromeの違い

JQueryのajax()を使って非同期アクセスをした場合、エラーが起こると、

error: function(XMLHttpRequest, textStatus, errorThrown){

//　　この中に入る

}

このとき、

XMLHttpRequest.statusでエラーコード（４０４とか）、
XMLHttpRequest.statusTextでエラーメッセージ

が拾えるが、この返り値が、IEとChromeで微妙にちがっている。

以下、そのまとめ

---

■チェック内容

以下のプログラム

<HTML>
<head>
<script src="http://code.jquery.com/jquery-1.9.1.js"></script>
<script>
$(function(){ 
  $("#bt1").click(function () {
	$.ajax({
   		type: "POST",
   		url: "dummy.jsp",
		dataType:"html",
   		success: function(msg){
			document.open();
			document.write(msg);
			document.close();
   		},
   		error: function(XMLHttpRequest, textStatus, errorThrown){
			msg="--- Error Status ---"
			msg=msg+"<BR>"+"status:"+XMLHttpRequest.status;
			msg=msg+"<BR>"+"statusText:"+XMLHttpRequest.statusText;
			msg=msg+"<BR>"+"textStatus:"+textStatus;
			msg=msg+"<BR>"+"errorThrown:"+errorThrown;
			for(var i in errorThrown)
			{
				msg=msg+"<BR>"+"error "+i+":"+ errorThrown[i];
			}
			document.open();
			document.write(msg);
			document.close();
   		}
	});	
  });
}); 
</script>
</head>
<body>

<BUTTON id="bt1">AJAX</BUTTON>

</body>
</html>

を、
（１）c:/tmp/codetest　のフォルダの下に、index.htmという名前で、
（２）Tomcatのベース/webapps/codetestの下にindex.jspという名前で、
それぞれ用意する。

なお、
（１）には、index.htmと同じフォルダに、dummy.htm
（２）には、index.jspと同じフォルダに、dummy.jsp
が置いてあり、dummy.htm、dummy.jspとも、中身は
dummy
とだけ記述されている。

以下、赤字のURLの部分を変えていく

---

■（１）のファイルパス指定→存在するファイル

上記赤字のURLを「dummy.htm」と記述
としてブラウザに「C:\tmp\codetest\index.htm」と入力し、アクセス
AJAXボタンをクリックする

・IEの場合
dummyと表示される（＝アクセスできる）

・Chromeの場合
（ファイルパスはfile:///C:/tmp/codetest/index.htmと書き換えられる）
以下の表示でエラー

--- Error Status ---
status:404
statusText:error
textStatus:error
errorThrown:

---

■（１）のファイルパス指定→存在しないファイル

上記赤字のURLを「dummy2.htm」と記述
としてブラウザに「C:\tmp\codetest\index.htm」と入力し、アクセス
AJAXボタンをクリックする

・IEの場合
以下の表示でエラー
--- Error Status ---
status:0
statusText:[object Error]
textStatus:error
errorThrown:[object Error]
error name:TypeError
error message:The system cannot locate the resource specified.
error number:-2146697211
error description:The system cannot locate the resource specified.

・Chromeの場合
（ファイルパスはfile:///C:/tmp/codetest/index.htmと書き換えられる）
以下の表示でエラー

--- Error Status ---
status:404
statusText:error
textStatus:error
errorThrown:

---

■（２）のURL指定→存在するファイルをフルで指定

Tomcatを起動し、index.jspの
上記赤字のURLを「"http://localhost:8080/codetest/dummy.jsp"」と記述
"http://localhost:8080/codetest/をアクセスしたとき

・IEの場合
dummyと表示される（＝アクセスできる）

・Chromeの場合
dummyと表示される（＝アクセスできる）

---

■（２）のURL指定→存在するファイルを相対指定

Tomcatを起動し、index.jspの
上記赤字のURLを「"dummy.jsp"」と記述
"http://localhost:8080/codetest/をアクセスしたとき

・IEの場合
dummyと表示される（＝アクセスできる）

・Chromeの場合
dummyと表示される（＝アクセスできる）

---

■（２）のURL指定→存在しないファイルをフルで指定

Tomcatを起動し、index.jspの
上記赤字のURLを「"http://localhost:8080/codetest/dummy2.jsp"」と記述
"http://localhost:8080/codetest/をアクセスしたとき

・IEの場合
--- Error Status ---
status:404
statusText:Not Found
textStatus:error
errorThrown:Not Found

・Chromeの場合
--- Error Status ---
status:404
statusText:Not Found
textStatus:error
errorThrown:Not Found
error 0:N
error 1:o
error 2:t
error 3:
error 4:F
error 5:o
error 6:u
error 7:n
error 8:d

---

■（２）のURL指定→存在しないファイルを相対指定

Tomcatを起動し、index.jspの
上記赤字のURLを「"dummy2.jsp"」と記述
"http://localhost:8080/codetest/をアクセスしたとき

・IEの場合
--- Error Status ---
status:404
statusText:Not Found
textStatus:error
errorThrown:Not Found

・Chromeの場合
--- Error Status ---
status:404
statusText:Not Found
textStatus:error
errorThrown:Not Found
error 0:N
error 1:o
error 2:t
error 3:
error 4:F
error 5:o
error 6:u
error 7:n
error 8:d

---

■（２）のURL指定→存在しないサーバーアプリ指定
Tomcatを起動し、index.jspの
上記赤字のURLを「"http://localhost:8080/codetest2"」と記述
（webappsの下には、codetest2のファイルは存在しない）
"http://localhost:8080/codetest/をアクセスしたとき

・IEの場合
--- Error Status ---
status:404
statusText:Not Found
textStatus:error
errorThrown:Not Found

・Chromeの場合
--- Error Status ---
status:404
statusText:Not Found
textStatus:error
errorThrown:Not Found
error 0:N
error 1:o
error 2:t
error 3:
error 4:F
error 5:o
error 6:u
error 7:n
error 8:d

---

■（２）のURL指定→存在しないIPアドレス指定
Tomcatを起動し、index.jspの
上記赤字のURLを「"http://192.168.4.1"」と記述
（192.168.4.1のIPアドレスを持ったサーバーは存在しない）
"http://localhost:8080/codetest/をアクセスしたとき

・IEの場合
--- Error Status ---
status:0
statusText:No Transport
textStatus:error
errorThrown:No Transport

・Chromeの場合
--- Error Status ---
status:0
statusText:error
textStatus:error
errorThrown:

---

以上。