カミナシが夏に正式リリースした「カミナシ 従業員」を担当しているプロダクトデザイナーの @ludesign (以後 lu) とソフトウェアエンジニアの 飯間さん(以後 iima) に、デザイナーとエンジニアがどう協業してプロダクトを作っているかというお話を聞かせていただきました。

「カミナシ 従業員」チームの別のメンバーにインタビューした記事もありますのでそちらも合わせてご覧ください。

ーー 本日はよろしくお願いします！ まずはお二人の経歴を簡単に教えてください！

iima：カミナシ歴2年で、今担当しているプロダクトではフロントエンドのエンジニアリングを中心に担当しています。前職などではフロントは少し書くぐらいで、主にバックエンドのエンジニアリングを担当していました。

カミナシは特定領域特化型のエンジニアを当時募集していなかったのでなんでもやれる人として入って、入社試験もフロントエンドを書いたり、入社直後に担当したプロダクトではビジネスロジックをフロントエンドで書いていたのでフロントエンドのタスクが多くその流れのまま今はフロント中心に書いていますね。

lu：私はカミナシ歴3年、台湾出身です。新卒は台湾の会社、次にイギリスの会社で DTP などを担当しグラフィックデザインの仕事をしてきました。中国の会社でウェブマーケなどを担当した後日本に来て求人アプリの運営会社のデザイン、その後 2015 年ごろビズリーチに入って複数の新規事業の UI/UX デザインを担当した後転職しました。

デザインシステムの構築なども担当してきました。

ーー 最近のお二人の働き方はどんな感じですか？

iima：僕は 8 時間きっかりで働いています。10 時〜 19 時ですね。終わったらすぐご飯食べて好きなことをしたいので。(笑)

lu：私もです、基本的な勤務時間は 9:30 〜 18:30 ですね。自分もご飯食べたいし、お腹が空いたら脳が動かない人間なので。(笑)

ご飯食べた後、残ったちょっとした作業を終わらせるために 30 分ぐらい作業することもあります。

ーー 仕事を明日に残さないようにするためですか？

lu：はい、それもありますし、この画像が欲しいみたいなリクエストが PR チームから来た時やっぱり早く対応してあげたいので。

ーー 会議の量や出社頻度などはどうでしょう？

lu：(Google カレンダーを見ながら) 勤務時間のうち 10〜20% ぐらいがミーティングにあてられていそうですね。

iima：僕はミーティングは週10時間ぐらいで、朝会・スクラムイベントの定例ぐらいです。たまに差し込みがあるぐらいで、たとえば直近だと全社横断でやろうとしている UI 改善とかの相談会ですね。少ない方なので助かっています。

出社頻度は月一でオフサイトがあるのでその時ぐらいですね。

lu：自分も月1、2回ですね。

ーー 我々デザイナーチームのオフサイト日が追加である感じですね　笑

lu：ですです。笑

ーー カミナシ従業員チームの仕事は順調ですか？

lu：はい、ただカミナシのアカウント基盤との連携がすごく難しいんですよね〜。

iima：これ難しいですよね。

lu：まだ正式にこの辺りの用語集が決まっていないんですよね。人やいろんな要素の管理をどうすればいいかがまだ決まりきっていないですね。

iima：そうですね。それにログインするために使う連携の部分が難しいんですよね。要は OIDC（OpenID Connect）を扱うので難しかったですね。 @a2 さんがかなり頑張ってくれました。
（前回インタビュー「カミナシが新たに送り出す SaaS「カミナシ 従業員」を手掛ける PM とエンジニア　新規プロダクト作りにおける協働スタイルとは」参照）

プロダクトのサービス開発がありつつ同時開発するこの基盤サービスとの連携を考えないといけないのが苦労しましたね。

lu：そうなんですよね。概念の理解をしつつ、ユーザーにとってスムーズな体験になる仕上げをするのが大変で、コミュニケーションコストがかなりかかりました。まだ考えないといけないことが色々ありますね〜…。

ーー プロジェクトへのアサインはそれぞれどのぐらいの状況からでしたか？

lu：2023 年の春ぐらいの合流でした。諸岡さん、後藤さん、@kakomoeさんらが先に顧客ヒアリングなどをしていて、ベータ版の開発段階でべっちさんも合流してきてくれました。

iima：自分もその後 2023 年 6 月ぐらいでビジネスどうするか、a2さんと同じタイミングで合流ですね。

正直この時期が一番辛かったですね〜…。(笑) 課題がふんわりしていて。実装はなんとかなる感じがしていましたが、アプリケーションに落とし込むにあたっても課題解決のアイデアの具体化が見えてこなかったので辛かった印象があります。

ーー プロジェクトはどういう流れで進行してきましたか？

lu：こういうもの作りたいというのと、現場にはどういう課題があるのかというのをリスト化していきました。

顧客が困っていて、かつビジネス的にマネタイズができそうなものにフォーカスしていった感じです。ヒアリングなどで課題解決のアイデアの費用対効果を検証ですね。

具体的なところだと、チャット、シフト管理などを従業員管理のサービスを利用している場合、現場にはどういう課題があるのかなというのと、私たちのサービスは雇用契約・業務連絡・給与明細など 3 つの機能がベースになっているので、この中で緊急性と費用対効果が高いものは何かというのを検証していました。

iima：業務連絡でもお知らせ機能とチャット機能どちらが実装も早く提供できて、お客さんが十分に利用可能な状態になるか考えました。

チャット機能はアルファ版として提供していましたが、ベータ版では先にお知らせ機能を作りました。チャット機能は明日（インタビュー日の翌日 2024 年 11 月 7 日）リリースですね。

ーー おおすごい！楽しみですね。諸々の仕様やチケット管理は何を使われてましたか？

lu：仕様やチケットなどは Jira を使用していましたが今は Notion を使用していますね。

iima：初期は GitHub Project を使っていましたが、CS がチケットを切ってくれることもあって、Jira を使うようになった気がしますね。その後 Notion がページの同時編集に強いのと、そもそもの機能が強化されてきたことで Notion に落ち着いてますね。

lu：Notion 気に入っています。仕様やプロジェクト内の情報以外とのリレーションが作れたりするのも便利なんですよね。

あとはコミュニケーションツールとして Miro を使っていたりしますね。

iima：メモがわりに be さんを中心に使っていたりしますね。

ーー 探索に使用するプロトタイプの制作や、そこでのフィードバックはどういうものがありましたか？

iima：アルファ版は実装のみでやって、最近は Figma で描いてもらったものを実装という感じでやりましたね。

lu：アルファ版で実装したチャット機能のフィードバックは、最初はバグ報告が中心でしたが、日々使っていただくにあたって、当初提供していた UI がわかりにくいという声が出てきました。そこで現在のトーク型の UI に変更していきました。

お知らせ機能では、 PDF を添付できるようにしてほしい、閲覧状況を確認する機能を強化してほしいといった UI に関するフィードバックに対応する改善を繰り返しました。

VoC (注：Voice of Customer) を CS と連携して活用させていただいています。

iima：それと一時期、今存在しないとある機能を作ったのですが、まだプロトタイプというか実験段階レベルですぐには実現できないのですが、お客様やビジネスチームの期待値を上げ過ぎてしまいました。

期待値調整って難しいんだなとか、チーム間でコミュニケーションをもっとしていかないといけないんだなって学びがありましたね。

ーー 前回の a2 さんにもお聞きしましたが、実装時といえばプロダクトで使用する技術はどう選定しましたか？

iima：自分はこのプロダクトに関わる前フロントエンドはそこまで得意ではなかったし、チームの人数は少なかったので、キャッチアップが薄めでも使えるような技術を重視しました。ビジネス仮説を立てたり困っていることの課題の探索にフォーカスしたかったというのもあります。

具体的には当時は Next.js や Remix などが界隈でも話題で盛り上がってはいましたが、なるべくクライアントサイドレンダリングで伝統的なシステムを選定しました。

この選択は良かったと思っていて、後に入社されたり合流してこられた方も元々バックエンドメインの方だったというのもあり React でも簡単な構成になっているので良かったとお聞きしたことがあります。

ーー デザイナーはどういうツールやワイヤーフレームを利用されましたか？

lu：やっぱり Figma や FigJam 、Notion を使用していますが、Figma Slide も結構いいなと思って使ってみたりしました。

これはチャットのデザインを説明するときに利用しました。プロトタイプを見せたい時に、Figma のプロトタイプがスライドの中に埋め込むことができるのでスムーズにプレゼンができるぞ、というのがありました。

ーー チームでのコミュニケーションはどんなスタイルが多いですか？

lu：開発の初期は全体的な仕様や UI コンポーネントの選定など大局的な議論が必要なので、 Gather で同期的に直接話してすり合わせをします。開発の後期では比較的具体化しているので Slack や Figma で非同期的にコミュニケーションをして細かい部分を擦り合わせていきますね。

最近だと Chips というコンポーネントについての確認のため同期的に会話をしました。

iima：あとはチケットで会話することもありますかね。ちなみにチケットはストーリーレベルだと PM かデザイナーがチケットを切りますが、エンジニアがチケットを切ることもよくあります。

ーー チケットのアサインと実施はどうやってますか？

iima：誰もアサインされていないチケットとかは日中とかであれば、持ってるチケットが完了できたら、次浮いてるチケットを勝手に取っていって、次から次へとやっていく感じですね。

朝会とかでチケットが転がって誰かにやって欲しいものをお願いしたりすることもありますが、API 周りとか。そう、私は最近はフロントエンドのタスクをこなすことが多いので、気づいたらバックエンドが少しわかんなくなってきているかもしれません。(笑)

lu：えぇ、そうなんですか？(笑)

iima：慣れというか…。

ーー 地方出身の方が東京に住んでいたら標準語に慣れて方言がわからなくなるみたいな。

iima：近いかもしれませんね。とはいえもちろんバックエンドも書いてますよ。(笑)

lu：ペアプロとかも結構やられてますよね。

iima：そうですね。必要に応じてやっています。特にフロントエンドを一緒にやろうってやってる感じですね。

lu：フロントエンドは iima さんに相談するって思ってます。iima さんはフロントエンドの神様なんですよ。(笑)

iima：いやいや。(笑)

ーー デザイナーとエンジニアで密に連携されている感じですね。

lu：はい、iima さんはじめ、エンジニアには開発視点だけでなく、ユーザー視点での UX や UI に関する意見もレビューしていただいています。

なぜなら開発メンバーが私よりも高い UX/UI の知見を持っているな〜と感じることがよくあるんですね。

デザインは提案時、複数案を踏まえているのもあり、検証のためによくデザイン変更が行われました。ただ私は実装できないしというところで、少し劣等感というか迷惑をおかけしたくないとか、気にし過ぎかも〜どうかな〜と思っていたんです。

そしたら iima さんから「検証のためにデザインを変更することは全然大丈夫です、良いプロダクトを作りましょう」という言葉をいただいて。とても感動して励まされました。

iima：いえいえ、フロントエンドはユーザーのフィードバックで成り立っているので、変えやすさを意識して実装しています。

デザインも必要あらば変えるべきだと思っているので、そういう発言をした記憶がありますね。

lu：心から感謝です！

ーー チームのコミュニケーションで工夫されていることもありそうですね。

iima：Slack などではレスは早めにつけるようにしていますかね。少なくとも emoji をつけるとか。

放置しないのが大事だなと思っていて、みんな意味があって Slack に投稿していると思うので、反応することは意識していますね。

lu：デイリースクラムとかで雑談とかもよくありますね。意識づけというか。

雑談テーマを設定して雰囲気を柔らかくする工夫をすることもあります。

ーー PM やセールス、CS といった他ロールとのコミュニケーションも多いですか？

iima：そうですね。そういう意味だとエンジニアはオンコール担当みたいなものを決めて、週一でローテーションしています。

オンコール担当は障害対応や監視、チーム内外でのコミュニケーションをエンジニアとして一旦受け取る役みたいな感じです。オンコール担当になった週、エンジニアは Slack を打ち返すのを本業にして、軽いチケットだけやる感じですね。

これはいいアイデアだったと思っていて、コンテキストスイッチで実装が全くできなくなっちゃうので、これをやるようにしたことでチーム全体としてチケットの捌き方が良くなったと思います。

lu：CS とは特に毎週 VoC の確認をするために定例をしています。CS はお客さまと直接話しているので CS 要望は優先度が高いなーと思っています。なので CS が担当するヘルプページに使用する画像とかのリクエストは特にすぐ対応したいと思っているんですよね。

ーー お互いへの要望をお聞きしたいです。エンジニアとして、デザイナー は何がわかっているとエンジニアは仕事がやりやすいと思いますか？またその逆はどうですか？

lu：うーん色々お願いしているので何か言いたいとかはないですかね〜。デザイナーは React ができたらいい？(笑)

iima：いや React はできたらでいいと思います。(笑)

私たちのような SaaS の場合デザイナーはコンポーネント単位でデザインするというアイデアを持っていただくと仕事がしやすいかなーと思います。文言を UI で変えたいときは Figma であればコンポーネントをうまく活用いただければ一発で変えることもできますし。

特に私たちのチームは MUI (※Material Design の React 実装ライブラリ)を使用しているので、その単位を意識して設計していただけるとという感じです。

lu：そうですね。実装側は MUI にないコンポーネント単位を持つこともあるのでそれをデザイナーに共有いただけるのがありがたいですね。あとは不足している箇所とかの指摘をいただけると、とか。

iima：エッジケースとかですかね。これはどういう値を取るかとか。Empty State はどうするかとか。

ーー 将来、これからプロダクトをどう成長させていきたいですか？

lu：毎日使いたくなるプロダクトを提供したいですね。

iima：同じことを思っています。「カミナシ 従業員」は個人の端末を使うことを前提にしています。なので日常遣いで使えるいいアプリにしたいですね。

ちゃんと活用したいと思えるようなプロダクトでないと、ビジネス的にも成長しないですからね。(笑)

ーー 成長に向けた課題はどんなところがありそうでしょうか？

iima：カミナシのプロダクトは他にも色々あるんですが、他のプロダクトも私たちのプロダクトを通して利用できるようにしたいんですよね。

lu：そこはチャレンジですよね。やっぱりユーザーも何個もアプリを使い分けるのは大変ですから。

なのでそのためにはアカウント管理の体験をスムーズに使えるようにしたり、ID の拡張性をどうするとか、この辺りの設計が難しいんですよね〜。く〜。

ーー 最後にこんな方と働いてみたいなというのがありましたら教えてください！

lu：ドメイン知識がある方というか、ドメインへの熱意が高くてかつデザインできる人だといいかもですね。多くのプロダクトデザイナーは現場の知識がない状態から取り組んでいきますが、現場の世界は奥が深いので。ビジネス観点もコミットできる人がいたら最高だと思います！

iima：そうですね、ドメイン知識なくてもいいけど吸収したい人が前提かもですね。使う人のことを考えて、アプリの手触りとかを考えて、設計とか仕様とか考えられる人、ですね。

開発リソース配分を考えると、スコープを狭めて作りやすいものに倒して考えることも多いので、そこに待ったをかけてくれるような人がいるとよりチームの成長が加速していくかもですね。

ーー 本日はありがとうございました！

（写真・インタビュー：カミナシ　プロダクトデザイナー　髙橋伸弥）

・・・

＼\ 一緒に働く仲間を募集中です！ /／

採用サイト👇️