こんにちは！ひさふるです。
最近、Loop Engineeringという、プロンプトではなくループを設計するという手法がバズっていましたね。
要は、人間がプロンプトを書くのはもう古く、これからはAI自身にプロンプトを書かせる時代だ、という手法の話でした。
では、さらに時代が進んだとき、人間は何を設計するのでしょうか？
私は、確実に人間中心デザインがエンジニアリングの中心となり、人から"意図"を引き出すための設計がメインになると思っています。
今回は、そんなお話をしていこうと思います。
次に人間が「設計」するものは何か？
AIエンジニアリングの進化
これまで、AI関連のエンジニアリング手法は大まかに以下のように変化してきました。
| 手法 | 説明 |
|---|---|
| Prompt Engineering | AIに与えるプロンプトを作成・調整することで、望む結果を得る |
| Context Engineering | 生成AIに与えるあらゆる情報（コンテキスト）を改善・取捨選択することで応答を最適化する |
| Harness Engineering | 生成AIを安全かつ効率的に稼働させるための環境（＝ハーネス）を設計する |
| Loop Engineering | 生成AIが目標達成まで自律的に実装・検証を回せるためのループを設計する |
| ??? Engineering | 次に設計するのは何か？ |
これらの用語は、人が何を設計してきたかを示しています。
この整理では、プロンプトから始まり、コンテキスト全般、そして実行環境たるハーネスへと設計対象が広がります。
さらにループエンジニアリングでは、人間は個々のプロンプトではなく、AI自身が実装と検証を繰り返すループ機構そのものを設計します。
では、次に人間が設計するものは何なのでしょうか？
次はIntent Engineering？
近年、Intent Engineering（意図の工学）という言葉も使われるようになりました。
本記事では、Intent Engineeringを次のような考え方として認識します。（※Intent Engineeringはまだ定まった定義がないので、私が色々な記事を読み解いた内容です）
HOW（どのように実装するか）だけでなく、WHAT（何を達成したいか）を、目的・成功条件・制約・評価方法として記述し、AIがその達成に向けて行動できるようにすること
要は、生成AIの進歩によって設計・実装の多くは"丸投げ"できるようになったため、"どうやって実装するか"よりも"何をしたいか"をAIにわかりやすく伝える方が大切だ、という理論なわけです。
これは、AIエージェントを安定して動かすうえで、とても重要な考え方だと思います。
また、これは段々と開発者が開発そのものをAIに明け渡し、興味の中心がより"意図"や"やりたいこと"にシフトしてきた証拠だと思っています。
Intent Engineeringのさらに手前にある問題
一方で、ここにはさらに手前の問題が残っています。
それは、記述すべき意図そのものを、どうやって見つけるのかという問題です。
例えば、開発者が「AIエージェントを使ったプロダクトで売上を上げたい」と考えていたとしても、
- AIエージェントを使うことは本当に制約なのか
- 売上以外の成功条件はないのか
- 誰の、どんな課題を解決すればその意図が達成できるのか
- 開発者の思惑と、実際に使うユーザーの意図は同じなのか
といったことは、最初から明確とは限りません。
そもそも、開発者自身が自分の意図を正しく認識し言語化できるとも限りません。他人であるユーザーの意図を汲むとなった場合は、なおさらです。
つまり、Intent Engineeringが意図を実行可能な仕様へ変換する工学だとすれば、その入力となる意図を発見し、現実で検証し、更新する工程が必要になります。
Intent Engineeringが「意図をどう実現するか」を扱うなら、「そもそも何を意図として扱うべきか」を問い、検証する工学が必要
Inquiry Engineering：「意図を汲む」ために「問いを設計」する
ここまで見てきた通り、AIに意図を正確に伝える以前に、そもそも誰の、どんな意図を扱うべきなのかという問題が残っています。
そこで私は、この問題を扱うための方法論として、Inquiry Engineeringを提唱したいと思っています。
定義は以下のようになります。
Inquiry Engineering：AIが、開発者への問いから、言語化されていない意図・制約・課題を引き出し、実ユーザーの発話や行動から意図・制約・課題の仮説を立て、検証するための証拠を得られるように、「問いの規律」を設計する方法論
複雑な言い回しになってしまいましたが、要するに
- 開発者やユーザー自身から意図を正しく引き出すためには、"問い"の設計が重要
- その"問い"の設計は人間が行っていたが、それをAIに肩代わりさせるための方法論
が、Inquiry（問い）Engineeringというわけです。
HCD（人間中心デザイン）との関連性
Inquiry Engineeringは、HCD（人間中心デザイン）の考え方を大いに参考にしています。
HCDでは、利用者視点を重視し、利用状況や要求を理解・明示したうえで、解決策を作り、評価し、必要に応じて見直すことを繰り返します。
Inquiry Engineeringは、HCDそのものを置き換えるものではありません。HCDで培われてきた「誰に何を問い、どの証拠から要求を理解し、どう検証して更新するか」という実践知を、AIが回す問いの規律として実装し直す試みです。
AIによって実装の速度が上がるほど、利用者の実態を理解し、仮説を現実で検証する工程の重要性はむしろ増していきます。
Inquiry Engineeringの構成要素：「誰に」「何を」問うのか？
大切な前提として、Inquiry Engineeringでは意図を汲むべき相手は2種類存在します。
それは開発者とユーザーです。
また、それぞれから、意図、制約、課題の3つを引き出す必要があります。
ただし、開発者とユーザーでは、情報を集める入口が異なります。
開発者は、自分の意図について直接対話できます。一方でユーザーからは、意図が直接整理された形で出てくるとは限りません。
そのためユーザーについては、まず利用状況・過去の行動・発話を集め、そこから意図を仮説として導きます。
1. 開発者の意図・制約・課題
開発者側の意図・制約・課題は、A.G. LafleyとRoger L. Martinの共著『Playing to Win』が示す、Winning Aspiration・Where to Play・How to Winと似ています。
まず、開発者には開発者自身の意図があります。先述のIntent Engineeringでは主に開発者の意図が主軸となっています。
例えば、"AIエージェントを活用したプロダクトを開発して売上を出したい"というものが、開発者の意図になるでしょう。これは、Winning Aspirationに近い目標として捉えられます。
制約では、ズラせない前提を明らかにします。例えば、上記の例ではAIエージェントを活用したプロダクトという前提はズラせないのでしょうか？他のプロダクトで売上を上げるのはダメなのでしょうか？
また、成果は売上がすべてなのでしょうか？社内に展開し、業務効率化を達成するのではダメなのでしょうか？
このように、本当にズラせない制約をあぶり出すことが重要です。これは、Where to Playを考えるときと同じく、どの領域で戦うかを明確にするための作業です。
最後に、確定した制約の範囲で課題を定義します。
最終的に"AIエージェントアプリで売上を出す"ことが前提（制約）となった場合、昨今のAI市場ではChatGPTが最大の敵になります。
ChatGPTは様々なアプリに接続して、大抵のことはChatGPTだけでもできる、と言えるほどになりました。
そのような状況を加味した上で、本質的な課題は"ChatGPTとは独立して存在する価値のあるAIエージェントアプリを作ること"と定義することができます。（これはあくまで一例ですが）
このように、自分自身の意図を深掘りし、プロダクトの制約を引き出すことで、より本質的な課題を設定しやすくなるのです。
第一段階として、開発者本人が自分の意図と制約を認識し、そこから本質的な課題を設定する
2. ユーザーの意図・制約・課題
続いて、実際にプロダクトを使うユーザー側の意図・制約・課題を考えます。
ただし、ユーザーに対して「あなたの意図は何ですか？」と直接聞いても意味がありません。
ユーザー自身が、自分の本質的な要求や行動の理由を明確に認識しているとは限らないからです。これは、HCDの文脈でもよく言われています。
そのため、ユーザーの場合はインタビューやアンケートを通じて利用状況・行動・経験から最初に"制約"を導き出します。
例えば、あるエレベーターの待ち時間が長いことが問題となっているとします。
ここで、ユーザーに直接「何を解決したいですか？（意図は？）」と問えば、「待ち時間を短くして欲しい」と返ってくるでしょう。
しかし、それだけが唯一の正解とは限りません。ユーザーの行動を観察してみると、実はエレベーターが遅いことによる実害はそれほど出ていないことに気がつけるかもしれません。
つまり、"エレベーターを早くすること"は制約ではなかったのです。
そうすると、"課題"は例えば"エレベーターの待ち時間を退屈にさせないためにはどうすれば良いか？"と設定することもできます。
このように、ユーザーから直接出てきた意図が問題の本質を捉えているとは限らないのが、このステップの難しいところです。
ユーザーからは正しい意図が直接出てくるとは限らない。ユーザー状況の観察から制約を導き出し、本質的な課題を設定することが重要
Inquiry Engineeringで問うもの
ここまでのまとめです。
Inquiry Engineeringでは、主に開発者とユーザーそれぞれから、意図、制約、課題を抽出することを目指します。
| 開発者 | ユーザー | |
|---|---|---|
| 意図 | 開発者がプロダクト開発を通じて最終的に得たい状態。後続の制約や戦略課題の選択に差を生むまで掘り下げる。 例）AIエージェントを組み込んだプロダクトで売上を上げたい |
ユーザーが持つ本質的な要求。HCDの考え方においては要求は単なる質問では直接的に抽出することができず、インタビューや行動観察から状況を把握し、仮説として整理する。 例）エレベーターを早くしたい（が、これは本質的ではない） |
| 制約 | 課題を設定するときに守るべき制約。開発者自身やAI自身は、守らなくてもよい事柄を「制約」として思い込むことがある。「制約」を疑うことが、本質的な課題設定の第一歩である。 例）AIエージェントが価値の中核となっていること |
ユーザーの状況から導出される、課題設定で守るべき制約。これ自体が、本質的な課題設定のカギとなる。 例）エレベーターの待ち時間に発生するユーザーの不満を解消すること |
| 課題 | 意図を達成するために、本質的に解決するべき課題。単に「プロダクトを作ること」ではなく、そのプロダクトがどのような状態を満たしていればよいかに着目する。 例）ChatGPTと差別化でき、独立のアプリとして存在する価値があるプロダクトを作る |
ユーザー自身も認識していない、本質的な問題を解決するための課題設定。 例）エレベーターの待ち時間を退屈にしないためにはどうしたら良いか？ |
開発者自身は、自分が認識している制約や課題が本当に疑いようがない確定したものなのかを、自分自身に問うことで、それを言語化します。
ユーザーに対しては、利用状況・行動・発話を集め、潜在的な意図・制約・課題を導出します。
さて、Inquiry Engineeringでやることはこれでわかりましたが、本質はここからです。
これまで、この作業の質はHCDの知識や実践経験に大きく依存していました。Inquiry Engineeringでは、問いの設計、記録の整理、仮説の更新といった一部を再現可能な手順へ落とし込み、生成AIに委譲します。
人間は、制約を確定すること、証拠の採否を判断すること、最終的な拒否権を担います。
Inquiry Engineeringでは、"問い"そのものをAIに移譲する
Inquiry Engineeringで設計するもの
ここまで語ったことは、正直AIが無くてもできることでした。
Inquiry Engineeringでは、これをAIが主導して行い、人間が必要な判断に集中できるようにするために、"問えるAI"を設計します。
では、AIには具体的にどんな「問い」の能力を持たせればよいのでしょうか。
前提を問う能力
前提を問う能力とは、AIが「これは動かせない」と思い込んだものを、鵜呑みにせず疑い直す能力のことです。
疑う対象は制約、課題の入口、実現可能性の3つに分類できます。
①制約を問う能力
これは、開発者から入力された情報を鵜呑みにせず、前提を疑える能力になります。
そもそも、現在のAIは与えられた情報を誤った形で扱うことが多いです。
- 制約の過剰生成：与えられた情報を制約だと勘違いし、それを守るように行動する
- 制約の過剰緩和：与えられた制約を制約として扱わず、最終的に違反する
これは、結局のところ与えられた情報の誤分類という問題に帰着します。
具体例を挙げて説明すると、以前私がDevOps × AIエージェントがテーマのハッカソンのアイデアを壁打ちしているとき、AIは勝手にDevOpsを効率化するプロダクトであることを制約として扱い始めました。
しかし、ルールや採点基準にはそのような記述はなく、単にリリース後の運用まで考慮されていることという評価基準があるのみでした。
確かにDevOpsを効率化するプロダクトも悪くはないのですが、それ自体は制約ではなく、この勘違いは生成されるアイデアの幅を大きく制限してしまいます。
そのため、「これは制約なのか？単なる事実なのか？」という「前提を問える能力」をAIに与えることが重要となるのです。
これを解決できる方法は色々あります。例えば、与えられた「制約だと思われる情報」を分類させてみればよいのです。
| 分類 | 説明 |
|---|---|
| 所与 | 根拠が確認でき、現時点で人間が守ると承認した制約 |
| 仮定 | 根拠が未確認のまま、制約になると推測されている事柄 |
| 未指定 | 根拠となる情報源を特定できず、判断材料も足りない |
まず、"仮定"や"未指定"についてはそもそも制約として扱うための根拠がなかったので、勘違いだったということがわかります。
また、ここで重要なのが、AIに所与に対する反例チャレンジをさせることです。
実は、人間が「これは絶対条件です」と申告した制約にも、思い込みが混ざることがあります。例えば、開発者が無意識に「BtoC向けサービス」という前提を置いている場合です。
これに対して「本当にそうですか？」と抽象的に聞き返しても、思い込みは表面化しません。本人は本気でそう信じているからです。
そこでAIには、具体的な反例（例：「BtoB向けに、この価格で、この利用シーンで売るのはダメですか？」）を開発者に提示させます。
「営業チームがいないから成立しない」のように反例が成立しない理由を名指しできれば、それは本物の制約と言えるでしょう。逆に「なんか違う」としか言えなければ、それは思い込みかもしれません。
ただし、制約を緩めるかどうかの最終決定はAIにさせてはいけません。AIの仕事は思い込みの可視化までであり、決定は必ず人間が拒否権を持つ形にします。
②課題の入口を問う能力（水平思考）
続いては、定義した課題から解決策を考えるときに必要な能力です。
これも「前提を問う」能力の1つです。
ただし今度は制約ではなく、「この課題は、こう解くものだ」という解き方の前提を疑います。言い換えると、課題への入口を問う能力です。
基本的にAIは垂直思考、つまり論理的に根拠がつながった解決策を導き出します。逆に「水平思考をして」と言うと表向きにはそれっぽいアイデアが出てきますが、飛躍しすぎてしまうこともあります。
つまり、飛距離と論理を両立した「論理的な水平思考」ができないのです。
では、どうすればAIに水平思考をさせられるのでしょうか。手順は3ステップに分けられます。
- ステップ1：今思いつく解決策を、先に書き出させる
- ステップ2：入口をずらす（課題を言い換える）
- ステップ3：もとの課題につながっているか確認する
ステップ1は、まず今のアイデアの現状を認識するためのステップですね。
ステップ2では実際に水平思考を行います。単に"水平思考で考えて"とAIに伝えるだけでもある程度やってくれると思いますが、水平思考でよく使われる"SCAMPER法"などのメソッドを指定してあげると、なお良いでしょう。
最後のステップ3が最も重要です。ここでは、以下のような確認をAIに行わせます。
言い換えた課題は、もともと定義した他の制約を満たしているか？そして、開発者やユーザーの本質的な意図を、ちゃんと達成するものになっているか？
先程のエレベーターの例で、今度は"エレベーターが遅くて遅刻者が出ているから、速度向上は必須"という制約があるとします。この場合は、"待ち時間を退屈にさせない"という解決策は不適切ですよね。
面白いのは、創造性の質を決めるのはアイデアの飛距離ではなく、このつなぎ直しの精度だということです。いくらアイデアが遠くへ飛んでも、元の制約と意図に着地できなければ、ただの思いつきで終わってしまうわけですね。
③実現可能性を問う能力
最後は、AIが「これは無理だ」と思い込んだときに、その実現可能性の前提を疑う能力です。
AIは、実現可能性を一般的な前例や標準的な工数で見積もってしまうことがあります。
「一般的に、この規模の調査には数週間かかります」、「通常、この工数では難しいでしょう」……みたいな出力、見たことありませんか？
これに対しては、以下のような制御を行います。
- 「難しい」を結論ではなく出発点にさせる：その難しさが何の前提に依拠しているのかを列挙させる
- 前提を1つずつ揺さぶらせる：「AIエージェントが使える前提なら崩れないか？」、「この状況に固有の何かで崩せないか？」
本質的な課題解決には、時には難しいと思われる問題にも立ち向かう必要があります。
一般論で可不可の結論を出させるのではなく、解決の糸口を見つけられるようにAI自身に試行錯誤させることが大切です。
ユーザーに問う能力
ここからはもう1つのグループ、つまり現実のユーザーに対する問いを扱う能力です。
これは能力というより今までそもそもできなかったことです。
まず、HCDの前提を思い出しましょう。
先述の通り、ユーザーの意図は、直接質問するだけでは十分に抽出できないことがあります。「何が欲しいですか？」と聞いても、本人がそれを明確に言語化できているとは限らないからです。
さらに、こちらが立てた解決策も、あくまで「仮説」に過ぎません。だからこそ、プロトタイプを作ってユーザーに当て、その仮説が本当に正しいのかを高速に検証し続けることが求められます。
そして、この「意図の抽出」と「仮説の検証」は、構造化された定量的なアンケートでは不足します。
「満足度を5段階で」のようなアンケートは、集計はしやすいのですが、本人も気づいていない意図や、言葉にならない不満までは掘れません。
ここで重要になるのが、半構造化インタビューや、文脈による質問法（コンテクスチュアル・インクワイアリー）です。大枠だけ決めておき、相手の答えに応じて動的に掘り下げたり、実際に使っている現場で、その文脈ごと観察しながら問う、というやり方ですね。
これらは、実際にHCDの現場ではよく活用されます。
「量」と「質」のトレードオフ
問題は、これらがとにかくコストが高いことでした。
半構造化インタビューをするには、これまで人間のリサーチャーやインタビュアーが介在するしかありませんでした。
そして人間の介在はコストが高く、遅く、少人数にしか届きません。だからこそ、検証は常に開発のボトルネックであり続けたわけです。
つまり、従来は「量」と「質」の間に強いトレードオフがありました。
アンケートは量を稼げる一方で浅くなりやすく、インタビューは深い一方で少人数にしか届きません。限られた時間と予算のなかでは、両方を十分に確保しにくかったのです。
インタビュアーエージェントを「配布」する
ここでAIの出番です。AIが直接ユーザーと対話できれば、人間が一件ずつ聞き取る負担を大幅に減らせます。
とはいえ、意図の抽出から仮説検証まで、そのすべてをAIに丸投げするのは、まだ難しいのが正直なところです。
そこで、その第一歩として私が提案したいのが、大まかな質問項目や聞きたいことだけを教えたAIエージェントを、インタビュアーとして送り込むという手法です。
イメージとしては、今までアンケートを配布していたところを、インタビュアーエージェントを配布する、という感じですね。
こうすると何が嬉しいか。
エージェントなら、相手の答えに応じて動的に掘り下げながら、多数のユーザーと並行して対話できます。つまり、アンケートを配布するのに近い規模で、静的なアンケートより深い一次情報を得られる可能性があります。
このトレードオフを緩め、より多くの一次情報をもとに高速な検証ループを回せるようにする。これがユーザーに問う能力の、いちばんの狙いです。
全体の流れ：HCDのプロセスに照らし合わせる
ここまでで、Inquiry Engineeringで問うもの（開発者とユーザー、それぞれの意図・制約・課題）と、そのためにAIへ与える能力を説明してきました。
では、これらは開発全体のどこで、どの順番で使われるのでしょうか？
この流れは、HCDの基本プロセスを骨格として、Inquiry Engineering向けに次のように再構成できます。
HCDの基本プロセスは、計画から始まり、要求定義⇒具現化⇒評価を反復し、運用に至る流れです。
計画 → 〔 要求定義 → 具現化 → 評価 〕を反復 → 運用
これをInquiry Engineeringに対応させると、以下のようになります。
| HCDの工程 | Inquiry Engineeringでやること | 使う能力 |
|---|---|---|
| 計画 | 開発者の意図・制約・課題を定義する | 制約を問う能力 |
| 要求定義 | ユーザーの意図・制約・課題を仮説として定義する | ・制約を問う能力 ・ユーザーに問う能力 |
| 具現化 | 課題から解決策の仮説を立て、その仮説が反証可能になるように検証方法まで設計したうえでプロトタイプを作る | ・課題の入口を問う能力 ・実現可能性を問う能力 |
| 評価 | 具現化で設計した検証方法を誘導・確証バイアスの観点から点検し、インタビューや行動観察として実行する | ・ユーザーに問う能力 |
| 評価⇒要求定義 | 観測結果を解釈し、仮説（＝意図の理解）を更新して次の周回へつなぐ | ・前提を問う能力 |
では、計画から運用まで、各工程で具体的に何をやるのかを1つずつ見ていきましょう。
①計画：開発者に問う
最初の工程です。ここでは、開発者側の意図⇒制約⇒課題を定義します。
「制約を問う能力」を開発者本人に向けて使い、「本当に守るべき制約は何か」を炙り出し、そこから戦略課題（＝意図を達成するために本質的に解くべき課題）を導きます。合わせて、締切・使えるリソースといった「事実」や「ペルソナ」も、ここで登録しておきます。
②要求定義：ユーザーに問う
ここから、HCDの反復ループに入ります。
計画で固めた枠（戦略課題・制約）の中で、今度はユーザー側の意図・制約・課題を、仮説として定義します。
この工程では、実際のユーザーにインタビューし、過去の行動・利用状況・困った場面を問い、可能なら利用現場を観察します。
そこから、意図・制約・課題を定義するのですが、この段階ではこれらは"仮説"であることに注意が必要です。
③具現化：解決策を作る
定義した課題から、解決策の仮説を立て、プロトタイプを作る工程です。
解決策を考えるところでは「課題の入口を問う能力」、すなわち水平思考が効きます。
発散させて、元の制約と意図に収束させる。実装そのものは、既存のcoding agentに任せる領分です。
HCDでも、"発散"と"収束"はダブルダイヤモンドプロセスという有名なフレームワークで用いられています。
また、ここで悩ましいのが、プロトタイプをどこまで作り込むかです。
従来のHCDでは、紙やワイヤーフレームのようなローファイプロトタイプから始め、少しずつ忠実度を上げることが基本でした。
しかしAIによって、実装のコストは非常に小さくなりつつあります。もはや、紙でプロトタイプを作るのと同等の速度で、動くプロトタイプが作れるようになっています。
したがって、Inquiry Engineeringでは「必ずローファイから始める」とは考えません。
判断基準は、最も短い時間で、必要な学びを得られる形は何かです。
検証に必要な要素を備えた最低限、すなわちMVP（Minimum Viable Product）を見極めることが重要になります。
④評価：仮説を検証する
作ったプロトタイプを、実際のユーザーに当てて検証する工程です。
ポイントは、仮説を「支持する」のではなく「反証する」方向にも検証することです。
AIにインタビュアーを任せると、どうしてもユーザーに同意する方向に話が進んだり、与えた前提を支持するようになりがちです。
あくまでフラットになるように、立てた仮説(=解決策)を反証する動作も一部組み込んでおくことで、よりフラットな効果を測定できるようになります。
⑤評価⇒要求定義：解釈して、意図を更新する
最後に、得られた検証結果を解釈して、必要ならユーザーの意図を更新します。
作ったプロダクトでは思ったような反応が得られなかった場合、それはそもそも立てた仮説(=仮定したユーザーの意図)が間違っていた可能性があります。
この改善ループを回すことがInquiry Engineeringの重要なポイントであり、さらにHCDの根幹を成す行為でもあります。
HCDのプロセスを骨格として、人間の判断と現実のユーザーによる検証をゲートにしながら、「問い⇒仮説⇒検証⇒更新」のループをAI主導で回す。これがInquiry Engineeringの全体像である。
Inquiry Engineering自体も、まだ仮説である
正直、Inquiry Engineering自体まだまだ仮説に過ぎません。
しかし、この多くは理想論に過ぎませんが、一方で良いプロダクトを作るためにはいくら開発が高速化してもダメで、本質的な課題設定や意図の抽出は避けては通れないと思っています。
そこで、今後は人間中心デザインを中核として、それをさらにAIで効率化する方法論が語られてゆくと信じています。
おわりに
……というわけで、「次に人間が設計するもの」についてのお話でした。
こうして系譜を眺めると、人間の設計対象はどんどんメタな方向へ押し上げられています。
プロンプトを書き、コンテキストを整え、ハーネスを組み、ループを設計し、そして「問い」の設計すらAIに任せるようになったとき……最後に人間へ残るものは何なのでしょうか？
私は、「意図の発生源であること」そのものだと思っています。
「AIに何を望むか」を最終的に持つのは人間です。望みの源泉は、望む主体の外には置けません。
だから最後に残るのは、望みを発すること、事実を差し出すこと、そして出てきたものに文句を言うこと。
それだけで開発が回る世界を目指して、Inquiry Engineeringを提唱してみた次第です。
ここまで読んでいただき、ありがとうございました！