「丸投げ」と「任せる」の違い（"部下を持ったら必ず読む「任せ方」の教科書"読書メモ）

仕事を任せるのって難しい

皆さんこんばんは。 突然ですが、皆さん自分の部下にどのように仕事を振っていますか？　方法としては、色々あると思います。

• やるべき事の手順を伝える？
• 欲しい成果物を伝える？
• 仕事の発生した背景を伝える？

かく言う自分は会社では一人部署なので、これまで悩む事も無かったのですが、 最近は自分ディレクションで社外に仕事をお願いしたりもしているので、多少考えたりもします。

実際、社内を見ているとトラブルが多く、 特にクリエイティブな仕事では任せ方が難しいようです。

もっとも、今日においてクリエイティブ"でない"仕事の価値は激減しており、現代の仕事とは総じてクリエイティブであると思っています。なので、別にうちがゲームを作っているから特段クリエイティブな仕事をしている、という考えも間違いでしょう。……という議論は本題ではないので今日はここで打ち切り。

そんな訳で、仕事を「任せる」方法論について、さっとgoogle先生とamazon書評から選んだのがこちら。

部下を持ったら必ず読む　「任せ方」の教科書　「プレーイング・マネージャー」になってはいけない (角川書店単行本)

ライフネット生命出口さんの著書です。 私も一度、出口さんとは直接お会いした事がありますが、歴史に詳しく、それを知識ではなく知恵に昇華されており、講演会などを頼めば名古屋にでも来ていただけるフットワークの軽い方です。

結論としては「５つの条件」を満たすべし

結論から言ってしまえば、仕事を振る際に、以下の５つを全て伝えると上手くいく、というのが出口さんの意見です。（本の中では４つとなっていますが、複数の意味を持つものがあるので、ここでは分解します）

1. 期限
2. 他の仕事と比べた優先順位
3. 良し悪しの判断軸とその優先順位
4. （仕事が生まれた）背景や目的
5. 要求レベル

以下、この５項目を自分なりに考察してみます。

「期限」と「他の仕事と比べた優先順位」、「要求レベル」はマネジメント上の必須要件

このうち、「期限」「他の仕事と比べた優先順位」「要求レベル」の３つは、主に仕事の全体像を見ている者として、進捗を管理する上で必要になる項目でしょう。

「期限」「他の仕事と比べた優先順位」について、組織全体でどれだけの仕事があり、どの仕事をどういう順番で終わらせていけば良いのか、知っているのは上司だけです。部下は部下で、これが分からないとペース配分ができません。よって、この２つは至極当然の（しかしやはり現場では徹底されていない）事です。

「要求レベル」についても、初めから作り込んだものを出されて、結果そもそもスタートから逆方向に走っていましたとなると手戻りが大きいですから、そうしたリスクマネジメントのために予め握っておくに越したことはありません。

「良し悪しの判断軸とその優先順位」「背景や目的」は、仕事の質を高める工夫

一方残りの２つ、「良し悪しの判断軸とその優先順位」「背景や目的」は、仕事の質を高める工夫ではないかと思います。

まず「背景や目的」については、本書にそのままズバリ書かれています。

目的と背景を説明しておかないと、仕事の全貌は伝わりません。部下Bは、言われた事しかできなくなります。 データが見つからなければ、「見つかりませんでした」と報告して終わり。「代わりのデータを探そう」という発想は持たないでしょう。 部下の創意工夫を引き出すためにも、「目的と背景」をきちんと伝えるべきです。

次に「良し悪しの判断軸とその優先順位」ですが、実際にはこれが一番肝だと思っています。 なぜならこれを伝える事は、上司が望む通りの成果を得る事と、部下が裁量を持って自由に仕事をする事を、両立させ得るからです。

例えば、本書の例では、出口さんがWeb担当者にWebサイト制作をお願いした時、以下の優先順位を伝えました。

1. 使いやすさ
2. わかりやすさ
3. SEO対策

すると担当者は、自分の持ちうる知識とスキルを総動員して、何より「使いやすい」サイトを構築してくれるでしょう。 もしも優先順位の指定がなければ、担当者がSEO対策を重視したサイト構築を行い、求める物とは違う物が上がってきてしまった可能性があります。

判断軸を伝えるが、最終結果は指定しない

「良し悪しの判断軸とその優先順位」を伝える事についてもう少し突っ込むと、このやり方では「細かい成果物の形」については指定をしません。

上述のWEBサイトの例で、WEBサイトのデザイン案が上がってきた時、ボタンのサイズが小さかったとします。この時、上司の側は大きく二つの言い方ができるでしょう。

• ここのボタンを大きくしてほしい
• これは使いにくいと私は思うので、大きくするなど、何か対策をしてほしい

1.は指示レベルでのフィードバック、2.は要件レベルでのフィードバックです。

１のフィードバックを返すのは簡単です。ただ自分が変えたい所を直接伝えるだけです。次に出てきた時には、自分が指摘した通りの物が返ってくるでしょう。しかし、この指示には問題が２つあります。１つは、部下の考える余地を奪ってしまい、ただの手足にしてしまう事。もう１つは、この指示を繰り返すと部下が「何が正解か分からない」状態になる事。

前者は論じるまでも無いので良いとして、後者が厄介です。上司も万能ではなく、仕事を発注している段階では、完璧な完成形は見えていません。その状態で、個別具体的な指示を出していると、「こうしてみようか」「やっぱりこっちが良かった」「いや、でも最初だったかも」と部下を大いに振り回す事になります。前の会社では自分が振り回される側でしたし、今の会社では振り回しているのをよく見ます。（現在毎週楽しみに見ているアニメ「SHIROBAKO」でもキャラデザ担当が、Pと監督に振り回されるエピソードがありました。これがまた面白いので、そのうち記事にすると思います）。 すると完成まで時間がかかるだけでなく、部下の側も「この上司はどこに行きたいのか分からない」と途方に暮れてしまいます。これでは皆が不幸です。

これに対して、２のフィードバックを返すのは難しいです。そもそも事前にしっかり、判断軸を伝えておかなければなりません。そうでないと「要件を後出ししてちゃぶ台返し」が発生してしまいます（実際これはこれでよく起きます）。また、個別具体的な事はその場ですらっと言うことができますが、要件レベルで反しているかどうかは、一度考える時間が必要です。

人間はどうしても安易な方へ流れてしまいますが、その誘惑を振り切ってでも、２のフィードバックをするメリットはあります。それは、部下が困らず働ける事、そしてそれにより短期間でクオリティの高い成果物が得やすい事です。

例えば上司は「使いやすい＝ボタンが大きい」、部下は「使いやすい＝ナビゲーションが一箇所に集まっている」と捉えていた場合、往往にして発注段階ではそこまで深く理解しあえず、初めの提出では大きくずれた物になると思います。しかし、事前に評価軸が共有されていれば、そこから「使いやすいとはなんぞや」という議論にすぐに入る事ができます。上司からNGのフィードバックを受けても、それは評価軸の「捉え方」が違うだけで、そこを修正すれば良いのだと明確に分かるのです。

このやり方であれば、評価軸に反しない範囲で、部下は自由に動けます。それであれば、部下は自分の創造性を大いに発揮しながら、上司から出された要件を満たすという"パズル"を、解いていく気になれそうです。

ただし気を付なければならない事として、評価軸を個別具体的にしすぎない事、評価軸を大量に設定しない事です。

あまり細かく順位をつけると相手の自由度を奪うので、１番目から３番目までぐらいでよいと思います。

だいぶ回り道をしましたが「丸投げ」と「任せる」の違いとは

言ってしまえば、上記の「５つの条件」を全て備えていない依頼は、全て「丸投げ」と言っていいでしょう。

• 期限が無ければ最悪30年後に提出されても、非はこちらにあります。
• 他の仕事との優先順位が無ければ、どうでも良い簡単な仕事から先に上げられても、非はこちらにあります。
• 要求レベルがなければ、取り返しのつかない所まで進められても、非はこちらにあります。
• 目的と背景を説明しなければ、全然使えないものが出てきても、非はこちらにあります。
• 評価軸を伝えず、仕事が停滞しても、非はこちらにあります

そもそもなぜ「任せる」必要があるのか？

ここまで読んできて、「任せる」事が実は凄く難しい事だと思われたかもしれません。私もそう思います。 ですが、組織で仕事をする以上「任せる」ことは絶対に必要になります。

なぜなら元々組織とは、一人では成し得ない大きな事を成すために、特性の違う人々が寄り集まったものだからです。その中で、マネージャーが一つ一つ、全ての仕事をチェックし、細かく直していては、結局マネージャー一人で100人分の働きをしなければならず、すぐに破綻してしまいます。

いかに上手く部下に「任せ」、組織として最大の成果を効率良くだして行くかを考えるのが、マネージャーの責任でしょう。

まとめ

というわけで、読書メモにかこつけて、だいたい最近仕事場で色々見ながら自分が思っている事を書いてみました。 皆さんそれぞれ、上司であり部下である立場をお持ちと思いますが自分が指示を出す時は以下の５点を伝え、自分が指示を受ける時は以下の５点を引き出す事を心がけましょう。 私も心がけます。

1. 期限
2. 他の仕事と比べた優先順位
3. 良し悪しの判断軸とその優先順位
4. （仕事が生まれた）背景や目的
5. 要求レベル

刺身の上にタンポポを乗せる作業で振り返る「ザ・ゴール」

こんばんは。 今回は、経営大学院の先生から（随分前に）教えて頂いたこちらの本を（正月休みに）読んだので、 （すごい間が空いていますが）まとめも兼ねてその紹介をさせていただきます。 ……無駄に行間の多い文章だこと。

ザ・ゴール ― 企業の究極の目的とは何か

概要

本書は、赤字続きで3カ月後には工場閉鎖というところまで追いつめた主人公アレックス（工場長）が、元々物理学教授で現在はTOC (theory of constraints) の研究をしている教授ジョナと再会し、ジョナ助言にしたがって工場を立て直して行く物語です。 小説という体をとっていることで興味を持って読みやすく、アレックスと共にTOCの考え方を段階的に身につけていくことができる構成になっています。

TOCとは

TOC＝制約条件の理論とは、複数の様々な制約（できないこと）がある環境において、それらを調整し、最大の「ゴール」を得る為の理論です。 ここでいうゴールとは「目的」のことであり、営利目的の活動であれば利益のことであり、利益を上げることが使命になります。

しかし、ただ漠然と利益をあげろと言われても、何をどう考えたらよいのかわかりません。 そこで利益を要素分解します。

例えば、私の勤めている様なオンライン（もしくはモバイル、ソーシャル）ゲーム業界では

利益 = ユーザ数 × ARPU - 運営費用 - 会社固定費

と利益を１段階分解する事で、状態を把握し、何が利益を圧縮しているのかを考えやすくします。 実際には、このレベルでもまだまだ荒く分からない事が多いので、もっと多くの要素に分解していきます。

それと同様、TOCでは

利益 = スループット - 在庫 - 業務費用

と考えます。 スループットの定義は「販売によって作り出すお金」（ざっくり言って、売り上げ） 在庫の定義は「販売しようとする物を購入するために投資したお金」（ざっくり言って、材料費） 業務費用の定義は「在庫をスループットに変えるために費やすお金」（ざっくり言って、加工・販管費） となっています。

別にこんなものはどうとでも定義できる。数式遊びだ、という向きもあるかもしれませんが、そういう訳でもありません。 指標には力があります。 正しい指標を選べば物事は正しい方へ、誤った指標を選べば物事は誤った方へ、流れていってしまいます。

TOCでは「スループット」「在庫」「業務費用」という三つの指標に注力することで、自然と制約条件下での最適解が見つけられる様になっているのです。

ボトルネック

TOCの肝になる考え方に「ボトルネック」があります。 ボトルネックとは、ある製品の製造プロセスにおいて、もっとも多くの時間を必要とする工程の事です。

突然んですが、刺身の上にタンポポを乗せる作業を考えてみましょう。（！？） 作業現場では、トレー、バラン、刺身、タンポポが流れてきて、順番に乗せるものとします。 バランを乗せるのに１秒、刺身を載せるのに３秒、タンポポで２秒かかるとすれば、 一人で一連の作業をやった場合、６秒程度で終了します。 三人で並行してやった場合、平均して２秒で一皿完成します。

しかし仮に、バランを載せる作業、刺身を載せる作業、そしてタンポポを載せる作業、 それぞれを別の人が担当したらどうなるでしょうか。 なぜそんな事をと思うかもしれませんが、工場での大量生産は、本質的にはそういう事をしています。 （もちろん、それが必要だからです）

さて、バランを載せる人をバランさん、刺身を載せる人を刺身さん、タンポポを載せる人をタンポポさんとした時、 三人がそれぞれ自分の工程を担当した時、生産スピードはどうなるかといえば…… ご想像通り３秒で一皿が限界になります。 バランさんが3秒に一回、１秒だけ仕事をし、 タンポポさんが３秒に一回、２秒だけ仕事をしている間で、 刺身さんは休むことなく刺身を乗せ続けている状態です。

この時の、刺身を乗せる作業こそが、この生産工程におけるボトルネックであり、 "制約条件の理論"における「制約」その人なのです。

ボトルネックとスループット会計

もう少し思考実験を続けましょう。

この日、サシミニタンポポノセール工場の朝礼で次の様なやりとりがあったとします。 上司「本日、皆さん一人一人と面談をしますので、バランさんは10:00、刺身さんは11:00、タンポポさんは13:00に、私のところまで来てください」

バランさんの視点

この日、バランさんは10:00から60分ほど、作業ができません。 自分が作業できないと、刺身さんやタンポポさんが困ってしまいます。 そこでバランさんは、刺身さんが60分作業するために必要な量を、先に作っておくことにします。 バランさんは普段３秒に１個のペースで生産を行っていましたが、実際には１つ作るのに１秒しか掛かりません。 そこで本気を出し、残りの２秒を使って、余分に作ることにしました。 刺身さんが60分間で必要とするのは1200皿。 バランさんはそれを普段の生産の片手間で、30分で作り、面談に行きました。 面談から返ってくると、予定通り余分に作った皿が消化された所で、 そこからはまた３秒に１回のペースで作り続けました。

刺身さんの視点

この日、刺身さんは11:00から60分ほど、作業ができません。 自分が作業できないと、タンポポさんが困ってしまいます。 が、しかし。それはわかっているものの、元々刺身さんは休む間もなく働いています。 0900からバランさんの全身が赤く光り出し、作業ペースが普段の３倍になり、自分の前に仕掛品が大量に積まれましたが、自分のペースはこれで限界です。 たまった仕掛品をなんとかこうとか仕上げた頃には、面談の時間になってしまいました。 面談から返ってくると、バランさんは「刺身がいないのにバランを乗せても仕方ないだろう」と作業を止めており、 タンポポさんは「やることがないお」と作業を止めていました。

タンポポさんの視点

この日、タンポポさんは13:00から60分ほど、作業ができません。 しかし、自分は最終工程なので、後から頑張ればなんとかなるだろう、と特に何もしませんでした。 そうこうするうち、11:00から刺身さんが席を外した事で仕掛品の供給が止まり、仕事がなくなります。 その後お昼休憩を挟んで1300から60分面談をし、返ってくると1200皿が溜まっていました。 仕方ないので、タンポポさんも本気を出します。 普段３秒のうち２秒を使って１皿仕上げている所を、残り1秒もタンポポを載せる作業に使うことにしました。 結果、普段の1.5倍のペース、３秒に1.5皿を消費し続け、2時間後には1200皿の仕掛品も消えました。

この時何が起きていたのか？

この時何が起きていたのか、振り返ってみましょう。 まずバランさんですが、事情により作業が止まることがわかっていため、ペースアップすることでそれに対応しました。 一方タンポポさんは、作業が止まっている間にたまった仕事を、ペースアップすることで処理できました。 しかし、刺身さんはどうでしょうか。 刺身さんは普段から余力がなく、常に全力です。そのため、他の二人の様に休んだ時間分の生産を取り戻すことができませんでした。 それどころか、休んだ時間分、まるまるバランさんとタンポポさんの仕事も休ませてしまいました。

これが、ボトルネックの恐ろしい所です。

スループットの最大化＝ボトルネックを休ませない事

工場で生産工程を組んで仕事をしていると、必ずボトルネックができます。 そして、ボトルネック以外の作業ではその生産ペースを上げ下げ調整する事で、不意の事態にも対応可能になります。 しかしボトルネック工程はそうした対処ができないからこそのボトルネック工程であり、ここが止まる事は作業を一つ止めただけでなく、生産プロセス全体を止める結果になるのです。 逆に、生産プロセス全体は、ボトルネックのスピード以上で生産する事はできません。

よって、TOCでは「ボトルネックを休ませない事」を重視します。いかなる理由があっても、ボトルネックを無駄使いしません。 また、もしもボトルネックの作業容量を増やせるのであれば、部品個別で見た時に製造コストが上がることになろうとも、外注や旧式機械の使用もするべきと判断します。ボトルネックの負荷を下げることは、工場全体のスループット向上に劇的に効くからです。

刺身の上にタンポポを乗せる作業の場合、もしもう一人を雇うなら、刺身の作業をやってもらいましょう。 その場合、今度はタンポポを乗せる作業がボトルネックになりますが……。

在庫と業務費用の最小化=非ボトルネック業務を適度に休ませる事

一方で、非ボトルネック業務は適度に遊びをもたせておく事が重要です。 局所的に見れば、遊びをもたせる＝非作業時間が増える＝時間あたりの生産コスト効率が下がる、と言えますが、実際にはこんな事を考える必要はありません。 なぜなら、スループットを決めているのはボトルネック作業であり、非ボトルネック作業をぎゅうぎゅうに詰め込んだ所で、まったく意味のない作業か、保管スペースを必要とする仕掛品の山ができあがるだけだからです。

刺身の上にタンポポを乗せる例ではバランさんとタンポポさんは実は普段手を抜いていましたが、有事にはその余力があるからこそ対処できたし、普段は本気を出しても仕掛品の山を気づくだけなのです。

まとめ

ということで前回の記事に引き続き、自分では（まだ）実践していない机上の空論シリーズをお届け致しました。

ザ・ゴールでは生産管理に対してTOCを適用する例を示していますが、実際にはTOCはより上位の概念であり、何段階かのプロセスを経て成果物ができあがる、どんな場面にも適用可能なはずです。 見るべき所が多すぎて、何から改善すれば良いのか分からない。そんな時にはまず刺身さんーーボトルネックがどこなのかを炙りだしてみましょう。

今更ながら「関数型」という概念に触れて戦慄を覚えている。こんなにクールな考え方があるとは。

お久しぶりです

スタート早々更新が止まって依頼、半年ぶりの更新です。 なんでこんなに間が空いてしまったのか、振り返ってみると結構謎です。 何かこれ以外のアウトプットがあったかといえばそれは（ほとんど）なく、さりとてインプットをしていたかというとそうでもない……。 いや、仕事は確かに忙しかったし、そこでたくさんのインプットとアウトプットをしてきたので、全然無駄な半年では無かったと思っていますが。

きっかけ

それはそれとして、タイトルの話です。 私、名古屋のこわい人たちとは近いような遠いような位置にいまして、「関数型プログラミング」という言葉は聞いたことはあったし、興味もあったわけです。 さりとて、Haskell勉強会に参加したりする事もなく、独学で勉強する事もなく今日まで来ていました。 私自身、「グロースハッカー」というポジションを目指していても（いるからこそ？）、データマイニングやマーケティングの勉強はしても、実装技術についてはもう今更良いかな、と考えていた節もあります。 （一応、手続き型プログラミングはできるつもりでいたので、良いかなと）

ところが先日、社内で技術陣が使っているチャットでこんな記事が流れてきていました。

※1 Qiitaですので、読むには登録が必要です ※2 内容は後日書籍化されるそうです、というかQiitaの方が書籍の冒頭を公開したものになります

副読としてはこちらもあります。

これらを読んで、私は一発で「関数型」という概念のファンになってしまいました。

論理を記述するという、クールな方法

従来の、というか現在主流となっている手続型プログラミングは処理の手順を記述します。 一方で、私の理解したところでは、関数型プログラミングとは論理を記述するという方法論の様です。 劇中の登場人物「セキヤ」君も相当衝撃を受けていましたが、これには私も強い衝撃をうけました。 この二つは、明確に、概念が違うのです。

（以下は私の解釈ですが、ここが違う、ということがあればお手柔らかにお願いします(^^;）

手続型ではプログラマはベビーシッターであり翻訳家であった

手続型では、コンピュータに対して手取り足とり、何をどうすれば良いのか教えてあげます。 一つ一つ丁寧に、どこのメモリから値を取り出して、その値に何をして、どこのメモリへ格納するのか。 私は高専時代にマイコンのプログラミングもやっていましたので、その感覚が強くわかります。 コンピュータを、何の知性も持たず、人間に言われた事だけを超高速に、誤りなく実行してくれる存在として捉え（本当に誤らないかは別の問題ですが……）、人間が導いてあげるのです。まるで、赤子に対して物事を教えるがごとく。

これは副読記事の方にも言及があるように、コンピュータが文字通りただの「計算機」だった頃の延長にあります。 コンピュータのリソースは有限で、貧弱で、それを人間が職人芸でチューニングし、動かしていました。 プログラマとは翻訳家であり、自然言語をマシン語へいかにうまく変えるかが、プログラマのスキルであったのだと思います。

関数型ではプログラマはコンピュータと対等な友人であり、科学者にもプロデューサーにもなれる

関数型では、コンピュータに対して手取り足とり、何をどうすれば良いのか教えてあげません（隠蔽されている内部的な実装は置いておくとして）。 足し算をしたいなら「足し算をしろ」、素数を数えたいなら「素数を数えろ」としか言いません。 それはあたかも、コンピュータを知性ある友と認め、普段同僚にするが如く「そんな感じでやっといて」とお願いしているように見えます。 もちろん、関数型の流儀に従った自然言語の翻訳は必要ですが、手続型とは雲泥の差です。

そうして、翻訳という作業が極端に軽くなることで、プログラマはより本質的な「論理」に気を配ることができるようになります。 論理とは計算ではなく、物事の成り立ちの本質です。関数型では、そこに気を配り、最適化し、より正しい論理を得ようとすることもできそうです。 論理を拠り所として新たな論理を得る。そのような行為は、元来研究者、ないしは科学者が行ってきた事であり、プログラマであっても、そこに到達できるのではないでしょうか。

さらに、別の可能性として、論理が必要になる「目的」まで思考を及ばせることもできます。 なぜこの論理を選んだのか、なぜこの論理が必要なのか、そうした事を考え出した時、その答えを得るためには「何のためにこのプロジェクトは存在しているのか」という問いに答えなけばなりません。 「何のために」「誰のために」「なぜ」、こうした思考はプロデューサーのそれでしょう。

もちろん純粋に、関数型プログラミング言語を用いて極めて高い生産性を発揮する、という超プログラマになる事も可能です。

それで私はどうしたいのか

一言。Haskellやろうと思います。 将来的には関数型の思考でデータマイニングができれば、ベストでしょうが、まあ実際のところ実用的にはいかほどのものか、やってみないとわかりませんし。

まとめ

今日はあまりに強い衝撃を受けたため、筆を取らざるを得ませんでした。 関数型プログラミングは、これまでとは発想法が違います。 コンピュータはもはや手取り足取り導いてあげるべき存在ではなく、もっと概念のレベルで対話が可能になっていたのです。 SF作品などでよくある「 AIがプログラムを自動生成する」シチュエーションは、関数型なら比較的早く実現できるのかもしれません。

個人的には、これまでプログラミングをやったことがない、すでに挫折してしまった、という人ほど関数型に向いているのではと思います。

この概念と出会い、理解するのがあと5年早ければ、僕は人生の着地点を今と違えていたかもしれません。

蛇足

こんなパラダイムが30年も前からあるというのに、フローチャートを可視化し、繋ぎ合わせて作っていくモデルベースを採用した業界があるらしい。 (追記）もっともあちらは組み込み系故、いつまでもギリギリのリソースでの開発を強いられる訳で、致し方ない面もあるとは思いますが。

Rこわい

こんにちは。7月も後半に入り、夏本番ですね。 今日からは「Rによるやさしい統計学」を参照して、統計解析ソフトであるRの使い方と、統計学の再学習を進めていきます。 基本的には、演習しながら引っかかった、面白いと思った所だけをピックアップしていきます。

Rによるやさしい統計学

サマリー

• Rというのは統計処理に重きをおいた数値計算ソフトです。オープンソースで利用は無料！
• Rは統計学の歴史に則り、不偏分散を「分散」としていますが、ビッグデータ的に全数解析する場合には「標本分散」を分散として使う必要があります
• Rの文法……これはまさか、関数型！？

---

Rのインストール

Rの使い方を学ぶのにRのインストールを紹介しないというのもいかが、という事でまずはインストールから。 といっても何も難しい所はなく、以下のURLからpkgファイルをダウンロードして実行。あとは流れで……。

http://cran.md.tsukuba.ac.jp/bin/macosx/

後々細かい設定が必要になる気もしていますが、ひとまずはバニラ運用でいきましょう。

Rの基本的な操作

Rは対話型CLIを基本としている統計計算ソフトです。使い方は簡単で、計算させたい内容を1行づつ入力していくだけです。

ただ、足し算をやらせるだけなら電卓で良い訳ですし、Rの強みである統計処理をやらせてみましょう。

この様に、数列に対して最小値、最大値、平均値、中央値などを簡単に出してくれます。 尚、上記のコマンドで使用している様に、Rでは以下のようにして配列、行列を定義できます。

height = c(173,178,170,164)

physical = matrix(c(173,178,170,164,75,80,65,60),4,2)

しかし実務でこんな事はせず、csvファイルなどを読みこませる事になるでしょう。

physical = read.csv("physical.csv")

この場合のcsvの中身はこう書きます。

height,weight
173,75
178,80
180,65
183,60

１行目に、列の見出しを書くのがポイントですね。

標本分散と不偏分散

そんなこんなで統計的な処理を一通り備えたRですが、早速１つ注意点があります。 Rで分散を計算する標準の関数としてvar()が定義されているのですが、これがなかなか気の利いた奴で、不偏分散を出してきます。でも、実はまずい。

不偏分散とは、N個の母集団からn個のサンプルを選んだ時、そのn個のサンプルを用いて推測した母集団の分散の事です。 具体的には、N個の母集団全てを用いて計算する標本分散が

であるのに対し、そこからn個のサンプルを選んで計算する不偏分散は

となります。

この理由を直感的に説明すると、

• 本来N個ある母集団からn個のみを取り出した事で、標本のばらつき(=分散が表している指標)が抑えられるので、分母を少し小さくして帳尻を合わせる

という事で、もう少し厳密に説明すると、

• N個の母集団からn個のサンプルを全組み合わせ取り出し、「全組み合わせの分散の平均」と「N個の母集団の分散」を突き合わせると、nではなく(n-1)で割った値が母集団の分散に一致する という事の様です。

証明はこちらが参考になります。

不偏分散はなぜ-n-1-で割るのか？

なぜ不偏分散はn-1で割るのか

ここらで話を戻して、R標準の分散を求める関数が不偏分散だとなぜまずいか。

理由は不偏分散と標本分散の違いを理解していれば明白で、「ビッグデータ」と呼ばれる大量データを収集・分析する技術のある今、必ずしもサンプリングせずに大量のデータをそのまま統計処理したいからです。

サンプリングし、推定するというのは先人の知恵ではありますが、全数処理できるならそれに越したことは無いのです（もちろん、コスト問題などはついて回りますので、ケースバイケースではありますが）。

そんな訳で、標本分散を計算する独自関数を用意してみましょう。

Rは関数型言語だった……？

そして最後にタイトルのネタになります。

冒頭でRは対話型CLIを基本としている、と書きましたが、実際にはプログラミングの様な事も可能です。さらに、独自に関数を定義し、それを呼び出すことも可能です。一連の処理をまとめて定義しておけば、再利用性も高くなり、自分だけの処理環境が構築できるでしょう。

では、肝心の定義方法と呼び出し方です。

関数定義

varp = function(x){
    var(x) * (length(x) - 1) / length(x)
}

呼び出し

varp(x)

実行例

関数定義を変数に代入しちゃうこの書き方……まさか関数型言語！？ いや、ただ文法が似てるだけですよね。すみません。

以上、今回はここまで。次回は、今回「別にいらないんじゃないか」と言った推定のお話をやる予定です。

はじめまして

初めましての方、初めまして。katoma586と申します。

人生何度目かのBlogになりますが、初めのエントリーという事で、今回このBlogを開設するに至った経緯と、その目的をまとめたいと思います。 

記事要約

• 人生色々さまよったけど、グロースハックが自分にぴったりの領域だと感じたよ！
• 経験もスキルもほとんどないので、日々勉強しつつ、それをアウトプットする場所を作ったよ！　これからグロースハッカーを志す人の道標になれればいいな！
• 今見えている範囲でスキルセットを定義してみたよ！　これにそって勉強をしていくよ！