pandazx's blog

データ分析など雑多な技術ブログ

戦わずして勝つファシリテーション

プロジェクトマネジメント

開発プロジェクトでお客様または企画と打合せする際に打合せ資料を作成し、打合せの流れを考えてアジェンダを作成する。

打合せの目的が進捗報告の場合がある。その場合、プロジェクトを進めるにあたって見つかった課題を議論する。

課題はプロジェクト関係者全員にとって解決すべきことだが、その解決方法は様々である。解決方法によっては、誰かにしわ寄せが行くこともある。開発を請け負う側としては、開発がスムーズに行くようにしたいと思うのは当然である。

 

おそらく、多くの場合、課題は開発から報告される。打合せで課題をそのまま報告するのは悪手である。開発側としては、その課題の落とし所を考えておき、打合せで解決方法が意図したところに落ち着いて欲しい。

これの可能性を高めるには打合せ準備が大事だ。そして、「戦わずして勝つ」、つまり、打合せでハードな議論をせずに意図したところに話の流れを持っていく。

それは話の出発点を相手が重視するところからスタートさせること。例えば、企画があって開発があるので、当然、出発点は企画の立場にたったものになる。最初に開発の話からスタートさせてはいけない。それでは、企画からしたら、自分たちのロジックではないものをぶつけられるので、話を聞くスタンスが守りから入ってしまう。それではお互いがぶつかってしまう。

相手が納得しているロジックからスタートして、意図した解決方法に至るまでのロジックを展開する。この時にすべてを話すのではなく、一部は相手に考えてもらい、自然と意図したところに話がいくようにファシリテーションする。

 

どうやっても、どちらかが泣くしかない場合は戦うしかない。ただ、その場合、最終的に責任者が決断することになるので、それこそ、打合せが始まる前に勝負は決まっていると言えなくもない。

Openstack Swiftコマンドメモ

openstack

Swiftをコマンドラインから操作する方法メモ

コンテナ操作

# リスト表示
openstack container list
# 作成
openstack container create {container_name}
# 削除
openstack container delete {contaier_name}
# オブジェクトが残っていてコンテナが削除できない場合は以下のコマンドで削除
openstack container delete -r {contaier_name}

オブジェクト操作

# リスト表示
openstack object list
# 登録
openstack object create {contaier_name} {filepath}
# 削除
openstack object delete {contaier_name} {filepath}
# 取得
swift download {contaier_name} {filepath} -o {output path}

メルカリ CRE Server Side Tech Talk vol.2に行ってきた

勉強会

mercari.connpass.com

に行ってきた。以下はメモ

CREチームの紹介

  • CREとは、お客様からの信頼性向上を目指すエンジニア
  • 元々はCXIで、カスタマーセンターCSのサポートがメインだった
  • これをメルカリのユーザーにまで対象を広げた

メルカリの商品監視を支える技術

機械学習によるマーケット健全化を支える技術

  • LovemachineというML基盤を独自開発しており、OSS公開予定だが、人手が足りなくて、あまり進んでいない

機械学習によるマーケット健全化の施策

  • スピーカーの自己紹介
    • Solarのクエリチューニング
    • 近所検索を開発
  • CSには偽ブランドを見分ける鑑定士がいる
  • 質問
    • 商品監視の機械学習モデルは複数ある？複数の結果をどう解釈してる？
    • 監視目的別にモデルがある

「アプリケーションエンジニアのためのApache Spark入門」出版記念セミナーに行ってきた

勉強会 spark

connpass.com

に行ってきた。以下はメモ

Apache Spark入門書籍の紹介

  • 理論よりも使い方に重きを置いた入門書
  • サンプルのプログラミング言語はPython
  • データ分析基盤に使われるOSS紹介
  • データ収集はfluentd, kafka
  • データ蓄積はhdfs, cassandra
  • ストリーム処理、簡易な集計分析はSpark structured streaming
  • バッチ処理はSpark SQL
  • データ分析はSpark MLlib, Jupyter
  • Sparkが注目されている理由はデータ分析プラットフォームの主要な機能があるため

Fluentd, Kafkaの紹介

  • 残念ながらスピーカーが私用のため、欠席

Spark Streamingについて

  • ストリーム処理はデータが無限
  • バッチ処理はデータが有限
  • ただ、Spark Streamingはマイクロバッチなので、データを有限として扱う
  • Spark2.3.0から継続実行方式が可能になる
  • ストリーム処理で発生する問題
  • データが発生した順に到着しない。out of order. ネットワーク遅延やサーバ間の時刻ズレなどが原因
  • データのグルーピングの概念
  • タンブリングウィンドウは固定長で区切る方式
  • スライディングウィンドウは固定長だが、スライド幅が異なる方式
  • セッションウィンドウは特定キー、特定時間内のデータを同一ウィンドウにまとめて処理する方式
  • 実際に到着が遅れて困る例。データが大幅に遅れると、どこまで、その遅れを待てばいいのか検討が必要
  • 対応方法としては、データ発生時刻とデータ処理時間を分けて管理する。加えてDBへの投入時間を管理する場合もある
  • どこまで処理したかの管理はwater markで管理
  • データ発生時刻が一定時間以上古い場合は除外する
  • 出力する値や集計方式として、処理完了したもの、追加部分のみ、更新部分のみを選択可能
  • これらのサンプルプログラムが書籍に記載されている

データの蓄積

  • Spark SQLとCassandraの紹介
  • Spark処理結果を出力先として、Cassandraがオススメ

データ分析について

  • データ分析プロセスCRISP-DM
  • 他にKDD,SEMMAがある
  • 資料は後日、公開

プロダクション投入に向けて

  • Sparkは計算資源といえる。そのため、ステートレス化できる。今風に言えばサーバレスにできる
  • AWS Glueを使うとHdoopクラスタなしにSparkを使える。GlueにHive metastoreを置いて、実データはS3に置く構成

サイバーエージェントの機械学習祭りに行ってきた

勉強会 機械学習

www.wantedly.com

に行ってきた。以下はメモ。

推薦アルゴリズムの今までとこれから

スピーカー：サイバーエージェント 内藤 遥

推薦アルゴリズムの種類

  • 協調フィルタリング
    • データがないと機能しない
  • コンテンツベース
    • データがなくても大丈夫。商品の特徴量を使う

GroupLens

Matrix Factorization

  • Netflix Prizeで登場したアルゴリズム
  • ユーザの暗黙的評価。閲覧1、お気に入り2、購入3という評価値とするなど

Factorization Machines

  • MFの改善手法
  • ただ、MFより予測の計算量が多い。TopNの算出に時間がかかる
  • 特徴量にドメイン知識が必要

RNN

  • 時間による変遷を考慮できる
  • クライアントブラウザの種類などのコンテキストを考慮できる

Collaborative Metric Learning

  • オンラインで近似的に高速に解ける
  • Amebaで注目してる手法

Amebaの推薦基盤

マルチメディア機械学習の取り組み

スピーカー：サイバーエージェント 藤坂 祐介

アメブロ画像カテゴライズ

  • ブログのAmeba公式ジャンルのカテゴライズを自動化したい
  • NLP+投稿画像認識
  • 内製のラベル付け管理ツールで30万枚の画像をタグ付け
  • 分類精度。t-SNE. top1 82.73%
  • アルゴリズムはKerasでResNet

スパム画像検知

  • エログロなどのスパム画像を検出したい
  • スパム画像は全体の0.1%
  • アルゴリズムはKerasでResNet
  • 教師データは日々の監視業務で作成
  • いい精度が出ていない

次の課題。マッチングアプリで業者が同じようなプロフィール画像を使い回すユーザがいるので検出したい

  • 画像をdhashで64次元に変換
  • Humming距離で類似度を計算
  • 7,8bitで良い精度が出て、実際に使われている

楽曲の盛り上がり検知をやってみた

  • 課題は楽曲のサビ検知
  • メロディ、サビ、その他の3分類で精度評価して、分類精度51%

大規模分散深層学習とChainerMNの進歩と課題

スピーカー：PFN 秋葉 拓哉

  • ChainerMNのMNはMulti Nodeの略
  • 分散深層学習を非同期でやるよりも、同期でやった方が精度が高い。大事なのはスループットではなく精度
  • ChainerからChainerMNに移行する際のコードの変更量は少ない
  • 2016年では分散深層学習すると精度が落ちる。しかし、2017年には精度が保てるようになった。しかも高速
  • 分散深層学習で2-3週間かかっていたものが256GPUsで1時間まで短縮されたが、PFNは1024GPUsで15分まで短縮した
  • 非同期型はネットワークの状況によって学習結果が異なるため、扱いづらい、チューニングしづらいのが難点
  • マルチノード構成にした場合、1Gbでは1台より遅くなる。10Gbで遅くならないぐらい。40Gbで戦えるかもレベルだが、未検証

cronで実行したシェルから呼ばれるRubyスクリプトの標準出力が出力されない

linux

test.sh

#!/bin/sh
ruby test.rb
echo done

test.rb

puts 'hoge'

上記スクリプトがあった場合に、以下のようにcronを設定しても、test.sh のdoneしかtest.logには出力されない。

0 * * * * cd /home/user/tools; sh test.sh >> ./test.log

cronで実行される際、環境変数は実行ユーザでログインした場合はとは異なるという問題もある。

参考：cronで実行時に環境変数を読み込む - Qiita

以下のようにして環境変数を読み込む -l オプションをつけて、-c でコマンドを実行させればよい。

0 * * * * /bin/bash -lc 'cd /home/user/tools; sh test.sh >> ./test.log'