人の観点

次に人の観点を見て行きましょう。

ロールの明確化

スクラムでは、プロダクトオーナー、開発チーム、スクラムマスターという3つのロールが定められています。 この3つのロールをあわせてスクラムチームと呼びます。 またチームの外側には、ステークホルダーと呼ばれる関係者がいるはずです。 たとえば、顧客、ユーザー、スポンサー、営業、マネジメントチーム、スペシャリストチーム、QAチーム、運用チーム、社内管理部門、システム連携先などはステークホルダーの候補です。

まずはここから先を進めていく上で、誰がどのようなロールを担うのか明らかにしておきましょう。 スクラムチームだけに限らず、ステークホルダーが今回のプロダクトにどのように関係していて、どんな利害があるのかも明らかにしておくと良いでしょう。

スクラムでは、スクラムチームとその外側に境界を設定します。 境界を設定することで、開発チームは集中して成果を出すことに取り組めるようになります。 外部との接点は、プロダクト面ではプロダクトオーナーが担い、プロセス面ではスクラムマスターが担うのが一般的です。 つまり、プロダクトオーナーとスクラムマスターは外部と協働するのも仕事のうち、ということです。

プロダクトオーナーの決定と教育

スクラムで成果を出す上で、プロダクトオーナーはいちばん重要です。 プロダクトオーナーは、プロダクトの責任者（結果責任）を取る舵取り役で、プロダクトの価値を最大化する責任を持つ1人の人（委員会ではありません。 サポート役はつけても構いませんが最終決定権は1人に集約します）です。 次のような責任を担います。

• プロダクトの結果責任を取り、ビジネス価値を最大化する責任

• プロダクトのビジョンを周りに示し理解させる責任

• プロダクトバックログの管理と並び順の最終決定の責任

• 開発チームをうまく使う責任

• 開発チームの成果物の受け入れ可否を決める責任

• スクラムイベントに参加して開発チームやステークホルダーと協働する責任

• ステークホルダーをマネージする責任

• 予算の管理責任

• リリース日を決める責任

• スプリントのキャンセル判断をする責任

なお、開発チームのメンバーにタスクをアサインしたりやり方を指定する責任や権限はありません。

プロダクトに唯一の舵取り役なので、成果を出せるかどうかはプロダクトオーナー次第です。 ステークホルダーとのやりとり、開発チームとのやりとり、プロダクトバックログ項目の優先順位付け、開発チームが作ったものの受け入れ判断など、プロダクトオーナーにはやるべきことがたくさんあります。 その中でも、いちばん重要な仕事が意思決定です。

すべてのものは有限です。 プロダクトの開発の予算や期間は限られています。 開発チームの人数も限られていますし、その一方でやりたいことはたくさんあります。 すべてをやることは絶対にできません。 つまり、取捨選択の意思決定ができなければいけません。 「No」を言わなければいけないのです。 これができる人をプロダクトオーナーとします。 ステークホルダーの言うままにすべてを行わなければいけない状況であれば、その人はプロダクトオーナーとして適任ではありません。 適切な人を選び直すか、権限移譲が必要です。

プロダクトオーナーは色々な悩みや問題は尽きることはありません。 しかし、それを1人で抱え込む必要はありません。 すべてのことを1人でやりきれるわけでもありません。 困ったことがあれば、開発チームやスクラムマスター、ステークホルダーなどに助けを求めればよいということを理解する必要があります。

プロダクトオーナーが、いつどのようなことをやるか一例を挙げておきます。

• 初期

  • 事業計画を考える

  • プロダクトビジョンを考える

  • マーケットの状況を理解する

  • 事業やプロダクトの承認を得る

  • ステークホルダーを特定する

  • 必要な権限を移譲してもらう

  • 予算を確保する

  • マイルストーンを考える

  • 非機能要件を考える

  • 初期のプロダクトバックログの作成をリードする

• 開発中

  • プロダクトバックログを並べ替える

  • 開発チームの疑問に答える

  • スプリントプランニングに参加する

  • 開発チームの作成物の受け入れ判定をする

  • スプリントレビューを主催する

  • ステークホルダーをスプリントレビューに招待する

  • フィードバックを受けてプロダクトバックログを更新する

  • ステークホルダーや顧客の満足度を定期的に確認する

  • スプリントレトロスペクティブに参加する

  • 全体の進捗や今後の見通しを明らかにする

• 終盤 リリース計画を考える

  • マーケティングやサポートなど他のステークホルダーと連携する

  • 社内プロセスの手配をする

  • クロージングに必要なプロダクトバックログ項目をとりまとめる

誰がプロダクトオーナーをやるべきか

事業責任者がプロダクトオーナーを担う

プロダクトを開発するということは、そこに事業があります。 プロダクト自体は、事業を達成するための1要素ということになり、ほかにもマーケティングやサポート、営業などさまざまな要素が登場します。 事業責任者がプロダクトオーナーを担うということは、大きい会社であれば、たとえば事業部長が担うようなものです。 スタートアップであれば創業者が該当することになるでしょう。

メリット

予算を持っており、意思決定権限が強いので、プロダクトに対する判断を素早くできる。 たとえば予算やチームメンバーを追加したり、リリーススケジュールを変更したりするということも比較的容易

デメリット

プロダクト以外の仕事も多数持っていることが多いので、継続的にスクラムプロセスに関与し続けること自体が難しいことが多い。 たとえばイベントにプロダクトオーナーが来れず日程調整をするようなことが増え、プロセスのリズムが悪くなったり、プロダクトバックログの手入れが十分に行き届かず見切り発車が増える。 ほかの人に比べて立場が上であることが多く、開発チームとの間で健全な交渉が行われなかったり、フィードバックループが弱くなりやすい。 組織のサイズが小さいうちしか機能しない可能性が高い。

ビジネスサイドの人がプロダクトオーナーを担う

たとえば、企画担当の人がプロダクトオーナーを担う例です。 ある一定規模の組織になると、最初に出た事業のアイデアを具現化していくのに企画担当の人が参画して、詳細化していくことがよくあります。 その上で投資判断などを経てゴーサインがかかります。 このとき、引き続きその人がプロダクトオーナーになるイメージです。

メリット

ビジネスのことが分かっている（ドメイン知識がある）ので、どの順番に何をつくると良いかの判断がしやすい（意思決定の権限を事業責任者から適切に移譲されていることが前提になる）。

デメリット

技術的な知識がないことがあるため、性能やセキュリティ、運用といった非機能要件に関するプロダクトバックログ項目を用意できなかったり重要性の判断を間違えることがある（そのためスクラムマスターや開発チームがプロダクトバックログの管理を支援するのに時間を使う必要がある）。 組織として企画は平行して複数進めるようになっている場合、プロダクトオーナーが忙しくなりやすい。 プロダクトが生み出す成果に焦点をあてるといちばん成果を出しやすい。

UXデザイナーやアーキテクトの人がプロダクトオーナーを担う

企画が通ったあとに、それをUXデザイナーやアーキテクトなどエンジニアリングに近い人に引き渡して、進めていくやり方です。 組織構造上、企画部門と開発部門が分かれているような場合によく見られる形態です。

メリット

全体の使い勝手や、プロダクトにあった品質やアーキテクチャの構築という観点が考慮された状態でバランスを取って開発を進められる。 開発チームと近いスキルセットなので、開発チームとのコミュニケーションは円滑に進みやすい

デメリット

プロダクトのビジョンを開発チームに伝え続けるのが大変。 プロダクトバックログの並び順や、機能をどの深さまで作るのかという点をプロダクトオーナーだけで判断することができず、企画側などのステークホルダーと常時交渉と調整が必要になる。 関係性によっては常時プレッシャーをかけられることもある。 時に、作りすぎてしまう可能性がある

顧客がプロダクトオーナーを担う

受託開発の文脈で検討することのある形態で、発注者側がプロダクトオーナーを担当し、スクラムマスターと開発チームを受注者側が担当する、というような形です。 現実的には厳しいやり方です。

メリット

顧客が自分自身の責任でドライブできる

デメリット

いままでのやり方と関与の度合いが変わってくるが、その時間を捻出できず、開発チームに十分な時間が使えない。 発注側のマインドセットのままで、対立構造となってフィードバックループが形成されない。 プロセスを無視して、要求を押し付けてしまいやすい。 開発チーム側がプロダクトの価値を理解できなかったり、プロダクトバックログ項目ごとの意図が分からないままに、開発しなければいけないようなことが起こりやすい。

開発チームの適切なメンバーの選定

プロダクトの開発を進めることが決まった時点で開発チームのメンバーも決まっていることも多いかもしれませんが、 これから新しく開発チームを作る場合には、どのようなメンバーを集めれば良いか見ておきましょう。

適任者の特性は次のとおりです。

• 新しいことに抵抗がない

• 常に変化する状況にストレスを感じない

• 個人の責任範囲ではなく、全体の成果を気にすることができる

• 自分のことばかりではなく、人が困っているときに助けられる

• 意見や反論を言える

• コードが書ける・インフラが作れる・必要な技術スキルがある

これらはスクラムに限らずアジャイル開発全般にあてはまります。 アジャイル開発は変化への対応を重視しています。 したがって変化することが自然だと考えるようなマインドセットは重要です。 また個人ではなくチームによるコラボレーションやコミュニケーションを重視するやり方なので、周りから信頼を得られるようなふるまいができることが求められます。 もちろん、実際に役にたつものをつくる上で技術力も必要です。 すべてを高いレベルで満たすことはなかなかできませんが、開発チーム全体としてこれらが実現できるようにしましょう。 また、開発チームの強さはさまざまな角度から物事を考えられることなので、同じキャリアや考え方に揃い過ぎないように多様性に配慮すると良いでしょう。

開発者は必ず専任でアサインします。 他のプロダクトやプロジェクトを兼任していると、それに引きづられて十分にコミットできなくなってしまったり、ボトルネックになってしまい、かえって開発チームの迷惑になることもあります。 開発者が地理的に分散している場合は1箇所に集めて全員同席になることが理想です。 もちろん働き方の多様性も重要ですが、一緒に同じ場所で働いたことのない人たちが、同じ目的をもったチームとして働くことは難しいので、1か月程度でもよいので一緒に同じ場所で働くようにすることをお勧めします。

なお、アジャイル開発の考え方があわない人たちでチームを作ってしまうと失敗する可能性が高くなります。 例えば、以下のようなケースではリスクが高くなります。

• 開発チーム内の開発者のパートナー比率が非常に高い

• 既存のチームが強力な指示型で運営されている

• 開発経験が非常に少ないメンバーだけで構成されている

スキルの見える化

開発チームができあがったら、開発チームのメンバーのスキルセットを明らかにしておくのは良い手です。 見える化のためによく使われるのがスキルマップです（下図）。 そうすることで、成果を上げやすい技術を採用できるとともに、メンバー間でのスキルアップを進めやすくなります。

スキルマップによる見える化

スクラムの知識レベルを揃える

また、体制がある程度見えてきたら、さまざまな活動に本格的に入っていく前に、スクラムチーム（プロダクトオーナー、開発チーム、スクラムマスター）とステークホルダーの知識レベルを揃えておきましょう。 全員を集めて、アジャイル開発の価値観、仕事の流れ、イベント、作成物、ロールなどの基本的な概念を理解して、言葉があうようにします。 こうすることで、これから行う活動で、従来型の考え方をそのまま持ち込んでしまってムダが発生するのを防ぎます。 またこのような活動は、その後も定期的に行うと良いでしょう。 全員がプロセスに対して共通理解を持っていることは非常に重要です。

ファシリティ

これからアジャイル開発を始めるにあたっては、スクラムチーム全員が集まれる場所を用意するようにしましょう。 部署が違っていても同じプロダクトを開発しているのであれば、同じ場所に集まるのです。 このようなやり方を全員同席と呼びます。 全員同席はエクストリームプログラミング（XP）のプラクティスの1つで、コミュニケーションのオーバーヘッドを大きく削減できます。 専用の部屋が用意できると心理的にも安全性を確保しやすくなります。 逆に、社内で初めてのアジャイル開発を行うようなケースで、いままでの環境が日常的に静かな環境の場合、他のチームからクレームがつく場合があります。 こうなってしまうと、コミュニケーションが阻害されて、成果が出にくくなってしまいます。

道具を揃える

専用の場所が用意できたら、ほかに必要なものをまとめて準備しておきましょう。 よく使うのは次のようなものです。

• 付箋紙

• 模造紙

• ホワイトボード

• 大きなディスプレイ

• コーヒー

• おやつ

• 冷蔵庫

• ペン、マーカー、定規、その他文房具類

• もちろん速いPC

多くの場合、いちばんコストがかかるのは人件費です。 つまり人が安心して働きやすい環境を作ることは、いちばん高い「リソース」を効果的に活用する上で絶大な効果があります。

ワーキングアグリーメントを設定する

ワーキングアグリーメントとは、スクラムチームが規律を守って生産的に物事を進めるために用意するもので、仕事の働き方のルールを示したものです。 Googleなどは良いチームのポイントとして「集団規範」を挙げていますが、このような規範を明確にするものです。 ワーキングアグリーメントは、スクラムチーム全員で議論して納得した内容を明文化するものであって、 プロダクトオーナーやステークホルダーが強制するものではありません。

スプリント1の開始前までに用意して、以後レトロスペクティブごとに見直していくと良いでしょう。 守るのに注意が必要な項目に絞り込む（ホワイトボードの脇に貼れるくらいの量）、当たり前にできるようになったことを削除するなどして、軽量に保つようにします。

働き方の合意なので、スクラムチームによって内容は異なります。 例を見てみましょう。

• 午前9時〜午後4時がコアタイム。コアタイム外にスクラムイベントを設定しない

• スクラムイベントは休暇以外は全員参加。不参加の際は意思決定を委ねる

• デイリースクラムは午前10時に開始

• デイリースクラムの前までにタスクの残時間を更新しておく

• 毎週火曜日の午前11時からスプリントレビューを実施する

• レビューの準備には1時間以内

• イベントやミーティングは時間通りに開始して、タイムボックス内で終了する

• イベントやミーティング中は携帯に出ない

• レトロスペクティブでは、スクラムマスター以外はノートPCを閉じる

• プロダクトオーナーは午前11時〜午後3時まではチームの部屋にいる

• テストがすべて終わったものを完成とする

• ビルドが失敗した場合、修正コード以外のプッシュをしない

• 誰かに助けを求められたら「よろこんで」と返事する

• 予定休暇は1週間前までに共有する

• マスターブランチへの直接プッシュは禁止

• ペア作業をする場合は50分に1回10分休憩を入れる

• ドキュメントはマークダウン形式でバージョン管理システムに入れる

• 1つのことに30分ハマったら周りに助けを求める

• 体調が悪い場合は無理して来ない。周りに移す方が迷惑

• 休日の前日午後4時以降はリリースしない