サイトアイコン NegativeMindException

そのアプローチは帰納的か演繹的か

長く書いたけど、結局また上手くまとまらなかった。

先週のSSII 2015のチュートリアルセッションで林さんが語っていた「設計とプロトタイピングのバランス」の話が頭の中でグルグルと回っている。
「帰納的アプローチと演繹的アプローチ」の割合、自分はどっちにウェイトを置いた方が上手く行くだろうか、と。
取りかかろうとしている作業(開発とか)が、自分にとって未知なジャンルなのか、既知のジャンルなのかで変動させるべきなんだろうけど。

色々考えて、思考法の違いについて書かれたこちらの記事を思い出した↓

「理系と文系」より「帰納と演繹」

思考法には演繹法帰納法があって、この思考法で分類してみるほうが理系/文系の分類よりも面白そうに僕には思える。そして「文化」の衝突も理系/文系と同じくらい、帰納派演繹派の間で起こっているような気がする。

(中略)

思うに、若いうちは演繹的な思考力が強く、経験を積むにつれて帰納的な思考が得意になる。

実は僕自身、思い当たるふしがある。昔と比べてデバッグの効率は明らかに上がったと思う。「あの辺に原因がありそうだな」という嗅覚が以前よりも働くようになった。後輩が「くそっ、原因が分からん!」とハマっている様子を横から眺めて、「この辺が怪しいんじゃない?」と適当なことを言うだけで当たってしまうこともある。そんな時はきっとドヤ顔(恥ずかしい・・・。

しかし、プログラマという職業は絶対「演繹派」が向いていると思うんだよね。帰納派プログラマはどうも頂けない。例を挙げると、ある関数の動きを知りたい時に演繹派プログラマはソースを読むのだが、帰納派プログラマは「実験」するのだ。ソースは読まずにブラックボックスのまま、とりあえず引数を色々変えながら呼んで実験をして、その実験結果から関数の仕様を類推するのである。

一見、帰納派プログラマの方が要領の良いアプローチに思える。実際、瞬発力的な比較で言えば帰納派の方が仕事が早い。しかしそのアプローチではプロジェクトが早晩破綻する。効率よくバグのないソフトウェアを開発するためにはコードをキレイに保つ必要があり、コードがキレイであるということの評価軸の一つは、演繹的な論理の流れが端的にすっきりと表現されているかどうかである。そういう視点を持たない(あるいは希薄な)帰納派プログラマは、デバッグや緊急対応のような瞬発力が要求される場面では活躍するかもしれないが、長期的に見ればプロジェクトにダメージを与えてしまうと思う。

技術の進歩で手軽な開発ツールで満たされている昨今、プロトタイピングの敷居が下がって、帰納派でもアウトプットの質を上げることができるようになったんじゃないかと思う。今の時代なら、未習熟者でもそれなりに参入できて、アウトプットにこぎ着ける手段がある。一昔前なら、それなりに演繹的に計画してからでないとまともにカタチにはできなかったはずだ。

ウォーターフォールって開発スタイルはかなり演繹的なやり方だよね。



スポンサーリンク

工学と理学

こういうの、工学と理学のアプローチの違いかもなぁ。と、ふと大学・大学院時代を思い出す。
オイラは情報系だったけど、いわゆる工学系の先生と理学系の先生が混在していた。(ちなみにオイラがもらったのは理学の学位でした)

この話に当てはめてみれば、工学系の先生は帰納的、理学系先生は演繹的な思考過程を教えているような印象だった気もする。

帰納的→ボトムアップ
演繹的→トップダウン

と言い換えても良いかもしれない。工学系のアプローチは、過去から脈々と続く古の部品群があり、その上に現在の技術が乗るような、積み上げ式の文化があるような気がする。工学とはトライ&エラーの歴史だ。

それに対して、理学系のアプローチは、まず真理となるルールを定義し、そのルールに則って作れば自ずと細部まで矛盾なく完成する、っていう考えがあるような気がする。例外を許さないというか、例外があるならルールが不完全という認識。

ん、違うか?よくわかんなくなってきちゃった。ただ、大学院在学中は、この2つの考え方の違いを結構意識していた気がする。

デザインプロセスの話

話を軽い方向へ持っていく。
インタラクティブなコンテンツの開発作業は、割と帰納的なアプローチが中心となる気がする。少なくともオイラが関わったものはそうだった。
よほどの天才でもない限り、「頭の中に完全なイメージがすでに存在していて、それを外へ出力するだけ」というプロセスでインタラクティブなデザインを仕上げられる人はいないと思う。
粗いイメージでもアウトプットしてみて、それを見てまた考える。より具体的になったそれを受けて、また考える。その手助けをするツールが豊富でとても良い時代だ。

インタラクティブコンテンツに限らず、最近の立体造形は非常に複雑で、昨今のツールの恩恵をダイレクトに感じる。特に、複雑なパーツが折り重なって構成されているようなメカのデザイン。
コンセプトデザインの現場でZBrushがデファクトスタンダートになっているのも納得できる↓

Atom-Eater Robot – スーパーコンセプトモデラーVitaly Bulgarov氏によるメカアリクイ制作タイムラプス映像!



以前、頭の中にぼんやりとある飛行機的なビークルのデザインイメージを、プラモデルのパーツの寄せ集めで何とか実体化させようとしたことがあった。
雑誌の付録で付いてきたカスタムパーツや、キットのジャンクパーツを瞬間接着剤でつなぎ合わせて、サーフェイサーを吹いた↓



これも帰納的アプローチということか。オイラ、帰納的なアプローチでカタチに持っていく方法を結構考えてたんだな。(気づき)

追記:論理的推論には、演繹、機能だけでなく、Abduction(仮説形成)というのもある。


スポンサーリンク

関連記事

  • 『さらば あぶない刑事』を観た
  • ZBrushのZScript入門
  • ZBrushでアヴァン・ガメラを作ってみる おでこ(?)のバランス調整
  • ZBrushCoreのTransposeとGizmo 3D
  • ZBrushで仮面ライダー3号を造る 仮面編 失敗のリカバー
  • PCの自作
  • まるで成長していない
  • 劇場版『仮面ライダーエグゼイド トゥルーエンディング』を観た (ネタバレ無し)
  • ZBrush キャラクター&クリーチャー
  • 2022年4月 振り返り
  • 2016年の振り返り
  • 2020年3月 振り返り
  • 中学3年生が制作した短編映像作品『2045』
  • デザインのリファイン再び
  • 『帰ってきたウルトラマンの世界』展
  • こんなところで身体を壊している場合じゃない
  • 2018年1月~3月 振り返り
  • ZBrushでアヴァン・ガメラを作ってみる 頭頂部の作り込み・舌の追加
  • 頭がいい人
  • 文章を書く時の相手との距離感
  • OpenMesh:オープンソースの3Dメッシュデータライブラリ
  • ラクガキの立体化 反省
  • Mayaのポリゴン分割ツールの進化
  • 2022年5月 振り返り
  • 2021年5月 振り返り
  • ZBrushでアヴァン・ガメラを作ってみる 脚のポーズ調整
  • 書籍『天才を殺す凡人』読了
  • デジタル写真のRAW現像と銀塩写真の現像の感覚
  • ZBrushで仮面ライダー3号を造る 仮面編 横顔のシルエットをリファレンスに合わせる
  • ZBrushで仮面ライダー3号を造る 仮面編 Dam Standardブラシでディティールを彫る
  • ZBrushで仮面ライダー3号を造る 仮面編 Clay Polish
  • 2020年10月 振り返り
  • ZBrushトレーニング
  • iPhone5S → iPhone6S
  • 2019年12月 行動振り返り
  • 映画『ハン・ソロ/スター・ウォーズ・ストーリー』を観た (ネタバレ無し)
  • Structured Approach
  • ZBrushのキャンバスにリファレンス画像を配置する
  • 世界ふしぎ発見!「特撮の神様 円谷英二の世界」
  • 『THE仮面ライダー展』を見てきた
  • 書籍『伝わる イラスト思考』読了
  • マルチタスクに仕事をこなせる人とそうでない人の違い
  • モバイルバージョンを終了