【勉強会メモ】Cybozu Tech Conference 2017
- 日時：2017/12/02(土) 13:00 〜 20:00
- 場所：サイボウズ株式会社（大阪オフィス）
サイボウズさんのテックカンファレンスに参加。内容的には改善系の取り組みの話が多かったように思う。長年使われてレガシーになったシステムやコードとの向き合い方、組織が大きくなる中で出てきた課題との向き合い方という観点では自分の現状もにている面がありとても参考になった。LTありの懇親会も参加したかったが所用により本編終了でタイムオーバーとなり帰宅。
- チームワークあふれる働き方を目指して -サイボウズが歩んだスクラム導入の道-
- 開発文化を育て、広げる愉しみ - 海外拠点Kanban導入記 -
- エンジニアとOSSコミュニティ
- 最高のリモート開発を実現するために取り組んでいること
- 組織横断でエンジニアを支援する生産性向上チームの役割
- Salary negotiation battle on Cybozu （サイボウズの給与交渉戦）
個人的に特に参考になった部分をざっくりピックアップしておく。
- スクラム
- 開発文化
- ボトルネックの観点の重要性を改めて認識
- 全員を巻き込むというより巻き込めないようなら文化としては定着できないということだと理解
- スモールスタートも同様でまずできる状態にすることが重要
- OSSコミュニティへの参加
- リモート環境
- このセッション自体が東京・大阪・愛媛をまたいでのセッションだったが何のストレスもなかった
- 在宅、ベトナム・上海も同じTV会議に参加できる環境が整っている
- 快適なリモートワーク環境を実現するにはこれくらい環境を整える必要があると認識
- 生産性向上の組織横断チーム
- 組織横断チームはノウハウの集約と共有が最大のメリット
- 横断チームとしての価値が理解されないと継続が難しそう
- 給与交渉
- セッションの中でも少し触れられていたが社外的価値を知るためだけに転職系サービスを利用するのはまずいのでそれなりにパワーが必要
- 社外的価値と社内的価値のすり合わせのプロセスという印象
- 交渉は大変そうだがその過程で社員側、企業側双方に得られるものはある
チームワークあふれる働き方を目指して -サイボウズが歩んだスクラム導入の道-
スピーカー：天野 祐介さん
www.slideshare.net
- 現在の開発プロセス…昔からの慣習、都度議論した結果
まわりを説得すればスクラムを開始できそう
最初は盛大に爆死
- いきなり2チーム制
- スクラムマスター⇒激詰めおじさん
2017年2月：実装期間1.5ヶ月、試験1.5ヶ月
- 3ヶ月で2週間ごとのスプリント
スクラムのチェックリストを活用
社外の勉強会で人とつながる
2017年5月：実装期間を1ヶ月に短縮
チームとして本当に治すべき不具合を減らす
- 優先度高…120件
- 優先度低…1000件
試験のプロセスをどう変えるか
DevQAトークナイト by 永田氏
www.slideshare.net
2017年8月：最後の1回はKAiZENスプリント
- 機能開発は徐々に減らして試験の割合を増やす
失敗から学ぶ
不確実性を管理する
- 気をつけるとかふわっとしたTryが出る
- 見積もりがこれぐらいだったらそのタスクは危険などがわかるようになる
- 終わらないかもしれない⇒終わらなかったらどうするか考える
ゼロバグ時代到来
2017年11月：実装7割、試験＆改修3割
- 後半はバグが減って試験＆改修の半分をKAIZENタスクに
開発組織全体への普及
- スクラムトレーニングを全員受ける
コーチとしての一歩を踏み出す
- スクラム導入したいチームのお手伝い
- 後から入ったメンバーのトレーニング
浸透が進む
- ほとんどの開発チームがスクラムorカンバンを導入
- 海外拠点も現地のトレーナーを見つけて受講
- 事実上の標準プロセスに
開発外にも浸透
- 総務から相談を受ける
- カンバンと朝会を導入
- 業務の見える化と流れの改善
- 営業からも相談
- 興味のある人が聞きに来てくれる
kintone開発チームの成果
- リリースサイクル⇒3ヶ月⇒1ヶ月
- 不具合報告数⇒70%減
- お試しからの契約率⇒38％向上
チームの働き方変化
- 残業がほとんどなくなる
- ロールを超えた頻繁で迅速な相談
- 計画を達成したらのんびり過ごす
- 一週間単位の休暇
- チームで働くことで属人性が排除
チームワーク
- ペアプロ、モブプロが普通に浸透
- ブランチ切る作業
- できるメンバーがちょいちょいとやってしまいがち
- 新人をみんなで囲って全員でやってみる
Q&Aのメモ
- kintoneはこれから2チームでスクラム
- ガルーンは7チームで実施
- マネージャとか組織トップの理解が重要
- 政治的な努力はしなくて済んだ
開発文化を育て、広げる愉しみ - 海外拠点Kanban導入記 -
スピーカー：横田 智哉さん
なぜカンバン？
- マルチプロジェクト担当メンバーが多い
- 誰が何をやっているかわかりにくい
開発文化の歴史
- 年単位の開発・試験スケジュール
- Unit Testがないプロダクト
- 開発Fix前にデイリービルド
クラウド挑戦
- リリース増加
- 不安定な品質と開発工数の爆発
- CI/CDを利用して品質安定化
- 開発効率の向上に積極投資
- 開発支援のための開発文化へ
サイボウズだからうまくいくのか？
- サイボウズでも失敗しながら前進している
- 過去の失敗をネタにする
開発文化を育てるプラクティス
ボトルネックは文化の母
UnitTestを広めようとしたが…
- UnitTestが当たり前の開発体制にしたかった
- 当時の状況ではUnitTestはまだ早かった
⇒UnitTestはボトルネックではなかった（ほかにもっと大きな問題があった）
デイリービルドを自動化
- 大きなボトルネックを解消
開発文化の始まりをはじめよう
- ボトルネックを解消できれば大事にされる
- みんなが大切にするもの⇒継続に必要不可欠
- 開発文化の外に新しい文化がうまれる
- バームクーヘン構造
仲間を増やそう
全員参加型の勉強会を開こう
- 知識のベースラインを揃える
- 勉強会の題材を使って問題意識の共有
- シンプルな原理・原則の理解
上海・日本カンバン勉強会
- 細かい知識よりもカンバンの理解を徹底
- WIP・仕事の流量制限
- 仕事の可視化
カンバン仕事術
- 英語で消耗したくなかったのでそれぞれの言語で（中国語・日本語）
- 書籍の付録のゲームを実践
有識者勉強会を開く⇒×
- 参加者は問題意識がある人なので効果が薄い
- メンバーで知識差が出てしまう
- 理想が共有できない
Small Start
できることをすぐに始めよう
- できるだけシンプルに１週間やってみよう
- Kanbanをすぐに作った
知識を一通り付けてから実践⇒×
- ベストプラクティスだがそのまま適用できない
- 現状と理想の違いに疲弊する
効果的なふりかえり
- 開発文化として定着させるための振り返り
- 原理・原則を意識してふりかえり、改善する
- 効果的な振り返りは褒めるポイントが明確になる
- 原則からプロブレムが見える
ふんわりした振り返りは良くない
- 些末なプロブレムを解決する価値はあるか？
- 複雑な解決策を採用していないか？
KAIZENと守破離
- ふりかえりからKAIZEする
- カンバンの改善
- アバターを作成
- レビュー列を追加
- カンバンの改善
- 組織に合わせた開発文化
- 海外拠点は？
- カルチャーを尊重
- 魚を与えるより魚の釣り方を教えよ
- カンバンの画像を定時にアップロードして拠点に共有
- 管理コストがかからない運用を意識
- 海外拠点は？
福利と再投資
余剰時間を福利として開発文化に再投資していく
- テストの自動化
- 改修後即リリースしたい
よりアジャイルな開発文化へ
Q&Aのメモ
- 余剰時間ができるとそこに仕事を入れられないか？
- 組織の上長の理解
- リファクタ禁止
- チーム全体で主張する
エンジニアとOSSコミュニティ
パネルディスカッション
- モデレータ：風穴 江さん
- 小崎 資広さん
- 武内 覚さん
アンケート：会場のOSSコミュニティの参加者
- 東京：10人くらい
- 大阪：数人
- 松山：1人
コミュニティデビュー
- 元々そのOSSの技術に興味があった
- 業務でもやっていた
- エンジニアとしての成長のため
- エンジニアなので興味のあるものに手をだすべき
- 業務での必要性
- 基本的に得た技術は外へ出したい
企業にとってのメリット
- エンジニアが大きく成長できる
- 違う業種、世界のトップレベルのエンジニアとの関係
- 採用がしやすくなる
- この会社がどういうOSSにコミットしているか分かって間口が広がる
- OSSは口コミのひとつの形態として効果がある（エンジニア向けの効果）
- 有りものを使うかOSSに関わって自分で必要なものを作っていくかの戦略
- OSSはいざという時誰でも直せるというのはうそ。誰も直さない。
- 先頭を走ると地雷を踏む確率は上がるが企業としての強みは増す
- Googel検索できる情報は既に古いのでそうじゃない情報を得られることに価値がある
- デメリットは？
- OSSをやることによって何を得るか？を話す
やりたいけど、やれないジレンマ
- できたらやりたいという人はたくさんいる
最高のリモート開発を実現するために取り組んでいること
- 岡田 勇樹さん
- 水戸 将弥さん
- 青野 誠さん
- 青木 哲朗さん
www.slideshare.net
リモート開発とは？…１つのチームが同じ拠点にいない状況
- 現在…東京、大阪、愛媛メンバー混在チーム
- リリース後の飲み会もリモートで
リモート開発の３つの要件
- ツール
- 精度
- 風土
導入前（2009年）
- 東京・愛媛
- 愛媛で何かやる時は数年単位でエンジニアが行く
導入期（2010〜2011）
- 3種類の働き方選択制度
- 在宅勤務制度
- 承認制…上長の許可が必要
- 利用率低かった（せざるを得ない人が主）
- 震災がきっかけで東京は利用者は増えた
- 意外とできるという実感
- 外部アクセスの機能的向上
- リモートデスクトップ…あまり使い勝手がよくなかった
- 開発はできるけどコミュニケーション面が難しい
成長期前半（2012〜2013）
- 市場価値による評価
- ウルトラワーク
- 一時的に時間や場所を選択
- 働き方選択⇒9分類
- 人ごとに宣言してkintone上で公開
- クラウド開発の高まり
- 開発サイクル短縮
- 問題のキャッチアップと改善を早める
- kintoneの社内活用
- SNSツールの活用がコミュニケーション活性化
- カジュアルなコミュニケーション文化
成長期後半（2014〜2015）
- 情報システム部立ち上げ
- セキュリティ意識の高まり
- テレビ会議システム
成熟期（2016年〜）
- リモート接続
- 社員標準PC
- 5種類からメイン開発機とサブ開発機を２台選択
- モニタも2台まで
- さらにもう1台…在宅用PCと社用スマホも希望者に貸与
- 突発的に在宅勤務するなど、随時持ち運ぶのは大変なので
- 情シス的には管理が大変…
- 働き方9分類⇒分類なし、一人ひとりがその人の働き方を宣言
- 通勤費などの管理大変
Q&Aメモ
- 働きすぎる人は？
- ⇒いない。業務状況はkintoneに書くような管理で把握。
- リモートワークできる人が特別扱いのようになって雰囲気悪くなったりしないか
- 多様性を認める風土がある
組織横断でエンジニアを支援する生産性向上チームの役割
スピーカー：宮田 淳平さん
www.slideshare.net
生産性向上チームができる以前
各チームで開発基盤を整備
- 自動テスト
- CI
- デプロイパイプライン
問題点
- それぞれのチームが似たような試行錯誤
- ノウハウが共有されない
- 片手間でやるのでその場しのぎになりがち
生産性向上チーム設立
- 開発基盤の整備
- 自動化・効率化の支援
最近の活動
リリースプロセス改善
⇒関係者を集めて議論
Artifactoryの活用
JFrog社製アーティファクト管理ツール
結果
- やりとり…100件以上⇒約20件
- リリースとアーカイブが明確に
Jenkins 2.0布教活動
問題点
- Jenkins職人化（GUIでの設定）がつらい
- CercleCIなどの設定ファイル方式が欲しい
Jenkins2.0で求めていた機能
⇒社内に共有して導入の手伝い
Jenkins2.0でも残る問題
CircleCI2.0
- CircleCI1.0⇒2.0への移行のお手伝い
これからの活動
- リリース自動化
- 日常的にリリースを行えるようにしたい（現状は月1回）
- CircleCI Enterprice導入
- kintone on IaaSのお手伝い
- 海外展開を見据えてIaaS上での開発基盤整備
- 脱1人チーム
- 存在を知ってもらい関心をもってもらう
組織横断チームってどう？
サイボウズの組織構造⇒職能型組織＋職能横断型組織
職能型組織
- 開発部、品質保証部など
- マネジメント、育成しやすい
- 同じプロダクトに関わるメンバーでも職能の違いで目標にずれが生じる
- 部署をまたいだコミュニケーションでオーバーヘッドが大きい
職能横断型組織
- プロダクトチームが自立
- 目標に集中しやすい
- 他チームとの標準化、共通基盤整備が進めにくい
プロダクト横断型組織
- 生産性向上、アプリ基盤、モバイル、PSIRT、TE、フロントエンド
- プロダクトチームの自律性を保ちつつ標準化や基盤整備、ノウハウ展開
横断型組織
- 特定のプロダクトに所属しない問題に積極的に取り組める
- 複数チームのノウハウを集約・共有
問題
- マルチタスクになりがち
- あのチームは何をやってるんだ？
対策
- 生産性向上しナイト
- スクラムマスターの会
- フロントエンドランチ
⇒ノウハウの共有がメイン
生産性向上チームは会社の変化に合わせて生まれた横断型組織
Q＆Aメモ
Salary negotiation battle on Cybozu （サイボウズの給与交渉戦）
- 佐藤 鉄平さん
- 三苫 亮さん
給与交渉
- 全員に交渉機会を設けることはない
- やりたい人がやる
サイボウズの評価制度⇒社外的価値と社内的価値の掛け合わせ
- 社外的価値
- 転職したらいくら貰えるか
転職ドラフト⇒材料を揃えて交渉
- ビックマウスで高評価を得たわけではないことをレジュメに書いて交渉
- 事実と解釈を分けて伝える
- 会社にどう変わってほしいかを伝える
- 今後の方向性で合意できるゴールを用意しておく
- 同じ業態での給与のギャップ
- 上がったか下がったかは重要ではない
交渉相手は敵ではない
- しっかり方向性を共有できればあとはおまかせできる信頼関係が重要
Boss Side
社外的価値
- 転職するといくらか？の幅
- ベースとなる給与レンジが決まる
社内的価値
- 信頼＝スキル×覚悟、社内の事情・需給
- レンジの中のどこか
従来の評価手法
- 給与テーブル・役職給⇒定義を決めるのは組織側なので交渉が困難
- 目標管理制度⇒目標設定が恣意的になる
- ビジネス価値につながる？
市場価値ベースだと
- 正規のルートで正々堂々と給与交渉できる
- 外部性が反映される
評価は何のため？
- 給与の決め方
- 成長へのフィードバック
- 組織の目標とのすり合わせ
給与評価と成長フィードバックを分けて考える
