3連休も終わりですね。
連休だったので帰省していたのですが、なんと実家にあの有名な古典の「ライト、ついてますか」があり、思わず一気読みしてしまいました。
この本は問題解決の本で、「エンジニアにきいたオススメの1冊」みたいなのにも取り上げられるような本です。
さて、この本いわく、問題を解決する際（または問題について考える際）に、「それは誰にとって問題なのか？」を考えるべきだと書かれています。（つまり、誰がその問題で困っているのか、誰にとっての問題を解決したいのか、ということ。）
例えば本の冒頭では、ビルのエレベーターが遅いという問題に対して、入居者にとっての問題であると見たときと、ビルオーナーにとっての問題であると見たときでは、問題の解決方法が変わってくるよね、ということが書いてあります。
「たしかになぁ・・・」と思いつつ、ふと身近な問題で考えてみようと思い、このブログ記事を書いてます。
僕らエンジニアでよくある問題といえば、「開発速度が遅い」というやつでしょう。
問題定義
問題はもちろん「開発速度が遅い」です。
ここでウォーターフォールについて頭を巡らせるのも楽しそうではありますが、せっかくなので、ベンチャー企業でBtoCの自社サービスを開発していて、アジャイルを、何ならスクラムを採用しているイケイケなチームについて考えてみましょう。
このチームにとって、「開発速度が遅い」という問題は誰にとっての問題なのか、そしてその問題はどのように解決するべきなのかについて考えていきます。
先に結論
というよりも、この記事では結論を出しません。というか僕もよくわかりません。
解決方法を提案する記事ではなく、問題についてぼんやりと考えてみる記事なのです。
もしも結論や解決方法を知りたければ、スクラムフェス三河にでも行って、そこらへんのスクラムマスターに質問してみるのが一番早いと思います。
（質問する前に「『それはチームによって違います』なんて（役に立たない）回答はしないでくださいね」と付け加えておくと、あなたが欲しい結論が得やすいかもしれません。）
誰にとっての問題か？
さて、話を戻しましょう。「開発速度が遅い」のは誰にとっての問題なのでしょうか。
本に倣って候補を挙げてみましょう。
こんなものでしょうか。
候補を細かく見ていきましょう。
まず、この問題はスクラムマスターにとっての問題であると言って間違いないでしょう。
スクラムマスターはプロセスの権威であり、開発速度の遅さはプロセスの問題であることがほとんどだからです。
スクラムの有用性についての責任もあり、開発速度は有用性を測る指標のひとつにもなるでしょう。
開発速度が低いままだと「お前は仕事をしていないじゃないか」と減給されてしまうかもしれませんね。
逆に、開発者にとってこれは問題になりづらいでしょう。
開発者にとって、開発速度が遅いことは（目に見える範囲）で問題になりづらいので、問題として認識されないように思われます。
開発速度が遅いとどのような悪いことが起きるのでしょうか。遠い将来のことを除けば、悪いことは起きないですよね。
なぜならチームの（遅い）速度をベースに見積もりをし、計画を立てているからです。
どちらかというと開発者が問題として認識するのは、開発速度が遅いときではなく、遅くなったときでしょう。
速度が遅くなった場合はプロダクトオーナーと連携を取る必要が出てきますし、その結果スプリント中のトレードオフが発生する可能性もあります。スプリントレビューのシナリオを考え直さないといけないかもしれません。そしてレトロスペクティブでベロシティが下がったことが議題として挙がり、解決策が考えられるでしょう。
ただ、今回問題にしたいのは、「普段よりも遅くなった」ことではなく「普段から遅い」ことなのです。
一番候補から外れやすいのはユーザーでしょう。
「開発速度が遅いとユーザーに機能を届けるのが遅くなってしまう。そうするとユーザーは困ってしまうぞ。」と言う人がたまにいますが、そんなケースは非常にレアです。
なぜなら多くの機能は、ユーザーに事前告知なくリリースされるからです。
「俺はよく知らない機能がなかなかリリースされなくて困っているんだ！」なんて人はいないでしょう。 （そもそもリリースした機能がユーザーに認知されているのかも怪しいです。）
ユーザーにとって開発速度が問題になるときは、バグ修正のリリースや、すでにわかっている機能のリリースなどの場合（例えばそのユーザーが大口顧客で、機能の追加をしないと契約しないぞと言った場合など）に限られます。
ステークホルダーにとっては問題にはなり得ますが、あまり深刻な問題としては捉えていないかもしれません。
例えば営業の場合、既存の機能をもとに営業をかけることのほうが多いからです。
その企業が新たな機能がないと契約してくれない場合でも、他の代案を提案したり、契約を待ってもらうなど、回避策を用意することができる場合がほとんどです。
ただし、開発速度が遅いことによって自分たちの仕事が増えているので、解決できるなら解決したいと思うでしょう。
経営者にとっては深刻な問題になる可能性があります。
例えばVCに「今季中にシングルサインオンと権限管理の機能をリリースする」などと約束している場合などです。
出資取り止めになることはどうしても避けたいので、何としてでもこの問題を解決しないといけません。
プロダクトオーナーにとっては少し複雑な問題です。
開発速度の遅さは直接的にはプロダクトオーナーの問題ではありません。
どんなに開発速度が遅くても責められるのは開発者やスクラムマスターであり、プロダクトオーナーは開発速度に責任を持たなくていいはずです。
一方で、開発速度は「どのような戦略をとるか」ということに関係してきます。
「もっと開発速度が速ければ、こういう戦略も取れたんだけどなぁ」と心の中で思うプロダクトオーナーは多いのではないでしょうか。
また、自分の考えたものがなかなか形にならず世に出ないということは、心にもやもやを抱えることになりそうです。
このもやもやを解消したいと思うのであれば、これはプロダクトオーナーにとっての問題なのかもしれません。
問題解決のむずかしさ
さて、「それは誰にとっての問題なのか？」を考えてみると、なぜこの「開発速度が遅い」という問題が多くの場所で起こり、そしてそれがなかなか解決されないかの一端が見えてくるように思います。
この問題を解決するのは誰なのか、それはきっと開発者でしょう。
開発者が今までのやり方を変えるなり、認識を改めるなり、残業をするなり、何かしらのアクションをしないと開発速度は上がらないでしょう。
一方で、前述したようにこれは開発者にとっての問題ではないのです。
この「問題の当事者と問題の解決者が一致しない」ということが、解決が難しい原因のように思います。
当事者と解決者が一致しない場合、問題を解決するためにはこの問題を開発者の問題にする必要があります。（「今年中にここまでリリースしないと給料を下げるぞ」といったように。）
アジャイル風に言うと「問題を売り込む」でしょうか。
この売り込み方が、非常に難しいように思います。
アジャイルなチームなのであれば、自己組織化をしなければいけません。
つまり、開発者の代わりに問題を解決したり、解決方法を押し付けるようなことは避けるべきです。
では、どんな方法で問題を売り込めばいいんでしょうか。
さて、ここからはまだ考えがまとまっていません。
たとえば
- 「このままだとVCから投資されなくなってクビにしないといけない」と脅す
- 「開発速度が速いほうがみんな幸せになるよ」と開発者の良心に訴える
みたいなのはすぐに思いつきますが、あまり良い方法ではなさそうですね。
もしこの問題に興味があって良い売り込み方法が思いついた方がいれば、スクラムフェス三河で登壇してみてはいかがでしょうか。
（7月末までプロポーザル出せるっぽいよ！）
