Productivity Engineering Vol.3 に参加してみた
10月14日に開催されたProductivity Engineering Vol.3
（チームで生産性アップ）イベントに参加してきました
きっかけは会社の人にこんなイベントがあって島田さんがお話されるよと聞いてその場で申し込みました。 チームを任せてもらう機会も増えてきたのでとても興味があり鍛えていきたい分野です。
発表資料はイベントサイトに挙げてくださっているようなので詳しくはそちらをどうそ。 ここではいくつかメモのとれた発表の紹介したいと思います。
生産性を向上させるチームコミュニケーション カブク 足立さん(@adamrocker)
チームの生産性を上げるには邪魔しないことが大切
- コミュニケーションがチーム効率を阻害する場合がある
- コミュニケーションを乱雑に発生させない
効率を阻害しないコミュニケーションの方法
- CI/CD：自動化してコミュニケーションを発生させない
- 開発プロセスの明確化（スクラム開発）：開発サイクルを定型化
- TODO（依頼）リスト：依頼は特定の場所に突っ込む。依頼で作業を割り込まない非同期）
- 議事録：GoogleDocumentで共同編集。発信した情報が正しく受診されているかその場で確認）
- OpenAPI：API仕様書をドキュメントベースで作成）
- 定例MTG：週1回10分〜20分。Syncと相談
- 評価：3ヶ月に1回の評価面談。正しい評価が生産性に最も影響する
生産性を上げるコミュニケーション
- 価値のないコミュニケーションを最小化
- 価値のあるコミュニケーションを最大化
感想
- コミュニケーションの闇雲に増やしても減らしてもよくなくて難しいなと思ってたのですが分解して分類して省くべきところ、外さないところを整理していくといいかもしれないと思いました。
- 手が回らなくて明確化できていないことが最終的に手間のかかることになったりするので後々楽になることはさっさとやってしまった方が効率上がるなと思いました。
- 議事録はうちの会社もGoogleDocumentで共同編集しながら作ってますが、その場で勘違いを無くせるので便利です。なかなか人前で書くの緊張するのですが色々コスト削減になります。
- 3ヶ月に1回評価面談はすごい。でも確かに目標に向かって取り組めているか半年後に蓋をあけるより途中経過もみつつ軌道修正しつつになるのはいいなと思います。
標準化で立ち上げの生産性UP SHIFT 玉川さん(@nkns165)
現在の体制になる前の問題点
- チームメンバーが物理的にも業務的にもバラバラ
- 知識の偏り
- 新規プロジェクトの立ち上げに時間が
技術の標準化
- 社内標準テンプレート + 各プロジェクトごとに作成
- 標準化メリット
- 皆がはまる「あるある」をクリアにできる
- ちょっとした便利機能を共有できる（なかなか手がまわらいものを提供し素早く立ち上げ）
- 教育も標準化（皆が同じツールを使っているのでノウハウがまとめやすい）
標準があるからこそ冒険もできる
- 空いた工数で先行研究的な活動
課題・これからやりたいこと
- 教育する人の教育
- 標準化とデリバリーのローテーション
感想
- プロジェクトの立ち上げのお話だったのですが自社で新人教育の悩みと同じような悩みがあってそれも新人教育を標準化して解決した経緯があったので近いなーと思っていたらメリット3に出てきて色々応用できることだなと思いました。
- 標準化することでそれ以外の案件ならではのことに注力できるので楽できるところは楽して向き合うところは向き合ってやっていきたくなりました。
生産性を高める 1 on 1 アイリッジ @Satoshi 吉永さん
1on1ミーティングを通じて得た知見
- 一人毎週30分
- マネージャーの役割
- 関係する組織と円滑に業務を遂行する
- 自組織のメンバーの生産性を最大化する
- 1on1の進め方
- 上司は聞き役、部下から話し始めてもらう
- 事前にアジェンダを用意してもらう
- 1on1で話す内容
- 話す内容は人や時期によってそれぞれ。今の案件の困り事から休日の釣りの成果まで様々
- 継続した結果
気づき
- コミュニケーションは頻度が超大事
- 頻度を落とすと関係を戻すのに労力が必要週1はやった方がいい
- 心理的安全性を保つための維持コスト
- 「確保された時間」のありがたさ
テクニック
- 気をつけていること
- 傾聴することに徹する
- スキップではなくリスケ。安易にスキップするような扱いをしない
- フィードバック
- ―言いにくいことを伝えるには信頼関係が構築された状態が必須
- SBI収集（Situation/Behaior/Impact）をおこたらない
- 客観的かつ正確に事実を伝える
- 嫌われることも覚悟
- フィードバックした後が大切。フォローとモニタリングを忘れずに
感想
- 私も心理的安全の確保は大事だと思ってて確保に努めてます。急に話してといっても話してもらえないしそこが（人も含めて）安全な場だって伝えることはとても大事で言葉だけではどうにもならないものな気がしてます。
- 週に1回の頻度を続けるってすごいなと思います。そこで積み重なるものもがあるからフィードバックも効果的な伝え方ができるのかなとも
- SBI収集は怠りがちだったので意識していきたいです。
- おまけで話されてたセルフケア、マネージャー同士での相談大事ですよね。今年になって他社のマネージャーさんとお話したり元気もらってます。
'P' is for Productive えにしテック 島田さん(@snoozer05)
プログラマのための生産性向上術
プロダクティブ・プログラマについて
- 技術
- 4つの原則
- 加速：段取りは最短化
- 集中：今集中したいこと以外は見えなくする
- 自動化：CIちゃんとやる
- 正準化：あちこちで同じ事をしているのはまとめる
- 4つの原則
- 実践
- クオリティを上げることが生産性を上げることに繋がる
- 自然な方法で成長するものはフラクタル(部分と全体が自己相似)性がある
- 組織・チーム・個人・コードには自己相似がある
- 今日のコードの質をあげることが明日の生産性につながる
エラスティックリーダーシップモデルについて
- チームに3つのモードがある。その状態によってよりよい状態へのアプローチは変わる
- サバイバルモード（指揮統制方）：ゆとりがない
- 学習モード（コーチ／独裁者）：ゆとりを使う
- 自己組織化モード（ファシリテーター）：ここちよくないところに置いてチャレンジさせる
- どのレイヤーにも当てはまるのが「今日の品質を上げることが明日の生産性を上げる」
- Productiveは効率化だけでなく、自分の中のものを導き出す。そうして前へと導き出されるものがProduct
感想
- 個人でやるときもチームでやるとこきも、仕事でやるときもプライベートでやるときもどんなこともで似てる、応用できるんじゃないかと思いながらやってるので「自己相似」はストンときました。
- 『今日の品質を上げることが明日の生産性を上げる』という言葉が印象的でした。やっぱりコツコツ積み上げていくこと大事だしとても勇気をいただけました。
交流タイム
参加者の大半がJavaかPHPやってる人で普段RubyKaigiとかRails関連のイベントにしか参加していないのでこういうのは新鮮でした。 交流タイムでふらふらしてたりやスポンサーブース歩いてるとRubyされてるんですかと声をかけていただくことが多くありがたかったです。Rubyやってる人、始めた頃に比べたらとても増えた気がするんですがまだまだ少ないことを思い出しました。
色々収穫多いイベントでした。ありがとうございました。
イベントのその後
発表の中で紹介されていたこの2冊を買ってみました。読んだらまたブログを書きたいと思います。
初めての自動テスト ―Webシステムのための自動テスト基礎
posted with amazlet at 17.10.18
エラスティックリーダーシップ ―自己組織化チームの育て方
posted with amazlet at 17.10.18
