スクラムで役立つアジャイルなマインドセット その3 ビジネスの成功を目標にする
アジャイル開発をするうえで大切なマインドセットを数回の記事に分けて紹介しています。真面目に仕事をしているはずなのに、なぜか上司からチームへの評価が高くない、他のチームに比べて指摘が多いなど、そういったお悩みを解消するお手伝いができたらと思います。
第1回は、「小さく挑戦・小さく試す」でした。
第2回は、「担当領域を明確に分けず、全員で成果を出す」でした。
第3回は、「ビジネスの成功を目標にする」です。
3つ目の大事なマインドは、「ビジネスの成功を目標にする」です。こう説明すると「仕事なんだから、当たり前じゃん」と思う方もいらっしゃるかと思います。しかし、そう考える方はそんなに多くなかったり、思いはしつつも行動が伴っていない場合が非常に多いのです。
「ビジネスの成功を目標にする」が当たり前じゃんと思った方も、もう少しだけ読み進めてみて自分や、周りの同僚達が該当していないか確認してみてください。
例えば、ビジネスの成功を目標にせずに、こんなことを目標にしてしまっている例をよく見ます。
エンジニアがコードの綺麗さを最優先に考える
エンジニアがテストコードやテストの自動化を最優先に考える
QAが品質を最優先に考える
スクラムマスターがチームの成長を最優先に考える
プロダクトオーナーが質の高いプロダクトバックログを作ることを最優先に考える
マネージャーや、プロダクトオーナーは、ビジネスに近い位置にいるのでビジネスの成功の優先順位が高い傾向にあり、あまりこういった方を見かけることは少ないですね。しかし、それ以外は、ある程度の数がいらっしゃるのが現状です。その時のプロジェクトの状況にそぐわないがコミュニティで良いとされている方法や、自分たちが働きやすくなること優先してしまうといったものです。
さらに、スクラムのカイゼンをしていると、仕事のプロセスの変更をするときに、ビジネス的にはデメリットが大きいが自分たちが働きやすくなる方法を選択してしまうチームもよくあります。こういったときに、自分たちが「ビジネスの成功を目標にする」ことができているのか、改めて自分たちに問い直してみていただきたいです。
なぜなら
なぜ、私はこんなにビジネスの成功にこだわって説明しているのでしょうか。会社は一般的に営利組織でビジネスを成功させることや、ビジョンを実現するために存在しています。そして、何をするためにもお金が必要です。
従業員として、みなさんを雇い続けるためにも、皆さんに賞与を多く出すためにも、昇給させるためにも、ビジネスの成功が必要なのです。それに加え、アジャイルをやることになった、テスト駆動開発をやりたいと思った、もっと便利な開発ツールを導入したい、そんなときに、研修に自由に参加できたり、詳しい人が伴走しながらスキルアップやプロジェクトの成功を応援してくれたほうが良くないですか？ビジネスとして成功することで、こういった選択肢も多く取りやすく（上長も許可しやすく）なります。
「ビジネスのことは偉い人が考える役割だから関係ない」といった意見もたまに聞きますが、こちらに対しても2つ目のマインドセット「担当領域を明確に分けず、全員で成果を出す」で考えてもらえたらと思います。偉い人が考える役割かもしれませんが、偉い人だけがビジネスを考えている会社よりも、会社全体でビジネスを考えている会社の方が成功しやすいのではないでしょうか。また、局所最適の罠に引っかかりづらくなりますよね。
ビジネスの成功よりもエンジニアの快適さばかり優先してしまったチームの末路
まだ、私が未熟だった頃に失敗してしまったプロジェクトの事例を紹介します。このプロジェクトは会社での仕事ではなく趣味でのWebサービス作りでしたが、ユーザに使ってもらって収益化をゴールとしたものでした。
そのプロジェクトでは、メンバーはエンジニアばかりで構成されていること、新規のサービスを立ち上げ途中で収益化できていない、すなわちビジネスをまだ成功させていないチームでした。まだ、サービスが起動に乗っていないので、継続開発が続けられるかどうかも、わからないタイミングです。
本来そのようなチームが最も優先すべきことは、ユーザに使ってもらえるような、満足してもらえるような、機能を作ることです。もし、作ったものが使われなかったらその機能はボツにする可能性も高く、どの機能もメンテナンスをする可能性は低い状態なためです。
当時、発言力のあるエンジニアが、テストコードを書くことと、慣れていないが最新でエンジニア界隈ではアツいと言われている設計を導入しようと提案しました。最も技術力もあり発言力もあるエンジニアからの提案だったため、チームはその提案を承諾してしまいました。
テストコードを書くことや、素晴らしい設計手法というのは、メンテナンスを継続すればするほど恩恵を受けられる取り組みです。また、テストコードを実装することや、慣れていない設計でシステムを開発するということは、開発速度を犠牲にします。要するに、この提案は、新規開発のコストは大きいがメンテナンスコストを小さくするための施策だったわけです。
もしビジネスの側面を重視すれば、メンテナンスする機会がどの程度あるのかも分からない機能を開発するときにメンテナンス性を高める施策を取り入れるということに賛成するはずがありません。代わりに新規開発のコストを下げるために見送ろうと提案するはずです。
しかし、このときはビジネスの成功を目指していたにもかかわらず、意思決定のときにエンジニアとして良いとされているテストコードを書くことや、良い設計で開発することが望ましいと考えて承諾したのでした。つまり、ビジネスマンとしてではなくエンジニアとしての価値判断に基づいた意思決定を行ったわけです。
もちろん、このプロジェクトの結果は説明するまでもありませんが、サービスがユーザに使われることはなくクローズしてしまいました。多くの労力を投資したにもかかわらず、サービスは失敗に終わることになりました。このとき、テストコードや慣れない設計をすることにならなければ、同じく失敗するにしても開発のコストがもう少し小さくすんだのではないかと思います。
これは趣味のプロジェクトじゃないか、仕事でやる場合は全然違うのではないか？といった意見もあるかもしれません。しかし、仕事でやる場合はエンジニアチームを抱えるということは毎月コストとして何百万円もかかってしまうことであり、余計にシビアになってきます。そのため、趣味か仕事かにかかわらず、ビジネスの成功がなければ長期的に投資判断をすることは、判断が難しくなるでしょう。
「ビジネスの成功を目標にする」ための具体的な施策
ここまで説明した「ビジネスの成功を目標にする」ことに取り組むときに、よく使われる指標がアウトカムです。最近のアジャイルの界隈では、アウトカムを重視しようという流れが活発になっています(1)(2)(3)。アウトカムとは、ユーザや顧客に対して提供できる価値です。AmazonのようなECのモールであれば、便利に買い物ができるようになった、ほしかったものがすぐに見つかるようになった、買い忘れでのトラブルを避けられた、などです。
このアウトカムは、会社の利益にかなり大きな影響を与えることと、自分たちの仕事の結果として得られたことが比較的わかりやすい指標です。だから、自分たちの仕事をするときに、アウトカムを重視して業務をすることで自分たちの仕事がビジネスの成功に影響しているのか考えやすくなります。
では、もう少し具体的に、アウトカムを重視して業務をするとはどういったことでしょうか。スクラムでは、プロダクトゴール（製品の目標）を設定することが規定されています。いわゆるKPIを設定して、スクラムチームでその指標を追っていきましょう。
例えば、チームのプロダクトゴールが「新規ユーザが2日目に何％利用継続をしてくれるか」であったら、それを日次や週次で計測しチームで毎日確認するといった方法が取れます。こういった数値をチームで毎日確認し、それに対して対話することを繰り返していくうちにチームがビジネスの成功を目標にしやすくなります。
もう一つの方法は、チームで何かしらの提案をするときに、なぜ会社に役立つのか？なぜユーザに役立つのか？を他のメンバーが理解できないときは説明を求めることがあげられます。
例えば、「iOSがバージョンアップしてアプリにこういった機能が搭載されたから、こんな機能が提供できます。」といった提案がチームからあったとしましょう。それに対して、「それは、なぜユーザに役に立つのでしょうか？」と聞いて良いというルールを作っておくのがオススメです。
こういった、「なぜ？」を聞くことは攻撃的な意味合いに取られてしまう可能性もありますが、チームでそれを聞くことが、みんなで目線を合わせて施策に取り組むときに有用であると認識し、ルール化しておくことで質問のハードルを大きく下げることができます。
まとめ
ビジネスの成功を目標にして活動しないと、それぞれの業種が自分たちの仕事の最適化をしてしまいがちである
対策1：アウトカムを継続的に計測し、チームでアウトカムに関する対話をする
対策2：「なぜ、会社/ユーザの役に立つのか？」を質問していいルール作りをする
参考文献
この記事が気に入ったらサポートをしてみませんか？