ソフトウェアテストを中心に、品質を創造する企業へと進化を遂げてきたベリサーブ。現在はその一環として、状態遷移図等のモデルからテストケースを自動生成するMBT（Model-Based Testing）ツールの開発にも注力されています。
しかし、プロトタイプを積み上げる形で進められてきたツール開発には、次第に拡張性や他ツールとの連携といった課題が浮かび上がり、アーキテクチャの見直しが急務となっていました。社内外の人材不足、複雑化する仕様、そして海外開発拠点との連携の難しさ──そうした壁に直面する中で、ベリサーブが選んだのは、構造化支援に強みを持つLeviiの「伴走支援」でした。
本記事では、実際に行われた伴走支援のプロセスや、構造化ツール「Balus」の活用によってチームや議論にどのような変化が生まれたのかについて、ベリサーブの蛭田さんに詳しくお話を伺いました。
蛭田さん
ベリサーブは、もともと第三者検証会社としてスタートしましたが、今は「品質を創造する企業」として、ソフトウェアテストを中心に品質向上のための多様なサービスを提供しています。プロダクトやサービスそのものの価値を高める支援を行っています。
私は現在、事業開発部のソリューション課に所属しています。昨年までは研究開発部でMBTツールの研究開発に携わっていましたが、そこから事業化を進めるミッションを負い、事業開発部へ異動しました。ソリューション課の役割としては、事業企画課で立案された企画に基づき、プロダクト開発課が作ったプロダクトを現場にデリバリーしていく支援が主なミッションです。特に現在は、MBTの延長線上で、QAに必要なさまざまなツールやソリューションを組み合わせて現場に適用していくことに力を入れています。他にも、ボイスオブカスタマーの分析ツール(TERUS)などを活用し、CXやUXの改善支援も行っています。
蛭田さん
私たちのチームでは、状態遷移モデルからテストケースを自動生成するMBTツールの開発を進めていました。元々は研究開発の延長としてプロトタイプを組み上げる形で作っていたのですが、実際の業務で使えるようにするためには、より柔軟で変更に強いアーキテクチャが必要だと感じるようになりました。
特に、ベトナムでの開発において、新しいテストパターンの対応や変更を加える際に、思った以上に開発工数がかかってしまうことがありました。以前は作れていたテストケースが作れなくなる「デグレード」も発生し、「変更に強いアーキテクチャ」とは言えない状況だと感じていました。当初、綿密な検討をするよりもプロトタイプをブラッシュアップする形で進めてきた背景もあり、振り返ってみると、予想以上にコストや不具合につながっていたのだと思います。
事業化を見据え、今後もどんどん新しい機能が追加されたり、他のツールとの連携が必要になったりすることを考えると、このままプロトタイプを積み上げていくだけでは対応が難しくなるという不安があり、アーキテクチャの見直しが必要だと強く感じていました。
蛭田さん
元々は、ベトナム側でアーキテクチャの構築を主導できる人材を探していたのですが、適任者が見つからなかったんです。日本側にも、ツールの全体像を設計できる人材がいない。どうしたものかと悩んでいたときに、過去にやり取りのあったLeviiさんのことを思い出しました。
Leviiさんとは以前からやり取りがあったこと、また、同様の支援経験があり、MBTについても知識をお持ちだったことから、相談しやすいと感じたのが大きいです。Leviiさんに依頼すれば、何かしらの具体的なアウトプットや、進め方に関するアドバイスが得られるのではないかという期待がありました。私たちとしては、アーキテクチャをしっかりと決定することをLeviiさんとの連携で実現したいと考えていました。
蛭田さん
Leviiさんへの依頼はアーキテクチャの構築でしたが、まずは現状把握から始まりました。私たちベリサーブ側が考えるアーキテクチャとは何か、そしてLeviiさんが考えるアーキテクチャとはどういうものか、という認識合わせを丁寧に行っていただきました。その上で、既存のMBTツールの仕様やソースコードの構造を調査してもらい、現状を把握していただきました。
その後、Leviiさんから改善に向けた具体的な提案があり、ベトナム側と日本側それぞれに対して支援が行われた、という印象です。特に印象に残っているのは、Leviiさんがサンプルコードを作成してくれたことです。これは、なかなか他では見られないアプローチだと感じました。また、ベトナム側の開発体制についても、より良い進め方に関するアドバイスを頂いたことも記憶に残っています。全体を通して、ネガティブな印象はなく、さまざまな面で状況を良くするための提案を頂いていると感じました。
蛭田さん
伴走支援が始まった当初は、チームメンバーも不安を感じていたようですが、Leviiさんと議論を重ねる中で、さまざまな意見が出やすくなったと感じています。特に、私自身の悩みでもあったのですが、いろいろな視点からの発言があると、それが何にどう関係しているのか、話だけでは掴みにくいことがあります。
しかし、LeviiさんがBalusを使いながら、私たちの発言を構造化してまとめてくれることで、議論の焦点が明確になり、チーム内のコミュニケーションが円滑になったと感じています。Balusでは、発言したことが無駄な情報にならず、一旦可視化されるので、意見を言いやすい雰囲気がありました。後から振り返ってみると、このコミュニケーションの円滑化が、当初はあまり考えていなかった大きな効果だったと思います。
蛭田さん
アーキテクチャの見直しは、目標としていた「がっちり決めきる」という点では一部達成できたと考えています。特に、MBTパターン側がどれだけの役割を持つかという点で、モデルから情報を抜き出す部分と、それを組み立てるパターン側の役割を明確に切り分けるという重要な合意ができたことは大きな成果でした。
ただ、当初の想定以上に考慮すべき点が多いことも分かりました。特に、「ビジネス視点」や「ユーザー業務フロー」からの議論も重要だということに気付かされました。最初は単に仕様とソースコードの整理が中心だと考えていたのですが、事業化や企画につなげるためには、これらの視点からの検討も不可欠だと理解しました。想定していなかった部分ではありましたが、最終的にはこれらの視点を取り入れたことで、より良い結果につながったと感じています。
蛭田さん
Balusは、Leviiさんと議論するときに構造化のための道具として使っていました。特に、私やメンバーとの間で考えていることを言語化・可視化していく上で、とても有効でした。
例えば、ふわっとしたアイデアや「なんとなく違和感がある」といった感覚をそのままにせず、Balus上に書き出していくことで、次第に整理されていくんです。「これは前提だったのか」「これは本質的な課題なのか」といった区別が自然と付いてくる。
また、議論の記録としても優れていて、発言した内容がどんどん構造として積み上がっていく。話し合いが流れて終わるのではなく、しっかり「かたち」になって残るんですね。そういう意味で、発言が無駄にならないという安心感もありました。
Balusのおかげで、議論の焦点がブレず、チーム内の認識のズレも減ったと感じています。当初はやや遠慮がちだったメンバーも、Balusを通して発言が整理されていく過程を何度か経験するうちに、自然と発言の量や質にも変化が出てきたように思います。
蛭田さん
個人的には、これからもBalusを使っていきたいと思っています。特に、自分の中でまとまっていないアイデアを整理したいときに有効なんですよね。「何から手をつけていいか分からない」と感じるような局面って、開発でも企画でもよくあると思うんですが、そういうときにBalusに書き出していくと、考えがスッと前に進む感覚があります。
また、一人で使うだけでなく、他の人と一緒にワークするのにも向いています。全員が同じ情報を見ながら、リアルタイムで構造を作っていけるので、認識のズレが減る。発言が整理されていく様子も目に見えて分かるので、ファシリテーションの補助にもなると感じています。
問題点を一点挙げるなら、Balusで作ったボードを他の人に共有する際の見せ方にはまだ工夫が必要かなと思っています。自分が口頭で補足すれば伝わるんですが、ボード単体で共有すると、初見の人にはちょっと分かりづらい場合があるので。その辺りがもっと改善されていくと、さらに活用の幅が広がると思いますね。
蛭田さん
一番感じたのは、外部の視点を入れることの価値ですね。同じチーム内だけで議論していると、どうしても視野が狭くなったり、慣れ合いになってしまったりして、新しいアイデアが出にくくなる。でも、Leviiさんのように第三者として入ってくれる方がいると、自然と「なぜそう考えたのか」「そもそもの目的は何か」といった本質的な問いが出てきて、議論が深まるんです。
Balusのようなツールと、モデリングの知見を持った支援者がいることで、チームが自分たちで答えを導けるようになる。これはすごく大きな変化でした。
もし今、自分たちだけでは行き詰まりを感じているとか、設計や議論に不安があるという方がいれば、思い切ってLeviiさんと組んでみるのは、良い選択肢だと思います。