SmartHR Tech Blog

SmartHR 開発者ブログ

SmartHRにおけるクロスファンクショナル実践例

こんにちは!

SmartHRで開発したり、アジャイル推進したり、筋トレしたりしてるkouryouです。

SmartHRでは顧客の価値の最大化を目指し、日々開発プロセスの改善を行っています。
特に私の所属する基本機能のDチーム*1では、以前からクロスファンクショナルを強く推進しています。
本日はクロスファンクショナルとは何なのか?やってみてどんなメリットがあったのかをまとめました。

クロスファンクショナルとは

スクラムガイドでは機能横断型と翻訳されています。
機能横断型というのは、エンジニアリング、デザイン、QAなど複数の職能(スキル)を持つことを表しています。
そして機能横断型という言葉は、チームに対して使われることが多いですが、個人に対しても使われます。(例: プロダクトエンジニアがデザインもできる、QAエンジニアがコードも書けるなど)

SmartHRにおいてチームが機能横断型であることは、LeSS文脈で使われるフィーチャーチームという言葉で浸透しています。
そのため、本記事ではクロスファンクショナルのことを「個人が機能横断型であること」の意味で書いています。

1年かけてクロスファンクショナルを推進した結果

Dチームでは約1年かけてクロスファンクショナルを推進してきました。
その結果を一枚の図にまとめてみました。 1年かけてクロスファンクショナルを推進した結果の図

複数色のアイコンは、1人が複数職能できるようになったことを表しています。
フィーチャーチームになりたての頃は1人1色でしたが、1年かけて複数色の人が増えました。

クロスファンクショナルのメリット

クロスファンクショナルのメリットは大きく4つあると感じています。

  • チーム内ボトルネックの解消
  • コミュニケーションコスト削減
  • 組織のスケールの柔軟性向上
  • より創発的になる

チーム内ボトルネックの解消

最も効果がわかりやすく、最初に得られるメリットがこのチーム内ボトルネックの解消になります。

フィーチャーチームになったとしても、ボトルネックはチーム内に存在します。
どうしても開発フローの中には特定の技能が必要な箇所が存在し、そこを担当できる人が限られているとボトルネックになります。
わかりやすい例で言うと、チーム内で受け入れテストをできる人が1人だけだった場合、プロダクトエンジニアがどれだけ早く実装を終えてもテストを実施できないため、リリースまでに時間がかかります。
ボトルネックになっている箇所を担当できる人を増やす(クロスファンクショナルになる)ことでボトルネックを解消でき、顧客に早く価値を届けられます。

まずフィーチャーチームはこのボトルネック解消を目標にクロスファンクショナルを推進していくのが良いと思います。

コミュニケーションコスト削減

フィーチャーチームを実践してみると感じるのが、コミュニケーションコストが高いことです。
最初はフィーチャーチームであるために、各職能1人以上のチーム構成になる必要がありました。
結果的にDチームは10人という大人数でスタートしました。
人数が増えたため、認識合わせなどのコミュニケーションコストが増大しました。

そこで各職能のクロスファンクショナルを推進し、その職能の人が常にチームにいなければいけない状態を脱しました。
結果として、一部のメンバーはコンポーネントメンター*2と呼ばれる関わり方になりました。
コンポーネントメンター体制の動きとしては、基本的に各職能は残ったチームメンバーで回しています。たまに難しいタスクがある場合には、コンポーネントメンターからアドバイスをもらい、時には協力して動く形で乗り越えています。また、その職能領域のカイゼンもチーム内で進めています。

組織のスケールの柔軟性向上

組織のスケールのため、新たにフィーチャーチームを増やすにはどうすればいいでしょうか?
シンプルに考えると、新たに各職能を1人以上採用する必要があります。 しかし、ほぼ同じタイミングで各職能を1人以上採用するのは非常に難しいことでした。
採用できない場合は、採用できるまで誰かが兼任するという手もあります。しかし兼務ではフィーチャーチームのメンバーとして使える時間が足りず、コンポーネント的に動かざるをえないので本末転倒になるという難しい問題があります。

基本機能では、この問題を先ほどのコンポーネントメンターで解消しました。
新たにできたFチームにフィーチャーチームのメンバーとして入り、Dチームにはコンポーネントメンターとして関わることで、両方ともフィーチャーチームとして成立させながらスケールできました。

注意点として、図だけだと兼任とあまり変わらないように見えますが、実際には兼任とは大きく異なります。
それは、チーム内でその職能領域をきちんと回せているためです。
兼任の場合、例えばデザインタスクがあったら、兼任してるデザイナーの手が空くまでブロックしてしまいます。しかし、Dチームでは基本的にデザインタスクもチーム内で完結できているため、ブロックしません。

より創発的になる

創発とは、部分の性質の単純な総和にとどまらない性質が、全体として現れることです。
要するに創発的なチームとは、1+1が2どころか200になるようなチーム、10倍だぞ10倍なチームのことです。
クロスファンクショナルが進んだチームは、より創発的になります。なぜなら画期的なアイデアは、異なる知と知の新たな組み合わせで生まれるからです。

フィーチャーチームで複数の職能の人が議論するだけでも創発的ではあります。しかし自分が詳しくない職能に関しては、他の専門の人の意見を信じるしかありません。
そして一つの職能を極めた人ほど、その経験に基づいたバイアスが掛かってしまいがちです。

しかし1人の人の中に複数の職能があると、多角的な観点でものを見れ、バイアスを減らせます。
そして複数の職能視点による掛け算のアイデアが素早く出てきます。
クロスファンクショナルな人が多いチームほど、掛け算が起こる機会が増え、創発的なチームへとなっていきます。

実際Dチームでも開発工数の少ないデザイン案や仕様といったアイデアが、PMやデザイナーに限らず活発に出るようになってきました。

どうクロスファンクショナルを推進したか?

それぞれの職能ごとに様々なストーリーがあったのですが、1つ言えることは、クロスファンクショナル推進に銀の弾丸はありません。
効果的な進め方は、職能特性やメンバーのコミュニケーションや学習のスタイルによって変わってきます。
そのため常に検査・適応を繰り返しながら、チームやメンバーに合うやり方を探る必要があります。

とはいえ自分の中で汎用的な進め方が確立されつつあるので、紹介します。

  1. 対象の職能がどういうものか?どういう仕事をしているのかをチームメンバーに教える
  2. チームメンバーに対して仕事内容を透明化する(スプリントバックログにタスクを表示する、デイリースクラムでやることを共有する etc)
  3. 対象の職能において、「何をどの程度学ぶとどういう状態までいけるのか」という成長の道筋を教える
  4. 対象の職能のタスクをモブやペアでチームメンバーと一緒にやってみる
  5. 慣れてきた人に1人でやらせ、成果物を各職能の人にレビューしてもらう
  6. レビュー自体もチームに移譲する
  7. 抜けても大丈夫そうなスクラムイベントは抜けてみる

7まで到達すると、実質スクラムチームの外にいる存在となります。
コンポーネントメンターになったケースは、7まで到達した後に完全にスクラムイベントから抜けた状態です。

クロスファンクショナルの注意点

クロスファンクショナルに関して、よく誤解されることが多いと感じる考え方を2つ紹介します。

全員が何でもできる人になる必要があるという誤解

全員が何でもできる人になる必要はありません。
まずはボトルネック解消をするだけでも大きな効果があります。
その先を目指すにしても、個人のキャリア観を尊重し、チームでの合意を取りながら少しずつ進めていきましょう。

また他職能の専門家になるわけではないので、その職能の仕事全てを1人で担当できるレベルまで学習する必要はありません。
モブデザインや全員で仕様を考えるなど、複数人で力を合わせる進め方の方がより創発的になります。

各々が専門性を発揮した方が早いという誤解

餅は餅屋の考え方で、各々が専門性を発揮した方が早いと考える人も多いかもしれません。
たしかに1つのタスクを消化する時間だけに注目すると、その分野に秀でた人がやれば局所的に早くなることもあります。
しかし顧客に価値が届くまでの全体の流れで見た場合、各タスクの間にコンテキストの共有のための時間や作業が必要になったり、実は部分最適になっているだけの工程が存在したりしています。
クロスファンクショナルを推進するとそのような工程が減り、全体としてはより早く顧客に価値を届けられます。

実際にDチームでどれだけ工程が短縮されたかをVSM(バリューストリームマッピング)を用いて見てみましょう。
クロスファンクショナル前後VSM比較

クロスファンクショナル後のVSMが短縮されています。
これは大きく2つのクロスファンクショナルの効果によるものです。

  • 長かった仕様策定・デザイン工程が、リファインメントに全て集約されました(リファインメントの時間で全員で仕様策定・モブデザインをしています)
  • テスト工程はチーム内で開発からQAへと受け渡しがありましたが、開発した人がテストもまとめて実施する方式に変わりました

工程が減ったため、合計のリードタイムも削減され、より早いリリースが可能になりました。

これらの改善は、クロスファンクショナルが進んだことで取れた選択肢です。

最後に

当然新しいことをするには学習コストがかかります。また、クロスファンクショナルによる効果を実感するまでにはある程度の時間がかかります。

しかし、こうして 1年を振り返ると多くの効果が実感できました。これだけのメリットを得られるのであれば、費用対効果は決して悪くないと思います。
顧客の価値に繋がるメリットが得られるため、引き続きクロスファンクショナルを推進しています。

そのためSmartHRでは、プロダクトエンジニアもエンジニアリングの領域にとらわれず、より幅広いプロダクト作りに携われます。
興味を持たれた方は、ぜひ一緒に価値あるプロダクトを作りましょう!

hello-world.smarthr.co.jp

*1:基本機能ではLeSS(Large Scale Scurm)を採用しており、A~Fの6チームが存在します

*2:SmartHRにおけるコンポーネントメンターは、特定の職能に関するチーム外のアドバイザー・協力者のような存在です。本来LeSS文脈では技術的なコンポーネントの先生役・レビュワーといった動きをする人のことを表しています。しかし他に適切な表現が見つからず、コンポーネントメンターで浸透しました。