エンジニア対談 開発組織の魅力”issueドリブンな開発”とは？
「ニーリーの開発組織で働く魅力」の記事でもお話ししましたが、エンジニア全員が集まってニーリーの開発組織の魅力を言語化するワークを行い、3つのキーワードを設定しました。
熱量と冷静さの共存
issueドリブンな開発
ロールを自ら進化させていく集団
前回の「”熱量と冷静さの共存”とは？」の対談記事に続き、今回は「issueドリブンな開発」について、エンジニアの野呂さんと石倉さんに、どのようなシーンでこの魅力を感じるのかを具体的な体験も交えてお話しいただきました。
■今回の対談者のプロフィール
株式会社ニーリー Park Direct事業本部 プラットフォーム開発グループ
野呂 有我 Yuga Noro
大学院時代に友人と起業（実際には個人事業主）し、楽譜を作って売るサービスを始める。その後、システムそのものに興味が移り、某社でシステムの新規開発開発に従事。2020年夏から株式会社ニーリーにてお手伝いを始め、2022年10月にジョイン。現在、アーキテクトチームのリーダーを務める。
株式会社ニーリー Park Direct事業本部 プロダクト開発グループ
石倉 和真 Kazumasa Ishikura
2020年に合同会社DMM.comにエンジニアとして新卒入社。オンライン公営競技サービスのシステムフルリプレースプロジェクトに参画。その後、同サービスの開発・運用に従事。2022年11月に株式会社ニーリーにエンジニアとして入社。現在、プロダクト開発グループのリーダーを務める。
——まずは簡単にお二人の自己紹介をお願いします。
野呂：
Park Direct開発部のアーキテクトチームでリーダーをさせていただいている野呂です。アーキテクトチームは社内では「アーキチーム」と呼ばれていて、「アーキテクチャ」をかなり拡大解釈した感じでやらせていただいています。
※野呂さんの入社エントリはこちら
石倉：
Park Direct開発部のプロダクト開発グループでリーダーをしております石倉です。普段は、ビジネス部門と開発の橋渡し（窓口）的な役割を担いつつ、要件整理・設計から開発までを一気通貫して行っております。
※石倉さんの入社エントリはこちら
■Nealleの“issueドリブン”とは
——「ニーリーの開発組織で働く魅力とは」の記事にある通り、「issueドリブンな開発」が開発組織の魅力を表すキーワードの一つとして設定されたと思いますが、どのような議論がされたのでしょうか？
野呂：
前の記事で紹介したissueドリブンでは、「Park Direct」は急成長中で解くべき課題が沢山あり、自身が解決したissueが事業の成長や創造に繋がっている実感を得やすい環境だよという話をしていました。
自分は、ここでいう”issueドリブン”というのは、いわゆるチケット駆動みたいな話とは違って「何を開発するか、次に何をするべきかを、解決したい問題を中心にして考える」みたいな意味で捉えています。
解決したい問題の本質が本当は何であるかを見極めてから、開発に取り掛かるということですね。
石倉：
同感です。“issueドリブンな開発”は、ニーリーの開発が事業の成長や創造に繋がっていることをストレートに表しているキーワードだと思います。
野呂：
開発組織の魅力をディスカッションする際にも、ニーリーでは「ビジネス側に対して開発側からアイディアを提案したり、逆にあえてビジネス側の要求をプロダクト観点や技術的観点を理由に断ったり、やるべきはこういうことじゃないのかと議論するという場面をよく見かけるよね」という話があがりました。
なぜそういった場面を多く見かけるかというと「事業の成長スピードを落とさないために、その開発が本当に状況にあった正しい開発かどうかを開発主体で考える」からで、その認識を開発サイドもビジネスサイドも共通で持てているよね、と。
石倉：
そうですね。
プロダクトや業務における課題、またプロダクト価値向上につながる施策は、開発・ビジネス組織問わず多く挙がり、それに対して開発やビジネス組織が協働して取り組むケースは多く観測できます。
野呂：
石倉さんの所属している部署は特にissueドリブンな開発の色が強いですよね？
石倉：
そうですね。
僕が所属するアプリ開発チームは、プロダクトの価値向上を主目的とするチームのため、プロダクト課題に常に向き合っています。ほぼ毎日ユーザから届く大量の要望から、”今解決すべきこと”を整理し実現（開発）することが主な仕事となります。
Park Directには社内外含めて3種類、
● 駐車場の借主（カスタマー）
● 不動産管理会社（クライアント）
● 社内のクライアントサクセス＆カスタマーサクセスチームのメンバー
というユーザが存在しており、各々から日々相当な量の要望が飛んでくるため、一つ一つ丁寧に解決していてはプロダクトの成長速度が鈍化してしまいます。そのため開発としては、いかに素早く、かつ効率よくユーザのペインを解決するかがキモになります。
まさにこの意識こそがニーリーの考える”issueドリブン”そのものであると考えています。
野呂：
この素早さや効率性を実現するために、エンジニアはただ開発をするのではなく、要件・要求の整理からビジネスサイドの方々と協働していたりします。
石倉：
具体的には、”分科会”という会議をビジネスサイドのグループ毎に隔週で開催しておりまして、そこで日々クライアントや社内から挙がった要望についてビジネスサイドの方々と議論をしています。
具体的には、要望の起票に至った背景や要求事項についてビジネスサイドの方から共有いただき、その情報を基にペインとなっている箇所の特定、ペインを解決するための具体的な手段について議論します。手段が決まれば、開発チームが手段を基に詳細設計し、実装・テスト・リリースまで行うというのがエンジニアの基本的な動きとなります。
エンジニアがこれだけ事業に染み出して立ち回る光景は中々に珍しいことだと思っていて、まさにこの染み出し具合がニーリーにおけるエンジニアの醍醐味ですよね。
■“issueドリブンな開発”を表すエピソード
——開発組織の魅力の言語化を議論する場では、エンジニアのみなさんから具体例を発表したということでしたが、どんな具体例やエピソードがありましたか？
野呂：
僕が入社してまず、駐車場の借主（カスタマー）に提供しているサイトの一部刷新を行ったんですけど、その意思決定も今思えば完全に“issueドリブン”でした。
その時のissueが「SEOスコアが低い状態になっていること」「レスポンスが遅くて使いにくいこと」で、それを解決するためにどうすべきか考えた結果「刷新する」という決定に至ったのですが、issueを解決するための最速の方法を取りました。つまり、「SEOに関係がある」「遅いと使いにくい部分」だけをまず刷新して、それ以外の部分はそのままにしたんですね。
結果的に、古いシステムで動いているページと、新しいシステムで動いているページが混在する形になって、ページ数が多いわけでもないのにAngularとNext.jsが1つのドメインに共存するちょっと複雑な構成になりました。ホストしている環境も違うしパス単位で切り分けをしたので、リダイレクトの方法なんかにも結構気を使う感じでしたが、それでも全部を作り切るよりは全然早かったと思います。
石倉：
もしissueドリブンでなければ「全体を作り切ってから置き換える」みたいな意思決定になっていそうですね。
野呂：
そうですね。普通「刷新」ってそういう意味なので。
技術選定も、今回のissueにフォーカスして行いました。
`ISR` を使うために `Next.js` を `Amplify` にホストしたり、動作の速さを優先してCSSフレームワークに `vanilla-extract` を採用したり、など。
「熱量と冷静さの共存」記事にもありますが、決してオーバーエンジニアリングやissue解決に貢献しない謎のタスクが入り込まないように、それ以外の部分はほとんどフレームワークや環境の「標準」を使うようにしています。
この辺りの判断も、解くべきissueが定まっているのでやりやすかったです。
結果として、狙い通りにSEOスコアが上昇し、事業に貢献できた！という実感があります。
石倉：
私の場合だと、直近リリースした「お知らせ機能」はまさに“issueドリブン”を表すエピソードなのかなと思っています。
この機能が実装されることになった背景をざっくり説明しますと、機能リリースやメンテナンス告知、管理会社様向けのお知らせが発生するたびに、該当する管理会社様に向けてメール配信をしていました。
ただ、このメール配信業務は以下のペインを抱えておりました。
１．ゼロダウンタイムでのリリースができるようになったことで、機能リリースの頻度が向上した結果、定期リリース以外のタイミングでも頻繁に配信するようになった（配信業務の工数増大）
２．メールだと管理会社様が実際に確認してくれたかどうか判別できない上に、実際にメールを確認してくれない管理会社様も多数存在していた
このようなペインを解消するために、実際に配信業務に携わるあらゆる部署のメンバーを巻き込み、要件定義・機能設計を行い、実装まで一気通貫で行いました。
野呂：
ビジネス側のメンバーと一緒に要件定義をすると、「他にも実は」と要望が出てきそうでいいですね。
石倉：
まさにその通りで、メール配信をしていた担当者の方々から「画像の埋め込みをしたい」や、「配信時間の時限設定ができてほしい」など様々な要望をいただきました。
ただ、まずはなるべく早くペイン解消することを目標としたため、一旦初期リリースではMUST要望のみをスコープとして調整し、実装を進めました。
実際にお知らせ機能がリリースされたことで、上記ペインの解消はもちろんのこと、管理会社様にとってもお知らせを見逃しづらい環境にできました。
当初は内部の業務効率化・リスク低下を主目的としておりましたが、結果として内部だけに留まらず、管理会社様にまでメリットが及ぶ形となったので、非常に貢献できたのではないかと思っております。
以下余談ではありますが、お知らせ機能をリリースすることをサクセスチームに報告したときに、お褒めのスタンプやお言葉をたくさんいただけて、救われた気持ちになったのを今でも覚えております(笑)
■Nealleには解くべき魅力的なissueがまだ沢山ある
——今後取り組んでいくissueにはどのようなものがあるのでしょうか？
野呂：
ある程度以上に成熟したサービスだと、そもそも「解くべき課題（＝issue）」が何なのかを見極めるのが難しくなっていることが多く、まず開発側で成果の見えやすい課題を設定して取り掛かるということも多いと聞きます。
issueドリブンでない場合、完全に無駄なものを作ってしまったり、誰も求めていないものを作ってしまってプロダクトの価値を下げてしまったり…みたいなことが起こりやすいですよね。
一方で、今のPark Directは作ったら確実に事業貢献できる「根拠あるissueが目白押し」という状態です。
石倉：
そうですよね。プロダクト機能観点だけでもこんなことやあんなことをやらないといけない・やりたいと思っていることがたくさんあります。例えば、インボイス制度施行に向けたシステム改修は直近でしなければならないですし、より多くの不動産管理会社様にご導入戴くためにも、賃料計算の端数処理方法はより詳細に設定できるようにしたいですし、その他にも内部向けの業務効率化施策などなど...列挙し始めるとキリがないほどにやりたいことがありますね（笑）
野呂：
そうですよね。一方で、アーキテクチャや技術観点でも、大きくてやりがいがある開発issueがありますよ。例えば、今、AngularをNext.js化しているのもそうですが、他にもバックエンドのリアーキテクチャや認証基盤の作成、権限制御の構造の変更なんかをやっていきたいと思っています。
なので、解くべき課題が沢山あって、確実に事業貢献ができる状況で楽しい！と思っています。
——ありがとうございました。最後に、この記事を読んでいただいた方へメッセージをお願いします。
野呂：
繰り返しですが、今Park Directには解くべき課題が沢山あります！
課題解決が好きな皆様、是非一緒に事業を盛り上げてください！
石倉：
開発領域だけに閉じずに、事業領域にもっと染み出したいエンジニアの方にとってはぴったりの環境だと自信を持って言えます！
是非一緒に事業成長させていきませんか💪
ニーリーでは、事業拡大に伴う組織強化のため、多様な職種で⼈材を募集しております。
詳しくは、採用特設サイトをご覧ください。
採用特設サイト：https://jobs.nealle.com/
また、少しでもご興味を持っていただいけたら、オープンポジションのカジュアル面談も実施中です！
https://herp.careers/v1/nealle/HT6slw2HulGr
■開発メンバーとのカジュアル面談はこちら
・三宅 克英（取締役CTO）
モビリティSaaSのプロダクトグロースについてお話しましょう
・菊地 弘晃
Mobility SaaSを一緒に開発しませんか？