アウトカムに向き合う前に開発者がやるべきこと
はじめに
昨今のソフトウェア開発では、
アウトプットじゃなくて、アウトカムに着目しましょう
ということがよく言われており、当たり前になりつつあります。
たしかに、どんなに早く作っても、誰にも使われないモノを大量生産してはせっかくの努力が報われません。いわゆる「ビルドトラップ」というやつです。
しかし、開発者目線で見たとき、これは一定のアウトプットを出している前提の話なので、まずはアウトプットに向き合うことから始めませんか？という話をしたいと思います。
いきなりアウトカムに向き合うのは難しい
ソフトウェア開発は、不確実性がとても高いです。
そのため、「経験主義」という とりあえずやってみてそこから学んだことを積み重ねる という姿勢で開発することで、私たちはそれに立ち向かっています。
しかし、いきなりアウトカムに向き合おうとしても「とりあえずやってみる」のスピードが遅いと学ぶためのスタートラインにも立てません。
まずは、仮説検証を高速に回すような土台を作ったうえで、その質を上げていく必要があります。
スクラムガイドでは、開発者は次のように定義されています。
ここから、開発者はまず「作成すること」に対してコミットメントする必要があることが分かるかと思います。
開発者はスクラムチームの⼀員である。各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。
つまり、「開発者はいきなりアウトカムに向き合うのではなく、まず一定のアウトプットを確約できるようにしましょう」ということです。
と、ここまで話してきましたが
すでに @onk さんがすでに私が言いたいことを分かりやすくブログに書いていただいているので、ぜひご覧ください。
どのようにアウトプットに向き合うか
開発者として、どのようにアウトプットに向き合うとよいのでしょうか？
私たちのチームでは、次のようなことを行なっています。
チームの現在地を定量的に計測する
個人のスキルを伸ばす
チームの現在地を定量的に計測する
まずはアウトプットを定量的に計測をできるようにしました。
具体的には、Four Keysと呼ばれるパフォーマンス指標を使っています。
これは、 DevOps Research and Assessment（DORA）が提唱する、ソフトウェア開発チームのデリバリーパフォーマンスを示すことができる、次の4つの指標のことです。
デプロイ頻度 - 本番環境へのデプロイ頻度
変更リードタイム - コミットからデプロイまでの所要時間
変更障害率 - デプロイ起因の障害が発生する割合
サービス復元時間 - 障害から回復するのにかかる時間
また、DORA の発行する State of DevOps Report にて、これらの指標に基づくクラスタ分析でチームを「エリート」「ハイ」「ミディアム」「ロー」の 4 つにグルーピングしています。
この基準を使うことで、自分たちのチームが今どのレベルにあるのかをグローバルな基準で評価できます。
そのため、客観的にチームの状態を判断しやすいということもあり、この指標を採用しました。
個人のスキルを伸ばす
計測するのは大事ですが、それだけではチームは成長しません。
ここで、もう一度スクラムガイドにおける開発者の定義を見てみましょう。
開発者はスクラムチームの⼀員である。各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。
このように開発者は「インクリメントのあらゆる側面」を作成することが求められます。
つまり、自身の専門性を発揮しつつ、やれる範囲を広げていく必要があります。
次の図のように、チーム内で各々が自分の仕事だと捉える領域の重複が増えた状態が、チームが最も発展するタイミングと言われています。
つまり、個々が自分の仕事だと捉える領域を増やしていくことで、成長するチームが作れるのです。
私たちのチームでは、個々での自己研鑽はもちろん、お互いの専門領域を越境し合うことで、個人のスキルを伸ばしています。
具体的な取り組みの例をチームメイトが記事にしてくれてましたので、気になる方は覗いてみてください。
気をつけていること
開発者としてアウトプットに向き合うようにしつつ、取り組む中で次のようなことに気をつけています。
数字の上下に一喜一憂しない
やはりアウトカムも大事
コミュニケーション量を増やす
数字の上下に一喜一憂しない
Four Keysでパフォーマンス指標を定量的に可視化しましたが、よくあるのが数字の上下に一喜一憂するということです。
数字に振り回されていると、次のように指標を良くない方向にハックし出す可能性があります。
デプロイ頻度を上げたいので、顧客価値のない単位まで細かくしてしまう
変更リードタイムを短くするために、低い品質のコードをデプロイしてしまう
etc.
エンジニアという生き物の特性上、これは仕方ないことです。
そのため、私たちのチームでは「これは健康診断です」と言って、数字の裏にある成功要因や障害要因を特定して、見つけた要因に向き合うことで、定量的な指標と付き合うようにしています。
やはりアウトカムも大事
アウトプットが大事と言ってきましたが、チームとして私たちがここにいる理由は「たくさんのアウトプットが出せるようになること」ではありません。
私たちは趣味でやっているわけではなく、ビジネスでソフトウェア開発をしています。そのため、作ることでたくさんのユーザーに使ってもらい、利益を生み出す必要があります。
そのため、チームの土台として一定のアウトプットを出せるということは重要ですが、それに囚われすぎないこともまた大切です。
手段と目的が入れ替わらないように、一定のアウトプットを出せるようになったらアウトカムに向き合えるような柔軟さを持ち合わせましょう。
私たちのチームでは、Four Keysでエリートの指標が出るようになったタイミングで「どうやったらアウトカムに向き合えるか」という話をして、目的を見失わないようにしました。
コミュニケーション量を増やす
チームとしてアウトプットを出すことを注力したり、アウトカムを出すことに注力したりと、フェーズに応じてチームとして注力したいことが変わってくることがあります。
これは、ゴールやビジョンを共有したり、そのための現在地を共有したりすることで、個々の認識が揃いやすくなります。
しかし、同じ言葉や言い回しを使って説明しても、人によって捉え方が変わっていて、実はお互いに全く違うことを考えていたなんてことは、稀によくあります。
そのため、私たちのチームでは、インセプションデッキを作るのはもちろん、普段の開発の中でのコミュニケーション量を増やすことで対策しています。
具体的には、次のような取り組みです。
Slackのハドルに常駐して、すぐに相談できるようにする
毎朝、POを交えてディスカバリーについて話す時間を設ける
週2回程度、チーム全員で今考えていることを雑に話す時間を設ける
このように、様々な角度で話をすることで、お互いの認識の違いに気付けるタイミングを増やすようにしています。
最後に
力こそパワー！
個々で力をつけて、強いチームを作っていきましょう！！
ただ、手段と目的が入れ替わらないようなバランス感覚も大切なので、お忘れなく。