  |
はてなキーワード:テスト駆動開発とは
----
「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 として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
「品質管理が僕たちの責務です」
って、最近エンジニアリング界のライザップ的元テスト専門会社のQAエンジニアが、昔、言ってたなぁ……、と。
思い上がるなっ！
君たち如きに背負えるものでは、すでにない。
とあえて言おう。
いや、マジで、無理なんよ、もう。
例えば、キッチキチにエレベータを作り込んだとして、後から点検してくれ、と言われたら、まぁ、普通は困るよな。
モーター室がモーターが入るギリギリの広さだとしたら、箱の外に出る手段がなったら。
どうやって点検するんだよ。
実際には、設計時に点検方法を決定して、それができる余地を確保してから、施工するものだろう。
今時のEV車なんて、テスト用の仕組みがきっちりと、製品に組み込まれている。
検証不可能とまで言わなくても、検証困難な場合はちゃんと対策をとるもんです。
作りきってから、「E2Eテストお願いねー」とQAチームに投げるものじゃあないんですよ。
設計時に、テスト戦略から何から何まで検討済みになってるもんなんです。
別にユニットテスト書いて、カバレッジあげるのがTDDというわけではない。
検証可能なシステムを設計実装し、リリースのたびにシステムの健全性を検証できる仕組みを整える。
ってのが「テスト駆動開発」なんですわ。
テスト戦略をちゃんと練れば、マイクロサービスの分割の仕方、連携の仕方等々、多分、今、Web上でよく見る記事とはだいぶ様相が異なってくるはずだ。
で、プロダクトの中身である、設計や実装を理解できなければ、検証のしようがないのがここ10年ほどだ。
金槌を渡されて、「品質検査しろ」と言われたら、まだ何とかなるだろう。
けどボーイング787をポンと渡されて、「品質検査しろ」と言われたら？
マニュアルなしで。
モジュールがどう組み合わされてるか等、中身を理解できなければ、何をどうしていいかも分からんだろう？
扉の開け閉めができるとか、主電源入れたらなんか部屋の明かりがつくとか、そういう表面的な検査しかできないだろ？
これは、QAが、設計に飲み込まれることを意味する(10年以上前に、↑のQAエンジニアとした話)。
QAのテストに関する知見を、設計実装するエンジニアは当然持っておかなければならないということとともに、QAエンジニアは消えてなくなるということでもある。
お分かりだろうか？
同じ流れで、SREも不要になる。
Infrastructureas Code は設計実装エンジニアのためのものだと言っておこう。
決して、Terraformのファイルを編集して、SREの許可を、延々と待ち続けて、適応してもらうことをいうわけではない。
そこまで込みで、設計するのだ。
高負荷時にどうスケールさせるかなども、当然設計に入ってくるからな。
ってなわけで、ほとんどの現場では、そういう致命的な誤認識をしていると思う。
認識が古すぎている上に、大型化複雑化した現状を認識できていない。
開発初期はまだ規模が膨らんでいないから、何とかなりそうな勘違いを犯しているだけの話だ。
初回リリース前後で、「あ、やばい……」となっているところがあまりに多すぎる。
また、この誤認識によって、役に立たないエンジニアの頭数だけを並べて札束を燃やし、事業の拡大の足を引っ張っていると指摘しておこう。
ここら、どげんかせにゃならんのよな。
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
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 1900 | なんとなく使っていませんか？ 括弧の種類と使い分け｜モリサワ note編集部 | note.morisawa.co.jp |
| 1309 | 波 2024年4月号 おつむの良い子は長居しない 第12回／高嶋政伸 | www.shinchosha.co.jp |
| 1241 | 電車の中で座るための戦略とアクションプラン｜みずほリサーチ＆テクノロジーズ | www.mizuho-rt.co.jp |
| 1061 | 無印良品のランドセルの思い出 -プロムナード | promenade.hatenablog.jp |
| 1011 | 謙虚なリーダーのもとで心理的安全性が高まりメンバーが本領発揮しやすくなる―職場においてリーダーの謙虚さと心理的安全性が果たす役割― ｜東京大学 先端科学技術研究センター | www.rcast.u-tokyo.ac.jp |
| 986 | いらすと本舗 | irasutofree.com |
| 921 | 電通、人間の消費行動に強く影響する「11の欲望」最新版を発表 ｜ AdverTimes.（アドタイ）by宣伝会議 | www.advertimes.com |
| 918 | 訃報｜集英社『週刊少年ジャンプ』公式サイト | www.shonenjump.com |
| 808 | 日本の賃金が上がらない理由（大企業の中の人目線で） -konanタワリーマンブログ | konantower.hatenablog.com |
| 730 | はじめに ｜ ちいさなWebブラウザを作ってみよう | browserbook.shift-js.info |
| 680 | あなたが教わってるそのCSSテクニックはもう古い ｜TAKLOG | www.tak-dcxi.com |
| 664 | 個人開発を7年以上続けて分かった技術選択のコツ | blog.craftz.dog |
| 648 | お知らせ 閉店・廃業します。 ｜新宿curry草枕 | currykusa.com |
| 638 | さすがの一言に尽きる！全登山者が求めていた“神アイテム”はモンベルにあった ｜ YAMAHACK[ヤマハック] | yamahack.com |
| 618 | 高木浩光＠自宅の日記 - Claude 3に例の「読了目安2時間」記事を解説させてみた | takagi-hiromitsu.jp |
| 590 | とほほさんの「お茶・紅茶入門」の内容を検証する（主に中国茶部分） – あるきちのお茶・旅行日記 | arukichi.teamedia.jp |
| 582 | 【翻訳】テスト駆動開発の定義 - t-wadaのブログ | t-wada.hatenablog.jp |
| 543 | 冬の電気自動車の遠出は本当に厳しい。航続距離も減るし、とにかく充電スピードが落ちます -勝間和代が徹底的にマニアックな話をアップするブログ | katsumakazuyo.hatenablog.com |
| 540 | トーチweb創作文芸サークル「キャロット通信」の崩壊 【創作文芸サークル「キャロット通信」の崩壊】 | to-ti.in |
| 539 | ワイヤレスイヤホンの価格帯別選び方 -ARTIFACT@はてブロ | kanose.hateblo.jp |
| 536 | 「会議で話されている内容と、ソースコードが全然違う」〜イオン発の“新ネットスーパー”リリース直前の1年間を語る｜イオンネクストCTOインタビュー ｜AEON TECHHUB | engineer-recuruiting.aeon.info |
| 532 | 27歳年収420万非モテ男がマッチングアプリ始めた結果がヤバすぎる -人生万事こじらせるべからず | www.gorannosponsor.net |
| 525 | Python滅ぼす協会に入会したい | dev.thanaism.com |
| 514 | はてなのアプリ専用マンガビューワを集英社が採用。2,700万ダウンロードを超える「少年ジャンプ＋」に提供開始 -プレスリリース -株式会社はてな | hatena.co.jp |
| 485 | 【無料】台湾で収録された自然環境音ライブラリ、99Sounds「Nature Sounds」無償配布開始！ ｜ComputerMusic Japan | computermusic.jp |
| 476 | 美しいもの・美しいもの | comic-medu.com |
| 451 | ゲームを途中でやめた理由､ご意見＆対策集 - SmokingWOLF -Ci-en（シエン） | ci-en.dlsite.com |
| 447 | 【シェフ考案】チキン南蛮の作り方。衣はザクザク、肉はジューシー！甘酢、タルタルレシピも必見です ｜三越伊勢丹の食メディア ｜ FOODIE（フーディー） | mi-journey.jp |
| 439 | 業務スーパーのラグジュアリッチコーヒーはなぜ美味い？珈琲まめ工房を質問攻め -福岡のフリーライター・大塚たくま.com | www.otsuka-takuma.com |
| 429 | 文字組版の教室note版｜モリサワ note編集部 | note.morisawa.co.jp |
プログラミングの話題と相性がいいんじゃないかと思って、昔読んだことがある達人プログラマー (1999年に出版された第1版の方、2019年に出版された第2版ではない) をぱらぱら見返してみた。プログラマーとしての姿勢やプラクティスなどは一般に普及したかどうかの判断が難しい。間違いなく一般的になったなと思えるものに絞って書く。インフラ面の進化が大きいと言えそう。
フリーレン「わずか数年で人類の開発方法論に組み込まれ、新しいインフラによってシステム開発の生産性を向上させた。」
でも今のチームはソースコード管理システムを使っていないんだけど……
恥ずかしいと思ってください！ そして、これが伝道師となる機会だと受け止めてほしいのです。しかし、彼らが自ら進むべき道を見つける時まで、あなた一人ぼっちであってもソース管理を使うようにしてください。
フェルン「いまのはバージョン管理システムです。」
いつリファクタリングを行うべきなのか？
コードがうまくなじんでいないと感じたり、まとめるべき 2つの事柄を見つけたりといった何か「おかしなもの」に遭遇した場合、手を入れることを躊躇してはいけません。
テストの文化
あなたの記述したソフトウェアはすべてテストの対象になります。あなたやあなたのチームの人間がテストをしなければ、最終的にユーザーがテストを強いられるのです。このため、テスト計画を徹底的に練る必要があります。しかし、事前にものごとを少し考えるだけでメンテナンス費とヘルプデスクへの呼び出しを大幅に削減できます。
(中略)
テストは技術というよりは文化なのです。こういったテスト文化は、使用する言語に関係なくプロジェクトに植え付けることが可能なのです。
フェルン「いまのはテスト駆動開発です。」
多くのプロジェクトでは、こういったレベルのビルドは毎晩自動的に実行されています。つまり、プロジェクトの特定部分を夜間ビルドで作成すると同時に、個別のテストよりも完全なテストを実行できるのです。これによって、完全なビルド実行時に行うテストをすべて実行させることも可能になります。結果として、その日のうちに回帰テストの問題を見つけられるようになるわけです。ソースの変更後、できるだけ早い時点で問題を検出できれば、バグの検出と修正を円滑に進められるようになるはずです。
これ、応用情報技術者試験のR4春の午後の問3前半のコードと似ていて読めないようなコードではない。
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt80000009sgk-att/2022r04h_ap_pm_qs.pdf
応用情報のほうは添え字を一次元に展開しているのをChatGPTは二次元でやってるだけ。
問題後半では探索の効率化をやっていて、人間が解くように候補の数字のリストを作成してそこから処理するんだけど、ChatGPTのコードも少しの変更で速くなることはコード読んで短時間で判断できるから決して保守性の悪いコードではないでしょ。
むしろVBAかじった素人や、派遣の自称エンジニアのコードのほうが一般に酷い。
応用情報の方は誘導がありコメントの通り書くだけのラッキー問題で1問あたり30分で設問3つのうちの2つを占めるから制限時間20分だけど、ChatGPTはこれを一行命令で誘導なしで即答する。
一定水準の網羅性を考慮した動作確認用のいくつかの入力と出力の組を過去の業務データから用意して、テスト実行マクロもChatGPTに書かせてしまえば、変更があったときもコードベースで修正しないでプロンプトから出し直してしまえば中身がブラックボックスでもテストで品質確保するテスト駆動開発ができる。レビューなんかテストパターンの網羅性とテスト結果で十分よね。
業務をよく知っている人が業務内容をプロンプトに落とし込んでテストパターンを適切に準備できればVBAの知識はほとんどいらないし、その知識すらChatGPTのコードと会話から学ぶことができるんよね。
どんなに優れたツールや設計思想などがあっても、使う奴がダメだと全く無意味。弊社もWebアプリを作ってて、RESTだのFluxアーキテクチャだのいろいろ導入を試みたが、ほとんど無駄に終わった。
どんなクソ組織でも効果があると確信持って言えるのは上の3つだけ。1つ目は初歩的すぎると思われるかも知れないが、筆者の想定するダメな組織・ダメなプログラマというのは、このレベルの連中を含む。
静的型付け言語（サーバーサイドならJavaやC#、フロントエンドならTypeScript）を使わせれば、少なくともコンパイル時に分かるエラーは修正させられる。
というか、ダメなプログラマに動的型付けの言語は触らせてはいけない。必ずそのプロジェクトは半年後には保守できなくなる。
テストは強制的に書かせるし、テストのないクラスや、通らないテストあったらコミットできないようにする（それは容易にできる）。
もう一つの方法は、そもそも優秀なエンジニアしか参加できないようにすること。たとえば、Scala、Haskell、Erlang、Common Lispなどで書かれていれば必然的にそれが分かるエンジニアしか開発できないし、こういう言語を自主的に学習しているエンジニアは優秀である可能性が高い。
汎用系のエンジニアからRubyのエンジニアとして転職して1年。
コボラー（笑）なんて言われることも多いが、この1年で出会ったRubyエンジニアは全て糞だった。
その特徴はだいたいこの3つだ。
やれテスト自動化だ、やれテスト駆動開発だの口だけ達者なエンジニアの多いこと。
そもそもブラックボックステスト、ホワイトボックステストを分かっていない奴が多すぎ。
テストコードでカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしまう。
ドキュメントを揶揄し机上デバッグも行わない、こんな状態で「アジャイルですから」とかドヤ顔でいってしまうRubyエンジニアは糞である。
そもそも自分が行おうとしているソートが何ソートなのか知っているのか？計算回数を考慮した上での実装か？
便利なメソッドがたくさんあるのは知っている。
ただ、中身くらいは知っておこうよ。
新人に教えたらバカにされたけど、まずフローチャート書くようにしようぜ。
「Githubで公開されてましたんで導入しました」じゃねーよ。
得体の知れないコードをたくさん詰め込んだプログラムをよく動かせるな。
そんで都合の悪いところだけコードを読んでオーバーライドする。
影響範囲を全く調査せず、Gem絶対神話を唱える。あれなんなの？
いや、Rubyが便利なのは認めるよ。俺だってPLIとかCOBOLより書いてて楽しいよ。
エンジニアもどき量産言語だね。どれか１つでも当てはまった奴は小学校からやり直せ。
追記
意見がたくさんもらえて喜ばしい。
文化の違いという意見もあったが、「よくわからないけどなんかうまくいく」コードだとデバッグも大変だし不具合も起きやすい。
「だいたい」とあるだろう。全てのだいたいだ。
＞フローチャート糞
精神論に聞こえるかもしれないが、フローチャート書いて育ったエンジニアは頭の中でロジックの組み立てと凡その演算回数が計算できるようになるよ。
＞カバレージが100%だったとしても実際の打鍵結果でエラーは弾ける
あー、ここは誤タイピングだわ。
自動テストでカバレージ100%です、そして画面数回触ってリリースしますーっていう奴が多いってこった。
単体だけじゃなく画面使ったテストもケース表書いて網羅性を担保しないとダメだろ。
■7:00 起床
最近使い始めたアラームアプリは簡単な計算問題を解く必要がある。
今日は27-13。
最初は良かったけど、最近は寝ながらでも問題を解けそうなので、
■7:05
■7:30 出社準備
またネットサーフィン。
未だにテスト駆動開発とか言ってるのを見つけて懐かしい気持ちになる。
去年死んだでしょ？
■8:40家出
自宅を出て駅へ。
5分後ぐらいに別の交差点で会う。
数年かけて最短コースを探索したつもりだったけど、
まだ他に抜け道でもあるのか。
■08:57電車に乗る
■09:30会社最寄駅到着
09:15には出社する予定だったはずだけど気にしない。
コンビニでお昼ご飯を買う。
■09:45会社到着
ネットサーフィンする。
相変わらず真面目で面白味のないやつだ。
2chも二次裏もニコ動もネトゲもはてなも発言小町も知らないらしい。
うむ、その生き方が正しい。
やっと雑用が終わってEclipseを立ち上げる。
起動を待ってる間にネットサーフィン。
木村岳史の極言暴論コラム、今度は「中国にも抜かれるIT後進国ニッポン、
この記事Facebookいいねランキング一位なんだけど…IT後進国だと実感するわ。
今日は早く帰るだろうと思い、残業用に残しておいた菓子パンも食べる。
■12:45
「達人プログラマー」を読み返す。本に書いてあるようには上手くいかない。
自分だけがDRY原則や割れ窓理論を守ってもしょうがないんや…
昼寝。
■13:00 午後の仕事再開
「この社内業務用のサイトがやたら遅いんだけどなんで？」
あーとりあえずF12押してからF5押してください。デバックできます。
…このサイト、ただプルダウン表示するだけでサーバと六千回通信してる…!?
■13:30
いつも思うけど、どうやったらあんなつくりにしようと思えるのか。
といっても朝だらだらしているうちにだいたい考えていたので、
あとはタイプするだけ。
■14:00
「去年君が作ったプログラム見てるんだけど、
一時期私の中ですべてXMLに書くのが流行った時期があるからですよ。
■14:30
本気で飽きたので業務と関係のない自動化プログラムを作って遊ぶ。
あとは上司にこのExcelを開かせれば楽しいパーティーの始まりだ！
だいたいこういう調子に乗っているときはよくないことが起きる。
■15:10
幸い運用は止まっていないけど今まで見たことのない挙動をしてる。
■15:30
「今日は様子を見るので遅くまで残っておいて」とのこと。
昼に菓子パン食べたの後悔。
■16:00～
記憶がない。
■21:00
帰宅準備。
落ちないかな、と思っちゃいます。」
古事記にもそう書いてある。
■21:30
スマホを取り出すとこの前の日曜に遊んだ女子大生からLineが来てた。
「ブラック企業って本当にあるんですか？？」
もう一週間未読放置されてる。徹底的すぎるでしょ。
事務連絡っぽく送ったんだからせめて既読ぐらいつけてくれてもいいのに。
■22:00晩御飯
■23:50
この日記を書き始める
検索窓にふとtdd is って打って出た候補にワロタｗｗｗｗ
容赦なさすぎやろｗ
肯定的な文句がまったく出てきませんでした。事実はともかくとして、このように思われているということでしょうね。啓蒙は難しそうですね。大変ですね。
こちらからは以上です。
ゆーすけべーさんが以前に作ってたimeeroみたいな感じです。画像Blogをスクレイピングしてエロ画像を効率的に見るサイトです。
なお、先程解約手続きを済ませたので4月末くらいに見れなくなります。エロサイト自体にあまり興味がなく、ローンチしたらやる気が無くなったのです。
テスト駆動開発がやりたく、DSLに強いロック魂を感じたRSpec。
はやりに乗ってBootstrap。
特にCapistranoは名前がキュートでやっていることがカッコイイのでどうしてもやりたい技術でした。
あと、メインとなるRailsはこの記事に書いているスキルの中で唯一経験が無かったというのが一番の理由です。Rubyが好きなのもありますけどね。
いやぁ、退職しようとすると会議室で8時間説教されるって都市伝説じゃないんですね〜。
ところで転職活動をした感覚だと、今より給与が2倍出るところでも簡単に内定が出ることが分かりました。
転職活動やエロサイト作成を通して精神的な余裕も出ましたので、もう少しSIerそのものの問題、仕事の進め方などを熟考した上で、本当に正しいSIerのあり方を考えたいと思います。無理そうなら逃げます。
以上、よろしくお願いいたします。
初音ミクのオンラインかるたゲーム「ミクミクかるた」をリリースしました。
http://mikumikuplay.com/karuta/
個人で開発して、開発期間は3週間くらいです。
http://www.nicovideo.jp/watch/sm22964822
リリースしたものの過疎ってるので、増田で宣伝をさせてくださいなと！
「ミクミクかるた」はブラウザで簡単に遊べるオンラインかるたゲームです。ゲームのルールは簡単で、ボカロ曲が流れたら、歌詞の先頭文字の札をクリックするだけです。「みっくみ～くにし～てあげる♪」と流れたら「み」の札を取ります。かるたの札の読み上げの代わりにボカロ曲が流れるというシステムです。オンライン対戦することも出来ます。ボカロ好きな人たちが集まって遊べる場になればと思っています！
ゲームで使わせて頂いた曲はpiapro(ピアプロ)でお借りしました。改めて素晴らしい曲がたくさんあることを知り感動しました。このゲームによって素晴らしい曲が、より多くの人に聴かれることを願っています。
実はこのゲームの開発者である私もボカロPをちょびっとやっています。私の場合、曲を作ってニコニコ動画にアップしても2日も経てば再生数の伸びが止まってしまいます。毎日すごい数の曲がアップされている為、すぐに埋もれてしまうのでしょう。私の曲は大したことがないのでいいのですが、中にはすごく良い曲でも再生数が少ないものが多々見られます。このゲームによって埋もれている隠れた名曲に、光を当てられたらと思っています！
以前、「ミクミクすごろく」というオンラインすごろくゲーム(http://mikumikuplay.com/sugoroku/)を作り、ユーザーがイラストと文章を作ることによってゲームコンテンツを拡張していくことが出来るCGG(Consumer Generated Game)の仕組みを作りました。CGGはブログなどでおなじみのCGM(Consumer Generated Media)のゲーム版に当たります。
今回開発した「ミクミクかるた」では、開発作業をニコニコ生放送で配信していました。すると視聴者の方がゲームの機能やデザインについてのアイデアをコメントしてくれました。コメントしてくれたアイデアのほとんどを採用しています。言わば、生放送駆動開発(Live Driven Development)と言えるのではないでしょうか？まぁ、これは悪乗りですが・・・。
最近流行している開発手法としてテスト駆動開発(Test Driven Developement→略してTDD)というものがあります。TDDをするとテストしやすいインターフェースやモジュール設計が出来るようになりますが、この生放送駆動開発すると、ユーザーが望んでいる設計が出来るのではないかと思います。新たな開発手法を発見することが出来ました。
■特徴一覧
・ニコニコ動画等で埋もれてしまっている隠れた名曲に光を当てるシステム
・HTML5、Node.jsによりWebブラウザゲームにおけるリアルタイム処理を実現
