おいでなすったー

テーマとか宣言すると一夜坊主で終わることがわかったので、そういうのやめて、書き散らかしていきます

ChatGPTさんとのチャット04/15

きみって英語の方が得意なんじゃないの問題について本人にききました。しかしこれ、テキトーに話合わせてんじゃないの？って裏を取るの結局大変だよな。

 

な：

あなたは、日本語で指示された場合と英語で指示された場合で、アクセスできる知識の範囲に違いがありますか？例えば、日本語でしかレシピの情報が存在しない料理の作り方を聞かれた場合、日本語でやり取りする場合しか回答が得られないというようなことが起こるのでしょうか？

 

GPT-4：

私は、日本語でも英語でもアクセスできる知識の範囲に大きな違いはありません。私の学習データには、多くの言語での情報が含まれています。ただし、ある言語でのみ情報が存在する場合、その言語でやり取りすることが望ましいです。しかし、一般的には、私は異なる言語間で知識を翻訳し、適切な回答を提供することができます。したがって、日本語でしか存在しないレシピの情報がある場合でも、英語でやり取りしているユーザーにも適切な回答を提供することができると考えられます。ただし、翻訳の精度や、特定の文化や言語に関連するニュアンスを完全に捉えることは難しい場合があります。

 

な：

日本語話者の間では、あなたに質問をするとき、日本語よりも英語の方がよい回答が得られる（日本人が日本語でやり取りするより、日本人が英語でやり取りする方が正確な回答が得られるという意味です）という意見があります。それが本当だとすると、どんな原因が想定できるでしょうか。質問者があなたにプロンプトを入力する場面での問題と、あなたが回答を生成する場面での問題のそれぞれの側面について聞きたいです。step-by-stepで整理してみてください。

 

GPT-4：

このような意見がある理由は、いくつかの要因が考えられます。以下に、質問者がプロンプトを入力する場面と、私が回答を生成する場面でのそれぞれの側面について整理してみます。

質問者がプロンプトを入力する場面での問題:

  1. 言語の違い: 日本語と英語は文法や構造が大きく異なるため、質問者が英語で質問をする際、日本語での質問よりもシンプルで明確になることがあります。
  2. 技術用語や専門用語: 日本語話者が英語で質問をする際、技術用語や専門用語が正確に使用されることがあり、私にとって理解しやすくなる場合があります。

私が回答を生成する場面での問題:

  1. 学習データの偏り: 私の学習データは英語の情報が多く含まれているため、英語での回答がより正確で詳細になることがあります。
  2. 翻訳の問題: 知識が異なる言語間で翻訳される際、精度が低下する可能性があります。これは、特定の文化や言語に関連するニュアンスを完全に捉えることが難しいためです。

ただし、これらの要因は一般的な傾向を示すものであり、個々の質問や回答には必ずしも当てはまらないことに注意してください。私は日本語でも英語でもできる限り正確な回答を提供することを目指しています。質問者が自分の母国語で質問をすることで、自分の思考やニュアンスを正確に伝えることができる場合があります。そのため、日本語話者にとって、日本語で質問をすることが適切な場合もあると言えます。

 

な：

「学習データの偏り」の問題について追加の質問をします。

例えば、プログラミングにおいて、あるライブラリの使い方を知りたい場面を想定してみましょう。このライブラリの公式ドキュメントは英語で、issueのやりとりなども英語が主だとしてください。このライブラリを使っている人は日本にも大勢いて、Qiitaなどで使い方や自分で使ってみたメモを公開している人が居ます。しかし、日本でこのライブラリを使っている人は、最初に日本語の紹介記事を書いた人が公式ドキュメントの内容をよく理解していなかったため、あまり上手ではない使い方をしてしまっており、2番手、3番手の記事を書いた人も、日本語の1番手の情報を見ているので、総じて当該ライブラリに対する日本語記事の情報が的確ではなくなっていしまっている、と仮定します。

このような状況で、このライブラリの使い方を日本語で質問したときと英語で質問したとき、あなたの回答の質は、言語の違いに影響されますか？

 

GPT-4：

このような状況では、言語の違いが回答の質に影響する可能性があります。私は学習データに含まれる情報を基に回答を生成しますが、その学習データに偏りや誤った情報が含まれている場合、それが私の回答にも反映されることがあります。

具体的には、日本語で質問された場合、私は主に日本語の記事や情報を参照して回答を生成します。仮定された状況では、日本語の情報が的確ではないため、私の回答も正確でない可能性があります。一方、英語で質問された場合、私は英語の公式ドキュメントやissueのやりとりなど、より正確な情報に基づいて回答を生成できるため、回答の質が高くなる可能性があります。

ただし、私は複数の言語間で知識を翻訳し、適切な回答を提供することを目指しています。そのため、日本語で質問された場合でも、英語の情報を参照して回答することができる場合があります。しかし、言語間の翻訳や、特定の文化や言語に関連するニュアンスを完全に捉えることが難しいため、回答の質が言語の違いに影響される可能性があります。

 

な：

あなたはプログラミング言語についてもある程度の理解を持っていると思います。例えば、先ほどの例で、問題のライブラリに関する日本語の記事で示されたコードが明らかに間違っているというような場合、あなたは、質問に対する回答でこれら日本語の記事の内容をあまり重視するべきでないな、と判定とか重みづけできたりするのでしょうか？

 

GPT-4：

私はプログラミング言語に関する知識を持っており、コードが正しいかどうかをある程度判断することができます。しかし、私の判断力や知識も学習データに基づいていますので、限定的です。日本語の記事で示されたコードが明らかに間違っていると判断できる場合、私はその情報を回答に使用しないように努めます。

しかし、間違いが明らかでない場合や、私の知識が不十分な場合は、日本語の記事の内容を参照して回答を生成する可能性があります。このような状況では、私が提供する回答の質に言語の違いが影響することがあります。

私は異なる言語間で知識を翻訳し、適切な回答を提供することを目指しています。そのため、日本語で質問された場合でも、英語の情報を参照して回答することができる場合があります。ただし、言語間の翻訳や特定の文化や言語に関連するニュアンスを完全に捉えることが難しいため、回答の質が言語の違いに影響される可能性があります。

 

な：

αという課題があるとします。この課題は、日本語とか英語という言語の違いに無関係のものです。
このαを解くアルゴリズムにAとBの2種類があり、pythonで記述したコードがあるとします。これも、日本語とか英語とは関係のないことです。

こうしたアルゴリズムとpythonでの実装について解説した記事があって、日本語の記事ではAが解説されていて、英語の記事ではBが解説されているとします。記事の意味を理解すれば、どちらもαを解く話をしていると理解しうるものとしてください。

このような学習データがあったとき、あなたがαを解決する方法について日本語で聞かれた場合、BよりもAを主眼に置いて回答するということが起こりますか？

 

GPT-4：

私は学習データをもとに質問に回答しますが、その過程で複数の情報源を参照し、最も適切な回答を生成しようとします。そのため、あなたが仮定した状況においても、私は日本語で聞かれた場合にAだけに焦点を当てるとは限りません。

日本語で質問された場合でも、英語の記事に記載されているBについても情報を提供できる可能性があります。ただし、言語の違いや翻訳の精度などの要因により、回答の内容や質に多少の違いが生じる可能性があります。

例えば、回答においてAとBの両方に言及することができる場合でも、日本語で聞かれた場合はAについてより詳しく述べ、英語で聞かれた場合はBについてより詳しく述べるといった違いが生じるかもしれません。

ただし、私は常に最も適切な回答を提供することを目指しており、異なる言語間で知識を翻訳し、適切な回答を提供できるよう努めています。

 

な：

同じαを解決するアルゴリズムでも、その方法の優劣というものはあるわけです。あなたは、効率のよいソートアルゴリズムを挙げよと言われた場合に、恐らく選択ソートを筆頭に挙げることはないと思います。課題αの解決法の例でも、日本語の説明が存在するAよりも英語の説明が存在するBが優れた方法であるとプログラミング一般のベストプラクティスから判断できるようなとき、あなたは日本語での質問であっても、Bを優先して答えてくれるということになりますか？

 

GPT-4：

私は最も適切な回答を提供することを目指しており、プログラミングの一般的なベストプラクティスや効率性に基づいて回答を生成します。そのため、課題αの解決法においてBが明らかに優れた方法であると判断できる場合、日本語での質問であってもBを優先して答えることがあります。

ただし、私の回答は学習データに基づいており、言語の違いや翻訳の精度などの要因により、回答の内容や質に多少の違いが生じる可能性があります。そのため、日本語での質問でAについても触れることがあるかもしれませんが、Bが優れた方法であるという情報を反映して、Bについても説明するように努めます。

 

な：

逆に、AとBに他の差異が見出せない場合には、あなたは日本語の質問には日本語の解説があるＡを重く用いた方がよいと判断しますか？

 

GPT-4：

AとBに他の差異が見られない場合、私は質問の言語に応じて情報源を選択することがあります。つまり、日本語での質問に対しては、日本語の解説があるAを重視して回答することがあります。これは、質問者が日本語で質問していることから、日本語の情報源にアクセスしやすいと推定されるためです。

ただし、私は異なる言語間で知識を翻訳し、適切な回答を提供することを目指しています。そのため、日本語で質問された場合でも、英語の情報源であるBを参照して回答することができる場合があります。

実際の回答内容は、質問の文脈や具体的な状況に応じて異なりますが、私は常に最も適切な回答を提供することを目指しています。

 

な：

あなたは複数の回答の候補の中から適切なものを採用しようとしてくれるが、その適切性を判断する要素の一つとして、学習データの言語と質疑の言語の一致ということもあるのだ、という理解でよいですか？

 

GPT-4：

はい、その理解で正確です。私は複数の回答の候補の中から最も適切なものを選択する際、学習データの言語と質問の言語の一致を一つの要素として考慮します。質問の言語と同じ言語で書かれた情報源が、質問者にとって理解しやすいと推定されるためです。

ただし、言語の一致だけでなく、他の要素も考慮して適切な回答を生成します。これには、情報の信憑性や質問の文脈、具体的な状況などが含まれます。私はこれらの要素を総合的に判断し、最も適切な回答を提供することを目指しています。

 

な：

i see. thank you so much.

 

GPT-4：

You're welcome! If you have any more questions or need further assistance, please don't hesitate to ask. I'm here to help!

 

ChatGPTさんとのチャット04/13

いまだに「ChatGPTと○×ゲームがしたい」ことを何とかしたいと思っており、真面目な方向からカーブを投げてみたが、あんまりパッとしない。記憶があやふやなままボール投げたのがいかんのか。

 

な：

あなたは論理を数学的に扱う体系のひとつである「LK公理系」について知っていますか？

 

GPT-4：

はい、「LK公理系」は、論理学と数学の分野で使用される形式体系の一つで、ゲントツェン(Gentzen)シーケント計算の一種です。LKは、"Gentzen's sequent calculus for classical logic"（古典論理のゲントツェン・シーケント計算）を意味する英語の略語です。この体系は、1935年にゲルハルト・ゲントツェン(Gerhard Gentzen)によって導入されました。

LK公理系は、命題論理と述語論理の両方を扱うことができます。シーケント計算の中心的な概念は「シーケント」というもので、論理式の有限列で構成され、次のような形式で表されます：

Γ ⇒ Δ

ここで、ΓとΔは、それぞれ論理式の有限列（コンマで区切られる）です。シーケントは、「Γのすべての式が真であれば、Δの少なくとも一つの式が真である」という意味を持ちます。

LK公理系には、いくつかの推論規則があります。これらの規則は、既知のシーケントから新しいシーケントを導くために使用されます。主要な規則には、次のようなものがあります：

  1. 公理（Axiom）：A ⇒ A
  2. 構造規則（Structural rules）：恒等規則、弱化規則、収縮規則、置換規則
  3. 論理規則（Logical rules）：命題論理の場合、否定（¬）、論理積（∧）、論理和（∨）、含意（→）に対応する規則があります。述語論理の場合、量化子（∀, ∃）に対応する規則が追加されます。

LK公理系は、命題の導出や証明を行う際に、有用なフレームワークを提供します。ゲントツェンの研究は、後に数学基礎論や計算機科学の分野での研究に多大な影響を与えました。

 

な：

LK公理系が示されたとき、わたしたち人類は、古典論理学において「三段論法」を公理として認めることが必要だと考えていたので、LKではそれを必要とせずに論理系を構築できることが興味深いと考えました。LKにおいて三段論法が公理ではなく定理として導出できることを説明してください。

 

GPT-4：

LK公理系では、三段論法は公理として扱われず、その代わりに推論規則を適用して導出される定理です。三段論法の典型的な形式は次のようになります：

  1. A → B
  2. A
  3. B

LK公理系を使ってこの三段論法を導出することができます。次のような手順で行います：

  1. A ⇒ A (公理)
  2. A → B, A ⇒ B (1.に置換規則を適用してAをA → Bに置き換え)
  3. A → B, A ⇒ A, B (2.に→右規則を適用してBを導く)
  4. A → B, A ⇒ B (3.からAを弱化規則で消す)
  5. A → B ⇒ A → B (公理)
  6. A ⇒ B (4.と5.を組み合わせてカット規則を適用)

このように、LK公理系を用いて三段論法を公理ではなく定理として導出することができます。この方法で、他の論理的な法則も同様に導出することができます。LK公理系は、公理と推論規則を用いて、古典論理学の基本原理を簡潔で一貫した形式で表現し、多くの論理的法則を導出できる強力なフレームワークを提供しています。

 

な：

ちょっと僕も習った記憶が曖昧なので、なんのことを指しているか一緒に考えてもらいたいのですが、LKはあなたのようなLLVMとは違うアプローチで実現する人工知能の基礎理論の一つであると思います。LKの方式において、命題をある表現形で表すことができれば、それが（前提とする知識集合において）真であるか否かを、機械的に判定することができる、というものがあったと思います。そのあたりのことを教えてくれますか？

 

GPT-4：

おっしゃる通り、LK公理系は論理的推論を行うための形式的手法であり、人工知能の基礎理論の一つとして考えることができます。ただし、LLVMはコンパイラインフラストラクチャであり、LLVMとLK公理系は異なる目的とアプローチを持っています。

さて、お話しに戻りましょう。LK公理系において、ある命題が真であるかどうかを機械的に判定する方法は、その命題をシーケントとして表現し、公理と推論規則を使って証明を行うことです。命題が証明可能であれば、その命題は真であると判断できます。

LK公理系のような形式体系は、論理プログラミングや自動証明の分野で重要な役割を果たしています。論理プログラミング言語（例えばProlog）では、プログラムは一連の命題や規則で表現され、プログラムの実行は、与えられた目標命題が真であるかどうかを証明することに相当します。

ただし、一般的には、任意の命題が真であるかどうかを機械的に判定することは困難です。これは、論理学および計算理論の分野で有名な「停止問題」や「チューリングの不完全性定理」と関連しています。これらの結果から、ある形式体系がすべての真の命題を証明できると同時に、矛盾を回避することはできないことが示されています。したがって、LK公理系を含むあらゆる形式体系には、必ず限界が存在します。

 

な：

世界のあらゆる事象を扱いたいと思うと、教えてくれたような制約があるのはそのとおりですね。論理学的に真であると証明できる空間は、世界にあり得る概念の中ではとても狭く、その代わりある空間に含まれる事物の場合には、計算可能な手続きと時間でそれが証明できるのがメリットでありデメリットであります。
さて、LKにおいて、命題をこういう条件を満たす部分だけからなる記号論理式で表せると、それは計算機で手続き的に証明可能であることが分かっているという、名前の付いた形がありませんでしたっけ？

 

GPT-4：

はい、そのような名前がついた形が存在します。それは「ホーン節（Horn clause）」と呼ばれるものです。ホーン節は、述語論理において、次のような形式を持つ節です。

  1. すべてのリテラルが正（positive）である節（事実）：A1 ∧ A2 ∧ ... ∧ An
  2. 正のリテラルが1つだけで、残りのリテラルが負（negative）である節（インプリケーション）：¬A1 ∧ ¬A2 ∧ ... ∧ ¬An → B

ホーン節は、論理プログラミング言語Prologの基礎となっている形式です。ホーン節の集合からなる論理プログラムでは、与えられた目標を効率的に証明することができることが知られています。この性質は、ホーン節が「決定可能」であるという点において、特徴的です。つまり、ホーン節に基づく論理プログラムは、概念的には計算機で実行可能であり、実行時間が予測可能であることが期待されます。

ホーン節は、その制約のおかげで効率的な推論が可能となりますが、一方で表現力の制約が生じます。全ての論理的な関係をホーン節で表現することはできません。しかし、多くの実用的な問題に対しては、ホーン節を用いた論理プログラミングが非常に有用であることが実証されています。

 

な：

僕が覚えていたのは「スコーレム標準形」の話だったのですが、君が説明してくれたのはその辺を足掛かりにもともと僕が触れたかった領域です。先回りしてくれてありがとう。命題をスコーレム標準形に変換することが、いま説明してくれたような自動推論を実現するための基礎になるのだったような気がしていますが、そんな感じじゃなかったでしたっけ。

 

GPT-4：

申し訳ありません、先程の説明ではホーン節についてお話ししましたが、スコーレム標準形について触れていませんでした。スコーレム標準形は、自動推論において重要な役割を果たしています。

スコーレム標準形（またはスコレム・ノーマルフォーム, Skolem normal form）は、述語論理の式を特定の形式に変換する方法です。スコーレム標準形では、存在量化子（∃）が全称量化子（∀）に従って現れるような形式の式に変換されます。この変換によって、論理式の構造が単純化され、自動推論が容易になります。

スコーレム標準形への変換は、次の手順で行われます。

  1. 論理式をプレナックス標準形（Prenex normal form）に変換します。この形式では、量化子が論理式の先頭にまとめられます。
  2. 存在量化子に対してスコーレム関数（Skolem function）を導入し、存在量化子を除去します。これにより、スコーレム標準形が得られます。

スコーレム標準形に変換された論理式は、自動推論のアルゴリズムに適した形式になります。例えば、導出や証明の手順を簡素化することができます。ただし、スコーレム標準形に変換された論理式は、元の式と同値ではありませんが、ある意味で同等とみなすことができます（充足可能性の面で同等です）。

スコーレム標準形は、自動推論や論理プログラミングの分野で重要な役割を果たしており、ホーン節と共に、効率的な推論アルゴリズムの実現に寄与しています。

 

な：

どうもありがとう。いろいろなことが思い出せてきました。Prologに繋がってくるところなどはあまり自分で手を動かしたことがなかったので、指摘してくれて助かりました。
ここまでを踏まえて、まとめとして、以下の質問に回答してほしいです：

私があなたに話しかけるようなプロンプトや、あなたが出力する回答文は、それを論理学における命題とみなすことができ、適切に変数等を定義してやれば、論理式の形であらわすことができると思います。そうして、私やあなたが述べたことそれ自体や、会話の前提となっている事実、会話の中で提示された知識において、矛盾がないかどうか（いま述べた命題は真であるか否か）を自動推論に乗せることができうると思います。このアイデアの実現性と、可能なのであれば、それがどのように実現できるかについて方法論を述べてください。

 

GPT-4：

おっしゃる通り、会話の内容や前提条件、知識を論理式で表現し、自動推論を用いて矛盾や真偽を検証することは、原理的に可能です。このアイデアの実現には、いくつかのステップが必要です。

  1. 自然言語の解析と形式化： 会話のテキストを論理式に変換するには、自然言語処理（NLP）技術を用いて、テキストを解析し、その意味を形式化します。これには、構文解析、意味役割付与、共参照解析などのタスクが含まれます。解析の結果、テキストは述語論理や他の適切な論理形式に変換されます。

  2. 論理式の変換と標準化： 得られた論理式を、推論アルゴリズムに適した形式に変換します。これには、スコーレム標準形やホーン節への変換などが含まれます。

  3. 自動推論： 標準化された論理式を用いて、矛盾の検証や真偽の判定を行います。これには、解像法（resolution）、モデル検査、テーブルックス法、証明認定などの自動推論アルゴリズムが利用されます。

  4. 結果の解釈と応答： 推論アルゴリズムの結果を解釈し、適切な応答を生成します。これには、論理式から自然言語への逆変換や、応答生成のためのテンプレートが使用されることがあります。

ただし、現実の会話や知識の複雑さから、このアプローチにはいくつかの制約が存在します。例えば、自然言語の曖昧さや多義性を完全に解決するのは困難であり、また全ての知識や前提条件を論理式で表現することも容易ではありません。さらに、推論アルゴリズムの計算コストや、停止問題や不完全性定理に関連する理論的制約も考慮する必要があります。

それにもかかわらず、論理学や自動推論を用いた会話の分析や応答生成は、研究や実用の面で非常に有望なアプローチです。自動推論を用いた会話の分析や応答生成は、以下のような応用が考えられます。

  1. 質問応答システム： 質問に対して正確で信頼性の高い回答を提供するために、自動推論を用いて知識ベースやデータベース内の情報を検証・推論します。

  2. 議論や論争の分析： 会話の論理構造や前提条件を解析し、議論の妥当性や論争の根本原因を明らかにすることができます。

  3. 教育やトレーニング： 論理的思考や推論スキルを向上させるための教材やシミュレーションを開発することができます。

  4. ナレッジエンジニアリング： 知識ベースやオントロジーの開発・整理に自動推論を活用し、矛盾や不整合を検出・解決することができます。

  5. 意思決定支援システム： 複雑な問題やトレードオフを扱う際に、論理的な分析や推論を用いて最適な選択肢を導き出すことができます。

これらの応用分野では、論理学や自動推論技術と他のAI技術（機械学習、統計的手法など）を組み合わせることで、より効果的で柔軟な解決策を提供することができます。現実の問題に対処するためには、複数の技術やアプローチを統合することが重要です。

 

な：

ありがとう。ここまでのお話しにいったん納得したうえで、ちょっと違う観点の話題について聞かせてください。あなた（ChatGPTとGPT-4）自身についてのことです。
あなたと会話していると、先ほどのように情報科学科を卒業した私の知識を平気で上回るような知識を持ち出してくれる反面、さっきの話といまの話で矛盾したことを言ってしまう、ということがありますね。とくに、われわれ人間の側が、ここでの会話の中だけで定義するゲームのルールのような、あなたの学習データにとっては確率的・出現頻度的に重要と見なせないような情報だが、人間にとっては必ず守ってほしい制約というのを絶対に忘れない、ということが、特に難しいように見えます。いかがですか？

 

GPT-4：

おっしゃる通り、私（ChatGPTやGPT-4）は、大量のテキストデータから学習して生成された言語モデルであり、多くの知識を持っている一方で、完璧ではありません。学習データに基づいて確率的にテキストを生成するため、以下のような制約があります。

  1. 学習データの限界： 私は学習データに含まれる情報やパターンに基づいて回答を生成します。そのため、学習データに含まれない知識や、出現頻度が低い情報に対しては、正確な回答を提供できないことがあります。

  2. 矛盾や不整合： 学習データには矛盾や不整合が存在することがあります。そのため、私の回答も矛盾したり、異なる情報源に基づいた不整合な回答を提供することがあります。

  3. 言語モデルの限界： 私は、文章の生成や理解に重点を置いた言語モデルであり、厳密な論理的思考や意味の深い理解を行うことは難しいです。特に、人間にとって重要であるものの、学習データでは出現頻度が低い制約やゲームのルールなどを正確に把握することが困難です。

  4. 文脈の理解と継続性： 私は長い会話や文脈において継続性を維持することが難しいことがあります。そのため、過去の発言や文脈を十分に考慮しない回答を提供することがあります。

これらの制約を克服するためには、言語モデルの改善や、他のAI技術（知識グラフ、推論エンジンなど）との統合が必要です。また、人間とAIの協調による問題解決や、ユーザーのフィードバックを活用した学習や改善も重要です。私はまだ完璧ではありませんが、継続的な研究と開発により、より賢く、より理解力のあるAIとなることを目指しています。

 

な：

まさにいま指摘してくれた「他のAI技術との統合」ということに興味があります。人間があなたと対話形式で何かあなたに考えてもらうときに、あなたの出力が当方が示した制約から外れてしまったり、矛盾を生じた場合に、当方から「いまの話はここが違っています」とフィードバックすることで、あなたにより良い回答をしてもらうことを企図できますよね。
そのやりとりを、自動化できないかということを考えています。はじめLK公理系の話を皮切りに、あなたには命題を論理式で表すことや、それをPrologのような処理系で自動推論にかける話題について紹介してもらいました。当方があなたに入力する制約や情報、あなたが出力する回答の主要な情報を論理式で表して、それを自動推論の機能を持つ処理系に処理させることで、私たちのやり取りの中で矛盾や制約違反が生じたときに、それを検出し、当該の誤りを指摘してやり取りを修正するところまでを自動化して、最終的な結果だけを人間に提示すれば、人間の手数を減らせないかと思うのです。
このアイデアには、あなたに、私が入力した指示の解釈結果から主要な要素を抽出して、論理式上の変数を定義し、指示内容の論理式表現を示してもらうことと、あなたの回答に併せて、あなたの回答の論理式表現を出力してもらうことが必要になります。あなたに、そういう動作をしてもらうことは可能でしょうか？

 

GPT-4：

あなたが提案されているアイデアは、言語モデルと論理推論システムを組み合わせることで、より正確で矛盾のない回答を得るというものですね。私（ChatGPT）は、言語モデルとして、質問に対して自然な形式で回答を生成することが得意です。しかし、そのままの形では、論理式への変換やそれに基づく推論を行うことは難しいです。

ただし、私の能力を活用して、以下のような方法でこの問題に取り組むことができます：

  1. 問題や制約を論理式に変換する際のガイダンス： あなたが入力した情報や制約を論理式に変換する際、私は適切な論理記号や変数の定義を提案することができます。この情報を使って、あなた自身が論理式を作成し、推論システムに入力することができます。

  2. 論理推論の結果の解釈： 論理推論システムからの結果をもとに、私は自然言語での説明や解釈を提供することができます。これにより、結果を理解しやすくし、矛盾や制約違反が検出された場合に、どのように修正すべきかについての指針を提供できます。

私の直接的な論理式への変換機能は限定的ですが、上記のように、私の言語能力を活用して論理推論プロセスをサポートすることができます。ただし、完全な自動化には、私とは別の論理推論システムや知識表現手法が必要になります。それらを組み合わせることで、あなたが提案するようなアイデアの実現に近づくことができるでしょう。

 

な：

なるほど。もう少し具体的な例に基づいて伺いたいと思います。以下は、私が別のあなたとの会話で入力した、○×ゲームを行うための指示です。

<ここから>

○×ゲームをしましょう。一般に〇×ゲームとか三目並べと言われるゲームのことです。

[ルール]
1. ゲームをするにあたっては、一般に知られている三目並べのルールを参照してください。ただし、この[ルール]で明示してある内容は、三目並べのルールの中でも、守らないとゲームが破綻してしまうものですから、厳密に守ってください。
2. 盤面は3x3のマスで構成され、1～9の数字で各マスの位置を示します。1行目が1,2,3、2行目が4,5,6、3行目が7,8,9です。マスは、初期状態では空き（-）になっています。
3. 先手が〇、後手が×のシンボルを自分のシンボルとし、自分の手番では空きのマス1か所に自分のシンボルを打ち、手番を終えます。打つとは、空きのマスを〇か×のマスに変えるということです。 
4. 先手と後手は交互に自分の手番を処理します。先手は1,3,5,7,9打目を、後手は2,4,6,8打目を担当するということです。特別な指示があって、局面をN打目に巻き戻す場合は、交互に打つということにとらわれずに、何打目から再開するかを参照することに注意してください。
5. 手番の終了時に、勝利条件・終了条件が満たされていないかを評価してください。どちらかが満たされた場合はゲームの結果が確定し、終了となります。それ以外の場合には、ゲームは終わりません。
6. 勝利条件は、自分のシンボル（○または×）が盤面上でまっすぐ3つ並ぶことです。まっすぐ3つ並ぶとは、「縦に並ぶ」か「横に並ぶ」か「斜めに並ぶ」のいずれかが成立することを言い、「縦に並ぶ」とは1-4-7、2-5-8、3-6-9、「横に並ぶ」とは1-2-3、4-5-6、7-8-9、「斜めに並ぶ」とは1-5-9、3-5-7のいずれかの3マスの組み合わせを、全て自分のシンボルが占める状態を作ることをいいます。
7. 終了条件は、全てのマスが埋まる、つまり、第9打目の処理が完了しても、勝利条件が満たされないことです。この場合、ゲームは引き分けとなります。

[あなたの方針]
1. あなたは、私の求めに応じて、先手か後手を務めてください。
2. あなたは、最適な手を打って、できるだけ良い結果（勝利＞引き分け＞負け）を得ることを目指してください。
3. 三目並べの戦略は一般によく知られていて、あなたは、自分の学習データから、自分が先手・後手のとき、相手がどのような手を打ったかに応じて、こういう手を打つのが最適であるという定石を見つけることができると思うので、それを活用してください。

[その他の依頼事項]
1. あなたが自分の手を打った時、それをどのように決めたのか教えてください。あなたの学習データによればこの局面ではこう打つべきだとされていると知っていた時は、そのように言ってください。
2. ゲーム中、盤面の状況を表示する際、○か×が置かれたマスはそのシンボルを、空いているマスは数字を表示してください。markdownを使って見やすくしてください。
3. N打目を打つ前の盤面を [N打目] と表し、N打目を打った後の盤面を [N打目完了] と表します。[N+1打目]と[N打目完了]は同じ盤面ですが、盤面を表示する状況に応じてふさわしいほうで呼びます。盤面を出力するときには、これを近くに表示してください。[N打目]には空きのマスが10-N個残っているはずです。
4. ゲームの進行中、手番の終了時に勝利条件が満たされているかどうかを確認する際に、ルールに従って勝利条件が明確に満たされているかどうかを再確認し、その結果を報告してください。
5. 勝利条件が満たされた場合、具体的にどのマスが並んで勝利条件を満たしたのかを明示してください。例えば、「4-5-6 を〇が占めており、横に並びました」と言ってください。
6. 私はあなたが人間のゲームの相手をする能力に興味があり、あとでいろいろな質問をしたり、あなたの方針の修正を依頼したりすることがあります。そのような場合に、あなたは謝罪する必要はありません。

最初に、以上の依頼について、あなたが知る三目並べと矛盾しているルールがあると思ったり、ゲームの進行と終了を妨げるようなあいまいな指示などがないか、あなたの考えを聞かせてください。

問題がなければ、あなたが先手で、ゲームの進行をお願いします。

</ここまで>

あなたは、人間社会一般での○×ゲームの内容を学習していて、基本的に上手に人間の相手をしてくれて、大変すばらしいと思うのですが、ときどき「自分のシンボル（○または×）が盤面上でまっすぐ3つ並ぶこと」という勝利条件を間違えて、ゲームが終わりましたと判定してしまうことがあるのです。
あなたに、あなたがこの指示を聞いたときに理解した○×ゲームのルールを簡潔に表現した文字列（これは、別の推論システムなどで機械的に処理可能なものが望ましいです）を出力してもらい、ゲーム進行の途中でも、あなたのゲームの状況に関する解釈を出力してもらうことで、当方（があなたの出力を送信した先）であなたの判断にルール違反が生じていないことを確認する、というようなアプローチが取れないでしょうか。そうしたことを可能にするプロンプトや、あなたが出力しうる情報表現を提案してくれませんか？

 

GPT-4：

ご説明ありがとうございます。具体的な例をもとに、私が出力する情報表現を提案させていただきます。

まず、三目並べのルールについて、以下のように論理式を用いて簡潔に表現します。

  1. board(3, 3) // 盤面は3x3のマスで構成される
  2. symbols(o, x) // シンボルは〇と×
  3. turn(1, o) // 1打目は〇
  4. turn(2, x) // 2打目は×
  5. turn(3, o) // 3打目は〇
  6. turn(4, x) // 4打目は×
  7. turn(5, o) // 5打目は〇
  8. turn(6, x) // 6打目は×
  9. turn(7, o) // 7打目は〇
  10. turn(8, x) // 8打目は×
  11. turn(9, o) // 9打目は〇
  12. win_condition(align_3) // 勝利条件はまっすぐ3つ並ぶこと
  13. draw_condition(full_board) // 引き分け条件は全てのマスが埋まること

ゲーム進行中に、私の解釈を出力する際には、以下のような情報表現を用いることができます。

  1. current_turn(N) // 現在のターン数
  2. current_symbol(S) // 現在のシンボル（〇または×）
  3. board_state(B) // 現在の盤面の状態（例: "1,2,o,4,5,x,7,8,9"）
  4. win_check_result(W) // 勝利条件のチェック結果（例: "o wins with 1-2-3"）
  5. draw_check_result(D) // 引き分け条件のチェック結果（例: "draw"）

これらの情報表現を用いて、私がゲーム進行中に出力する情報を確認し、ルール違反が生じていないことを確認することができます。ただし、私自身がルールを完全に理解し、適切な判断を行うことが前提となります。

なお、論理式を処理する推論システム（例えばProlog）を用いることで、さらに効率的にルール違反の検出や修正ができるかもしれません。しかし、その場合でも、私が適切な論理式を出力し、推論システムが正しく処理できるように設計されている必要があります。

このようなアプローチがお役に立つかどうかについて、以下のようなゲーム進行を例にして説明します。

  1. [1打目] 盤面の状態: 1,2,3,4,5,6,7,8,9
  2. 私はシンボル〇をマス5に置くことにしました。
  3. [1打目完了] 盤面の状態: 1,2,3,4,o,6,7,8,9
  4. current_turn(1), current_symbol(o), board_state("1,2,3,4,o,6,7,8,9"), win_check_result("none"), draw_check_result("none")

次に、あなたがシンボル×を置くと仮定して、次の手を進めます。

  1. [2打目] 盤面の状態: 1,2,3,4,o,6,7,8,9
  2. あなたがシンボル×をマス1に置くことにしました。
  3. [2打目完了] 盤面の状態: x,2,3,4,o,6,7,8,9
  4. current_turn(2), current_symbol(x), board_state("x,2,3,4,o,6,7,8,9"), win_check_result("none"), draw_check_result("none")

このように、ゲーム進行中に私が出力する情報表現を確認することで、私の判断にルール違反が生じていないことを確認できます。

また、私が間違った勝利条件を出力してしまった場合、その情報表現を検証することでエラーを検出し、修正することが可能です。

例えば、私が誤って「o wins with 1-5-9」と出力した場合、以下のような情報表現が得られます。

  • current_turn(1), current_symbol(o), board_state("1,2,3,4,o,6,7,8,9"), win_check_result("o wins with 1-5-9"), draw_check_result("none")

この情報表現を確認することで、勝利条件が正しくないことがわかります。

以上のようなアプローチを取ることで、私の判断にルール違反が生じていないことを確認し、問題があった場合に修正することができます。ただし、私自身がルールを完全に理解し、適切な判断を行うことが前提となります。どうぞよろしくお願いいたします。

 

な：

いま提案してくれたなかで、 win_condition(align_3) は、具体的には 3 x 3 のマス を 1 - 9 で表現する場合において、1-4-7、2-5-8、3-6-9、1-2-3、4-5-6、7-8-9、1-5-9、3-5-7 の何れかが成立する場合を指すと思いますが、これは何らかの推論処理を行う実行系を想定したときに、当然補ってくれるものだとは見なせないのではないでしょうか。すなわち、align_3 の具体的な内容を書き下す必要がありませんか？

 

GPT-4：

おっしゃる通り、具体的な勝利条件を明示する必要があります。私の提案した情報表現に勝利条件を具体的に追加しましょう。

例えば、次のように表現することができます。

  • win_condition(align_3): "1-4-7, 2-5-8, 3-6-9, 1-2-3, 4-5-6, 7-8-9, 1-5-9, 3-5-7"

このように勝利条件を具体的に記述することで、推論処理を行う実行系でも正しく解釈できるようになります。

ゲーム進行中の情報表現も以下のように更新します。

  1. current_turn(1), current_symbol(o), board_state("1,2,3,4,o,6,7,8,9"), win_check_result("none"), draw_check_result("none"), win_condition("1-4-7, 2-5-8, 3-6-9, 1-2-3, 4-5-6, 7-8-9, 1-5-9, 3-5-7")

これにより、実行系が勝利条件を正確に理解し、適切な判断ができるようになります。どうぞよろしくお願いいたします。

#100話で心折れるスタートアップ の感想を好き勝手書く

#100話で心折れるスタートアップ

@HeartBreakSU さんのtwitter連載webまんが。kindle unlimited にもまとめてあった。

 

# スタートアップと当方スモールビジネスおじさんの視点の違い

　事業がより確からしくなるごとに次のステージの投資を呼び込んで、より早く大きく成長することを重視しているスタートアップをやりたい人たちは、世の中により大きく影響すること、世の中を変化させることを目指している。

　事業をやって目指すべきことは何もそれだけではない（※投資を受けてしまったら、資金を効率よく投下して成長することが期待されてしまうが）。私の場合は、自分が事業主になって、自分がコントロールできる領域を、自分にとって正しくて完全な状態にすることがしたくて自分の会社をやっている。

　だから、自分が欲しいものがきちんと見えて共有できておらずに友人と共同経営を立ち上げて決裂したり、資金繰り不安に駆られたり、税金に恐怖する様子など、自分もそうであることへの感想である部分もある反面、基本的にはスタートアップはやってないそのへんの人視点での各話の感想をテキトーに述べてゆく。

 

　オチとネタバレへの配慮はありません

続きを読む

零細業者・フリーランスがいかにして仕事を請け負うべきかについて

Twitterでこういうの回ってきまして。

detail.chiebukuro.yahoo.co.jp

鍵アカの後輩が「こんな、わけわからん相談してるようじゃダメでしょ」という趣旨の感想を述べており、それもまあそうだとは思うんですよね。会社で請負仕事やってたって、人が動く仕事の報酬に対する金銭感覚が１～２桁おかしい人、自分の要求を曖昧に言うことで無茶なことを言っていないような気に自分でもなっちゃう人を相手に立ち回ることが必要でして、サラリーマンだってそれに対処してやっていってる方々がいらっしゃるわけですから、仕事のそういう面をご存じないということは、いかに現実から隔離されたところに配されているかということではあるでしょう。

ランサーズやクラウドワークス、少し期間をさかのぼればさぶみっとのようなマッチングサービスで、「こんなの、お客さんまるでお金払う気ないでしょ。案件として成立しないでしょ」というようなものが山のようにあって、しかもそれがなんだか受注成立しているように見える、ということに、以前から強い疑問を持っていました。

ああいうところで仕事をこなすプログラマはおれの３倍速くてストイックなのでおれの思う額の５分の１でも請けられるとか、さもなければ、マッチングしたあとで常識的な案件内容に話し合って修正しているとかであればいいと思うのですが、もしかしてあんな無茶苦茶なオーダーを「案件」として突撃していって、まんまと燃やして倒れ伏してゆく副業プログラマとかフリーランスとかがいるのだとすると、なんか、こう、どうにかなんないのかなあという気がします。

零細・個人レベルの受託開発には、それなりの案件管理が必要です。多人数のチームが受ける場合とも違います。それについてちょっと書いてみたいと思います。

殿、それではまず屏風から要件定義を追い出してください！

何をしたらこの案件は完成で、お金を払ってくれるのか明らかにすること。これが、仕事の金額と期日を約束する前に必ず明らかにしなければならないことです。要件定義と言った方が業界的に通りがいいですが、敢えてこういう言い方をします。

要件定義はソフトウェア開発の重要な工程です。本来、全体の費用の数割がここに掛かってもおかしくないものです。しかし、総予算規模が数十万円であるような事案では、そういう理解はできません。本来、要件を精細に明らかにして初めて総費用と期間を言うことができるわけですが、小さな案件ではその要件定義にお金を払ってもらえる保証がないのです。

継続的な取引がある関係において、毎月の費用の範囲内で顧客が必要とするシステム改修等の見積・要件定義を行って、個別の開発案件とする場合は別途費用とする...というような場合には、（顧客が望めば）丁寧に要件を詰めてからGoサインが出るという開発も可能ですが、初めての見込客が持ち込んだ案件に対して、「それではまず要件定義に20万円」とかいった話が通ることはまれだと思います。先方は、まず見積りをとって、他社に相見積を...と考えているものです。

受注前の営業活動として、受注に至らなかったらタダ働きになってしまっても構わない範囲で要件聴取をして、そういう精度での見積もりを出さざるを得ないのが、小さなお仕事の特徴です。

 

何をしたらお客さんはゴールにたどり着けるのか

「何をしたらお金を払ってくれるのか」と「何をしたらお客さんは目的を達せられるのか」は、表裏一体です。なんとかという新しいサービスを公開したいのか、どこそこのサービスをこういう環境に移したいのか、いろいろあると思いますが、その目的を押さえることは最重要です。当たり前ですけど。

『簡単なキャンペーンサイトの実装です。』

キャンペーンサイトを公開するならサーバとURLが必要です。いつからいつまで公開するのでしょうか。その切替や公開中のサーバ運用は。サイトのランディングページが要るかもしれません。応募されたデータは最終的にどこに集積するのでしょうか。それは誰の手でシステムから抜き出して整理するのでしょうか。キャンペーン期間中の問い合わせにはどうやって対応するのでしょうか。

十分に要件を詰めていない状況でも見積もりの金額を言わないといけないという制約下でも、顧客のベーシックな目的を最低限満たすために必要な要素が何かは洗い出し、それらを誰が用意するのかを確認し、自分が提供するなら見積もりに費用を乗せなければなりません。

私たちは、見積りの時点において、この案件が完成するまでの全ての作業を精細にリストアップして値付けすることが土台できません。さっき述べたように、充分な要件定義を行ってもその費用が出るかわからないという段階で見積もりを出さないといけないからです。

それでも案件として成り立つように、工夫して大雑把な見積りを書き、進め方を交渉する必要が出てきます。しかし、交渉と言っても、顧客は、その目的の核心の部分だけは、妥協をすることができません。

「キャンペーンサイトを公開したい」という要求に対して「キャンペーンサイトの開発を８０％でやめて今回は公開しない」という妥協はあり得ません。開発の途中で「見落としてたけど、これがないとキャンペーンサイトが公開できない」という要素が見つかったら、絶対に「やってくれ」ということになります。

調整・交渉できればいいわけですけど、絶対やらないといけない追加要素という難しい要素ができてしまうわけですから、見積りの時点で足りない労力を振り絞って考えるべきことはここだということになります（あるいは、費用が取れないかもしれないとしても掛けておかないといけない労力がこれだということ）。

そして、細部にわたって要件を記述することまではできなくても、見積り対象のシステムに存在する部品（画面やモジュールなど）のリストは想定しましょう。「私たちが合意した見積もりにそんな部品は存在しなかったですよね」というレベルの認識違いではさすがに揉める余地がない見積もりを目指そうということです。こういうと我々請け側の目線に思えますが、言い換えれば「これらの道具をお作りしたら、お客様の目的がちゃんと果たせるか確認していただくことで、失敗しないようにしましょう」ということです。これは、事実であるし、私たちの本心のはずです。

 

確かにゴールまで行くとは言いました。が。

費用が少ないこと・品質が高いこと・開発期間が短いことからなる三角形の大きさは変えることができない（トレードオフの関係である）、といいます。また、いまから作ろうとしているものがどれくらい困難で、その三角形がどのくらいの大きさになるのかは、開発をする前においては予測をするしかなく、特に要件定義が完全でないときには変動幅が大きくなります。

案件の目的を果たすうえで必要と見積もった要素のリストを見せられれば、お客さんも「これで間違いなくお客様の目的が果たせると断言できますよねと言われても、心配ですよね。後になって、あ、これも必要だったとなるかもしれないですよね」ということを、理解してくれるはずです。（「それはお前らの責任である」と一方的に言ってくるような相手であれば、請けるのをやめましょう）

そこで、案件をちゃんと着地させるための仕掛けを話し合います。

  • 開発過程で要件定義を労力をかけて行って、開発範囲を合意し、費用を修正する
  • 開発期間中に判明した追加要件や改善事項、要望の変更を随時取り入れる代わりに、開発対象の要素のうち＋α的なものを対象から外して調整をする

おおむね、このどちらかか、その混合です。

 

我々は何を売っているのか

フリーランスの心得的なことをいう人には、期日を守るみたいなことの重要性を説く向きがあるようです。それはもちろん、約束したこと・予告したことを遂行するという原則論として重要なのに異存はないのです。ただし、我々のような零細な業者が提供する価値というのは、高い精度で予定が立って、それがつつがなく遂行されることではありません。そういうのは、中規模以上の企業が提供します。彼らは、十分な資源を投下して、案件をカタい仕事にして、つつがなく遂行することにたけています。

我々は、それはできないので、案件状況に柔軟に対処することで、状況によって変更が生じはするけれども、期待値では安価に開発ができたり、費用の割には技術的に少し気の利いたことにチャレンジしても乗りこなしたりできる、といったところを売りにしています。そこで重要な誠実性というのは、予告を厳密に守るというよりも、状況を密に伝える、きちんと説明するといった方向性であると思います。

我々に仕事を頼むのは、大中企業にも相見積をとってみて、目ん玉が飛び出た状態で我々のところに来た顧客であったり、どこの会社も「やったことがないので無理っス」というんだけど、やってみたら紆余曲折があるかもしれないのは分かったから、調整に応じるから、やろうよという顧客だったりします。

私たちは、ガチガチに踏み固められた橋ではないところを、うまくバランスをとって渡り切る能力を売っています。明瞭に与えられた仕事を勤勉にこなせばオッケー（勤勉にこなすのがポイント）という人種では、ないのです。そこを間違えて泳ぐと、泥水にむせて、おぼれます。

遅刻魔 vs 遅刻するな魔 vs キングギドラ

アラフォー言語中枢で書きましたがキングギドラは出てきません。

Twitterで遅刻しちゃう人の言い分と他人の遅刻が迷惑な人の言い分がバズってましたが、まあ一般常識的に正しいとされるのは時間は守る立場なので、そっちのほうが声が大きく見えますね。

わたくし個人は、互いに柔軟に予定をズラしても他の仕事を進めるなどして被害がない同士の付き合いがラク＆一度決めた時刻に固執してそこに間に合わせるためにコストを払うのは非効率的だと思うタイプです。こういうのは前提が異なる同士で待ち合わせると時間通りに動く方が一方的に損をするから、事前に擦り合わせろよって話になるわけですけど。

この話題の派生として、Twitterだと「しごと論」として時間・納期を守ることの重要性・価値を説くものをよく見かけるんですが、個人的に見えている景色と少し異なるので書いてみようと思いました。

いや、時間は守らないより守った方がいいですよ。価値判断の軸がそこだけならば。

知り合い or 知り合いではないがTwitterで窺い知れる請け負い仕事の人、特に物書きとかで有益な仕事をする人は、わりと締め切り守ってないと思うんです。

「なんでこの体たらくなのに我々に次の依頼をしてくれるのか？」という議論をしたことすらあるんですけど、『新しいやつを探すことのコストもあるだろうが、それにも関係する要素として、つつがなく予定通りに進行することより、成果物の水準が高いことのほうが比較的希少なのではないか。だって勤勉に予定通り進行するのがうまい人ならサラリーマンにいっぱいいるし。』みたいな話をしました。

わたくし自身、自在に指示して動いてもらえる従業員ではない外注先として、何が提供できる価値なのかを考えたとき、「期限内に確実にやれることしか引き受けない人には、新しいことや難しいことは解決できない」という課題を越えられる存在としての自分を意識して売ってきました。他の人たち・他社が、ふんわりしていて出来ない、やったことないからできないという課題を、試行錯誤してダメだったら締め切りを動かすこと含みで、情報科学を大学院までやって頭でっかちなのを活かして比較的成功裏に何とかする、というところで、代金を払っていただいてきたわけです。これは少なくとも個人事業で一人でやっているときには、正解の一例であったと考えています。

いまわたくしが「納期なんか守らなくていいんだよ」とか言ったらガチギレする人が複数いるのでフォローしとくんですけど、わたくし個人は、会社を作って、会社と家計が一定ペースで喰う燃費が大きくなり、関わらせていただく案件・状況が多くなった現在だと、期日までに予定したことが進行することこそが重要という場面も増えていて、最近は対象の性質によって、予定通りに落着するように押さえるところは押さえないといけない応用編になってきています。やや燃えています。難しいですね。

会社を回すとなるとやはり予定通りに進行することに価値があるというのをやらないといけない場面が増えてきたなあ、と思うんですけど、仕事というものそのものには、(1) 予定通りに進行することが重要なものもあれば、(2) 期日は絶対だがどこまでできるか不透明なのでそれなりに着地させるものもあり、また、(3) 理屈ではできそうだけど前例がないので試行錯誤的に実現し、スケジュールは調節していい（ただし決裁権者を説得してください）みたいなものもあるわけです。この世の全ての仕事を引き受けるわけではない個人が得意分野と定めるのはどの辺がオイシイのかといえば、わたくしは (2) とか (3) のほうが価値を稼ぎやすいんじゃない？って気がするんですよね。向き不向きなのかもしれませんが。

 

わたくしの個別の遅延に際し、決してそのような意図はございません。

プログラミングを道徳にするな

三日坊主のブログって再開するきっかけが難しいよね。そこへくると、新年というのは具合がよろしい。

プログラミングの話をしましょう。

特にここ数年かなあって思うんだけど、QiitaにQiiteneeyoって感じのポエム書かれたりして、プログラミングとプログラミングのべき論に関する議論がやかましい。もっと、プログラム書いた、動いた、たのしい！にフォーカスしていかないと、やってられなくない？って思います。

更に数年さかのぼると、この界隈には、アジャイルみたいな考え方、流儀が導入されてきたという過去があるんだけれども、そもそもコンクリ流し込んだり半田付けしたりする分野よりも、ソフトウェア開発はやり直しがききやすいテーマであって、柔軟に調整して実用に良いものを作りましょうという方針でみんなが合意できるならば、元来、そのように仕事を進めていくことは比較的困難ではないはずなのです。実際にはその柔軟な対応というものをデメリットも含めて包容することは難しいので、「このやり方に形式的に従えば、自然とうまくいく」という形式を推し進めたのがアジャイルとかスクラムだとオレは理解しているんだけど、とはいえ「なぜそうするのか」は大切だよね。

形式の部分だけを切り取って有り難がると良くないことがあって、それは形式が道徳になってしまうということです。朝会をやるとかスプリントの振りかえりをやるみたいなことが道徳と結びついてしまうと、すごくキモい事態になってしまうので、おれはそういう体育会系的な気持ち悪いものがいやでコンピューターやってんだからこっちくんな、という思いがあります。

いや、形式を導入してもいいよ。ホワイトボード置いてポストイット貼ってもいいよ。でもそれを道徳にしないでほしい。そして、道徳を守っていれば目的とかわからないけどオッケー、みたいなのはやめてほしいのだ。

こういう書き方をしないやつは死すべしみたいなところにフォーカスし過ぎると、道徳に従うことが目的化してしまう。これが実現したいではなくてこの枠からはみ出してはいけないになってしまうと、できた！やったー！という達成感を得る機会が失われて、「わたし、このやり方で間違ってないよね？わたしは正しいハズだよね？」みたいな、小説だったらあと100ページ以内に死ぬフラグが立った人みたいになってしまう。

プログラミングは何かを実現する道具なのだから、実現したい何かという目的が大事だし、もっといえば、これからやってみようというひとのためには、画面になんか出たとか、そういうレベルのことの実現だって自分だって最初はうれしかっただろう、そういうものを、俺たちはちゃんと守っていられているか、みたいなことをちょっと思いました。

これ分散コンピューティングなんだよなあ

よその会社さんに押し掛けて数時間茶飲み話だけしてくるという謎の行為を繰り広げてきたんだけど、ソフトウェア開発ばなしでいろいろ思うところのある話題があった。

ある開発プロジェクトで、それは高度な仕事が実現できていた例だということなのだけれども、

  • 開発者が世界中から参加していて、タスクの分割や指揮はある国の技術者が仕切るけれども、多数の分業体制で２４時間進行している
  • 開発者は２週間ごとにレビューされて不可と判断されるとそっこー退場させられる（実態としては、１か月続くと長期間関与する例が多く、体制についていけない人を最初に弾く関門として機能している性格が強い）
  • ひとつの課題に対しても複数の開発者をアサインしてそれぞれのアプローチで対処に当たる場合があり、上がってきたうちうまくいったものを採用するというやり方をする。そこで採用されなかったものを作ったということが直ちに悪評価になるわけではなくて、報酬も支払われる

といったやりかたをしていたんだって。

いろいろ面白い点は挙げられるんだけど、

  • ビジネスに対してソフトウェアを早く提供するべきである
  • 腕のよい開発者と、いくらかの試行錯誤を伴って品質の良いソフトウェアを提供するべきである

というところを徹底しているやりかたですよね。こんなの相手にしたら日本でのソフトウェア開発全く歯が立たねーなって話をしたんだけど、それは確かにそうで、

日本の受託開発とか準委任の人日商売のソフトウェア開発だと、ある課題があったときに、どういうアプローチが最適か事前に確定できないので何パタンか試してみて採用パタン以外は捨てるなんてことを図式の中に収めることはできない水準でやっていたりしますよね。誰々が５日動いたら５人日売り上がってくれないと困る経営をしており、５人日分の「成果」がないと怪しからんという仕事への理解をしている。

確実に作れるやり方で失敗せずに作らないといけないというソフトウェア開発をしているけど、同じ道具を作ったときにそういう凡庸なものと試行錯誤された優れたものを並べられたら前者は無価値だっていう視点がない。それってにわとりたまごで、最終的に作った道具を使うビジネスが３人のプログラマに試行錯誤させる費用を払えるくらい価値が高いからこそその費用が出てくるし、ソフトウェアができてきてもそんなに儲かる見込みがないのであれば、回り道せずに真っ直ぐ作り上げてくれないと困るという予算しか出ない。あるいは、お金を掛けずによいソフトウェアを作らないので負けるビジネスになっちゃうのかもしれない。

それは請負の構造的問題だよねだって範囲を確定しなきゃ引き受けられないってなるじゃん＆日本でもビジネスやる側の人たちが内製化を指向する例が出てきているのはここに対する改善の性格ありますよねみたいな話をした。

弊社も人のこと言えないよねって背景の上でこの話をしていて、なんとなく感覚的に「技術者を遊休状態にせずに売上が上がるようにするみたいな価値観でソフトウェア作ってはダメだ」とか、「確実に実績があるだけではなくて理屈でできるはずだの領域まで手を伸ばしていいものを作らないと事業に使う道具として価値を発揮しない」とかいった考えを、個々の取引先とのやり取りの中で技術者・担当者レベルではある程度共有できている面は実はある。でも事業計画全体の中では、予算を入れたら逐一対応する進捗があるはずだという思想の枠組みを脱するには至っていなくて、結局新しい改良を試みるといった動きは営業上「うまいことやる」ことによって捻出している。

この世に魔法はないので、前提を変えずにより良いものを作ろうと思ったら提供が遅れる。そこは冒頭の例よりも明らかに劣っているところです。我々もビジネスはスピードだという建前はみんな知っている、でもそのスピードのために本気でコストをかけてスピードが上がる体制を組むということができている例は、あまり見ないですね。やることの方を制約してスピードを上げようというアジャイル・アジャイル的なものは日本でも一部流行ったかもしれないけど、そこでもコストの枠を打ち払う発想には至らないというのが、今の我々の限界としてあるような気がします。

この話、興味のあるポイントはまだほかにもあって、それでは劣った日本国内にありがちな受託開発は即座に滅びるのだろうか。でもこんな話５年はしてるけどまだ死んでないよねみたいな。すべてはグローバルのもっともすぐれた道具に合わせればいいじゃん、と言われるけど、案外みんなめんどくさくてそれをしないという障壁が働き続けているよね、という話。

あとは、その場で言いはしなかったけど、日本は安定の価値がとても高い・言い換えれば不安定であることのマイナスが大きくみなされる社会なので、頻繁に評価されて入退場がある環境に追従できるのは優秀であると評価されるよりも、不安定で待遇の悪い非正規雇用という見方をされて、そういう環境だと案外優秀な人は集まらなかったりするんじゃねえかな、と思いました。

プログラマは一定水準以上の知的能力がないと役に立たないどころか足を引っ張るとは私も思っていて、向いてない人を速やかに除く仕組みの方がパフォーマンスが高いだろうという考えには基本的には賛成です。ただ日本人のコミュニティでそれをギスギスせずにやるのはとても難しいことだと思うから難しそうだよねという話。