こんにちは！新卒2年目の @y_hideshi です！
私はオンプレで管理していたアプリをクラウド(GCP)に移行する「クラウド移行」をかれこれ一年以上やっています！
クラウド移行はアプリに詳しいアプリ開発メンバーとインフラ周りに詳しいSREGメンバーと一緒に行います！基本はアプリ開発メンバーが必要な設定ファイルなどを用意します。SREGメンバーはLBやDBの用意をし、準備が整い次第クラウドにあげます。その際、環境が変わったことによる不具合やクラウドに移行するために仕様や構成を変更するための対応を行う必要があります。
今日までの間、私たちのチームは1人の状態の時もあれば複数人の状態に変わりながらもこれらの多くのタスクをこなして来ました！
今回はそれらのタスクを1人でやっていた状態から複数人のチームで作業するために、やってよかったことを話したいと思います！
これまでのチームの状態
- 2017年11月
- SREGメンバー・メンターがやっていたクラウド移行にJOIN!!
- メンターからやるべき作業の内容を教えてもらう
- 2017年12月：
- メンターがいなくなる (寂しい) 😢→ 開発メンバーが私ひとりになる
- 2018年1月~3月：SREGメンバーとともに二人三脚で頑張る！
- わからないところもSREGメンバーとグーグル先生に相談しながら頑張る
- だいぶ知見がついてくる！
- 2018年4月：開発メンバー3人のチーム結成
- 新しい開発メンバーと一緒にがんばる！人が増えて嬉しい！
- 2018年7月：2人チームに変更
- 2018年9月：5人チームに変更
- リーダーポジションにつかせてもらい、チームを引っ張ろうと頑張る💪
- 2018年12月：3人チームに変更
- 頑張っている💪
やってよかったこと😍
「なぜやるか」と「ゴール」の認識をあわせる
認識を合わせる理由は大きく二つあります。
- 手戻り・無駄な作業をなくす
- タスクの意味・内容を納得・理解して進む
やるべきタスクが大量にある中、私たちは常に効率化を求められます。効率化をするためには、言われたことをただやるだけではいけないと思っています。
そのため私たちのチームは、週の振り返りやタスクを設定する際に下記のことをメンバー間で話し合いチームの改善を図ってきました！
- 朝会なぜやるんですか？
- この作業なんでやってるんですか？
- このタスクのゴールはなんですか？
とにかく疑問に思ったことをぶつけまくり、認識のブレや余分な作業が発生していないかを確認します。
そうすることで、私たちのチームは手戻り作業や無駄になっていた作業を減らすことができました！
また、メンバー全員が行うタスクに対して納得した上で作業するため「これなんでやってるんだ...」といった疑問を持つことやタスクの意味を考えて動けるようになりました！
ペアでの作業
もともと私1人で行なっていたこともあり、私に知識が偏り属人化していました。この問題を解決するために「知見の共有」ということでペア作業を行なった結果、下記のメリットをチームにもたらし、チームでの作業を効率化してくれました！
- 知見の共有
- 意思決定の高速化
- 共有・レビューコストの低下
- 精神的安全の確保
メンバーが増減する中、ペアでの作業はとてもよい方法だと感じています！新しいメンバーに知見を共有しながら作業を進められるのに加え、わからないことをその場ですぐに聞くことができます。
主に調査作業や環境が変わったことによる対応が多いクラウド移行では、共有コストの低下は非常に重要となってきます。。
それに加え、ペアでの作業は常に情報を共有しながら作業をするため、意思決定に迷った時2人ですぐに相談し意思決定を行うことができます。また、詳しくないシステムの調査を1人でやるのと2人でやるのでは精神的な負荷が大きく異なります。そのため、メンバーが安心して作業を進める方法として、ペアでの作業はとても有効な方法だと感じています。
そのため、私たちのチームでは基本的にペアで作業を行うようにしています！
タスクの見える化と言語化
メンバーが増えること、ミーティングや休暇時の不在のことを考えるとタスクの見える化と言語化は重要です。
見える化は、チームが抱えているタスクの共有につながります。また、言語化はタスクのゴールの認識を合わせることやタスクの整理、タスクが終わった際の状態が明らかになることにつながります。
上記のことを行うことにより、メンバーが手すきになる・誰が何をやっているかわからないという状態が生まれなくなりました！（私たちは Trelloを使いました）
SREG・開発メンバーと一緒に勉強会
SREG主催で行っていた勉強会(入門 Kubernetesを読む会)に混ぜてもらいました（カレンダーの予定をみて、面白そうなので混ぜてくださいと交渉したら歓迎してくれました！）
クラウド移行を始めたばかりのころは、SREGメンバーとアプリ開発メンバーにおいてKubernetesに関する知識の差が大きくありました！そのため「Kubernetes関連で困ったらすぐにSREGメンバーに相談」ということが多発していました。。。
しかし、勉強会に参加させてもらい知識レベルをSREGと近づけることで相談回数が減り、コミュニケーションコストが減りました。また、新しい開発メンバーがチームにjoinする際も、開発メンバー間で知見を共有することできるようになり、SREGとのコミュニケーションコストを減らすことができました！
やればよかったこと😢
1人1人のメンバーとのコミュニケーション時間の確保
途中からチームのリーダーポジションにつかせてもらいました。その結果、ミーティングが多くなり実作業を行うチームメンバーとのコミュニケーションをとることが減ってしまい、困っていることや悩みに気づくことが遅くなってしまいました。。。
そのため、メンバーとは1日1回は必ずコミュニケーションを取り、不安なことや困っていることが話しやすい環境を作っていき、課題を解消できるようにしていきましょう！
メンバー・リーダーの期待値のすり合わせ
タスクを「どこまで」やればいいのかはゴールの認識合わせのときにやっていますが、「だれに」「なにを」「どこまで」してほしいのかの期待値のすり合わせはやっていませんでした。
これをやるとやらないとでは、チームのメンバーの動き方が大きく変わってくると感じています。
何を期待されているかが明確になっている場合、その人はその期待に応えるために「自ら」考えて動こうとしてくれます。
そのため、期待値のすり合わせは自発的な行動を促すためのきっかけとなると私は考えており、もっとやるべきだったと感じています。
資料の更新
クラウド移行をすることで、システムの構成図はどんどん更新されていきます。
また、クラウド移行初期の頃に比べて作業手順にも変更が加わることが多くありましたが、忙しさにかまけて資料の更新を怠ってしまいました。
そうすると、あとからjoinしたメンバーが読む資料に誤情報が残っていたり、正しいのか正しくないのか資料の信頼性が低くなってしまいます。信頼性が落ちると、誰も資料を読まない状況が生まれる要因になってしまうので資料の更新はちゃんとやりましょう。。。
まとめ
今回はクラウド移行を一年間行い、チームで作業をする際にやってよかったことをメインに話させてもらいました！
クラウド移行にかかわらず、今後の仕事においてこれらのことは必ず活きることだと思うため、引き続き続けて行こうと思っています。
最後に、今回お話しした内容が少しでも多くの人の役に立つことを祈っています👍
閲覧ありがとうございました！