株式会社コギト
企画力 × 技術力で
ソーシャルイノベーションしていく

ストーリー
STORY

メンバー数人が集まり
COGITOのプロジェクトの進め方や特長について座談会をしました。
メンバー目線で、COGITOとはどのような会社なのでしょうか。
プロダクト:待ち楽flex

営業と開発のパートナーシップ!
それぞれが役割を果たすことでたどり着いたプロダクト

待ち楽flexの前身である「待ち楽」は元々携帯ショップ向けの発券機として開発され一定の認知度があったが、異業種からのニーズも強く、新たな市場への展開が求められていた。

このような状況の中、現場の意見を多く知る営業の眞川(京都営業)と、開発者でありアイデアマンでもある協力会社の新藤さんとの連携が成功の鍵を握っていた。

開発に際しては、姫野(東京営業)が具体的なイメージを伝え、新藤さんがそのイメージを理解し、適切なアドバイスを提供するスタイルで進められた。このコミュニケーションの密なやり取りにより、待ち楽flexは市場で求められる機能を備えた優れたプロダクトとしてリリースに至った。

待ち楽flex:https://machiraku-flex.cogito.co.jp/
主な開発メンバー
営業本部 京都営業部
眞川 公宏
「待ち楽flex」発案者かつ初期営業責任者。
営業本部 東京営業部
姫野 大輔
眞川から引継ぎ「待ち楽flex」営業責任者へ。3年間ほどメインで顧客・代理店・開発とのやりとりをこなす。
ジェネクス株式会社
新藤 貴也
「待ち楽flex」初期からの開発責任者。入社半年で責任者となり、以降5年以上改修に携わる。

「待ち楽flex」はどのような経緯で開発することになったんでしょうか?

姫野

「待ち楽flex(以下「フレックス」)」は、発券機の競合企業と協業しているところが面白いところですよね。
開発は眞川さん起案で進めていましたが、当時どんなやりとりがあったんですか?

眞川

実はその話がある以前に構想は私の中であったんです。
当時、「待ち楽」は携帯ショップ向け発券機としては一定の認知があったのですが、それゆえに機能が携帯ショップ向けに偏ってしまっていました。
問い合わせは飲食店やクリニックなど、色んな業種からいただいているのに、機能が合わずに売れない、という悩ましい状況で…。
何かをきっかけにして、そういった市場に向けた発券機を作りたいと思っていたところ、携帯ショップ関連で協業企業と出会ったんです。
先方の担当者と話し合った結果、お互いの強み・弱みを補い合い、かつ相乗効果で市場を伸ばすことができるだろうということで協業するに至りました。

開発に際してこだわったことはありますか?

眞川

開発というかプロジェクト進行の話になりますが、初期にある程度売上が見込めるような販売パートナーを作ることと、定期バージョンアップをすることは自分の中で絶対条件でした。
当時は社内で定期バージョンアップをするという体制が整っていなかったので、開発責任者に色々と交渉した記憶があります。
仕様に関しては、当初のターゲットであるクリニック以外にも、様々な業種にあわせて使えるようになっていきたいという想いがありました。
開発メンバーにイメージを伝えるために、全操作画面のイメージをPowerPointで50枚くらい作ったのは少し大変だったかもしれません(笑)。

新藤

そのイメージを見せてもらった初回の打ち合わせが、私と眞川さんの「はじめまして」のタイミングだったんですよね。なにしろ入社半年でしたから。笑

姫野

新藤さんはそこからずっとフレックスの担当ですよね。
営業担当は途中で眞川さんから私に代わって、そこからかれこれ3年ほどプロジェクトを進めていますね。

定期的にバージョンアップされているということですが、どのように進めておられるのでしょう?

姫野

基本的にはお客様の要望を私やパートナー先の担当がリストアップして、新藤さんと私が中心になって仕様をまとめる形です。
共同開発とはいえ、コギトのプロダクトですので、「コギトとして実現したいこと」と「要望」をどのようにすり合わせるのか、という見極めが結構大変ですね。
あくまで「要望」=「現場担当の意見」なので、客観的に見ると「その現場以外は不要な機能」もあるんです。
ですので、コギトとして売り上げや市場を増やすには何が必要なのか、そして機能追加をするとどのような可能性があるのか、を新藤さんと常に話し合っています。

新藤

当初はクリニックがメインでしたが、徐々に官公庁の案件が増えていて、そういった役所系は「ならでは」の要望があるんですよね。
それに対応する際も、姫野さんと要望を全て洗い出して優先順位をつけて…と、必要機能の整理にかなり時間をかけました。

開発で大変なところは?

新藤

なにしろ要望や意見が山ほどあるので、それがいつも大変ですね…。
言われ続けるとだんだん「みんな好き勝手言って!」と思ってしまうこともあります(笑)。
そういった要望の管理というか、「いつまでに何をするのか?」という優先順位決めや、「これをしたらどうなる?」という見極めがフレックスの開発に関しては大事だと思います。

姫野

新藤さんのすごいところは、仕様を決めるにあたって意見をくれるところ。
基本的に開発って、要件定義書を書いて、開発者がその通りに開発をすると思うんですが、そうすると、要件定義書を書く人がどれだけ知識があって、色々なことを想定しているか?にシステムの出来が左右されますよね。
新藤さんは「要件定義書通り」の人ではなく、「こうしたい」「ああしたい」と営業が要望を出した時に、コンシューマの立場に立ち、かつシステムを理解している人だからこその意見を出してくれるんです。
そこが何より有難い。
また、「現時点で要望にバッチリ沿ってはいないが、将来的にこうなるから今この仕様にすべき」みたいな、先読みもしてくれて。
結果その仕様が受け入れられてユーザー数が増えているので、パートナー企業からもびっくりされています。

新藤

前職は「仕様書通りに作って終了」という開発スタイルで働いていたんですが、もっとプロダクトに関わりたい!と思って出会ったのがコギトなんです。
もちろん色々考えすぎて頭が破裂しそう!面倒くさい!と思うことはありますが、やるならとことん関わりたいので。
仕様決めに関しては、開発は「営業が言葉で言うことをまとめる役割」だと思っているので、姫野さんから要件定義書ではなくイメージを伝えてもらって、コミュニケーションをとりながらプロトタイプを作る、というスタイルで進めています。
普段から細かくやりとりをしているので、色などの微調整があるくらいでいつもスムーズに仕様は決定しています。

営業・開発間のコミュニケーションで気を付けていることは?

姫野

意識していることは、どんな案件があったか?などを都度フィードバックすることです。
開発者は「自分が開発したものがその先どうなっているのか」を自分の目で確認することはできないので、どういう所で受け入れられているのかをきちんと伝えることが営業の役割だと思っています。
新藤さんが開発してくれて、素晴らしいプロダクトになっているので、感謝の気持ちも込めて。
開発と営業は両輪で、営業がいないと世に出ないし、開発がいないと要望に応えられない。
やりとりを密にすることで、考えを共有でき、結果的に開発もスムーズに進んでいると思います。

新藤

前職でもリリース後にフィードバックはなかったので、やはり自分の開発したものがどうなっているのかを知ることはモチベーションになっています。
あと、姫野さんのフレックス愛がすごくて、それもモチベーションになっているかもしれません(笑)。

姫野

本当にフレックス大好きなんですよ!
前職含めて色んな商材を扱ってきましたが、こんなに愛しているプロダクトはないと断言できます。
だから、いろんなお客様にも使ってもらいたい!良いプロダクトですよ!と自信を持って言えます。
これ以上良いものはない!と本気で思っているので、お客様のところでデモをしたらほぼ発注をいただきますね。愛が溢れているからだと思います(笑)。
「商材愛」って言いますが、その商材に関わっている意識が強ければ強いほど、商材愛が芽生えるんだと思うんですよ。
その点やはり新藤さんとずっと一緒にやってきた絆もあるので、それだけ愛が深いんだと思います。

新藤

距離感って大事ですよね。
開発者って、「組織の一部として働きたいタイプ」と、「クリエイティブな仕事をしたいタイプ」がいると思うんですが、私は後者なんです。
コギトは小さい会社だからこそ開発と営業現場の距離が近く、かつ開発したものが世に出るまで見守ることができるので、とても良い環境だと感じています。

フレックスの今後について教えてください

姫野

2つ方向性がありまして、1つはフレックス単体での機能の高次化。もう1つは、他サービスとの連携による機能の高次化です。
1つ目の「単体での機能高次化」に関しては、現在タブレット端末であるフレックスの本体をAIロボットにすることを検討しています。
AIロボットにすることで、フレックスで受け付けボタンを押す一瞬のタイミングで顔認証や体温/心拍計測ができたり、施設案内などの会話をすることができます。
リピーターを増やしたい飲食店や調剤薬局などでこのフレックスを使うと、待ち順管理に加えて体温測定をしてくれるだけでなく、「新規の人」と「いつもの人」の判別をして対応を変えることができるので、人的コストを削減するだけでなく、サービスの価値向上にもつながります。
2つ目の「連携による機能高次化」については、フレックスをクラウド化することによって、オーダーシステムなど関連サービスとの連携を図るというものです。
対象としては飲食店などをまず検討していますが、「1つのシステムで管理する」という利便性アップだけでなく、データ連携による店舗やサービス状況の分析なども可能になるので、より付加価値を高めることができるのではと考えています。