昨日は夜にいろいろ作業して、1時に寝て4時に起きて7時に起きた。

テックブログ執筆⌗

先週から調査している内容 についてテックブログを書き始めた。マネジメントや実装をしていると筆が進まなくて書き始めるのが随分と遅くなってしまった。学校の試験前に、試験勉強やらずに部屋の掃除をやってしまったりするような感覚。午前中は昨日 go-ldap に送った pr がまとめてマージされた。その修正を取り込んだライブラリのバージョンで関連するところのコードをリファクタリングしていた。それでもようやく書き始めた。書き始めたら一気に 2/3 は書けた。本当は晩ご飯を食べた後にレビューできるところまで書いてしまおうと思っていたが、そこまで体力 (集中力) が続かなかった。なんとなく張り合いがなくて適当なところで妥協してしまう。

試行錯誤から学ぶ開発スタイル⌗

たまたまみかけた記事でひどい内容の記事をみた。一読しただけでもやもやしていたのを知人と議論していて言語化できるようになったので書いてみる。

もっと前段にエンジニアが議論に参加する、なんなら議論をリードするくらいのことをしていく必要があるでしょう。

こういうこと言い出すマネージャー (PO) 多いし、意見そのものは一理あるんだけど、これをエンジニアがイニシアティブとってやっていたらマネージャーいらないでしょ？ということを自覚していない。もっと言うと、PO という責任のある立場の人が大変という理由で責任放棄しているようにみえてしまう。(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 という記事では実際にテックリードまたはエンジニアがプロジェクトのイニシアティブを取っていると書かれている。もしそうするなら、まず自身のスキル不足や未熟さを受け入れないといけない。

マネージャー (PO) にとって大きな役割は意思決定であって、仕様案や計画において技術的なところがわからないのであれば、エンジニアに委譲したり相談して事前にいくらでも調整できるはずだし、その調整作業そのものはマネージャーの仕事の1つと言える。そういった調整をマネージャーがやるからエンジニアは実開発の設計や実装に集中できる。結果的に生産性も上がる。この文章から伺えることはリファインメントや計画に臨んだときにダメ出しされてやり直すことを手戻り、大変、効率が悪いとネガティブに捉えている。逆に言えば、最初から完璧に仕様案を作れるはずだと思い込んでいるふしがある。

そして、誰もが知っていることだが、最初から完璧な仕様案や計画など作れるはずがなく、不確実性を許容しながらスクラムやアジャイル開発といった開発方法論の取り組みで調整していくというのが、モダンな開発のやり方である。その試行錯誤や手戻りは無駄なことではなく、チームやプロジェクトが学ぶべきことの1つだという考えがこの文章からは読み取れない。そして、自分が仕様案を適切に作れなかったのを自分のスキル不足だと認めず、チームのエンジニアが議論に参加していないからだと責任転嫁している。それはマネージャーが技術的に大事なことを理解できていなかったとふりかえり、計画を修正したり、次に計画するときは同じようなことが起こらないよう、努めていくというのがスクラム的なプロジェクトの進め方になるはずだ。手戻りはアンチパターンではなく、学びの過程や必要な試行錯誤であると認めて受け入れるところから始めるべき。