シェア
はてブ
2020年8月26日（水）、Findyが主催するエンジニア向けイベント「アジャイル開発最前線〜メルカリ、LINE、クオカードのエンジニア組織を徹底解剖！〜」がオンライン上にて開催されました。
新型コロナウイルスの影響により、私たちの働き方は大きく変化しました。こうした状況の中で、より良い製品を作り出すためには、単に働き方を変えるだけでなく、多様な働き方に適した組織体制やコミュニケーション、さらにはツール選定など、エンジニア組織や開発手法自体も、時代に合わせて考える必要があります。
今回は、長きに渡ってアジャイル開発を進めてきたゲストの方々をお呼びし、アジャイル開発のこれまでと直近の変化、今後のあり方について語っていただきました。その内容を、前編のパネルディスカッションパートと、後編のQ＆Aパートに分けてお届けします。
■登壇者プロフィール
鎌田 正浩／LINE株式会社 [@iratamak]
メーカーでの組み込みソフトウェアエンジニアとしてキャリアをスタートさせた後、 自社SNS、ゲームプラットフォーム、動画配信サービス、VR技術研究など複数領域でエンジニアとして働く。スタートアップでのEngineering Manager や、FOVE株式会社でのVPoEとしての経験をもとに、現在 LINEでアジャイルコーチとして、組織横断的に開発チームやEngineering Managerのコーチ業に従事。
齋藤 健一／株式会社クオカード [@saito400]
株式会社クオカード デジタルイノベーションラボ プロダクトグループリーダー。
フリーランス、SIerを経てベンチャー企業数社でCTOを歴任。 現在はQUOカードPay開発のプロダクトオーナー。CSM/CSPO。
白石 久彦／株式会社メルカリ [@hisahiko]
大学卒業後、さまざまな業務システム、インターネットサービスの開発プロジェクトにエンジニアとして携わる。ソフトバンクグループ、株式会社レコチョクなどにおいて、大規模新規サービスの立ち上げや技術組織の立ち上げを担当し、2014年ドリコムの技術担当役員に就任。技術組織の強化に取り組む。2018年より株式会社メルカリに参画、技術組織強化担当Directorに就任。他社の技術顧問も務めている。
■モデレーター
田頭 一真／ファインディ株式会社 [@taityo0911]
株式会社ドリコムでIP系ゲームアプリの開発ディレクターを経験後、2018年6月にジョイン。Findyでは、Freelance事業と転職事業のユーザーサクセスの立ち上げ〜グロースに携わる。
スピーカーのご紹介
ーー今回、モデレーターを務めるFindyの田頭と申します。本日はどうぞよろしくお願いします。それでは、まずLINEでアジャイルコーチを務められている鎌田さんから、簡単に自己紹介をお願いします。
鎌田：
LINEの鎌田と言います。僕は今、アジャイルコーチという仕事をしているんですけど、僕自身もこの会社で応募するまでこの職種の名前を知らなくて。どういうことをやっているか紹介したいと思います。
アジャイルという名前がついてはいるんですが、必ずしもアジャイルに関することだけではなく、社内のいろいろな開発に限らないチームの支援を主に担当しています。支援内容はチームによってさまざまで、もちろんアジャイルやスクラムを導入する支援もありますし、マネージャーの方の相談に乗りつつ、課題へのアプローチを一緒に考えて実行していくようなこともやっています。
それ以外には、社内の研修やワークショップを設計して実施するといった仕事もやっています。今日はよろしくお願いします。
ーー鎌田さんはLINEに入社される前から、組み込みエンジニアやスタートアップのVPoEとして、さまざまな規模の開発組織を見られてきた方です。各チームにあった開発仕様をどう見定めていくのか、などを中心に質問させていただければと思います。続いて、齋藤さんの自己紹介をお願いします。
齋藤：
クオカードという会社で、現在エンジニアリングマネージャーとプロダクトオーナーをやっています。齋藤と申します。今日はよろしくお願いします。
ーー齋藤さんはクオカードの1人目のエンジニアとして、DXの推進をされてきたり、エンジニア組織を立ち上げて、アジャイル開発を浸透させたり、といった取り組みをされてきた方です。立ち上げ期の開発組織をどう運営していくのか、など質問していければと思います。それでは、最後に白石さんの自己紹介をお願いします。
白石：
メルカリの白石と申します。日本向けのサービスを作っているメルカリJPで、エンジニア組織の強化を担当する部署のディレクターをやっています。今日はよろしくお願いします。
ーー白石さんは、私の前職でもあるドリコムという会社で、当時技術領域の役員をされていて、そこでも非常にお世話になりました。白石さんはメルカリに入られて、採用のオンボーディングであったり、QAの自動化であったりと、フローの最適化に取り組まれてきた方です。工程全体から見たときに、開発をどう軌道に乗せて行くのかといったマクロなテーマを含めて、質問させていただければと思います。本日はどうぞよろしくお願いします。
齋藤・白石・鎌田： よろしくお願いします。
コロナの影響で生じた課題と、それに対するアプローチ方法は？
ーーパネルディスカッション1つ目のテーマは、「新型コロナの影響に関して」です。コロナのbefore/afterで大きく変化を感じた課題や、その課題に対して皆さんがどのようにアプローチしたのか、について伺っていければと思います。まずは白石さん、いかがでしょうか？
白石：
メルカリでは、結構早めにリモートワークを導入していたんです。なので、そこに関しては、割とスムーズにシフトしていった感じでしたね。
ただ、そこにあまり影響がなかったという判断をしがちになってるところが、逆に今ちょっと危ういかなと感じていて。決められたことを実行に持っていくところ、つまり効率的な面はそんなに落ちていないんですけど、最近僕が気にしているのは、実現性。新しいものを実行に持って行くところに、影響が出ていないかというのを意識して見ています。
それから、メルカリは一昨年くらいから、海外からエンジニアメンバーを迎えるグローバル化を大きなテーマとして進めていました。すでにオファーを出して来ていただくことが決まっている方がいるのに、コロナの影響で来日できていないという課題はありますね。
あとは、グローバルの文脈に近い部分もありますが、リモートになって物理的なロケーションが離れているので、ちゃんと「なぜこれを作るんだっけ」というコンテキストの理解を深めてモノを作っていこう、という話を最近しています。
ーー続いて、鎌田さんにお聞きしたいと思います。アジャイルコーチとして複数のチームを見られている中で、チームによってコロナによる影響度合いの差はありましたか？
鎌田：
そうですね。やっぱりLINEは大きな会社なので、組織ごとにカルチャーも含めて結構違いがあります。リモートワークをしたことがある人の割合もそれぞれで、それこそチーム内で誰もやったことがないようなチームもあって。
リモートワークの経験値もありますが、どちらかと言うと普段からチームでコミュニケーションが取れているか、仕事を見える化しているかといったところが、リモートワークに順応しやすかったかどうかの要素になっていたと思います。
ーーコミュニケーションが上手く取れていないチームがあった場合、どういった形で入られることが多いですか？
鎌田：
コミュニケーションが上手くいっていないチームは、コミュニケーションに限らずなんですが、新しいやり方を試すことへの抵抗がある場合が多いと思います。なので、まずは小さくやってみる。
何か新しいことを始めるにあたって、向こう1年遵守するルールを作るぞというものではなく、例えば1週間だけやってみて、ダメなら元に戻しましょうと。そういうことを試すところから入っていくケースが多いです。
ーー齋藤さんにもお聞きしたいと思います。クオカードさんはコロナ前からリモートワークを導入されていたそうですが、影響はいかがでしたか？
齋藤：
もともとリモートワークを取り入れていたので、すごく大きな影響というのはなかったです。ただ、スクラムイベントだけは極力対面でするようにしていたので、振り返りなどはオンラインでできるように対応していきました。
そういった細かな調整は多少あったんですが、一番大きかったのは雑談の機会がかなり減ったことですね。雑談Zoomみたいなのも作ったんですけど、決まった人が入る感じになってしまったりして。
最近基本的にモブプロかペアプロで進めるようにしているんですが、今度はそこから人が出てこなくなって、雑談Zoomがどんどん過疎になったり（笑）。この間はモブプロに勝手に入っていって雑談を始めるっていうのをやってみたんですけど、結構迷惑そうな感じになったので、やめた方がいいと学びました（笑）。
組織フェイズ別に開発チームで工夫したことは？
ーー次のテーマは、不確実性に対するアジャイルな開発、エンジニア組織に関してです。まずは「組織フェイズ別に、チーム開発で工夫されてきた点は？」というトピックスについて、お伺いしたいと思います。齋藤さんはエンジニア組織を立ち上げて、アジャイル開発を浸透させていくために、どのような工夫をされていましたか？
齋藤：
失敗したものもかなりあるんですけど、結論として特に気をつけるべきだと思っているのは採用です。弊社がどういう進め方をしたいのか、どういった価値観を大事にしているのか、という情報をちゃんと出して、面接でもお伝えするようにしています。できるだけカルチャーアンマッチを避けるためですね。
あと、スクラムの場合クロスファンクショナルにすべきだと思うんですけど、最初はそうも言っていられないところもあって。なるべく徐々にクロスファンクショナルに、1人がいろんなところに触れるチームを作っていくように今進めています。
ーー続いて、鎌田さんはメガベンチャーやスタートアップなど幅広く見られている中で、変化に適応しやすいように組織フェイズ別に変えてきた工夫はありますか？
鎌田：
一概に「このサイズの組織ではこのやり方」というものはないんですけど、やっぱり最初のステップとしてオススメするのは、振り返りです。リモートワークだと特に、チームメンバーがどんな環境で働いているかって、結構わかりづらいと思うんですよね。
例えば、会社で隣の席に座っていた人の家の間取りとかって、あまり知らないと思うんですけど（笑）、子どもがいて、子どもと同じ部屋で仕事しなきゃいけないとか。そういうリモートワークにおける自分の課題を、チームに展開したことがない場合もあったりするんです。
振り返りの場を作ってオープンに話して、上手くいっていないことがあれば、そこで取り上げて改善していく。そういう場があると、組織の大きさに限らず変化に適応していく上で効果的なのかなと感じています。
ーー続いて、白石さんも組織フェイズ別に工夫されてきたことがあれば教えてください。
白石：
メルカリは今、クロスファンクショナルチームへシフトしていこうとしています。2年前くらいに僕がジョインした頃、立ち上げから上場まで持って行くところのチームは、クロスファンクショナルだったんですよね。
その後、人数が増えてマネージャーを立てていく段階で、エンジニアマネージャーの制度を導入し、バックエンドやフロンドエンド、モバイルなどのファンクショナルな組織を立ち上げていきました。これはどこの会社でもそうだと思うんですけど、ファンクショナルとクロスファンクショナルを行ったり来たりしながら、細胞分裂して大きくなっていくようなイメージですね。
ファンクショナルな組織にして、その中でリーダーを増やしていき、例えばバックエンドのマネージャーが複数名出てきたら、その人たちとモバイルのマネージャーの人たちを組み合わせてクロスファンクショナルな小さい組織を作って、というような細胞分裂の仕方です。Spotifyさんなどがやっているモデルに近いかもしれません。
スピーディーかつ柔軟なアジャイル開発の手法をどのように検証していくのか？
ーー続いてのトピックスは、「組織フェイズ別にマッチした開発手法を、どのように検証するか？」についてです。エンジニアメンバーの入れ替わりがあり、組織規模や雰囲気が変わっていく中でマッチした開発に柔軟に変更していくことが重要かと思います。 鎌田さんは、アジャイルコーチとして新しいチームに入る際に、この辺りはどのような流れで行われていますか？
鎌田：
最初はマネージャーの方とお話しします。その後、メンバーの方にもお話を聞いたりするんですけど、マネージャーの方とメンバーの方で、認識している課題や優先順位が違うことがあって。そういう場合は、振り返りやワークショップで認識を合わせるところから始めます。
同じサイズのチームでも、作っているプロダクトやプロダクトのフェイズによって優先順位も変わってくると思うので、そこで例えばワークショップばかりやっていても、ビジネスに対してプラスの効果は作れません。チームで新規の開発や、組織の課題などを議論の俎上に並べて、どの順番でやるべきかを話したりします。
明確に、1番、2番……と1つの物差しで決められるものではないので、難しいところではあるんですが、ひとまずやってみて数字を記録して、それを次に生かすというパターンもあります。
普段の仕事に対して、何がしかの数字を取得することができます。何かを変えると、その数字が変化すると思います。そういう数字をKPIにすると、数字をハックする気持ちが出てきたりとか、またそれが評価に繋がってしまうと難しくなってしまうんですけど、単純にメトリクスとして数字で取れるものを残してみて、その変化を材料にすることもあります。
ーー差し支えなければ、例えばどんなところを数値化しているのか教えていただけますか？
鎌田：
開発でいうと、例えばバグの数ですね。バグの重要度はmajorとかminorなどいろいろだと思いますけど、重要度別の数字がどう変わっていくかとか。あとは、プルリクエストの件数とかマージするまでの平均の時間など。
明確な差分が出ることも出ないこともありますけど、チームにとって良い数字が何かというのは残していくと比較ができるので、そういう数字を取ってみるという感じです。繰り返しになりますが、KPIとして数を増やすとか減らすではなく、変化を見るために使います。
ーー齋藤さんは複数のスタートアップを見られてきた中で、例えば10人から30人になるような規模の変化もあったと思うのですが、いかがでしょうか？
齋藤：
組織フェイズというよりは、クネビンフレームワークというセンスメイキングフレームワークがあって、対応する問題の質によって進め方を変えたりしています。問題がそれほど複雑でないものに関しては、ウォーターフォールでやってみたりはしています。一応、スクラムでやる時はベロシティも取ってはいるんですが、ウォーターフォールだと尺度がそもそも変わってしまうので。
そういう意味では、鎌田さんと同じ部分もあるんですけど、振り返りや1on1で状況を見たりしています。あと、日頃オープンコミュニケーションにしているので、やりにくそうだとやっぱりチャットに現れてくるんですよね。そういうのをフィードバックとして受けて、やり方を変えてみたりしています。
ーー白石さんはスタートアップの技術顧問も務めていらっしゃる中で、例えばこういう組織にはこんなアドバイスをしているなど、あれば教えてください。
白石：
組織のフェイズもありますし、何を作っているかにもよると思うんです。あとは、その会社のトップの方の考え方もですね。例えば、広告系のツールを作っている会社だと、おそらくB to Bが多くなってくるので、案件によってはどうしてもウォーターフォール的な開発が求められて、エンジニアがちょっと疲れやすい傾向があるような気がします。
広告って数字を上げていかなくてはならない仕事なので、営業とすごく近いところにエンジニアが置かれていて。そういう会社さんのアドバイザリーをする時は、ビジネスのカルチャーであったりとか、先ほどコンテキストの話がありましたけど、「なぜそれが重要なのか」を伝えた方が良いですね、とお話したりしています。これはゲーム系の会社も近いかもしれないですね。
エンジニアの育成において工夫する点は？
ーー最後のトピックスは、「エンジニアを育成する上で工夫されている点は？」です。 今後もサービス開発のスピードや質を高めていく上で、個人の活躍を最大化するための採用・アサインや長期的に関わってもらうための育成は重要かと思います。 白石さんは、もともと採用からオンボーディングの領域を担当されてきたと思いますが、育成に関してどのようなことを心掛けていますか？
白石：
まさにメルカリでは、採用後にチームでオンボーディングをしてもらって、入社してくださった方が活躍できる状態をいかに作っていくか、というところに取り組んでいます。
採用は本当に合う人を採っていくところに尽きるんですけど、今のフェイズのメルカリに入って何ができるのかというような期待値のすり合わせは、入り口のところでするようにしていますね。そこがズレてしまうと、どうしても不幸になりがちなので。
育成とオンボーディングを分けて話をすると、育成については新卒採用をやっているので、研修プログラムを作っていて、そこはどんどん充実させていきたいと思っています。一方で、中途の方を含めて、チームに馴染んで活躍してもらうまでの期間をどれだけ短くできるか、ということにも今すごく注力しています。
長く働いていただければいいんですけど、海外の方を採用し始めて、日本人とは勤続年数に対する感覚が違う気がしていて。長く働いていただけるにしても、例えば2～3年で1回ちゃんと成果を出させてあげるにはどうしたらいいんだろう、というのはすごく考えていますね。
ーー続いて、齋藤さんにお聞きしたいと思います。スタートアップの多くはサービス開発の優先度が高く、なかなか育成に時間を割くのが難しいという状況があると思います。クオカードさんでは、育成に関してどのようにされていますか？
齋藤：
私の部署は今経験者しか採用していないので、入社後の研修は部署としては行っていません。基本的にはOJTで、たまに勉強会をやっていたりします。
あと今、クロスファンクショナルなチームにしようとしているんですけど、本人たちのやりたいことをある程度踏まえて進めたいなと。なので、それぞれスキルマップを書いてもらい、今持っているスキルや伸ばしたいスキルを見て、できるだけそれを反映するチームになるようにしていますね。
それから、会社全体ではMBOなんですが、うちの部署では評価制度を特殊なものにさせてもらっていて。ノーレイティングに近い感じで目標を作るのをやめて、なるべく細かい単位でフィードバックしていく形を取っています。
ーー最後に、鎌田さんにお聞きできればと思うのですが、チームコーチングなどを行われていく中で、個人メンバーの育成にあたって工夫されている点はありますか？
鎌田：
私のチームがどこかのチームの個人に対して、集中的に育成するということはあまりないので、チームごとにさまざまです。スクラムを始めたいチームの方に対して、集合研修のような形でお伝えしたり、スクラムの各イベントに参加してフィードバックをしたり、コーチングをしたりといったことをしています。
マネージャーの方々とお話していると、結構エンジニアって有名なエンジニアのことをみんな知っていて、そういう人と自分をいつも比べてしまってずっと自信を持てない人が多いなと。ただよく見てみると、有名なエンジニアの方の専門の分野と自分のその領域の実力を比べていたりします。有名なエンジニアも全知全能ではないので、自分のほうがよく知っていることだってあるんです。エンジニアって自分より年下にすごい人がいたり、逆に自分がそういう存在だったりする職種でもあるので、他の人と比べるのではなく、過去の自分とギャップをどれだけ作れたかにフォーカスすることが大事かなと思っています。
ーーありがとうございました。パネルディスカッションとしては以上になります。この後、参加者の方からいただいた質問をもとに、Q&A（後編）に移ってまいります。
後編はこちらから
