TOMOLOG

こにゃにゃちわ

組織コンディションのスコアリングとその運用 ~wevoxを半年使ってみた~

イントロ

この記事は Engineering Manager Advent Calendar 2018 - Qiita の15日目の記事です。

EMをやっている@tomox1001です。
すっかり寒くなってきて、年の瀬を感じる今日このごろです。
みなさま、いかがお過ごしでしょうか。

ありがたいことに、今携わっているプロダクトが順調に成長しており、合わせて組織も拡大しております。

1年ほど前までは、EMである私が目標設定や1on1などのピープルマネジメントを全てのエンジニアを対象に行っていました。 が、このまま人数が増え続けると、EM1人が全員をマネジメントするやり方ではいつか破綻するぞという漠然とした危機感がありました。

また、プランナーやデザイナーなど、エンジニア以外の多様な職種が多く所属する組織で、エンジニア組織だけでなく組織全体で同じような課題を抱えていました。

そこで、ミドルマネジメント層を意図的に作り、立ち行かなくなるその前に育成・強化をはかることにしました。

そういった経緯の中、組織全体のマネジメントの質を向上させる手段のひとつとして、『wevox』というツールを組織に導入することにしました。

f:id:tomox1001:20181215201752p:plain

今日は、このwevoxを導入・運用してみた感想を、簡単ではありますが書いていこうと思います。

（蛇足ですが、マネジメントスケールの課題に至るまでの様々な組織の歴史については、以下の資料にまとまっているので興味がある方はご覧下さい。）

wevoxとは？

公式HPにわかりやすく説明がまとまったものがあるので抜粋します。

wevoxは独自のサーベイを用いて組織の状態を可視化し、エンゲージメントにおけるマイナス要因を特定及び改善策を実施していく事で、組織改善のサイクルを生み出すサービスです。 働く人々の「エンゲージメント」が企業の成長に関与している事が立証されており、昨今世界中で注目を浴びています。 エンゲージメントを高める事で、働きがいや組織に対しての愛着心が増し、生産性が向上するだけでなく、リファーラル採用の促進、及び離職率の低下により、採用・育成コストを削減できます。

より詳細な情報については公式HPを参照下さい。 wevox.io

同じようなツールにモチベーションクラウドなどもありますが、定期的に実施するアンケートの時間が2~3分という気軽さに惹かれ、うちの組織ではwevoxを試してみることになりました。 www.motivation-cloud.com

まずは導入してみた

f:id:tomox1001:20181215200903p:plain
wevox管理画面サンプル画像
公式から拝借した画像ですが、これがwevoxの管理画面のサンプル画像です。

wevoxから配信されるアンケートを元に職務 、自己成長、健康 などの様々な観点で自組織のスコアが確認できます。また、設定次第で、所属チーム、職種、年代、入社年、など多様な切り口でスコアをみることも可能です。

私たちの組織で最初に実施して出たスコアを見て、「このスコアがそもそも高いのか低いのかよく分からん」という状況になりました。しかし、wevoxの機能の中に、wevoxを利用している近しい業種の会社の平均スコアと比較できる"ベンチマークとの乖離"というチェック機能があることを知り、まずはそれを元に自分たちの組織の立ち位置を知ることができました。

結果、概ね平均以上のスコアで良好であるが、一部自己成長に対してスコアがベンチマークスコアより下回っているメンバーがいそうということが判明しました。

この課題設定を元に、(具体的な内容はここでは割愛しますが)目標設定の大幅な改善を全職種で行うことを決断しました。 その結果、改善施策を実施した翌月、自己成長のスコアが先月と比べて増加したため、自分たちが実施した施策の手応えを感じることができました。

これまで、漠然とメンバーから上がってくる意見や組織の雰囲気から課題を抽出し、なんとなく優先度を決めてアクションを決めていたものが、ある程度根拠がある状態で課題を見定めることが出来るようになったと実感しました。

本格的に運用しはじめた

このファーストアクションをきっかけに、

  1. メンバーからのアンケートを元にスコアを算出する。
  2. 過去スコアやベンチマーク比較を元に、マネージャー/リーダー層で議論を行う。
  3. 議論を元に、解決すべき課題に対するアクションを決め、実行する。

という、流れで約半年ほど運用を続けています。

このフローにおいて、"2."のリーダー層との議論が、イントロで書いた"ミドルマネジメント層の育成・強化"において重要だと感じています。なぜなら、議論を通じて各リーダーの意見を聞くことで、リーダーとしての立ち振る舞いや考え方をインプットすることが出来るからです。

議論の際は、「なぜ自分のチームがこのスコアなのか」という質問をリーダーに必ず問うようにしています。 リーダーがチームやメンバーと向き合っていれば、自分のチームのスコアについてある程度仮説を持って説明が出来るはずなので、それができない場合は例えチームのスコアが高くてもリーダーとしての職務を果たせているかは疑わしいと思っています。

また、スコアにあまり振り回されないようあくまで参考程度にする、ということも意識しています。

スコアが低くても、そこに妥当性があるケースもあると思います。

『スコアの低いチームのリーダー=マネジメントがうまくできていないリーダー』

と短絡的に決めつけず、スコアに対する説明に妥当性があるか、今の組織やプロジェクトのフェーズがどうかなど、多角的に判断をしています。

アウトロ

いかがでしたでしょうか。

他にも、マネジメントスケールの取り組みとして、1on1ロープレやリーダー陣による目標設定レビュー会など、様々な施策に挑戦中です。 みなさんも組織のマネジメントの育成・強化で試みていることがあればぜひ教えていただきたいです！

明日はtany3さんの記事ですね。お楽しみに！

※ wevoxの回し者ではありません。

会議の質を上げる！gaoryuさんによるファシリテーション研修のレポーティング

この記事はファシリテーター Advent Calendar 2017 21日目の記事です。

今日は私が所属する組織で実施した、gaoryuさんによるファシリテーション研修のレポートを書きたいと思います。

研修を依頼した経緯

私の組織では会議に対する課題感があり、どう改善すればよいかをずっと悩んでいました。

- 会議にゴールやアジェンダがない
- "とりあえず1時間！"な会議が設定されることがある
- ファシリテーション文化が組織に根付いていない
- etc

このような課題感をgaoryuさんに相談したところ、
「会議の質を上げるためのファシリテーション研修をやりましょう！」
と、快く引き受けてくださいました。（改めて感謝です…！神…！）

- 会議の質を上げる
- メンバーのファシリテーション力を上げる
- ファシリテーション文化を組織に根付かせる

上記を目的として、ファシリテーションをする機会の多いメンバーや会議に対して課題感を持っているメンバーを中心に社内研修を実施する運びとなりました。

講義内容

f:id:tomox1001:20171221134720j:plain

ファシリテーションの基本とは何か

f:id:tomox1001:20171221141201p:plain

ファシリテーションとは"今を捉えて、人に作用することを意識的に行うこと"である。

「今、あの人の発言少ないから話題を振ってみよう」という作用
「今、会議の本質からずれはじめているから話題を本質に戻してみよう」という作用
「今、緊張しているメンバーが多いからアイスブレイクをはさんでみよう」という作用

などなど。

なぜ会議にファシリテーターが必要か

f:id:tomox1001:20171221141213p:plain

会議は誰もが出来ることなので学ぶ機会が少ないため形式知になりづらい。つまり、会議には必ず暗黙知がある。それを共通の意識の上で実施できるようにするためにファシリテーターが必要である。

会議に影響・作用する要素

f:id:tomox1001:20171221141238p:plain

常に変化していく要素を認識し、その要素に対して"今を捉える"。ファシリテーターはそれらの要素に対して、様々なアクションで影響・作用させ、会議の質を上げる。

ワーク内容

f:id:tomox1001:20171221134037j:plain

講習後にワークショップを実施しました。事前に会議のテーマを2つ決めており、それぞれグループに分かれて実施しました。

  • テーマ1: 惰性で取り組んでいるものを"すてる会議"
  • テーマ2: 組織の未来について考える"あした会議"

f:id:tomox1001:20171221154222p:plain

上記の会議の構成を念頭に、各自どのフェーズを担当するかを決め、会議の準備から事後処理までどういったことが必要になるかを議論しました。研修の本質的な内容(学び)のネタバレになってしまうので深くは触れませんが、私達のグループは会議の準備の進め方について迷走してしまい、意見がまとまらずタイムアップとなってしまいました。

※ この研修を受けてみたい方は gaoryu さんにぜひお声がけください。「相談はいつでも受けてます！」とのことでした。

学び

f:id:tomox1001:20171221134134j:plain

今回の研修を通じて、私自身たくさんの学びがありました。
特に大きな気付きや学びとなったことを以下にまとめます。

常にファシリテーターとしての自覚を忘れないようにする

  • 私は特に議論に集中しすぎてしまう傾向があるので気をつける。

会議ごとに振り返ることを意識する

  • 何にフォーカスしてファシリテートできたかを考える癖をつける。

会議中のファシリテーションだけでは不十分であることを認識する

  • 事前準備~事後処理まで考えて設計する。

ファシリテーターは会議に一人じゃなくてもよい

  • リーダーシップをメンバー全員が持つことでよい組織になるように、ファシリテーションスキルは会議の参加者全員持っていたほうがよりよい会議になる。

会議=文化である

  • ルールでガチガチにかためて会議を良くしようとしていたがそれだけでは足りず、文化まで昇華させる必要があると感じた。
  • 例: 遅刻した人を責める、ではなく「みんなで行きましょう！」と会議に参加するメンバーに声がけする雰囲気にする、など。

これから

当初の目的に対して、この研修を通じて今後組織に対してどう還元していくかを最後にまとめ(宣言し)ます。

会議の質を上げる

  • ファシリテーション研修の内容を全員にフィードバックする。
  • まずは会議のグラウンドルールを用意し、"良い会議とはなにか"の共通認識をチームとしてもつ。

メンバーのファシリテーション力を上げる

ファシリテーション文化を組織に根付かせる

読了メモ 201709

最近改めて本を読む機会が増えてきたので備忘録がてらブログにまとめる。
主に仕事関連の本。

Inspired: 顧客の心を捉える製品の創り方

http://amzn.asia/bCNTrqN
https://images-fe.ssl-images-amazon.com/images/I/41u0jJ-CbvL.jpg
プロダクトマネージャー向けの本だが、ものづくりに携わる人であれば全員におすすめできる本。チームでものづくりをする時の進め方や立ち上げ時のノウハウなど内容盛りだくさん。

ザ・ファシリテーター

http://amzn.asia/fVM2k5I
https://images-fe.ssl-images-amazon.com/images/I/41WL3QBtH4L.jpg
ファシリテーターを小説風に解説した本。ストーリー自体がおもしろい上にファシリテートについて学べる一石二鳥な本。 日曜劇場でドラマ化して欲しいレベル。

エラスティックリーダーシップ ―自己組織化チームの育て方

http://amzn.asia/8irAad0
http://www.oreilly.co.jp/books/images/picture_large978-4-87311-802-4.jpeg
サバイバルな環境から抜け出し、ゆとり時間を作り学習し、自己組織化に導く。
よくある組織の状態が分かりやすく言語化されており、フェーズごとのリーダーシップの取り方がとても参考になる。 リーダーシップは一辺倒なやり方ではいけないものだと再認識した。

結果を出すリーダーはみな非情である

http://amzn.asia/dP1hFPj
https://images-fe.ssl-images-amazon.com/images/I/51o2sKcCgZL.jpg
『そもそもリーダーシップは、管理職になった後に鍛えるものではない。』
まさに。自分のポジションの一つ二つ上を意識し、日々シミュレーションすることが大事だということを改めて学んだ。
いい意味で危機感を煽られる良書だった。

「学力」の経済学

http://amzn.asia/6Uv20Ok
https://images-fe.ssl-images-amazon.com/images/I/51wRTLN8tFL.jpg
子供の"学力"についてデータに基づいたファクトベースで紹介している本。
『本を読んだら（インプット）ご褒美、といい成績をあげたら（アウトプット）ご褒美だったらどちらが学力向上するか⇒インプットインセンティブのほうが効果が高い』
など参考になる事例がたくさんあり勉強になった。

elasticsearchのGet APIで特定のフィールドを取得する。

elasticsearchのGet APIで特定のフィールドを取得する方法を試す。

特に指定せず、普通に取得すると以下のようになる。

[user@search001 ~]$ curl -XGET "http://localhost:9200/user_v1/searchable_user/1/_source?pretty=true"
{
  "birthdate" : "1989-07-07T15:00:00.000Z",
  "register" : "2014-07-08T07:00:17.232Z",
  "update" : "2014-07-10T02:04:29.302Z",
  "gender" : "female",
  "zodiacSign" : "cancer",
  "userId" : 1,
  "name" : "チョコレート",
  "isNew" : false,
}

特定のフィールドを取得する場合は、クエリーストリングで _source={FIELD} を指定する。

[user@search001 ~]$ curl -XGET "http://localhost:9200/user_v1/searchable_user/1/_source?pretty=true&_source=name"
{
  "name" : "チョコレート"
}

複数のフィールドで絞り込みたい場合は , でセパレートする。

[user@search001 ~]$ curl -XGET "http://localhost:9200/user_v1/searchable_user/1/_source?pretty=true&_source=name,gender"
{
  "gender" : "female",
  "name" : "チョコレート"
}

mongodbでsecondaryに参照クエリを流す

目的

mongodbは特に指定しない場合、write/read共にprimaryに対して処理が行われます。 これをsecondaryに対してもread処理を流すようにすることで、負荷分散ができますよというお話。

Read Preference

MongoのクライアントにRead Preferenceというオプションがあります。 これは、クライアントからMongoDBの読み出しを行う際、どのメンバーに対してread処理を行うかを指定できる設定です。 docs.mongodb.com

  • primary : primaryからのみread処理を行う。
  • primaryPreferred : primaryからread処理を行うが、もし処理が行えない場合はsecondaryからread処理を行う。
  • secondary : secondaryからのみread処理を行う。
  • secondaryPreferred : secondaryからread処理を行うが、もし処理が行えない場合はprimaryからread処理を行う。
  • nearest : ネットワークレイテンシーが最も低いメンバーから優先的にread処理を行う。

secondary readを試す

> db.test.find().readPref({mode:'secondaryPreferred'})
{ "_id" : "hoge", "name" : "fuga" }

↑のようにクエリごとにread処理を決めることができます。
アプリケーションなどで利用する場合、単純に全てのクエリに対してsecondaryを指定すると、参照処理が全てsecondaryに向いてしまうため、 処理ごとに明示的にわけるか nearestを指定するなどでクエリがバラけるようクライアントの設定を調整しましょう。

補足

MongoのクライアントにWrite Concernというオプションがあります。 これは、クライアントから『書き込み処理がどこまで行えたら成功とみなすか』を指定できる設定です。 docs.mongodb.com

今回、参照処理をslaveに流す対応を行いましたが、タイムラグが許されないデータに関しては、write concernをmajorityにするなど厳密な設定が必要になります。その場合、writeのスループットに影響するため、 secondary read = パフォーマンス向上 に繋がるとは安易に言えません。 サービスやデータの特性に応じて、secondary readを導入すべきか慎重に検討しましょう。

社内ISUCON TOTEC2015で優勝しました！

TOTECという、サイバーエージェントの社内ISUCON的なエンジニアコンペで優勝しました！

今年はチーム戦ということで以下のメンバーで参戦しました。
ともっくす - infla
はぎ - server
ゆし - front

このメンバーは、ピグブレイブというサービスの立ち上げを一緒にやったメンバーで、お互いのことを熟知した状態で大会に望めたのが大きかったなと思います。当日も阿吽の呼吸感がすんごかった。チーム力大事ですね。

事前準備から当日まで、本当にわいわい楽しくやれたのもこのメンバーだからこそなので、改めてはぎとゆしにはありがとうと伝えたいです。

チーム名のマイナスツンデレーションについて、
「そのチーム名なんなん」
と聞かれることが多かったのですが、説明が難しいので決まるまでの過程を貼っておきますね。 f:id:tomox1001:20151114140328p:plainf:id:tomox1001:20151114091821p:plain

やったこと - 事前準備

コンペに向けて、事前準備はかなり念入りにやりました。
「入賞しなくてもベスト準備賞は狙えるかもねw」 という話も出るくらいに。 ベスト準備賞なんてないけどｗ

事前すり合わせでやっておいてよかったと感じたのは、やることの優先順位をチームとして決めておいたことです。
我々は「まずはアプリを作る、動かす！」をポリシーとしていました。
当日は時間がない中でやることが無限にあるので、まずは動くものを最速で作ることを決めておいたことで何をすればいいのかが明確になったかなと思います。

以下、事前準備用のメモです。
こうしてみるとほんと色々やったなぁとしみじみ。
f:id:tomox1001:20151114095038p:plainf:id:tomox1001:20151114095042p:plain

やったこと - 当日

「まずは動くものを最速で作る」
のポリシーに従い、よいスタートダッシュを切るために、事前に用意していたSTART:DASH!!!というToDoリストを元に環境構築をしました。
大きな事故もなく、開始1時間くらいでアプリが動くところまでいけました。 f:id:tomox1001:20151114095939p:plainf:id:tomox1001:20151114095947p:plain

システム構成は、2インスタンスがアプリサーバー(計測用の1台にはリバプロとロードバランサー - nginx が共存)、1インスタンスがDBサーバーというシンプルな構成でした。 アプリはnodejs、テンプレートエンジンはectを使いました。自分の手に馴染んでいるもので、というのが選択理由です。
データストアはmongoとredisを予定してたのですが、渡されたデータの容量がjson化しても1.5GBぐらいだったので、「オンメモリわんちゃん」というはぎの一声でDB全部捨ててオンメモリでいく方針にしました。起動まで3分くらいかかりましたが、なんとかメモリに載りきりました。この時点でDB用に用意していたインスタンスもアプリサーバーに切り替えることにし、再プロビジョニングしました。

一応、newrelicやkataribeなどのパフォーマンス計測ツールも用意していたのですが、そもそもの実装量が膨大だったのでチューニングにはあまり時間をかけられなそうでした。ので、割り切りでこの辺のツールも事前にオフっておきました。
ちなみに、競技終了前にやるべきことは忘れそうだったのでEND:DASH!!!というToDoリストにまとめてありました。 f:id:tomox1001:20151114095956p:plain

まとめ

色々書きましたが、 まとめると
- オンメモリわんちゃん
- 最速実装への振り切り
- チーム力！！

が、主な勝因かなと思っております。
あとは、運の要素も大きいです。はっていたヤマが当たったり、定めていたチームポリシーがたまたま競技にマッチしたり。

個人的にはエンジニアが一同に介してわいわいやるのは本当に楽しかったのでぜひ来年も期待しております！

運営のみなさま、参加者のみなさま、本当にお疲れ様でした！！

Mac OS X Lionでrvmがインストールできない件

mac

rvmインストールがうまくいかなかったので備忘録代わりに書き残します。
Lionでrvm install 1.9.3しても下記のエラーが出てしまいうまくいきませんでした。

$ rvm install 1.9.3

で、実行しても

Installing Ruby from source to: /Users/jamie/.rvm/rubies/ruby-1.9.3-p0, this may take a while depending on your cpu(s)...
 
ruby-1.9.3-p0 - #fetching 
ruby-1.9.3-p0 - #extracted to /Users/jamie/.rvm/src/ruby-1.9.3-p0 (already extracted)
Fetching yaml-0.1.4.tar.gz to /Users/jamie/.rvm/archives
Extracting yaml-0.1.4.tar.gz to /Users/jamie/.rvm/src
Configuring yaml in /Users/jamie/.rvm/src/yaml-0.1.4.
Compiling yaml in /Users/jamie/.rvm/src/yaml-0.1.4.
Installing yaml to /Users/jamie/.rvm/usr
ruby-1.9.3-p0 - #configuring 
ERROR: Error running ' ./configure --prefix=/Users/jamie/.rvm/rubies/ruby-1.9.3-p0 --enable-shared --disable-install-doc --with-libyaml-dir=/Users/jamie/.rvm/usr ', please read /Users/jamie/.rvm/log/ruby-1.9.3-p0/configure.log
ERROR: There has been an error while running configure. Halting the installation.

となる。。

どうやら、新しいXcode(4.2以降？)がTraditionalなGCCを持っていないことが原因らしい。なので下記のオプションを適応して再度実行。

$ rvm install 1.9.3 --with-gcc=clang

で、うまくいきました。