[音楽]背コースラージャる開発今回はアジャイル度チェックについて説明したいと思いますここに来てあの今まで多くの葉茶ようについて解説方がを上げてきましたけれども
アジェルといって方一つの形だけを行えば良いというものではありませんしあとバスそのチーム阿部組織あるいはプロダクト言うユーザー環境ビジネス環境をそういったものをに応じてやり方を少し変えていったり嬢たちなりに色々アレンジを加えたりということもしていくと思いますそんな中で
徒会という形式もう本質これをきちんと理解して仕組みの中に取り入れてでうまくやっていくということを考えた場合にどれぐらいいいその今のチームの取り組み方がアジャイルなのかといったってチェックシートみたいなものですね結構多くまあこれらについて今日は
解説してみたいと思いますで a ここに反復していればアジャイルなのではないと書きましたが私は本当にたくさんいろんなプロジェクトに入って見てきましたけれども一番初めにやはり一番誤解しやすいのが
計画不動型ウォーターフォールモデルというのは基本的に反復をしません計画を立てて要件提起をしてそこから見積もりをしたり次の工程にどんどんコーパスをしていくわけですけれども基本的にはもう前枚工程から後コーデに対してシーケンシャルに連続して行なっていく前から後ろあるいは上からした一方高なんですね
なのでアジャイルというのをやりましょうとなった場合ウォーターフォールモデルに対してアジャイルというこの2つの堆肥の仕方をしてしまうことによってアジャイルというのは反復するプロセスのことなんだと理解をしてしまいいいそれだけが残ってしまった場合ですねなのであっ
反復さえしていればジャイロなんだといった誤解を生みやすいそういった状況を私は何度も見てきましたなので自分たちはアジャイルをやってるんだけどと思っている状態を私なりに入って観察していくとそれは単に反復しているということだけであってそれ以外のことは全然アジャイルという基本的なコンセプトが
組いる組み入れられてないということがよくありますなので今回は反復以外のところに関してアジャイルというものが一体どういう本質を持っていてそれがどれぐらいそのチームあるいはそのプロジェクトが理解をして実践しているかといった視点でチェックできる
ような項目を並べてみましたではまず1つめは意思決定にかかる時間がどれぐらい長いのかどれくらい時間がかかっているのかというのをまずチェック項目の一番初めに入れましたここで意思決定というのは何も会議で議題があってそれを系ましょうという会議ミーティング設定が1時間あったら1時間で決めた
はことという意味というよりは一つの例えばユーザーストーリーについてそれをどのような仕様で決めるか開発するかといった議論が1ヶ月くらいかかってるみたいな状態のことを指したりa ここでは行っておりますa
中にをですね結衣あのいろんなあの意思決定にかかる時間が長いというまあバットケースはあるんですけれども典型的なバットケースとしてはスプリントの期間をですね通常も私が入ったプロジェクトでは最大で4週間というのがありました
で私がおすすめも話題で1週間とか2週間長くても2週間ですねですけれども実際にそのスプリントとして決められた枠組みが重要な6ではなくて意思決定としての1サイクルですねこれこの期間の方が重要ですなので形上はスプリントと区切られていても実は議論の対象と
て考えているサイズがですね3スプリントにもわたって実はずっと議論をしているっていうような状態だと形という形上はスプリントになって言ってもスプリントで切られていても実質中身をつながっていますなのでもし1スプリントが2週間で区切って家としても3スプリントにわたって議論してるんであればそれは1スプリントがえっ
2週間の3倍の6週間でやってるって言うよと同じ意味なんですねなので実際にはその意思決定にかかる時間をスプリントで区切ってそしてそのスプリントの中で決めてデリバーしてしまう作りきってしまうというのを最小単位とするというのを汗その単位と数というの枠組みが必要になってい
しますええまあよくあるケースですけれども1スプリントを4週間にしてはじめの1週間でスプリントプランニングをやって最後の1週間がレビューですとかですねとなると実際作っている期間
間の2週間だけで始める1週間はプランニングなのでどんなものを作ろうかあるいは見積もりはどうなるんだという機関が始めの一週間に当てられてしまってでその後開発をしてれっレビュー段階まで来ると開発が法令終わっていてどういうものかってチェックありが
テストそういったものがやらつですなされるようなきたんとし用意されていたりするわけですけれどもこの仕組みの問題点というのははじめの1週間で何を作るかと考えてやろうとする1週間を置いてしまったがゆえにここで話す内容というのはかなり溺れば増えるんですよね
1週間も時間があるので1週間でいろんなことを決めましょうとなってしまいがちですなが実際に作れるボリュームを超えた議論ができてしまうことが問題でもありそして実際に作れるボリュームは2週間しかないのでその1週間で議論した分が作れると限らないですよねすると
持ち越して次のスプリントでも次のスプリントでも作るようなかもしれないことを議論したりあるいはその2週間で作れないとなるとその2週間に作れる分だけを1週間かけて議論しちゃうみたいな無駄な議論が大生んでしまいますするとその場ですぐ決めて作ってすぐ決めて作ってということができなくなってはじめの
1週間目のスプリントプランニングの中でもう本当に詳細な仕様までがっちり決めてしまおうという流れが起こってしまいますこうなるともはや計画不動型ウォーターフォールモデルのちっちゃいサイクル番になってしまいますね
その時間の区切り方としてスプリントプランニングがそのスプリント機関全体の5分の1を超えているとかあるいは1週間まるまるねスプリントプランニングなってるみたいな状態になっているとちょっとへへこの石けって帰る時間が長すぎると判断してください
でここはなぜそんなにして一体かかるのかというのはいくつかの原因があると思いますまず意思決定できる人という m もがこの人と決めた場合のソモサチームの範囲が ok すぎる場合ですね
例えば複数チーム4チームで開発してますの時に最終意思決定者例えばこの機能をつけましょうと判断するプロダクトオーナーがその一つのチームのプロダクトオーナーとして意思決定をするという役割を1を与えられてはいるんですけれども実質的にはその4チームの上にいるプロジェクトオーナーのマネージャーのような
人が最終的な意思決定を実はしているとなので形的にはこの人それぞれの一つのチームのプロダクトなんか決めてもいいよあるいは決めなさいと1大きく形をなってるんですけれどもその後その上に立つプロダクトオーナーの意向で急にそれやつだめだとかあるいは何で
揃う ok 出したんだみたいなことを言ってしまってストップをかけるシーンがたびたび発生するとそのチームの中のプロダクトオーナ自分で決めることを嫌いますあるいは自分で決める前にもうプロダクトオーナーのの上の人間にされお伺いを立ててで ok が出たら決めようというそういったプロセスになるわけですねそっと実質
決めてるのはこの人になってしまうのでこの人がすべてを決めないといけないというふうにして意思決定けども送れるわけですね4キーもあると4チームそれぞれやプロダクトオーナーその場でどんどん君ていけばいいものを一つ一つに対してチェックを入れようとしてしまうという現象が起こりますなのでルールとしてプロダクトオーナが決めましょう決めて
いいですよではなくて実質的に今動いているプロジェクトの意思決定のメカニズムはどうなっているかのほうを重視してくださいなのでえっプロダクトオーナースプリントへスクラムの中どう
ユーザーストーリー関してもあるいは a官僚の定義にしてもプロダクトオーナーがジャッジをどんどんしていくという間の1ルールにはなってますけれどもそれがちゃんと運用されているのが適用されているのかというところにチェックの目を光らせてみてください
それが意思決定にかかる時間応報にお暮らしているということであればその意思決定の仕方その後を修正する人がありますしなぜそのような意識ってなってしまったのかというところに対して議論をした方がいいです次に仕事の枠組みの有無これはの
別の動画で説明しましたがワーキング agreement なことですねまあなどでワーキング agreement という名前で用意してなくてもいいんですけれども何らかの自分達の仕事の進め方仕事のあり方というものについて言及されたもの枠組みがあるのかどうかそしてそれ
を改善するというプロセスがあるのかどうかこれらのスクラムデイトレードするretrospective ですね自分たちがしている仕事も進め方仕事のあり方そのものを改善しましょうと言うretrospective 自体があるのかどうかというのをチェックしてみてください
開発スクール6開発の中だとスプリントプランニングとスプリントレビューに関してはそれをなしにするというプロジェクトは今の道路私は見たことがありませんすべてのプロジェクトがスプリントプランニングをやってスプリントレビューをやってましたただワーキング agreement とレトロスペクティブがないという
プロジェクトは結構ありますでワーキング agreement というのはスクラムの中では特に規定されていたりする言及されておりませんなので別になくてもいいじゃなくても良いと思いがちですけれども私はワーキングが売り面とという名前のものが無くてもですね
同様に自分達の仕事の枠組みを決めるのかどういうスタイルでやるのかというたものに対して議論をしてそして自分たちで決めてそれを改善するレトロスペクティブというものがある必要があると考えていますそもそもこれがなければ意思決定にかかっている時間に対してなんでこんないぃしけて時間かかってるんだろうと見直すというきっかけすらもなくなってしまいますね
プロジェクトがどんどん遅れたりダメには均質がダメになっていくという現状に対して何が問題なんだと立ち止まって考えるそういった場がないんですねなのでなんとなくこれはヤバいんじゃないかなとかなんとなく最近プロジェクトうまくいってないようなこのまま行くと多分ダメだなと誰もが思っていても
おっそれをじゃあ開閉しましょうという行動に移すきっかけがないのでずーっと何を釣るする入ってしまうということが起こりえますそしてメンバーが辞めそして誰か疲弊しそして水が混入しバグが出てもそのバグを直す余力もないといったような
スクラムアジャイルでのまあデスマーチが始まってしまうということが起こりえますなのでこの仕事の枠組みがそもそもあるのかそしてそれを改善するという機会があるのかどうかというのをチェックしてみてください次にコミュニケーションスタイルが文言を重視して文言に偏重したスタイルなのか
太陽重視しているのかというのをチェックしてみてくださいこの文言を重視するというのはまあいわゆる言った言わない書いてあるかいてないという議論ですねこれは本来のコミュニケーションの中にコミュニケーション内側の議論ではなくてこれはどちら区とコミュニケーションを外側な話ですよね
どんな言葉を使ったのかとかあるいはその言葉が意味する解釈に対してどうなのかという議論になってしまうのでそもそもコミュニケーションというのはある程度のコストもかかりますなのでコミュニケーションの量が増えれば増えるほど当然無駄が増えますそれを文書に加工が口頭でしゃべろうがコミュニケーションその
ものにもコストがかかるんですとなるとコミュニケーションのコストを増やすようなことというのはいたずらに増やすということはこの意思決定に関わる時間を置くさせることになりますなのでできる限りコミュニケーションというのはコンパクトにしないといけないんですけれどもコミュニケーションそのもので議論すべきものというのはコミュニケーションの内側
中身ですなのでその中身に集中しないといけませんとなると対話としてアイコミュニケーションというのはこちらが何かを走ったことによって相手の反応が当然変わりますその場で変わったものまで受けるこの一連の値上がりはコミュニケーションなんですよねなる
で片方のこのいった部分だけを切り取ってこうだというふうにジャッジはできないんそもそもここでのこの回は両方から生まれているものがそもそもの文脈なんですよねなので文脈を欠いた中でも一方的なメッセージあるいはそれから帰っていたレスポンスそれだけを見て何か意味のあることを読み解こうとすると間違った判断
間違った文脈の理解になりがちですなのでここは文文について元気をし続けすぎるとコミュニケーション量がやたらと増えますそれは一方光を発するメッセージの中に分3個滑る詰め込まなきゃいけなくなってしまうんですよねいわばどこを切り取られても読んだ人が分かるようにって文章の閣下とせざるを得ない
のでそうなるととても冗長なコミュニケーションになりますそれはそれでどの部分を見とセーフティじゃないかと思うかもしれませんただそれは限界があります無理がありますさらにそれをやればやるほど文脈全部見ようとしなくなりますこの部分だけ見ても意味がわかるように書かなかった
この人が悪いとなる某この分だけ見ればいいという考え方を進めることになってしまいますなのでむしろ体はその文脈も含めてどういう解釈どういう意図を持ってその場の雰囲気でも損でいたのかというのを重視しないといけませんとなると文言偏重の
コミュニケーションを伝えるというのは全参加者がゲーその話の内容を理解してなくてもいいみたいなスタイルなるんですよねいわばこの過程今回の懐疑論の中で話をしないといけない人が三人しか実質的には必要ないのにとりあえず関係あるかもしれない人というのを10人ほど読ん
でですねまぁ手っ取り早く例えばチーム体というメンバー全4 j とで会議を始めるで実質その中で意思決定をしたり話したでしょ3人しかしてないとすると酷いの7人は聞かなくてもいいという状態になりますねするとその37人を利かなくなったもう実際
会議に出ていても話のほとんどを聞いてませんで後で議事録見ればいいやとかあるいは後でメッセージとかでsummary送ってもらえばいいやとなりがちですねすると本当に話を聞いてないといけない人まで
効かなくなってしまう恐れがあります実は話をしているその3機の中でもそのうちの一人は常にしゃべっているわけではありませんからそのうちの1人2人はですね a 自分の会話のターンじゃない時はまったく別のことやっている考えてるみたいな事が起こっ入っていますなので
対応重視するというコミュニケーションをとる場合というのは本当に必要な人を必要なタイミングでだけ読んでそこで集中してこの文脈も含めて理解をしていくということをする必要がありますなのでいたずらにそのミーティングあるいは開業するメンバーの数を増やしすぎたりするとこの対応ができなくなり
ますなのでできる限り小さなチームの方が望ましいというのはこの帯はコストを下げるのとそれだけスリングな対話で済むようにするためですね中でコミュニケーションステイルがもしもん偏重のスタイルなってるなぁと思った場合はそれは参加者が多すぎるんですそしてそれでの文言の
小さな部分で文脈を読めない人が増えてききてしまいますなのであるメッセージのある一部分だけに反応してそれはそういう意味じゃないよとかって言ってしまうなえっもし言葉のやりとりが発生していたらそのチームは少し危険ですなのでその場合は
コミュニケーションとして文脈そのものを捉えられるほどのコミュニケーション沿っサイズにするための努力するための運営というのを考えてみてください次にドキュメントの書き方の定義があるかどうかですねドキュメントは基本的にはアジャイルでは中間ドキュメントと色を作らないというスタイルですこれがその中間ドキュメントという考え方は
計画魚型ローターボールモデルでいう仕様車とか要件定義書とか詳細設計図とかですね aそういった次の豪邸にパスするための指示書みたいなものがwaterfall だとその工程ロッド途中途中パスするタイミングで大量に作られます
でそれらを入りそれらをなるべく最小限にしてドキュメントを返してのコミュニケーションではなくて対話で伝えていきましょうというのがアジャイルのスタイルベスけれどもだからといってドキュメントを一切変えちゃいけないとかドキュメントそのものは全く無視していいというわけではありません
ドキュメントはドキュメントで使い3使い方として有効な使い道がありますそれはこの回はあるいは対面で会って話す内容を超えたサイズの場合ですね例えば今はユーザーストーリーのこの部分に対して議論をしているんだけどそもそもこのユーザーストーリーは他も多くあるユーザーストーリーの中に対してどの位置づけなのかどういった繋がりが
あるのかというのを把握するにのてぃドキュメントというのは有効ですなのでドキュメントでそれぞれのユーザーストーリーの関連をモデルにしたり説明として位置付けをきちんと整理した上でじゃあこの部分で話しましょうといったようなことに進めていくためにもその全体としてのドキュメント
あるいはそれぞれのないように対して記憶を超えてしまうようなボリュームも部分というのにドキュメントというのは有効で使えるものになりますなのでその前でとやはりどのように書くのかということが決まってないと各側もですね毎回毎回どういうドキュメント書かないできないのかということを考え
ないといけないすると服メット書くこと自体が遅れますねすると書かなくなってしまいますなのでできる限りドキュメントの書き方そのものいい頭を使うのではなくてドキュメントの中身ですねに頭を使えるようにするためにもこの書き方定義というのがあるのかどうかというのを
チームの中で見つけて下さいもしないんであればってその定義を決めたほうがいいです次にビジョンがあるのかどうかでビジョンってそもそも何だとよく言われるんですチームが集まって何か価値のあるものを提供しようとするわけですからその価値は一体ユーザにとってどのようなものなのかそして自分たちはそのために何ができるのかで自分たちでなければならない理由は何なのか
そういったものがいわゆるビジョンですね形として目に見えたものとして表れるものではなくていう自分たちのうこの今の存在に対してあるいは未来に対して思い描くものですねそれがビジョンとなりますがなぜビジョンが必要かというと
このアジアの場合ですと基本的にはそれぞれがそれぞれ多様な価値観を持っていることをもうまず許容へ認め合いますでそれぞれの価値観というのを終え認めようということはいろんな勝ち団の人がいてもいいむしろいろんな価値観も
人がいた方がいいというスタイルになると自分達の好みで好き勝手作ればいいということになってしまいます製品としてプロダクトとしてチームとしてアウトプットのするものが一体何なのかというものに対して共感をさせる共感をしておく必要があるんですけれども決して
価値観の教官ではありません価値観はそれぞれ好きなもの嫌いなものあっていいんですむしろその方が多様性があるという意味においては様々なアイディアが出たり意見がたりいろんな視点が入りますのでより質の高いプロジェクトができる可能性が高まりますただしその価値観に対してぶつかったりしないようにしないといけないんですねとなん
とそのビジョンが誰かの価値観の延長にあるようなものだとまずいんですねするとその価値観をもった人だけから aそのチームのアウトプットで貢献できるそれ以外の毒テール誰かの価値観の延長上にない価値観を持っている人は貢献できなくなってしまいますなのでチームとしてのビジョンというのは得点縁下の勝タンの反映ではなくてあくまで
もチームとして何をめざすのかどんな未来があるのかということについてのアウトプットが必要になりますでそれが全く共有されていないという場合もビジョンという何らかしらの書かれたドキュメントがあるんだけど誰も知らない誰も見てないあるいはこのチームのビジョンでなんですかって聞かれたときに誰も答えられないあるいは
全員が答えられる状態ないという場合はそれは4を共有されていないのでビジョンはないと同じですなのでビジョンもそもそもあるのかというのをチェックしてみてくださいで次に全工程を理解しているメンバーがどれぐらいいるのかというのもチェック項目に入っていきます
であられるの場合は要件を定義するというのと実際に開発をして作るということさらにその後のそのユーザーストーリーの内々でのテストですねわー基本的に全員でやれる状態というのを目指します例えばデータベースの設計はこの人しかできないとかネットワークに関してはこの人
しかわからないとかあれ要件定義はこの人しかできないとかコーディングはこの人しかできないといったような役割で分業されてしまっているスタイルというのはアジャイルというチームを組んだ時の生産性はあまり上がりません全員が全員すべてができるなかっ
い今回のこのスプリントの子ユーザーストーリーのこの部分はじゃあデータベース設計は誰々さんがやってくださいネットワークに関してこの人が入って画面 ui に関してはこの人が入ってくださいでを割り振ることはあったとしてもその人でなければわからないその人でなければできないという領域がそのチームらどこ
出るというのはなるべく避けてくださいとなるとその全行程を理解しているメンバーがどれぐらいいるかによってそのチームの強さが変わるんですねアジャイルの場合だとマイ工程を待ってから作るというスタイルではないのであると特定の自分が今日やるべきだって業務が終わったら
すぐに別の人が業務に入ってそして相談を受けたりあるいは乳首も手伝ったりということをすぐにどんどん積極的にやっていく2いるが生産性を上げるコツですからある特定のことはできるんだけど他の所で困っている人がいてもその人が言ってることは私は分からない
だからとりあえず待ってますそして私の役割はありませんとなってしまう人たちがそのチームのなかである程度の数がいてしまうと生産性が下がりますそういった意味で理想的には全工程を理解しているメンバーだけでできているというのが理想です全員が
全肯定できるというチームが最も強いチームです次に行動する時のベースとなる心理状態ですねこれはのチームの文化と言ってもいいかもしれませんその文化が謝罪をベースにしているのか曲をベースにしているのかこれは主体性に関わってきます
何か公論移すあるいは何か意思決定をする何か実実行するその場合に事前に許可をえてからいる行動に移すというスタイルがベースになっているチームというのはあまり生産的ではありませんというのは常に許可を求めて
曲降りるまではしないあるいはその許可の求めるととその許可の根拠また求めるんですよねなぜそれをししようとしますかなぜそれが必要なのですかこのやりとりが発生する都度何か行動に移そうと思う時にためなんですね
でそして行動を送れます伏せこの許可というパターンはですね許可を得たんだからじゃあ逆に何やってもいいんだろうってなりますよ許可もらったんだからすると許可した人にあまりにもケンケンが多くすぎてですね許可するがもうなかなかとかしなくなりますすると結果的に許可を求めたとしても簡単に曲が下りない
するとあまり大きな許可が必要なものはは行動としてとるのやめようとなるべく小さく簡単に許可がおりるものだけが許可を求めてであろうという風にしてどんどんどんどん対象となる考え料いてどんどん狭まるんですね
とだってくると最終的にユーザーにとっている最も有益なもを提供するというそのスタンスがどんどん縮小されて言って小さな価値が提供できなくなる小さなチャレンジングしかしなくなるということが起こりますそれが許可をベースとしたチーム文化の成れの果てですね
にもう一つが謝罪をベースとした文化これはとりあえずやってみますとで自分も想定と違ったあれは間違った結果が出たらごめんなさいって言うどちらの子ゴって事後に mr というスタイルですねline あったんだったら去年許しますと
そういうスタンスであ ml ときになぜこれが起こったのかというのを含めてその起こった原因そしてそれに対して次の対策そういったものをチームで考えましょうってそれによって他のチームメンバーも自分がしたした失敗じゃないんだけども自分がした行動じゃないんだけれども
他のメンバーがした失敗から学ぶことができるんですねなのでこの謝罪をベースとした文化を持ったチームというのは生産性が高いですなので基本的にとりあえずまずやってみろとやるときに何を持ってして失敗なのが成功なのかというのを決めたうえでやりましょうあるいはう
出てきたアウトプットを見て正解なのかあるいはですから成功なのか失敗7個判断してそれをもし失敗だったらどう生かすのか成功であったとしてもこれも良くするにはどうしたらいいのかっていうの含めて考えましょうというそっかな後々に対して見ていくというのがこの謝罪のスタンスですからこの車台をのをベースにしたチームのほうが生産性が高く想像力が高くアウトプットを出すクオリティ
が高いという傾向がありますのでどちらをベースとした今はチームの文化になっているのかというのをチェックしてでえええこの傾聴なのか板金合戦が起こるのかこれはどミーティングの中のスタイルを見てもらえばわかると思います
各ユーザー各メンバーが何かの発言をしたりですねあるいはそれぞれの発言をみんなで促して聞こうとするスタイルこれが傾聴というのベースにしているチームというのはそれぞれの意見が生んだから有益な情報があるかもしれないあるいは自分が気づかない何かに他のメンバー気づいてるかもしれないと
いうことで他人のメンバーの中でも自分以外のメンバーの意見という積極電気コードしますそれがたとえ相手がユーザーだったとしてもユーザーがどんなフィードバックをしてきてもそれを積極的に聞いてなぜこの人のこの発言になったのだろうかというその裏側も含めて聞こうとしますこれはいわゆる傾聴
に対してもう一つはマウンティング合戦は自分の主張が正しいと自分がやった行動が正しいんだ自分の判断は正しかったんだあるいは自分の判断がもし間違ってるかもと思った場合でもやその判断は自分は仕方なかったんだあるいは自分のした判断というのはこの判断に関しては誰誰さんがやれって言ったからなんだとか誰な
のですどうかな文書にこう書いてあったから行っただけなんだといったような自己擁護がえっそのチームの中で起こっているような場合だと危険ですチームの中で誰が偉いとか誰からで悪いとか誰がまずいとかという議論そのものは
どっちでもいいんですねチームとするアウトプットの成果が上がればいいんですなので誰かを責めて品質のクオリティが上がると思ってるような文化だもチーム文化と危険ですむしろ何かチームにとってまずい状態が起こったらそれはチャンスだと思ってもっとよくしてやろうと
でへ提供する価値の放任しフォーカスを絞ってその提供する価値を高めるために今のこの与えられている状況ここから得られた情報をどう生かすかの方を見るということですねなのででへコミュニケーションのスタイルとして傾聴をベースにしたスタイルで
様々なところに注意を張り巡らしてここにいるメンバー針はユーザーそういった人たちからの意見あるいはその心の向こう側にあるものを積極的に取り入れていこうとするコミュニケーションスタイルであるチームのほうが生産性が高いです
なのでもしマウンティング合戦がん行われていたらですねそのマウンティング合戦が始まるきっかけというのは全員がマウンティングをしているというシチュエーションはあんまりないと思いますけれども特定の誰かがマウンティング合戦を始めた場合は
a まあスクラムマスターが止めればいいんですけれどもまあ最悪なのはスクラムマスターがバウンディングが空いちゃうことですけれどもa その人はもうまあスクラムますやめてくださいあのマウンティングをしたところでチームの生産性は上がりませむしろチームロックへモチベーション下がりますし a それによって
まあ品種最終的な品質攻撃はおちおちます落ちていきますなのでそういうところに対してどういうコミュニケーションをどういうチームのあり方になっているのかというのは特に注意をしてみてくださいそれではこのアジャイルにへ
結構していった後はですねあじゃうなのかどうかでチェックをしていった後はもしですねええ形省はアジャイルだと思ってたものが実は前じゃなかったあるいは jal あじゃないんじゃないかという風にハァハァ判断した場合はですねじゃあ同様にしてどういう視点でどういう本セプ4でアジャイル化していけばいいのかといったようなものを今
から説明していきたいとおもいますでこの2つに分けてこちらからこちら側に帯同あるいは指向あるいはプロセスシステムというのを書いていきましょうと言ったようなコンセプト図になります
でこちら側はですねええどちらかと言うと計画フロー型で用いられる重視されるスタイルになります7 day長くオーダーフォールモデル方に慣れ親しんでる葬式やあるいは全くアジェンというものが本質的にまで理解できていないという場合であれば
おうおうにしてこちらのスタイルから始まる傾向がありますというのも今まで受けてきた学校教育の中あるいは社会に出た後の新人教育を含め様々なこの社会的なシステムの中だとこちらの皮を一歩より多くるなじみがありこちら側の考え方の言う方がより直観的に理解しやすいんですね
なので放っておくと通常はこちらのスタイルを十方したり意思決定をして何か考えたりという場合はこちらのスタイルになってしまっているということはよくありますなのでこちらは放っておいてもなるものではないので
ある程度のトレーリングあるいは強い意識付けあるいは週間そういったもので変えていかないとなかなかこちら側にならないですなのでそのへんの違いを少し説明していきたいとおもいますまず文言が重視されてしまっているどういう文章を書いたのかとか
その分湘南のかかり方がどうなのかといったようなその文書自体のスタイルですねそういったものにこの文書を中心とする文化文章を重視する組織というのはそのあたりの議論がより多かったりしますメンバーそそちらに意識が向いちゃっているということですね
でそれはそうではなくて選択の方にシフトしていってくださいではば自分でじゃあ何をするのか何をすればいいのかというところ議論もせ選択議論の集中するべきところを持っていくんですねでえっkk 自分たちが何を知っていて何をしたことがあるのかというところにばかり議論が
集中しているとできないことをやったことがないことはやらないになりますね過去に行ったことがあることをからしか判断ができないとなるのでそうではなくて動力の方にフォーカスしてください過去行った事があるかではなくてこれから出来るのかどうかでそれは今までの経験がなければ当然一発目からいきなりできればなりませんけれどもそれは
未来永劫できないという意味ではなくて未来のどこかのタイミングができるようになるだろうできるようになるためにどうするどうすればいいのかといった議論にシフトしてそして何かをするときに事前に許可を求めて曲がなければやっちゃいけないあるいは許可が下りないかもしれないからあらかじめ小さな許可しか求めないように
しようとなるのではなくて謝罪の方とりあえずやってみてダメだったらごめんなさいそれによってダメだったところがわかったのでダメだダメだとわかった子の部分に関して皆さんにん
何らかの情報を提供して共有しますんで皆さんで考えましょうと言ったような謝罪をベースにした文化を考えての方に移行してくださいこれは少しチームメンバーの初めの+フォームが一番探偵興信的な抵抗があると思い今まで許可をベースとした組織だったのが
終わった後失敗したら謝りなさいというスタイルの方に切り替えるというのはかなり勇気がいりますこれもマネージャーサイドもかなり我慢しないといけませんきっと一番この許可から謝罪にシフトする時に一番ビビるのはマネージャーですなぜならマネージャー今まで許可したものだけをしてくれるっていう
強化したものしかさせない空スタイルだったのが何をされるか分からないわけですからその何をされるか分からないと不安と違わなければいけませんなのでこの曲は彼ら世代に移行するのにもっとも障害になるのはそのもともと許可をする権限を持っていた人ですね許可をする権限を持っていた人が真っ先にビビりますなのでそれを
どのようにしてせ際に移行すればいいのかというのはそのマネージャーがいかに耐えられるかになります次に評価から信頼の方に移行させる方法ですけれどもこの評価というのは a
自分たちがどう思われるのかあるいは作ったプロダクトをどう評価されるされるのかされているのかあるいはこれから先に評価されるのか気にするのがこの過去に対して会を行う発想でその結果評価の部分に重点置いてるチームというのは評価というのはその出した結果アウトプットに対するごく一部でしかないので
えそれやばい watch 注意を払いすぎるといい評価もらえるものならやるあるいは良い批評家がもらえないならやらないそういった判断をしがちですそこに対してそうではなく信頼の方にシフトをしていきますリコいう信頼テイラーはこの備えにもつながるんですけれども
各メンバーが各メンバーの想像力を使って想定力を使って能力を使って何かを成し遂げるということに対して最大限の支援サポートするそれはお店印ですねするというスタイルを持ち込みますこれであれば自分が他のメンバーからどう思われているかということを気にしなくて済みます
もうすでに信頼されているわけですからその信頼の中であればお互いにどう思われているかということを気にしなくてもいいのでするとその信頼をベースにした議論信頼をベースにした仕事の協業というのがよりスムーズにうまくいきますなので評価をベースにした
コミュニケーションスタイルなり aチームの姿勢化できていたとしたらそれを信頼の方にシフトするように意識をしてみてでこの場合これらをそのまま持っていくのに彼に意識を変えましょう例えばこれらの説明をしてですねじゃあしたから皆さん気を付けて下さいと言ったところで人はそんなに変わりません
さらにチームとなるとそういうおりそんな簡単には変わらなくなりますなので帰るときにはまず仕組みを変える必要がありますなので仕組みそのものチームとしてのルールあるいはチームとして行われているミーティング
のそれぞれの趣旨ですねミーティングには味んだがあってその趣旨というのがあると思いますけれどもそれらを今9組み合わせを変えたりあるいはその設計構造を変えたりしないから仕組みをシフト戦時していってください
なので基本的にどういう仕組道夢がリズムでアジャイルプロセスというのをこのチームに適応していけばいいのかと考えた場合にこれを視点で議論をするこれらの視点で組み込んでいくということをベースに行ってみてください