For Your ISHIO Blog

データ分析や機械学習やスクラムや組織とか、色々つぶやくブログです。

1on1始めるぞー!のためのチェックシート

ゴールデンウィーク明けから、1on1をメンター側で始めることになりそうです。すでに組織に1on1は導入されていて、これまで私は部下の立場でマネージャーと週30分程度行っていました。

今後は立場を変え、「後輩(部下ではない)」との1on1を行っていく(たぶん)ですが、間違った運用を続けていると、組織と個人を破壊するので、過去に読んだ「ヤフーの1on1―――部下を成長させるコミュニケーションの技法」を読み直しました。

自分の考え含め、仕事中にカンニングするために、ブログ上でチェックシートという形で整理しておきます。

www.diamond.co.jp

1. 1on1は部下のために行う面談であることを忘れない。

1on1は、個人の経験学習を促すことが、一番の実施する意義。とはいえ、30分の対話が終わったときに、部下が「話してよかった」と思えれば、まず成功。業務についての相談の場になってもよい。例えば、なかなか上司が忙しくて話す時間が取れない等、それが部下にとって有意義な場であるならば。

2. 定期的に実施できているか

忙しいからといって、1on1を先延ばしにしてはならない。とはいえ、上司のカラダは1つなので、信頼関係が高まってきた部下は「2週間に一度」にするなど、粒度をつけて工夫するとよい。

3. 1on1内での対話の内容は、原則他人に話さない。

できるだけ安心してしゃべってもらおう。もしかしたらプライベートでの悩みがあるかもしれない。部下が良いコンディションで仕事に集中するためには、プライベートが安定していることも重要。

4. 部下に十分に話してもらえたか。

1on1は部下の行動や経験学習を深めることが目的。自分の経験を思い出し、言葉にして深い内省を促すために、部下側にたくさん話してもらおう。

5. アクティブリスニングの態度がとれているか

アクティブリスニングは、すなわち傾聴。部下が話しやすい雰囲気を作ってあげる。そのための安心感を与える動作を取る。信頼関係を構築するところから始める。

6. 部下の話を最後まで聞いているか。

部下に最後まで話をさせず、途中で遮って質問をしてはならない。部下本人が思い出し、学び行動することが重要。また、質問攻めにすることは、上司側の関心や興味に基づく質問であり、対話の内容は部下が本当に話したいことからずれていく。

7. 上司が先に自分の考えを言っていないか。

部下の言葉を先取りして、自分の考えていることを話し始めてしまっていないか。これでは部下の学びは深くならない。また、上司と異なる見立てを持っているとしたら、部下はそれを表明しづらくなる。

8. 1on1を評価のための面談にしていないか。

良い悪いの判断は避け、部下の想いや考えを深めるための問いかけをすべき。特に第三者が行うコーチングとは異なり、上司と部下の関係では、本音で話せないこともでてくる。より一層の安心できる・話しやすい雰囲気を醸成し、信頼関係を築く必要がある。

9. 否定は常にNGではないが、上手に否定しよう。

部下は上司の指示待ち人間になりかねない。上司依存になると、部下は考えなくなり、学びが深まらない。ただし、期待を持っている限り、言うべきことはしっかり言うことも大事。

10. 部下の次の行動まで、促すことができているか。

「いつまでにやろうか」「自分に手伝えることはあるか」など、部下の具体的な行動宣言まで支援できると善き。

11. 今日は何から話そうか。

テーマは部下側に決めてもらおう。それでも信頼関係ができていない最初は、話すネタが出てこないかもしれない。そのために、上司側もいくつかネタは持ち合わせておこう。

12. 1on1自体のプロセスも振り返ろうぜ。

1on1は結局のところ、個人と個人のコミュニケーションなので、書籍で読んだようにうまくいかないだろうし、人によってリアクションは違うだろうし試行錯誤が続くと思われる。1on1自体やそのプロセス自体も振り返りを行い改善していき、自身の態度などを改善していく必要があると思います。


現職場では、スクラムフレームワークで業務を行っているため、チームの振り返りは「スクラムイベント」、個人の振り返りは「1on1」という仕切りになるかと。ITの領域は進化のスピードが速いため、個人と組織が継続的に振り返り成長していくことがより求められるため、定期的・短期的に振り返りを促せる1on1の意義は大きいと思います。

直感・感覚値で作ってたData Visualizationから卒業する(したい)

データドリブンな組織を作るとか何とか叫びながら、あれ私データ可視化するとき、直感や感覚値だけで適当に色使いやらなんやら作ってるやん?と、ふと思ったのが勉強のモチベーションです。

『The Big Book of Dashboards』という書籍を読んでいます。グラフやダッシュボードを作りデータ可視化を行う上で、データを扱う人間が気を付けるべきことはたくさんあります。それは人間の脳の働きや色覚が異なる人への配慮、色の使い方やデータタイプなど様々です。こういった(恐らくデザイナーさんが普通に知っている)可視化テクニックを体系的に教えてくれる良書であると思います。 デザインや色の使い方を直感や感覚値で選んでいた私はとても参考になっているので、いくつか勉強になった観点を共有します

The Big Book of Dashboards [Book]

Anscombe's Quartet

「そもそもなぜデータの可視化をするのか」という疑問に対しては、アンスコムの数値例(Anscombe's Quartet)に説得力があります。統計学者のフランク・アンスコムさんが1973年に頑張って作ったらしい。実は、4つのグラフのXとYの平均・分散、XとYの相関係数も回帰直線も全て同じになります。実際にプロットしてみると、表や統計量だけでは把握できない情報が存在していて、視覚化により発見できることが理解できます。

f:id:ishitonton:20190405194457p:plain
The Big Book od Dashboards: FIGURE1.1

Preattentive Attributes

Preattentive Attributesは、日本語では前注意的処理とか言います。他のことに注意を払ったり、意識的にデータを理解しようとする前に、無意識に人間の脳がミリ秒単位でする処理のことを指します。この人間の脳の認識処理をうまく活用すると、情報をより効果的に理解させたり、相手の注意を引き付けたりすることができます。

例えば、次の図の中から「数字の9の数を数えてください」という質問に対して回答は簡単だと思います。ただし少し時間がかかると思います。この図に対して、Preattentive Attributesの処理を活かすように少しだけ手を加えると、質問に対する回答がずっと早くなります。

f:id:ishitonton:20190406151532p:plain
The Big Book od Dashboards: FIGURE1.3

次の図の場合はどうでしょうか。おそらく意識的に数字の9を探そうを試みる前に、赤字の数字9に注目したと思います。

f:id:ishitonton:20190406151634p:plain
The Big Book od Dashboards: FIGURE1.4

1つの色を視覚化に使用することは、1つのカテゴリを際立たせるために非常に効果的です。複数色を使う場合でも、カテゴリが少なければ十分識別に有効です。8~10個のカテゴリーがある場合は、色が多すぎて1つを他のカテゴリと識別することは難しくなります。おそらく感覚的には認識されていることだと思います。

上で出てきた色とサイズ以外にも、Preattentive Attributesに有効な特徴はたくさんあります。これらを効果的に利用することで、相手に効果的に情報を伝えたり、組織の意思決定を早くしたりできると考えます。

f:id:ishitonton:20190405201516p:plain
The Big Book od Dashboards: FIGURE1.10

How to Choose Color

「色」の使い方はデータの可視化において最も重要である一方、誤った使い方をされる要素の1つです。色は意図的に利用されるべきです。たとえば、読み手の注意を引きつけたり、データの一部や異なるカテゴリの間の区別を強調したりすることです。

次の図では、色の主要な使い方が説明されています。Sequential(連続)Diverging(発散)Categorical(カテゴリー)Highlight(強調)Alert(警告)です。

f:id:ishitonton:20190406154853p:plain
The Big Book od Dashboards: P15

Sequential Colorは、1種類の色に対して、色の明るさを変更し、グラデーションで表現します。

Diverging Colorは、中間に分岐ポイントを設定し、その中間点からそれぞれ2色のグラデーションを利用して表現します。例えば、ポジネガの可視化などにおいて、ニュートラルをグレーとし、そこからポジティブな値は青のグラデーション。ネガティブな値は赤のグラデーションで表現したりします(ポジ/ネガにどの色を使うかも重要です。西洋文化では、左記に挙げた色使いが一般的で、色だけでポジネガの印象を与えます)。他には、気温の可視化などでは、寒いときは青、暑いときは赤を利用したりしますね。

Categorical Colorは、異なるカテゴリ間で表現を区別するために色を分けて利用します。

Highlight Colorは、読み手に何か情報を際立たせる必要がある時に利用します。ただし、警告や警報以外の用途になります。この色の使い方には様々な方法があります。その一例を以下に示します。

  • 特定のデータポイントのハイライト

  • 表内のテキストのハイライト

  • 折れ線グラフ上の特定のラインの強調表示

  • 棒グラフ内の特定の棒を強調表示

最後のAlert Colorは、読み手に警告を与えるものであり、すぐに注意を惹けるような、明るいアラーミングカラーを利用します。

Color Vision Deficiency

Color Vision Deficiency(CVD)は、日本語だと色覚異常色盲などと訳されます(※専門家でないので誤っていたらご指摘ください)。CVDをもつ人は、色は見えるが大多数の人と見え方が異なっていたり、特定の色を区別できない。本書籍だと女性で0.4%、男性で8%ほど、程度は違えどCVDであると記載されています(※色彩検定のHPには異なる数字が記載されている)。 大企業に勤めていて、大勢の人が可視化したダッシュボードを見る場合や、可視化した情報を一般公開する場合には、無視することはできません。色の見え方は多様であることを理解し、多様な人間が苦なく正確に情報を理解するためには、CVDの人がどのように色を区別しているかの知識を持つ必要があります。

私自身もこれから勉強を始める身ですが、CVDにも様々なタイプがあり一概に全員が同じ傾向にあるとは言えないようです。例えば、protanopia(=red color blindness)Deuteranopia(=green color blindness)Tritanopia(=blue color blindness)などのタイプがあります。

一般的には赤と緑の間の区別に問題を抱えると記載されています。赤と緑を一緒に利用しないことがベストな可視化方法であり、つまり一般的に、信号機色の同時利用を避けるべきです。

下記の図は、左が信号機の色を利用したグラフで、右がCVD(Protanopia)がどのように見えているかをシミュレーションしているものです。信号機のカラーパレットは多くのソフトウェアで普及しており、今日のビジネスで一般的に使用されているため、議論の種の1つです。

f:id:ishitonton:20190406162441p:plain
The Big Book od Dashboards: FIGURE1.24

解決策として、本書ではColor-blind-Friendlyなカラーパレットの知識が手に入ります。一般的な解決方法としては、緑の代わりに青、赤の代わりにオレンジを利用することです。下記の図は、Color-blind-Friendlyな色を利用した場合のCVDの見え方です。

f:id:ishitonton:20190406163845p:plain
The Big Book od Dashboards: FIGURE1.25

まとめ

『The Big Book of Dashboards』には、より細かく、様々なシナリオにおける可視化のテクニックや注意すべき知識が述べられています。今まで感覚でなんとなくやっていたことが体系的な知識として獲得できると思いますので、大変お勧めです。データを扱う人間であれば知っていて損はないと思います。

とりあえず、私自身は、色彩とかCVDに関する知識を身に付けたいモチベが高まっているので、そこらへんの資格をとる勉強をしようと思います。

以上です。

Hadoop / Spark Conference 2019 参加メモ

3月14日(木)にHadoop / Spark Conference 2019が開催されました。このイベントの参加メモになります。

hadoop.apache.jp

目次

同イベントは毎年開催されているわけではなく、近年は開催されていなかったらしい。そんなわけで「Hadoopはオワコンなんだね」と巷では認識されることもあるが、ちゃんと進化してますぜ!ということをこのイベントではアピールしたいらしい。(※旧MapReduceは確かに下火ですが、HDFSはバリバリ活躍中ですよね。)

Hadoop/SParkの初心者の方は以下の勉強会資料をご参考ください。 speakerdeck.com

プログラム

黄色線が引かれた講演を、私自身は聴いてきました。いくつか本ブログでも共有したいと思います。

f:id:ishitonton:20190315211623p:plain
プログラム

1. Hadoopの現在と未来:鯵坂 明さん、Arpit Agarwalさん

Hadoopの利用状況」に関する事前アンケート結果

※あくまで参加者のアンケート回答であり、正しい現状を示しているとは限らないので注意してください。

  • Hadoop利用者の1/4くらいはHadoop 3系を既に利用。2系から3系へと検証/導入が進んでいる。
  • オンプレミス環境での利用者が60%くらい。オンプレ優勢もクラウドでの利用ユーザが拡大している。
  • クラスタ数は~10台と小規模なクラスタ構成が45%程度と多い。

Hadoop 3系がリリースされたのは、確か2017年の12月くらいだったと思うので、この1年ちょっとで徐々に浸透し始めているということだと思います。

f:id:ishitonton:20190315213322p:plain

並列分散処理の取り巻く動向

現在の並列分散処理の取り巻く動向としては、下記4つが挙げられており、この動向を受けて、Hadoopエコシステムも進化を続けている模様。

  1. クラウドサービスでの利用が増加
  2. データ量/計算量の増加
    • スケーラビリティの限界突破が進んでいる。
      • HDFS/YARN Router-based Federationクラスタを束ねることで、マスタの負荷を軽減(クラスタを束ねる機能?)
      • OZONE:オブジェクトストレージ機能の開発。
      • HDFS Erasure Coding:ディスク節約。(データローカリティがなくなるが、あまり問題にならなくなってきている。)
  3. 機械学習、深層学習の浸透
    • Submarineというサブプロジェクトが進んでいる。これは、YARNの最新機能をフル活用して、TensorflowやPytorchなどの深層学習フレームワークHadoop上で分散実行させる。
    • GPU isolation、Docker on Yarn、Container DNS support
  4. コンテナ技術の発展

個人的には、TensorflowやPytorch等のカバーを目指している点に注目。

オブジェクトストレージ機能『OZONE』の紹介

  • Ozoneは、HDFS上にオブジェクトストアを実装し、(⁠Amazon S3やAzure Storageのような)オブジェクトストレージとして利用可能にする技術。HDFSの良い部分はそのままに、HDFS併用可能かつ移行可能な技術。
  • 「多数のオブジェクトを格納したい」、というHDFSが苦手とする領域をカバーする目的で開発が進んでいる。
  • 現在はまだアルファ版。今後ベータ版も出す予定。Hadoop/Sparkのエコシステムはそのまま利用可能。

www.slideshare.net

2. The upcoming Spark 3.0: What’s Next:猿田 浩輔さん、Xiao Liさん

Sparkに関するこれまでの振り返りと今後の展望について共有がなされました。

振り返り

2018年の12月末にはSpark2.4がリリースされている。Sparkは、Unified Data Processing Engineとして着実に進化。バッチ処理、ETLでの活用が依然として多いが、新たに「IoTやアナリティクス領域」でのデータ活用を取り込めている。Spark2.0以降では、これらのデータ活用に即した機能追加も行われた(ex:Structured Streaming/Pythonからの利用における利便性向上/PandasUDFなどの拡充)。詳しくは下記資料にまとめられています。

medium.com

一方で、現在の課題としては「AI領域の需要取り込み」が挙げられます。昨今は機械学習Deep Learningがトレンドとなっているが、この領域の活用を取り込めていない現状があるとのこと。

Spark3.0の展望について

CIOへの調査報告によると、AI分野への投資が増加しているが、成功例は少ない。Unified Analyticsが成功のカギと言っている。79%のCIOがUnified analytics Platformとして、データサイエンスとデータエンジニアリングの統合を評価しており、AI領域においても、AIとデータの統合的なアプローチが期待されている。これを受けた下記のような展望。

  1. Project Tungsten

    • メモリの利用効率改善やモダンなCPU機能の活用によりCPUネックの解消を行うプロジェクト。
    • 分散実行されるDeep LearningのジョブをSparkのStageとして埋め込むために、ギャングスケジューリング機能を追加する。これにより分散学習のワークフローが簡素化される。
  2. MLflowの導入

    • 機械学習のライフサイクル(前処理×モデル評価×デプロイ)は手作業が多くて統一性がない。これを統合化する取組み。
      • パラメータやメトリクス等のトラッキング
      • 管理(依存ライブラリ管理、バージョン間のトラックなど)
      • モデルのパッケージング
  3. Data Source API 2.0
  4. クエリ実行時の再最適化
    • クエリが完了した後の統計情報をもとに、実行計画を再最適化させる

github.com

software.intel.com

3. Cloud-Nativeなデータ分析基盤におけるPrestoの活用:廣瀬 智史(SmartNews, Inc.)

既に資料は公開されています。

speakerdeck.com

2014年当時は、Amazon S3上のデータをMapReduce処理してMongoDBに蓄積していた。課題としては、データを気軽に分析できる環境ではなかったこと。新しい集計処理が必要になる度にMapReduce処理を追加する必要があったし、新たな可視化ニーズの度にアプリケーションの修正が必要になっていたとのこと。

そこで、「Amazon S3 + Presto + Hive」の構成に変更。ETL/バッチ処理はHive(Hive metastoreのデータを参照)、リアルタイムデータ集計はPrestoを利用。これにより、ストレージとコンピューティングリソースを分離することができ、またSQLを書けば、誰でもデータ分析できるようになった。

また、利用用途ごとに要求が異なるため、クラスタを使い分けて利用している(例えば、広告配信はシビアな要求が求められるが、ニュース配信はそこまでではない)。これにより依存性を局所化しているが、その結果データが分散する状況にもなる。そこで複数のデータソースに対するリクエストを可能とする「Presto」をインタフェースとして利用し、この問題を解決している。 また、EMRではなくEC2上にPrestoクラスタを構築することで、デフォルトのPrestoには存在しないコネクターや、独自のファンクションの追加を行っている。Prestoは開発が盛んなので、最新版を試せる環境にしておきたいとのこと。

4. DataFrameとDatasetの内部をのぞいてみる:石崎 一明(日本アイ・ビー・エム

資料公開されています。個人的にとても面白かったです!!

www.slideshare.net

Sparkで実装する上で、RDDやDataFrameやDatasetなどの選択に迫られる。DataFrameはSQL由来なのでループ処理の記述が難しいが、一方DatasetはScala由来なので簡単に記述できる。ただし、同じ処理でもDatasetはDataFarmeと比較して処理が非常に遅い、という二者択一状態。機械学習アルゴリズムを記述する場合、ループ処理が書けないと結構大変なので、Datasetの処理性能改善を加えていっている、という話。Spark2.2以降でだいぶ改善されている模様。 Sparkの仕組みとして、DataFrameやDatasetは様々な最適化(Catalyst)の末、最終的にJavaのコードを生成する。PythonとかScalaのまま実行されるわけではない。それぞれ最適化の仕方が異なるので、処理性能に違いが生じる。 DatasetとRDDでは、現状は性能差があるため、SparkのMLアルゴリズムではほとんどRDDへの変換後に実行されているのが実情(?)。本来はRDDへの変換にオーバーヘッドコストがかかるため本当はやりたくない!でも現状はまだまだRDDがメインストリームということなのだろうか。

5. スキーマレスカラムナフォーマット「Yosegi」で実現するスキーマの柔軟性と処理性能を両立したログ収集システム:井島 洸二さん

資料公開されています。

www.slideshare.net

ヤフーで日々発生する多種多様なサービスのログは、リアルタイムに収集しHDFSに格納している。データを利用するデータサイエンス部門が試行錯誤を繰り返すために、ログの仕様変更(つまりスキーマの変更)が日々行われる(らしい)。

スキーマ定義には2つの方法がある。

  1. Schema on Read:利用時にスキーマを定義する
    • 収集時に制約が少ない/保存時の効率化が難しい
  2. Schema on write:保存時にスキーマを定義する
    • 収集時に制約が多い/保存時の効率化が容易

ヤフーでは、Schema on Readを採用。理由は多種多様なサービスからログが生成されるため、スキーマ定義のコストが大きいため。一般的には、JSONファイルなどが利用される。

一方で、カラムナフォーマットについても検討する必要がある。カラムナフォーマットは、データベースの分析用途に利用されるファイルフォーマットの1つ。大量データを扱う際に効率的に圧縮してストレージコストを下げたり、計算時に必要なデータだけを取り出して計算コストを小さくできる設計がされている。代表的なフォーマットにはORCやParquetがある。カラムナフォーマットへの変換には、事前のスキーマ定義が必要になる。

このように、多様なスキーマにはJSON、膨大なログ量にはカラムナフォーマットが選択肢としてあるが、スキーマの柔軟性と処理性能はトレードオフの関係にある。そこで、スキーマレスカラムナフォーマット「Yosegi」を開発したという話。スキーマの柔軟性と高い処理性能を両立しつつ、スキーマ管理が不要なログ収集システムを実現しているようである。YosegiはGithubでも公開されている。

github.com

5. Apache Kafkaって本当に大丈夫?~実際にいじめてみたのでお伝えします~:土橋 昌さん

正直、知見があふれまくってたので。資料公開をお待ちしています。この発表では、Kafkaの障害における様々な検証をしてくれています。

Kafkaは、データハブとして、ストリーム処理のパイプラインとして、そしてスケーラブルなメッセージングキューとして利用されるメッセージングシステムです。Consumer、Broker、Producerで構成され、さらにZookeeperを利用してHA構成を取りますが、それぞれのコンポーネントが故障した時に、Kafkaの挙動はどうなるのかを実際に各コンポーネントに障害を起こして検証しています。バージョンの違いでKafkaの構成は異なってくるため、一概にこの検証がそのまま役に立つわけではないと思いますが、検証結果や検証項目の考え方は非常に勉強になるものでした。

故障検証のサマリーとしては、公式ドキュメントに記載されたアーキテクチャから想像される挙動とおおむね合致するが、実際の挙動のうちZookeeperのアンサンブル故障と、データファイル(ログファイル)の異常については特に注意したほうが良いよ!という内容でした。

f:id:ishitonton:20190317212939p:plain f:id:ishitonton:20190317213007p:plain

ShakeDownを食らったMicrosoft Malwareコンペを振り返る

KaggleのMicrosoft Malware Predictionが終了しました。参加した皆さん大変お疲れ様でした。 これまでもつまみ食いはしつつも、今回初めてKaggleコンペに本格的に参加しました。少し期待していたのですが、Publicでソロ銅圏(150位)からPrivateで840位と大幅なShake Downを食らい悲しいし恥ずかしい。 一方で、Kaggleコンペに参加したことで多くの学び・教訓を得ることができました。失敗や経験を次につなげるためにも、本コンペを通じて学んだことを振り返っておきたいと思います。

技術的な学び

今回のコンペの特徴は下記であったと考えます。

  1. 大規模なデータ
  2. 訓練データとテストデータの分布が異なる
  3. (結果的に)テストのPublicデータとPrivateデータの分布が異なる

こういった特徴の中で出会った学びについて書いていきます。

メモリ載らない問題

大規模データであることから、私の環境ではDataFrameがメモリ上に載らない事案が発生し、メモリ節約の必要性が出てきました。そこら辺に関しては、自身もブログに記したほか、えちさんのブログで知ったreduce_mem_usage()関数でデータ型を最適化する等により対処をすることができました。

ishitonton.hatenablog.com

amalog.hateblo.jp

仮説検証サイクル遅くなる問題

Kaggleに限らず、いかに仮説検証を効率的に高速に回せるかが非常に重要だと思います。 今回のコンペが大規模データセットであることから、仮説検証サイクルが遅くなることに遭遇しました。より高速にサイクルを回すために、Feather形式での特徴量管理やデータの入出力する等のアイデアをもらい試しました。

amalog.hateblo.jp

訓練データとテストデータの分布違う問題

訓練/テストデータの分布が違う点に関しては、ディスカッションにも出ていましたが、私はAdversarial Varidationを試しました。訓練データとテストデータを判別する95%くらいの精度の2値判別モデルを構築。そのモデルを訓練データを対象に推論し、テストデータのProbavility Scoreを生成しました。テストデータの確度が高いと判別された訓練データを検証データとして、モデルの学習を行いました。

ただし、結果的に大幅なShakeDownを食らったことをみると、Adversarial Varidationのプロセスに何かしら問題があったか、テストデータの中でもPrivate/Publicデータの分布が想像以上に異なりPublicに過学習していたのか。いずれにしても自分の勉強不足以外のナニモノでもないですが、上位者の解法が出てきたらヒントを得たいと思います。 なお、Adversarial Varidationやそのほかvalidationの重要性については、u++さんのブログで勉強させていただきました。

upura.hatenablog.com

upura.hatenablog.com

特徴量生成について

今回自分は3つのモデルを組み合わせて最終的なsubmissionを生成していました。Non Tree Based Modelが1つとTree based Modelが2つです。これらのモデルのタイプに応じて、特徴量生成のケアや前処理方法は異なるため、改めて整理することが出来ました。前処理についてはCourseraのKaggleコースで勉強し、その内容の一部をアウトプットしました。

ishitonton.hatenablog.com

www.coursera.org

特徴量選択について

特徴量選択についてはかなり勉強不足で、今回の敗因の大きなウェイトを占めている気がします。 u++さんがブログに記載してくれたコルモゴロフ-スミルノフ検定を利用した特徴量選択とかを試したりしたが、私のモデルではモデル説明力が失われたように見え、残念ながら有意義な仮説検証に至りませんでした。

今後は『機械学習のための特徴量エンジニアリング』読んで勉強したいと思います。Adversarial ValidationでFeature Importanceがものすごく高い特徴量が何個かあったのだが、それ抜いたらスコア上がっただろうか。

upura.hatenablog.com

技術面以外の自身の内省

どこで満足するか

今回、自分は締切り1週間前の段階でソロ銀の状態にいました。その段階でかなり満足している自分がいたことを認識しています。その結果ラスト一週間でのsubmissionはかなり惰性的なものであり、全く進捗なく締め切りを迎えました。

一方で、トップ層では日本のKagglerの皆さんが最後までさらにスコアを挙げようと邁進していたことを横目で見ており、自身の精神面での未熟さを痛感しました。 どこで自身が満足するかは、Kaggleに限らず人生のあらゆる局面で自身に課せられる問いであり、仕事においてもプライベートにおいてもKaggleにおいても、この未熟さを改善したいと感じた次第です

学び多し犠牲もあり

KaggleのKernelやDiscussionを理解することで、多くの学びを得ることができました。結果よりこの学びの方が、自分の仕事にもポジティブな影響を与えてくれるかもしれない。 一方で、自分の性格上Kaggleを頑張ると他の様々な学びの機会を犠牲にしていることも理解しました。感覚的には、一時期ビットコインを購入して一攫千金を狙ったことがあるが、夜中も推移が気になり寝れなかった感覚に似ている。時に自身のライフサイクルを逸脱し、知的好奇心が一極集中。

その傾向を認識した上で、今後も参加したい!!

最後に

改めてDiscussionを見てみると、同じく大幅なShakeDownを食らっているolivierさんが、Conglatulationsというスレッドを立て上位者を祝福している。素晴らしい。自分も、自分がダメでも周りを称え、コミュニティに貢献できるスキルとマインドと懐の広さを持ちたいと思う次第です。

f:id:ishitonton:20190314191403p:plain
https://www.kaggle.com/c/microsoft-malware-prediction/discussion/83990

以上です。

モデリングのための特徴量の前処理について整理した

久しぶりのデータ分析関連の記事を書きたく、モデリングを行う上での特徴データの前処理について整理しました。本投稿は、下記courseraのKaggleコースの受講とその周辺情報のインプットを整理したものです。より詳細かつ正確な内容については受講してください。

www.coursera.org

目次

前処理の分類

データの前処理には様々な技法が存在するが、自身が利用する「予測モデルのタイプ」×「データ型」により、その処理や特徴量生成方法は大きく異なると認識している。

この文脈における教師あり学習の「予測モデルのタイプ」は、大きく次の2つに大別される。

  1. Tree Based Model
  2. Non Tree Based Model

Tree Based Modelは決定木やランダムフォレスト、AdaBoost等を、Non Tree Based Modelは線形モデルやKNN、Neural Network等を指している。

また、データセット上には、下記のような様々なデータ型が存在する。これらをモデルが識別可能な形式に処理する必要がある。

  1. Numeric(数値データ)
  2. Categorical(カテゴリカルデータ)
  3. Ordinal(順序付きデータ)
  4. Datetime(日付、時間)
  5. Coordinates(座標)

また、本投稿では割愛するが、データセット上には一般的に欠損値が存在する。欠損値もモデルによって処理方法が異なるために注意する必要があるし、そもそもデータセットには、分析者の意図しない/認識しえない範疇で、既に欠損処理された値が埋め込まれている可能性がある。これらを可視化し明らかにし、モデルに合わせてエンコーディングする必要性もある。

以降では、具体的な各データ型における前処理方法について、整理していく。

Numeric(数値)データ

Numericデータにおいて注意すべき1つに、Scaling(スケーリング)がある。Scalingとは、「特徴量の取りうる値の範囲(スケール)を変えること」をさす。例えば、体重と身長、価格と数量では、単位と値の範囲が異なる。特徴量間で極端に異なるスケールのデータセットのままでは、うまく学習できない可能性があり、スケールを揃える必要がある。一般的にTree Based ModelモデルではScalingに依存しないが、Non Tree Based Modelの場合には予測に失敗するか悪影響を及ぼす。

Scalingの影響に関して、Non Tree based Modelに含まれるKNNを利用した例を1つ挙げる。2つの数値データを特徴量としたデータセットにおいて、「オレンジのデータがAとBのどちらと同じグループに含まれるか」のクラス分類を考えてみる。データ間の距離(類似性)をユークリッド距離で計算する場合、左の図ではBとの距離が近くなるために、Bと同じグループに分類される。次に特徴量Xを100倍にしたとする。その結果オレンジのデータはAとの距離が近くなり、Aと同じグループに分類されるだろう。これは相対的に特徴量Xの影響力を肥大化させ、特徴量Yを無視することに繋がる。

f:id:ishitonton:20190223101652p:plain
KNN(Non Tree Based Model)でのクラス分類

逆に、特徴量Xにゼロを掛け合わせたらどうなるか。上記の例ではKNNは特徴量Xを無視することになる。以上はKNNの例だが、線形モデルでもNeural Networkでも勾配降下ベースの最適化に依存するモデルについては、適切なScalingがなされていない場合には、予測結果に悪い影響を与える可能性がある。

特徴量のScalingの方法はいくつか存在する。

  1. Min Max Scalar
  2. Standard Scalar
  3. Outliers(外れ値)への対処
  4. rank transformation
  5. log transformation/square transformation
1. Min Max Scalar

最も直感的かつ簡単なScalingの方法。全ての特徴量の値を同じスケールに変換することである。全ての値から最小値を引き、MinとMaxの差で割る。その結果、値は0から1となる。 デメリットは、0から1の範囲に値を収めるため、標準偏差が小さくなり、外れ値の影響が抑制されること。

SklearnのMinMaxScalerでは、次の変換により行われる。

X_std = (X - X.min(axis=0)) / (X.max(axis=0) - X.min(axis=0))
X_scaled = X_std * (max - min) + min

なお、sklearnのドキュメント内の説明では、This transformation is often used as an alternative to zero mean, unit variance scaling.と記載があり、次に挙げるStandard Scalarの代替手段として利用されるのだろうか。

sklearn.preprocessing.MinMaxScaler — scikit-learn 0.20.2 documentation

2. Standard Scalar

この変換処理では、平均0、分散1の標準化された分布を得ることができる。標準化(standardization)と同義。まず、平均値を引くことで0前後の値とする。次に、値を標準偏差で除算して、結果の分布が平均0、標準偏差1の標準となるようにする変換方法である。代表的なパッケージとしてはsklearn.preprocessing.StandardScalerがある。

ここでも外れ値には要注意。Standard Scalerでは、平均値と標準偏差を計算する際に外れ値が影響を及ぼし、特徴量のrangeが狭まります。特に、各特徴量の外れ値の大きさが異なるため、各特徴量の変換データの広がりは大きく異なる可能性が出てくる。このように、外れ値が存在する場合にバランスの取れたScalingが保証できない

下記記事も参考にしました。

python - Difference between Standard scaler and MinMaxScaler - Stack Overflow

Standard Scaler v Min Max Scaler in Machine Learning - All Things Software, Data Science and Technology

Feature Scalingはなぜ必要? - Qiita

3. Outliers(外れ値)への対処

Min Max ScalarやStandard Scalarにおいても、外れ値の影響について述べたが、特に線形モデルでは、外れ値の有無が予測精度に大きく影響を与える。これらに対処するために、下限と上限を決め、2つの選択された値の間で特徴量を切り取る方法などがとられる。Kaggleコース内では、特徴量の分布の中から1%~99%のデータを切り取る方法が提案されている。

Scipyのwinsorizationモジュールを利用すると、データから切り取ったデータを返してくれる。

scipy.stats.mstats.winsorize — SciPy v0.14.0 Reference Guide

4. rank transformation

特徴量内の各値の間隔が等しくなるように、数値の順序を保って数字を振り直す方法。例えば、外れ値が存在する場合には、外れ値を他の値に近づける効果があるためMin Max Scalerよりも有効な手段となる。チキチキ外れ値の処理をやっている時間がない場合には有益。

ただし、テストデータへの適用時には注意が必要。事前にTrainデータとTestデータを連結してrank transformationを行うか、もしくが特徴量とランク値のmapping情報をストアしておく必要がある。

rank transformationには、scipyにはrankdataモジュールが提供されている。値が等しいときに、どのようにランクを割り当てるか、いくつかオプションが用意されている。

>>> from scipy.stats import rankdata
>>> rankdata([0, 2, 3, 2])
array([ 1. ,  2.5,  4. ,  2.5])
>>> rankdata([0, 2, 3, 2], method='min')
array([ 1.,  2.,  4.,  2.])
>>> rankdata([0, 2, 3, 2], method='max')
array([ 1.,  3.,  4.,  3.])
>>> rankdata([0, 2, 3, 2], method='dense')
array([ 1.,  2.,  3.,  2.])
>>> rankdata([0, 2, 3, 2], method='ordinal')
array([ 1.,  2.,  4.,  3.])

scipy.stats.rankdata — SciPy v0.16.1 Reference Guide

5. log transformation/square root transformation

多くのモデルは、正規分布を仮定していることが多いので、対数変換により正規分布に近似させる。データを正規分布に従わせる以外にも、外れ値が含まれるデータの分散を小さくするためにも使われる。すなわち、対数変換により極端に大きすぎる外れ値を平均値に近づける。これに伴い、ゼロに近い値をもう少し区別しやすくなる。特徴量の平方根を取る方法も同様の効果が見込める可能性がある。Non Tree Based Modelの中でも、特にNeural Networkで有効。

なお、下記のブログでは、場合によっては分散が増大するケースがあることも書かれている。 yolo-kiyoshi.com

Categorical / Ordinalデータ

Categoricalデータとは、統計用語集によると、質的データと同義で、名義尺度や順序尺度のデータをさす。Ordinal(順序付き)データは、Order Categoricalデータとも呼ばれ、Categoricalデータに含まれる。 Categoricalデータは、性別(男性/女性)や出身都道府県(北海道/青森県岩手県...)、チケットのクラス(エコノミークラス/ビジネスクラス/ファーストクラス)などが該当する。ここでチケットのクラスは、一般的に大小には意味があるが、間隔には意味がないデータであり、Ordinalデータに含まれるだろう。すなわち、チケットのクラスがNumericデータである場合、「エコノミー(1)とビジネス(2)」の差異と「ビジネス(2)とファースト(3)」の差異は等しいと解釈される。Ordinalデータでは、どちらの差異が大きいかはわからない。

Categoricalデータの一般的なエンコード方法は下記のとおりです。

  1. Label Encoding
  2. Frequency Encoding
  3. One-Hot Encoding

上記以外にも、最近ではTarget Encodingなどの手法もKaggleではよく利用されている。

1. Label Encoding

Ordinal featureの最もシンプルなエンコード方法であり、この特徴量のユニークな値を異なる数値にマッピングする方法である。Ordinalデータに限らず、Label EncodingはKaggleのCompetitionでのベースモデルとして、とりあえずCategoricalデータを全てLabel EncodingしているKernelをよく目にする。それほど、最も簡単な方法の1つである。Label EncodingはTree Based Modelでうまく作用するが、逆にNon Tree Based Modelでは効果的ではない

Label Encodingのラベル方法には、次の2通りがある。

  1. alphabetical order
  2. sorted order

alphabetical orderは、SklearnのLabel Encoderモジュールのデフォルトである。すなわち、アルファベットや数字の順序に準拠し、ラベルを振り直す。

>>> from sklearn import preprocessing
>>> le = preprocessing.LabelEncoder()
>>> le.fit([1, 2, 2, 6])
LabelEncoder()
>>> le.classes_
array([1, 2, 6])
>>> le.transform([1, 1, 2, 6]) 
array([0, 0, 1, 2]...)

>>> le = preprocessing.LabelEncoder()
>>> le.fit(["paris", "paris", "tokyo", "amsterdam"])
LabelEncoder()
>>> list(le.classes_)
['amsterdam', 'paris', 'tokyo']
>>> le.transform(["tokyo", "tokyo", "paris"]) 
array([2, 2, 1]...)

sorted orderはpandasのfactorizedモジュールで実装される。値が出現する順序でラベル付けを行う。 既にデータが何かしら意味ある方法でソートされている場合に有効となる。

>>> import pandas as pd
>>> labels, uniques = pd.factorize(['b', 'b', 'a', 'c', 'b'])
>>> labels
array([0, 0, 1, 2, 0])
2. Frequency Encoding

カテゴリーが出現する頻度にデータを置き換えるエンコード方法であり、Tree Based Modelで有効。カテゴリーの頻度がTargetデータとの間に相関がある場合には、線形モデルにおいても効果がある。

注意すべき点としては、仮に複数のカテゴリーで同じ頻度を持つ場合、それらの値を持つデータを区別をすることができないため問題になる可能性がある。この場合の対処として、下記サイトにはwill need to change it to ranked frequency encodingと記載されている。当初、ranked frequency encodingとはよくわからなかったが、恐らくFrequency Encodingとは別に、Label Encodingの特徴量も用意すれば、Tree Based Modelであれば分割可能だということだと思う。

### FREQUENCY ENCODING

# size of each category
encoding = titanic.groupby('Embarked').size()
# get frequency of each category
encoding = encoding/len(titanic)
titanic['enc'] = titanic.Embarked.map(encoding)

# if categories have same frequency it can be an issue
# will need to change it to ranked frequency encoding
from scipy.stats import rankdata

4. Feature Preprocessing & Generation — Data Science 0.1 documentation

3. One-Hot Encoding

One Hot Encodingについては、カテゴリー変数をアルゴリズムが学習しやすいように0と1で表現する方法。エンコード方法には、sklearnのOneHotEncoderモジュールやPandasのget_dummiesメソッド等がある。

One-Hot Encodingは既に最大値1、最小値0にスケーリングされており、Non Tree Based Modelに適用する場合に有効。One-Hot Encodingは、カテゴリー数だけバイナリデータが特徴量として生成される。これは1つの特徴量を効率的に分類しようとするTree Based Modelでの分類を困難にする

次のブログで、Tree Based ModelでOne-Hot-Encodingを実行したプロセスの図が描かれているが、直感的に効率が悪いことが確認できると思う。

f:id:ishitonton:20190224173803p:plain
Visiting: Categorical Features and Encoding in Decision Trees

Visiting: Categorical Features and Encoding in Decision Trees

Categoricalデータにユニーク値が多く含まれている場合には注意が必要である。One-hot Encodingによって、ほとんどゼロの値を取る大量の特徴量が生成される。これらのデータを効率的に利用するために、Sparse Matrixが有用。RAM上に、すべてをStoreせずに、Non-Zeroの要素だけを保存し、メモリを節約できる。目安としては、カテゴリー内の全ての値の半分以上がゼロであるときに有用。XGBoost、LightGBM、sklearnなど、一般的なライブラリのほとんどでSparse Matrixは利用可能。

Lasso on dense and sparse data — scikit-learn 0.20.2 documentation

Sparse matrices (scipy.sparse) — SciPy v1.2.1 Reference Guide

Sparse Matrixを用いたLightGBMの例

LightGBM. Baseline Model Using Sparse Matrix | Kaggle

Datatimeデータ

Datetimeデータの特徴量生成方法には、大きく2つの方法がある。

  1. 期間内のある瞬間の情報
  2. 特定のイベントからの経過時間
1. 期間内のある瞬間の情報

ある期間(1カ月/1年)における週、秒、分、時、日といったデータを追加することができる。これらは、データ内の繰り返しのパターンを捉えるのに有効。例えば、毎月20日は給料日である場合、その繰り返しの情報は、支払いや売上の予測に有効かもしれない。

2. 特定のイベントからの経過時間

ある瞬間からの経過時間に関する情報である。その「ある瞬間」とは、固定の場合と変動の場合がある。前者の例でいえば、「2019年1月1日から経過した日数」が特徴量となる。後者の場合、「日曜からの経過日数」や「前回のセールからの経過日数」などレコードに依存する情報となる。

また、複数のdatetimeデータを保持してている場合には、datetimeデータ同士の差分情報を特徴量として生成することも有効な場合がある。

Coordinatesデータ

座標データは、これまで挑戦したことがないので簡易的な記述とさせていただくが、特徴量生成方法には次の2つが一般的。

  1. 距離の計算
  2. 統計データの利用
1. 距離の計算

仮に地図上に何か重要な地点が存在する場合に、その重要地点との距離を計算し特徴量とする方法である。例えば、もし建物の位置に関する追加データがある場合には、そこから最も近い店舗の距離を計算し特徴量として追加できる。 追加データがない場合にも、様々な工夫により、特徴を生成することが可能である。以下に例を挙げる。

  • 対象のエリアをさらにサブエリアに分割(クラスタリングやグリッド線での分割)し、各サブエリア内で最も高価な建物を代表点と定める。そして代表点までの距離を計算し特徴量とする。
  • サブエリアの中心地点からの距離を計算する。
2. 統計データの利用

オブジェクト周辺エリアの統計データを利用することも有効である。例えば、そのエリアの平均家賃の計算など。

おわりに

もし間違っている箇所があればご指摘下さい。長くなってしまったが、欠損値についてもいつか整理したい。

チームの暗黙の了解をWorking Agreementとして定めた話

自分では当たり前と思っていたけど、隣のメンバーは知らなかった・違う認識を持っていた。仕事をしていてそんな経験はありませんか。

私は、個々人が創造性と情熱をもって、自律的に働ける組織こそが、最大限のパフォーマンスを発揮できると考えています。そのための環境作りの1つとして、我々が取り組んでいるWorking Agreementについて書きたいと思います。

Working Agreementとは

Working Agreementとネットで検索すると、おそらく色々な記事が出てくるかと思いますが、私は次のように定義しています。

共に働く上での非公式の合意事項

例えば、クライアントとの取引や各従業員の雇用等の関係性については、契約書があり文書で明文化されており、私は「公式」的な合意事項のくくりに含んでいます。

一方で、組織に属しチームとして共に働く(=生活する)上中で、特に書面で合意したわけでもないし、雇用契約条項に書かれているわけではないけど、いつの間にか「暗黙の了解」として皆が従っている様々な決まりごとが出てきます。 例えば、、(今考えている)

  • 週に1回、チームの誰かがルンバを回す
  • 喫煙者は、毎回ファブリーズをする
  • 生ごみはこっちのゴミ箱に捨てずにあっちのゴミ箱に捨てる
  • 帰宅時は、メンバーに一声かけよう。
  • 空調の調整方法について
  • とかとか。

こういったものを我々は「非公式の合意事項」と考えており、どちらかというと仕事の内容ではなく職場環境や生活する上での合意事項を集めて合意した文書がWorking Agreementです。

Working Agreementを決めるべき理由がいくつかあります。

  • チームメンバーが入れ替わるリスク
  • 新メンバーのスムーズなジョイン
  • メンバー間、お客様との不必要な衝突や仲たがいを避ける
  • 直接言いにくいこともある
  • セキュリティリスク

暗黙の了解事項は、個人の頭の中に知識として蓄えられているため、チームメンバーの離脱等、入れ替わりがあった際に、チームとして知識を消失するリスクが発生します。また、新しいメンバーがチームにジョインした際に、スムーズにチームに参加できるメリットがあります。メンバー各人が考えている「当たり前」が違うと、それは時として、メンバー間の仲たがいが発生するリスクにつながりますし、セキュリティリスクにつながることもあります。

どのように作り運用するか。

Working Agreemnetはどのように作成すべきでしょうか。私たちのチームでは次のようなプロセスで作成し、現在も運用しています。

  • 最初にチーム全員で、「暗黙の了解」となっている非公式な合意事項を洗い出します。
  • 集約した項目の中には、Working Agreementに含むべきではない項目が出てきます。例えば上述のような契約事項は「公式的」なものですから、Working Agreementには含めない、という考え方を私たちは取っています。これらをメンバー全員の合意のもと精査する。
  • 集約した項目の中には、各メンバーによって認識が違うものが必ず出てきます。これらをメンバー全員で1項目ずつ擦り合わせを行っていきます。
  • 作成したWroking Agreementのテキストは、プロジェクト管理ツールのWiki等に展開し、誰もがいつでも確認できるようにします。

新しいメンバーが入ってきたときは、まずチームの働く上での合意事項としてWorking Agreementを読んでもらいます。また、働いている中で、暗黙の了解は増えていきますし変わっていきます。Working Agreementは働く中で柔軟に追加・修正していくべきものと考えていますが、個人的に編集するのではなく、MTG等のメンバーが集う場で合意を取って修正していきます。

また、Working Agreementを破った場合、決してその人を非難するべきではありません。誰だって失念することはありますし、間違いを犯すこともあります。罪人の様に扱うのではなく、こういったタイミングを会話の契機として、チーム内のコミュニケーションや関係性を向上させていくことだと考えています。

現在我々のチームでは、100個近くの項目が存在します。是非皆さんも試してみてください。

チームの振り返りにワールドカフェが良かった件

インフルエンザA型にかかりまして、出勤もイベント参加もできないのでブログでも書かせていただきます。 先日、チームで行った振り返りのフレームワークで、ワールドカフェがとても良かったので皆さんにもシェアしたいと思います。

振り返りの意義

私たちのチームはスクラムフレームワークをベースとして日々のタスクや開発を進めています。スクラムでは経験主義に基づく考え方を取っています。経験主義とは、Wikipediaによると

人間の全ての知識は我々の経験に由来する、とする哲学上または心理学上の立場

経験論 - Wikipedia

と定義されています。すなわちスクラムでは、チームが知識を積んで成長していく/未来の不確実性を少なくしていくために、自分たちの「経験」から学ぶことを非常に重要視していて、そのために「振り返り」と、その結果をチームに「適応する」ことが非常に重要です。

振り返りの対象にも、いくつかあります。仕事の「プロセス」や「成果」、チームの「関係性」に対する振り返り等です。この振り返りをおこなうイベントとして、スクラムではスプリントレビューやレトロスペクティブ等のイベントが用意されています。

スクラムの詳細については他の記事に詳細をお任せするとして、自身のスクラムの進め方については下記記事をご覧いただけるとわかると思います。

ishitonton.hatenablog.com

ワールドカフェとは

今回、チーム内の長期間にわたるプロジェクトが一段落したため、このプロジェクトに関する振り返り手段として、今回ワールドカフェを試してみました。

ワールドカフェは、チーム内で対話を行うための方法の1つで、その名前のとおり、カフェにいるような非常にリラックスした雰囲気の中、テーマについてチーム内で会話をするフレームワークです。 話し合いを行うと、最終的に1つの合意形成を得ることを目標とすることが多いですが、ワールドカフェでは会議の結果として合意形成を得ることをゴールとしていません。 あくまで、話しやすい雰囲気の中で、チームメンバー個々人の考えや価値観を共有し、相互理解を深化することが目的になります。

ワールドカフェは以下の手順で進めます。

  • チームを3~5人程度のテーブルに分けます。テーブル単位での対話を行います。
  • 各テーブルには、マジックペン模造紙を準備し配備します。議論の補助として、好き勝手に使ってもらいます。
  • 1回の話し合いのサイクルを20分とし、それをメンバーを移動させながら3回繰り返します。
  • 各テーブルに1人ホスト役を設けます。ホスト役はテーブルを移動しません。
  • 2回目では、ホスト役以外の人が他のテーブルに散らばって移動し、新たなメンバーで同じテーマについての話し合います。ホスト役の人は、1回目のメンバーで話し合った内容について、模造紙等を利用しながら新たなメンバーに共有します。移動してきたメンバーは、元のテーブルで話しあった内容を共有し、さらに話し合いを進めます。
  • 3回目では、全員が1回目のテーブルに戻り、他のテーブルでの会話をシェアしながら、さらに話し合いを進めます。

以上が、ワールドカフェの手順です。上記のようなテーブルをミックスさせる進め方をとることで、大人数のチームでも、他のテーブルの人の考えや価値観を吸収できるような配慮がされています。

より詳しくは、下記ブログが参考になります。

www.kaonavi.jp

私たちのチームでは、リラックスした雰囲気づくりの一環ついて、実際にカフェでコーヒーのポットをレンタルし、コーヒーを飲みリラックスしながら話し合いを行いました。

また、テーマとしては、「〇〇プロジェクトの成果・プロセス・人間関係で、良かったこと・悪かったこと・その他何でも」といった感じで、非常におおざっぱなテーマ設定をしました。

以下では、やってみた感想を記載します。

運営の難易度が低い

ワールドカフェは、非常に運営の難易度が低く、失敗しずらいことがメリットの1つです。世の中には様々なディスカッションのフレームワークがありますが、成功失敗のカギをファシリテーションが握ることが少なくありません。うまくファシリテートできないと議論が活性化せずに取り組み自体が失敗に終わるケースが多いです。ワールドカフェは、ファシリテーションをほとんど必要としないので、失敗する確率は低いといえます。

また、必要とするものも模造紙とマジックペン、あとはリラックスするためのコーヒーくらいなもんで、準備も少ないです。

リラックス。安心して環境で本音に近いトーク

カフェの雰囲気により全員がリラックスして本音に近い内容を発信しやすい環境となります。また、合意形成を得るものではないので、意見を集約しなきゃ!とかグループディスカッションでありがちなsomethingがないのも本音トークができる要因です。

また、KPT法とかは非常に堅苦しく、ついつい暗くなりがちですが、ワールドカフェは比較的ポジティブに対話ができると思います。

大人数でも議論の内容をミックスできる

大規模なチームで、このようなディスカッションをする場合、各テーブルの議論の内容を把握できないことが多々あります。ワールドカフェは、各テーブルでの話し合いの内容を、席替えにより効率的にミックスさせるフレームワークとなっているので、自ずと色々な考え・価値観を吸収できます。

どういったチームに効果的か。

ワールドカフェは、まだ関係性が成熟していないチームでも、自己組織化されているチームに対しても効果的であると考えます。

ワールドカフェでは、普段チームでしゃべらない人とも話すことができるので、チームビルディングの観点でも効果的です。こんなこと考えていたんだ!というような気づきを得ることができると思いますし、相手の考えを知れると、チームの関係性は高まっていきます。

例え、既にチームの関係性は成熟し、自律的に行動が可能な自己組織化チームにとっても効果的だと思います。ワールドカフェは合意形成を得るものではありませんが、自己組織化チームであれば、対話の結果を各人が持ち帰り、持ち帰った内容を能動的にチームに反映していけるものと考えます。

良かったら試してみてください。