JaSST Review'18 S2 (memo)

目次

このページの概要

一気に書き上げようと思ったら書ききれなかったので、S0,S1 と S2,S3 を分けることにしました。 今回は S2。

S2) レビュー再定義

speakerdeck.com

  1. レビューの目的
    • 品質担保、バグをみつける
    • コードの均一化
    • スキルの低いメンバーの教育
    • スキルトランスファー？をするため
  2. 分類
    • 検査：品質担保
    • 学習：ナレッジ共有
    • 強化：リファクタリング、もっとよく、もっときれいに
  3. 目的達成できてる？
    • レビューの目的と実際にレビューをしている人のコメントの間で相違があることがある
      • 実際のコメントにしかないもの：コードの理解、コミュニケーション
  4. レビューは楽しいですか？
    • やらなくてはいけないこと
    • やるべきこと
    • やりたいこと
    • やらなくてはいけないことに話が集中しすぎてつらくなる
      • 実際にはやらなくてはいけないことですら難しい...
  5. モブプロを通してもっとわくわくするレビュー！
    • モブプロを初めてレビューが不要になった
    • でもレビューはやっぱり必要
  6. モブプログラミングを通してもっとわくわくするレビューについてのアイデアが出てきた
    • 働き方モブプロ
      • 9:00-11:00 個人時間
      • 以降全部モブ
      • 分担作業
    • 分担作業の前後に同期をとる作業が必要になる
      • 前：キックオフ 後：レビュー
      • これ忘れがち
    • ミスコミュニケーションにより手戻りが発生する可能性もある
  7. 分担作業とモブワークの違い
    • 向き不向きがある。同期コストがかからないのであれば、分担でもいい
    • 分担する＝生産性が高いという思い込み
      仕事や状況に合わせて使い分けている
    • モブワークをすると、工程としてのレビューは不要になった
    • レビューによる忖度がストレス源
  8. チームの最善を目指す
    • 分担：誰がやっても難しい作業も、アサインされたら誰かが頑張らなきゃいけない＝つらい
    • モブ：誰がやっても難しくてもチーム全員で割り切って判断して対応することができる
  9. モブプログラミングはチーム全体の活動
    • チーム全体で立ち向かってダメなら仕方ない
    • 判断をチームですることができる
    • 絶対なる安心感とそこから学ぶ姿勢
  10. モブプログラミング学習
    • 結果だけじゃなくて過程を学ぶことができる
    • 分担：同期(ナレッジ残す的な)しなければ、個人の学びに過ぎない
    • 経験値が低い人をドライバーにすると、わからなければ手を止める権利があるのでわからないところが見えやすい
    • ノウハウの Just in Time！
  11. 我々に必要なレビュー
    • Pull-Request
    • モブ振り返り
    • 今日の仕事は最高だった？
      • どう改善するか
      • それは今やること？
      • 次はどういうことを学ぶべき？
  12. Re-View (再び、見る)
    • モブじゃないレビューは本当に Re-Viewだった？
      • 実際にはファーストビューである
      • 初めて見る場合は理解するコストが必要
  13. リアルタイムとレビューの強み、弱み
    • 強みと弱みが補完関係にある
  14. レビューの再定義
    • 自分たちのレビューを見直そう
    • そのプロセスでの解決に固執しなくてもいい
    • 目的を達成するために、そのプロセス自体をやめるという選択肢も常に頭に入れておく
  15. 実際にやらなくてはいけない、からの解放
    • 無限にわいてくる やらなくてはいけないことに対して、有限のリソースで向かっている きりがないし、目指したって無理、つらいしギスギスする
    • ROI を考えて自分たちにできることをする
    • ダメなら仕方ないという割り切り
    • 最善を尽くしても失敗したときはそこから学ぶ
  16. 変化に適用する
    • 他人にうまくいったことが、自分たちにそのまま当てはまるとは限らない
    • チームの練度や状況によって最適解は変化する
      • 一度定義しても時がたったら見直す
  17. 情緒を大事にする
    • 小手先のテクニックでどうにかできると思わない
    • 人間であることを楽しむ
    • 完璧ではないけれど成長できる
    • 楽しいと楽しくないのインパクト
    • 楽しくないとやめるのでは * 楽しいレビューを考えよう！！！！

      S2) 私見

      モブプロ推し、というわけじゃなく、モブプロを通して学んだこと、その結果必要なレビューについての話でした。
      私が大事そうだと思ったところは赤字にしておきました。 自分の中の結論としては、現在のチームでモブテスティングは難しい。テストの専門会社として、お客様先に入ってテストをしているので、モブテスティングを「やってみる」というのがまず超難関。 ただ、基本的に全部仕事をするうえで大事なことだなと思いました。特に時間とお金とリソースが許せばいくらでもやりたいことがわいてくる中でレビューにどこまで時間をかけるのか。
      あとは、チームリーダーとして作業を見積もる際に忘れがちな「作業の同期」にかかわるコストの存在を改めて「コスト」として認識できました。

他、モブテスティングを研修で使えるんじゃないかということ。 レビューという軸からはちょっとずれてしまいますが、今いるメンバーのスキルが上がれば、畢竟レビューの質も上がるはず、という強引理論。
モブテスティングを通して、要求分析～テスト実装(あるいは実行、報告まで)をチームで行い、テスト初心者の教育、新ドメインに入るメンバーの育成などが行えるのではないか、と考えました。 実施するとしたら恐らく1日がかりになるでしょうし、すぐには難しいことと思うのですが、私が参加したいですｗ

なお、やり方次第ですが、WACATE 2018夏で同じようなことをしていたチームがあったと記憶しています(うちの班は分担を選びました)。
次に WACATE に参加する機会があれば、モブテスティングを提案してみたいです。