プログラミング

2017/05/05

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。
ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。
以下は書きかけ。

【参考】
第0回:人月の神話とはなんなのか?(解説編)|本気で読み解く”人月の神話” | GiXo Ltd.

第2回:銀の弾は無いけど、”銃”はあるよね|本気で読み解く”人月の神話”(第16章) | GiXo Ltd.

ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ

ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間

【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の内容自体は10年以上前のWebやIT業界の話が多く、内容も古くなっているので、新たな知見が得られるという感覚はしない。
しかし、「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の中に、「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という言葉があって、すごくしびれた。

(引用開始)
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、実験的にその性質を証明することで、3世紀にわたって偉大な進歩を遂げた。
この方法でうまくいったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったからだ。
複雑性が本質である場合には、この方法は使えない。
(引用終了)

上記の内容は、ブルックスの「人月の神話」の一節そのまま。
なぜ自分がすごく衝撃を受けたのか、考えてみると、ソフトウェア開発の本質に触れているものだから。
たぶん、僕の心のなかにある、ソフトウェアに対する楽しさだけでなく、ソフトウェアへの憎しみというか、なぜこう思い通りにソフトウェア開発をコントロール出来ないのか、という腹立たしさに触れている気がしたから。

「偶有的」という言葉も引っかかる。
この言葉は、古代ギリシャのアリストテレスの哲学から引用したものらしい。

(引用開始)
アリストテレスに従って、難しさを本質的なものと偶有的なものに分けて考えてみよう。
ここで、本質的な複雑さとは、ソフトウェアの性質に固有な困難のことであり、偶有的難しさとは、目下の生産にはつきまとうが本来備わっているものではない困難のことである。
(引用終了)

自然科学、特に数学や物理学では、できるだけ単純なモデルを作り、そこから演繹される性質や定理を証明することで、自然現象を多面的に分析しようとする。
複雑なものを複雑なまま捉えるのではなく、理想的な単純なモデルに純粋化して、人間の思考に耐えられるレベルにして、数多くの観点で徹底的に分析するのが自然科学のやり方。
シンプルなモデルを「徹底的に」分析し尽くして、全ての特徴を洗い出し、全てを因果関係や演繹でまとめ上げて一つの理論体系にするのが自然科学のやり方。

すると、シンプルなモデルをどのように事前設定するか、どのパラメータを重視して選択しておくか、というのが重要になる。
その部分が、科学者の腕の見せ所。

たとえば、物理学では、理想気体みたいに、現実から離れるけれど、シンプルなモデルを設定することで、計算や実験を扱いやすくするモデル作りは一般的だ。
熱力学、相対性理論、量子力学など、色んな分野の物理学でもその手法を用いている。

物理学は一つの認識論: プログラマの思索

数学でも、一流の数学者は、自分で理論を打ち立てたい時、最も組合せの少ない公理や公準を直感的に選んで、そこから矛盾が生じないように設定しておく。
そこから、「誰々の定理」のような重要な結果を導き出す。
一流の数学者がすごいのは、最も組合せの少ない公理を直感的に把握できること、そして、重要な定理を導く時に、ロジックの穴になりそうな難しい場所を事前に察知して、それをくぐり抜けるために、あらかじめ「誰々の補題」みたいな補助的な公式を用意しておくのが上手い点。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

このやり方がすごく成果を上げているので、人文科学や社会科学でもそのやり方を真似ているように思える。
特に、経済学は典型的だろう。
マクロ経済学やミクロ経済学みたいに、人間は合理的に行動する、とか、市場の価格は恣意的な手段で決めても長続きせず、神の手(つまりは市場原理)で決まる、みたいに、現実とかけ離れた仮定をおいて、数多くの経済モデルを作り、そこから重要な経済学の定理を導き出す。
単純な経済モデルから得られた経済学の定理で現実に通用する場面が過去にあったから、経済のグローバル化が世間に言われ始めてから、世の中の経済事象は、市場原理で決まる、いや決めるべきだ、みたいな論調が多い気がする。

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

しかし、ブルックスの「人月の神話」では、ソフトウェアにはそのやり方が通用しない、という指摘をしている。
「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」からだ。
つまり、複雑性を排除したソフトウェアは、ソフトウェアの本質を意味しないからだ。

【2】ソフトウェアの本質的な複雑さと、偶有的な複雑さの違いは何か?
ソフトウェアの本質的な複雑さは、リーマンの法則そのものを指すと思う。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

リーマンの第1法則
 使われるシステムは変化する。
リーマンの第2法則
 進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
リーマンの第3法則
 システムの進化はフィードバックプロセスによって決まる。

(引用開始)
レーマンとベラディは、大規模なオペレーティングシステムのリリースについて、継続してその変遷を研究してきた。
そこで分かったことは、モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース番号に対し指数的に増加するということだ。
(中略)
システムプログラムの作成は、エントロピーを減らす仮定だから、本来は準安定なものである。
他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行なっても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
(引用終了)

(引用開始)
ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来している。
(引用終了)

この文章を読んで思い出すのは、ケント・ベックがXPを生み出した経緯のことだ。
ケント・ベックは、ソフトウェア工学の授業で習った、リリース総数が増大するにつれてソフトウェアの複雑度や変更コストが増大していく経験則に対して、異議を唱えた。
時間が進むに連れて、この曲線を頭打ちにできるような開発プロセスはないのか、と。

- eXtreme Programmingの魅力を探る オブジェクト倶楽部

(引用開始)
「変化ヲ抱擁セヨ」
この呪文めいた言葉は,Kent Beck による本の副題として掲げられている. 時間を横軸に,ソフトウェアの変更にかかるコストを縦軸にプロットする.
この「時間-変更コスト」曲線は極端な右上がりになると信じられて来た(図左).
すなわち,要求分析,設計,実装,テスト,保守,と時間が進むにつれ, 変更にかかるコストが増大するというのだ.
現在までのソフトウェア開発プロセスは,この仮定上の議論が多数 だったのである.
XP はこの曲線を平坦にできるのではないか, また,そうできたとしたら,全く違った方針でプロジェクトに立ち 向かえるのではないか,という挑戦をしている(図右)
(引用終了)

こういう素朴な問題意識はすごく重要だと思う。
XPがその理想を本当に実現したのかどうか、は検証がいると思うが、そういう背景を元にアジャイル開発のプラクティスが生まれたことは、アジャイル開発が従来のソフトウェア工学と対立しがちに見える傾向を示唆しているように思える。

ちなみに、上記の第1版の「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」に、上記の「従来のソフトウェア工学が提唱しているソフトウェア複雑性へのXPの果敢な挑戦」の文章と図はあるのに、第2版の「エクストリームプログラミング」から削られていることだ。
とても残念。
この部分がXPにとって一番重要な主張なのに。

【3】コードクローンと再利用性。

(引用開始)
ソフトウェア実体の本質とは、データセットやデータ項目間の関係、アルゴリズムや機能呼び出しなどが組み合わさったコンセプトで構成されたものである。
この本質は、同じ概念構造体が多くの異なる表現で表されるという点で抽象的である。
それにもかかわらず、非常に正確で十分に詳細なものである。
(引用終了)

コードクローンとは、同一アルゴリズムを各プログラマが別々の実装したプログラムのことだ。
上記は、ソフトウェアの複雑性が増大しがちな理由の一つは、コードクローンが大量に発生しがちである、と言う点を示唆していると思う。

ソフトウェア工学の論文を見ていると、コードクローンのメトリクス採取の記事が割と多い。
その理由は、コードクローンを減らす方がソフトウェアの複雑性が減るので、良い、という主張が隠れているのではないか。

では、なぜコードクローンは良くないのか?

(引用開始)
ソフトウェア実体は、どの2つの部分をとっても似ることがないので、大きさの割にはおそらく他のどの人工構造物よりも複雑なものだ。
似通っている部分があれば、2つの類似部分を1つにする。
この点において、ソフトウェアシステムは、重複要素(部品)が豊富なコンピュータやビルあるいは自動車などとは全く異なっている。
(引用終了)

その理由は、ソフトウェアの再利用が進まないからだ。
たとえば、自動車やパソコン、スマートフォンのような工業製品は、再利用可能な汎用部品を組み立てる手法と大量生産することを組合せることで、規模の経済を生かし、経験曲線効果を生かして、1個当りの製造コストを劇的に減らす。
しかし、この「規模の経済」「経験曲線効果」というコストメリットを享受しうる生産手法がソフトウェア開発には全くといっていいほど通用しない。

ソフトウェアを部品化して、スマートフォンみたいに部品を組み立てるように製造したい、と考えて、CORBAとかEJBのようなコンポーネント駆動開発、製品ファミリー群の製品開発手法であるソフトウェアプロダクトラインとか色々考えられたけれど、どれも実用的ではない。

ソフトウェア部品化の幻想: プログラマの思索

ソフトウェアプロダクトラインが解決しようとするもの~品質と再利用: プログラマの思索

だから、多額の資金を設備投資に投入して、最新の機械で汎用部品を組合せて大量生産する生産手法がソフトウェア開発には馴染まない。
ソフトウェア開発は徹頭徹尾、経験曲線効果すらも有効でない労働集約的な生産手法に似ているように思える。

【4】ソフトウェアの本質的な複雑性とは、同調性、可変性、不可視性。

【4-1】同調性は、リーマンの言う組み込まれた(Embeded)プログラム、を連想する。

「ソフトウェア・グラフィティ」の感想: プログラマの思索

(引用開始)
支配しなければならない複雑性の多くは気まぐれによるものだ。
インターフェイスを人間の社会制度やシステムに適合させるべく、いわば是非もなくそれらによって強制されているからである。
(引用終了)

最近、業務システムとかERPに僕自身が少し興味をなくしているのは、システム化したい業務そのものが元々複雑過ぎて、それを整理しようと言うよりも、現実の業務をいかに忠実にシステム化するかに注力する案件の方が多いからだ。
元々の業務が、日本的な複雑な組織体制を元に作られていれば、複雑なのは当たり前であり、それを忠実にシステム化するなら、複雑怪奇なままだ。
日本では、ERPをBPRとして捉えるよりも、自分達の業務中心に考えすぎているために、システムも複雑怪奇になりやすいような気がしている。

【4-2】可変性は、ソフトウェア品質の移植性や保守性を連想する。

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

(引用開始)
ソフトウェア実体は、つねに変更という圧力にさらされている。
(引用終了)

XPの言う「変化を抱擁せよ」と同じ。
ソフトウェアにとって、VerUpは宿命であり、常に変化が内在している。
ソフトウェアは変化しない固体として存在し得ない。

(引用開始)
純粋な思考の産物であってきわめて融通性に富んでいるので、ソフトウェアがより簡単に変更できるということもある。
ビルも現実には変更されるものだが、だれもが了解しているように、変更コストの高さが思いつきで変更しようとする者の気をくじく働きをしている。
(引用終了)

ソフトウェアに、仕様変更という名の保守はつきものだ。
それは簡単にできるように思えるから、簡単にソフトウェアに手を入れて、潜在バクを埋め込んでしまう。
ソフトウェア品質特性のうちの保守性を連想させる。

(引用開始)
大当たりしたソフトウェアはまずたいてい、すべて変更される。
あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を越えるような新しい使い方を試してみようとする。
主として、拡張機能のために変更して欲しいという圧力は、基本機能が気に入っていて新しい使い方を考えだす利用者から出される。
(引用終了)

これは、たとえば、Redmineが当初のバグ管理の使い方から、タスク管理、そして、アジャイル開発やWF型開発、さらには、事務処理ワークフロー、ハードウェア資産管理システムへ使い道がどんどん広がっていった事例を連想させる。
本来想定しなかった使い方が一般的になってしまい、その使い方をさらに使いやすくしたり、機能改善することで、ソフトウェアの複雑性がどんどん膨張する。
あらゆるソフトウェアは機能追加という変化にさらされている。

(引用開始)
大当たりしたソフトウェアは最初に書かれた対象である機械機器の通常の寿命よりも長く使用され続ける。
要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器といった文化的マトリックスにすっかりはめこまれているのだ。
そしてそれらは絶えず変化し続けるものであり、その経kながソフトウェア製品に容赦なく変更を強制するのである。
(引用終了)

たとえば、OSやDBやミドルウェアのバージョンアップとか。
あるいは、サーバー本体のリプレースとか。
たとえば、WindowsXP廃棄対応、WindowsServerのリプレース、OracleのVerUp、RailsのVerUpとか、iOSやAndroidOSのVerUpとか、色々思い出す。
つまり、ソフトウェア品質特性の移植性を連想させる。

こういうミドルウェアやOSのVerUpに伴うプログラム変更作業は、とてもしんどいものだ、と開発者なら誰でも知っている。
こういうつまらない開発基盤のVerUp作業は、ソフトウェアの外にある外部環境の変化によって生じるものであり、避けることは出来ない。

【4-3】不可視性は、ソフトウェア設計の難しさを連想する。

(引用開始)
ソフトウェアの構造を制限したり単純化したりすることは進歩したにもかかわらず、その構造は本質的に視覚化できないままになっている。
そのため強力な概念上のツールを作る意欲を阻害している。
その欠落は1人の人間の頭の中のデザインプロセスを妨げるばかりでなく、複数の人間の間でのコミュニケーションもひどく妨害する。
(引用終了)

UMLやDOAは、ソフトウェア構造を視覚化する問題を解決しようと試みていた。
SySMLもその流れだろう。

複雑性をコントロールするための設計技法は、歴史上いくつか考えれてきた。

たとえば、Nティア設計。
つまり、レイヤ化。

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

NFuji's Café: 「Beautiful Code」を読む(中)

ポインタを制する者はプログラミングを制する: プログラマの思索

MVCモデル、通信プロトコルの7層モデルもそういう考え方だろう。

他に、渡部幸三さんの観点でのDOAでは、業務・機能・データの3層構造の業務システムにおいて、業務レイヤとデータモデルのレイヤに複雑性を押しこんで、機能レイヤは複雑性をできるだけ減らす設計が良い、と提唱していた。
すなわち、機能レイヤはまさにプログラミングレベルなので、その部分の複雑性はできるだけ減らして保守性を高めようとする考え方。
つまり、複雑性というエントロピーは一定で変わらないと仮定した場合、人が携わる業務レイヤと、データモデルのレイヤに複雑性を落としこんで、複雑性をコントロールしようとするわけだ。

だが、これらの手法で、ソフトウェア本来の複雑性が本質的に解決されたのか、と問うてみると、正直分からない。

【5】一方、ソフトウェアの偶有的な複雑さは個別撃破している。

「高水準言語」は、たとえば、VBよりもRuby。
たとえば、VBはListやHashなどの基本ライブラリのAPIが非常に不足していて使いにくい。
たとえば、Rubyなら、そういう低レベルなライブラリは非常にAPIが揃っていて、VBよりも1行で書ける。
つまり、複雑性を軽減している。

「タイムシェアリング」は、たとえば、コンパイラ言語よりもインタプリタ言語、継続的ビルド管理、構成管理を指すのかな。

(引用開始)
考えていた内容をすっかりというわけではないが些細な点でどうしても忘れてしまう。
(引用終了)

この部分は、まさにソース管理、構成管理を連想させる。
たとえば、CVS、Subversion、Gitに至るまでの構成管理ツールの歴史を振り返れば、ソフトウェア開発プロセスにおけるブランチ管理、マージなどの作業の複雑性は軽減されている。

「統一されたプログラミング環境」はたとえば、VisualStudioやEclipse、IntelliJとか。

つまり、ソフトウェアを開発する作業そのものが生じる複雑性は、今までの歴史で生み出された技術によって、多少は軽減されてきた。
しかし、だからと言って、ソフトウェアの本質的な複雑性を攻略できたわけではない。
あくまでも、以前よりも大きい複雑なソフトウェアをコントロールできるようになった、というだけだ。

| | コメント (0)

2016/12/18

Pythonの記事のリンク~道具が理論にようやく追いついてきた

最近のバズワード「ビッグデータ」「機械学習」が知りたくて、Pythonの記事のリンクをメモ。
自分用の参照記事。
ラフなメモ書き。

【参考1】
Pythonでプログラミングを始めよう:新刊ピックアップ|技術評論社

(引用開始)
「もしコンピュータ言語をひとつも知らないのなら,まずPythonを学ぶことを勧める」。これは『How to become a hacker』(Eric S. Raymond著)の一節です。なぜ,Pythonを勧めるのか,それには様々な理由がありますが,筆者の経験や,世の中の動向を踏まえて説明してみます。
(中略)
工学系のエンジニアにとっても,プログラミングのスキルは設計作業に必要不可欠です。筆者もメーカーに勤務するエンジニアですが,入社以来様々な言語を使ってきました。シェルスクリプト,sed,Perl,C言語,C++,MATLAB/Simulink,Octave,Scilab,Mathematicaなど,作業内容に応じて使い分けています。テキストデータの整形をsedで行ったのち,C言語のプログラムから読み込んで処理し,その結果をMATLABで解析・可視化する,といった具合です。
(中略)
このような状況を変えつつあるのがPythonです。Pythonは,テキストデータの整形も,数値計算とその結果の可視化も得意です。すべての作業でPythonを使えば事足りる,という場面が多いのです。そのため,Pythonを使って設計をする機会が,日増しに増えています。

また,エンジニアにとって大切なことは,自分の設計内容や検討内容を完全に把握しておくことです。その点,MATLABのような有償のソフトを使うと,ライブラリのソースコードが公開されていないことが問題になる場合があります。Pythonと,Pythonの主要なライブラリの場合は,ほとんどがオープンソースプロジェクトです。そのため,すべてを自分のコントロール下に置いて,開発を進めることが可能です。
(引用終了)

(引用開始)
ディープ・ラーニングとビッグデータ解析での活用

次に,Pythonが実際に活用されている場面を見ていきます。

AlphaGoの快挙を支えたPython
ぶつからない車もPython!?
ビッグデータ解析でもPython
(引用終了)

【感想1】
R言語を色々触ってみたが、何か使いづらい。
たぶん関数型言語の特有の考え方に僕が慣れていなからだろう。
Pythonなら、RubyやJavaにも似ているので書きやすそう。

データの統計処理だけでなく、ファイル読み込み、グラフ表示、正規表現も一つの言語で処理できるのは便利。
プログラミングは歴史や英語のような暗記は不要だけど、APIの使い方とかテクニックは最終的には覚えるしか無い部分がある。

「エンジニアにとって大切なことは,自分の設計内容や検討内容を完全に把握しておくことです」という指摘は同意する。
「すべてを自分のコントロール下に置いて,開発を進める」ことが重要だから。
自分が使っている道具の特徴、癖を知っておかないと、自分が解決したい問題に適用する時に、落とし穴に落ちる時があるから。

道具の制約が、問題解決の可能性を制限する。
道具の制約が、問題解決の発想、アイデアの範囲や質を制限するから。

【参考2】
akipiiさんのツイート: "「断片的な情報を地図にまとめて大局的な視点を持つ」「人に何かやって貰いたい時は具体的に指示をだす」「今あるものを工夫して新しい道具を作り出す」といったエンジニアにとって大事なことがストーリーに織り込まれています。ルビィのぼうけんhttps://t.co/OaZHqw2E0w"

ルビィのぼうけん」のAmazon書評コメント欄に、下記のコメントがあってすごく納得した。

Amazon.co.jp: ルビィのぼうけん こんにちは! プログラミングの deko-papaさんのレビュー

(引用開始)
翔泳社の特設サイトで見つけて、帰宅途中で書店にて購入。10歳の娘に買って読ませてみました。
 夢中になって読んで、あっという間に前半のストーリー部分は読破。後半の練習問題は、夜遅かったので翌日へ。さらに寝るまでお母さんに読み聞かせを強請っていました。

 私はさわりの部分しかまだ読んでいませんが、それでも「断片的な情報を『地図』にまとめて、大局的な視点を持つ」「人に何かやって貰いたい時は、具体的に指示をだす」「今あるものを工夫して新しい道具を作り出す」といったエンジニアにとって大事なことがさりげなくストーリーに織り込まれているのが分かります。

 さらに、絵の中にさらっとプログラミング言語のキーワードが描かれています。もちろんそれについての説明は一切ありませんが、将来プログラミングに触れたとき、「あ!見たことある!」とこの絵を思い出す子どもが大勢いることでしょう。
(引用終了)

【感想2】
「プログラミングは実現したいことの手段に過ぎない」意見もあるが、僕はむしろ、プログラミングという道具が思考方法を規定してしまう側面の方を強く感じる。
既に確立した理論はあり、その理論の内容を実現したいのに、プログラミング言語やそのライブラリが貧弱であれば、やりたいことを表現するのにすごく手間がかかって、イライラしてしまう。

たとえば、配列やハッシュにデータを一時的に退避するとか、ファイルを読み込んで文字列を正規表現でマッチする部分を抽出するとか、そういうコンピュータの基盤に近い部分の処理は手短に書きたい。
そして、理論が本来言いたい部分をプログラミング言語で的確に表現したいのだ。

プログラミングにおいて、「断片的な情報を地図にまとめて大局的な視点を持つ」考え方は、理論で本来実現したい結果を得るための登山ルートを詳細に具体化する能力に対応するのではないか。
「今あるものを工夫して新しい道具を作り出す」考え方は、プログラミング言語とライブラリという「道具」で工夫して、理論で実現したい結果を得るためのアルゴリズムを作りだすのに使う、ことに相当するのではないか。

つまり、今ある道具を工夫する手間が少ないほど、コンピュータレベルではなく、もっと高次のレベルで物事を思考することが容易になるはず。

たとえば、統計学の理論は基礎数学で確立しているけれど、経済学者や心理学者は「大数の法則」「中心極限定理」「正規分布」などの定理や概念を数学的に証明するのに使いたいわけではない。
それらの定理や概念という道具を使って、経済現象や人間の心理現象を分析して、問題を解決したり、新たな観点をもたらしたいのだ。
昔は計算能力が貧弱だったので、統計処理はいかに簡便な手計算でやるか、という技術の説明をする本ばかりだったけれど、今は、優れたプログラミング言語やライブラリは揃っているから、計算処理はコンピュータに任せることが楽になった。

すると、理論がどのプログラミングのモデルに適用できるか、理論をどのプログラミングのモデルに適用すると手短にたどり着けるか、という考え方に発展するだろう。
つまり、問題のレベルが、単にプログラムが書ける、というレベルではなく、プログラムが表現するモデルが理論や現象を上手く説明できているか、というレベルに上がるだろう。
そこが面白くなってくる。

【参考3】
いまさら聞けないDeep Learning超入門(1):ニューラルネットワーク、Deep Learning、Convolutional Neural Netの基礎知識と活用例、主なDeep Learningフレームワーク6選 (1/2) - @IT

(引用開始)
 筆者がデータ解析に従事し始めた2010年ごろ、Deep Learningという言葉は一部のアカデミックな分野では流行していましたが、ユーザー企業でその言葉を聞くことはあまりありませんでした。

 今あらためて、Deep Learningの歴史をひも解いてみると、その歴史は決して明るいものではなかったことが分かります。Deep Learningの構成要素である、ニューラルネットワークとそれを単純に多層に組み合わせたものに関しては、それこそ1980~1990年代前後から盛んに研究されていました。しかし、その精度や処理量の問題から、同じく分類推定モデル構築によく利用される機械学習ロジックである「ベイジアンネットワーク」「サポートベクターマシン」の裏に隠れてしまい、冬の時代が長く続くことになったのです。

 再び脚光を浴びるようになったのは2000年代に入ってから。2006年にDeep Learningが発表され、その後2012年にトロント大学のHinton氏が「ImageNet」と呼ばれる画像セットを用いた画像識別コンペティションでDeep Learningを用いて2位以下を大きく引き離す精度を記録したことがきっかけです。このあたりからグーグルをはじめ、マイクロソフトやフェイスブックなどが注目し、ビッグデータのブームやGPUサーバーなどのハードウエア面の進化も伴ってDeep Learningは広くデータ解析者に広がっていきました。

 Deep Learningの最大のウリは何といっても、「人手で特徴量を抽出する必要がない」という点です。
(引用終了)

深層学習(ディープラーニング)を素人向けに解説(前編)―基礎となるニューラルネットワークについて

(引用開始)
ディープラーニングとは、適切な特徴抽出能力を持つ教師なしニューラルネットワークを多層にして構築したものです。
(中略)
まず、ディープラーニングを理解するためには、ニューラルネットワークを理解しなければなりません。逆に、ニューラルネットワークを理解してしまえば、ディープラーニングの概要自体はかなり分かりやすくなります。

ニューラルネットワークと言うのは、人の神経を模したネットワーク構造のことです。それを踏まえて、そう言う構造を持った人工知能のこともそう呼びます。このニューラルネットワークでは、神経細胞を模したパーセプトロンと言う小さな計算機をたくさん用意し、一つの計算を協力して行わせるように作られています。
(引用終了)

【感想3】
最近、囲碁でコンピュータが人間に勝ったニュースが流れたが、Deep Learningのアルゴリズムはニューラルネットワークであることは初めて知った。
30年以上前にニューラルネットワークは流行したけど、なかなか実用に至らなかった、という話は随分聞いた。
僕は、Deep Learningのアルゴリズムはベイズ統計かなと思っていたので、意外だった。

そんな話を聞くと、昔に確立した理論が、ようやく時代に追いついて花開いた、と感じる。
今ようやく、プログラミング言語の科学技術ライブラリ、統計処理ライブラリ、クラウドなどの開発基盤がそろってきたから、ニューラルネットワークのような理論が実際にプログラム上で実現できたわけだ。

ニューラルネットワークの理論は僕も詳細は知らないけど、古くから研究されて確立している理論なので、その理論をバックにした技術はそう簡単には廃れないだろうと直感する。
今後も、たくさんの応用用途も見つかるだろう。

実際、Deep Learningは、車の自動運転、顔認証システムなどにも使われている。
アイデアさえあれば、もっといろんなことが出来るはず。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

【感想4】
僕は「新しいアイデアとは、古いアイデアを新しい場所に置いたアイデアのこと」という言葉が好き。
既に知られた理論や知見(例:統計学、ニューラルネットワーク)は、新しい場所(例:人工知能、深層学習、自動運転、顔認証)で使われると、新たな発見を呼び起こす。
そういうことをやってみたい。

| | コメント (0)

2016/09/12

「関数型プログラミングはオブジェクト指向の正当な後継である」記事のリンク

「関数型プログラミングはオブジェクト指向の正当な後継である」記事が素晴らしいのでリンクしておく。
オブジェクト指向設計の概念で、関数型プログラミングの概念を翻訳できるという指摘が腑に落ちた。

【参考】
関数型プログラミングはオブジェクト指向の正当な後継である - Qiita

「モナドの主な使い方は「保持役(状態役)に暗黙の制御構造を付与すること」になります」という指摘が腑に落ちた。
Haskellでは、Maybeモナドでエラー制御とか、IOモナドで状態を保持する処理で使うけれど、ではモナドとは一体何か、と自分の中で言えなかった。
上記の指摘では、オブジェクトの責務の6個のうち、「保持役」のロールに相当する。

そして、モナドはポリモルフィズムの使い方に似ている、と。

一時期、UMLやオブジェクト指向設計を貪るように乱読した時があったけれど、上記の記事を読むと、その知識は関数型プログラミングでも無駄ではない、という気がしてくる。

| | コメント (0)

2016/04/28

WindowsOS上でbash環境を使うためのツールのリンク

WindowsOS上でbash環境を使うためのツールのリンクをメモ。

【参考1】
【レビュー】Windows OS上で超気軽にbash環境を楽しめる「clink」 (1) コマンドプロンプトとの互換性も十分 | マイナビニュース

Clink

clink/clink.md at master ・ mridgers/clink

mridgers/clink: Bash's powerful command line editing in cmd.exe

コマンドプロンプト派なら入れておくべき機能改善ツール『Clink』 | ライフハッカー[日本版]

【参考2】
Windows用のお手軽なUNIXシェル環境としておすすめなGit For Windows (Git Bash)

Mingw-w64/MSYS2 を入れなくても Git for Windows で間に合うみたい - 檜山正幸のキマイラ飼育記

Git for Windows で日本語を使いたい - Qiita

WindowsにおけるGit利用環境は整った: Git for Windows と SourceTree for Windows - 檜山正幸のキマイラ飼育記

Git for Windows で日本語を使いたい - Qiita

GitHub for Windowsの導入について(追記あり) - 鎌玉のよしなしごと

ちょっとした些細な作業をルーチン化したい時、Windows上でシェルスクリプトを書きたくなる。
bashのスクリプトをWindows上でそのまま動かしたくなる。

以前はCygwinを使うのが普通だったが、たくさんのライブラリをダウンロードする必要があるし、設定が結構面倒なイメージがある。

ネットで探してみたら、clinkというツールがあるらしい。
他には、Git For Windowsがいいらしい。
以前は日本語のパス名だとうまくcdできなかったが、GitHub for Windowsの導入について(追記あり) - 鎌玉のよしなしごとによれば、幾つかの設定を追加すれば使えるみたい。
実際、フォルダ上で右クリックして、GitBashを開くと、Unixコマンドも普通に使えて便利。
過去のシェルスクリプトをWindows上で動かしたりして試してみる。


| | コメント (0)

「昨日までJavaJavaしてた人がいきなりExcelのVBAを実装する羽目になったときのためのメモ」の記事が役に立つ

「昨日までJavaJavaしてた人がいきなりExcelのVBAを実装する羽目になったときのためのメモ」の記事が役に立つのでメモ。

【参考】
昨日までJavaJavaしてた人がいきなりExcelのVBAを実装する羽目になったときのためのメモ - Qiita

個人的には、CobolやVBの案件に放り込まれるのは嫌い。
でも、仕方ない場合もあったりする。
特に、ExcelのVBAは開発案件でなくても、保守運用で使う報告書や作業指示書や集計表などで、ルーチン作業を自動化するために使われているので、使わざるを得ない場面が多い。

一番嫌なのは、今までのJava、C#のやり方がCobolやVBAでは通用しないことだ。
つまり、開発環境の使いにくさ、言語仕様の未熟さ、API不足などで、普通は考えなくて良い所まで考えさせられるのが苦痛。

上記の記事は、Java経験者がVBAを初めて書く時にはまりがちな内容を記載してくれていて、とても役立つ。
VBAはオブジェクト指向言語っぽく見せかけていながら、言語仕様が未熟なので正直使いづらい。
でも、使いにくい部分を知っておけば、多少は苦痛を減らせる。

個人的には、RubyやJRubyでWin32OLE経由でExcel操作した方が便利で速いのではないか、と思う。

RubyでExcelを操作(OLE)する

Rubyist Magazine - Win32OLE 活用法 【第 1 回】 Win32OLE ことはじめ

RubyでWin32oleを使ったExcelサンプルプログラム - Qiita

Ruby から Excel を操作する方法 | TipsZone

| | コメント (0)

2016/01/03

ITの地殻変動はどこで起きているのか~技術革新の流れはWebから機械学習やデータマイニングへ

2015年になって、ITの地殻変動がどこに起こっているのか?を考えてみる。
自分の理解が浅いのは承知のうえで、以下は、妄想を含めたラフなメモ書き。
間違っていたら後で直す。

【参考】
機械学習をこれから始める人に押さえておいてほしいこと - Qiita

Pythonでデータの分析を出来るようになりたい(その1) - Qiita

Pythonでデータの分析を出来るようになりたい(その2) - Qiita

Pythonでデータの分析を出来るようになりたい(その3) - Qiita

Pythonでデータの分析を出来るようになりたい(その4) - Qiita

「AARRR」 今更だけど絶対抑えておくべきグロースハッカーのコンバージョンの見方 | グロースハックジャパン | growth hack japan

Google、脳のシミュレーションで成果……猫を認識 | RBB TODAY

データサイエンティストを目指すというかデータ分析を生業にするなら読んでおきたい初級者向け5冊&中級者向け12冊(2015年冬版) - 東京で働くデータサイエンティストのブログ

クリスマスイブに「さくらの聖夜」というイベントに行ったら、とんでもない発表が行われていたw #さくらの聖夜 - Blog::koyhoge::Tech

「統計学が最強の学問である」の感想: プログラマの思索

機械学習に関するメモ: プログラマの思索

「データサイエンティスト」の感想~データマイニングが自然科学を再定義し直す: プログラマの思索

教育学は人工知能の研究者によるデータ主導で置き換えられつつある: プログラマの思索

【1】最近思うのは、オープン化、Web2.0、スマフォ・タブレットと進化し続けたWebの進化よりも、データマイニングの技術革新の方がすごく勢いがあるように感じることだ。
今や、スマフォは手のひらサイズのPCであり、Unixであり、これ以上の究極の進化形はないのではないか。

【2】一方、データマイニングの技術は、ようやく必要な機能が一通り揃ってきたように見える。

1)HadoopやStackなどのMapReduceの技術がこなれてきた。
これらの技術によって、データ解析の技術基盤が揃ってきた。

2)データマイニングの開発環境は、クラウドですぐに作れる。データ容量が増えても、スケールしやすい。

3)IoTの概念によって、HWのセンサー機器から大量のデータを収集できるようになった。
他にも、皆が持っているスマフォから、位置情報やSNS情報を収集できる。
あるいは、ドローンやRaspberry Piなど、数多くの機器からも、大量のデータをリアルタイムに収集できる。

4)R言語のような統計学に特化したプログラミング言語が普及してきた。
今なら、R言語よりもPythonの方がもっと手軽に書けるだろう。

5)他にAIの復活。機械学習がAIを復活させたように見える。

【3】機械学習やデータマイニングが今のトレンドになっている理由は、R言語やPythonなどでプログラミングしやすくなり、クラウドで大量データをスケールしやすくなったことだけではないと思う。
機械学習やデータマイニングの背後には、統計学という理論でそれら成果の裏付けが保証できる、という点が最大の理由だろうと思う。

つまり、IoTでセンサー機器から大量のログを収集できた後、それら大量データを帰納法を使って見出した因果関係は、その正当性を統計学が保証できる仕組みがあるからだ。
すなわち、統計学が機械学習から得られた知見の確からしさ、正当性を保証してくれるわけだ。
その因果関係の真の意味は後回しで良く、理論づけはその後で良い。

統計学が最強の学問である」に書いてあるように、昔の統計学は退屈な学問だった。
つい最近まで、せいぜい電卓を使うぐらいで、コンピュータの性能も低く、大量データを手計算で処理するには限界があった。
だから、限られたデータ量から、いかに少ない手数で計算して、因果関係を推測するか、という手法ばかり発達していた。
つまり、統計学の本来のメリットが生かせていなかったわけだ。

しかし、プログラミング言語やMapReduceなどの技術、クラウドなどの開発基盤、センサー機器やドローンやスマフォなどのデータ収集機器が揃ってきて、ようやく大量データから帰納的な理論を打ち立てることが可能になってきた。
そして、誰もが手軽に、センサー機器を組み立てたり、ドローンを飛ばしたり、PythonやRでデータマイニングのプログラムを書くことができるようになってきた。
それらから得られた知見は、統計学を上手く利用すれば、その正しさを保証できるはずだ。

【3】「機械学習やデータマイニングで得られた知見は統計学で保証できるはず」という考え方は、僕にとって既視感を感じる。
つまり、「既存の理論をバックにして、新しい技術を使って試す」というやり方がすごく既視感。

例えば、チケット駆動開発というアイデアは、既に枯れたツールであるBTSやITSをアジャイル開発に適用するという発想から生まれた。
そこから更に発展させて、汎用的な機能を持つBTSをアジャイル開発だけでなく、PMBOKやソフトウェア工学に適用させて、既に知られているプラクティスや理論上の概念を実際に試して評価することもできた。

理論を完全に理解できていなくても、既知の理論にあるプラクティスや概念を片っ端から試してみれば、ノウハウがたまるし、理論のメリットやデメリット、適用の限界なども見えてくる。

同様に、統計学で既に知られている概念やメソッドを実際のプログラムで実現し、実際に機械学習で試してみれば、色んなノウハウが得られるだろうし、理論を使えばもっと良い方法が見つかる可能性もあるだろう。

例えば、「統計学が最強の学問である」では、POSデータ解析でよく使われるバスケット分析は、統計学におけるカイ二乗検定の方が優れている、という指摘がある。
実際、グーグルの共同設立者も「バスケット分析よりも統計学的な相関分析の方がいい」という論文を書いているらしい。

つまり、システム開発で試行錯誤して相関関係を見出したアルゴリズムよりも、統計学にある既存の概念を使った方がはるかに効率的に因果関係を見いだせる場合があるわけだ。

その理論を知っている人なら当たり前のことでも、現場の人はそういう理論は知らない。
逆に、理論を知っている人は、ビジネス経験や実際の応用事例が不足しているから、世間に向けて効果のある知見を披露できない。
だからこそ、プログラミングという強力な武器を持っているプログラマは、理論を少しかじってみるだけでも、新しい知見を見出し、社会に貢献することが可能なはずだ。

【4】とは言え、統計学の手法を実際の応用事例に生かす、という手法は、IT業界以外でも既に幾つか知られている。
例えば、製造業の品質管理技法では、統計学を応用する手法は既に行われている。
実際、製造業では、出荷時に全数検査はできないので、一部の標本を抜き取って品質をチェックする抜き取り検査を行わざるをえない。
その時に、抜き取り検査で得られた品質評価の結果が、他の残りの全ての製品でもほぼ同じで問題ない、という箇所で統計学の推定・検定を使っているわけだ。

品質管理技法は、日本では昔から、QC検定で既に資格化されている。

QC検定 | 一般財団法人 日本規格協会

QC検定2級って奴 受けてみた - Pass Hunter

また、最近ならば、マーケティングにも統計学を応用する動きが見られる。
レコメンドエンジン、バスケット分析、CRMなど、購買分析や顧客分析にも使えるし、ビジネスにより直結する。

統計学検定という資格もあるらしく、3級は高校卒業程度らしいので、理論を習得するのに丁度良いかもしれない。

統計検定:Japan Statistical Society Certificate

日本統計学会認定「統計検定2級」に合格しました - akiyoko blog

【5】機械学習やデータマイニングで気になることは、Pythonの隆盛であり、Rubyがやや遅れているように見える点だ。

例えば、Rubyは、Railsという強力なWebフレームワークのおかげで、Webの世界では大きな影響力を持つ。
また、Chefなどクラウドに関するインフラ技術においても、Rubyという技術は必須であるように見える。
しかし、今のトレンドである機械学習やデータマイニングの世界では、Rubyの影が薄いように見える。

個人的には、Rubyはたくさんのポテンシャルが秘められていると思うので、この方面にも拡張して欲しいと思う。

| | コメント (0)

2014/05/21

「統計学が最強の学問である」の感想

統計学が最強の学問である」本を読んだ。
とても面白い!

今まで統計学の本を10冊ほど乱読したものの、統計学の思想は何なのか、さっぱり分からなかった。
でも、「統計学が最強の学問である」本を読んで、今までずっと疑問に思ってきたこと「統計学の背後にある思想は何か?」「統計学が抱える根本問題は何か?」が詳しく書かれていた。

そして、「統計学を疫学・社会学・心理学・データマイニング・経済学などに適用した場合、どんな違いがあるのか?」という問いにも的確に答えてくれている。
しかも、統計学の異端児であるベイズ統計が最近なぜ注目されているのか、という問いも解説してくれている。

以下、理解したことをメモ書き。
間違っていたら後で直す。

【参考】
なぜ、統計学が最強の学問なのか? 『統計学が最強の学問である』ビジネス書大賞2014「大賞」受賞記念記事|統計学が最強の学問である|ダイヤモンド・オンライン

「統計学が最強の学問である」で学ぶ 統計学で見える新しい世界 - 酒と泪とRubyとRailsと

書評:「統計学が最強の学問である」、データをビジネスに使う人のための知識が凝縮 - Publickey

漢(オトコ)のコンピュータ道: 書評:「統計学が最強の学問である」→ はい。

『統計学が最強の学問である』感想 - 社会学者の研究メモ

【1】統計学の根本思想、統計学の根本問題

統計学の根本思想は「データから帰納法で因果関係を導き出す」。
統計学の根本問題は「サンプルデータは偏りがないということをどうやって保証しているのか」。
この2つさえ知っておけば、真値、p値、カイ二乗検定、t検定などの概念も多分分かるはず。

その思想を支え、その問題を解決するために、たくさんの用語や概念が出てくるわけだ。

【1-1】本来は、全てのサンプルを抽出して分析すべきだが、コストや時間などの制約で、一部のデータしか採取できないとする。
その時、得られたサンプルデータ(標本)は、全てのサンプル(母数)の一部から抜き出したものと見なせる、と判断できるようにしたい、という意図がある。

【1-2】「統計学が最強の学問である」本で得た知識の一つは、サンプルデータのp値に着目すること。
p値が5%(つまり0.05)未満なら、そのサンプルデータは偏りがなく、そこから得られた因果関係は確からしい、ということ。

例えば、下記の記事では、「誕生月によってJリーガーになりにくくなるのか?」という命題を統計データから分析している。

実践! Rで学ぶ統計解析の基礎(1):Rは統計解析のブッシュナイフだ (2/4) - @IT

R言語で計算した結果、p-value(p値)は2.031e-14(10のマイナス14乗)という値なので、「Jリーガーの月別出生数分布は日本人の月別出生数分布と同じである」確率がその値ぐらい小さい。
そこで、「誕生月によってJリーガーになりにくいということがありそうだ」という命題がかなり高い確率で言える、と指摘している。

【1-3】また、「統計学が最強の学問である」本では、データマイニングでよく出てくるバスケット分析は、カイ二乗検定の方がもっと精度が高い、という指摘も載せている。
その指摘は、グーグルのCEOの過去の論文に掲載されているらしい。

そういう内容を読むと、すごくワクワクドキドキする。
統計学という理論は既にあるのだから、その理論を使って、プログラムを書いて実行してしまえばいい。

【2】統計学を他分野へ応用した場合の注意点

統計学は帰納法で因果関係を導く手法として使えるので、特に人文・社会科学に適用すると、新しい知見が得られる。
人文・社会科学は、自然科学のような演繹法が有効でない場面が多いからだ。

(引用開始)
1) 実態把握を行う社会学調査法
=> 可能な限り偏りを減らして、求める誤差に収まる推定値を効率よく算出する

2) 原因究明のための疫学・生物統計学
=> 原因を見つけることに重視。母集団への当てはまりにはこだわらない

3) 抽象的なものを測定する心理統計学
=> いくつかの測定方法から相関性を出して、数値化したのが知能指数(IQ)

4) 機械的分類のためのデータマイニング
=> マーケティングを目的にクラスタ分析や相関を調べる。ニューラル・ネットワークやサポートベクターマシンなどのような機械学習は、予測に役立つデータマイニングのための手法

5) 自然言語処理のためのテキストマイニング
=> 大量のテキストデータから目的にマッチしたデータを抽出・集計する。形態素解析として辞書を使うMeCabや辞書を使わずに重複する単語を探しだすN-Gramなどがある

6) 演繹に感心を寄せる計量経済学
=>経済学分野で統計学を用いる。相互作用を含む説明変数の選択について慎重な検討を行う

番外) 確率に対する考え方の違うベイズ派
=> 事前確率と事後確率を使う。限られた情報と仮定を組み合わせることで、迅速に答えを出す。
(引用終了)

【2-1】一番興味深いのは、計量経済学。
統計学の基本は、エビデンスとなるデータから帰納法で因果関係を見出す手法。
逆に、自然科学は、ニュートン力学のように少ない仮定から演繹法で理論を導き出す。
自然科学の手法を人文・社会科学へ適用して成功した数少ない事例が、経済学。

計量経済学では、経済データから統計学で分析して得られた因果関係を、過去100年の経済学で得られた理論体系に当てはめて、より良いモデルを作ったり、影響度合いを推定したりする。
つまり、計量経済学は、帰納法と演繹法を組み合わせることで、経済理論を強化する。

国勢調査や経済指標が常に採取されて公開されるので、そのデータを扱って、数多くの理論が今も編み出されている。
「理論なき計測」と見下されるように言われるが、計量経済学の比重は最近高まってきているらしい。

【2-2】ベイズ統計学がなぜ役立つのかも面白い。
ベイズ統計学は、事前確率という仮定を置いて、事後確率を導き出す。
計量経済学のように、既に統計データがあり分析するだけでなく、事前確率という仮定を過去の経済学の理論から持ち出せば、演繹的に導き出せる。

疫学や社会学のように、分析した結果が得られるだけでなく、理論に当てはめて、推定まで行える方が経済学では重要らしい。
だから、経済学者はベイズ統計学を駆使しているわけだ。

【2-3】また、「統計学が最強の学問である」本には、社会心理学に適用した事例として、「学習塾に通った・通わない子供の成績の比較」などもあげられている。
p値が5%未満の数値なので、その結果は正しいだろうと見なせる。
すると、「学校の宿題をやるよりも、学習塾に通った方が子供の成績が良い」という傾向が見られるらしい。

あるいは、「統計学が最強の学問である」本によれば、知的専門家のモチベーションと金銭の関係についてもデータから分析した結果、「既に成功した知的専門家には、動機付けよりも、より良い報酬を与える方が効果的」という傾向が見られるらしい。

そういう因果関係が統計データとして得られるのが面白い。
心理学や社会学は、統計学を使えば、人間の本性について、かなりの部分を解明できるのではないだろうか。

データさえあれば、データを分析するプログラムさえ書ければ、新しい理論を見出すことができる。

| | コメント (0)

2014/03/31

「データサイエンティスト」の感想~データマイニングが自然科学を再定義し直す

最近、R言語や統計学、データマイニングに興味を持っている。
データサイエンティスト データ分析で会社を動かす知的仕事人 (ソフトバンク新書)」を読んだ感想をメモ。

【元ネタ】
SBクリエイティブ:データサイエンティスト

ASSIOMA(アショーマ) ≫ 書評:データサイエンティスト データ分析で会社を動かす知的仕事人

データサイエンティスト(1)データサイエンティストとは?:『ビジネス2.0』の視点:ITmedia オルタナティブ・ブログ

ビッグデータ活用が進まない3つの理由、データを成果につなげるデータサイエンティストの役割とは/ソフトバンク・テクノロジー | Web担当者Forum

科学研究手法の「第四のパラダイム」としてのData-intensive Computing | JOURNAL | FERMAT

むしろ数式が苦手だけど統計を勉強したいという人はRをやるといいかもしれない - Line 1: Error: Invalid Blog('by Esehara' )

【連載】「変わる」広告会社:第1回 エージェンシーのビッグデータ“ドリブン”マーケティング(前編) - ITmedia マーケティング

【1】データサイエンティストが必要になる背景

IT技術が世の中に普及して、当たり前の時代になった今、大量データが溢れている。
その大量データを分析することで、意味ある法則を導き出せるのではないか、という発想。

今までの統計学は、おそらく、机上の空論に近い理論だったのだろう。
実際、コンピュータがなければ、大量データを処理する計算は、手作業でやるしかなく、それは有限の時間で有限のコストでやるには、限界値が低すぎた。

完全独習 統計学入門」によれば、昔の統計学は、いかに少ない計算量で、統計学の意味ある原理原則を導き出すか、というテクニックに走っていたらしい。
でも、現代の強力なコンピュータ技術を使えば、大量データを並列で処理させれば、かなりのことができる。

【2】データサイエンティストに必要な3つの思考パターン

【2-1】オッカムの剃刀

シンプルに考える。
必要以上に多くの過程をしない。
複雑なモデルにしない。

この言葉の発端は、プラトンに由来する実在論に反対し、モノそれ自体とは別に普遍概念が存在する彼らの主張を批判すること。
「プラトンの髭をオッカムの剃刀で剃り落とす」ことから由来している。

オッカムの剃刀 - Wikipedia

データサイエンスなら、前提となる条件はできるだけシンプルにし、大量のデータからシンプルで有効なモデルを作り出すこと。
そのための前提となる考え方。

【2-2】フェルミ推定

フェルミ推定 - Wikipedia

限られた情報からざっくりと答えを出す。

データサイエンスなら、仮説で置いたモデルないし公式に、大量データからデータマイニングして得られた数値を当てはめて、答えを導き出す。
地頭力を鍛える 問題解決に活かす「フェルミ推定」」が読みやすい。

【2-3】アブダクション

アブダクション とは - コトバンク

アブダクションとは、仮説と発見の論理。
演繹法、帰納法の次に来る3番目の論理。

論理の流れは以下になる。

a)驚くべき事実Cが観察される
b)しかし、もしHが真であれば、Cは当然の帰結であろう
c)よって、Hが真であると考えるべき理由がある

たくさんの仮説からもっともらしいものを選び出す論理。
帰納法+推論。

データサイエンスは、帰納法を発展させた考え方と言える。
つまり、大量データという事例を元に、それら事例に共通する原理原則を導き出す手法。

だが、いくらデータマイニングが強力といっても、帰納法ですべての事例が同じような振る舞いや原理原則に従うとは限らない。

そこで、統計学における仮説検定という手法を使う。
Rによるやさしい統計学」によれば、たとえば、「母集団から一部の抽出した標本に対して○○の相関関係を見つけた」という研究論文の主張に対し、「その主張は、母集団から都合の良い標本を見つけ出したのに過ぎないのではないか。本当はそんな相関関係はあると限定できないはずだ」と反論を受けたとする。

すると、そのライバルの指摘した事象が起こることは現実的にほとんどありえない、という主張で反論し返す。
つまり、母集団に我々が主張する相関関係が全くないとしたら、我々が見つけた標本が得られる可能性は非常に小さい、ということを示す方向で反論する。

この反論の仕方は、母集団から全ての標本を集めた証明に比べると、説得力は弱いが、限られた標本データからある程度の合理性を持って、コストや納期の観点による検証可能性から見れば、かなり強力といえる。

すなわち、データサイエンスは、統計学の仮説検定という手法を使って、データマイニングで見つけた相関関係という原理原則はほぼ確からしい、という統計学の理論的基盤によって、その正当性を示しているわけだ。

【3】データサイエンスは第4のパラダイム

【3-1】第1のパラダイム~経験科学

観察・観測によって自然現象の原因を解明する。

【3-2】第2のパラダイム~理論科学

既知の法則に基づく新たな現象の予測。
実験による仮説検証。

【3-3】第3のパラダイム~計算科学

理論的解が得られない複雑な現象を近似解として、ITのシミュレーションで予測する。

【3-4】第4のパラダイム~データサイエンス

膨大な一次データを収集・分析し、関係性を見出す。
コンピュータによる経験科学の再定義。

科学の「第4のパラダイム」 データ集約型科学が人類の危機を救う | トニー・ヘイ | 2011年11月号|DIAMOND ハーバード・ビジネス・レビュー

【4】データサイエンティストは計算可能な定量モデルを提示する

その数学が戦略を決める」では、ワインの質の方程式を統計学の手法から定量的に求めた式がある。
品質が高いワインは、収穫期に雨が少なく、夏の平均気温が高いという経験則をもとに、ワインの質の定義をソムリエから奪った。
ワインの質は、舌よりもデータで決まる。

ワインの質の方程式のおかげで、生産者やワイン売買業者も、数年から数十年経って質が決まるワインをある程度予測できるようになり、その分、助かったという話がある。

【5】データサイエンティストグロースハッカー

データサイエンティストは、プログラミングとマーケティングの二つの技術を兼ね備える人。
Webサービスの世界で増えてきた。

グロースハッカーとは何か?―シリコンバレーで急増する、WEB業界の新たなキャリアを定義する[1]│CAREER HACK

1990年代は、Apacheアクセスログから、PVやユニークユーザ数などを解析した。
2000年代は、GoogleAnalyticsを使えば、だれでも手軽に解析できる。
しかも、技術的知識がなくても、マーケティング知識があれば、いろんな使い方ができる。

グロースハッカーの出現は、リーンスタートアップの発想に似ている。
ビジネス>プログラミングから、プログラミング>ビジネスの時代への転換。

【6】マーケティングモデルはAIDMA、AISASモデルからAARRRモデルへ

AIDMAは、1920年代のアメリカで生まれたマーケティング手法。

AIDMA - Wikipedia

日本の広告代理店の電通等によるWebマーケティング手法として、AISASモデルが提唱された。
そして、ECやクラウドサービスの見込み客を優良顧客へ変えて収益を上げるマーケティング手法として、AARRRモデルが提唱されている。

「AARRR」 今更だけど絶対抑えておくべきグロースハッカーのコンバージョンの見方 | グロースハックジャパン | growth hack japan

AARRRモデルを使えば、コンバージョンを追跡することで、Webサイトのどこに問題があるのかを分析できる。
Twitter、Instagramを導いたグロースハッカーの仕事とは―グロースハッカー徹底解明[2]│CAREER HACKには、下記の例がある。

(引用開始)
例えば、同じアイテムを取り扱っているECサイトが2つあるとします。
Aのサイトは一日に100人の訪問者があり、50人が会員登録してくれた。
ただ、実際に買物してくれたのは、そのうちの5人。
50%がサインアップしてくれたが、
そのうちの10%しか課金してくれなかったということになります。

Bのサイトも同様に一日に100人の訪問者があるものの、会員登録してくれたのはわずか10人。
しかし、その半数の5人が買物をしてくれた。
サインアップしてくれたのは10%でも、その50%が課金してくれた。

AとBともに100人の訪問があり、
5人のユーザーが課金してくれたという事実は同じですが、
それぞれが抱えている問題は全く異なります。
この違いは、PVとコンバージョンだけ見ていても絶対に分からないでしょう。
アクイジションやアクティベーション、リテンションなど、
どのプロセスに課題があるのかをまず見つけること。
そこからアイデアに優先順位をつけて、実際に改善をしていく必要があります。
(引用終了)

つまり、サイトAは、訪問者を集めるプロセスは良いが、課金プロセスを改善するのが課題になる。
サイトBは、課金プロセスは良いが、訪問者が会員登録するプロセスを改善するのが課題になる。

グロースハッカーは、データマイニングを使って、そのような問題を洗い出し、問題解決の対策を打ち出して、実行して結果を上げる役割を担うわけだ。

【7】データサイエンティストが育つ場所

データサイエンティストが育つ場所は、新領域での実践の現場。
ビジネス側とソフトウェア開発側の協同作業。

統計学の理論だけでは机上の空論。
マーケティングの手法を知っていたとしても、実際にプログラミングして、Webサイトからフィードバックをすぐに得られる仕組みがなければ、机上の空論。
プログラミングだけできても、ビジネス上の問題を解決する手法でなければ、単なる技術の持ち腐れ。

データサイエンティストグロースハッカーであるならば、ビジネスもプログラミングも両方知っている。

【8】プログラマがデータサイエンティストになるための方法

データサイエンティスト」には、どんな言語を選べばよいかは書いていない。
個人的には、R言語が面白いと思う。

オープンソースだし、情報はネット上にいくらでもある。

データマイニングが自然科学を再定義し直す。
すごくワクワクする。


| | コメント (0)

2014/03/29

第56回 SEA関西プロセス分科会「Eclipse XText によるドメイン特化言語の応用」の感想

第56回 SEA関西プロセス分科会「Eclipse XText によるドメイン特化言語の応用」に参加したので感想をメモ。
自分用メモをそのまま貼り付けたので、適当に書く。

【元ネタ】
3月29日 第56回 SEA関西プロセス分科会「Eclipse XText によるドメイン特化言語の応用」

Xtext - Language Development Made Easy!

ベータパブリッシュ - テキスト型DSL開発フレームワーク Xtext 入門

最初は、細合さんのお話。

【1】DSLのメリット

 生産性の向上
  コードの自動生成
 ドメイン分析
  プログラムを第三者視点で表現して分析
 特定のモデルしか書けない
  プログラミングの知識があまり必要ない
  ドメインを明確にする
 プログラミングというプログラマの暗黙知を形式知にする

DSLを使いたい最大の理由は、暗黙知にあるドメイン知識を形式知にすること。
DSL文法を使うことによって、例えば業務ドメインの言葉を定義することで、どんな概念が必要で、どんな文法(つまり制約条件)が必要なのか、を明確にする。

DSLで書かれたモデルから、XtextはすぐにJavaソースへ自動生成できる。
昔のモデル駆動開発は、本来はXtextで書かれたモデルからソースを自動生成すべきではなかったのか。

【2】DSLの種類

Internal(言語内・内部)・External(外部)と、テキスト形式・グラフィカル形式で分類された4種類がある。

・Rake:Internal(言語内)+テキスト形式

・Make、SQL、Ant:外部DSL+テキスト形式
 →XTextもココに入る

・UML、SysML:外部(独自処理系)+図形式

・VisualStudio:内部+図形式

AntやSQLは外部DSL。
Rakeは内部DSL。

UMLやSysMLも、グラフィカルなDSLの1種ととらえる発想は面白い。
確かに、業務モデルや組み込み機器のモデルをUML文法やSysML文法に従って、図に書いているわけだ。

【3】DSL環境
 DSL定義→メタモデル→コード

DSLの作り方
 ドメイン知識が必要なので、新規開発に向かない
 既存資産からパターンを抽出し、ドメインモデルと変換規則を生成する

XText
 OSSのEclipseのDSL支援環境

昔に比べると、言語生成がすごく楽になった
 XTextなら、DSL定義とメタモデルさえ書けば、コードを自動生成してくれる
  コードアシスト、シンタックスカラーリング、バリデーションなどの開発環境もある
  Javaのライブラリを参照できる
  Eclipse上で、テキスト形式とグラフィカル形式を連動できる

XText
 DSL定義

XTend2
 Javaを生成する軽量言語が内蔵されている
 XTextで作られたJavaを生成する軽量言語
 Javaの痒い所に手が届く便利な言語
 書いたそばから自動生成
  コンパイルまで行なってくれるので、Javaとシームレスに利用可能
  動的型付け
   但し、コンパイル時に型決定なので安心
  ラムダ形式、拡張関数、拡張Switch(型に応じて条件分岐)
  テンプレート記述
   Javaを自動生成するためのコードテンプレート
    テンプレートにある変数にクラス名、変数名、メソッド名などが、メタモデルから設定されて、自動生成される

MWE2
 DSLからモデル、コード生成までのモデルワークフローエンジンが組み込まれている
 ワークフローエンジン
  XTextで書かれている
 モデル駆動開発の主要な作業をワークフローの形で記述できる
  状態遷移図みたいなもの
  State、Transitionを定義する
 Xtextの言語生成を行う際もこのMWE2のスクリプトを起動して言語環境の生成を行う
 DIのような機能もある
  ワークフローの途中にポイントがあり、動的にロジックを挿入できる?

Xtextの最大の利点は、DSLの文法を定義するプロセス、自動生成するソースのテンプレートをXtextだけで書けること。
つまり、Xtextさえ覚えれば、DSLを自前で定義できる。

使い道としては、フレームワーク開発を担当する上級SEや上級プログラマがXtextでDSLを定義する。
設計SEは、自前で定義されたDSLに基づき、業務のモデルをDSL文法に従って書く。
すると、即座にモデルに従ったJavaソースが自動生成される。
さらに、テストソースも自動生成されるので、設計SEが開発者の役割も兼ねて、自分でプログラムを書いてしまえばいい。

【3】Xtextを使ったDSLの使い道としては、下記のような業務システムの内部設計があるだろう。

【3-1】業務システムのCRUD表からJavaソースのスケルトンを作成
 機能とテーブルのCRUDマトリクスを、DSLに基づくモデルを書いて、ソースを自動生成する。
 画面やバッチが、どのテーブルからどんなデータを使って、どのテーブルへデータを更新しているのか
 機能をいじると、影響するテーブル、そのテーブルを使う機能に影響が出るのが分かるようにならないか?

【3-2】モデルからソースを自動生成
 モデルベース要件定義に相当する。
 例えば、オブジェクトの状態遷移図をDSL文法で書いて、ソースを自動生成する。

【3-3】既存システムのリバース・エンジニアリングは使えないか?
 既存システムの保守の過程で、パッチで継ぎ接ぎされて、ドキュメントが実際の仕様を反映していない
 誰も既存システムの仕様を知らない
 そんなときに、DSLを使ってソースを解析し、モデルを自動作成とかできないか?

【3-4】ワークフローエンジンを作る
 例えば、ユーザ企業の経費申請、工場の製造・出荷の作業フローなど。
 DSLで状態遷移図の文法を定義し、モデルにワークフローを書き、ソースを自動生成する。

 Xtextでは、トランジション(条件分岐)にDI(Dependency Injection)が使えるらしいので、BRMS(ビジネスルール管理システム)を理論上実装できるはず。
 例えば、出張申請のワークフローをXtextのモデルで書いておき、「出張旅費5万円以上なら、処理Bを実行する」のような業務ロジックをトランジションに挿入して呼び出しできるようにすればいい。

【4】次は、細谷さんの事例の話。

【4-1】Xtext導入の経緯
 SNSで聞いていた
 アジャイル開発で、通信プロトコルの解析処理の実装が電文解析しながら、単純作業になっている
 電子仕様を形式化して、コード生成手段とマッチング
 Xtextは15分でやれると聞いて試した
 チュートリアルの試行
 独自のコードジェネレータを実装

Xtext以前のコード生成
 Excelマクロでコード生成
  Excelで設計書を作る
 Rubyによるコード生成

より良い手段としてXtext導入を検討

Xtextの適用
 バイナリファイルのパーサー

 製品に対抗する装置のシミュレータ
  100種類の信号に対応する電文
  製品とシミュレータがTCP/IP通信
 様々な装置に対抗する装置のシミュレータ
 コード生成のツールとして利用
 既に規定されている構造を処理するコードを生成する
 通信プロトコルを定義するための文法を設計、実装し、未来のプロジェクトで利用可能なDSLを定義する

Xtextの気づき
 ドメイン知識の形式化
  文法を定義する過程で、ドメイン知識が形式知になる
  定義された文法を読めば、非常に少ない情報量で、モデル化の範囲や内容を理解することができる

  70%をカバーする製品に適用した
   マニアックな製品仕様は除く
   コストが割に合わない

 モデルの改善
  一つの言語要素から1つの対応するクラスを生成する
   ジェネレータの実装が簡単になる
  自動生成範囲が派生クラス、共通部分が基底クラスとなり、実装の重複がなくなる

効果的な導入ポイント
 最初から全てのモデル化は困難
 容易に効果が出るポイントに着目する
  コストや時間のトレードオフ
 分析して言語を決めるのは、初心者ならXtextは時間がかかる
  最初は単一プロジェクトから
 行数の多い表に注目する
  Xtextに適用すると効果的
  表は一つの型
 一つのデータ定義が複数の箇所で実装される部分に注目する
  例:機器の監視項目
     監視項目は電文の仕様に近い
      電文の定義をDSLでモデルとして表現する
     監視項目は画面で表示して、担当者がチェックする
 同じ概念を複数のソフトウェアで共有している部分に注目する
  例:複数の機器の間の通信
     通信されている機器のI/Fは共通の電文仕様を持っている

【4-2】細谷さんの話を聞くと、Xtextを組み込み機器の通信プロトコルに使われる電文や制御処理の自動生成に使われていたらしい。
DSLで通信プロトコルの制御仕様を書くことで、100種類以上の電文の仕様(ドメイン)が明確になり、そのドメインを他の開発者も共有できる。

興味深かったのは、DSLが万能といっても、すべての電文をDSLの対象はならないこと。
複雑な仕様の電文は、コストや納期などの都合上割にあわないので、効果が出る部分のみにXtextを導入した、とのこと。

【5】Xtextの実演習では、Eclipseを使って、サンプルソースを書きながら動かしてみた。
初心者なので、開発環境Eclipseの使い方にはまる。

慣れると、Eclipse上でDSLのコード補完、バリデーション、Import文の自動追加、コードハイライトなどがあるので、すごく書きやすい。
フレームワークを開発、保守するプログラマなら、Xtextを覚えれば、かなり生産性が上がるのではないだろうか?

また、細谷さんから聞いた所によると、XtextのDSL文法はEclipseのプラグインにできるらしい。
すると、ある特定の実装モデルを記述するDSLをXtextで書いてEclipseプラグインにしておき、開発工程でプログラマにプラグインを読み込ませて、実装モデルの設計をDSLというプログラミングで書いてもらえばいい。

すなわち、上級プログラマがDSL文法を定義して、それをEclipseプラグインにして設計SEに配布しておけば、設計SEはDSL文法に基づくモデルを書くと、ソースないしスケルトンを自動生成できる。
つまり、上級プログラマが、システムの方式設計と、システムの設計内容を記述するモデル言語としてDSLの文法を作っておけばいい。

他に、DSLに基づくモデルとして、UMLのクラス図やシーケンス図、状態遷移図があるだろう。
設計SEは、業務をそれらUMLのダイアグラムを絵で書くのではなく、DSLの文法に従ってテキストで書けばいい。
設計書はモデルを表すテキストなので、Gitの配下でバージョン管理でき、その変更履歴をいくらでも追跡できる。
また、モデルをグラフィカルに表現するようなツール(例えばPlantUML)に食わせれば、顧客などのエンドユーザも理解できるはずだから、要件定義や仕様変更で議論しやすくなる。

色々試してみる。


| | コメント (0)

2014/03/18

パターン指向リファクタリングのワークフローはドメイン駆動設計のアイデアに似ている

Martin Fowler氏によるリファクタリングのワークフローの記事が面白かったのでメモ。

【元ネタ】
Martin Fowler氏によるリファクタリングのワークフロー

TDDには黄金律(Red→Green→Refactoring)というワークフローがある。
つまり、テスト駆動開発とリファクタリングは密接に関連している。

テスト駆動開発・実践編01・黄金の回転 - Strategic Choice

実践テスト駆動開発第1回

テスト駆動開発の概要とメリット ? 実践テスト駆動開発一人読書会(1) ? mizoguche.info

リファクタリングは、反復的な設計手法でもある。
最初から完璧な設計ではなく、動くコードを徐々に洗練させながら、より良いコードへ変えていく。
つまり、進化的設計の手法の中にリファクタリングが組み込まれている。

パターン指向リファクタリング入門」は、GoFのデザインパターンとファラーのリファクタリングを結びつけた本だ。
アイデアとしては、パターンを、新しい設計の初期段階ではなく、既存の設計を改善するのに用いる。
さらに、パターンを使って設計を改善する時に、コードレベルの設計の変換、つまり、リファクタリングを使う。

(引用開始)
Joshua Kerievsky氏は著書「パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法」の中でこう提案した。

継続的にコードの設計を改善していくことで、どんどんそのコードを扱いやすくなる。
これは、ほとんどリファクタリングせず、便宜上新しい機能を追加する際に多大な注意を払う、というようなよくある状況とは雲泥の差だ。
もしあなたに継続的リファクタリングの衛生的習慣が身についたなら、いかに拡張や維持が容易になるかよく分かるだろう。
リファクタリングは今や周知の手法だとFowler氏は述べているが、多くのチームはリファクタリングの際に使用できる様々なワークフローをより良く理解する必要がある、と彼は示唆している。
そうすることで、それぞれの状況に一番合ったものを適応出来るからだ。
(引用終了)

リファクタリング」によれば、ファウラーは、パターンは目指そうとする所であり、リファクタリングは、どこか別のところからそこへ到達する方法、と言っている。
これは、リファクタリングの結果出てきた構造が実はパターンである、ということを意味していると思う。

この話はドメイン駆動設計の話に似ている。
ドメイン駆動設計において、浅いモデルを洗練させていくと、ある時、ブレイスクルーが起きて、深いモデルに変わる瞬間がある。
すると、深いモデルでは、ドメインエキスパートと開発者はユビキタス言語で会話できるようになる。

つまり、動くけれども汚いコードをリファクタリングしていくうちに、シンプルな構造になり、ブレイクスルーが起きた時、パターンが自然に現れてくることを意味しているのだろう。

パターン指向リファクタリング入門を突き詰めると、下記の3つのワークフローに集約されるらしい。

(1)新しいタスクを始める際に適応する"Preparatory(予備の)リファクタリング"
(2)広範囲において多大な注意を払う必要があるような問題のあるコードが存在する場合に適応する"Planned(計画的)リファクタリング"
(3)複数回の反復を通して大きなモジュールをリプレースする際に適応する"Long-Term(長期の)リファクタリング"

上記の3つのリファクタリングのワークフローは、ドメイン駆動設計の蒸留プロセスの連想させる。
パターン指向リファクタリング入門」は実際のコードを使って、リファクタリングとデザインパターンを絡めたパターン集になっているが、そのアイデアを突き詰めて抽象化させると、上記3種類のワークフローに収斂させるのだろうと思う。

他にも色々考えてみる。

| | コメント (0)

より以前の記事一覧