「設計力」について、というのをずいぶん前からやろうと思っていたが、今頃になってしまったよ。
「会をうまく進行できただろうか?」
今回はブレストやディスカッションの形で行なってみた。
想定外だったのは、都合で若手が参加できなかったこと。経験の浅い人が質問することで、
場が活性化されること、それから、教える-教えられる の形が生まれること を期待していたのだけれど。
特に後者は一番のねらいだっただけに非常に残念だった。
場に期待を持ちすぎたと思う。主催者として責任を持って進める、準備と気持ちが足りなかった。
そして、その場で議論をつくっていくテクニックも必要だとわかった。
参加者に合わせて、私の方から問いを投げ、議論をドライブしていかなければ。
また、参加者にはっきりとしたゴールを示していなかったこともよくなかったのかもしれない。
もちろん、参加者自身に見つけてもらいたいという想いもある。
だが、ワークをしてもらうだけで、誰もがねらった結果に向かい、気付きを得るわけではない。
具体的なゴールを示すことで、議論がそちらに向かう場面もあるのではないか、ということだ。
事前に準備した枠にとらわれすぎず、少し大きな視野を持って、
自分自身がゴールを見失わず、場をコントロールしていくことが必要だ。
「設計という行為は何なのだろう?」
この勉強会の中であらためて気付いたことは、
我々が使っている「◯◯図」というヤツは「フレームワーク」だったのだ、ということ。
◯◯図を描くこと自体が目的になっていることも多いが、本来は
「何かを設計したくて、何かを明らかにしたくて」それを描いているのだ。
そのことを意識させないのも、フレームワークゆえ、だけども。
この、設計図のフレームワークとしての目的を意識することで、もっと漏れのない堅実な設計ができるかもしれないし、
設計すべき順序や、使うべきアタマ(設計の観点)も明確化するのではないか、と思った。
ただ、みんなの話しを聞いていると、やはり図を描くことがゴールになっていて、
その最中の「あれを考え」「これを決めて」という、設計項目を洗い出し、具体化していく行為については、
無意識のうちに、しかもみんなまとめていっぺんに、やっているようだった*1し、
何を描くのか、という点でも、経験をベースに感覚的にチョイスしているふうで、
選択基準のようなものを持っているようではなかった(と感じた)。
周りや過去(の設計書)を真似て作っている、という話しもあり、何かことさらに意識しているふうではなかった。
一方で、設計過程としての成果物ではなく、後から誰かのための解説資料になるのも設計(書)だ。
いろんな目的で作られ使われる。あまりカタいことを考えることもないのかもしれないナ...。
「設計をどうやって身に付けたのだろう?」
クラスやメソッドをどうやって考えているのか?という話では、ある若手の参加者が
「Javaから入ったので*2、関数化はよくわかる」と言っていた。
また「何度もつくり直していくとキレイな形になる」とも話してくれた。
私は、関数化やモジュール分割については、身に付くまでかなり苦労した。
やはり周りの先輩たちの作っているものを見て学びながら、徐々に部品化の方法を理解していったわけだが、
「お手本があること」と「経験を積むこと」の2つは確かに大事なことかもしれない。
「うちの仕事って...」
...って、ちょっとかたよっているのかな? と思った。
仕様を具体化しブレークダウンする方向のものが多い。
「ドライバなんて、初めから仕様が決まっている」という声もあった。
確かに「組込みで下回り」なので、動くものをつくるのが仕事であるし、こういう方向になるのはやむを得ないか。
一方で、シンプルに概念化したものを扱いながら設計する、いわゆる「モデリング」というヤツもある。
ザ・設計 という感じだ。
こちらの分野では、はたしてやれるのだろうか?
我々は下請けで、仕様はお客さんが考えること、と思う人もいるのだろうか?
いろんな仕事があるのは当然なのだけど、今のままでいいのだろうか...。