Search

LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

Blog


仕事をよりクリエイティブにするための「Learning Session」ノススメ

Hiroyuki Ito2019-07-30

LINE株式会社のSET（Software Engineer in Test）です。「SETタスクフォース」（以下「SETチーム」と表記）のリーダーとして、主にLINEプラットフォームのサーバーサイドで、テスト自動化を活用したプロダクト開発ライフサイクルの改善を立案・実施・主導しています。また、アジャイルコーチも兼務しています。

はじめに

こんにちは。LINE株式会社のSET（Software Engineer in Test）の伊藤 宏幸（Hiroyuki Ito）です。

皆さんのチームでは、タスクの引き継ぎに際して、どのような準備をされていますか？

また、onboarding（新しいメンバーをチームに慣れさせ、成果を出せるよう導くこと）で、どのような工夫をされていますか？

さらに、チーム・メンバーの成長のために、どのような仕組みを取り入れていますか？

私たちSETチームでは、「Learning Session」という仕組みを導入し、上記の課題に対して一定の成果を出し始めています。この記事では、私たちのチームで実施しているLearning Sessionについてレポートいたします。

Learning Sessionとは

Learning Sessionは、日本でも人気急騰中の「モブプログラミング」の創設者の一人、Chris Lucianさんから教えていただいた、チームでの勉強会のやり方です。

Agile2018にてChrisさんと

Chrisさんの会社では、以下のように勉強会を実施しています。

  • 1週間あたりトータルで7時間、業務時間内に行う
  • テーマは、仕事に必要な内容であれば何でもOK
    • 例
      • TDDの練習
      • ツールの選定・検証など、新しいアイデアの実験
      • 開発した機能のデモ
  • 基本、モブプログラミングの要領で教え合う

Chrisさんたちは、この方法で様々な実験を行い、実際に実務の改善に活かしています。

また、onboardingでもこの仕組みを活用しています。

なぜLearning Sessionなのか

私たちのチームでLearning Sessionを採用したのは、私が個人的にChrisさんからアイデアを教えてもらっていたこともありますが、特に次の3つの課題を解決したいと考えたためです。

1. 業務とツールの属人化

これまでは、SETチームのメンバーひとりひとりが、各プロダクト開発チームに加わって活動するというスタイルを取っていました。しかし、SETチームの活動範囲が、テスト自動化だけではなくプロセス改善などに徐々に広がり始め、これまでのように個々のメンバーだけで各チームの課題を解決することが難しくなり始めていました。

加えて、SETチームでは、各メンバーが日々新しいツールを発掘・開発しています。しかし、チーム内での情報共有が不十分で、担当外のチームで適用する価値がありそうであってもすぐに試せないという問題も顕在化しつつありました。

2. 新メンバーの急増

特に今年6月頃から、新卒・中途採用新人の配属、および他チームからの転属が相次ぎ、本稿執筆時点でチームメンバーの半数が新メンバーとなっています。したがって現在、チームとしてonboardingの比重を高めざるを得ない状況にあります。

一方でChrisさんから、Learning Sessionでonboardingを効率化した事例を教えてもらっていたことから、これは自分たちでも試してみるチャンスなのではないか？という思いを強くしていました。

3. 業務時間中に勉強したい！

ある日、中途採用で入社した後輩たちから、「仕事で必要な勉強や準備を、業務時間中にやっても良いものでしょうか？」という質問を受けました。LINEでは、業務に役立つものであれば業務時間中の勉強を特に禁止してはいません。しかし、世の中には将来的に業務に役立つものであっても、現在抱えている仕事に直結しないものに関しては業務時間中の勉強を禁止している会社もあるようで、前職での不安からこのような質問をしてくる人が増えてきました。

「プロであれば、業務時間中に勉強することこそ当たり前ではないのか？」

チームのマネジメントをしている立場として、このような疑問を抱きました。

例えば、野球やサッカーなどのプロスポーツでは、勝つために日々「仕事として」練習をしています。また、Scrum Allianceの創設者の一人のMike Cohnさんは、プロダクトバックログ（≒仕事）の種類として、Features・Defects・Technical workに加えて、Knowledge acquisitionを挙げています。

「プロとして、業務時間中の勉強をルール化しよう。そして、それを私たちの「新しい当たり前」としよう。」

そのような思いから、Learning Sessionを試してみることにしました。

始める際に気をつけたこと

これまで5年以上、アジャイルコーチとして様々な方法論・ツール・改善策の実験を繰り返してきた経験から、Learning Sessionである程度の成果は出せるだろうという自信はありました。また、私の同僚・上司・役員が「良いものはどんどん取り入れよう」というスタイルであることから、試さないマイナスよりも試すプラスの方がはるかに大きいとも判断しました。

一方で、上司に事前に実施許可と工数確保の申請をすることは避けました。まだ形の見えないものの説明をして上司を混乱させることよりも、「ステルス」※（こっそり試して、成果を出してから見せる手法）で「見える成果」に直接触れてもらう方が話が早いと判断したからです。新しい取り組みは、短期間で成果を出し、それを見せて喜んでもらい、自然と賛同してもらう方法がスムーズであることが多いです。

※以前書いたブログ『テスト自動化の理論と技術と戦略：LINE Developer Meetup Tokyo #39 – Testing & Engineering』をご覧ください。

私たちのチームでやっていること

実際の様子。Karate（後述）でAPIの自動テストを書いています。

チームが東京と福岡とに分かれていること、またメンバーごとに関わるプロダクト開発チームが異なることから、Chrisさんから教えていただいたやり方に、いくつかのアレンジを加えています。

実施概要

次の2つのパターンで実施しています。

参加メンバー 人数 実施頻度・時間 形式
東京のみ 4名 基本毎日、30分 - 1時間 自席または社内のフリースペースで実施共用の大きなモニターとホワイトボードを活用
東京&福岡 6-7名 毎週月曜日、30分週次のチーム定例ミーティングとセットで実施 ビデオ会議で実施ホワイトボードは使わず、ビデオ会議システムで扱える範囲で

扱ったトピック

仕事に役立つものとして、幅広いトピックを扱っています。

  • 各メンバーの業務・ツール
    • ツールの紹介・デモ
      • 例：APIテストフレームワークのKarate、自作のパフォーマンステストツール群
        ※Karateについては、後日ブログで紹介させていただく予定です
    • ツールの設定・操作の練習（実際に動かす）
    • ツールに関する問合せ対応とツールの改修（実際に問題を解決する）
    • （技術に限らない）業務上の課題の共有と解決
    • 開発・修正中の機能のデモとレビュー
  • Onboarding
    • 社内ツールの設定・使用方法
    • Pull Requestの作成方法
    • コードレビュー
  • 業務に役立つこと
    • IntelliJのショートカットキーの紹介と練習
    • JIRA/Confluenceのショートカットキー・Tipsの紹介と練習
    • テストスクリプトのリファクタリング（含むテスト設計のティーチング）
  • プロセス改善の実験

ポイント

  • メイン発表者は誰でもOK
  • 極力lightweightに行う
    • 説明資料は、必要ならば作るという程度
  • 極力「実物」（実業務・ツール）に触れるようにする
  • 無理はせず、できる範囲で試す
    • 忙しい時期に、無理して時間を割くようなことはしない
    • テーマが見つからない日はスキップする
    • 実施することを目的とするのではなく、あくまで仕事に役立つ知識・スキルを無理なく得ることを目的とする
  • 批判は避け、良い点を褒めることを心がける（続けるモチベーションにつながる）
  • 楽しむ！

成果

当初の課題認識をある程度解決できたことに加え、メンバーの心理面や評価面でのメリットも見つけることができました。

当初の課題認識

  • 引き継ぎの前倒し
    • これまで特定メンバーしかできなかった業務を、他のメンバーが代行・実施できるようになってきた
    • 結果、特定メンバーが病気などで一時不在になっても、他メンバーがすぐにカバーできるようにもなった
  • ツールやソリューションの利用を、他チームにも広げやすくなった／広げられた
  • Onboardingのスムーズ化
    • チームに合流して2-3日以内には、Pull Requestの作成・マージ・リリースまでは出来るルーティンを構築できた
    • 作ったものは利用者にデモする・リリースして初めてタスクを終了とみなすなどの、チームの文化への順応が迅速になった
  • 新しいこと（プロセス・ツール）を試すことが、チームとして「当たり前」になってきた

心理的側面

  • 作業に詰まっても、気軽に質問・相談し合えるようになった
  • お互いのプログラムや資料を気軽に見られる／見せ合えるため、フィードバックや新規のアイデアの取り込み・反映が容易になった
  • ミスとリカバリの練習を、チーム内で気軽にできるようになった
    • 結果、「本番」へのプレッシャーを、事前かつ「安全に」軽減できるようになった

評価の側面

人事評価にまつわる庶務（情報整理・面談・フィードバックなど）を、マネージャー・メンバーともに大幅に簡略化・軽減できました。

  • マネージャー（評価者）として、毎日メンバーの具体的な活動・成果に触れられるため、メンバーの評価が容易かつ的確になった
  • メンバー（被評価者）として、毎日活動・成果を見せられるため、マネージャーへのアピールが容易になった
  • 日々の業務でお互いにフィードバックを与え合っているため、1 on 1などを別途設定しなくても、チームの目的・ゴールへのアジャストを迅速に行えるようになった

今後実施・改善したいこと

今後はSETチーム内だけではなく、一緒に働いている各プロダクト開発チームでも実験していきたいと考えています。また、スキルやマネジメントに課題を感じているチームがあれば、Learning Sessionを活用した改善支援を実施して課題解決を支援できるのではないかと思っています。

一方で今後、以下の改善が必要とも考えています。

  • メンバーがさらに増えた際の運営方法の整理
  • 他チームで実施するための方法論・ガイドラインの整理・共有
  • ファシリテートできる人の育成
  • ソフトウェア開発以外の分野での実験

最後に

Learning Sessionを導入してから、業務時間中の勉強が「当たり前」となり、業務やonboardingで少しずつ改善がみられるようになりました。また、心理面や評価面でのプラスもみられました。

一連のアクションは、小さく試せることをひとつひとつ実施し、うまくいったものだけを、無理のない範囲で継続しています。言い方を変えると、チームをより成長させるための、そして仕事をよりクリエイティブにするための実験を、日々繰り返していると言えます。

ちなみに、書籍『ACCELERATE: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations』によると、チームのパフォーマンスを向上させる手段として、「Team Experimentation」は有効なのだそうです。

皆さんも、チームをより良くするための実験、してみませんか？