システムアーキテクト通訳案内士のブログ

前回の記事ですが、読者の方から洗脳を解くには弱いという指摘を受けたのでちょっと補足を考えてみました。実際にオブジェクト指向に洗脳されている方には何をいっても聞かないのですが、そもそも論として、なんでこんな記事を書くのか？ということを説明しましょう。 一般的な話になりますが、エンジニアの中には原理主義者よろしく自身の考えを曲げない人が確かにいます。その人の世界で頑張ってもらえればよいのですが原理主義者の中には妥協という言葉をしらないのか、他人のコードや考え方に口出しをする方もいらっしゃいます。たとえば『手続型はダメ。オブジェクト指向はよい』とかですね。彼・彼女が完成されたエンジニアなら口出しも立派なアドバイスとして成立するでしょうが、ある意味究極のセオリーだと私が考えるのは『コードに正解はない』ということです。あるとすれば『こちらの方がより適切かもしれない』ということと『動くコードはやっぱり最強』ということです。あるエンジニアに、その昔私が書いたコードをありがたく手術と称してリファクタリングしてもらいましたがテストをすると重要なエラーチェックが抜けていることに気づきました。質問すると「まだ書いていない」という返事をもらいました。つまりこういうことです。エラーチェックのコードは時として見栄えが悪くなります。まぁ通常処理に加えて異常系の処理を加える関係上仕方がないでしょう。そういうコードから異常系の処理を取り払えば確かに見栄えはよくなります。さて、見栄えは良いが重要な処理が抜けているコードと見栄えは悪いがきちんと処理が入っているコード、あなたはどちらを評価するでしょうか？見栄えを取るという人は将来失業しないように気を付けましょう。 オブジェクト指向に心酔するのは構わないのですが、結論から言いますと残念ながらオブジェクト指向技術は思ったほど役には立ちません。詳しくは連載を通して理解してもらえればよいのですが、非常に残念なことにオブジェクト指向に過剰に心酔する人がいるのも事実です。例えば、この記事です。 staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて 経験のあるエンジニアならこの記事が眉唾だと理解できるのですが経験の浅いエンジニアなら真に受けてしまうでしょう。少し技術的な点を突っ込んでおきます。記事中

アセンブリやCOBOLのような言語では、オブジェクト指向言語で一般的なカプセル化という考え方がきわめて弱いということがあります。変数は静的なグローバル変数が中心であり、

とありますが、アセンブリ言語でもローカル変数はあります。またいわゆるメンバ変数もシミュレートできます。もし仮にアセンブリでローカル変数がなかったりメンバ変数をシミュレートできないとすればJavaやC++のコードはどうやって実行されると考えているのでしょうか？OSはどんなふうに記述されていると考えているのでしょうか？JavaやC++はコンパイラを通して一旦機械語に変換されます。アセンブリとはその機械語に一対一に対応します。また、そもそも論としてアセンブリとCOBOLを同じテーブルに並べるところにもの凄い違和感を感じます。もしあなたが違和感を感じられないのならオブジェクト指向を勉強する前に他に勉強することがあるということになります。 さてこの方の約3年後の他の記事を見てみましょう。 開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 引用しますと、

最後に、最近になって気づいた自分の間違えについて書いておかなくてはなりませんね。以前であればこうした設計上の問題は日本のSI業界の構造が問題なのであるという話をしていたかもしれません(^_^;)が、ここで書いたような話は多少フィクションが入っているとはいえ、実際私がSI業界以外の今の会社で体験したことに基づいていると告白しなくてはなりません。言語の特性から、Javaで開発していると、こういった設計上の問題が起きやすいということがある可能性もありますが、こういった話はSIer以外でも、どこの国の開発チームでもあるのだなということですね。

この中にあるJavaで開発していると、こういった設計上の問題が起きやすいということがある可能性もあります この感覚は実はオブジェクト指向症候群から脱する第一歩になります。多くの生き残っているエンジニアは大なり小なりこういう感覚を端緒とし、次に”Javaはダメだ○○は良い”となり、最後には”オブジェクト指向がダメなんだ”となります。もちろんですが私も20年程前にこういう感覚に襲われたことがあります。 まとめますと、オブジェクト指向症候群にかかると間違った知識をまき散らします。さらに病気から抜け出すと後でそれを修正しなければならないという二度手間が発生するわけです。できれば早く抜け出した方が本人の為でもありますし業界のためでもあります。 と長くなったのと月末でいろいろ忙しいので、今週はこれにて終了です。次回は、メソッドと関数についてもう少し突っ込んで話したいと思います。

先週に続きましてオブジェクト指向再考ということで特にオブジェクト指向に毒された方を対象に現実的な観点でプログラムできるように、プログラマとして社会復帰できるように、ヒントを出したいと思います（もちろん回復するかどうかは本人次第です）。 今週からはメッセージについて話たいと思います。世の中には、 メソッド（メッセージ）>>どうしようもない壁>>関数 と思っている方がいらっしゃるようですが、今後数回に分けて、この『どうしようもない壁』というのはオブジェクト指向病特有の幻覚であるということを示したいと思います。まぁ、厄介なことに患者さんには明確に壁が見えているのでなんとも言えないのですが、もし少しでも『これは幻覚かも？』と思った方はこの連載が助けになるかもしれません。ちなみに『この壁を感じれないやつはプログラマとして終わっている』とお思いの方はお帰り頂いて構いませんし、反論のコメントを書き込んで頂いても構いません。 前回の最後に示しましたが、オブジェクト指向のキーファクターとしてメッセージがあります。この考え方（パラダイム）はそれはそれで素晴らしいものです。分かり切った例をあげますと、マウスの入力（クリック）がメッセージとしてOSに伝わり、イベントハンドラ（コールバック関数）に制御が引き渡されます。当たり前のようですがこの仕組みはメッセージパラダイムを具現化したものになります。もしメッセージを使わなかったら、例えば定期的にマウスの位置を読み込み、クリックされたどうかを確認することになります。考えただけでも厄介ですよね。GUIプログラムがイベント駆動型と言われる所以ですね。 さて、ここでのキーポイントは、『世の中の事象は全てイベント駆動（メッセージ）で記述するのが良いことか？』ということになります。例えば、以下のプログラムを考えましょう。 ユーザがスタートボタンをクリックしたら画面に"Hello"と表示する。 間違いなく、『ユーザがスタートボタンをクリックしたら』、というところはイベント駆動と相性がいいですね。では次の 『画面に"Hello"と表示する。』・・・・・(A) というのはどうでしょうか？この部分はイベント駆動またはメッセージで記述できるでしょうか？ よくオブジェクト指向の教科書に出てくるのですが、 『画面オブジェクトに、引数に"Hello"を指定して表示依頼のメッセージを送る。』・・・・・(B) というのを見受けます。最初に指摘しますと(B)は(A)を劣化させたものだと言えます。 ポイントは(A)は手続き指向で書かれて、(B)はオブジェクト指向（メッセージ指向）で書かれています。そして重要な点ですが、この場合、(A)はプログラムの仕様（本当にやりたいこと）を表していて(B)はプログラムそのそのものの説明を行っている点ということになります。つまり、(B)は以下のようなコードの説明を行っているということになります。 label.setText("Hello"); ここで画面オブジェクトというのがlabelになり、setTextが表示依頼メッセージで"Hello"が表示対象の引数ということになります。 つまり(B)は上記のコードの説明を行っていることになり、(A)は上記のコードの意図を表しています。 もし上記のコードにコメントを付与する場合、（A)、（B)どちらが良いでしょうか？ label.setText("Hello"); // 画面に"Hello"と表示する。・・・・・(A) label.setText("Hello"); // 画面オブジェクトに、引数に"Hello"を指定して表示依頼のメッセージを送る。・・・・・(B) (B)の方がよいという考え方の人に質問したいのですが、ラベルオブジェクトに値をセットする方法にはプロパティを使うというものもあります。つまり以下のコードもありえます。 label.Text = "Hello"; この場合、(A)、(B)どちらのコメントの方が適切でしょうか？ label.Text = "Hello"; // 画面に"Hello"と表示する。・・・・・(A) label.Text = "Hello"; // 画面オブジェクトに、引数に"Hello"を指定して表示依頼のメッセージを送る。・・・・・(B) それとも以下のようにコメントするのでしょうか？ label.Text = "Hello"; // ラベルプロパティに"Hello"をセットする。・・・・・(C) もっとも、(C)のような発想もオブジェクト指向から離れたと言えるでしょう。 さて、ある程度経験のあるエンジニアなら大なり小なりこのようなジレンマを抱えたことがあるかと思います。つまりメソッドの中身を書こうとしたときに『どうもオブジェクト指向していないな・・・』と感じることがあったかもしれません。しかしよく考えてみれば分かりますが、メッセージ指向というのはある種の手続きの上っ面（呼び出し方法）についてパラダイムであり中身をどうするかは別問題ということに気付くかと思います。 ここで重要なことは、 メッセージというのはプログラミングパラダイムの一つであり、メッセージで表現した方がよいもの（例えばイベント）もあれば、そうでないもの（手続き指向のもの）があるということで、プログラマは適宜適切なパラダイムを選択してプログラムを行えばよいです。多くのプログラマは、プログラミングパラダイムについて オブジェクト指向（メッセージ指向）> 手続き指向 と考えているかもしれませんが、実はそれぞれ適材適所があり適宜使用すればよいということになります。つまりマルチパラダイムですね。さてオブジェクト指向言語しか知らない方は実は手続き指向という発想がないかもしれません。何かをステップバイステップで処理をするという発想が手続き指向になります。特段難しいとは思えないですが、もしピンとこない方がいらっしゃいましたらコメントを下さい。 イベント処理を手続き指向で考えるのは不適切ですし、能動的に画面に何か表示したいと思った時にいちいちメッセージ云々を考えるのも不適切ということになります。そう考えると以下の2つの記述方法のどちらかが適切か理解できるかと思います。 z = 3 * x * y + 4 * x + 6 * y + 2; z = 3.multiply(x).multiply(y).add(4.multiply(x)).add(6.multiply(x)).add(2); もう迷う必要はなく上の方が適切だと理解できるかと思います。数式も一つのパラダイム（というか表現方法の一種）だと理解すれば無用なパラドックスに悩まされる必要もなくなります。 次回は、メソッドと関数についてもう少し突っ込んで話したいと思います。

　前回出した記事（オブジェクト指向おじさん？）のあいださんのコメントで最も興味深いものが、オブジェクト指向しかしらないプログラマが増えてきている、というものである。実は私はそれまで『なんでこうオブジェクト指向信者が途絶えないのか？』と疑問に思っていたのだが冷静に考えれば解るとおり『良いも悪いもなくソレしか知らない。』（あいださんのコメント）世代が増えて来ているようだ。幸いにして私の周り半径3メールではそんな奴はいないので私の視野が狭くなっていたらしい。そういう意味では前回の記事をアップして良かったと思う。 また、元々、オブジェクト指向に関する記事を書こうかと思って対象読者を従来の手続き型言語に精通している人としようかと思っていたのだが方針を若干変更してメインターゲットを『オブジェクト指向しか知らない世代』にして、今後増えるであろう、オブジェクト指向症候群に掛かった患者への処方箋を今後数回に分けて書くことにする。 　オブジェクト指向という言葉を聞くとみなさんはどんなイメージをもたれるでしょうか？『オブジェクト指向とは何か？』を素人に説明するとプログラミングパラダイムの事でつまりプログラムを開発する上での一つの考え方や一つの模範ということになる。実はこれ以上でもこれ以下でもないのですが、もしあなたが以下のどれか２つに当てはまるのならオブジェクト指向症候群に掛かっているかもしれないので、この連載は役に立つだろう。 　１．関数という言葉に嫌悪感を感じる。または時代遅れの遺物だと感じる。 　２．よく他のプログラマ・言語に対して『オブジェクト指向ではない』と言っている。 　３．staticを使っている人をみるとプログラマとして終わっていると感じる。 　４．過去にオブジェクト指向を批判した記事を読んだが書いている奴がオブジェクト指向を分かっていないだけだった。 　５．C++が最高、他の言語はダメと思う人。 　６．Javaが最高、他の言語はダメと思う人。 　７．C#が最高、他の言語はダメと思う人。 　８．と言いつつも、自分自身がオブジェクト指向というのが何か実は良く解っていない。 さて、こういうと『お前が解っていないだけだ』と批判を受けそうなので少し私自身について説明します。私は14歳の時からプログラミングを初めて今年で32年目になります。仕事で使った言語は、覚えた順からBasic,Assembly,C,C++,VB,SQL,Java,Perl,PHP,MDX,Ruby,VB.NETです。ちなみにAssemblyは複数のCPUのインストラクションセットを覚えたし、実際に20年前まで仕事で使っていました。メジャーな言語ではC#が抜けているがやったことがないだけです。オブジェクト指向についていうとこれまた20年以上の経験になり、いわゆる手続き型言語からオブジェクト指向言語へコンバートした人になります。批判される前に私のオブジェクト指向の経歴をいうと、十数年前にJavaの記事を書いたこともあるし、ADPというプログラミング言語のプロジェクトを持っているがこれはC++で書かれています。またADPもオブジェクト指向をサポートしてます。その関係で一般のプログラマよりもオブジェクト指向についてよく考えていると自負している。 さて、まず最初の処方箋を言うと、オブジェクト指向は過大評価されている点を挙げましょう。実際は全くそんなことはないのにも関わらず、『オブジェクト指向はプログラマが進む最終地点』と考えている人が多いでしょう。歴史的にみてオブジェクト指向が持てはやされたことがありそれに無意識に乗っかっている人々がいたということもあるが、実はオブジェクト指向自体になにかプログラマを引き付ける魅力があります。ある人はそれを『究極の一手』と表現し、またある人は『彼女（彼氏？）』と言ったり、私自身も『オブジェクト指向はプログラマが進む最終地点』と考えていた時があった。さてここまでで『私がオブジェクト指向を理解していない』と思ったあなたは充分オブジェクト指向病に冒されていますので、何かコメントをしよう考えたのなら少し我慢して以下を読んで頂いて反論を頂きたい。 誰でも知っていることだがオブジェクト指向というのはもともと分類学の技法をプログラミングに取り入れて複雑なプログラムに対応しようというパラダイムの一種で、クラスとか継承とか多態性という言葉は分類学から借りてきたものであるといえる。ここで冷静になって考えてみれば分かることですがそもそも世の中の全ての事柄を分類学でカバーできるでしょうか？世の中の学問を見渡せば分かるとおり分類学では全てはカバーできないことは理解できるでしょう。つまり継承とか多態性というのは一部の領域にのみカバーをすることが保障されているということであり、ここで代表例を挙げると、GUIシステムにはオブジェクト指向がうまく適合できたようで、他の例を挙げると私の経験上になるがプログラミング言語の処理系もうまくマッチすると思う（残念ながら全く問題がない訳ではないが）。その他、経験上言えることは、一連の法則性を持った多様なものを処理するにはオブジェクト指向が向いていると考えられる。ほかの例を挙げると、実はオブジェクト指向ってしっくりこないんです！の記事にある、とりすけ さんのコメントで税金計算処理の適用事例があります。 以上、確かに適用できる事例はありますが、逆にいうと応用例はかなり限定されています。よく自称オブジェクト指向専門家に具体的な話を聞くと『息を吸うようにインタフェースを使っている』という分かったような分からないような返しをされますが、具体的な話ができないということはそもそも彼（彼女）も分かっていないということになるでしょう。本当に息を吸うようにインタフェースを使っているのなら具体例が多数出てくるでしょう。 また、オブジェクト指向の本質はメッセージだ！という人もいらっしゃいます。なるほどメッセージをやり取りすることにより複雑なシステムを簡単に構築しようということらしいです。では以下の２つのコードはどちらが理解しやすいでしょうか？ z = 3 * x * y + 4 * x + 6 * y + 2; z = 3.multiply(x).multiply(y).add(4.multiply(x)).add(6.multiply(x)).add(2); 『下のコードの方が良い』という人はぜひリハビリを行ってください。少なくとも人前では上の方がよいと言いましょう。ちなみに当たり前ですが、これを持ってオブジェクト指向がダメだと言いたい訳ではなく、言いたいことは、『メッセージというある種のプログラムを抽象化する道具も乱用すると却って悪戯にプログラムを複雑にする』ということです。 次の回（おそらく来週？）このメッセージについて考察したいと思います。

　私の盟友（？）ことみながわさんの日記が更新されたので覗いてみた。2016年1月29日の記事によると、とあるWEBの記事「staticおじさん」はなぜ自信満々なのかというのが目につく。 この手の記事に対しての警鐘は以前にも行ったのだが、未だにこういう煽り記事が出てくるということは出版業界はよっぽど不景気なのか？と邪推したくなる。 アメリカに留学して習った単語にobjectiveというのがあり日本語訳は客観的で、反対語はsubjective（主観的）になります。論文を書くときは客観的であれといわれます。といっても何が主観で何が客観か分からないでしょう。本当かウソか分かりませんがアメリカではこのobjectiveということを子供の頃から教わるらしいです。もっとも子供の頃にそんなことを習ったことのない日本人は文章を読むときに、何が主観的か客観的かが判断がつかないこともあるでしょう。ちなみに何の説明もなしに『普通はこうだ』とか、他にも記事を読んで『俺の意見を代弁していてくれる』と思ったら、その記事は主観的である可能性があります（主観的の定義に従えば自明ですよね）。 さて、元の記事にあるこの部分

　Javaでメソッドを呼び出すときにはクラスからインスタンスを生成してインスタンスのメソッドを呼び出すのが普通です。一方、staticメソッドはインスタンスを生成しなくてもクラスから直接呼び出せます。このため、オブジェクト指向プログラミングを理解していない古いタイプのプログラマは、Javaでもstaticメソッドを多用します。これを揶揄して「staticおじさん」と呼ぶのです。

これは、 インスタンスメソッドを使う→普通 staticメソッドを多用する→プログラマがオブジェクト指向を理解していない可能性あり と読み取れます。思わず普通ってなんやねん？と突っ込みたくなるのですが、 そろそろこのインスタンスメソッドを使うのが普通という誤謬を解きたいのですが、staticメソッドは場合によっては推奨されています。 期待するコードを期待するように書こうという本から引用させていただくと

クラスのメンバへのアクセスを制限するもう一つの方法は、メソッドを出来るだけstatic にすることだ

このReadable codeという本は私は英語版を購入したのですがそこでも同様のことが書かれています。 また、英語が読める人は、static methodで検索をかければいろいろ議論を見ることができます。たとえば以下のQAたち https://www.quora.com/Why-is-using-statics-Static-method-block-variable-in-Java-programming-bad-programming http://programmers.stackexchange.com/questions/98083/cant-i-just-use-all-static-methods ここでは、インスタンスメソッドを使うのが普通とか訳のわからん理由ではなくきちんと事実に則って議論がされています。 事実（fact)に則って議論するということは客観的(objective)な議論ができているということになるでしょう。 ざっくりとまとめますと、staticメソッドを使うと 欠点：継承ができなくなる。ポリモーフィズムも使えなくなる。 利点：メンバー変数へのアクセスを制限できる。パフォーマンスが上がる。 ということです。他のものは自明として、利点のところで『パフォーマンスが上がる』かは検証の必要があるのですが、ポリモーフィズムはオーバヘッドを発生させるのでそれを使わなければパフォーマンスがあがる可能性はあります。 また欠点の中で、『ややこしくなる』という意見もあったのですが、これは主観的な意見でしょう。たとえばstaticメソッドを使いなれた人はむしろすっきりとすると考るかもしれません。 さて、継承もポリモーフィズムも使わないということであれば、staticメソッドを使ってもよいということになるのですが、この反論として、『オブジェクト指向でなくなる』というのがあります。もはや手段と目的が混同されているとしか言いようがない意見でいやはや疲れます。 まぁ一介の無名なエンジニアが何をいっても仕方がないのでもっと説得力のある例を出しましょう。 επιστημη さんという著名なライターさんがいらっしゃいますが、彼は思い切りstatic メソッドを使っておられます。 http://blogs.wankuma.com/episteme/archive/2012/12/28/310396.aspx のコードのrefereeクラスがそれに当たります。refereeクラスには3つのメソッドがありますが、すべてstaticメソッドになっています。 つまり、事実としてstaticメソッドは使うときは使うのです。ちなみにもちろんですが、επιστημη さんがオブジェクト指向を理解していないということはないでしょう。 という訳で、

　ただ、現実に年齢を重ねると、どうしても守りに入りがちなのは事実です。「自分はstaticおじさんなのではないか」という問いは、常に忘れてはならないのでしょう。

というヒマがあったら自身が思わぬ誤謬をしていないか記事の検証を行うことを勧めます。 2/4追記 　コメント欄で文意を汲み取っていないという指摘を受けましたが、まぁ充分文意を汲み取って反論をしているのですがどうも分かりづらいかもしれないので、補足します。

　ただ、現実に年齢を重ねると、どうしても守りに入りがちなのは事実です。「自分はstaticおじさんなのではないか」という問いは、常に忘れてはならないのでしょう。

こういう教示的な文章は一見ごもっとなことのように受け取れますが、冷静に読めば分かりますとおり、ど素人でも同様のアドバイスができるでしょう（例を出すとサッカーや野球観戦をしているおっさんが野次っているさまと同じと言えば納得できるでしょうか？）。 社会人としては自分を律したり反省することは歳をとろうが若かろうが、技術者であろうがなかろうが、常に必要でいちいちアマチュアに指摘されることではないです。 そうはいっても100歩譲って、プログラミングに携わるプロが 『（引用先の記事に書かれてるニュアンスでの）自分はstaticおじさんではないか？』 と自問するということはどういうことでしょうか？ つまり、『staticは使えるのか？使えないのか？』という正に私がここで行っている議論をすることです。 そしてまさに インスタンスメソッドを使う→普通 staticメソッドを多用する→プログラマがオブジェクト指向を理解していない可能性あり こういう意見が20年前はともかく今となっては偏見に基づく誤謬でしかないということを認識することが重要だと言いたいわけです。プロなら気づきましょうということと、素人なら知ったかぶりをするのはやめましょう、という話です。

ここ1年ほど続いた炎上プロジェクトですが、奇跡的（？）にやっと落ち着き定常運転ができるようになったのですが、やることはまだまだたくさんあるので全くもってヒマがないので、更新もすっかりご無沙汰になったのですが、そのおかげで変な人の付きまとい行為も減り結果オーケーではある。 変な人というと総務省が、「独創的な人向け特別枠（仮称）（通称：変な人）」というのを募集するようです。 『「Disruptive Change」：世界的に予測のつかないＩＣＴ分野において、破壊的な地球規模の価値創造を生み出すために、大いなる可能性がある奇想天外でアンビシャスなICT技術課題に挑戦する人を支援。閉塞感を打破し、異色多様性を拓く。』 とか 『＊ゴールへの道筋が明確になる価値ある「失敗」を奨励』 ということで、来年あたりならヒマができるのでADPを引っ提げて応募しようかと考え、調べていたら色々思うことがあるので、コメントします。 そもそもなぜこのような政策を実行するのか？つまりこの政策の背景ですが、『イノベーション創出委員会』ということろがとりまとめを行っています。とりまとめの案が以下から読めます。 イノベーション創出委員会最終とりまとめ（案）に対する意見の募集 あとインタビュー記事が以下にあります。 「俺の言うことがわからん奴はバカ」という人が欲しい--総務省のイノベーション創出事業“変な人” これらをみて思ったのは、やはり日本は衰退に向かっているんだということで、さらに残念なことに国家や大企業ではそれを克服できないんだなということです。私の経験から一言で言えば潰れかけの会社が色々足掻いているという印象がぬぐえないです。 もちろん、座して死を待つよりは遥かにましですし何事もチャレンジすることはいいのですが、例えば、上記の記事をみますと変な人の育成方法は、『いまのところ決まっていない。』とか、いやいや人任せにせずにそれぐらいは自分で決めましょう突っ込みが出てきて思わず心配してしまいます。 また、 『「なぜ“変な人”という表現ではダメなんだ。“独創的な人”より伝わりやすいじゃないか。これだからイノベーションが起きないんだよ」―こう指摘したのは元総務副大臣の○○○○という。』 については、言葉尻をとらえた本質的でない所で熱く議論をしているんだ税金を使って・・・と思わざるを得ない。まぁ成長が鈍化した会社の会議なんかで見る光景ではあるのですが・・・。 イノベーションとは常識を理解した人があえてそれを破ることから起こると考えているのだが、つまり温故知新ですね。スティーブ・ジョブズの例で言えば、Macintoshの開発逸話を読めば、彼が変な人だとは思わないはずで、卓越したプロデューサーというのが私の印象になります。まぁ私にはできないですね。 記事では変な人を探す理由として、イノベーションのジレンマをあげています。 イノベーションのジレンマとはWikipediaによると『巨大企業が新興企業の前に力を失う理由を説明した企業経営の理論』ということです。つまりイノベーションのジレンマとは今の日本の状況を説明するものではなく単に大企業が衰退する理論的な説明にしかすぎないです。まぁ日本の新陳代謝を促す為、世界で戦えない大企業に関しては潰れて頂いてもよいかと思うのでイノベーションのジレンマは歓迎ということになります。 ちなみに記事からはあたかも今の日本ではイノベーションが起こっていないという印象を受けますが、日本でイノベーションは私の半径３メートルでもみることができる。 ほんの５年前までは、ガラケーを使いながら『スマホってなに？』といっていた人たちが今ではスマホでガンガンゲームをやっている。スマホ歴自体は私の方が長い（７年以上）のだが、その適応力をみると個々人でみた場合、日本人のテクノロジーを扱うポテンシャルは全く衰えていないと実感する。スマホは確かに海外発のテクノロジーかもしれませんがその中に入っているアプリは日本で作成されいます。 『たかがスマホのゲーム』と思うかもしれないが、5年前と今で電車内の人のようすを比べますとまさにイノベーションが起こったといってもよいでしょう。 というわけで、政府や大企業が危機感を持っているのは解ったのですが、まぁ既得権益を享受している組織は、今の状況は芳しくないと考えているようですが、破壊的イノベーションはそういう既得権益者が破壊されるとこではないのか？という疑問が出てくるのですがどうだろうか？ ちなみに私の半径3メートル以内の話になりますが、個人に入るかどうかは別として優秀な人はそれなりにお金をもらって仕事をしており、300万では対したことができないのだが、相場というものを理解していないのでしょうか？もっとも例えばこの事業が自宅警備員のような方に対する支援なら全くもって理解できなくもないですが、それでも『金は出せないがお前ら頑張れ』という昔居た会社の上司が言っていたセリフが思い出されます。その返答としては、だったら君たちがその金でイノベーションを起こしなさい、ということで今年の応募は見送りますが、もっとも何事もチャレンジすることはよいことですので、ちょいちょい様子をみてみましょう。