初めて学生インターンを受け入れて感じたこと 2019夏

はじめに

先月、初めて学生インターンを受け入れた。会社としては随分前から受け入れていたのだけど、うちのチームでは初めてだった。今年は縁に恵まれて受け入れることになったのだけど、自身にとって初めてだったということもあり、気づきや反省をここに残しておこうと思う。

背景

うちのチームの特徴は以下の通り。

• 会社はいわゆるWeb系の会社
• 筆者のチームはインフラサービスのためのソフトウェア開発をしている
• 筆者のチームは福岡が拠点だが、東京のチームと協働してサービス開発をしている
• 技術スタックはソフトウェアにPythonを、サービスのインフラにはKubernetesを使っている
• 日本人は筆者だけで他のメンバーは外国籍で、コミュニケーションには英語を使っている

インターン生にしてもらったこと

簡単に言うと、Chaos engineeringをしてもらった。Chaos engineeringについては以下のQiitaの記事がエントリーポイントとして良さそう。

• カオスエンジニアリングと聞いてカオスになった人必見

早い話が「システムに対して、有り得そうな障害を意図的に起こして問題をあぶり出し対策を考える」手法と言える。細かいというか、正確に言うと、多少違うのだけど、実際的な視点で言えば、それほど的外れではないだろう。

で、なぜインターン生にChaos engineeringをしてもらったかというと、以下の考えに基づいている。

1. Chaos engieering（に限った話ではないけど）ではいわゆる"PDCA"サイクルを回しやすく、成果や進捗が把握しやすい
2. チームとしてChaos engieeringに興味を持っていたが、誰も手を付けることができていなかった
3. これまでに障害対策のための実装を行ってきたが、それらが本当に機能しているかどうかを確信できていなかった

なお、今回はテスト環境での実施となったので、本格的なChaos engineeringとは違うが、利用したソフトウェアや手法は一般的なChaos engineeringと同じものを採用した。

狙い

まず#1 Chaos engieering（に限った話ではないけど）ではいわゆる"PDCA"サイクルを回しやすく、成果や進捗が把握しやすい について。Chaos engieeringを行うにあたって、対象システムをある程度把握してもらってから、どこが問題になりそうかという仮説を立てて、どのように障害を起こすかということまでを最初に考えてもらった。これはChaos engieeringを行うにあたっては非常に重要だ。というのも、Chaos engieeringは意図的にシステムを不調にさせるため、何を行うかをチームでレビューして事前に作業内容を周知する必要がある。その後、作業をしてもらって、またレポートを書いてもらい、結果をチームでレビューした。これにより、自然とPDCAサイクルが出来上がってインターン生の状況が把握しやすくなった。また、副次的な効果として、技術文書の書き方の勉強をしたり、チームメンバーとの関わりを自然に増やすことが出来たと思う。

２つ目 チームとしてChaos engieeringに興味を持っていたが、誰も手を付けることができていなかった は割と重要だと思っていて、チームの誰もChaos engineeringを経験していないのでインターン生がチームでの第一人者となる。よって、周りからマサカリが飛んでくる危険を可能な限り減らして、失敗を恐れずに取り組むための環境を用意できたと思う（希望的な推測）。たとえ失敗したとしても、未経験のチームメンバーにとって全ての結果が貴重な知見となる点も重要だ。

３つ目これまでに障害対策のための実装を行ってきたが、それらが本当に機能しているかどうかを確信できていなかったはインターン生のためというか、プロダクトのためなんだけど、これまでに障害で発生した問題を解決するために色々な修正や機能開発を行ってきた。しかし、同じ問題には対応できているが、同じ"ような"問題に対応できているかどうか、ということまでは確認できていなかった。類似の状況でも、特にエッジケースで、問題なく動作するかという確信が持てるかどうかはインフラレイヤーのアプリケーションでは非常に重要で、Chaos engineeringが良い機会になるだろうと思っていた。

これらの狙いは（筆者の視点では）概ね成功したと思う。結果的に、大きな問題は顕在しなかったが、それはチームメンバーに自信を、プロダクトには信頼をもたらすことになった。

その他に気を使ったこと

• 週単位で取り組みや成果物を決めて共有した
  • 途中で何をして良いのかわからなくのを防ぐため
• 途中経過や成果を発表する機会を設けた
  • 成果物を発表する機会を設けることで、成果物の品質にも気を使ってもらうようにした
• チームメンバー以外の社員と交流する機会を設けるようにした
  • 会社の雰囲気を知ってもらうために、チームメンバー以外とコミュニケーションをしてもらった

反省点

• 筆者がメンター役だったが、インターンの後半では放置気味になってしまった。
  • 筆者が色々あって多忙になってしまったが、もっと気を使うべきだった。
  • 筆者が成果物の完成度を上げるために出来ることは色々あったが、あまり貢献することが出来なかった
• もっと早くチームメンバーとのコミュニケーションの機会を持てるようにするべきだった。
  • 筆者以外のチームメンバーが英語話者であったため、意図的に筆者とのコミュニケーションを多めにしていたが、いくつかの事柄に対して筆者が上手く回答できず、チームメンバーに頼ることがあった。
  • これが結果としてインターン生の進捗を妨げる要因の１つになっていた。
  • インターン生のコミュニケーション能力を信じて早くからチームメンバーと直接コミュニケーションできるようにするべきだった。
• 筆者も含めてChaos engieeringは（知ってはいたが）未経験だったために適切なフォローができなかった
  • 今にして思えば、手当り次第にやってみるのではなく、ある程度こちらで想定される問題や事象を整理するなどして、道筋をつけてからやってもらえば良かった

次回に活かせそうなこと

• メンター役は業務上のメンター役と業務外のこと（社内の制度や社内でのコミュニケーションなど）を担当するメンター役などを分けたほうが良いかもしれない
  • メンターが１人だと業務の遂行に目が行きがちで、慣れない社内での過ごし方や社内手続きなどに関して疎かになりがち
  • メンター役の負荷を分散するため
• 任せる業務はある程度メンター役の社員が精通しているもののほうが良い
  • インターン生が詰まったときに的確にアドバイス出来るようにするため。
  • とはいえ、Backlogとかをさせてもつまらないので業務の選定は熟慮しなければならない
• R&D的な業務にしたのは良かった。もし次回があるなら、お題を与えてProof Of Concept的なものをやってもらっても良いかもしれない。
  • インターン生には挑戦的な業務をしてもらうのが良いと思う。インターンが会社のPRの一環だと捉えると、挑戦的な業務を行えるということは会社の良い面をアピールすることにもなるからだ。
  • たとえ失敗したとしても、チームはその失敗から得た教訓を活かすことができるし、インターン生は趣味の範囲では経験できないような失敗をするという経験を得ることができる。
  • 余談だけど、許容される範囲で失敗をするというのは学習においてとても重要だ。なぜなら、成功した理由というものは説明が難しいことが多く、かならずしもパターン化できない。しかし、失敗した理由を説明することは（簡単ではないが）可能であり、理由がわかればパターン化できるからだ。よって、失敗したほうが成長機会に結びつけやすい。

まとめ

インターンを受け入れたことで、より多くの学びを得ることができた。また、これまで手つかずだったChaos engineeringを導入するきっかけにもなったし、インターン生だけでなくチームにとっても実りのあるものに出来たと思う。とはいえ、まだまだ反省点は多いので、次回はちゃんと態勢を整えて、より良いインターンを提供できるようにしなければならない。

おしまい。