Fixpoint Mind Episode

Episode 02 サービス開発

サービス設計に必要なのは、
ターゲット像を見失わず真のニーズをつかむこと。

プロダクトデベロップメント部(PD部)

プロダクトデベロップメント部は、Kompiraシリーズのサービス設計・開発を担当する部署です。現在は22名が所属しており、サービスの企画、設計から開発に至る全工程に関わりながら、日々奮闘するメンバーの業務をご紹介します。

  • エンジニア

    本田
    製品の企画、設計、開発、リリースを担当する、プレイングマネージャー

  • エンジニア

    ありすえ
    フロントエンド、バックエンド、アプリケーションの設計・開発を幅広く担当

  • エンジニア

    築田
    バックエンドの設計・開発、プロジェクト進行の全般を担当

Our Values

ユーザーに衝撃を
困難でも最善を選択する

顧客のニーズを極限にシンプルにすることで
生まれたのがKompira Pigeon。

―直観的に使えることが顧客に好評なエスカレーション電話自動化サービス「Kompira Pigeon(以下Pigeon)※1」の構想が生まれたきっかけは?
本田:自動で電話連絡するサービスの構想が持ち上がった当時、僕はKompira Enterprise(以下Enterprise)※2を使ったSI案件を担当していました。
そこで関わった案件では、「障害時に電話連絡をする」という要件が共通の要望として多く挙がっていましたし、それまでは都度複雑な開発を行っていたので、単体のサービスとして提供することはニーズがあると思いました。
Enterpriseの共通機能でもいいし、クラウドサービスに落とし込んで提供するのでもいい。 お客様も喜ぶだろうし、SIにも役立つだろうということになって、開発に着手することになりました。
コンセプトや製品名などは、チームメンバー全員で何度も議論しました。
「夜中に電話で起こされる」「すぐに現地対応しないといけない」「24時間気がやすまらない」などの現場の課題をどんな仕組みで解決するか?をディスカッションし、その後の設計は僕が一人で担当しました。

ありすえ:その頃は今よりもずっと少ない人数で開発していて、皆それぞれのタスクがあって手が空いていない状況でした。そこで本田さんが開発者としてJOINすることになったんですよね。
僕はPigeonにはフロントエンドの開発では関わったけど、システムの設計自体は完全に本田さんが一人で組み立てた。それが良かったんだと思います。仕様に関しては、人数が関われば関わるほどぶれてしまうものなので。

本田:Pigeon自体はあまり手広くするよりもミッションクリティカルであることを目指して設計していたので、あまり大きくしたくなかったんです。 出来ることは限られてしまってもいいので、その用途に限っては本当に簡単に使えるように作りました。
障害発生時などに「確実に」連絡するための手段として使うことがコンセプトだったので、もしもそれ以外でも使うなら、もっとこういう機能が欲しいとか、いろいろな要件があったと思います。 それでも設計では、アラート対応のあるべき姿を極限にシンプルにすることを追求しました。

ありすえ:フロントやバックエンドの設計の話をするときでも、本田さんがしっかりシステム設計のコンセプトを持っていたので。色々な人から「こういう仕様にしたほうがいい」という意見があっても、コンセプトがぶれるようなものは本田さんがリジェクトしていましたね。フロントエンドの開発で細かいことを意識することはありませんでしたが、シンプルさとか仕様のコンセプトは常に意識していたのを覚えています。

―顧客から高評価を受けていることへの感想は?


本田:お客様のPigeonへの反応は、素直に嬉しいです。 製品として開発がうまく行ったという事以上に、チームメンバー全員で何度も議論したコンセプトがちゃんとはまって、それがお客様に受け入れられたというのは、すごく良かったと思っています。

コンセプトがユーザーニーズとマッチした
Pigeonとは違い、苦難の連続だったAlertHub。

―次に着手したサービス、「Kompira AlertHub(以下AlertHub)※3」の開発については?
本田:Pigeonは何かのシステムから呼ばれて動作する道具としては非常に優秀ですが、それ単体では全体の末端でしかありません。
ある事象に対して電話連絡をするといった、前段での判断をするような仕組みがクラウド上にあれば、今までEnterpriseでしかできなかったことがクラウド上で完結できるのではないかと考えていました。
会社的にもEntepriseやPigeonなどのサービスを繋げていくという構想があって、その二つが重なった時に、新しいサービスを作ろうかという話が持ち上がっていたんですね。
そうこうするうちに、次の大きな波が僕に押し寄せてきまして(笑)。それが今のAlertHubの開発の始まりでした。
明らかにPigeonよりも大きな開発で、期限も決まっていましたが、僕一人では到底無理な規模だったんです。そこで、ありすえくんと築田くんがJOINしてくれて、三人での共同開発が始まりました。

ありすえ:いやあ、あれは本当にヤバかった(笑)。結構本田さんって抱え込むタイプだけど、どう考えても時間が足りないよねということで。
これ僕と築田くんと本田さん三人フルで導入して、できるかできないかのレベルですよ、という話をして、それでもやらないといけないということで、全員投入になったという経緯です。

築田: 僕はもともと本田さんから細かい設計の相談をされていて、ある程度中身も分かっていたので、よし、じゃあやるか!という感じでJOINしました。
今振り返ると、三人フルでかかってもかなり難しい開発でしたね。

本田:僕は小さいお客様をたくさん受け入れる想定で設計していましたが、ファーストユーザーは想定とは違う大きなお客様でした。
おそらくユーザー像のすり合わせの時点でズレが生じていたのだと思います。そのズレが、そのまま設計に反映されてしまった。
それで当初考えていた思想がそのまま使えなかったりして、そこはかなり苦労しましたね。それが原因で、色々な問題が出たのも事実です。

築田: チーム内で、ユーザー像が共有しきれていなかったのだと思います。
どういう使われ方をするのか?というところが、追求しきれていなかった。なるべく簡単なものを積み重ねていこうと考えていたのですが、その設計が裏目に出てしまったのだと思います。
Pigeonは一人で設計したからこそ最後までコンセプトがずれなかったのだと思いますが、逆に判断する人が増えるとどんどんコンセプトがぶれて行って、最終的にはよく分からなくなってしまうというパターンでした。
そういう難しさは、AlertHubの開発を通して学びましたね。

本田:Pigeonがうまく行ったので、AlertHubも僕の考えた設計でうまく行くだろうと考えていました。それでも考えていたことが実際は違ったり、ユーザーの目線で考えるといくつか見逃してしまったこともありました。
それを解消すべく開発は継続していたのですが、ようやくAlertHubの新機能である「ランブック」をβリリースするところまでこぎつけました。
ランブックで重視したのは二つで、一つは複雑な表現をできる限り簡単に設定できることを目指してフロー図のような設計感をUIで実現すること、もう一つは実行の結果をより親切に分かりやすく表示してあげることです。これは始めからやりたいと思っていたことでもありました。
この開発も期間が限られた中で行ったので、そういう意味では大変でしたが、ようやくユーザーに必要な機能が提供できるところにこぎつけたのは、嬉しく思っています。

信頼し合えるメンバーとの
ドリームプロジェクトのようなわくわく感。

―大変な開発の中で、メンバーで助け合えたことは?
本田:僕は単純に、今まで一人プロジェクトが多かったので、良いエンジニアと一緒に仕事をするという経験があまりありませんでした。
AlertHubの開発にメンバーが三人も入るとなったときには、ドリームチームみたいでわくわくしましたね。このメンバーとできるのは面白そうだと思いました。

築田: AlertHubの開発という部分だけに焦点を絞ると、すごく楽しかったですよ。
すごく気持ちがいいのが、本田さんと僕でバックエンドを分担して担当していたのですが、二人で同じものを作るって、プログラムに限らず難しいものなんですよね。
お互いがお互いのことをちゃんと考えないと、合わせてみたら動かなかったということは良くあります。 でも本田さんとやったときは一発で動くものができたりしたので、「あ、動くんだ」みたいな(笑)

本田:気持ち良かったというか、逆に怖かったよね(笑)。僕はもともと実装だとか設計の能力に関しては、自分より二人の方が上だと考えていて。
ただ僕はプロダクトデザインとか、ユーザとのやり取りというところは二人よりも強いから、そういう役割を担うことが多かったんです。
でも今回は一緒に開発ができて、しかも自分より優秀だと思っているエンジニアをある意味自分の思想に巻き込んで開発できるわけですから、それは面白いですよね。
自分のコンセプトを実現するために、自分よりも優秀なエンジニアが力を貸してくれるという、ドリームプロジェクトでしたね。

築田: 本田さんは開発者としても能力が高いですし、どこをちゃんと詰めれば動くかというカンどころが分かっていて、それが見事にかみ合ったんだと思います。
やれば動くというのがずっと続いていて、開発に関するストレスというのは、そういう意味ではほとんどありませんでした。

ありすえ:難易度的にも高い開発だったから、その分楽しいというのはあったよね。

それぞれが感じるPD部の使命。

―開発の中で、PD部の使命として感じていることは?
ありすえ:僕の仕事は、夢を現実解に落とすことだと思っています。ユーザーが欲しいと思う「夢」をそのままでは現実に落とし込めないので、こういう風に考え直してみて、といって、現実解に落とし込むのが僕の仕事ですね。この辺は本田さんと違って、本田さんはお客様のニーズを叶えるとか、もっと大きい視点だと思うんですよね。僕はむしろ作ってほしいものとか、叶えたい願いがあるのなら、僕に言ってくれればそれを現実解に落とし込みます。現実的にできるようなものを作ることはできますし、クオリティの担保は僕が常に気を付けているところなので、それを作るのがPD部の中での僕の使命かなと思います。

築田: PD部の使命というと難しいですが、設計部分のあら捜しとか、そういう部分でのアーキテクチャ的なクオリティ担保の部分が僕の役割かなと思います。 PD部の中ではコンピュータの根本の方を知っている方だと思っているし、アプリケーションよりも、もっと仕組みの方を比較的知っていると自負しています。実現したいことがあった時に、それがなんかまずそうだな?というところに気づく能力というのは、人よりちょっと高めかなと思っています。

本田:顧客のニーズを満たすというところを、PD部の使命というよりも僕の使命感として持っています。 AlertHubに関しては、そういう面では僕も少し失敗をしていて。 ある意味Pigeonは自分の考えたコンセプトでうまく行ったので、AlertHubも僕の考えたコンセプトでうまく行くだろと当初色々考えていたんですね。それでも考えていたことが間違っていたりとか、実際のユーザーさんの目線でいくと、もう少し深く考える必要があったりだとか。 ある意味見逃してしまったところがいくつかあったと思っています。 なので、次はもう少し謙虚になろうかなと思います。(笑)ユーザーの直接の声を聴くのは、必須だなと思いました。

※1,2,3 Kompiraシリーズのサービス

Job openings
募集要項