正解主義の文化とプログラミング教育の危うさ
―「考える力」と「信じる安心感」のあいだで―
前回は「staticおじさん」現象を手がかりに、
ネット社会における“同調の構造”と“技術信仰”について考えました。
今回はそこから一歩進めて、
「なぜ私たちは“正解”を求めすぎるのか？」というテーマを扱ってみたいと思います。
「正しい答え」を求めすぎる社会
技術の世界、とくに日本のエンジニア文化では、
「正しい答えを知ること」自体が目的化してしまう傾向があります。
これは学校教育の影響が大きいでしょう。
正解が一つに定まるテスト文化の中で、
「悩むこと」や「保留すること」が評価されにくかった。
プログラミング教育にもその名残があります。
クリーンアーキテクチャ、デザインパターン、SOLID原則……
“正しい書き方”は数多く提示されますが、
それらがどんな文脈で、どんな痛みから生まれたのかを学ぶ機会はほとんどありません。
結果として、手法は暗記され、思想は抜け落ちる。
そして、「何が正しいか」だけが一人歩きするのです。
「正しさ」の呪い
こうした文化の中で、「正しさ」は一種の呪いになります。
何か新しい設計を提案すれば、すぐに「それは間違いだ」と反応が返ってくる。
それが本当に間違いなのかどうかではなく、
“教科書(コードコンプリート)に書かれていない”というだけで排除されるのです。
この現象の根底には、「考えることの恐怖」があります。
自ら考えるという行為は、
自分の中に“わからない”を抱えることでもある。
しかし、わからないままでいることに耐えられない人々は、
「答えを持つ人」に安心を求めてしまいます。
それが宗教のように“信じる技術文化”を生むのです。
プログラミング教育の逆説
教育現場では、「考える力を育てる」と言われます。
しかし、現実には「模範解答を暗記する力」が評価されがちです。
プログラミング教育においても、
“どの言語を使うか”“どの設計が正しいか”といった形式面に議論が集中し、
「なぜそうするのか」「どんな痛みを避けたいのか」といった
本質的な問いが置き去りにされています。
たとえば、「グローバル変数は悪」という常識があります。
しかし、それがどのような歴史的背景で「悪」とされたのかを知る学生はほとんどいません。
そこに文脈がないまま、「禁止事項」としてだけ教えられる。
それでは“思考するエンジニア”は育ちません。
「正解」よりも「判断」
これからのプログラミング教育、あるいは技術文化全体に必要なのは、
「正解を教える」ことではなく「判断を育てる」ことだと思います。
正解は、過去のある時点で有効だった一つの答えにすぎません。
しかし判断とは、目の前の状況・制約・目的に照らして、
「今回はこうする」と決めることです。
そしてその判断の積み重ねが、経験であり、設計力になります。
つまり、“正しさ”は借りられるが、“判断”は自分でしか育てられない。
その違いを理解しないまま、
「正解主義」に取り憑かれた技術文化はいつまでも他人の理想を追い続けるだけです。
「考え続ける」という勇気
結局のところ、プログラミングとは「考え続ける行為」です。
最適解など存在せず、昨日の正解が今日には不適切になっていることも珍しくありません。
それでも、他人の正解にすがらず、
自分の頭で考え続ける――その不安を抱えながらも歩み続けること。
それこそが、技術者（エンジニア）としての誇りであり、自由の証なのではないでしょうか。
この文章は、ChatGPTとの共同作業により作られています。
マイナ保険証（2025年7月）資格確認証を入手しました
Youtubeの方ではマイナンバー問題ということでちょいちょい動画をアップいましたが（こちらが再生リストになります）、ここ数か月動画の更新をさぼっていましたが、この度資格確認証を入手しましたのでそれについての記事になります。
資格確認証を取得するメリット（ほぼ今までどおり保険診療が受けられる）
マイナ保険証については過去にトラブルが発生しその検証・対策もまるで素人がやっているようで（詳しくはマイナンバー問題）、今後もきちんと運用がされるかどうか怪しいところがあります。
こういう状況で安心して保険診療を受けられるようにするには『資格確認証を取得する』ことが選択肢になるでしょう。具体的には、マイナ保険証の利用登録解除（および場合により多少の追加手続き）を行うと「資格確認証」が送られてくるようになります。これは従来の保険証とほぼ同じものであり、今後も従来どおりの保険診療が受けられるようになります。政府は「デジタルだ！」といいながら、不完全な（ベータ版としか言いようのない）システムを導入しているが、そんな不完全なシステムが引き起こすトラブルにいちいち付き合う必要はないでしょう。
ちなみに、2025年7月時点での利用登録解除は数万件程度であり、今の段階では比較的スムースに登録解除ができるようです。今年は私のマイナンバーカードの更新年で、新しいカードを取得するのに2か月半かかったが、利用登録解除はそれよりはるかい迅速に手続きができるようです。一度登録解除を行い、二度と登録しないようにすれば、今までどおり安心して保険診療が受けられるようになります。
マイナ保険証でよいのではないか？
現在、マイナ保険証を利用しており特段問題がない方はそのまま利用するのも手であります。
もっとも、マイナ保険証を利用するには２つ程注意点があります。
1点目は、マイナ保険証での受付が出来ない場合があるということで政府をそれに対する対応策を示しています。要はマイナ保険証だけでなく「資格情報のお知らせ」を持った方がよいということで、マイナ保険証だけでは窓口でトラブルとなる可能性がある。
2点目は、マイナンバーカード（電子証明書）の有効期限を意識しなければならないことで、5年目（5回目の誕生日）で電子証明書の更新があり、10年目（10回目の誕生日）でマイナンバーカードの更新があります。更新を忘れるとマイナ保険証が使えなくなる。『その場合どうなるか？』ということがあるが、最終的には資格確認証が送られてくることになるが、それなら資格確認証でよいということになる。
もちろん、今後システムの完成度が上がり、マイナンバーカードの更新が習慣化すればマイナ保険証で受診するのが当たり前となるかと思われるが、時間はかかるかと思われる。
マイナ保険証の利用登録解除とそのデメリット
利用登録解除を行うには、保険者（保険証に記載がある）に連絡することになる。保険者の名称からWEBで検索を行ってホームページから『利用登録解除』の方法を調べることになる。国民健康保険・後期高齢者医療保険は市町村に問い合わせることになる。サラリーマン等のいわゆる厚生年金加入者は健康保険組合と呼ばれる団体に問い合わせることになる。
サラリーマンの方が利用登録解除を行い、資格確認証を取得しようとすると、場合によっては資格確認証が会社に送られてくるかもしれない。多くの中小企業が入っている全国健康保険協会（いわゆる協会けんぽ）の東京支部の場合は、会社に送られてきた。また全国健康保険協会は会社に対して従業員に『マイナ保険証を使うように』と通知を行っており会社員の方にとってはプレッシャーとなるかもしれない。その他、確定申告時に医療費控除を受ける際に領収書を集めておかなければならないとか一定の不便さがある（このあたりは従来どおりと言えば従来どおりである）ので今一度、マイナ保険証のメリットを再確認して、メリットが失われた場合に本当に困らないかどうか、念の為、確認する必要があるでしょう。
変な人
ここ1年ほど続いた炎上プロジェクトですが、奇跡的（？）にやっと落ち着き定常運転ができるようになったのですが、やることはまだまだたくさんあるので全くもってヒマがないので、更新もすっかりご無沙汰になったのですが、そのおかげで変な人の付きまとい行為も減り結果オーケーではある。変な人というと総務省が、「独創的な人向け特別枠（仮称）（通称：変な人）」というのを募集するようです。
『「Disruptive Change」：世界的に予測のつかないＩＣＴ分野において、破壊的な地球規模の価値創造を生み出すために、大いなる可能性がある奇想天外でアンビシャスなICT技術課題に挑戦する人を支援。閉塞感を打破し、異色多様性を拓く。』
とか
『＊ゴールへの道筋が明確になる価値ある「失敗」を奨励』
ということで、来年あたりならヒマができるのでADPを引っ提げて応募しようかと考え、調べていたら色々思うことがあるので、コメントします。
そもそもなぜこのような政策を実行するのか？つまりこの政策の背景ですが、『イノベーション創出委員会』ということろがとりまとめを行っています。とりまとめの案が以下から読めます。
イノベーション創出委員会最終とりまとめ（案）に対する意見の募集
あとインタビュー記事が以下にあります。
「俺の言うことがわからん奴はバカ」という人が欲しい--総務省のイノベーション創出事業“変な人”
これらをみて思ったのは、やはり日本は衰退に向かっているんだということで、さらに残念なことに国家や大企業ではそれを克服できないんだなということです。私の経験から一言で言えば潰れかけの会社が色々足掻いているという印象がぬぐえないです。
もちろん、座して死を待つよりは遥かにましですし何事もチャレンジすることはいいのですが、例えば、上記の記事をみますと変な人の育成方法は、『いまのところ決まっていない。』とか、いやいや人任せにせずにそれぐらいは自分で決めましょう突っ込みが出てきて思わず心配してしまいます。
また、
『「なぜ“変な人”という表現ではダメなんだ。“独創的な人”より伝わりやすいじゃないか。これだからイノベーションが起きないんだよ」―こう指摘したのは元総務副大臣の○○○○という。』
については、言葉尻をとらえた本質的でない所で熱く議論をしているんだ税金を使って・・・と思わざるを得ない。まぁ成長が鈍化した会社の会議なんかで見る光景ではあるのですが・・・。
イノベーションとは常識を理解した人があえてそれを破ることから起こると考えているのだが、つまり温故知新ですね。スティーブ・ジョブズの例で言えば、Macintoshの開発逸話を読めば、彼が変な人だとは思わないはずで、卓越したプロデューサーというのが私の印象になります。まぁ私にはできないですね。
記事では変な人を探す理由として、イノベーションのジレンマをあげています。
イノベーションのジレンマとはWikipediaによると『巨大企業が新興企業の前に力を失う理由を説明した企業経営の理論』ということです。つまりイノベーションのジレンマとは今の日本の状況を説明するものではなく単に大企業が衰退する理論的な説明にしかすぎないです。まぁ日本の新陳代謝を促す為、世界で戦えない大企業に関しては潰れて頂いてもよいかと思うのでイノベーションのジレンマは歓迎ということになります。
ちなみに記事からはあたかも今の日本ではイノベーションが起こっていないという印象を受けますが、日本でイノベーションは私の半径３メートルでもみることができる。
ほんの５年前までは、ガラケーを使いながら『スマホってなに？』といっていた人たちが今ではスマホでガンガンゲームをやっている。スマホ歴自体は私の方が長い（７年以上）のだが、その適応力をみると個々人でみた場合、日本人のテクノロジーを扱うポテンシャルは全く衰えていないと実感する。スマホは確かに海外発のテクノロジーかもしれませんがその中に入っているアプリは日本で作成されいます。
『たかがスマホのゲーム』と思うかもしれないが、5年前と今で電車内の人のようすを比べますとまさにイノベーションが起こったといってもよいでしょう。
というわけで、政府や大企業が危機感を持っているのは解ったのですが、まぁ既得権益を享受している組織は、今の状況は芳しくないと考えているようですが、破壊的イノベーションはそういう既得権益者が破壊されるとこではないのか？という疑問が出てくるのですがどうだろうか？
ちなみに私の半径3メートル以内の話になりますが、個人に入るかどうかは別として優秀な人はそれなりにお金をもらって仕事をしており、300万では対したことができないのだが、相場というものを理解していないのでしょうか？もっとも例えばこの事業が自宅警備員のような方に対する支援なら全くもって理解できなくもないですが、それでも『金は出せないがお前ら頑張れ』という昔居た会社の上司が言っていたセリフが思い出されます。その返答としては、だったら君たちがその金でイノベーションを起こしなさい、ということで今年の応募は見送りますが、もっとも何事もチャレンジすることはよいことですので、ちょいちょい様子をみてみましょう。
STAP and Sleep
去年あたりから忙しくなり、我が人生で4回目の炎上プロジェクトを絶賛体験中のところですっかり更新がご無沙汰になりましたが、少し余裕が出てきたところへ考えさせられるニュースが入ってきたので書いてみます。ちなみに、こういうニュースを聞くたびに、日本は衰退に向かっている、と感じてしまします。がそれは私だけでしょうか？STAP細胞のニュースについて、経緯をざっくり説明しますと、iPS細胞に似た性質を持つSTAP細胞（STAP幹細胞）を理化学研究所の小保方氏らが作成に成功したと科学雑誌ネーチャーに１月３０日に発表したのですが、その後、相次いで論文に対して疑義が出され理研が調査を行うことになりましたが、その後も色々な疑惑が出てきて、共同研究者の若山教授が撤回を呼びかけ、昨日（３月１４日）に理化学研究所が中間報告を行いました。
同時に会見もありまして、その内容の一部が以下から見られます。
ＳＴＡＰ細胞:会見（１）「論文の作成の過程に重大な過誤」野依理事長
ＳＴＡＰ細胞:会見（２）「論文としてもはや存在すべきではない」竹市センター長
『論文の取り下げを視野に入れて検討する』というらしいですが、どこかのブログとは違って、論文の取り下げというのは研究を白紙にするということで大変不名誉なことで、それだけのことが論文の執筆過程で行われたということのようです。
まだ中間発表なので『STAP細胞は存在するのか？』とか『論文は捏造なのか？』といったことは今後の調査を待つことになりますが、インタビューで気になったのは責任者が他人事と受け取れるような発言をしたことにあります。
ＳＴＡＰ論文:「切り張りダメとは…」小保方さん謝罪によりますと、事件に対して
『似たようなことが起こっているのであれば、時代のなせる業、カルチャーが変わったなと非常に心配している』
と発言されたのですが、仮にもマネジメント側の人間の発言としては、疑問を持たざるを得ないです。
世の中、信じられないことをする人は昔からいます。私の半径３メール以内の経験では、約１５年ほど前になりますが当時の上司が顧客とのミーティング中に居眠りをしてました。
当時プロジェクトリーダーであった私はそれが理解不能で上司の足を蹴って起こし、ミーティングが終わってから叱責し、その後、続けて居眠りしたので、上の上司に話してプロジェクトから追い出しました。
もちろん、ここまでする必要はないかもしれませんが、人の上に立つ者としてはカルチャーのせいにしないで、きちんと対応をとるべきでしょう。というかこのような事態になった時点で『教育を徹底する』とかではなくまずはご自身の監督不行き届きを反省すべきだと思ってしまいます。そんなことだから、こういった声に耳を貸せないのか？と疑問に思ってしまいます。
実は、STAP細胞は存在しないと主張されている人が理研内部にいらっしゃるようです。ブログによるときちんと報告したにも関わらず政治的な力によりもみ消されたようです。もちろん私は専門家ではないので真偽を判断することはできませんが、理研にはこのブログの真偽に対してコメントしてほしいものです。
とかなり息巻いてコメントしましたが、まぁ歳をとると人は丸くなっていくもので、私の半径３メールの経験では、私自身が今となっては客先で居眠りしている人をみたとしても何とも思わなくなり、せいぜい飲み会のネタにするぐらいとなってしまったので、あまり人のことは言えないかもしれません。もっとも『居眠りできて天国です。』とか言われるとプロジェクトから追い出すかもしれません。
いずれにしても人の上に立つ人はきちんと人を見る目を養わないとダメということを思い知らされた事件です。
真のソフトウェアエンジニアに必要なモノ（SQLは銀の弾か？）
件の社長ですが、ブログで、まとめ記事を出しております。あれだけ口悪く私のことを煽っていたのにバツの悪い終わり方だと思いますが、まぁ、これ以上、『SQLはオブジェクト指向言語の数十倍の効率』の件を追求する必要もないのでその件は終わりにします。
ただ、私の方ですが、久しぶりに火がついたので気ままに書いてみます。もっとも粘着質といわれるのも嫌なので、件のブログ自体にはコメントしません。が別に書いていることが正しいとも思っていません。件のブログですが、コメント欄が消されていますので、疑問等ある人はこちらのコメント欄にでも書いて頂ければ『私に答えられること』でしたらコメントします。
素直さは如何に大切か、とか、騙されないようにする為に（適切な議論の方法）と記事を書いてきましたが、そもそも論として、ソフトウェア開発に関連した技術面で何か記事を書くのであれば、それは技術者を代表してという立場で発言することになるでしょう。ここでの技術者の代表とは、『ソフトウェア開発をリードし設計、開発、テスト、トラブルシュートを行い、単なる知識だけでなく頼れる技術を持った、顧客だけでなく共に働く人や競合他社からも一目置かれるような人』ということで話をします。お前はどうやねんとツッコミが来そうですが、私は僭越ながらその末席において頂いていると思っております。
というわけで、以下、真のソフトウェアエンジニアとって必要なモノについて語ってみましょう。
『銀の弾などない』ことを理解する
恐らくソフトウェアエンジニアだけでなく、顧客の情報システム部の方や、現代では企業経営者全ての人に教養としてお薦め本に『人月の神話』があります。私はざっと一読しまいたが、ソフトウェア開発の真実をみることができるでしょう。ちなみに訳本のせいか私にとっては少々読みにくい（というかくどい）です。その中にある、『銀の弾などない』という章で著者のフレデリック・ブルックス氏は『ソフトウェア開発においては○○を使えば生産性や信頼性、安全性が著しく向上したりするという特効薬は存在しない』という趣旨のことを主張しています。この主張は約25年前になされましたが、今でも充分に通用するでしょう。つまり、「○○を使えば生産性がX倍向上します。」ということを耳にするかと思いますが、『そんなものはない』というのが氏の主張で、私も自身の体験からこの主張は現在のところ正しいと思っています。
ひょっとしたら経験は浅いが技術力のある方の中には「そんなことはない、銀の弾はある！」と思うかもしれません。一経験者から言わせてもらうと恐らくそれは思い込みです。
ただ、この主張が将来に渡っても正しいかどうかは解りません。なぜかというとこの主張は現在のソフトウェア開発の弱点とそれが将来に渡って解消されないという予測を行っているだけだからです。人間という生き物は欲深いものでこの弱点を克服しようと多くの人が日々努力しています。私がADPを開発しているのもまぁそういう努力の1つです（と言っておきましょう）。
当然ですがフレデリック・ブルックス氏もその点はきちんとフォローされており、約25年前に、銀の弾の候補の一つとしてオブジェクト指向プログラミング（OOP)を挙げておられます。ただ、その約10年後に出された『「銀の弾などない」再発射』ではオブジェクト指向が本来使われるべき領域（業務ロジックにオブジェクト指向の適用）ではなく低レベルな部品レベル（リストクラスやGUI等）にとどまっていると指摘しています。
現在ですが残念ながら状況はあまり変わっていないでしょう。オブジェクト指向はだいぶ浸透してきたかと思いますが、現在ではソフトウェア開発期間に求められる時間が短くなってきています。つまり顧客はカジュアルにサービスを立ち上げたがります。そうなるとじっくりと開発するというわけではなくありものでちょちょっと作ることになり、OOPといっても『ライブラリを使う』ということはあっても業務ロジックを作ることはそう多くはないでしょう。また何よりOOPを使った失敗プロジェクトも多かったのも事実です。
そして、件の社長ですが、『少なくともRDBを使う業務アプリの開発において、データを操作する部分に関してはSQLは銀の弾になりうるのではないか』と主張しているのかと想像します。
行間を読む
ソフトウェアエンジニアは普段コンピュータばかりを相手にしているのでどうしても理屈っぽくなり、言葉を額面どおりに取る傾向にあります。がソフトウェアエンジニアたるものコンピュータばかりでなく人間も相手にしなければなりません。行間を読むことは人間同士のコミュニケーションで重要なことです。がもちろんですが相手に行間を読んでもらう前提で話をしてはいけません。コミュニケーション能力は技術者というより人間としての経験値が必要ですが、幸い今ではインターネットを使ったコミュニティが豊富にあります。行間を読む訓練は昔より遥かに簡単にできるでしょう。SQLは銀の弾になりえるか？
という訳で、まとめ記事ありました、件の社長が本当に言いたかったことを推測してみますと、『少なくともRDBを使う業務アプリの開発において、データを操作する部分に関してはSQLは銀の弾になりうるのではないか？ 銀の弾ではなかったとしてもオブジェクト指向プログラムより使える技術だろう』
ということが某社長が言いたかったのかと仮定します。
で『その根拠』について私の経験を元に考えてみましょう。ちなみに、『人月の神話』にはSQLは銀の弾の候補に上がっていませんでした（間違っていたらコメント欄にご指摘下さい）。
この点については社長自信、色々上げておられるのですが、私の経験上一番納得できるポイントは
・オブジェクト指向技術を使ったプロジェクトが失敗したときの被害
と
・SQLに頼ったプロジェクトが失敗したときの被害
とを比較した場合、どちらがより被害が大きくなるか？です。
件の社長が言いたいのは（というか過去の議論で私が理解できた社長の主張は）『OOPを使ったプロジェクトが破綻した場合の方がより被害が大きい。』ということでした。私の中では『どっちもどっち』と思う面もなくはないですが、確かに実際に聞く話は『OOPを使ったプロジェクトの破綻』が多いし深刻度が高いです。もっとも私の周り3メートルの範囲ですが。
この事実は、単純に『OOPが銀の弾候補』になり、それ以外にもオブジェクト指向がバズワードとして色々宣伝されたので、多くのチャレンジャーが集まり、壮大な実験の結果、失敗例が集まったということかと思われます。
その他、OOPが思ったほど実力がないということの例を挙げますと統合開発環境の存在があるでしょう。本当にOOPが銀の弾なら統合開発環境は要らないでしょう。皮肉な話ですが統合開発環境が高機能になればなるほどOOPがそれ程たいしたことではないという風に聞こえてしまいます。例えば、「統合開発環境のリファクタ機能を使えばそんなの簡単です。」という話を聞きますと、すごいのは統合開発環境であって言語ではないということでは？と疑問が出てきます。ちなみに「統合開発環境がないと開発できない」とか言われると『本末転倒やん』と嘆きたくなります。
さらに別の例ですが、私が関わったプロジェクトでC++を使ったものがあったのですが、バグ入りのものをリリースしたが、既に担当者がいなくなったので修正が出来ないということで私に助けを求めたものがありました。単純にOOPで作られたというだけでなく、マルチスレッドで動作していたのでバグの原因が不明で誰も手が付けられなかったということでした。OOPの思想の１つにカプセル化（隠蔽、ブラックボックス化）があります。確かにバグがないプログラムを再利用する場合はカプセル化は理想的です。しかし、そのカプセルの中にバグがある場合は否応なく内部を調べる必要があり、これにプラスして経済的な制約が加わると大変なことになることは想像できるでしょう（まぁ私は儲かるのですが・・・ちなみにこういうことでお困りの方がおられたら私ならなんとかできるかもしれません）。
ここまで言いますと『じゃなんでお前はC++を使っているんだ』とツッコまれそうですが、道具はあくまでも道具で、適切に使えば良いという話だけです。長所、短所を理解した上で使えばよいでしょう。ちなみに私が単独でプログラムを記述する場合はC++をメインで使いますが（もっとも最近はADPがメインですが）、誰かに引き継ぐ前提のプログラムの場合、関わるメンバを見て言語を選択します。そして、私の半径3メートル以内ではC++を使うことは残念ですがあまりなかったです。
一方でSQLに関してですが、さすがに長年の実績がある言語で、例えばパフォーマンス上で問題が発生した場合、様々な解決策（ノウハウ）があります。また私の半径3メール以内でも多くの人がSQLを使っています。SQLが出来ない人は少ないです。最近では、あるSQLが遅くて色々試行錯誤していましたら、一緒に働いている方から「何か知らんがこうすれば速くなった｣とアドバイスを受け実際に速くなったケースがあります。大人の事情で具体的な詳細は明かせませんが、そういうことは皆様の回りでも現実に多々あるでしょう。こういうことを言うと「実行プランをきちんと解析せいや」とかお叱りを受けますが当然そんなこともしております。
もちろん、SQLをどうこねくり回しても解決できないこともありますが、その場合でも案外ベタな解決方法（私のブログで紹介しているようにJOIN崩しとか、その他非正規化とか）があり、この辺りに関しては知る人ぞ知るという感じで、私の回りでは結構あるあるネタになっています。
このような言語自体の性質および実績から来る信頼性は追い込まれたエンジニアにとってはありがたい存在で、「SQLは良い」という意見については反対する気はないです。ただ、「SQLが効率的」といわれると普段から遅いSQLを速くするという作業も行っている身としては？と思うわけです。
またMDXという言語を知ってからは、JOINしながら集計することに関してはMDX（OLAP）の方がSQL（RDB）より強力という認識でおります。道具はやっぱり適材適所で過信はいけません。
業務アプリ限定で言いますと、SQLとOO言語を混ぜて使う必要があるために、SQLとOO言語のパラダイムの差を吸収する必要があるでしょう。いわゆるインピーダンスのミスマッチで、その解消策の1つとして『OO言語で統一する』という試みが昔から行われています。古くはオブジェクト指向DBなどで、今ではO/Rマッパーなんかですね。ここで某社長の思いの行間を読むと「OO言語に統一できるという考えがファンタジーだ！」ということで、その根拠にN+1問題をあげておられます。ちなみに「SQLはオブジェクト指向言語の数十倍の効率」自体は間違った主張ですが、その行間を言い直すとN+1問題ということになります。N+1問題はググれば出てきますし、私がSQLの実行パフォーマンスについて 2010で指摘した実験2は原理的にN+1問題と同じになります。
そして社長は「オブジェクト指向側に寄せるより混ぜて使うことを前提に上手く開発できるようなスタイルを確立すべし」ということが言いたいのでしょう。まぁ適材適所ですね。
ちなみに『OO言語とSQL（リレーショナルモデル）とのパラダイムの差を吸収することは難しいが、述語理論とSQL(リレーショナルモデル）との差はあまりないのでSQLを呼び出す言語を述語理論に基づいた言語にすれば上手くいくのでは』というのが私の仮説になります。
もう1つうんちく次いでに語りますと、「SQL系の言語で統一する」という試みもありました。4GLとか言っていたものです。これは早々に消えたかと思います。4GLが宣伝されていたとき、私はあまり関わっていませんでしたが「SQLでGUI」と言われても『どう組むんや!』ということは明白で、まぁやっぱり道具は適材適所なのでしょう。
「オブジェクト指向プログラミングが銀の弾かどうか？」というのはまだ結論が出ていないかと思いますが、最近では関数型の言語が一部ではクローズアップされています。ちなみにADPがベースにしているPrologという言語は述語理論を基礎においています。私は述語理論を押しているわけです。先のことはわかりませんが、オブジェクト指向プログラミングが昔の構造化プログラムと同じ道を行き、将来別のパラダイムがスタンダードになっているかもしれません。もちろんRDBが駆逐されているという世界もあるかもしれません。つまらない意見ですが、まぁ先のことはわかりません。
そして「SQLは銀の弾か？」と言われると『データを扱う上では候補ぐらいにはあげてもよいけどSQLはそもそもドメイン固有言語ではなかったですか？』。というのが私の意見になります。
以上、行間を読んで書いてみましたが、如何でしたでしょうか？ がんばりましたがさすがにSQLを持ち上げるのは厳しいです。つまらない結果ですがまぁ現実はこんなもんです。
最後に1つだけコメントしますと、このように書けば炎上はしませんが、多くの共感は得られるのではと思うのですが、まとめ記事では残念なことに主張すること自体を取り下げたようです。
いったい、彼は何が言いたかったのでしょうか？