  |
はてなキーワード:BDDとは
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
283:名無しさん＠おーぷん 2016/10/26(水)11:36:44ID:BdD
秋のよく晴れた日になると思い出す。
３歳の秋の日、母が朝からおにぎりを作ってくれて、「お出かけしよう」と言って電車に乗って遠くに行った。
行き先は山も海も見える田舎町だった。
真っ白い堤防のようなところで、母がベンチに座らせて、「ちょっとお母さん飲み物買ってくるから待っててね」と言った。
「わかった、ママありがとう。バイバイね」と言ったら、母は顔をそむけて走るように去って行った。
私はぼんやり座ってた。山はまだらに赤くて、空にはトンビが飛んでた。
しばらくして母は戻って来て、無言で一緒に弁当を食べて家に戻った。
成人して家を出て行くという日に、母はあの日の話をして、「あなたを捨てようとしてごめんなさい」と詫びた。
私は当時気付いてなかったふりをしたけど、勿論気付いてた。
それどころか、母があんまりに私の存在を疎んでるのを知ってて、大好きな母が楽になるならそれでいいと思ってた。
捨てられた私は次はどこに行くんだろうとボンヤリ考えてた。
私を捨てようとした母と、他人にむやみに金貸すのが趣味で散々妻子を苦しめた父。
私も順調なら年末に初めて親になる。
出来れば良い親になりたい。
ABA: 応用行動分析 [Applied Behavior Analysis]
AC:従順な子どもの心 [Adapted Child]（エゴグラム）
AC/ACoD/ACoDF:アダルトチルドレン [Adult Children of Dysfunctional Family]
ACT:アクセプタンス＆コミットメント・セラピー [Acceptance and Commitment Therapy]
AD:アスペルガー障害 [Asperger disorder]
ADD: 注意欠如障害 [Attention Deficit Disorder]
ADHD: 注意欠如・多動性障害 [Attention Deficit / Hyperactivity Disorder]
AN: 神経性無食欲症 [Anorexia nervosa]
AS:アスペルガー症候群 [Asperger Syndrome]
APD:回避性パーソナリティ障害 [Avoidant Personality Disorder] /不安パーソナリティ障害 [Anxious Personality Disorder]
ASD:自閉症スペクトラム障害 [AutisticSpectrum Disorder] /急性ストレス障害 [Acute Stress Disorder]
ASPD:反社会性パーソナリティ障害 [Antisocial Personality Disorder]
ASPS:睡眠相前進症候群 [Advanced sleep phase syndrome]
AUD:アルコール使用障害 [Alcohol use disorder]
BD:双極性障害 [Bipolar disorder]
BDD: 身体醜形障害 [Body dysmorphic disorder]
BN: 神経性過食症（過食症） [Bulimia nervosa]
BPD:境界性パーソナリティ障害 [Borderline Personality Disorder]
BPRS: 簡易精神症状評価尺度 [Brief Psychiatric RatingScale]
BT:行動療法 [Behavioural Therapy]
CBT:認知行動療法 [Cognitive Behavioral Therapy]
CCT: 来談者中心療法 [Client-Centered Therapy]
CDD: 小児期崩壊性障害 [Childhood Disintegrative Disorder]
CFIDS: 慢性疲労免疫不全症候群 [Chronic Fatigue and Immune Dysfunction Syndrome]
CFS:慢性疲労症候群 [Chronic Fatigue Syndrome]
CP:臨床心理士 [Clinical Psychologist] /脳性麻痺 [Cerebral palsy] / 厳格な親の心 [Critical Parent]（エゴグラム）
C-PTSD:複雑性PTSD [Complex post-traumatic stress disorder]
CT:認知療法 [Cognitive Therapy] /コンピュータ断層撮影 [Computed Tomography]
DA: 発達年齢 [DevelopmentalAge]
DBT:弁証法的行動療法 [Dialectical Behavior Therapy]
DCD: 発達性協調運動障害 [Developmental coordination disorder]
DESNOS:特定不能の極度ストレス障害 [Disorder ofExtreme Stress nototherwise specified]
DD:解離性障害 [Dissociative Disorder] /気分変調性障害 [Dysthymic Disorder] /発達障害 [Developmental disability]
DDNOS:特定不能の解離性障害 [Dissociative disorders nototherwise specified]
DD-NOS:特定不能のうつ病性障害 [Depressive disorder nototherwise specified]
DID:解離性同一性障害 [Dissociative Identity Disorder]
DIQ: 偏差知能指数 [Deviation IQ]
DMDD:破壊的気分調節不全障害 [Disruptive Mood Dysregulation Disorder]
DPD:依存性パーソナリティ障害 [Dependent Personality Disorder] /抑うつ性パーソナリティ障害 [Depressive Personality Disorder]
DSM:精神障害の診断と統計マニュアル [Diagnostic and StatisticalManual of Mental Disorders]
DSPS:睡眠相後退症候群 [Delayed sleep phase syndrome]
DQ: 発達指数 [Developmental Quotient]
ECT:電気痙攣療法 [Electroconvulsive therapy]
ED:摂食障害 [Eating Disorder] /勃起障害 [Erectile Dysfunction]
EFT:感情焦点化療法 [Emotionally focused therapy]
EMDR: 眼球運動による脱感作と再処理法 [Eye Movement Desensitization and Reprocessing]
EPS:錐体外路症状 [extrapyramidal symptom]
EUPD:情緒不安定性人格障害 [Emotionally Unstable Personality Disorder]
FAS:胎児性アルコール症候群 [Fetal alcohol syndrome]
FASD:胎児性アルコール・スペクトラム障害 [Fetal AlcoholSpectrum Disorders]
FC:自由な子どもの心 [Free Child]（エゴグラム）
FD: 注意記憶 [Freedom from Distractibility]（WISC）
FM:線維筋痛症 [Fibromyalgia]
FMS:線維筋痛症 [Fibromyalgia Syndrome]
FT:家族療法 [Family therapy]
FXS:脆弱X症候群 [fragile X syndrome]
GAD:全般性不安障害 [Generalized Anxiety Disorder]
GH:幻聴 [Gehörshalluzination]
GID:性同一性障害 [Gender Identity Disorder]
GLA:全般性不安障害 [Generalized Anxiety Disorder]
HFA/HA:高機能自閉症 [High-Functioning Autism]
HFPDD:高機能広汎性発達障害 [High Functioning Pervasive Developmental Disorder]
HPD: 演技性パーソナリティ障害 [Histrionic Personality Disorder]
IBS:過敏性腸症候群 [Irritable Bowel Syndrome]
ICD:疾病及び関連保健問題の国際統計分類 [International Statistical Classification of Diseases and Related Health Problems]
ID:知的障害 [Intellectual Disability]
IP:患者とみなされた人 [Identified Patient]（家族療法での用語）
IQ:知能指数 [Intelligence Quotient]
K-ABC: [Kaufman AssessmentBattery for Children]
LD:学習障害 [Learning Disabilities]
MAO: モノアミン酸化酵素 [monoamine oxidases]
MAOI: MAO阻害剤 [monoamine oxidase inhibitor]
MBCT:マインドフルネス認知療法 [Mindfulness-based cognitive therapy]
MBSR:マインドフルネス・ストレス低減法 [Mindfulness Based Stress Reduction]
MDD: 大うつ病性障害 [majordepressive disorder]
MDI:躁うつ病 [ManicDepressive Illness]
MR:精神発達遅滞 [mental retardation]
MRI: 核磁気共鳴画像法 [magnetic resonance imaging]
MSLT: 反復睡眠潜時検査 [multiple sleep latencytest]
MTBI:軽度外傷性脳損傷 [mildTraumatic Brain Injury]
NaSSA:ノルアドレナリン作動性・特異的セロトニン作動性抗うつ薬 [Noradrenergic and specific serotonergic antidepressant]
NDRI:ノルアドレナリン・ドパミン再取り込み阻害薬 [Norepinephrine-Dopamine Reuptake Inhibitors]
NLP:神経言語プログラミング [Neuro-Linguistic Programming]
NP:保護的な親の心 [Nurturing Parent]（エゴグラム）
NPD:自己愛性パーソナリティ障害 [Narcissistic Personality Disorder]
NT:物語療法/ナラティブ・セラピー [Narrative therapy]
OCD:強迫性障害 [Obsessive Compulsive Disorder]
OCPD:強迫性パーソナリティ障害 [Obsessive-Compulsive personality Disorder]
OT:作業療法 [Occupational therapy] / 光トポグラフィ [optical topography]
PANSS: 陽性・陰性症状評価尺度 [Positive andNegative SymptomScale]
PCA:人間中心療法/パーソンセンタードアプローチ [Person-Centered Approach:PCA]
PD:パニック障害 [Panic disorder] /パーソナリティ障害 [Personality disorder]
PDD:広汎性発達障害 [Pervasive Developmental Disorder]
PDD-NOS:特定不能の広汎性発達障害 [Pervasive Developmental Disorder - NotOtherwise Specified]
PDNOS:特定不能のパーソナリティ障害 [Personality Disorder NotOtherwise Specified]
PE: 持続エクスポージャー法 [Prolonged Exposure]
PET:ポジトロン断層法 [positronemission tomography]
PIQ: 動作性IQ [performance IQ]
PMDD:月経前不快気分障害 [Premenstrual Dysphoric Disorder]
PMS:月経前症候群 [Premenstrual Syndrome]
PMT:月経前緊張症 [Premenstrual Tension]
PO: 知覚統合 [perceptualorganization]（WAIS / WISC）
PPD:妄想性パーソナリティ障害 [Paranoid Personality Disorder]
PS: 処理速度 [processing speed]（WAIS / WISC）
PSD:心身症 [Psychosomatic disease]
PTG: 外傷後成長 [Post Traumatic Growth]
PTSD:心的外傷後ストレス障害 [Post-traumatic Stress Disorder]
REBT: 理性感情行動療法 [Rational emotive behavior therapy]
RLS:むずむず脚症候群 [restless legs syndrome]
RT:現実療法 [Reality therapy] /論理療法 [Rational therapy]
SA:システムズ・アプローチ [Systems Aproach]
SAD:社会不安障害 [Social Anxiety Disorder] /季節性情動障害 [Seasonal Affective Disorder]
SARI: トリアゾロピリジン系抗うつ薬 [Serotonin antagonist and reuptake inhibitor]
SAS:睡眠時無呼吸症候群 [Sleepapnea syndrome]
SD: 身体表現性障害 [Somatoform Disorder]
SDA:セロトニン・ドパミン拮抗薬 [Serotonin-Dopamine Antagonist]
SLD: 限局性学習症/限局性学習障害 [Specific learning disorder]
SLTA: 標準失語症検査 [Standard LanguageTest of Aphasia]
SMIT:自己洞察瞑想療法 [Self Insight Meditation Technology/Therapy]
SNRI:セロトニン・ノルアドレナリン再取り込み阻害薬 [Serotonin and Norepinephrine Reuptake Inhibitors]
SPECT:単一光子放射断層撮影 [Single photonemission computed tomography]
SPD:スキゾイドパーソナリティ障害 [Schizoid Personality Disorder] /サディスティックパーソナリティ障害 [Sadistic Personality Disorder]
SRS:性別適合手術 [Sex Reassignment Surgery]
SSRE: 選択的セロトニン再取り込み促進薬 [Selective serotonin reuptakeenhancer]
SSRI: 選択的セロトニン再取り込阻害薬 [Selective serotonin reuptake inhibitors]
SST:ソーシャルスキルトレーニング/社会生活技能訓練 [Social Skills Training]
TA:交流分析 [Transactional Analysis]
TBI: 外傷性脳損傷 [Traumatic brain injury]
TCA: 三環系抗うつ薬 [Tricyclic Antidepressants]
TS:トゥレット症候群 [Tourette Syndrome]
VC:言語理解 [verbal comprehension]（WAIS / WISC）
WAIS: ウェクスラー成人知能検査 [Wechsler AdultIntelligenceScale]
WISC: WISC知能検査 [WechslerIntelligenceScale for Children]
WPPSI: WPPSI知能診断検査 [Wechsler Preschool and PrimaryScale ofIntelligence]
WM:作動記憶 [working memory]（WAIS）
Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。
モバイルファースト、APIファーストな文脈でハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLをゴリゴリ生成するなんてよほど特殊な最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLやメタプログラミング等のテクニカルな技法が宝石のように鏤められている様はまるでエジプト時代の骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。
Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsのクラスやディレクトリという特定の実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナルな概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。
Rails界隈の人がよく「Railsの流儀」や「正しい"MVC"」というのを口角泡を飛ばして議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRailsの世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインやサービスレイヤの名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircularDependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別な名前や役割を与えられても正直しんどいので、皆が皆libにゴミを放り込んでいく様子にも納得がいきました。
RailsをAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFatModelを作ってしまうのかという事が良く分かりました。多くのRailsのリファクタ手法と称されているものはクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときはセットポジションでDDDの青本を投げつける必要が有るなと思いました。
ビューとコントローラを結合させた場合、結合テストはCapybaraとかのBDDでマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか、緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーやモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。
ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーはRubyもバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。
RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思います。GETがbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTはあくまでリソースを抽象化する美しい概念なので、アクションや副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間にしか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計を拝借することはよしとしても、「○○はRESTでは無い故云々～」みたいな注文はやめて頂きたいものです。
とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまでサーバーサイド初心者の感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います。
多少書けるけど絶対に「プログラマです」とは名乗れないゼネラリストたちで構成されている会社。
そんな会社だと、プログラムでなるべく解決する（コードが業務プロセスを頑張っちゃう）ために頑張るよりも、
業務プロセス・開発プロセス全体で最適化するよう頑張った方が、
プログラムで頑張ろうとすると、
外注するのに設計しようにも結局学習コストがかかりすぎるとか、
外注が逃げるとか、
引き継ぎ先がいなくて死ぬとか、
そんな余計なことが多かった。
反復性・正確性が求められるものはプログラム化に適しているけれど、プログラムは解決の一手段だし、一分野にしか過ぎない。
ともすればプログラムのスペシャリストでないことに大きなコンプレックスを抱くけど、
生産物が割合ライトで公共性も低い（例えばエンタメ系スマホアプリ）だったら、
身の程わきまえて、他の業務パラメータも見て総合的に結果を最大化しようというシンプルな結論に至る。
オブジェクト指向の本を読むのも結構だけど、もっと大きな見地から比較して
ライトなフレームワークを選択して、ライトな開発プロセスでやる選択がもっと歓迎されていいと思う。
そして、アジャイルとかTDD/BDDとかももちろんいいんだけど、開発現場からのボトムアップ的な思想やツールでなく、
マネジメント視点や経営視点から自分たちがライト層として開発するなら、という発想がもっとあっていいと思う。
元プログラマが経営層になっての話は近年よく聞くけど、非プログラマが経営層でかつ開発もある程度やるよ、というスタイルもそれなりにあるのに。
こういう情報が出回りにくい理由は、そもそも人数が少ないか、文章に書く魅力/余裕がないか、文章化が難しいか、まだ分野的にこなれていないか、のどれか。
暇ができたらまとめたいなあ。。
その前に売上UP（白目）
