このセッションで伝えたいこと

このセッションでは、説明下手なのにファーストペンギンをしている自分が、３種類の「やってみせる」をうまく活用してフットワークが重い人を巻き込んできた経験を共有することで、説明下手で人をうまく巻き込めない人たちの伝え方が変わる一歩を踏み出せる時間にしたいと考えています。

内容

全世界のみなさま、こんにちはこんばんは、やたです。普段はクリエーションラインという会社で開発者をしています。

これまでの背景

もともと自分はとある大企業の新卒としてはじまり、新卒研修としてRSGTやスクラムフェスで登壇するような人たちから学ぶ実践形式の研修を通じてかっこいいチームへの憧れやアジャイル開発に興味を持つようになりました。それから数年の間、スクラムフェスやRSGTなど現地のイベントなどに参加していたのですが、もっとお客さんやさまざまなロールの開発者と近い距離感で仕事をしたいと思い、今の会社で働いています。

社内の開発者の仲間を増やす活動に取り組んでいます

ただ、今の会社ではアジャイルコーチやスクラムマスターは多数在籍しているものの、開発者としてアジリティ高く仕事ができる人はまだまだ多いわけではなく、チームによっては1週間に1回しか全員で顔を合わせず、お隣さんのエンジニアが何をやっているかまったくわからないなんてチームも存在します。

そのような状況下でいくつかチームを渡りながら開発者の仲間を増やす活動を現在進行形で続けています。具体的には、t_wadaさんを会社に招いて講演（質とスピード）をしてもらったり、自分が新しいプロジェクトに入るたびにユニットテストの導入やモブプロに巻き込んだりして地道に変化を起こす取り組みを続けています。

結果として、必ずしも自分が変えたとは言い切れませんが、自分がチームから過ぎ去った後もユニットテストが増え続けてテストがレガシーコードが減っていたり、デイリースクラムが続いていたりしています。

３種類の「やってみせる」を活用しています

開発者に対しての普及活動を続けていく中で、ちょっと一緒にやってみません？ということでも拒否反応を示す人もいます。自分の経験上、そういう人の特徴は大体以下の２パターンに分類されてきます。

• アジャイル開発や関連するプラクティスに関して全く知らない
• どこかでアジャイル開発とかに苦い経験がある

そういう人たちに対してできることは、良さをちゃんと実感してもらえるように説明したり、苦い経験からくる誤解を解いてあげることだと思います。しかし、自分自身は社外にも名が知られているようなプロフェッショナルでもないので説得力に欠けますし、そもそも自分は言語化や説明が得意ではないので難しいものがありました。

だからこそ、自分の場合は３種類の「やってみせる」をうまく活用しています。

• 自分でやったものをそのままみせる
• デモしながら説明する
• ペアしながら答えをみせる

やってみせる上での大事なポイント

やってみせるの大事なポイントは巻き込む人の原体験を塗り替える・作るつもりで「やってみせる」という点です。

その点を意識するだけでも以下の効果があります。

• 興味を持ってもらう確率は高まって、そこから一緒にやる方向に繋げやすい
• 巻き込んだ人たちは自分がいなくなった後でもちゃんと続く確率が高まる
• たとえその時はうまく巻き込めなくても、その後の違ったファーストペンギンを助ける要因になる

新しいチームにジョインしたときに、チームに対してもっとこういうやり方があるのに！とは思うものの、うまく浸透させられず諦めてしまうことってありませんか？

スクラムやモブプロやTDDなどのプラクティスを「自分が実践できる」と「それらを知らないメンバーに実践してもらえるようにする」は他者を変えるという点で全く違うスキルであり、やったことがない人達にその良さを実感してもらってみんなができるようになっていくのは相当険しい道のりだと思います。

自分の場合は、

隣の人がなにをやっているのかまったくわからない日々、お通夜のような報告会、量産されるレガシーコード

を続けているチームに４ヶ月間ジョインする機会がありました。

しかし、そんなチームをスクラムやTDD、モブプロへと巻き込んでいく中で、

自分がいなくてもそれらのプラクティスが当たり前になるやり方が少し見えてきたような気がしています。

そこで、このセッションでは、そのやり方を直近で携わっていたチームを例に紹介します。

皆さんはこのようなチームに出会ったことがありますか？

• プロダクトコードにユニットテストがほとんどなく、クラスが肥大化している
• 個人が別々に動いていてメンバー間のコミュニケーションがほとんどない
• タスク管理がままならず形骸化したスクラムイベントが続いている

新しくジョインしたチームがこのような状況であるとわかった時に、「できるだけはやく逃げる」という選択肢をとるほうが無難なのだと思います。しかし、自分の場合は、これまで参加したRSGTやスクラムフェスのイベントで見てきたかっこいいチームやカイゼン話への憧れから「ちゃんと逃げ場を用意した上で1ヶ月だけカイゼンを頑張ってみる」という選択肢を取ってみました。

そこから毎日のようにアジャイルコーチと壁打ちをしながら続けていった結果、自分の中でメンバーへの伝え方や巻き込み方が変わっていきました。そうして1ヶ月経って自分自身の成長やチームの未来に少しだけ可能性を感じ、もう1ヶ月経ってバーンアップチャートがよこばいから右肩上がりになり始めたり、タスクの細かく分割して優先順位を考えることが見られるなどカイゼンの成果が少しずつ見えてくるようになりました。

このセッションでは、レガシーコードだらけでコミュニケーションが苦手なチームにジョインした普通の開発者が、スクラムマスターのような振る舞いをしてどう変わっていったかとそこから得た学びを生々しくお話し、聴いてくださった方がチームの改善に向けて一歩を踏み出せるセッションにしたいと考えています。

最近、5年の時を経て増刷された名著「Joy, Inc.」をご存知ですか？
「Joy,Inc」とは、Menlo InnovationsのCEOであるリチャード・シェリダンさんが執筆した本です。職場に喜びをもたらす知恵や経営手法だけでなく、顧客も巻き込んでより良い製品を作り、事業を継続させる手法などについて書かれた素晴らしい本です。

クリエーションライン株式会社は、このJoy, Inc.の考えに共感し、日本のJoy, Inc.を目指し、メンバーがいきいき働ける職場を目指しています！
どんな会社か気になってきたでしょう？

今回のセッションではクリエーションラインを知ってもらうために、実際に中で働いている多様なメンバーと一緒にクリエーションラインやメンバー自身を知ってもらおうと思います！もちろん良いとことだけではなく、裏の部分も包み隠さず赤裸々にお伝えします！

こんなメンバーと働けたらJoyだなぁ！
そう思った方はぜひJoy, Inc.にLet`s Join Inc.！

アジャイルなソフトウェア開発を効果的に進めるためには、「ライトウィング」と「レフトウィング」の両輪が必要になります。

• レフトウィング：協働でゴールに向かう「チーム環境」
• ライトウィング：高速に石橋を叩いて渡る「開発環境」

私達の現場では、レフトウィングについては、アジャイル向きなマインドセットを持ったチームメンバーが多いことと、アジャイルコーチ・スクラムマスターの支援によって、チーム環境の継続的な改善を進めることができています。ですが、ライトウィングについては、バージョン管理や継続的インテグレーションなどは実践していたものの、特に自動ユニットテストが十分に用意されておらず、そのことによってコードの保守性への大きな懸念が存在していました。

本発表では、ユニットテストを根付かせるために、チームメンバーとスクラムマスターがタッグとなって行ってきた以下の2つの取り組みについて紹介します。これらの取り組みを推し進める際にどういうことを考えていたかや、取り組み後の周りからの反応や効果についても触れたいと思います。

• 社内TDD Boot Campの開催
• ユニット環境の整備

MLOpsには、機械学習プロジェクトをより安定稼働させることが求められていると思います。そのためにあらゆるプロジェクトでモデルのデプロイ自動化やバージョン管理などが行われています。

ただ、モデルの品質を保つための必要十分条件はデプロイ自動化のみでしょうか。そもそも、モデルの品質を担保するのは学習データの質と量で、最初から完璧なデータセットを用意するのは不可能であったり、ユーザーの傾向が日々変わる中で常にデータセットをメンテナンスしていく必要があり、デプロイ自動化のみでそれが為されるわけではないはずです。

つまり、本来はサービスの中で予測に用いられたデータをモデルの学習につなげるサイクルを高速に何度も回せる仕組みがあるべきなのに、自分のプロジェクトも含め、多くの機械学習プロジェクトがなんらかの理由によってそこまでたどり着けていないもしくはその優先度が下がっているのではないかと考えられます。

実際、機械学習はそれ単体で成り立つものではなくソフトウェアの一部として組み込まれることで初めてユーザーに価値を届けることができるため、システムの中でそのサイクルを回せる仕組みを作っていくことは可能です。したがって、MLOpsは機械学習モデルをソフトウェアの一部として考え、モデルのデプロイ自動化やバージョン管理だけでなくシステムの中での学習データ作成の半自動化によって、ソフトウェアとして価値を届けることがあるべき姿なのではないかと考えています。

このセッションでは機械学習プロジェクトとMLOpsがこれからどうあるべきなのかを考え、自分たちのチームで取り組んでいる事例に基づいてお話します。

楽天株式会社の矢田です。現在、機械学習エンジニアとして社内の機械学習案件に携わっています。

機械学習プロジェクト×スクラムを実践していく中でぶつかった2つの問題について話したいと思います。

1. 機械学習プロジェクトにおける作成物の透明性とは

スクラムは透明性に依存しており、作成物の状態から様々な決定を行うとされています。

しかし、機械学習プロジェクトにおいては、顧客側の過剰な期待であったり、中身のブラックボックスにより透明性が担保されにくくなることが多くあります。

実際に、自分のプロジェクトで、透明性を向上するために行った知識の共有や説得、そこからの現状にあった方法の選択の提案などについて紹介します。

2. 機械学習プロジェクトで機能横断的なチームを作るためには

スクラムガイドによれば、スクラムチームは自己組織化されており、機能横断的なチームである、とされています。また、開発チームのメンバーに専門能力や専門分野があっても、最終的な責任はチームで持つとされています。

しかし、機械学習プロジェクトにおいてはAIに関して専門性が必要になることが多く、スクラムガイドの意図する機能横断的なチームになりにくい場合もあります。

僕らのチームも現在このような状態にあり、この問題を解決するためにとってきた（これからとる）ものについて紹介したいと思います。