読者です 読者をやめる 読者になる 読者になる

○×ゲームの神の一手を導いてみた

計算機 手慰み

小さい頃にノートの隅や地面で良く遊んだ○×ゲームを計算機で解いてみた。

○×ゲーム程度であれば、スクリプト言語を用いて、かつ枝刈りとかせずに終端までミニマックス法で全探索しても十分に解ける。ミニマックス法というのは、要するに負けない手を打てば勝てるという戦法で、○×ゲームのようなゲームではミニマックス法ですべての局面を調べることができれば、最善の一手が得られることが知られている。

○×ゲームは両者が最適な手を打てば引き分けとなる。先手に関しては一手目をどこに置いても、引き分けに持ち込むことができる。二手目以降からは、正しく受けないと負けてしまう。したがって、二手目を正しく受けれない可能性があるので、微妙に後手が不利かもしれない。

一手目が中の場合は、後手は隅で受ける必要がある。

f:id:fjkz:20160529221757p:plain

初手が隅の場合は、中で受ける。

f:id:fjkz:20160529221938p:plain

初手が、辺の場合は、隣の隅か中か対辺に打てばよい。

f:id:fjkz:20160529222112p:plain

以下のPythonスクリプトを実行すると、先手後手双方が最善の一手を打ち合う

fjk@x240:~/works/ox-game$ ./oxgame.py 

   +---+---+---+
   |   |   |   | 
   +---+---+---+
   |   |   |   | 
   +---+---+---+
   |   |   |   | 
   +---+---+---+


   +---+---+---+
   |   |   |   | 
   +---+---+---+
   |   |   |   | 
   +---+---+---+
   |   | O |   | 
   +---+---+---+


   +---+---+---+
   |   |   |   | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   |   | O |   | 
   +---+---+---+


   +---+---+---+
   | O |   |   | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   |   | O |   | 
   +---+---+---+


   +---+---+---+
   | O |   |   | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   | X | O |   | 
   +---+---+---+


   +---+---+---+
   | O |   | O | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   | X | O |   | 
   +---+---+---+


   +---+---+---+
   | O | X | O | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   | X | O |   | 
   +---+---+---+


   +---+---+---+
   | O | X | O | 
   +---+---+---+
   |   | X |   | 
   +---+---+---+
   | X | O | O | 
   +---+---+---+


   +---+---+---+
   | O | X | O | 
   +---+---+---+
   |   | X | X | 
   +---+---+---+
   | X | O | O | 
   +---+---+---+


   +---+---+---+
   | O | X | O | 
   +---+---+---+
   | O | X | X | 
   +---+---+---+
   | X | O | O | 
   +---+---+---+

特に結論とかはない。


ソースコード

ソフト開発にも生産技術者が必要

計算機 考察

製造業には必ず生産ラインの世話をする役職の人がいる。製造業においては、この役割の人は階級が高くて、会社内ではエリートがする仕事である。昔は社会的にも地位の高い仕事だったのだろう。現在だと聞かないが、かつては製鉄業の現場監督はエリートの仕事であったそうだ。今の日本国の首相である安倍晋三も昔は製鉄所の現場で働いていたらしい。どなたか忘れてしまったが、かつての製鉄業の偉い人は「俺は生まれ変わっても鉄を作る」と言ったそうだ。アツいし、誇りに満ち溢れるよね。

現在でも、製造現場の現場指揮官のような仕事は高給取りで組織内での地位が高いことには変わりないと認識しているが、印象として社会的に高い地位の仕事と認知されていないと私は思っている。決して低いわけではないが、同窓会で工場で現場監督しているといっても、おそらく「ふーん」となるだけで、「すごーい(黄色い声)」とはならないだろう。

私も、学生の時分はそういう仕事はしたいとは思わなかった。キーエンス任天堂・シスコ・アップルのような工場とかいらんでしょみたいな風潮が流行っていたのだ。そういう流れに逆らう形で、「ものづくり」とかいって工場の誇りを取り戻すための言葉が使われていて、この言葉は嫌いだった。工作は好きだったが、生産ラインが嫌いだった。

しかし、現在では、工場の現場の頂点に社長が君臨するような、工場中心の企業の代表格であるトヨタ自動車が、非常に大きな利益を出している。本屋にはトヨタ自動車の秘密みたいな本が平積みにされている。ミーハーなだけかもしれないが、トヨタマン流の行動原理は見習わなければならないと最近強く思っている。

生産ラインは嫌いだったが、ソフトウェアの開発にも結局ラインはあった。産業としてやろうと思ったら、ラインつまりシステムの形に落とし込まなければ、安定した生産というのは無理だと気づいた。製造途中の製品が流れていくのとは違い、意思決定とそのための情報が流れていくことになるので、形態は工場のラインとは異なるものになる。システムといっても、コンピュータシステムのことではない。システムの構成要素にホワイトボードだとか口頭伝達が含まれていてもよい。

ソフトウェアの開発をシステムの形に落とし込んでいって、そのシステムの維持管理をする役回りの人は当然いて然るべきだと思うけれども、あまり聞かない。製造業では、企業によって呼び名が変わると思うが、しばしば生産技術者と呼ばれる人である。

プロジェクト・マネジャーの仕事ではない。人間は適応性が高いから、人間が構成要素として組み込まれてているシステムというのは、整っていていなくても、即興でゴニョゴニョすることで一見回っているかのように見えてしまう。そういうことをすると一時的には問題を隠して乗り越えることができる。プロジェクト・マネジャーという役回りは、ゴニョゴニョと調整をして、問題をやり過ごすことだと思っている。プロジェクト・マネジャーのゴニョゴニョ自体もシステムの中にブラックボックスとして含まれてしまっているのだ。

システムに組み込まれた人間が一時的にシステムを逸脱して即興で解決するということに頼らずに、システム自体を綺麗に整えていくのが、筋だと思うのだ。即興で問題をさばいて解決している人が褒められる傾向にあるが、その人らは問題の存在を隠してしまって、いわゆる根本原因の解決を妨げているのではないかと思ったりする。やり過ごせればもうどうでも良くなってしまうものだし、やり過ごしたこと自体に達成感があっちゃうから困る。

イメージ的には、即興の調整役みたいな人に属人化されていてブラックボックス化されている意思決定のフローを可視化してシステム化したりする仕事、あるいは、そういう調整が必要なくなるように、前工程からやってくるもののバラつきを防ぐようにする仕事がいるのではと思っている。

何と呼ぶべきかわからないが、広い意味でいうところのQAエンジニアになるのだろうか。製造業だと、品質を一定に保つための仕掛けを治具という。ソフトウェアだと、テストフレームワークだとかビルドツールだとかCIツールがそれに相当する。課題管理システムとかもそれに入るかもしれない。現場を観察して、必要に応じて治具を作ったり、その運用をしたりする、そういう役回りの人は必要だと思うのだけれど、認知されていないし、名前もついていない。

名前のついていない職種を募集している企業はないので、探せないが、需要はあるのだろうか。というよりも、私はそういう仕事をする人は必要だと思うので、その考えに同意してコストをかける価値を認める会社があるなら、私がやってあげてもいいよという感じだろうか。もちろん、ラインでもなくて、その上に流れている製品でもなくて、製品が解決する問題の方に本来は興味があるので、そこが同意できることが前提ですが。

企業と効率とインターネットの可能性

計算機 所感

一般論として世の中の企業というのは非効率で不合理な多くてどうにかならんもんかなと思う。

ムダのために会社が損をしたら、株主なり債権者は金銭的に困る。従業員からしても、自分の金ではないからと、『サラリーマンは気楽な稼業と来たもんだ』とはならない。日本社会は会社が潰れないこと前提にできているから、潰れたらすごく困る。

ムダによる高コストを価格に転嫁するようなことがあれば、顧客にも悪いことをしている。現実には原価が高いから高く売るなんてことはできないので、顧客が本当に求めているときに商品を提供できなくて機会損失を与えたり、カタログスペックには現れないような微妙なところの品質が落ちたりして、買う側も気付かないようなところで損をするようになるのだろう。三菱自動車なども、コスト体質だとかの内情は知らないけれども、当然トヨタ自動車と同じような開発体制や生産体制を整えることはできないにも関わらず、トヨタ自動車と同じような値段で同じようなものを作ろうとしたら、無理がたたることになったのだろう。

また、ムダな仕事を黙々とするような従業員の人生は社会にとって無意味なのではないかとか思ったりするわけです。考えすぎるとすべては無意味でムダだといった虚無主義に陥ってしまうが、少なくとも経済的な意味においては間違いなくムダは社会的な損失だろう。

不合理・非効率――ムダの排除をして不幸になるステークホルダーはいない。

すごい昔は、カイゼンとか効率とか嫌いだった。効率最優先で人間性を阻害した利益至上主義で、それらが環境破壊だとか公害だとかを起こしていて、人を大切にせずに劣悪な環境で働かせて使い捨てにするような、汚い怪物ぐらいに(ちょっと盛っているが)思っていた。

しかし、その後企業ってもっと生産的なところだと思っていたのに――と逆にショックを受けて、考えが反転した。あくまで一般論で、どこでもそうで誰に聞いても誰もが一様にショックを受けている。それで今は非効率を憎んで、世の中のムダは抹殺すべきぐらいに思っている。

ムダをなくすだけでは、高いものが安くなるだけではないか単純には思ってしまう。人が要らなくなって、単に失業者が増えるだけではないかと。街の本屋が消滅してAmazon.comだけになったら、世の中つまらなくなるのではと。

でも、決してそうではないと、最近気づいた。単に不合理・非効率を排するだけでも、今までになかった喜びが現れる。

インターネットでしばしば本を買う。便利というのは麻薬で、インターネット通販サイトにはずいぶん貢いている。通販の便利さは実店舗に出向かなくても手元に本が欲しい時に手に入るだけではなかった。本棚を見ると、Amazonがもしなかったら絶対に読まなかったであろうし、認知すらしていなかった本が数多くある。冷静になって考えると、これはとんでもないことだ。私の人生は明らかにAmazonによって変えられている。

Amazonはインターネットを利用して物流と小売を効率的にしただけだ。インターネットそれ自体は、ただの通信網であって、そのものは何かを生み出したりはしない。それなのに、私は人生を変えられている。当たり前のようにそこにあったから、インターネットのすごさを忘れていた。非常に今さらながら、インターネットの可能性を再発見した。

ジェフ・ベゾスは、私に私が知らなかったような知識を与えて私の人生に影響しようとなんて、別に考えたわけではない。これが良いことだったかは知らないし、私が新しい本に出会ったことは社会に何の影響もないが、思わぬところで思わぬ効果があったわけだ。その事実が、無性に面白い。

アメリカの金持ちが、こんなに離れたところに住んでいる私の人生にかなり強く影響しているという事実に気づいたら、世界の見方が変わる。それを実現するインターネットのすごさよ。

企業はファイヤーウォールの内側にいて非効率なことをしているけれども、ファイヤーウォールをぶち破ってインターネットが企業内に進出し始めたら、革命的なことが起こるのではないかと思い始めた。実際そういう話が、最近私のアンテナによく引っかかる。社会の片隅にいる私の耳にまで聞こえるということは、もう爆発が起こる臨界点近くまで機運が高まっているのだろう。

ドリル/穴 問題について

所感

マーケティングの格言に

ドリルを買いに来た人が欲しいのはドリルではなく穴である。

というのがある。至言だ。この言葉にはいろいろ思うところがある。

言葉だけ聞くと当然のことである。道具なんて所詮道具だ。用途があって道具がある。用途がない道具はない。その道具があったら何ができるの?この問は道具を作るときにするべき本質的な問いかけだろう。

しかしながら、俺達が作っているのはドリルでなくて穴だなんていう発想をする人は実に少ない。企業には往々にして商品種別ごとの事業部がある。例えば、工具を作っている会社ならドリル事業部なるものがある。ドリル事業部なんてあったらドリルなるものが絶対的に存在していると思って、ドリルを作って売るという発想しかできない。ドリルって何に使うものなのかなど、考えもしない。

自動車メーカーの人に車の機能を聞いたら、「走る・曲がる・止まる」という人がいる。それは違うだろう。車の機能は、人や荷物をある場所から別の場所まで運ぶことだと私は思う。走る喜びとか・所有すると喜びとかもわからんではないので、それを機能に含むこともありうるかもしれない。だが、走る・曲がる・止まるは機能をつくる要素かもしれないが、それ自体は自動車の機能ではないと思う。走って・曲がって・止まるだけならラジコンでいいではないか。

「自分の作っているものがどう使われるかは分からない」という言葉は非常によく聞く。それを聞くたびに、ネガティブな感情が蓄積していく。

それでいて、もっとよく聞く言葉は「競合他社と比べて何が違うの?」である。機能が何かを分からないものの、機能要素について議論して一体なにの意味があろうか。何に使うのか分からないから、カタログスペックばかり気にするのだ。

ユーザーは、カタログスペック見て比較検討するのかもしれない。でも、ユーザーがカタログスペックだけ見ていると思っているなら、ユーザーのことを馬鹿にしすぎやしないか。売る方も馬鹿なら買う方も馬鹿なのか市場というのは?私は違うと信じている。

ヘンリー・フォードは言った:

もし顧客に、彼らの望むものを聞いたていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。

しかし、消費者が買ったのは自動車なのだ。

顧客の望むものを聞いてそれをそのまま作って、イノベーションのジレンマに陥っているのなら、まだましかもしれない。T型フォードがすでに発売していて、顧客はT型フォードが欲しいと言っていても、馬を売っていた連中は多分それに気付かないかそれを認めなかったのだろうと想像する。馬は忠誠心があるから車より優れているとか、意味不明なことを言っていたのではなかろうか(根拠はない)。それは何に使うのと考えたら、ほとんどの用途では自動車の方がいいに決まっている。

私は何に使うのか分からずに、ドリルなんて作りたくない。ものづくりなんて興味がない。ましてドリルそのものになんて、かけらも興味がない。私は社会に穴を提供したいのだ。ドリルの回転数とかアタッチメントの数とかどうでもいい。別にドリルがすぐに壊れるものであっても、顧客が欲しいのがたった一個の穴ならそれでいいではないか。別にそれなら穴ぐらい出向いて開けてやるよ。

プログラミングは「モノづくり」なのか?

所感 計算機

ソフトウェアを開発することを「モノづくり」と言う人が少なからずいる。これにすごく違和感があるのは私だけだろうか?

「モノづくり」ってよく分からない言葉だが、日本の製造業をポジティブに表現するために使う。すり合わせだとか高度な熟練技能だとか日本の製造業には優れたところがあって、そういう優位性は日本人の精神性によるものだという、よくある日本人論だ。製造業に別の言葉を当てるのは、お役所言葉っぽくて嫌いだが、まあよいとしよう。

しかし、プログラミングに「モノづくり」なんて言葉を適用されるとおかしくないかと思ってしまう。

プログラムは「モノづくり」でいうところの「モノ」なのか?例えば、脚本を執筆することを「モノづくり」というか――いわない。プログラムは著作物である。著作物は物理的な実体が伴わなくてもよいものだ。ハードディスクに保存して、ディスプレイに表示してもいいし、プリントアウトしても上に書かれた文字列には著作権がある。物理的実体が伴わないものが、工業製品と同じとは思えない。

しばしば「モノ」に対比されたものとして「コト」が言及される。プログラムはその対比でいうならコトの方だ。プログラムに記述されるのは業務プロセスであり、会社の仕組みやビジネスモデルそのものだ。*1

それに、「モノづくり」というと日本の産業が良い状態だというニュアンスを含む。日本のソフトウェア産業なんて、全くポジティブに評価していいものではないと思っている。「モノづくり」なんていうといかにも品質が高そうじゃないですか。品質を評価することは難しく、ハードデータもないのだが、これは疑っている。

「モノづくり」なら生産現場が散らからないように、現場で5Sをするのが現場監督の仕事のはずだ。しかし、生産現場が乱雑に散らかっているばかりか、製品自体もボンネットを開けたら配線がグチャグチャになってましたみたいな状態が多いのではないか。私はソフトウェアは「モノ」でないと思っているけれど、「モノ」っていうなら少なくとも「モノ」自体を見て、これがいいものだとか悪いものだとか、良くするためにはどうするのかとか考えるべきけれど、実際やられてないだろう。工業製品だったら全員が製品の現物(最低でも写真)を見る。ソフトウェアだとそれがなくなって、製品のカタログにはロゴしか書いてない。それがなんなのかすら分からない商品の多いこと。

「モノ」でないから、製造業の概念が適用できないかというと、そんなことはない。トヨタ生産方式の概念は適用可能だと思っている。「モノづくり」とか言っているわりに、本当の「モノづくり」の知見が全く参考にされていない。これが不思議だ。

*1:組み込みとかデバイスドライバとかは知らん

KdV方程式を解いてみた

計算機 手慰み

KdV方程式を数値的に解いてみた。*1

KdV方程式は、以下の式で表される方程式です。

f:id:fjkz:20160508115130p:plain

非線形偏微分方程式だけれども、手計算で頑張ることができて、よく研究されてきた方程式です。バーガース方程式と同様の非線形項に加えて、3回微分の項がある。この項は分散項と呼ばれている。

これを解いてみて、Zabusky と Kruskal による有名な報告と同じ結果が得られることを確認した。

Phys. Rev. Lett. 15, 240 (1965) - Interaction of "Solitons" in a Collisionless Plasma and the Recurrence of Initial States

コードは記事の最後に載せる。PythonでNumPyを使った。NumPyは計算も早く、forループもがなくなるので良いと思った。

空間の離散化には「擬スペクトル法」を用いた。擬スペクトル法というのは実空間と波数空間を行ったり来たりして、微分値を求める方法である。時間積分は4次の「ルンゲクッタ法」を使った。これは有名ですね。

つまり、無意味に高精度な計算をしている。

Zabusky と Kruskalが見つけたように、δ = 0.022のときに面白い動きをする。YouTubeに動画を上げた。


KdV equation

初期値にはcos波を与える。

f:id:fjkz:20160511193334p:plain

非線形項のために波が切り立って来る。

f:id:fjkz:20160511193431p:plain

波の先が崩れる。

f:id:fjkz:20160511193618p:plain

小さい波に別れる。

f:id:fjkz:20160511193722p:plain

伝播していく。

f:id:fjkz:20160511193829p:plainf:id:fjkz:20160511193942p:plain

波が重なりあうが、合体せずにいるようになる。

f:id:fjkz:20160511193942p:plain

この小さい波は「ソリトン」といって、かなり前に物理学界で流行ったらしい。動画を見ていると、いかにも力学的に意味がありげな動きをしていて面白い。


ソースコード

*1:先日の計算が誤っていたので再投稿

可読性に関するソフトウェアメトリクスを考えた

作業ノート 計算機 考察

新しいソフトウェアメトリクスを思いつきました。

ソフトウェアメトリクスとは、ソフトウェアの特性を推定するための定量値のことです。バグの数とかレビューの時間とか開発の過程で得られる値もありますし、テストの数だとかカバレージといったテストを評価する値もあります。ソースコード自体から測定されるものとしては、LOC (Line Of Code)やCyclomatic Complexityがよく知られています。それぞれ、ソースコードの規模・複雑さを示すものです。*1

近年では、ソフトウェアの特性としてソースコードの可読性が重要視されるようになっています。ソースコードは書く時間よりも読まれる時間の方が長い。読むための労力が少ないソースコードは、生産性を向上させ、バグも少なくなります。

可読性を高めるためには、適切な名付けやコメント、明快な処理のフローが必要です。名付けやコメントについては、数値化することは難しいのでフローの部分に焦点を当てて評価するメトリクスを考えました。

読みやすいコードというのは、読みやすい文章と一致しています。文章というのは必ず前の文を受けて次の文が続きます。唐突に前の文と関連がない文が現れていたら、それは文章としては成立していません。ソースコードも文章と同様に、前の文を受けて次の文が続くべきなのです。

ソースコードで、前の文を受けるというのは同じ変数を操作しているということです。前の文で操作した変数を次の文でも操作するようにすれば、文章のように前の文を受けて話を展開していく形になります。

しかし、プログラムでは前の文を受けないような記述もできてしまいます。ある行で操作した変数を離れた行で再び操作すると、前の操作を思い返さなければならないので、読みづらくなります。理想的には、ある行で操作する変数は、そこで最初に操作するか、直前の行で操作されているべきです。

そこで、「変数の使用される間隔の平均値」を可読性の指標としたらよいのではないかと考えました。関数やメソッド(ルーチンとよぶ)ごとに計算される値です。このメトリクスを仮に d として、d は以下で定義されます。

     1   L  n(l)
d = ―――  Σ   Σ  f(x,l)
     L  l=1 x=1


           0                 (変数 x が行 l で最初に操作された場合)
f(x,l) = {
           l - 前回変数xが操作された行 - 1 (変数 x が行 l 以前で操作されている場合)

ここで、

  • L : ルーチンの行数
  • l : ルーチン内の行番号
  • n(l) : 行lで操作される変数の数
  • x : 行lで操作される変数

となります。

d = 0 だとルーチンの可読性は理想的で、d の値が大きくなるほどそのルーチンは可読性が悪いということになります。

具体的なソースコードについて、d を計算し、d がどのような場合に大きくなるかというのは、次回に考えてみたい。

The Art of Readable Code (Theory in Practice)

The Art of Readable Code (Theory in Practice)