0時に寝て5時に起きた。朝から2時間ほどドラクエタクトしてた。
ふりかえりのフィードバック
先日 5日以上かけて非開発者向けのドキュメント を書き終えた。労力をかけてわかりやすいように書いたせいか、評判がよいという噂があり、ふりかえりのときにも先方の社内で共有されていて、他チームでも読まれているといったコメントをいただいた。それ自体は嬉しいことだ。一方で先方の社内に閉じている議論なのでドキュメントを書いた私には一切フィードバックはない。同じチームのメンバーからもほとんどない。
私はあまり自分自身を信用しない人間で、私が作った成果物はよいものだと考えていない。とくに初期のバージョンはすべてそう。誤り・勘違い・怠惰・抜け・漏れがいくつもあって3世代ぐらいのアップデートをこなさない限り、運用に耐えるものにはならないという考え方をする。書き終えたばかりのドキュメントを褒められても、自分の中ではそれはおかしいと思ってしまう。あんなものがよいはずがない。もっとよくするための取り組みがあるはずで、そのヒントを他者に期待しているところがある。単純に褒められるよりも「どこがわかりやすかった」「どこがわかりにくかった」「ここをもうちょっと詳しく」とか、そういったインタラクティブな議論を他者に求める傾向がある。それは自分自身が欠陥だらけだから。今回はふわっとした手応えで業務を終えることになる。
開発方法論を議論するのに飽きた
エンジニアリングマネージャーのしごと 読んでみたけど、質問ある？（答えられるとは言っていない に参加した。ちゃんとしたイベントじゃなくて、書籍を読んだ感想を discord で気軽に雑談するようなイベントだった。雑談と言っても話していたのは主催者のみで、他のメンバーはチャットにコメントして、それを主催者がみて話題として取り上げるといった進め方だった。悪いイベントではないのだけど、コミュニティの内輪感が強くて初めての人が参加するようなところではないなと思えた。
この1年、スクラムを実践しながらずっと開発方法論やマネジメント／リーダーシップについて考えてきた。考え抜いた (と言ってもたった1年だけど) 結論として開発方法論そのものはあまり重要ではないと結論づけた。重要なのは、自分たちの開発にとって障害や課題を認識したときに改善していけるか。そんなの当たり前だと思うかもしれない。改善するにあたって組織も含めて変えられるかというところが最も重要だと気付いた。スクラムにおいても、簡単な問題はすぐ解決しようとするのに、複雑で難しい問題はなぜ解決への試みすらやらないのだろう？とずっと不思議に思っていた。それは既存の組織や制度のなにかを変えないといけないとき、それらを改善の対象とみなすか・みなさないかという視点が人によって大きく異なることに気付いた。多くの人はそこまでやろうとしない。それは越権行為かもしれないし、思い付きで組織の決めごとを変えられても困るかもしれない。一方で私は頭がおかしくて組織や制度そのものも変えようとする。まず組織を変えようとするかどうかが最初の分水嶺になる。そして、実際に組織が変われるかという最大の課題もある。開発のためだけに組織を変えてくれと経営者にお願いして「わかった」という経営者は稀かもしれない。組織にも歴史や文化があり、会社には開発以外の様々な業務もある。大規模スクラムが提唱されるようになったのは組織を変えていくアプローチがスクラムには重要になってくるという証左かもしれない。
組織さえ変えられるのであれば開発はいくらでもよくなる可能性がある。これは小さい組織や若い組織にとってはとくに有利な点と言えるだろう。開発方法論に何を採用するか、初期のチームがうまく開発できないといったことは些事でしかない。自分たちの開発をより良くすることを本当にやろうとしているかどうかが重要だ。そのことに気付いてからゾンビスクラムをみかけたときも、これは組織のこういった課題から派生していると深堀りするようになってきた。
