InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

「邪魔をしない」ことを要望するチームメンバ

作者 Vikas Hazrati , 翻訳者 渡嘉敷 満理子 投稿日 2010年3月14日

セクション
プロセス/プラクティス
トピック
アジャイル技術 ,
Agile
タグ
Productivity

原文(投稿日:2010/03/09)へのリンク

多くの開発者は、孤立して作業をしたがるが、それは多少の時間であり、決して常時というわけではない。XPでは、「洞穴と共通の部屋(Caves and Commons)」と呼ばれる部屋の配置を推奨している。共通のエリアは、浸透性のあるコミュニケーションを最大化するように構成されている。洞窟は、個人的なメール、電話、クイック・スパイクなどを行うための孤立を推進することを意味する。ところが、複数または特定の1人のチームメンバが、このような孤立した状態での作業を過度に要望することがある。

Jacob氏は、ある状況についてScrum Development Groupで言及している。それは「邪魔をしない」時間の割当てをスプリント中に使用する上での基準を設けたいと、あるチームメンバがふりかえりの最中に申し出たことであった。この開発者によると、あまりにも頻繁に作業を妨げられているため、彼の生産性が最適とはいえないとのことであった。彼は、1日2時間割込みをブロックする時間を設けることを提案し、その時間はチームと話すつもりはないとした。Jacob氏によると、チームはこれをアジャイルに反する行為であるとみなし、コミュニケーションに悪影響をもたらすと判断した。このチームメンバの役割は、その企業のパートナということは別にして、チームのシニア・エンジニアであり、スクラムマスタであった。

Alan Dayley氏は、割込みはタイプによって異なることを示唆しており、次のように述べている。

その割込みが、彼が現在行っている作業に直接関係するとしたらどうなるでしょうか。その場合、割込みは大いに歓迎されるでしょう。では、複数のメンバ、さらには、チーム全体が1つのことに取り組んでいるとしたらどうなるでしょうか。この場合、その割込みは決して割込みとは言えません。彼らはその作業を行っているからです。

Kurt Haeusler氏は、この開発者を支持しており、開発者の中には孤立した環境を必要とする者もいるが、それは決して間違ったことではないと述べている。氏は、次の内容をはじめ、この問題には別の根本原因が考えられると述べている。

その割込みが彼の作業の障害になると残りのチームメンバが認識した上で、この開発者が実際に15分おきに割り込まれるような場合、その作業を行っているメンバは、その作業に必要な情報を持っているメンバではない傾向があります。

さらにKurt氏は、肯定的な点に注目すれば、あることについてふりかえりでこのように話し合われるのは、非常に有益なチーム文化であるとも述べている。

同様に、Elisabeth Shendrickson氏は、このシナリオが優れたコーチング課題になりうるとしている。Elisabeth氏は、複数の根本原因の可能性を示唆し、進行中の症状として考えられるのは、すべて仕掛中だが何も完了していない状態ヒーロー症候群アジャイルのエンジニアリング・プラクティスの欠如不十分な可視性やコラボレーションなどの兆候、あるいはより深刻な兆候として、チーム全体の意見の欠如、組織的なインセンティブに関する大きな課題などを挙げている。また、これに関して、さらに掘り下げて分析する必要があるとしている。

Roy Morien氏もまた、これは、「邪魔をしない」というよりは、開発者が複数の役割を果たそうとすることに問題があるように見えるとコメントしている。

一方、Johanna Rothman氏は、この開発者はチームにいるべきではないと、強い見解を示し、次のように述べている。

この開発者をチームから外すべきです。いずれにせよ、彼はチームとして機能していません。彼がしたいことを、このプロジェクトではなく別の場所でさせればいいのです。チームの速度は、「チーム」が主体であり、個人の速度ではありません。残りのメンバが話し合いを必要としているなら、彼は、孤立して作業をするのではなく、メンバと話し合う必要があります。ある人物が、シニア・エンジニア、スクラムマスタおよびその企業のパートナとしてどの程度の適正があるのか、私には分かりません。それは、彼が自ら選択することです。

Adam Sroka氏は同様の見解を示し、次のように述べている。

割込みを好まない者は、スクラムマスタになるべきではない、それだけです。スクラムマスタの役割は、チームに貢献することです。一日中、チームに対応できるようにしておく必要があります。それが彼らの仕事です。それ以外に重要なことがあるというのなら、それは真のスクラムマスタではありません。それならば、彼らを何かしらのシニアに割り当て、本当にチームに貢献したいと思う者を探してスクラムマスタにすればいいのです。

Siddharta Govindaraj氏は、興味深い見解を述べており、従来の方法からアジャイルの作業方法に移行する際に、そのような状況が組織に形成されることを示唆している。氏は、次のように述べている。

「理想的」には、メンバ全員が常に協力して作業することだと思いますが、そのような状態を支持する環境に移行する場合、時として、物事の均衡を図る必要もあります。Cone of Silence(会話を2人だけで行うためのツール)の興味深い点は、アジャイルの基本原則に反していることです。しかし、これはある特定のコンテキストでは、役立つ場合があります。

Siddharta氏は、プロジェクトで週に1回、Cone of Silenceを使用していたことについて言及している。その日は、全員個別に作業したが、その他の4日間については共同で作業した。時間の経過とチームの成熟にともない、最終的に彼らはCone of Silenceの必要性を取り除くことができた。

このように、ここにリストされているメンバの中で「邪魔をしない」という考え方に積極的な者が必ずしも多いわけではないが、一部のメンバは、コラボレーションと孤立には優れたバランスが必要だと確信している。このような場合、どのようなものがチームにとって効果的だろうか。また、あなたならどのような行動を取るだろうか。

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。