インタビュー: Emmanuel Bernard氏にBean Validation仕様について聞く
Bean Validationフレームワークの初期ドラフトに関する以前の記事に続き、InfoQは専門家グループが求めているコミュニティの関与と提案について理解を深めるため、Emmanuel Bernard氏と対談しました。
- Java,
News
問題を抱えたプロジェクトの舵取り：まず酸素マスクを確保せよ
作者 Vikas Hazrati, 翻訳者 編集部 投稿日 2008年2月27日 午後6時56分
近頃、コンサルタントでありテストプロジェクトマネージャのFiona Charles氏(source)がStickyMindsで 問題を抱えたプロジェクトの舵取り(source)について興味深い記事を書いた。氏は問題を抱えたプロジェクトは独創力や一歩進んだ知識を学べるというすばらしい機会を 提供してくれるので、ときどきそういったプロジェクトを探し求めると言う。彼女の考えはテスターよりに合致しているものの、どのようにアジャイルチームが 問題を抱えたプロジェクトの舵を取り、好転させるかについて貴重な洞察を提供している。Fiona氏は、「問題を抱えたプロジェクト」と「万事終わりのプロジェクト」の間に違いがあることを明らかにしている。その違いを見分けるのは、常に簡単というわけでは ない。チームが前向きな変化のもたらし方に考えを合わせて、行動がプラスの影響を与えているような場合、プロジェクトは問題の抱えたプロジェクトであり、 好転できる可能性がある。アクションが効果を生じない場合、そのプロジェクトは死の行進(source)となり、さよならをするときである。
Fiona氏は、 正しい心構えを維持して独創的に問題を解決し、戦術的なソリューションを考え出す方法についての考えを共有した。以下の策略のリストを提示し、問題を抱えたプロジェクトを好転させて、そこで生き残り、栄え、役割を演じていくことを述べている。
ありのままの事実
明瞭で冷静に事実を提示すれば、事態が収拾する。最優先事項は、システムの質について明確な情報を得ることである。
周りとうまくやる
プロジェクトを好転させるには、チームのメンバーが信頼し、互いの考えを広く受け入れる寛大な気持ちが大切である。会議などの場において同僚を非難したり爆弾発言をすることほど、気持ちの寛大さを踏みにじるものはない。
チームに気を配る
問題を抱えたプロジェクトによって誰もが大損失を被るが、それほど力がない者には特に堪える。チームの管理をする場合、こういう大変な時期にこそ確実にサポートするようにする。(アジャイルチームのメンバーはこの分野でもサポート可能)。
まず酸素マスクを確保
共感、論理および独創性がつらい時期を通して役に立ち、プロジェクトに価値をもたらす。睡眠不足であったり、不機嫌だったりすると、効果的に利用することができない。
苦境を試す
チームにはっきりとしたテストの役割があるなら、問題を抱えたプロジェクトはテスターやテストマネージャにとってやりがいのある課題を与えることを気に留めておく。到着のバグ率が測定値の上限を超える場合、テストは減速し、不安度は上昇する。
いつも膝を曲げておく
問題を抱えたプロジェクトは前進のための融通の利かないプロセスのための時間ではない。
覚えておくべきこと--誰にでも起こり得る
プロジェクトの救済を求めているのではない。しかし、試すこともせずに問題を抱えたプロジェクトになってしまうこともある。
Stephen Cohen氏は、問題を抱えたプロジェクトを救済するより、問題に近付かないほうがより簡単で、常に助けになると信じているようだ。氏は、問題に近付かな いためにすべきことをリストとしてあげた(ブログ・英語)。その第一の原則は何か?分かりきっているが、問題が生じたときチームは必ずといっていいほど自己防衛的な振る舞 いに逃げる。 明瞭で冷静に事実を提示すれば、事態が収拾する。最優先事項は、システムの質について明確な情報を得ることである。
周りとうまくやる
プロジェクトを好転させるには、チームのメンバーが信頼し、互いの考えを広く受け入れる寛大な気持ちが大切である。会議などの場において同僚を非難したり爆弾発言をすることほど、気持ちの寛大さを踏みにじるものはない。
チームに気を配る
問題を抱えたプロジェクトによって誰もが大損失を被るが、それほど力がない者には特に堪える。チームの管理をする場合、こういう大変な時期にこそ確実にサポートするようにする。(アジャイルチームのメンバーはこの分野でもサポート可能)。
まず酸素マスクを確保
共感、論理および独創性がつらい時期を通して役に立ち、プロジェクトに価値をもたらす。睡眠不足であったり、不機嫌だったりすると、効果的に利用することができない。
苦境を試す
チームにはっきりとしたテストの役割があるなら、問題を抱えたプロジェクトはテスターやテストマネージャにとってやりがいのある課題を与えることを気に留めておく。到着のバグ率が測定値の上限を超える場合、テストは減速し、不安度は上昇する。
いつも膝を曲げておく
問題を抱えたプロジェクトは前進のための融通の利かないプロセスのための時間ではない。
覚えておくべきこと--誰にでも起こり得る
プロジェクトの救済を求めているのではない。しかし、試すこともせずに問題を抱えたプロジェクトになってしまうこともある。
互いに話をする。 プロジェクトが失敗になるのを防ぐことのできる疑いのない確実なアクションは、自由で開放的な意見交換である。しかしながら、プロジェクトが結果的に問題のあるものとなってしまった場合、チームは明確に定義された策略でそれを立て直す努力が必要となってくる。
Fiona氏は以下のように述べ、話を結んだ。
これまで説明してきた策略により、適切な考え方を持続し、自分自身の独創力を利用し、プロジェクトの問題に対する戦術的なソリューションを考え出すことが 可能となる。それができるのであれば、問題のプロジェクトで自分なりに楽しむことやプロジェクトスキルを磨くこともできる。
** InfoQの関連ニュース：責任、個人のアジャイル性、その他の親密なコミュニケーションのアイデア(参考記事)
原文はこちらです：http://www.infoq.com/news/2008/02/leading-troubled-projects
No comments
返信