職能割りからプロダクト割りのチーム運営へ

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© DMM.com 自己紹介 2 坂本圭佑・合同会社EXNOA プラットフォーム開発本部・プラットフォームフロントエンド開発部・Webチームリーダー・認定スクラムマスター（Certiﬁed ScrumMaster®：CSM®）これまでやってきたこと・スマホアプリ開発チームのディレクション・UXデザイン導入支援・ブロックチェーン関連新規プロダクト企画・フロントエンドチームマネジメント兼開発石川県金沢市尾山神社にて

Slide 3

Slide 3 text

© DMM.com プラットフォーム運営部プラットフォーム開発本部 3 ● 「DMM GAMES, FANZA GAMES」というゲームプラットフォームを担当 ● 職能軸とプロダクト軸のマトリクス構造 Web … 本部長副本部長ディレクターデザイナーフロントエンドエンジニアバックエンドエンジニアバックエンドエンジニア有料ゲームディレクターデザイナーフロントエンドエンジニアバックエンドエンジニアアプリディレクターデザイナーフロントエンドエンジニアバックエンドエンジニアプラットフォームインフラ部プラットフォーム札幌システム部プラットフォームシステム部プラットフォームフロントエンド開発部プラットフォームデザイン部プラットフォーム企画制作部

Slide 4

Slide 4 text

© DMM.com Webチーム 4 ● 基本無料ブラウザゲーム領域を担当 ● 職能別チームリーダーが協力してチーム全体の課題解決を担う Web チームリーダーディレクターデザイナーフロントエンドエンジニアバックエンドエンジニアバックエンドエンジニアディレクターデザイナーフロントエンドエンジニアバックエンドエンジニアバックエンドエンジニアディレクターデザイナーフロントエンドエンジニアバックエンドエンジニアバックエンドエンジニアプラットフォームインフラ部プラットフォームデザイン部プラットフォーム企画制作部プラットフォーム札幌システム部プラットフォームシステム部プラットフォームフロントエンド開発部プラットフォーム運営部

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© DMM.com 課題①：開発着手後の手戻り発生デザイナー,フロントエンドエンジニアが仕様検討に関わるタイミングが遅く、開発着手後に手戻りが発生 ※より良い解決策の検討を諦めてそのまま進行する場合もあり... 7 仕様検討段階設計・開発段階この案件の開発をお願いできますか？ ※ワイヤーフレームあり了解です！ちなみに〜についてはいかがですか？であれば、こんな解決策はどうですか？フロントエンド側も関わりそうなので相談です！バックエンドは先行して着手してます！ディレクター ⇔ バックエンドエンジニアバックエンドエンジニア ⇔ フロントエンドエンジニアなるほど。この目的に沿った場合、別の解決策もありそう。デザイナーにも相談してみますね。この機能の実装ってデザイナー的にはどうですか？フロントエンドエンジニアとしては...と考えているのですがフロントエンドエンジニア ⇔ デザイナーなるほど。新しい解決策を思いついたので、ディレクターに提案してみます！手戻り

Slide 8

Slide 8 text

© DMM.com 解決策：開発プロセスの変更仕様検討段階から各職能がキャッチアップできる仕組みに変更 8 仕様検討段階チームリーダー層案件割り振りMTG ● 案件の目的と内容,解決策の方向性について認識合わせ ● 案件ごとに必要な各職能のメンバーをアサイン設計・開発段階案件MTG 案件メンバー ● キックオフ時に案件に関する質疑応答を実施 ● それぞれの職能の専門性を活かしてベストな解決策を検討 ● 他職能の困りごとも積極的にサポート注意すべきことは、ごく当たり前のルールであるが、どのような問題にしても、生産プロセスの中で、できるかぎり、”価値が最低”の段階で問題を発見して解決すべきだということである引用元：HIGH OUTPUT MANAGEMENT 詳細な設計や開発が進むと投下したコストが高くなっていく

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© DMM.com 課題②：職能ごとにドキュメント,連絡手段が散逸 • 職能ごとにドキュメントが存在し、プロダクトに紐づく情報を探しづらい • 職能ごとに連絡手段が散逸しており、コミュニケーションしづらい 10 PFシステム部ドキュメント PF札幌システム部ドキュメント PFデザイン部ドキュメント PFフロントエンド開発部ドキュメント PF企画制作部ドキュメントドキュメント（Conﬂuence）の散逸 #olg-pf-web_ des-fe-sys #team-エンハンス_all #team-エンハンス_dir-des 連絡手段（Slack）の散逸プロダクトに紐づく情報を探しにくい... この情報って別のコンフルでも見たけどどの情報が最新なんだろう... #team-olg pf_dir-sys 目的が重複していたり、クローズドなチャンネルもあったり... この案件のやりとりどのチャンネルでしてたっけ...

Slide 11

Slide 11 text

© DMM.com 解決策：Webチームとしてドキュメント,連絡手段を整備 11 • 共通スペースを用意し、プロダクトに紐づく情報を集約 • 定常的な連絡手段, 案件ごとの連絡手段を整理 Webチームドキュメント（Conﬂuence）の整備連絡手段（Slack）の整備管理者向けサイトユーザー向けサイトデザイン領域フロントエンド領域カテゴリチャンネル目的 Web web-all 全体に関するやりとり Web web-develop 開発に関するやりとり Web web-leader 各職能リーダーの課題解決やりとり Web ・・・・・・案件 prj-案件名「案件名」に関するやりとり案件・・・・・・プロダクトに紐づく情報を探しやすい！各職能で協力して情報の重複を少しずつ解消していこう目的ごとにチャンネルが整理されたチャンネルは基本的にオープン案件のやりとりは案件チャンネルで！・・・・・・

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© DMM.com 1.理想を擦り合わせ、現状からそこに至るまでの段階を描く 14 お互いについての理解を深めることと、チームの機能性を高めていくことを段階で捉える。どちらも一気に仕上がることはない。チームがどういう段階にあるかを把握し、 “次の段階”に向けて、“今何をするべきか”を講じる。引用元：チーム・ジャーニー逆境を越える、変化に強いチームをつくりあげるまで現状（ASIS）理想（TOBE）職能割りでのチーム運営プロダクト割りでのチーム運営チーム運営体制時間第〜段階

Slide 15

Slide 15 text

© DMM.com 2.チームとしてエンジニアリング（不確実性の削減）に取り組む 15 不確実性方法不確実性目的不確実性通信不確実性誰かの曖昧な要求からスタートし、それが具体的で明確な何かに変わっていく過程が実現で、その過程のすべてがエンジニアリングという行為です。つまり、「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答えでもあるのです。引用元：エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング要因将来がわからない他人とのコミュニケーションの失敗や不足削減方法将来がわからない Webチーム取り組み ①仕様検討段階から職能横断で取り組むことで、仮説検証の議論の際に解決策のバリエーションが増えた ②ドキュメント,連絡手段を整理することで、コミュニケーションが改善スケジュール予測と見積もりの手法振り返りの手法要求と仮説検証の手法

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© DMM.com 個人的な取り組み：組織横断的に有志と輪読会を開催理想を擦り合わせるには会話のプロトコルを合わせる必要がある • アジャイルとは,不確実性とは etc. 17 プラットフォーム開発本部全体のエンジニアリング力の向上組織横断的に有志と輪読会開催 • 「エンジニアリング組織論への招待」 • 「オブジェクト指向UIデザイン」 • 「チーム・ジャーニー」 • 「DMM.comを支えるデータ駆動戦略」書籍の内容や自身の取り組みについて会話することで、徐々に会話のプロトコルが合ってくる