Cybozu Tech Conference 2017に行ってきました
詳細は公開されているスライドで...
https://cybozu.connpass.com/event/70374/presentation/
チームワークあふれる働き方を目指して -サイボウズが歩んだスクラム導入の道- 天野 祐介氏
以下の状況を改善するためにスクラムを始めた
- 開発メンバーの立場は3種類。プロダクトマネージャ / プログラマ / QAエンジニア(試験設計、テスト)
- それぞれ別の部署から集まり、ドキュメントで情報共有していた
- 意味不明な要求、常態化した残業、不具合が減らない → エンジニアの評判が社内で落ちていく → 3ヶ月毎にデスマーチ
- 納期に間に合わせるために残業、コードに妥協する
- レガシーコードに苦しめられている
いろんな本を読んだ
- アジャイルとかスクラムをキーワードにいろいろ調べた結果、スクラムが現状を解決してくれるのではと思った
- 当時は標準化された開発プロセスは無く、チーム毎に自由だった
- 自分から周りを説得していき合意を得て、スクラムマスターとして働くようになった
「共通の理想を持つ」ということを大切にした
- 当時、組織がバラバラなので。協力し合う仲間なんだという共通の認識を持ってほしかった
- プロダクト開発チームがどんな感じだったらいいのか、ランチミーティングでそれぞれの状況を共有しあったりした
スクラム導入 1スプリント目
- 工数インパクトを抑えるため、スクラムマスターはエンジニアと兼務
- 全員素人でスプリント第一回目をやって盛大に爆死する
- 残業しまくり、スクラムマスターという名の、ただメンバーを激詰めする人になっていた
- プログラマ兼務だったので、木を見て森をみずのスクラムマスターになってしまった
- スプリント1回目の爆死の後、「http://www.ryuzee.com/training_scrum/」をチーム全体で受講した
スクラム導入 2スプリント以降
- これまで3ヶ月かけてやっていたことをを2週間の1スプリントにはまとめられなかったので、工程を分けスクラムイベントだけは守るようにした
- 機能開発が1、2スプリント → 試験/改修を3、4スプリント 1割程度 機能開発
- スクラムチェックリストでみんなでチェックするようになった
- Readyの定義とDoneの定義をチーム内で明確にした
- 不具合を修正する際は、チームとして直すべき不具合はなにか、メンバー全員で話し合い優先度を決めた
- 試験のプロセスも変える必要があった
- DevQAトークナイト
- QAメンバーも慣れてきたので、機能開発50% 試験50%。前スプリントで機能開発したものを、次スプリントでテストするようになった
- 6スプリントくらいから、KAIZENスプリントもできるようになってきた
- メンバーが各自好きなものを自由に選んで改善活動を行う
- 終わらないという状況について、評価が下がるわけではないことをメンバー内で確認し合った
- 不確実性について
- 調査の工数を別で確保するようにした
- 2017/11月時点で1スプリントの内訳は機能開発 70% 試験 15% KAIZEN 15%
開発組織全体への普及活動
まずは「スクラムトレーニング」を受ける
- マネージャも含め、全員が知識として持っている、という状態を作った
- スプリント1回目で爆死したおかげで他組織への導入はスムーズだった
- 1人知っているだけで全然違う
- 海外拠点(ベトナム、上海)のメンバーも現地で開催されているトレーニングを受講し、全社的な標準プロセスになった
- 組織に浸透して、スクラムの用語が共通言語になっていった
- スプリント1回目で爆死したおかげで他組織への導入はスムーズだった
ビジネス部門(営業や総務)からの相談
- リーンスタートアップはもともとは経営の話だし、カンバンはトヨタの生産方式でITに限った話ではない
- カンバンを使用した業務の見える化と振り返りをビジネス部門に共有した
スクラムを導入した結果
- リリースサイクルは3ヶ月 → 1ヶ月に
- 不具合報告数は7割減
- ビジネスインパクトとしてはkintoneのお試しからの契約率38％向上
チームの働き方の変化
- 残業がほとんどなくなった
- ロールを越えた、頻繁で迅速な相談ができるようになった
- 計画を達成したらのんびり過ごす
- KAIZEN活動したり
- 一週間単位の休暇を取れるようになった
チームワークを発揮する
- ペアやモブが普通になってきた
- ブランチ切ったりとかをみんなで新人の前でやってみたり
- リモートのメンバーと常時接続端末
まとめ
- チームワークを改善するためにスクラムを入れた
- スクラムマスターはチームワークを改善するためにいる、と捉えている
他
- Nexus(大規模アジャイル開発)を参考にして、チームの分割を検討した
- マネージャや管理者に理解があって導入に承認は簡単だった
開発文化を育て、広げる愉しみ - 海外拠点Kanban導入記 - 横田 智哉氏
タスクを依頼しにくい...誰がなにをやっているのかわからない... → カンバン方式の導入
- サイボウズはクラウドサービス化の前は、開発文化がなかった
「開発文化はビジネスを支える重要なファクター」としている
導入のしたもの及び失敗談
- ボトルネックを解消しないか開発文化は廃れる。無理に作ろうとしてもだめ
- ユニットテストを広めようとしたけどだめだった。当時としては不要だった
ボトルネックを解消できる開発文化は、みんなに大切にされる
全員参加型の勉強会の開催
勉強会を利用して問題意識を共有した
- カンバン仕事術の本使った
- 開発文化には「なぜxxx?」の共感が必要不可欠
- KANBANの最初はホワイトボードを作った。メンバーで相談しあって独自の仕様にしていった
- 最初に知識をつけすぎると、理想と現実の差に気づいて疲れてくる、取捨選択して小さく始める
- KANBANでチームメンバーの協業が進む
- AさんのWIPが多いから代わりにやってあげる
- レビュアーを工夫する
- TODO DOING DONE
- レビューが終わると別のTODOが始まるが、レビューが返ってくると辛い
- TODO DOING REVIEW DONEにして、アバターを用意してタスク上限を設定した
発表者にした相談、質問
- 事業部や不具合の調査など、機能開発以外の対応をどのように進めているのか？(基本的にはメンバーには機能開発に専念してほしい)
- → 開発メンバーにはエンジニアリング、機能開発に専念してもらう為に、メンテチームのメンバー、チーム内のメンテ担当をアサインしている
- もしくはスクラムマスターが一次受けで調査する。開発メンバーには調査させない
- メンテチームメンバーが問い合わせなどへの調査を行なう体制になっている
- メンテチームで対応ができない場合は、チームメンバーをアサインするが、全てカンバンに記載して、そのメンバーが機能開発外の作業を行なっていることをオープンにする
- この人は今これに時間を取っているんだ、これで機能開発が遅れてしまっているんだ、ということを明示する
エンジニアとOSSコミュニティ 小崎 資広氏, 武内 覚氏／モデレータ：風穴 江氏
- OSS活動は手段
- パネルディスカッション
- 発表者に質問していたので半分以上聞いていない...
最高のリモート開発を実現するために取り組んでいること 岡田 勇樹氏, 水戸 将弥氏, 青野 誠氏, 青木 哲朗氏
- パネルディスカッション
- １つのチームメンバーが、複数の拠点で勤務している
- 在宅勤務含む
- リモートアクセス
- 震災後、社員全員が一度は在宅勤務、リモートアクセスを経験しそこから少しずつ広がっていった
- 給与評価は市場価値で決めている
- 給与交渉に転職ドラフトを使った人も
- 新卒採用も幅を持たせている
- テレビ会議はpolycom + skype for buisiness
- 今はciscoのシスコミ？
- 在宅勤務でも、テレビ会議に参加できる
リモート接続
- 基本は会社にPCに接続してから
- ICカードを貸与して、IPSec AP
組織横断でエンジニアを支援する生産性向上チームの役割（仮） 宮田 淳平氏
サイボウズの生産性向上チームについて
- 機能開発の片手間なのでその場しのぎになりがち！
- 各チームが似たような試行錯誤をしている
- ノウハウが共有されない
生産性向上チームを作り、開発基盤の整備、自動化、効率化の支援を行なうようにした
組織横断チーム
- 組織横断チームは「つくってみたけど、やっぱやめました」が多い
- 開発部 品質保証部、PM部
- 職能側組織で、近い立場の人が多いので成長しやすい
- 部署間のオーバーヘッドが大きい
- プロダクトチーム + プロダクト横断型のチーム(フロントエンドとか、生産性向上とか)
- プロダクトチームが中心になるのは間違いない
エンジニア評価・給与 佐藤 鉄平氏, 三苫 亮氏
- サイボウズは市場価値の確認のため転職ドラフトの結果を給与を決める際の参考にしてくれる
- 「人事は各エンジニアの相場観は把握していない」という認識から