2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
チームをチーム開発に導く方法(全1記事)
リンクをコピー
記事をブックマーク
梶原成親氏(以下、梶原):こんにちは。よろしくお願いします。エウレカCTO Officeで責任者をさせていただいております。
自分はエウレカでアジャイルコーチの人と一緒にチームビルディングをしたり、エンジニアのリクルーティングをしたり、採用広報をしたり、ちょっとマルチなポジションでやらせていただいております。
『Pairs』を使ったことがある人はいますでしょうか?
(会場挙手)
知っているという方は?
(会場挙手)
あ、けっこう知ってらっしゃいますね。ありがとうございます。Pairsはオンラインマッチングデーティングサービスです。オンラインで知り合ってデートするまでの価値を提供しているサービスです。
価値を提供するために最も良い手段はなにかと考えたときに、私たちエウレカは、すべてのチームが「自己組織化されたチーム」になることを目指しています。ユーザーに素晴らしい価値を提供するために、自分たちで考えられるチームになれればいいかなと考えています。
みなさんはチームを引っ張っていく立場の人たちなのでわかるかなと思うんですが、(スライドを指して)この絵を見て、この人に「今なにをしていますか?」と聞いたときに、ただ「レンガを積んでいます」という人がいます。また、「レンガを積むことで仕事になって、これで家族を養っていける」という目的の人、「このレンガを積むことによって教会が建ち、その協会の中で信仰が守られてみなさんの生活を豊かにすることができる」という目的を持っている人もいます。
レンガを積むという1つの仕事ですが、それぞれが積み上げたあとのクオリティには決定的な差が出るのは明白です。
いわゆるエラスティックリーダーシップにおけるチームのモードから解釈しているんですが、そもそも自己組織化されたチームとは、チームにスキルがある状態、もしくはチーム自身がチームに必要なスキルを定義して、獲得する方法を知っている状態であったりするかと思います。
チームに対して、リーダーは生産性に関与しない。自分たちで意思決定ができる。衝突を内部で解決できる能力を持つチームを多く作っていく。そういったことが必要だと考えています。
自己組織化されたチームが必要な理由として、私たちが作っているソフトウェアが経営に与える影響が年々大きくなっているのは、みなさんもご認識いただいている通りかなと思っています。
コンペティターもいるし、ユーザーの影響や、ユーザーからのフィードバック、ソフトウェアの出来によってその会社が伸びるとか、もしくはシュリンクしていくというのが明白な状況になっている。そういったなかで、現場で判断して問題や課題を解決することによって、早いサイクルで改善できるようになることが本当に重要だと思っています。
仲が良いチームはそれはそれで素晴らしいことですが、チームの中でちゃんと厳しい指摘をフィードバックしあったりすると、関係性がもっと良いかたちになるのではないでしょうか。最も大事なのはユーザーに価値を提供することなので、そのためにできることをフィードバックしあえるような関係性にならないと、強いチームにはならないと考えています。
もう1つは、チームの中で解決していくと裁量化が進んですごく早くなるんですが、大事なところをちゃんとエスカレーションできないというのは大きな問題になってくるということです。「自分たちで決められる範囲」「自分たちで判断する範囲」と「エスカレーションして指示を仰ぐ部分」をちゃんと理解すれば、判断待ちを最小にすることができるのではないかなと思っています。
自分たちで判断しなければならない範囲も全部エスカレーションしていたら、判断待ちや、確認待ちになってしまうので、そういうのを避けていきたいと考えています。
(スライドを指して)これは、Pairsで実際に結婚したり、交際が始まったりしたみなさんのポスターです。最初のレンガの話でもないんですが、僕たちは、価値を提供することによって出会ったり、子どもができたり、家族になったり、結婚したりということで、その人の人生にすごく大きな価値を与えることができるんだということを常に意識しなければいけないと思っています。
前置きで5分終わってしまいました。要は「僕たちが価値を提供するのが1日遅れたら、それを待っている人が1日待っているんだ」ということをよく理解してもらう、ということを念頭に置いていました。
ここから本題になるんですが(笑)。自己組織化へのステップということで、まずは「課題を見える化する」「一緒に課題解決する経験をする」「チーム自身で課題を解決する」「チームで意思決定するのが習慣化する」という4つのレベルを置き、私たちコーチが関与するのは、「一緒に課題解決する経験をする」までとしていました。
なにをしたかと言うと、チームのプロセスを改善するために、1つのオペレーションの中で振り返って「僕たちうまくやれているんだっけ?」というのを確認するような振り返り会を持つようにしました。
振り返りの終わりに、例えばプロジェクトのゴールがあって、いつまでにリリースしなければいけないというときには「俺たちうまくやれているんだっけ?」というように、リリースまでにちゃんとできるかどうかをファイブフィンガーで確認するようにしています。
ファイブフィンガーを使うことによって、小さい感情の動きもそこでキャッチできるようになるんですよね。3とか2とか出していたら「なんで2なの?」「いや、こういうところが気になっているんです」という対話のきっかけになっています。
(スライドを指して)妨害リストというものがありまして、チームのプロセスを阻害しているものをリスト化することによって、そのプロセスを改善していくようになっています。
プロセスの振り返り会について話をしたいなと思います。例えばあるオペレーションの振り返りで、プロダクトバックログがReadyになっていない状態を改善した例です。(スライドを指して)これはホワイトボードの写真なんですが、Fact、仮説、解決策、計測方法を定義してみました。
事実を書き出して、意見を募って、ソリューションを定義します。ここらへんはKPTでもよくあるんですけど、プラス改善された条件を計測するのが大事なんですよね。
思い込みとか想いが先行して、「結局それってどうなったら改善してるの?」というのがわからないままトライしてしまう。大事な時間をそんなことに使ってしまうとふわっとして終わってしまうので、改善がちゃんと終わった条件を最初に定義して決めるというのを大事にしました。
結局ソリューションをいくつもやっていてもダメなので、そこもファイブフィンガーでこれをやりたいという人が多いやつをやったり、想いが強いやつに限って一つずつ改善したり、というようなことを一緒にやっていました。
変わったこととして、ペアプロ(ペアプログラミング)とかペアワークというかたちで、属人性の解消を始めています。(スライドを指して)これはiOSのエンジニアとフロントエンドのエンジニアがペアワークしているところなんですが、役割もクロスファンクショナルになって、例えばiOSの仕事が滞ったとき、奥の彼がiOSの仕事を助けるとか、そういうことができるようになったりします。
フェーズごとに完了の定義があいまいだったので、品質を一定にするために完了の定義を明確にしました。トラブルになったことを未然に防ぐために、リリースが終わるときにはちゃんとカスタマーケアに共有できていることとか、1つずつ定義しています。
振り返り会から出てくる学びとしては、ユーザーが求めていることを知るために、「ユーザーに価値を提供するために困っていることがあったらみんなで片付けようぜ」というように、エンジニアであったとしてもユーザーのことをもっと知ろうということです。
例えば、ユーザー・ストーリーを検証するためのバックログを積んで、完全に稼働をかけて作り切る前に「これが本当に正しいんだっけ?」という確認をしてから作ろうとか、そういうかたちで1つひとつ変わっていきました。
「変わって良くなった」という成功体験によって、チームを自分のチームごととして捉えることができるようになってきています。例えば、仕様どおりに開発していたチームがユーザー価値に基づいて、「もっとよいユーザー価値にするにはどうしたらいいんだっけ?」というような話をするようになったりするんですね。
チーム全員でチームのプロセスをどうやって改善するのかを考えるようになったり。チームの問題に対して、よく「上司が……」と言う子がいるんですが、これによってチームの問題として捉えることができるようになりました。
どうもありがとうございました。
(会場拍手)
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには