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

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

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

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

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

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

(中略)

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

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

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

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

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

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


スポンサーリンク


スポンサーリンク

工学と理学

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

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

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

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

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

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

デザインプロセスの話

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

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

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

Atom-Eater Robot – 3DModelling/Design Timelapse

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

ぼくのかんがえたビークル

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


スポンサーリンク

関連記事

ZScript
2018年6月~7月 振り返り
ZBrushで仮面ライダー3号を造る 仮面編 失敗のリカバー
脳波で遊ぶゲーム 東京ゲームショウ2009
1週間のサイクル
ZBrushの作業環境を見直す
タイトルが記事の見出しみたい
共通の「思い出のコンテンツ」がない世代
「考える」と「調べる」は違う(と思う)
ラクガキの立体化
Maya LTでFBIK(Full Body IK)
ZBrushのキャンバスにリファレンス画像を配置する
文章を書く時の相手との距離感
ZBrushで仮面ライダー3号を造る ベース編
自分への質問
携帯電話ロボット『RoBoHoN(ロボホン)』
ガワコス
映画『ドラえもん のび太と雲の王国』を観た
「ウォーリーをさがせ!」が実写映画化←観客が必死にウォーリーさがすの?
ZBrushのハードサーフェイス用ブラシ
機動武闘伝Gガンダム
Windows Server 2008に触ってみた
2019年12月 行動振り返り
書籍『天才を殺す凡人』読了
ゴジラ トレーディングバトル
職場におけるセルフブランディング
Mr.ビーン
ZBrush4新機能ハイライト 3DCG CAMP 2010
2012 昨日のクローズアップ現代を見た
S.H.MonsterArts ゴジラ(2001)はプレミアムバンダイで発売
手軽な娯楽
書籍『The Art of Mystical Beasts』を購入
TOHOシネマズ新宿
まるで成長していない
調べものは得意なのかもしれない
映画『ドラゴンボール超 ブロリー』を観た (ややネタバレ)
布のモデリング
自分の性質
布地のシワの法則性
Structured Approach
ZBrushからBlenderへモデルをインポート
マイケル・ベイの動画の感覚

コメント