「ニーリーで働く面白さを、より多くの人に伝えたい！」という思いから始まった、「ニーリーの開発組織で働く魅力」の言語化企画。エンジニア全員が集まって議論し、3つのキーワードを設定しました。

• 熱量と冷静さの共存

• issueドリブンな開発

• ロールを自ら進化させていく集団

今回は、魅力の3つ目である「ロールを自ら進化させていく集団」についての記事です。お話いただくのは、エンジニアの西村さんと大友さん。どんなときに「ロールを自ら進化させていく集団」であると感じるのか、事例をもとに詳細までお伺いしました。

※「ロールを自ら進化させていく集団」とは、自分の与えられた役割や期待値を超えて、自らを進化させていける人の集まりのことを指します。詳しくはこちら「ニーリーの開発組織で働く魅力」の記事をご参照ください。

■今回の対談者のプロフィール

株式会社ニーリー　プロダクト開発本部　
西村 啓渡　Keito Nishimura

2011年ワークスアプリケーションズにエンジニアとして入社。2014年にITコンサル企業、2017年にはフリーランスを経て、2020年4月にニーリーに入社。

株式会社ニーリー　プロダクト開発本部
大友 凜　Rin Otomo

2019年にエンジニアとしてのキャリアをスタート。最初はフロントエンドエンジニアとして小規模なアプリやPoC開発を中心に経験し、仕事と並行で独学でスクラム開発などの開発手法を学ぶ。2023年1月に株式会社ニーリーに入社。最近の口癖は「のびしろ」と「やっていき」。

――まずは簡単にお二人の自己紹介をお願いします。

西村：
2020年4月にニーリーに入社し、バックエンドのエンジニアとしてサービス開発や運用を行ってきました。今は、お金回りの業務改善プロジェクトを担当するエンジニアとして働いています。

大友：
2023年1月に入社しました。僕も西村さんと同じプロダクト開発本部所属のエンジニアで、今年発足した同プロジェクトに参加しています。
普段はフロントエンドエンジニアを名乗っていますが、実際にはアプリレイヤー全般の設計が好きなエンジニアです。ニーリーではフロント・バックの両方の開発を担当していますね。
（※大友さんの入社エントリ記事はこちら）

■Nealleの“ロール”とは

――ニーリーでの“ロール” について、どんなことを感じますか？

大友：
例えば一般的なエンジニアにとって“ロール”とは、上流・下流で明確に分かれている様なイメージを持たれることが多いと思います。僕も前職では、いわゆる下流の製造・コーディングを担当するプログラマーでした。ただ、ニーリーに入ってからは、そうした役割関係なく横断的に動いている実感があります。前職とのロールの捉え方は大きく違っていて、全く新しい世界観ですね。

西村：
そうですね。ロールの捉え方にユニークなところがありますね。ニーリーでは、一般的な開発の役割をあえて意識していない感覚があります。もちろん「誰がやるべき」という役割分担はあるのですが、「誰がやるのが一番効率的か」という視点から考えることが多いですね。アサイン方法についても、基本的には「プロジェクトの目的を達成するための最適な方法」を考えて割り当てられます。なので大枠の目的感から役割を考えることができますね。

――「ロールを自ら進化させていく」文化は、日常にも現れていますか？

西村：
はい。ニーリーはオーナーシップを持って取り組むことが推奨されている環境だと思います。目的や背景を知り尽くした上で開発できることは、大きな魅力ですね。そもそも社内においても、エンジニアはシステムの全体像を一番よく知っている存在というのが浸透しています。なので開発の役割を超えてビジネスサイドの方とも関わりながらプロジェクトを進めています。他部署の方に度々ヒアリングをしながら、サービスのルールを決定するところから携わることができますね。

大友：
たしかに。日々の業務の中で、実際に運用する方々と関わることが多いですよね。僕も「事業にとっての価値を考えると、自分が担当した方が合理的だ」と思う部分を見極めて取り組む事が多いです。運用に任せきりにせず、仕組み化や交通整備などをして、常に伴走することを意識していますね。開発組織としても「エンジニアだから運用はやらない」と既存のロールにとらわれることなく、事業インパクトが出せる方向に行動していくことが当たり前になっている様に思います。このあたりの文化が「ロールを自ら進化させていく」ということに当たるのかなと思います。

■“ロールを自ら進化させていく集団”を表す具体的なエピソード

――ロールを自ら進化させたエピソードとして、ぜひ具体的な事例を教えてください。

※ニーリーの事業・ステークホルダーについての詳細は「Park Directがつくる社会の「選択肢」～ミッションである「社会の解像度を上げる」挑戦とは～」の記事をご覧ください。

① 頻繁に他部署と連携し、エンジニア主導でルールを決めていく

西村：
事業KPIについての事例を紹介します。開発部門は通常はプロダクトKPIには直接関わりますが、事業KPIについて直接関わることは多くはないかと思います。今回取り組んだ事例では、事業KPIの１つである契約数を改善するために、プロダクトおよび社内の契約・請求に関するフローの見直しが必要でした。

プロジェクトの体制は不動産管理会社と向き合うクライアントサクセス本部、駐車場の契約者と向き合うカスタマーサクセスと、プロダクト開発のメンバーで構成されていましたが、スピーディーに対応する必要がある一方で難易度が非常に高い案件だったので、プロダクト開発手動で進める案件だと感じ、ルール策定の部分からイニシアチブを持って進めていきました。実際に戦略を決めて開発するまでに要した期間は4ヶ月程度でした。

大友：
あの時、めちゃめちゃ大変そうでしたね。。。（笑） 僕は直接、開発に参加していなかったのですが、特に難しかったこととかって何がありましたか？

西村：
課題として、複雑で難易度が高いKPIにフィットさせていくためには、今までのルールを変更・整備する必要がありました。何をやりたいかについては明確でしたが、どう実現するかは非常に難解でした。ユーザーの契約・請求フローはもともと分岐が多く、複雑な部分まで知ることができるのは開発である自分だと思い、整理を進めました。

大友：
なるほどなるほど。

西村：
運用開始後に想定外のことが起きてしまうと、運用の担当部署に大きな負荷がかかってしまうため、「想定できる分岐をもれなく洗い出すこと」が必要でした。そしてそれが特に難しかったです。主にカスタマー・クライアントのフロント担当の方と頻繁に打ち合わせをして、詳細までヒアリングし、ケーススタディを書き、それをもとにディスカッションをして新しいルールを整備していきました。

②部分的な開発ではなく、全体ゴールイメージの策定から総合的に携わる

大友：
僕が担当した口座振替管理システムの導入サポート事例を紹介します。2ヶ月程度で、ユーザー受け入れテストや導入後の業務支援など、ペイメントグループ（お金回りの仕組化を経理と連携して担う部署）とビジネスオペレーショングループ（管理会社様が契約している既存の駐車場ユーザーの方を、Park Directへの契約に切り替えを行う部署）の方と協働して新しい業務フローを構築しました。

一般的な自分のロールとしては、交通整理と機能説明、バグフィックスなど、いわゆるエンジニアの業務のみですが、当初はプロジェクトメンバーにも共通の完成像がない状態だったため、今回は全体のゴールを決めるところからがっつり関わりましたね。フローの提案、優先順位づけ、運用開始後のトラブルシュートから原因調査まで、社内の色んな部署の方とかなり密に連携して動くことができました。

西村：
開発の作業だけでなく、社内の他の部署とも連携して業務してましたよね。口振管理システムのリリース後の反響ってどうでしたか？

大友：
そうですね。週次の会議などで協力していただいた方々に本当に感謝です。そうしたご協力のおかげもあり、口座情報がシステム上で確認できるなど検索性が上がり、よりスムーズな請求データの作成に繋がりました。実際に社内からも「便利になった」という声を直接いただけたのは嬉しかったです。様々な部署から直接フィードバックをいただける環境なのでモチベーションも上がりますね。

③運用を自走化できるよう、自ら運用し丁寧に手順に落とす

西村：
保証サービスの追加導入事例では、Park Directで解約や滞納があった場合に保証会社へのデータ連携が必要になるのですが一部システム化できていなかったため、手動オペレーションでデータを出力・加工して連携をしました。

大友：
最初に連携のための作業をやっていたのって西村さんだったんですね。

西村：
そうですね。最初の1〜2ヶ月は僕のほうで作業してましたね。保証会社のシステム担当の方と連携の仕様について会話していたのが自分であったため、まずは自分で作業してみるのが効率的だと判断しました。スムーズに運用担当者に引き継ぐために、最初は、自分で作業して手順書へ落とし込みをしました。

そして2ヶ月目には運用担当者の方と並走して作業をし、3ヶ月目には完全にお任せできる形になりました。後工程の方が困らないように、実際の業務に落とし込んで自走化を促進することは、エンジニアの枠を超えた事例かと思います。

④必要に応じて、エンジニア分野以外の新しい知識を得る

西村：
もう一つ、進行中の決済会計プロジェクトを紹介します。請求・支払いなどのお金に関するデータの管理が複雑で煩雑という課題があり、これを解決する必要がありました。

私はもともと新卒の企業で、受注・売上管理に関するシステム開発をしていたので入出金フローの基礎知識は得ていたものの、経理の専門知識はありませんでした。今回のプロジェクトでは経理の知識が必要になると考え、再度勉強をしました。Park Directにおける入出金のパターンを洗い出し、経理の方ともディスカッションをして仕訳のルールを決めています。このように必要であれば新しい知識を学ぶことも、ロールを自ら進化させている例だと思います。

⑤エンジニアとして他部署と直接対話をしてクイックに開発

西村：
駐車場の借主に対応するカスタマーサクセス、いわゆるコールセンターの役割を担う部署との取り組みです。ありがたいことにPark Directの契約者が増加したにも関わらず、対応する人や対応のルール、システムがまだ確立できていなかったこともあり、応答率が落ち込んでしまい、負荷が高まっている時期がありました。そこで、電話対応の業務効率化のため、エンジニアとしてフロントの方々の意見を直接聞きながら業務効率化のための開発をクイックに実施していきました。

大友さんにも、カスタマーサクセス部を通さない解約申請機能の開発をお願いしてましたね。

大友：
そうですね！カスタマーサクセスの方々と密に連携して開発させてもらいました。初めて僕がリリース〜運用含めて検討・開発に取り組んだ案件だったので、特に印象に残ってますね。

西村：
その結果、開発だけではなくカスタマーサクセスと協働して応答率が90%以上まで改善されました。総合的な数字ですが、90%は大企業でも難しい数字と言われている応答率なので、嬉しかったですね。

■“ロールを自ら進化させていく”カルチャーについて

――最後に、エンジニアとして「ロールを自ら進化させていく」カルチャーをどう思いますか？

西村：
本当に“面白い”ですね。お願いされた部分のみを開発して「結局これって何のためになるんだっけ？」と、大きな目的感を見失いがちなケースは一般的にあると思います。しかしニーリーでは、業務・運用も含めて背景を知った上で事業全体のゴールを見据えた開発ができるので、実際のタスクとゴールの関係性が見えやすいです。プロジェクトごとに内容や立ち位置が違うので様々なことにチャレンジしやすいですし、プロジェクトメンバーからのフィードバックもたくさんある環境です。仕事の幅を広げたいと思っている方には、ぜひおすすめですね。

大友：
圧倒的に“面白い”、と思っています。自分で作ったものが実際に価値を発揮するまでの一連の流れに対して、オーナーシップを持って取り組める貴重な環境ですね。僕を始めエンジニアは技術的な部分が専門なので、ロールを超えていく中で、ビジネスの部分については専門外で難しいと感じることも多いです。しかし、エンジニアリングだけに閉じずにPMなどのポジションにも挑戦していきたい自分にとってはやりがいがあり、自然とスキルや経験が幅広くなっている実感もあります。また、事業全体を見据えて開発するというスタンス自体がPMなどの次のキャリアに繋がっているとも感じるので、それもモチベーションに繋がっていますね！

herp.careers O01【エンジニア】オープンポジション

株式会社ニーリー

募集要項をみる

■開発メンバーとのカジュアル面談はこちら

・三宅 克英（CTO）
圧倒的に事業に染み出す開発組織に興味がある方お話しましょう！

・菊地 弘晃
【シリーズB累計102億調達】モビリティSaaSのエンジニアを募集してます！