スクラムにおける既存職種のあり方について考えてみた(後編)
はじめに
前編、中編では既存職種のスクラムにおける役割を考えてみました。後編ではスクラムマスターはどのような人が適しているかという考察をします。
スクラムマスターに求められるもの
まず最初に開発者としての立場から、スクラムマスターに一番お願いしたいことについて書きます。それは障害・妨害の除去(Impediment removal)です。スクラムチームが仕事をする上で障害となっていることを見極めて、それをスクラムチーム一丸となって取り組めるように働きかける、それがスクラムマスターの一番の責務だと考えています。
なぜなら、自分は一昨年末に(スクラムをやっていない)チームを抜けましたが、どうやってもうまくいかなかったのは、開発者の役割を超えた問題解決です。開発者内で解決できる問題、例えば「たまに通らないテストがある」というのは開発内の問題として根気よく時間をかければ解決できました。しかし開発者の役割を超えた問題は手が負えませんでした。
その理由は2つあります。1つ目の理由は開発者が「片手間」で行うには大きすぎるからです。例えばアーキテクチャの見直しといった「重要だが緊急ではない」大きな変更は到底1スプリントで終わりません。技術的には漸進的に進めることも可能でしょう。しかし多くの場合、緊急なものを優先してしまいがちです。「重要だが緊急ではない」ものを進めるためには必ずこれはやり切ると宣言してチーム一丸となって取り組む必要があります。
もう1つの理由は、開発者の立場で仕事をしていると、開発者としての自分ができることにフォーカスしがちだからです。ボトルネックが開発者にない場合、開発者内で改善しても全体のスループットは上がりません。ボトルネックを解消するためには、全体を俯瞰的に見れる人が必要です。
この2つの問題を解消するためには、既存の役割と独立した、独自の役割が必要です。それがスクラムマスターです。スクラムマスターはチームの中にいながら、「岡目八目」ということわざが示すように、第三者視点で見ることができます。
そしてスクラムイベントはその障害を見つけ出しやすい形に作られています。例えばデイリースクラムは15分と決まっていますが、これは15分というタイムボックスを定めることで「毎回15分を超えるので進め方に問題があるのではないか」「毎回10分未満で終わるので形式的なものになっているのではないか」といった問題点を見つけやすくする効果があります。
スクラムマスターは人を活かし、持続可能なチームを作る
そのようなスクラムマスターはどのような人がふさわしいでしょうか。自分は職種を問わず、何より人を大切にする、共感力の高い人にこそなって欲しいと考えています。
プロダクトを持続可能にするためには、プロダクトの成長に合わせてアーキテクチャを追従させ、品質を高く保つ必要があります。その作業を行うのはチームメンバーです。そのためにはチームが持続可能でなければいけません。書籍「エクストリームプログラミング」(以下「XP本」)には「チームの継続」について次のように書かれています。チームメンバーがコロコロ変わるのも、属人化してしまいその人がいなくなると成り立たなくなるのも良くありません。
優秀なチームは継続させること。大きな組織は、ヒトをモノに抽象化する傾向がある。互換性のあるプログラミングユニットだと考えているのだ。ソフトウェアのバリューは、みんなが知っていることや行っていることだけでなく、人間関係やみんなで一緒に成し遂げることによっても生み出される。要員計画の問題を単純化するためだけに、人間関係や信頼の大切さを無視するのは経済的ではない。
小さな組織には、こうした問題は存在しない。そこにはひとつのチームしかないからだ。チームが一致団結し、信頼関係を築けたならば、チームがバラバラになるのは大惨事が発生したときくらいである。一方、大きな組織はチームの重要性を無視して、「プログラミング資源」に分子や流体のメタファーを使っている。プロジェクトが完了すると資源が「プールに戻る」というわけだ。そのような要員計画の目的は、すべてのプログラマーを可能な限り有効利用することである。こうした戦略は、気心の知れた信頼できる人と一緒に働くことの重要性を無視して、プログラマーにキーボードを入力させ続けるという幻想の効率化を求めている。局所的には効率化できても、組織全体の効率性は低下するだろう。
一致団結したチームを継続させるといっても、チームを固定化するわけではない。確立されたXPチームの新規メンバーはすぐに貢献を始める。その早さに驚かされるほどだ。最初の週からタスクにサインアップするし、1か月もすると単独で貢献を始める。チームを継続しながら適度なローテーションを行えば、組織は「安定したチーム」と「知識や経験の継続的な広がり」の両方の利点が得られるだろう。
そして開発者もプロダクトオーナーも無理しがちな人たちです。無理が祟ってチームが持続できなくなっては意味がありません。持続できないやり方を続けているなら、それを止めて持続できるやり方に変えて、チームを守るのがスクラムマスターの役割です。そしてもちろんその責務を果たすためにはスクラムマスター自身も持続できる働き方をする必要があります。
このような持続可能なチームを作るためにはどうすればいいでしょうか。XP本にはそのためのヒントがいくつか載っています。
いきいきとした仕事(Energized Work)
XPの主要プラクティスの1つである「いきいきとした仕事」は以前は「週40時間」として知られたプラクティスです。XP本ではより本質的な「無理なく続けられる時間だけ働くこと」という表現になっています。
生産的になれる時間だけ働くこと。無理なく続けられる時間だけ働くこと。意味もなく燃え尽きてしまい、次の2日間の作業が台無しになれば、あなたにとってもチームにとってもよろしくない。
なぜ長時間労働しようとするのだろうか?よくXPのプラクティスの「科学的」な根拠を求められる。まるで科学がプロジェクトの成否の責任を担っているかのようだ。労働時間についても同じ質問をしてみたい。週に40時間働くよりも80時間働いたほうが、より高いバリューを生み出せるという科学的根拠はどこにあるのだろうか?ソフトウェア開発は洞察力のゲームだ。洞察力は、準備の整った、休息のとれた、リラックスした精神から生み出される。
ゆとり(Slack)
同じくXPの主要プラクティスに、ゆとり(Slack)というプラクティスがあります。Slackと言えばチャットツールという時代になりましたが、英語では「緩み」「ゆとり」「余裕」といった意味があります。
どのような計画にも、遅れたときに外せるような重要度の低いタスクを含めること。あとからストーリーを追加したり、約束より多くのストーリーをデリバリーしたりするのは、いつでもできる。不信感を抱かれたり、約束を破ったりしたときは、やるべきことをきちんと果たすことが重要だ。少しでもやるべきことを果たせば、人間関係の再構築につながるはずである。
「組織パターン」の重要人物
中編で紹介した書籍「組織パターン」にもいくつか興味深い役割があります。中編で登場した「門番」の他に、「パトロン」「人気者」「偉人」「賢い愚者」と言ったロールが特に重要とされています。スクラムマスター自身が行うこともあれば、適した人を見つけることもあるでしょう。
パトロン
パトロンはマネージャーを説明するためのロールですが、マネージャーはチームを守るためにあると明確に説明されています。このロールの説明もスクラムマスターの障害・妨害の除去(Impediment removal)そのものと言っていいでしょう。
プロジェクトが、目に見える上位のマネージャーと交流できるようにしよう。そのマネージャーはプロジェクトの存在理由を擁護する人物だ。パトロンはプロジェクトにおける最終意志決定者だ。こうして組織は、意志決定を素早く行うために必要な駆動力を得られる。パトロンは、進捗を妨げるようなプロジェクトレベルの障害を取り除く責任があり、組織の「士気」(うまくいっているという感覚)を保つ責務を持つ。
人気者
人気者はコミュニケーションのハブとなる非公式のロールです。自分もこのような人に助けられたことが何度もあります。
人気者というロールを演じる人を数人立てて、社会的なプロセスを助けてもらおう。裏方になってもらうことも、表だったイベントを手伝ってもらうこともあるだろう。
(中略)
プロジェクトのメンバーは、人気者であるとして後ろ指をさされることがある。たとえば、こんな風に言う人がいるだろう。「彼女はいつも何もしていない。噂話ばっかりだ。」しかし、人気者は、組織が大規模プロジェクト同士をつなぎあわせ、成功させるうえで欠かせないのである。我々は数々の事例を通じて、人気者が一人もいなくなったせいで、組織の士気と文化が大きく変わってしまうのを目にしてきた。技術に強い人が一人いなくなるどころではないのである。人気者は本質的に非公式だ。プロジェクトマネージャーが誰かをこのロールに割り当ててもうまくいかない。そうではなく、このロールはすでに誰かが果たしている状態で、認識され、活用されるのである。こうした認識は、このロールを維持するのに役立つ。
偉人
数多くの役割をこなしていた人に対して、その人にちなんだ名誉あるロールを作るパターンです。偉人は多くのことをこなす一方で、属人化してしまい、その人が引退してしまうことで組織がバラバラになってしまう危険性があります。それを緩和します。
人にちなんでロールに名前を付けよう。そして、そのロールを果たすことを名誉としよう。人は伝説的な人物をまねたいと考え、同じくらいうまく仕事がしたいと思うものなのだ。
多くの場合、人にちなんで名付けられるロールは自然と発生する。そのため、そのロールを少しばかり形式的にして、伝説的な人物が引退したときに誰かを割り当てるのだ。
賢い愚者
最後に賢い愚者というロールです(自分はタロットカードの「0.愚者」を想像しました)。スクラムマスターはときにはこの「不快な真実」をチームに伝える必要があります。
賢い愚者というロールを育てて、不快な真実を口にしても罰を受けずにいられるようにしよう。
賢い愚者は、嫌な質問をしたり、政治的に危険な質問をしたりする。しかし、こうした質問によって、チームは立ち止まり、自分たちの判断を再検討するのだ。同じ質問をしたがる人が多いかもしれない。しかし、実際に口にはしないのだ。賢い愚者は、洞察や率直さ、無造作をごちゃまぜにして表に出す。
おわりに
3回に分けて、XP本を通した既存職種のスクラムにおける役割を考察してみました。スクラムを実際に導入する際はスクラムについて書かれた書籍を読むことが多いと思いますが、本記事ではあえてスクラム以外の書籍、古典とも言える「エクストリームプログラミング」「組織パターン」を取り上げてみました。
スクラムガイド 2020の内容はわずか13ページで、スクラムの本質とそれを実現するための最低限の要素が凝縮されています。読みやすくなった分、よく読まないと間違って解釈される危険性もあります。
一番多い誤解はスクラムを「開発プロセス」と考えることです。実際はスクラムガイドに書かれている通り「フレームワーク」です。開発者ならフレームワークという単語に馴染みがあると思いますが、プログラムの枠組みを決めるのがフレームワーク、プログラムから使うのがライブラリです。
これをスクラムに置き換えると次のようになります。スクラムというフレームワークがあり、チームのやり方、例えばデイリースクラムのやり方を自分たちで決めます。その際、定評のあるプラクティス、例えばXPのプラクティスを自分たちで選んで採用できます。
そして、フレームワークには明確な目的があります。スクラムガイドの先頭には次のようにスクラムの定義が記載されています。
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。
簡単に⾔えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。
1. プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。
2. スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。
3. スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。
4. 繰り返す。
「次の環境を促進するためにスクラムマスターを必要とする」、これを言い換えると、この環境を阻害するものを取り除くのがスクラムマスターの責務です。
この構造を理解しておかないと、スクラムを「開発プロセス」と捉えてしまい、スクラムイベントを形式的なものとし、開発者をコントロールしてしまう、従来のプロジェクトマネジメントのやり方に戻ってしまいます。それではスクラムでないのはもちろん、アジャイル開発とすら言えなくなります。アジャイルソフトウェア開発宣言に「プロセスやツールよりも個人と対話を」とあるのを思い出してください。
おわりのおわりに
「おわりに」が長くなってしまいました。改めて書き直します。
なぜアジャイル開発が必要なのか、それは人間性の回復のためです。
アジャイル開発以前のソフトウェア開発手法は人間性を無視してきました。人の強みをなくし、人のつながりをなくし、人を交換可能な部品として扱ってきました。
アジャイル開発では人間性を尊重します。人の弱さを認めつつ、人々が対話し、協力し合うことで人々に力を与えます。それを支える前提が「リスペクト(敬意、尊重)」です。まずありのままの相手に敬意を持ち、尊重する、それだけは忘れないでください。