他者と働き、チームで成果を出す方法- 人との関係からみるカケハシ -/KAKEHASHI of the relationship between members

Transcript

1. 他者と働き、チームで成果を出す方法 - 人との関係からみるカケハシ - 株式会社カケハシ Kanehira Yumi / Shogo Kubota Atsushi Taneoka / Naohito Sasao 2024.01.11
2. © KAKEHASHI Inc. 司会者の自己紹介 kanehira 開発ディレクター 食べて美味しい、飼ってかわいい、医療でも貢献してる ぶたの様に変幻自在に社会に貢献したい生き物 今日はみんなでツラミを分かち合って 他者へのハシのカケ方知って羽ばたいてこー！
3. © KAKEHASHI Inc. 自己紹介 kubop エンジニア -> QA -> エンジニア 品質向上のため頑張る💪 自費でCSM取得した。
4. © KAKEHASHI Inc. - 組織で起きる問題には、 - 既存の知識・方法で解決できる技術的課題と、 - 技術やノウハウで解決することができない - 「適応課題」が存在する。 - それらの適応課題に向き合い、解決する方法が「対話」 技術課題と適応課題 他者と働く 「わかりあえなさ」から始める組織論 第1章 より 既存のノウハウで解決できる技術的課題 既存の解決方法では解決できない適応課題
5. 対話とは、 「新しい関係性を構築すること」 他者と働く 「わかりあえなさ」から始める組織論 第1章 より
6. © KAKEHASHI Inc. - マルティン・ ーバーによる人間同士の関係性 - 「私と、それ」 - 「私と、あなた」 - 「私と、それ」は人間でありながら、向き合う相手を自分の「道具」のよ うに捉える関係性のこと。 人間関係の2つの分類 他者と働く 「わかりあえなさ」から始める組織論 第1章 より https://coach.co.jp/view/20210609.html 「私と、それ」 「私と、あなた」
7. 対話とは、 自分の中に相手を見出すこと、 相手の中に自分を見出すこと 他者と働く 「わかりあえなさ」から始める組織論 第1章より
8. QAチームでの対立と 私の橋の架け方 by kubop
9. © KAKEHASHI Inc. - 前提 - QAチームを組成したばかりの3人チーム。 - 同僚はス ードタイ 、私は手が遅い熟考タイ でお互い のコミットに対立があった。 - ローを作る際にも... - 私「既存の ローと理想の ローを本と他社事例を調査して描きました！」 - 同僚「まずは現状調査して、出来ることからクイックに成果出していこう！」 QAチームでの同僚との対立
10. 目的は同じなはずなのに 何故か意見が合わない
11. © KAKEHASHI Inc. 溝に気がつき、観察した - 既存の技術や知識では解決できない適応課題だと気がつく。 - 同僚はエンジニア・QAを兼務していた。 - 私は専任でQAを行っていた。 - 私がQAあるべき論や膨大な調査結果を押し付けてしまっていた。
12. 私は同じチームである 同僚に対し、 私と同じ機能としての 振る舞いを求めた
13. © KAKEHASHI Inc. 同僚との溝に橋を架ける - 毎日huddleで雑談コミュニケーションをして人となりを知る。 - 獲得した知見やデータは咀嚼して少しずつ展開し、同僚の意見を しっかり聞いた上で、意見交換して成果物を作り上げる。 - お互いの「良さ」を活かした仕事の振り分けをする。 - 調査・資料を作るのは私、拡散・調整するのは同僚のような分担。
14. 半年以上一緒に働き、 お互いの意見は自身のものと 同じように尊重され、チーム でアウトカムを出すことに集 中出来た
15. 相手のナラティブを理解し 「わたしと、あなた」 という新しい関係を 橋を架けて 構築することを学んだ
16. © KAKEHASHI Inc. わたしがカケハシで実践している「架け橋」 - QAのあるべき姿や、アーキテクチャの理想論など正論を押し付けない。 - 単体テストの書き方をTipsとして提案して意見を集う。 - 品質についての勉強会を各チームで行い、それぞれのチームが求める 知識に寄り添って構成を変更する。 - DDDやスクラムの輪読会を実施し、実際に設計・サン ルコードを書い て少しずつ展開する。 輪読会ハ ネスレーダー 単体テスト提案 DDDサン ルコード 品質勉強会
17. THANKS!
18. プロジェクトの方針転換時の対話
19. © KAKEHASHI Inc. 自己紹介 taneoka エンジニア 本日は、カケハシで約4年参画していた toC向け開発チームでのお話をします
20. © KAKEHASHI Inc. iOSアプリリリース直後に方針転換 iOSアプリ vs LINE Webサービス 仮説検証をどちらで進めるか？
21. サービスを通じて患者さんの医療体験 を良くしたいという気持ちは同じ
22. © KAKEHASHI Inc. 対話を経て学んだこと - 自分の意見を押し通すところをゴールにしない - 最初に意思決定 ロセスを明確にしておくこと - 対面での対話の大切さ - 結果に対しては素早く検証できるように努める
23. THANKS!
24. © KAKEHASHI Inc. 自己紹介 sasao エンジニアリングマネージャー 多くの人がもっと楽に成果を出せて 最高の ロダクトやサー スを 生み出せる環境を目指しています
25. 入社直後の 組織課題への対応
26. © KAKEHASHI Inc. 入社時に発生していたこと - ロダクト成長とともにチームは拡大を続けていた - エンジニアも10名を超えてEM層拡充へ - ロダクトに対する開発要望も積み上がっている - 0-1 ェーズが終わりエンター ライズ企業導入ステッ へ - 新入社員には開発チームが何をしているか見通せない - 開発テーマが肥大化しリリースまでの期間が伸びている - メンバーも開発ス ードが落ちている実感がある - 振り返りでコメントは出るが理由まではわかっていない
27. © KAKEHASHI Inc. 自分の中の行き詰まりと不安 - 僕自身、右も左もわからなのに組織改善する必要がある - 改善に対しチームの理解を得られている訳ではない - 抽象的な理想を語っても現実との乖離で受け入れづらい - チームが抱える課題感はメンバーそれぞれで異なる
28. © KAKEHASHI Inc. 僕とメンバーとの間にある溝 現場の課題や温度感 良いチーム体験の有無 ラクティスなどの知識による 大きな溝 現場も知らずに 理想ばかり 今でも開発はできてる！ 理想の組織になるんだ! こうやって進めたい! 過去の経験 組織システムに対する興味 それらに基づく知識 今の開発 ロセスによる経験 業務への責任感やドメイン知識 そららに基づく価値観
29. © KAKEHASHI Inc. どうしようとしたか？ - 可逆性の高い変化を積み重ねる - 組織変更など不可逆な変更は後回し - 少し前に進むだけで変化の大きな ラクティスを選ぶ - まずはユーザーストーリーを小さくする - 理解が得られなくても必ず進める内容は説明する - 一緒にできる事は一緒にやる - ロダクトマネージャーやデザイナーとも一緒に進める - 信じて一歩進めてくれるメンバーを全力で支援する
30. © KAKEHASHI Inc. 小さなカケハシを作りたい 『少し良くなったかも』という 小さなカケハシ 少し現場を理解してるし 理想ばかりではないかも 変化も感じられそう 僕も不安だし みんなも不安 少しずつ少しずつ 過去の経験 組織システムに対する興味 それらに基づく知識 今の開発 ロセスによる経験 業務への責任感やドメイン知識 そららに基づく価値観
31. © KAKEHASHI Inc. たくさんの小さなカケハシを作りたい 『少し良くなったかも』という 小くてたくさんのカケハシ 少し現場を理解してるし 理想ばかりではないかも 変化も感じられる 僕も不安だし みんなも不安 少しずつ少しずつ 過去の経験 組織システムに対する興味 それらに基づく知識 今の開発 ロセスによる経験 業務への責任感やドメイン知識 そららに基づく価値観
32. THANKS!
33. ちょっとだけ KAKEHASHIの宣伝
34. THANKS!