サービスリニューアルからのチームの変遷

Copyright EDGE, Inc. All Rights Reserved
サービスリニューアルからの
チームの変遷
2017/7/11 Gaiax Tech Meetup エンジニア交流会

自己紹介
• 渡部幸紀 / @wantonbe
• 経歴
• 2003年から受託系の会社でエンジニア
• 2013/9 Gaiax 入社 → 2017/4 EDGE株式会社転籍
• エンジニア → Manager / PO → エンジニア

今日話すこと
• サービスリニューアルからのチームの変遷
• 子会社からしてからのチームの変遷

会社紹介

会社紹介
2017年4月株式会社ガイアックス100%子会社としてスタート
ガイアックス内で2006年よりSNS事業開始
人はもっと輝ける
キャッチコピー
事業ミッション
人材育成
・モチベーション向上
・優秀人財の定着

事業紹介
内定者フォロー、新入社員研修、OJT支援
企業用SNS、コミニュケーションツール
内定辞退の防止・入社後の活躍フォロー・人事業務効率化

内定辞退者の減少割合
23%
内定者フォロー業務
26%減少
事業紹介

企業内活性化・社内共有ナレッジ
産休・育休中の情報共有、復帰サポート
事業紹介

宣伝終わり

サービスリニューアルからの
チームの変遷

リニューアルプロジェクト
• サービス拡大のために2012年からスタート
• UIの刷新＆機能のブラッシュアップ
• リリース半年前くらいから結構なデスマ状態
• それでもなんとか頑張って2014年3月にリリース

リリース後の課題
• 相次ぐチームメンバーの入れ替え
• たまらないノウハウ、業務の線引き
• たまり続ける技術負債
• 進まない進捗
• 社内受託のチーム

課題:相次ぐチームメンバーの入れ替え
• 出て入っての繰り返し
• そもそもメンバーのことをよく知らないままやってる
• 人を入れるだけでは何も生まれない

チームビルデイング
• ロングミーティングでお互いを知る
• チームで成し遂げたいことを合意
• 1回だけじゃなくて定期的に何回も実施

課題:たまらないノウハウ、業務の線引き
• たまらないノウハウ
• XX さんしかできない
• その人がやめちゃったら誰もできない
• 業務の線引き
• テストはQAの仕事、運用なんてしらんっていう姿勢
• 開発がきちんと作って出してこない

すべてペア作業
• 開発 / QAという分業を廃止。全員で開発チーム
• 運用もチームで持つ
• バスファクターを大きくする
• 品質向上は開発チームの責任（QAという職種ではできない）
• その人しかできない、という状態を避ける

課題: たまり続ける技術負債
• 使われてないコード / 重複したコード
• うごかないテスト
• 頑張る運用
• 引き継がれる秘伝のタレ

テスト導入とリファクタリング
• そもそもアプローチ方法を知らなかったので、有識者に習う
• 習ったことをチームで実践していく
• 改修・追加で触るときにリファクタリングする
• CIで毎日テスト実行、状態を可視化
• 基本的にペア作業で実施

課題: 進まない進捗
• いつまでたっても終わらないタスク
• ていうかそのタスクって具体的になにやるの？
• 待ちが発生しても担当しかできない
• 開発が終わってからリリースまで儀式が必要

開発プロセスの変更
• タスクの可視化
• カンバン
• 終わらせることを始めよう
• リリースまでの流れを視覚化＆見直し
• 儀式はなくしていく
• Value Stream Mapping
• すべてペア作業

課題: 社内受託の開発チーム
• 偉い人の言う通りに動く
• マネージャー
• 社長
• 営業担当
• 理由不明の機能要望開発
• 機能要望だけがあがってきて、只々つくる

サービスに取り組むチームへ
• 権限の再確認と委譲
• 自分たちが動けるように権限と期待を擦り合わせる
• デリゲーションポーカー
• 要求は機能についてではなくて実現したいことを話す
• ゴールデンサークル
• その要求は誰のため？を明確にする
• 言われたことをやるだけではなく、チームからも提案

やってみて
• チームビルディングと定期的なリフレーミングでチーム力UP
• ペア作業による守備範囲の拡大と安心感を得る
• テストとリファクタリングでメンテナンスしやすいコードに
• タスクの明確化・可視化で状況をわかるように
• 儀式の撤廃でスピードアップ
• 開発チームで意思決定ができる

開発チームはよくなりました

めでたし、めでたし

で、終わりではない

• 開発チームだけよければそれでいいのか？
• 会社全体を俯瞰してみるとまだできることはある

新たな課題
• メンバーがサービスのことを知らない
• 競合の追い上げ
• 他チームへの無関心

課題: メンバーがサービスのことを知らない
• 新メンバーに機能のことが伝わってない
• 昔からいるメンバーも
• そもそも何でその機能があるのかわからない
• そもそもどうやって活用するのかわからない
• そもそも自分たちのサービスを使っていない

ドッグフーディグ
• 自分たちのサービスを自分たちで本気で使ってみる
• 営業チームが顧客に提案していることを実践する
• 他のサービスはなんでそうなっているのか気づく
• 不便だと思うことでアイディアが生まれる
• ドッグフーディング中の不備・指摘はチャンス

おさわり会
• 機能の説明ではなくて、実際にユーザーが実現したいことをお題に、
どの機能をどう操作すればいいのかを発表しあう
• サービスをよく知っている人だから正しい、ということもない
• サービスをよく知らない人の方がユーザーに近い
• 正しいことの共有、新しい視点からの気付き

課題: 競合の追い上げ
• 業界No1はいつの話？
• 気がついたら競合と機能の差がなくなっている
• 価格勝負になって負ける

競合を意識しながらの戦略
• まず敵を知る
• ピンポイントよりちょっと広く調べる
• 実際に競合のサービスも使ってみる
• 競合より早く出す
• 出してしまった方が事業戦略的なメリットが多い
• フィードバックを受けてすぐに改善
• No1 なんて一時的。先に出してもすぐに追いつかれる
• 顧客の声を聞ける環境を生かす

課題:他チームへの無関心
• 開発したものを共有しても伝わってない
• バグがあっても怒られない
• 売り上げ数字未達でも誰も突っ込まない、手を差し伸べない
• 問い合わせの内容を共有されても聞き流す
• 自己防衛のための無関心さ

全員でプロダクトを作っている意識
• 自分たちの立場からできることを考える
• 営業に使える武器と使い方を渡す
• サポート、営業からの指摘は一番の宝
• 忙しそうでも巻き込む
• 目的を履き違えない
• 自分たちだけどんなにうまくやってても儲からなければダメ
• 嫌な空気になると思っても言いたいことはハッキリ伝える

やってみて
• 自分たちのサービスは自分たちが一番のユーザーに
• 知らない人からほど良い意見が出てくる
• 開発だからこそ競合を意識する必要性
• 全員で目標達成を目指す雰囲気に

まとめ
• サービスをつくっていく上で開発チームがよくなることは必須
• とはいえ開発チームだけがよくまわってるだけでは事業は伸びない
• 開発、営業、サポート、ステークホルダーでプロダクトを作っている意
識でやっていく

サービスリニューアルからのチームの変遷

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (12)

Similaire à サービスリニューアルからのチームの変遷

Similaire à サービスリニューアルからのチームの変遷 (20)