はじめに
11/1に日本橋にて開催されたDevelopers.IO-2019に参加してきました。開催してくださったクラスメソッドさんと、忙しい時期にも関わらず行ってきなよと背を押してくれた弊社上司に深い感謝の意を表しつつ、回復したMPを使って得られた知見をアウトプットしていこうと思います。
本来は記憶の新しい内に書く予定だったのですが不運とは重なるのか、右目に異常が発生して絶賛片系稼働中なため適宜休憩を挟みながら出力しております。文章は恐らく変です。
私が拝聴したセッション
| セッションタイトル |
|---|
| カルチャービルディング〜世界最強のAWSエンジニア集団の作り方〜 |
| AWSに超詳しいエンジニアが育つ環境をつくる方法 |
| [Amazon CultureとAWSの設計思想 ～マイクロサービスアーキテクチャとアジャイル開発～] |
| ハイブリッド/マルチVPC環境を構成するためのAWSネットワーク完全理解 |
| IoT はここまできた！「作らずに創る」IoT システムとその先の「デジタル化＆データ活用」 |
| [DeepRacer発のモビリティコミュニティとちょっと自動運転の話] |
| [DeepRacerで学ぶ機械学習] |
申し込んだ当時はテクニカルな話をメインに参加セッションを組んでいたのですが、弊社で新しい取り組みを始めるということで部が新設されてそこに急遽配属されるという、自身の状況が若干変わったこともあって仮にそれを軌道に乗せる為にはどうすればいいかと考えた結果、ビジネスやマネジメント寄りの話も聞いておこうという結論になりました。
戦略理解に努めていこう的なやつです、はい。
その中でも特に重要なカルチャー部分に焦点を当てて今回は書いていこうと思います。
クラスメソッドさんの企業カルチャー
聞いてきた内容をスライドを挟みつつ書いていく予定でしたが、イベント当日に本家大本が詳細を書かれておりましたのでそちらをご参照ください。下手に書かれた物より1次ソースを読んだほうが圧倒的に良いです。常識です。
読みましたか？読みましたね？
私自身AWSが好きでしたのでDevelopers.IOにも日々お世話になっておりましたし、その他色々あってクラスメソッドさんの文化は知っているつもりでしたが、それでもなお驚きのあったセッションでした。
自分の周りは出来ている？
クラスメソッドさんが実施してきた企業カルチャーの構築を踏まえて例えばフェーズ1の部分を、自分の周りはどうだろうと知り合いと振り返ってみると、↓みたいな感じになりました。大体の企業に所属するエンジニアは同じ様なものなんじゃないかなと勝手に思っています。
・企業理念は確かある、意識しているかはというとNo、そもそもピンと来ていない。
・人事考課もある。最近できた。
・評価基準も一応ある、はず。
・採用基準は何かあるんだろうけど可視化or明文化されてはいない
・行動指針はあったっけ？パッと出てこない
仮に来年からこうします！と宣言してそれが浸透＆既存メンバーにマッチするかも難しいですし、場合によっては篩になってしまうこともありますね。成程、途中から作るとなると難易度の高さが伺えますね…。かと言って放置したままだとより一層難しくなりそう。いきなり広い範囲でやるのではなく小規模ではじめて徐々にオセロゲームしていくようになるのかな、という結論となりました。
エンジニアは企業カルチャーを意識するべきか？
クラスメソッドさんの様に強固にカルチャービルディングをしていない or 上手く実現できていないごく一般的な企業の場合、マネジメント層がめちゃくちゃ頑張る必要はもちろんありますが、エンジニアが全く意識しなくていいかというとそうではないと考えます。
理由としてはポジティブ/ネガティブで２つ挙げてみました。
・もしあなたが今いる企業が気に入っていて、企業はカルチャービルディングを正に進めようとしている場合、気付いた箇所からでもボトムアップで提案してより強い会社にしていくきっかけになると思います。その際に企業が何を考え何をやってきたかを理解する為のマインドの下地になると思います。
・もしあなたが今いる企業に特に何も感じていなくて、企業のカルチャービルディングが進んでいない場合、数年後あなたはもしかしたら自分たちは何者で何を実現する集団なのか考える様になるかもしれません。周りのみんなももしかしたら同じです。自分の立ち回りを見直すきっかけになると思います。
また、既にしっかりカルチャービルディングされている企業に所属している場合、言わずもがな当然意識する必要があります。というより意識して行動する事が仕組み化されてるはずですね。
マネジメント層も 足を運ぼう Developers.IO
自分たちの在り方を明文化して仕組みを作り共有して実行に移して信頼出来る仲間を集める。言葉にするのは簡単ですが想像力を少し働かせるだけでもハードルが高く感じてしまいます。スケール中の組織なら尚更です。企業カルチャーの重要性を説かれながらも多くの企業が苦戦しているのも頷けます。
この話どう結論づけようか迷いましたが、マネジメント層の方にも為になる内容でしたので是非、次回足を運んでみてはどうでしょうか？とオススメして締めようと思います。
AWSエンジニアが育つ環境について
AWSに超詳しいエンジニアが育つ環境をつくる方法、こちらもとても面白い内容で、タイトルこそAWSと銘打っておりますがAWSに限らず幅広く応用が効くと思うので続けて気になった箇所を書いて行こうと思います。
エンジニアが育つ環境の土台として３つあるとのことでした。
・カルチャー
・楽しさ
・支える仕組みと雰囲気
カルチャー
カルチャーの重要性やクラスメソッドさんのカルチャーは最初のセッションで聞いていた通りの内容です。
楽しさ
楽しさがエンジニアの成長を助ける
・エンジニアは
・学習コストが高い職業
・ツライ勉強を長く続けるのはツライ(うん、うん)
・技術を楽しみたい(そう、そう)
・なるべくなら楽しみながら成長したい(わかる)
・楽しさを阻害する要素を取り除く
・仕事を管理されることはストレスになる
・管理自体が管理職/エンジニア共に高コスト
→責任と裁量を与えて自分で仕事を管理(企業カルチャーにあるセルフマネジメント)
→マイクロマネジメントはしない（WBS引いて細かな進捗管理しない）
→ビジネス価値のあるアウトプットで判断
→ビジネス価値のあるアウトプットとは？
・案件の受注や対応
・社内wikiへのナレッジの蓄積
・サービスを生み出す
・イベントで登壇する
・書籍の執筆
・Developers.IOのブログを書く
アウトプットはそもそもインプットがないと出来ない。
→必然的にインプットを行うようになる
・AWS公式ドキュメント
→AWS公式ブログ
→BlackBelt
・Developers.IO
・社内Slack(技術相談やRSS)
・勉強会(社内外)
・案件対応
・書籍
・SNS
副産物として登壇したりLTも行うようになる。
有名なラーニングピラミッドに当てはめるとこうなるとのこと。
これらピラミッドの各階層を日々の活動で抑えることで高効率な学習サイクルが実現できている印象を受けました。
成長を支える仕組み
１on１ミーティング
お互いを知り、信頼関係を深めながらお互いを理解し目標や課題に対するアクションプランについて話し合う。
セルフマネジメント
自律的にアクションを行う前提でエンジニア自身がタスクをコントロール
管理者への進捗報告などにかかるコストをアウトプットへ向ける
リモートワーク
通勤による消耗や時間のロスをなくす
※自律的に動けるメンバーだから成り立つ
案件のアサインは挙手制
案件内容に対して高いモチベーションのメンバーが対応できる
※私自身、話を聞いていてこれが一番驚いたかも知れません。そもそもどんな案件が有るのかオープンじゃないと成り立たないわけでして、選択出来る環境というのは正にカルチャーショックでした。
継続的なチャレンジ
チャレンジをして成功体験を積み上げる
→その為にチャレンジしやすい環境をつくる
→失敗を叱責するのではなくチャレンジが称賛される
案件/技術質問は専用のSlackチャンネル
→質問には全員で即レス
※チャットの活用について以前上司と会話したことが有るのですが、客先常駐なSESだとそもそも多くの社員が活発にやり取りが出来るConnectedな状況を作り出すのが難しいなあと悩んでます。何方か良い知見があればご教示ください。
モチベーション
モチベーションには２パターンある。
・ノルアドレナリン型モチベーション
危機回避用モチベーション。即効性と強いストレスが伴う。
・ドーパミン型モチベーション
結果と報酬によるモチベーション
即効性とストレスはないけどルーティン化出来る
ドーパミン型モチベーションを好循環で長期間維持することによってAWSに詳しいエンジニアが育つ環境が出来るとのことでした。
私のモチベーションタイプを比率で表すと恐らく６:４くらいの割合な気がするので、ドーパミン型モチベーションサイクルを作っていこうと思います。
まとめ
経営の歴史やセオリーについて詳しくは知りませんが、近代的で理にかなった経営なそれらがガチッと嵌ってるんだなあという印象を受けました。技術とは別視点で見る強さの秘訣を学べた素晴らしいベントでした。