データエンハンサーの戯言置き場

データサイエンティストを挫折した人がデータとアナリシスのエンハンスメントについて考える

はじめての方へ

このページは初めての方に向けた自己紹介とその他諸々のページです。よしなに。




自己紹介

某インターネット企業にてデータアナリストを経てデータサイエンティストになれず、データエンハンサー(自称)、アナリシスエンハンサー(自称)をやっております。 ブログの内容は個人の意見・見解であり、所属組織の意見・見解とは異なる事があります。




データエンハンサーとは

自称です。

lucies.hatenablog.com




↓それでは最新記事をどうぞ↓



能力を上げる基本的な方法

結論

結論だけ言うと

  • フィードバック大事
  • レビュー大事
  • ディスカッション大事

以上、です。

 

「能力」にもいろいろあるのだけれど、基本的にいろいろな能力を身につける方法は、この3つに集約されていくと思います。

https://3.bp.blogspot.com/-9_wU72o_4sw/VdL1Na0LYcI/AAAAAAAAw7o/STbgsN4kotE/s800/mensetsu_group_discussion.png

 

フィードバック大事。

結構インターネットの業界とかだと、とにかくアウトプットしろ!みたいなことはよく言われるのだけど。アウトプットだけしてても伸びないよなあというのを個人的には思うのです。

重要なのは、アウトプットしたものを「評価」することであって。「市場に問う」なんて言葉が使われたりもしますけど、要はフィードバックをちゃんともらわないとね、という話。

PDCAで言うならC。Cがあった上でのA。PDSで言うならS。

Twitter上だと(というか僕のTL上だと)、絵がうまくなるにはどうしたらいいですか?→とにかく描け!みたいなのがよく流れてくるのだけれど。絵なんかは良いんですよね、自分の絵を見れば他人の絵より下手なことはわかりやすい。

けど、サービスまでいかなくても、企画書にしろプレゼンにしろコードにしろ、フィードバックもらわないと結構オレオレ理論になっちゃうんですよね。俺の考える最強の企画書、みたいな。

なので、きっちりフィードバックはもらいましょう、もらえる環境を作りましょう、というお話。

 

レビュー大事

フィードバックをもらう方法の1つが、「レビュー」という形式。サービスリリースして市場に問う、とかそうそう高速にサイクルが回らないわけですよね。企画書を偉い人に見せてフィードバックもらってまた書き直して・・・とか、提案書をお客さんに出してフィードバックもらって・・・とかやりたくないじゃないですか。だからレビューをするんですよね。ローコストでフィードバックをもらえる。

この方法は特に経験の浅い人には有効で、能力の高い人にレビューしてもらう、というのは何度もやると良い。

理屈が通ってない、ストーリーがわかりにくい、読みにくい、伝わりにくい・・・なんていうのは、アウトプットとして出す前にきっちりレビューを通せば結構解決する。

ブログ記事も誰かのレビュー通したい。いややっぱめんどい。

 

ディスカッション大事

能力がある程度対等の人同士でやるなら、レビューよりはディスカッションが良い。

ディスカッションって、「意見を言う」、それに対して「反論」とか「同意」とかを返す、というのを繰り返すわけじゃないですか。このagree/disagreeってフィードバックですよね。集団で集まってそれぞれが意見を言い合う会は、実は超高速フィードバック会なわけじゃないですか。

意見を言う、フィードバックをもらう、それに対して別の意見を言う・・・というのは、フィードバックの回数で言ったら1時間で3桁を超える回数がもらえるわけです。こんな密度の高いお得な時間はないですよね。

 

ただしディスカッションは声の大きい人(物理的にじゃなくて、意見を多く言う人)がいると、その人の意見に引っ張られてあまり活性化しなくなるので注意が必要だったりもする。その場の偉い人に対して意見を言えない、とか偉い人が絶対、みたいになっちゃうとディスカッションにならない。

マジであるんですよ、そういう会社。あの某銀行とかがそうなんですけど。

 

逆に、能力不足だと全く議論についていけずに押し黙っちゃう、、、というケースも多かったりする。ので、ある程度フラットな雰囲気で、同レベルの人たちが行うのが良い。ついていけなくても、見て、理解しようとするだけでも価値はあるけどね。

 

実行できてますか

フィードバックを大量にもらえる環境ってできてますか。

これ、できてる組織とできてない組織で結構差があるなあという感じがしています。同じ会社でもチームによって全然違ったりする。1週間の予定表見直したときに、レビューをもらうとかディスカッションする、という時間が最低でも5時間(1時間/営業日)くらいは必要だよなあというのが個人的な感覚。5時間だとちょっと少ないかな、くらい。できれば15時間くらいあると良いと思う。残業無しで、1日8時間労働のうち3時間くらい。

この時間が少なすぎるところにいると、基本的には能力伸びないので転職したほうがいいんだろうなあと思うよ。ホワイトカラーな仕事をするなら。

 

まとめ

ということで、

  • フィードバック大事
  • レビュー大事
  • ディスカッション大事

という話でした。

 

 

フィードバックの具体的なやり方にこんなのもあるよ

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

 

 

なぜゼネラリストが無能になるのか?

さて、久々に読書と関係無い記事でも書こうと思います。

三行でまとめる

  • チームにおいてただのゼネラリストは無能
  • チームの能力はチームメンバーの最大値に依存する
  • 有能なゼネラリストはスペシャリストをつなぐスペシャリスト

チームワークとはなにか

現代のホワイトカラー的な仕事は殆どがチームでの仕事を前提にしてます。なぜチームで働くのか、というといろいろな考え方がありますが結局

  • 個々人がバラバラに働くより良い成果が出るから

ということに尽きるはずです。

では、より効率のよいチームワークとはなにか。より成果の上がるチームを作るためにはどうしたら良いのか。

 

逆の視点で、全く意味の無いチームを考えてみる。意味のないチームというのは、すなわち個々人がバラバラに働いているのと同じ状態である。例えば、作業を分担しているだけ、など。

f:id:shoohnalmy:20180818164019p:plain

 

 

これに対して、意味のあるチームというのは、アウトプットが単なる分担よりも良い成果が出る状態であると言える。

f:id:shoohnalmy:20180818164553p:plain

横軸はアウトプットであって、人月で計算したときのインプットは同じときのイメージね。

 

知恵は足し算されない

ただ人をあつめれば良いのかというとそういうわけではなく。チームの能力というのは得てして、そのチームで最もスキルの高い人に依存するんですね。幼稚園児10000人でチームを組んでテストを解いても、東大に入学できるだけの点数は取れないけれど、優秀な高校生なら一人で東大入試を解ける。

知恵というのは足し算されないわけです。f:id:shoohnalmy:20180818171403p:plain

 

ひとつの目的を達成するためには、ひとりスキルの高い人がいれば解決するわけですね。

けど、当然知恵というのは複雑で、人によって得意なことも不得意なこともあるわけです。だからこそ、チームを組んで得意なことを活かしあい、不得意なことを補い合うチームが必要になってくるわけです。

チームの能力

得意なことを活かし合い、不得意なことを補い合う、というのはどういうことかというと、こんな感じ。

f:id:shoohnalmy:20180818172645p:plain

 

チームのスキルはメンバーの最大値に依存するので、営業の得意なAさんと開発の得意なBさんが補い合うとチームとしてはいい感じ。

逆に、補い合ってないとこんな感じ。

f:id:shoohnalmy:20180818172712p:plain

なぜゼネラリストが不要なのか

さてここでタイトルに戻ってもう少し複雑なチームを考えていく。たとえばデザイン力という新しい軸を取り入れて、デザイナーを入れるとこんな感じ。

f:id:shoohnalmy:20180818200923p:plain

これがたとえば、デザイナーの代わりになんでもできるゼネラリストが入ると、

f:id:shoohnalmy:20180818201245p:plain

デザイン力は上がらない。

これくらいだったらまだ良いけれど、スペシャリストがいなくなってぜねらりすとばかりになると、チーム力はどんどん下がる

f:id:shoohnalmy:20180818201416p:plain

しかも、最初のチームにゼネラリストが加わると、

f:id:shoohnalmy:20180818201614p:plain

となってくるわけです。

チームが大きく、専門家が多くなるほどにゼネラリストの居場所はなくなり、むしろ足を引っ張る側になっていくんですね。

本当に必要なゼネラリスト

とはいえ、ゼネラリストが役に立つタイミングはあって、それは複数のスペシャリストをつなぐ力がある時。

よくありがちなのは、「営業は全然技術のことをわかってない」「技術者は全然ビジネスのことがわかってない」みたいに、言葉が通じなくていがみ合うような光景。

こういうところで、間に立つ"通訳"として営業のこともわかるし技術のこともわかるゼネラリストというのが役に立ってくる。

言い換えると、ただ色んなことをかじっただけでは単なる器用貧乏。専門家の仲立ちができると使えるゼネラリストになっていく。

ゼネラリストというよりは、仲立ちのスペシャリストが求められるわけです。いわゆるマネージャー職とかの人たちに求められるのはこういうスキルですね。

 

日本企業に多い問題

日本企業の、多くの「総合職」とかの人たちにありがちなのは、全員でジョブローテーションしてゼネラリストを作っていく人事。ジョブローテーションは確かにゼネラリスト/仲立ちのスペシャリストを作るのには適しているんだけど、それだけではチーム全体のスキルが上がらないのは上で書いたとおり。

 

重要なのは、スペシャリストとその仲立ちの両方をバランスよく育てていくこと。「チームワーク」という言葉は、ただ単に仲良くしましょう、飲み会開きましょう、コミュニケーションしましょう、みたいな話ではなく。

個々人の専門性とその仲立ちのスペシャリストをちゃんと育てないと、どれだけ仲良くしても生まれるチームワークはたかが知れているのです。

まとめ

  • チームにおいてただのゼネラリストは無能
  • チームの能力はチームメンバーの最大値に依存する
  • 有能なゼネラリストはスペシャリストをつなぐスペシャリスト

という久々に真面目な話でした。

【読書記録】組織にいながら、自由に働く。

 

 はい、読みました。

働き方改革的な本。

 

著者は楽天大学学長、という肩書を持ちつつもよくわからない働き方をしている人。楽天のお客さんと遊ぶのが仕事、と自称している。

 

働き方には4つのステージがある、という持論フレームとその解説、という構成。4つのステージを「加」「減」「乗」「除」と表している。個人的には、加減乗くらいまではしっくりわかるのだけれど、除だけがイマイチわからないというか、腑に落ちない感じ。著者の周りでは「わかるわー」という感じらしいので、僕はまだそのステージにいけていないということだと思う。

加減乗除の触りくらいは

comemo.io

この記事にも書かれているので、そちらを呼んでもらえれば。

 

自分の周囲を見てみると、結構良い年いっていても、「加」のフェーズから抜けられない人がパラパラと見受けられるなあという感じがする。意識的に強みを見つけられていない人。

 

よくある自己啓発書とかとはちょっと違う雰囲気で、あんまり読んだことないタイプの本だと思う。結構自己啓発系のビジネス書って著者のひとりよがりというか、俺理論になりがちなところが多かったりするんだけど、ちゃんと抽象化して系統立てて整理されているのですごくわかりやすい。

 

多分、これを意識しながら仕事をしつつ、また数年後くらいに読み返すと新しい発見があるのだろうな。読み返そう。