[レポート]ベトナムと日本,海を越えたアジャイル開発 #scrumosaka

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Scrum Fest Osakaとは?

2020年6月26(金)・27日(土)にScrum Fest Osakaがオンラインで開催されました。 Scrum Fest Osaka 2020@ONLINEは以下のようなイベントです。クラスメソッドではシルバースポンサーとして協賛を行いました。

Scrum Fest Osakaはスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。この2日間を通じ、参加社同士でスクラムやアジャイルプラクティスについての知識やパッションをシェアするだけでなく、ここで出会ったエキスパートに困りごとを相談することもできます。

[ベトナムと日本,海を越えたアジャイル開発]

本記事は、セッション「ベトナムと日本,海を越えたアジャイル開発」をレポートします。

スピーカー

Yahoo! Japan 荒瀬中人氏

セッション概要

今回はオフショア開発に限ったお話ではありません。

  • チームメンバーと普段離れて仕事して状況が把握できない。
  • ステークホルダーを巻き込みたい。
  • 組織にアジャイル開発を浸透させたい。

上記にお悩みの方にも参考になります。

私はアジャイルコーチとして約1年前からベトナムにある子会社(Techbase VietNam Company Limited)のアジャイル開発の導入支援をしています。「チームは全員同じ場所で作業するのが良い!」アジャイル界隈に限らずよく耳にします。また、チームが頻繁にコミュニケーションし連動、連携するアジャイル開発はオフショアに不向きと言う声も聞こえてきます。 一方で日本でも新型コロナウイルス感染症の拡大がきっかけでテレワークが進み、やむをえず分散作業するスクラムチームを見ます。その結果、オフショアと似た課題を抱えているチームも少なくありません。 コロナで働き方が急激に変化しましたがベトナムのスクラムチームは変化に適応し持続可能なペースで活動できました。

なぜできたのか? 文化も言葉も違うベトナムと日本、両国のチームが目指した国境を超えたアジャイル開発、その裏にあるメンバーの思いや組織的な取り組みも含めてお話しいたします。

スライド

公開され次第スライドを追加します

レポート

チャレンジ

  • さらなる自己成長をするチームとしてAgile開発を進めていったお話
    • 管理コスト削減
    • 提案力向上
    • 生産性向上
    • コミュニケーションの質を向上
    • 技術力の向上
  • 最初に想像していた苦労は実際は無かった
  • メンバーの前向きなマインドに助けられた
  • Techbase Vietnam(TBV)について
    • 140名(日本人3名)
    • 20以上のヤフーのサービスを担当している
  • User First!
  • One Team
  • People focus
  • CMMi Level 3 認定

Agile開発に対する不安

  • ヤフーはステークホルダー
    • プロダクトの品質
    • コミュニケーション(管理)コスト
    • ドキュメントの量と確認が増える
  • TBV
    • プロダクトの品質・生産性
    • メンバーのAgileの適応力
    • 目指したいことの実現可能性
  • 荒瀬さんの個人的な不安
    • 初めての海外拠点のAgileサポート
    • 英語のコミュニケーション
    • サポート方法
      • 今までは、週1で伺ってたがそうは行かない
      • まとまった期間サポートして、まとまった期間離れる

Scrum実践に向けて

  • 既存プロジェクトの影響を軽減すること
  • Scrumの導入コストを軽減すること
  • 効果やプロセスを見える化すること

どのようにScrum実践していったか

  • 緊急性が高く重要なものは、優先開発。緊急性は低いけど重要な要件をScrumで開発した
  • Agileコーチによる要件定義のPBL化
    • 軽いFakePOとして、バックログの叩きを作る
    • ツールとか進め方を決めさせてもらった
  • スプリントレビューにてTBV主体のプロダクト検証
    • ツール
    • トピックス
    • ファシリテーション
  • 定期的なScrum継続判断
    • 定期的に継続判断をする
    • 現場を見て、研修/サポートを変える

Scrum研修2days

  • Scrum説明
    • 共通理解を得るためにやった
    • リモートアジャイルの事例とか話した
    • TBVのメンバーが感じる課題などや目指したいことのブレストした
  • DoD作成
    • 開発を担当しているエンジニア
    • コードの品質を担保できるけど、プロダクトの品質を担保できない
    • ユーザーにどんな不利益があるか声掛けながら
    • 不利益を与えないためのDoD
    • 品質をみたすために、アプローチ
    • 後々いい結果が出た
  • PBL作成
    • 受け入れ条件のみ明確にした
    • 受け入れ条件以外はチームへ移譲
  • Role説明
    • Roleの説明をしてRoleの決定をした
  • 現状のプロジェクトに対してメンバーが感じている課題
    • ドキュメント管理コスト
    • 対話コスト
    • ユーザーが見えにくい

見えてきた課題

  • 膨大なドキュメントの量に対して
    • ドキュメントに対する疑問や確認をする
    • 質疑・確認のMTGやテキストチャッティング
    • 結果ドキュメントの更新頻度が高い
  • ドキュメントを見て開発しているので、ドキュメントの更新コストが大きかった
  • 現状メンバーが感じている課題
    • ドキュメントの管理コストが高い
    • 仕様変更が困難
    • 対話コストが高い
    • ユーザーが見えづらい

大胆に実験

  • ユーザーを想像し自分たちで解決し、提案をして行こう

Scrum実践

  • 自分たちで考えてもらった
  • ユーザー像は、把握している限り伝えた
  • ツールはアナログを利用
    • ドキュメントの量が多いのが課題
    • アナログは書ける範囲が狭い
    • 小さい範囲の中で伝えていく
    • カイゼン速度を高めたい
  • 色々な勉強会をやった
    • バックログの切り方
    • スクラムのロール
  • スプリントは1週間で、荒瀬さんは2週間滞在
    • この2週間は、非常に忙しい
    • オブザーブして、勉強開して、明日の研修とか毎日考えていた

実験結果

  • 気づきとしては、以下
    • プロダクト(全体像)やユーザーが不明
    • 共通知識が不明
    • 通訳コストが高い
    • 技術力が想像以上に高い
    • スクラムマスターとマネジャーのコンフリクトが起こる
    • 意思決定による不安

プロダクト(全体像)やユーザーが不明

  • 新規プロダクトはプロダクトが明確だが、長寿プロダクトは、メンバーも入れ替わっており、全体像が分からない

共通知識が不明

  • プロダクトの担当範囲や経験による認識齟齬が発生していた。
  • それまでは、ドキュメントにより認識齟齬をカバーしていた。

通訳コストが高い

  • 対話/ドキュメントは通訳・翻訳を経由するので単純計算で2倍

技術力が想像以上に高い

  • 定義を委ねると拡張した
  • CI/CDとか自分たちで定義して実践していくようになった

スクラムマスターとマネジャーのコンフリクト

  • マネジャーの役割と仕事内容が、ScrumTeamに移行し職責を果たせない不安

意思決定の不安

  • 決めていいの???
  • 確認しなきゃ
    • 都度都度確認していた

気づきに対して更に実験

プロダクト(全体像)やユーザーが不明に対する実験

  • ヤフーメンバー出張時に一緒にターゲットユーザーを明確化
  • ユーザーストリーマッピング、ペルソナでターゲットユーザーの行動を理解
  • 実際のユーザーでプロダクト検証を行った

共通知識が不明に対する実験

  • 抽象化と詳細化を行った
  • 相互理解が出来ているものは、ドキュメントを減らせるチャンスなので抽象化
  • 調査だけではわからないものは詳細化
  • 抽象化と詳細化はバランスが重要

通訳コストが高いに対する実験

  • コミュニケーターにプロダクトを語れるための学習機会を提供
  • コミュニケーターがプロダクトを理解している状態を作る
    • 大幅にコミュニケーションが減った
  • SprintReview
    • 進行・ファシリテーションはコミュニケーターが行う
    • 質疑応答は、Team、PO(通訳)

技術力が想像以上に高いに対する実験

  • さらなる技術向上の環境づくりのため、Scrum Islandを作った
    • モブプロ
    • Sprint Review
    • オンライン研修
  • TBVのマネージャーがすぐに対応してくれた

スクラムマスターとマネジャーのコンフリクトに対する実験

  • ScrumTeam、マネージャーの全てタスクを洗い出し整理を行った
  • Roleがお互いサポートする
  • 更に上位レイヤー(評価者)にスクラム研修

意思決定による不安に対する実験

  • 裁量と権限の明確化した
    • ヤフーが決める範囲
    • TBVが決める範囲
    • 相談して決める範囲

さらなる自己組織化へ

  • 安定的に運用していくために
  • アジャイルコーチ育成
    • 荒瀬さんは、支援先から抜けることをミッションにしている
    • みんなでアジャイルを学べる
  • アジャイルコーチ育成
    • サポートオブザーブ
    • 勉強会
    • 勉強会サポート
    • 週1相談会
    • CEOとか大共有

まとめ

荒瀬さんのお話では、アジャイルを実践するための具体的にどのような事をやったのかが、非常に分かりやすく、なるほどと思う部分が多々ありました。改善されていったのもヤフーさん、TBVさんがより良くしていくために、しっかり前を向いていたからだと思います。さらなる自己組織化に向けて、益々パワーアップしていくチームの話を今後も聞きたくなりました。