Microsoftの支援を受けた革新的なAIスタートアップとしてもてはやされたAI企業のBuilder.aiは、ソースコードを書かずに開発できる「ノーコード開発プラットフォーム」を提供していましたが、このサービスが実はAIではなくインドのエンジニア700人による人海戦術で成り立っていたことが判明し、倒産に追い込まれたことが報道されました。
破産したAI企業が提供していたコーディングAIが実は700人のエンジニアによる人力サービスだったと判明 - GIGAZINE
Builder.aiは、自社のサービスが「Natasha」というAIアシスタントによって運営されていると宣伝しており、レゴブロックのようにソフトウェアアプリケーションを組み立てることができるとうたっていました。
破産したAI企業が提供していたコーディングAIが実は700人のエンジニアによる人力サービスだったと判明 - GIGAZINE
しかし、その舞台裏では顧客のリクエストがAIではなく人間の開発者によって手作業で処理されていたことが発覚し、大きく取り沙汰されています。
破産したAI企業が提供していたコーディングAIが実は700人のエンジニアによる人力サービスだったと判明 - GIGAZINE
フィンテックに詳しい投資会社であるEbern Financeの創業者のベルンハルト・エンゲルブレヒト氏は「Natashaというニューラルネットワークは700人のインド人プログラマーによって構成されていました。
破産したAI企業が提供していたコーディングAIが実は700人のエンジニアによる人力サービスだったと判明 - GIGAZINE
スタートアップのBuilder.aiは、必要な機能を選択することで、コンストラクターなどの任意のアプリケーションを作成することを提案していましたが、実際のところ顧客からのリクエストはインドのオフィスに送られ、そこではAIではなく700人のインド人がコードを書いていました。
破産したAI企業が提供していたコーディングAIが実は700人のエンジニアによる人力サービスだったと判明 - GIGAZINE
この詐欺により、この新興企業は8年間で4億4500万ドル(約640億円)の投資をMicrosoftを含む大手IT企業から集めています。しかし、『AIによって作成された』はずのアプリケーションは頻繁に不具合を起こし、コードは判読不能で、機能は動作せず、結果的に本当にAIが作ったようなできばえでした。そして、詐欺行為が発覚した後、スタートアップは正式に破産しました」と説明しています。
破産したAI企業が提供していたコーディングAIが実は700人のエンジニアによる人力サービスだったと判明 - GIGAZINE
⇧ 何と言うか、「企業倫理」とか考慮しないと、お金のためなら、何だってするのが人間ということですかね...
それにしても、700人ものエンジニアがいたならば、何割かを「ソフトウェア開発」に従事させて「ノーコード開発プラットフォーム」を開発すれば良かったのでは？という気がしますな。
ソフトウェア開発の不確実性が高いのは自然と情報が錯綜した状態に行き着く性質のためが故
前々回、前回、と
⇧ 上記の記事で「JJUG CCC 2025 Spring（Japan Java User Group Cross Community Conference 2025 Spring）」 のセッションを傾聴してきて思ったことを徒然なるままに記したわけなのだが、今回も同様。
セッション『事業戦略を理解してソフトウェアを設計する』が良かったので、備忘録として。
で、表題の件の話にもなるのだが、セッション『事業戦略を理解してソフトウェアを設計する』の資料が公開されていたので、抜粋するが、
⇧ 上記にあるように、「ソフトウェア」というのは、自然に任せるままにしておくと「情報が錯綜した状態に行き着く」と。
これは、至極当然のことで、「ソフトウェア開発」というものは、「個人開発」でもない限り、多数の「ステークホルダー」が関わることになるのだが、様々な要因で「ソフトウェア開発」に関わる人やチームは変遷し続けることになる。
その結果、
- 不特定多数のファジーな意思決定が潜在リスクを発生させ得る
- 100%の正しさを保証できないが、全てを把握するのは不可能ので致し方ない。
- 開発時点の局所的な最適解にならざるを得ない
- 未来も最適解である保証はないが、未来のことは分かりようがないので致し方ない。
- 暗黙知と形式知が混在した状態で継ぎ接ぎされていく
- 氷山モデルの状態にならざるを得ないのは致し方ない。
のような感じで「ソフトウェア開発」を取り巻く「状態」が徐々に「カオス」な方向へ変化し続けることになりますと。
つまり、「情報が錯綜した状態」になるのは不可避でありますと。
改善するには、
⇧ 上記のスライドにあるように、「情報」を再整理する必要があるわけだ。
所謂、
- リエンジニアリング
- リファクタリング
といった作業が必要になって来るのだが、「現状（AS IS）」について把握できなければ、「改善」のための「方針」が定まらず、「あるべき姿（TO BE）」に変化させることは難しい。
で、言い方は悪いのだが、「ソフトウェア開発」における「情報」というものは、虚実入り混じった「状態」になってしまっているので、
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。
⇧ 上記の結末に行き着くことが多い。
つまり、「情報」の再整理をしようにも、「情報」自体がファジーであるため、「推測」などせざるを得ない「状態」であるがため、且つ、不特定多数の人間が関わるため、各々の「認識」のズレは微々たるものであったとしても、相乗効果で結果として「認識齟齬」の雨霰が発生してしまいますと。
このような「状態」を表すのに良いものとして、
バタフライ効果（バタフライこうか、英: butterfly effect）は、力学系の状態にわずかな変化を与えると、そのわずかな変化が無かった場合とは、その後の系の状態が大きく異なってしまうという現象。
気象学者のエドワード・ローレンツによる、「蝶がはばたく程度の非常に小さな撹乱でも遠くの場所の気象に影響を与えるか?」という問い掛けと、もしそれが正しければ、観測誤差を無くすことができない限り、正確な長期予測は根本的に困難になる、という数値予報の研究から出てきた提言に由来する。
⇧「バタフライエフェクト」があると思う。
そもそも、本来「プログラム」は僅かな誤りで動作しなくなる代物であるとされるにもかかわらず、「ソフトウェア開発」では「障壁」となり得る要因が多過ぎて、「問題」が発生しないということの方が稀であると言わざるを得ない。
とは言え、「予算」が限られているがため、
⇧ 上記にあるように、基本的な「方針」としては、「中長期的」に「利益」を得られそうな「要求」の見極めをして、導入するに適切な「要求」を取捨選択し「システム」の「要件」を決めていく必要があるわけだ。
ただし、「ソフトウェア開発」で新たな「要件（機能・非機能）」を追加する「コスト」が高過ぎる「状態」、所謂、「変更容易性」の低い「状態」になっていると「事業戦略」に追随していくことができなくなると。
「銀の弾丸」が存在しない以上、あらゆる「意思決定」は「現時点」での「ベター」を模索する活動になりますと。
限られた時間の中で、
- できること
- できないこと
を定義していくしかないわけなのだが、どんなことも「トレードオフ」にならざるを得ないですと。
誰でもできることは、可能な限り「空中戦」を無くすことぐらいかなぁ...
相も変わらず「ソフトウェア開発」は難しい...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
