見出し画像

続けることの大切さ。楽天MIPエンジニアが語るアジリティーの極限


イントロ

 こんにちは。楽天株式会社ランキングサービスグループのフロントエンドチームでエンジニアをしているキム・ウヒョクと申します。

弊社にはMIPという賞があります。「Most Impressive Person」の略語なのですが、一ヶ月の間一番目立つ成果を出せたエンジニアに対して授与される賞です。今年の6月に私がその賞を受賞しました。

この度アジャイルジャパンのLTに登壇することになり、私たちがどういう仕組みを持ってアジャイルを実践しているのか、どういうやり方でパフォーマンスを最大化しているのか読者のみなさんに少しお話しさせて頂きたいと思います。

アジャイル

 時代の複雑性が高まり、顧客からの様々なニーズに対し臨機応変に対応策を模索するために登場したアジャイルプロセス。それを持って私たちは、ウォーターフォールをはじめとする従来のプロセスでは得られなかったプロダクトの品質や能率の良い工程に関する究極の答えを求め続けています。

 その中でも理想の形に近づけるために私たちエンジニアはチームの構成を見直したり、スクラムを導入してみたりするなど研究を重ねています。ただし注意すべきなのは、最終的に目指すところがどこなのかを常に念頭に置いていなければならないということです。

どんなに良いソフトウエア・文化作りができても、私たちの持っているその武器が世界に対し、意味のあるソリューションとしてきちんと機能しなかったり、一時の話題にしかなれなかったりすると、そこにかかったリソースは誰から報償されるのでしょうか。

改善の努力を続けること。努力を続けながらも常にアジリティーを求めること。この二つの前提が成立してからこそ世界に対する付加価値を創出すると共に、目標達成をいう言葉が使えるようになるのではないでしょうか。

楽天ランキング、そしてフロントエンドチーム

「楽天ランキングhttps://ranking.rakuten.co.jp 2019.07.16」

 弊社のランキングサービスグループ、その中でも私が所属しているフロントエンドチームも、この理念に基づき、最高のパフォーマンスを発揮できる仕組みに向けて、日々試行錯誤しています。

グループの構成

まずランキングサービスグループですが、4チームに分かれています。

(1) ランキングスコアを計算するプラットホームを作るチーム,

(2) 計算されたスコアをAPIとして管理・提供するチーム、

(3) スコアデータをユーザーに提供するためのフロントエンドチーム

(4) プロダクトそのものやプロジェクトスケジュールを管理するプロダクトチーム                                で構成されています。

開発チームである(1) ~ (3)チーム全てが現在アジャイルを導入しており、そのうち(1)と(2)はスクラムを採択しています。フロントエンドチームの場合カンバン方式でプロジェクトを管理しています。

フロントエンドチームとカンバン

 フロントエンドチームがカンバン方式でプロジェクトを進めているのは、開発そのものだけを進める組織ではない部分があるからです。なぜならサービス提供するウェブアプリケーションを管理しており、通常のオペレーション作業トラブルシューティングまたデザインの変更のようなビジネスリクエストへの対応など突発性の作業も多少含んでいるため、スコープをスプリントバックログという一つの枠に定義しづらいからです。

 その反面カンバン方式としてWIPタスクの数を管理し、案件に対する対応力を最大化すると共に、アジリティーを持ったタスクの処理のために仕組みを改善することに集中する方針でチームを運用しています。

基本的に現在7人制のチームですが、ボードを使って、みんなのWIPタスクを見える化していることから、お互いにどういう作業をしているかが共有できていることを前提としています。

カンバンと共にしたチームのここ1年

パフォーマンス

 アジャイルを導入する目的を考えると、仕組み・文化作りも大事ですが、それに止まらずその前提となる環境を生かしたビジネスとしての価値創出を伴わなければなりません。

フロントエンドチームでは、ここ1年間全力で走り抜いた結果、今月のプロジェクト賞1回ノミネート、今月のエンジニア賞2回ノミネート・1回受賞という目に見える成果を得ることができました。社内からの評価のみならず、サービスを利用していただくユーザーの方々からも「使い勝手が良くなってる」との好評もちょくちょく聞こえてきています。こういった成果も感じられるようになり、私は組織のプロセスについて誇りを持てるようになりました。

この勢いのまま、部内一のチームになると共にユーザーの声に耳を傾け、それぞれのニーズに「機敏に(With Agility)」対応していくことで、弊社のサービスをより楽しんで頂けるように、引き続き前進しようとしています。

我々のアジリティーを支える原動力

その原動力として、以下のことが例として挙げられます。

パイプライン

フロントエンドチームは現在、アプリケーションのビルド・デプロイを全てパイプライン化しています。ビジネスリクエストであれなんであれ、開発が終われば速いスピードでユーザーに利用していただけるように、各ステップを自動化することから、開発からリリースまでの間で発生可能な様々な変数を極力減らせる仕組みを持っています。もちろん単純にスピードだけを求めるのではなく、テストを自動化することから変更のクオリティーも担保できるようにしています。

10% Rule

 私たちは「10%ルール」というものを実践しています。「10%ルール」とは、今のプロセスが改善できるものなら何をしても良いというスローガンを持って、通常案件とは別に業務時間の10%を投資して好きなことをすることです。軽い気持ちで集中できる金曜の午後に行われていますが、最初スタートする時は、メンバーのみんなが多少モヤっとしていました。「何をしたら良いのだろう」と悩みましたが、1週目2週目と経過に伴って、少しずつ具体的に何かが展開していることに気づきました。その結果をみんなと共有しながら少しずつ完成していく成果を見ることがとても面白いです。

私の場合、今まではなかったUIテストアプリケーションを実装しました。10%ルールで誕生し、最初プロトタイプだったものが今は20時間もかかるリグレッションテストをほぼ代替し、月におよそ30時間ほどのエンジニアのリソースを節約しています。その成果で社内で表彰されたり、外部の国際カンファレンスで講演機会を得ることができました。

今すぐパフォーマンスが出なくても、最初モヤっとするところからスタートしても、徐々に見える化することをみんなが楽しんでいる、その仕組みができているのが魅力的なところです。自分が興味を持つところを触るので、そこから湧いてくる責任感や使命感が、改善の原動力になることもあります。個人的に一番楽しんでいる時間です。

Mob / Pair Programming

 最近流行りのモブやペアプログラミングも積極的に導入しています。アジリティーの測定や改善を期待するためには、メンバーのプロダクトへの知識がある程度同一なベースに基づいていなければなりません。メンバー間の知識の差を最小にすることからみんなが共感できるアイデアも生まれやすいでしょう。

モブの対象は、コードの実装だけではなく開発プロセス全般にしています。例えば、「影響範囲シート(Impact Area Sheet)」というものを用意していて、新しい案件に対してどのパーツが影響されるかをみんなで判断する時間を持っています。プロダクトの規模が多少大きいので、メンバー全員のディスカッションで今まで知らなかったところが学習できたり、違う考え方を確認して、対策を模索したりしています。また新人に対しても、シニアエンジニアの視座が見習える良い機会となっています。

メンバー全員の参加が難しい場合、重要なのは形ではなく知識が共有されることなので、現実と妥協してモブからペアにしてでも、フロントエンドチームだけのナレッジベースの基盤作りに力を入れています。

Always improve with creativity

 意味のある改善ができるようにするためには、瞬間の奇抜なアイデアを大事にしなければなりません。そのため私たちはそういう議論の場がどこでも開かれやすい環境を用意しています。

時には一人で集中したいときもあるでしょう。そういうときは「集中スペース(Concentrate space)」に引きこもって、静かな雰囲気の間クリエイティビティが発揮できる環境も整えています。

緑の芝生や川が見えるワイドビューの居心地の良いラウンジはボーナスです。

プレッシャーの少ない環境にいるからこそ、エンジニアーのパフォーマンスも上がるのだと思います。実は前述したパイプラインもこのディスカッションから生まれました。何をどう改善したらより能率が上がるかをみんなで工夫しながら、現在の仕組みに止まらず、メンバー全員が常に改善を求めています。

その他

今までお話ししたこと以外でも、なるべくチーム員全員が毎日きちんとコミュニケーションが取れるようにしています。終業時に書いた「Fun & Done & Learn」を元に、印象的なテーマについて議論するか、週1回「Praising Time」と言って、多少気恥ずかしいですが、相手を一人ずつ選んで良かったところを褒める時間を持って、互いのやる気を促進する仕組みも持っています。

2週間1回のクラブ活動としてコミッティーというチームを構成し、ML(Machine Learning)やCI/CD等みんなで一緒に勉強会を開いたりもしています。

走り出せ。 限界を知らないレース

 前述にあるように、上の活動は全てシナジー効果を起こして最大のパフォーマンスを発揮しています。通常業務のスコープに10%ルールやコミッティー活動からの自らの改善タスクを足すことから全体的にペースの回転を加速化しています。またそれらをリリースしながらも自動化したテストで品質を担保しながらサービスのクオリティーも高めつつあります。

もちろん、最初から出来上がっているものは何もありませんでした。続けることの大切さという信念の元に、「プロダクト今日よりもよくしよう」と思いながら極限までのアジリティーを求めて続けているのです。

もしかしたら存在しない終着駅に向かって、私たちは進んでるのかもしれません。

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

8

この記事が入っているマガジン

ぼくたちのひみつきち
ぼくたちのひみつきち
  • 9本

日本中の「チーム自慢」を集めましょう。 みなさんの現場のお話をお待ちしております!

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。