さて、今朝思いついた 検図サービス についてだけれども、いくつか反省があるのでメモしておこうと思う。
まあ、そもそも検図サービスなんてものが、需要のあるものなのかどうか僕にはまだ見当もついていない。けれども、例えばMakerbotは初期の段階ではメカの強度が足りていなくてヤバかったみたいな話を聞くと、あった方が良いんじゃないかなと思う。確かにMakerbotは成功さプロジェクトだし、それは時間が解決する問題なのかもしれないが、プロジェクトの成功までのショートカットができるのであれば、意義のあることに違いないと思う。
承認プロセスという概念が気に入らない
でも、検図というものは上位職者が若手の図面の誤りを修正して承認するというプロセスだ。つまり、アンバー組織的な営みであり、オープンソースプロジェクトのような個人をターゲットとしたプロジェクトに馴染まない可能性もある。承認権限は誰にあるのかという話になってしまうが、オープンソースプロジェクトにそんなものはないし、そもそも依頼主と検図者に上下関係などない。
承認プロセスではなく助言プロセス
だから、検図という概念をアップデートしなければならない。そして、その方向として有力なひとつの方向性は、ティール組織的な助言プロセス的検図だ。助言検図者は承認するのではなく、あくまで助言するだけに留める。助言検図の依頼主は、自分のアイディアの幅を広げたり、図面の正確さを高めるためにこのプロセスを利用する。最終的に決めるのは依頼主だ。当然と言えば当然のことだ。
そもそも、発注という概念が気にくわない
しかし、そうなると発注者が偉いみたいな風潮になってしまうけれども、決してそういう訳ではない。そもそもこんなサービスを受ける人は自分の誤りを正したいという、ネガティヴなフィードバックを望んでいる訳だから、そのフィードバックを無視することはないだろう。もし、アドバイス通りにしないことがあるとすれば、設計思想の優先度が依頼者と助言者間でズレただけの話だ。検図という対話を通して、納得してブラッシュアップさせるプロセスを発注と称するのは僕は気にくわない。これは、協創と呼ばれるプロセスであるべきだ。
従来のプラットフォーマー志向を捨て、DAOを志向せよ
そして、やはりオープンソースプロジェクトを意識するならば、従来のプラットフォーマー的な立ち位置で話すのは最終目的地を見失いそうな気がする。UberやAirbnb的なものではなく、DAO（分散自律組織）であるべきだ。この部分は個人的な信念の話なのだけれども、オープンソースを志向するならば、そのプロジェクトのためのツルハシはそれに親和性の高い形態にするべきだと思う。DAOはオープンソースプロジェクトのための資金調達や貢献への報酬に関する機能を有するので、その形態にマッチさせるようにデザインすることが肝心なのではないだろうかと思う訳だ。
そんな感じで、思いつきに対する現時点の考えを書いてみた。将来、皆さん（というより自分自身）の役に立てば良いなと思いつつ。