Cloud Native On-boarding

Transcript

1. Cloud Native Onboarding ~実践で身につけるモダンインフラの基礎~ Presented by Kohei Ota and Takuya Mikami CloudNative Days Tokyo 2020
2. 自己紹介
3. 自己紹介(メンティー) 名前: 三神 拓哉 所属: ZOZOテクノロジーズ 役職: エンジニア カタギの人 普通の人 オンプレミスを扱う部署から 　　　　　　　　　　クラウドを扱う部署へ異動
4. 自己紹介(メンター) 名前: 太田 航平 (@inductor) 所属: HPE 役職: ソリューションアーキテクト Kubernetes SIG-Docs Japanese localization owner Cloud Native Ambassador Docker Meetup Tokyo、本カンファレンス運営
5. 自己紹介(メンター) 名前: 太田 航平 (@inductor) 所属: HPE 本セッションはZOZO時代の話をします 役職: ソリューションアーキテクト エンジニア Kubernetes SIG-Docs Japanese localization owner Cloud Native Ambassador Docker Meetup Tokyo、本カンファレンス運営
6. アジェンダ
7. アジェンダ • 本セッションの動機 • 今日のゴール • メンティー視点 ◦ 基本的な業務の進め方 ◦ Cloud Nativeな開発を始めて意識するようになったこと ◦ 振り返り • メンター視点 ◦ オンボーディングの基本 ◦ チーム結成後の動き方と実践に向けたアプローチ ◦ 実践でうまくいったこと、いかなかったこと
8. 本セッションの動機
9. 本セッションの動機 (メンティー視点) • オンプレだけでこのままやっていけるのかという漠然とした不安の解消 ◦ クラウド未経験からクラウドネイティブなエンジニアに転身 • 社外勉強会で他社エンジニアと交流したときに感じた外とのギャップ ◦ 自身は3ヶ月のオンボーディングと実務経験で様々なことを学ぶことができた ◦ 周りからは『どうやって勉強したのですか？』という声が多かった ◦ 多くの人がクラウドネイティブに関する興味を持っていると感じた
10. 本セッションの動機 (メンティー視点) • オンプレだけでこのままやっていけるのかという漠然とした不安の解消 ◦ クラウド未経験からクラウドネイティブなエンジニアに転身 • 社外勉強会で他社エンジニアと交流したときに感じた外とのギャップ ◦ 自分は3ヶ月のオンボーディングと実務経験で様々なことを学ぶことができた ◦ 周りからは『どうやって勉強したのですか？』という声が多かった ◦ 多くの人がクラウドネイティブ関する興味を持っていることを感じた クラウドネイティブな技術に興味はあるが、はじめ方がわからない人が多い？ 『仕事でクラウドを使う』ことに大きな壁を感じている人も多い！ 自身を例としてクラウドネイティブなエンジニアになるまでの知見を共有したい
11. 本セッションの動機 (メンター視点) • 前職のチームビルディングが自身のキャリアにとって1つの大きな資産 ◦ チームの仕事に再現性のある一定のクオリティを与えられた ◦ 技術力は当たり前として、チームとして何をどうすべきか考えながら動く文化 • 自分がメンターをやった成果 ◦ 1クオータ(3ヶ月)で2人のクラウドネイティブなエンジニアを育成した ◦ 今回ZOZOテクノロジーズ関係で登壇している 4人はその時のチームメンバー全員（！） ▪ リーダーが@sonots、サブが私
12. 本セッションの動機 (メンター視点) • 前職のチームビルディングが自身のキャリアにとって1つの大きな資産 ◦ チームの仕事に再現性のある一定のクオリティを与えられた ◦ 技術力は当たり前として、チームとして何をどうすべきか考えながら動く文化 • 自分がメンターをやった成果 ◦ 1クオータ(3ヶ月)で2人のクラウドネイティブなエンジニアを育成した ◦ 今回ZOZOテクノロジーズ関係で登壇している 4人はその時のチームメンバー全員（！） ▪ リーダーが@sonots、サブが私 参加者の皆さんにも、仕組みとして導入できそうなノウハウをシェアしたい！ きっとこういう内容で悩んでいる人はいるはず！ という気持ちで申し込みました。
13. アジェンダ • 本セッションの動機 • 今日のゴール ← • メンティー視点 ◦ 基本的な業務の進め方 ◦ Cloud Nativeな開発を始めて意識するようになったこと ◦ 振り返り • メンター視点 ◦ オンボーディングの基本 ◦ チーム結成後の動き方と実践に向けたアプローチ ◦ 実践でうまくいったこと、いかなかったこと
14. 今日のゴール
15. 今日のゴール (Key takeaways) • 今日からあなたもクラウドネイティブ！ • 自主学習とオンボーディングの活用で、短期間でも実践できる学習法 • メンターとメンティーの関わり方について考えるきっかけにしてほしい • 仲間を増やすことの大切さについて知ってほしい
16. 当時の背景 • 時は2019年の終わり頃 ◦ なんか認証基盤をリプレイスするみたいな話が出た ◦ 深遠な理由で比較的ベンダーニュートラルな技術スタックで基盤を作りたいという要件 ◦ ML基盤チームでKubernetesの利用が進んでいたので白羽の矢が立った • ZOZOTOWNオンプレチームとの連携 ◦ リプレイス案件なので、既存のシステムに理解のあるメンバーも必要だった ◦ オンプレチームから 2人が名乗りを上げたため、合計 4人の新しいチームが結成された
17. メンバー構成 • リーダー ◦ @sonots - 圧倒的リーダー • メンバー ◦ @inductor - Kubernetes利用歴が一番長いので教える人になった ◦ @god(三神) - 神 ◦ @kame(亀井) - 亀 @sonots @kame の セッションも是非ご覧ください →
18. メンバー構成 • リーダー ◦ @sonots - 圧倒的リーダー • メンバー ◦ @inductor - Kubernetes利用歴が一番長いので教える人になった ◦ @god - 神 ◦ @kame - 亀 当時兼務で忙しかったリーダーを除き 1人のメンターと2人のメンティーで クラウド技術の第一歩を歩み始めた (オンボーディング開始)
19. アジェンダ • 本セッションの動機 • 今日のゴール • メンティー視点 ← ◦ 基本的な業務の進め方 ◦ Cloud Nativeな開発を始めて意識するようになったこと ◦ 振り返り • メンター視点 ◦ オンボーディングの基本 ◦ チーム結成後の動き方と実践に向けたアプローチ ◦ 実践でうまくいったこと、いかなかったこと
20. メンティー的業務の進め方
21. メンティー的業務の区分と進め方 • リアクティブな動き方 (チームのために動く) ◦ タスクをもらったときに指摘を受けたことや意識したこと ◦ タスクへの取り組み方とすり合わせ ◦ ゴールの設定と振り返り • プロアクティブな動き方 (自己学習のために動く) ◦ 完全ガイドを用いた輪読会 ◦ 帰り道の反省会 ◦ 社外勉強会への参加
22. チームを意識した動き
23. メンターからの指摘点や改善点 • 思考のドキュメント化 ◦ 1年後の自分が見ても理解できるような文章を心がける ◦ 自分がいつ辞めてもいいように仕事をする • タスクをもらった時に最初に議論する ◦ 認識が合わないままタスクが進んでも誰も幸せにならない ◦ 不明点は明らかに • クロスレビューの徹底 ◦ 事前にメンバー同士でレビューを繰り返すことでリーダーの仕事を少しでも減らす ◦ 物事を多面的に見るためには他人の目が必要なことも多い
24. タスクへの取り組み方 • レビューを最優先タスクにする（自身を他人のボトルネックにしない） ◦ レビューは質問や議論の格好の場。分からないことを理解できるのは大切なこと • 不明点はすぐ質問 ◦ 期間が短いので詰まることすらもったいない。集合知は正義。議論を徹底的に！ • 成果物ができたらすぐ共有 ◦ 共有が早ければレビューも早くできるし、仕事も早く終わる • ペアプロ推奨 ◦ 手の動かし方を学び、できる人の思考を理解できる
25. ゴールの設定と振り返り • タスクの最初にゴールのすり合わせを行う ◦ 不明点を洗い出しておくことでタスクを迅速に進めることができる • 大きなタスクをサブタスク化して細かくゴールを定義する ◦ 調査・改善・設計・実装などフェーズによって目指すべきゴールも変わる • 隔週のKPTで振り返り ◦ 日常的に業務改善するための仕組みづくり
26. (参考)いつかのKPT(抜粋) • KEEP ◦ Gitを使えるようになってきた ◦ 学習のINPUT/OUTPUTの時間を強制的に設定した • PROBLEM ◦ 単純な知識が足らないので指摘してもらった点を理解するのに時間がかかる • TRY ◦ 単純な知識が足らないので指摘してもらった点を理解するのに時間がかかる → ホワイトボードで話して写真とってドキュメントに貼っておいてもらえるとよさそう (そ のっつ）
27. 当時の ホワイトボード
28. 自己学習のための動き
29. 完全ガイドを用いた輪読会 • メンティー２人で毎週1章ずつKubernetes完全ガイドの輪読会を実施 • お互いの資料について質問 ◦ 担当しているタスクに関する質問 /議論
30. 帰り道の反省会 • その日メンターから受けた指摘点を帰り道で振り返る ◦ 人の振り見て我が振り直せ • 技術で自分が知らなかった点、誤認している点を共有 ◦ 他人も同じポイントでハマりがち • 明日への活力 ◦ 大事
31. 社外勉強会/技術ブログへの参加 • 人と議論することが理解を深めるための最短経路 ◦ 同じレベルの人と会話する機会を増やすことが大事 • ブログ等の明文化は自分の思考整理にとても有効 ◦ 自分の中で理解していない部分が見つかる • 学んだことのアウトプットは必ず誰かの為になる ◦ 「こんなこと、みんな知ってるはず」という思考は不要
32. Cloud Nativeな開発を始めて 意識するようになったこと
33. 中長期運用を意識した変化に強い構成管理 • 気軽に更新/改修ができる環境を用意する ◦ dev / stg / prd の3環境を用意し、インフラのコード化によって構成を統一 • 更新/改修フローを自動化し構成管理に再現性をもたす ◦ インフラのCI/CDを作り込むことで環境に直接触れる必要がなくなった
34. 中長期運用を意識した変化に強い構成管理 • dev / stg / prd の3環境を用意し、インフラのコード化によって構成を統一 dev stg prd
35. 中長期運用を意識した変化に強い構成管理 dev stg prd git push • dev / stg / prd の3環境を用意し、インフラのコード化によって構成を統一 加えて、インフラのCI/CDを作り込むことで環境 に直接触れる必要がなくなった
36. 中長期運用を意識した変化に強い構成管理 dev stg prd git push • インフラのCI/CDを作り込むことで環境に直接触れる必要がなくなった ・運用を踏まえた設計のシンプルさ(Simplicity) ・改修、追加のコストを抑えるための簡単さ(Easiness) のどちらも両立した基盤設計ができた
37. 基盤を『作る』よりも『使う』
38. 基盤を『作る』よりも『使う』 『サービスが動くものを作る』から 『マネージドサービスをうまく使う』へ考えがシフト
39. 基盤を『作る』よりも『使う』 • 物理レイヤーを意識しなくなり、基盤自体の最適な使い方を考える 余裕ができた ◦ マネージドサービスの利用における比較検討や検証などが日常的にできるようになった ◦ インフラだけでなく、アプリケーションの CI/CDも開発チームと一緒にメンテナンス • 検討、検証のサイクルが短くなった
40. 守備範囲や働き方の変化 • 複数人での開発をGitで進めるのが当たり前に ◦ ソフトウェア開発との境界線が曖昧になってきた ◦ 一人ひとりの守備範囲を広くとることで、誰かが欠けても回せるチーム作り • 他人のタスクをレビューするのが当たり前に ◦ タスクを作るときにゴールを明確にするための議論ができているからこそできること ◦ 隔週の振り返りや、質問の文化が活かされる場面 • 実現(How)はコードに、思想はドキュメントに記載するのが当たり前に ◦ コードには何をしたか、どうしたかがある ◦ コメントには経緯などが書かれている ◦ ドキュメントには、なぜ他のアプローチを取らなかったかが書かれている
41. 守備範囲や働き方の変化 • 複数人での開発をGitで進めるのが当たり前に ◦ ソフトウェア開発との境界線が曖昧になってきた ◦ 一人ひとりの守備範囲を広くとることで、誰かが欠けても回せるチーム作り • 他人のタスクをレビューするのが当たり前に ◦ タスクを作るときにゴールを明確にするための議論ができているからこそできること ◦ 隔週の振り返りや、質問の文化が活かされる場面 • 実現(How)はコードに、思想はドキュメントに記載するのが当たり前に ◦ コードには何をしたか、どうしたかがある ◦ コメントには経緯などが書かれている ◦ ドキュメントには、なぜ他のアプローチを取らなかったかが書かれている 完全に同じではないが アプローチは似ている
42. 秘匿データの扱い方、考え方の変化 • 公開するサービスは既存環境と変わらない対策が求められる • コード管理を始めたことでパスワードの平文記載文化を見直す ◦ External Secretsを用いてAppの秘匿情報をGitのKubernetesマニフェストに載せずに 管理する手法の導入 • SSHによるアクセスを行わない方針(EKS, GKEどちらでも実現可能)
43. 秘匿データの扱い方、考え方の変化 パスワード等の秘匿情報をより厳密に管理 • 公開するサービスは既存環境と変わらない対策が求められる • コード管理を始めたことでパスワードの平文記載文化を見直す ◦ External Secretsを用いてAppの秘匿情報をGitのKubernetesマニフェストに載せずに 管理する手法の導入 • SSHによるアクセスを行わない方針(EKS, GKEどちらでも実現可能) オンプレミスでは実現が難しいセキュリティ要件でも マネージドサービスを利用することで対応できるかも？
44. コストに対する考え方 • 物理サーバを購入した場合はダイレクトに維持費が変動することは無い 運用の効率化に成功しても 物理的な維持費は変わらない
45. コストに対する考え方 • クラウドは利用分だけ課金されるため、コスト感をより意識する 俺の効率化で前月よ り安くなってる！
46. スケジュールに対する考え方 • 物理サーバの購入に1~2ヶ月程度かかるので準備期間がある • 物理的作業や構築作業の分担があって余裕をもったスケジュールになる サーバ屋 綿密な計画やスケジュール調整が大事
47. • 構築準備が不要なので、設計から構築までのリードタイムが無い！辛い • 個人のスキル次第でこなせるタスク量に差が生まれる 待ち時間が無い サーバ屋 スケジュールに対する考え方 個人のスキル次第でタ スクを進められる
48. ここまでのまとめ • 短期間で多くのことを学ぶには「個人」と「チーム」どちらの動きも重要 • クラウドとオンプレは一直線上にあるものではなく、別の概念 ◦ かといって、太刀打ちできないわけではない
49. メンティーとしての振り返り
50. クラウドネイティブ入門の心構え • あなたは今、『新しいこと』に挑戦しようとしてます • 初めはみんな、学ぶところから始めています ◦ いま『インフラエンジニア』でも、知らないことがあるのは当たり前 • オンボーディングはその勇気を踏み出すための第一歩
51. クラウドネイティブ入門の心構え • あなたは今、『新しいこと』に挑戦しようとしてます • 初めはみんな、学ぶところから始めています ◦ いま『インフラエンジニア』でも、分からない事があるのは当たり前 • オンボーディングはその勇気を踏み出すための第一歩 『新しいものに挑戦する』と意識するべき 新しいものに挑戦するからには分からないことが多くて当然 半年後に成果が出てれば大成功 (だと思う)
52. 自走の仕方を学ぶ • 魚をもらうのではなく「釣り方」を教わる意識 • 他人の実践方法を「盗む」 ◦ 周囲のエンジニアはもちろんだが、インターネット上には情報がたくさん転がっているので都合 のいいものだけ「いただく」 • アウトプットにより指摘をもらいに行く ◦ 本来なら自分がもっと積極的にアウトプットすべきだが、不足を感じており今後の課題
53. メンターとの接し方 • メンターがいる最大のメリットは議論ができること ◦ 悩んでいる時は積極的に悩みのポイントを伝える (タスクの頭出しフェーズなど ) ◦ 結論を出したい時は自分が考えうるベストを尽くして結論に関する 5W1Hを伝える ▪ ドキュメント整備の習慣がさらに活きてくる • 自身の考えを整理したうえで積極的に議論を重ねるべき ◦ 結果的に間違っていたとしてもきちんと振り返ることが大切
54. 学ぶ仲間が一緒にいてよかった • 最も気軽に相談できるのは、同じレベルの仲間 ◦ 相談しながら一緒に思考を整理できる ことが強み ◦ 自分の至らなさに挫折しそうな時に 支えになってくれる • お互いに質問し合ったり、教え合ったりすることは理解への最短経路 ◦ 自身とは違う視点で疑問を持てる相手 がいると、学びが深くなる ◦ 「間違ったことを教えてはいけない」という意識が 物事を正しく理解する習慣 につながる
55. ここまでで、だいたい 30分ちょいの想定(フラグ)
56. メンターが最後の 追い上げをします
57. アジェンダ • 本セッションの動機 • 今日のゴール • メンティー視点 ◦ 基本的な業務の進め方 ◦ Cloud Nativeな開発を始めて意識するようになったこと ◦ 振り返り • メンター視点 ← ◦ オンボーディングの基本 ◦ チーム結成後の動き方と実践に向けたアプローチ ◦ 実践でうまくいったこと、いかなかったこと
58. メンター的 オンボーディングの基本
59. オンボーディングにおける原則 • レビューは最優先タスク • 不明点はすぐ質問 • 成果物ができたらすぐ共有 • ペアプロ推奨 • 思考のドキュメント化 • タスクをもらった時に最初に議論する • クロスレビューの徹底 メンティー視点と 基本は同じ
60. オンボーディングにおける原則 • レビューは最優先タスク • 不明点はすぐ質問 • 成果物ができたらすぐ共有 • ペアプロ推奨 • 思考のドキュメント化 • タスクをもらった時に最初に議論する • クロスレビューの徹底 メンティー視点と 基本は同じ 最も重要なポイント: 1. メンター自身が実践できている こと 2. できたことを認識してもらうこと！ 「やってみせ、言って聞かせて、させてみせ、ほめて やらねば、人は動かじ」 by 山本五十六 といいつつ、sonotsさんの受け売りです＞＜
61. チーム結成後のアプローチ
62. メンター自身が実践できること • 基本的に自分ができないことは無理に教えようとしない ◦ 自分の間違った理解を相手に伝えることはチーム全体にマイナス ◦ リーダーに頼るべきところは頼る。その代わり 普段はできるだけ負担をかけず に動く • アウトプットは自分が一番積極的に ◦ 会社に紐付いたQiita(アドベントカレンダーとか )やテックブログへの貢献 ◦ チームで使っている OSSへの貢献 ◦ その他コミュニティでの会社としての登壇 • ちょっとしたペアプロやDiscordでの雑談の機会を逃さない ◦ 教わるメンティーにとって「こいつ常に暇なのでは？」と思わせるくらいの錯覚を与える ◦ 見えないところでがんばる 「お前が言うなよ」 と言わせない実行力
63. できたことを認識してもらう • ゴールのすり合わせ ◦ 相手が見えない世界をいきなりは無理に見せない • KPTや朝会などを定期的に行うことで定期的にタスクを共有 ◦ メンターとか関係なく一人の人間として進捗にばらつきがあるのは当たり前 ◦ みんながスーパーマンではない。相談しながら改善を続けるための仕組みを用意 ◦ タスクのKPTをシェアすることで達成感を持ちつつ、チーム自体の距離を縮める • 1on1の実施 ◦ 日々の業務とは別に、リーダーの sonotsさんに1on1をやってもらうように依頼 ◦ リーダーは話を誘導せず傾聴に徹し、メンバーが話したいことを話せる環境づくり
64. できたことを認識してもらう • ゴールのすり合わせ ◦ 相手が見えない世界をいきなりは無理に見せない • KPTや朝会などを定期的に行うことで定期的にタスクを共有 ◦ メンターとか関係なく一人の人間として進捗にばらつきがあるのは当たり前 ◦ みんながスーパーマンではない。相談しながら改善を続けるための仕組みを用意 ◦ タスクのKPTをシェアすることで達成感を持ちつつ、チーム自体の距離を縮める • 1on1の実施 ◦ 日々の業務とは別に、リーダーの sonotsさんに1on1をやってもらうように依頼 ◦ リーダーは話を誘導せず傾聴に徹し、メンバーが話したいことを話せる環境づくり メンターが特別ぶっ飛んだことを やってるわけじゃないと伝える SRE Nextのそのっつさんのスライドに詳し く書いてあります
65. 文化の継承と成果
66. 文化の継承 仕組みによって伝えられることは仕組みで伝えるべきだが、限界はある 例: やらないことの範囲を決める、 まず最初にゴールを明確にする etc.
67. 文化の継承 • クラウドの考え方やSREという文化を伝えるために ◦ SREの考え方に則り、ソフトウェア開発の手法 を積極的に取り入れる ▪ CI/CDは触れて当たり前だし、無いと困るくらい体験の良いパイプラインを作る ▪ OSSにIssueを立てる、PRを投げるのは当たり前 • git pushするだけでKubernetes YAML/ Terraform/CFnのCI/CDが反映されるパイプライン • アプリケーションのデリバリーも自分たちで作る • 「なぜ他の方法をとらなかったか」が ドキュメント化されている • 外部の人にも情報を一般化して伝えられる
68. 文化の継承 • クラウドの考え方やSREという文化を伝えるために ◦ まだ実現できてないタスクも ある程度道筋を示した上で 渡す(相談できる安心感を与える ) ▪ 例1: AWSで機密情報どうやって管理しますか？ ▪ 例2: SSHのポートを開けずにどうやってトラシューしますか？など ▪ 結果: オンプレとクラウドの違いを意識しつつ設計から考える機会ができた • 検証、設計などをドキュメント化し、 IaCで実装、構築、 運用までを体系的に行ってもらう • 答えが大体分かっているものをお願いする • よくわからんやつは(最初は)全部巻き取る
69. 文化の継承による成果 • クラウドの考え方やSREという文化を伝えた成果 ◦ 既存のオンプレでは仕組みとして作れていなかった無停止 & 全自動のデプロイを 作り込むことによって、 SREとして担当できる範囲を増やせた ◦ 開発チームとの日常的なコミュニケーションは 当たり前にできるようになった
70. 文化の継承による成果 • クラウドの考え方やSREという文化を伝えた成果 ◦ 既存のオンプレでは仕組みとして作れていなかった無停止 & 全自動のデプロイを 作り込むことによって、 SREとして担当できる範囲を増やせた ◦ 開発チームとの日常的なコミュニケーションは 当たり前にできるようになった • メンターのおかげではなく、ここまで自分たちがこなしたタスク や養った経験の成果であると認識してもらう ◦ ドキュメントやKPTとして全て成果が残っている ◦ 給料や職位も爆上がり！！！！
71. 文化の継承による成果 • クラウドの考え方やSREという文化を伝えた成果 ◦ 既存のオンプレでは仕組みとして作れていなかった無停止 & 全自動のデプロイを 作り込むことによって、 SREとして担当できる範囲を増やせた ◦ 開発チームとの日常的なコミュニケーションは 当たり前にできるようになった • メンターのおかげではなく、ここまで自分たちがこなしたタスク や養った経験の成果であると認識してもらう ◦ ドキュメントやKPTとして全て成果が残っている ◦ 給料や職位も爆上がり！！！！ 「やってみせ、言って聞かせて、させてみせ、ほめてやら ねば、人は動かじ」 by 山本五十六(&sonots)
72. うまくいかなかったこと
73. うまくいかなかったこと • (SREなのに)コードを書いてもらう時間が全然とれなかった ◦ 日々の業務をこなしながらの 3ヶ月ではA tour of Goをちょっとやってもらうのが精一杯 ◦ そもそも自分もプログラミングはそこまで得意じゃない • リーダーのサポートが十分にできなかった ◦ (当時の自分もだったが、自分以上に )複数のポジションを兼務していて、できるだけ タスクを取りたかったが、思った以上の成果は出せなかった • プロダクション運用はやれなかった ◦ 設計構築までの段階で自分は離れてしまったので、運用までメンターはできなかった ◦ オンボーディングだけする引き継ぎのおじさんになってしまったことは否めない
74. メンターとしての振り返り
75. 振り返り 「やってみせ、言って聞かせて、させてみせ、 ほめてやらねば、人は動かじ」
76. 振り返り 「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ」 このスライドは、僕にとっての バイブルです 参考: “「ZOZO MLOps のチームリーディング とSRE(Engineering)」というタイトルで SRE Next 2020 に登壇しました”
77. まとめ(Key takeaways) • 今日からあなたもクラウドネイティブ！ ◦ 新しいことを学ぶためには 仕組みと取り組みが重要 • 自主学習とオンボーディングの活用で、短期間でも実践できる学習法 ◦ 日々の業務でも、リアクティブ、プロアクティブを意識して動く • メンターとメンティーの関わり方について考えるきっかけにしてほしい ◦ メンター、メンティー共に上下はなく ただの役割 ◦ 対等に議論できる仕組みと文化づくりが重要 • 仲間を増やすことの大切さについて知ってほしい ◦ 気軽に相談できる仕組みと文化づくりが重要
78. ありがとうございました