2017-03-17

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

チームで働くということ

助け合い

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

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

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

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

仕様を全員で共有する

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

技術を全員で共有する

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

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

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

無理はしない

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

休みたい

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

すべてを知っていたい

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

最高のチームを作りたい

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

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

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

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

生産性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我々の仕事は何か

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

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

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

チーム内ペアプロ

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

エピックのススメ方

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

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

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

2017-02-01

2段階認証について

2段階認証(2 factor authentication)

2段階認証(2 factor authentication)について

https://gist.github.com/asufana/daaa0477df93a5a2870c

二段階認証(TOTP)メモ http://qiita.com/xylitol45@github/items/4f8418554a6550189341

QRコードのURLについて https://github.com/google/google-authenticator/wiki/Key-Uri-Format

Deviseを使っているRailsアプリに2段階認証を導入する http://qiita.com/Kta-M/items/e155f6e35e3e8274ff1e

考慮すること

リカバリコード
- リカバリコードをDBに保存する
- リカバリコードでもログインできるようにする
  - 使用したコードは無効化する
- 再度secret codeを作成してユーザーに提供する（？）
時計のズレ
- クライアントとサーバーで時計がずれていくことがあるので、ズレを吸収するためにどの程度ズレが生じているのかをサーバー側に保持しておく。次回以降はそこを起点とする。

ライブラリ

https://github.com/wstrange/GoogleAuth

import com.warrenstrange.googleauth.{GoogleAuthenticator, GoogleAuthenticatorQRGenerator}

/**
  * Created by fscoward on 2017/02/01.
  */
object Main {
  def main(args: Array[String]): Unit = {
    val authenticator = new GoogleAuthenticator()
    val credential = authenticator.createCredentials()

    // この URL で QR Code を作成して読み込ませる
    val url = GoogleAuthenticatorQRGenerator.getOtpAuthTotpURL("fscoward", "otp-sample", credential)
    println(s"url: $url")

    // QR Code に埋め込まれた secret key
    val secretKey = credential.getKey
    println(s"credential: ${secretKey}, verificationCode: ${credential.getVerificationCode}, scratchCodes: ${credential.getScratchCodes}")

//    val totpPassword = authenticator.getTotpPassword(secretKey)
//    println(s"totpPassword: $totpPassword")

    // QRコードで読み込ませたときの secret key
    val storedSecretKey = "JW6W56PKJJFDTRX6"
    println(s"${authenticator.getTotpPassword(storedSecretKey)}")

  }
}