GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
Articles
ブックマークされました！
ブックマークがエラーになりました。もう一度お願いします。
マネージャ 2.0: スクラムでのマネージャの役割
作者 Pete Deemer , 翻訳者 徳武 聡 投稿日 2010年8月23日
関連情報
組織がスクラムを調査すると早い段階で気まずい瞬間がやってくることが多いです。それは、“マネージャ“の役割が完全に欠落していることを誰かが指摘したときです。“え、マネージャをみんな厄介払いにしなければならないのか。”と開発者のひとりが皮肉ると、部屋にいるマネージャは皆、気まずそうに座り直します。
スクラムは3つの役割しか定義しません。それは、プロダクトオーナ、チーム、そしてスクラムマスタです。組織内の他のメンバに与えられる基本的な指示は、“彼らをサポートすること、彼らの邪魔をしないこと”です。これはあまり詳細な指示ではありません。特にあなたがマネージャで、上級マネージャからすべてのことが確実に首尾よく進むことを期待されている立場の場合、このような指示は大雑把すぎます。
企業の世界において、マネージャの伝統的な役割は“指揮統制”として知られるモデルに基づいます。ここでのマネージャの役割は何をする必要があるかを特定し、従業員に詳細な指示を与え、従業員が確実にその指示に従って仕事を完了するようにすることです。このモデルでの従業員は単純に与えられた指示に従い、正しい仕事を正しい方法で完了するためにマネージャの判断と知恵を信じるだけです。
しかし、ソフトウエア開発のような複雑で変化の激しい環境ではこの手法は機能しなくなりやすいです。まず、マネージャがすべての要求の完全な細部まで理解し、従業員の仕事を指導するため正確な指示を出すのは難しくとても時間がかかります。ソフトウエア開発チームの仕事は相互の関連の度合いが高く、複雑に依存し合い、変化や予期しない驚きが頻繁に発生します。ひとりのマネージャがチームのためのすべての基本的な判断を下すことを期待するのは現実的ではありません。また、マネージャの指示能力がチームの生産性を抑圧するのもよくあることです。加えて、この手法には従業員のやる気を減じてしまう傾向があります。というのは、従業員の役割が単に“指示に従う”だけになり、多くの場合、オーナシップをもって自分の仕事に取り組めなくなります。説明責任は“与えられた指示を完了できたか”という問いに対する答えに限定されます。この問いに対する答えが“イエス”なら仕事は完了したということになります。正しい結果を首尾よく生み出せたか、顧客のビジネスの目的を満たすものが作れたかは関係ありません。
スクラムは異なった手法に基づいています。それは、自己組織化チームです。チームの最初の一歩からして従来の手法との違いは明確です。スクラムではひとつのスプリントでチームがどのくらいの作業を行うのかのコミットメントをチーム自身が行います。チーム自身が作業量を決め、そのコミットメントが現実的で実現可能であれば、チームの集中力、モチベーションや活気がかなり上昇し、より良い結果を残すということは経験が示しています。マネージャがスクラムを初めて学習したとき、“チームが作業量を少なめにコミットする場合はどうするのか”という懸念が表明されることが良くあります。しかし、これは一般的には問題になりません。コミットメントの過程はとても透明でオープンにされているからです。実際には、早い段階でのスプリントではチームは作業量をかなり多めにコミットするほうが一般的です。というのは、ほとんどのチームは自身で見積もりをする経験がないからです。ありません。たくさんのスプリントをこなすことで、チームの楽観主義は経験によって鍛えられます。その上、作業量を少なめにコミットする場合でも作業が終わってしまえば、その分早くスプリントを終えることができるでしょうし、プロダクトバックログ上の次の項目を始められます。被害なければ問題なし、です。
Tangoチームは最初のスプリント計画ミーティングを終えたところだ。このミーティングは2週間のスプリントのためのものだ。彼らはマネージャのJasonを呼んで、決定したこのスプリントの間の作業内容を確認してもらった。
そして、彼らはJasonにこう尋ねた。“作業量はこれでいいのでしょうか。”
Jasonはチームに対して次のように尋ね返した。
“スプリントの間に仕事を完了させ、高い品質の結果を生み出せると本当に信じていますか。責任をしっかりと感じていますか。”
チームのメンバは全員うなずいた。全員が決定した内容を確信しているようだった。
“であれば、この作業量は正しいでしょう。”とJasonは返事をした。“多すぎたり少なすぎたということは今から2週間後にわかるでしょう。そのときは、次のスプリントではどのくらいの作業をコミットすべきかが学習できるでしょう。”.
自己組織化の次の特徴はスプリントの間に現れます。それは、チームが近くで一緒になって、誰がどのタスクを実行するのかを決めて、すべての作業が確実に完了できるようにするときです。チームがこの決定に責任を持つ場合、自分たちがコミットした内容の所有者であるということを考え続けます。チームの外の誰かが、誰が何をする必要があるのかについての決定に責任を持つとしましょう。例えばマネージャが責任を持つとします。そうするとチームは微かな、しかし確実に存在する信号を受信します。それは、自分たちには責任が無いという信号です。コミットメントが遵守されるかどうか心配するのはマネージャの仕事であり、チームの仕事ではないという信号を受信してしまいます。一方、チームが責任を持つということは、スプリントの間、マネージャはチームを支援しないということではありません。マネージャはチームの目的に対するオーナシップを減じるような信号や、スプリントの間の自己管理を妨げるような信号を送らないように注意します。
初めてのスプリントの初日、チームはマネージャのSanjayに毎日行うスクラムミーティングに来てくれるように頼んだ。Sanjayは何か力になりたいと思っていたのでその要求に答えた。チームのメンバが各自の報告をしている間、Sanjayは円陣から外れたところにいた。メンバは前日に完了した仕事については強調して報告しているが、ぶつかった障害の報告についてはあまり時間を裂いていないようだ、とSanjayは気付いた。チームのメンバは短い報告をした後、Sanjayの方を期待しながら見た。自分の成果を認める目配せを期待していたのだ。ミーティングの終わりに、メンバが円陣を解いて自分と向かい合わせになったことにSanjayは気付いた。
最後の報告が終わると、チームのメンバのひとりが手を挙げて尋ねた。“Sanjay、何かフィードバックや指導はありますか。”
Sanjayは彼がそうしなければならないのを知っていた。
“みんな, 私はとても心配しています。このミーティングが私の利益のためにやっているような感じがするからです。確実に正しいことをするためにみんながまだ私の方を向いているように感じています。いいですか。私はスプリントのどの時点でも、必要な支援はどんなことでもするつもりです。何らかの障害にぶつかって自分では解決できないのであれば、私が可能な支援ならどんなことでもします。でも、結局のところ、みんなには自分自身のコミットメントを遵守するのに必要な仕事をすることに対して責任があります。これからは私はこのミーティングには出席しないつもりです。これはみんなのミーティングです。目的は自分自身を管理氏、自分自身のコミットメントを遵守するためです。私がここにいると、こういう目的が私によって台無しになってしまうかもしれないからです。”
チームは黙った。それから、メンバであるVictorが話始めた。
“話を整理しましょう。私たちがここでは責任者であるということですね。私たちが本当に所有しているのはこの…”
チームの中に鋭い理解の感覚が走った。この時点でこのチームは本当の自己組織化チームになるための第一歩を踏み出したのだ。
自己組織化をうまく実現するための最大の困難のひとつは、チーム外のすべての人が細かい指示をチームに与えることをやめない限り、そのチームは自己組織化を始めないということです。チームは指示によって強く条件づけられています。したがって、従うべき指示がなくならない限り自己組織化を始めません。このような場合、チームは指示を出すマネージャを盲信しますが、これは恐ろしい事態を招く可能性があります。とはいえ、マネージャはチームを捨てる必要があるということではありません。むしろ、マネージャは意思疎通の方法を変えて、チームのメンバ自身が責任を持っているということがわかる信号を定期的に送る必要があります。
EileenはRedAlpha Systems社のエンジニアリングマネージャで、比較的若い開発者7人のチームと働いていた。最初のスプリント計画ミーティングで、彼女は部屋の後ろに座ってメールを書いていた。そのときチームはプロダクトバックログの一番上にある大きな機能を個別のタスクへと分解し終えたところだった。
この作業が終わったとき、チームのメンバはEileenの方を向いて言った。“どう思いますか。”
Eileenはチームがデータベース関連の重要なタスクをいくつか見落としていることにすぐに気付いた。彼女にとってその見落とされているタスクを単に指摘するだけで問題を解決するのは簡単なことだったろうし、それによって問題は解決しただろう。
しかしEileenは別の方法を試してみることに決めた。彼女は立ち上がって次のように言った。“みんな、いい仕事をしたわ。でも完全ではないね。いくつか見落としているタスクがあるから。それが何か私は教えるつもりはないけどヒントをあげる。ユーザセッションについてもっと注意深く考えてみて。私はこれからコーヒーを持ってくるから、5分後くらいに戻ってきます。戻ってきたら教えて。もし何が抜けているかわかったらね。”
そう言うとEileenは大股で歩いて部屋を出て行った。
チームのメンバは少し混乱した様子で互いに顔を見合わせた。Eileenはいつもは素早く間違いを指摘してくれた。チームはその指摘に依存していたのだ。しかし今回は、彼女はチームに間違いの指摘を任せた。彼らは黙ったまま立ち上がって、ホワイトボードの前でゆっくりと議論を始めた。ひとつひとつのタスクを異なった角度から検証した。数分間そうした作業をしているとTonyが 言った。
“ちょっとまてよ… ユーザセッションはどこに保存するつもりだ。保存用の新しいテーブルを準備する必要があるんじゃないか。だろ。”.
すると他のメンバがみんな額をピシャリと打った。
“そうだ。どうして見落としてしまったんだろう。”何人かがこうつぶやいた。恥ずかしさゆえのくすくす笑いがおこると、Samが黄色のポストイットに抜け落ちていたタスクを書いてホワイトボードに貼付けた。数分の後、Eileenがコーヒーカップを持って戻ってきた。彼女はホワイトボードを見てうなずいた。
“よくやったわ、みんな。ミーティングを続けてちょうだい。私は送らなければならないメールがもっと増えたから。”
Eileenはテーブルの端に座って自分の仕事ができることに満足した。
この例では、Eileenがチームにどうすべきか指示を出した方が早いし簡単だったでしょう。しかし、彼女がそうしてしまうと、彼女からの解決策を待つチームの姿勢を後押ししてしまいます。自分自身で考えなくなってしまうのです。Eileenが代わりにしたのはもっと難しい方法でしたが、それは究極的にはより価値がある方法でした。彼女はチームが忘れていたことをチーム自身に見つけさせるためにチームの肩に責任を置きました。そして、確実に見つけられるように十分なヒントを与えたのです。 Eileenが戻ってきたときにチームがまだ悩んでいたら、追加のヒントを与えたり、手がかりになる質問をすることもできました。チームが抜け落ちていたタスクを見つけるまでこのような助言や支援を続けることもできたのです。Eileenはタスクが抜けていることを指摘せずにそのままチームを進めてしまうこともできました。この場合、チームはスプリントの間に自分たちの見落としを発見します。失敗は最も強力な学習機会を生み出します。
最も単純な言葉で言えば、スクラムのマネージャはチームにとっては“子守”以下であり、メンターや“グル”以上の存在で、チームの学習や成長や実作業を支援します。これが“マネージャ1.0”から“マネージャ2.0”への移行です。
この新しい流儀の中でマネージャが効果的に振る舞うためには、組織がマネージャの役割やマネージャに対する期待を再定義しなければなりません。例えばスクラムでは、ひとつのスプリントでのコミットメントを遵守する責任はチームにあります。そして、これがうまくいくためには、すべてのマネージャがチームのコミットメント遵守に対して責任がないということをはっきりさせる必要があります。同じようにスクラムでは、スケジュール通りにリリースを行うことはプロダクトオーナの責任です。エンジニアリングマネジメントの責任ではありません。このことも組織のすべての人に周知する必要があります。組織内でマネージャの新しい役割について“話”しても、実際に困難が発生したときにその役割が“機能”しないときに問題が発生します。
Galaxyチームは数ヶ月の間、スクラムを実践してきた。チームは真の自己組織化チームになる道を着々と進んでいた。モチベーションも高く、ピントもはっきりしていた。また、何度かのスプリントで不十分な結果になったこともあったので、今や各スプリントで妥当な内容をコミットメントし、その内容を100%を遵守するパターンを見せている。高いモラルを持ち、実作業の“流れ”も実感している。エンジニアリングマネージャのFrancisも成長した。かつては細かく指示することを習慣にしていた彼だが、今やかつてよりも遥かにチームのメンターやコーチのように振る舞っている。しかし残念なことに、8回目のスプリントでチームは予想していなかった困難に直面した。そしてスプリントが半分過ぎたころには進捗にかなりの遅れが生じた。グループの副長のSimonは思い切ってチームの作業場へ踏み込んで、スプリングバーンダウンチャートを見た。そしてオフィスにFrancisを呼んだ。
“Francis、どうやらこのスプリントは大惨事のようだね。どうなっているんだい。”と彼は尋ねた。
Francisはこう答えた。 “チームがスプリントの途中でいくつかの障害にぶつかりました。皆懸命にコミットした内容をすべて完了させようと努力していますが、際どい状況です。”
Simonは渋い顔をした。
“Francis、このプロジェクトはとても重要だ。遅れさせるわけにはいかない。チームがコミットした内容を確実に終わらせるようにすることについては君を信頼している。このスプリントでも他のすべてのスプリントでもね。マネージャとしての君の役割はチームに確実に仕事を完了してもらうことだ。うまくいっているのなら少し後ろに引くのもいいが、まさかのときは現場に行って、チームが時間を無駄にせずにみんながやるべきことを正確に遂行するようにしてくれよ。”
Francisはイライラした。Simonは忙しすぎて社内のスクラムのトレーニングに参加していなかった。しかし、FrancisはSimonに自己組織化チームやマネージャの新しい役割についてのパワーポイントの資料をメールで送付していた。それに対してSimonは何も反対はしなかった。Francisは次のように言った。
“しかし、自己組織化チームはどうなります。Simon、細かく指示するマネジメント方法からの移行はどうなります。”
数ヶ月前に受け取ったパワーポイントの内容を思い出すにつれて、SimonはFrancis言ったことにかすかに覚えがあるのがわかった。
“ああ、チームには責任がある。でも彼らが失敗し始めたなら、私は君に責任を負わせるね。我々は最大限の説明責任を求めているんだ。だからチームにも責任があるし、君にも責任がある。君の部門の全員に責任があるんだ。さあ、なんとかしてくれ。”
こう言うとSimonは椅子をまわしてタイピングを始めた。Francisはヒントを得てオフィスを去った。
翌日、Francisはデイリースクラムミーティングに姿を現した。
“みんな、今日のミーティングはいつもと違ったやり方でやろう。このプロジェクトはとても大事だから、Simonは僕に指示をしたんだ。このスプリントの間、もっと活発に…うーん…
みんなの自己組織化の‘手伝い’をしろ、とね。そこで今朝のミーティングではみんながコミットした各機能についての状況の更新をしたい。今までのところ、誰が何を完了して何が未完了のまま残っているのかの状況をね。それで、その結果を踏まえて僕がさらに詳しいフィードバックをするつもりだ。これで来週末までにすべて100%終わらせられればいいんだけどね。”チームのメンバは互いに顔を見合わせた。チームのスクラムマスタであるPhilipはこう言った。
“Francis…うーん…ということはこのチームはもう自己管理について責任を負っていないということですか。”
この発言にうなずく数人のメンバ。
Francisは答えた。“みんな、我々は全員責任を負っている。みんなは自分を管理することに責任を持っているし、僕はみんなが確実にすべての仕事を終えることに責任を持っている。全員が責任を持っているというわけだ。”Francisはみんなの目玉が微かに回るのをみていなかった。
スプリントが進むにつれて、Francisチームへの関わりを強めるようになった。デイリースクラムミーティングは、チームにとっては完了できる作業をFrancisへ報告する場となり、Francisにとってはそのような作業を次週のタスクとして誰かに割り当てるミーティングになった。チームの雰囲気は変わった。モチベーションは低下し、チームのメンバはスクラム導入以前の役割に戻ったようだった。その役割とは、かつて“偉大なるFrancisのしもべ”と皮肉をこめて言われていたものだ。スプリントの終わりになると、チームは完全に“指示と服従”モードに戻ってしまい、Francisはチームの力をタスクからタスクへと割り当てていた。
スプリントレビューを行うときがきた。チームのメンバが驚いたのは、レビューの始めからSimonが参加していたことだ。
“それで…”とSimonは言った。“コミットメントはすべて遵守できたかい。”
チームのメンバは互いに顔を見合わせた。Francisが答えた。
“Simon、残念なことに完了できなかったバックログの項目がふたつあります。”
Simonの目には怒りで輝いた。
“どうしてだ。誰に責任があるんだ。”
チームは沈黙した。しかし、すべてのメンバはゆっくりとFrancisの方を向いた。
Simonは続けた。“Francis、君にはやり遂げてくれと言ったよな。次のスプリントでは同じことを繰り返さないでくれ。同じ結果になったら、えらいことになるぞ。…”
このやり取りを聞きながら、チームのメンバは皆、次のスプリントでどのくらいのコミットメントをするかとても慎重に考えて心のノートに書き留めた。彼らにとって最も嫌なのはこれから2週間また怒鳴られることだった。
スプリントをこなしていくにつれて、Francisはチームの各段階での作業に対してより積極的に指示するようになった。うわべだけの自己組織化すらなくなり、それに伴ってモチベーションや活気も悪くなった。かつてチームが見せ始めていた集中力もなくなった。モラルは急落し、同じように生産性も悪化した。昼食の休憩は長くなり、コーヒー休憩も頻繁になった。Francisはチームのメンバが机に座って仕事をすることを確実にするためだけにより多くの時間を費やしているように感じた。チームが真に自己組織的で、本当の実力に見合った水準の仕事をしていた初期の素晴らしいスプリントの記憶はますます遠ざかった。細かな指示をする方法に戻ったことにより、すべてが悪化した。皆、自己組織化の“豊かな暮らし”を経験していたからだ。
この例では各段階で判断の誤りがありました。スクラムマスタがFrancisの細かな指示からチームを守らなかったこと、つまりFrancisの“訳の分からない話”を呼び込んでしまったこと。そして、FrancisがSimonを説得しようと努力しなかったこと、つまりSimonの行動の重大さをSimon自身に知らせようとしなかったこと。しかし、最大の失敗は初期の失敗だと思います。それは、 Simonが成功するスクラムに必要なマネジメントモデルの変更について適切な教育を受けなかったことです。そして、スクラムが首尾よくいっているときだけではなく、厳しい状況のときにもこの変更をどのように適用するかについての教育も受けていません。そして、この変更はFrancisの職務内容記述書の“公式”な変更になりませんでした。その結果、成功した、高い能力を持つスクラムチームがすぐに以前の低生産な状態に戻ってしまいました。
上のシナリオはとても一般的な、スクラムへの体制変換の失敗の原因です。さらに、このシナリオ通りにことが進んだ組織では、噂があっという間に広まった結果、他のマネージャが自己防衛の手段として、詳細な指示をする管理方法へと積極的に回帰することも多いです。
ではこうした失敗を防ぐにはどうすればいいのでしょうか。
まず、マネジメント層が持つ変革への意欲や能力を明確に査定しなければなりません。マネジメント層や経営層に“指揮統制”的方法の効果に対する盲信がにあり、威嚇や脅しや罰則(屈辱を与えるような)をマネジメントの道具として使うことに過度に依存している場合は、新しい考え方の移行するのはとても難しいでしょう。その結果、スクラムの適用は不完全で機能不全になる危険性があります。そうなれば、組織はほとんど改善しません。
しかし、変革に対して理解を示し、既存の指揮統制的な方法は最も効率的な方法ではないかもしれないという認識があれば、すべてのレベルのマネジメント層に教育と指導が必要です。 実際には、すべてのマネージャに高品質なスクラムトレーニングが必要だということです。対象は最も職階の低い機能マネージャから上級のマネージャ(バイスプレジデントやその上)まで、組織のすべてのマネージャです。
そして、マネージャの役割の再定義を完了させるのに必要な最後の一歩は、組織の中で“その定義を公式にする”ことです。ひとつの方法は既にある職務内容記述書に下のサンプルを参考にした内容を追記することです。もうひとつは、組織のすべてのマネージャに対しての教育を完了し、彼らの職務内容記述書を一度破棄して、スクラムの価値や実践と互換性のある職務内容記述書を再構築することです。どちらの方法を採用するにしろ、マネージャの新しい職務内容記述書についてそのマネージャのマネージャ(例えばエンジニアリングディレクターや部門のトップ)から公式な許可を得ることはとても重要です。上層部からはっきりとした“公式”の許可がないと、何らかの困難が発生したとき、そのマネージャの新しい役割を守るのは難しいです。
スクラムマスタとしてのマネージャ
マネージャをチームのスクラムマスタにするという方法で、マネージャの役割を再定義する方法もあります。しかし、この方法は成功例が少ないです。マネージャがスクラムマスタの役割を担うと、チームは自己組織化が起こりえません。この場合は、以前の“命令する人-命令を受ける人”や“命令者-追従者”の関係を壊すのが難しく、以前の指揮統制的な手法の価値観やパターンがスクラムの実践の中に持ち込まれます。その結果、オーナシップや集中力、活気、品質への誇り、高いモラル、優れた生産性といった自己組織化チームの利点は実現できないでしょう。同時に開発に責任を持たなければならないとしても、ほとんどの場合はチームのメンバがスクラムマスタになるのが得策でしょう。
ハンズオン: マネージャの役割の再定義
必要な人: マネージャ、この訓練の進行役
ステップ1. マネージャに自身が現在抱えている仕事に対する責任をすべてポストイットに書いてもらう。マネージャには可能な限り包括的に、公式、非公式を問わず抱えている責任や、する必要があるものの時間がなくてできていないことを全部書いてもらう。ほとんどのマネージャは20から25の項目を思いつくはずだ。例えば下記のように。
ステップ2.ホワイトボードにふたつの列を書く。“スクラムと相性がいい”と“スクラムと衝突する/スクラムには必要ない”の2列だ。マネージャにひとつひとつのポストイットの検討を促して、そのポストイットをどちらかの列に置く。
ステップ3. “スクラムと相性がいい”に分類された項目をすべてマネージャの新しい役割として職務内容記述書に記述する(この段階で人事部門の協力を得るのは有益かもしれない)。
ステップ4. マネージャに次の質問をする。“あなたはこの新しい役割を担うことで、組織にとって今まで以上に役に立つようになるか、それとも今までよりも役に立たなくなるか。”そして“あなたはこの新しい役割に興味が湧くか、それとも関心がないか。”。ほとんどの場合、“役に立つ”と“関心がある”という答えがすぐに返ってくるだろう。
ステップ5. マネージャの新しい役割についてそのマネージャのマネージャ(例えばエンジニアリングディレクターや部門のトップ)から公式の許可を得る。これはとても重要な最後の一歩だ。公式な許可がなければ、マネージャの新しい役割は“公式”なものだと見なされないだろう。以前の指揮統制と細かな指示出しのパターンに戻ってしまう危険性すらある。
説明
スクラムと相性がいい
- チーム自身で解決できない障害を取り除く手伝いをすること
スクラムマスタがこの作業を毎時毎時/毎日毎日行っている一方で、マネージャはより体系的な問題や企業全体にわたる課題を取り除くのに集中します。これらの問題は組織にとって最もイライラするものです。そして、克服するにはマネジメントの影響や権威、尽力が必要です。>Ken Schwaberは著書The Enterprise and Scrumで、マネージャや経営層で障害対策をして企業を進化させる企業変革チームを作ることを推奨している。 - チームが直面する技術的な困難に対してアドバイスやインプットを行うこと
チームが尋ねてきたときは、マネージャはいつでもアドバイスや支援をできるようにしておくべきです。 - 指導や教育のため定期的にチームのメンバと一対一でミーティングをすること
マネージャは適切なタイミングで頻繁にチームのメンバと一対一のミーティングをするべきです。このミーティングはタスクの状態を更新するためではありません。指導や教育のためです。隣に座ってコードを書きながらこのミーティングをするマネージャもいます。 - 機能改善のためのインプットを与えること
このインプットは直接プロダクトオーナへ届きます。たいていはスプリントレビューのときです。 - チームが開発で使っているツールや技術、手法などを把握しておくこと
これはとても重要ですがいつも無視される活動です。マネージャは最後に実際の開発したときから技術や開発手法についての知識が“凍結”することがあります。 - チームメンバのトレーニングやスキル開発を計画すること
マネージャはチームが開発で利用したいスキルや、今後扱う予定のバックログに必要な能力について注意深く考えるべきです。 - IT産業のニュースや開発状況について最新の情報を持っておくこと
これも重要ですが無視されがちです。 - ツールやスキルなど将来必要なものを予想すること
これも重要なのに無視されがちです。チームからのインプットを確実に得ることです。 - 予算や財務について計画し管理すること
これも重要ですがあまり行われていません。チームからのインプットを確実に得ることです。 - チームが実装すべき機能についてのインプットを与えること
このインプットは直接プロダクトオーナへ伝えられます。 - チームのパフォーマンスを評価しフィードバックを与えること
これはほとんどの組織に必要です(使われている手法には実証済みの欠点がありますが)。マネージャは、自身の観察や同僚からのフィードバックに基づいて評価するべきです。 - チームのメンバのキャリア開発やキャリア計画を行うこと
キャリアの機会は、雇用者からの報酬の中で最高に価値があるもののひとつです。 - チームの新しいメンバを募集し、面接して雇うこと
最高の、場合によっては最悪の、マネジメント活動は人を雇う意思決定です。素晴らしい人を雇えば、その分だけ毎日配当を得られます。しかし、無能な人を雇えばチームのビジネス価値を生み出す能力に毎日見えない課税をされているようなものです。 - チームの中であまり機能しない人を除外すること
指導を積み重ねても作業に貢献せず、他のメンバの邪魔になったり、求めるレベルの業務をできない人は、チームから除外した方がいいかもしれません。マネージャがこのような行動をするときは、人事門と協力するのが一般的です。スクラムと対立する、あるいはスクラムには不要
- 行う必要のある作業を決めること
実装すべき機能や特徴はプロダクトオーナが決めます。そして、決められた機能を実現するためのタスクはチームが定義します。 - チームに仕事を割り当てること
これはチームがスプリントの間に決めます。 - チームのすべてのメンバが何をやっているのか追跡すること
これもチームが行います。デイリースクラムミーティングやスプリントバックログを利用します。 - チームが作業を完了させるのを確実にすること
これはチームに責任があります。 - 特定の日までにチームがどのくらいの仕事を完了させるかの管理を確約すること
プロダクトオーナがチームの作業の速度を見積もったり、計測したりします。そして、特定の日付までにどのくらいのバックログを完了できるかを予測します。プロダクトオーナが達成困難な日付にリリースすることをコミットした場合、それはプロダクトオーナはその目標を達成するのに必要なスケジュールの余裕を考慮することに責任を持つ。 - マネジメント層向けにマネージャがコミットメントをして、その内容をチームが満たすことに責任を持つこと
プロダクトオーナは、チームの作業速度が予想よりも遅かった場合どうするかについての意思決定をする責任を持ちます。リリース日を動かすのか、プロダクトバックログを減らすのか、バックログの項目を単純にするのか決める必要があります。 - マネジメント層のために状況の更新を毎週報告すること
スクラムには必要がありません。マネジメント層がプロジェクトの進捗具合を知りたいとき、彼らはプロダクトオーナにリリースバーダウンチャートを問い合わせます。 - 毎週チームでミーティングをすること
スクラムには必要ありません。チームは互いの更新情報を毎日交換します。マネージャはスプリントレビューのときに更新情報を得ることができます。
ハンズオン: マネージャの職務内容記述書のサンプル
- 新しいチームメンバの募集や採用を先導すること(今いるチームのメンバを活発に巻き込んだり、インプットを与えながら)。
- 製品の戦略とビジョンについてプロダクトオーナにインプットを提供し、プロダクトバックログの内容や優先順についてフィードバックを与えること。
- チームやそのチームのスクラムマスタを支援や援助をすること。チームが効率的に働くことを邪魔する障害を素早く除去するための手助けをすること。
- スクラムマスタがチーム内の混乱や分裂、チーム外からの干渉からチームを守ろうとする努力を積極的に支援すること。
- チームが作業する中で直面した技術的な課題に対して助言や支援をできるようにしておくこと。
- 拡張性や性能、セキュリティなど、チームが見逃しているかもしれない課題を特定すること。
- チームのメンバを指導し、キャリア開発上の助言やガイダンスを与えること。技術的な指導と同じように、ソフトスキルやその他の開発組織の中で効果的に上手に働くための態度も指導する。
- チームメンバのスキル開発やトレーニングを計画し管理すること。最良の開発が必要なスキルの領域や、最も改善の余地がある領域を注意深く考える必要がある。適切なトレーニングを見つけるために人と一緒に働き、トレーニングを完了させるために必要な予算と許可を手に入れること。
- チームが使っているツールや技術を理解しておくこと。使えそうなツールや技術についてチームやその他の関係者から情報を得ること。それらのツールや技術に親しむために時間を使うこと。
- IT産業のニュースを把握しておくこと。自分の会社や競合相手、最大の顧客の開発の状況を把握すること。それには、財務内容や市場シェア、製品ロードマップ、全体のビジネス戦略が含まれる。
- チームの中で、よく働かないメンバや他のメンバと一緒に効率的に働けないメンバ、要求される専門知識や品質のレベルを満たせないメンバを除外すること。これは、指導や教育をしても改善しなかった場合のみ行う。
- チームのための財務計画や予算編成を行うこと。この計画は、未来の採用活動や必要なスキル開発やトレーニング、ツール、技術、ハードウエアなどのその他のリソースを考慮する。
- チームのメンバの性能のフィードバックを提供すること。チームのメンバの業績評価を完成させること。非公式なフィードバックは定期的に提供される必要がある。また、それには同僚からのフィードバックが含まれる。フィードバックは、成果や成長の機会を正当に評価することに着目するべきである。
著者について
Pete Deemer氏はThe Scrum Training Instituteの創設者のひとりであり、スクラムの入門者に最も広く読まれているThe Scrum Primerの共著者でもあります。氏は世界的な企業で22年間の間、製品やサービスの開発のチームを率いていました。また、上級管理者としてYahoo!の大規模なスクラム適用を指導しました。これは世界中の2,000人を超える従業員を巻き込んだプロジェクトに成長しました。Yahoo!に在籍している間、氏はアメリカのYahoo!の製品開発部門のバイスプレジデントとして働きました。また、インドのバンガロールにある1500人規模の研究開発センターでチーフ プロダクトオフィサーを務めました。
推薦図書
Ken Schwaber氏のThe Enterprise and Scrum
Fred Kofman氏のConscious Business: How to Build Value Through Values
Peter M. Senge氏のThe Fifth Discipline: The Art & Practice of The Learning Organization
より詳細な情報が欲しい方はwww.ScrumTrainingInstitute.comへ。またはメールでpetedeemer@ScrumTrainingInstitute.comに問い合わせてください。
No comments
スレッド表示 返信