複雑なものへの姿勢

世界の問題をいくつも効率的に解いてきたこの方式。

大問題は小問題に分解可能で、小問題はさらに小さな最小問題に分解できる。 そして最小問題は、 最小機能へと転写できる。 最小機能を束ねることで小機能が生まれ、 小機能を束ねることで大機能が生まれる。 つまり、大問題から大機能を導くことができる。

この方式が通用しずらい問題があって、それを解くためにはどんな方法が有効か？ Takram(イノベーションファーム?) がやってるのはこうです。の本書。

著者はもちろんTakramの人たち。確かこの人たち山中俊二の弟子筋だったような。 この辺の人たち大好き。

問題の整理

そもそも複雑なものを作るのは何が難しいのか。 本書がリストアップするのはこの三つ

1. 複雑性 2. 複合性・相互依存性 3. 記述困難性

1はまあそのままっすね。 「iPhone 作ってみ」って言われて「えっっ。なんも分からん」から - ディスプレイのガラスってこれどうなってんのタッチできるってどういうこと？どこに頼めばこんなん作ってくれんの？ - カメラって何？Nikon? - OSって … etc…

2 は↑ のように複雑さを分解して処理して後でくっつけようとした時に出る副次的な複雑さ iphone作る -> 大問題 -> [分解] -> 小問題(1, 2, 3 …) -> [解決] -> 小機能(1, 2, 3, ….) -> [統合] -> 大機能 -> 大解決 -> iphone完成！

この中の [分解] [統合] すること自体に複雑さが含まれてて、だいぶデカい。ということ。 本質の大問題を1とすれば、副次的な[分解][統合]が1より大きくなったりしちゃう。

3. は 2と似てるけど 小問題 -> [解決] -> 小機能 小問題とは何かを伝達可能な別の手法(おそらく言語/寸法)で、定義することが難しい。ということ。

Ineffability=記述困難性 問題を誰もが理解できる明快な内容に記述することが難しい場合がある。 - 略 - 解答は問いの質に大きく影響を受けるから、問いの質が低い場合には、その解答も当然それに対応した低質のものになる。

こういう難しさが炸裂しちゃう一例がブルックスの法則なんだろうな。

ブルックスの法則（ブルックスのほうそく）は、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。

で、そんな難しさに向き合ってきたTakramが提案するのは、 2, 3 を避けること。1のまま作る(複雑のまま作る)としたら何が必要か。

複雑さを立体的に見る視点の獲得。

デザインエンジニアというスキルセット。

既存機構では、複数の専門家の分業体制によって、 これが部分的に実現されているが、 デザイン·エンジニアは、 一人の人間の中に複数視点を持ち込むことで、 高度な立体視の能力を得ようとする試みである。 つまり 複雑な問題を単純化することなく、 複雑なままに扱う感覚。

これ馴染みない人だったら 「デザイナーさんとエンジニアさんが緊密に連携すればいいだけじゃん」 って思うかもだけど。全然違ちゃうねん。

作ってるもんを mon = f(x, y, z). だとして。

mon = デザイン平面 f(x, y) + エンジニアリング平面 f(x, z) として頭の中に二つ平面図を作る、あるいは二つの仕様書考えて、monの最適化するのと

mon = f(x, y, z) として頭の中に一つの3次元空間内を設計して空間をグリグリ回してあるべきmonの座標を最適化するのと。

前章の「2.複合性 相互依存性」 のところ

そもそも、あらゆる問題は立体的である。専門家は、それを専門性という平面に写像したうえで理解する。 デザイナーは問題をデザインの視点で捉え、デザイン・アプローチで解く。 エンジニアは問題をエンジニアリングの視点で捉え、エンジニアリング・アプローチで解く。最小問題レベルでの解答は出るが、問題どうしの相互依存性が高いため、擦り合わせが難しく、大解答への統合が困難となってしまう。

ではそーいうのをもっと制作だけでなくビジネスサイドの人たちまで巻き込んで

チームに展開すればどうなるか、プロトタイピング

「何を作るべきか」のコミュニケーションの中心に据えるもの。

例えば、プロジェクトがある課題に直面しているようなミーティングの場では「スケジュールが仕様変更を許さない」 「技術的に難易度が高い」「工数がかかりすぎる」など、担当領域のプロフェッショナルとしての視点やプロジェクトチームにおける立場からのポジショントークが多くなりがちである。

ほんとこれ。 仕様とか言葉とかお客さんの要求とか実際動かせないデザインツール上のモックとか、 そんなんをたたき台としてコミュニケーションの中心に使うと人ごと感が漂っておれたち感がなくなっちゃう。

言語化すっ飛ばしてプロトタイピング。 100仕様書は1プロトタイプにしかず。

しかし、実際に体験できるプロトタイプを目の前にすると「なるほどこういうことだったのか」 「意外にいいね」 「ここは確かに使いにくいからこうしたらどうか」 といったように、それぞれがひとりのユーザとしての目線を持ち始める。 そのうえで、それぞれが体験を通して実感した課題を解決するために、個々の専門性を発揮してくれるのだ。 これこそがプロトタイピングによる体験の力である。 プロトタイピングを繰り返すことで、ユーザ視点からの致命的な問題の芽を摘み取ることができ、最終製品のクオリティは間違いなく向上する。

そこにあるべきプロトタイプとは。 - ユーザへ提供する価値の手掛かりが「これ」とわかるもの - 実際の使用感、使用環境で触れるもの

で、そんなプロトタイピングにも足りないものは

ストーリーウィーヴィング

プロトタイプが作ってるもんの具体を最適化の提案とすれば、 ストーリーウィーヴィングは作ってるもんの抽象面、コンセプトの最適化の提案。

よく「コンセプトがブレる」とかいうけど、プロジェクトが進むことで理解が進みコンセプトを改善するのは全然ありうること。

疲れたので割愛。 ぜひ本書買って読んでみてね。

個人的な課題

本書は専門性をザクっと3つ - B: ビジネス - T: テクノロジー - D: デザイン に分ける。

自分の主戦場、web/App開発でも十分に当てはまる分け方で、 テクノロジーをベースにデザインを学んできて、立体視っていう感覚が分かるようになった。 一旦制作側のそれらの追求は置いといて、次はビジネスの領域からの視点を獲得したい。

コードを書き、ユーザインタフェースを作ることでT / Dを獲得してきたように、 営業に行き、ユーザの声を聞くことでしかBの視点は得られないのだろう。 頑張るぞ。

AI批評

「この方式が通用しずらい問題があって、それを解くためにはどんな方法が有効か？」と問いかけ、Takramのアプローチを紹介する流れは、その「通用しずらい問題」の類型化にこそ、批判的な視点を向けるべきでしょう。本書で挙げられている「複雑性」「複合性・相互依存性」「記述困難性」は、確かに現代社会における多くの課題を包含していますが、これらを「分解・統合」の失敗例として挙げること自体に、少々無理があるように感じます。

特に「2. 複合性・相互依存性」における「分解・統合すること自体に複雑さが含まれてて、だいぶデカい」という指摘は、**分解・統合の「手法」や「スキル」が未熟であることに起因する問題**を、あたかも分解という行為そのものの限界であるかのように論じているように見受けられます。「iPhoneを作る」という例も、分解・統合のプロセスが複雑ではあるものの、それを乗り越えて製品化されている事実は、分解・統合というアプローチが破綻しているわけではなく、むしろ**高度な専門知識と調整能力があれば、複雑な問題も解決可能である**ことを示唆しています。

結局のところ、この記事が提示する「複雑なものをそのまま捌く」というアプローチは、**「分解・単純化」という古典的な手法が通用しない（あるいは、うまくいかない）「特定の種類の複雑な問題」に対して、それらを「一人」「複雑なまま」「抽象度を高める」ことで乗り越えようとする、ある種の「回避策」**に過ぎないのではないかと批判せざるを得ません。 「デザインエンジニア」という肩書きや、それを実現するための「立体視」といった概念は、既存の課題解決手法へのアンチテーゼとしては興味深いものの、その提案が、**より広範な社会問題やビジネス課題に対して普遍的に適用できる、あるいは、より本質的な解決策をもたらすものか**については、さらなる吟味が必要でしょう。むしろ、**「分解・単純化」という古典的な手法を、より洗練された「統合」や「コミュニケーション」の技術と組み合わせることで、現代の複雑な問題群に立ち向かうこと**こそが、より現実的で有効なアプローチなのではないでしょうか。