日本の経済成長と低迷
そして、このような日本的システムは、「何を作るか(What)」が明確で、「どう作るか(How)」が主な問題なときは、凄まじい生産性をたたき出します。
しかし、「何を作るべきかが明確」で、「どう作るか(How)こそが問題だった」時代は過ぎ去りました。
作らなきゃならないことがはっきりしているモノやサービスは、あらかた作って、世界中を満たしてしまったからです。
日本のソフトウェアビジネスが今後もずっとアメリカの足下にも及ばない理由
http://d.hatena.ne.jp/fromdusktildawn/20070226/1172462591
日本が急激な経済成長をなぜできたか、90年代に入ってから低迷し続けているのか何故か、というのは上の理由によるところが大きいと思います。組織のトップレベルに要求されるのは、「何を作るか」であり、これが明確であれば、実質的にこのレベルでの意思決定を行わなくてもうまくいきます。この時、重要なのは「協調性」で、改善による持続的イノベーションが効果的になるため、「努力」に比例したリターンが得られます。
しかし、日本が世界に追いついてしまった時、この成功モデルは機能しなくなります。トップに必要とされるべき、内部/外部のテクノロジーのマネジメント、将来のシナリオの想定、そして、「何をつくるか」を決定する能力が必要とされるからです。このようなリーダ/組織を作るシステムを持たない日本が低迷するのは必然的なように思えます。
グローバルな経済システムによって昔のような状態にもどることは無理でしょう。アメリカで起こったイノベーションは日本が真似する時間を持てない位にすぐに日本まで届いてしまいますし、ローカライズによってその商品がそのままサポートされてしまうからです。以下の記述にあるように、世界は水平分業の効率的な実装によってグローバルにカバーされていくと考えられます。
産業構造の変化というとき、池尾・池田本で想定しているのは、こうした広義の情報産業における垂直統合から水平分業への変化である。それは不可避で不可逆であり、すべての工業製品やサービスが何らかの意味でデジタル化する現代においては、このグローバルな分業構造の変化に適応できない企業は淘汰されるしかない。
日本企業はなぜ敗れたのか
http://blog.goo.ne.jp/ikedanobuo/e/39c2970f079ebad7f1ef793ec99f7105
この4社だけで、10兆6000億円と、日本のソフトウェア業の（主業の）売上 11兆4000億円に匹敵する。しかし、従業員は、合計24万人程度しかいない。
IT業界に関する統計（その4）
http://d.hatena.ne.jp/elm200/20091029/1256644159
特定部分を集中的に効率化/自動化して、これを世界規模でばら撒くことが現在においては効果的な戦略です。少数の優秀なチームで特定部分を徹底的に自動化して低コスト化した商品を作り、それを多くのユーザに使ってもらうことで結果的に大きな利益を生み出すというモデルです。これはコピーコストが０に近いソフトウェア（サービス）では特に有効に働きます。
ソフトウェアにおいては、微妙に異なるシステムをその都度、ユーザに合わせて作っていくような受託開発では低コスト化、価格競争力という点で非常に不利です。Microsoftのようなパッケージ、Googleのサービスのようなモデルが先進国で取りうる一番の戦略だと思います。
分業をモデル化することと、そこに知性を集中させるシステム(金融システム？)が今の日本には必要ではないかと思います。
Googleは完全な翻訳に成功するか？
米Googleは米国時間2009年11月19日，同社が運営する動画投稿サイト「YouTube」で，動画再生時に自動で字幕を付ける機能「Auto-caps（automatic captions）」を追加と発表した。
GoogleがYouTube動画に自動で字幕，日本語への翻訳も可能に
http://itpro.nikkeibp.co.jp/article/NEWS/20091120/340811/
Googleが動画に自動的に翻訳文をつける機能を開発したようです。もしリアルタイムでの処理であれば、これは同時翻訳を行っていることと同じ機能といえます。まだ、人がするような精度の高い翻訳はできないと思いますが、この先開発を進めていくと人が行うものと区別がつかなくなるくらいの品質になる可能性があると思っています。
言語翻訳とは本質的には言語間での言語ゲームといえます。言語ゲームとは以下で言及したようなものです。
言語とは、世界と記号の対応ですが、その意味は言語ゲームによって決定されていきます。言語ゲームとは、ウィトゲンシュタインによって作られた考え方で、言葉とそれが使われる状況の積み重ねで言葉の意味が決まっていくというものです。
「キラーフレーズ」がキラーではない理由
http://d.hatena.ne.jp/shat/20090826/1251302011
例えば、特定の英文というのは特定の日本語の文に翻訳することができます。このとき、日本語から見て英語は一つの世界として考えることが可能です。通常の言語ゲームでは世界と特定言語での対応が考えられますが、このときは、アルファベットが生成する記号の世界と日本語間での言語ゲームを考えることができます。この対応の蓄積によって英文に対する日本語が決定されていきます。そして、これは翻訳にとって本質的な処理だと考えられます。
一方、Googleが採用している言語翻訳アルゴリズムは統計的機械翻訳です。このアルゴリズムは大量の等しい意味を持つ英文と日本語文のペアを元に未知の英文を翻訳するというものです。つまり、統計的機械翻訳というのは言語ゲームによる意味づけに基づいた本質的な言語翻訳処理であるといえます。もしも、Googleが大量の計算リソースと翻訳文のペアを使って翻訳処理を行うとすると人が行っている翻訳にいくらでも近づいていくことが可能ではないかと思います。
成功するに当たって重要なことは、翻訳文のペアを集めることです。手段としては、同じ意味を持つ文をクローラで集めたり、ユーザに間違った翻訳文を直させるインタフェースをつけたりといったことがあると思います。もちろん、十分なデータが集まった後でも言語は変化していくものなので、常に修正のインプットを吸収しながらシステムで学習されていくのではないかと思います。こうなると人の知性を学習していくシステムが射程に入ってきそうです。
投資銀行を救済するということ
FT 大きすぎて潰せない金融機関の自己勘定取引には制約を設けるべきですか。ソロス 報酬やインセンティブの体系は統制すべきだと思います。というのは、保証を与えた以上、そうした銀行が自己資本でリスクを取って、追加的な資本投入を余儀なくされるような事態は防がないといけない。大きすぎて潰せないというコンセプトには、銀行の従業員が受け取る報酬を規制する必要性が伴うんです。
ジョージ・ソロスが語る世界経済と金融 「二番底のリスクあり」「金融機関の報酬規制を」
http://jbpress.ismedia.jp/articles/-/2031
リーマンショックに象徴される金融危機での投資銀行の救済の一方で銀行当事者の多大な報酬というのは明らかにおかしく、これに対して何らかの対応をするというのは当然だと思います。
恐らく、投資銀行のルールというのはモラルハザードを助長する構造を持っているため、ルールを変更することが必要です。失敗したときは会社を辞めるだけ(会社がつぶれるだけ)、成功したときには報酬が際限なく増える、という構造に問題があるように思えます。このようなルールのもとでは、なるべく大きな賭けをすることが最適な戦略となり、レバレッジを大きくして報酬の期待値をあげることが優先されるからです。この行動には大きく２つの問題があります。
- (1) 予想とは逆に相場が動いたときに返せない借り入れが残り、貸し手にも連鎖的に影響を与える。
- (2) ポジションが大きすぎて清算できなくなり、他のプレイヤーの取引を阻害する。
(1)は借金の焦げ付き、(2)はシステミックリスクと言われ市場の流動性を毀損するものです。どちらも自分の責任能力を越えたリスクをとっていることが原因といえます。
資本主義において、成功したときにはそれに応じた報酬を得ることは当然です。しかし、これはリスクに対する責任を前提とします。責任を取れなければそもそもリスクをとる権利をもてないはずです。救済された銀行は救済されたということによりこの原則を破っているといえます。
以上の事から、救済される可能性を持つ組織というのはリスクテイクを制限される義務を負う必要があるといえます。ソロスのいうように過大なリスクテイクの原因である報酬体系を修正することが必要ではないかと思います。
Codeの美しさと価値
技術的負債は金融の負債と似ています。金融の負債と同じように、技術的負債にも利息を支払わなければなりません。この支払いは、将来の開発で必ず発生する余計な努力というかたちで支払うことになるでしょう。
InfoQ: 技術的負債を解剖する
http://www.infoq.com/jp/news/2009/10/dissecting-technical-debt
これは全くそのとおりだと思います。Codeの複雑さというのは指数的に増えるので。
「汚い」構造は、将来のアップデート時に余分な利子(アップデートコスト)を必要とします。その利子を支払えないためさらに安易な方法がとられやすく、さらに将来支払う利子が増えてしまうという意味で、負債と全く同じ構造をしているといえます。
負債を負う理由があるとしたら、将来的に価値がある何かを買うときだけです。極端にパフォーマンスを高くすることができるとき、先行してサービスを公開するメリットが非常に大きいとき、くらいだと思います。前者の場合だと指数的なハードの性能向上で将来問題が緩和される可能性、後者の場合では将来行うべきリファクタリングのデグレリスクがあるため、これらの要素を十分吸収できると判断できるときのみでしょう。目先の中途半端な利益のために負債を負うのは明らかな間違いです。もちろん、アップデートが予定されていない場合もテストフェーズでの修正がありますし、運用時に何らかの障害が発生するリスクもあるため、このコストを潜在的に負うことになります。
しかしながら、行動に移すことは非常に難しいかもしれません。借りる側もその意味をよく理解しているはずの金融的な負債でさえよく利用されるからです。この構造が明示的に理解されていないソフトウェアではなおさらです。チームで開発する場合はさらに難しいかもしれません。メンバ全員がこのことを十分理解する必要がありますし、「政治」が入ってきます。
優秀なプログラマが優秀なメンバとしか仕事をしたがらない理由もこれが背景にあるのではないかと思います。チームの人数増加に伴って極端にプロジェクトの成功率が下がると考えられるため、チームは信頼できる少数の人たちで構成されるのが望ましいかもしれません。
ソフトウェアにおけるテストの有効性と限界
ソフトウェア開発において、テストは必要ですが、品質をあげるという意味では場合によっては機能しません。何故なら、ソフトウェアの品質は、ほとんど設計に依存するからです。
例えば、1〜Nまでの和を出力するプログラムを考えてみます。この要件を持つ設計は1通りでないことは明らかです。その意味のとおりNまでを足していく設計、再帰的にN以下の和を足す設計、数学の公式を使う設計、いろいろあると思います。
各設計に基づいて実装されたプログラムに必要なテストのパターンもその設計に応じて変わってきます。例えば、上のような設計に基づいていれば数パターンのテストで十分でしょう。
問題となるのは、設計が「複雑」な場合です。N=1なら1、N=2なら3…というように無数に分岐したプログラムの正しさを確認するには、無限のパターンが必要です。このケースは極端な例ですが、実際の要件は十分複雑で、問題の本質を捉えられなければこのような設計になってしまうことも多いと思います。
以上の事から、テストの有効なパターン数というのは、設計の「複雑さ」に依存するといえます。
全体を通して、複雑さというのは3種類考えられます。
- (1) 問題(要件)の本質的複雑さ
- (2) 設計（、実装）の複雑さ
- (3) テストパターンの複雑さ
自明ですが、(2)は(1)よりも小さくすることはできません。そして、(3) は、(2)と同程度であるとき有効です。つまり、複雑さが抑えられた設計では、テストの複雑さは要件の本質的複雑さと同程度で済み、コストが抑えられるということです。
バグを極力減らして、品質が高いソフトウェアを開発するには、複雑さが極力抑えられたシンプルな設計にする必要があります。反対に、よく設計が考えられないまま開発されたソフトウェアは、複雑さを無駄に大きくして多くのバグを内包し、テストのコストを高くします。さらに、カバーできなかったバグは運用へ送られ…ということです。
テストが有効に働くのは設計が「シンプル」に行われたときで、そうでなければ膨大なテストパターン(=コスト)を必要とし、品質を確保できなくなってしまうのではないかと思います。
プログラミングの難しさ
プログラミングは簡単であり誰でもできる、といわれます。また、プログラミングは難しいとも言われます。どっちが正しいのか？というと、どちらも正しいと思います。何故かと言うとプログラムという言葉が指す範囲があまりにも広すぎるからです。
世の中にはいろいろな物があります。
本、食べ物、動物、自動車、自動車工場、建物、飛行機、テレビ、冷蔵庫、ダイヤモンド、火星。
また、世の中には、いろいろな事があります。
医療、経営、金融、科学、接客、法律、組織、プログラムなど。
プログラムを作ることは、概念を作ることです。アーキテクトという言葉は建築家の例えからきていると思いますが、ソフトウェアにおいては、建築という概念を含む世の中に存在するありとあらゆる物事全ての概念が対象です。
対象となる概念が簡単な構造であるとき、プログラミングは簡単です。簡易的な足し算だけを行うプログラミングというのは誰でも簡単にできると思います。しかし、概念の「難しさ」に伴って、プログラミングは難しくなります。高度な整合性、依存性や、トレードオフが必要なプログラミングは非常に難しくなります。また、別の難しさも考えられます。概念間の関係性という難しさです。ソフトウェアが対象とする概念は非常に広いため、何らかの抽象化、構造化をするときに、概念の概念も考える必要があるからです。
このようにソフトウェアというのは全ての物事を扱うことのできる本質的なものですが、一括りに簡単であるとの誤解から軽視されるとすると非常に危険であると思います。現在はビジネスを部分的に置き換えるだけですが、将来的には人間でさえもその範囲に入るとおもいます。そのときにはどうなっているかというと、それを重要視して強化した組織/国に力がシフトすると言うことです。
「全体のために」働くべきか？
「つまり会社にとって何がベストか？」ということが、最終的には関係者全員にとっての利得を最大化するはず。ゲームのルールを「自分のために」から「全体のために」に変えるだけで、「囚人のジレンマ」から逃れることができる。あなたが本気で勝ちたいなら、そして経済的にも成功したいなら、このルールの変更はなるべく早い方がいい。勝てないゲームに我慢して耐えしのぶのではなく、ルールを変えよう。今日にでも、すぐ。
「勝てないゲーム」なら「ルール」を変えよう――脱「囚人のジレンマ」
http://bizmakoto.jp/bizid/articles/0909/29/news031.html
経営者と従業員の戦略における最適戦略は(高く雇う、がんばる)、(安く雇う、がんばらない)となりますが、前者が双方の利益を大きくするために双方が「全体のために」働くべきという内容です。
双方の利益のために行動するということは重要ですが、状況によっては必ずしも正しくありません。考える必要がある状況とは、相手がどの程度こちらと協力する用意があるかということです。これは信用の問題です。そして、信用はゲームの試行回数に依存します。
ゲームが一回きりで終わるとすると(高く雇う、がんばる)という選択は経営者/従業員の双方にとってリスクが高い選択となります。どちらかが裏切れば損失が高くなるからです。そして裏切る側の利益が高くなるため、裏切りの戦略にバイアスがかかります。従って、この場合、リスクが低い(安く雇う、がんばらない)を選択せざるを得ません。ゲームが複数回続けば、(高く雇う、がんばる)を選択する余地が出てきます。裏切られた場合は損失が多くなりますが、しっぺ返しをすることで相手に損失を与えることができるからです。
つまり、繰り返しゲームにすることで「安定的で」最適な戦略セットに(高く雇う、がんばる)が入ってくるということです。従って、繰り返しを多くすること、関係を長期化することが重要ではないかと考えられます。しかしながら、これは雇用の流動化とトレードオフになっているように思えます。
最適な人的価値配分をすることと最適な行動させるということは本質的に相反していて、どこかで折り合いをつけていかなければならないかもしれません。
