BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 分散チームの同調を保つには

分散チームの同調を保つには

原文(投稿日:2018/08/16)へのリンク

分散チームの最大の課題はコミュニケーションである。コミュニケーションは、コラボレーションの基本ルールを確立する上で不可欠なものだ。お互いの連絡に都合のよい勤務時間へのシフトやチームリエゾンは、コミュニケーションと作業同期を行なう上で有効な手段である。信頼と尊敬とオープン性に立脚したチームは、組織全体の人々を支援し、チーム間の同調を維持する文化を育む。

SkuVaultのプロジェクトマネージャであるMarat Kiniabulatov氏は、Atlassian Summit Europe 2018で、分散チームの構造について講演を行う。同イベントは9月3~5日、スペインで開催される予定だ。

他のユーザとともに私たちのチームに加わって刺激を受け、Atlassianツールを使用する最善の方法について専門家の話を聞き、最新のテクノロジとプロダクトアップデートを学び、世界をよりよいものにしてくれるチームを祝福しましょう。

カンファレンスの様子については、Q&Aやサマリ、アーティクルでお伝えする予定である。

InfoQはKiniabulatov氏に、分散チームの課題、SkuVaultにおけるプロダクトオーナやステークホルダとのコラボレーション方法とワークフローの管理方法、分散チームの効率的なコミュニケーションと作業同期の方法、SkuVaultにおいてチーム間の同調を維持する文化を育む方法などについて、話を聞いた。

InfoQ: SkuValutでは、分散チームに関してどのような課題に直面しましたか?

Marat Kiniabulatov: そうですね、言葉の壁から時差の問題、チームの一体性やモチベーションまで、たくさんありますが、最も大きいのはコミュニケーションです。この問題は、可能な限りの合理化が必要な、ワークフローやプロセスの把握にも密接に関わってきます。チームが同じ場所にいれば、直接対話することで非効率なプロセスを補うことも可能なのですが、離散しているチームでは、コラボレーションに関する基本的なルールを確立することが重要になります。

IInfoQ: プロダクトオーナやステークホルダは、要件の定義や優先順位付け、承認にどのように協力するのでしょうか?

Kiniabulatov: 先日、PO/アナリストと開発者とのタスクのやりとりの中で、開発者が新たな機能の開発に着手した時に、十分なリサーチとデータが用意されていなかったという、要求品質に関する問題がありました。一部のプロダクト領域では説明に関する基準がなく、そのためにビジネスロジックが曖昧であったり、あるいは矛盾していたりする場合があります。スタートアップではよくあることですが、品質は多少損なわれるかも知れません :)

要件がどのように処理されるのかをインタビューで追跡した結果、将来的な機能をQAチームと開発チームが共同で徹底的に議論し、ステークホルダが承認し、プロダクトオーナが優先順位を設定するという、独立したプロジェクトが立ち上がることになりました。

このプロジェクトでのワークフローのステップは、次のようなものです。

  1. 事前評価。提案されたほぼすべての機能について、プロダクトオーナがリサーチを行う。
  2. その後、一括してステークホルダの書名を受ける(通常は週1回)。
  3. 次に、QA、PO、開発チームが集まってユーザストーリを詳細に検証し、開発に先立って、想定されるあらゆるリスクを高いレベルから把握する。ワイヤフレームが必要な場合は、UX/UIチームの協力を得て資料を用意する。
  4. 最後に、開発待ち(Ready for Development)バケットを用意して、チームが開発対象として機能を取り上げるのを待つ。

この方法で、要件品質を大幅に向上させることができました。エッジケースを明確化するための堂々巡りをする必要は、今ではありません。

InfoQ: ワークフローはどのように管理しているのでしょう?

Kiniabulatov: 最初に背景を少し説明しましょう。当社には2つの機能チーム、1つのオンコールチーム、2つのサービスチームがあります。

機能チームではスクラムを採用して、プロダクトオーナが優先順位を付けたグローバルバックログから項目を引き出して、スプリントバックログに追加しています。

オンコールチームでは、緊急のバグに対して事前に適切な計画を立てられないという予測不可能な特質のため、かんばんを利用しています。オンコールチームの基本的な考え方は、緊急の問題に対応することと、機能チームの作業を中断させないことです。バーンアウトを回避するため、チームはローテーションしています。

後の2つは、運用をサポートするDevOpsチームとコアチームです。

DevOpsを除けば、ほとんどのチームは、ToDo、進行中、コードレビュー、テスト、完了という、WIP制限付きの典型的なかんばんバケットと同じ開発ワークフローを使用しています。

当社ではAtlassian Jiraタスクトラッカを使って、分散したチームに対してこのワークフローを仮想的に反映しています。

InfoQ: 勤務時間の重ならないない分散チームが効率的なコミュニケーションを行なって、作業を同期させるには、どうすればよいのでしょう?

Kiniabulatov: チームはそれぞれがユニークですから、どのような作業方法がベストかを決めるのはメンバ次第です。必要なのは時間をかけて調査し、適応することです。チームメンバが互いに遠く離れているために分散チームの採用が遅れている場合、コラボレーションパターンのための単一のカタログというものはありません。

ほとんどのチームには、メンバを一ヶ所に集めてオンサイトでプロジェクトを立ち上げる余裕はありません。ですから私の仕事は、あらゆるコラボレーションテクニックの中から、どれが彼らに適しているかを理解することです。

最も効率的な方法は、お互いが対応できるように勤務時間をシフトすることです。こうすることで、ある程度の作業時間を共有することができます。私が支援した中には、オフショアのメンバと時間を合わせるために、レトロスペクティブとスプリント計画を一緒にしたチームもあります。

分散したチームで開発されたパーツを結合する必要のある場合や、勤務時間内にリーチできない他のチームと接触する必要がある場合には、チームリエゾン(team liaison)という概念があります。ひとりのメンバをリエゾンとして選出して、デイリースクラムやスクラム・オブ・スクラム、あるいは全社的な議論に同僚を代表して参加させるのです。この役割は回り持ちで担当します。

私はブログに、作業時間がオーバーラップしなかったり、言語の壁があったり、あるいは単純に分散しているチームのための、アジャイルコミュニケーションテクニックの概要について書いています。

ただし、これらのコンセプトはいずれも、要件基準やさらなる文書化(すべての決定事項を書き留めておいて、ナレッジベースを通じて検索可能にしておく)、使いやすいワークフローなどを必要とします。

InfoQ: チームの同調を維持する文化を育てるために、どのようなことをしていますか?

Kiniabulatov: 健全な文化は、従業員自身がそれを理解し共有して初めて広まり、維持されるものです。完璧な世界では、文化は共通の目標を反映し、モチベーションに影響を与えます。それを達成するには、従業員の声を聞き、彼らの能力をプロジェクトと組織の両方に向けて、プロフェッショナルとして活躍してもらうことが必要です。

最終的には人が最大の資産であり、分散しているかどうかに関わらず、意欲的な従業員こそが最大かつ最も素晴らしい製品を世に送り出してくれます。組織そのものと同じように、そこで展開される文化もまたダイナミックな、時間の経過とともに変化していく存在なのです。

信頼と尊敬、オープン性に基づいたチームは、組織全体の人々を率先して支援し、他のチームのイベントを訪ねて進行中の作業について聞いたりトラブルについて話たりし、自らの経験をユーモラスなブログ記事として投稿し、お互いをチャットで“称賛(kudos)”します。

人々を結ぶ楽しく面白いアクティビティとしては、リリースノート用の猫の写真を検索する(猫の写真を探すことが大規模プロジェクトのリリースを意味しているということを、チーム参加者全員に周知しておく必要があります)、それぞれのクリスマス毎に小さなプレゼントを贈り合う、サイドプロジェクト(Webカメラベースの自動車修理やゲーム開発など)に一緒に取り組む、skype飲み会を開催する、などがあります。

そうすることで、従業員が明るくなり、彼ら自身と同じように活気と意欲に満ちた文化に変わることでしょう。

 
 

この記事を評価

採用ステージ
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

BT