Review : 山中俊治著 「デザインの骨格」

ずいぶん長いこと積読でしたが、やっと読了しました。

デザインの骨格

デザインの骨格

個人的には、もともと機械工学専攻でロボットやシステムを研究していたこともあって、とても共感できる内容の多い書籍でした。 当時のメカトロニクスエンジニアは、今はデザインエンジニアとしてキャリアを描いているのがちょっとうらやましかったり。

あとは漫画が印象的でした。
そういえば僕も小中学校の頃は、よく漫画を描いていたし、絵を描くのが好きで、市の展覧会に展示してもらったことなどを思い出したりしました。 機械工学科のときも、そういえば絵を描いている友人も結構いて、機械屋とプロダクトデザイナーという職は、実は同じ感性のライン上にあるのかもしれないなどと思ったりしました。

以下、ソフトに軸足を置く人間として心に留まった言葉をいくつか書き留めて起きたいと思います。


技術者は常に性能向上を目指します。しかし、新しい価値は、性能のいかんにかからわず、はじめからその技術自体に遺伝子のように組み込まれているように思います。

確かにそうかもしれない、と思いました。
音を信号化する技術の本質はコンパクトに持ち運べること、つまりポータビリティだとするとWalkmaniPodは納得できる。 iPodWalkmanよりも音楽のポータビリティが高かったから、改めて市場に受け入れられたのかもしれない。

ソフトに携わる僕としては、「では、ソフトウェア技術の本質とは?」と思わずにはいられません。
僕はふと、「ソフトウェア技術の本質は、世界を概念化すること」じゃないかなと思いましたが、まだ噛み砕けていない感じがします…


美しくない設計は、はじめから美しくする気がないか、美しくする時間がないかのどちらか

どうしてもスケジュールや仕事量の管理結果から、美しくする時間がとれず、結果的に妥協することが多かったと身につまされる言葉でした。 この妥協が、僕のキャリア上の弱みだし、アウトプットの弱さだと改めて突きつけられたようで、非常に恥ずかしいところです。プロ失格…

とはいえ、物理世界を相手にしている機械と概念を扱うソフトウェアでは、実はUIの美しさとコードの美しさが必ずしもその連続の上にない気がしています。 この場合、そもそもここで言う「美しさ」とはなにか?ということ自体が不明瞭かな。


あなたが納得しているなら、何も言わない。

これも妥協。納得していないのに、自分を無理に納得させて先へ進めてきたという自戒。 壁にぶつかったとき、この言葉を思い出したい。そう思いました。


747には独特の威厳がある。乗客にしろ、パイロットにしろ、そこを気に入っているわけだが、それこそが人類に貢献している点で、その貢献は無視できないほど大きい。

この飛行機のもつ「威厳」は、機能でもないし、論理的に説明もできないと思うけど、その重要さはわかります。
僕は会社で、「心の豊かさ、という価値へのアプローチは製品の機能性ではなく、きっと官能性ーある種のセクシーさによってもたらされるのではないか」という話をしました。 ただの機械が愛機へと変わるには、そういった性質を宿すことは不可欠だと思ったからです。それはソフトウェアにも言えるだろうと思っています。


図面というのは、設計者と製作者をつなぐ言葉のような物。もし自在に臨機応変に最終素材を加工することができるなら、デザインと製作は同時であり、記号化された情報の交換は必要なくなります。 自分がまだまだ産業革命以降の兼題の枠踏みの中だけで思考していたことを思い知らされた経験でした。

ソフトウェアではしばしば、デザインと製作が同時であると言われることを思い出しました。しかし、現場では設計書や発注書がコード以上に作成され、情報交換されているのが実情です。
アジャイル開発では、そこにメスを入れる哲学がありますが、導入には意識改革からといわれるように、20世紀のものづくりの延長概念そのものがその大きなハードルなのかもしれないと思いました。

実はコードの美しさについては、僕はリーダブルコードであることだと思っていて、それはコードはソフトウェアそのものであると同時に、他のチームメンバに読んでもらう設計書でもあるからです。
デザインと製作が同時になれば、コードと動作するソフトがすべての中心になる。そんな開発が理想です。


感覚を射抜く言葉をみつけよ

イデアソンなどで、よく感じます。一言で表現できるのは、その対象についてどれくらい理解ができているかのひとつのバロメータだと思います。 あとボキャブラリーも必要な気がします。


便利って、美しさと矛盾するから大変なんだよ

ソフトウェアでもよく直面する課題です。バランスをどうとるのか、というところをもっと追求したいところです。