  |
はてなキーワード: 非機能要件とは
選挙の度に「エストニアみたいにネット投票導入すればよいのに」という声が出るので、実際にエストニアで起きたことをベースに日本ならどうなるか、を列挙するよ。
・65歳以上の老人の投票率は向上
・しかし、全体ではネット投票導入前と比べて投票率の有意な向上は見られない。例えば国政選挙の投票率はネット投票導入前の1990年代から60%前半をずっと継続
→つまり、老人以外の投票率は低下。「投票所行く体力が無くてのお」と言ってる老人だけが得をする、シルバー民主主義促進ツールに過ぎないのが実態だ
分かりやすい事例で言うと、投票締め切り10分前に一斉に人を集めて「さあ今から◯◯さんに投票を始めてください。まずはログインから…」ということをやられたらお手上げだ。もうやり直すには時間がない。
他にも、特定の候補に「最終的に投票する」ように強制して実行させる手法はいくらでも思いつく。エストニアでどうなってるかは知らないが。
エストニアのネット投票の数は30万人くらいしかない。日本の有権者は1億人だ。仮にその半分の5000万人がネット投票するとしたら…普通に鯖落ちして開票が開始できない状況に陥る。桁が2つ違うと求められる非機能要件は根本的に違ってくるからな
エストニア以外の国がネット投票を導入しないのには理由がある。少なくともシルバー民主主義を加速させてしまうことは認識すべきだろう。
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 Page Application）にすることでユーザー体験を向上させたい（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 Page Application）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「 Permalink | 記事への反応(0) | 17:09
戦略という言葉が、仰る通りデザインパターンとゲーム理論の両方で使われる用語であることは事実です。
しかし、それぞれの分野における「戦略」の使われ方には、明確な違いと、ある種の共通点があります。
デザインパターンにおける「戦略（Strategy）」は、振る舞いに関するデザインパターンの一つです。
目的: 複数のアルゴリズムや振る舞いをカプセル化し、クライアントから独立して交換可能にする。つまり、同じ問題を解決するための異なる方法を、実行時に切り替えられるようにする。
特徴: 共通のインターフェース（戦略インターフェース）を定義し、具体的な戦略クラスがそれを実装します。コンテキスト（ストラテジーを利用するクラス）は、このインターフェースを通じて具体的な戦略クラスとやり取りします。クライアントは、実行時に使用する戦略をコンテキストに設定することで、振る舞いを変更できます。
例: 税金の計算方法が複数ある場合（標準税率、軽減税率など）、支払い方法が複数ある場合（クレジットカード、銀行振込、電子マネーなど）など。
ゲーム理論における「戦略」は、プレイヤーがゲームにおいて取る行動の計画を指します。
目的: 自身の利得を最大化するため、他のプレイヤーの行動を考慮に入れながら、どのような行動を取るかを決定する。
特徴:純粋戦略 (Pure Strategy): ある状況で特定の行動を一つだけ選ぶ計画。混合戦略 (Mixed Strategy): ある状況で複数の行動を確率的に選ぶ計画。プレイヤーは、他のプレイヤーの戦略や可能な結果を予測し、自身の戦略を決定します。ナッシュ均衡など、安定した戦略の組み合わせが分析されます。
選択肢の中から最適なものを選択する:** どちらの分野の「戦略」も、複数の選択肢の中から、ある目的を達成するために最適な行動や方法を選択するという点で共通しています。
柔軟性: デザインパターンでは、異なるアルゴリズムを柔軟に切り替えることを可能にし、ゲーム理論では、状況に応じて最適な行動を柔軟に選択することを可能にします。
目的が異なる:デザインパターン:主にソフトウェアの設計と実装において、変更容易性、拡張性、再利用性といった非機能要件を向上させることを目的とします。ゲーム理論: 主に意思決定の分析において、複数の合理的なアクターが相互作用する状況で、各アクターがどのような行動を取るべきかを予測・分析することを目的とします。
主体が異なる:デザインパターン:開発者が、ソフトウェアの振る舞いを構造化するために使用します。ゲーム理論:プレイヤー（意思決定者）が、自身の利得を最大化するために採用する行動計画であり、また分析者がプレイヤーの行動を分析するために使用します。
相互作用の有無:デザインパターン: 基本的に、戦略パターンを利用するコンテキストと戦略クラスの間には直接的な競争や駆け引きはありません。単に振る舞いを切り替えるだけです。ゲーム理論: 複数のプレイヤーが存在し、各プレイヤーの利得が他のプレイヤーの行動に依存するという、相互作用と駆け引きが本質です。
コードの書けない人が設計をする事例は、現場によっては存在するかもしれませんが、それはあまり望ましい状況ではないと思います。コードの書けない人が設計をすると、以下のような問題が起こりやすいと考えられます。
以上のように、コードの書けない人が設計をすることは、システム開発において多くのリスクを伴います。コードの書けない人が設計をすることを避けるためには、以下のような対策が考えられます。
コードの書けない人が設計をすることは、現場の状況によっては避けられないことかもしれませんが、できるだけコードの書ける人に設計を任せることが望ましいと思います。コードの書けない人は、コードの書ける人と協力したり、ローコード開発などの手法を活用したりして、コードの書き方や技術の知識を身につけることが大切だと思います。
インフラにありがちだと思うけどトラブルが起きて初めて存在が認識される節があって、マッチポンプか否かにかかわらず何かしらのトラブルが起きてその解決をすることで仕事の成果が可視化される。マインススタートにすること意識されるようになり、それゆえゼロに戻した時の振れ幅が大きいと錯覚される。
問題を起こさないことがプロの仕事として評価されるべきなんだけど要件の時点で問題が起きないことが前提となってるので別に完成したところで振り幅は少ない。
不良がたまにみせる優しさが相対的に高く評価されるのと同じアレね。
当事者としてはトラブルないほうがはるかにいいのでテストや非機能要件には気を配ってるがそれが評価されづらいというのは体験としてあるけどこれはビジネス側と現場間にある大きな価値観の分断なんだろうね。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
「AWSによるクラウド入門」が2つ入っているのは?s=09というパラメータが付いているのと付いていないとので割れたせい。
ただ未来がないと喚いても仕方がないので、IT業界に来た若者向けに言いたい事。
受託開発でも何でもいいんだけど、
言われた事だけをこなす技術者にはならないで欲しい。
これは、言われなくても察しろとかそういう話ではなくて、
というのを常に考えて欲しい。
それと、案件に参加したならば
何か一つでいいので、
俺が考えたイカす機能というか、
要求仕様には無いけどサービスでやってやったぜというのを組み込んで頂きたい。
機能要件に関わるところでそれをやるとちょっと揉めることもあるので、
非機能要件で、使い心地を向上させる部分に、エゴを埋め込んでいくのがまずはオススメ。
こんなの作ってみました！どうすか！？やばないですか！？ と見せると
そのまま客先に持っていくことはできないかもしれないけど、
こいつ・・・やるな・・！ってなるはず。
そして、そういうのを後輩が持ってくるようなチームは、仕事が楽しくなる。
言われた事だけをひたすら実装するプログラマにはならないでほしい。
一口にIT土方と言っても色々な仕事があるが、その中でもブラックという悪名の大元になっている、開発の仕事を新卒から手がけて10年になったタイミングで、上司から「人の上に立つキャリアに行かないなら、技術者として横への広がりを」と勧められ(加えて開発の仕事があんまり取れない事情もあり)、そこから数年ほど運用チームの一員として業務をやってきたが・・・俺にはこの仕事のセンスがまるっきり無いことが判明しただけに終わった。
というか、今はもう運用という仕事に対して憎悪の感情しか沸かない。心底嫌気が差してしまった。
以下、色々向いていなかった系の主張メインの言い訳。
俺が長く手がけた開発は必ずゴールがあり、それを踏まえた細部への落し込みの段取りが仕事の核となる。そしてこの段取りを進める忙しさが常にあり、上手く行かなくなった時はブラック激務が待っていると。
一方の運用は、開発と比べたら桁違いにヒマで、しかもゴールがない。しかし、その緩やかな時間の中で日々業務改善に頭を巡らせ、より上手い回し方を工夫することが肝要である。
まず俺は、この時間感覚・仕事感覚の違いに、結局どうしても慣れなかった。ヒマに任せてひたすら惰眠を貪ってしまい、働かないオッサンに成り果ててていた。
多分このまま行ったら、給料泥棒としていずれ切られるだろう。
それから、今時のシステムにはサーバやスイッチのみならず、大小様々なアプライアンスが含まれる。それもアプライアンスが基幹装置だったりすることは全く珍しくないので、こいつらの監視は非常に重要なのだが・・・俺はこのアプライアンスというやつに全く興味が持てなかった。
真面目な運用者なら仕組みや機能を率先して調べ、業務改善や次期システムの提案に噛ませるなんてするんだろうけど、俺の場合「よくわからんブラックボックスで、でもなんかよろしくやってんだね、じゃあそれでいいんじゃね？」程度にしか思えず、出来れば障害の1つも起きないなら無視したいものだった。
これはもう運用者としては致命的にダメなセンスだろう。開発で例えるなら「ミドルウェアに興味ない」とか「クラスライブラリやフレームワークに興味ない」と言っているようなものである。
そうそう、開発と運用の違いと言ったら、確実に対立するポイントがある。
それは非機能要件の取り扱い。
開発にとって非機能要件というのは「障害発生時の検証用や、機能要件の異常系処理など、恙無くシステムを動かすのに最低限必要な仕組み以外は手を出したくないもの」だったりする。基本的に手を入れ始めたらキリがないので、やればやるほど仕事が増えてしまうのに、それに見合ったカネも時間も用意されていないことが多い(というかそんな見積もりを客に出すのは無理)からである。
一方の運用にとっては「機能要件は満たせていて当たり前で、その上で特に障害時の対応を中心とした非機能要件はきちんと作られるべきもの」である。システムトラブルで矢面に立つのは運用者であり、そこで手も足も出なければ存在意義を問われるのだから当然だろう。
このように非機能要件だけ取っても、同じシステム屋なのに見ているポイントが全く違う。
「正直気にしたって仕方ないような細かいところまで質問してきて、いちいちこっちの回答を言質に取って、その上で文句ばっかり付けてくる面倒な奴ら」
「いつも中途半端なモノを作り逃げし、いざという時も要領を得ない曖昧なことしか言えない、信用出来ない奴ら」
となる。
こういう、ともすれば対立の原因になる認識の違いを踏まえ、身も心も運用者になることが、俺にはできなかったと言ってもいい。
というわけで、これから俺はまた開発に戻る。
「流しのオッサンコーダー」として半年～1年単位で現場を点々とすることになると思うが、何年も椅子に座ってログを眺めているようで眺めていないよりは会社に貢献できるだろう。
或いは若手開発者育成という名の、ブラックな環境に飲まれないノウハウとか、「ハイリスクノーリターン」を避けるサバイバル術伝授とかやってもいいかなーと思っている。若手をOJTで潰すのは許せないので。
この場合、「この人にはどういう言い方をしたら通じるのか」という問題が今以上に重要になるだろうけど、それくらいは受けて立たないとという感じ。
追記歓迎
| 言葉 | 意味 |
|---|---|
| 議事録 | 気が変わる前の意見 |
| 非機能要件 | 実装するかは気分次第 |
| 確認しておきます | 今日は帰ります |
| オブジェクト指向 | オ○ニー |
| 偉い人の意見 | パルプンテ |
| ちょっとした仕様変更 | ザキ |
| 客先担当者の急な交代 | ザラキ |
| 要件定義から見直し | ザラキーマ |
| 確定した仕様 | 幻想 |
| WBS | Sはサグラダファミリア |
| キーマン | 鬱病になりにくいことがわかってる人 |
| ベストプラクティス | モジュール化されてません |
| 増員 | 導入教育で作業が止まる |
| それは新しい方法ですね | 問題がおきたらお前が対応しろ |
| 操作手順書 | 唯一多少参考になる設計ドキュメント |
| 備考 | 最も重要な考慮事項 |
| ＸＸはリスク | 問題が起きる(起きてる)けど俺は知りません |
| 試験のエビデンス | 誰も見ないけど一番手間のかかるもの |
| ペアコーディング | 今日はだるいから流すわ |
| すべての入力パターンを網羅したテスト | 1ケース0.1秒で実行しても宇宙が終わるほうが早い |
| フレームワークのバグ | 仕様です |
| カバレッジ100% | 不具合だらけですがコンパイルエラーはありません |
| トレードオフ | この仕事やるのと休日出勤どっちがいい？ |
| 動きます | 完成度10% |
| 一部のエラー処理がまだ | 完成度20% |
| 誰かの独自フレームワーク | お前はしぬ |
| 会社の独自フレームワーク | みんなしぬ |
