セルフアウェアネスを高めよう /「99%の人がしていないたった1%のメンタルのコツ」を読んだ

IBM 時代にお世話になった河野さんのシリーズ最新刊「99%の人がしていないたった1%のメンタルのコツ」が 9/14 に出版されたので,さっそく読んだ.出版おめでとうございます!改めて,自分自身を客観的に見直すことができたような気がする.

99%の人がしていないたった1%のメンタルのコツ

99%の人がしていないたった1%のメンタルのコツ

  • 作者: 河野英太郎,田中ウルヴェ京
  • 出版社/メーカー: ディスカヴァー・トゥエンティワン
  • 発売日: 2017/09/14
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

セルフアウェアネス

「自分のモチベーションを見つめ直す」という話が最初に出てくる.内発的動機と外発的動機に関しては「モチベーション3.0」に詳しく書いてあるけど,自分のことを知るのは本当に大切だと思う.また,経験とタイミングによってもモチベーションが推移するので,定期的に見つめ直す機会を作るのが良いと思う.

kakakakakku.hatenablog.com

ちなみに,個人的には「キャリア・アンカー」が好きで,定期的に読み直している.とは言え,何度やっても「奉仕・社会貢献」「純粋な挑戦」のスコアが高いため,僕のモチベーションはそういう方向性にあるんだなと自己認識をしている.

キャリア・アンカー―自分のほんとうの価値を発見しよう (Career Anchors and Career Survival)

キャリア・アンカー―自分のほんとうの価値を発見しよう (Career Anchors and Career Survival)

さらに,セルフアウェアネスとして「苦手な人」と「嫉妬」という話が出てくるのもすごく良かった.組織に所属していると,良くも悪くも「人間は感情に左右される」ことを感じるため,感情を言語化して対処するというのは,合理的なアクションだとは思うけど,いざ実践しようとすると感情的にタフだろうなという印象もある.

目標設定

「マンダラート」と呼ばれるメソッドは初耳だった.今までは基本的にマインドマップを使っていたけど,次に目標を整理する機会があったら試す.目標設定に限らず,自分の強みを洗い出したり,プロダクトの戦略を考えたり,幅広くユースケースがありそうなメソッドだと思う.

navi.dropbox.jp

リラックス

「笑う」ことでリラックスできるというのは前から知っていて,仕事で意識するようにしている.関連することとしては「ノンバーバル・コミュニケーション」を意識していて,常にリアクションをすることで,頭を活性化させている.瞑想の話も出ていて,これは「マインドフルネス」のことだと思うけど,僕がすごく苦手なことの一つだ.考えすぎてしまう性格なので,まずは数秒からでも挑戦してみたい.

感情

「落ち込むことをプラスと考える」という話も良かった.個人的によく落ち込むタイプなので,信頼のできる友人に相談してみたり,週末の過ごし方を工夫してみたり,本書に書かれているコツを積極的に実践してみようと思う.

XP 祭り 2017 で「Fearless Change を活用した組織変革」をテーマに発表してきた

今日は「XP 祭り 2017」で発表してきた!(最近は発表をしまくっている…w)

発表資料

今日の発表タイトルは 「全ては Fearless Change から学んだ,開発組織の変革を支えた実践的アプローチ」 にした.大好きな “Fearless Change” の活用事例を紹介したくて応募したので,採択されて良かった.

スクラムなどの特定の手法に依存せず,どんな組織にでも適用できる実践的なアプローチを紹介したはずなので,参考になれば嬉しいなと.

speakerdeck.com

Fearless Change

全てのパターンを発表では紹介できなかったので,是非「組織変革のバイブル」として読んでみてもらえると!重要なのは,パターンを理解することではなくて,パターンを咀嚼して,自分の組織にフィットしたアプローチを実践することなので,間違えないように!本当にオススメの一冊!

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

  • 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
  • 出版社/メーカー: 丸善出版
  • 発売日: 2014/01/30
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (16件) を見る

44 engineering management lessons

発表で少し紹介をした “44 engineering management lessons” も非常に参考になるため,読んでみてもらえればなと!

kakakakakku.hatenablog.com

他セッション

ワークショップには参加せず,セッションを聞いていた.まず,昼休みに行われてた「野良 LT」を聞いていて,チームの状態が悪いだけなのに「モブプロが悪い」みたいに言われてしまうのは,モブプロに限らず本当によくあるなーと思った.まずコミュニケーションの問題を立て直すことに着目するべきだと思う.逆に言えば,モブプロをしてチームの状態が悪いことに気付けたことに喜ぶべきかなー.

「陣形」の話で「プロのトラブルメーカー」に対して「ボックスワン」で対応する,という話があって笑った.つらい.今までの経験だと,エンジニアリングマネージャーがそういう対応をしている気がする.

speakerdeck.com

まとめ

マネジメント系のコミュニティで発表したいなと思っていたので,今回発表できて良かった.会場は満席だったし,発表も盛り上がっていたように感じたので,少しでも参考になっていれば嬉しいなと.ちなみに冒頭で紹介をしたポッドキャスト omoiyari.fm にも出演をしているので,是非聞いてみてもらえると!

lean-agile.fm

今回「XP 祭り」は初参加だったけど,予想以上にエンプラな発表が多くて,こういうコミュニティなんだなーと感じた.一言に「アジャイル」と言っても,様々な形があり,多様性という意味では勉強になった.また来年も参加したいと思う!

関連記事

8月に July Tech Festa 2017 で発表した資料は以下にある.「DevOps + 組織変革」をテーマにしたため,より技術的な内容になっている.

kakakakakku.hatenablog.com

「パターン28. 経営層の支持者」をテーマに話したインタビュー記事もある!

developers.cyberagent.co.jp

参加者レポート

t-and-p.hatenablog.com

CA.io で「Amazon ES 移行」をテーマに LT してきた

昨日は Elasticsearch をテーマに開催された CA.io に参加してきた.サイバーエージェントグループのマッチング系サービスが対象なのに,友情出演という形で,特別に LT をさせてもらった.楽しかった!

cyberagent.connpass.com

発表資料

タイトルは「Amazon ES に移行をしたら幸せになれるのか?」にした.最近そこそこ大規模で,レガシーな Elasticsearch を Amazon ES に移行するプロジェクトを担当して,そこで学んだことをザックリと話した.LT だと全然時間が足りなくて,ネタっぽくなってしまった感はある.

speakerdeck.com

雰囲気

f:id:kakku22:20170912214903j:plain

補足

自動スナップショット

Amazon ES のダメな点として「自動スナップショットをリストアする場合はサポートに依頼する必要がある」という話をしたら,LT 中に大谷さんから「数日前に改善されたよ!」と指摘をもらって,実際に調べたら本当にリリースが出ていた.ただし,Amazon ES (Elasticsearch 5.5) 以降で使えるらしく,Amazon ES (Elasticsearch 2.3) では,引き続きダメだった.知れて良かった!!!

運用面

今回は時間が無くて話さなかった Amazon ES の運用面の話は去年に作った資料にまとめてある.参考になればと!

kakakakakku.hatenablog.com

Elasticsearch 6.0 is coming / @johtani

  • Elastic Pioneer Program で Elastic 6.0 を使うと粗品がもらえる!
  • Elastic 6.0 の特徴
    • ダウンタイムなしで 5.x から 6.x にアップデートできる
    • Upgrade Assistant
    • ソートクエリのパフォーマンスが改善する (index sorting)
      • 簡単に言うと,インデックスのときに順番を入れ替えてしまう
    • Elastic 7.0 からインデックスの _type を削除するので,警告が出るようになる

メジャーバージョンが上がるたびに進化していて凄いなと思う.Elasticsearch SQL の話を懇親会で大谷さんに聞いたら,6.0 では入らなそうとのことだった.良し悪しはありそうだけど,SQL 形式で書けることのメリットはありそうなので,期待してる.

タップル誕生が Elasticsearch を導入した3つの理由

  • MongoDB から Elasticsearch に移行した
  • 複数の検索項目があり,柔軟に実装できる点がメリット
  • 全文検索も現在実装中

位置情報を用いたElasticsearchの活用事例

  • すれ違いを検索するときに Elasticsearch を使っている
    • geo_point type でデータを格納している
    • geo_distance で検索をしている
  • 逆 Geocoding (緯度経度から住所を検索する)
    • 国土交通省のデータを Elasticsearch に入れている
  • Geo Shape を使うと Elasticsearch で範囲の中に特定の場所があるかを検索できる

Elasticsearch 活用 & 運用事例

  • mimi はマニアックな属性で検索ができるのが特徴
    • 完全一致 (年齢,住所…)
    • スコアマッチ (目/鼻/メガネ…)
  • インデックス再構築
    • エイリアスも reindex も採用しなかった

トルテが実践したマッチしたユーザーを除く3つの方法

  • マッチしたユーザーを除外する
  • Elastic Cloud と Amazon ES を検証した

speakerdeck.com

まとめ

最近は July Tech Festa 2017 / CROSS 2017 など,発表が多くてバタバタしているけど,移行事例を話せて良かった.また他社の事例を聞いて,まだまだ Elasticsearch を活用できるなと感じることができたため,適材適所に技術選定をしていきたい.

CROSS 2017 : Serverless Ninja Warriors でパネルディスカッションに参加してきた

今日 9/8 に横浜で開催された CROSS 2017 で,パネルディスカッションに参加してきた.テーマは Serverless Ninja Warriors で,サーバレスのガチ勢に囲まれて緊張したけど,楽しかったし,モチベーションも高まった.ありがとうございました!

2017.cross-party.com

資料

自己紹介として,簡単な資料を作成して最初に話をした.SpeakerDeck にアップロードするほどでもないため,そのまま画像で貼ってしまう.

話した内容としては,ザッと以下のような感じ.僕のポジションとしては「非ガチ勢」だったので,サーバレスに興味があるけど試したことがない人や,Lambda を管理コンソールで実装していて運用に困っている人などの参考になれば良いなと思っていた.

  • 個人的なサーバレスの定義は「FaaS の特性(ある意味で制約とも言える)を活かしたアーキテクチャ全般」と考えている(今のところ…)
  • サーバレスに限らず,スモールスタートを意識してチームに成功体験を作ると,導入障壁が下がる
    • そのために社内ツール系は最適
    • デプロイ/テストなど,ラストマイルも意識するとプロダクションレディな知見が得られる
  • CircleCI + Apex の組み合わせは非常に便利
    • Apex は複数ファンクションの管理も,複数環境へのデプロイもできる
    • ローカル環境は python-lambda-local を使っている

f:id:kakku22:20170908175225j:plain

f:id:kakku22:20170908175347j:plain

f:id:kakku22:20170908175406j:plain

質疑応答など

「CloudWatch Events など,Lambda 以外の AWS リソースはどのように管理しているのか?」という質問があり,ここは現状だと管理コンソールでポチポチしている.サービス全体で CloudFormation を導入するべきだと思うし,Apex + Terraform の構成にしても良いけど,現時点では既存のリソースへの影響が怖くて対応できていないという感じ.やらなきゃ!

「環境ごとにどのようにデプロイしているのか?」という質問もあり,これは Apex の Multiple Environments 機能を使っている.さらに Lambda の環境変数を Multiple Environments の定義ファイルに書けるため,それで invoke する Lambda の ARN などを管理している.あと IAM でも厳格にリソースを制限している.詳細は以下の記事を参照してもらえればと!

kakakakakku.hatenablog.com

補足など

ローカル環境の話が全体的にあまり無かったけど,僕は python-lambda-local を使っている.詳しくは以下の記事に!

kakakakakku.hatenablog.com

今日は話すタイミングが無かったけど,Apex の話をすると「Go 動くんでしょ?」とよく聞かれたりする.前に発表した資料の後半にまとめているけど,結局は Node.js の子プロセスで Go バイナリを動かして,プロセス間通信をしているだけなので,絶対に必要なら検討しても良いけど,AWS 公式でサポートされるまで待っても良いのでは?というのが個人的な判断かな.

kakakakakku.hatenablog.com

今回紹介したアーキテクチャは CloudWatch Events で Lambda を起動して SQS からメッセージを取得するため,ポーリング系の処理になっている.現時点では SQS のキュー操作は Lambda のイベントになっていないため,イベントドリブンにはなっていないけど,公式サポートが入ると嬉しいなとは思う.

会場で感じたこと

会場の各ホールが分離されていないため,隣のセッションの声がガンガン入ってきたり,マイクで音を拾えないと後ろの席まで届かなかったり,大規模カンファレンスの会場としては適していないのではないかなと思った.パネルディスカッションの序盤でそれに気付いたため,僕はかなり大きな声で話すようにした.

まとめ

今回パネルディスカッションに参加させてもらえて非常に刺激的だった.サーバレスとは何か?という疑問を自分なりに考え直せたことも良かったし,なによりも,パネルディスカッションに一緒に参加した皆さんの技術レベルが本当に高く,ディスカッションをするだけでも楽しかった.モチベーションも高まったし,もっともっと攻めて行かないとなと感じた.本当にありがとうございました!

マネジメントのポイントは "44 engineering management lessons" から学んだ

今年は「組織変革」「組織マネジメント」「育成」あたりをテーマにした発表をしたり,ポッドキャストで話をしているので,最近は「マネジメント関連」で相談や質問を受ける機会が増えている.一言で表現すると?みたいに聞かれたときは 「愛情のある無茶振り」 って答えてはいるけど,そもそも一言で表現できるようなものじゃない.

44 engineering management lessons

今まで紹介したことはなかったけど,マネジメントの参考にしている “44 engineering management lessons” という記事がある.本当に大好きな記事で,記事の存在を知った2年前ぐらいから定期的に読み直すようにしている.タイトルの通り,44種類の原則が紹介されていて,大きく7種類に分類されている.どの原則も参考になるけど,その中でも特に好きなものをコメントを添えて紹介したいと思う(翻訳するわけではない).

  • Do
  • Don’t
  • Motivation and culture
  • Emotions and people
  • Tiebreaking and conflict
  • Difficult conversations
  • Rough edge

www.defmacro.org

Do

メンバーの得意な部分を伸ばし,苦手な部分にも挑戦させることで,常に成長できるように意識している.そのときに明確な上下関係を作らず「お互いに高め合う」雰囲気になるように工夫している.また,メンバーと話して成長が鈍化している原因がある場合は,それを取り除いてあげられるようなアクションをする.

1 . Attract, nurture, coach, and retain talent. Talk to engineers to tease out concerns early, then fix them if you can.

ファシリテーターとして,議論を活性化させるのもマネージャーの役割かなと思っているけど,議論が白熱し,全員の合意が得られず収束してしまうような場合は,別の視点の質問をして収束を打破させるようにしている.それでも合意が得られない場合は,最終的な意思決定をする.それを記事では「タイブレーカー」と表現していた.そのためには議論を客観的に俯瞰するスキルも必要になるし,マネージャーが決めたなら信じよう!と思ってもらえるような信頼をメンバーから勝ち得ておく必要もある.

3 . Be the tiebreaker when the development team can’t reach consensus.

様々な情報のハブになることを意識している.特に人脈のハブになることを目指していて「この技術を導入するならこの人にアドバイスをもらおう」など,技術的な情報交換が迅速にできるように工夫している.まさにこれは「トランザクティブ・メモリー」だと思っていて,組織が「ガラパゴス化」しないためにも重要だと考えている.

4 . Be the information hub. Know what every engineer is working on, and help connect the dots that wouldn’t otherwise get connected.

Don’t

マネージャーだからということはなく,ポジションの問題だとは思うけど,マネージャーをメインで担当していると,コードを書く機会がどんどん減り,そこに危機感を持った結果,優先順位の低いまま残っているバグ修正をしてしまうという経験は誰しもあるのではないだろうか?絶対にダメだとは思わないけど,それでコードを書いた気になってしまうのも良くないので,僕は意識的に気を付けている.むしろ,コードを書かないとしても,品質を高く維持できるようなコードレビューをしたり,バグ修正に着手する前の実装デザインを一緒に議論したり,インパクトを残せるアクションを選ぶようにしている.

7 . Personally fix bugs and ship features. You have to write code to remain an effective tiebreaker, but that’s where your coding responsibilities end.

Motivation and culture

信頼残高を勝ち得るには,中長期的に成功し続ける必要がある.目の前のことに一喜一憂するのではなく,粘り強くアクションを起こすようにしている.

11 . Authority isn’t bestowed freely. It’s earned by making good decisions over time.

僕のチームは特に感じていると思うが,とにかく課題解決に対するアイデアは,メンバーに考えてもらうようにしている.考える機会はメンバー全員に平等に与えるべきだと思っているし,決定権もメンバーに与えている.そのときに個人的に意識しているのは「誰かアイデアありませんか?」と全員に問いかけるのではなく「○○さん,何かアイデアありませんか?」と期待値を込めて,名指しで聞くようにしている.そうすると,主体性を持ってアイデアを創出できるようになる.

12 . Don’t make decisions unless you have to. Whenever possible, allow the team to explore ideas and make decisions on its own.

Emotions and people

とにかく重要なのは「雑談」だというのは僕も同意で,世間話のような雑談でも,技術的な雑談でも,日頃から何でも話せる雰囲気を作るのはマネージャーの役割だと思っている.雑談の良いところは,論理的に話す必要がなく,思っていることを何でも気軽に話せるところにあると思う.また1人と雑談するのと,複数人と雑談するのでも意図が違うので,うまく使い分けられると良さそう.

20 . Most people won’t easily share their emotions. Have frequent informal conversations, and tease out everything that might be wrong. Then fix it if you can.

組織的な課題(ボトルネック)を常に客観的に探し,勇気を持って伝えるようにしている.メンバーが誰かしら気付いているのに言いにくいような課題もあるだろうし,メンバーが誰も気付いていないような課題もあると思う.さらに,多くの課題は価値観の違いによって気付かれないことがあるため,前提となる価値観を伝えて認識を合わせるのも必要だと思う.

22 . You’re paid to discover and fix cultural problems your team may not be aware of. Have the courage to say what everyone should know but doesn’t.

Tiebreaking and conflict

これは非常に重要なことだと思う.同じ結論になるとしても,マネージャーが決めるのと,メンバーが提案したアイデアを採用して決めるのでは,大きな差がある.実際にはメンバーが提案する方がインパクトが大きくなる.そのためにも,別の視点の質問をして議論を盛り上げる必要がある.何でもすぐに決めて進めてしまうと,結局メンバーは主体性を持てなくなってしまう.

25 . Don’t judge too quickly; you’re right less often than you think. Even if you’re sure you’re right in any given case, wait until everyone’s opinion is heard.

正直に言って,今までに経験してきたどの組織でも「あの人は苦手だから,あの人のアイデアは全て反対だ」という状況を見たことがある.人間はそもそも感情的なので,完全になくすことは難しいと思うが,頻度が高くなると,組織として何も機能しなくなってしまうので,チームを分割したり,辞めてもらったり,何かしらのアクションを起こすように気を付けている.また,好き嫌いだけではなく「技術的な信頼残高」に依存することも多いと思う.「あの人はバグを多く出すし,適当な性格だから,このアイデアはダメなのでは?」など.マネージャーは常に冷静に本質を見抜く必要があると思う.

29 . When disagreement gets personal or people don’t accept well-reasoned decisions, it turns into conflict.

Difficult conversations

難しい話を後回しにしてしまうというのは非常に良くわかる.ただし,状況をさらに悪化させる可能性もあるため,可能な限り早めに話すようにしている.また,そういうときに Slack や GitHub を使うのではなく,口頭で話すようにしている.日頃から雑談をしていれば,実は容易なことだが,雑談ができていないと,あえて Slack で情報を流してしまったりすると思う.

32 . Have difficult conversations as soon as possible. Waiting will only make a bad situation worse.

Rough edge

“Disagree & Commit” と表現することもあるが,個人的には「意志を表明すること」を重要視していて,さらにもし自分が反対したアイデアが採用された場合も,チームとして合意したのであれば,フルコミットで進めて欲しいと伝えるようにしている.議論の参加者が多いと「発言なし = 賛成」となるのに,ミーティングが終わって席に戻りながら不満を漏らしているメンバーがいたりもする.それでは議論の意味が全くないため,反対ならちゃんと意志表明をしてもらいたいし,どうしても言えなさそうなら,雑談を活用する.

39 . A firm “I’m not ok with that” is usually enough.

これも「意志を表明する」と似ていると思うが,常にニコニコする必要はなく,言うときは言う,感情を表に出すことは良いことだという雰囲気を作るようにしている.空気に流される必要はないと思う.関連して,よくある勘違いとして「チームの意思決定は多数決で行われる」というものがある.議論が本質的ではないと思ったら,空気に流されず「それは違うのでは?」と切り込む勇気を大切にしたいと思っている.

40 . Don’t laugh things off if you don’t feel like laughing them off. Have the courage to show your true emotions.

まとめ

“44 engineering management lessons” は,本当に参考になるマネジメントのバイブルで,定期的に読み直すようにしている.全部で44種類の原則があり,今回紹介しなかったものも多いため,是非一度読んでみてもらいたい.この記事はもっともっと有名になるべきだと思うし,僕の記事をキッカケに少しでも多くの人に届けば嬉しい.

(再掲する)

www.defmacro.org

関連記事

前の部署で僕のメンターをして頂いた @waysaku の記事もとにかく最高で,定期的に読んで「あー,ここ全然できてないなー」と反省をしつつ,改善をしている.特に「喋りすぎなマネージャー」と「条件反射」は今もまだ完全に直せてなくて,司会をメンバーに任せたり,突っ込みたくなるのを5秒我慢したり工夫はしているけど,まだまだという感じ.頑張る!

waysaku.hatenablog.com