スクラムだからとあーだこーだ言っても仕方ない

こんばんは。ドワンゴ Advent Calendar 2015 12/10担当の@regtanです。昨日はorzngoさんのCharlesでらくらくフロント開発でした。
今年の2月ごろまではニコニコ静画（電子書籍）の開発リーダーをやっていましたが、現在はもう一つ上のレイヤーでのエンジニアの管理や評価を担当しています。そんな中で、これまで以上にエンジニアチームのマネージメントや育成などの部分とこれまで以上に向き合う機会がふえました。

今年のアドベントカレンダーはとても技術よりの部分が多かったので、箸休め的に今日はエンジニアマネージメントについて書いていこうと思います。しかも、ポエム要素がつよいのでQiitaではありません。

評価されないと悩むスクラムマスター

先日、このようなエントリーを読みました。techblog.yahoo.co.jp
詳細はこちらのエントリに任せますが、このエントリーの中に出てくる評価されないと思い悩むスクラムマスターも世の中には多くいるかと思います。

スクラムマスターってなにをする人なのか

スクラムマスターはどういう役割を担う人なのかというと、スクラムガイドの中にはチームのサーバントリーダーつまりメンバーが成果を上げるために支援や奉仕をするリーダーとあります。でも、実際はどうでしょう。スクラムイベントの仕切りやJIRAやbacklogなどのカンバンを管理するだけの人もいます。カンバンの管理なんて下手すればbotが勝手にやってくれる場合もありますし、スクラムイベントの仕切りなんてslack botが時間になったら全員に通知さえしてくれれば足りてしまこともあります。

スクラムイベントの仕切りをすることやカンバンの管理をすることが「メンバーが成果を上げるために支援や奉仕をする」ことなのでしょうか。

先日、とあるエンジニアと飲み会の席でこんな話をしました。

「花を咲かせるのには24度に気温保つ必要がある」と聞いた時に「24度に保つことだけにひたすら頑張る」という人がいるけど、本当に求められるのは「花を咲かせる」ってことなんだからそこにコミットできないと何の意味もない。

いくら24度に気温を保つことに最新の技術を投入しても花がさかなければ意味がありません。最終的なゴールを見失っていては仕方ないということです。

評価されるスクラムマスターってどういう人なのか

上の話で行くと「花を咲かせる」ことを目指すために支援や奉仕をする人です。
つまり、形式や手法だけでなく、目標を達成するためになにが必要か判断し、それを実践することを推進する。時として、スクラムマスターという肩書きが邪魔になった時に適切にそれをすてることができる人です。

評価されないスクラムマスターってどういう人なのか

上の話でいくと「24度に保つことだけにひたすら頑張る」人です。
つまり、形式や手法だけを追い求めて最終的なゴールを見失い、スクラムマスターという肩書きだけをもつ、カンバンを管理する人です。そんなもの自動化してしまいましょう。わざわざ人間の手でやる必要もありません。

スクラムマスターをどう評価するか

スクラムマスターであるから良い評価を得られるというわけではありません。スクラムマスターとして何ができて、結果にどれだけコミットできたかで評価します。（肩書きへの評価ではなく一般的な評価とおなじく成果に対しての評価です）
評価をするにあたり、「スクラムマスターとして◯◯という取り組みをしました。」とアピールするメンバーも中にはいます。私が決まって聞くのが「それはスクラムマスターでないとできなかったことですか？それにより開発全体としてなにが変化しましたか？」ということです。
評価されないと嘆くスクラムマスターの皆さんはスクラムマスターでないとできなかったことに取り組み、成果を上げることができましたか？そうでなければ、評価されなくても仕方ないことなのです。

評価されるスクラムマスターをどう育てるか

一つはスクラムマスターは何をゴールとして取り組まなければならないかということを明確にして、そこに対して達成することを約束してもらうことです。そこにたどり着くための様々なアプローチを支えるのが上司のしごとです。
もう一つはそもそもスクラムマスターというものを置かないということです。評価しようもないポジションを作っても仕方ないのではないでしょうか。

スクラムにしても手法の一つでしかない

最近のアジャイル的な開発手法の話をすると窮屈な議論に陥りがちです。「スクラムなのでこうしなければならない」「XPなのでこうでなければならない」という手法を優先するばかりにプラクティスを取り入れることができなければ（スクラム|XP|アジャイル）ではないという話になってしまうからです。
本来、いずれの手法にしても結果にコミットすることを目指すもので、こうしなければならないというルールはほぼなかったはずです。うまくいかなかったすぐ辞めればいいのに、それをせずに続けて失敗するという事例を見ることもあります。
その開発手法・その技術しかありえないと決めつけることは非常に愚かなことです。上司としてもチームがそのような袋小路に陥らないようにしなければなりません。1〜10まで全て指示してチームがそのようにだけ動く組織もよいかもしれません。ただそうなるとマネージメントコストはかかるので長期的に見ると辛いことが増えてきます。
一定の方針の中で自ら判断し内発的発展をするチームや組織を多く生み出すことが上司としての役割だと考えています。

最後に

ほんとはIchigoJamについて書こうかとおもったのですがそれはまたの機会に。
明日は@urakawaさんです。お楽しみに。