  |
はてなキーワード:律速とは
----
「My Job Went ToIndia」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went toIndia :オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は2006年です。
かいつまんで話すと、インターネットが整備され、輸送コストがほとんどかからないソフトウェア開発では、アメリカのエンジニアは給与の面でオフショアに歯が立たない、だって、1/10の給与でインドのエンジニアは働くんだぜ？という本です。
そうした、価格競争力で負けるアメリカのソフトウェアエンジニアは、如何にして今後サバイブすべきなのか、という本になっています。
（普通に面白いしAIコーディング時代に通づるものがあるので復刊を希望したいところですが、まあ直球過ぎる題名を何とかしないと再販は無理でしょうな）
そして、JTCや外資問わず、過去にオフショア開発を経験された技術屋のみなさんははてブにも多く生息されているでしょう。
では、ジュニア開発者は不要になりシニア開発者のみになって、いまのソフトウェア開発は主に安い給与で働いてくれるところに遠隔で作業してもらって、レビューだけすれば良い環境ですか？
そうはなっていません。なぜでしょうか。
さて、今普通にXと連動する中古品売買プラットフォームを開発しようと思ったら、どうやってつくるでしょうか？
この文脈に埋め込まれたいくつもの情報「今」「普通」「連動」「中古品」「売買」「プラットフォーム」「開発」を解釈し、すり合わせ、未来の運営者も含めた全員に伝えるためのコストが、コミュニケーションコストです。
そうなると、「ちょっと良い感じにラフでいいからプロトタイプ作って持ってきてよ」で話が通じるのは、受注者マインドがしっかりした日本の受託開発現場の精鋭たちになるわけです。
テストケースだけを通過するように、内部テーブルを持たせた関数を大量に持ってこられてレビュー時に頭を抱えた経験が無いひとは、とても幸運なのです。
とは言え、これは何も文化の違いに起因するだけではありません。仕様とは、環境によって定まるものだからです。
例えば、うるう年判定の関数は、1581年以前をエラーにしますか？1873年以前をエラーにしますか？（ヒント：明治六年）
テスト駆動開発、古い言い方で言えばテストファーストの考え方は、成功したすべてのプロダクトで例外なく、ただの一つの例外もなく、必ず最初から取り入れるべきだったものです。
品質は最後に振りかける粉砂糖のようなフレーバーではなく、最初から設計に組み込むべきだからです。
ありとあらゆる趣味において、最初から良いものを使えば時間を無駄にせずに済んだ、と言われるような初期投資の大切さが説かれます。
果たして本当でしょうか？
そうです、その趣味にハマって生き残りサバイブした人から見れば、過去にその時点で投資をすべきだった、というのは正しいのです。
その趣味にハマれなかった人からすれば、少ない投資で自分に合わないことが分かったという合理的な選択であることと矛盾しません。
そのため、全ての失敗したプロダクトは、テストケースを書く時間でプロダクトを作り上げて、さっさと世に問うべきだったわけです。
少し昔話をしますが、オフショア開発において重要なのはドキュメンテーションとテストケース、それにレビューでした。
他の部署で失敗しつづけていたオフショア開発のやり方は、端的に言えば"教化"でした。
具体的には書けませんが、グッとお安い単価の国に出す仕事を、日本の会社に出すのと同じようにすべく、相手の会社のメンバーを教育して仕立て上げるブートキャンプの仕組みを作り上げていました。
発注側を変えずに済むように受注側を教育して、日本の会社に出すのと同じように単価の安いところに出せたらお得ですよね？でもこれは必ず失敗します。
何故か。だって、日本の会社と同じように働けるようになったら、日本の会社に就職するじゃないですか。少なくとも価値は上がったんだから単価を上げるように交渉しますよね？
結局のところ、当初言われていたような劇的な節約にはつながらないわけです。それなら下手に転職されるよりも自前で現地工場でも立てて地元に貢献しつつ雇用を創出した方が喜ばれるし持続可能です。
小なりとも成果が上がった方法は、フィードバックを相手ではなくドキュメントにした場合でした。
例えば先ほどの例で言えば、テストケースは通るが意図したコードにならなかったとき。
「普通はこういう意図でコードを書くから、テストケースを通るにしても、関数は次からこう書いて」というのが、相手に対するフィードバック。
「関数を書く前に、関数の意図をコメントで残して、レビュー時にはそれを見ましょう」というプロセスの修正が、ドキュメントへのフィードバック。
こうすると、担当者が退職していなくなっても、次の担当者はその方法を参考にすれば良いわけです。
これ、何かに似てませんか。現在のAIコーディングのベストプラクティスと呼ばれるものに非常によく似ているんです。
つまり、オフショア開発というのも、設計と実装が分離できるという前提に立って動いていたんです。
そして、実装しながら設計しても問題ないとする場合、それは「技術的な問題」ではなく「組織構造」に起因します。
つまり、プロダクトの構造を分割して、オフショア開発側に設計と実装とを委譲して、実装しながら設計を変えてもらうことが許容できるのは、契約や責任分界点、輸出入の法規を含めた法務の領域です。
少なくとも当時、諸々をクリアにして相手側にプロダクトの一部を荒い設計と共に切り出して、コーディングしながら再設計してもらい、テストケースを完備したコードとドキュメントを共に完成までもっていってもらったことは、大きな成果であったはずです。
（当時日本側と仕事をしたという実績があると大きな実力があるとみなされたと聞いたので、今はより良いところで良い仕事をされていると思います）
（あと、コミュニケーションコストと輸出入の関連法規が複雑だから）
少なくとも、納期までに契約したこれを納品してください、という枠組みの中では、実装作業だけ切り出すことはできない、というのが教訓として残ったはずです。
少なくともあと数年、場合によっては10年スパンで、日本ではほとんど変わらないと予想しています。
これは技術の話ではなく組織構造や、もっと言えばお仕事の進め方と契約の話だからです。
そうは言ってもジュニアエンジニアの簡単な仕事が減って成長機会が失われているのは事実では？と思うかもしれませんが、そもそもの前提が誤っています。
未経験（弱経験）者を雇って戦力まで鍛え上げる必要があるなら、AIに仕事渡してないでそのジュニアエンジニアにやらせるべきなんです。
ジュニアエンジニアとAIと両方にOJTさせて、その違いをレビューの場でフィードバックしてジュニアを育てるわけです。
もし、そんな時間は無いというなら、元々ジュニアエンジニアをOJTで育てていたというのは幻想です。
（たまに、失敗が経験になるとして、会社に損害を与える方法でジュニアを"教育"しようとする人がいますが、商習慣的にも信義則違反ですし言語道断です）
シニアエンジニアだけで事足りるとしてジュニアエンジニアを雇わなかった企業は、シニアエンジニアが抜けてガタガタになります。
これは中核エンジニアがゴッソリやめた会社が傾くなんて言う話で、昔からそうです。（たいてい、もっと人雇ってくれ待遇上げてくれみたいな悲鳴を圧殺した結果だったりします）
昔から、中堅がやれば手早い仕事を新入社員にやらせて鍛える、その代わり質は悪いし時間もかかるしフォローも必要だったわけでしょう。
AI時代が到来するとしても全く同じです。AIが出力するコードレビューで悲鳴上げてる場合じゃないんですよ。
レビューできるシニアエンジニアが足りなくなると予想されるなら、当然、ジュニアエンジニア雇ってレビューできるようにする必要があるんです。
そしてそれは、技術的な問題点ではなく、組織的・経営的な決断です。
国産LLM開発の文脈でもそうなんですが、ハードウェアの進歩を無視して話をする方が多いのが気になります。
現時点のコンピューターパワーは、10年後には手の届く価格になる可能性が十分高く、もっと言えば20年後には個人が所有する可能性すらあります。
いまから20年前の2005年は、Youtubeが誕生した年です。その時に、誰もがいつも手元にビデオカメラを持ち、即座に動画を世界に公開できるようになるとは思っていなかった頃です。
今もそうだと思いますが、ある分野で必要な性能にはもう十分という期待値があり、10年経てばある程度大きな会社の部署単位で現在最先端のコーディングAIがローカルで動くようになると想像するのは容易です。
そうなったときに、果たして営利企業が、エンジニアを育成するというコストを支払うかといわれると、疑問です。その時点で今後のリアルなコストと比較対象可能になるので。
だって、筆耕担当者とか、清書担当者を雇わなくなった企業って、多いでしょう？
My job went toAI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
酔っ払ったので色々吐き出そうと思う！
10年近く勤めた某SIerを辞めて、1年くらい一応無事に過ごしている。
小説の設定を練るときのフォーマットを作って、割と納得いくものになりました。
創作で悩みがある人の助けになればと思って、具体例や書く時のコツと一緒に公開します。
上から埋めていくと本文を書けるくらいにイメージが固まってきて、心穏やかに小説を書けます。
小説って書くのに時間かかるから、勢いで書くと書いてる間に飽きるし、考えたこととか忘れて投げ出しちゃう。
設定を練ろう！
ちなみに、小説の実力は趣味程度だから、上手な人は優しくアドバイス貰えると嬉しいな。
追記: みんなブックマークありがと！記事に影響を与えたコメントは後ろで謝辞してあるよ。
====以下、フォーマット====
例:ゾンビさんは在宅
例:
感染した人の思考力・感覚レベルが低下してしまう「Zウイルス」が突如流行し、みんなが外出を控えている。
【主人公の自宅】
H道某市、会社から徒歩5分のところにあるマンションの1階。間取りは1K。
ゲーミングチェアと可動式デュアルディスプレイで快適にリモートワークできる。
例:
根黒 幽(ねくろ ゆう)
ちょっと内向的な新社会人。声は暗いが目はきらきら。経理部に配属され、OJTが終わった直後にウイルスが流行し、在宅勤務を余儀なくされた。
例:
【怪しい経費の流れを発見？】
営業経費の仕分け処理をしていたら、このリモートワークのご時世に出張費が昨年の同月と全く同額の営業さんを発見。
【久しぶりの出勤】
街は危ないので武装。
オフィスに着いたところ、営業さんが殴りかかってきて戦闘になる。
例:
Zウイルスに感染した場合はお近くの宗教施設でお金を払うと蘇生してもらえる。
物流はドローンを使って各家庭のベランダまで送ってもらう方式が普及。
土木工事などはお坊さんがお経を唱えてゾンビ避けをしている間にバリケードを作ってから作業する。
例: ほんとは図で書いたほうがいい
根黒→先輩: カッコいい
例:
根黒OJT修了
【怪しい経費の流れを発見？】
例:
例:
1.ニュースで本日の感染者数を紹介(世界観を簡単に説明するための情景描写)
2. 朝のルーティン(朝食やぼやきなど、根黒の性格が分かるような心情描写)
3. 勤務開始連絡後、レビュー対象の経費申請を先輩から渡してもらう(先輩に対する尊敬や経理の知識に対する不安などの心情描写)
なるほど！
目的とゴールがあると、書くべきイベントの取捨選択に便利だね。ありがとう！
増田はいつも感覚でイベントを取捨選択してそれを書ききったら終わりにしてるんだけど、これがあると迷わないね。
フォーマットの更新版を作ってコツが集まったらまた記事にしようかな。
入れるとしたら舞台設定や登場人物が明確になった後かなという気がする。
ゾンビが人を襲う場合、理由知りたい派なんだよね（ポピュラーに食うからとか、ゾンビの本体は菌なので傷付けて感染させることで疑似的に繁殖してるとか）。
ありがとう〜。
こういう感想を小説書く前に100分の1くらいの労力で貰えるのが設定を書くメリットの一つだよね。
言われてみたら気になったから、世界観詳細の例に追加しといたよ。
趣味に合うと嬉しいな。
ありがとねー。
こっちの方にもコメント反映したよ。
結晶の構造みたいなもの。リスト構造とか種類があるが、元素のように新規に人類が新規に発見するのは困難になりつつある。
【アルゴリズム】
たとえば黒鉛は炭素の同位体であるダイヤモンドに変換できる可能性があるが、その変更プロセスは多種多様である。コストやエネルギー効率のためにベストな方法をチョイスされるように、計算量という律速段階のようなもので比較される。
1mol が 6.0e23 個の原子と同じように、1バイトは8ビットである。バイトにするメリットは、英語圏だと 1バイトも有れば日常で使う文字はコンプリートできるのだ。
計算機で使われる浮動小数点数は実は実数ではない。たとえば、0.4f - 0.3f は 0.1f でない。ただし、0.5f - 0.25f は 0.25fである。
【オブジェクト指向】
フッ素分子（F2）を作ろうとした努力をプログラミングでもやろうとしたもの。
【アスペクト指向】
ポインターをインターセプトするための道具。電気泳動するためのツール。
【オライリー】
【インフルエンサー】
錬金術師（対価はカモの財布）
【JAVA】
【Ruby】
Al2O3。
【Perl】
Pearl でない。
テロリズムというものの正体っていうのは、高学歴といった少数のエリートが情報の秘匿化で「美味しい思いができた」時代の名残りなんだよ。なんと言っても、鉄砲玉を除いて、テロを起こす連中は「テロで死なない」だろ。死ぬのは、無学な『身内以外』なんだよ。テロリスト集団は、情報格差を使って『良い思い』をするために集うの。テロは、その歪なものを作り出すために利用された『結果』であって、その結果を期待したくなければ「テロリストにミカジメ料を払う」という方法で回避するしかない。じゃあ、どうやって？
テロリズムというのは、マスメディアという情報の律速段階が存在した時代の名残りであって、マスメディアが自己の存在理由がために、テロリズムを活用して来たのだよ。頭の良い増田はピンとくるかもしれないが、その際たるのが朝日新聞だ。朝日新聞というのはゾルゲ事件をはじめとし、北朝鮮や韓国や中国に「自社のせいで被害にあった方々のために、わざわざお礼参り」をして、反日運動を煽ってきた。そうすると、朝日新聞が儲かり、日本が特定アジアに甘くなる、というゴールデン・サイクルが昭和の末期まであった。ネトウヨ・ムーブメントはここに起点する。ところが、平成の初期にインターネットができてしまって、謝罪で儲かる朝日新聞というループは消えてしまった。なんといっても、朝日新聞の「取材する→記事にする→輪転機を回す」ということよりも、twitter の方がスピードが速い。今という時代は、朝日新聞は間接的にテロをしても儲からないのだ。そうだとも、我々は「新聞を購読することで、テロリズムを養ってきた」のだ。テロリズムで「一気に赤化して、世界同時革命！」という方式は、もはや実現できない。そう、インターネットのせいでね。マスメディアは、テロリズムを活用して自社のプロダクトを売ってきたのだけど、もはや「民衆を動かす」という力を失ってしまい、テロリズムに必要な「（嘘の）姿、たとえばクメール・ルージュを『アジア的優しさ』と形容したような（嘘の）姿」を広げる力は、ひろゆきの「それ、あなたの感想ですよね？」という『２ちゃんねる』の出現によって、空気を読めないバカが「大虐殺の現場」をアップする時代に、価値を成さなくなってしまったのだ。
テロの時代に、死なない方法は「新聞を買う」ということでした。今は死なない方法は、スマホを持つことです。そして、テロに共感しそうなアホは可視化できないけど、アホは「スマホで自爆してくれる」ので、ちゃっちゃとデジタル・タトーを刻まれて、一生ひもじく暮らしてください。良かったですね、本当に。
申し訳ないがあまりにも突っ込みどころが多すぎて突っ込みきれない。そのレスも分かってない感を上塗りしてるだけだ。
まず学習に必要な計算量と推論に必要な計算量は違うということを理解するべきだし、ムーアの法則が律速になってからここ10年で計算量がどれだけ増加したか・それは何故なのかを知るべきだし、意味も分からず教師データを学習モデルに突っ込んで精度が良いとか悪いとか言う前に統計学の基本を勉強するべき。つうか「機械学習までは勉強した」ってなんだよ。何を勉強したら「機械学習を勉強した」ことになるのか全く分からないので情報量がない。まともに勉強してたらこんな言い方は絶対にしない。
統計学の勉強には東大出版会の「自然科学の統計学」や竹村先生の「現代数理統計学」あたりを読むといいだろう。線形代数をある程度分かってる前提だが。
今課題でペアでプログラミングしてるんですが、どうしても相方の人とのペースの違いや考え方の違いでもやもやしてしまいます。
例えば、プルリクが溜まってしまってそれが開発の律速になってしまったり、レビューでどっちでもいいようなことを辛辣な言葉遣いで指摘されたりすると正直イライラしてしまいます。
当たり前のことですが、個人で開発する分には全て自分でコントロール出来ることが共同開発だとそうではありません。
仕事だったら他人のコードを読むことも読まれることも沢山あると思うんですが、皆さんはそれで嫌な気分になったりすることはないんでしょうか？
また、もしそういう気分になるなら皆さんはどうやって折り合いをつけているのでしょうか？
数学もそうだけど、実は物理学と化学と生物学にも律速されてんのやで。以下順に説明するで。
【物理学】光の速さが30万キロpersecなのはしっているかい？よって、我々は高速を超えられない。ところで君のパソコンの周波数はいくらかな？3GHz と仮定しようか。するとどうだろう？1サイクルで10cmしか進めない。よって計算量は資源なんだ。もっと知りたければ「ハミングバードプロジェクト」でも読んてくれ。
【化学】主に信越化学工業とSUMCO が頑張っている。ネトウヨがフッ化水素酸についてうるさいのも半導体製造には必須だからだ。化学の進化なしに、計算機科学は存在しない。
【生物学】我々の扱うものは、人が作っている。人とは何か？生物じゃろ？よって、コードされているものには限界がある。つまり、バグとされるものは、人間の認識の限界から来ていると思わないかい？人工知能が偏見を持つのでなく、偏見があるから、人工知能が真似をしてしまうのだ。
と、まあ、こんな感じかな。とりあえず元増田には『数学＝IT』という発想はやめてもらいたいと思った。こんなんで答えになってるかな？
本体の導入コストが高い、かつランニングコストが高いという意味。
EUVはスズを熱して筒の先から水滴のようにして真空中に吐き出したのに対して、レーザーを当ててプラズマを作って励起、
そこから目的の13.5nmの波長の光を作る。EUVってのはその13.5nmの波長が極端紫外光って名前の略。
そのスズのプラズマから、光以外に大量のスズの粒子が飛び出てくる。
200W～250Wくらいのレーザーを当てているので、そのエネルギーが粒子に移っている。
粒子の中には高エネルギーを持ったものから、低エネルギーのものまで沢山ある。大きさもバラバラ。
半導体を作るためにはリソグラフィという虫眼鏡のように集光させる必要があるが、
EUVは通常の虫眼鏡のような集光レンズでは光が吸収されるので、鏡に反射させて集光させる方式を取っている。
プラズマから光が出る方向は、レーザーの当て方によって変えることはできるが、光が一番強い方向に、エネルギーを持った粒子が飛び出てしまう。
そうなると鏡が粒子によって削れてしまう。これが装置の寿命につながる。
真空をひいているので、ミラーを交換するのに大気圧に戻しして、再び真空にするといった時間的なロスが発生する。この間ウェーハを流すことができず、収益悪化につながる。
ミラーと言っているが、日常品で使うようなアルミのミラーではなく、EUVを反射させるためのもの。自分が知っているのはモリブデンを多層膜にしたもの。他にもあるかもしれない。
ミラー以外にも長時間使っているとスズが堆積していくので、真空度が下がらないといったことが起こる。
半導体を作るうえでnmのゴミがあると不良品になるが、シリコン側にも影響する。
大量に落ちる所は避けてウェーハを置くように、複数のミラーを置くことになるが、ミラーでの反射回数を増やすと、光量が足りなくなる。
また距離を離しても光量が減る。
よって光源とウェーハを近づけることになるが、プラズマからエネルギーを失ったスズ分子がウェーハに落ちる。
この問題に対しては、ウェーハに保護膜をつけるといった対策方法が取られる。もちろんこれがコストに響く。
保護膜のデメリットはなにかというと、保護膜でEUVが吸収されてしまう。
保護膜なし場合は200Wのレーザーで済むが、保護膜ありだと250W必要となる。
レーザーを高出力にすると、先ほどのミラーが削られる速度が上がる、レーザー自体の寿命が縮まるといったデメリットにつながる。
EUVで利益を上げられないので、グローバルファウンドリーは導入前に撤退した。
EUV使って利益を上げられるのは、現時点ではAppleのような世界中を寡占しているようなメーカーの依頼品のみ。
それこそ数億の大量生産でようやく元のコストが高くてもやっていける。
そんなメーカーは限られているので、TSMCのように複数のメーカーから依頼を受けているファウンドリーでないと導入が難しい。
最先端の微細ロジックが不要な所がある。Arduinoのような趣味用のマイコンでもいいし、その辺のオーディオや自動車、ゲームセンターのアームの制御など、
処理速度が不要な部分がある。
例えばモーター制御だと、モーターの回転数の上限はマイコンのCPU性能で律速しない。ベクトル計算が必要だとしても、最先端のプロセスを使ってコストが上がるよりも、
少し古いプロセスで製品コストが上がらない方がいいといった分野もある。
毎年や2年ごとに価格が高くなっていくスマホのような製品ばかりではない。
