去年認定スクラムマスターになって、実際に自分の開発チームにScrumを導入したり、最近ではチーム内でテックリード交代して開発プロセスの高速化についてより考えるようになってきた。
Agile, Lean, XP, DevOps, Four Keys, Team Topologies など様々なフレーズを見かけたり本を読んだりしたところ大体皆同じ場所を目指していると感じるけど、イマイチ自分の脳内インデックスが貼れていない気がしたのでこのエントリで軽く考えを整理してみようと思う。
- とにかく改善のサイクルが回っていない (ソフトウェア開発に限らない)
- 開発速度が上がらない (ソフトウェア開発者側)
- チーム内での連携が上手くいっていない
- チームの構成がイマイチ・他チームとの連携が上手く取れていない
- まとめ
とにかく改善のサイクルが回っていない (ソフトウェア開発に限らない)
まず一番わかりやすいのが、特に改善サイクルを回している感じがなくて、ここ数年ずっと効率が悪い進め方をしていますという状況。これはソフトウェア開発に限らずどんな作業でも共通で、改善したいならIncrementalにIterativeなプロセスを取ると良い。つまりAgile FrameworkでいうところのScrumを導入してみると良さそう。絶対Scrumを導入したほうが良いというわけではなく、期間を区切って仕事をして振り返りを行って次に活かすというのをやっていれば良いが、1からプロセスを考えるくらいならScrumを参考にするのが良さそう。
開発速度が上がらない (ソフトウェア開発者側)
がんばってソフトウェア開発しているがイマイチ速度がでない、というときはいくつか要因がありそう。何はともあれまずはFour Keysの指標を使って計測して現状を把握する必要がある*1。Four Keysについては以下のエントリが参考になる。
yigarashi.hatenablog.com
その上で要因としては以下のようなものがある。
- ソフトウェアの設計に問題がある
- 開発環境やCI/CDが整っていない
- チーム内外との連携が上手くいっていない
上二つについてはExtreme ProgrammingやDevOpsのプラクティスを実施すると良い。少なくともWebアプリケーションエンジニアとして働いている身としてはScrumもXPもDevOpsも全部意識するのは当たり前という感じで最近考えています。
Extreme Programmingのプラクティス
Extreme Programming (XP) のプラクティスは、普段あまり意識していないかもしれないが、ソフトウェア開発には欠かせないものなど沢山含んでいる。実施できていないものがないか見直していくと開発速度の向上 (Four Keysの向上）に役立つはずです。
いくつか適当にピックアップしてみると、
DevOpsのプラクティス
ソフトウェアをユーザに届けるには、アプリケーションコードをアプリケーションエンジニアが書くだけではなく、その書いたコードを適切なインフラでユーザ向けにリリースして運用する必要がある。そのため、DevとOpsで歩調を揃えていかないと素早くリリースできない。
Four Keysの指標をここで改めて紹介すると以下の4つです。
- デプロイの頻度
- 変更のリードタイム
- 変更障害率
- サービス復元時間
ゴールとしては全ての指標を高水準に保つことであるが、それには素早くデプロイできることや、問題に素早く気づいて修正できることなどが大事になる。DevOpsのプラクティスも導入できると良い。
上記のエントリを参考に簡単にまとめてみます:
- アジャイルプロジェクト管理
- ここにはアプリケーションの要件だけではなく、インフラ面の話題も同列に管理できると良いと思います
- CI/CDを整える
- Extreme Programmingでも取り上げられているテスト駆動開発(TDD)と組み合わせると早い段階で問題に気づけて良い
- また、CDを整えることによってデプロイのたびに「インフラ担当」と連携する時間を減らせる
- Infrastructure as Code (IaC) する
- TerraformやCDKに落とし込むことによってアプリケーションエンジニアがインフラを触りやすくなる
- 可観測性をあげる
- 障害が発生したときなどに誰でも対応しやすくなる
- 文化を変える
- ソフトウェアがデプロイされているインフラにも、アプリケーションエンジニアが責任を持つという文化にする
ちなみに最近はDevOpsから派生してDevSecOpsやBizDevOpsなどの用語もでていて自分は実施したことはないが、結局どれもソフトウェアをユーザに届ける流れに色々な仕事を上手いことフローに組み込めるといいよねという話なのかなと思います。
チーム内での連携が上手くいっていない
チーム内の話であれば、基本的にはScrumなどを実施している前提でデイリースクラムや振り返りの場で相談するのが良いと思う（自己組織化されているチームなら自分達でいい感じにできそう）。ただしそうなっていない場合はメンバーを信頼できていないとか、まだ自己組織化の域に行っていないなどがありそう。
信頼については心理的安全性、HRTみたいな話になりそう。ここについて自分は知見をあまり持っていないが、チーム内での関係性が構築できていないとScrumとかXPとか言ってもうまいこと回らなそうということだけわかる。
blog.toshimaru.net
エラスティックリーダーシップは現在のチームの状況を元に適切なモードを判別し、次にどのような動きをするべきかの参考になるので「なぜか自己組織化されたチームになれない」という時に有効です。
ちなみにメンバーの成長とか、コードを自分達の物にする、とかをしたい場合もXPのPair Programmingのプラクティス実施がおすすめです。
チームの構成がイマイチ・他チームとの連携が上手く取れていない
ソフトウェアの設計も最高で、CI/CDもIaCもできていて、Scrumもやっていて最高だけど、もっといいチーム編成があるのではないかというときはTeam Topologiesの本が参考になる。
そもそも他チームとの連携で時間を取られているとか、巨大なモノリシックなリポジトリに複数サービスが相乗りしているから気軽にデプロイできないとか、コンウェイの法則によって開発の進め方が縛られているが本当は別のチーム編成ならもっと高速に開発できるとか、そういうことはよくあるのでそこを見直すことも大事。
チームの編成を考えると言われると上層レイヤーの人々の仕事という気もしてくるが、アプリケーションコードとの対応や適切なデプロイフローなども意識する必要があるので決めるにはソフトウェアアーキテクト的なポジションの人の関与が必要です（みたいなことが本にも書いてある）。
まとめ
ここまで色々と書いてきてわかったこととしては、ボトルネックはスコープやカテゴリでわけることができそう。*2
- スコープ
- 職能チーム（エンジニアチームなど）
- 機能開発チーム (企画からリリースまでを含む)
- チーム横断
- カテゴリ
- アプリケーションコードなど (設計、リファクタリングなど)
- 開発フロー周り (Scrum、XPなど)
- 人間関係 (信頼、メンバーの成長など)
Software Architect, Techlead, Engineering Managerみたいな名前の職種の場合はこういうスコープやカテゴリの中で色々とボトルネックを考えた上でどういう方法・順番で改善していくかを考えていくのかなと思います。いちSoftware Engineerでも今回話題にあげたXPやDevOpsの項目、Four Keysなどをちょっと調べてみて実践してみたりTechleadに話題を出してみて改善を促してみるなど働きかけるのが良いかもしれません。また働きやすい同僚としてHRTを改めて意識して生活するのも良いですね。
*1:ちなみにScrumにベロシティという指標がありますが、ベロシティはあくまでリリース予測などに使うと便利で開発速度の指標には向いていません。
*2:Engineering Managerの四象限を考えるとプロダクトマネジメント方面の話題もあるが今回は取り上げていません。
