プロジェクトをとにかく進める、そのためにメンバーに認めない“甘え”とは――ビービット 那珂将人氏《後編》

前編はこちらから。

どれだけやろうがアウトプットがなければ評価はゼロ

――次は、開発組織についてお伺いしたいと思います。スクラムなど、特定の方式を取り入れていらっしゃいますか？

　チームによるんですが、機能開発では結構スクラムをやっています。ただ、きちんとできていないチームもあるので、詳しい人に入ってもらってスクラムのやり方自体を見直し、横展開しようとしているところです。一方、インフラやデータ解析はスクラムが合いません。タスクの粒度が大きく、毎スプリントで結果を出すというようなサイクルにうまく収まらないところがあります。

　ただ、スクラムって、課題を見つけたり優先順位をつけたりするのが目的なんですよね。課題がはっきりしているからスクラムを取り入れない、というのも含めてスクラムの一部だと言われたりもするらしいので、何とも言いづらいですが（笑）。

――全社的にもプロダクトへの期待が大きい中、開発者チームの運営で増やそうと意識されているのは、「知識」「意欲」「時間」でいうと、どれでしょうか。

　私が特に周囲の人に対して増やしたいと思っているリソースは、デベロッパーの「意欲、やる気」ですね。

　具体的には、私自身はCTOの直下にいて、会社としての決定事項や方針を近くで聞くことができます。「今やっていることは会社の目標にどうつながっているんだっけ」ということの理解は、意欲ややる気につながります。それが結びつかないと意味ないですよね。そもそもいくつか目標があって、今この瞬間にやっていることが何らかの形で結びついていないと、本当にやめたほうがいい、ということになってしまいます。

　あと、アウトプットにはこだわっていて、「どれだけ作業をしても、外に出なければゼロだ」という話もよくしますね。当たり前じゃないですか、どれだけテストコード書こうが何しようが、リリースしなかったらゼロ。全員スコアゼロ点だよ、と。

――方針を説明するときに凝らしている工夫は何かありますか？

　前の会社でOKRを使っていたんです。会社のトップが決めた抽象的な目標を具体的なものに落とし込んでいく。それに近いことをしたいと思っています。そのときに採る方法は自由でいいと思っています。忘れてほしくないのは、どんな課題を解決したいのかということ。そのために私は、それを解決したら何につながるかを説明するようにしています。