「そもそも開発生産性ってなんだ？」　“勘”ではなく“データ”で判断するために可視化すべき指標

登壇者の自己紹介

佐々木淳志氏：弥生株式会社の佐々木です。私からは、「より早く良いものを多くのお客様に使ってもらうために」というタイトルでお話をいたします。

最初に軽く自己紹介を失礼します。弥生株式会社でCTOをやっている佐々木と申します。弥生での業務ですが、けっこう全体的にフワッとしたことをやっているというイメージがいいかもしれません（笑）。

全社レベルのアーキテクチャ検討とか採用とか教育とかセキュリティ推進とか、そんな感じのことをやっていて、個別のプロダクトというわけではないのですが、なんとなく全体を見ている感じになっています。

趣味などいろいろ書いてあるのですが、『FF14』をやっていたり、自転車で走り回っていたり、お酒を飲んでいたり、そんな生活をしています。

弊社の製品を軽く説明しておきます。弥生というと、弥生デスクトップ、「弥生会計」のパッケージが有名かなと思いますが、実は「弥生オンライン」とかのオンライン製品、SaaS的なものも作っています。あと最近は「弥生Next」という新しい製品ラインを作っています。

ですので、デスクトップメインと思われつつも、実はクラウド会計ソフトも作っています。今は新サービスに注力している状況の会社だと考えていただければと思います。

この中で、一番端っこの弥生Next、このあたりが今まさに作っているところで、今日は、このあたりに関係するお話がけっこう多いかなと思います。

弥生にとって成果とは何か？

というわけで、「開発生産性を考える」と書いてありますが、私の発表は、Howの部分はあんまりなくて、なぜ「Findy Team+」の採用に至ったのかという、WhyやWhatなど、そのあたりの共有がメインのお話です。

開発生産性を上げる。これは悪いことじゃないので、こういった時に反対する人はいないと思うんですけれども。そもそも開発生産性は、具体的に何がどうなったら上がったことになるのか。ここからちょっと考え始めました。

考える時に、よく「ウィキペディア」で調べたりすると思いますが、生産性を調べると、「少ない労力で大きな成果が得られれば生産性が高いと言えるようなものである」ということがわかりました。そうなった時に弥生の成果、これってそもそもいったい何なんでしたっけ？　まずは、ここを考えてみました。

成果を考えるにあたって、「そもそも弥生って何をミッションにしているんだったっけ？」。いったんここに立ち戻ってみました。（スライドを示して）こちらは弊社のミッションなのですが、弊社のミッションを見ると、「スモールビジネスのインフラとして、日本の中小企業、個人事業主、起業家の事業を支える社会的基盤（インフラ）として、日本の発展に能動的に貢献します」。こんなことが書いてあります。

ということは、日本の中小企業を元気にする。これが弥生のミッションなので、これが実現されていないといけないですね。これが成果ですね。

ちょっと大きく見ちゃうと大変なので個々の会社を見ていくと、中小企業と言ってもものすごい数があって、中小企業のみなさんがやっているビジネスはさまざまだと思います。

ですが、インフラはみなさんに使ってもらう共通の部分です。そのあたりはどこなんだろうとあらためて考えると、やはり給与計算や会計業務など、必ずやらなくてはいけないようなバックオフィス業務ですね。このあたりが発生しているはず。

なので、このあたりを支援するという弥生のアプローチは、そもそもミッションと合致しているはず。まずはここを確認します。

バックオフィス業務ですね。そもそもバックオフィス業務をやりたくて会社を立ち上げる方はものすごくレアだと思います。普通は、やりたいことがあって会社を作ります。コーヒー豆を売りたい人がコーヒー豆を売るために会社を作っているわけで、別に会計をやるために会社を作っているわけではありません。

ということで、お客さまがより本業に費やせる時間が増えたら、これは1つの成果なんじゃないかな。こういうふうに定義しました。

もう1つですね。本業に費やせる時間が増えるということと、あと、お客さまのビジネスがさらに伸びる。ビジネスが伸びるというのにもいろいろ定義がありますが、売上が伸びたりなど、そういうところなのかなとうっすら考えています。

可視化すべき指標とは何か

これをどう可視化するのか。可視化しないと基本的に改善は難しいと思うので、定量化、可視化が必要になってきます。

お客さまのビジネスが伸びた。これですね、お客さまの利益が伸びたらビジネスも伸びていると仮置きできるんじゃないかなと思います。

ここでの注意点としては、利益以外を目的としたビジネスもあるかもしれませんが、じゃあ、利益じゃ駄目なのかなとか売上じゃ駄目なのかなとか、そういうものも考えて、1つの重要なファクターとして、サービスが継続できたほうがよいですよね。継続するためには売上とか利益が必要ですよね。

そう考えると、お客さまの利益というものも見ておいて損はない指標なのかな。こういうふうに考えました。

さらには、弥生のサービスがどう満足していただけているか。このあたりも、取っていかなきゃいけない指標じゃないかと考えました。

満足しているのであれば、継続的にサービスが利用されるのではないか。このあたりの仮説が立ち、SaaSの主要KPIなどの測定も必要だろうというお話になりました。Churn RateとかLife Time Valueとかですね。こういうものも含めていろいろ数値を取っていく必要がありそう。

いったん、お客さまの成果から弥生自体の成果に戻り、「弥生の成果って何だ？」という話をすると、お客さまの成果とお客さまの数の掛け算じゃないかと考えました。

日本のインフラになるということは、たくさんのお客さまに使っていただいて、それぞれのお客さまの成果が高くなれば、弥生もインフラとしての価値がある。こういうふうに考えました。

そうなると、個々のお客さまのフィードバックだけじゃなく、ユーザー数やユーザーの伸び率なども見ないといけない、可視化しないといけない、こんな感じに考えています。

サービスの成長につながるループを回していく

では、多くのお客さまに使ってもらえるサービス、お客さまの成果につながるサービス、満足していただけるサービスとは何なんでしょうか？

これを悶々と考えていてもわからないです。実際にお客さまに聞いて、そこで当たりをつけて分析して、それを基に動くものを使って、実際にお客さまに当てて反応を見る。よくあるアプローチですが、これが一番早かろうと考えています。

自分自身のことを考えても、動くものを見て、「あっ、これは使えるね」とか「これは便利だね」と言えたほうがわかりやすいと思うので、動くものを出していく。これが非常に重要なことだと考えています。

ざっくり言うと（スライドを示して）こんなループを早く回しましょうということになると思います。使ってもらって、改善して、これをクルクル回します。

発表資料的に、ちょっとこれだとシンプルすぎるので、もうちょっとそれっぽい図にしてみました。「Amazon」のビジネスモデルで有名な図があると思うんですけども、それっぽくちょっとループするものを表現してみました。

機能が増えたら、ユーザーの成果が増えるでしょう。ユーザーの成果が増えたら、ユーザーが増える。ユーザーが増えたら、フィードバックが増える。フィードバックが増えたら、そのフィードバックを使って機能向上ができる。こういうサイクルが回るはず。

（スライドの）真ん中にサービスの成長とか弥生の成長とかありますが、規模が拡大したら低コスト体質になって、その結果、機能向上への投資余力が増える。もしくは低価格にするとか、そういう作戦が考えられるんじゃないか。このループを回すんですね、という考えに至っています。

このループを実際に回すとなった時に、それぞれきちんとループが回っているかの定量化、可視化が必要になってきます。

ここで可視化すべき項目として、例えばユーザーの成果などはユーザーの利用時間を取ったり、弊社だと会計の製品だったりするので、会計のある業務に実際にユーザーが費やした時間とか、このあたりを測定したり。

あと、ユーザーがきちんと増えているか。このあたりはユーザー数、ユーザー満足度を見ていけばいいかなと。フィードバックは、お客さまが使っているとデータがどんどん増えるので、そのデータが使えるんじゃなかろうかと。

単純な機能開発というのもありますし、そのデータを分析してなにかをやるというのもあります。さらには、機械学習のモデルを作ってなんかやるとか、そういうものも考えられます。

あとは、このループがどんな頻度で回っているかとか、機能のリリースがどれぐらいのスピードで行えているかとか、このあたりも見ていく必要があるよねと。さらには、弥生自身の施策がきちんと費用対効果が出せているかとか、このあたりも可視化する必要がある。こんな感じで考えています。

正しい試行錯誤をしながら正解に向かっていく必要がある

早くサイクルを回すというところですが、「そもそもなんでサイクルが早くなきゃいけないんでしたっけ？」というところを考えてみます。

上がサイクルが長い状態で、下がサイクルが短い状態ですね。サイクルが長いとゴールに向かって試行錯誤する時の方向転換が遅くなりますよね。下のサイクルが短い状況だと、方向転換がそれなりに細かくできるので、最終的にゴールに至るまでの距離は短く済むんじゃないか。

スタートからゴールに向けて一直線で行けるパターンもあると思いますが、それはちょっと目標設定が低いかもしれないですね。こんな感じで考えています。

ここで注意すべきなのは、ゴールは動き回るはずということです。となると、今のゴールはどこにあるかをマメに見ていかないと、変なゴールに向かっていっちゃうんじゃないか。正しく努力していきましょうみたいな意味で、ここはきちんと補正しながらやっていきましょう。そのためにもスピードが必要になるんですよ。こんな感じで考えています。

なので、ここまでの話を軽くまとめると、早くやんなきゃいけないですよね。早くやるにしても、変な方向に向かっていたらしょうがないので、正しい試行錯誤をしながら正解に向かっていく必要がある。これができている状況が開発生産性が高いんじゃないか。こんな感じで考えています。

早くというところですが、リリース頻度を高くとか、スピードだけを追い求める……先ほどデプロイで、「1行単位でプルリクをつけろ」みたいな話もありましたが、それってやっちゃってもあまり意味がないので。

今までのお話をきちんと踏まえた上で、お客さまの成果を出すために適切な範囲で自分の状態を知りながらやっていく。これが重要じゃないかなと思います。

早さをひたすら書いていたので、ちょっと品質の話も入れておかないとまずいなと思ったんですけれども。t_wadaさんの発表にあるとおりなんですが、一般的に品質を犠牲にして早くする。これはあまりいいアプローチじゃないですね。

品質が犠牲になると結果的にむしろ遅くなる。早くするのであれば品質も担保しながらやっていく必要がある。ここは重要なポイントかなと思います。

（次回へつづく）