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

宇宙は究極のフリーランチ

マネジメント / 意思決定 / プログラミング

書評「企業内人材育成入門」

www.amazon.co.jp

  • 春なので新入社員がやってきた。
  • 人材育成についての本を読んだ。
  • 感想をメモする。

育成は専門技能である

  • この本は冒頭が面白い。
  • おおむね以下のような事が書いてある。
  • 誰もが被教育者としての経験を持つ。
  • そのため、教育について知っているかのような気になってしまうが、そのような認識は失敗を招く
    • サンプル数1の、被教育者としての経験などあてにならない。
    • 体系立った理論を学ぶ必要がある。

第1章

熟達化

2種類の熟達者

  • 定型化熟達者
    • 決まった手続きを早く正確に
  • 適応的熟達者
    • 手順が何もない課題を柔軟に確実に

あー、自分の場合は定型的熟達は苦手で、適応的熟達の方が得意だな…

熟達化によって起きる事

  1. 記憶力の向上
    • その領域について良く記憶できるようになる。
  2. 下位技能の自動化
    • 特に意識しなくてもスッとやれるようになる。
  3. 問題の直感的把握
    • 他の人が気づかない問題にすぐ気づけるようになる。

あるあるww

第3章

動機付け理論

「成功や失敗を左右しているものは何か」

「成功や失敗を左右しているものは何か」
この答えが「外的な要因」では無く「内的な要因(自らの行動による結果)」であると感じられる場合に動機づけが高まる。(「統制の所在と呼ばれる概念」)

この概念良い。この概念によって、いろんな事が説明できる。

  1. 人から与えられた答えではなく、自分で出した答えにもとづいて行動する必要がある
    • だからティーチングでは無く、コーチングが必要になる
  2. ガバナンスが強く効いた大企業より、裁量が大きいベンチャーの方が成長できる
    • 動機付けしやすいから
  3. 「成功 → 裁量が増える → 動機付けが高まる → より大きな成功」という現象が起きる理由。

結果をコントロールできる事を認知

  • 結果をコントロールできる事を認知出来た方が動機づけが高まる。

ああ、だから、楽勝な課題でも不可能な課題でもなく、一定のボラティリティがある課題が必要なのか。それがストレッチ目標か。

「能力は変化する」という感覚

  • 「能力は変化する」という感覚がある方が動機づけが高まる。

フロー理論

  • 心地よく強い集中。没入感。
  • これまでの動機付けについての理論が「人は何によって動機付けられるか」を中心にした物であったのに対して、フロー理論は「人が動機づけられるとどのような状態になるか」を視点に加えた理論である。
  • こういう状態になるとフロー状態になる。
    • 行為と意識の融合
    • 限定された刺激領域への、注意集中
    • 自我の喪失・忘却、自我意識の喪失
      • 集中しすぎて自我が無くなる
    • 自分の行為が環境を支配しているという感覚
    • 首尾一貫した矛盾のない行為を必要とし、フィードバックが明瞭。全体のステップが明瞭。
    • 自己目的的な性質
      • やってることそれ自体が楽しい

OJTの中でフロー状態に入ってもらう事を目指すとしたら、「課題を絞る」「フィードバックを明瞭に行う」「全体像を示す」と言った工夫ができそうだな。

第7章

修羅場

  • 修羅場は成長のチャンスであると同時に、挫折の危機である。

はい

これについては、この記事が参考になるかも知れない。

「自分を飛躍的に成長させる状況」と「自分が潰されてしまう状況」の見分け方 - 分裂勘違い君劇場

第8章

「企業教育の政治力学」

  • 正しさは相対的で、それを評価する人に依存する。

はい

全体を通して

  • 全体的に薄く広くという感じなので、一つ一つのモデルに対してしっかりと納得を得る事は難しかった。
  • しかし、そもそも存在すら知らない物が多かったので大いに参考になった。
  • また、新入社員の育成のためにこの本を読んだが、ここで述べられているような、学習動機付けなどのものは、決して新入社員だけが行えば良い物ではない。全員が行うべきものであると感じた。
  • 動機付け関連の理論は、ソーシャルゲーム開発にも役立ちそう。

新入社員の育成: 答えではなく問いを与えるべき

この記事はなに?

新入社員の育成を担当しているあなたに取って何かの参考になるかも知れない何かです。

  • 現在自分は、とあるプロダクトで、エンジニア兼マネージャーとして働いている。
  • この春から現行のメンバーに加えて、新入社員がチームにジョインする事になった。
  • 私は、新入社員やその他のマネージメントの対象の方々がより良い成果を上げられる方法を探している。
  • そういう背景の中で、この本を読んで感じた事を整理せずにアウトプットした物がこの記事。

www.amazon.co.jp

構成

  • 長い前置きの後に、この本を読んで気に留まった部分の抜粋が出てくる。
  • 何かについて明確な結論は書いていない。思った事をそのまま書いてある。

全員が何らかの第一人者

1つのプロダクトを作るためには、本当に幅広い領域の知識やスキルが必要になる。

おそらくこの原因は、何か特定の狭い領域についての知識だけで作れるプロダクトやサービスは開拓されつくしてしまっていて、コモディティと化してしまい、複数の幅広い領域の知識やスキルの合わせ技をもって作ったプロダクトだけが付加価値を生めるようになった事だと思う。

そういうった環境の中では、チームのメンバー全員が何か特定の領域*1についての第一人者である場合が多いし、そうなるようにしていく必要がある。

マネージャーが行えない意思決定を行うメンバー達

全員が何かの第一人者である時、一人ひとりのメンバーは、マネージャーが意思決定できない事について意思決定を行う事になる。

答えは与えられない

ドラッカーが面白いたとえ話をしている。

それは「ベトナムのジャングルにおける若い歩兵大尉へのインタビュー」として紹介されている、次のようなエピソードである。

「この混乱した状況でどう指揮しているか」との質問に対する答えがこうだった。「ここでは、責任者は私である。しかし部下がジャングルで敵と遭遇し、どうしてよいかわからなくとも、何もしてやれない。私の仕事は、そうした場合どうしたらよいかを予め教えておくことだ。実際にどうするかは状況次第である。その状況は彼らにしか判断できない。責任は私にある。だが、どうするかを決められるのはその場にいる者だけだ」
Amazon.co.jp: ドラッカー名著集1 経営者の条件 電子書籍: P F ドラッカー, 上田 惇生: Kindleストア

マネージャーはメンバーの代わりに意思決定する事はできないし、すべきではない。

彼(彼女)が答えを出せるようにするには

答えを与えられない状況でマネージャーがメンバーするべきことはなんだろうか。
それは「与えられない答えを与えようとするのではなく、彼(彼女)自身が答えを出せるようにする」という事だと思う。

どうすればそのような事が出来るのか。
それはとても難しい問題だ。

「3分間コーチ」の感想

さて、以上でとても長い前置きがおわり「3分間コーチ」の感想が始まる。
この本は、コーチングについての本だ。

コーチングとは何かという事については検索して欲しい。
私は、ティーチングとコーチングの違いについて以下のように解釈している。

  • ティーチング:「私の持つ全ての能力を彼(彼女)に伝える」 を目指す。
  • コーチング:「彼(彼女)が持つ全ての能力を私が引き出す」を目指す。

もちろん、私が知っている事の全てを伝えても彼(彼女)は答えを出す事はできない。必要なのはコーチングの考え方だ。

「3分間コーチ」はコーチングについての理論的な背景や体系だった説明よりも、それをいかに実践するかに重きをおいた本だ。

私も内容を咀嚼する事が出来ていないので気に留まった点を箇条書きしていく事にする。

  • 部下について考える。部下と話す。
    • 半期に一度の目標面談では遅すぎる。3分で良いので頻繁にコミュニケーションを取る。
    • 「部下の方から「マネージャー」と声をかけてきたときには、しまったと思うそうです。なぜ彼の様子にもっと早く気づいてやれなかったのかと」
  • 会話の中で問いを共有する。その問いが部下の頭の中に残り、その答えを探したり、いろいろと発想を展開していく<セルフトーク>が重要。
    • 3分間の会話から、次回の会話までのこそが重要。
    • 問うことが新たな視点をもたらす。
    • 未来について聞く。
    • 答えを強要しない。クローズドクエッションをしない。
  • 良い行動を行ったら承認する。褒めるのでは無く純粋に事実として伝える。
    • 承認することで方向付けを行う。
    • (指示では無く方向付けを行うというのが重要なのかも知れない)
    • 相手に現れている変化や成長、成果にいち早く気付き、それを言語化する。

もっとも面白いと思ったのは 会話の中で問いを共有する。その問いが部下の頭の中に残り、その答えを探したり、いろいろと発想を展開していく<セルフトーク>が重要。 という部分である。確かに過去に優秀なマネージャーから良い問いを発せられて、セルフトークが行われ、今までに無かった視点が持てたと感じられた経験がある。

  • どうして、良い問い掛けを受けると思考がはかどるのか。
  • 思考をはかどらせるにはどのような問いをすべきなのか。

という点については自分の中で整理がついては居ないが、「答えを与えようとするのではなくセルフトークをうながす問いかけをする」 という事が重要なのでは無いかという仮説を得た事がこの本を読んだ成果の1つだったと思う。

今後、実践の中でこの仮説を検証したり、なぜそうなるのか体系だったモデルが組み立てられるように本を読みあさっていく。

関連記事

ジャングルと権限委譲 - 宇宙は究極のフリーランチ

*1:もちろん、その人が持つ能力によって専門性を発揮できる領域が狭かったり広かったりしたり、ある程度メンバー同士で領域にオーバーラップしている部分はある

アプリケーションエンジニアが初めてserverspecに触ってみた

テストコードによるインフラのテスト

serverspecはインフラの構築状況に対してテストコードによるテストを行うgemだ。
packageのインストール状況、serviceの起動状況、ポートの開放状況などの各種設定状況を、 rspecの文法でテストできる

f:id:Shinya_131:20150301212949p:plain

このserverspecと、サーバー構築自動化ツール(itamaeとか)を組み合わせて 環境構築をテストファーストで行う TDI( = Test Driven Infrastructure = テスト駆動インフラ)などのコンセプトが登場しており大変興味深い。

個人の開発環境整備に使えないか

もちろんserverspecを使って個人の開発環境をテストする事が可能なようだ。

今回は、実現したい明確な目的があるわけでは無いが、 とりあえずこんな事に役立つかどうか知るために試しに触ってみた。

自身の開発環境構築

  • 自分の開発環境をコマンド1つで、0から自動で構築できたら便利そう。
  • まずは、正しく構築できたか?serverspecでテストしてみたい。

チームメンバーの開発環境構築

インストール

gem install serverspec

init

serverspec-initを実行するとテンプレートファイルを生成してくれる。

$ serverspec-init
Select OS type:

1) UN*X
2) Windows

Select number: 1

Select a backend type:

1) SSH
2) Exec (local)

Select number: 2

+ spec/
+ spec/localhost/
+ spec/localhost/sample_spec.rb
+ spec/spec_helper.rb
+ Rakefile
+ .rspec
  • sshを選ぶとリモートホストに対してテストが行えるんだろう。今回はlocalを選択。

テストコード

  • 書く。
# spec/localhost/sample_spec.rb
require 'spec_helper'

# middleware
describe package("mysql") do
  it { should be_installed }
end

describe package("redis") do
  it { should be_installed }
end

describe package('rbenv') do
  it { should be_installed }
end

describe package('rails') do
  it { should be_installed.by('gem') }
end

# VCS
describe package('git') do
  it { should be_installed }
end

describe package('tig') do
  it { should be_installed }
end

# development tools
describe package('pry') do
  it { should be_installed.by('gem') }
end

describe command "ls /Applications | grep -q Atom" do
  its(:exit_status) { should eq 0 }
end

describe command "ls /Applications | grep -q Xcode" do
  its(:exit_status) { should eq 0 }
end

実行

$ rake
/Users/nagai_shinya/.rbenv/versions/2.1.0/bin/ruby -I/Users/nagai_shinya/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/rspec-support-3.2.1/lib:/Users/nagai_shinya/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/rspec-core-3.2.0/lib /Users/nagai_shinya/.rbenv/versions/2.1.0/lib/ruby/gems/2.1.0/gems/rspec-core-3.2.0/exe/rspec --pattern spec/localhost/\*_spec.rb

Package "mysql"
should be installed

Package "redis"
should be installed

Package "rbenv"
should be installed

Package "rails"
should be installed

Package "git"
should be installed

Package "tig"
should be installed

Package "pry"
should be installed

Command "ls /Applications | grep -q Atom"
exit_status
should eq 0

Command "ls /Applications | grep -q Xcode"
exit_status
should eq 0

Finished in 2.47 seconds (files took 1.06 seconds to load)
9 examples, 0 failures

感想

  • 便利そう。
  • とりあえず各種packageのインストールが簡単にテスト出来た。
  • インフラはアプリケーションに比べて内部状態が少ないし、 外部APIが絡むケースも少ないので、シンプルなテストコードだけで済む場合が多い印象。
    • MockとかStubとか使わなくて良さそう。
    • #setupすらあまり使わないかも。
    • テストファーストの入門としては、TDDよりTDIの方が入りやすいかもしれない。

あとで調べる

  • インストールされたpackageのバージョンをテストする方法。
  • Applicationsへのインストールをテストする方法。
    • custom matcherを書けば良さそう。

実際どういうコマンドが実行されているのか気になる。

  • 失敗するテストを書けば分かるという気付きがあった。

例:

存在しないpackage名を指定してみる
describe package('pryyyyyyy') do
  it { should be_installed.by('gem') }
end
結果:
Failures:

1) Package "pryyyyyyy" should be installed
On host `localhost'
Failure/Error: it { should be_installed.by('gem') }
expected Package "pryyyyyyy" to be installed
/bin/sh -c gem\ list\ --local\ \|\ grep\ -iw\ --\ \\\^pryyyyyyy

# ./spec/localhost/sample_spec.rb:31:in `block (2 levels) in <top (required)>'

/bin/sh -c gem\ list\ --local\ \|\ grep\ -iw\ --\ \\\^pryyyyyyy というコードでテストを行っている事が分かる。

今日はここまで。

価値のある技術文書を書くためには読み手の想定を立てるべき

この記事はなに?

現在、私は「社内で、カジュアルに、技術情報やその他ノウハウを共有するにあたって、 より価値がある情報を発信する技術」の情報を集めています。

その動機は以下です。

  • 去年入社した新入社員にそう言うスキルを高めてもらって、有用な情報をもっと発信してもらいたい。
  • ついでに自分もそう言うスキルを高めたい。

その中で見つけた以下の本が役に立つ内容だったので、自分なりの視点を交えて紹介します。

というか、この本から得た気付きをきっかけに、普段自分が文書を書く時に考えている事を主張します。 (なので、本の内容とはかなり乖離した記事になっています。)

はじめに

この記事では以下の主張を行います。

  • 技術文書は、読み手が必要としている情報を書くべき。また、そのためには読み手がどのような人なのか想定する必要がある。

これ以降の章で、「なぜそのようにすべきかという理由」と、「どうすればそように出来るかという自分なりの方法の紹介」をします。

技術文書は読み手が必要としている情報を書くべき

技術文書を書く時に重要な事の1つとして、

  • 書き手が書きたい事ではなく、読み手が必要としている情報を書くべき

という点があります。

いくら書き手が満足しても、読み手が必要としてる情報を手に入れられなければ価値は生まれないためです。

とは言え、いくら読み手が必要としていても、書けない情報は書けないので、こういうエリアの情報を書いていく事が必要になります。

f:id:Shinya_131:20150215195428p:plain

以下で、その方法を紹介します。

まず想定読者が必要

読み手が必要としている情報を書くのにあたって、 まず読み手を想定する 事が重要です。

例えば あるプログラミング言語の解説について、「文法もおぼつかない初心者」から「その言語のコミッターのような上級者」にまで全員に価値を提供できる文書をつくるのは困難です。

  • 初心者にとって役に立つ情報は、上級者にとってはもう知ってる情報ですし、
  • 上級者にとって役に立つ情報は、初級者にとっては理解不能だからです。

あらゆる人間を対象にした文書は誰にも適切な情報を提供できません。
想定読者を設定して対象を絞れば、より適切な情報を提供できます。

読み手のニーズと書き手のシーズをすり合わせる

読み手が必要としている情報を書くには、文書を書く前の段階での工夫が必要です。
つまり、 「そもそも何について文書を書くか」 と考えている段階での工夫です。

私は、 「そもそも何について文書を書くか」を考える時に以下のどちらかの出発点から始めます。

    1. 「書き手が提供できる情報」を出発点にする。
    1. 「読み手」を出発点にする。

必要なアプローチはa.とb.とで異なるので、以下の章で分けて解説していきます。

「書き手が提供できる情報」を出発点にした場合

「書き手が提供できる情報」を出発点にした場合、以下の質問のどちらか(または両方)を自問自答してみます。

  • 「この情報を知って一番役に立つのはどんな人か?」
  • 「この情報を知らなければいけないのはどんな人か?」

この質問への答えを、想定読者として設定する事が出来ます。

例1

手前味噌になってしまうのですが、以前自分が書いた記事を例に解説してみます。

この記事の場合は、まず

  • 「rubyが持つ、オープンクラス/すべてがオブジェクト/ダックタイピングって特性面白いよな。解説したら誰かの役に立つんじゃないかな」

という「書き手が提供できる情報」が出発点になっています。

想定読者を設定するために、以下の質問を自問自答してみました。

  • 「この情報を知って一番役に立つのはどんな人か?」

この記事の場合は、以下のような人に役立ちそうだと考えました。

「rubyに触れたことがあって、rubyの文法は理解しているけど、 オープンクラス/すべてがオブジェクト/ダックタイピングのようなruby特徴的な挙動を理解していない人 」

これが想定読者になります。

例2

例えば仮に、運営中のサービスでトラブルが発生し、トラブルの原因を突き止め、再発防止策を実施したのなら、

  • 「この情報を知らなければいけないのはどんな人か?」

と、自問してみて、

「このサービスを担当しているエンジニア全員と、自社内の類似サービスを担当しているエンジニア全員」

という答えが出たなら、それを対象読者として設定する。と言った事ができます。

「書き手が書ける情報」を出発点にした場合は、 「書き手が書ける情報」は固定したまま、それに合う対象読者を探していくという事です。

「読み手」を出発点にして書くには?

読み手が最初から明らかな場合もあります。
ある誰かが抱える課題を解決するような情報のアウトプットが必要な場合などです。

この場合は以下を自問自答します。

  • 「この想定読者にとって一番役に立つ情報は何か?」
  • 「この想定読者が知らなければならない情報は何か?」

この答えが「読み手が必要としている情報」です。

  • 「デザイナーさんに、Gitを使って画像やマークアップ、アニメーションなどのリソースをpushしてもらいたい。 そのためにGitの使い方を説明する文書を書きたい」

この場合は、

  • 「この想定読者にとって一番役に立つ情報は何か?」
  • 「この想定読者が知らなければならない情報は何か?」

を自問して、

Gitの操作方法や、注意点といった情報、また、リポジトリの運用ルール

と言った情報が「読み手が必要としている情報」である事が分かります。

「読み手が必要としている情報」を出発点にする場合には、 「読み手が必要としている情報」は固定したまま、それに合う情報を探していくという事です。

文書を書く時の自問自答

さて、ここまでで、「そもそも文書に何を書くべきか」と「対象読者の設定の仕方」について主張しました。

ここで、「対象読者の設定」と「何を書くか」が決まった後、実際に文書を書く時に自分が使っている自問自答集を紹介します。

  • 「対象読者がすでに知って、はぶくべき情報は何か?」
  • 「対象読者がまだ知らない、説明が必要な情報は何か?」
  • 「この情報は、対象読者にどんな風に役に立つか?」
  • 「どんな効能を説明すれば、対象読者が興味を示してくれるか?」
    • 対象読者に文書を読んでもらうために、何の役に立つ文書なのか、文書の冒頭でしめします。
  • 「対象読者以外に対して、『あなたは対象読者ではない』と示すために何を書いておくべきか?」
    • 対象読者以外の人が文書を読んだ時、文書の冒頭で「自分は対象読者では無い」という事に気づけるようになっていれば、その人の時間を無駄にせずにすみます。

まとめ

f:id:Shinya_131:20150215195428p:plain

  • この図で、赤と青が重なっている部分について情報を発信すると価値があります。
  • あらゆる人間を対象にした文書は、誰の役にも立ちません。対象読者を絞る必要があります。
  • 「書き手が提供できる情報」を出発点に文書を書く場合は、「誰に届けたら一番価値がでるか?」を考えます。
  • 「読み手」を出発点に文書を書く場合は、「何を届けたら一番価値がでるか?」を考えます。

株価の値動きをかなり雑にモデリングしてrubyで実装した

2015/02/15追記: 以下の記事の内容は正しくありません。 以下の記事では私の勘で適当に株価の値動きモデルを考えて見ていたのですが、記事を書き終わった後に、実際に使われているモデルについて調べてみたところ、やはり私の適当なモデルは大いに誤っていると言う事が理解できました。興味がある方は「効率的市場仮説」 などのワードをお調べください。特に記事中の「株価に働く慣性の力と周波」については「効率的市場仮説 ウィーク型」として否定されている性質であると言う事が分かり、これはこれで勉強になりました・・・

ここまでのあらすじ

haskellの勉強のために、証券価格(株価とか)の値動きデータが欲しい。
しかし、インターネット上から入手できるデータは何かと制限が多い。

別に実際に証券取引や価格予測をしたい訳では無いので擬似的なデータで良い。
そこで、株価の値動きみたいな数列を擬似的に生成するプログラムをrubyで書いてみた。

なお、私は証券取引について何の専門知識も持っていない
生成の方法は完全にによるものなので注意していただきたい。

結果

最初に、これからこの記事で説明する方法によって得られる擬似値動きデータの一例を以下に示す。

なかなかそれっぽく見える。(と自分では思っている; )
この記事ではこのデータを生成した方法を説明していく。

f:id:Shinya_131:20141214211824p:plain

株価の値動きの構成要素を理解・分解・再構築

長期的な傾向/短期的な傾向

さて、株価の値動きらしき数列を生成するにあたって、
株価がどのような法則によって値動きを行うのか考えてみる。

その上で役に立ったのが、 テクニカルトレーディングの代表的な指標であるゴールデンクロス / デッドクロス という概念である。

移動平均#ゴールデンクロス(GC)とデッドクロス(DC)-- wikipedia

この指標は以下のように売り/買いのシグナルを発する。

長期的な値動きの傾向をあらわす長期移動平均線と、
短期的な値動きの傾向をあらわす短期移動平均線とが交わったタイミングが 売り(または買い)に最適なタイミングである

つまり、

  • 長期的に上がってる株が、短期的に値下がりしていれば買い時 (きっと買ったあと上がる!)
  • 長期的に下がっている株が、短期的に値上がりしていれば売りどき (きっと売らないと下がる!)

という訳である。

さて、この事から、ひらめきというか発見があった。

  • 株価は長期的な値上がり/値下がり傾向と、
  • 短期的な値上がり/値下がり傾向とを持つ

という事である。
ここで改めて株価の値動きグラフを見てみる。

google画像検索: 「株価 値動き」

確かに、そう思って見てみるとそのように見える。
この傾向は移動平均線付きのグラフで見てみるとより顕著だ。

google画像検索: 「株価 値動き 移動平均線」


株価に働く慣性の力と周波

また、一度上昇した株価は、その後下落するし、
ある程度下落した株価は、その後上昇しているように見える。

周波 があるように見える。

おそらく、このような法則が働いているのでは無いか?

1. 一度値上がりしはじめた株価は、上昇し続ける力が働く

値上がりする株は、さらに人気となり値上がりを続ける。
("株価に働く慣性の力"と勝手に名づけた)

2. 株価がある一定のラインを超えると、今度は株価が下落する

株価が上昇しつづけ、その時点の適正な価格を一定以上超えると、
下落が始まり1.と逆方向の力により値下がり続ける。

3. 株価がある一定のラインを下回ると、再び上昇し始め、1.に戻る

株価が下落しつづけ、その時点の適正な価格を一定以上下回ると、
上昇がはじまり1.に戻る。

このようにして 周波 が生まれるのでは無いか?


波長が異なる複数の周波

そして、2.で言うところの「適正な価格」が、

  • 長期的視点では、投資対象企業の実質的価値
  • 短期的視点では、株価の長期的な値動き(トレンド)

で決まる事により、波長の違う複数の周波が現れるのでは無いか?
これが株価が長期的な値上がり/値下がり傾向と、 短期的な値上がり/値下がり傾向を持つ原因ではないか? と考えた。

分解

株価を構成する法則

ここまでの考察により、私は株価の値動きについて以下のような仮説を立てた。

1. 株価は上昇と下降を一定周期で繰り返す(周波)。
2. 波長の違う複数の周波の組み合わさった物が株価である。

さて、このモデルによって擬似的な株価を生成してみよう。


ちなみにこのモデルでは、株価の暴落、暴沸について全然説明出来ないし、
波長の異なる周波数の組み合わせと言っても、どんな形のどんな波長の波で構成されるのか 全然考察されていない。
それどころか、株価のランダム性も全く説明出来ない。
こんな単純なモデルで株価が生成されていたら、株価の完全な予想が可能になってしまう

と、まあ、ハイパー穴だらけモデルであるが、
もともとhaskellでテクニカルトレード指数を計算するプログラムを書くときに、 (そもそもそれだってhaskellの学習のためなのだ!) 転載禁止などの制限が全くなくて、Webサイトからのスクレイピングなどのだるい作業を行わずにデータを用意するための物なのでかまわないのだ。

再構築

さて、上記のモデルにより株価を生成するプログラムを書く。
haskellで書きたい所だがまだ慣れないので使い慣れたrubyで書く。

実装の概要

このプログラムは、以下の3種類の波形を生成できる。
そしてこれらの要素を足しあわせて擬似株価を生成する。

長期周波

f:id:Shinya_131:20141214212938p:plain

短期周波

f:id:Shinya_131:20141214212953p:plain

ランダム要素

f:id:Shinya_131:20141214213011p:plain

このような要素は先ほどのモデルには出てこなかったが ランダム性が無い株価は明らかに不自然なので足しておく ; )

合成

以上を組み合わせて以下のようなデータが得られる。
どうだろうか…? まあまあそれっぽい。

f:id:Shinya_131:20141214213038p:plain

実装

実装を以下に示す。上に書いてある事がプログラムで実行されているだけである。
なお、周波数の幅、高さ、波形などはそれっぽく見えるように恣意的に設定している(;´Д`)

class PriceMovementDummy
  def initialize
    # 生成する値動きの期間
    @steps = 1..100 # 1..100なら、100回分の値動きを生成

    # 長期周波の設定
    @wave_width_coefficient = 15.0 # 波長を決める係数
    @long_wave_scale = 20 # 波高を決める係数

    # 短期周波の設定
    @short_wave_width_coefficient = (15.0 * 0.25) # 波長を決める係数
    @short_wave_scale = 10 # 波高を決める係数

    # マイクロな値動き要因の設定
    @micro_factor_scale = 10
  end

  # 生成
  def generat
    price_move = @steps.map{|step| price(step) }
    to_positive(price_move)
  end

  private

  # ある時点の株価
  def price(step)
    long_wave(step) + showt_wave(step) + micro_factor
  end

  # ある時点の波高を求める(長期周波要因)
  def long_wave(step)
    Math.sin(step / @wave_width_coefficient) * @long_wave_scale
  end

  # ある時点の波高を求める(短期周波要因)
  def showt_wave(step)
    Math.sin(step / @short_wave_width_coefficient) * @short_wave_scale
  end

  # ある時点の波高を求める(ランダム要因)
  def micro_factor
    rand(1..@micro_factor_scale)
  end

  # グラフ全体が正の数になるように切片を加算
  def to_positive(number_list)
    return number_list unless number_list.min < 0

    number_list.map{|i| i + number_list.min.abs }
  end
end

price_movement = PriceMovementDummy.new.generat
p price_movement
#=> [21.327959399617633, 22.654385953596055, 23.969000117050996,...] # ウェーイという感じで100回分の値動きが出力される

まとめと感想

非常に適当ではあるが株価の値動きについてモデリングを行い、それっぽいデータを生成する事ができた。

「株価がどのようなモデルで決定するのか」というテーマについては金融関係の企業や大学などで、 のように研究されている事と思う。

今回はそれらの研究を全く参照せずに素人の勘でやったが、 それらの機関が出している論文などを読んでもう少し理解を深めたいと思った。
(重要な研究成果は公開されていないだろうが、ごく初歩的な情報だけでも、 私の知らない知識でぎっしりに違いない)

また、このテーマに取り組むにあたって、実際の株価とこのモデルの乖離度を定量的に測りたい。という気持ちが湧いてきた。 これについては、そのような事が可能かどうかなのかすら分からないが気が向いたら調べてみたい。

ruby使いがhaskellでhello word

haskellにちょっと興味が出てきた。 新しいコンセプトや考え方を学ぶのは面白い。

今日はhaskellでhello wordをしてみる。

環境構築

$ brew install ghc

brewで簡単にインストールできた。
ちなみに環境はMac OSである。

ghcとはhaskellのコンパイラである。
他にもいくつかの処理系があるようだがどうやらこのghcというやつがスタンダードなようだ。

ghcにはGHCiというhaskellの対話的実行環境が付属してくる。
これはrubyで言うところのirbみたいなものだ。

gchiコマンドで起動できる

$ ghci
GHCi, version 7.8.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude>

hello worldをしてみる。
まだ特に驚くべき所は無い。

Prelude> print "hello world"
"hello world"

次に進む前に、対話的実行環境では無く、 実行ファイルを生成してからコードを実行する方法を試してみる。

まずGHCiを終了させる。

Prelude> :quit
Leaving GHCi.

:quitでghciを終了できる。
:で始まる文字列は、haskellのコードでは無く、ghciへのコマンドのようだ。

次に、先ほどのhello worldをファイルに書いてそこから実行してみる。

$ ghc -o hello_haskell hello_haskell.hs # コンパイル
[1 of 1] Compiling Main             ( hello_haskell.hs, hello_haskell.o )
Linking hello_haskell ...
% ./hello_haskell # 実行
"hello haskell"

コンパイルして実行するのに、2回コマンドを打つ必要があり面倒である。

$ ghc -o hello_haskell hello_haskell.hs && ./hello_haskell
"hello haskell"

とりあえず、このようにしている。


次に、よくhaskellのコードサンプルとして登場してくる階乗の計算を実装してみる。

factorial 0 = 1
factorial n = n * factorial (n - 1)

main = do
  print (factorial 5)

これは5の階乗を計算するhaskellのコードである。
注目した点が2つある。

パターンマッチ

factorialというキーワードが1行目と2行目の先頭に登場している。
これは関数名であり、この2行は関数の定義を行っている。

なぜ同じ関数が2箇所に渡って定義されるのか?

このような書き方はパターンマッチと呼ばれる。

  • もし、factorialの引数が0であれば、1行目のfactorialの処理が、
  • もし、factorialの引数が上記の条件に当てはまらなければ、2行目のfactorialが実行される

C++などだと、引数の型が異なる同じ名前の関数を複数定義できるが、
この場合は、引数のが異なる同じ名前の関数を複数定義している事になる。

繰り返し処理を再帰として表現

再帰自体はhaskellに限った機能では無い。
しかし、haskellのサンプルコードでは再帰が多用されているようである。

haskellが持つその他の特徴と再帰の相性が良いのかも知れない。
(まだ良く分からない)


とりあえず今回はここまで。
恐らくだが、この言語は数列に対する処理とか、数式の表現とかに向いていそうである。

例えば、金融商品の値動きデータは長さ無限の数列とみなす事もできるだろう。
遅延評価を備えていて、無限の数列を扱え、数式の表現にも強そうなhaskellならこ ういうジャンルに向いていそうである。

前工程からはpullし、後工程にはpushする

例えば、企画とデザインが行われたものを自分が実装し、QA(品質保証)にテストを行ってもらう仕事をするような場合、以下の点に気をつける。

  • 前工程の成果物はpullしてくる
  • 後工程には成果物をpushする

具体的には、

前工程(企画やデザイン)に対して:
  • 進捗状況はどうか?
    • あらかじめ相談していた期限に間に合いそうか?
  • 成果物について認識は一致しているか?
    • どんな形式の何をアウトプットとして受け取る予定か?
    • 不足物は無いか?
    • 代表的なユーザーが得る体験だけでなく、例外的なユーザーが得る体験についても設計されているか?
後工程(QA)に対して:
  • 渡した成果物はテストされているか?
    • テストに支障をきたすようなトラブルは起きていないか
    • テスト内容は適切か?

と、言った事に気をつけるようにしている。


「そもそも、各工程に対して各々の担当者が責任を果たすべきだ。各工程の担当者が責任を果たせばそのようなコミュニケーションは不要だ」

という意見もあるだろう。
そのような意見は正論かも知れないが、価値を産まない考え方だと私は思う。

工程の一箇所だけうまく行っても他で失敗すれば価値は生まれないのである。
私は、工程を終わらせる事では無く、価値を作る事にコミットして行きたいし、していく必要があると考える。

理論が美しいかどうか、スマートかどうかは重要ではない。実験に一致しないなら、それは間違っている。
「Rubyのしくみ」より

価値を産まないなら、それは間違っている!!

スキルについて: 領域に対するポータビリティ/時間に対するポータビリティ

「ポータビリティスキル」と言う概念がある。

一言で言うと「ポータビリティがあるスキル」というのは「転職しても使えるスキル」という意味らしい。

  • 例えば、「ある決済権限者Aさんを説得する技術」はポータビリティが無いスキルである。(余談: しかし! このようなスキルが役に立つケースは実際あるのだ! )
  • 一方、例えば「Ruby on Rialsを使って安全で高速なWebアプリケーションを作るスキル」は「Webアプリケーションを作る」という領域(ドメイン)に属する会社内であればすぐに役立つスキルと言える。ポータビリティがあるスキルである。

このように、特定の領域内で広く使える(結果として、転職しても使える)スキルの事を、「領域に対するポータビリティを持ったスキル」と呼ぼう。

さて、このポータビリティという概念だが、時間軸に対しても適用できるのでは無いだろうか?

時間に対するポータビリティを持ったスキル。つまり、長い時を経ても通用するスキルである。

例えば、こういうのがそうだろう。

時間に対してのポータビリティを持ったスキルと、今すぐ役に立つスキル、バランス良く身につけていきたいものである。


ところで、領域に対しても時間に対しても非常に強いポータビリティを持ったスキルがある。それは「現実をモデルに落としこむ(モデリングを行う)スキル」である。

このスキルはあらゆる問題の解決に役に立つ上に、科学の創世記から現在に至るまで全く陳腐化していない。

この究極のスキルをどうにかして極めたい物である。

読了「エッセンシャル思考」

この本を読んだ感想を書く。


ドラッカーはかつてこのように言った。

誰にとっても優先順位の決定は難しくない。難しいのは劣等順位の決定。つまり、なすべきでないことの決定である。
ドラッカー「経営者の条件」

この事を理解し、常に実践出来ている人にとって、この本はあまり価値が高く無いだろう。


この本の内容を一言に要約するとこのようになる。

ボトルネックに対する投資だけが価値を持つ。それ以外への投資は無駄である。だからボトルネック以外に対する全ての投資をやめよ。そしてその原則をすべての行動に対して適用せよ」

エッセンシャル「思考」と書いてあるが、この本の大半は、上記の考え方を実践するための「心構え」だったりとか「具体的な行動方法」だったりが占めている。

自己啓発的な内容である。

私は、捨てる事が苦手である。
だからこの本は私にとって価値が高かった。

ボトルネック以外への投資をやめられない人にはおすすめしたい書籍である。


ところで、この本と似た主張を行う本がある。

この本である。

この本を一言に要約するとこうである。

「貴方ををときめかせる品物だけが価値を持つ。それ以外はすべて不要品である。だから貴方をときめかせる品物以外の全てを捨てよ。そしてその原則を服に、本に、写真に、全ての持ち物に適用せよ」

そっくりである。
「エッセンシャル思考」が気に入った人には「片づけの魔法」を、
「片づけの魔法」が気に入った人には「エッセンシャル思考」をおすすめしたい。