$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

「デッドライン」読んだ

最近プロジェクトマネジメントをちゃんと学ぼうと思って色々読んでいる。今回はデッドラインを読んだ。

読み物として普通に面白かった。また「チームの結束については、既存のチームを探して利用する」「新しい仕事を引き受ける意欲のある結束の固いチームは、プロジェクトの成果の一つとみなす」辺りは新しい観点に触れられたと感じてよかった。

読書メモ

* 脅迫は、結果を挙げさせる手段としては不完全である。どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない 823
    * 気づき: 「もう少し〇〇してほしい」というのも一種の脅迫だと思う。それをやりたいと思うような理由をうまく作る必要がある
* 新しく採用した人材には、1回は実証済みの能力レベルのプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする 1197
* 最も採用したいと思った人物は、ほかの優れた人材を知っている可能性が高い 1197
    * 気づき: 採用後すぐに、リファラルを求めるというのは良いかも
* チームの結束については、既存のチームを探して利用する 1560
    * 新しい仕事を引き受ける意欲のある結束の固いチームは、プロジェクトの成果の一つとみなす
    * 気づき: 別プロジェクトにいたペアをそのまま次プロジェクトのペアとする方法が良いことを知った
* 相手を好きになり、気づかわなければ、人にちがうことをさせることはできない。相手を変えるには、相手の考えていることとその理由を理解し、尊重しなければならない 2934
    * 気づき: よく軽んじてしまうので戒めなければならない。「人を動かす」とかも読まないといけない
* 仲裁はわずかな投資で学習できる 3837
    * 気づき: どうやって学んだらいい?
* 理想の人数配分は、プロジェクトの期間の大部分を少人数のコア・チームで行い(特に初期)、プロジェクトの終盤に人数を大幅に増やす 4149
    * 初期に人数が多いと、重要な設計作業を省略せざるをえない。設計が完成する前に大勢に仕事を割り当てると、人や作業グループの間のインターフェースを最小化できない
* プロジェクトには目標と予想の両方が必要だ 4841
    * 気づき: 意欲を高めるための目標と、実際の締め切りみたいなのは別でも良い

最近読んだプロジェクトマネジメント本

blog.shibayu36.org

「ピープルウェア 第3版」読んだ

昔読んだけど、プロジェクトマネジメントや組織マネジメントをしてきた今だからこそもう一度読みたいなと思い、読んだ。

久々に読むとまた別のところに面白さを感じてよかった。特に「根本的に欠陥のある設計は、修正したりせずに、思い切りよく捨てて一から作り直したほうが結局はうまく行く」「早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない」「エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である」「誰とチームを組んでいるか、が生産性向上の要因になっている」あたりが面白かった。

読書ノート

以下読書ノート。(「知的戦闘力を高める独学の技法」という本で気づきも合わせてメモすると良いと書いてあったのでやってみた)

  • 根本的に欠陥のある設計は、修正したりせずに、思い切りよく捨てて一から作り直したほうが結局はうまく行く 469
    • 気づき: 制度設計や形骸化したミーティングでも同じ。インクリメンタルに改善していると局所最適で無駄が多くなってしまう。一回捨てることで全体最適が出来る
  • 早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない 706
    • 気づき: スケジュールは意欲の湧くものにする。
    • 気づき: 最終締め切りと、目標は別でも良い
  • エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である 770
    • 長い目で見れば、市場が必要としている程度に品質水準を合わせるとコストが増える
    • 開発者自身が満足する品質基準を決めることが生産性の向上につながり、品質を上げるためのコストを補って余りある 790
    • 気づき: リーンとDevOpsの科学でも、結局変更失敗率と変更速度は逆相関の関係では無かったと言っていたので、開発速度と品質がトレードオフという考えは直感では正しそうだけどそうでもないのだろう
  • 誰とチームを組んでいるか、が生産性向上の要因になっている 1248
    • パートナーの成績が良ければもう片方も成績が良く、そうでなければ逆の結果に
    • 気づき: デッドラインでも、別プロジェクトでチームとなっていた人をそのチームのまま他の部署にと書いてあったので、近いことを言ってそう
  • 仕事に取り組んだ時間の測り方を、フロー状態の時間をベースにしたものにする 1600
    • 連続して中断が入らなかったhour数で計測
    • E係数 = 中断なしの時間 / 机の前に座っていた時間で計測すると、最高0.38、最低0.10と大きな開きがあった
  • リーダーシップ:不言実行 2321
    • 気づき:経験則だが、とにかく言う前にやっていくというのは本当に大事
  • 人が入れ替わる際の全コストは、結局5ヶ月分の人件費ほどにもなる 2594

参考

昔読んだときの感想 「ピープルウェア」を読んだ - $shibayu36->blog;

Renovateを使ってライブラリアップデートの自動マージ

利用しているライブラリのアップデートは常に行いたいが、中々コストの掛かる作業でもある。その時にテストが通ったらOK・型検証が通ったらOKみたいなライブラリ(例: TypeScriptなら @types/系やjestなど)なら人間の目を通さずに自動でPullRequestをマージしてくれたら、その分コストが減り、人間の目が必要な作業を行う時間が増える。

そこでRenovateを使って上記のようなことをやってみたのでメモしておく。

出来たもの

https://github.com/shibayu36/typescript-cli-project/pull/10 のように、Renovateのbotが勝手にPRを作り、勝手にApproveし、テストが通ったら(GitHubのchecksが通ったら)勝手にマージしてくれるようになった。

実現するためにやること

  • Renovateを有効にして、自動マージできるように設定ファイルを作る
  • renovate-approveを有効にして、レビューが必須でも勝手にApproveしてくれるようにする

の2つだけしたら良い。

Renovateを有効にして、自動マージできるように設定ファイルを作る

https://github.com/apps/renovate を入れたいレポジトリに設定すれば良い。するとConfigure Renovateというissue( https://github.com/shibayu36/typescript-cli-project/pull/6 )が作られるので、それを見ながら設定する。

自動マージを実現するために以下のようにrenovate.jsonを設定した。

{
  // VSCodeで補完が効くようになって便利
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  // 一般的な設定を有効にし、timezoneも設定する
  "extends": [
    "config:base",
    ":timezone(Asia/Tokyo)"
  ],
  // ラベル付ける
  "labels": ["dependencies", "renovate"],
  // CIを阻害しないように、夜や週末に実行する
  "schedule": ["after 10pm and before 5am every weekday", "every weekend"],
  // これを設定しておくと https://github.com/shibayu36/typescript-cli-project/issues/17 みたいなのが作られて便利
  "dependencyDashboard": true,
  // pinのPRは自動マージ
  "pin": {
    "automerge": true
  },
  // npmではrangeのバージョンを使う
  "npm": {
    "rangeStrategy": "bump"
  },
  // @types/系はmajorが変更される以外は自動マージ
  "packageRules": [
    {
      "packagePatterns": ["^@types/"],
      "automerge": true,
      "major": {
        "automerge": false
      }
    },
    // jestはまとめる(一旦自動マージしない)
    {
      "groupName": "jest",
      "sourceUrlPrefixes": [
        "https://github.com/facebook/jest",
        "https://github.com/kulshekhar/ts-jest"
      ]
    },
    // linter系はまとめる(一旦自動マージしない)
    {
      "groupName": "linters",
      "extends": ["packages:linters"],
      "packageNames": ["prettier"],
      "packagePatterns": ["^@typescript-eslint/"]
    }
  ]
}

必要があればjestの自動マージやlinterの自動マージを設定すると良いだろう。

renovate-approveを有効にして、レビューが必須でも勝手にApproveしてくれるようにする

基本は上記設定でも問題ない。しかしGitHubのBranch protection rulesの設定でRequire pull request reviews before mergingを有効にしている場合、ReviewsのApproveがないことで自動マージが出来ないという問題がある。

この場合の解決策もRenovateは用意してくれていて、https://github.com/apps/renovate-approve を入れるだけで済む。とりあえず入れておくと良いだろう。

まとめ

今回はRenovateで自動マージを実現する方法を調べたのでメモしておいた。今回は調査のために1から設定したが、とにかく素早く使いたいなら下のような設定を使うのも良いだろうと思う。

developer.hatenastaff.com