DORA の思想をやっていきたいっすという話をした。 そして、実際に前四半期 four keys を測定できるようにした。
four keys については、 "開発速度と安定性はトレードオフではない" という思想が良い、と個人的に思っている。 従って、four keys を測定可能にした次のステップとしては、全ての four keys を改善傾向に向かわせたい、ということになる。
ところで、開発に関係する全員が four keys 全ての改善を意識するというのは、実際なかなか難しい。
詳しい機序は省くが、アプリケーション開発のノリとして、 とりあえず 「開発速度の指標をもっと精緻にする」「開発速度を良くしたい」みたいな話になりやすい。
繰り返しになるが、four keys は全てが相互に関係するはずだから、そういう とりあえず はあんまり良くないと思う。
が、結局「俺はもっと安定性の話をしたい、ナ😅💦」的なお気持ちの側面もある。 "開発速度に関する指標の話をしている時に、開発チームは安定性のことも考えてくれているだろう" と 俺は 信じていないだけ。 開発チームは開発チームなりに「開発速度の指標をもっと精緻にする」と安定性の関係を意識している。 ではなぜ 俺は 信じられないかというと、開発プロセスが諸々うまく連動していないからかなと感じる。
弊社の開発プロセスは、現状
- 機能開発
- リリース前テスト
- リリース後の顧客対応
あたりで責任者が分離している。 で、それぞれの責任者のやりたいことが食い違っているというか、まあ普通に嫌な言い方をすると「ちゃんとやってくれる、よね？😅💦」と各自目配せをしている。 目配せの一種として「安定性の話もして欲しい、ナ😅💦」と言いたくなっている。
開発プロセス上の謎の分離が four keys に対するオーナーシップの分離に繋がりかねないな、という懸念があり、 というか俺がそういう嫌なやつなので他人のオーナーシップを信用できずソワソワしているだけだが、 こういう分離を解消したい。 ではなぜこのような分離が起きているかというと、弊社にはたくさん開発チームがあるくせに社内標準がないせいや。 「開発チーム内でやれる部分は各チームの都合が良いようにやりつつ、やれない部分は放り投げる」ことになっており、放り投げるタイミングで分離が発生している。 この放り投げによる分離は、転じて "そもそもチームを跨いでの協力がうまくいかないがち" という弊社の別の問題にも繋がっていそう。
なんで、そういう放り投げベースの業務の分離が起きないように、
あたりが（four keys を意識した開発組織を作る上での）次のアクションかなと思っている。
それで、一旦 開発プロセス自体の社内基準を作る をやろうとしている。
開発プロセス自体の社内基準を作る にあたって、開発チームのミーティングとかタスク管理を覗いてみた。
皆さんが皆さんなりにちゃんとやってくれている。
結果、（特に基準がない中でちゃんとやるので、独自の工夫が積み重なって）ヤバいレベルの複雑化に繋がっている。
現場の判断で ちゃんと やっているわけなんで、うまくいってない部分は組織が悪い。
俺は組織なので、俺が悪いなと思う。
俺は俺だが、俺は組織だという自己暗示をかけて働くと給与が上がるので、そうしている。
ひとまず、俺の 目配せ を各チームの工夫に差し込む方法を探してみて、そっからさまざまな人の 目配せ を差し込む "最強差し込みメソッド" として抽象化していこうと思う。
"最強差し込みメソッド" が維持されている開発プロセスは、その時点で一定抽象化されており、継続的な改善に耐えるような気がする。
弊社も 7 年だか 8 年だかソフトウェア開発を続けており、このような（ "基準 " を "策定する" みたいな）業務も発生する季節になっています。 興味ある人いますか？俺は気が狂いそうなんで、興味ある人いたら嬉しいっすね。 下の URL から選考やカジュアル面談などを申し込んで俺と対戦しましょう。よろしくお願いします。
