チームビルディング？マネジメント？よくわからない

チームで働くということ

助け合い

• 全員で一つのEpic、Storyに取り組むスタンスで行きたい

今まではEpicやStoryがあったとしても誰か一人が主担当になって動いていてどうしてもチームという感覚が薄かった 今後はチーム全員で一つのEpic、Storyに取り組むスタンスで行きたい 保守チケットは暇な時にやる

私が死んでも代わりはいるもの

全員が全員の代わりになれるようにする

• 仕様を全員で共有する

新しい案件に取り組むときには内容をチーム全員に共有する できればチーム全員で案件について考える時間を取りたい 設計は二人で進める（サーバーサイドとフロントエンド一人ずつ） 設計が完了した時点でチーム全員に共有する 実装は全員で進める

• 技術を全員で共有する

サーバーサイドのエンジニアは時間がかかってもいいからフロントエンドのコードを書けるようにしたい 同じくフロントエンドのエンジニアは時間がかかってもいいからサーバーサイドのコードを書けるようにしたい まずは読めるようになることからでいい

へーきへーき！フレンズによって得意なこと違うから!

それぞれが得意な分野を伸ばして、苦手な分野は他の人で補い合えばいい それがチームで働くということ

無理はしない

頑張れる人が頑張ればよい

休みたい

一人で案件を抱えてたら休めない 全員で携わっていれば代わり代わりに休める

すべてを知っていたい

知らないことは怖いこと もし自分しかいなくなったときにわかりませんじゃ怖い ドキュメントに残すのも一つの手だが、普段からみんなで知識を共有することが一番コストが低い

最高のチームを作りたい

チームで働いているという感覚を持ちたい

責任の所在が曖昧にならないように

一人ひとりが責任を持って仕事をする 責任を取れと言うことではない 失敗は自分の責任だと思って反省する必要がある 他人のせいにするなということ

チームとして何を重視するか

生産性

そもそも生産性とは何であって何でないのか。

生産性とは 売上/コスト である。

つまり生産性を上げるには売上を上げるか、コストを下げるかの二択。

• エンジニアとして売上を上げるには機能を早くリリースして営業が売りやすくする。
• エンジニアとしてコストを下げるには機能を早くリリースして１機能のリリースまでにかける時間を減らすこと。

— 売上を上げる コードを綺麗にしておきたいが、どんなにコードが綺麗でも価値を生み出さないプロダクト（サービス）は意味がない。 とにかく機能を早くリリースするにはそれぞれが強みを活かしてそれぞれを補って動く必要がある。 まずは多少汚いコードだとしても良い。 もちろんリファクタリングの時間を取れるようにする必要はあるが、赤字垂れ流してるのにコードを綺麗にすることに熱心になってリリース遅くしてどうするの？ 現実を見て！営業側にどれだけの負担をかけているのかを理解して！ 自分が営業だったらどうする？「コードが綺麗なんです！」なんて営業トークしてお客さんがお金を払ってくれるの？コードが綺麗かどうかなんてどうでも良いでしょ？動くものがほしいでしょ？

— コストを下げる コードを綺麗に保つことがコストを下げることに貢献するなら、コードを綺麗に保つための施策を打てば良い。不具合を減らすことが出来て、営業の負担を減らすことができるならそうすれば良い。

コードが複雑すぎてコストが跳ね上がっているならそのためにどう動くべきかを考える。

新しい技術やアーキテクチャがあって、自分がいいと思ってやってみたいと思ったら、まずはチームに広めればいい。 チームメンバーがそれに共感しないなら、うまく伝わっていないか価値がないかのどちらか。 一人で進めるのは辛いが、それがコストを下げるために価値があると数人が感じたならそのメンバーで推進すれば良い。

— 機能を早くリリースする

機能を早くリリースする一番の近道は作らないこと。作るものを減らすこと。

— ユーザーストーリーマッピング p.14 より引用 アウトプットを最小限に抑え、最大限の成果とインパクトを獲得しよう

— ユーザーストーリーマッピング p.16 より引用 あなたがしなければならないことは、より早くより多くのソフトウェアを作ることではない。 作ると決めたものから最大限の効果とインパクトを生み出すことだ。

生産性とは個人で測るものではない。測れるものではない。

自分で作って自分で売ってるわけではない。 必ず誰かと一緒にやっている。

我々の仕事は何か

— ユーザーストーリーマッピング p.9 より引用 あなたの仕事は世界を変えることだ （中略） 製品に転化されたすばらしいアイデアは、それを使う人々からすれば、世界を少し、あるいは少なからず変えるものなのである。実際にそうなっていないなら、あなたの取り組みは失敗だ。

なぜ振り返りが必要なのか

• チームの改善
• 生産性を上げるために動けているかの確認の場
• 「どんな意識で仕事に取り組んでいるか」「どうすれば効率的に仕事ができるか」といった仕事の進め方について話し合う場の提供

チーム内ペアプロ

フロントエンドの人材が足りないのが、圧倒的にボトルネックになっている。 フロントとサーバーのペアでやってみたい

エピックのススメ方

http://qiita.com/Koki_jp/items/6aebc73bedd0a932dcb8 バックボーン（ストーリーの骨格） - PM ↓ ナラティブフロー（物語の流れ） - チームリーダー ↓ ユーザーストーリーの詳細出し - チーム全員 ↓ 詳細設計 - チーム全員（作業分担） ↓ 実装 - チーム全員（作業分担） ↓ テスト - チーム全員（作業分担）

マネジメントしようとしてはいけない？

• （悩み中
• リーダーの仕事は露払い？
  • 仕事がしやすいように環境を整えること？