リンカーズ株式会社

エンジニアとビジネス側の密なコミュニケーションで「三方よし」のサービスを提供

今回は、リンカーズ株式会社のビジネスマッチングサービス「LFB」について、マッチングプラットフォーム 事業本部 カスタマーサポートチーム マネージャー 中村 明朗氏と 同じくカスタマーサポートチームの 石田 聡史氏にお話を伺った。

既存サービスを発展させたLFB

リンカーズは2011年に創業し、設立当時よりBtoBのビジネスマッチングを事業として行っている。
リンカーズが提供しているサービスは、この事業で得たノウハウをもとに展開されている。

LFBはこれまでリンカーズが提供してきたサービス、「Linkers Sourcing」と「Linkers Marketing」を発展させたサービスであるため、まずはこの２つについて紹介したい。

最初に提供したのがLinkers Sourcingである。
企業が求めている、事業に必要な技術について、技術を持っている企業を繋いだり、その技術を共同開発する企業の探索を行う。

企業は自社のネットワークを使って、求める技術を持っている企業を探すが、見つからないことはよくある。
例えば、展示会に行って該当しそうなブースで話を聞いてみるという方法もあるが、時間もコストもかかるし見つかるとも限らない。
リンカーズソーシングに依頼すれば、リンカーズの持つネットワークの中から該当する企業を探して紹介してくれる。
こちらはニーズ起点のパートナー探索サービスとなる。

一方、Linkers Marketingは、企業の開発した新しい技術や素材を求めている企業を探索するサービスである。
こちらも同様に、自社で採用企業を探すのは大変だ。
想定もしていなかった所で使われてヒット商品になったり、長年の課題解決に繋がったりもする。
リンカーズマーケティングでは、リンカーズの持つネットワークの中から該当する企業を探して紹介してくれる。
こちらはシーズ起点のパートナー探索サービスとなる。

ここでお気づきの方も多いだろう、リンカーズでは、ニーズとシーズの両方の企業探索における運用ノウハウを持っている。
この強みを活かして作ったサービスがLFBである。

「ニーズ起点とシーズ起点、それぞれのビジネスマッチングを運営する中で、日々リンカーズ自身がパートナー探索を行っています。
そのために自社用に作っていたシステムを、ビジネスマッチングを運営している他社でも使っていただけるのでは？という発想からLFBを開発しました。」（中村氏）

LFB

LFBは最初に地方の金融機関に導入された。
地方金融機関は地域の企業と繋がりがあり、地元企業に対してビジネスマッチングを行っている。
このビジネスマッチングを効率的に行いたいというニーズにLFBのサービスがマッチした。

とはいえ、一企業としてビジネスマッチングを行っていたリンカーズと金融機関では、同じ事業といっても業務フローは異なる。
金融機関も各行それぞれ業務フローは違う。
自社内でのみ使われていたシステムをどの導入先も満足度を得られるサービスにするには、どんなところで苦労したのだろうか。

「確かに社内で使うことを前提にしたシステムから、お客様へ提供するシステムへのステップアップは難しいところでした。
初期のお客様は各地の金融機関様だったため、文化に合わせた機能が新たに必要でした。
情報管理をはじめ、いろいろ厳重な仕組みを取っているところもある業界なので、そこに合わせて新たに検討しなければならない事項は無数にあります。

カスタマイズ性がないと、ある機関にとっては便利でも、別の機関にとっては邪魔になってしまう機能が出てきてしまいますし、だからといってカスタマイズ性ばかり上がっていくと、設定項目が細かすぎて使いこなすのが難しくなってしまいます。
そこの取捨選択やバランスの取り方について、事業部全体で議論を重ね、最善の形を模索し続けています。」（中村氏）

三方よしのサービスを目指す

導入先の銀行だけでなく、サービスを使ってマッチングを実現する顧客の満足度も意識しているそうだ。

「リンカーズでは、サービスを発展させる「三方良し」という考え方を合言葉としています。
第1に、我々がサービスを提供する導入機関の方々にしっかり価値を見出していただけること、
第2に、その先のマッチングで繋がる方々にも、このプラットフォームに関わって新たなビジネスが生まれたり、課題が解決することで、幸せになってもらわないといけません。
そして、我々もLFBというサービスを提供し続け、向上し続けるために良い状況を保たねばなりません。
あくまでサービスをご利用いただく皆様の顧客満足を起点としながら、このサービスに関わる全てのステークホルダーの長期的な繁栄を実現し、ビジネスマッチングを通じて業界を変えるプラットフォーマーとなる事を目指しています。
元々ビジネスマッチングそのものが、登場人物が多く全員が満足するサービスとして成立させることは大変なチャレンジだと考えています。
導入機関の皆様に使いやすいシステムとは何か日々議論しています。」（中村氏）

自社システム開発時から使っていたRuby

リンカーズでは、当初はこれらのサービスはIT化されていなかった。
社内での業務効率化を図るためにシステム化した際に、Rubyを採用した。
その後、Linkers Sourcing、Linkers Marketingとして社外に提供するサービスにした際にも、そのままRuby利用し続けている。

「LFBがRubyを採用した経緯は?と言われると、もともと社内システムをRubyで作っていたからというのが一番大きい理由になります。」（中村氏）

Rubyを採用しただけにとどまらず、まつもとゆきひろさんに技術顧問を依頼したのだそうだ。

「弊社はまつもとさんに顧問になっていただいておりますので、わからないことがあっても聞ける環境です。
今回の機会にエンジニアチームとも改めて話しましたが、設計意図や、なぜこういう仕組みなんだろうといった深い部分まで日本語ですぐに聞けるということが、エンジニアにとってのスキルアップに繋がる環境かつ弊社の魅力となっています。
(Rubyを)作った方が技術顧問にいるとのは最高の環境だと思います。」（中村氏）

Rubyを採用してよかったと思えるところはどこか伺ってみた。

「RubyKaigiには、毎年弊社のエンジニアが参加させていただいています。
成熟したコミュニティやイベントの恩恵が受けられるところが、Rubyを採用しているメリットとして感じています。
弊社ではエンジニアチームが毎月勉強会を開催しています。
この勉強会はX(旧：Twitter)でも告知しており、社外の方も参加可能です。
初心者から経験者まで、様々な年齢層の、様々な経験を持ったRubyエンジニアの交流が生まれています。
エンジニアの採用の際も、国際的に優秀な方が集まり加入後すぐにチームにフィットしていますので、素晴らしいなと思います」（中村氏）

ビジネス側からみたエンジニアとの意思疎通

今回お話を伺ったのは、エンジニアではなくビジネス側の方だ。
中村氏はエンジニア経験がないが、石田氏は元エンジニアだそうだ。
そこでビジネス側の方から見たエンジニアとのコミュニケーションについて話を伺ってみた。

ビジネス側で様々な要素を考慮して考えた仕様をエンジニア側に伝えると、必ずしも良い返事が返ってくるとは限らない。
伝えた仕様に対してエンジニアから難色を示された時、どのように対処しているのだろうか。

「これを作りたいだけだと、どうしてそれを作るのかとか、それを作って結局何がしたいのかというところが共通認識として育ちません。
解決したい課題をしっかりエンジニアに伝えることを意識しています。
まずは課題とか、お客様の要望があって実現したいことを、ざっくりとしたプランの段階で『こういう開発を依頼できないかって考えているんですけど』と、一回見てもらうというアクションを挟むようにしています。
そこで、いろいろな温度感の答えが返ってきます。
良いんじゃないですかっていう時もあれば、分かるんだけどこういう事情で作るのがすごい難しいですという反応も当然あります。
どういった内容でも、多角的な検討による一歩前進ですから、それを受けてビジネス側としてどのような内容にまとめるか再度検討できます。
そうして双方の意見が行き来をするような形で、最終的な案をまとめていくプロセスを今は取っています。」（中村氏）

サービス仕様を考えている段階で、フランクにエンジニア側にも意見を聞いてみることによって、実装不可能な仕様になったり、無駄に工数がかかったりということが起きないようにしているようだ。

「こちらから提案することは、その課題を解決するアイディアの一つでしかないと思っていて、例えば技術的に難しいとか、他の機能との整合性の部分で難しいとか、いろんな理由があって、その最初のアイディアでは解決できないことはあります。
そうなんだ、知らなかった、じゃあどうしようっていうことを、キャッチボールしながら相互理解と知識の共有を深めていきたいと考えています。

ビジネス側が一番気をつけなければならないのは、エンジニアの皆さんに作っていただいたものがちゃんと価値あるものとして ユーザーのもとに届いている状況を維持することだと思います。
作ったものの価値がおざなりにされてるって、作り手として一番嫌なことですよね。
ビジネス側でも議論を尽くして、本当に必要なものを開発チームに依頼するということを守らないといけないと思っています。

エンジニアは、サービス設計だけでなく、実際に提供されているシステムの内側まで関わっている点で、ビジネス側よりもサービス理解が深い面があります。
作るものについて、本当に本質的に捉えられるっていう意味では、エンジニアの方ってそれができるから羨ましいなと、私のような立場では逆に思います。
基本的には、サービスに詳しければ詳しいほど正しい判断が出来ると思いますので、エンジニアの方にもどんどん発信していただいたらいいものが作れるんじゃないかなと思います。
少なくとも弊社ではウェルカムです。」（中村氏）

ビジネス側に理解してもらうには

リンカーズではエンジニア側とビジネス側のコミュニケーションはうまくいっているようだが、ビジネス側にわかってもらえないという悩みを抱えているエンジニアの方も多いのではないだろうか。
そこでビジネス側に理解してもらえなくて困っているエンジニアに対して、ビジネス側からのアドバイスをもらえないかお願いしてみた。

「日頃からの関係性の構築というか、お互いのマインドが揃っているっていうことが組織としては大事だと考えています。
いやーそれはちょっとっていう、その反応になった理由が整理されて伝われば、なるほどそこが難しいんだなっていう、ハードルを我々も正しく認識できます。」（中村氏）

「私の場合は、（エンジニア時代には）専門用語はなるべく使わず、簡単な用語で説明できるように心がけていました。

『説明するための前提を説明するみたいな感じで、こういうシステムが世の中にはあって、これはこういうもので、こういうことができます。
提案いただいた内容はそのシステムを使っているから、こういう理由でできますよ』
みたいな感じで。

用語の前提や、使っている技術の概要を大まかに説明をして、そこから理由付けしていく感じです。
Slackでやりとりをする時も、メッセージを送る前に、一度書いたものを自分で添削して、これなら伝わるだろうと確認してから送っていました。」（石田氏）

「エンジニアとビジネス側の関係性が構築できていなく、ビジネス側が技術的なことに詳しくない状態で一番不幸なのは、『現状できないから断られたのではなく、面倒だから断られた』とビジネス側の人が受け取ってしまう場合があることです。
このすれ違いは、普段のコミュニケーションの中での言葉のチョイスや振る舞いが影響するもので、（すれ違いを発生させないためには）お互いに気をつけて、相手をリスペクトすることが日頃からできているかだと思います。
日頃の行いは、組織がどれくらい強いかということに直結すると思うので、これからも大切にしていきたいです。」（石田氏）

石田氏の話を聞きながら、中村氏がまとめてくれた。

「そういう意味では、ビジネス側も頑張って技術的なことの知識をつけていく努力をしなきゃいけないでしょうし、
エンジニアは逆にその売り物としてのサービスだったりとか、日々顧客と接点を持っている人たちが、どんなコミュニケーションをしているかというところを、双方がキャッチアップしていくことが大切なのだと思います。
相互理解を深めて目線を合わせ、双方向の日々のコミュニケーションを誠実に積み重ねていきたいですね。」（中村氏）

今後について

「既に導入いただいている機関様がたくさんいらっしゃいますので、まずはこの方々へより良い価値を提供できるよう、LFBをブラッシュアップしていきたいと考えています。
日本中の企業を繋いで、日本中の企業のお困りごとをプラットフォーム上で解決していき、生産性を最大化したいというのが最終的な夢です。
その一つとして、導入機関の皆様がプラットフォーマーとなり運営していらっしゃるLFBを横断的に繋ぐことで、その地域の中だけでは発生しなかったマッチングを発生させていきたいというような構想を持っています。」（中村氏）

※本事例に記載の内容は取材日時点（2023年9月）のものであり、現在変更されている可能性があります。