Developers.IO 2019に行ってきました。

Developers.IO 2019に行ってきたので興味を惹かれた発表のメモをまとめます。 主にカルチャー系の話ですね。

カルチャービルディング〜世界最強のAWSエンジニア集団の作り方〜（西澤徹訓）

クラスメソッド 資料

2014年~

• AWSビジネスがまだまだ成功していない
• 組織としてなにもない
  •  企業理念が浸透していない
  • 人事考課がない
  • 給与の基準がない
  • 採用の基準もない

部の理念を作った

企業理念「オープンな発送と高い技術力によりすべての人々の創造活動に貢献し続ける」はあったが、より具体的な部の理念を作った。 「AWSに関する圧倒的な量のノウハウを用いて、AWSインフラを安く早く構築し、AWSのことをまるっとおまかせしてもらうことで、顧客のビジネスに貢献する」

行動指針を作った

企業理念＋部の理念を実現するために求められる行動を明文化した。

• セルフマネジメント
• アウトプットファースト  

セルフマネジメント

• 自由に提案しオーナーシップをもって自分で実行
• やってみていいですか？ではなく、まずやってみる
• 許可を得るな、謝罪せよ

アウトプットファースト

• 自学自習
• 他人が見れないインプットは成果と見なさない

人事考課の仕組みを作る

• JD Meeting Guideを作成しメンバーに共有
• 4半期ごとに1on1、Guideにしたがってヒアリングし、来期の目標を設定

給与の基準を作った

• 職種ごとに求められる能力を明文化
• 職種ごとの給与レンジを明文化
• 職種ごとの定量的目標を明文化
• 給与改定方針を作成しメンバーに周知

採用基準を作った

• 理念と行動指針に従った採用基準を制定
• 採用基準を通りに採用すれば、理念や行動指針に従わない人ははいってこない
• 採用は企業カルチャーを醸成し維持するための最も重要なフィルター

 最低限組織に必要なものが完成

• 企業理念
• 人事考課
• 給与基準
• 採用基準

フェーズ２：組織拡大

• 100人、200人を超え拡大
• それでもカルチャーの維持は重要

キャリアパスの設計

• 3年後や5年後の自分の姿を想像しながら効率的に成長できるように、エンジニアのキャリアパスを明文化

• キャリアパスを意識しながら人事考課を実施 (資料より) ###  360度評価の導入 300人突破したぐらい

• 人事考課がマネージャーガチャにならないように、評価の目を増やす
• ランダムに複数の同僚を評価
• 評価項目の大半はカルチャー
• 結果は人事考課に使わず、あくまでマネージャーが参考として使う

カルチャーの浸透で大事なこと

• カルチャーは行動規範であり、人事考課に使わない
• あくまで「カルチャーの体現の結果として発揮されたパフォーマンスやアウトプット」に対して人事考課する

Amazon CultureとAWSの設計思想 ～マイクロサービスアーキテクチャとアジャイル開発～

AWS　公開資料なし？

Amazon のカルチャー

お客様視点でものを考える 常により良いものを求める 開発前にWorking Backwards 社内の情報共有のためにプレスリリースを書く 2ページのwordドキュメント

長期的に物事を考える Working Backwardsの最終目的が受け入れられていれば途中でうまくいかなくてもその仕事を続けられる

失敗に寛容 失敗したときに得た学びを社内に積み上げる 長期に渡り失敗していない場合は新しいビジネスが生まれる可能性がほぼない 最大の失敗fire phone チームは解散し、アレクサに ノウハウを活かす 全部目標を達成するとできそうなことを目標にしたと言われる。設定目標が低すぎたということ。 目標を達成したかどうかは考慮されない いけると思ったけどいけなかったことを好んでチェックする 学びなどが評価

会社を揺るがすような判断は一般社員に訪れないのでどんどんやろう 訪れたら経営層の問題 メディアは許可なく発信できない

パワーポイント禁止 パワーポイントは喋る人とセット 配置転換になったときわからなくなる 文章は本人がいなくなっても済むようにする

 マイクロサービス

AWSはマイクロサービスアーキテクチャで実装 それぞれのアプリケーションには単一の目的だけをもたせる アプリケーションの連携経路はAPIに統一

もともとはモノリシックアーキテクチャ

最初はメンテナンスしやすい システムが巨大になると一人の人間が理解できる物理限界に どこかいじるとどこに影響あるかわからない クラウド使っているのにスケーリングはCPUとメモリを増やすだけ 把握できなくなると組織の古株が腹くくって判断するしかなくなる デプロイしていいですかというメールが飛び交うccに大量のアドレス。把握してる人探し 組織に新しく配属された人間が全く活躍できなくなる 上の人にYESと言ってもらわないとやりたいこともできなくなる #### マイクロサービスへ 分割されたアーキテクチャに対しては小さいチームしか割り当てないように 2枚のピザでお腹いっぱいになる人数を上限 6~8名 チームがデプロイ、リリースの権限を持つ マイクロサービスアーキテクチャを採用しても最終的なリリース判断が一人では機動能力が全く活かせない 腹くくって任せる必要がある 制御が難しくなる欠点はある イベントドリブン型は非常に重要 せっかくAPI経由の疎結合で非同期に処理できるのにずっとwebソケットで通信しっぱなしとかは避けたい

クラウドネイティブアプリケーション開発

アジャイルだよねという話はよく聞く ドキュメントを後回しにしようという話 AWSはドキュメンテーションのサイクルはどうしているかという質問が多い アジャイルソフトウェア開発宣言https://agilemanifesto.org/iso/ja/manifesto.html マイクロサービスはAPIを基本として連携 既存のAPIの改修や新規のAPIのリリースは最大限の注意 AWSの場合EC2のAPIはユーザーが使うものと社内の他のサービス開発で使うAPIは同じ APIの挙動に影響を与えるタイプと与えないタイプのデプロイで注意するポイントはある程度変わる 一つのアプリケーションには単一の目的だけ持たすのが基本ポリシー APIの挙動に影響を与えないバージョンアップはそんなに発生しない ほとんど影響を与えるバージョンアップ ウォーターフォールが属性が近い それぞれのサービスがリリースの権限をもった独立したチームが自分たちの判断でリリースできるのが重要 外から見るとアジャイルのように見える AWSでは一つの組織が複数のマイクロサービスを開発しているより、 実際は別々の会社が存在しているに近い構成でやっている

AWSに超詳しいエンジニアが育つ環境をつくる方法

クラスメソッド 資料

楽しさについて

• 学習コストが高い職業
• 辛い勉強を長く続けるのはきつい
• なるべくなら楽しみながら成長したい

どうするか？

• 手を動かして何かを作るのは楽しい
•  興味のある技術を触るのは楽しい

-> AWS検証がカウントエオ全員分用意し、興味をもとに案件以外でも技術を触ってもらう

-> アウトプット前提でいろんなイベントに参加

楽しさを阻害しない

責任と裁量を与えてじぶんで仕事を管理 マイクロマネジメントしない

• ビジネス価値のあるアウトプットで判断
  • 案件の受注や対応
  • 社内Wikiへナレッジの蓄積
  • サービスを生み出す
  • イベントで登壇
  • 書籍の執筆
  • 技術ブログを書く
  • などなど

インプットがないとアウトプットできないので、必然的にインプットを行うようになる

ブログを書くことによる副産物->  自然と登壇できるようになる？ いろいろなイベントで約2週間の間に8イベントで約60人のメンバーが登壇

支える仕組みと雰囲気について

1on1

相互理解 信頼関係の確立 埋もれてしまう課題をキャッチアップ 成果を最大にする手伝い プライベートな相談 頻度は1週間または2週間に1回 時間は基本30分

互いを理解し目標や課題に対するアクションプランについて話し合う

セルフマネジメント

自律的にアクションを行う前提でエンジニア自身がタスクをコントロール

進捗報告は大きいものはしてもらうが細かいものはパフォーマンス出してアウトプットに向けてほしい

リモートワーク制度

• 業務効率化のため
• 通勤による消耗や時間のロスをなくす
• 自律的に動けるメンバーだから成り立つ

チャレンジし続ける

失敗を買わがる必要のない雰囲気と環境 チャレンジしたことが称賛される

• 案件/技術質問は専用のslackチャンネル
• 質問には全員で即レス文化
• 早い段階でアラートをあげてくれたことを評価する
• 組織としてフォロー体制をつくり課題解決

モチベーションの維持

ドーパミン型モチベーションで維持

(資料より)