[音楽]成功する味ある開発今回は大規模アジャイルについて説明をしたいと思いますプロジェクトが大規模になればなるほど難易度上がりますこれはアジャイル開発に限らずすべてのプロジェクトに言えることです
まず大規模になるなるほどその青黒難しくなるのは一人の人間が全てを把握するということは非常に難しくほとんどの場合は不可能です一人の人間が把握できるには限界がありますですのでチームを組んで
どう把握するかその把握の仕方の方法論によって様々なフレームワーク様々なメソッドというのがこれまでも開発されてきましたそしてそのフレイマークが目指す方向が大きく分けて二つに分かれます一つは
それでも一人の人間が何とか把握しようという情報を集約してすべての情報をすべての状態を把握しようという方に努力をして向かわせるという方法これが一つ目
もう一つは一人の人間が全てを把握するということは不可能である情報を集約するというのは限界があるなので情報を集約して全てを把握するなんていうことをしなくても有機的に
プロジェクトが結果的にうまくいそれらを目指すというこの数は彼ますもともとはこっちだったね回方法論が紆余曲折して現在ではこちらの方法論をとるといった形のそういった歴史的な経緯があったりするフレームワークもありますので今回は
どういったものが大規模開発でこの難易度を上げる要因なのかそして何を優先すればいいのかそういった観点から一体どの大規模アジャイル開発のフレームワークを選択すればいいのかというのを開設し
していきたいとおもいます早速ですけれどもこの大規模開発において何を優先するかというポイントカラー考えていきたいとおもいますまずはこのスケーラビリティというのを一番初めにおいてきました
初めから大規模にやろうと意気込んでプロジェクトを開始していきなり大規模に作り始めるということも大規模プロジェクトを開始する時に起こりがちな傾向ですけれどもアジャイル開発においてはいきなり大規模にやろうというのはアンチパターンです
初めは小さくチームを組成して小さく作りながら結果的に大きくしていくインクリメンタルにしながらシステムが大きくなるとともにチームも大きくしていくそういった観点でありますのでこのスケーラビリティチームそのものもスケールできるのかどうか
あるいはチームそのものをスケールするということを求めるのかどうかですねですのでメンバーを追加したりチームを追加したりそういったことが容易なのかどうか方法論としてそれらを実現できるような方法論になっているのかというのがまず一つ目です
二つ目は対象となるビジネスドメインあるいはシステムが対象とする業務ですねこれらがどれぐらい変化するのか例えば業務のワークフローがどれくらい変化するのか求められる機能要件がどれぐらいのスピードで変化していくのか
そしてその変化は予測できるのかあれ全く予測でき予測できないカオスな状態なのかこの不確実性と変化速度これらに対してどれぐらい対応できるような
迅速なチームを組成する必要があるのかこれらが2つ目のポイントになりますそして3つめのポイントはその組織チームとして作り上げたその組織が
どのような意思決定手順を踏もうとするのかどのような意思決定手順に慣れているのかですねこれが3つ目のポイントになりますいきなりチームを組成するといっても本当に傭兵部隊のように様々な国さまざまな文化から寄せ集めてきてそして初めてそこで初顔合わせで
いきなりチームを作りましょうなんていうことは本当にごくまれだと思いますほとんどがかつて一緒に家働いたことのあるメンバーであったりあるいはもう一つの会社の中で旧来の意思決定メカニズムの中で育ってきた社員たちが
今からアジャイルをやりましょうという形で駆り出されるというケースが多いと思いますですので元々どういう意思決定プロセスの中で育ってきたのかというのはもう組み込まれていますそれらが組織文化として定着していますですのでそれらを優先するのかあるいはもう
そういった組織文化を全て捨ててしまってあらたら意思決定手順組織文化というのを作り上げるのかということをどれくらい重視するのか優先するの過程のがこの3番目ですアジェルに開発をしようと思った場合の人材これらはこの優秀なと書いてますけれどもどれくらいそのアジャイルに適合するのか
そういった人材をどれぐらい確保しやすいのかアジャイルな開発に興味を持つ魅力を感じるそしてそれに適合するというそういった人材目線から見た場合の今回のプロジェクトあるいはチーム組織
魅力的であればあるほど人材の確保は容易になりますしあと確保するための経路ですね人材にアクセスするだけの柔軟な採用経路を持っていれば考え確保する容易性は上がります半面日本の国\内の真相作業のように採用をしたいと動き出してから1年半後にようやく
採用ができるそして採用した人材もすぐにチームに入れられるものではなくて研修を2年3年やってからようやく現場で使いもなるんだといったようなことを考えているような家組織だればこの3番4番目の
このポイントというのはあまり優先が上がってこないと思いますですのでこの優秀な人材を確保するということをの容易性をどれぐらいプラウティをしてあげているのかによってこの4番目はチェックするポイントになってくると思いますここに戦略と組織というのが対立しやすいと書いてますけれども
戦略もこの組織も理想といえばどちらも優先するどちらも実現するというのが本当の理想ですけれどもスタート時点ではどちらかを優先せざるを得ないということが起こりえます戦略は組織に従うのかその逆ですね
組織は戦略に従うのかこれらは悩ましい問題でもありますけれども今回のこの私が説明している大規模アジャイルというテーマの中で本当によくよく考えないといけない問題でもあるんですけれどもこれらは元々組織論であっ
たりとか会社の経営論であったりするところでも触れる問題でありますからえ今回の味わえるダイバー jal の中ではこれらがかなり色濃く対立しやし合うような状況が発見できると思いますので
具体的にそれぞれのフレームはご説明巣の中で触れていきたいと思いますそれではですねこの大規模アジャイルのフレームワークについて大きく3パターンありますのでそれらを紹介していきたいとおもいます大きいわけでこの3パターンですけれどもそれぞれを比較した形でどういうところに
違いがあるかということを書き出しましたのでそれぞれのフレームワークを提唱している団体あるいは人物にとってみるとキーワードとして挙げている言葉違ったりしますただ私はこの場合それぞれを比較した上での特徴を出していますのでそういう意味でのどのプレーマークを
皆さんが提供すればいいかあるいは適用しようという判断の材料にすればいいかということと一つの参考として見ていただければと思いますまずは今日夕方これすですね一つの大きなバックログをそれぞれのチームで共有し合いながら作っていくというスタイルです
product あーが一人いてそしてその大きなバックログをプロジェクトオーナーがどんどん決めていくんですけれどもそのプロダクトバックログに追加するという作業だったりふぁい面としたりそういったのはそれぞれのチームが一斉に集まっていっにやっていく
というやり方ですこれは複数チームを大きなチームと扱いながら各イベントの通常のスクラムでやるチームでまとまってやるというイベントこれらを一度1チームでやってしまいそして各チームでもやるといったスタイルで行います
ですので大勢が一気に一堂に介して行きわーっとやってそしてまた各チームに持ち帰ってまた各チームではやるというスタイルんですねこの場合各チームが一度に返すような物理的な空間が必要だったりとかメンバーが揃わないといけないといった制約があったりあとはメンバーがあまりも増えすぎると収拾がつかなくなるといった不安茎捻転もこのフレームワークにはあります
ただ通常アジェルで開発をしようという場合にどれぐらいの規模のものを作ればいいのかというのが初めは全く分からないというのであればこういったこのレスから始めるというのは開発のプロセスを自分たちで体に染みつけるという意味としても初期導入としては
方法ではないかなと思いますあまりにも狛江かルールがありすぎるとそのルールを正しく守ろうとすることにばかり注意が行ってしまってproduct 良いプロダクトを作らなきゃいけないということはないがしろになってしまいますのでできる限りプロダクトにフォーカスするという意味ではこのレスと
いうのは非常にシンプルなフレームワークですので初期導入にとってみればとても良い選択肢ではないかなと思いますそして次が統制型ですねこれはまあ政府が代表的かなと思いますけれどもこのそれぞれのチームはスクラムでやりつつただ
統制を取るというところは計画道のように全体を把握してそしてリリースするというの計画を立てておいてそしてそのリリースをすればいいかどうかのジャッジをチームのよりも上の組織が
ジャッジをしていて実際のリリースというのを行っていくというスタイルになりますコンセプトとしては計画不動のいいところ計画を立てて全体を把握して情報を集約してそして昨日
製品を提供していくそのタイミングも全部あらかじめコントロールしておくといった計画道の良さとスクラム各チームが自律的に早く作っていくということを
良いとこ取りを目指したフレイマー君ですけれども厳密にはこの政府のモデルは純粋な味あるではありませんですのでこれは負0正を選択するときに一つのポイントとして考えて欲しいんですけれども
味れるとしてやる必要があるのかといった際にやジェルじゃなくてもいいという判断が入るのであればこの政府というのは選択肢の一つにありなりうると思いますですので基本的には計角度と変わりませんなので計画駆動でいいというジャッジをしたいんですけれども
ただ計画どうであれば計画道としてのさまざまなリスクがありますからそれらを多少軽減したいといった計画駆動でやりややリムつつもその計画道によるリスクを軽減するために少しスクラムを導入しましたアジャイルに行ってみましたというレベルの会
判断を下すのであればこの政府というのは選択肢に出てくるかなと思いますそしてへこの3つ目のこのフラクタル方これは小さなスクラムもチームをさらに
中心にまとめるスクラムオブスクラムストーンをつくってそしてさらに真ん中にそのまたさらに上位ですねスクラムオブスクラムオブスクラムずというのを作っていくといった形でa
それぞれがそれぞれとしてスクラムなんですけれどもさらにそれをもう一つ上位で見ればさらにそれもスクラムチームであるつかのチームであるといったまさしく自己組織化ですねこれをこの代表的なものとしてはスクラム at スケールというもともとバスクーパー s クラブを提唱した団体が
この形を推進してますけれども特徴としては最初のマネジメント組織をくっつけていくあるいは新しくチームをつくるといった際にはマネジメントが必要です
なのでそのマネジメントを行き過ぎないレベルで有益なレベルで留めておくそしてそのこの発想フラクタルである発想というのは私たちの細胞であったり生物であったりあるいは社会であったりといったような脳神経科学neuroscience がベースになっているような考え方です
はっきりと明言しているかどうかは別としても私から見てみるとこのフラクタルな形は全体を把握するということに重点を置くのではなくて以下に使える意思決定をしていくかということを重点を置いていますなので全体をすべて詳細にまでし知らなきゃいけない統制を取らなきゃいけないといったことはそもそも優先順位が食べないだろうと
重要なのはユーザーにとって価値のあるシステムを提供しそしてそのシステムが勇気かどうかであるそしてこの中で実際に働いているメンバーたちが幸福感を感じながら自分たちは有益なものを作っているという意義を感じられるのかどうかこちらの方が重要であると
なので統制を取らなきゃいけないすべての情報を知っている人が神のような存在がいないといけないということをそもそも必要としないという発想ですね私は私は非常にこのフラクタル方の巣クラマーとスケールのコンセプトを考え方というのは
様々な面で有益な考え方じゃないかなと思いますただ難易度の順番でいくとこの3つこの並べた順番の中ではもっとも難易度高いですセイコー製のない方がいん高いですなぜかというといくつかの条件が揃わないというと難しいんですねなのでいきなりこのスクール
マットスケールをはじめからやりましょうとやるよりはまずは確実に一つずつスクラムチーンを機能するような形を作りながらそしてチームとして追加していくとしてやりながら
さらにスケールしたいスケールしなきゃいけないというタイミングでどれにしようと迷った場合に自分たちのチームがそれに耐えるチームになってきているという自信があればスクラムとスケールを採用するあるいはそこまでないなぁでも人はも必要だなぁスケールしないできないなぁ
だったら別にしようあるいは基本的には対象とするドメインはそんなに変わらないそしてユーザーは要望もそんなに大きなものが変更がないと既存のレガシーシステムで十分に機能は網羅されているのでそれがを端に置き換える
だけなんだとそうあれば政府音を採用するそういった判断をスケールするタイミングで決めてもいいかなと思いますあらかじめフレームワークありきでどういうものをしようと考えるよりも自分たちの葬式を優先してその組織に対してどの戦略をとるか
ってやるほうが私はごく自然な方法かなと思いますそういう意味では組織スタート時点では戦略は組織に従うべきかなと思うんですけれどもただ遠い未来を考えるんであれば戦略に対して組織が従うようにというふうに組織も変更させていくという形でそれらを交互に繰り返しながら
目指すべき形にしていくのがいいんじゃないかなと思いますそういう意味では本当に長期的にみるのであれば私は最終的にはこのスクラマットスケールが最も有益で最もいるものが大多いんじゃないかなと思いますでこれらの
この負0正口の中で特に混まないとが高いと言いましたこのスクラットスケールが難易度が高い理由とそしてそれを成功させるために入ってどうすればいいかこの規模になるポイントはスクラムマスターの存在ですそしてこのスクラムました様々なプロジェクトさまざまな組織に誤解されて部と私は
よく感じるんですけれどもscala もましたーーーをまずスクラムマスターがすべき仕事に選任させてくださいスクラムマスターのスクラムましたしかできない仕事をスクラムマスターだからできる仕事は何かというと
コーチングですコーチング2000円コーチングの専門家に刺すすることができるかどうかですね決してスクラムマスターは意思決定おかわりする人ではありません雑用する人でもありませんそして遠慮をして皆さんの意見をただ聞くだけ
という人でもありませんそして各メンバーに指示を出すという人でもありませんスクランますとはメンバーでありながらメンバーと少し話だ視点を持つ必要がありますそういう意味では最も組織チームを広く外側から眺める
それに宣言させないといけない立場ですですから観察をするという役割をスクラムマスター担う必要がありますそのスクランましたがなんかちょっと手が空いていそうだなということで何かと圧をたくさん押し付けたりあるいはスクラムますと自身もメンバーにやらせ悪いなと思って率先的に
例えば開発環境を代わりにセットアップしてあげたりとか開発者がいい必要そうな資料をまとめてあげて撃っ手元に持っていってあげたりとかですねあるいは勉強のためにこういうものを知っておいた方がいいというのは赤字にリストアップしてあげて
品を提供したりなんてことはしなくていいですそれは高抵抗値が入るべき仕事ではありませんスクランバスターが本来の仕事ではありませんなので一時的にやるというだけ落としてやる分が良いと思いますけれどもそれらがスクラムマスターの仕事だと思ってやってしまうようなことというのは結果的には
スクラマットスケールを実現するうえでのスクラムマスターが肝になるってポイントこれらを実現することになりませんので猪飼スクラムマスターがスクラムマスターとしての続続石ですねを果たせるかにかかってきますのでまた何処が次回以降でジャギースクラムはしたというのはどのようなスキルどのような
立ち位置どのような振る舞いをすればいいのかというふうに関しても解説をしていきたいとおもいます