人事とアジャイルが目指すゴールは同じ

私は、SHIFTのアジャイルコーチとして現場に入りつつ、社内のスクラムマスターの育成も行っています。

新卒で入社したゲーム会社で長期的に働くイメージがもてず悩んでいたときに、『アジャイルサムライ――達人開発者への道』（著：Jonathan Rasmusson）という本と出会い、同書の「持続可能な働き方をしよう」「どこまでできるかは開発者が決める」という考え方に感銘を受けました。

加えて、当時SHIFTが専任のスクラムマスターを募集しており、「スクラムマスターの道を極めたい」と思ったため転職しました。

ゲームプログラマーだったころは「面白いゲームをつくろう」という考えが強かったのですが、スクラムマスターになることで「いいチームをつくろう」と考えるようになりました。

組織づくりが性に合っていたという背景もあります。

今回私が登壇した理由は、「三品さんのお話が、人事向けのイベントに合うので登壇してみませんか？」と打診されたためです。

はじめは「人事の方にとって興味深い話ができるかな」と思っていましたが、声をかけてくれた方と話しているうちに、アジャイルと人事には案外共通点が多いことがわかってきました。

例えば、人的資本経営、エンゲージメント、自律型組織などが共通点といえそうです。

例えば、アジャイルでは「プロセスやツールよりも人との対話を重視する」「チームは資産であり、優秀なチームは解体してはいけない」という考え方があります。

また、チームメンバーのパフォーマンスを発揮できるように奉仕する「サーバントリーダーシップ」も必要になります。これらは、人的資本経営と通ずるところがありますよね。

次に、エンゲージメントですが、アジャイルにはチームで成果を出す、つまり「チームのエンゲージメントを高める」活動も含まれます。

顧客、プロダクト、チームのエンゲージメントが高まれば、従業員エンゲージメントも高まる。こうした考え方も、似ているなと感じます。

最後に、アジャイルには自己組織化という概念があり、これが自律型組織とよく似ています。

内容はほとんどいっしょで、外部やリーダーからの指示を待たずに自己が主体的にゴールを決め、課題を解決し、改善成長をつづけていくという考え方です。

こういった点からも、人事とアジャイルは変化に強く、継続的に価値を生み出せる組織やチームをつくるという目的は同じなのではないかと思います。

ただし見ている視点、アプローチが違います。

スクラムマスターはプロジェクトメンバーやチームから組織や会社全体に広めていくのに対し、人事はトップレイヤーからプロジェクトメンバーのチームや人も見ています。

理想のチームをつくるための3つのポイント

それでは、開発においてはどうすればよいチームをつくれるのでしょうか。ポイントは3つあります。

1つ目は、開発をスムーズに進めることです。そのためにスクラムマスターはスクラムのプロセス、サイクルが円滑にまわるように支援します。

スプリントが開始されると、日々デイリースクラムでスプリントのゴール達成のために何をするか話し合い、作業を進めます。スプリントが終わると、動作可能な作成物ができます。

毎スプリント、実際に動作可能な作成物がつくられることで、開発が進んでいきます。

2つ目は、問題を早期発見・解決することです。開発が進んでから問題が見つかると、手戻りが大きくなるため、スクラムでは「透明性・検査・適応」の三本柱が重要視されます。

「透明性」とは、言葉通り、誰でも状況を確認できる状態にすること。そして「検査」をして計画とズレがあることがわかったら、すぐに対策を講じて「適応」します。

この「検査」と「適応」は、計画ミーティング、デイリースクラム、スプリントレビュー、ふりかえりといった各種イベントでつねに行われます。

3つ目は、プロダクトの改善とプロセスの改善を両輪で動かすことです。これはスクラムの肝といえる部分です。

プロダクトオーナーがプロダクトバックログをつくり、計画ミーティングで何をつくるか考え、スプリントを経て動作可能な作成物ができます。

レビューでフィードバックをもらい、それがまたプロダクトバックログに戻る。これが「どんな価値を提供するか（＝プロダクト）」をつねに改善するサイクルです。

一方、開発者は「どうつくるか（＝プロセス）」を自分たちで決め、スプリントバックログでタスクを分解し、デイリースクラムで問題がないか確認します。

スプリントの最後にはふりかえりを行い、自分たちの働き方も改善していきます。

スプリント期間は1〜4週間と短いので、劇的な変化はないように思えるかもしれません。

しかし、たとえ1%の改善でもあったとしても、積み重ねていくことで複利効果によって半年後、1年後には大きな差が生まれます。

これらの3つのポイントを押さえたチームこそが、変化に強く、継続的に価値を生み出せるチームだと考えています。スクラムマスターは、このような状況を実現・維持できるようにチームを見守り支援します。

よいチームでありつづけるために組織でやるべきこと

最後に＋αの部分として、よいチームでありつづけるためには、組織による支援や理解も必要です。

1つ目の支援策は権限の委譲です。何をつくか、つくらないか、いつリリースするか、ユーザーから直接フィードバックを得るか、などを自分たちで決められる必要があります。

会社によっては、チーム外の人の許可が必要だったり、ユーザーへのヒアリングが禁止されていたりと動きづらいことがありますが、こうした権限を委譲しないと素早く開発することはできません。

2つ目の支援策は、チーム内で開発が完結できるようにすることです。

プロダクトを開発するためには、ビジネスアナリスト、エンジニア、デザイナー、QAアナリストなど、開発に必要な能力がチームに備わっている必要があります。

プロジェクトによっては、デザイナーが外部にいてデザイン変更のたびに発注しなければいけなかったり、QA部門が別にあってつくったものを都度テスト依頼しなければいけなかったりしますが、これだと素早く開発が進みません。

最後は、組織がチームを信じることです。「アジャイル開発ははやく安く開発できる」と思われがちですが、そんなことはありません。すぐに成果が出ない可能性があります。

また、アジャイル開発ではメトリクスをとるようになりますが、目先の生産性を追求するあまり、ストーリーポイントを求められることもあります。

しかし、重要なのは「どれだけ作業したか」ではなく、「どれだけ価値を出したか（＝アウトカム）」です。ですから、目先の生産性を重視せずに、チームを信じて待つことも重要です。

「楽しく働く」を突き詰めた先に成果が待っている

私は、「チームメンバーに楽しく仕事をしてもらいたい」と常々考えています。もともと、私はゲームが好きでゲーム会社に入ったのに、持続可能な働き方ができませんでした。

しかし、チームでゲームを開発するのは楽しかったんです。

人生の半分くらいは働かなければいけないので、楽しく仕事がしたい。いままでの経験上、成果を出しているチームは楽しく仕事をしていると思います。

私なりの「楽しい」の定義は、大きく分わけて3つあります。1つ目は「納得できる」こと。これは、自分がつくっているプロダクトに価値があると信じられる状態です。

2つ目は「自分の意見が言える」こと。与えられたタスクをこなすだけでなく、自分の意見が反映される状態です。

最後は「フィードバックが得られる」こと。ユーザーの意見から、自分のつくったプロダクトが役に立っていると実感できる状態です。

私はスクラムのフレームワークを採用することで、こうした「楽しい」状況が自然に生まれるように支援をしています。

どのようなことが楽しいかは人それぞれかもしれませんが、この3つのポイントは状況や環境に関するものなので、どのような人にでも提供できるものだと思います。

「楽しい」環境を提供できれば、自ずと主体性、モチベーション、エンゲージメント、やりがい、自己効力感といった、もともと人事が実現したかったことも満たされるのではないでしょうか。

従業員が楽しく仕事できているか、ということをもう一度考えてみてください。みなさんが楽しく働ければ、それが結果として会社の利益につながっていくと思います。

人事もスクラムマスターもよいチーム、よい組織をつくりたいという想いは同じです。お互いのノウハウや知見を活用し、協力・連携することで、施策の効果をより実感できるのではないでしょうか。

（※本記事の内容および対象者の所属は、イベント開催当時のものです）