Cybozu Tech Meetup #4 15年目プロダクトの開発スピードを上げる取り組み - connpass
ハッシュタグ ：#CybozuTech
アーカイブは後日公開。
トークメモ
生産性向上チーム
開発基盤や生産性向上取り組み、CI/CDの整備などを行う。
複数のチームが一つの Jenkins を利用。
Jenkins みんなで触ると壊れたり、誰もメンテできない状態へ。
整備専用の人がいないので、工数を避けない問題が発生。
生産性の改善は必要だと分かっていても、チーム全体で取り組むにはハードルが高い。
問題意識を持つ人がいても、それだけでは改善は難しい。
通常のプロダクト業務と、改善業務を兼務をして両方をうまくつなぐ。
結果的には生産性向上チームの深いサポートを受けられるようにする。
QA
生産性向上の改善コストや開発費全体でみてどのぐらいの割合でしょうか？コストをかけても改善すべきか参考にしたいです。
CircleCI / AWS などチーム全体からでも気軽に使えるクラウド整備なども行っている。
1スプリント=1W で、1〜２割が改善業務。
ユーザーにプロダクトの価値を届ける部分が本質なので、その程度の割合を改善業務に使っている。
専属の改善仕事人(改善チーム)がいる場合と専属はいないけどチームで改善を継続するのとどっちが長続きしやすいとお考えでしょうか？
ちょっとした改善は現場でできる。
大きな工数がかかる大変なものがある場合は、専属がいるとやりやすい。
改善をすべて専属チームに投げると続かないと思う。
生産性がどれくらい向上したかをうまく測定する方法があれば教えて欲しいです！（定量的・定性的どちらでも）
チーム立ち上げたときからの課題。
定量的に時間を測って改善を見える化するのは簡単だけど、それを続けるのは難しい。
定性的に辛いと感じているとかの方が問題なので、定性的に辛くない状態を作る。
開発者が辛くてやめられる方がダメージでかい。
定量的に出せないと納得感は出せないが、この問題の答えは出ていない。
新しいことに対する心理的障害を下げる工夫を教えていただけると嬉しいです＞＜
個人かチームかわからないが、個人としては...
QAエンジニアをやっていて、伝統的な品質保証を学んだので、違う系列（XPとかアジャイルとか）が見えてきた。
その両方を身に着けたいと感じて、その先の CI/CD を学びたくなった。
新しいことを取り組んだ気持ちはなく、結果としてそうなった。
スクラムチームで毎週振返り、スプリントレビューなど情報共有の場があったのは大きい。
それを利用して周りを巻き込んだ。
所感
ジェンキンスおじさんがいないとメンテできなくなるだろうし、その解決のために専属や兼務、CircleCI などマネージドサービスの利用はいい改善案だと感じました。
兼務しているからこそ辛いところがわかって、改善にも時間がかけられるいいサイクルになっていそうです。
誰かが拾うべき隙間の仕事を業務としてちゃんとやる状況は大事ですし、評価されるべきと思います。
