チームをソフトウェアのように扱った方がいいのでは、ということを考えている。
最近なんかこのタイプの書き出しが多いな。ご容赦ください。
人間の適応力を過信しない
人間もソフトウェアのように扱ったほうが良いなと思うことはよくある。人間、機械よりは後方互換性を担保しなくても柔軟に動けるけど、ブレーキングチェンジが頻発するとハレーションも起きるので、細かいブレーキングチェンジを頻発させるのはやめたほうが良いんだなという気持ちがある
— こじま (a.k.a. 515hikaru) (@tak428k) 2022年8月24日
人間の適応力は高い。機械とかソフトウェアとかに比べて。
一方で、その適応力が絶対的に高いかというとそうでもない。この世にはサービスや OS などで、一度特定の UI に慣れるとそれを変えられない人種がいるらしい。Windows XP みたいな画面で 2017 年くらいに仕事をしている人を僕はみたことある*1。Windows 10 から Windows 11 にするのを渋る人もいっぱいいるようだ*2。ホームボタンがないと iPhone じゃない、などという意見もその典型だろう。
変化を厭わない人もいる一方で、変化を嫌がる人もいる。全ての変化をいやがっているわけでもなく、これはいいとかこれはいやだとか人によって向き不向きもある。
ということで、人間の適応力に過度な期待はしないほうがいい。特に理由がないなら、人間に対しても後方互換性には配慮した方が良い。というのが何年間か会社員をやってきてわかったことである。人は口では改革とか変化すべきとか耳障りのいいことを言うが、ほとんどの人は本心では望んでおらず、今日と同じ明日が来ることを願っている。それは悪いことではない、人間の本能のようなものだ。
互換性を意識したチームの変更
さて、仕事の話をしよう。
望ましいのは自分の周辺（チームだったり部署だったり）ではアグレッシブなバージョンアップをするが、そのバージョンアップが外部（他チーム、他部署）からは互換性が担保されているように見えている、というのを目指す。このとき、前者の閉じた変更はパッチバージョン、外部への影響があるものはマイナーバージョンに相当する。便宜上、以下ではパッチアップデート、マイナーアップデートと呼ぼう。
パッチアップデート
パッチアップデートは容易だ。いつでもチーム内で合意をとれば実行してよい。チーム内で会議の頻度を増やす / 減らす、やり方を変える、ツールの使い方を変える、などなど。このとき、変更内容がチーム内で閉じていれば気軽に意思決定してよいと考えている。ステークホルダーがチームメイトのみであり、そこにいる人々は定例会議などで定期的に話すことが精度高く保証されているからだ。
マイナーアップデート
一方で、マイナーアップデートは、外部からは互換性が担保されているように演出することが大事だ。これは細かい内容が多いが、範囲が幅広く注意が必要なときもあるかもしれない。
他チームの人が影響を受けそうなことはなるべく変えない、もしくは互換性を持たせて変更するように意識する。具体例としては、Slack のチャンネル名（全社的な命名規則に則っているか？）、全社共通のドキュメントツールの階層構造や場所の一貫性、このチームに雑に相談するときの一次請けは誰か、他チームを含めた会議をするときのガイドラインなど。
ほとんどの人は他チームの内情に強い関心はない。何が決まっていることなのかの結論を API ドキュメントを作るようにきっちり整備しておくことが重要だ。逆に、こうしたドキュメントを一度整備すればメンテナンスの機会は少ないようなチーム運営をするのが理想である*3。
情報のプル
これが原則だが、これが続くとサイロ化していき、情報や知識が共有されなくなる。しかし、他チームに自チームの知見を導入したいからと、自チームのルールを他チームに強くプッシュするのもまた悪手である。自チームの内情は知っていても、大抵の場合あなたは他チームの内情には詳しくない。同じルールをそのまま適用できるとは限らない。
重要なのはルールのプルをしてもらうことだ。自チームのルールで他チームにも適用できそうなことは、他チームの人にしか判断ができない。例えば弊社では知見共有、他チームに知見を持ち帰ってもらう場として社内勉強会を利用していたりする。
イメージとしては、自チームのローカルのリポジトリにコミットした変更をリモートリポジトリにプッシュして、必要なコードだけ各チームがプルしていくような感じ。それを繰り返して、重要な部分はシェアされながらも各々のチームのイロが出ていったりするといいんじゃないかと思う。
そう考えると、まさにチームというのはソフトウェアのようなものなんだなぁと思えてくる。
時にはメジャーバージョンアップも必要
キーマンの退職や休職、事業方針の転換など、非常に大きな変化を受けて今までとは全く違うルールへと変更せざるを得ないときもあるだろう。これがメジャーバージョンアップに相当する。
まず、平時はメジャーバージョンアップをしないことが重要だ。その理由がステークホルダーにとって火を見るよりも明らかなときしか、メジャーバージョンアップに対する納得感はない。いざというときのためにメジャーバージョンアップはとっておくべきだ。
そしてそのいざというときが来た時、「一気にやる」、「徹底する」。関係する人のほとんどがわかってくれるような事情なら人は協力してくれる*4。
そう、ライブラリのメジャーバージョンアップを浸透させるときと一緒。非難轟々ありながらも、やりきることが大事。
終わりに
なんだこの記事。
