ユーザーの利益を常に考える環境。開発チームとCSチーム双方向でお客様に対応できるDIGGLEの仕組み

今回は開発メンバーの宮川が思うDIGGLEについてお話させていただきます！

課題を常に深く考えるDIGGLEの仕事

開発チームではまず２週間単位でどんなタスクをすべきか全員で決めています。その後開発メンバーそれぞれの希望や得意・不得意に合わせてタスクを分担していきます。私は前職での経験もあるので他のメンバーよりインフラのタスクを少し多く担当しつつ、フロントエンド・バックエンドのタスクも垣根なく担当しています。開発で使用している言語・フレームワーク（Ruby on Rails、React）は以前から個人的に勉強もしていましたが、業務で扱うのは初めてのため日々勉強しつつ仕事に取り掛かっています。

入社当時（今もですが）DIGGLEの開発チームの考え方がすごく印象的でした。何故そのタスクが生まれたのかという背景を考え何が根本的な原因なのかと深掘りしていく姿勢がDIGGLE開発メンバーの特徴ですね。CTO水上を筆頭にそのような考え方をしていますが、他のメンバーも自然にそのような考え方をする方が多いですね。私はまだまだなところもあり、意識的に考えるようにしています。周りのメンバーも私にアドバイスをしてくれるので、毎日刺激を受けながら仕事できる環境です。

エンジニアから能動的に「ユーザーの利益になるか」を考える

常に「ユーザーの利益になるか」ということを考えているため、プロダクトの中でその機能が使われているのか、あまり使われていないのか効果測定を行っています。他社ではPdMの方がやるのかもしれませんが、その辺りも関われるのはプロダクト全体を見ているようで面白いですね。

また、DIGGLEではお客様がサービスを利用中に発生したシステムエラーを検知し、その際の操作ログを記録するシステムがあります。こちらのシステムで実際にエラーを検知した場合、開発チームは漏れなく検知内容をチェックしてお客様にどれくらい影響が出ているのかを確認し、必要であればCSチームと連携してお客様対応を行います。もちろんCSチームから開発チームにエラーについて問い合わせもありますが、開発チームとCSチーム双方向でお客様に対応できる仕組みが印象的でした。実は前職でも同様のシステムはあったのですがそこまで徹底して対応していたわけではなかったため、DIGGLEの人数規模でこの仕組みがしっかりと運用されていることに入社当時は驚きました。

社員からの手厚いフォロー。フロントエンドとバックエンドを勉強中

私が望んだことではありますが、前職はインフラ専任でフロントエンドとバックエンドには携わっていなかったため、もっと勉強をしなければならないと考えています。入社当時開発メンバーの岡崎がメンターとして、最初の数週間は毎朝ミーティングを設定してくださり、わからない点や不安な点などを確認してくださいました。入社当時不安なことがありましたが、このフォローで救われました！今でも週１でミーティングを設定してくださり、手厚いフォローに感謝しています。

今後の目標

私の経験からインフラ周りに強いため、様々なインフラ周りの仕事を任せてもらっています。バックエンド・フロントエンドのスキルをつけて、どのポジションでも任せられるような存在になるのが私の目標です。また、現在DIGGLEで学んでいるお客様がどんな課題を持っていてどんなアクションをすべきかを深く常に考えるようになれるよう日々努力しています。

DIGGLEは様々なポジションを募集しています。少しでも興味のある方はお気軽にお問い合わせください！