ソフトウェア業界の規制[終了]

数年ごとに、ソフトウェア業界に対してより厳しい規制を提案する人がいます。

このIEEEの記事は、最近この問題について注目を集めています。

物理的または金銭的なリスクに公衆をさらすシステムのプログラムを作成するソフトウェアエンジニアが、自分の能力をテストすることを知っていれば、コードの欠陥と失敗を減らし、掘り下げて命を救うかもしれません。

私はこれの価値とメリットについて懐疑的です。私の考えでは、それを提案した人たちが土地をつかんでいるように見えます。

私にとってそれを締めくくる引用は次のとおりです。

試験は、主題の習熟度ではなく、基本的な知識をテストします

なぜなら、大きな失敗（たとえばTHERAC-25）は複雑で微妙な問題であり、「基本的な知識」ではそれを防ぐのに十分ではないからです。

現地の問題を無視する（一部の管轄区域におけるタイトルエンジニアの既存の保護など）：

目的は高貴です-quacks / charlatans ¹を避けて、ソフトウェアを購入する人にその区別をより明確にします。ソフトウェア業界のより厳しい規制は、当初の目標を達成することができますか？

¹まさに、医療専門職の規制が意図されていたとおりです。

ソフトウェアエンジニアが医療専門家や会計士と同じ分類に穴を開けられるという見解は、彼らが解決しようとしている「問題」に対する無知な見解です。これについて意見を述べる前に、この法案を提案している規制機関の副議長であるソーントン氏の議論のいくつかを整理しましょう。

「医師、会計士、看護師などの実務家と同じようにライセンスされているので、ソフトウェアエンジニアも同様です」とソーントンは言います。「一般の人々は、ソフトウェアを作成する請負業者を選ぶ際に、何らかの資格情報に依存できる必要があります。」

-Mitch Thornton、IEEE免許および登録の副議長

これは表面上は非常に合理的に聞こえます。結局のところ、「規制の成功」と見なされる可能性のある他の業界があります。規制の順守とは、イエローページで医師を調べると、認定大学で徹底的な教育を受け、多くの試験に合格し、レジデンシーを修了したことを合理的に確信できることを意味します。ここに、いくつかの「成功裏に規制された」産業があります（専門職の観点から）。

• 弁護士
• 医師
• 会計士
• 原子力エンジニア
• 理髪師（冗談ではない）

結局のところ、膵臓から腫瘍を除去したり、町のすぐ外にある原子力発電所の遠心分離機で作業したりする人はいません。ソフトウェアエンジニアに同様の制限が存在してはならないのはなぜですか？

「公衆衛生または安全、セキュリティ、財産、または経済を危険にさらす可能性がある」プログラムをテストする必要があるのは、

これはあいまいな声明であり、自由な解釈と適用に対して開かれています。Apple Inc.やFacebookはアメリカ経済の不可欠な部分であるという議論をすることができます-私は彼らの能力を失ってサイトを倒すとアメリカを傷つけるかもしれないので、今それらのためにコードを書くために政府から特別なライセンスが必要ですか？経済？私の最後の仕事で、間違ったcronジョブで穀物エレベーターを誤ってシャットダウンしました-食料供給を危険にさらしている可能性があります。

私はこの提案の実際の意図を避けていることに気づきました。その背後にある考え方は、新しいJettaでアンチロックブレーキシステム用のコードを書いている人が、アンチロックブレーキシステム用のコードを書く能力と適切なライセンスを持っていることを保証することです。あなたのジェッタに。

問題は次のとおりです。この時代のソフトウェアエンジニアリングにはすべてが含まれており、すべての分野をテストすることはできないでしょう。ビジネスルールは非常に具体的であり、規律ごとにあまりにも多様です。JettaでABSシステム用のコードを記述する仮想エンジニアは、Elantra上のABSシステム用にまったく異なる何かを書いているかもしれません。彼は再認定を受ける必要がありますか？

そして、これらの派生的な分野すべてをテストするとどうなりますか？eコマースWebサイトで作業するすべてのプログラマーがeコマース対応プログラマーとして認定されたとします。そう？これは突然、これらのプログラマーや企業が実際にすることを意味していません、必要な検証をし、PCIコンプライアンスに構築しますか？たとえそうだとしても、グリッチはまだ起こります。

IEEE Licensure and Registration Committeeの副議長Mitch Thorntonによれば、この試験は、主題の習熟度ではなく、基礎知識についてテストされます。

これがキッカーです。基本的な知識の不足が問題になることはありません。チャックが制御構造の概念に苦労していたため、私のアンチロックブレーキは動作を停止しませんでした。テールライトの電気的ショートのためにABSがオフになり、電源が適切に転送されなかったグリッチがあるため、それらは失敗しました。か何か。

私が書いたインスリンポンプソフトウェアは、基本的なスキルが不足しているため動作を停止しませんでした。私のヨーロッパのチームメイトがメートル法を使用していたときにインスリンのディスペンスを測定する方法にバグがあったため、停止しました。

これは開発中に説明できるものですが、認定ではテストできません。

この「認証」が有効になった場合に起こることは次のとおりです。インシデントの数はまったく同じままです。どうして？それは、ABSまたはインスリンポンプが故障するという実際の問題を解消するために何もしないからです。

医療規制のおかげで誰も死なず、金融規制のせいで誰も傷つけられず、住宅規制のせいで誰も家を差し止められず、理髪師規制のせいで誰も髪の毛を切らされず、飛行機がcrash落することはありません航空機の規制のおかげ。

明らかに、規制の存在は、欠陥や失敗がないことを意味するものではありません。逆に、欠陥や障害の存在は、規制がそれらの欠陥や障害を防ぐことを意味するものではありません。ソフトウェアエンジニアは、それぞれのセーフティクリティカルな業界のメンバーとして既に高度に規制されており、それらの業界以外ではほとんど必要ありません。

優秀な職人と平凡な職人の違いは、客観的な尺度でテストすることはできないと、歴史は示しています。基本的な知識は、その基本的な知識をどのように応用するかについて、実際に客観的に教えたり測定したりすることのできない優れたプログラマー、知恵、経験を生むものではありません。

また、これらのテストは通常​​、いくつかの話題の言葉と具体的な手順であり、実質的なものを最初から測定することはできません。

ソフトウェア業界が何らかのギルドを開発したいなら、それはこの問題に取り組むためのはるかに良い方法でしょう。ただし、集中化には卓越性を破壊する力しかありません。

さらに、この手段が防止しようとしている問題は、おそらくテストによってとらえられないでしょう。とにかく、私も@ThomasOwensがこれに答えるのを見てみたいです。

少なくともアメリカのイデオロギーからの政府の役割は、ソフトウェア会社が欠陥のあるまたは安全でないソフトウェアによって引き起こされた財産の損害に対して責任を負うことです。これにより、企業は独自の基準を実施し、問題に対して個人的な責任を負うようになります。これは常により良い解決策であり、中央政府がその境界を越えて踏み込むことは含まれていません。

更新

昨晩、ビールか10杯でこれについてもう少し考えていました。

医療分野の規制は、1つを除くすべてのパラダイムを根絶することでした。彼らの目標がホメオパシーと自然療法の医師を排除することであった場合、彼らは親切に「鳴き声」と呼ばれ、そのような規制は成功しました。しかし、そのようなことは、法律を書いている人々以外の誰にとっても有益であることに同意しません。これが何をしたかを考えてください。医療費を持続不可能なレベルに引き上げ、MDの賠償責任レベルを大幅に引き上げ、消費者の選択力と自己決定権を市場からすべて排除しました。医学界にはアイデアの市場がなくなっており、現在、新しい治療法や医学に対する考え方は抑制されています。さらに、フィールドへの参入障壁は非常に高く、その結果、優れたMDが不足しています。s。さらに、規制機関には医師の供給を管理する権限があるため、医師に支払われる価格を管理することができます。

医療規制から得た利益は確かにありますが、費用はまったく高すぎます。

このような規制が可決されると、ソフトウェアエンジニアにも同じことが起こります。私は今それを見ることができます、規制機関はオブジェクト指向プログラミングが設計の唯一の標準であり、機能的および手続き的プログラマーが練習することを許可されないことを支配します。それから、彼らは安全ではないので自分の記憶を管理することは許されないと私たちに告げ始めるでしょう。その後、JAVAとC＃をすべての喉に詰め込み、OracleとMicrosoftがより太くて幸せになるまで使用する必要があることを伝えます。イノベーションは抑制され、創造性は禁止されます。マイクロソフトとグーグルが法律を制定するので、市場のルールは彼ら自身の収益性と社会の幸福に向けられます。

また、コンピューターが趣味とアカデミックの取り組みとして始まったことを皆さんに思い出させてください。80年代および90年代初期のUnix戦争以外に、無料のオペレーティングシステム、無料のコンパイラ、無料のプログラムなどがありました。これはすぐに終わります。リチャード・ストールマン、ライナス・トーバルズ、デニス・リッチーが私たちに残した世界は、徐々に存在から消えていきます。

要約すると、「1時間あたり25ドルでワードプレスCMSサイトを設計します」または「500ドルでiPhoneアプリを購入する」という人たちと競争することにうんざりしていませんか？そうではない、なぜですか？私は自分がしていることをとても上手くやっていて、私が望む顧客は優秀さのために喜んでお金を払っているからです。独立して、または私の職場でプロジェクトに取り組むとき、私は自分の頭と評判に私のf *＆^ upsの危険を冒します。それは私がどこへ行っても私に続きます。また、ほとんどの人は自分が支払うものを手に入れることを知っています。彼らが彼らの芝生の人に払う価格だけを私に支払うことをいとわない顧客は、とにかく対処する悪夢になるでしょう。政府がサービスプロバイダーに損害の補償を強制するために法的構造を修正した場合、その分野でまだ雇用されている悪いプログラマーはほとんどいないでしょう。

ところで、私たちにはまだ悪い医者がいます。唯一の違いは、彼らを市場から排除する力が非常​​に少ないことです。自分の行動に責任を負わなければならない場合、彼らは顧客に無能な大混乱をもたらす別の機会を得る前に廃業するでしょう。

シリコンバレーニュース-2015年6月31日

ホラー：認定されていないプログラマーがプログラムを中止しました

「私は二度と走ることはできません」、犠牲者を出力します。警察は調査中です。

犯罪者：H. Acker Jr.博士のライセンスは、ポインターの誤った使用のために取り消され、システムファイルから読み取ろうとしました。

提唱者は、最高裁判所への控訴が予定されていると言います。

お知らせ：1975年に認定されたCobolプログラマは、2025年までに再認定する必要があります

IEEEは、認証が変更されていないことを確認しました。

広告：Magic Knowledge Stuffers、Incで保証された認定

21日間でプログラミングを教えてください。

あらゆる職業に規制を適用するには、いくつかの異なる方法があります-明確に定義された知識体系、倫理規範、教育プログラムの認定、認定とライセンス、および専門能力開発とその他の側面をサポートする専門団体職業。ソフトウェアエンジニアリングには、職業のほとんどの特徴があります。

私は、ソフトウェアエンジニアリング知識体系（SWEBOK）およびソフトウェアエンジニアリングの倫理および職業実践規範から始めることを考えるのが好きです。これらの一般的な受け入れはまだかなり限られていますが、ソフトウェアエンジニアとして自分自身を識別する誰かが専門的な能力でどのように行動するべきかを知っている必要があるものの種類を識別するための良い基盤として役立つと思います。これは、これらが厳しい規則であることを意味するのではなく、むしろこれらのドキュメントは、プロのソフトウェアエンジニアが、彼らが行うことを求められる可能性のある作業に通常関連することに関してガイドします。SWEBOKは、関連性を維持するために随時改訂されます。

次の特徴は、教育プログラムの認定です。米国では、ソフトウェアエンジニアリングプログラムの認定はABETによって処理されます。また、コンピューターサイエンス、情報技術、コンピューターエンジニアリング、その他のコンピューティング関連の専門職も認定しています。ABET は、認定プログラムの要件を Webサイトに掲載しています。ソフトウェアエンジニアリングはエンジニアリングプログラムと見なされます。認定の目的は、少なくとも教室で教えられる主題に関して、異なる工学プログラムの卒業生の間で一貫性を確保することです。教育の質については何も述べていません。

卒業後、認定とライセンスを使用して、教室で（場合によっては仕事で）学んだ知識を、標準的な知識体系と比較評価します。認定校には、教えるべき教材が定義されていますが、この教材がどれだけうまく教えられているか、プログラムの完了時に生徒がどれだけ学ぶかについての尺度はありません。認定とライセンスはそれを行う方法を提供します-誰もが同じ試験を受け、職業が根ざしているさまざまな知識の知識を証明します。ソフトウェアエンジニアリングでは、IEEEはSWEBOK- 認定ソフトウェア開発に根ざした認定を提供しますシニアおよび最近の卒業生のためのアソシエイトおよび認定ソフトウェア開発プロフェッショナル業界経験のある人向け。これらが価値を高めるには、ソフトウェアエンジニアリングとは何かの適切な定義としてSWEBOKを受け入れる必要があります。

最後に、専門家団体は、専門家向けのガイド文書を維持し、知識やアイデアの交換のための会議や出版を促進し、学界と産業界のギャップを埋めるなどしています。2つの主要な社会はIEEE Computer SocietyとACMですが、世界中に他の社会があります。これらはすべてを素敵な小さなバンドルにまとめ、適切な人々に情報を提供するのに役立ちます。

ここから、質問する他の質問があります。ソフトウェアの開発はエンジニアリングの分野ですか？認定またはライセンスはソフトウェアエンジニアに価値をもたらしますか？認定は便利ですか？

私はすべてのソフトウェア開発がエンジニアリング分野の厳格さを必要とするとは思いません。それは、ソフトウェアの構築の科学と工学に関する経験的で科学的な研究がすべての人を助けるわけではない、と言っているわけではありません。ただし、最新のビデオゲームの開発、ペースメーカー用の組み込みソフトウェアの開発、または次の宇宙船の構築には大きな違いがあります。強調はすべてで異なります-3つのうち2つは熟練したエンジニアの注目に値します。もう1人はエンジニアリングの実践から学ぶことができますが、プロジェクトを正常に完了するためにそれらに依存する必要はありません。

認証とライセンスには、認められた知識が必要です。SWEBOKは強固な基盤を提供する優れたドキュメントですが、広く受け入れられていません。実践者によって受け入れられる具体的な何かに基づいてアカデミックプログラムと認定/ライセンス試験を行うことができるのでなければ、実際には意味がありません。SWEBOKまたは代替ドキュメントが広く受け入れられるようになった場合（少なくともエンジニアリングの厳密さが必要な分野で）、認定またはライセンス試験を使用して、必要な知識の理解を評価できます。

ただし、認定には重大な問題が1つあります。これは本のテストです。一部の人々は、読書、学習、暗記、テストを受けるのが得意です。しかし、それは彼らが優秀なエンジニアであることを意味しません。人々は常に亀裂をすり抜けます。認定またはライセンスは単一のステップにすぎません。優秀な実務家を育てるには、他の経験豊富なエンジニアによる職業訓練と指導が必須です。さらに、人々が重要な環境で練習するのを防ぐ能力は、社会や企業に対するリスクを軽減するのにも役立ちます。

これについてかなり詳細に議論された優れた本は、Steve McConnellのプロフェッショナルソフトウェア開発：スケジュールの短縮、製品の品質の向上、プロジェクトの成功、キャリアの向上です。

政府の規制が可決されると、米国のソフトウェア業界は大幅に縮小します。これらの規制への対応に関連するコストは、新興企業や中小企業が負担できるよりも高くなるためです。

法律の学位または医学博士に関連する希少性とコストは、当業界で多かれ少なかれ目に見えるようになります。すべてのジョーが次のFacebookを作成できる可能性があるという代替案の場合は良くありません。

人々は間違いを犯しますが、いかなる規制も災害の発生を妨げるものではありません。NASAについて考えてみましょう。NASAは、人間に知られているソフトウェア開発に関して最も厳しい要件を持っています。彼らにはまだソフトウェアのバグがありますか？（はい、はい、そして何度も、はい！）

市場はこれらの問題を規制よりもはるかにうまく整理しています。問題を引き起こすソフトウェアを作成する企業は、負傷した人々によって責任を問われます。私たちの残りの人は、彼らの過ちに対して支払う必要はありません。

1999年に、ACM は、IEEE SWEBOKの作業から大幅に撤退したときに、ライセンスに関する声明を発表しました。一般公開されているSWEBOKドキュメントとACMステートメントを確認した後、ACMの意見を支持します。

この記事を一目見ながら、4〜6年の経験を持つ人が試験を受ける必要があり、基本的な知識をテストします。それはばかげていることを超えて、ドアの外で笑われるべきです。

デバイスのソフトウェアコンポーネントは、実装の詳細です。たとえば、制御システム業界では、すべての安全装置が配線されていたため、人々はソフトウェアを信頼していませんでした。ただし、現在、セーフティリレーやセーフティPLCなどのソフトウェアベースの安全装置が登場しています。これらは、安全装置に関する業界の規制（安全カテゴリに応じて）を満たす必要があるため、許容されます。そのため、場合によっては、デバイスに冗長プロセッサ、および2つの異なるチームによって記述された冗長コードなどが必要になります。

一般に販売および消費される場合、安全ガイドラインを満たす必要があるのは製品です。製品にはソフトウェアが含まれているため、これらのルールは変更されません。製品がすべての規制基準を満たしていることを確認するのはエンジニアの仕事であり、製品にソフトウェアが含まれている場合は、ソフトウェアをレビューしてその分野で有能でなければなりません。そうでない場合、設計者が設計を承認し、それが欠陥であることが判明した場合、彼ら（またはその会社）は責任を負います。

一部の製品がより厳しい要件を満たす必要があるという理由だけで、すべてのプログラマを規制する必要はありません。そのような製品にソフトウェアが含まれる場合は、ソフトウェアコンポーネントが要件を満たしていることを確実に判断できる、十分に開発されたエンジニアリング分野が必要です。どちらかといえば、それはIEEEが意味するものです。ソフトウェア工学の比較的若い分野は、他の工学分野の信頼性と信頼のレベルまで開発される必要があります。

それは本当に「プログラミング」とは関係なく、「エンジニアリング」と関係があります。

これは、もちろん、開発者とエンジニアの違いという論争の多い問題に私たちを連れ戻します。これらは通常、定期的に重複する2つの異なる役割です。開発者の部分は、ソフトウェアを作成することを意味します。この役割のエンジニアリングの部分は、デザインにスタンプを押せば、公共の安全に責任を負うことを意味します。あなたは他の人なしで一人にな​​ることができます。

ソフトウェアはすでに航空機業界で厳しく規制されています。DO-178Bを参照してください。

私は、業界の他のサブセットには彼らの規範があると確信しています。

「ソフトウェア」は、最近非常に多くを網羅しています。あらゆる包括的な規制が義務付けられているのはばかげていると思います。

ソフトウェア業界の規制は、品質保証プロセスの規制を通じて行うのが最適です。

これはすでに行われています-大規模なソフトウェア会社には、多数のテスター、QAマネージャー、自動テストスイート、コードレビュープロセス、テストプロセスなどがあります。他の会社のソフトウェア品質監査を実行することが全体的な目的である会社があります。標準化組織には、QAおよびQA監査のガイドラインがあります。

会社の内部では、ソフトウェアエンジニアが仕事の品質に責任を負っています。ただし、それらのチェックとバランスは、会社の品質プロセスにあります。

これは、「ソフトウェア関連の問題」を解決するためのほとんどの最新の試みと同じです。立法化しようとする人々は、問題の根本的な経過についてほとんど知識を持っていません。安全性が重要なソフトウェアを開発するときに規定のプロセス（および当然の意図）に従う場合、航空機、医療機器の原子力発電所では、単一のバグだけでは故障を引き起こすのに十分ではありません。アルゴリズム全体が誤って実装される可能性がありますが、いずれも損傷を受けません。

FDAとFTAはどちらもリスク分析を必要とし、それに基づいて緩和戦略を策定します。後者は通常、スイスチーズ戦略であり、緩和策に欠陥があることを受け入れるため、同じリスクに対する複数の緩和策が適用されます（1つの緩和策は複数のリスクにも適用される場合があります）。 1つは、おそらく2つのスライスを組み合わせますが、十分なスライスを一緒に配置することは不可能です。軽減策が完全に実装されていても、100％安全な機器にはなりません。リスク分析が正しくない場合、誰も考えていないリスクがあります（Y2K）。

エンジニアは必要なすべてをテストできますが、主題についてもテストでき、非常に高いレベルが必要ですが、それは非常に重要です。ほとんどの安全上の重大なエラーは統合エラーです。それらは1つのマンコードのエラーではありませんが、2つのソフトウェアシステムのソフトウェアとハ​​ードウェア間の不整合、またはアルファ粒子がプログラムカウンターを適切な場所から打ち出したために発生します。

私は、経験豊富で有能な開発者と一緒にいくつかの安全性重視のシステムに携わっており、彼らはその分野で賢明なテストに合格します。安全に重大なエラーがないプロジェクトに行ったことはありません。（幸いなことに、システムが誰かを傷つけるようなことは一度もありませんでした）

長い歴史のある慣習や伝統にもかかわらず、ほとんどすべての職業、医学の職業にも存在するため、charlatansとquacksを完全に排除することはできません。

しかし、この声明は土地をつかむものであり、ITがソフトウェア開発の自由な制御と規制を悪魔のように陰謀的に企てているのかどうかはわかりません。実際にIEEEについて話している場合は、確かに規制の側面がありますが、IEEE規格への準拠は多かれ少なかれ自由自在であり、銃口ではありません。彼らは、私たち全員が同じ言語を話し、全体の効率を高めるように、普遍的な業界標準を開発しようとしています。

さらに、彼らがレイアウトする標準は、一般的な慣行を合法化し、ソフトウェア開発の土台を築いて、最終的に機械工学や化学工学とは異なり、より統制のとれた工学分野になるのに役立ちます。ソフトウェアはその目標に近づきつつありますが、エンジニアリング分野として完全に受け入れられることは決してないでしょう。

核となる問題は、ソフトウェア開発者が、きれいなデスクトップウィジェットの作成から、ミスルガイダンスシステムの実装まで、何でもできるということです。一方では、エラーの重大度と結果が他方よりもはるかに高いため、合理的、安全、効率的にアプローチするために厳密に規制されたエンジニアリングの規律が必要です。これは、誤って設計されたブリッジのエラーの重大度に似ており、結果としてブリッジが崩壊します。橋の設計者は、品質を確保するために私の工学基準を遵守する必要があります。

私はそれをより厳格な規制と呼ぶのではなく、その代わりに参入の障壁となるでしょう。その点でメリットがあると思います。品質を向上させるためには、非常に議論の余地があります。

現在、John / Jane Doeは誰でもプログラムを作成できます。入場の障壁はありません。スクリプティングとWebテクノロジーに関する本をいくつか手に入れて、ハッキングを開始するか、さらに悪いことには、「実行」する方法についてGooglingを開始してください。

私たちが集合体全体として、参入障壁を高め、業界をより高い水準に保ち、ハッカー/職人からエンジニアに進化する時期を決めるかもしれないとき、その種の規制はすべて順調です。

今日、プログラミングを行う資格のない個人が多すぎます。重要なシステムで動作するかどうかにかかわらず、彼らはまだコードを生成し、ビッグマッドオブマッドを生成しています。

その点で、自己規制またはより適切に参入障壁を作成することは良いことです。私たちが言っているので、ちょっと通りから出て、自分をソフトウェアエンジニアと呼ぶことはできません。実際には、スキルのレベルを下げる必要があります。

スキルのデモンストレーションは、単にテストを受けるか、「名誉のバッジ」を取得するだけではありません。テストは単なる検証です。実際の検証は、学校、インターンシップ、見習い、先輩の下でのメンタリング、練習、すべてがその一部です。

IEEEが何を達成しようとしているのかはわかりますが、現時点では実りのない演習です。業界は急速に変化しており、製品をドアから押し出そうとする需要が多すぎる、「ハッカー」マインドセットなどがあります。規制は、もしあったとしても、内部から行われなければなりません。

私はこの記事を読んでいませんが、ソフトウェア業界の規制が人類に利益をもたらすことができるかどうかについての質問であれば、状況に依存すると思います。

1. 業界全体では、さまざまな分野が含まれており、その一部は生命に関わるもの（医療機器での放射線量の制御など）とそうでないもの（「Which Muppet Are You？」Facebookアプリ）があります。利害関係が低いアプリケーションの規制に関する議論は見当たりません。

2. 法的規制から始めるべきではありません。むしろ、開発者向けの認定プログラムから始める必要があります。法的規制の問題があるのは、認証プログラムがある程度の利益を生み出す場合のみです。

3. たとえ認証プログラムが測定可能な結果を​​生み出したとしても、業界は厳密にビジネス上の理由からこの認証を要求することで標準化する可能性が高く、法的規制は必要ありません。（これが、MCSEのような代表団が存在する理由です-企業は、MCSEが訓練されるドメインのためにMCSEを雇うことを好みます。）

4. つまり、ビジネスに害を及ぼす意味のあるドメインはまだ残っています（多くの場合、これらは負の外部性であり、一部の機関の市場支配力の結果である場合があります）。たとえば、ある地域には1つの地元の病院がある場合があります。この場合、バックエンドソフトウェアの品質は、患者が受けるケアのレベルに大きな違いをもたらす可能性がありますが、患者が選択する病院にそれほど違いはありません。その場合、病院は必ずしも高品質の開発者に投資するための多くのビジネスケースを持っているわけではありません。この場合、病院が雇うことを許可されている開発者を規制するための公衆衛生のケースがあるかもしれません。

私見では。

私はこれに答えなければなりません...

@JonathanHensonの発言と@gnatのエントリから始めます。私が言うことは大丈夫です。お金を持っている人は認証されたものにお金を払うことができます。 ）、それが実践されれば、反逆者がまだいるでしょう。従来の（それほど伝統的ではない）配信方法が閉じられたとしても、関心のあるユーザーにソフトウェアを配信する方法を見つけるでしょう。別のHTTPプロトコルまたは代替のネットワークスタック全体を開発することを意味する場合でも、接続を検出できないようにすることにのみ焦点を当てています（これを行うことができる人については、最後の段落を参照してください）。

また、世界はますます貧しくなりつつあるため、何かにお金を払うという考えは危険にさらされています。そのため、物を買うためのお金がどんどん少なくなり、FOSSソフトウェアのみを使用する国もあります。認定（ブラジルとインドが思い浮かびますが、確かに他のものがあります）、そしてそれらの国のいくつかは大きく、本当に大きくなっています。そして、彼らはスキルが不明な未知のプログラマーによって作られた認定されていないソフトウェアを使用します。

また、ある種の認証があったとしても、認証は倫理ではなく知識のみを認証します。一部の医師は人から無許可の方法で除去された臓器を使用すると考えているため、認証されたプログラマもいます。倫理を持たず、意図的または非意図的にずさんなコードを記述します。ほとんどのFOSSプロジェクトでは、ほとんどの潜在的に未熟なプログラマーも、他の人からのコードを確認し、ペアプログラミングを少しだけ小さくする方法でエラーを見つけようとします。

最後に、セキュリティについてより多くのことを知っており、特定の政府部門の最も専門的なプログラマーにのみ一致する方法でセキュリティソフトウェアを開発するハッキンググループ（ブラックハットハッカーグループではなく、ホワイトハットグループまたはグレーハットグループ）についてあなたは何と言いますか？