プログラミング

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)

2014/03/02

「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」の発表資料が素晴らしい #devsumi

デブサミ2014の発表資料を読んでいて、僕の中では「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」が一番心に残った。
ラフなメモ書き。
以下の発表資料の文章を引用している。

【元ネタ】
Developers Summit 2014 で「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」という内容で発表してきました - sifue's blog

2014/02/14 デブサミ2014【14-A-6】Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所 #devsumiA - Togetterまとめ

【0】背景

この発表資料は、「Scalaを使ってWebサイトを構築、運営してみようとしているリーダーさん向け」。

ニコニコ動画のPHPソースがレガシー遺産という負債となっていた。
リファクタリングしたものの、抜本的な対策が必要と痛感。
そこで、ニコ生動画を書き直すニコ生2プロジェクトが発足した。

目的は、スケーラビリティ・フォールトトレランス・保守性・パフォーマンスの品質を担保すること。
チームは4人から始まった。

【1】Scala

Scalaの利点は、静的型付けを持ち、保守性も高そう。
そして、関数プログラミングによる並列処理も実装可能。

但し、PHPプログラマからScalaへ移る場合、アルゴリズムとデータ構造、関数型プログラミングの考え方などのサポートが必要。
社内で勉強会を開く、など。

【2】PlayFramework+ドメイン駆動開発

ドメイン駆動設計で、UI層→アプリケーション層→ドメイン層→インフラ層の4層構造というレイヤードアーキテクチャ。
ユビキタス言語を使ったドメインという業務知識の共有。

コアの蒸留、汎用サブドメインの分離によるモジュール化。

Play2/Scalaはドメイン駆動設計を実践するのにとても良いフレームワーク。

・CoCがきつくなく好き勝手フォルダが掘れる。
・マルチプロジェクト機能でサブモジュールの依存関係を作れ、レイヤー ドアーキテクチャの強制できる。ドメイン層、インフラ層はplayに依存しないただのjar。
・case classがエンティティと値オブジェクトの作成のコストを下げる。例えば、インフラ層ORMのマッピングクラスとドメイン層のエンティティを分けることなどが苦にならない。
・play2を捨てられるように開発することが可能。

僕の感想としては、この部分が一番なるほど、と感じた所。
ドメイン駆動設計では、ドメインが明確になるために、オブジェクト指向設計の長所を適用できる。
更に、ドメイン駆動設計は小規模リリースと相性の良い設計手法なので、新しいフレームワークの基盤の上に機能を少しずつ追加していく時に役立つだろう。

但し、ドメイン駆動設計は敷居が高い。
リファクタリング」「UMLモデリングの本質」「アナリシスパターン」「エンタープライズ アプリケーションアーキテクチャパターン」の4冊を読んでおかないと、「ドメイン駆動設計」の凄さが分からない。

この点も僕も同感。
振り返ってみれば、僕も、Javaの勉強のために「リファクタリング」、オブジェクト指向設計の勉強のために「UMLモデリングの本質」「アナリシスパターン」、アーキテクチャ設計のために「エンタープライズ アプリケーションアーキテクチャパターン」を読んでいたから、「ドメイン駆動設計」に出てくるたいていのパターン名が何を意味していてどんな背景から生まれたのか、はすぐに分かった。
つまり、ドメイン駆動設計は、先人の設計手法の積み重ねの上にある。

ドメイン駆動設計をいち早く理解するには、下記のYouTube資料が良いらしい。
視聴してみると、確かに「何がドメインであり、何がドメインでないか」はよく分かるのでお勧め。

20110409_DevLOVE「Building Blocks」_都元ダイスケさん - YouTube

また、ScalaのWebフレームワークであるPlayフレームワークを使っている点も上手い。
Struts→Seasar、Spring→Wicket、Playへ発展した経緯を考えると、RailsのようなPlayフレームワークは、今後のJavaプログラマには必須のフレームワークになるだろう。

Javaの常識を変えるPlay framework入門

ScalaのWebアプリケーションフレームワーク「Play Framework」入門 ~(1)環境構築とスタートアップアプリの作成 (1/6):CodeZine

但し、Play2/Scalaの弱点として、下記が挙げられていた。
今後のPlay2/Scalaの改善点になるだろう。

1. sbtが遅すぎる。
  →proxyを作ったり、良いマシンを使うぐらいしかない
2. Play2のscalaテンプレートが、コンパイル遅く、文法がデザイナー にやさしくない仕様。
  →Groovyテンプレートで作成。 github/dwangoでフォークしたも のを公開中
3. テストで困るobjectとtraitと関数引数。
  →specs2のmockitoの制約。objectのモック作れない、traitはmixin が必要、ジェネリクスパラメーターが付いた関数引数のメソッド を拡張できない。

【3】Scrumはリーダーを育てる

「自身のウォーターフォール開発とアジャイル開発のプロジェクトマネージャ経験」として、以下の苦い経験があった。

1. 過去4度のフォーターフォール開発と、大失敗の経験。
 →要求が変更されてしまうと地獄。不確定要素に対応するためのバッファ重要。最後のしわ寄せは品質に。
2. 要件が確定できない、また、要求の優先順位が日々変わる場合、アジャイルとスクラムの考えが良い
 →日々変わるチームの目標への柔軟な対応が必要なWeb開発

「Scrumはリーダーを育てるのにすばらしい手法である」理由は下記の通り。

・会議体が固定
・JIRA/GreenHopperなどのサポートツール
・書籍が充実している
・プランニングポーカーでの見積もりが、スクラムマスターを孤立させない
・全員が全ての帽子をかぶるので段階的にスクラムマスターにさせ ることが可能

この点は、すごく納得した。
開発チームを運営する役割であるプロジェクトリーダーには、アジャイル開発やWF型開発に限らず、最低限3つのスキルが必要だと思っている。

一つ目は、体制図。
つまり、案件に出てくる利害関係者の関係をグラフにまとめたもの。
普通は、プロジェクト立上げ時に真っ先に書くべきもの。パワポやVisioなどで書く。
WF型開発の大規模プロジェクトほど、利害関係者が多くなり、誰がどんな役割で動くべきか、をきちんと定義しないと、無駄なコミュニケーションばかり増えて、プロジェクトが進まなくなる。

Scrumの良い点は、アジャイルなスクラムチームには、プロダクトオーナー・スクラムマスター・チームの3つだけでロールが十分であると定義していること。
更には、「ニワトリとブタ」の話のように、スクラムチームに所属していない利害関係者から開発チームを守る仕組みが提供されていること。
これによって、体制図はとても簡単な構造になり、コミュニケーションを取りやすくなれる。
また、それぞれの役割が明確なので、Scrumのフレームワークに従って行動すればいい。

2つ目は、概要スケジュール。
つまり、タスクの詳細を書いたガントチャートではなく、各工程、各プロセスの前後関係を明確にしたPERT図。
普通は、プロジェクト立上げ時に、マイルストーンを意識しながら、どんな工程が必要かを洗い出し、各工程のInとOutをつなげて書くので、自然にPERT図になる。
この概要スケジュールを元に、概算で見積りし、詳細なスケジュールを落としこんでいく。

Scrumでは、大まかなリリース計画(ロードマップ)をプロダクトオーナーが決めて、それを実現するためにストーリーに分割してバックログへ優先順位ごとに並べる。
開発チームは、バックログのストーリーの順に従って開発していくだけでいい。
また、スプリントごとに出荷してデモするから、利害関係者も定期的にソフトウェアを評価して、ロードマップ通りに進んでいるかをチェックすることもできる。

3つ目は、コミュニケーション計画。
つまり、体制図に書かれた利害関係者といつどこでどんな会議をするのか、という会議体の構成図。
普通は、顧客との月次進捗定例、複数の開発チームリーダー同士の週次の課題管理定例、開発チーム内の毎日の朝会、などがコミュニケーション計画になるだろう。
これらの会議体がスムーズに運営されなければ、プロジェクトの障害や課題がスムーズにエスカレーションされず、納期が遅れたり、品質悪化の原因になる。

しかし、たいていは、会議の運営コストが大きすぎて、プロジェクトリーダーは常に会議の資料の準備に追われたり、1日が打合せだけで終わってしまう時も多い。

Scrumの良い点は、デイリースクラムという毎朝の15分の朝会が会議体として決まっていて、その会議だけで十分であること。
デイリースクラムで進捗を確認できるだけでなく、メンバーが抱える課題を早期に見つけ出すこともできる。
更に、スプリントの最後には、製品評価であるスプリントデモや、スプリントをふりかえるスプリントレビューがフレームワークとして準備されているので、定期的に直近のスプリントを評価し、改善策を考えるきっかけにもなる。
「スクラムマスターはScrumプロセスの守護神」という考え方は、この会議体のスムーズな運営によって支えられているわけだ。

発表資料では、上記以外にも、「スクラムマスターも常にプレーイングマネージャーであれるようにする」「ユーザの要求理解に時間をかける」「企画と相談する時は、重要度ではなく常に要件の優先度で議論する」「インフラチームや他チームとの共同作業は合流バッファを考える」など、プロマネがプロジェクト管理で気を付けるべき点について、たくさんの経験談が含まれていて、とても参考になった。


| | コメント (0)

より以前の記事一覧