LeSS（Large Scale Scrum）のフィードバック会が行われました。

はじめに

会社の先輩にLeSSのCertifiedを持っている方がいて、その先輩がLeSSの研修会に参加されたそうで、そのフィードバックを社内で行っていただいた。 LeSSとはLarge-Scale Scrumの省略で、Scrum開発を大規模に拡張したフレームワークのこと。通常のScrum開発との違いはこう。

Scurm

• チームは1つ
• 最小単位は個人
• チームが解散する可能性がある

LeSS

• チームが2～8つ
• 最小単位はチーム
• チームの解散はしない　※ただし、メンバーの入れ替えはある

共通点は、あくまでScrum開発であること、プロダクトバックログは1つ、プロダクトオーナー（以下、PO）も1人。 ※LeSSをさらに拡張したLeSS Hugeというフレームワークも存在するが、後ほど構成だけ説明。

こっから実際に社内で話された内容を書いていくべ |^・ω・)/

組織で目標を共有する

最初のテーマは、「目標を共有する」ことの大事さについて。

○ワークショップ：ある時自分の会社が理想的な会社になりました

まず参加者全員で、「もし自分たちの会社が最高の会社になった」ことを想像する。 それがどんな会社か、具体的に思いつく限り付箋に書き出した。（例：最低でも月給が手取りで50万円以上、家賃全額支給、備品・機器は無制限に支給） そっから物理的に不可能なものを除く。

できたリストが自分たちの会社が理想的な会社になるための課題。これに優先順位をつけ、会社の売り上げ目標を考慮した上でどれくらいで達成できるか、そのために何をする必要があるかなど、具体的に計算する。 そうすると現実的に見えてくるので、メンバーも頑張ろうという気が起きる。（モチベーションアップ！）これが重要で、組織運営していくための重要なキーワードだと思う。

○会社の短期的・長期的な目標、そのために自分がすべきこと

これを把握しているメンバーが社内にどれだけいるか？（うちの会社はほとんどいなかった）

• 従業員レベルでは把握している人はなかなかいない
• だからモチベーションが上げにくい
• 社長に聞けば答えてくれるかもしれない
• だから、最初のワークショップが必要かつ重要
  • ワークショップで挙がった内容が達成できれば理想の会社になる！
  • 従業員もモチベーションが出る！
• まずは目標を持つこと
• そのために必要なことを各自が理解・把握する
• そのために何をすべきか考えるようになる
• 会社としても、いい会社にすることリストができ、その優先順位もつけられる
• メンバーもアクションを起こすようになる
• 働くのが楽しくなる

つまり、「メンバー1人1人が目標を持つこと」が理想的な会社になるための最低条件である。 会社はそうするために何が必要か？どうすればいいか？を考えていくことが大事。 そういうことが相談できる、またいくらでも「こうしたい！」って言えて、それを前向きにとらえてくれる環境を作っていくことが大事。

Large-Scale Scrumとは

次のテーマはLeSSについて。「はじめに」でも書いたが、改めてLeSSとはどういうフレームワークなのかを説明。

○構成

基本的にScrumは1チームで構成されていることが前提。 LeSSはこれを規模拡張したもの。 具体的には、チームが複数存在

• LeSS: チームが2〜8チームまで
• LeSS Huge: それ以上（数千人単位）
  • POの下にArea Product Ownerが存在し、その下にチームがぶら下がる
  • プロダクトバックログはPOに一個存在

○LeSSの進め方

ここはちょっと曖昧なので、随時更新していきます。

• スプリントプランニングは2回に分けて行う
  • 1は各チームの代表とPOで行う
  • 2は各チーム内で行う
• デイリースクラムは各チーム毎に行う
• プロダクトバックログリファインメント
• スプリントレビューは各チーム毎に行う
• スプリントレトロスペクティブは各チーム毎に行う
  • いろんなチームをごちゃ混ぜにして行う
• オーバーオールレトロスペクティブは代表者が集まって行う
  • 代表者は交代制で行う

○Certifiedについて

Certified（認定）という制度がある。3日間の研修を受けて、試験に合格すれば認定される。 日本のCertifiedは約34万人で、日本のScrum開発はまだまだこれから。

LeSSのCertifiedは、LeSSそのものができて2年くらいなので世界で900人ほど。日本では30人ほど。 しかし研修内容は思った以上に勉強になるそうで、自分の中で暗黙知になっていたことがちゃんと言葉で表現されるため、 本当に勉強になるらしい。もし興味がある人は是非。

チームで働く事

次のテーマは「チーム」について。LeSSではとにかくチームに重きが置かれているため、このテーマが1番分厚く、先輩も1番語りたかった内容だったらしい。

○個人の力でなんとかなるなら組織は不要

そのままの意味。会社で守ってくれているものはあるが、自分でもできるよな、くらいのレベル。

もちろん個人の力を軽視するわけではないが、誰かと仕事をすればできる事はたくさんある。
例えばもっと大きな事ができるかもしれない。自分ができない事が他の人にはできるかもしれない。 また、個人だと本来やりたかったことが、他の作業でできないこともある。（例えば契約周りや決算時の諸手続きなど）

そういう意味もあって、組織で仕事をする意味と大事さを把握する。ちゃんと協力してやっていこう。

○コンポーネントチーム＆フィーチャーチーム

コンポーネントチーム

従来よくあるチーム。会社で例えると、開発チーム・営業・インフラチーム・情報システム部など。
専門メンバーで組織されるチーム。

こちらだと、ウォーターフォールになりがち！

フィーチャーチーム

いわゆるなんでもできるメンバーで組織。
そのチームに任せれば、頭からケツまでなんでもできるチーム。
　→LeSSではこっちのチームを作りたい！

Q.　どんなチームがフィーチャーチームか？

なんでもできるチーム・人達にはある特徴がある。
「例えば、お客さんは自分の言葉で説明してくるが、そういうお客さんの言葉を理解し、 お客さんの言葉で自分たちのシステム・やることを説明できる。」

A.　お客の言葉で話しができる人達・チーム

○リソースの話

Scrumでは個人がリソース。LeSSでは、チームがリソースであり最小単位。だから、チームは（未来でも）解散しない。 ただ、チーム内の人の移り変わりはある。

Q.　なぜ「チームをリソースにしている」のか？
A.　LeSSでは、チームをすごく大切にしている。従来の管理型企業では個人を重要視している。 そうすると、例えば出世とかで個人で差が出てくる可能性が出てくる。それでは最高のチームを作ることはできない。

○チームを作る時に注意すること

理想のチームを作りたいが、パフォーマンス100%出すチームはなかなか作れない。 そのため、まずは技術よりも業務・ビジネスについてノウハウを持っている人を先に雇う。

なぜなら技術はある意味で簡単に学べる。極論本読めばいい。 しかし、ビジネス・業務能力はなかなか身につかない。 だから先にこう言うスキルが身についている人を揃えた方がいい。

○チームに仕事を割り当てる

従来の企業では、仕事のためにチームを作ることが多い。 何かプロジェクトがスタートするから、人を集めてチームを作って走る。これではチームとして熟成するころには、 プロジェクトはかなり進んでいるか、終了している。チームが熟成するには時間がかかる。

しかし最高のチームを作っていれば、そのハイパフォーマンスのチームにこういう仕事を割り当てれば、ハイパフォーマンスで仕事を回せる。

○効率よく作業するには

リファイメントをちゃんとやることが重要。次にやるスプリントを明確化する。 そうすれば、明日から何をやるかはっきりしていて、ゴールも見えていて、何をするかが分かっている状態にできる。

また、各タスクに難易度はあるが、タスクはビジネス上価値があることを先にやる。 手広くやらない！シングルスレッドで走る。 とにかく早く回し、先に失敗し、何度も何度も立ち直り、早く成長する。

定例会はやめた方がいい。例えば失敗した時に、その定例まで先延ばしにしがちになる。 だから、調整は何か問題が発生した時点ですぐに調整する。定例会で調整するのであれば、すぐに電話して怒られる方がまだいい。

○トラベラー＆コンポーネントメンター

この2つはの考え方はすごく面白い！特にトラベラーは日本にはない考え方。

トラベラー

チームに大抵一人はもの凄い能力の人がいる。チームにはそういう人が欲しい。 こういう人をあえてチームに所属させない。トラベラーとは、スプリントごとに、そのスペックの高い人が選んで、 そのチームに参加する。ただし、チームが合意したら参加する形。各チームとしては、メンバーも引き上げられるし、 トラベラーとしても働きやすいところで働くので、相乗効果。

コンポーネントメンター

いわゆる先生。専門的な人。「困ったら〇〇さんに聞いて。」と言える人。
海外では何人かのコンポーネントメンターを集めて質問会を開き、そこに集まった人に「今回話したいこと」を付箋に書かせて、 それを持ってそのメンターのところに行って話をする、という会を開いているらしい。

○LeSSのレビュー

スプリントレビューの事。POに見せるのではなく、ステークホルダーの人達にバザー形式で見せる。 いわゆるカンファレンスのブースみたいなことをやる。そうすれば忌憚なく意見が出てくるので、とても良い意見が出やすい。

日本に良くある机を挟んだ会議ではなかなか意見が出てこないし、全員が参加するのは難しい。

無駄をなくす

タイトル通り、次のテーマは「いかに無駄をなくすか」。

○プロダクトを知る

Q.　プロダクトを一番よく知る人は誰か？
A.　「そのプロダクトを使うお客さん」である。

○プロジェクトの後片付け

プロジェクトの後片付けが無駄。そもそもプロジェクトを作ること自体が無駄。 あるメンバーがプロジェクトを移る時、必ず引き継ぎをしないといけない。 それだけでかなりの工数が取られる。（3ヶ月の工数見積もりでも、実質2ヶ月しかなかったりする）

○契約ゲーム

約束駆動の仕事は無駄。当事者じゃない人達（良くあるのが営業）が勝手に話進めたものを、よろしくって渡すな。 勝手に「何ヶ月でできるだろ。」と見積もってくるが、その人にはできてもアサインした人ができるとは限らない。

○形式だけの会議・ミーティング

形にこだわる会議は意味がない。何の目的で、どうしたいのか、どういう理由で誰を呼ぶのか、ちゃんと把握して臨む。 また、できるだけMTGは少ない方がいい。極論ない方がいい。

LeSSのレビューでも書いたが、テーブルを囲んでの会議より、ワークショップの方がよっぽどいい意見が出る。

不安のタネ

次のテーマは「不安のタネ」について。

ほとんどのものは、内容が理解ができていないか予想ができないから。これを解消すれば、大抵不安のタネはなくなる。

銀の弾丸

最後のテーマ。「銀の弾丸」。
いろんなところで話が出るが、そんなものはない！しかし、問題解決のコツはある！！

諸問題のほとんどは人が絡んでいる。だから、口を使う。ちゃんと伝える。ちゃんと話す。 どんな些細なことでもいいので、しっかり話さないと、クリアにならない。

おわりに

今回のフィードバックを受けて、本当にチームを作る大事さを感じた。 そして、改めてウォーターフォールではうまくいかないとも思った。 お客さん、開発側、双方がwin-winになるには良いチームを作っていくことだと思う。

個人によっては、理想のチーム像が異なるかもしれない。それさえもしっかり共有し、一緒にやっていきたい、 と思えるメンバーと仕事できたら、最高のパフォーマンスが出るだろう。 そういうチームを作るためには何が必要か、全員で考え続けいける環境があれば、自然と最高の職場になるだろう。