  |
はてなキーワード:プラクティスとは
----
「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 として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
https://b.hatena.ne.jp/entry/s/frantic.im/remix-3/
機能が存在すると "使い倒さないといけない" or "使い倒さないなら一流でない" と考える "謎の集団" が存在して、そういう声に流されてるからv18以降の機能追加に拒否反応を示してるんじゃないの
あるいは "ベストプラクティスは義務である" みたいな謎の強迫観念を持っているとか…
Next.jsを勧めるわけではない(自分は仕事ではNext.js、プライベートはRemixv2ユーザーである)が、Next.jsを使用した上でもv18以降の機能の使用はほぼ全てオプションだよ
ただ、Reactの開発がNext.jsに毒されていて本筋から外れている感じは否定しない
ここから来る害があるとしたら、非Next.jsユーザーからするとv18以降のReactは特に発展していないということだろう
いいえ、関数の引数が多すぎる（「Too Many Arguments」）問題の解決策としてConfigクラス（またはパラメーターオブジェクト）を使用すること自体は、一般的にアンチパターンとは見なされていません。
関数の引数が多すぎる状態は「コードの臭い（Code Smell）」の一つとされており、Configクラスなどの単一のオブジェクトに引数をまとめることは、その問題を軽減するための一般的な解決策です。
| メリット | 説明 |
| 可読性の向上 | 長い引数リストはコードを読みにくくしますが、関連する引数を一つのオブジェクトにまとめることで、関数シグネチャ（定義）が簡潔になり、何を受け取っているのかが明確になります。 |
| 引数の順序間違いの防止 | 位置引数が多いと、呼び出し側で引数の順番を間違えるリスクが高まります。オブジェクトとして渡せば、プロパティ名でアクセスするため、この種のエラーを防げます。 |
| 変更容易性の向上 | 新しい引数が必要になった場合、関数のシグネチャを直接変更する代わりに、Configクラスに新しいプロパティを追加するだけで済みます。これにより、関数の呼び出し元すべてを変更する必要がなくなり、マージの競合も減らせます。 |
| 引数のグループ化・関連付け | 論理的に関連する引数（例：`name`, `lastname`, `city`, `country` → `Address`オブジェクト）をまとめることで、その意図やコンテキストが明確になります。 |
このような引数をまとめるためのオブジェクトは、Data TransferObject (DTO) やParameterObjectとも呼ばれます。
Configクラス自体が問題なのではなく、そのクラスの使用方法や、そもそも引数が多いという事実がより深い設計上の問題を示している場合があります。
引数が多い関数は、しばしば単一責任の原則（Single Responsibility Principle / SRP）に違反している大きなクラス（Large Class）や長いメソッド（Long Method）の兆候であることがあります。
Configクラスを作っても、根本的な問題は解決しない：引数をクラスにまとめただけで、関数やクラスが多くの異なる責任を持ちすぎているという根本的な問題は解決しません。
対処法： この場合、Configクラスを作成する前に、関数が実行している処理をより小さな責任を持つ複数の関数やクラスに分割することを検討すべきです。
Configクラス自体が、もはや数十のフィールドを持つ巨大な「すべてを持つクラス」になってしまっている場合、それは設計上の問題です。
対処法： その巨大なConfigクラスのフィールドを、論理的なサブグループ（例: `DatabaseConfig`, `NetworkConfig`, `LoggingConfig`など）に分割することを検討します。
引数が数個（例: 2～3個）しかない関数に対して、引数をまとめるためだけにConfigクラスを作成すると、不必要なオーバーヘッドと複雑さが増すだけで、メリットが薄い場合があります。
対処法：Configクラスの使用は、引数の数が多すぎて（一般的に5個以上が目安とされることが多い）管理が難しくなった場合に限定するのが賢明です。
結論として、関数の引数が多すぎる問題をConfigクラスで解決するのは、有効な設計パターンです。
ただし、その解決策を適用する前に、「なぜこの関数はこんなに多くの情報が必要なのか？」と自問し、それがより大きな設計上の問題（SRP違反など）の単なる症状ではないかを確認することが、クリーンなコードを書く上で最も重要です。
例えばオタクの臭い問題で言うと「オタクは風呂に入れ」 「オタクは運動して汗を流せ」は長年折に触れて話題になっていたけど「オタクは新しい服を買え」は中々話題にならなかった。ここ２、３年(もうちょっと前か？)くらいでようやく前述の２つとセットで語られるようになった印象がある
定期的に服を買い替えている人間は「長く着られた服が臭いの原因」であると思い至れない。服を買い替えていない当事者(と近親者)だけが「服が臭いの原因なのでは」と気付く事ができる
当事者でない人間が自分の知識の範囲で問題の原因を探ろうとするので、ベストプラクティスとして語られているものであっても個々の問題を解決するには至らなかったりする
恋愛工学ってのも同じなんじゃなかろうか
■ はじめに
サイバーセキュリティの歴史を振り返ると、かつては「脆弱性を隠すことで攻撃から守る」という考え方が主流だった。しかしこれは、ユーザーやシステム管理者が自己防衛する術を持たないという重大な欠点を抱えていた。その反省から、現代のセキュリティ・パラダイムは「責任ある開示（Responsible Disclosure／CoordinatedVulnerability Disclosure）」へと移行している。すなわち、脆弱性は一時的に調整の下で管理されるが、最終的には公開され、社会全体の防御力を高めることが前提となる。
https://www.itmedia.co.jp/news/articles/2509/09/news110.html
2025年9月、経済産業省とIPAが発表した声明は、一見するとこの流れに沿ったもののように見える。しかし、その実態を検証すると「古いセキュリティ観」への逆行になりかねない危うさを孕んでいる。
■ 「公開前の適切な調整」という建前
今回の声明は「脆弱性情報は、修正や検証が完了するまで不特定多数への無秩序な公開を慎むべき」としている。これは表向きにはもっともらしい。攻撃者に悪用される前に関係者間で修正を進める、というのは責任ある開示の基本に合致しているように見える。
しかし問題は、この「適切な調整」の実態が 無期限の放置 に化ける可能性である。
•企業にとって、非公開であればセキュリティ対策の優先度は低下しやすい。
• 「対策中」という名目の下、実際には数年単位で放置される危険がある。
• その間に攻撃者が独自に脆弱性を発見すれば、利用者は情報も対策手段も持たないまま被害を受ける。
これは、かつて批判された「セキュリティ・スルー・オブスキュリティ」の構造そのものである。
海外ではこの問題を防ぐため、公開期限を設けるのが常識になっている。
•Google ProjectZero：発見から90日で公開。企業が修正していなくても原則開示。
• CERT/CC（米国）：45日ルール。対策が遅れても一定期間で情報公開。
• ENISA（欧州）：協調公開を推奨しつつ、期限付きでの開示を前提。
つまり「調整期間は有限である」ことが、責任ある開示モデルを機能させる前提条件なのだ。
■提言：逆行を避けるために
今回の日本の声明が本当に現代的パラダイムに沿うものとするなら、次の仕組みが不可欠である。
1. 明確な公開期限（例：90日）を設けること。
3. 段階的な情報公開（「報告済み」「調整中」「修正中」など）により透明性を確保すること。
これらがなければ、「適切な調整」という建前の裏で、実態は非公開による放置――すなわちオブスキュリティの復活に他ならない。
■ おわりに
情報を握りつぶして安全が保たれる時代はすでに終わった。もし日本が責任ある開示の理念を本気で受け入れるのであれば、調整と公開のバランスを「期限付き透明性」の仕組みで担保する必要がある。そうでなければ、今回の声明は「前進」ではなく「逆行」と評されることになるだろう。
なんかムズムズするなベストプラクティスの対義語っぽいけどなんだろうと思ってたけどアンチパターンのことか。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250728172448# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaIcz0gAKCRBwMdsubs4+SEHNAP4qltMiGRD5gnhFCTWUKQ/8hyLM1bmk2l3veXZ6kgU0NwD+OPsN9Q6wdzbNtzUFXO03yVwNNOCMabVo3rJ/fRu2YQI==qm58-----ENDPGP SIGNATURE-----
CSS（カスケーディングスタイルシート）は、HTMLで構築されたウェブサイトの見た目を整えるために不可欠な技術です。CSSを使うことで、文字の色やサイズ、背景、レイアウト、余白、アニメーションなどを自在にコントロールできます。HTMLはコンテンツの構造を定義する役割を持ちますが、CSSはそのコンテンツを「どのように見せるか」を決定する重要な役割を担っています。たとえば、同じHTML構造でも、CSSの適用方法によってデザインの印象をまったく違うものにできます。
CSSでは、セレクタを使ってHTML要素を選び、プロパティと値の組み合わせでスタイルを指定します。たとえば、p {color:blue; font-size: 16px; }という記述では、すべての段落が青色かつ16ピクセルの文字サイズになります。また、classやidセレクタを使うことで、特定の要素だけにスタイルを適用することも可能です。こうしたセレクタの使い方を理解することは、効率的なスタイル設計に不可欠です。
さらに、CSSはレスポンシブデザインにも大きな役割を果たします。メディアクエリ（@https://mavenanalytics.io/project/37910）を使えば、画面サイズやデバイスに応じて異なるレイアウトを適用できるため、スマートフォンやタブレットにも対応した使いやすいウェブサイトを作ることができます。現代のウェブ開発では、このモバイルフレンドリーな対応がとても重要です。
また、CSSには再利用性を高めるためのテクニックも多く存在します。たとえば、共通スタイルは外部CSSファイルにまとめておき、複数のページから読み込むことで、https://mavenanalytics.io/project/37905一貫性のあるデザインを保ちつつ管理を簡単にすることができます。style.cssなどのスタイルシートを用いることで、HTMLファイルがすっきりし、保守性も高まります。
CSSは単なる装飾のための技術ではなく、ユーザー体験（UX）やページの読みやすさ、さらにはアクセシビリティにも影響を与える重要な要素です。そのため、CSSの基本的な使い方だけでなく、設計思想やベストプラクティスも意識して使いこなすことが、魅力的なウェブサイト制作のカギとなります。
※なんか頭のなかのもやを発露しただけの、駄文です。全部自戒です。
最近、生成AIの普及で質の低いコンテンツがめちゃくちゃ増えてる気がする。新しいツールやテクノロジーが出るたびに、表面的なチュートリアル記事が量産されて、検索結果がノイズだらけになってるよね。一部の専門家だけがアクセスできた情報を一般化すること自体は良いことなんだけど、問題は内容の薄さ。公式ドキュメントにAIで質問すれば、もっと適切で完璧な情報が得られる時代に、わざわざ劣化版のチュートリアルを作る意味ってあるのかね。
求められてるのは基本的なセットアップ方法じゃなくて、それらを使った独自の実践例や実験的な活用事例だと思う。そこにその人らしさや独自の価値が生まれるんだよね。
AI技術の進歩で、エンジニア界隈は今めちゃくちゃカオスな状態になってる。AIに批判的な既存エンジニア、AIコーディングを全面的に受け入れる層、AIによる新規参入者への反発、日々変わるベストプラクティス、短期間で陳腐化する専門性など、色んな思惑やイデオロギーが交錯してる。
それに、それぞれが住んでいる生態系やクライアントの特性、業界特性、背景、生まれた背景、国や言語なんかによって全然違うじゃん。例えば大企業がクライアントの場合は、当然そうじゃないところよりも色んな要素が多くなって複雑性が高い。一方で、そうじゃないところは煽り合戦だったりストーリーテリングみたいなのが大事だったりする。昔からよくある、ベンチャーvs大企業みたいな構図。だから、それぞれがいるポジションが全然違う中で、ああだこうだ言っても正直意味がない。そこで議論する前に、まずお前らのコンテクストをエンジアリングにしろよって思うわ。
生成AIブームで色んなプレイヤーが参入してるけど、現状を冷静に見ると面白い構造が見えてくる。今の生成AI界隈のプレイヤーって、大体初級レベルの情報商材・教育事業者、中級レベルの教育系AIサービス、生成AIを使った新規事業・起業家みたいな感じに分かれてる。この中で、生成AIネイティブで既存の業界課題を解決する形のサービスも一定数いるんだけど、圧倒的にやりやすくてレバレッジが効いて短期間で利益を取りやすいのは、まだAI利用の環境すら整っていないところの教育分野なんだよね。だから、そういったものへの参入が多い。想像したらわかりやすいけど、まだChatGPT使ったことない人に、ChatGPTの初級編の使い方を教える感じ。使った人はすげええええええってなるじゃん。
一方で、本当にAIや画像生成なんかを使ってユーザーを獲得して収益の上がるサービスを日本国内や海外向けに作っていこうとすると、そこには大きなハードルがある。そこにチャレンジしてる方々もいらっしゃるので、それは本当にリスペクトするし応援してる。なるべくサービスも使うようにしてる。でも、そうじゃない人の新規参入として、AIネイティブなサービスを作るのは本当に難しくて色んな変数があるので、プロダクションレベルで提供するのは困難。だからこそ参入が取りやすい教育系のサービスやコンテンツ販売、また今の時期だとAI動画を使ったYouTubeチャンネルみたいなところが参入しやすいので、そこのプレイヤーも多くなってしまう。エコシステムっていうのはこうして発展していく部分もあるけどさ、視座を高く持とうぜって。
そうすると、参入がしやすいものっていうのはあっという間に飽和してしまうので、そこに成功を求めて向かって行ってもあまり勝ち目がない。もちろん資本が大きい分には参入していって、そこのパイの一部をもらって売上を上げることができるかもしれないけど、微妙と言わざるを得ないかもしれない。何が言いたいかと言うと、AIを使ったネイティブなITサービス、純粋なITソリューション製品・サービスを作るっていうのは非常に難しい。BtoBの領域で言うと既存のワークフローがあったり業界特有の既存サービスがあったりするので、そういったもののプレイヤーたちがAIを組み合わせた方がむしろ効果が出やすかったりする。その業界ならではのAIサービスを0から作っていくような気概がないとそこは難しい。開発者向けのAIサービスっていうのは本当に世界中のエンジニアがある意味競合でもあり仲間みたいな状態なので、そこに挑戦する人々は本当に応援したい。
一方で、そうじゃない人の参入としては、やはり自分のバックグラウンドや強みもしくは隙間がある領域×AIみたいなところで勝負を探す方がいいんじゃないかと思う。その方が競合は少ないし独自の価値を付けやすい。それはWebサービスのみならず、自分のポジションやどの業界を見ようかって価値観の変容みたいなところも必要なんじゃないかと思うし、自分がどうすればレバレッジが効くのかみたいな観点でも有用になるのかなと思う。グローバルニッチって考え方がたびたび目にするけどそれだね。
あとは過去に投じた時間やお金への愛着が、変化の激しい時代では足かせになってしまう「サンクコスト」の概念は重要。これまでの思い込みや概念を一度見直す必要がある。これからは職種の細分化から「大統合」の時代になると考えてる。AIで一人ひとりのパフォーマンスが向上すれば、従来のような細かい職種分けじゃなくて、ビジネス系とバックエンド系、営業・マーケティングとエンジニアリングみたいな、もっと大きな単位での役割分担になるんじゃないかな。職がなくなるんじゃなくて、シフトするだけ。
個人で作る小さなサービスやアプリの多くは、既存のもので代替可能だよね。革新的に見えても、実際は誰かがやらなくても困らないものが大半。それよりも、たとえば日本独自の食文化や自然環境みたいな、時間をかけて積み重ねられた価値の方が、世界的に見てもユニークで重要だと思う。
ちなみに、インフルエンサーが作る情報商材についても思うことがある。彼らが何かコンテンツを作ったとしても、その情報はAIに聞くより古かったり、1ヶ月後には状況が全然変わってたりすることが普通にあり得る。そもそも作られた時点が半年前とかで、現在の状況とは全然違うってこともある。だから、そういうコンテンツに高いお金を払う前にAIに聞いた方がいいし、賞味期限が非常に短いってことは留意した方がいい。
良識のあるインフルエンサーやビジネスマンの人も言ってるけど、AIは自分が得意じゃない専門領域に掛け算して活用した方がレバレッジが効く。また、AIの情報を参考にするにしても、しょぼいティップスを紹介してる人をフォローするんじゃなくて、ちゃんとその業界の第一人者と言われる人たちを調べて、そういう人の評判も聞いて、それでフォローするべきだと思う。もちろん偏りすぎちゃダメだから、戦略的に複数のポジションの人たちをフォローしていくのは良いことだけど、偏りすぎたり変な信者みたいになってると、全く価値のない情報商材にお金を払ってしまって、結局コミュニティや情報商材の餌食になってしまうから注意が必要だね。
資本主義にはバグが多くて、短期的な利益追求が長期的な価値を破壊することがある。ダーウィンの進化論を誤用して「変化できるものが生き残る」って言う人がいるけど、実際は「多様な遺伝子を持つ集団の中で、たまたま環境に適合した個体が生き残った」っていうのが正しい理解。画一化は逆に脆弱性。
最近のSNSでは、他人のコンテンツを使った煽り投稿や、承認欲求を狙った浅いコンテンツが目立つ。コンテンツサービスとかでも稼げる方法として普通にアダルトな要素のコンテンツ販売とかが紹介されたりする。インプレッション＝ビジネスチャンスっていう構造上仕方ない面もあるけど、社会のノイズを増やすだけの行為は価値を生まない。カルチャー界隈でも、知的な議論や批評が重視されてきたけど、AIがその領域でも力を発揮するようになった今、「Deploy or Die」の精神で、考えたことは実際に製品サービスにしていく社会に説いていってくれ。そうじゃなくて、いい感じのフォロワーつけて、その中でワイワイやるなのなら、大きいことは言わんでくれ。
あと、これは完全に個人の主観なので悪気はないんだが、SNSのインプレッションを取るための傾向として、演者や自分の顔をデカデカと載せるのが増えてる。正直人間の顔を見たくない。何のコンテンツなのかわかるようにしてくれ。その中でお前の顔が写ってしまうのは仕方ないけど、毎回顔を載せたり煽ったりして、「これなら視聴者がクリックするんだろう」みたいなのを感じ取ったやつは、正直その時点で萎える。
「コンフォートゾーンを出ろ」みたいな話も正直嫌いだな。これも生存者バイアスがかかってる気がする。そういうことを言ってる人も、5年後10年後には完全にそのビジネス失敗することだってあるし、その一瞬の状態で生きてる人が言ってる場合も多いんじゃないかと思う。どちらかと言うと、コンフォートゾーンを出るとか競争だとか努力至上主義みたいなことよりも、単純に一人ひとりの好奇心を大事にしようって方がよほど説得力がある。周りを寄せつけないくらいの好奇心で掘れ。変に資本主義とか短期的な利益に流されないから、世の中的に面白いものが生まれてくると思うんだよね。考えてみろよ、賛否両論はあるけど、ジークアクスはコンフォートゾーンを出ろ論や資本主義を意識して出てくると思う？あんなの子供心と好奇心の産物だろ。まあ逆かもしれんがなｗ
一人ひとりができることが増えて、アクセスできる情報や知能レベルが爆発的に向上した今こそ、既存の構造を打破する新しい取り組みが生まれることを期待してる。変化の激しい時代だからこそ、本質的な価値とは何かを見極める目が大切だと感じてる。みんな他の人がやってることじゃなくて、おもろいことしようぜ。
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
根幹は、人間を自己完結した情報処理システムと捉える点にある。
システムは、外部からの入力を受け、内部で処理し、外部へ出力する一連のプロセスを絶えず行っている。
「静寂」とは、単なる音の不在ではなく、システムの目的遂行を阻害するあらゆる「雑音」が極小化された状態を指す。
ノイズは二つに大別される。
「静寂を手に入れる」という行為は、内外のノイズを能動的に制御し、システムが処理すべきS/N比を意図的に最大化するプロセスに他ならない。
この最大化がもたらすメリットは、単一の事象に留まらず、システムの全機能の最適化として現れる。
この技法が示すのは、自己というシステムの情報エントロピーを最小限に抑え、その内在的ポテンシャルを最大限に解放するための方法論である。
意識的に静かな場所に身を置き、静寂そのものを体験する時間を作る。
通知の完全オフ:スマートフォンの緊急性のないアプリ（SNS、ニュース、ゲーム等）のプッシュ通知を全て無効化する。
情報断食: 就寝前1時間や食事中、週末の半日など、一切デジタルデバイスに触れない「オフラインの時間」をスケジュールに組み込む。アプリの数を最小限に絞り、フォルダにまとめる。特に中毒性の高いアプリは削除する。
プル型への転換:SNSのタイムラインを漫然とスクロールする（プッシュ型）のではなく、「この情報を調べる」という目的を持って能動的に情報を取りに行く（プル型）習慣をつける。
時間と量を決める:ニュースやメール、チャットアプリをチェックする時間を決め、それ以外の時間は開かない。
呼吸瞑想: 1日5分でも良いので、静かな場所に座り、ただ自分の呼吸（鼻を通る空気、お腹の膨らみとへこみ）に意識を集中させる。思考が逸れたら、それに気づいて優しく呼吸に意識を戻す。
観察瞑想: 湧き上がってくる思考や感情を「〜と考えているな」「〜と感じているな」と心の中で実況中継（ラベリング）する。それらを評価・判断せず、ただ流れる雲のように観察する練習。
ブレインダンプ: 朝起きた時や夜寝る前に、頭の中にある心配事、タスク、アイデアなどを、構成を考えずに紙に書き出す。思考を外部化することで、頭の中が整理され、客観的に見つめ直せる。
シングルタスクの徹底:複数の作業を同時に行うマルチタスクをやめ、一つの作業に集中する。タイマーを25分にセットして一つのタスクを行い、5分休憩するポモドーロ・テクニックは有効。
意識的な呼吸:ストレスや不安を感じた時に、4秒かけて鼻から吸い、6〜8秒かけて口からゆっくり吐き出す腹式呼吸を数回行う。副交感神経を優位にし、心身をリラックスさせる即効性がある。
自然との接続: 週に一度でも、公園を散歩したり、森林浴をしたりする時間を作る。自然環境は、人間のストレスレベルを効果的に下げ、注意力を回復させることが科学的に証明されている。
身体活動:ウォーキング、ヨガ、ストレッチなど、穏やかな運動を習慣にする。身体的な緊張をほぐすことは、精神的なノイズの低減に直結する。
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
日中の生産性は、夜の過ごし方、特に「就寝」というクリティカルなタスクをいかに成功させるかにかかっている。本記事では、つい夜更かししてしまうエンジニアのために、早寝を「技術」として体系化し、再現性のある形で実践するための具体的な手法を探求する。これは精神論ではない。あなたのQoLと生産性を向上させるための、実践的なスリープエンジニアリングだ。
我々エンジニアにとって、夜は不思議な魅力を持つ時間だ。日中の喧騒から解放され、思考は冴えわたり、ゾーンに入りやすい。しかし、その魅力的な時間は、往々にして「早寝」という、人間の生存に不可欠な基本プロセスを犠牲にすることで成り立っている。
「リファクタリングが楽しくなってきた」
これらの探求心はエンジニアの美徳であるが、同時に我々を「睡眠負債」という深刻な技術的負債へと導く。本稿は、この負債を返済し、持続可能な開発（と生活）を実現するための「早寝」という技術に焦点を当てる。
早寝を実装する前に、まずは現状のアーキテクチャに潜むアンチパターンを特定しよう。
就寝前のスマートフォンは、まさに同期的なブロッキングI/Oだ。SNSの無限スクロール、動画プラットフォームの自動再生、チャットアプリの通知。これらは我々の意識というシングルスレッドを完全に占有し、本来実行されるべきsleep()プロセスへの遷移を妨げる。
深夜まで続くコーディングや問題解決は、脳を極度の興奮状態にする。ベッドに入っても、アドレナリンやコルチゾールといったホルモンがCacheに残り続け、CPUがクールダウンしない。shutdown -hnowを叩いても、プロセスが終了しないのだ。
「夜更かしの供」として注入されるカフェインやアルコールは、一見するとパフォーマンスを向上させるように見える。しかし、これらは睡眠の質という重要なmetricsを著しく劣化させる、誤った依存関係だ。特にアルコールは、入眠を助けるように見えて、実はレム睡眠を阻害し、睡眠のアーキテクチャ全体を不安定にする。
不規則な就寝・起床時間は、体内時計という最も重要なCronジョブを破壊する。毎日異なる時間に実行されるジョブが安定した結果をもたらさないのと同様に、不規則な睡眠スケジュールは、日中のパフォーマンスを予測不可能なものにする。
では、どうすればこれらのアンチパターンを排除し、安定した早寝pipelineを構築できるのか。ここではSleepas Codeの概念に基づき、具体的なプラクティスを紹介する。
毎晩、同じ手順で就寝プロセスを実行することで、入眠を自動化する。
-PC/スマホのシャットダウン: 最も重要なステップ。物理的に電源を落とすか、手の届かない場所（別のコンテナ）にdeployする。
- 入浴: 38〜40℃のぬるめのお湯に15分ほど浸かる。これにより深部体温が一時的に上昇し、その後の下降とともに入眠が促される。これはHot-swapならぬHot-bathによるクールダウンだ。
静的コンテンツの消費: 激しい思考を伴わない、静的な情報（紙の読書など）に切り替える。電子書籍ではなく、紙媒体が望ましい。
ストレッチ: 軽いストレッチで、日中のcommitで固まった体をreleaseする。
すべての準備が整ったら、ベッドという本番環境にデプロイする。余計な思考はgitclean -fdで強制削除し、呼吸に集中する。
例：「夕食後のコーヒーが原因だった」→「カフェインの摂取は15時までというSLAを設ける」
早寝は、単に体を休める行為ではない。日中の高いパフォーマンス、明晰な思考、そして創造性を維持するための、最も効果的で再現性の高い「技術」だ。
我々はインフラをコードで管理し、CI/CDでデプロイを自動化するように、自身の睡眠もまた、技術と工夫によってコントロールできる。今夜、あなたのwhile(true)なループをbreakし、持続可能なパフォーマンスを手に入れるための第一歩を踏み出してほしい。
Happy sleeping!
＊
だいわ文庫
＊
4.2/5平均レーティング: 5つ星のうち4.2つ星
前代未聞! 気鋭のコンサルが内幕を暴露した全米騒然の問題作! デロイト・ハスキンズ＆セルズ、ジェミニ・コンサルティングと、大手コンサルティングファームを渡り歩いてきた実力派コンサルタントが、自らとコンサル業界が犯してきた恐るべき過ちの数々を大暴露。「戦略計画」「最適化プロセス」「業績管理システム」……こうして企業は崩壊する。望ましいコンサルティング業務のあり方、クライアントとコンサルタントの正しい付き合い方を提唱する。
＊
【目次より抜粋】
はじめに御社をつぶしたのは私です
「数人のコンサル」が歪んだ流れをつくった
「確実にまちがっている」理論の数々
ほか
お得意の「人員削減」を自社で行うはめになる
ほか
ほか
正しく動くと評価されない
ほか
公正に見える「不公正」なシステム
ほか
ほか
一度の失敗が「致命的」になるシステム
ほか
■第七章 「リーダーシップ開発」で食べている人たち
ほか
コンサルタントの「使い方」
ほか
おわりに
＊
お客様はこの本について、以下のような評価をしています:ストーリーが爽快で、勉強になる良書だと感じています。コンサルの現実を追求した爽快なストーリーで、意外性があって面白かったと好評です。内容については論理的で、本質的な答となっている点も好まれています。また、著者の性格や人となりが表れているという指摘もあります。コミュニケーションについても、ツールは手段であって目的ではないことを再認識させる本だと評価されています。
システムエンジニア。社内システムの内製や開発会社と要件定義やスケジュール管理したりするいわゆる社内SE
昨今のAIの進化は日進月歩で寝て起きたら昨日学んだことが無駄になることも多い
職場もAI導入しているがセキュリティや内部情報の管理の為に巷で話題の技術にすぐ触れられないがそれなりに活用はできている
そんな中後輩がとにかくAI任せになるのだがとにかく雑でぱっと見でエラー分かるレベルだ。業務的にフルスタックな感じなので色んな分野を面倒見るがどの分野もAIに吐き出させその結果軽く動かして持ってくる。
別にAI任せは良いし今後はスタンダードだと思っているが、命令する側が知識無きゃAIは平気で嘘つくしゴミ回答でトークン無駄遣いする
そういう意味でドメイン知識や基本情報レベルのシステム知識はあった方がいいよと言ったが
と矢継ぎ早に言われてううんとなった
正直AIって自分で出来る人がすごく楽できて、いくらバイブコーディング言って初心者が二人三脚で作っても出来るアプリやサービスはその辺の技術書かUdemy課題レベル
そこから興味持って壁打ちでどんどん吸収するのは極々一部で大半は楽を覚えてシスアド以下で仕事した気になっちゃう
と氷河期世代のシステムエンジニアが心配しても流れは変わらないし今後どうなるんだろう。フルスタックで上流経験あっても若さ優先になるのかな〜辛いな
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 1166 | デジタルアドレス｜日本郵便株式会社 | lp.da.pf.japanpost.jp |
| 1159 | 教皇選挙を終えて -司教の日記 | bishopkikuchi.cocolog-nifty.com |
| 862 | 花王 ｜日本の住環境における菌の実態調査 | www.kao.com |
| 710 | チームラボよ、どこへ行く？ | matsuuratomoya.com |
| 639 | 【悲報】ガンダムジークアクス、鶴巻和哉監督(59)が乃木坂46にんほる為の作品だと判明して炎上wwwwww | www.anige-sokuhouvip.com |
| 586 | ソフトウェアエンジニアがHondaに転職して感じたこと4選 -Honda TechBlog | honda-techblog.hatenablog.com |
| 570 | コラム「今の生成AI市場って焼き畑農業っぽくない？（2025年5月時点の所感）」｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 | wa3.i-3-i.info |
| 539 | BIZUDPゴシックと99.99%同じだけど、数字が等幅の「帳票UDPゴシック」フォント公開 –プログラミング生放送 | pronama.jp |
| 526 | 川口市のクルド人 -河野太郎（コウノタロウ） ｜選挙ドットコム | go2senkyo.com |
| 512 | EXPO2025万博マニアックマップbyOpenStreetMap | k-sakanoshita.github.io |
| 498 | ボタンを「押下（おうか）する」という言い方はかなり昔から存在していた（文献引用つき） - StatsBeginner: 初学者の統計学習ノート | blog.statsbeginner.net |
| 464 | 郵便番号・デジタルアドレスAPI ｜郵便番号・デジタルアドレス for Biz ｜日本郵便株式会社 | guide-biz.da.pf.japanpost.jp |
| 456 | macOSSequoia (15.4 以降) で cal やdate を打つと出力がおかしい -id:onk のはてなブログ | onk.hatenablog.jp |
| 454 | 参政党 -sanseito- ｜新日本憲法(構想案) | sanseito.jp |
| 443 | 全ドット絵データベース | horicun.moo.jp |
| 439 | Obsidianおすすめプラグイン 〜日常記録、コードスニペット、ブログの下書きに〜 - neccoNote ｜ necco inc. | necco.inc |
| 419 | 『ソフトウェアエンジニアがHondaに転職して感じたこと4選』の記事削除について -Honda TechBlog | honda-techblog.hatenablog.com |
| 412 | ある日本人少年の物語中国が用いる手法 —情報操作とナラティブ・ジャミング -グローバル・ガバナンス研究センター（Institute for Global Governance Research：GGR）-一橋大学 | ggr.hias.hit-u.ac.jp |
| 407 | ゆめみ、アクセンチュアによる買収に合意 ｜ ゆめみ | www.yumemi.co.jp |
| 398 | Just fucking useHTML | justfuckingusehtml.com |
| 395 | ニッポン放送初の英語・語学学習ポッドキャスト番組！『AnimeEnglishClub withSally Amaki』 | news.1242.com |
| 394 | AWSの安価でスケーラブルなウェブアプリ構成2025年度版 -maybedaily devnotes | tmokmss.hatenablog.com |
| 391 | 神名データベース –國學院大學古典文化学事業 | kojiki.kokugakuin.ac.jp |
| 390 | 自分のiPhoneがどの電波（バンド）とつながっているのかを簡単に調べる方法 ｜イチオシ ｜ ichioshi | ichioshi.smt.docomo.ne.jp |
| 369 | Claude 4プロンプトエンジニアリングのベストプラクティス - Anthropic | docs.anthropic.com |
| 368 | 情報収集の仕方を模索している - 下林明正のブログ | shimobayashi.hatenablog.com |
| 366 | GitMCP | gitmcp.io |
| 358 | ずぼら女子による無肥料・無農薬・ほぼほったらかしでも育った作物、育たなかった作物ランキング【春夏編】 | agri.mynavi.jp |
| 353 | Gemini -HAL9000型との対話 | gemini.google.com |
| 352 | 中央図書館窓口等委託事業者の交代に伴う業務の停滞について -大阪市立図書館 | www.oml.city.osaka.lg.jp |
このネット投稿は、データ分析ライブラリであるPandasとAIを組み合わせたデータ処理について、その効率の悪さを強く批判しています。投稿者は、特に以下の点に言及しています。
この投稿は、PandasとAIを用いてデータベースから取得したデータを扱う際に、データの正規化を無視して不必要に結合したり、非効率なデータ構造を選択したりすることへの強い反発と、処理効率を重視するべきだという主張をしています。データベースやプログラミングにおけるデータ処理のベストプラクティスを理解していない、あるいは無視している実装に対しての批判と解釈できます。
