#362 ソフトウェア開発はなぜ難しいのか？生産性を10倍にするような銀の弾などない

2025/6/8 ·

00:03
この番組はエンジニアの成長は楽しい学びからをもっとに我々が日々学んだことをワイワイとアウトプットしていくラジオでございますはいなんかワイワイ感少なめなシリアスなナレーションから始まりましたありがとうございます息吸ってましたね映画の広告をイメージしてみましたそんな感じなんですね映画の広告まあ物によるけどねまあまあまあそれはそうマーベルとかでこういう感じじゃないけどねなるほど今日はですねはいはいはいなんでしょう
00:34
論文を読もうのコーナーでございます論文を読もう論文読むんですね論文を読もうのコーナーでございますいやですねいやいや大丈夫だよ論文重いじゃないですか重いと思ってるでしょ実は本よりめっちゃ軽いよそうですよね逆にそれめっちゃ重いなんかね俺も論文のイメージそういうイメージがあってこれ多分英語でびっちり書かれてて
00:59
スライドとか50ページくらいあるのかなって思ってたんですけど僕今回ですねコンピューターサイエンスの歴史を変えた論文シリーズがいくつかあるかなと思っていて例えばシャノンのなんとかかんとかみたいなやつとか全然わかんないじゃないですか例えになってないんですよコミュニケーションのなんとかかんとかみたいなやつとかあと
01:29
コット博士のリベーショナルデータベースのやつとか多分誰かが書いただろうオブジェクト思考のやつとか無理して出さなくてもあるとは思いますあると思っております最近だとアテンションイズオールユニードとかいろんな歴史を変えた論文があると思っていてその中のうちの1個のフレデリックス・フィリップス・ブルックス・ジュニア長っすね
01:58
名前長すーすーすー言ってましたNo silver bulletEssence and accidentIn software engineeringえーとなるほどなるほど最初なんて言えばブレッドSilver bulletSilver bulletよく言われますねソフトウェア界隈ではね発音バレットかなバレットだと思いますね確かにシルバーバレットだと思いますでもなんか外人発音するとブに聞こえんだよなそれはなんかあれじゃないですかイギリス読みか英語アメリカ読みかみたいな話じゃないですかそういうことか多分はい
02:28
さあこの論文何の本でしょう長かったなリスニングですよ今のは銃弾銃弾シルバーバレット銃弾ですよねちょっと足んないですけどね後ろの方は何でもいいわそこの部分あんまり日本語訳されないでも後ろの方結構大事じゃないですか内容に踏み込んだら大事コンピューターサイエンスにおける大事な銃弾
02:59
さっきの論文の導入に引っ張られすぎてるこれあれですね日本語で言うとウィキペディアには銀の玉などないと訳されてますね珍しい訳しですね銀の弾丸って言いますけどね銀の弾丸はないとかとも呼ばれるよね銀の弾丸あれですかドラキュラ倒せって言ったっけ狼人間狼人間を倒すには銀の弾丸が必要なんですけど
03:29
そんな特効100みたいなもんソフトウェア界隈にはないですよっていうそういう話ですねこの論文意外とね5、6枚ぐらいなんですよねPDFまあ論文って全部そうですよねフォーマットが決まっててで学会がその枠みたいなのが決まってるからこのぐらいの長さで出してねっていうそうそうそうそう感じですからねそうで
03:54
とはいえ内容がやっぱ難しいんでしょうってなるじゃないですかでも僕らには今ね地の巨人が宿ってるんですよジャイアントオブブラッドですかジャイアントオブアースウィンドーファイアーです全然わかんなかったアースウィンドーファイアーって何アース&ウィンドーファイアーです属性
04:18
セプテンバーとかを歌ってる人たちですね知らねーわアースウィンド&ファイヤーかセプテンバーってあれですかウォーターボイズ違う?セプテンバーは違う?なんの曲セプテンバーってウォーターボイズで使われてる可能性はありそうだけどじゃあちょっと違うやつですねセプテンバーですね音楽の人ですねそんなことを言っておいてはい
04:40
知恵の巨人がいるってことですねそうですそれはノートブックエレムさんがまず一人目もう一人はジェミオくんですねノートブックエレムなのになんで急にジェミニだけノリさんのあだ名みたいなのついてるんですかジェミオくんがね活躍してくれましたよこれとりあえず論文をねノートブックエレムに突っ込んで全部日本訳してもらいますと確かにいいなそれ
05:07
なるほどで概要を作ってマインドマップ書いてくれるじゃないですかマインドマップでだいたいざっくり構造を把握して歩きながらインプットするために音声を生成して歩きながら聞いてたわけですよなるほどその上でジェミニーにも同じようなことをして論文のURLだけバーって渡して壁打ちをしてくださいって文を投げてそしたらですね向こうからいっぱい質問くるんですようん
05:35
こっちが質問したかったのにいやですよねおかしいなって思ったんですよ今違う違うって仕方なく質問返しまくってたんですけど何個も来るんですよね質問がだから最終的には回答プラス逆質問を突っ込んでなんとか流れを断ち切って
05:54
こっちから質問することに成功しましたね別の誘導の仕方ありそうですけどねこっちが質問したい質問したいって最初からそう言えばよかったんですけどとはいえこの質問に答えるのも意味ありそうだなってなっちゃってなんかねやっちゃったんですよねやっちゃったんだこの難しい論文を読み解いてみましたはい今日はこれの発表をしていこうかなと思っておりますお願いしますということでまずですねこの
06:23
論文発表されたのは1986年
06:26
9月40年弱前そうだからあれですねわかりやすく言うと尾崎豊の死んだ年の6年前ですねピンとこないしなんで尾崎豊ベースなんですかキリストみたいな話だな紀元前何年みたいな話でした今いや僕と僕が生まれた年なんでなるほどつまりカイチが生まれた年ですねカイチ誕生3ヶ月前に発表されてますこれえ
06:53
違う違う違うそれは尾崎豊かだった危ないややこしいめちゃくちゃ嘘ついたずっと何の話してるんですかめっちゃ嘘ついたわ一人で袋工場にどうしようどうしよう全然意味わからなかったしかも1992年の9月って別に尾崎豊かの命日でもないしなんでもない日にちを言ってしまったわ
07:25
ちょっと戻ってください1986年ね発表された論文でございますこれ題材がですねソフトウェア開発における困難というか難しさみたいなのを題材にしている論文で今もう発表されて40年ぐらい経とうとしてるんですけどそれでもいまだにエンジニア界ではね聖書として扱われている論文ですねやっぱ聖書論文なんですねエンジニアは
07:55
まあそこは適当に言ったんですけどまあまあでもよく参照に出てくるなと思ってまあ確かにねいまだにそれこそね分かんないけど達人プログラマーもそうなんじゃないですかちょっと調べてないですけどまあでも達人プログラマーまだ20年じゃないですかはいはい20周年達人プログラマーがリファレンスにしてそうじゃないですかああそういうことねそうそうそうしてると思うよですよねなんかあったはずうん
08:16
まあ思うなんでねその正確なところを見てくださいそうですちゃんと見ましょうはいでこのここで言う銀の玉っていうのが具体的な定義があってですねまあ生産性を10倍にするものっていう感じですねほうえっとその解決策によって生産性が10倍になるようなその銀の弾丸というのでいるとさようなるほどはい
08:36
これを書いているブルックスさんって何した人なのっていうところで一言で言うとすっごい開発者ですねすっごい開発者IBMのOSとかを作った人っぽいんですけどなるほどこれ以外今回紹介する銀の玉などない以外だと有名なのは遅れてるソフトウェアプロジェクトに
08:57
要因を追加してもプロジェクトをさらに遅れるだけであるっていうので有名なありがとうブルックスの法則を提唱したありがとう本当になんかそういうのを管理側も理解してくれてるおかげで大混乱が起きなくなっているのはブルックスさんのおかげですねそうですこれについて書かれているのが人月の神話っていう本ですねこちらが論文より前に書かれてるんですけどなるほど
09:23
ちなみにブルックスの法則なぜ人を追加しても納期が早まらないでしょうじゅんぺいくん直感的にはね働きあり増えるなら仕事早くないそうですけどねそうですよ確かに確かになぜでしょうねえこっからこっちに物を運びたいって言ったらね猫の手も借りたいですよねそうですよだって納期ねあとあと1ヶ月で納期だけどこれ3ヶ月分はタスクあるんじゃないか
09:50
どうする?どうする?どうするは質問とちょっと違いますけどねまあ確かにまあでもねもうちょっと分かりやすく言うとあと1ヶ月と半月分あるってなった時にうん
10:03
じゃあ人増やして解決するかってそうでもそれは失敗しますなぜでしょう人を増やしたとてそいつはすぐにキャッチアップできなくて戦力にならないからであるいいとこついてますそういう人が来たらどうしなきゃいけないですか教育しなきゃいけないそういうこと教育コストがかかってそのプロジェクトの方に結果時間が割けない
10:29
避ける工数が減るそういうことが1個目喜び方どうした?マジで確かにな自分は下がってましたよだいぶ確かにねどうしたんだろう他にもいくつかあるんですけどコミュニケーションパスの増大要は人が増えればそれだけ連絡経路増えるからコミュニケーションのコストも上がるよねとなるほどバカにできないですねそして3つ目タスク分割の限界
10:58
これよく妊婦の話が出てくると思うんですけど子供を産むのにとっつきかかりますとじゃあ10人集めたら1ヶ月で産めますか厳しいもんなんすかねやっぱりいけるかみんなでどうしたどうした頑張って急にこれ炎上するかなしないですよね炎上はしないよマジで取るやつ一人もいないからこれがタスク分割の限界ですよ確かにできない実際のプロジェクトでもなんかさ
11:28
ここ分けてもなーみたいなことないですかめちゃありますそれですねっていうのがあって増えちゃうよっていうブルックスの法則ブルックスの法則が今回いいんですわ続いてソフトウェア開発はなぜ難しいのかという本質の部分に入っていきましょう逆になぜ簡単だと思ってしまったのか教えてくださいまあいいやすいませんちょっと変なチャチャ入れました今の教えてくださいなぜ難しいのかそれはみんなの心にあるそういうことじゃないです
11:58
読んできたんでしょ論文まずですね難しさには2つの分類がございますそれこそさっき副題にあったエッセンス&アクシデントっていうのがすごいそれを分類してるやつになるんですけどエッセンスつまり本質的な困難っていうのがまず1個ございますそしてもう1つ偶発的な困難っていうのがございますこれ翻訳によっては偶有的とかも言ったりするんですね偶有ってどう書くんですか偶がある
12:28
初めて見たそれは初めて見た日本語福寺的って言った方がなんか分かりやすいかもしれないイメージでもグーは結構大事なんじゃないですかそのグーの字というかどうなんだろうな
12:46
いろんな要因が重なってたまたまというかたまたまがぶっちゃけない感じする副作用というかそんな感じする聞きますまず本質的な困難からいきましょうこれはソフトウェアというものが抽象的であるがゆえの困難でございますパターンは4つありますその1複雑性ソフトウェアはとっても複雑だよねとうん
13:16
どの辺が複雑ですか?なんかいっぱいクラスあってちょっとよくわかんなくなっちゃいますねまあ遠からず他の人工物と比べるとね圧倒的に部品とかその部品に対する状態が多い上に単純な繰り返しが少ないんですよ上に全体の把握が難しいと例えば棚を想像してみてください棚を組み立てるときまずパーツどんなの入ってますか?板ネジネジ
13:50
なんかネジ回すやつやつしかなくない?今カラーボックスの感じだったけどしかないじゃないですかサイズのバリエーションはもちろんありますけどしかも同じサイズのパーツとかも何個もあるよねネジAとかと比べると圧倒的に複雑ですと圧倒的に複雑ですしかもさ棚の組み立てって要するにくっつけてネジでつけるだけじゃないですか
14:19
そういうなんかちょっと割り込んでいいですかさすがに棚はハローワールドすぎますよいやいやいやさすがに多分マンションを想像した方がいいですマンションあれも多分半年とか10ヶ月プロジェクトですただマンションって
14:38
色々工程はありますけど多分ひとたび1階は置いといて2階から10階までは多分一緒なんですよ部屋の構造が部屋の構造もですしあとは組み立てる工程が確かに階段とかも繰り返しのパターンでついていってるしそうですそうですドアも全部そうだし部屋の中の構造も違うところもあるけど大体同じだよねとか
15:02
部屋の構造もおそらくマンションだと縦割りしてるんですよ部屋によってグレードがあってそのグレードは縦割りになってるんですよそれはなぜかっていうとどの階層も同じように工事するためだから同じ位置に柱立てて同じ位置にコンクリ流してっていう風になってるんでだからマンションは同じ工数がかかったとしても繰り返しは多いよねっていうのは
15:31
隣でマンション建つのを見ながら思いましたなるほどね隣でマンション建つのを見ながらそれを思ってたのそうですそうですすごいなこいつでもね毎日ベランダからね日課でしたから隣のマンションがどんどん大きくなってくるのがねそうね自分の部屋をちょっと超えるシーンを見てそうそうそうあーもう超えちゃったかーちょっと景色悪くなったなーってねだいぶねだいぶなったよねだいぶなりました確かにかなりそういう意味だと繰り返しが多いっていうのは確かになって思いましたねうんうん
15:58
ソフトウェアの方がいいかも普段触ってるでしょうしどういうことですかソフトウェアって実際繰り返し公文とかあるじゃんってなるけどいやあんまないじゃないですかとはいえって感じだよなっていう例えばですよECサイトだったらユーザー登録と商品登録一見どっちも登録かと思いきや全然違う処理書くじゃないですか確かにねそういう意味だとあんまり繰り返しないと思いますわコンポーネント作って使いますとかも限界あるよね
16:27
そんなにしょっちゅう使ってるわけじゃないしっていうそうそうそうソフトウェア全体に対する繰り返しの割合は全然マンションとかよりは少ないっていうので複雑になってしまいますよとそしてその2同調性もしくは適合性整合性これちょっとね言葉の意味と説明が微妙になんかあれなんですけど
16:47
要はソフトウェアって人間が作った既存の制度とかシステムとか他に動いてるやつとかそういうのに合わせてインターフェース作っていかなきゃいけないのでそういう不条理な外部のルールに適合して作っていかなきゃいけないというそういう難しさしかもソフトウェアって大体最後に載せられるじゃないですかなんで一番適合しやすいよねって思われちゃうから他のに合わせてよって強制されることが多い
17:16
なるほど最後って言ってるのはあれです例えばIOTとかみたいな話してます?そうそうそうそう確かにめっちゃあるわ組み込みのやつとかだとねもう決まっちゃってでなおかつ納期はそっちの方が早いからうんじゃあ納期の遅いアプリ側でちょっとこれ合わせてってなるなるよねなりがちそうえー
17:38
っていうので他の環境に合わせて作ることを強要されがちっていうのがその2の難しさその3は変更可能性っていうところで成功したサービスほど新しい機能の追加とか環境に対応するための変更みたいなのをやってねって圧力がすごいかかってくる
17:57
ユーザー多い方が声届きやすいよねとかそういうことだね声届いたらじゃあビジネス的に変えていこうかってなるのは必然的な流れかなとそしてその4不可視性いろんな意味で不可視性あるんですけどまずソフトウェアそのもの見えないよねとプラスソフトウェアをじゃあ視覚化するっていうことがそもそもできないんですよっていうのは次元が多すぎるあまりにも変数が多すぎるというか
18:24
どういう意味?UMLとかを作るにしてもUMLっていわばモデリングして書くわけじゃないですかとはいえあれってソフトウェアの一側面を切り取って図にしてるだけで統一的な一個の図にすることってできないですよねそれはなぜできないかっていうとソフトウェアにいろんな側面がありすぎてそれを統一的に視覚化することがまずそもそも3次元じゃできないと2次元とかいろんな側面っていうと
18:52
例えば例えば状態にフォーカスした図とかもあるしクラスにフォーカスした図もあるしデータの流れにフォーカスした図もあるしまたまたデータベースのデータ構造の図もあるじゃないですか確かに一個じゃ表せないそうっていうところが非常に複雑でこの辺がやっぱ本質的な課題になってるねというわけでございますはい一方
19:17
偶発的な困難副次的な困難も存在してるよとこれはね分かりやすいですね具体例が例えば厳しいハードウェア制約最近少ないけどあるでしょうね最近だったらどっちかというとGPUとかでこの辺がネックになっている気もするけどAI周りはもちろんありますねAI周りは性能足りなくて思ったよりハードウェアが高くなるのかもしくはちょっと精度下がるのかみたいなねそうそうそうそう
19:49
そもそもこの論文を書かれた時って個人が自由にPC使える時代じゃなかったので本当に一台の超強力なメインフレームみたいなPCがあってそこにみんなが端末つないで作業するみたいなだからみんなが使いすぎると重くなったりとか一回送ったリクエストが全然返ってこないとかっていうのが普通にある時間だったんで時間?時代だったんでそういう制約がまずあるよねと
20:16
それは今もどんどんミニマムになっていってるけどゼロにはなってないよねって感じだねそして扱いにくいプログラミング言語やデバッグツール当時すごそう当時ちなみに主流だった言語はねCとかコボルとかフォートランとかそういう系らしいですリスプとかもかなまあまあまあはい
20:40
ここでも言及されてるけどCとかっていわば高級言語じゃないですかおそらくこのブルックスさんが論理を作り始めてるのはもっと前だと思うんでCとか登場する前からなんかこれ使いにくいなって思ってたと思うんですよだから結構Cの登場は多分この時代の人たちにとっては衝撃だったというか革命的だったらしいですよそうでしょうねというので2種類の困難がございます技術はでも進歩していってますよね
21:09
例えばオブジェクト思考が登場したりとかそれこそUMLとかも多分90年代の末頃に出てるんでへーそれ以前どうしてたんでしょうね本当にね本当だよね各々がやってたんだろうね独自のルールとかね複雑なものは作れなかったんだろうななかったからどうにかなってたんでしょうねそうかもね
21:28
まあというので技術は進歩していってるんですけどその進歩した技術によって解決されるのって本質的な部分じゃなくて全部偶発的な部分の困難がこう解決されていったと確かに確かにコンピューターの性能どんどん上がっていってそういうなんか待ち時間とかどんどんなくなっていって生産性は上がっていったけどでも本質的にソフトウェアが複雑だよねっていう部分に関しては別に解決してないというかうん
21:52
なんならもっと複雑になってると思ってるそうだよねできること増えてリッチになった結果複雑になってってる気がする機能多いだろうねそれはシステム関連系とかめっちゃ増えてると思うそうなんですなのでそういうオブジェクト思考とかもなんかその
22:09
オブジェクト思考で抽象化とかできるじゃないですかその複雑な行動なんですけど結局それって実装面でそういう複雑な部分を取り除いているだけでそもそもそういうオブジェクトを設計しなきゃいけないとかどういう風な構造化するかみたいなところの難しさが変わったわけではないというのを言ってますね一応ですねこの中には本質的な課題へのアプローチというのが4つあってこれだったらアプローチできるんじゃないかというその1
22:39
作るではなく買うどういうこと?作るのが難しいなら買えばいいじゃないという発想です合ってるか分かんない絶対に当時ないんですけどSARSみたいな話ですか?ブルックスやば買えば炎上しないぜってことすごい素晴らしいしかもそれが既存の製品でニーズ見出せるならいいじゃんっていうそういうこと非常に大事な考え方ですねそうなんです
23:11
そしてその22と3ちょっと似てるな似てるけどちょっと違うかその2要求仕様の反復的改良とラピッドプロトタイピング反復的改良はわかるインクリメンタルで改善しましょうみたいな話だと思っててラピッドプロトタイピングってどういうことですかさっさと形にしてそれをベースにして議論を進めていきましょうよっていうことですねなるほどじゃあアジャイル開発の考え方ですねそうそうそう結局クライアントも何が作りたいか分かってないんで自分で
23:41
だから物があって議論してた方がそういうのに近づきやすいよねっていうことで早くプロトタイプ作れっていうそういうことで3つ目がインクリメンタル開発アジアル開発の話してますねこっちがアジアル開発に近いかなイメージ全体のうちの一部と一部かこっちはもう構築するという発想を捨ててソフトウェアを育てるという発想で作れという
24:05
偉すぎるな1986年って言いましたっけうんだからまだアジャイルマニフェストとかの全然もっと前だよね本当に頭いい人って頭いいですねやっぱね当たり前のこと言ってますけどおしまい頭いいやつの発言ではない絶対小泉幸文だったこれが本当に今で言うアジャイル開発だよね当時はインクリメンタル開発って呼ばれてたのかなそっちの呼び方の方が本質ですよねうん
24:36
で4つ目でも根本はこれだよねっていうのがあって卓越した設計者の発掘と育成発掘?採用だねあーなるほど掘ってんだ掘ってるって意識なんだ
24:51
市場から掘り出してるじゃん大事ですね結局どんな優れたプロダクトとかも少数の偉大な設計者がいてそれに支えられてることが多いよねみたいなことをこの論文では言ってて絶対そうどんだけ技術進歩してもそういうより構造をシンプルにして理解していくみたいなことできるのは人間なんだから優れた人間が
25:18
を見つけるのが一番大事だよって言ってますね設計ってマジ職人技っすよねノウハウはあれど案件というか課題とか問題とか状況によって全然条件違うというかやるべきこと違うじゃないですか何を
25:35
どのトレードオフで何を重視するとかどうやるとうちのチームのスキルセット的にこうだからとかってのもあるでしょうしねマジ職人技だと思うんで確かにビジネス戦闘力大事ですねそう本当に思うそこやれたことないからなアーキテクチャー楽しいよ設計家なので設計力磨くっていうのはエンジニアのスキルとしてめちゃくちゃ大事なんだなっていうのがねわかりますねうん
26:05
銀の弾丸はなかったんですけどこの辺のアプローチは効果的なんじゃないかとちなみにここから問いかけないので何も調べてないんですけどAIってさ銀の弾丸になり得るのかっていう銀の弾丸になるとしたらさっき言ってた本質的な複雑さを解決できるかって話ですよね本質的な複雑さは何でしたっけ
26:34
複雑すぎるってことと同調性周りに合わせなきゃいけないっていうのと変更可能性成功すればするほど変更が求められるっていうのと不可視性目に見えない複雑さがみたいななるほどなるほどなるほどはいはいはいわかりましたそれで言うとあれかもしれないですね開発プロセス全部AIでやれるんだったら銀の弾丸になるかもしれないですけどそれを人間が求めてるかがよくわかんないですね
27:00
そうだね人間視点だと解決したかもしれないけどそれはAIに責任転嫁しただけで課題は残っているのかもしれない課題になっているかはでもAI次第ですよねもちろんやれるようになったとしてもいやいやAIのいろんな処理のおかげですごく電力食っちゃいますそれで地球環境とかエネルギー問題すごいですだったら課題だと思うんですよ
27:27
じゃあもっと根本的にやり方見直した方がいいねってなるかもしれないですけど初めて本質的な困難側のアプローチの一個になるかもねみたいなことはあるかもなって思いましたね複雑なのは変わんないですよねソフトウェア自体はむしろもっと複雑になるかもしれないただ
27:53
って言っときながらなんですけどさすがに人間絡むことはあると思うんで人間が絡んだ瞬間解決してないと思います確かになぜなら人間がジャッジを下さなきゃいけないはずでジャッジを下すために物事を理解しなきゃいけないはずでその理解をする上では絶対に複雑性とかは出てくる
28:13
変更可能性とかあとなんか周りへの適合に関してはだいぶマシになるかもしれないですねどういうのはなんか他の外部のルールとかに合わせなきゃいけないっていうのが大変って結局変更がめんどくさいってことだと思っててその変更のハードルはだいぶ下がるんじゃないかなと思いますねそれこそちょっとずれるんですけどはい
28:35
バージョンのアップグレードとか動くことを担保しつついい感じに書き方変えなきゃいけないみたいなタスクめっちゃ得意じゃないですかAIそれって変更のハードル下がってると思っててだいぶ前よりはまだ何かに対してアップデートかけるのはいいかもねリポジトリとか読み込ませれば対応も抜け漏れないかを見れるようにもなるんでしょうしねいずれ個人的には思うんですけどどうです?
29:06
なんか聞いてて思ったのはソフトウェア自体が内在している課題感というか複雑性の本質みたいなところは結局変わってないけどそれを人間が課題として認識する重さは減っていくのかなっていうのがあったなって感じですねそうそうそう要するに銀の弾丸ではないけどいい
29:31
銀の弾丸じゃないけど効果的なダメージは与えられそう効果的かは分かんないけど銀の弾丸じゃない方法で狼男を殺してしまったみたいな殺せてるかも分かんない殺せるかも分かんないけど新しい武器は手に入れた確かにかな確かにな人間の手に負えないくらい複雑なことをする可能性ってあるんですかねないんじゃないかなと思ってんですよね
30:02
どうなんだろうな抽象度が上がればいいだけか抽象度が上がればできるのかもAIが発達してシステムが警備のバグを起こしましたその時AIではどうしても解決できませんでしたさあ君の出番だって見てなんだこれはってなった時に一体どう責任というか説明していくのかみたいなでもそれ多分今もありますよね
30:26
まああるねなんかすげえ人がいなくなった結果そうなるみたいなはいもうですしなんかどっかでやれませんでしたっけなんかもうこのバグ結局直せませんみたいなえーあれ馬娘違うなんだっけなんかのそうし上げであったんですよね不具合があってで直せなくてそのまま左衆したとかそうなんだえーまあそれは結局人間でもAIでも変わんないなとは思いますうんうんうん今も結局そのPMの人がいたとしてエンジニアじゃ解決できませんうんどうすんだうん
30:58
追加でバグに人を投入するならお金もかかりますし直せないなら直せないでじゃあサービス終わらせるかっていう判断するだけじゃないですかそんなクリティカルなやつだったのそれって
31:14
そうなんじゃないですかでもこれも別に噂ですけどねメンテ入って長期メンテ入ってそのままメンタッチだったとかって気がするそれは闇感じるな確かにラッキーだったかもしれないですけどね闇を通ってたぜって話かもしれないですけどこれを機にやめちゃうかってでも別に人間でもねよくわかんないっすってことはあり得るですよねあり得るなーっていう
31:46
回でございましたありがとうございます本質的な複雑性と偶発的な複雑性じゃあ困難かどっちも困難ですねっていう考え方は整理できましたわなるほどって思ったあとやっぱねノートブックエレムすげーわ使い方すごいですねノリさんこっちから質問していくのめっちゃいいわやっぱ
32:11
本とかめっちゃそうオライリー本特にありがたいPDFこれ撮ってるじゃないですかこうやってポッドキャストででもポッドキャストでこれ聞かれたらやばいなってやつを先にジェミオンに聞いておくって言い直さなくていいっすねすっと入ってきちゃったわ何も気にならなかった突っ込むべきだったわ失礼しました練習が必要ですなるほどねめっちゃいいなめちゃくちゃ整理できた
32:41
なんかあのAIが作った文章って語るじゃないですかあるで僕は分かんないんですけどどうやら分かる人はこのブログ記事AIで書いたなとか分かるらしいんですよポッドキャスト分かんないんじゃないかなと思っててなぜならAIからのカイチからのエピソードになるじゃないですかあーなるそこでなんか言い回しとか変わるんでそれゆえなんかその
33:10
記事書くちょっとAI書いてるなって気にする層が少数払ったらまあ関係ないんですけどポッドキャスト的にはすごいAIめちゃめちゃいいですね確かにあとね昨日これは発見には繋がんなかったんだけどもしかしたらあるかもなって思ったのはこれソース突っ込むじゃないですかノートブックLMってそのソースに銀の弾丸とこの論文となぜか間違えたのかひまプロの
33:42
オブシディアンでテッテルカステンの話した時の音声データがアップロードされてて
33:46
それに気づかずに音声概要を生成したんですよそしたらなんかポッドキャストみたいなの生成されるじゃないですか音声ですねその最初の冒頭聞いたら学習を加速させる方法とあとはソフトウェア開発における難しさこれって一見全然違うように聞こえるんですけど奥の方では繋がってるものがあるんですよって導入されて本当に?ってなってノー
34:14
ノートブックエレーブそう言いますよね一見関係ないように見えるんですけど奥で繋がってるんですねとか言いますよねこれによって本当に繋がることもあるんじゃないかと思って
34:28
全然関係ないものがっていうミックスを楽しめるなって思いました楽しみじゃああれなんすね我々のエピソード溜まってきたじゃないですかあれなんか関係ないと一見関係ないエピソードをガチャンってすると実は新しいエピソードが台本ができるかもしれないやつができる可能性あるそれ楽しいんすねだいぶね無限に生成できますよねそれね無限にいけるエピソード
34:55
今までエピソードをね我々ポッドキャストなんかハイペースで上げてきましたからだいぶ組み合わせは今何個あるんだ360から2を取れるから360PにCですかコンビネーションでそれを3つ組み合わせようとかもありですよね3つ組み合わせもあり無限にいけるなもんっていうねエピソードとして持ってきてもらって
35:25
関係ないように見えて奥の方が繋がってるんですよってその導入でそうなんですねって結論まで聞かなかったんですけど早くちゃんとしたバージョン聞きたかったんで聞く意味ないからなそんなの
35:42
ありがとうございます締めていいですかねハッシュタグひまじんプログラマーでSNSのXでフィードバック募集してますので銀の弾丸はないエピソードお願いしますあと読んでほしい論文とか健康にも銀の弾丸ないですからね多分ね
35:58
あるのかなあるんです1個だけあるんですこれだけやったらいいみたいなこの白いカプセルを飲むと怖い怖い怖い怖い絶対にやっちゃダメですよそんなことはいあとはポッドキャストの説明欄からGoogleフォームで番組への要望・感想・質問お待ちしてますスラックのオンラインコミュニティひまプロダウンは質の参加リンクもありますのでそちらもお願いしますお願いしますお願いします各種ポッドキャストプラットフォームでのフォロー・高評価もお願いします励みになります待ってますはいではまた次回バイバイバイバイ
36:28
やめて!ラーのバグ侵入の特殊能力でマスターザブランチが焼き払われたら闇のスパゲティコードと密結合しているじゅんぺうちの心までクラッシュしちゃうお願い死なないでじゅんぺうちあんたがここでクラッシュしたら戦法との契約はどうなっちゃうの?ソースコードはまだ修正の余地があるここを耐えればコードを納品できるんだから次回納期間に合わずデバッグスタンバイ

0:00 37:00