【メンバー座談会第1弾】トドケールのプロダクトチームってどんなことをするの？
トドケールでの仕事をリアルにお届けする新企画「メンバー座談会」。第1段はプロダクトチームの3人に登場してもらい、日々のお仕事について語ってもらいました。
トドケールのプロダクトチーム
3人の紹介
山本隼汰さん
1995年生まれ。広島県出身。千葉大学法政経学部を卒業後、研究開発スタートアップに入社。画像や最適化アルゴリズムなどを中心にAI関連の研究開発に従事。レアジョブに転職し、データサイエンティストとして、データ分析・機械学習チームの立ち上げ、AI関連の研究開発を推進、サービスローンチを経験。2021年3月よりトドケールに参画し、プロダクトマネジメントから設計開発、開発組織の設計や採用を担当。翌2022年7月に執行役員CTOに就任。
十河洋介さん
1992年生まれ。兵庫県出身。愛媛大学にて情報工学を専攻し大学院を卒業後、三菱電機に入社。社会インフラシステムの領域でプロジェクト管理などの上流工程業務に従事。ビーズ株式会社に転職し、社内SEとしてバックエンドからフロントエンドまで一気通貫で開発を行う。2022年1月にトドケールに入社し、フロントエンドエンジニアとしてプロダクトの画面デザインや実装を担当。現在は徳島県の海沿いに住みながらフルリモートで参加。
中橋崇行さん
1985年生まれ。兵庫県出身。デザインの専門学校を卒業後、編集プロダクションの会社に入社。法人の会社案内資料や広報物に関する取材・編集・執筆からデザインまでを経験。その後デザイン事務所に転職し、ロゴやウェブサイト製作などWebデザイン全般に関わる。退職後、フリーランスとして活動し、現在は業務委託としてトドケールのデザインを担う。
トドケールとは？
株式会社トドケールは総務メール室のためのスマートな郵便物・配達物管理ツール「トドケール」と一人総務問題を解決する郵便物・配達物管理ミニBPO「クラウドメール室」を提供するスタートアップ企業です。
プロダクトチームの仕事について
ー 本日はインタビューにご参加いただきまして、ありがとうございます！インタビューはトドケールの公式マスコットである「トドケル」が務めさせていただきます！
山本・十河・中橋）ありがとうございます！こちらこそよろしくお願いします！
ー プロダクトチームは、バックエンド、フロントエンド、デザインと開発に必要な人が集まった最小単位のチームだと思いますが、３人は日々どんな仕事をしているのですか？
山本）自分はCTOという一面も持っていますが、ここではバックエンドのエンジニアという立場で話しますね。プロジェクトのディスカバリーフェーズ(※)で決まったユーザー体験を、どのようにシステムで実現するかを決めて実装するという役割です。
十河さんはフロントエンドとしてどう機能と接するかを中心に考えてもらっていますが、自分はその機能を裏側でどう提供するかを考えます。
どうデータを残すべきか、この機能は将来どれくらい使われるか、複数のパターンを考えて、システムを設計し提供していきます。わかりやすい例で言うと、「一度に大量にアクセスが発生したときにどう対処するか」などです。
（※ディスカバリーフェーズ：ユーザーに提供するべき体験を定義し、それを達成するために実行するべき内容を特定して、実行可能なパーツに落とし込むことを目的としたフェーズのこと）
十河）山本さんが一部話してくれましたが、自分はフロントエンドとして、ユーザーに提供したい体験をどういうカタチで提供するかを考え、実装する部分を担っています。トドケールの場合、PCの画面がメインになります。デザイナーの中橋さんとどのようにデザインするかを一緒に決め、そのデザインを実装していく役割です。
中橋）十河さんが話してくれましたが、自分は主にデザイン領域です。例えば、プロジェクトのディスカバリーフェーズでは、議論活性化と意思決定のためにUIをカタチにして持ち込んだり。また、最終的に合意形成したものを実装していく役割です。
業務連携（バックエンド×フロントエンド）
ー 山本さんと十河さんは、普段どのように業務連携していますか？
山本）ディスカバリーで決定しているフェーズでは、十河さんとのやりとりが多いですね。
ユーザーに提供したい体験を決めながらも、今後のシステム保守性も担保しながらどう実装すべきかを十河さんとやりとりします。十河さんから、「こういうデータを画面に出したい」などそういった内容です。
バックエンドの業務において常に考えていることは、「保存するデータが荒れると、ユーザー全体に影響してしまう」というリスクです。それゆえに「これは半永久的に使うものなのか」、それとも「この機能1回だけしか使わないものなのか」を気にします。それによって、コードの書き方が大きく変わります。比喩的に表現すると「今後、上に物積み上げる想定ならちゃんとしたレンガで作らないといけないんだけど、そうでないならこんにゃくを置くだけでも良い」みたいなイメージですね。
ー フロントエンドでは、そのあたりどういった考え方をするのですか？
十河）「半永久的に使うのか、使い捨てなのか」は、フロントエンドにも共通する考え方だと思います。
特に弊社では完全分業はしておらず、ディスカバリーのフェーズではみんなで議論しますし、そのときに「これって将来的に使い続けるのか？」という議論はよくでますね。
あと山本さんとよく会話する内容でいうと、フロントエンド・バックエンドどちらでも実装可能な要件ってあるんですよね。例えば、「データの検索」って、フロントエンド・バックエンドどちらでも可能なんです。バックエンドで検索条件で絞り込んだ結果をフロントエンドに送ることもできるし、逆にバックエンドが全データをフロントエンドに渡してフロントエンドで絞り込むという方法もある。そういうときに、こういう観点でこっちの処理の方がよいのでは？みたいな話があがりますね。今のは極端な例でしたけど、フロントエンドorバックエンドという観点でいうと、そういった類いの話が多いですね。
山本）これって１回の認識合わせで解決するような話でもないんですよね。フロントエンドである十河さんはページの観点を重点的に見ていて、バックエンドである自分はデータ保持の観点を重点的に見ている感じです。
十河）一般的によく取り上げられる話題ですよね。フロントエンドの人間は画面でどう見せるかを気にするけど、バックエンドは（超極端なことを言うと）データを持っていればOKのような。
山本）フロントエンドとしては、ある画面にユーザー情報と荷物情報を表示させたいからそのデータをバックエンドから送ってほしいけど、バックエンドから見るとそのページのためだけにだけに使っているようにも見えちゃったりはするんです。
お互いにやりたいことや言っていることは同じなんですけど、このあたりはプロダクトや開発の思想や価値観の話に近いので、ちゃんとすり合わせて調整するということをしています。
業務連携（フロントエンド×デザイン）
ー 続いて、十河さんと中橋さんの、普段の業務連携について教えてくれませんか？
十河）よくあるケースで言うと、ディスカバリーフェーズでどんな画面を作ろうかとなったときに、中橋さんから検討漏れをフィードバックしてもらうことが多いですね。例えば、荷物を登録する画面を作るとなったときに、登録が失敗したときにはどうする？とか。エラー画面を出すのかなにも画面が出ないとではユーザー体験がまるで違うので。
こういうのって、作っていくなかで気づくことが多いんですよね。なので、中橋さんに相談して、そういった検討漏れがないかを指摘してもらっています。自分はデザインの知識がそんなに豊富というわけではないので、なにか機能を実装しようとなったときに中橋さんに相談すると、よりベターな実装になっていくんです。
中橋）なんかヤな奴に見えてません？笑
十河）そんなことないです！笑
中橋さんって、「こっちのが好み」みたいなフィードバックをしなくって、「こういう原理原則があるのでこっちの方がベター」という言い方をしてくれんですよね。自分が認知していないことをフィードバックしてくれるので助かりますし、とても勉強になってます。
中橋）フロントエンドとデザイナーは近しい部分もありますよね。自分はフロントエンドの知識もある程度あるので、そこも気にしながらデザインを考えたりしています。
ただどうしてもデザイナーはデザイン重視で考えてしまいますし、全くエンジニアの論理と一致しているわけではないので、そこはすり合わせする必要があるという感じです。
十河）フロントエンドとしては開発コストを下げたいという考えはありますね。例えば、中橋さんがあげてくださったデザイン案のなかで、線が一本入っていたとします。その線が一本あるだけで実装方法が変わることもあったりするので、横線にこだわりがないのであればこうすることはできますか？みたいな相談をさせていただきます。
中橋）利害は一致しているけど、制約がそれぞれ違うというイメージですね。
例えば「半永久的に使うのか」という考え方もデザイナーにはあります。デザインシステム(※)を作って共通認識をとったりや、コンポーネント(※)の管理したりなどもあります。
（※デザインシステム：プロダクトを作るうえで共通の方向性やガイドラインのこと。例えばトドケール内では、ボタンの色はオレンジで角丸という規定がある。）
（※コンポーネント：Reactのフレームワークにおいて、アプリケーションを構成するコードブロックのこと。Reactにおいてはコンポーネントを再利用しながらUIを組み上げることで開発が容易になる。）
業務連携（バックエンド×デザイン）
ー 続いて、山本さんと中橋さんの、普段の業務連携について教えてくれませんか？
山本）正直、デリバリーフェーズの段階においてバックエンドのエンジニアとデザイナーが直接やり取りすることはあまりありません。
中橋）そうですね。トドケールではディスカバリーの段階ですべての役割のメンバーが一緒になって議論に参加するので、その議論の中で出てきた画面デザインに対して山本さんがIA（Information Architecture）観点からのフィードバックをくれるくらいですね。
デリバリーフェーズでは基本的にフロントエンドのエンジニアである十河さんが間に入って私と山本さんの話を仲介してくれます。
お互いの強み
ー お互い、どんな人に見えていますか？
山本）十河さん・中橋さんともに、僕ができないことをやってくれているのでとても助かっています。１年半前までは誰もいなかったので、十河さん・中橋さんがやっている領域も担当していました。ただ、領域を広く取りすぎると意思決定が鈍るっているのがあるんですよね。
例えば、デザインを考えているときにふとバックエンドの制約を気にしてデザインしちゃったり。その点中橋さんはこだわってデザインを提案してれます。デザインだけに集中することで、もちろんチーム内の調整は発生しますが、結果的によいアウトプットになっていると思います。
十河さんはインタラクションを考えるのが上手いですよね。フロントエンドのコードもよくなおしてもらっています。その領域は自分は勝てないと思っているので、十河さんに任せているし、頼りにしていますね。
十河）お二人とも、自分が知らない話をしてくれるから面白いです。トドケールに入ってから初めて聞くようなこと、意識するようなことがたくさんあります。中橋さんからはデザインの話、山本さんからはシステム構築の話など。
山本さんは論理思考が強い人だなと思います。自分は感情的なところが強い側面があって、山本さんが論理的に自分にブレーキをかけてくれています。中橋さんは重複しますが、デザインに関するフィードバックで知らないことを教えてくれるのですごいなと思っています。
中橋）山本さんはバックエンドからフロントエンドのことはもちろん、ビジネスのこともよく知っていて、論理的にかつ俯瞰的に物事を見られているなと思います。人生２回目感があります。笑
十河さんはフロントエンドの専門職ではあるんですけど、デザインのことはもちろん趣味のことも、好奇心旺盛で、なんていうか熱い人って感じですね。
プロダクトチームに向いている人
ー ３人が考える、トドケールのプロダクトチームに向いている人ってどんな人ですか？
山本）ロールによって求めるものが異なるんですけど、プロダクトに関する理解があるのが重要だと思います。分からない領域に対して関心を持てるのかは大事だと思います。
よく言われることかもしれませんが、技術はあとから伴うのでマインドセットですね。自分を高める気概と素地があれば、あとは興味思考で周りを巻き込んでいければどこでも活躍できると思います。
十河）マインドセットや興味のお話は完全に同意です。自分の技術がどうこうとかリモートワークだからみたいなのは微妙だと思います。プロダクトに興味がない人がこのフェーズに入ると、思ってたのと違うと感じることが多い気がします。
あとは、個人的には意見を言う人にきてほしいと思います。エンジニアの人って指示待ちの人が多いイメージありますが、頼まれたことだけ実行するという人は合わないと思います。やはりプロダクト全体のことを考えて意見が言える人にきてほしいです。
中橋）バックオフィスのメール室業務という、世の中の大多数の人が関わったことがないであろうプロダクトなので、情報をすべて積極的に取りに行かないと的外れになりやすいんですよね。ドメイン知識だけでなく、それに関連してすべて紐付いています。なので、情報を自分で取りに行くというマインドはマストだと思います。
ー ありがとうございます！自分が合うと思う人はぜひカジュアル面談まで応募してください！本日はどうもありがとうございました！
この記事が気に入ったらサポートをしてみませんか？