あなたはどうやって絵を描く?〜ざっくりアウトラインから?それとも一部分毎に詳細に?〜

「ソフトウェア開発ファシリテーション」アドベントカレンダー13日目の記事です。

「ソフトウェアってどうやって作っていけばいいんですかね?」

と問われたときに、私が一番最初に思い浮かべるのは絵画のメタファーです。

みなさまが絵を描くときって、どんな風に描いているでしょうか?

キャンバスをいくつかのブロックに区切って、それぞれのブロックを正確に描いていくようなアプローチで絵を描くでしょうか?

それともざっくりアウトラインを描いた後に、全体の修正を繰り返しながら完成に近づけていくようなアプローチで描くでしょうか?

前者のアプローチで絵を描ける天才もいると思いますが、大体の人は後者のアプローチなのではないでしょうか。

しかしながら、ソフトウェアの設計を考えるときになぜかされてしまいがち(?)なのが、前者のアプローチです。全体としてどうなのか?を考えるフェーズで、一つ一つの機能を緻密に考えてしまうようなアプローチです。緻密であればあるほど作り込まれているような気がしてその場では安心できるのかなと思うのですが、実際に動かして見ると違和感があったりします。しかしその緻密さゆえに、動かすまでが大変だったりして、後戻りしなければならなくなったときのダメージが大きいわけです。

ざっくり全体を描いてみて、この全体が上手く回るかどうか検証するための最小限の機能を搭載したソフトウェアを作るようなアプローチのことをMVP(Minimum Viable Product)と呼んだりします。私の周りでは「まず一周回す」と言ったりします。いざとなればもう一度最初から作り直せるぐらいの文量に抑えられれば良い設計です。いかにミニマムに設計できるかが腕の見せ所です。

ちなみになぜ絵画のメタファーなのか?というと、私自身が絵を描くことが好きなのと同時に、テクノロジースタートアップのシードアクセラレータであるYコンビネータ(有名どころではDropboxやAirbnbが出資を受けています)の創立者でありLispプログラマーであるポール・グレアム氏の書いた『ハッカーと画家』という本が好きで、そこでも絵画のメタファーが出てくるからです。

絵画から学べるもうひとつの例は、次第に詳細化しながら創ってゆく方法だ。絵画はたいてい、スケッチから始まる。そして次第に細かい部分が埋められてゆく。だがそれは、単に隙間を埋めてゆくだけの過程ではない。X線で見てみると、手や足の位置が変更されていたり、表情が変えられたりしている絵画は数え切れないくらいある。

(中略)私はハッキングもそうあるべきだと思っている。プログラムの仕様の完璧さを期待するなんて非現実的だ。

ポール・グレアム著『ハッカーと画家 コンピュータ時代の創造者たち』P.31より引用

全体を描くためにはユーザーストーリーマッピングを活用して全体を見える化しながら進めたり、実際に動くソフトウェアをプロトタイピングしたりといった様々な方法があります。絵を描くこともコードを書くことも、ソフトウェア開発のファシリテーションにとっては必要なリテラシーだと思います。