複数のスキルを持つことがなぜ大事なのか？LeSSの視点から解説
こんにちはこんばんは。スクラムマスターの いのもえ です。
LeSS ではチームに所属する個人に複数の専門性を持つことを期待している表現を度々見かけます。実際に LeSS の夜明けのキーノートの中では単一専門性のみで現場に立つ事に関する課題についても触れられていました。
一方で、これまで単一専門性を究めることが自然だった人からするとかなりハードルの高いことなのではないか？とも思っています。
今回はこれについて自分の考えをまとめてみたいと思います。
なぜ複数専門性が求められているのか？
LeSS に限らず、アジャイル全体で探求していることの一つに「コスト削減」が挙げられると思います。
例えば、アジャイルの勉強を進めていると以下のような内容はよく見かけます。
プロセス上の無駄を省こう（リリースまでのコスト削減）
小さく効果検証しよう（誤った方向に進めることで無駄に作ることにつながるのを防ぐ）
集中して物事を進めよう（スイッチングコストの削減）
同様に、開発チームに限らず会社の経営にも広げて考えると "単一専門性を極めた多くの専門家を雇って進める" よりも、 "複数専門性を持つ少ない人数で進める" ことができればより少ないコストでやりたいことの実現ができる状況だと言えます。
LeSS で実現したいのはまさにこの「少ない人数で実現できる状況」です。
留意しておきたいのは、「専門性の数（≒ 種類）を削らずに実現する方法を検討している」というポイントです。
よく聞く不安について考えてみる
「複数専門性を持つことが求められている」という話に対してよく出てくる不安を取り扱ってみたいと思います。
十分得意でないこと/意向に沿わないことをやらされる？
私の考えは「やりたくないことをやる必要はないが、課題と向き合う必要はある。解決策は "あなたがやる" 以外を選択できる」です。
例えば、顧客折衝に慣れているメンバーが 1 名しかいないチームで、「顧客折衝が必要な仕事が 1 名で処理しきれないほど多くあり、仕事が遅延している」という課題があったとします。慣れている 1 名以外のメンバーは顧客折衝に慣れておらず、かつ、やりたくないと思っているとします。
この状況のとき、解決策は「慣れてないメンバーがチャレンジする」以外にも「チーム外から慣れている人を採用する」「顧客折衝が不要になるようプロセスを変える」なども考えられます。
顧客折衝をやりたくないメンバーは顧客折衝自体をやることは必要ありません。しかし、「顧客折衝が必要な仕事によって仕事が遅延している」という課題の解消については真摯に向き合う必要があります。
一番コストがかからないのは「慣れていないメンバーがチャレンジする」に見えることもあるかもしれません。私の考えでは、重要なのは "そういった状況であるということを自分たちで確かめて、自分たちで「慣れていないメンバーがチャレンジする」という策を選ぶこと" だと思っています。
コストを削減することを求めていくのであれば、他人に管理してもらうのではなく、チームが自分たちで自分たちを管理できる方がコストは低いです。その状況を実現できれば、「やりたくないことをやらされる」ことも起こることはないと考えています。
もちろん、この状況の実現にはスクラムマスターやマネージャーによる支援が欠かせません。
LeSS を導入したチームに入ったら専門性を究めることはできないのか？
私の考えは「究めることはできるが、その専門性の仕事ばかりをやり続けることはできない」です。
アジャイルな進め方を採用するのであれば、小さく効果検証を繰り返すために自ずと細かいプロジェクトを重ねることになると思います。例えば、スクラムであればスプリント一つ一つが小さなプロジェクトに相当します。1 スプリントは最大でも 1 ヶ月ですから、ある 1 領域のみに特化する人の仕事があるのは多くても 1 ヶ月未満の期間です。
例えば、バックエンドのコーディングに特化した専門性を持つ人がいたとします。1 ヶ月（4 週間）あるスプリントの中で、バックエンドのコーディングの仕事は 1 週間程度と仮定します。
この前提で、他の 3 週間の過ごし方について 2 つの案を考えてみます。
① 別のプロジェクトでバックエンドのコーディングを続ける。
その場合は複数のプロジェクトを掛け持つことによるスイッチングコスト、リソース調整のための管理コスト、引き継ぎにかかるコストなどが追加でかかることになります。
② 同じプロジェクトで他の専門性の仕事をキャッチアップしながら進める。
その場合はやったことない内容を進めるためのキャッチアップコストが追加でかかることになります。
①でも②でもコストはかかりますが、大きく違うのは掛け捨てになるコストの大きさが違います。
①の方では、その時にかけたコストによって後々に利益を得ることは難しいです。②の方では、キャッチアップによって次回以降はより早く仕事を終わらせることができるかもしれません。
他方で、 LeSS における専門性を究める仕組みは「コミュニティ」があります。コミュニティは同じ専門性を持つ人達が専門性の高い内容を話す場で、コミュニティで検討・議論したことを PBI にしたり、他のチームメンバーに共有することで LeSS チーム全体へ貢献しながら専門性を究めることが期待できます。
いきなり高品質を求められてしまうのか？
私の考えは「はじめから完璧は求められていない」です。
誰でもはじめは初心者です。この事実を覆すことはできません。一方で、コスト削減を求めるなら複数専門性を持っている人が多いほうがコスパは良いです。
これを両立させるために、 LeSS では開発プロセスの中に学習できる仕組みを取り入れることが重要視されています。
学習と企業運営におけるコスパの考え方は、 LeSS の公式サイトで紹介されている以下のブログシリーズが非常にわかりやすく、おすすめです。順番に読むことをおすすめしますが、特に学習の話がでてくるのは 2 番目です（記事の下部に同シリーズの他記事へのリンクがあります！）
〆
プロダクト開発における専門性の扱いについて、少し前は専門性が高いほうが優位とされている雰囲気があったように感じます。最近はどちらかというと深く知っているよりは広く知っている方が優位に扱われているように思います。
また、取り扱う課題の複雑化に伴って課題解決に必要な専門性も幅が広くなっており、状況によって必要な人材のバランスを考える必要があると思うようになりました。
LeSS では「複数専門性を持つほうが良い」とハッキリと言っているようなところもあって、これまで単一専門性を究めることが良いと言われていた人にとってはかなりエッジ（ここでは心理的なエッジを指します）がきついフレームワークなのではないかと思います。
この記事がエッジを乗り越える助けになれば幸いです。
いいなと思ったら応援しよう！
