スクラムにおける既存職種のあり方について考えてみた(前編)
はじめに
前回、スクラムにおいて開発者が推進するものとは？という記事で、エクストリームプログラミング(XP)とスクラムとの関係について述べました。この記事では、そのエクストリームプログラミングを通して、既存職種とスクラムでの役割の関係を考察します。
スクラムの役割は3つ
スクラムには3つの役割があります(正確には「責任」です)。開発者、プロダクトオーナー、そしてスクラムマスターです。この3つ以外の役割はスクラムチームにはありません。スクラムガイド(2020年版)では次のように書かれています。
スクラムの基本単位は、スクラムチームという⼩さなチームである。スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。スクラムチーム内には、サブチームや階層は存在しない。これは、⼀度にひとつの⽬的（プロダクトゴール）に集中している専⾨家が集まった単位である。
チーム外の人たちは「ステークホルダー」としてまとめられています。
なお「開発者」という言葉が使われていますが、これはプログラマーだけではなく、インクリメントの作成に直接的な責任を持つ人たち全員を指しています。
スクラムでは「開発者」という⾔葉を使っているが、開発者以外を排除しているのではなく、単純化のために使⽤しているだけである。スクラムから価値を得ているのであれば、そこにあなたも含まれていると考えてもらいたい。
XP本で説明されている役割
書籍「エクストリームプログラミング」(以下「XP本」)では「XPチーム全体」として、さまざまな職種のXPにおける役割が説明されています。これはXPにこのような役割があるというよりは、アジャイル開発以前に使われていた役割を示しているというのが適切でしょう(XP本の第二版の原著は2004年に発売されています)。
この書籍では次の10種類の職種についてどのように振る舞えばいいか説明されています。本記事ではXP本の記述を通して、この10種類の職種それぞれがスクラムの役割のどれに当てはまるのかを考察してみました。
テスター
インタラクションデザイナー
アーキテクト
プロジェクトマネージャー
プロダクトマネージャー
経営幹部
テクニカルライター
ユーザー
プログラマー
人事
開発者
開発者に分類される役割は次の5つです。
プログラマー
テスター
アーキテクト
インタラクションデザイナー
テクニカルライター
これらの職種において、次の点が強調されています。
プログラマー
プログラマーについては次のように説明されています。今でこそ少なくなりましたが、プログラマーは孤独にプログラミングをする仕事と思われていました。しかしアジャイル開発ではチームで共に働くため、技術力はもちろん、コミュニケーションスキルも必要です。
XPチームのプログラマーは、ストーリーやタスクを見積もったり、ストーリーをタスクに分解したり、テストを書いたり、フィーチャーを実装するコードを書いたり、退屈な開発プロセスを自動化したり、システムの設計を少しずつ改善したりする。プログラマーは技術的に密接に協力しながら一緒に働く。たとえば、プロダクションコードにはペアで取り組む。つまり、プログラマーは社交性や人間関係のスキルを身に付ける必要がある。
テスター
テスターについては次のように説明されています。単体テストはプログラマーの責務のため、テストの専門家としてプログラマーの支援も行いつつ、受け入れテストなどのシステムレベルのテストに注力する役割が求められています。
XPチームのなかで、つまらないミスを捕捉する責任の大半を引き受けるのはプログラマーである。テストファーストプログラミングからは、プロジェクトを安定させるテストスイートがもたらされる。つまり、テスターの役割は開発の初期段階に移行しているのだ。機能が実装し終わる前に、システムの受け入れ可能な機能を構成する要素の定義や仕様化を支援するのである。
アーキテクト
アーキテクトについては次のように説明されています。システム全体の設計という役割は変わりませんが、システムの成長に合わせてアーキテクチャを追従させるというこれまでなかった役割が与えられています。
XPチームのアーキテクトは、大規模リファクタリングの調査や実施をしたり、アーキテクチャにストレスを与えるシステムレベルのテストを書いたり、ストーリーを実装したりする。アーキテクトはプロジェクト期間中に、少しずつ専門知識を適用する。プロジェクトのアーキテクチャを進化させながら、方向付けをしていく。小さなシステムのアーキテクチャは、大きなシステムのアーキテクチャと同じであってはいけない。システムが小さければ、それにあった大きさのアーキテクチャにしなければいけない。システムの成長に合わせてアーキテクチャを追従させるのがアーキテクトの仕事だ。
アーキテクトとプログラマーは組織によっては完全に分かれていますが、XPではプログラマーとして実際の開発を行うことも要求されています。
アーキテクチャの大幅な変更を小さくて安全な手順で行うことは、XPチームの挑戦である。権限と責任のバランスを保つ原則では、意思決定の権限を誰かひとりに与え、その決定に他の人たちが当事者意識を持たずに従うのは、よくない考えだとしている。したがって、アーキテクトも他のプログラマーと同じようにプログラミングのタスクにサインアップする。ただし、アーキテクトは大きな見返りのある大きな変更についても目を光らせておく。
インタラクションデザイナー
インタラクションデザイナーは次のように説明されています。インタラクションデザイナーは自分には聞き慣れない言葉ですが、記載内容を見る限り、UXデザイナー、UIデザイナーが該当するようです。
XPチームのインタラクションデザイナーは、システム全体のメタファーを選んだり、ストーリーを書いたり、デプロイされたシステムの利用状況を評価して、新しいストーリーの機会を見つけたりする。最終的なユーザーの課題に取り組むことが、チームの優先事項である。ペルソナやゴールといったインタラクションデザインのツールは、本物の人間との会話の代わりにはならないが、チームがユーザーの世界を分析したり理解したりするのに役立つ。
これまでと役割は変わらないようですが、開発をフェーズに分割しないことを求めています。
インタラクションデザイナーに対するアドバイスの多くは、開発のフェーズモデルに準拠している。フェーズモデルでは、求められるシステムをインタラクションデザイナーが特定してから、プログラマーがそれを実現することになる。フェーズはフィードバックを減らし、バリューの流れを制限する。開発をフェーズに分割しなければ、インタラクションデザイナーとその他のXPチームのメンバーとの相互利益が成立するだろう。
テクニカルライター
テクニカルライターはシステム開発では最近あまり聞きませんが、製品のマニュアルやWebサイトを作る人たちです。次のように説明されています。
XPチームにおけるテクニカルパブリケーションの役割は、フィーチャーのフィードバックを早期に提供したり、ユーザーとの密接な関係を築いたりすることである。ひとつめの役割があるのは、最初にフィーチャーを目にするのがテクニカルライターだからだ。
ドキュメントはフィーチャー(機能)より遅れて完成するため、チームとは異なるサイクルで動く可能性があります。そのためステークホルダーと分類することも考えられますが、フィーチャーとドキュメントは同時に完成するのが理想なため、自分は開発者として分類するのが適切だと判断し、開発者として分類しています。
完璧なドキュメントはどのようなものだろうか?それは、記述されたフィーチャーが完成すると同時にできあがるドキュメントだろう。改善の必要性があるとわかったときに、簡単に更新できるドキュメントだろう。コストのかからないドキュメントだろう。基本的な開発サイクルの時間を増やさないドキュメントだろう。ユーザーにとってバリューのあるドキュメントだろう。
プロダクトオーナー
プロダクトオーナーに分類される役割は次の2つです。スクラムではプロダクトオーナーは1人と定められているため、1人がプロダクトオーナーになり、他の人はステークホルダーとして関わるのがいいでしょう。
プロダクトマネージャー
ユーザー
プロダクトマネージャー
プロダクトマネージャーは次のように説明されています。プロダクトオーナーそのものと言っていいでしょう。
XPのプロダクトマネージャーは、ストーリーを書いたり、四半期サイクルのテーマやストーリーを選択したり、週次サイクルのストーリーを選択したり、実装によって明らかになったストーリーのあいまいな部分の質問に答えたりする。
(中略)
チームがオーバーコミットしていたら、想定していた要件と現実の違いを分析して、チームが優先順位をつけられるように支援する。
ユーザー
ユーザーは次のように説明されています。ステークホルダーの方が適切かもしれませんが、「ユーザーがプロダクトマネージャーに成長することもある。」と説明されているため、プロダクトオーナーの候補として入れています。
XPチームのユーザーは、開発中にストーリーの記述や選択の支援をしたり、専門領域の意思決定をしたりする。
特殊な職種
次の二つの職種はチームでの役割ではなく、XPを採用することにより、チームとの関わりが変わる人たちです。
経営幹部
人事
経営幹部はチームを勇気づけ、チームを守る
経営幹部は次のように説明されています。チームのスポンサーとしてゴールを明確化する役割が求められています。
経営幹部は、XPチームに勇気、自信、説明責任を提供する。
(中略)
大きなゴールの明確化と維持は、XPチームのスポンサーや監督を務める経営幹部の仕事である。
もう一つ特徴的なのは、ボトルネックがチーム外に移動した時に、チームを守る役割を担っていることです。
チームが新機能をこまめにデプロイし始めたら、バリューの流れのボトルネックは組織の別のところに移動するだろう。経営幹部は、この移動がポジティブなものであるとあらかじめ会社に認識させておく必要がある。制約が移動したことによって、他の部門に問題があるかのように見える可能性があるからだ。それによって、ソフトウェア開発を元の状態に戻せと言われるかもしれない。それでも経営幹部は、毅然とした態度を貫く準備をしておかなければいけない。
人事は評価と採用の基準が変わる
人事は次のように説明されています。XPの採用によりチームで働くことが求められるため、人事評価と雇用のあり方が変わります。
チームがXPを適用し始めるとき、人事評価と雇用という2つの課題が発生することが報告されている。人事評価の課題が発生するのは、XPはチームのパフォーマンスに集中しているのに、実際の人事評価や昇給は個人の目標や達成度に対して行われているからだ。
人事評価には正解はありません。しかし少なくとも、チームとして働けることを重要視する必要があります。
XPチームのメンバーを個人として評価するといっても、XP適用前の評価の仕方を大きく変える必要はない。以下は、XPにおける重要性の高い従業員だ。
・リスペクトを持って行動できる。
・他人とうまくやれる。
・イニシアチブをとれる。
・約束したものをデリバリーできる。
役割の兼務について
最後に、役割の兼務について記載します。XP本では次のように、役割は固定的なものではないと記載されています。
成熟したXPチームにおける役割は、固定化された不変のものではない。全員がチームの成功に最善を尽くして貢献することが目的である。とはいえ、最初は役割を固定化しておいたほうが、新しい習慣を身に付けるのに役立つだろう。たとえば、技術側の人間には技術的な意思決定をしてもらい、ビジネス側の人間にはビジネス的な意思決定をしてもらうのである。チームメンバーが相互にリスペクトした新しい人間関係を築くことができれば、こうした役割の固定化は全員が最善を尽くすという目的の妨げになるだろう。そのときは、プログラマーでもストーリーを書けばいい。プロジェクトマネージャーでもアーキテクチャの改善を提案すればいい。
一方、スクラムガイドでは3つの明確な役割が定義されています。
スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を 持つ。スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスター という 3 つの明確な責任を定義する。
一見XP本とスクラムガイドの記述は矛盾しているようですが、正確には「役割」ではなく「責任」であり、少なくともスクラムガイドでは兼務は禁止されていません。そして、スクラムガイドではプロダクトオーナーやスクラムマスターがデイリースクラムに開発者として入る場合を定義しています。
プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。
おわりに
この記事では、XP本を通して、既存職種のスクラムにおける振る舞いについて記載しました。しかし残っている職種が2つあります。
1つはXP本における「プロジェクトマネージャー」、もう1つはスクラムにおける「スクラムマスター」の役割です。中編・後編ではこの2つの職種がどうなるのか考察していきます。