forkwell主催のチーム生産性アップに関するMeetupに行ってきたので備忘録的にまとめ。
個人的な目的とか
- エンジニアと交流する。
- 転職先を探す。
ゲストトーク
クックパッド 勝間亮 氏
Twitter: @ryo_katsuma
ポイント
- マネージャーとしてチームメンバーの成果と成長を支援する。
- 人の顔をよく見るようにしている。顔色が悪い人、声のトーンが明らかに低い人を見つけ、直接話を聞くことができれば、大抵は対策が立てられる。
生産性向上のために実施したこと
- よもやま会
- KAIZENの日
- 先週のよかった！
→ よもやま会
いわゆる 1 on 1 Meeting だが、名前をユルくしてなんでも話してもらえるように。
月に1回程度、1人20〜30分で実施。時間コストが大きいがリターンも大きい。
→ KAIZENの日
1日まるごと何か改善する作業に使う日。
システムの改善はもちろん、最新技術の学習など自分の改善もOK。 ただし、やる前にそれをやるとどうなるのかを具体化してから取り組んでもらう。
→ 先週のよかった！
名前のまま、先週のよかったことを発表してもらう。
自分たちで楽しいことを発見する習慣をつけ、コミュニケーションの促進にもなる。
サイボウズ 宮田淳平 氏
Twitter: @miyajan
www.slideshare.net
ポイント
生産性向上のために実施したこと
- Jenkinsからマイクロサービスへ
- コンテナ＋IaaSによる変化に強い環境構築
→ Jenkinsからマイクロサービスへ
Jenkinsによる自動化では、ボトルネックになっている機能を特定しづらく、発見してもその部分だけ回収したり代替することが難しい。
マイクロサービスで再構成することで、上記の問題を解決することができる。
→ コンテナ＋IaaSによる変化に強い環境構築
コンテナ化しておくことで素早く構築でき、IaaSによるリソースの確保が迅速にできる。
… 以下力尽きたのでメモのみ
ドリコム 大仲能仲 氏
Twitter: @onk
www.slideshare.net
メモ
リリースできない徒労感とPullReqによる疲弊
レビュー →コードフォーマット →メガネを外してレビュー：概観が分かる →セキュリティ →ぱふぉーまんすた担保 など
上記は最低限必要なレビューで本当はもっとユーザー志向のレビューしたい →速度を落とさないためには？ →フォーマットはスタイルガイド、ネスト深いとかは自動でできるよね →セキュリティはフレームワークの性能にある程度頼れるんじゃね？ →パフォーマンス担保は？
コード差分の理由を書いてもらう。 →目的・方針・実装・テスト・相談 →方針：前提条件みたいなもの。除外した選択肢があればそれも。 →相談：自身がないところ、レビューコメントに書いた上で相談する。
不要なレビューを減らす →例）Rubyの仕様を見てほしい。機能仕様はみなくていい。
migrationとroutesでpushしてね →方針段階でチェックできる
設計レビューはMarkdownで書いてもらう
リリースを躊躇しない →リリースしてからが開発の8割 →リリース速度の維持が大切
レビューは新しい価値を作らない。 レビューによってリリースが遅れるのは本末転倒。
レビューでの人間関係にはアンチパターンがある →本：みんなではじめるデザイン批評 レビューは人格攻撃ではない…など →心理的安定性：悪意があってバグをつくっていない
「レビューは取り込むもの」 →一方的に指摘せず、議論して納得して取り込むのが大事 →納得していない状態では次も同じことを繰り返す →納得してもらうために有名な本の引用などを利用する
ルーキーがレビューすると教育効果が高い →二段階レビューを利用する →ルーキーが指摘漏れを認識できる
レビュータイムを作ることでルーキーがレビューせざるを得ないことになる
レビューの基盤 「問題 vs 私達」「空気を導入しない」（例）ベテランだから大丈夫だよね
レビュアーは専門知識が必要なものはBOTが選別している スタイルガイドが全て説明することができたらルーキー卒業
エフ・コード 門田芳典
エンジニアが2人（2016年1月時点） もともとはWebマーケの会社
メモ
ワンチーム化：組織との一体感 →組織構造を少し改善するだけでも変化は起きる
ウォーターフォールは複雑なシステム開発に適さない →品質・納期どちらを優先するのか。操作性？パフォーマンス？どっちが優先？ →スクラム開発の導入 ？エンジニアチームの自己組織化 →プロダクトオーナーと開発側を分けない
採用戦略 →業務系の優秀なエンジニアをターゲット →彼らが一番興味があるであろうScalaでシステムを書き換える
技術顧問ってどうやって採用するの？→社長の同級生だよ！
14:45まで小休止
和田氏は欠席
Forkwell（代打）
メモ
ベロシティを目標にしてはいけない
目先のものに囚われることで - あとでやるが山積み - バグが増える - ポイントを取りに行ってで基準が曖昧になる
アジャイルは元々全力でやっている →目標を使って発破をかけるのはマッチしない →全力でやる中で課題があると考えるのが正しい。
KPT K：Keep P：Problem T：Trouble
☆ベロシティを目標にしなくても生産性はあげられる →定量目標ではなく定性目標でも積み重ねる価値がある。
スカウトサービスに対する不満が続出 →週に100通スカウトメール送るというKPI →一括送信してるからシラネ
スパムスカウトからの解放 →一括送信なし →マッチしないと送信できない →面談の温度感を共有しよう →スパムっぽいスカウトメールを通報するボタン
アトラシアン 長沢智治 氏
アイディアを価値に。 →早ければいいわけではない。 →リードタイム：アイディアが出てからリリースまでの適正期間がある。 例）定期的にリリースすることで、期待感を高めてレスポンスを増やすことができる。
- ブランチ戦略
- ビルド戦略
- デプロイ戦略
戦略は局所的に最適化しても全体で最適かは別
企画・運用メンバーが議論に参加できるタイミングを見極める必要がある。
Q.フィーチャーブランチはどのタイミングでビルドするの？ A.コードを変更したらすぐにビルドしましょう。 →各フィーチャーが常に動くソフトウェアになっている →各フィーチャーブランチがビルドされているので、拾って構築しやすい？
JIRA(PBL) → … → デプロイ → 工程全体の状況をJIRAから一望できる。
エクストーン LT 豊田陽一 氏
エクストーン チーフエンジニア Twitter: @rs_wisteria 会社11年目 エンジニア11名 B2B 受注案件が中心
メモ
会社として大事にしているのは「睡眠」 →集中力・免疫力低下、太りやすくなる？？ →睡眠がだめだと仕事も駄目になり、人生の57％の時間を損している →１．体を動かすとよく眠れる 自転車部を作りたいなー（！） →２．日中に太陽を浴びる 窓が多く日の入るオフィスで仕事ができる。 →３．昼寝をする（１０分くらい） 制度はないが、眠いと勝手に寝る →４．寝る前に脂肪分を取りすぎない。 →５．ストレスを貯めない。
サーバーサイドエンジニアが足りない
おまけ
司会の方がプロのアナウンサーでした。
