3/3 チームの生産性を改善するために決断疲れを最小化する #tryswiftconf
try!Swiftのセッションまとめシリーズです。Derek Leeさんの「Minimizing Decision Fatigue to Improve Team Productivity」についての記事になります。
資料
www.slideshare.net
内容
テーマ
- 生産性を上げるために決断疲れを減らす
- 精神的な疲れをどうしたら減らすことができるか
決断疲れ
- ソフトウェアエンジニアは常にキーを打つ度に意思決定を行っている
- 0から構築するかライブラリを探すか
- CocoaPodsかCarthageか
- viewをどう描くか
- これら決定は小さなことのように思えるが集中しないと決断できない
- 選択肢の中でも努力のいらないものを選んでしまったり選択を避けてしまったりする
- みんな意思決定するがコミュニケーションを取る
- 意思がたまたま合致するということは起こらない
- 結果だけ伝えるということになると疲労が生まれる
- すると単純なミスを犯して思わぬところにインパクトが出る
どうやったら疲労を減らし重要な決定を行えるのか
- 意思決定をシンプルにする
- エンジニアリングだけではないカバーも行う
朝ごはんの決定
- Pivotalではこの決断は必要なく、提供される
- いい朝ごはんを食べる必要がある
朝礼(9:06)
- 新しいメンバー、お客さん紹介
- 助けが必要な人の申し出
- 興味深い話題
朝礼(9:15)
- プロジェクト向けの朝礼
- 前日なにが怒ったか、今日何やるか
- 時間がかかったなどの話があったら話し合った方が良さそう
プロジェクトの組織化
- どこにファイルを入れればいいのか
- ファイルをどう見つけるか
- ファイルの名前がわかればタイプインすればいい
- なぜファイルが置かれている場所が重要なのか
- 知らないところの作業をしているとき困る
- 自分が考えているより長い時間を費やすことになる
- 一定の組織化が必要という話になった
- ヘルパーのような一般的な名前だと検討がつきにくい
- MVCつかったら？
- フィットしないものを入れた時それを特定するのは難しい
- Application, Components, UIを用意してみた
- Applicationフォルダ
- アプリを実行するために必要なもの
- AppDelegate, Main , LaunchScreen.storyboardなど
- 日常触らないもの
- Componentsフォルダ
- コンポーネントごとに区分け
- モデルオブジェクト、パーサーもここに入る
- UIフォルダ
- 個々のビジュアルスクリーンを入れている
- 特定のVCに関連したものがあれば含めていく
- 新しいファイルを足す時にあまり考えなくていい
- テスティングフォルダも同じ形に整備
- Applicationフォルダ
プログラミング(10:00)
- エクストリームプログラミングを実施している
- テスト駆動、CI、ペアプロによってコミュニケーション高められた
- ペアプロ
- やったことがあったものの経験したスタイルとかなり違った
- Mac2台並べて全く同じコンテンツが見られるようにしている
- ピンポンプログラミング
- 順番にプログラミングを行う
- ドライバーとナビゲータのスタイル
- より経験のある人がナビゲータとなりコードは書かず教える
- 新しいメンバーが入った時に適している
- 共通の理解を持つために出来る限り一緒に作業する
- エンジニアだけでなくあらゆる職種の人たちとやる
- チーム全体を通じてコードを共有
- 自分のコードだけに注力することをなくす
- すぐにフィードバックが返ってきて、意思決定がすぐ行える
昼食(12:30)
- ケータリングでランチを取りつつテックトークを開く
- プレゼンがスケジュールされていなければ動画を見る
ペアプロ続き(1:30)
- 週1,2回プランニングのMTGをすることも
- 一貫性を保つためにどうしたらいいか
- 馴染みのない領域にふみこむことも
- VC開いて新しいオブジェクトをどこに入れるのか
- Contl+6で全体を見渡す
- 自分の求めているものが見つかるようにセクション化していく
- アノテーションを付けて見やすくする
//MARK: -があると理解しやすい- 横の線が入っている事によって読みやすい
- 自動化したいと思うところもあるかも
- 新しいVCの作成は一定の自動化できるかも
- スニペットでコード挿入実現
- プロトコル
- プロパティーとイニシャライザから書き始める
- プライベートメソッドは下にまとめる
- 何がどこに入るのか見つけやすくなる
- 新人もどこに新しいコード入れればいいのかわかりやすい
休憩(3:30)
- 卓球をしている
- 頭を切り替えられる
- 新鮮な視点をえることができる
クロスプランニング(4:00)
- 担当分野だけではなく担当分野間の話も
UIオブジェクトのスタイリング
- スタイルの定義は一つにする
- フォントの定義
- カラーはextensionで定義していく
- OKとキャンセル
- フォントのサイズだったりUIボタンに対して適応していくことができる
- UIButtonそのものに対するextension
- 列挙型を使っていく
1週間の終わりの金曜(5:00)
- 振り返りのMTG
- コアチームメンバー全員
- 食事、飲み物も提供する
- 特に1週間どう思ったかの感情を重視する
- keep, discuss,improveに分けて思ったことを書く
- ファシリテーターはボランティアでポジティブになるように進めていく
- 誰でも安心して意見を表明できる
- 一緒にブレストして解決していく
- 良いことも悪いことも振り返る
まとめ
- チームのコミュニケーションの改善の仕方を紹介した
- 連携を高められれば開発プロセスの効率化ができる
- チームの人間が小さな意思決定を効率化していくことは将来にとって有効
- どうやったら効率的にできるのかを考えてみてください
- 何回も反復されるようであればどう自動化できるか考えてみてください
- 個人、チームの意思決定の数も減っていき、より重要な意思決定に時間を割ける
Q&A
バランスの質問について。働いている時の快適さは大事だと思うが終始2人の一貫性を保つことが必要なのか
リモートで働いているのでペアプロ難しいが、良いアイディアがあれば
開発者が奇数の場合は？
- 1人は残念ながら残される
- ゲットデューイット？というツールを使っている
- 朝は一人でも午後にはペアになるなどの対応をしている
- 頻繁にペアリングを変えるようにしている
- ペアがいなかったら小さなタスクをやったりする
その他このトークに関する情報源
- チームの生産性を改善するために決断疲れを最小化する | try! Swift Tokyo 2017 #tryswiftconf Day2-12 聞き起こし - niwatakoのはてなブログ
- [速報レポート] try! Swift TOKYO 2017 2日目 午後II #tryswiftconf ｜ Developers.IO
togetter
Minimizing Decision Fatigue to Improve Team Productivity #tryswiftconf - Togetterまとめ
