絵を描く男とプログラミング

あるプログラマのデザイン手法から妄想してみる話。

絵を描く男

メンバーを公募で集めたりすると色んな能力の人と会う機会がある。私自身の進め方もあるが、人によって考えのまとめ方や進め方が違うのが面白い。

今回の話の技術リーダーはとにかく絵にする、というか構造をビジュアル化する。UMLなんかで書いて残してもいるだろうが、検討の間はホワイトボードフル回転である。描いて、消して、描いて、消す。

私はあまり描かない人なので何かコツがあるのかわからないが、まぁそれで議論が効率よく進むので「ほー」と思いながら見ている。

(Linuxのオープンソース開発だとアスキーアートになることもあってほとんど絵は書かない、どちらかといえば文章化が要る。）

チームは若手が多かったのだが半年も経つとみんな絵を書いて議論するようになっているので「あれ？絵なんて描いてたっけ？」と尋ねると「何言ってるんですが、描かないと議論できないでしょ」と言われる始末。

では、絵を描いて「これでいい」と判るのか？

視覚情報

進め方を聞くと、こういう風にモノ造りをするんだそうである。

１. 絵に描いて設計する
２. 試してみる
３.  １に戻る

で、何ループか回すと絵を描いた時点で「これでいい」と感じるそうだ。

絵を描く描かないに関わらず皆やってることは同じなんだろうとがコードの前にビジュアル化されているのはチーム作業的には正解なんだろうなと思う。ではどうしたら「これでいい」と判るようになるのか。

本人にインタビューすると（あまり話したがらないが）どうも囲碁を本気でやってたらしい。そう聞くと視覚情報をベースに可能性を検索し、イテレーションを繰り返して正解を引き当てるという訓練が積まれているのであろうかという気がする。形勢判断が肝かなぁ。

局面の理解ができていないといけないので色んなパターンを経験・妄想しているという経験値が必要そうだけども直感の働く余地はありそうである。

※分散システムの”正しさ”を形式手法で証明するのはそれはそれで大切だと思うので検証方法とはまた別の話。

機械化

囲碁というとDeep Learningを思い出してしまう。上のような話を聞くとビジュアル化さえすれば「これでだいたい良いかどうか」AIで学習可能なんじゃないか妄想する。ハードルは高そうなんだけども。

- ビジュアル化手法
- パターンの蓄積
- 評価方法

いや、高いか？違和感を検知するような技術は作れそうだけどなぁ（もう商用化されているのがあったりするのかな）

色んなブレークスルーは可能性としてあるかもしれない。

天才ゲームデザイナーを必要としないアクションゲームのレベルデザインみたいな話では傑作ゲームのプレイヤーの緊張と弛緩を計測し、計測された緊張曲線に沿うように敵を配置するみたいな話もあったりする。ゲーム体験は同じになってしまうが.....

結局、我々は何を計測しなければいけないのかって評価方法の問題なのか。だけど、エンジニアの脳内では評価ができてるんだよなー。3年もしたらAIが設計・デザインパターンを提案してくるんだろうか。それはそれで面白くないけど。

それはそれとしてリモートワーク状態だとホワイトボードで絵を描けないのがそれが問題である。目下のところ。