正しい「正しい日経新聞の読み方」の読み方
LilacLog さんのblogを読ませていただきました。
http://blog.goo.ne.jp/mit_sloan/e/bfa3c758e46d24ca37b97d6ad063cdc9
最初に断っておきますが、論旨には私は賛成です。私のこれから書くことはちょっとした補足と思ってください。
日経新聞を批判的に読むこと自体は、私も大賛成です。ただ、私は、新社会人や学生の方は、15〜20分でざっと全体を読むのではなく、疑問に思った記事を30分くらいかけて「なぜ」「なぜ」と考えながら、一次資料にも当たりながら突き詰めていくことをおすすめします。
blog には、「雨」「傘」の例として、このような記述があります。
記事には、ホンダや三菱自動車が手元資金積み増し企業例として載っている。別の日の記事を思い出すと、自動車企業は、一部の部品の調達が間に合わず、生産が遅れているという話があった。ということは、ほとんどの部品については調達を継続してるから資金は出て行くのに、ある一部の部品が間に合わずに製品は出荷できず、お金が入ってこない、となることを想定しているのではないか。
日経新聞の「雨」「傘」を素直に信じてはいけないのと同様、この記述も素直に信じてはいけません。ほんとうかな？ と突き詰めていくことが特に初学者には必要です。
では、一次資料に当たる、すなわちホンダの2011年3月末決算を見てみましょう。
（本田技研工業?(7267)2011年３月期決算短信 より引用）
確かに「現金および現金同等物」は増えていますが、「たな卸資産」は減っています。また、「自動車会社は、一個流しや後工程引取で先進的な取り組みをしている」という一般知識と組み合わせると、生産が遅れているのに調達を継続というのはおかしいかな？ と考えることもできるかと思います。
その後の鉄鋼業に関する記述についても、
例えば、自社が今のところ上流からの影響は少ない鉄鋼メーカーだったとする。自動車業界がこんな状況だと、今は出荷は順調だけど、そのうち多くの部分で需要が止まるかもしれない、と「雨」のストーリーを作っていくわけである。
とありますが、これも「鉄鋼生産（特に高炉）はフレキシブルに生産量を調整できない」という一般知識や、他の報道と組み合わせると、
「今は出荷が落ち込んでいるが生産は落としていないため在庫が積み上がりつつある。需要回復や復興需要が読みにくいので、様子を見て、場合によっては減産を考える」
と考えることもできるかと思います。
「傘」に関する記述も同じです。
むしろ一般的には、市況変化が大きな業界で、資金回収が不安定になる可能性が高い企業が、キャッシュがショートしないように手元資金を多く持つ傾向が高い。例えばGoogleがそうだし、米国のバイオベンチャーもその傾向が強い。手元資金を成長につなげろ、といいたい気持ちは非常にわかるが、ちょっと飛びすぎ感がある。
実際に一次資料に当たってみると、Google の現金および現金同等物の直近の残高は、売上の 14.1 ヶ月分になります*1。
それに比べて、「市況変化が大きな業界」として工作機械と比べてみます。工作機械は、不況時には受注が前年比６割減になるほどの、代表的な市況産業です。
工作機械メーカーの直近決算を調べてみると、牧野フライスで売上の4.62ヶ月分*2、森精機で売上の0.74ヶ月分*3です。
これと、Google が他社の買収に食指を動かしているという報道、そして Google の売上が急に前年比６割減になることは工作機械よりは考えづらいかな、という一般知識を総合して考えると、むしろ Google の手元資金の厚みは、むしろ日経の主張する「豊富な資金力で戦略投資に踏み切る」ためのものと考えることもできるかと思います。
と、なんか批判めいた書き方になってしまいましたが、批判をする気は毛頭ありません。実際、多忙な経営者や売れっ子コンサルタントには、一次資料まで細かく当たるような時間はありません。いわゆる「限定合理性」の中で、「ヒューリスティクス」に基づいた意志決定が要求されます。
時間をかければより妥当な結論にたどり着くのは当たり前ですし、私の考察にも批判は多々あり得ると思います。
だからこそ、新社会人や学生の方は、最初は「なぜ」「なぜ」と常に考えながら、一次資料にも当たりながら突き詰めて考えていくことをおすすめします。そうすることにより、ヒューリスティクスが磨かれていき、それでいつの日かやっと、15〜20分で全体を、かつ批判的に読めるようになるのではないかと思います。
*1:http://finance.yahoo.com/q/ks?s=GOOG
*2:http://www.makino.co.jp/jp/ir/pdf/201104.pdf
*3:http://www.moriseiki.com/japanese/ir/announce/pdf/fy2010_4shihanki_kessan.pdf 他社より少ない理由は、コミットメントライン契約のためと思われます。コミットライン契約の未実行分 38,750百万円を現金同等物とみなして分子に加えると、4.60ヶ月とほぼ牧野フライスと同水準になります。
地震の発生確率について
竹中平蔵さんのtweetが大分叩かれているようです。
http://togetter.com/li/133823
この87％という確率はBPT分布に従って算出されています。*1
http://www.asahi.com/national/update/0507/TKY201105060460.html によると、直近の東海地震は1854年の安政東海地震で、さらに周期は100-150年と考えられているとのことです。
つまり、下記の図（正確ではありません。ラフなものです）の、 (青色部分の面積)÷（(青色部分の面積)＋(黄色部分の面積)）が 0.87 であるということです。
このように、一様な分布ではないため、たとえば直近の１年間に東海地震が起きる確率は、(87% ÷ 30) よりも大きいものになります。
逆に、今から29年後から30年後までの１年間に東海地震が起きる確率は、(87% ÷ 30) よりも小さいものになります。
よって、竹中さんのtweetの計算方法は、リスクを過少に見積もっていると言えると思います。*2
こういう見方で論じている tweet はあまりないような気がしたので書いてみました。私も経済学研究科在学の大学院生なので数学や地震の専門家ではありません。ご批判・コメント等ありましたらお気軽に。
【追記】
id:fuka_fuka さんのブックマークコメントより
周期のピークを過ぎると「もう起こらないだろう」とみなされているとは知らなんだ。
それは少し違います。「条件付き確率」という考え方なのですが、「今から１年間地震が起こらなかった条件下で、今から１年後から２年後までの１年間に東海地震が起きる確率」＞「直近の１年間に東海地震が起きる確率」＞ 「今から１年後から２年後までの１年間に東海地震が起きる確率」となるのです。
よって、上で紹介した朝日新聞の記事で、『地震調査委は０４年、３０年以内の発生確率を「８４％」と公表。その後の時間経過から今年１月現在で「８７％」と計算した。』と書かれているように、地震が起こらなかった条件下では、徐々に一定期間内の発生確率は上がっていくことになります。これは、直感的な感覚*3とも合致しているのではないかと思います。
Let’snote B10 購入 + RealSSD C300換装
長年使っていた Let'snote Y7。持ち運びのできるサイズで、液晶が縦1,000ピクセル以上ある PC は他にあまりなかったので、ずっと愛用していたのですが、さすがにメモリ最大 2GB では、FireFox + Thunderbird + Eclipse + Evernote + Tween あたりを同時起動するとかなりツラい状況になるということで、買い換え先を探していました。
2011年3月11日に発売となった Let'snote B10 は、ちょっとサイズが大きいもの、液晶の大きさ、Sandy Bridge 対応、そしてこれまでの Let'snote への信頼で、対抗馬 VAIO Z より良いMy脳内評点を得て、早速購入することに。プレミアムエディションにも食指が動きましたが、リーズナブルな店頭版 (CF-B10AWADR) を購入。自分でメモリ 4GB (CFD D3N1333Q-4G) の増設 (計:8GB) と、RealSSD C300 256GB (CTFDDAC256MAG-1G1) への換装を行いました。
メモリの増設は簡単なので説明は省略します。SSDへの換装の手順は以下の通りです。
- まず、HDDのまま起動してリカバリーディスク(DVD)を作成する。
- 本体を裏返して、バッテリを外す。
- 上の写真の(１)の部分のプラスネジ２つを外す。
- 上の写真の(２)の部分のプラスチックカバーを外す
- 中のHDDを引っ張って取り出し、SATAコネクタを外し、SSD を代わりに取り付ける。
- (２)のプラスチックカバーを元通り取り付け、(１)のネジを締める。
- リカバリーディスクからSSDへのリカバリーを行う。
以上の手順で、SSD で問題なく使えるようになりました。CrystalDiskMark の結果は以下の通りです。
体感速度もかなり速くてフルHDの液晶も見やすく*1、もう Let'snote Y7 には戻れないと感じます。ばりばり使っていきたいと思います。
*1:Let'snote Y7の液晶のバックライトも最初よりだいぶ弱くなっていたかな？？
垂直統合は必要か？
そうですね。Apple や Google は垂直統合の企業と言われます。
私は、垂直統合それ自体は必要な場合があると思っています。垂直統合に伴って内向きで閉鎖的になってしまうことが悪いのだと思います。
経営学では、企業が垂直統合か水平分業かのどちらを選択すべきか(MAKE or BUY)は、取引コストで説明が可能です。
垂直統合を考える上で、一番大事なのは「取引コスト」という考え方。
「取引コスト」とは、売り手と買い手が取引をする際に発生するありとあらゆる費用を指す。提案活動をし、価格交渉をし、契約書をとりかわすなどの一連の作業にはコストが当然伴う。このモノの購入価格以外などとは別のコストのことを「取引コスト」*1という。「垂直統合の最も重要なメリットとは何か？」と問われれば、「取引コスト」を低くおさえ、機動的な経営を可能にすることと、私なら答える。
この引用させていただいたブログエントリは非常に参考になるのと思うのですが、以下のところの考察は同意できません。
情報技術の進展により「取引コスト」が全体的に削減され、従来と比較し「文系/スーツ族」による調整という「取引コスト」の必要性が薄れてきたのは事実。
私の考えは逆で、
- 商品の特性として取引コストが少ない場面では、「文系/スーツ族」での調整で済み、水平分業が優位となる。
- 商品の特性として取引コストが大きい場面では、エンジニア同士でしか理解できなくなり、垂直統合が優位となる。
と考えています*1。
情報技術の進展により「取引コスト」が全体的に削減されているというのは確かですが、その同質化した競争の中で優位性のある商品・サービスを提供するためには、より取引コストの高い部分に注力しなければならないのが現状だと思います。
Apple では、その優位性はユーザビリティ（ユーザエクスペリエンス）でしょう。「ユーザビリティ」は極めて客観評価のしにくい品質指標*2であり、ユーザビリティへのこだわりは取引コストを増大させます。アップルは垂直統合からもたらされるユーザビリティを差別化要因として、競争に勝っていると私は見ています。
これはIT企業でも同じです。「ラフなコンセンサスと動くコード」が大事なのは、きっちりとしたコンセンサスに至るまでの取引コスト*3が高いからです。「発注企業」と「受注企業」、「デザイナー」と「プログラマ」と「ＤＢＡ」と「インフラ担当者」が過剰に分業していては、まず動くコードを得るまでのコストが高くなります。「ソーシャル・ネットワーク」の映画でザッカーバーグが Facebook を最初に立ち上げたときのように、すべてを独力でハックするのが、一番取引コストが低く、
IT企業にとって垂直統合は必要です。ハッカー文化を活かすためには、外注（水平分業）よりも、内製（垂直統合）が必要なのです。
オープンイノベーションのウソ？
こうした流れに西野氏は異を唱えます。これまで技術開発を軸に据えた企業の中でオープン・イノベーションの成功例はないし，今後も難しいのではないかとみます。P&G社の例に対しては「日用品レベルの開発の話で，既存の技術と技術の組み合わせで済む場合ならあり得る」と評価しますが，同じ考えが「先端技術を軸にする企業には通用しない」（西野氏）と指摘します。
オープンイノベーションは、日用品レベルなら成り立つが、先端技術では通用しないと主張されているようです。
しかし、チェスブロウさんの本に書いてあることは逆のように思われます。
“オープンイノベーション"では、このモデルを支持する証拠として掲げたものは、ほとんどすべてコンピュータ、IT、医薬品などのいわゆる“ハイテク"産業から得られた定性的な証拠だけだった(Chesbrough 2003a、2003b、2003c、2003d)。しかし、これらの業種は、先進工業経済のさまざまなセクターのなかのごく一部を代表するものでしかない。オープンイノベーションのコンセプトがローテク産業や素材産業にも当てはまるかどうかは、まだ答えられていない問題だ。
むしろ、オープンイノベーションの事例はこれまではハイテク企業に偏っており、ローテクや素材でも通用するかはまだ未知数、と書かれています。
オープンイノベーションのコンセプトが過度に持ち上げられ過ぎているという懸念は私も持っていますが、ちょっとこの批判*1はずれているような気がしました。
*1:「技術経営の常識とウソ」はまだ未読です。
「ハッカー中心の企業文化」を偉い人に説明する
デブサミ2011で、よしおかひろたか氏のセッションを聞きました。
「生涯一プログラマ宣言」が非常に印象に残っているのですが、直接お話を聞くのは初めてです。
期待して聞きました。
非常に素晴らしいメッセージだと思いました。
ハッカー文化は、「自分に心地良いから」必要だ、というよしおかさんのメッセージは、エンジニアである私には非常にプリミティブに共感できます。その他の理由は「偉い人に説明するための理屈」という割り切りも素敵です。
ただ、私はエンジニアでありながら、夜間大学院で経営学を学んでいます。それは、やはり偉い人に説明するための理屈も必要と感じているから、という面もあります。
偉い人たちの一部は、企業経営はトップダウンで進めるべきで、ハッカー中心の文化は正しくない、と考えています。しかし、これは正しくありません。ハッカー文化が企業の業績に貢献するということは、現代の経営学ではスタンダードな考えです。
トップダウン型の経営戦略論を、「分析型戦略論」と言います。しかし、下に示す「分析型戦略論の前提」を満たす企業がどれだけあるでしょう。
■分析型戦略論の前提
（１）環境が分析可能であること。
（２）組織メンバーが提示された戦略を十分に了解し、自動的に計画通りに動くこと。
（３）戦略決定者が戦略代替案を全て列挙でき、その結果も予測することができること。
しかし、現実はそうではない。「行動の中から戦略を生み出す」こともある。
⇒「プロセス型戦略論」の台頭
特にハイテク・ソフトウェア企業において、
（１）環境は分析・予測が難しい。
（２）社員は「提示された戦略（中期経営計画など）」を、単なる計数目標としか思っていない。
（３）戦略決定者（役員・管理職）は最新の技術動向が理解できない。
というのが実際のところではないでしょうか。
そのような企業では、プロセス型戦略論のアプローチ「行動の中から戦略を生み出す」ことが重要になります。アジャイル的で、ボトムアップで、管理より自由・自律を重視する企業戦略です*1。
ではそのような場合、経営者は、何をすればよいのでしょうか。行動の中から戦略を生み出す場合であっても、「企業内の人々の意思決定の指針となるもの」としての経営戦略が必要なのです。例えば、世界２位の製薬会社のメルクは、
このことは、メルクが2000年に出した年次報告書によく表れている。同社は優秀な社内研究組織を抱えていることで広く知られているが、報告書の8ページには、次のようなことが書かれている。
「メルクは、世界の生物医学研究の約1%を担っている。しかし、世界中の大学、研究機関、企業と積極的に連携して残りの99%を取り入れ、最良の技術と潜在製品をメルクに持ち込まなければならない。バイオテクノロジーとヒトゲノム(最近目立つ2つを挙げただけに過ぎないが)の知の奔流は、1つの企業が単独で相手にするには複雑すぎる。」
重要なのは、このような社外の知識供給源が、大学や国立研究所だけではなく、スタートアップ企業、専門的な小企業、個人発明家、さらには引退した技術スタッフや大学院生にまで広がっていることだ。
と、社外の知識に目を向けることの重要性を経営者が認識しています。
IT業界においては、社外の知識（イノベーション）の大きな供給源が「勉強会」であることは、もはや疑いがない事実であると思います。
経営戦略として、社員の勉強会への積極参加を掲げる企業があってもいいし、あるべきだと思います。
そうしたイノベーションを学ぶ場としていまもっとも機能しているのが勉強会です。もしも社外での勉強会の出席を禁止している企業があるとすれば、イノベーションに取り残されていくか、あるいはイノベーションを学ぼうという意欲ある社員を失うかのいずれかになるでしょう。
私も、自分のため、エンジニアのため、そして、企業の競争力向上*2のため、「ハッカー中心の企業文化を日本に根付かせる」ことに賛同し、応援します！
*1:「創発的戦略」とも言います。デブサミ2011のテーマとも合致しますね！
*2:意地悪な人は、「じゃあ、なぜハッカー文化があったはずのDECはイノベーションのジレンマに陥り競争に敗れたのか？」と聞くかもしれません。私の答えは、現代の二都物語 なぜシリコンバレーは復活し、 ボストン・ルート128は沈んだか アナリー・サクセニアン (著), 山形 浩生 (翻訳), 柏木 亮二 (翻訳) にあるように、ハッカー文化には外部性（規模の経済性）があり、「オープンなハッカー文化が根付く地域性」が重要なのではないかと考えます。
携帯対応クイズシステム KtaiQuiz 公開しました
先日、結婚披露パーティ（いわゆる二次会スタイル）で、携帯電話を使ったクイズゲームをしました。
その時に使用したシステムを、GPLv3 で公開します。
システムは、Java + SAStruts (Super Agile Struts) で作りました。
SAStruts はサクサク作れてとってもいいですね！
URLとそのQRコード*1を書いた紙を、参加者に配布して、携帯やスマートフォンで回答してもらいます。
回答分布や成績発表は、パソコンで表示してプロジェクタでみんなに見せます。
クイズ参加者54名で、Amazon EC2 *2 の Micro Instance 1つで十分でした。
後でログを見たところ、最長のリクエストでも 6ms で処理できていました。
Micro Instance なので、もちろん Free Tier の枠内*3です。
完全に無料で実施できました。Amazon に感謝！
ソースコードは GitHub にあります。
https://github.com/takagiko/KtaiQuiz
コメント、フォーク等歓迎です。
*1:残念ながらQRコード生成機能はありません。私は「QRのススメ」で手作業で作りました。
*2:当日は、普通にAmazon Linux AMI(32-bit)に手動でJ2SE6とTomcat7をインストールした環境を使いましたが、後で確認したところ Amazon Elastic Beanstalk でもそのまま動きました。
