経験由来の技術と理論由来の技術

Posted by Hiraku on 2013-07-10

主観入りまくりですが、技術というか知識とかノウハウには経験由来のものと理論由来のものがあって、この違いは意識した方がいいのではないか、と最近思っています。

私の主観に基づく分類

経験由来 理論由来
  • プラクティス、バッドノウハウ、アンチパターン
  • デザインパターン
  • アーキテクチャパターン
  • オブジェクト指向
  • フレームワーク
  • アジャイル・開発手法系
  • MVC
  • 帰納的発想
  • 人間らしい直感を重視する
  • ふわふわ・もやもや
  • ふわふわ・もやもやしているものを扱う
  • 人間を扱う
  • たまに精神論が混じる
  • アルゴリズムとデータ構造
  • 暗号、圧縮、人工知能、etc
  • 関数型
  • SQL(リレーショナルデータベース)
  • プログラミング言語そのもの
  • コンピューターサイエンス
  • 演繹的発想
  • 直感より真理を重視する
  • 対象範囲が明確に限定されている要素技術が多い

まあ実際はスッパリ別れるものではなく、「どちらかと言うと経験由来かな」「どちらかと言うと理論由来かな」と言う風に両者入り混じってるケースがほとんどだと思いますが。。ちなみに特に判別が思いつかないものは入れていません。

経験由来の技術とは

過去に誰かが何かを試してみて、それがうまくいった、うまくいかなかった、そういう経験の積み重ねから生まれてきたノウハウの類を、ここでは「経験由来の技術」と書いています。

たとえば「デザインパターン」とは、ソフトウェアを作る上でよく登場するパターンを体系立ててまとめたものなので、まさしく経験由来と言えます。そのデザインパターンやらアーキテクチャパターンを元に作った「ナントカフレームワーク」も、経験由来になります。

特徴として、割と定義があいまいというか、正解がないというか、ふわふわしています。経験の寄せ集めなので、人によって定義が異なるのもざらで、よく言葉の定義について議論が起きますが、結論が出ることはありません。「MVC」とか「オブジェクト指向」とか、オリジナルの定義は書けますが、後から積もり積もった経験たちが主張「いや私が考えるMVCとは云々」みたいなのを開始すると、よく炎上しますよね。

扱う対象も割とふわふわしているものが多く、いや逆に曖昧なものを取り扱うのが得意だと言えるかもしれません。顧客の求めるソフトウェアとは何か、とか、そもそも自分たちが作ろうとしているWebサービスとは何かですら、いつも曖昧でよくわからないではありませんか。ソフトウェアの神様がいれば、解るのかもしれませんが、あいにく我々は人間ですからねえ…。

曖昧なものの代表が人間の思考ですので、ヒトの思考を分析するようなものが多いですね。

直感的なノウハウが多く、1つ1つの学習コストは低めです。しかしそれが膨大にあるのでやっぱり大変です。

経験由来の技術を使うときの注意

経験由来の技術を100%鵜呑みにするのは危険です。いくら分厚い本に著名な先生が高尚なことを書いていようと、元が経験である以上、「偶然うまくいった」だけであった可能性が残っているからです。「柳の下のドジョウ」や「守株」といったイメージです。

例えばGoFのデザインパターンをいくら真似しても、PofEAAをいくら真似しても、ナントカ原則に忠実になろうとも、よいソフトウェアができることは保証されません。もしかすると、あえてそれらの定番手法を破った方がうまくいくかもしれません。「真似すると痛い目を見る」アンチパターンというものもありますが、そのアンチパターンですら、適用しても問題ない例外ケースがあったりします。

何も信じられない。信じられるのは「こいつらを信じてはいけない」と言うことだけ…。しかし80%ぐらい信じられるぐらいのプラクティスだけは山のようにある。うひー。

この性質ゆえ、しばしば「考えるのを止めるな」という趣旨の言葉が登場します。特にアジャイルとか開発手法の本とか…。何もかも不確定な中で、それでも何かを作り出すための合言葉としてはカッコいいですが、個人的には『そんなに色々考えてたら大変だよ…』と思うことがあります。。

明確な正解がないということは、裏を返せば間違いを指摘するのも難しいということです。スタティックメソッドだけでプログラミングするのが好きなオッサンに対して、オブジェクト指向の素晴らしさを説いたところで、経験 vs 経験なのでなかなか納得させるのは難しいです。

経験をもとに何かを語るときは、所詮それが自分の経験でしかないことを認め、謙虚に語る必要があります。そうでないと議論が成立しません。自分の経験を何かの真理のように勘違いして語りだすと、融通の利かない老害ができあがります。気をつけねばなりません。

理論由来の技術とは

数学のモデルなど、なにがしかの理論をベースに発展させた技術を指しています。自明ないくつかの「真理」を基準にして、じわじわと足場を固めていくような発想で作られています。

例えばSQL・リレーショナルデータベースは関係代数や集合論を元に構築されているので、こちらの仲間だと思っています。比較的、要素技術として登場することが多いです。

理論から勉強する必要があるので、学習コストは高い傾向にありますが、その分革新性のある技術が集まっています。大学でコンピューターサイエンスを学ぶ場合、こちらを指すことが多いのではないでしょうか。

理論由来の技術を使うときの注意

理論から構築された技術は、人間の直感と反するような見た目や挙動を示すことがあります。そのため背景となる理論を理解しておかないと、使いこなせません。逆に理論さえ分かるようになれば、すんなり理解できるようになり、その美しい世界観に引き込まれるようなものが多いです。

理論の適用範囲であれば一々疑ってかからなくてもよいように作られています。もちろん、適用範囲を認識しておく必要があります。

手段的な技術と陳腐化しにくい本質的な技術

「ソフトウェアアーキテクトが知るべき99のこと」の中で、伊藤直也さんが「技術には手段的なものと本質的なものがあって、どちらも勉強しないとだめですよ」というようなことを語っているのですが、「経験と理論」と言う切り口はちょっと違います。

経験由来の技術が陳腐化しやすいかと言うとそうでもなく、統計的に多くの経験論をまとめ上げて作られたパターンの類は確度が高く、陳腐化しにくい傾向があります。

理論由来の技術についても、技術革新によって前提条件が変わってしまうことで、陳腐化してしまうケースもあります。

私のイメージ

何かの要望をかなえるためにソフトウェアを作るとき、まずはモヤモヤした要望をまとめて形にしていくことになります。こういったフェーズでは、経験由来の知識が有利です。扱うものがモヤモヤしていると、理論を構築するのも困難になります。解らないながらにぶつかってみるしかないのですが、過去に同じような問題にぶつかっていった先人たちの失敗と成功の記録を参考にすることはできます。

しかし何でもかんでも経験ベースで作っていくと、自分の作ったものすべてを疑い続けれなければなりません。これは大変ですし、疲れてしまいます。そこで、理論由来の技術を取り入れていくことで、思考停止しても問題ない範囲が広がって楽になります。また、直感で解決策が発見できないような本質的に困難な課題は、理論ベースで攻めていった方が解決策が見つかりやすくなります。

時とともに、理論の適用範囲が広くなって曖昧なものも扱えるようになったり、経験の整理がされて理論が構築されたりして、双方の対象が重なっていきます。発想の違う両者は分かり合えず、いがみ合っているような印象を受けます。

こういう知識論は合理主義 vs 経験主義みたいな感じで哲学の範疇だと思いますが、どちらも人間が繰り返してきた手法であって、お互いの得意分野・不得意分野を認識して、使いこなせばいいのではないかと思います。

ソフトウェアアーキテクトが知るべき97のこと

ソフトウェアアーキテクトが知るべき97のこと

etcの最新記事