プロダクトエンジニアリング部の興津です。私は普段アプリケーションエンジニアとしてLIFULL HOME'Sのサイト改善業務しています。そのかたわらで、社内の制度を利用して、LIFULLのサービスの一つであるACTION FOR ALLの企画もしています。
今回はそんなLIFULLの独自の制度である「キャリフル」と、その経験を通して私が得られたものについて紹介します。
LIFULLの独自制度「キャリフル」について
まず初めに、エンジニアの自分が企画に挑戦することを可能にした、LIFULLの独自制度である「キャリフル」を紹介します。
キャリフルとは、LIFULLの社内兼業制度で、業務時間の1割程度を本業とは別の業務ができる制度です。
私のように、普段とは別の職種に挑戦することもできるほか、たとえば同じエンジニアでもLIFULLの別のサービスの開発に携わることも可能です。
キャリフルについては公式Noteでも紹介しているため、もっと詳しく知りたい方はこちらをご参照ください。
私がキャリフルに応募した理由
私がACTION FOR ALLの企画職に応募した理由は2つあります。スキルアップとビジョンマッチです。
企画職を体験することでスキルアップをしたい
自分のキャリアビジョンを考えた時、これからはエンジニアの業務だけではなく、一緒にサイト改善を担う企画やデザイナーの業務にも気を配れる存在になりたいと考えました。
特に前職が顧客の社内Webサービスの構築PJに参画することが多かったこともあり、企画職が何をする仕事で、何をエンジニアに期待していることがまったくわからない状態でした。
企画のことを知るためには、実際に企画を経験してみるのが一番よいと考え、企画のキャリフル募集を探し始めました。
ACTION FOR ALLのビジョンに共感し、事業に貢献したい
運が良かったことに、探し始めた時とほぼ同じタイミングで、企画の未経験でも応募可能な募集が始まりました。それがACTION FOR ALLの企画です。
ACTION FOR ALLは国籍や人種、性別、背負うハンディキャップにかかわらず、誰もが自分らしく「したい暮らし」に出会える世界の実現を目指す事業です。
さまざまなバックグラウンドを持つ人が安心して相談できる不動産会社を探すことができるFRIENDLY DOORなどのサービスがあります。
私がLIFULLに入社を決めたのも、ACTION FOR ALLをはじめとした、社会課題の解決に事業として本気で取り組んでいるところに共感したからでした。
特に、私は長年プライベートでも社会的弱者とされる方々の支援活動を行っていたこともあり、LIFULLの数ある事業の中でもACTION FOR ALLは最も好きな事業です。
いつかACTION FOR ALLに貢献できる仕事ができればと思っていた中で、キャリフルの募集はまたとないチャンスでした。
こうして、企画のキャリフルに応募したいと思った時と同じくして、携わってみたいと考えていた事業の企画が募集をしていたため、応募しました。
挑戦して知った、企画職のたいへんさ
施策案を作ることの難しさ
LIFULLにおけるサイト改善の企画職の仕事のメインは、現状のサイトの課題を見つけ、その解決策を立案することです。
言葉にすると簡単ですが、やってみると想像以上に難しいことを痛感しました。
まず、先輩方がアップデートを続けてきたサイトに対して、課題を見つけ出すことすら私にはできませんでした。見慣れて愛着が出てしまっていることもあり、「もう今のサイトが完璧なのでは」と言う気持ちになってしまいました。
先輩方の助けも借りながらなんとか課題を見つけることができても、今度はその解決策を見つけることができませんでした。たとえば、FRIENDLY DOORの会社情報が長すぎるのでは、という課題が出た時に、皆で情報を整理してスッキリできないか案を出し合おうということになりました。しかし、私は考えても「全部の情報が必要！」という思考になってしまい、よい案を思い付くことができませんでした。その時に先輩方からは「ほかの同じようなサイトもよく見て、参考にできるようなものがないと見てみるとよい」というアドバイスをいただきました。企画の人たちは自分たちのサービスだけでなく、競合他社をはじめとした世の中のさまざまなサービスを見ているんだと気付かされた一件です。
さらに、施策を立ち上げた後に行う仕様作成でも、簡単な施策であっても実際にドキュメントに起こしてみると、「こんな細かいところまで考えなければいけないのか」という気付きの連続でした。たとえば、私はFRIENDLY DOORの駅・路線での絞り込み機能を追加する施策の仕様作成を担当しました。この施策も、「複数の路線が通る駅で絞り込まれた時のURL」や「複数の駅が選択された時のH1の文章」など、検討しなければいけないことがたくさんありました。一つ一つの検討事項の結果がサービスの質や売り上げにつながっていくと思うと、いわゆる「決めの問題」となる些細な決定でも責任を感じました。
開発を託すことの不安
無事に仕様が完成し、エンジニアに託した後も、企画はけっして気が抜ける状態ではないということを知ることができました。
エンジニアとして自分が開発者として参画しているときは、現在どんな進捗で、どんな課題があって、計画通りにリリースができそうか否かが簡単にわかりました。それに、何かトラブルが発生したとしても「いざとなれば自分が必死になって頑張る」という最終手段があるという安心感もあります。
企画の場合は、開発中は大きなトラブルなく進むことを祈るしかできません。トラブルを防ぐための打ち手として、事前に仕様を十分に検証するということは可能ですが、開発が始まった後にできることはあまり多くなく、非常にもどかしい気持ちになりました。進捗が遅れた時のリリース日延期の判断や、リソース調整など、企画としてできることにおいても、その判断を早くするためには進捗の把握を積極的に行わなければならないということに気付きました。
最も、私の本業はエンジニアであるため、最終的には自分も開発に入ってなんとかするという判断ができますし、実際にそうした施策もありました。しかし、本業がエンジニアでない企画はそうもいかないので、さらに不安が大きいであろうことは想像にかたくありません。
施策が実を結ばなかったことの悔しさ
企画の先輩方にアドバイスをもらいながら仕様を作り、エンジニアに多くの工数を使って改修してもらった施策が、必ずしもうまくいくとは限りません。
中にはリリース後にビジネス指標が悪くなってしまい、緊急で改修前の状態に戻す判断が必要となった施策もありました。
たくさんの人の協力を得ながら行った改修の結果が悪かったことは、本当に悔しく、皆に対して申し訳ない気持ちになりました。 企画の人たちはこんなプレッシャーとともに施策を打ち出しているのかと思うと、頭が下がる思いです。
エンジニアの自分だからこそできること
企画のたいへんさがよくわかった一方で、エンジニアだからこそ企画業務で活かせることもいくつかありました。
技術観点から策定する仕様
仕様を決めるときに、自分がエンジニアであるため、既存のソースコードやDB構成などを自分で確認できます。
そのため、仕様を決める時に実装のしやすさや性能などを考慮した仕様を考えることができました。
もちろん、そこをエンジニアに相談して一緒に仕様を決めていくことも可能であり、普段の業務でもこうして進めていくことも多いです。
それでもエンジニアのリソースを別のところに使えることは効率的でした。
SQLを用いた分析
先日、FRIENDLY DOORでは住宅弱者フレンドリーな物件一覧のページをリリースしました。
この一覧ページを作った後に、この一覧に掲載される物件の傾向を分析することになりました。「一覧に掲載される物件はどんな増減をしているのか？」「都道府県ごとに差異はあるのか？」「フレンドリーな物件を多く扱う不動産会社はとは？」ということを知れば、次の打ち手の材料にできると考えたためです。
上記の疑問点は、SQLで件数を調べることで知ることが可能です。
こちらもエンジニアに依頼して調べることも可能ですが、ちょっと気になった件数も自分で簡単に調べられるのはエンジニアならではの強みだと思います。
普段の業務での知見を活かした改善
ACTION FOR ALLではLIFULL HOME'Sとは異なる独自のドメインやリポジトリを有していますが、LIFULLでは技術的に管轄している部署が存在していない状態でした。
開発は施策ごとにベトナムの開発拠点であるLIFULL Tech Vietnam Co.,Ltd.(以下LFTV)に依頼しているため、サービスのリリース当初から保守運用があまり積極的に行われていない現状がありました。
そこで、普段の業務で行っていることを活かし、ライブラリのアップデートの推進やテスト用の環境の整備などのエンジニアとしてできることも積極的に行っています。
キャリフルの経験を、普段の業務に活かしていく
普段の業務の経験をキャリフルで活かすことも可能ですが、逆にキャリフルで得た経験が普段の業務に活きていることも感じています。
企画に寄り添えるエンジニアに
当初の目論み通り、企画が行う業務や企画ならではの困難さを体験したことで、企画に寄り添えるエンジニアとして成長できていると感じています。
たとえば、日々の進捗確認では一見エンジニアどうしで把握しておけばよいかもしれないことも、可能な限りエンジニア以外にもわかりやすい言葉を使って説明するようにしています。開発の進捗が端的にしかわからないことは不安であることを知ったからです。
また、施策の結果が数字としてはうまくいかなかった時こそよかったところを見つけて前向きな言葉を発することを心がけるようになりました。結果が振るわなかった時の企画の悔しさや決断の重圧を身をもって知っているからです。
次の段階としては、より確度の高い施策を作れるように、エンジニアの立場からバックアップできることを考えていきたいと思っています。
エンジニア組織のいないサービスに参画したことで、技術的に強くなった
ACTION FOR ALLには専属のエンジニアが存在しないため、障害対応が発生した時は自分しか調査をできる人間がいませんでした。（2024年1月現在は、開発を依頼しているLFTVのメンバーも障害調査ができる権限を付与し、一緒に調査ができるよう整備しています）
普段は同じチームの先輩方に頼れる技術的な判断も、自分に委ねられることになります。
この状況に身を置くことで、技術的にも成長できました。もちろんこの成長は、普段のエンジニア業務の中でも糧になっています。
終わりに
このように、LIFULLでは自分の所属以外の業務や職種にも積極的にチャレンジできる環境が整っています。
さまざまなことに挑戦して成長したいと考えているエンジニアの方は、ぜひ以下のページも見ていただけますと幸いです。
