え今回はチーム術まチームマネジメントアジャイルメソッドについて解説をしたいと思いますプロ野球選手教育者エンジニアスタートアップ企業家コンサルタントそしてエグゼクティブコーチとして他方面
に渡る経験を持つ私がこのポッドキャストで皆さんにお届けするのは人生の様々な局面で直面する挑戦に対処し自己実現を果たすための具体的なアドバイスやインサイトです私の経験とコエル技術で紹介し
た方法論を通じて皆さんの夢の実現に役立つ情報をお届けしますこのまチームマネジメントについて私はあのアジャイル開発アジャイルというえまこれはソフトウェア開発の中で使われる言葉なん
ですけれども開発の方法ですねでえそれとまあの比較されるのがウォーターフール型というまえフェーズをこう前から順番にこう1つずつのフェーズを完全に終わらせてから次のフェーズに行くというやり方
これをまフォール開発と言いますがこれあのまソフトウェア開発やってる人であればまピント来るとは思うんですがあまソフトウェア開発をあまり馴染みがない方に説明しておきますとえウォーター
フォール開発というのはま初めに何を作るかというのを完全に決めてしまってでまそのえ決めたことが絶対にもうこれ以降は変更がないという前提でえその後設計をしてでえ開発ソフトを実際に作ってみてで
作ったで完全に作り終えた後にまテスト実際にえ作ったものが元々のこ想定した通りに動くようになってるのかというのをテストしてでえ最後にえそれらを動かしてでえ終了するとでこれはあの前提となっ
てるこの考え方と言いますかあこの流れなんですけれどもま製造業とかま建築業とかで使われている方法ですねでこれをソフトウェアの開発の方でもま同じように流れとして同じような流れで作るわけです
けれどもままその一見まこれはあのま他の業界で使われているやり方なのでま別に矛盾がない変変じゃないという風に思われるかもしれませんがこれがあの他のあの業界とま違うところというのはま建築物と
かあとはあの製造房製造業での製造物というのは1回作っちゃ1回作ってお客さんの手元に行ってしまったらそれ以降基本的に変更できないですよね建物も立ててしまった後にまた何かを変更するとなると
ま修繕まそこを壊してでもう1度そこを作り直すみたいな部分的なま修繕回収というのはま可能な範囲であればやる可能性はありありますけれどもまそれはま何かこう老朽化したりとかトラブルがあったり
とかあそういった場合にま行う方法ですよねなので基本的にえ元々のそのお客お客さんその物が欲しいと思っていたそのニーズがま変化しないというのが前提ですよねでえそれを作っていく過程でももう
初めにもニーズは決めてしまったんだからまその通り作ればいいという前提で作るこれがまウォーターフォールですねこれのウォーターフォールというのはま滝ですけれども滝の流れのようにま上から順番に
こま工程をですねこ上というのはその工程の1番上はあま要件定義といってえお客さんが何を求めているかというのを初めに決めてしまうとでえそこからその設計で実装といった流れでま完全にその決め切っ
てしまうとえそれで次へ進んでいくというま作り方ですねでえこれはあの歴史が非常に長く建築とかはそうですがあま歴史的にはま2000年ぐらいはあるかと思いますあの人間が何か建造物を立て始めたあ歴史
を考えますとですねとなるとあのその当時から私たちが求めてるものというのはそんなにこうとんでもなく変化したということはあんまりないとは思いますえ建物に対する人間のニーズっていうのはあまその
間にまいろんなテクノロジーが入ってきてであとはその人数規模ですねが増えてきてまいろんなことはあ多少は変わったとは思いますがそれに比べてまソフトウェアの世界というのは人間の基本的な欲求自体
これも変化してでテクノロジーそのものも変化してますのでえお客さんが欲しいと思っているであろうものをこう決めて作ろうとしてる間にもそのニーズはどんどん変化してしまいますそしてそのお
客さんのニーズも1番初めの段階でこう固めきれないていうことも起こるえことがよくありますであとはあお客さんのニズを初めに全部決め切ろうとすること自体が結構無理があってえ実際のその建物建造物
であればあ概ねその他にサンプルになるものがいっぱいありますよねなのでえ要件とか要求を決めていく際にその他のサンプルを見せながら他のサンプルを引き合いに出しながらどういうものが
欲しいのかというのをお客さんに確認しつつでお客さん側も他のあの建造物で実現されていることを前提に話したりもするのでそんなにこうあの変な要求変な要望というのは出にくくかつその自分たちが言っ
てることの意味もま概ねイメージできて分かっているわけですよね扉ですと言えば大体扉のイメージはつくかと思いますしえ例えばエアコンがで言えばそのエアコンもままいくつか種類があるとは言ってもエア
コンというのは一体何をするものなのかそれがどういった形でえどういったところについていてどういう風にこう操作してえ作動するのかみたいなものもまそんなにこうあのえお客さんの中のお客さん同士
複数人のお客さんがいてもお客さん同士の中でもそんなにこうぶれないかなと思いますがソフトウェアの世界はそうではなくて形がないものに対して色々要件要求というのをお互いに確認し合うんですがそれ
は開発とお客さんの間でですね確認をするんですがここが実は全然イメージが違ってるみたいなことよく起こりますでえこれはあの例えばこういうウェブサイトを作りたいんですすと言ってきてもその
ウェブサイトがまだこのようにないえこの世界にまだないものを作ろうとした場合に引き合いに出すものがイメージがお客さんのイメージとそれを聞いてこういうものかなと想像開発側で想像をしたそのえま想像
物ですねえお客さんが求めてるのかなこれが欲しいのかなと思って想像してえイメージしてるものとがまかなり違うということも起こりますしあとはお客さん側もこういうものが欲しいと思って作ってい
たんだけれども実際にその物を見てみるとあなんか違うかも本当に欲しいのはこんなのじゃないのかもとか思ってしまうわけですねそれはなぜかと言うと目の前にえ具体的な自分がイメージしてるものがない
のでえその段階でどんなものが欲しいのかと聞かれても人間はですねえ自分が何が欲しいのかというのを目の前にして使ってみて触ってみないと実はよく分かってないんですねでそれがそのソフトウェア開発に
おけるま何点でえ形がないものをあらかじめお客さんのイメージの中で固めていくみたいなことをやる必要があるところが難しいえですねでなのでま既にこの世の中にあるものでもうどこかで
すでに稼働していて使われてみたいなものを作るのであればまそれほどその要求のところでブレたりはしないんですけれどもあのソフトウェアの世界というのはえコピーしてくることというのはコストが
限りなく0に近いので既に世の中にあるものをもう1回作るというのはあんまり特色ではないです例えばあるソフトウェアを作るのに1億円かけて作ったそしてそのソフトウェアとほとんど同じものをもうえ
もう1回1億円かけて作るみたいなことは無駄ですよね建築物ならあの1億ま1億じゃ作れないとあの大したも作れないかもしれないですけれどもまあのあるビルを作ってそのビルとまほとんど同じような
ビルをもう1個作るとなるとま同じだけのお金がほぼかかりますって言われてもまそれはあの材料品もそうですしあと作るためのえコスあるいはえ職人さんの労働労働に必要な経費まいろんなものが必要
ですのでま同じようなコストがかかると言われてもまそれは仕方がない実際にはま仕方がないこととしてえ受け入れられますけれどもソフトウェアの場合は1回作ってしまえばコピーが可能なものなのにも
関わらずもう1度同じものにお金を払うというのはこれあのソフトウェアのそのビジネスとしての競争力がないわけですよね他であればもうそのまま使えてしまうのに自分のところだけえそれをもう1回お金
を請求するみたいなことをしてもま他のあのえま競合他のライバルはあもっと安くでえもっとこう簡単にこう提供しますみたいな風にこう競争が起こりますのでなのでそういう意味では同じものを基本的に
作るというのは定のの世界では競争力があまりないわけですよねとなるとの世界でのそのビジネスの競争というのは1度作ってしまってで同じものはもう使い回す同じものはもうほぼ流用するとで違うところ
だけを作っていくみたいなスタイルがそのソフトウェアビジネスにおいては競争力になっていくわけですけれどもえそうなるとお客さんが大体要求とか要件を言ってくる時というのはすでにないものについてえ
要件要求をこうお互いに確認して引き出していかないといけないわけですねとなるとお客さんがもう今まで見たことがないものとかあ実際に触ったことがないものについても話さなといけないわけですねそれをま
顧客ニズという意味でえお客さんが何を求めているかというのを開発する側も想像しながらそしてお客さん側に確認もしつつでえ要件とか要求を始めに決めていこうとするわけですけれどもこの過程でもう
そもそもその確認する相手のお客さんの頭の中のイメージというのがちゃんと描ききれてない場合の方がほとんどでその描ききれてない上にお客さん側もそれをこう色々アプローチえ開発さ開発側と
コミュニケーション取っている間に色々意見が変わってしまう新しい気づきがあったりあとは過去に言ったことをも記憶上忘れているとかでえお客さん側も自分がやらないといけないことっていうのがあ
本当は元々こうだと思っていただけど実際に色々考えたり議論したりコミュニケーション取っていく中で本当はこっちが大事なんじゃないかということに改めて気づいたとかこんなことが何度も
起こるわけですねすると要件とか要求がどんどんこう変化していくあるいはもっともっとという形でどんどん肥大化していく要求とか要望がく膨れ上がってくるみたいなことも起こりますでここでいやいやもう
初めにもう決め切ってくださいともうこれで終わりにしてくださいと言ったところでえお客さん側からすればですねいやじゃああのそれ要望聞いてくれる他のえソフトウェアを作る会社にもう変えちゃい
ますあるいはお客さんがもそう思うようになりますよね要望をちゃんと叶えてくれる自分たちが作りたいもを作ってくれる他の会社に当たろうよっっていう風になりますよねするとお客さん側はあの他の測定会社
に逃げちゃうわけですよねでそうなるとえソフトウェアを作る側ソフトウェア会社側もお客さんの要望をえ聞かざる得なくなってきてしまいますでそれはその辺りはもう契約書で
がっちり固めてもう契約書上そんなことはできないようにっていう風にうまくあの初めの段階で合意を取るみたいなことをビジネス上はやったりしますがただお客さん側の心情としてはま契約書ではそう
書かれてるけれどもなんか実際やってみたらあこの測定会社すごく不親切だななんかこっちが思ってたのと全然違うな初めにこんなことできますあんなことできますって言ってきたあの時のあの幻想を
抱かせたあれは結局嘘だ嘘だったのかと先でさなのかとまいう風にこうなってしまうわけですよねそれはもう速定会社がもうそうなることも見越してますのでえなのでその辺り初めのこう要件定義要求をお客
さんの要求をちゃんとこう初めに固めてしまいましょうみたいなことをやろうとする時にはそのフェーズが元々はこう1ヶ月でえ件をどうするか固めましょうよとかって言って一応置いていたもののま大抵
はそれがどんどん伸びてえ2ヶ月3ヶ月を伸びてお客さんの要望もコロコロ変わってえみたいなことにこうソフトウェア会社側は巻き込まれていくような気がするわけですねでこれの何が問題かというと要件と
か要求がココ変わるお客さんが問題なのかそしてえそれをこうちゃんと1ヶ月と決めた中でお客さんが言ってきたことを1ヶ月内にまとめきれなかったソフテ会社側が悪いのかってこれはどちらも別に悪くない
わけですこれはやり方に実は問題があるわけですねお客さんの要求とか要望は変更することがま前提変更するものだと思うことが大事でそしてその変更がこの途中で開発をし始めたり計をし始めたりした
ところでその要求の変更が受け入れられないことが問題なわけですねなので初めに全ての要求とか全ての要件を固め切りましょうみたいなそういうえプレッシャーをまお互いがえそれをこうその要求を決め
なきゃいけないという前提で物事を取り組もうとすることこれに無理があるわけですねお客さんは基本的に本当に動くもの手にさまそでの場合は手に触れることってあんまりないですけれどもま画面
をえ触ってみたりとか触ると言ってもクリックですねまカーソル合わせてクリックしてみたりとかまタブレットだったら指でタップしたりとかですけれどもまそういったこう目に見えるものやあ触れ
られるもの動かせるものが実際に目の前ににこう与えられないと本当の要求本当の自分がしたかったこと果たさなかっていけなかったことていうのは分からないわけですよねなのでこのアジャイルメソッド
アジャイル開発のそのえま利点というのはお客さんに実際に動くものやあ操作できるものというのをもう最小限でいいのでえそれを提供しながらでお客さんのフィードバックを取りながらどんどん修正
回収というのを行っていってで最終的なまチなものにするまその逆もありますけどもね初めは多機能にしながらどんどん機能を逆に絞って削っていくでよりシンプルにしていくみたいなこともありえますけれども
初めに決めたことをそのまま最後まで全部その通り作るではなくて変更や修正やあとは追加のよりこうリッチな機能をつけていくそしてえ柔軟にお客さんが求めてるニーズというものの変化を捉えていくそれ
をちゃんと実装していくていったやり方を取るのがこれはアジャイルメソッドアジャイル開発のま基本的な考え方になりますでそうなるとそのえアジャイル開発をする上で重要なのはチームの作り方とあと
そのチームメンバーのえスキルセットとかあとマインドセットですねこれらが非常に重要になってきますえウォーターフォール開発だと要件定義だけをする人その後設計だけをする人そして実装だけをする人
そしてテストだけをする人みたいな形でま工程ごとに人を入れ替えたりえまそれこそチームごと入れ替えたりすることができるわけですねまできるというかあそれができると思われていてそして実際にそれを
してしまうわけですねでこれはもうそこの領域に特化した人たちをまお金を払って作らせた方が例えば要件定義だけをするコンサルティングファームのそのコンサルの人たちを雇ってその人たちに要件提供さ
せるみたいなことした方がなんか一見効率がいいように見えるわけですねそして設計だけをするまSのまその設計をするようなエンジニア上級エンジニアみたいな人たちにえ設計書を書かせてでその後それをえま
プログラミングコーディングしていくプログラマーたちでこれはまあ大体頭数が必要だということでたくさんプログラマーがそこに投入されたりするわけですけれどもえそういったこう分業がされるわけです
ねでこれをやると後程の方になってる人たちはその前工程を作った人たちの意図や意思というのをドキュメントだけから読みとまない読み解かないといけないとこれが書かれてる意味が何なのかというのをその
書かれた文章やあとまあのま画面のレイアウトとか書かれてたりもする場合もありますけれどもうんその中から読みとかないといけないするとこれって伝言ゲームみたいなもので当初要件定義をしていた
コンサルがお客さんと話していたこととその後ドキュメントにしてえ次設計フェーズで受け取ったあまエンジニアそしてそのエンジニアが書いた設計書をその後受け取ったプログラマーたちは元々
の当初の意図や背景っていうのがよくわからないままドキュメントに書かれてるこう動くことこうここでこうななることだけを読み解いて作っていくことになるわけですねそうなると出来上がりが元々の
お客さんが意図していたものとなんか食い違うものができてくることもありえますよねこれ伝言ゲームのえ世界でよく皆さんも小さい頃ですね前から順番にこう1列並んでえま先生が1番前の人に何かを
こう後ろに伝えるようにと指示されてそれをどんどん後ろに伝えていくと最終的にえ1番前の人が先生からま受け取ったメッセージが全く違うものになってるみたいなことが起こるのが経験上あるかと
思うんですけれどもこれがそのソフトウェア開発の中でも起こるわけですねなぜそんなこと起こるかというとあの人間の記憶や人間の解釈というのは現実の世界の捉え方も変えてしまいますのでえ
こう伝言をしていく中で当然その伝える側と受け取る側の解釈がずれるということよくありますしそれはもう当然のことですねお互いのバックグラウンドで背景が違いますのでなのであの伝える側がまこれで
伝わるだろうと思ってえ用意したものと実際にそれを受け取ってえそこから解釈をして読み解く側とのイメージがずれるということをお互いがお互いによく分からない中でそういった伝言ゲームをするもの
ですからあどんどんずれてくるということが起こります本当に単純なシンプルなメッセージであっても伝言ゲームをすれば最初と最後とでえメッセージが変わってしまうみたいなことは本当によくあります
なので実際に体験してみるとあの面白いほど人は人の話をえ正しく解釈できないんだなと逆に伝える側も伝える側でこれで伝わるんだなと思って喋ってる伝わるんだなと思ってドキュメント書類を書いている
みたいなことがいかにこう人間がこれで伝わると思うそのさ伝わると思ってしまうえそのま錯覚ですねそれがいかに強いかということが分かると思います私たちはこのま頭蓋骨の中の限られた領域の中で自分の
こう脳を持ってますのでこの脳のえ頭蓋骨の中にあるこの脳が私たちの世界の全てですからあ他者がどんな風に解釈してどんな風にこれが聞こえるのかというのをえ客観的に判断するのは非常に難しいです
ね自分たちのこの解釈をしたこの世界の中で世界を見ているので相手も同様に見てるはずだという錯覚を起こしてしまうわけですねでこれがそのドキュメントを用いたドキュメントの書類ですね書類を用いた
伝言ゲームでも起こりますでこれがソフテ開発みたいなかなりこうドキュメントの量も多くそしてその中身がですねえ分かりにくいもの簡単にイメージししづらいもので特にま文章とかとかでたくさん書かれ
てるものとかだと当然連言ゲームをやってしまえばどんどんずれていきますでこれがアジャイル開発の中ではなるべくそういった中間ドキュメントを排除して直接開発者が物を作りながらお客さんに見せてお客
さんがそのフィードバックををその開発者にすることによってそれによってその要件や要望のずれこれを修正していくわけですねでその開発えその開発をする中でお客さんの要言要望は当初言ってきたこととま
変化してくるみたいなのもえ基本的にはそれを見越してやりますのでその要件とか要望がま変化したとしても開発者側はそれによって本当のお客さんのニーズというのが把握できたという風に捉えてえそれを
反映していくとただあのお客さん側がこう色々こうあっちかなこっちかなという風にこうどんどんぶれていってしまう場合はあせっかくま先週作ったものがま今週も全く使わないま全く大安になってしまうみたい
なこともあり得るとま開発側はまそこでちょっとモチベーション下げてしまうようなあの可能性もありますがあそこはそのお客さん側にもあのそういう要件とか要望を変更が入った場合はですねそれ本当に必要
なものなのかそれとも要件とか要望がそんなにコロコロ変わるということはそれ全然その本当は必要な機能じゃないんじゃないか欲しいものじゃないんじゃないかと本当に欲しいものがそんなにコロコロ
コロコロ変わるというのは思いつきで変わるというのはですねそれは実はどっちかというとどうでもいい機能やどうでもいい要望なんじゃないかという風に国人をお互いにし合う方がいいですねなのでお客
さん側があしたいこうしたいていうのがコロコロコロコロもし変わるんであればもしかするとそのプロダクトは必要がないプロダクトかもしれませんお客さん側が本当に求めているものというよりはどちら
かというとどうでもいい機能それに時間を費やしてる可能性がありますのでお客さんが本当に欲しいもの本当に優先して作りたいものというのが何なのかというのを開発者側もリードしていく必要があります
で画面を見せたり実際に動く実際にこう動くものを見せたりしながらお客さんのま業務なりお客さんが実際使うシーンというのをま疑似的にですけどまデモをすることデモンストレーションすることでお客さん
自身も自分たちが使いたかったもの欲しかったものというのがま分かるわけですでま今回はそのチームでどうマネジメントするかチームがどうどういうえ形で機能するべきかというところに
ちょっと話を戻しますとえチームで作ることの1番のメリットは人間の記憶の限界や感情の変化これをなるべく平坦化することですねね平準化することですえぜえ私自身もこう1人で何かをしてる時に当初
なんでこれをやるんだったのかとかこれを作る時にどんな感情だったのかみたいなものはこう時間と共に変化していきそして時間と共に例えば記憶であればえ記憶が変わってしまったり記憶を忘れてしまった
りっていうことも起こるんですがそれそれ自体も私個人本人1人では気づきにくいわけですね自分が解釈が変わってきている自分の感情が変化してきているそしてその同時の感情は何だったんだろうかみたいな
こともそれ自体が変化したことに気づきにくいわけですねしかしチームであった場合はチームの全員が同時に同じ感情になるとか同じ感情の変化を全員が同時に味わうとかあとは記憶を全員が同時に記憶
がなくなるとか記憶がすり替わってしまう上書きされてしまうみたいなことは現実的には起こりにくいわけですね要はあの個個人があそれぞれ記憶が変わったり記憶が忘れたり暴挙したりすることは個々人では
あったとしても同時ではなくまそれぞれがバラバラでえそういった行為が起こる可能性はありますとなってもえそれぞれが全員が何らかの記憶元々決めた目標や元々決めたあビジョンに対してま1人2人が忘れた
としても他のメンバーが覚えていればいやそれ違うよ昨日こう言ったんじゃんとかあこういう風に決まったんじゃなかったっけあるいはその実際の行為を見てあそうだったそうだったあ元々これやろうと言ってた
んだたみたいな風にして他のメンバーは忘れかけてた忘れかけてしまおうとしていたメンバーがそれに気づけることがあるわけですねなのでこれは記憶や感情の分散化でまどこかのメンバーがま誰かがあもし
忘れたとしたり感情が変化しても他のメンバーがそうでなければま元に戻せるわけですねでその分散化ができることによってチームが向く方向性というのが安定します
すると個人1人だけでやってた時というのはその個人の波というのがああってえとてもこう生産性が高い時期とそうじゃない時期みたいなものがま不定期に起こってきたりしますがそれをチーム全体でえ
それらをこう分散することによってカバーするわけですねそれとチーム全体としては進むスピードが安定するそして個人としてもその波が個人の波も減ってくるということになりますこれがまチームでえ仕事を
する上でのま利点ですねなのでチームメンバーはあまりにも多すぎるのは危険ですね多すぎるとそのお互いのビジョンやお互いの記憶が元々本当どうだったのかということを確認するための作業というのが
またくさん大量に発生してしまってまこれをま同期性と言ってますけれども同機を取ることがとても難しくなりますなので感情が変化したりあ記憶が変化したりそういったこうお互いが何の仕事をしているか
何を今考えてるのかということを確認するためだけの作業というのが膨大に増えて結果的にえ仕事の大半がそれにに終われてしまうみたいなことが起こりますなのでチームをくんで仕事をする上でそういった
ことががあまりうまくない組織やあまりにもチームが大きすぎる組織というのはその確認の作業がほとんどの時間に追SYされますするとだんだんとえその確認をすることが仕事なんだという風に錯覚してくる
わけですねなので1日のうちのえ半分ぐらいがその進捗確認や進捗報告のためだけに用意された時間だったりみたいな変な現象が起こるわけですねなのでほとんどがその進捗確認や報告資料を作るための
時間に当てられかつえそれを確認してチェッしてここどうなってんのどうなってんのみたいなこと突っ込みを入れるだけの時間みたいなものが設定されで実際に動くソフトウェアを作るとかあるいは何か
価値のある仕事をするという時間はもう1週間の中でも1/3や1/4もうないみたいなことが起こるわけですねでそれがチームをやる上で結果的にチームの生産性をちゃんと引き出せないということが
起こりますなのでこの同期性があ重要なのでえその同期性をいかにこう高く維持し続けられるかそうなるとチームのメメンバーは少ない方がいいわけですねなので実際のそのソフトウェア開発でたくさん
の人が投入されてたくさんのチームが蘇生されることがよくあるかと思いますが私はお勧めするのは1つのチームその同期を取る頻度ですねえ高い頻度で同期を取る必要のあるえチームの単位えその中の
メンバーの数というのはもう9人以下まできれば5人ぐらいが1番望ましいんですけれどもま高い同期性でお互いが何を考え何を思って何を今取り組んで仕事をしているのかというのがまそんなに頻繁の
コミュニケーション取らなくてもなんとなくの日々のコミュニケーションで分かるというレベルの人数がいいですねでえそのアジャイル開発においてはまこれはスクラムという方法1つのアジャイル開発
のうちのま1つの方法論ですがスクラムというものがありますでそのスクラムではえ毎日決まった時間に5分程度でえメンバーがまデイリースタンドアップミーティングといってえその5分間の中で各メンバーが
昨日から今日まで何をしたかで今日から明日にかけて何をするつもりなのかそして今チームの成果を阻害するような何らかの問題点や懸念点等があれば報告するといったことを1人ずつ順番にやっていくわけ
ですねでここのこの時間の中では何か相談をしたりとか議論をしたりみたいなことはせずにただただただ一方的に報告をするとでえ質問があって相談がしたいという場合であればベッドミーティングを設定して
必要な人とだけ時間を取ってやるとそのえミーティングデイリースタンドアップミーティングの中ではそういった議論や相談は基本的にしないといった形でえただただそこはもう同期を取るためだけの
場所ですね同期を取るためだけの時間として使うとという風にこう展開していくわけですねすると最小限の時間で同期を取るという時間があるあるわけですからえその同期性を取るという点においてここの
デイリースタンドアップミーティングでえ全員がちゃんと集中して他の人のその報告を聞けないような人数は多すぎるわけですねこれがもしチームメンバーが30人とかいたら1人1人が報告しててもほとんどの
人はあま聞かないですよね聞いてないですよね全員分をちゃんと集中して聞き続けるなんてできないですよねえ注意がそれますよねえそうなるともうそのミーティングというのは外化してま誰か特定の人だけが
喋るとかあるいはもう疑似録に書かれたものを後から見るので回してくださいで終わってしまったりして結果的に同機が取れなくなっていくわけですねまそういう意味ではま同期が取れるメンバーというの
はむしろ小人数の方がうまく同機が取れますのでえチームメンバーを絞るというのはま原則になってきますなのでチームで仕事をしましょうと言ってもそれは大人数の100人200人でやりましょうでは
なくてま5人とかえま少なくてもまえ3人ですねえぐらいでやるという形でえ十分かなと思いますでこの辺りえ私のそのもう1つの著書え成功するアジャイル開発の中でそのアジャイル開発というものがどういう
ものかそしてま陥りやすい罠あ多くの人が誤解している点うまくいかないアジャイル開発というのはまこういう特徴がありますよみたいなことについて書いた本がありますのでまそちらの方見ていただければ
いいんじゃないかなと思います今日はまチームというまアジャイルというテクニックの中でえチームをどう捉えるべきかという風にえお話をしましたがあ是非ですね皆さんもチームを組んでえ仕事
を効率化してでかつ自分のパフォーマンスを最大化するようなチームメンバーを探してうまくチームをマネジメントしてもらえばと思いますでチームを蘇生する上でま難しいのはえチームのその形形態だけじゃ
なくてま誰なのかチームメンバーそのものですねここが実は非常に難しくかつ選択肢が少ないわけですね本当にいいチームメンバー合うチームメンバーと出会えるというのはま本当に稀なのでえできればあ
自分のこだわりをちゃんと理解してもらえるようなチームメンバーとま出会えればそれはすごくいい出会いですしもし出会いないんであればやはりそういったメンバーを探すということも同時にえ
やっておく必要があるかなと思いますそういう意味ではソフテ会社の1番の希望は採用だと思います人をちゃんと採用してアイをかけられてそしてそういった人たちを引きつけられるようなビジョンや働き方
やあそれらに対してえうまくこうまちゃんとえ求心力を持って引き寄せられるようなそういった組織体制というのがソフト会社のま勝負のポイントかなと思いますそういう意味では人ですねチーム
メンバーそのものがソフトウェア会社にてみると資本なのでえそこにこだわっている会社そこに皆さんもこだわっていただければと思いますはいということでえここまでアジャイルメソッドについてまざっ本当に
簡単にですけど紹介しましたこれコエル技術の中でも書いてますのでえまだコエル技術を読んでいない人はAmazonでポチって買って読んでいただければと思います