最近開発チームの改善を行う時に、どういう目的で開発チーム改善を行うのかや、開発チームの責務は何なのかについて悩んでいた。色々本を参考にしながら、自分の中でしっくり来た責務があったので、ブログにまとめておく。
まず自分の中で、開発チームの責務は次のものであると言語化した。
- エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する
なぜこの責務としたか
まず現代のソフトウェア開発においては、非常に不確実な状況で、顧客にとって価値があるものが何かを探索しながら、高速に価値を創出・提供しなければならない。これを満たすためには、「正しいものをつくる」ということと、「正しくつくる」ということの両輪を回す必要がある。
この時、プロダクトオーナー側と開発チーム側で分業するとすれば、やはり開発チームは「正しくつくる」ことに焦点を当てて責務を持つと良いと考えた。つまり開発速度(価値提供速度や試行回数)を最大化することを第一優先とする。
一方で、何も考えずに開発速度を高めすぎると、エンジニアリング面でサービスが継続困難になるようなリスクが高くなりすぎるかもしれない。例えば属人性を高めれば開発速度は高められるかもしれないが、コア部分で特定の人しか分からない実装が出来てしまうと、その人が退職した時にサービスの開発ができない状態に陥ってしまうかもしれない。例えば、開発速度を重視するあまり、サービスの可用性を犠牲にしてしまうと、信頼できるサービスとみなされず、サービス自体が頓挫してしまうかもしれない。例えば、リリースに間に合わせることを意識するあまり、セキュリティの考慮が漏れると、ユーザーに不利益を与え、サービスを閉じなければならないかもしれない。こうなると困るので、開発速度は最大化しながら、リスクはコントロール可能な状態に制御しておく必要がある。
以上より、最初に書いた「エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する」を開発チームの責務とすれば良いと考えた。
ちなみにこの責務に込めた他の意味としては
- エンジニア観点ではなくエンジニアリング観点
- 総合的な開発能力の話をしているので、エンジニアだけでなく、他の開発に携わる職種(企画、デザイナ、翻訳担当など)全体のエンジニアリング能力に焦点を当てる
- リスクを減らすことを責務とするのではなく、リスクのコントロールを責務とする
- リスクを0にすることは出来ないし、小さくしようとしすぎると多大なコストがかかってしまう。結果として開発速度も落ちてしまう
- あくまで開発速度の向上を第一とし、リスクはコントロールして許容範囲を超えないようにする
- これはSREにおける、信頼性と開発速度の関係を意識した
この責務を意識した3つの改善の軸
さらにこの責務を意識した上で、自分が改善を提案する時は3つの軸に分けて考えてみている。
- 1) 開発速度が最大化できているか
- 2) エンジニアリング観点でサービス継続リスクをコントロールできているか
- 3) 正しいものを作れているか
1と2については責務をそのまま分割した形にしている。3については先程プロダクトオーナーと分業した責務だが、
- 変に分断を作りたくない。それぞれが越境し、顧客の価値最大化を全員で目指したい
- 開発速度を最大化しても間違ったものを作っていたら意味がないので、開発チームから気づいたものがあれば「正しいものを作る」ための提案をするべき
と考え、あえて改善の軸に入れている。
この3つの軸に分けて考えた時、チーム改善を行う時に施策に一本筋が通るように感じ、いろんなレイヤーで改善提案をしやすくなったと感じている。例えば
- デプロイの自動化
- 開発パフォーマンスに有意に影響を与える「変更のリードタイム」「平均修復時間」「デプロイ頻度」(LeanとDevOpsの科学で言及されている)という指標に良い影響を与えるため、特に開発速度の軸の改善になるだろう
- ソフトウェアアーキテクチャ設計
- 今後柔軟に変更出来る状態にしておくと、開発速度の軸に好影響を与える
- しかし、早すぎる最適化をしすぎると、サービス継続リスクを下げようとしすぎて、むしろ開発速度を落とすことに繋がるので注意する
- レビューフローを改善する
- レビューが遅れると「変更のリードタイム」に悪影響があるため、改善することで開発速度を上げられる
- もし一部のメンバーしかレビューをしていないと属人性の問題を抱えるかもしれない。リスクをコントロールするため、レビューによって属人性をある程度に保つ
- スプリント会におけるタスクの入荷フローの改善
- タスクの入荷フローに問題を抱えると、顧客に最大の価値をもたらす開発を行えなくなってしまう。ここを改善することで、より正しい優先度で開発ができるようになる
- 採用の改善
- 優秀なリソース確保は、開発速度をスケールさせるために必要である
- また採用力が相対的に低まると、サービスを継続させるための最低限の人員も確保できなくなるかもしれない
このようにTechなレイヤー、開発フローのレイヤー、ヒューマンマネジメントのレイヤーなど、どのレイヤーでも3つの軸を意識すると改善の目的がぶれないようになっている。
まとめ
今回は開発チームの責務とは何かについて自分なりに考え、一旦「エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する」とおいたことについて書いてみた。改善の軸を3つに分けて考えるようにしたことで、改善の目的を見失わずに一貫性を持って改善提案を出来つつある。
今後は開発のパフォーマンスを定量的に見えるように、「変更のリードタイム」「平均修復時間」「デプロイ頻度」の可視化や、エラーバジェットの可視化などを進めていきたいと思っている。
