クラウドネイティブ時代に最適化されたエンジニアリング組織の追求

クラウドネイティブな手法によるアプリケーションの開発はものすごい勢いで広がりをみせています。10年前とは全く違う世界がそこには広がっていますが、あなたの組織はそれら新しいエンジニアリング手法に対応できていますでしょうか？ 手法の変遷とともに、アプリケーションエンジニアとインフラエンジニアの垣根が曖昧になってきていることもあり、10年前と同じ考え方と組織では、クラウドネイティブな開発手法を活かし切れません。 このセッションでは現代のアプリケーション開発に携わる全てのエンジニアを対象に、各エンジニアがおさえておくべき姿勢と考え方、そして組織としてどう効率よく意思決定し、アプリケーションを進化させていくべきか、その理想を追求しお話します。

Transcript

1. クラウドネイティブ時代に最適化された エンジニアリング組織の追求 CLOUDNATIVE DAYS TOKYO 2020 1
2. 2 誰向けな話か これからクラウドネイティブな開発⼿法を 現場プロジェクトに導⼊中、導⼊予定な エンジニアやマネージャー
3. 3 ⾃⼰紹介 濱⽥孝治（ハマコー） • クラスメソッド株式会社 • CX事業本部 MADチーム マネージャー / シ ニアソリューションアーキテクト • 2020 APN AWS Ambassador • 2019 APN AWS Top Engineers • JAWS-UG コンテナ⽀部運営 • 好きな⾔葉「わっしょい」
4. 4 @hamako9999 ハマコー
5. 5 15分後 悩めるエンジニア・マネージャー の皆さんに 勇気と希望を与えることができることを 望んでお話します
6. 6 Agenda • ハマコーの⽴ち位置 • クラウドネイティブとは • ビジネスゴールに向けて必要不可⽋なもの • クラウドネイティブ活⽤におけるアンチパターン • エンジニア⼼構えとして⼀番重要な事
7. 7 ハマコーの⽴ち位置
8. 8 普段の仕事はこちら クラスメソッド MAD
9. 9 普段の仕事はこちら クラスメソッド MAD （Modern Application Development）
10. 10 クラスメソッド MADとは
11. 11 クラスメソッド MADとは サーバーレス コンテナ専⾨の 開発集団
12. 12 クラスメソッドMADの構造 クラス メソッド MAD 多種多様なお客様 ⽀援・開発 ノウハウの蓄積 ブログ執筆 担当顧客 Developers.IO
13. 13 クラスメソッドMADの構造 クラス メソッド MAD 多種多様なお客様 ⽀援・開発 ノウハウの蓄積 ブログ執筆 担当顧客 Developers.IO 膨⼤な数のお客様と ご⼀緒させていただいている
14. 14 今⽇の話の裏側 ⽇々お客様と接する中で感じる 率直な感想がベース
15. 15 クラウドネイティブとは
16. 16 CNCFの定義（⽇本語版） https://github.com/cncf/toc/blob/master/DEFINITION.md#%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88
17. 17 今⽇の話におけるクラウドネイティブの定義 クラウド上で コンテナとかサーバーレス使って システム提供すること （Kubernetes前提ではない）
18. 18 ビジネスゴールに向けて不可⽋なもの
19. 19 ビジネスゴールに向けて不可⽋なもの ビジネスゴール
20. 20 ビジネスゴールに向けて不可⽋なもの ビジネスゴール クラウドネイティブ
21. 21 ビジネスゴールに向けて不可⽋なもの ビジネスゴール クラウドネイティブ
22. 22 ビジネスゴールに向けて不可⽋なもの ビジネスゴール クラウドネイティブ 良いエンジニア組織
23. 23 良くないパターン ビジネスゴール クラウドネイティブ 良くない エンジニア組織 別の ⾏き先 遅延 検討のみ
24. 24 結局のところ 同じ⼿段を使っていても それを扱うエンジニア組織によって ⾏き先が異なる
25. 25 クラウドネイティブ開発における アンチパターン
26. 26 はじまります ここから主観丸出しで ございます
27. 27 アンチパターン① ビジネス上のクリティカルな 問題に新⼿法を使おうとする
28. 28 アンチパターン① サービス要件が⾮常に厳しいアプリケーションに慣れて ない⼿法を適⽤しようとする • 社運をかけたプロジェクト • 1秒たりとも落とせないサービス • 新⼿法を取り⼊れるメリットを最⼤限活かすため
29. 29 アンチパターン① サービス要件が⾮常に厳しいアプリケーションに慣れて ない⼿法を適⽤しようとする • 社運をかけたプロジェクト • 1秒たりとも落とせないサービス • 新⼿法を取り⼊れるメリットを最⼤限活かすため 失敗できないが故にスピードが遅くなる • 計画段階で複数プロダクトのプロコンを作成 • ⾮機能要件の全ケースと異常ケースを洗い上げ • 想定する全ての機能、⾮機能の検討が終わらない限り開発 に着⼿できない
30. 30 アンチパターン①の解決策 ⼩さくてコケても 問題ないものを対象にする
31. 31 アンチパターン①の解決策 SLA、SLOが低いもので試してみる • 社内のちょっとした情報共有ツールやブログなど • 半⽇ぐらい落ちても影響ないものあたりを選定
32. 32 アンチパターン①の解決策 SLA、SLOが低いもので試してみる • 社内のちょっとした情報共有ツールやブログなど • 半⽇ぐらい落ちても影響ないものあたりを選定 運⽤することでノウハウの蓄積速度が早い • 設計だけでなく、実際に⼿を動かして開発、そして運⽤す ることで得られる知⾒はものすごく⼤きい • 特にトラブル発⽣時に得られる知⾒は貴重 • たとえkubernetesの採⽤がオーバーエンジニアリングだ としても、あえてやってみる価値はある
33. 33 アンチパターン② すべてを計画だてて そのとおりに進めようとする
34. 34 すべてを計画⽴ててそのとおりに進めようとする 予算とスケジュールありきでプロジェクトを組む • 投⼊するエンジニアの⼈数と期間が決定済み • キャッシュアウトする部分の予算化のため計画ありきでス ケジュールが組まれている • リスクを抑えたいがため事例クレクレおじさんが発⽣
35. 35 すべてを計画⽴ててそのとおりに進めようとする 予算とスケジュールありきでプロジェクトを組む • 投⼊するエンジニアの⼈数と期間が決定済み • キャッシュアウトする部分の予算化のため計画ありきでス ケジュールが組まれている • リスクを抑えたいがため事例クレクレおじさんが発⽣ スケジュールが必達なため正常な意思決定ができない • 適切でない意思決定をしがち（リスクは低いがやたら⼿間 はかかる運⽤ができあがる） • 特に運⽤しないとわからないものが多い
36. 36 アンチパターン②の解決策 スコープを可能な限り⼩さくする
37. 37 スコープを可能な限り⼩さくする MVPの完成をゴールとする • 開発だけではなく、運⽤も評価できるようMVP （Minimum Viable Product）を設定 • 期間は2週間〜最⻑1ヶ⽉程度 • 実際に⼿を動かして評価することで、精度の⾼い意思決定 が可能
38. 38 アンチパターン③ ロールの違いを 過剰に意識する
39. 39 ロールの違いを過剰に意識する 最初にロールを作って、それに当てはまる作業を振り分 けようとする • 「Dev」 vs 「Ops」 • 「アプリ」 vs 「インフラ」 • 「YAMLは誰が書くの︖」
40. 40 ロールの違いを過剰に意識する 最初にロールを作って、それに当てはまる作業を振り分 けようとする • 「Dev」 vs 「Ops」 • 「アプリ」 vs 「インフラ」 • 「YAMLは誰が書くの︖」 クラウドネイティブなアプリケーションの開発や運⽤に おける考慮事項は多い • アプリケーション開発、構成管理、開発フロー整備、アプ リケーションデプロイ、テスト、監視、トレーシング、セ キュリティ、ロギング、ライブラリアップデート
41. 41 ロールの違いを過剰に意識する セクショナリズムが発⽣してチームパフォーマンスがで ない • 「これあんたがやるのでは︖」 • 「え、忙しいよ、そっちでしょ︖」 • 「そもそもこんな作業想定してないし」
42. 42 アンチパターン③の解決策 ゴールだけを⾒て役割分担する
43. 43 ゴールだけを⾒て役割分担する ビジネスゴール クラウドネイティブ 良いエンジニア組織 実装や運⽤が必要な機能 を都度考える
44. 44 従来のロールイメージ App1 統⼀インフラ基盤 HW保守 アプリケーション エンジニア インフラエンジニア App2 App3 App4
45. 45 クラウドネイティブなロールイメージ クラウド アプリより エンジニア App2 App3 App4 App1 インフラより エンジニア
46. 46 ゴールだけを⾒て役割分担する やるべきことを都度ロールに分類することは無理 • 多岐にわたる実施項⽬を「これインフラ︖アプリ︖」と分 類することは無意味
47. 47 ゴールだけを⾒て役割分担する やるべきことを都度ロールに分類することは無理 • 多岐にわたる実施項⽬を「これインフラ︖アプリ︖」と分 類することは無意味 マインドとして「落ちてるボールは拾いまくる」意識が 重要 • エンジニアリングとして成⻑できる機会、経験する機会を のがさない • 全ての問題が⾃分ごとに思えてくるぐらいが理想
48. 48 エンジニアの⼼構えとして ⼀番重要な事
49. 49 ⼀⾔ クラウドネイティブな技術を 楽しめているか︖
50. 50 ⼀番重要だと思うこと 全てのモチベーションの源泉は楽しさにある クラウドネイティブな技術を使うことを楽しめていますか︖ あなた⾃⾝は︖隣の同僚は︖
51. 51 ⼀番重要だと思うこと 全てのモチベーションの源泉は楽しさにある クラウドネイティブな技術を使うことを楽しめていますか︖ あなた⾃⾝は︖隣の同僚は︖ たかが⼿段、されど⼿段 技術はビジネスゴールの⼿段でしかないが、技術⾃体を楽し める知的好奇⼼があるほうが、圧倒的に学習スピードが早く なる
52. 52 ⼀番重要だと思うこと 全てのモチベーションの源泉は楽しさにある クラウドネイティブな技術を使うことを楽しめていますか︖ あなた⾃⾝は︖隣の同僚は︖ たかが⼿段、されど⼿段 技術はビジネスゴールの⼿段でしかないが、技術⾃体を楽し める知的好奇⼼があるほうが、圧倒的に学習スピードが早く なる ぶっちゃけビジネスゴールは後回しでも良いかも︖ ミニマムにやるなら、⼿段先⾏で始めるのも正解の⼀つ
53. 53 まとめ
54. 54 今⽇の話のまとめ • クラウドネイティブな開発においては、従来のイン フラエンジニア、アプリエンジニアの垣根は限りな く曖昧になっている
55. 55 今⽇の話のまとめ • クラウドネイティブな開発においては、従来のイン フラエンジニア、アプリエンジニアの垣根は限りな く曖昧になっている • クラウドを使うことで⼩さくスタートして早く学ぶ ことができる。それを活かした計画づくりをする
56. 56 今⽇の話のまとめ • クラウドネイティブな開発においては、従来のイン フラエンジニア、アプリエンジニアの垣根は限りな く曖昧になっている • クラウドを使うことで⼩さくスタートして早く学ぶ ことができる。それを活かした計画づくりをする • 組織として⼀番重要なのはクラウドネイティブな技 術要素を純粋に楽しめるかどうか