Table of Contents
このエントリでは、Yegor Bugayenkoによる記事、Daily Stand-Up Meetings Are a Good Tool for a Bad Managerを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。
スタンドアップミーティング (または単純にスタンドアップ)は、「チームマネージャに状況報告をするためのデイリーチームミーティング」であるとWikipediaに書かれている。 こうしたミーティングは、ソフトウェア開発チームの間でとても人気な手法ではあるが、単なる悪であり、よいマネージャは決してやらない。 以下、その理由を説明する。
私は、スタンドアップのやり方が適切だったり不適切だったりする、と言いたいわけではない。それについて述べた記事は大量にある。 また、スタンドアップを上手く機能するように実施する方法についてアドバイスしようとしているわけでもない。 よいマネージャはデイリースタンドアップを決して実施すべきでないと言っているのだ。 スタンドアップは、単に「機能しない」だけでなく、非常に悪い、時に破壊的なものをマネジメントプロセスにもたらす。それがアジャイルかどうかにかかわらず。 一方、ダメなマネージャは常に、デイリースタンドアップを重要なマネジメント手法として使う。
私の意図を説明するため、マネジメントをいくつかの異なった視点から見ながら、よいマネージャとダメなマネージャが仕事をどのように進めるかを比べてみよう。
情報
ダメなマネージャは進捗を尋ねる。
オフィスを歩き回り進捗を訪ねて回るのは、ひどいマネージャの崇高な習慣だ。 彼は、プロセスと情報伝達フローを適切に構築できるほど賢明ではなく、チームが何をしているかを知らない。 しかし、彼は進捗を知る必要がある。彼もまた上司からちょくちょく尋ねられるからだ。 必要な情報を収集する唯一の方法は、チームに「今何の作業をしているの?」と尋ねることだ。 朝のスタンドアップは、メンバの作業内容を知らないことに気付かれずに、このうっとうしい質問を正式に尋ねる最高の場だ。
よいマネージャは必要なときに報告を受ける。
プロジェクトマネージメントにはコミュニケーション管理が必要だ。 情報伝達フローが適切に構成されていれば、チームメンバはいつどのようにマネージャに報告すればいいかが分かる。 何か問題が起きたとき、そういう状況をどのように報告しなければいけないかを全員が知っている。即時、直接報告するのだ。 作業が完了したとき、必要に応じてプロジェクトマネージャにどのように知らせるかを全員が理解している。 完璧なプロジェクトマネージャは決してチームに質問しない。代わりに、チームが必要なときにマネージャに報告する。 そして、報告を怠るメンバが出たときには、その壊れたコミュニケーションチャネルを修復するのがよいプロジェクトマネージャだ。 ただし、情報収集のためにデイリーミーティングは決して実施しない。
よいマネージャとして、何がゴールで何がプロジェクトマネージャ(またはスクラムマスタ)として重要かをチームに伝えるべきだ。 チームメンバは、マネージャがチームの進捗、リスク、障害、失敗について知るために何が重要であるかを知っているべきだし、チームメンバがマネージャの期待に沿えなければどんなトラブルに陥るかを理解しているべきだ。 プロジェクトやチームが取り組んでいる最も重要な課題についてをチームに伝えることは、よいマネージャとしてすべき仕事だ。 また、よいチームメンバとしては、重要な情報をつかんだら、すぐにマネージャに知らせることが重要だ。 これが完璧なマネージメントというものだ。
もしそのようなチームワークを築いたなら、開発者が今日何をしてどんな問題にあったかを、明日の朝まで待ってから尋ねる必要はなくなる。 マネージャはこういった情報をもっと早く、まさに必要なタイミングで知るようになる。 オフィスの外にいるときでさえ、プロジェクトで起こっていることを知ることができるようになる。 実際には、オフィスは全く不要にさえなるが、これはまた別の機会に議論したい。
デイリースタンドアップはプログラマ間で情報交換する最高の機会で、スクラムマスタに報告してフィードバックを受けるだけの場ではないと言う人がいるかもしれない。 もう一度、同じことを言うが、なぜ、その日の必要になった時点で情報交換をしないのか? なぜ、10人のメンバを毎朝集めて、その内たった5人だけに関係することを議論する必要がある? 答えよう。ダメなマネージャは、チームメンバ間で情報交換する場を用意する他の方法を知らず、朝のスタンドアップを適切なコミュニケーションモデルの代わりとして使う。 こういったミーティングは、マネージャが熱心に働いていて、大げさな給料を受け取るに値するかのような印象を与える。 対照的に、よいマネージャは定期的な状況報告ミーティングをいっさい実施しない。 なぜなら、効果的なコミュニケーションツールの使い方を知っているからだ。 例えば、問題追跡ツール、メール、コードレビュー、意思決定ミーティング、ペアプログラミングなど。
責任
ダメなマネージャはマイクロマネージメントをする。
ダメなマネージャはプロジェクトマネージメントのことをほとんど知らないので、大きな不安を抱えている。 彼はチームのコントロールを失うことを恐れていて、チームを信頼せず、いつも十分な情報を得ていないと感じ、上司から状況を尋ねられたときに動揺する。 このため、彼はチームメンバを抗うつ薬として使う。チームメンバが彼の言う通りのことをしているとき、彼はより安心と安定を感じる。 デイリースタンドアップミーティングは、彼がメンバに何をしているかを尋ね、代わりに何をすべきかを指示するためのすばらしい機会だ。 このマネージャは、メンバに個人の目標と計画を報告するよう強制し、必要だと感じればそれらを修正する。 次のようなやりとりをを何回聞いたことがある?「私はテストXをやるつもりです。…いや、それは来週だ。今日はYをやってくれ。」 これはマイクロマネージメントだ。デイリースタンドアップはマイクロマネージャのための完璧なツールだ。
よいマネージャは責任を委譲する。
理想的なマネージメントには4つのステップが必要だ。
- 複雑なタスクを小さいサブタスクに分解する。
- それらを部下に委譲する。
- 報酬と、ペナルティと、ルールをはっきりと伝える。
- 報酬はちゃんと支払われること、ペナルティは免れられないこと、ルールは厳格に守られることを確実にする。
完璧なマネージャは日々何をするかをメンバに指示しないし、業務時間の使い方にも口を出さない。 彼は信頼し、コントロールする。 彼は、メンバに作業方法を指示して自尊心を削ぐようなことは決してしない。 すばらしいマネージャは次のようなことを言う。「今日はテストXをやるつもりだって? それは君の判断だ。最大限尊重するよ。ただ、Yが今週中に完了しなければ、君は約束どおりプロジェクトからはずされるということを忘れないでくれ。」 こういうマネージャにデイリースタンドアップが必要だろうか? チームメンバに何をしているか聞く必要があるだろうか? 彼はメンバの計画によけいな干渉はしない。 代わりに、メンバを信頼し、成果をコントロールするだけだ。
重ねて言うが、私は責任は委譲されるべきだと強く信じている。この委譲は3つの要素からなる。報酬、ペナルティ、ルールだ。 近代西洋文化の中では、これらを定めるのはむしろ難しいかもしれない。普通は長期の契約と月々の給料がある。 しかし、よいマネージャは方法を模索しないといけない。それぞれのタスクは委譲され、分離されないといけない。 これは、あるタスクに従事しているプログラマは、その成功または失敗に個人的な責任を持たなければいけないということだ。 また、そのタスクの結果が与える影響を知っていなければいけない。
よいマネージャは、どんなチームメンバでも必ず責任逃れをしようとするということを理解している。 誰もがマネージャの両肩に責任猿(訳注: 責任のメタファである猿)を返そうとする。 それは自然で不可避なことだ。デイリースタンドアップミーティングはこのたくらみを助長するだけだ。
朝、君が私に進捗を聞くと、私はいくつか問題があって今週末までにタスクが完了できるか怪しいと言う。 それだけだ。私はもうそのタスクに責任がない。もし間に合わなくても私の失敗ではない。 私は失敗するかもしれないと伝えたよね? 今後、その責任は君がもつんだ。
よいマネージャはこういう策略について知っていて、それを防ぐために報酬・ペナルティ・ルールを明確に規定する。 もし間に合わないかもしれないと言われたら、報酬を逃しペナルティを受けることを思い出させればいい。
- 締め切りに間に合わないかもしれない…
- それは残念だ。君は$200の週末ボーナスを逃すことになる。プロジェクトマネージャやスクラムマスタがこんなことを言っているのを見たことがあるかい? あまりないと思う。そう、よいマネージャは珍獣なんだ。 しかし、よいマネージャだけが報酬・ペナルティ・ルールを明確に厳格に定義する能力を持つ。
この3点が定義されれば、毎朝状況報告ミーティングをする必要はなくなる。 全てがありのままに明確になる。全員がゴールと目標を把握する。 全員が失敗したときに何が起こるかを知っているし、成功したときに何を得られるかも知っている。 マネージャは毎朝それをメンバに確認する必要はない。マネージャはメンバの進捗を確認する必要もない。 マネージャは既に非常に明確に各メンバの目標を定めている。それについて毎朝話す必要があるだろうか?
ダメなマネージャは目標を定める能力がないので、毎朝メンバをマイクロマネージメントしようとする。 実際、ダメなマネージャは一日中マイクロマネージメントしている。 明確なゴールやルールがないので、チームが間違ったことをしたり何もできなかったりするのではないかと恐れている。 しょっちゅう状況確認するのはそのせいだ。 実際のところ、彼はチームの首根っこをつかんでいるのだ。
モチベーション
ダメなマネージャは皆の前で恥をさらさせてモチベーションを下げさせる。
ダメなマネージャはチームメンバにやる気を出させる適切な仕組みの作り方を知らないため、恥をさらすことへの生理的な恐怖を利用する。 誰も「忘れました」と皆の前で言いたくないのが当然だ。 デイリースタンドアップミーティングは全員を一列に並べて「昨日何をした?」と尋ねる場だ。 この恐怖の時間はチームにやる気を出させるだろ? 私はそうは思わないが。
よいマネージャは目標でモチベーションを上げさせる。
理想的なマネージメントは、目標を定めて、チームメンバがスキル、リソース、知識、情熱を駆使してそれを達成できるようにする。 適切に定められた目標は常に3つの要素からなる。報酬、ペナルティ、ルールだ。 すばらしいマネージャは組織の目標を個人の目標に落とし込む方法を知っている。 「もし今週中にこの機能を納品できたら、会社はさらなる利益を出せる。サリー、君個人としては$500を得る。もし君がしくじったら、君は他の、あまり面白くないプロジェクトに異動することになる。」 これが完璧に定められた目標だ。毎朝、皆の前で、機能の実装を忘れてないかとか、熱心に作業しているかとか、サリーに尋ねる必要があるだろうか? この尋問は彼女の手助けになるだろうか? なるはずがない ! 彼女は既に何のために作業しているか知っていて、動機付けは十分だ。 彼女が期日に作業を終えたら、ミーティングを開いて、皆の前で$500のチェックをあげよう。 これがよいマネージャによるミーティングの使い方だ。
他にもある。 皆の前での日々の進捗報告は、チーム内最高のメンバを堕落させ、最悪にしてしまう。 主な理由は、彼らは突出した成果を出すことで他の人の気を損ねたくないからだ。 グループ内で他の皆と同じように振舞おうとするのは、人間の性だ。 皆が「まだ結果は出ていません」と報告しているときに、有能なプログラマが「全てのタスクを終えたので、他の仕事をください」と言うことを期待するのは奇妙だ。 いや、一回くらいはこういうことを言うかもしれないが、しばらくするとこの有能なプログラマは熱心に作業することをやめるか、チームを抜ける。 彼は、彼の成果が際立っていることを知り、それがグループから評価されていないことを知る。マネージャが何を言おうとも。
よいマネージャは、プログラマそれぞれに固有の作業速度、質、給料があることを理解する。 よいマネージャは、人によって与えるタスクを変え、異なる結果が返ってくることを期待する。 明らかに、朝全員を並ばせて、皆が同じような報告をすることを期待するのは大きな間違いだ。 この間違いは、突出した成果を出して格別な評価と報酬を得たがっている有能なメンバに破壊的な効果をもたらす。
ダメなマネージャは異なる人々を異なる方法でマネージメントできない。単にやり方を知らないからだ。 そのため、デイリースタンドアップという、全員が同じような、比較しやすい成果を報告する場が必要になる。 また、皆と違った報告をする人を責めたり励ましたりもしやすい。 言い換えると、ダメなマネージャはデイリースタンドアップを平等の手段として使う。この場合の平等は、チーム全体のモチベーションを破滅させるだけだ。
デイリースタンドアップや、他のあらゆる状況報告ミーティングは、怠惰で愚かなマネージャを隠して守るのにはすばらしい手段だ。 マネージャの無能っぷりをチームメンバから隠すことができる。 適正のなさを隠し、問題や挑戦やリスクへの恐れを隠す。 よいマネージャになりたいなら、デイリースタンドアップで自分自身を困らせないことだ。
以上がYegorの記事。
Yegorは、自身が経営するTeamed.ioという会社でのソフトウェア開発プロジェクトを、自身が考案したXDSDという手法を使ってマネジメントしている。 上の記事は、そのXDSDを念頭に、 巷で流行っているスクラムなどで行われるデイリースタンドアップにはっきりと異を唱えるものだ。
アジャイルソフトウェア開発宣言が発表されてから14年もたち、私の会社のような古い体質の組織にもアジャイルな手法や理念はさすがに浸透していて、私の周りでもデイリーミーティングをするチームが目立つ。私としては、管理される側にとっても、管理する側にとっても、いい情報交換の場だとは思うが、だらだら長くなりがちで、じわじわ煩わしくなるのが難。
Yegorは、定例ミーティングなんかやめて、情報交換は必要なときに必要な人どうしでやれよと言っているわけだけど、悪いニュースは隠したくなるし、いいニュースもきっかけがないと報告するのがおっくうになるのは自然の摂理ではないか。 この摂理を乗り越え、適時情報共有するための、「適切な情報伝達フロー」の作り方は、また別の記事に書かれているんだろうか。
責任の委譲についてのくだりは、以前読んだドラッカーを思い出した。もしドラだけど。 ドラッカーは「権限 (authority) を委譲しろ」と言っていたけど、Yegorは「責任 (responsibility) を委譲すべき」と言っている。 また、ドラッカーは、「権限の委譲を責任の放棄と混同してはいけない。権限を委譲したらむしろマネージャの責任は大きくなる」と言っていた。 つまり、Yegorはここでさらっとドラッカーにも異を唱えていることになる。 権威によるバイアスもあるのかもしれないが、私にはやはりドラッカーの話の方がしっくりくる。責任は猿みたいに身軽に移動できるものとは思えない。 失敗した部下のボーナスを減らして別のプロジェクトに飛ばしたところで、開発の遅れを取り戻せるわけではないし、納品が遅れたら怒られるのは結局上の人たちだ。
ところで、XDSDもそうっぽいけど、アジャイルな開発手法は基本的に、意欲に満ちた優秀なメンバで構成されたチームを前提に組み立てられたものだ。 私の会社を含む、日本の大企業がやっているような、経験(ほぼ)不問、サークルやバイトでの体験談を聞いて新卒一括人柄採用なんてボランティアみたいな選考方法を刷新しない限り、上手く回るようになることはない。 こんないい加減なやり方で集められた烏合の衆で、何千万も何億も稼ぐソフトウェアを作ろうってんだから、上の人たちはさぞかし大変なんだろう。意欲に欠けた部下の尻を叩くためにデイリースタンドアップをやらざるを得ないマネージャを批判するのは、ちょっと気の毒に思える。
