合意とはなにか - プロジェクトの合意形成、プロダクトの合意形成

• 合意には、表面的な合意（決定事項としての合意、推進のための合意）と深く納得した合意がある
• プロジェクト推進のための合意は、表面的な合意でも構わないケースが多々ある
• プロダクト開発、長期的な開発においては、最終的に深く納得した合意で進めないと落ちこぼれていく
• 私個人のスタンスとして、プロダクト開発のチーム内においては、深く納得した合意による結論であればそれは誰の意見が元になっていても構わないし、極論内容はなんでもいい
  • プロダクトはそうやってみんなの意見でできていくし、それでも隠せないものが勝手に色として出る

というようなことについて語ります。（タイトルは若干誇張的な部分がありますが、大きくずれてはいないかなと思います）

合意とは

デジタル大辞泉によると、合意とは以下のような意味であるとされています。

互いの意思が一致すること。法律上は、当事者の意思表示が合致すること。「合意に達する」「離婚に合意する」

例えば、

A: このプロジェクトではunsafeな文字列を格納する変数にはusという接頭辞をつけましょう（真のハンガリアン）
B: わかりました

という会話がなされた場合には、AさんとBさんの間で「このプロジェクトではunsafeな文字列を格納する変数にはusという接頭辞をつける」ということについて合意が形成されています。

合意の深さ

合意には、浅い・深い、あるいは表面的・根本的とでもいうべき概念があります。
Bさんが、「決まったことだから」として、規則として何も考えずにただusを接頭辞につけようとしているとしたら、それは浅い合意です。
一方で、別のCさんが「usの付いている変数は安全でない、という意識でコードを自然に読めるようになり、実際に見分けもつきやすいし、ガードレールとして機能する」ということを心から実感できている、あるいはそこまではいかなくても理屈としてusをつけることの目的を理解できているとすれば、それは深い合意です。
どちらも、「unsafeな文字列変数にusという接頭辞をつける」という結果は保証され、単純なプロジェクトの成果物レベルではほぼ同じ結果を生むと言ってよいでしょう。その点においてBさんの出力とCさんの出力は同じですが、この合意の差は一次出力とは異なる影響を生み出します。
つまり、CさんはBさんよりも、このプロジェクトのコードをより効率的に読める、ということです。

Bさんの認知においては、「とにかく安全でない変数名にusをつける」ぐらいのことしか思っていなくて、それをコードリーディングに活かすとか、あるいはそれをする目的のような観点はなく、出力をあわせるということだけしか考えられていません。一方、CさんはなぜAさんがそのような提案をしたかという目的の部分までAさんと合意できていて、いわばAさんと同じ認知でコードを読むことができます。
重要なことは、BさんもCさんも表面的には同じように合意しているし、また出力も同じであるが、しかし合意の文言で直接的に規定されている内容とは別のことで確実に深く影響が発生している、ということです。

このような構造が、任意の合意について存在し得る、ということが重要です。つまり、浅い合意と深い合意では、間接的にもたらされる結果が大きく異なる、ということです。
これは、例えば算数の問題を解く練習をするときに、表面的に解法を暗記するのか、それとも自分の中で深く問題の構造を理解しようとするのか、といった差と同じようなものです。例えば文章題について、「出てくる数字を適当に四則演算に当てはめる」と解釈するか、それとも「言葉としての意味を理解して、適切な計算方法を検討する」と解釈するか、というようなこととも同じです。

浅い合意でもプロジェクト推進はできる

プロジェクトにおいて、「決めの問題」という言葉をしばしば耳にすることがあるかと思います。ないですか？
「決めの問題」というのは、案Xでも案Yでも、どちらの案を選択することも可能であり、決めたら決めたなりにワークする（ワークさせることができる）、というような意味合いです。決めの問題のうち、特に非本質的と思われることが、いわゆる自転車置き場の議論と呼ばれるようなものです。自転車置き場の屋根の色をどうするか？ということは、外観的にそれなりに重要なことかもしれませんが、しかし自転車を使う人にとって本質的に重要なことではありません。
一般論として、プロジェクトを進めるうえでは「決めないといけないこと」が沢山あり、その「決めないといけないこと」について合意を得ないとバラバラになってしまいますが、合意の深さは表面的なものでも十分なことがしばしばあります。先の例で言えば、自転車置き場の屋根の色を何色にするか、その経緯や深い意味を、自転車置き場の工事をする人が知らなければならないかというと、必ずしもそうではありません。「経緯を知っていたから出せる微妙な色合い」みたいなものもあるかもしれませんが、普通はそれはどうでもいいでしょう。
プロジェクトを進める上では多くのことが浅い合意で済みます。もちろん、全てのことが表面的な合意で済むわけではないですが、少なくとも、長期的なプロダクト開発と比較すると、浅い合意でよいです。
これは、出力を規定するという部分については十分にワークします。

長期的なプロダクト開発には深い合意が必要

一方で、長期的なプロダクト開発においては、深い合意が必要になります。それは、先程のコードリーディングの例などでもそうですが、「ある物事をどのようにして決めたか」という経緯や考え方の持つ情報量は豊富であり、合意によって直接的に規定されていることとは別の物事にも大きな影響が生じるからです。
一般論として、プロダクト開発を継続するとプロダクトはより複雑・高度になっていきますが、それはつまり プロダクトが扱う対象領域への理解が深まっていく ということを意味します。これまでに開発した機能や仕組みが前提となって、次の開発が行われることになります。そうすると、表面的な合意・ただ決まったことに従うというような理解であったとすれば、開発者は次に開発すべき機能の選定や、その機能のあるべき姿を規定することができなくなります。
これは、学校の勉強における落ちこぼれの構造と同じです。開発の一つ一つは、技術的に特に難しいことでもないのですが、表面的な合意の積み重ねによって段々と深まる議論についていけなくなり、やがて静かに脱落していく。自分が何をすれば「正解」であるかがわからなくなり、正解を当てるパズルが解けなくなる。そのような構造があります。
したがって、プロダクト開発を長期的に行っていく場合には、深い合意をする、つまり合意する内容の意味を自分の中でできる限り深く考えたうえで納得して理解する、とにかく深く腹落ちするまで考えて納得するということを繰り返していく必要があります。

納得するまで考えることが仕事

これ以降は、ここまでに書いた事実・事象・構造を踏まえて、私自身がどのように考えて取り組んでいるか、ということです。
まず、私は、仕事をするというのは「納得するまで考えること」だと思っています。もちろん、状況によっては根本的に納得できていなくても、決まった通りに動かないといけない、という場面もないわけではありません。ただ、そうした場面にあっても、その後にその納得できなかったことを解消するための動きを取り続けなければならない、と考えています。理由は、そうしないと上記のようなプロダクト開発の長期的な継続ができないからです。
これは、仕事の種類によっては必ずしもそうではないと思います。例えば、スポット的に高度な開発サポートを行うような種類の開発者にあっては、常にすべてのことについて深い合意が必要ということではないでしょう。ただ、そのような開発者においても、自分の業務領域における深い理解は必要だとは思います。
私の思うジェネラリストとは、一つ一つの物事については専門で詳しい人が別にいるかもしれないが、一方で自分のプロダクトや仕事の範囲において、それを決めた理由については、誰よりも筋を通して説明ができる人、です。これは、それ自身が責任を取れないAIによる開発が増加する将来においては一層大事なことだと思います。つまり、AIが様々な可能性を提供してくれる中で、どういう意図を持ってそれを選ぶかということを論理的にきちんと筋を通して説明ができる、ということが人間の仕事であると思っています。そのためには、理解していないことをコピペプログラミングするのではなくて、それが他人の意見だろうとAIの出力だろうと、自分の中で納得するまで考えるということが最も重要なことです。
すべてのことの詳細を厳密に理解するということではなくて、仮にブラックボックスが存在するならばどこからどこまでがブラックボックスであるかという理解も含めて、構造的に全体を把握して、かつそれが納得するまで考えられている、ということが我々の仕事だと思っています。曖昧な判断があってはいけないということではなく、仮に曖昧な判断をするとすればどこからどこまでが曖昧な判断かわかっていてコントロールができる、というのがあるべき姿であるということです。（これは、Rustのunsafeに似ているかもしれないですね！）

総じて、「決められたことだから」「合意したことだから」「合意しないと進められないことだから」ではなくて、「納得するまで深く考えたことだから」「できる限り深く考えて、合理的だと判断して選んだことだから」の積み重ねで物事を進めるのが仕事である、ということです。これは特に、他の人からのアドバイスやAIの意見などを取り入れる場合においてもそうである、ということです。

元が誰の意見であろうと、成果が出るならそれでいい

他の人、AI、その他資料。元が誰の意見であったとしても、納得するまで考えるということを経て、自分が納得していることを選ぶのであれば、何でもいいです。私は自分の意見を通したいわけではなくて、成果が出るという意味での正しい選択をしたいのであって、それが誰の意見であるとかは、「最終的には」むしろどうでもいいと思っています。これは「最終的には」であって、もちろん意見の精度という意味では誰の意見かということは大事だと思いますが、意見の検討自体はフラットに行うべきです。

同じ情報から別の結論が出ても構わない

ここまでに書いたような意見の検討がフラットに行われて、前提となる情報が揃って十分に考えて、それでも意見が割れることもあり得ると思います。それこそ、自転車置き場の屋根の色をどうするかというとき、感性のレベルでの意見は、情報が出揃ったうえでも個人の感覚によって変わってくるでしょう。
そのような物事については、私は「その仕事を担当する人が自由に決めればよい」と思っています。自転車置き場の屋根の色は担当者が最終的に決めればいいし、usをつけるかどうかもそのメリット・デメリットを十分に話し合ったあとであれば、極論誰が決めてもいいです。それが感性の差であったり、重みの差によって生じるような程度のものであれば、自由に決めてよいと思います。私自身が担当でない物事について、私は自分の直感から意見をいいますが、一方で多くの場合、その「答え」は持っていなくて、特定の「答え」に誘導したい訳でもないです。私の直感も検討したうえで、それで理由があって別の結論を選ぶならば、それは全く問題のないことで、納得のできること、合意した全員で健全に次に進めること です。統計的に私の意見が採用されることは多いかもしれませんが、正しく十分に検討されたならば、採用されなくてもよいのです。

守破離の離で色は勝手に出る

そのようなスタンスでプロダクトを作っていても、あるいはそのようなスタンスでプロダクトを作っているからこそ、作っている人の色は勝手に出ます。また同時に、勝手に成果も出て、勝手に成功します。
私の勝ちパターン、または私のチームの勝ちパターンは、とにかく納得できるまで考えて、かつ、最終的に合意した結論には納得する、です。これをやっていると、勝手にうまくいきます。おそらく他にも必要な要素はあると思いますが、根本的に一番重要なことは、このような行動パターンだと思っています。そうやっているうちに、勝手に私の成果と呼べるかもしれないものが後からついてくるのだと思っています。
これは、頭の良さ、あるいは頭の回転速度みたいなことは、全く関係ないと思います。もちろん業務領域の向き不向きはあるかもしれませんが、これの継続で必ず仕事ができるようになると思います。そのようなことを、私は証明していきたいと思っています。