ワークリスクヘッジ
仕事はだいたいの場合、リスクリターンの関係で考えることができるようにあると思う。上司の期待値と自分の思い描いているものが全く違う可能性があるが、これはsyncすることによって抑え込むことができる。一方で、syncすることによりオーバーヘッドが出てしまうため作業のスピードが下がることもある。どのタイミングで何をsyncすべきかということはかなり工学的に決まってくると思われる。
- 上司と擦り合っていない時
擦り合っていないので、高リスク状態にある。頻度高くsyncすることで基本的にリスクをヘッジすることができる。擦り合ってきたらsync頻度を落としていき、自走モードにしていこう
- 上司と、その上司が擦り合っていない可能性がある時
自分と上司が擦り合っていても、そのアウトプットは全く使われない可能性もある。リスクが低いものから順にやっていくことで全体の生産性は高まるはずである。場合によってはボスのボスに確認しにいくこともありだが、これは組織風土によってはタブーとなる場合があるため気をつけるべし
ブログ版死の谷とは何か
Blog版死の谷とは、「個人がBlogを立ち上げてから、最初に記事がバズるまで」である。読者とのインタラクションが生まれはじめることで、Blogを書き続けようという動機は生まれる。しかし、最初に記事がバズるまでの間に読者とのインタラクションが生まれることはない(誰にも読まれてないから)。なのでこの間にほとんどのブログの更新が途絶えてしまうということだ。
Blogを立ち上げた直後は素晴らしい。勢いがある。内発的な動機がある。この内発的な動機が燃え尽きるまでの間に、ターゲットを決め、PVを、エンゲージメントを稼ぐ仕組みづくりをしていかなければならないということなのである。
正直、これは顕名のブログであれば楽である。Facebookに投稿すればいいんだから。楽にいいねをもらえるのだから、それでいいのである。でも匿名の、人にいえないブログの場合は自分の「ともだち」からの支援がないのでかなり厳しい戦いにならざるを得ない。
つまり、このブログがブログ版死の谷の真ん中にいるということである。
データ解析のプロジェクト7つ道具
最近企業のデータを解析して示唆を出す or 予測モデルを作るみたいなプロジェクトをいくつか回しているのだが、チームとしてデータ解析を進める上でどのようなツールを使うと良いのかまとめてみた。現状はこんな感じでやっている。
- (前提として)Python
データ解析関連ではPythonかRを用いるのが良いと思う。この二つの言語であればライブラリも充実しているので、生産性はかなり高くなる。但し、Rubyやその他の言語を既に習得している場合はRよりもPythonの方が習得コストは低いように思うので今回はPythonを紹介させていただいた。 - iPython notebook(Jupyter)
インタラクティブな形式で、webページ上で試行錯誤しながらコーディングを進めることができるツール。データ解析の場合は結果を見ながら作業をした方がミスも減り、結果的に圧倒的に早くコードが書ける。グラフィカルに画像やチャートを表示することもできるし、実験ノートとして気がついたことをmarkdown形式でコードの隣に書き記すこともできる。ipython notebookで処理を一通り書いた後に、pythonのscriptとして書き直してより大きなデータに対して計算回すとか分散で処理させるとか、他のシステムに組み込むみたいなことをしている - pandas
データフレーム形式でデータを扱えるようにするPythonのライブラリ。numpyでやるよりもデータの整形がしやすいし、ipython notebookとの親和性も非常に高く、HTML table形式でデータを出力してくれるため非常に見やすい。DBからの読み出しや書き出しも非常に楽だし、大きなサイズのデータをDBからチャンクに分けてとってきて処理することや、ダミー変数への変換もやってくれる - scikit-learn
機械学習に必要な機能が一通り備わったライブラリ。正規化等の前処理から、PCA等の次元削減処理、クロスバリデーション用のデータ分割、各種学習アルゴリズムの実装、学習器の精度評価、パラメータサーチまでscikit-learn上の機能を用いて行うことが可能 - Lasagne / xgboost
Scikit-learnに実装されていないようなアルゴリズムは別途ライブラリを使用する。Lasagneはニューラルネットのライブラリであり、xgboostはKaggle等のコンペで大人気のGradient Boostingのライブラリである。各種アルゴリズムのscikit-learnラッパーを用いることで、scikit-learnのほかのアルゴリズムと同様に扱うことが可能
- Git & GitHub
コードの共有 / バージョン管理に用いる。GitHubは最近ipython notebookの表示にも対応したため、非常に使い勝手は良くなった。但し、いわゆるgithub-flowみたいな開発フローのモデルがデータ解析系の案件に対して効くのかどうかは不明である。GitHubのIssues機能を使ってタスク管理をすることもできる。 - Google SpreadSheets / Excel
スライドに落とす前に、実験結果を表形式でまとめる時に用いる。どういう実験をどれだけやって、それぞれの精度がどうだったかというのを見るにはなんだかんだ言って表計算ソフトが一番実装スピードが早いように思う。エンジニアは使うの嫌いなのだけれども、ExcelやGoogle Spreadsheetはうまく使いこなせば非常にパワフルなツールだと個人的には思う - PowerPoint / Keynote
最終的な資料として落とす際には、PowerPointもしくはKeynoteを利用している。データをしっかり見せたいのであればPowerPointの方がグラフ機能が充実しているのでオススメであるが、資料をキレイに見せたいのであればやっぱりkeynoteの方がよい。
上記の組み合わせが本当に最適なのかといえばそんなことは全くない。日々新しいツールが出てきているし、もっと良いやり方はいくらでもあるような気がしている。例えばどのようにデータや成果をプレゼンテーションすべきかという点でいえば、実はパワポなんか使わないでipython notebookを用いてインタラクティブなダッシュボードをサクッと作成し、簡単に数値をいじりながらd3.js等でビジュアライズしたデータを見せるみたいにした方がよいかもしれない。今後もいろいろ試してみながら可能性を探りたい。
エピソードを記憶する能力がなさすぎる
半強制的に過去を振り返るシートを記入しているのだが、そこでは「xxxxのような思い出、エピソードはありますか?」とか「人生の転機は?」とかそういったエピソードを聞かれるのだけれども、全く思い出せない。エピソード的な記憶がなさすぎてなんらかの障害を疑うレベル。でも言われたら思い出せるんだよね、いろんなエピソード。ふしぎだ！
エピソード記憶障害を克服するためにもblog的なものに何かを書き残すのはとても重要な気がする。
ちなみに：エピソード記憶に関して調べてみたらwikipediaのページが面白かった。
若者と老人とでエピソード記憶を思い出すときに活性化する脳の部位が違うし、やはり研究によれば女性の方が男性よりもエピソード記憶に優れているらしい。
メディアに取材されるコツみたいなものが知りたい
先日、某新聞社に取材いただいて、記事が出たのだが、なかなか取材されるのも難しいものである。「取材され力」に関して今回の件の学び(暫定版)を以下にまとめておく。(但し、少ない自分の経験のみに依拠しているため、間違っている点も多々あると思うと思われる)
- そもそも取材されるべきものか判断
取材を受けて記事にすることが良いかどうかは内容に依存する。とにかく認知を広げることが売り上げにつながるようなものであれば両手を挙げて出まくるべきだし、製品がテスト段階であるような場合にはイメージ悪化にもつながりかねないので、最初の段階から露出を広げるのはやめた方がよいし、場合によるだろう。取材を受けることによって何の得があるか、何のために取材を受けようと思うのかは具体的にしておいた方がよいだろう - 記者を呼ぶフックを用意
ニュース性の高いことをやっていたとしても、記者に「取材しよう」と思わせられるようなフックを用意する必要がある。フックとしてはイベントを打つ、Blog記事をバズらせる、等が有効そうだが、他にもいろいろあるかもしれない。場合によってはこちらから告知するのも良さそうであるが、どうなのだろうか。(地方の場合は小規模なイベントでも地方面向けに記者が来てくれる場合があるし、専門のネットメディアに刺さりそうな内容であれば、告知すれば高確率で記事にしてもらえる可能性がある)。また、仲の良い記者がいる場合にはしっかりニュース性の高いことをしていれば声をかけるだけで取材にきてくれるかもしれないので、無理してフックを用意しなくても良いだろう。 - ニュース性の高いメッセージを用意
見出しレベルで刺さりそうなニュース性の高いメッセージがあると良い。もちろん記事を実際に書くのは記者の側だが、こちらで見出しイメージや内容イメージをおぼろげに持っておいた上で記者とコミュニケーションをとると、伝えたい内容を記事にしてもらえるので効果が高い - リスクヘッジのために掲載して欲しくない内容をまとめておく
基本は記者の方に掲載して欲しくない内容を伝えてはいけないのだが、どうしても取材の過程で伝わってしまう場合があるし、口を滑らせてしまう場合もある。明確に「xxxがxxxxなことは掲載しないでほしい」ということをコミュニケーションした方がよいだろう。今回の場合は口を滑らせてしまった事項や、裏方を見せる過程でどうしても見えてしまう部分があったので、口頭で一つ一つ確認した上で、箇条書きでメールを送付した。 - リスクヘッジのための記事下書きを確認
できる場合には記事のドラフトを確認させてもらうように頼むべき。大きなメディア（新聞社やTV)では確認させてもらえないこともあるが、雑誌やネットメディアだったらおそらく確認させてもらえると思う - 御礼
忘れずにね
会議読解力を上げて会議のプレイ品質を上げる
前職の企業でいくつかの企業の経営会議やら重役の会議やらに出席させて頂いたことがあるのだが、この会議というものが非常に難しかった記憶がある。会議読解力とでもいうべきものがあって、それのあるなしによって全く状況認識の精度が違ってきて、会議中のプレイのクオリティが変わってくる。
・Lv1: 会議全体で何が決定事項で、ネクストステップが何かが分かるレベル
決める物事の粒度が組織の階層が上になればなるほど抽象的になってくるため、階層が上の会議体を理解するためには抽象的に物事を把握する能力が求められる。しっかりと抽象概念の共通認識を詰めてくれればいいものの、必ずしもそういう認識の議論が行われるというわけではない。そもそも文脈を完全にお互いに把握しあっていればあまり説明せずとも認識が擦り合っているというケースもあるし、政治的な理由やその他の理由から意図的にぼやかされる場合もあるし、単純に擦り合ってると思っていても全然擦り合っていないケースもある。そういったものをしっかりと考えた上で会議を受けてそれぞれのプレーヤーが次にどのように動かねばならないかということを把握するのは(少なくとも僕には)すぐにはできなかった。
・Lv2: 会議参加者の発言の意図が汲み取れるレベル
一人一人の頭の中がおぼろげに見えてくるとこのレベルに到達する。それぞれの人の関心は微妙にみんな異なっていて、更にどうしたいかという意図も異なっている。その違いをしっかり認識できていると会議参加者のある発言を聞いた時にも、明示的に示されないような懸念や、他の人のxxxの件への牽制であるというような意図が理解できるようになってくる。このレベルまでくるとその頭の中にある本当の懸念に対して答えるような発言をできるようになるため、会議中のプレーが非常にやりやすくなる。
・Lv3: 会議の事前にどのような発言が出るか大体予想がつくレベル
会議参加者の脳内を理解する能力が高くなってくると、次に会議のシミュレーションができる段階に来る。Aさんはこの資料を見た時にxxxxの件が気になっているからxxxxのような反応をするだろうし、Bさんはこの件についてxxxxだと思っているからxxxのような反応が来るだろう、といったようなことが事前に読めるようになるのである。こうなってくるとアジェンダ設計や資料設計のレベルから会議をコントロールできるようになる
とはいえこの思考の枠組みも前職のコンサルティング会社側のバイアスがあり(会社の外から資料を持ち込んで議論する)、社内のプレーヤーからすると"人の頭の中を読みながら精度の高いエミュレーターを構築し、アジェンダや資料レベルから会議をコントロールしようとする"というプレイスタイルは最適ではないような気もする。権限があれば単純に自分の頭の中をいかに理解させるかという戦いになる気がするし、権限がなければもしかすると会議の以前にいかにハードコンテンツ & ソフトコミュニケーションの両面から内容を握っておくかみたいなことの方が重要になるような気もする。
大企業と違って、中小企業やスタートアップ、省庁等ではまた微妙に違ってくるのかもしれない。工学的にひもといてみたいものである。会議工学。
人脈ではなくディスカッションパートナーを
事業に必要な人脈なんて、実際に事業をはじめて、そのコンセプトがちゃんとしたものだったら後からいくらでも自然とできてくるのだから問題はない。人脈ガーみたいなことを言っていないでとっとと始めるべき。(もちろん事業内容によっては起動に人脈が必要不可欠な場合があるが、でもそういうのも思っている以上に限定的)
じゃあ実際に必要な人脈ってなんだろうと考えてみると、お互いに意見を遠慮せずにぶつけあえた上で生産的な話し合いができ、アイデアや問題の解決策を出し合えるようなディスカッションパートナーなのではないか。
大学時代から / 元同僚の友人とならディスカッションできるが、他業種他年代のディスカッションパートナーはそこまで多くないし、そういう関係にまでなれる人はあまりいないので貴重である。
