電子CADシステム開発・販売から設計・製造・実装までをフォローするQuadcept株式会社。 国産クラウド型電子CADのパイオニアとして、その代表である加藤昌宏氏は、顧客の潜在的な課題を言語化し、解決に導く「スーパーCS」として活躍しています。 またその圧倒的な顧客課題のヒアリング、現場経験を活かして製品の要件出しや仕様策定にも関わっています。 開発リーダーの吉村氏は、チーム開発体制のリニューアルとコミュニケーション活性化をミッションに掲げています。
今回は、そんなQuadceptが、いかにしてBalusを導入し、顧客との共創、開発チーム内の連携強化、そして業務効率化を実現してきたのかを伺いました。
加藤さん
Quadcept株式会社で代表をしております加藤です。私たちは 電子CADシステムや電子回路向けのクラウド型PDMの開発・販売をしており、 お客様に提供した後は、設計、製造、実装といったEMS（電子機器受託製造サービス）でフォローさせていただいている会社です。
元々私は、アメリカや韓国の製品を扱っていましたが、 日本のユーザーの要求に応えるには自社で開発するしかないという思いから、 国産のQuadceptを立ち上げました。 電子回路業界の人たちを楽にするという志を持って日々取り組んでいます。
私は電子CADの販売、サポート、基板設計もすべて経験していますが、 現在は代表という立場で、クラウド型電子設計プラットフォームのCS（カスタマーサクセス）を担当しています。
営業として3,000社以上回った経験を活かし、 お客様の課題をある程度理解した上で、 顧客自身が気づいていない潜在課題の言語化にも力を入れています。
吉村さん
開発リーダーの吉村です。私は現在、各製品のマネジメント業務を主に担当しています。弊社には6、7ほどの製品が稼働しており、そのスケジュール調整や開発進行を一通り行っています。 元々CAD開発を担当していたので、今でもエンジニア兼マネージャーという感じで、可能なタイミングで開発も担当しています。
加藤さん
課題があったというよりも、どちらかというとBalusの良さに後から気づいてきた、というのが率直な感想です。 課題を意識するよりも、使うことによって課題が分かってきて、Balusで解決できると認識するに至ったという順番ですね。
特に私に関しては、表現が適切か分かりませんが「感覚人間」なんです。 ビジネス、営業活動、サポート全てにおいて「お客様ファーストで、こうした方がいい」というのを、 これまでは精神論的に伝えてしまうことが多く、言語化するのが苦手でした。
それをBalusで構造化することによって、「なぜ必要であるか」ということを伝えやすくなりました。 これは業務でも、お客様とのコミュニケーションの中でも言えることです。 お客様も自分たちの課題を伝えきれていない、分かっていない、でも潜在的にはある。 そういった課題がBalusを使うことによって可視化されていくんです。
吉村さん
導入のきっかけですが、まず開発チームとして体制をリニューアルしたいタイミングでした。 具体的には、チームと言いつつ各グループがそれぞれ勝手に動くような体制だったので、 これをなんとか立て直し、チームで動く組織に変えていきたいという思いがありました。 そのタイミングでLeviiさんと関わる機会があり、Balusをご紹介いただいたという経緯です。
当初は主に振り返り（KPT）のツールとしてBalusを導入しました。 そこから開発チームメンバー間のコミュニケーション量を増やしていくための主な場として使っていきました。
その後、構造化とそのあたりの勉強を始め、現在では設計ツールとして非常に重要な役割を担っています。 各自が担当する内容や機能追加における要件をまとめたり、要件分析する場所であったり、設計する場所であったりと、 主要なツールになっています。
加藤さん
やはりBalusの優位性は圧倒的な「簡単さ」にあると思います。 コミュニケーションを取りながら構造化していくという点で、非常にやりやすい。 スピードに関してもそうですし、修正も楽です。 終わってから構造化したノードに対して紐付けしたり、グルーピングしたりするのも結構楽なので、 そこが圧倒的に使い勝手の良いところだと感じます。
お客様と話しながらどんどんBalusのビューを作っていって、それをプレゼンテーションにすることもあります。 そうすると、みんなBalusの良さを実感してくれるのですが、 一方で「そこまでできるのは慣れてないと難しいよね」と、 一瞬壁を作られてしまうケースがあるのが、逆に残念な点ですね。
吉村さん
私から見て気に入っているポイントは、機能が必要以上にないところです。 正直、機能が足りないと感じるタイミングもたまにありますが、なくてもやれるんです。 むしろ、機能がありすぎると逆に悩んでしまう。
例えば、Balusは使える色が限られていますよね。 これがもし「好きな色をカスタムできます」となると、色の設定で悩み始めてしまうかもしれない。 あえてそういった制限があるところが、結果的に効率に繋がっているんじゃないかなと感じています。
あとは、同時接続でコラボレーションできる点です。 複数のメンバーと同じ絵を同時に見ながら作業を進められる感覚は、最近では当たり前になってきていますが、 これまでこういったツールをあまり使っていなかった私たちにとっては、最初は衝撃でしたね。
そのため、コミュニケーションツールとしての位置づけとして、私はBalusを非常に気に入っています。 もちろん設計ツールとしても活躍しますが、 それ以上に他社とのコミュニケーションやミーティングの際に非常に有効なツールだと感じています。
加藤さん
基本的に私の場合、弊社のプラットフォームを導入いただく際に、 お客様の課題を確認するところで使っています。 お客様の業務フローの確認も含めて、Balusでヒアリングしながら可視化するのが一番多い業務ですね。
その可視化した課題のポイントに対して、 私たちのツールやサービスがどのように解決できるのかを機能やサポートと紐付けていきます。 そうすることで、お客様も「自分たちの課題をQuadceptがこのように解決してくれるんだ」と理解しやすくなります。
最終的には、それを資料化し、起承転結でプレゼン資料として提供することで、 お客様が社内で上層部に説明する際の準備まで整えて提供することが非常に多いです。 Balusの図を直接貼り付けることもありますね。
吉村さん
ミーティングでは当然使いますが、開発チームのチームビルディングにも活用しています。 開発チームで勉強会などを開く際、ワーク形式で進めるのに非常に役立っています。
例えば、Balus を使って去年の1年間のチームの振り返りをしたり、 ブレインストーミングをしたりしています。 開発チームでは、画像を活用する場面も結構多いですね。
また、面白いBalusの使い方のアイディアをみんなが出してくるんです。 例えば、付箋を何枚も重ねておいて、話す時に裏の付箋をめくるようにパッと出すことで、 次の文字、次の文字と情報を見せていく。 マウスでいかに面白く表現するかという、Balusでのプレゼンテーションのような使い方もしています（笑）。
もっと真面目な話で言うと、開発設計でも使っています。 あるCADの機能開発における設計をまとめた例ですが、 最初にどんな要求があるのかをまとめ、対応方針を決め、社内向けにプレゼンして意見を集めます。
そして、最終的にロードマップとして「こんなスケジュールでこんなことをやっていきます」というのをまとめたり、 メリットデメリットを整理したりと、様々なビューをそれぞれ作成し、一つの場所にまとめています。 これにより、後から見返した時に「なぜこの対応をしたのか」「どういう経緯があって今のこの機能になっているのか」 という経緯が非常に分かりやすくなっています。
そのため、大規模な開発ではほとんどBalusで設計仕様をまとめています。
加藤さん
以前は要件をExcelなどでまとめていましたが、Balusを使うことで、 ユースケースを考える際に、言葉では伝えきれないポイントや、 私自身が当たり前だと思っていることが表現できるようになりました。
「こことこのデータが繋がるべき」「この情報が次にこの作業に繋がっていく」 「この担当者も見れるようにしなくてはいけない」といったことをBalusで表現すると、 抜群に伝わりやすいですね。
同じ絵を見ながら話すことで、前提の認識を合わせられますし、 開発側も「こことこれ、繋がってますか？」「これよく分からないですね」と突っ込みやすくなる。 コミュニケーションが格段にしやすくなった実感があります。
また、Balusの便利な点は、みんなで一緒に構築できるところです。 もし機能的に難しかったり、スピードが遅かったり、使い勝手が悪ければ、誰もやってくれません。
そこの入り口に関しても、利便性や使い勝手の良さはBalusの大きな強みだと思います。 お客様から出てきた言葉をうまく活用できるので、非常に共創しやすいですね。
吉村さん
Excelでこれだけの情報量を伝えようとすると、お互いに大変ですが、 やはり絵として情報が伝わる点でお互いにメリットがあると感じています。 情報を受け取る側としては非常にありがたい状況です。
また、社長のアイデアや情報量が非常に多く、これまで全てを伝えきれていない、 あるいは言えていないだろうと推測していましたが、 Balusで可視化していただくことによって、だいぶクリアになってきました。
どうしても「分かっている前提」や「そこは知らなかった」といったギャップが生じるので、 そういったギャップを確認するためにも、Balusのようなツールで可視化することは重要だと改めて感じています。
あとは、設計をする際のパフォーマンスが良くなり、大きな時間短縮に繋がっています。 設計資料を作る際、エビデンスを残しながら検討を進めていく必要がありますが、 Balusを使うとほぼ同時並行でできるんです。
これまでは、設計を考えて、メモや何かに残し、後で文章やExcelにまとめ直すという作業が必要でしたが、 今は考えつつ資料を作りBalusにまとめ、そしてエビデンスをBalus上に足していくという作業ができるので、 場合によっては半分ぐらいの時間でできていると感じています。
さらに、最近の新しい使い方として、 作成した設計資料をお客様への納品用のPDF仕様書にする際、 BalusのキャプチャからChatGPTで叩き台を作成してみたんです。 この精度が予想以上に高く、納品用の仕様書作成にかかる工数は、 80%削減になりました。2日かかっていた作業が、1時間でできるようになりましたね。
加藤さん
私の場合、資料作成時間でいうと感覚的には半分くらいになっています。 セミナー資料など、構想や構成を作る部分が非常に楽になりました。
提案書を作る際、これまでは「見せ方」も同時に考えなければなりませんでしたが、 Balusではまず「伝えたいポイント」を先に構築し、その後から見せ方を考えるので、 作業時間が圧倒的に短縮できます。
本質的な部分を伝える方が難しいので、 そこをBalusで構築してからデザインなどを考える方が断然早いですね。 PowerPointだと、このページ内にどう収めるか、ストーリーが繋がるかなど、 同時に色々考えなければならないので。
吉村さん
やはり、Balusを使えている人と使えていない人の差というものがあります。 使う気がない人もいるので、このツールをみんなが基本的に使えるような状態にしていくことが重要だと感じています。
そうすることで、今ある思考のギャップやコミュニケーションロスも減っていくのではないかと考えています。 これにより、開発ひいては会社全体の効率化に繋がることを期待しています。
加藤さん
将来的には、開発者の方たちのナレッジをBalusに蓄積し、それを設計データと紐付けていくのは、積極的にやりたいですね。 例えば、設計データの中に開発のナレッジを登録できたとしても、 それがExcelや文字で起こされたものだと、なかなか見られなくなってしまいます。
しかし、Balusで構造化されたものが設計と連携されることで、 設計上で構造化された仕様や要件とのミスマッチが起きている場合に、 AIでアラートを出したり、アドバイスをしたりしてくれるような機能に繋がると非常にありがたいですね。
Balusに情報が全て入っているので、作られたデータのチェックやアドバイス機能に繋がることは、 非常に大きな価値を生むと思います。