量を質に転換させることを常に考えている。
例えばエンジニアの中には、自身のコードが綺麗ではないことを理由に人に見せることを避けようとする人がいるが、綺麗なコードとは何か考えてみてほしい。料理になぞらえると、料理を綺麗にしようと思うと、人に食べさせるために何度も練習する。料理本を見て、一つなぞらえて終わりではなく、何度も練習する。同じように、綺麗なコードというのは何度も繰り返すことで身につくようになる。繰り返す量を増やすことで質が向上するようになる。
後はポジティブになること。生産性が高いのはポジティブな時。それを実現するのがマネジメントでもある。
マネジメントできる数は1on1できる人数だと思っている。各メンバーに寄り添えるメンバー数でしかマネジメント出来ない。今、50人ほどいるがキツくなっている。色々と委譲していくことで改善しようとしている。ヤフーの1on1はバイブルのように読んでいる。

小賀さん

常に現在の能力をわずかに上回る課題に挑戦し続けるようにしている。
超一流になるのは才能か努力か?という本がある。おすすめ。才能は先天的か後天的かということだが、この本に書いてある一説でもある。人はストレスのないことをやっても、それ以上は伸びない。届きもしないことをやっても時間がかかりすぎて良くないので、わずかに上回ることが大事。それがストレスなくクリアできるようになれば良い。
周囲を見渡していると、新しいことにチャレンジする機会を持てていないことは普通に起きているように見えるので、チャレンジはしていってほしい。

明石さん

興味の深度が深いものや、目的意識の明確なこと・ものについて、より理解を深めるようにしている。
学ぶことが目的になった勉強は頭に入らない。基本は興味と目的意識が明確なことについて理解をふかめるやり方で進めている。
自分の理解を自分の言葉、文字にできるのは大事だと思う。ただ面倒なのでやらないけどw

会社または組織として新しいことを学習する際、どのようにしているのでしょうか？

藤川さん

やる気のある人を重視し、先に進んでもらってから全体に広めていくやり方をしている。
フロントエンド系技術は進化が早い。とあるタイミングでは作り直さないといけないかもと考えている。そういった進化にはついていかないといけないが、残念ながらついてこれない人もでてくるだろうと、覚悟して取り組みを進めている。

明石さん

目指す到達点と自分たちがどこにいるかを可視化するようにしている。
学びは終わらない。組織で学ぶ時は結果どうありたいかが大事。ゴール設定して自分たちがどこにいるかの目線を合わせることから可視化して始めるようにしている。
急激な変化にも適応できるチームであり続ける。変化に適応できるチームでないといけない。AWSが良い例。あのようなものが出てきた際に、必要かどうか試し、失敗し、学んで取り入れることができるかが大事。
学ぶは目的ではない。学んでスキルに転化し、発揮できるか、ということが大事。

CTOの皆さんは企業規模、組織のフェーズが違うが、フェーズに応じて学習のやり方が違う、アプローチが違うなどあるのでしょうか？

小賀さん

チームで学んだことを共有することを大事にしている。
エンジニア1000人は無理、100人も無理。小さく分割してチームでの学びを共有するようにしている。
新しいことをするのにR&Dを作るより、チームの中で変化に適応できるようにチャレンジして失敗して学べるようにしている。

大きな企業で新卒として優秀でも、スタートアップだとそうはならない。規模が大きいから共通部分がリーズナブルにできるが、小さい規模だと職種を超えてやらないといけない。そのやり方をわかっていない人をたまに見かける。

明石さん

規模によって違うということはなく、課題によって違う。
ベンチャーでも大企業病のような課題があるところもある。その逆も。
課題設定の中で学習、成長というキーワードを取り込んでいくことが大事だと思う。組織は常に変化して成長しないといけない。変化しない組織は大企業病になる。営業、企画チームと分けると数年で組織体として固まり、変化が悪くなる。

ベンチャースピリットが失われているという課題についてどのように考えますか？

藤川さん

一度壊す、ということをやる。
守らないといけない責任を守り続けるがために変化を抑制する方向に進む。変化できないのは組織構造の問題がある。パラダイムが変化しても、経営側が変化を抑制している。
そういったことをなるべく壊すようにした方が良い。
しがらみがないところに移って経験してから戻ってくるというやり方も良い。M&Aを通じて新エネルギーを得るプロセスは日本でも回ってきているように思う。

小賀さん

リスクをちゃんと見て、一線を超えるとマズイというリスクだけ押さえるようにすれば良い。それだけを隔離して、それ以外は自由に動けるようにすることはできるはず。
会社、事業が大きくなり、ステークホルダーが増えると守ることも増える。それは隔離して、大部分の人が自由に動けるところは作れるはず。

明石さん

新しいことを始めても今のビジネスに影響を与えることはないはずなのに、ぐるぐると考えているように見える。治外法権を作ることは大事。大企業は失敗しても戻れる場所があるが、スタートアップは無いので違いは出てくる。

これからをになう技術者、クリエーターに何をどう学んでいくべきかコメントをお願いします。

藤川さん

技術習得に対する楽しさ、ワクワクを失わないようにしてください。
分かったつもりにならない。数年前に見たことがある、ということで判断せず、今の時代になぜ必要とされているかを考え、フラットに受け止めてあげるようにしてください。数年前は失敗だったとしても、同じ失敗をしないかもしれない、それをカバーできる人もいるはずなので。
技術というのは、誰かが作り、賛同者が多いことで普及する。科学技術のすごいものではなく、皆が使っているからエンジニアリングが成り立つ。

明石さん

自分のコアとなる技術をきちんと身につけるようにしてください。
専門性が何かを意識して深度を深める、横に広げる、ということを心がけるのが良いと思います。
自分自身がこの考え方で助かったといいうのもある。専門職を名乗るならエンジニアと言うのではなく、何の専門職かを語れるようになった方が良い。

小賀さん

変化は追いかけたいが、変化のスピード、ペースが違うものは意識した方が良い。
AWSの変化は早い。フロント系技術の変化も早い。
一方でLinux、リレーショナルDB、プロトコルのように長く使えるものもある。
変化に追従しつつも、長く使い続けられているものをきちんと見て自分の強み、弱みを見ることが大事だと思う。

参加しての感想

全体を振り返って思うのは、CTOとしての課題、取り組みは違えど、「学び」という観点では中心にある考え方や大事にしようとされていることは皆さん同じなんだろうな、ということです。
学び続けないといけない、変化に追従しないといけない、明確なゴール、目的を持って突き進まないといけない、ということはあると思いますが、基本的に皆さん楽しそうに話されているのを見て、何事も楽しむようにされているのだろうと感じています。
CTOまでの道のりは楽なものではなかったと想像していますが、苦難を楽しめるようにしてきたからこそ、多くのことを学び、成長に繋がったんだろうとパネルディスカッションを通じて感じることでした。
その昔、「勉強」というのは娯楽だったそうです。一部の富裕層だけに認められた娯楽で、それ以外の人々は生きるために働かなければならなかった。学ぶための手段は勉強だけではありませんが、学びそのものが楽しいことであることにも納得感を感じています。学ぶことは楽しいです。その楽しみを得たいがために学ぶ。そういったことを繰り返すとでエンジニアライフも豊かになっていくのだと思います。

最後に、CTO Night Kansaiを開催頂いた主催者の皆さま、登壇された皆さま、貴重な機会を頂きありがとうございました。毎期開催されているとのことですが、次回も是非参加させて頂きます！

2019-02-11

大規模スクラム [感想・レビュー!] LeSS (Large-Scale Scrum) はただのスクラムと考えれば良い

LeSS スクラム Scrum

2019年1月30日に発売された大規模スクラムーアジャイルとスクラムを大規模に実装する方法ーを読むことでLeSSの理解がかなり進みました。また、疑問に思っていたことにもきっちり答えてくれているので、LeSSをこれから学ぼうとする方には是非オススメしたい一冊です。

そもそもLeSSとは

スクラムをスケーリングする際のアプローチとしてSAFe、Nexus、DADとともに紹介されるフレームワークの１つ。Large-Scale Scrumを略してLeSSと呼ばれる。以下の図はLeSSを表すイメージ図です。

https://less.works より

LeSSについて疑問に思っていたこと

スクラムとしての理解はスクラムガイドやエッセンシャルスクラムを読んで理解を深めていましたが、スクラムをスケーリングする際のフレームワークの１つであるLeSSについては、イマイチよく分かっていませんでした。というより、この本を読むまで全くと言って良いほど何も分かっておらず、なんとなく疑問に思っていたことは以下のようなハテナの連鎖でした。

大規模スクラムということだから、スクラムを階層構造にしたものではないか？
プロダクトオーナーを階層化して組織化するのか？
スクラムマスターは階層化できるのか？メインのスクラムマスターが必要なのか？
チームはどのような単位に分割されるのか？
マネージャーの役割は？

読んで最初に驚いたのは、この疑問のほとんどは本の前半で解消されたということ。また、作者の実験と経験から裏付けられた非常に説得力のある内容になっています。

1. 大規模スクラムということだから、スクラムを階層構造にしたものではないか？

まったく違いました。読み始めて8ページ目で理解できました。 LeSSは新しいスクラムでは無く、改善版でもない。「スクラムの原理・原則、ルールなどを大規模開発の文脈に可能な限りシンプルに適応したもの」とされています。スクラムガイドラインの素晴らしいところがまさに現れているポイントだと思います。ガイドラインは非常にシンプルかつ、理解しやすい内容になっています。それはつまり「抽象的」であるからだと思います。抽象的だからこそ大規模開発にも適応できる、というのがLeSSを理解することで分かってきます。つまり、LeSSを理解する前に、スクラムを理解しておくのが近道と言えるのでは無いでしょうか。（エッセンシャルスクラムは必読だと個人的には感じています。）

2. プロダクトオーナーを階層化して組織化するのか？

これも違いました。9ページ目に説明されています。 1つのバックログ、1人のプロダクトオーナー、1つの出荷可能なプロダクト、1つのスプリントと定義されています。スクラムそのままですね。

3. スクラムマスターは階層化できるのか？メインのスクラムマスターが必要なのか？

当然、これも違うということがわかります。 LeSSはスクラムなので、階層はありません。全てフラットな関係性です。その中でスクラムマスターの責任も大きく変わりません。サーバントリーダーとして、スクラムプロセスの番人としての役割を担います。通常のスクラムと異なる点として、1〜3チームに1人のスクラムマスターを配置するようです。また、大規模開発に導入するにあたり、時間の経過とともに重視するポイントが変わることも書かれており、なるほどと思わされます。
初期段階では

プロダクトオーナー
開発チーム
組織
技術手法

の順番。
時間が経過してくると

組織
技術手法
プロダクトオーナー
開発チーム

になります。これは、スクラムチームが自己組織化されることでチームへの優先度が下がることを意味していますが、これをさらに加速するためには組織の構造、ポリシーを改善しない限りは頭打ちになるということのようです。通常のスクラムと比べるとスクラムマスターの行動範囲はより大きくなるように思います。

4. チームはどのような単位に分割されるのか？

スクラムで開発チームは「クロスファンクショナル」、つまりプロダクト開発を進めるために必要なスキルを全て持ち合わせているチームであるべきとされています。それを大規模開発に当てはめた場合、どのようにチーム分割するのでしょうか。 LeSSでは「顧客価値中心」でクロスファンクショナルなチームとされています。比較対象としてあげられているのが「コンポーネントチーム」です。コンポーネントチームは価値よりアウトプット量への注力であり、顧客価値に直結していません。これはスクラムの目的に反します。顧客価値中心であるフィーチャーチームを優先することで、受け渡しの無駄を除去し、作業がより価値の高いものにできる。
これ以上綺麗な分け方はないですね。

5. マネージャーの役割は？

スクラムではコントロール型マネージャーの存在は良しとされていないように、LeSSでも同じです。ただ、マネージャーを不要とするのではなく、「任意」としています。もし今いないのであれば、無理に作る必要もないとのことです。従来組織のマネージャーの役割、責任はプロダクトオーナーと開発チームに委譲されるべきで、そうすることにより自己組織化が促進されます。その状態でマネージャーが担うべき重要な役割は何になるのでしょうか。それは「改善する能力の向上および必要となる組織変更の支援」となります。スクラムマスターやチームでは超えることのできない組織の壁をマネージャーが支援することで超えていきます。チームが一段上のパフォーマンスを出すためには組織の壁が重荷となることがあります。それを越えるために支援するのがマネージャーの役割となります。では、そのためにマネージャーに求められるスキルとは何になるかが疑問となります。それに対しては「現地現物」であると答えてくれています。現地現物とは、「習慣的に現場に行き、実際の問題を真に理解し、組織向上に生かす」ことです。現場で問題の分析は行わず、問題の原因に迫る偏見のない質問をすることが求められています。もしマネージャーの責任として問題解決が課せられている組織の場合、このスキルを発揮する難易度は高いかもしれません。

所管

LeSSの概念としてはスクラムとなんら変わらないと理解して問題なさそうですが、大規模開発に適合できるように「全体スプリント計画」と「全体振り返り」がスプリントの最初と最後で行うようになっています。個別チームとしてはスクラムを廻しつつ、複数チームでプロダクト全体の透明性、検証、適合を維持するための考え抜かれた工夫を感じ取ることができます。概念を理解すれば、あとは実践しながら、学びながら改善していくことで、自分の組織にあったフレームワークへと変化させていくのが良いと思います。

最後に

スクラムを理解することは簡単でも、実践するのが難しいのと同様で、LeSSの実践の難しさは計り知れないと感じています。それは、組織変更を行なうに等しいためです。そこで一番苦労することになるのがスクラムマスターだと思いますが、書籍の中ではスクラムマスターのサバイバルガイドの1つとして「正気を保つ」をあげています。「忍耐と低い期待」「永続性」「勇気」「ユーモアのセンス」「寛容と謙虚」がその構成要素です。言葉の意味するところの解釈は人それぞれかもしれませんが、書籍の説明を読み進め、解釈することで複雑な世界を生き抜くヒントとなるのかもしれません。