データ管理製品やITサービス、および金融や流通業をはじめとする多種多様な業種向けのシステム開発・運用をグローバルに展開する、株式会社セゾン情報システムズ。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

今回は、セゾン情報システムズで「HULFT DataCatalog」の製品開発に携わる、野原さん、原田さん、松岡さんの3名にインタビュー。アジャイル開発に取り組むチームの背景や、開発生産性の計測において「Findy Team+」をどのように活用しているかなどについてお話をうかがいました。

データマネジメント分野の「HULFT DataCatalog」を開発

――まず最初に、皆さんの簡単な経歴を教えてください。

野原：2009年に新卒でセゾン情報システムズに入社し、HULFTチームでエンジニアとして過ごし、その後IoT関連のソフトウェア製品の立ち上げに携わりました。IoTチームでは4年エンジニアとして過ごし、2年くらいはチームリーダーをしていました。2022年からエンジニアリングマネージャーを務めています。

原田：私の前職はSIerで、エンジニアとして開発に携わっていました。2008年に中途でセゾン情報システムズに入社し、15年ほど経ちます。入社後は主にHULFT、DataSpider関連の、新製品の立ち上げから携わる仕事をしてきました。そのなかで、開発エンジニアやプロダクトオーナー、スクラムマスターなど、さまざまなロールを経験して今に至ります。

松岡：私は2011年に中途で入社しています。入社して5年くらいは、HULFTのオープン系の開発をしていました。その後、新製品の企画に携わったり、HULFT, Inc.というアメリカの子会社で新製品の開発をしたりしました。戻ってきてからは、HULFT Squareという製品の開発をして、その後はDataCatalogの製品に携わっています。

――皆さんの所属されている組織やチームについて教えていただけますか？

野原：組織としては、1つの課のなかにDataCatalogチームと、他の製品開発チームが2つほど含まれる構成になっています。私はDataCatalogチームのマネージャーをしていて、松岡と原田が同チームに所属しています。

――DataCatalogチームは今、何名くらいの規模で運営されていますか？

松岡：開発のエンジニアは、私を含めて4名。原田がプロダクトオーナーとして、製品の方向性を決める立ち位置を担っています。

――DataCatalogチームは、いつごろどういった背景で立ち上がったのでしょうか？

原田：チームが立ち上がったのは、2018年の夏です。当時、我々の製品ラインナップから次の一歩を考えたときに、製品個別の価値を打ち出すのではなく、製品全体で叶えられる包括的なデータソリューションを打ち出していこうというコンセプトが出てきました。

そのためには、足りない分野を埋める製品が必要だということになり、その1つが「HULFT DataCatalog」でした。DataCatalogは、データマネジメントの分野の製品なのですが、我々はその分野の製品を持っていなかったので、自社で開発するために開発チームを立ち上げました。

――DataCatalogチームのミッションについて教えてください。

原田：DataCatalogのエンハンスを含めて、バージョンアップをしていくことが1つ。そして、もう1つは製品維持です。お客様からお問い合わせいただいた内容のなかでも、調査が必要なものに対応する作業ですね。この2つの軸がチームのミッションになっています。

――チームで設定されているKPIやOKRはありますか？

原田：KPIは特に設けていません。必要性はとても感じているのですが、現状はお客様の数が少なかったり、測る指標がまとめきれていなかったりして、設定しにくい状況があります。

OKRは、製品開発を始めた当初は掲げていました。いつまでにファーストバージョンをリリースするかとか、そのために必要な機能を作り込むとか、そういったことをOKRで定めて、そこに注力する形でやっていました。ただ、最近は業務が多様化してきているため、なかなか設定できていません。

全社的な移行の流れに先駆けて、アジャイル開発にトライ

――DataCatalogチームでは、アジャイル開発に取り組んでいると伺いました。開発スタイルに関して、どういった背景があるか教えていただけますか？

野原：全社的な背景としては、もともとHULFTは30周年を迎えるような製品で、古くからずっとウォーターフォールで開発をしてきた経緯があります。ですが、最近は少しずつアジャイルに切り替えていこうという流れがあります。

原田：そうしたなか、DataCatalogチームでは最初からアジャイル開発を選びました。新規分野でゼロから作る製品だったので、大きく作って後戻りができなくなると、負担が大きくなってしまいます。自分たちの考える仮説をもとに、お客様の反応を感じながら最小限の単位で製品開発を進めたかったので、アジャイル開発がフィットしていると考えました。

一方で、HULFTのように昔からある製品については、少しでもミスがあったときに既存のお客様への影響がすごく大きいんですね。なので、それを踏まえると、アジャイルよりウォーターフォールのアプローチの方が適している面があります。

――他のチームでは、長らくウォーターフォールでやってきた背景があるなか、アジャイルで体制を構築していくことに難しさはありませんでしたか？

原田：当社の経営層は、アジャイルに関して知識があって、それによって得られるメリットも理解していたんです。なので、体制づくりにあたっての説明などに、それほど苦労することはありませんでした。

――全社的にもアジャイルに移行していく流れがあるとのことですが、そちらについても教えていただけますか？

野原：昔からずっとウォーターフォールで開発しているHULFTでは、数字が3つバージョニングされるのですが、左から順にメジャーバージョン、レベル、リビジョンという考え方になっています。

リビジョンが上がる周期は、バグフィックスなどのリリースで年に2～3回。レベルが上がるのは3年くらいの周期で、エンハンスや機能追加が行われます。そして、メジャーバージョンアップに関しては、10年に1回の大イベントです。

はたして10年前の要望を今実現すべきなのかと考えると、疑問に思う部分もありますし、昨今は技術トレンドの移り変わりも激しいですよね。たしかに既存のお客様が多く、失敗したときのインパクトが大きい面はあるのですが、やはり小さく速くリリースしていくことは、チャレンジしていかなければならない部分だろうと考えています。

ただ、現状としてはメインのHULFTなどは、まだウォーターフォールからシフトできておらず、DataCatalogチームのような規模の小さなチームから、少しずつアジャイルにシフトしていっている状況です。

――少しずつアジャイルにシフトしていくなかで、課題として顕在化しているものはありますか？

野原：製品の数が今すごく増えていて、一つひとつのチームが小さくなっています。DataCatalogチームもそうですが、小規模なチーム内でエンハンスの対応も、お客様からのお問い合わせ対応も、バグフィックスの対応もしていかなければなりません。

プロダクトマネージャーも製品ごとにいるわけではないので、製品の方向性を決めながら開発もしながら維持をしていく、個人商店のようなチームがたくさんあります。そういったなかで教科書通りのスクラムを導入していくのは難しい部分もあり、どうしていくべきかというのが課題になっています。

原田：もう一つ挙げると、経営層はアジャイルの知識を持っているものの、会社全体としてはウォーターフォールをベースにした承認プロセスになっています。なので、そこは避けて通れないというところもありますね。

――DataCatalogチームの承認プロセスも、全社的なものと同様なのでしょうか？

原田：基本的には同じです。製品の性質上、融通が利く部分もありますが、他部署や経営層の理解を得なければならないので、他と比較できるようなフォーマットで提出する必要があります。

実際に上手くいかなかったケースもあって、いくつか前のバージョンでは、企画書をレビューに出してから議論が巻き起こって、通すのに4ヶ月くらいかかりました。その分リリースが遅れていることにはなりますが、リリース前に検討すべき指摘も多くあり、必要な議論を重ねているという意味で、そこをどう捉えるかのバランスは難しいところです。

野原：パッケージ開発の特性でもあると思いますが、βリリースのようなことが結構難しいんですね。一度出してしまうと取り下げるのにすごく労力を使うので、慎重にディスカッションを重ねるため時間を要します。

――アジャイル開発を行っているなかで、どのようなメリットを感じますか？

松岡：ウォーターフォールでは先に進んでしまうと、手戻りが大きくなりますが、アジャイルは小さく進めていくことができます。そこがやはり大きなメリットの1つかなと思います。

野原：アジャイル開発をしているDataCatalogチームは、他のチームに比べて、コミュニケーションの頻度がかなり高いと思います。それがチームの良い雰囲気をつくっているし、アジリティを上げるコミュニケーションにもなっていると感じます。

今はリモートワークになっていて、バーチャルオフィスのGatherを使っているのですが、なかなか浸透しにくかったりするんですよね。でも、DataCatalogチームはそこで常にチームで会話しながら開発を進めていて、すごくチームの雰囲気が良いと思います。

松岡：ウォーターフォールでは、1人でバリバリ開発していることが多かったですが、アジャイルだとコミュニケーションを取りながら、かつペアでやることも多いので、誰かが置いていかれてしまうことが少ないと感じます。

――ペアプロを取り入れていることでメリットを感じる部分はありますか？

松岡：大きなところでは、知識の平準化ですね。あとは、1人で進めていたらレビューが必要になりますが、ペアプロではすでに2人で話し合いながら作っているので、なるべく短く次の作業に進められるというメリットもあります。

原田：ほかにメリットを挙げると、人の入れ替えに強い組織がつくれるところ。ペアでいつも共有していると、引き継ぎ時間がほぼなくなるので、そこも組織としては大きいと思います。

Four Keysを計測するため、「Findy Team+」を導入

――御社では「Findy Team+」を活用いただいていますが、開発生産性の可視化に取り組み始めた経緯を教えてください。

野原：私が昨年マネージャーになってから、どんな組織にしていきたいかをよく聞かれるようになったんです。それに対して、イケてる開発組織を目指したいとは思っていたものの、“イケてる”の定義とは何だろうと、考えたり調べたりしていたなかで、Four Keysというメトリクスに出会ったんです。

開発生産性については、社内的にもこれまで何度か可視化にチャレンジしていたのですが、上手く定着しなかった背景がありました。なので、このメトリクスを使って生産性を可視化し、Four Keysの基準でEliteを自分たちの“イケてる”の定義にしようと思ったのが始まりです。

――過去のトライでは、どういったアプローチが取られてきたのでしょうか？

野原：聞いた話によると、ステップ数や工数で生産性を測ろうとしていた時期があったようです。ですが、それだと冗長なコードを書けば生産性が高いという話になってしまうので、指標としては脆弱です。そういうものではなく、かつ他社とも比較できるような指標がないかという視点で探していました。

――Four Keysを指標に採用しようと思われたのは、どういった理由からでしたか？

野原：過去のトライのように、書いたコード量や工数を指標にすると、簡単にハックできてしまうイメージがあります。しかし、Four Keysには4つの軸があって、1つをハックしようとすると、別の指標が悪くなります。

例えば、レビューもテストもせずにコミットしてマージすれば、リードタイムは速くなりますが、品質の指標が悪くなる。指標同士がお互いに牽制し合っていて、トータルで良くならないとEliteにはならないという考え方が、すごくしっくりくると思いました。

――当初、生産性の可視化をどのように進めていこうと検討されていましたか？

野原：「Findy Team+」を知る前は、スクラッチも考えていました。Googleから生産性が可視化できるオープンソースが出ていたので、それを使ってダッシュボードを作ってみようかなと、個人的には思っていたんです。

でも、これまで社内で独自にシステムをつくったものの、維持やメンテナンスができる人が辞めてしまって、誰も触れなくなっていることが結構あったんですね。なので、将来的なことを考えると大変かもしれないと考えて、サービスを探し始めたところ、「Findy Team+」に出会いました。

――実際に「Findy Team+」を導入いただくまでには、どういった検討がありましたか？

野原：自分としてはFour Keysが見れることが重要だったので、特に検討が必要なことはありませんでした。競合のツールがあれば比較しようと思いましたが、国内にあまり競合はなさそうだったので、一択かなと。あとは、上の人たちを説得するだけという感じでした。

――「Findy Team+」の導入について、社内で理解を得るのが難しかったポイントなどはありましたか？

野原：特になかったですね。経営層にも、もともと生産性を可視化しようとチャレンジしていた人がいたことなどもあり、理解は早かったです。

サイクルタイム分析のすべての項目で、Eliteをキープ

――「Findy Team+」を導入いただいた際、どういったゴールを設定されていましたか？

野原：まずはFour Keysの指標を可視化して、現状を知るところからだったので、DataCatalogチームでの導入からスモールスタートしました。すると、サイクルタイム分析の前半部分にボトルネックがありそうだとわかってきたので、直近はそこの改善をゴールにしていました。

そして、チームでデータを見て改善サイクルをまわす習慣をつけることや、他チームに展開できるナレッジやプラクティスをつくっていくことも目標にしていました。さらに次のステップとしては、部門全体に導入を広げていき、組織全体でパフォーマンスを可視化して、チーム間で比較できたりプラクティスを共有したりと、コラボレーションが広がることをイメージしています。

最終的には、開発チームのパフォーマンスを上げるだけでなく、開発前後のプロセスまで含めて、全体の生産性を上げていくにはどうしたらいいかを考えていけるようにしたいと思っています。

――「Findy Team+」で、目標として置かれている数値などはありますか？

野原：数値ではないのですが、サイクルタイム分析のランクでEliteをキープすることを目指しています。

――現在は「Findy Team+」をどのように活用いただいていますか？

松岡：基本的には週に1回、スクラム開発のスプリントのなかで行うセレモニーで、ファインディレビューという振り返りをしています。そこでは、チーム全員でサイクルタイム分析を見ながら振り返り、ランクがEliteになっていることを確認しています。

加えて、プルリクエストのなかに、いつもより大幅に時間がかかっているようなものがあれば、何か困ったことや大変なことがなかったか、ヒアリングするようにしています。

――実際に御社のサイクルタイム分析を拝見すると、すべての項目がEliteになっていて、リードタイムをかなり意識して取り組まれていることがわかります。

松岡：これを確認することで、どこがボトルネックになっているかもわかるので、チームとしても非常に助かっていますね。

――「Findy Team+」を導入される以前は、振り返りの場ではどのように会話をされていましたか？

松岡：以前は、振り返りの一般的な手法に則って、良かったことや困ったことについて話していました。ただ、そのやり方だと、その人の覚えている範囲でしかないんですよね。数値を見て、大きく時間がかかっている箇所がわかれば、具体的にプルリクエストを見ることもできるので、その方が改善の効果が断然高いと感じています。

それから、チームメンバー全員が上手く発言できるわけではないので、何か困ったことがあったときにフォローしてあげられると、「助けてもらえるんだ」という安心感を持ってもらえます。そういうところも、より良いチームの雰囲気につながると思いますね。

開発生産性可視化のデファクトをつくる

――ここまでにお話いただいた以外にも、生産性の可視化によるベネフィットを感じる部分はありますか？

原田：プロダクトオーナーという立場から見ると、開発チームの生産性が上がることは、製品のリリースのサイクルを考える上でもすごく大切です。なので、スプリントごとに改善を重ねて、それが雰囲気ではなく数字で見て取れるというのは、すごく安心感がありますね。

野原：振り返りをやっていくなかで、計測できていないことの改善をしてみても、その施策が効いたのかどうか、結局よくわからない。雰囲気としては良くなった気がするけど、実際はどうなんだろうとモヤモヤすることがありました。でも、こうして計測して可視化されると、施策を数値的に振り返ることができるのでいいなと感じます。

また、マネージャー目線では、今後新しく入ってくるメンバーのオンボーディングにも、活かせるのではないかという期待があります。ちょうどDataCatalogチームに若いエンジニアのメンバーが異動してきたので、これから開発のアクティビティが出てきたときに、定期的に見ながら1on1などができると良さそうだと思っています。

――そのほかにも、今後のトライとして取り組みたいと考えていることがあれば教えてください。

野原：今はFour Keysのなかでも、リードタイムに着目していて、それ以外の指標はあまり追えていません。なので、リードタイム以外の指標も、しっかり追っていきたいと思っています。ただ、品質の部分にあたる変更障害率やMTTRが、今の開発のアクティビティの運用上データが取りにくく、そこをどう対応していこうかと考えています。

松岡：今はプルリクエストの時間を見ていますが、Jiraの分析もできるようになっていると思うので、そことうまく突き合わせていきたいですね。Jiraのチケットを作成するときに見積もったストーリーポイントが、どれくらい合っているのか。そういったところを、実際にかかった時間と照らし合わせていきたいと思っています。

――今後の展望やアピールポイントがあれば教えてください。

野原：私たちも手探りではありますが、パッケージソフトウェアの開発における生産性可視化のデファクトをつくっていきたい、という気持ちがあります。まだ知見もプラクティスもあまりないなかですが、ファインディさんにいろいろ教えていただきながら、取り組んでいきたいと思っています。 開発生産性可視化・向上のゴールは事業成長にあると思っています。事業に関わるすべての人が生産性を上げることがビジネス (市場占有率や収益性) をドライブすることに直結することを理解することが大切です。 開発組織の生産性向上に留まらず事業全体の生産性向上を目指していきたいです。

また、30年売れ続け、国内では19年連続シェアNo.1のHULFT。 誕生して20年、多くの企業でご利用頂いておりコアなファンが多いDataSpider。 まさに社会インフラと言っても過言ではない、これら歴史あるプロダクトの開発に携われることは他ではない経験になります。 他にも収集、ディスカバリー、クレンジング、変換、格納、分析といったデータマネージメント全般に関わるプロダクト開発を行っています。 国内外の企業のDXを促進していくキーツールにしていくことを目標に日々開発に励んでいます。

――最後に、一緒に働きたいエンジニア像があれば教えてください。

野原：歴史のあるプロダクトでありながら、現代のニーズに沿った開発を進めるために幅広い知識を要します。胆力をもって、根気強く情報を集め、顧客ニーズを実現する方法を具体化していくことが求められます。 プロダクト開発には明確な答えがありません。チームの集合知を持って議論し、方針を決めていきます。自身の意見を臆せず発言し、説明に対しては質問責任を果たし、議論を前進させることを望みます。 そういった自走できるエンジニアの方を常に求めています。 また、ソースコードの美しさや、お客さま目線の品質をそれぞれの立場から追求しています。そういった価値観に共感いただけるエンジニアの方も大歓迎です。

――野原さん、原田さん、松岡さん、ありがとうございました！

※セゾン情報システムズの採用ページでは事業成長を一緒にしていきたいエンジニアを募集しています。 https://home.saison.co.jp/SIS/saiyo/recruit/

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。 https://findy-team.io/service_introduction