InfoQ

InfoQ

News

マイブックマーク

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

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

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

アジャイルの"ルール"を"ガイドライン"に変えられるか?

作者 Vikas Hazrati , 翻訳者 吉田 英人 投稿日 2010年2月3日

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

原文(投稿日:2010/01/27)へのリンク

一般的にルールとは,ある行動に関して定義された基準のことをいう。ルールには従わねばならない。法律の非公式な呼び方が "ルール" である,と言い換えてもよいだろう。これに対してガイドラインとは,決められた手順に従うことによって,特定のプロセスを合理化する目的のものだ。定義上は,ガイドラインは義務ではない。アジャイルチームはルールを語るべきだろうか,それともガイドラインで十分なのだろうか? ことアジャイルチームに関しても,"スタンドアップ・ミーティングのルール" や "ふりかえり(Retrospective)のルール" など,ルールの話題をたびたび耳にする。

では アジャイルチームはルールを語るべきだろうか,それともガイドラインで十分なのだろうか?

ここに数多くのアジャイルチームが採用し,十分な成果も上げている基本ルールのセットがある。Robert McGeachy 氏が公開した,次のような アジャイルチームのための一連の基本ルール である。

  • 発言権は全員平等である。
  • 誰の発言にも価値がある。
  • 個人ではなく,問題を追求せよ。
  • チーム内でプライパシを維持せよ。
  • 互いを尊重し,自身の違いを尊重せよ。
  • 全員参加。

氏は,これらのルールはチームをかごに閉じ込めるのではなく,前向きにするためのものだ,と言っている。同じことを Bob Hartman 氏は,アジャイルプロジェクトには複数の可動部分がある,と説明する。

これらすべてが大急ぎで整理したした結果なので,私はチームに対して,最も基本的なルールと相互関係をよりクリアにするために,行動規則 (rules of engagement) を文書化してまとめるように勧めました。

氏はアジャイルチームが使用するための 行動ルールのテンプレート を作成している。

しかし Steven M. Smith 氏はそのルールの概念に対抗し,いくつかのルールがいかに簡単にガイドラインに置き換えられるか,を実証して見せている。

  • ルールは意図しない結果を引き起こして,個人とチーム双方の足をすくう。
  • 私たちはそのようなルールについて,それが私たちの行動できること,質問できること,発言できることである,として学んできた。
  • ルールは行動を決定付ける。しかしそれをガイドラインに置き換えれば,適切な行動を選択することが可能になる。

氏はいくつかのルールを例に上げている。

ルール:チームメイトにチームからの離脱を強いてはならない – このルールは信頼と誠実を示すものだが,その一方で 悪いチームメンバ によって苦労しているチームの生産性を低めることにもなる。

氏はこのルールに代えて,次のようなガイドラインを提案している。

このルールは次のようなガイドラインに置き換えることもできるでしょう — チームメイトの行動が生産性を破壊したり,資金が不十分であったり,あるいは彼らのスキルが任務にもはや合致しないような場合においては,チームメイトをチームから外すことも可能である。

ルール:顧客に対しては,すべてにおいて率直でなければならない – このルールはオープンさ,誠実さを奨励するものだ。これに対して氏は,顧客に率直でいられる程度には限界がある,と反論する。顧客に対して,例えばメンバのひとりがアルコール依存症でいつも酔っていたため,チームが予定期日を守れなかったと告げるのは不可能に近い,と言うのだ。氏が代わりに提案するのは,次のような方法である。

ルールをガイドラインに変換すること,例えば — 情報を公開することが顧客の利益になる,コミュニケーションのリスクを解析して受け入れる,あるいはその他の方法が私たちに受け入れがたいものである,などの場合であれば,顧客に対して完全に率直になることが可能である,というように。

ルールは多くの場合において物事をよりシンプルにして,標準的な方向付けをしてくれるものだが,このように往々にしてチームを,建設的でも破壊的でもない立場に閉じ込めてしまう。

なすべきことなさざるべきこと,この2つを告げる内なることばに耳を傾けてください。そこに有効なものを見いだせるならば,それがルールです。正確に記し,そしてガイドラインに置き換えましょう。チームの生産性と破壊性の限界を決めている罠線は取り除かなければなりません。チームに命令するのではなく,選択の機会を与えるのです。

特集コンテンツ一覧

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 のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。