ソフトウェア業界の規制
数年ごとに、誰かがソフトウェア業界に対してより厳しい規制を提案しています。
この IEEE記事 は最近この話題に注目されています。
物理的または財政的リスクに公衆をさらすシステムのプログラムを作成するソフトウェアエンジニアが彼らがその能力についてテストされることを知っていれば、考えは進み、コードの欠陥と失敗を減らし、そしておそらく掘り出し物でいくつかの命を救うでしょう。
これの価値とメリットに懐疑的です。私の考えでは、それを提案した人々が土地を奪っているように見えます。
私にとってそれを折り曲げる引用は次のとおりです。
試験では、主題の習得ではなく、基本的な知識をテストします
大きな障害（例： THERAC-25 ）は複雑に見えるため、「基本的な知識」では防止するのに十分ではないような微妙な問題。
ローカルの問題（一部の法域でのタイトルエンジニアの既存の保護など）を無視：
目的は高貴です-クワック/シャーラタンを避けてください1 ソフトウェアを購入する人には、その区別がより明確になります。 ソフトウェア業界のより厳格な規制は、本来の目標を達成できますか？
1 まさに医療専門職の規制が意図されていたように。
ソフトウェアエンジニアが医療専門家や会計士と同じ分類に分類される可能性があるという見方は、彼らが解決しようとしている「問題」についての無知な見方です。これについて私の意見を述べる前に、この法律を提案する規制機関の副議長であるThornton氏の議論のいくつかを分解してみましょう。
「医師、会計士、看護師などの専門家がライセンスを受けているのと同じように、ソフトウェアエンジニアもライセンスを受けている必要があります」とThornton氏は言います。 「公衆は、ソフトウェアを書くために請負業者を選択するときに、何らかの資格情報に依存できる必要があります。」
-IEEE Licensure and Registrationの副議長であるMitch Thornton氏
これは表面上は非常に合理的に聞こえます。結局のところ、「正常に規制されている」と見なされる可能性のある他の業界があります。正常に規制されているということは、イエローページで医師を調べれば、認定された大学で完全な教育を受け、多数の試験に合格し、居住を完了したことを合理的に確信できることを意味します。 （規制に合格した）いくつかの産業を以下に示します（専門要員に関して）。
- 弁護士
- 医師
- 会計士
- 原子力エンジニア
- 理髪師（ 冗談ではない ）
結局のところ、その腫瘍を膵臓から切除したり、町のすぐ外にあるその原子力発電所の遠心分離機で作業したりしたくないだけです。ソフトウェアエンジニアに同様の制限が存在しないのはなぜですか？
プログラムが「公衆の健康や安全、セキュリティ、財産、経済を危険にさらす可能性がある」という人たちだけをテストする必要があります」
これは曖昧な発言であり、自由な解釈と適用を受け入れるものです。私はApple Inc.またはFacebookがアメリカ経済の不可欠な部分である-今私がそれらのためにコードを書くために政府からの特別なライセンスが必要ですか？私の能力不足のサイトはアメリカの経済を損なう可能性がありますか？私の最後の仕事で、誤ったcronジョブで穀物エレベーターを誤ってシャットダウンしました-おそらく食料供給を危険にさらしています。
私はこの提案の実際の意図を避けていることに気づきました。その背後にある考え方は、新しいJettaでアンチロックブレーキシステムのコードを書いている人が、アンチロックブレーキシステムのコードを書く能力と適切なライセンスを持っていることを確認することです。あなたのジェッタに。
ここに問題があります。この時代のソフトウェアエンジニアリングはすべてを網羅しており、すべての分野についてテストすることはできません。ビジネスルールは具体的すぎ、分野ごとに多すぎます。 JettaでABSシステム用のコードを書く仮想エンジニアは、Elantra上のABSシステム用にまったく異なる何かを書いているかもしれません。彼は再認定を受ける必要がありますか？
そして、これらすべての派生的な分野をテストするとどうなるでしょうか。少しの間、eコマースWebサイトで作業するすべてのプログラマーがeコマース対応のプログラマーとして認定されるとします。そう？これは突然、これらのプログラマーや企業が実際に必要な検証を行い実行し、PCIコンプライアンスを構築することを意味しますか？彼らがそうしたとしても-グリッチはまだ起こります。
IEEE Licensure and Registration Committeeの副議長であるMitch Thornton氏によると、試験は主題を習得するのではなく、基本的な知識をテストします。
こちらがキッカーです。 基本的な知識の欠如が問題になることは決してありません。チャックが制御構造の概念に苦労していたため、アンチロックブレーキが機能しなくなりました。テールライトの電気的短絡が原因でABSがオフになり、電力が適切に再ルーティングされなかったため、グリッチが発生したために失敗しました。か何か。
私が作成したインスリンポンプソフトウェアは、基本的なスキルがないため、動作を停止しませんでした。私のヨーロッパのチームメイトがメートル法を使用したときにインスリンの投与量を測定する方法にバグがあり、使用しなかったため、停止しました。
これは開発で説明できるものですが、認定でテストすることはできません。
この「認証」が有効になると、次のようになります。インシデントの数はまったく同じままです。なぜですか？それは、ABSまたはインスリンポンプの故障の実際の問題を排除するために何もしないからです。
医療規制のおかげで誰も死亡せず、金融規制のおかげで詐欺によって傷つけられた人も、住宅規制のおかげで家を差し押さえられなかった人も、理髪店の規制のおかげでひどい散髪になった人も、飛行機が墜落した人もいません。航空機規制のおかげで。
明らかに、規制の存在は欠陥や失敗がないことを意味するものではありません。逆に、欠陥や故障の存在は、規制がそれらの欠陥や故障を防ぐことを意味するものではありません。ソフトウェアエンジニアは、それぞれの安全性が重要な業界のメンバーとして既に厳しく規制されており、これらの業界以外ではほとんど必要がありません。
歴史は、私が信じているように、優れた職人と平凡な職人との違いは、いかなる形の客観的尺度でもテストできないことを示しています。基本的な知識は、その基本的な知識がどのように適用されるかについて、優れたプログラマー、知恵、経験（実際には客観的に教えたり測定したりすることはできない）にはなりません。
また、これらのテストは通常、いくつかの流行語と具体的な手順になってしまい、最初から実質的なものを測定できません。
ソフトウェア業界が何らかのギルドを開発したいと思ったなら、それは問題に取り組むためのはるかに良い方法でしょう。ただし、一元化には卓越性を破壊する力しかありません。
さらに、この対策で防止しようとしている問題は、おそらくテストでは捉えられないでしょう。とにかく、@ ThomasOwensがこれに答えてくれるのを楽しみにしています。
少なくともアメリカのイデオロギーから見た政府の役割は、ソフトウェア会社に欠陥または安全でないソフトウェアによって引き起こされたあらゆる物的損害に対して責任を負わせることです。これにより、企業は独自の基準を適用し、問題に対して個人的な責任を負うようになります。これは常により優れたソリューションであり、その範囲を超えた中央政府は含まれていません。
更新
私はこれを昨夜のビールや10杯よりももう少し考えていました。
医療分野を規制したのは、1つを除くすべてのパラダイムを根絶することでした。彼らの目標がホメオパシーおよび自然療法医を排除することであった場合、親切に「クォック」と呼ばれ、そのような規制は成功しました。しかし、立法を書いている人以外の誰にとってもそのようなことは有益であることに私は同意しません。これが何をしたか考えてください。これにより、ヘルスケアのコストが持続不可能なレベルに引き上げられ、M.D。の法的責任のレベルが大幅に増加し、市場から消費者の選択力と自己決定力がすべて取り除かれました。医学界ではアイデアの市場がなくなったため、新しい治療法や医学についての考え方が抑制されています。さらに、フィールドへの参入障壁は信じられないほど高く、その結果、優れたM.D.が不足しています。さらに、規制機関は医師の供給を管理する権限を持っているため、医師に支払われる価格を管理することができます。
実際、私たちが医療規制から得たいくつかの利益はありますが、コストは完全に高すぎます。
このような規制が通過すると、ソフトウェアエンジニアにも同じことが起こります。今、私はそれを見ることができます。規制当局は、オブジェクト指向プログラミングが設計の唯一の標準であり、関数型および手続き型プログラマーが実践することを許可されないことを決定します。それから、彼らは私たちが自分の記憶を管理することは安全ではないので許可されないことを私たちに伝え始めます。その後、彼らはすべての喉を詰め込み、JavaとC＃を使用して、OracleとMicrosoftがより太くてより幸せになる間、それを使用する必要があることを知らせます。イノベーションは抑制され、創造性は禁止されます。Microsoftとグーグルは法律を書くので、市場のルールは彼ら自身の収益性と社会的幸福に反対する方向に曲がります。
また、コンピューターは趣味や学問として始まったということを皆さんに思い出させてください。 80年代および90年代初頭のUnix戦争以外にも、無料のオペレーティングシステム、無料のコンパイラ、無料のプログラムなどがありました...これはすぐに終わります。 Richard Stallman、Linus Torvalds、Dennis Richtieが私たちに遺した世界は、次第にその存在から消えていきます。
要約すると、「wordpress CMSサイトを1時間あたり25ドルで設計します」や「iPhoneアプリを500ドルで設計する」人と競争するのにうんざりしていませんか。なぜですか？私は何をするのが得意なのか、そして私が望む顧客が卓越性のために喜んでお金を払ってくれるからです。私が独立して、または私の勤務地でプロジェクトに取り組むとき、私は私のf *＆^のリスクを負います自分の頭と評判です。どこへ行ってもついていきます。また、ほとんどの人は、彼らが支払うものを手に入れていることを知っています。彼らの芝生の男に支払う価格だけを支払ってくれる顧客は、悪夢になるでしょう。とにかく対処する必要があります。政府が法的構造を修正してサービスプロバイダーに損害を補償するように強制した場合、現場で雇用されていた悪質なプログラマーはほとんどいなくなります。
ちなみに、私たちにはまだ悪い医者がいます。唯一の違いは、市場から彼らを排除する力がほとんどないことです。彼らが自分の行動に対して責任を負わなければならない場合、彼らは彼らの顧客に無能な大混乱をもたらす機会が再びある前に廃業するでしょう。
シリコンバレーニュース-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の作業から大幅に撤退したときに、ライセンスについて statement を発行しました。公開されているSWEBOKドキュメントとACMステートメントを確認した後、ACMの意見を支持します。
記事をちらりと見ると、4〜6年の経験を持つ人が、基本的な知識をテストする試験を受ける必要があります。それはばかげたことを超えています、そしてドアの外で笑われるべきです。
デバイスのソフトウェアコンポーネントは、実装の詳細です。たとえば、制御システム業界では、以前はすべての安全装置がハードワイヤードであり、人々はソフトウェアを信頼していませんでした。ただし、現在、セーフティリレーやセーフティPLCなどのソフトウェアベースの安全装置が使用されています。これらは、安全装置に関する業界の規制（安全カテゴリに応じて）に準拠する必要があるため、許容されます。したがって、場合によっては、デバイスに冗長プロセッサ、および2つの異なるチームによって記述された冗長コードなどが必要になります。
それが一般に販売され、消費される場合、安全ガイドラインを満たす必要がある製品です。製品にソフトウェアが含まれているため、これらのルールは変更されません。製品がすべての規制基準を満たしていることを確認するのはエンジニアの仕事です。製品にソフトウェアが含まれている場合は、ソフトウェアを確認する必要がありますそしてその分野で有能であること。そうでない場合、設計者が設計を承認した場合、彼ら（または彼らの会社）は責任を負い、欠陥があることが判明します。
一部の製品がより厳しい要件を満たす必要があるという理由だけで、すべてのプログラマーを規制する必要はありません。このような製品にソフトウェアが含まれる場合、ソフトウェアコンポーネントが要件を満たしているかどうかを確実に判断できる、十分に開発されたエンジニアリング分野が必要です。どちらかといえば、それがIEEEの意味です。ソフトウェアエンジニアリングの比較的若い分野は、他のエンジニアリング分野の信頼性と信頼のレベルにまで発展させる必要があります。
「プログラミング」とはまったく関係がなく、「エンジニアリング」とはすべて関係があります。
もちろん、これにより、開発者とエンジニアの違いに関する論争の的となる問題に戻ることができます。これらは通常、定期的に重複する2つの異なる役割です。開発者の部分は、ソフトウェアを作成することを意味します。ロールのエンジニアリング部分は、デザインにスタンプを押すと、公共の安全に責任を持つことを意味します。あなたはcanがいなくても1つになります。
ソフトウェアはすでに航空機業界で厳しく規制されています。 DO-178B を参照してください。
業界の他のサブセットにも規範があると確信しています。
「ソフトウェア」は、最近非常に多くを網羅しています。私はすべての包括的な規制を強制するのはばかげていると思います。
ソフトウェア業界の規制は、品質保証プロセスの規制を通じて行うのが最善です。
これはすでに行われています-大規模なソフトウェア企業には、多数のテスター、QAマネージャー、自動テストスイート、コードレビュープロセス、テストプロセスが次々と導入されています。他の会社に対してソフトウェア品質監査を行うことを目的とする会社があります。標準化組織には、QAおよびQA監査のガイドラインがあります。
会社の内部では、ソフトウェアエンジニアが仕事の品質に責任があります。しかし、彼らのチェックとバランスは会社の品質プロセスにあります。
これは、「ソフトウェア関連の問題」を解決するための最新の試みと同じです。法制化しようとする人々は、問題の根本的な経過についてほとんど知識がありません。安全上重要なソフトウェアを開発する際に、規定されたプロセス（およびもちろん意図）に従っている場合、航空機の場合、医療機器の原子力発電所では、単一のバグだけでは障害を引き起こすことはできません。アルゴリズム全体は、いずれかが害されることなく誤って実装される可能性があります。
FDAとFTAはどちらもリスク分析を必要とし、それに基づいて緩和戦略を立てます。後者は通常、緩和策に欠陥があることを受け入れるスイスチーズ戦略であり、同じリスクに対して複数の緩和策が適用されます（1つの緩和策は複数のリスクにも適用される可能性があります）。 1つ、たぶん2つのスライスを一緒にしますが、十分なスライスを一緒にすると、それは不可能になります。緩和策が完全に実装されていても、100％安全な機器にはなりません。リスク分析が正しくない場合、誰も考えていないリスクがあります（Y2K）。
必要なすべての項目をテストでき、非常に高いレベルを必要とするすべてのエンジニアをテストできますが、それは非常に重要です。ほとんどの安全上重要なエラーは統合エラーです。それらは1つのマンコードのエラーではなく、2つのソフトウェアシステムのソフトウェアとハードウェア間の不整合、またはアルファ粒子がプログラムカウンターを適切な場所からノックしたために発生します。
私は、経験豊富で有能な開発者と一緒にいくつかの安全上重要なシステムに携わってきました。彼らは、その分野での賢明なテストに合格します。安全性に重大なエラーがないプロジェクトに参加したことはありません。 （幸いなことに、システムが誰かに危害を加えたことがありません）
長い間確立された慣習と伝統にもかかわらず、それらはほぼすべての職業に存在するので、シャーラタンとクワックを完全に排除することはできません。
しかし、この発言が土地の奪取であるということで、ITがソフトウェア開発の彼の自由な制御と規制を悪魔的に企てているすべてのものの何が暗い恐ろしい支配者かわかりません。実際にIEEEについて話している場合、それらには確かに規制面がありますが、IEEE標準への準拠は多かれ少なかれ自由意志であり、銃を突きつけられているわけではありません。彼らは普遍的な業界標準を開発して、私たち全員が同じ言語で話し、全体の効率を高めようとしています。
さらに、彼らがレイアウトする標準は、一般的な慣行を正当化し、ソフトウェア開発の土台を築くことを助け、最終的に機械工学や化学工学とは異なり、より規律のある工学分野になります。ソフトウェアはその目標に近づいていますが、エンジニアリング分野として普遍的に受け入れられることは決してありません。
中心的な問題は、ソフトウェア開発者がかなりのデスクトップウィジェットの作成から、ミサイルガイダンスシステムの実装まで何でもできるということです。一方では、エラーの重大度と結果が他方よりもはるかに高いため、合理的に、安全に、そして効率的にアプローチするには、厳密に規制されたエンジニアリングの規律が必要です。これは、ブリッジが正しく設計されておらず、結果として崩壊するエラーの重大度によく似ています。ブリッジの設計者は、品質を確保するために私のエンジニアリング基準を遵守している必要があります。
私はそれをより厳格な規制とは呼びませんが、その代わりに参入の障壁となります。その点でメリットがあると思います。品質を上げるためには、非常に議論の余地があります。
現在、どのJohn/Jane Doeもプログラムを作成できます。立ち入りの障壁はありません。スクリプティングとWebテクノロジーに関する本を何冊か入手して、ハッキングを始めましょう。あるいは、それを「実行」する方法についてグーグルを始めてください。
私たちが全体として、参入障壁を高め、業界をより高い水準に維持し、ハッカー/職人からエンジニアに進化するときがきっと決心するとき、私はその種の規制にすべて取り組んでいます。
今日プログラミングしている資格のない個人が多すぎます。重要なシステムで動作するかどうかに関係なく、彼らはまだコードを生成し、さらに Big Balls of Mud を生成しています。
その点で、自主規制またはより適切に参入障壁を作成することは良いことです。私たちが言っているので、ちょっと通り過ぎてソフトウェアエンジニアと呼ぶことはできません。あなたは実際にスキルのレベルを実証する必要があります。
Demostratingスキルは、単にテストを行うか、「名誉のバッジ」を取得する以上のものです。テストは単なる検証です。本当の検証は学校、インターンシップ、見習い、先輩の下でのメンタリング、練習であり、すべてがその一部です。
IEEEが何を達成しようとしているのかはわかりますが、現時点では、それは実りのない課題です。業界は急速に変化しており、製品をドアから押し出すことに対する過度の需要、「ハッカー」の考え方などがあります。規制は、もしあれば、内部から行われる必要があります。
まだ記事は読んでいませんが、ソフトウェア業界の規制が人類に利益をもたらすかどうかは、状況次第だと思います。
業界は全体として多種多様なドメインを包含しており、その一部は生命に関わるもの（医療機器での放射線量の制御など）であり、一部はそうではないものです（「マペットはあなたですか？」Facebookアプリ）。利害関係が低いアプリケーションの規制については、何の議論もありません。
法的な規制を開始してはいけません。むしろ、開発者向けの認定プログラムから始める必要があります。 のみ認定プログラムが測定可能な利益を生み出す場合、法的規制の問題があるはずです。
認定プログラムが測定可能な結果を生み出したとしても、業界は厳密にビジネス上の理由からこの認定を要求することを標準化する可能性が高く、法的規制は必要ありません。 （これが [〜＃〜] mcse [〜＃〜] のような委任が存在する理由です-企業は、MCSEがトレーニングされているドメインのMCSEを採用することを好みます。）
とは言っても、ビジネスに害を及ぼすことが理にかなっているドメインが残っています（多くの場合、これらは 否定的な外部性 ですが、一部の機関では 市場支配力 の結果である場合があります） ）。たとえば、ある地域には1つの地方病院がある場合があります。この場合、バックエンドソフトウェアの品質は、患者が受けるケアのレベルに大きな違いをもたらす可能性がありますが、患者がどの病院を選択するかにはそれほど大きな違いはありません。その場合、病院は必ずしも高品質の開発者に投資するための多くのビジネスケースを持っているわけではありません。この場合、病院が雇うことを許可されている開発者を規制する公衆衛生上のケースがあるかもしれません。
私見では。
私はこれに答えなければなりません...
@JonathanHensonの発言と@gnatのエントリから始まりますが、私が言ったことは問題ありません。お金を持っている人は認定されたものに支払うことができ、お金を持っていない人または国はライセンスに支払うことができません（認定されたものには多すぎる） ）、そのため、それが実施された場合でも、依然としてレネゲードがあります。従来の（それほど伝統的ではない）配信方法が閉鎖されている場合でも、関心のあるユーザーにソフトウェアを配信する方法が見つかるでしょう。別のHTTPプロトコルまたは代替のネットワークスタック全体を開発することを意味する場合でも、接続を検出不能にすることのみに焦点を当てています（これを実行できる可能性があるユーザーについては、前の段落を参照してください）。
また、世界はどんどん貧しくなり、物を支払うお金がどんどん少なくなるため、何かを支払うという考えは危険にさらされています。FOSSソフトウェアのみを使用し、認定（ブラジルとインドが思い浮かびますが、他にも確かにあります）、そしてそれらの国のいくつかは、本当に大きくなっています。また、スキルが不明な未知のプログラマーが作成した認定されていないソフトウェアを使用しています。
また、あるタイプの認定がある場合でも、認定は倫理ではなく知識のみを認定します。一部の医師は人から無断で取り出された臓器を使用していると考えているため、認定されたプログラマーもいます。倫理を持たず、意図的または非意図的にずさんなコードを書く。ほとんどのFOSSプロジェクトでは、熟練していない可能性のあるほとんどのプログラマーが、他の人からのコードをレビューし、ペアプログラミングを少しするような方法でエラーを見つけようとします。
最後に、セキュリティについてもっと知っており、特定の政府部門の最も専門的なプログラマーにのみ一致する方法でセキュリティソフトウェアを開発するハッキンググループ（ブラックハッカーグループではなく、ホワイトハットグループやグレーハットグループ）についてどう思いますか？.