品質を犠牲にせず“今より早い開発”を実現するために　Four Keysの可視化を用いた改善プロセス作り

各チームごとのふりかえりのためにFour Keysを計測して可視化する

佐々木淳志氏（以下、佐々木）：というわけで、全体をさらっとまとめると、開発生産性を上げようというところを考えるにあたって、「そもそも開発生産性って何なんだ？」とか「弥生がやるべきことって何なんだ？」を整理した上で、Four Keysを計測して可視化することで取らなきゃいけないデータの一部が取れるんじゃないか？　このような仮説の下、Findy Team+の導入を決めています。

今までの考えの中で出てきたと思いますが、あくまでお客さまの得られる利益を最大化するための手段なので、見た目上のスピードを上げるということを追い求めているわけではありません。

いろいろと開発の施策はやっていくと思いますが、開発の施策をやった時に、その施策が効果のあるものだったのか、きちんと結果が出ているのか、そのあたりを把握するために数値で現状を可視化して、それがどう動いていったのかを把握していこうとしています。

Four Keysの指標などを、他のチームとの単純比較に使うつもりは基本的にありません。今の状況を把握して、きちんと健康な状態がキープできているかとか、その数値を見て、「ここの数値が他の数値に比べて、なんかちょっと低いかな？」。

弊社のチームで1個あったのが、ある項目は金なんだけれども、1つだけ銅のものがあった。「他は金なのになんでここだけ銅なんだ？　じゃあ、ここをみんなでディスカッションしていこうか」みたいな使い方をしているチームが出てきています。

なので、弊社としては各チームごとのふりかえりとか、そういうことに使おうかなと思っていて、基本的には他チームと横並びで比較というところでの利用は考えていません。

という話の中で、弊社の開発規模をちょっと紹介したほうがイメージがつかみやすいかなと思ったのですが、今弊社には開発者が400名ぐらいいて、その中の100名ぐらいが新サービス開発に関わっているメンバーです。

新サービス開発は複数同時並行で動いていて、1つのプロダクトに対してだいたい小さいプロダクトで10名弱、大きめのプロダクトだと30名とか、そのぐらいの規模で動いています。30名のチームだと、スクラムチーム4つぐらいに分かれていて、ツーピッツァで収まるぐらいの規模のメンバーで開発をしている。そのような体制になっています。

各チームにこういう数値を見てもらって、自分のチームの状況を把握してもらって、各チームで改善してもらう。そのような使い方をしようかなと思っています。

というわけで、これ系のセミナーのお約束になるかなと思いますが、弊社も新サービス開発のチームを中心に開発者を募集中です。フロントエンドの方、QAエンジニアの方、あとはAWSが好きな方、詳しくなりたい方。このあたりの方にジョインしていただけるとおもしろい環境なんじゃないかなと思います。

私は個人的にAWSが好きで、AWS関連の教育はけっこう充実してきているかなと思っています。

というわけで、私からの発表は以上です。ありがとうございました。

司会者：ありがとうございました。みなさん、チャットやリアクション、パチパチをお願いします。はい、ありがとうございます。

「そもそも、開発生産性とは何か？」というところから入っていただいて、「どうやって可視化する？」という点については、けっこう「X」でも、「現場に下りたり、実際に試したりするのが早い」とか、「品質を犠牲にしたらちょっとしんどいですよね」というような共感コメントがたくさんありました。

生産性の可視化をどのように組織に説明したのか？

司会者：いくつか質問が来ています。せっかくなので事前質問も取り上げたいと思います。

1つ目の質問ですね。「開発生産性の可視化をどのように組織に説明、導入していったか。アウトプットの開発生産性とアウトカムの価値との結び付けはどのようにしているかといったところをおうかがいしたい」という質問があったのですが、ご回答いただけますか？

佐々木：開発生産性のところでいうと、けっこう経営陣から「生産性を上げなさい」みたいな、全社的な号令が出ている中で、「開発生産性とは何だろう？」ということを考えるきっかけにもなったんですけれども。

ちょっと、KPI、KGIの話と逆方向になるのかもしれませんが、単純に開発生産性を定量化して、それで他組織と比べるという状況にしたくないというのがあって、いろいろこういうものを調べたりしていました。

そうなった時に、可視化はするのですが、「可視化したことで各チームにもたらされるメリットって何だ？」というのを考えた時に、各チーム自身が自分の状況を把握して、自分自身でふりかえれるようにする、そのための情報を提供する。ここに主眼を置いた施策となっています。

司会者：ありがとうございます。お答えになっていたら幸いです。

トップダウンとボトムアップ、どちらで進めた？

司会者：「弥生さんでは、もともとみんなが開発生産性という認識があった上でボトムアップでいったのか、佐々木さんのトップダウンのどちらで進行したのか？」というところ。あと、「『開発生産性ってそもそも何か？』の議論をどのレイヤーで行って、組織に根付かせていったのかをおうかがいしたいです」というところですが、いかがでしょうか？

佐々木：もともとという意味だと、トップダウンとボトムアップ、両方がちょうどいいタイミングで来たというイメージを持っています。もともと、このあたりの施策をやっていこうというのは、どちらかというとボトムから出てきたお話です。

ボトムから出てくると同時に、弊社は2023年に株主が変わって、経営陣がちょっと代わったりしています。経営からも生産性向上というお題が出てきて、ちょうどトップダウンとボトムアップでやらなきゃいけないタイミングが被ったという感じになっています。

弊社のもともとの傾向としては、生産性というキーワードよりも、品質というキーワードが社内でよく聞かれていて、品質をどうやって積み上げていくかみたいな、そこに主眼を置かれた会話がされることが多いですね。

かなり品質を意識する文化だったので、ちょっと過剰な取り組みがないとも言いきれずに遅くなっているところもあったのかなというイメージを持っています。「品質を担保しながら無駄なところを省きつつやっていったら生産性が上がるんじゃないかな？」みたいなことを現場で話している時にちょうど、この施策のアイデアが出てきた。そんな状況になっています。

司会者：ありがとうございます。

経営層に対して費用対効果をどう説明しているのか？

司会者：次、さくさくといければと思います。その下ですね。「生産性の取り組みについて、費用対効果など、どのように経営層への説明をされていますか？　もしくは、される予定でしょうか？」というところですが、いかがでしょうか？

佐々木：このあたりは、「まずは、可視化しないと測定できないよね」という話から始めています。そういう意味だと「生産性向上の第一歩には可視化が必須です。まずは、可視化から始めましょう」と言っています。

過去の情報は可視化されていないところも多いので、そもそも可視化できていない時は、可視化から始めるのがセオリーですよね、みたいな感じで始めてしまっています。

司会者：なるほど。ごもっとも、みたいなところがあるかなと思います（笑）。ありがとうございます。

機能の変化に対するユーザーの抵抗にはどう対処する？

司会者：次ですね。「BtoB SaaSの場合、機能が少しずつ改善される（機能が変化する）と、ユーザーの抵抗が大きいような気がするのですが、そういうことはないのでしょうか？」。変更機能がまずかったからってなかったことにはできなさそうですし、というところですね。こちらに関しては、いかがでしょうか？

佐々木：おっしゃるとおりでして、お客さまの特性によって、やはり好まれるものがあるかなと思います。

弊社だと、デスクトップ版のアプリケーションとかですね。そっちのほうは機能改修でボタンが1個増えると、「なんで増えたんですか？」とか問い合わせが来る感じだったりするんですけれども。

それに対して、そんなに頻繁にやってしまうと逆にオペレーションが崩れてしまうので、そういう使われ方をしているお客さまには、適した頻度でやっていこうかなと思っています。

一方、新サービスのほうは、ちょっと頻度を上げていこうと考えています。どっちかというと、新しく起業されたお客さまをターゲットにしていて、比較的、画面のちょっとした違いをあまり気にしない、「むしろ自分で操作しないで裏で勝手に自動でやっておいてよ」というお客さまをターゲットとすることでカバーしようかなと考えています。

司会者：ありがとうございます。

品質を担保できるように取り組んでいることは？

司会者：もう1個質問が来ているので、こちらもお時間のある限り答えていただければと思います。

「プロダクトのフェーズにもよると思いますが、品質を犠牲にしないとすることは、言葉よりも難しいことだと考えています。品質を担保できるように取り組んでいたことはありますか？」というところなんですが、いかがでしょうか？

佐々木：おっしゃるとおりで、言うのは簡単だけど実行するのは難しいというタイプのやつですね。弊社もいろいろ取り組みはしているのですが、もともとはウォーターフォールの各フェーズで、きっちり関門を設けて、そこで品質を上げていくアプローチを取っていました。

ウォーターフォールで半年などのフェーズで開発しちゃうと、新しいサービスとしては機能改善のスピードが遅いですよねということで、最近はちょっとやり方を変えようとしています。

そこの品質担保のところは正直、今、試行錯誤中です。むしろ知見のある方とかいたら、ジョインしていただけるとすごく助かるなというのがポイントの1個ですね。

とはいえ、ソースコードの保守性を高めるとか、そもそも保守性が低いものに機能を追加しようとした時の苦労は、みなさん、「あぁ、わかる、わかる」という状況じゃないかなと思います。現場のエンジニアとしては「やはりある程度きちんと作ったもののほうが、その後の保守も早いので、きちんと作らせてほしいな」みたいな意見が多いんじゃないかなとは思います。

司会者：なるほど。ありがとうございます。

QAエンジニアはどう開発にアプローチしているか？

司会者：品質関連の質問が続いていて、「今、品質の文脈が強いとのことですが、QAエンジニアはどのように開発にアプローチしていますか？」というのは、今のご回答に絡んでいるかなと思いますが、この部分で付け足しとかはありますか？

佐々木：あえて付け足すのであれば、弊社のプロダクトは、今、世に出ているものと新しいサービスという、大きく2つに分かれています。今までに出ているものは、どちらかというとウォーターフォールベースの開発で、各フェーズで関門を設ける。そこに対して計画をきっちり作るみたいなアプローチが強かったんですけれども。

新サービスのほうは、極力リリース頻度を高めるためにも自動化推進していこうみたいな、そっち方向に倒れています。そういう意味だと、どのあたりを自動化していこうかとか、結合の自動化をどうやろうかとか、そういうところにもQAエンジニアに関わってもらって進めている状況となっています。

司会者：なるほど。ありがとうございます。先ほどチャット欄に弥生さんの採用リンクも貼りましたので、ご興味ある方は、ぜひぜひ見ていただければなと思います。

では、こちらで以上となります。佐々木さん、ご発表いただきありがとうございました。

佐々木：ありがとうございました。