Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

社内勉強会のふりかえり(「設計力」とは?篇)

「設計力」について、というのをずいぶん前からやろうと思っていたが、今頃になってしまったよ。


「会をうまく進行できただろうか?」

今回はブレストやディスカッションの形で行なってみた。

想定外だったのは、都合で若手が参加できなかったこと。経験の浅い人が質問することで、
場が活性化されること、それから、教える-教えられる の形が生まれること を期待していたのだけれど。
特に後者は一番のねらいだっただけに非常に残念だった。

場に期待を持ちすぎたと思う。主催者として責任を持って進める、準備と気持ちが足りなかった。
そして、その場で議論をつくっていくテクニックも必要だとわかった。
参加者に合わせて、私の方から問いを投げ、議論をドライブしていかなければ。

また、参加者にはっきりとしたゴールを示していなかったこともよくなかったのかもしれない。
もちろん、参加者自身に見つけてもらいたいという想いもある。
だが、ワークをしてもらうだけで、誰もがねらった結果に向かい、気付きを得るわけではない。
具体的なゴールを示すことで、議論がそちらに向かう場面もあるのではないか、ということだ。

事前に準備した枠にとらわれすぎず、少し大きな視野を持って、
自分自身がゴールを見失わず、場をコントロールしていくことが必要だ。


「設計という行為は何なのだろう?」

この勉強会の中であらためて気付いたことは、
我々が使っている「◯◯図」というヤツは「フレームワーク」だったのだ、ということ。

◯◯図を描くこと自体が目的になっていることも多いが、本来は
「何かを設計したくて、何かを明らかにしたくて」それを描いているのだ。
そのことを意識させないのも、フレームワークゆえ、だけども。

この、設計図のフレームワークとしての目的を意識することで、もっと漏れのない堅実な設計ができるかもしれないし、
設計すべき順序や、使うべきアタマ(設計の観点)も明確化するのではないか、と思った。

ただ、みんなの話しを聞いていると、やはり図を描くことがゴールになっていて、
その最中の「あれを考え」「これを決めて」という、設計項目を洗い出し、具体化していく行為については、
無意識のうちに、しかもみんなまとめていっぺんに、やっているようだった*1し、
何を描くのか、という点でも、経験をベースに感覚的にチョイスしているふうで、
選択基準のようなものを持っているようではなかった(と感じた)。
周りや過去(の設計書)を真似て作っている、という話しもあり、何かことさらに意識しているふうではなかった。

一方で、設計過程としての成果物ではなく、後から誰かのための解説資料になるのも設計(書)だ。

いろんな目的で作られ使われる。あまりカタいことを考えることもないのかもしれないナ...。


「設計をどうやって身に付けたのだろう?」

クラスやメソッドをどうやって考えているのか?という話では、ある若手の参加者が
Javaから入ったので*2、関数化はよくわかる」と言っていた。
また「何度もつくり直していくとキレイな形になる」とも話してくれた。

私は、関数化やモジュール分割については、身に付くまでかなり苦労した。
やはり周りの先輩たちの作っているものを見て学びながら、徐々に部品化の方法を理解していったわけだが、
「お手本があること」と「経験を積むこと」の2つは確かに大事なことかもしれない。


「うちの仕事って...」

...って、ちょっとかたよっているのかな? と思った。

仕様を具体化しブレークダウンする方向のものが多い。
「ドライバなんて、初めから仕様が決まっている」という声もあった。
確かに「組込みで下回り」なので、動くものをつくるのが仕事であるし、こういう方向になるのはやむを得ないか。

一方で、シンプルに概念化したものを扱いながら設計する、いわゆる「モデリング」というヤツもある。
ザ・設計 という感じだ。
こちらの分野では、はたしてやれるのだろうか?
我々は下請けで、仕様はお客さんが考えること、と思う人もいるのだろうか?
いろんな仕事があるのは当然なのだけど、今のままでいいのだろうか...。

*1:それはそれですごくて器用なことなのかもね

*2:うちはまだまだCがメイン。C++さえ珍しいよ(少なくとも私は)。