エンジニアにとって“役割を越えること”は難しいのか？　興味関心を熱量にする人が多いからこそ大切な「プロダクトへの興味」

瀬戸氏の自己紹介

瀬戸康大氏：株式会社ビットキーの瀬戸康大と申します。先ほど弊社の三竹（三竹弘司氏）に信じて任されたので、「エンジニアから見ると、そもそも越境って難しくない？」という話をできればと思います。

（スライドを示して）アジェンダはこのようなかたちとなっています。

まずは簡単な自己紹介からさせてください。前職はエンジニアというよりは、製品のモックアップの実装やコンセプト設計の担当をしていました。

弊社から開発として入っていて、先ほど三竹が紹介した「workhub」の前身にもなった「bitlock MANAGER」というプロダクト開発や、最近ではworkhubの開発チームのマネージャーを担当しています。我々のチームでは、主に管理機能をメインで開発しています。

プロダクト紹介です。こちらも三竹が紹介したので簡単に紹介します。、workhubでは、オフィスやコワーキングスペースなど、「働く」をテーマにプロダクト開発を行っています。

人や物、空間やアクセスコントロールを管理して、人が働く上で簡単に入退室の管理ができるようになったり、コワーキングスペースを運用する上での必要な契約の管理であったり、請求の管理を行うことができる機能の開発などを行っています。

余談になるのですが、弊社では自社のプロダクトを自社オフィスに導入しているので、自分たちの開発がオフィスの利便性を向上させるのに直接つながる点がおもしろいところかなと思っています。

越境をしていろいろ並行してやるよりも、役割が決まっているほうが楽

では、本題に入っていきたいと思います。越境というテーマを聞いた時、みなさまはどう思いましたか？　私個人としては、「越境ってなんか難しいよな」と思いました。

（スライドを示して）イメージはこんな感じです。例えば「越境ってほかのチームのことも責任を持ってやる必要があるのかな？」とか「デザインとか考えるべき」とか「考えたことないな」とか「そもそも興味ないな」とかってなる人もいるのではないでしょうか？　

（スライドを示して）これ、私はすごく共感できるんですが、エンジニアのみなさん、いかがでしょうか？　「もっとコードを書く時間が欲しい」と思う方もいるのではないでしょうか？　

ちなみに私はそうです。いろいろなことを並行してやるよりも、コードを書くのに集中したほうが楽だなと思います。コードを書きながらほかのことをやったりすると、集中が途切れたりしてけっこう大変だなと思っています。

いろいろなことに並行して注力するのが非常に苦手な性質なので、役割が決まっていると楽だなと私自身は思います。

なので私は、役割が非常に大好きです。

役割があるからこそ安心して働くことができる

話せば話すほど越境の話からズレてきてはいるのですが、最初に役割の話をさせてください。

役割がない状態で働くということを、私はこう考えています。役割がない場合だったら、「あれもこれもやっといて」とか「これなんでできてないの？」とか「これなんで勝手にやったの？」とか「これ誰に許可取ったの？」とか「これ責任取れるの？」という恐怖が常につきまとうと思っています。

役割がある場合は、例えば「これはAさんがやるから大丈夫」「これはBチームがやるから大丈夫」「これは私自身が責任取ってできるね」とか「これは私に許可を取ったら自由にやっていいよ」という話ができると思っています。私は役割がある状態で働くことで、非常に安心して働けると思っています。

このように、役割は非常にわかりやすいと思っています。ひるがえって、先ほどの越境に足りないのは、わかりやすさではないのかなと私は思っています。

でも役割を決めるだけではうまくいかない

では、越境の話に戻ります。先ほどの三竹の話でもあったとおり、役割を決めるだけだとうまくいかないケースが多々あります。

例えば、そもそも役割が十分に細かく決まりきっておらず、落ちる部分が発生したり、滞りなく役割を遂行するために必要なリソースがそもそも足りないなどが、問題が発生する原因になるかなと思っています。リリース担当などがいなければプロダクトはリリースできないし、いろいろあります。

なので、役割を決めてもうまくいかないケースは多々あるのかなと思ってはいます。例えば、「デザインは専門外だから、デザインチームが作ったやつをそのまま実装した」とか、「私自身としては必要ない機能だと思うけど、なんか偉い人が必要って言ったからそのまま実装してみた」とか、ほかにもいろいろあるかなと思っています。なんとなく心当たりがある方はいますでしょうか？　私はあります。

こういうことを続けていくと、使いにくいプロダクトになっていくというのは、想像に難くないかなと思います。

なので、なんとなく「役割が大好き」と言っているだけでは問題が発生することはわかったので、「開発の役割ってそもそも何だっけ？」と再度考えてみます。

越境は開発の役割だけれど、責任を持って考えるのは難しい

（スライドを示して）先ほど三竹の資料にもありましたが、こちらは弊社、株式会社ビットキーのミッションです。「テクノロジーの力であらゆるものを安全で便利で気持ちよく『つなげる』」。私はわりと好きです。

これはビットキー流の話ですが、開発のミッション、役割は、会社のミッションを最終的に達成できるようなプロダクトを作ることだと思っています。「ミッションを達成するためには、プロダクトを使ってもらわないと意味がない」と思っています。なので、使ってもらうプロダクトを作ることが開発の役割だと考えています。

使ってもらうプロダクトを作るためには、デザインやカスタマーサクセスで、プロダクトマネージャー、プロジェクトマネージャーとか、ほかの分野に無責任ではいられないと思っています。なので、そもそも越境（自体）は開発の役割なのかなと思っています。

とはいえ、越境が必要だからといって、「デザインが本当に使いやすいかな」とか、「ユースケース、これで全部達成できているか？」とか、そういうのをすべて考えながら開発することは、少なくとも私には非常に難しいなと思っています。専門家でもないし、開発する上で締め切りなどに常に追われているし、その状態で責任を持って考えるのは難しいなと思っています。

越境を達成するためには、シンプルにするのが良い

というわけで、次のアジェンダにいかせてください。先ほども言ったように、私はデザイナーでもないし、きちんとしたプロダクトマネージャー経験があるわけでもないので、越境して全部に責任を持てと言われても、非常に難しいなと思っています。

そもそも、得意でない領域で責任を取るのは、非常に難しいと思っています。決めるのも怖いです。ただ、質問したり自分の考えを話したりすること自体はできるかなと思っています。

例えばこんな感じです。「今後1年間でどんなプロダクトにしようとしているかを聞いてみる」とか、「デザインどおり実装してみて、なんとなく気になったところがあったらデザインチームに話してみる」とか、例えば開発と保守チームが分かれていたら「自分の作った機能にどのくらい問い合わせが来ているか」を聞いてみるとか、そういうことであればできるかなと思っています。

また、先ほども言ったように、よくわからないことを決めるのは難しいので、決める人は専門家に任せたいなと思っています。決める人が決まっていれば混乱しないし、役割としても非常に明確です。

また、その上で意見を言うこと自体は絶対に無駄ではなくて、1人で全部考えるより多数の意見は常に決定の参考になるという前提であれば、意見も言いやすいかなと思っています。

越境を達成するためには、まずシンプルにするのが良いのかなと思っています。例えば先ほど話したように、ちょっと周りに興味を持つだけならできそうだし、素人の意見も言っていいという話であれば意見も言えると思うし、責任を持って決めきれなくても良いのであれば、もっと積極的に入ることができると思います。これが、シンプルで安心な越境、私が思う越境です。

エンジニアが自発的に越境するために必要なのは「興味」

エンジニアの越境の話をします。エンジニアという職業自体が、常にアップデートされる技術や最近のトレンドを追い続けるという職種だと思っているのですが、それを常にやっているエンジニアは、基本的に興味関心を熱量とする方が多いのではないかと私自身は感じています。なので、エンジニアが自発的に越境するために必要なのは、興味だなと思っています。

これは私の話ですが、私は自分の意見が採用されたプロダクト、デザインなどがどう使われているか、すごく興味があります。あとは、自分が作りたいなと思って作った機能が顧客にどう使われているのかすごく興味があります。

エンジニアにおける越境は、興味をどう持つか。エンジニアに越境してもらうには、どう興味を持ってもらうかが大事だと思っています。

ただ、エンジニアあるあるなのかわかりませんが、しばらく使われていなかったり、あまり話を聞かなかったりすると、興味を失ってしまうことが私は多々あります。ほかの機能を作りたいし、やりたいことはほかにもたくさんあるからです。

（スライドを示して）ただ、例外的にこの3点を聞くと、なかなか興味を失わなくなります。例えば、どんな会社に導入されて、顧客がどのように使っていて、どのような感謝があって、どのような改善ポイントがあって……。そういう声を直接聞くとプロダクトにすごく興味が出るし、やってよかったなと思います。

あとは、ちょっと話が変わるのですが、シンプルにこのプロダクトがどこに向かっていくのか、どういう壮大な目標があるのかがわかるとすごくやる気が出ます。

興味が出ると、カスタマーサクセスに話をもっと聞きたくなります。例えば「あの機能どうだった？」「顧客、喜んでいましたか？」とか、あとは「この機能のデザインをもっと良くしたいな」とか思い始めます。そして、デザインチームに相談しにいったりします。これがエンジニアの越境の第一歩だと私は思っています。

自分たちのプロダクトを好きになることが大事

では最後に。みなさん、自分たちのプロダクトは好きでしょうか？　私は非常に好きです。そして越境は、自分たちに興味を持って、自分たちのプロダクトを好きになることが大事だなと思っています。

また、ほかのメンバーが安心して越境できるように、シンプルで安全な越境を定義したり、プロダクトを好きになってもらう努力をしていくと良いんじゃないかなと思っています。これが、私の思うシンプルな越境のコツでした。

以上です。ありがとうございます。