BACK
|ギフティの人

事業と共に成長できるソフトウェア開発──「いい機能」で終わらない、「いい設計」を考え続けるギフティエンジニア

最大1,000種類のラインナップから好きな商品を選べる「giftee Box」や、eギフトをカード形式で提供できる「giftee eGiftカード」。eギフトの可能性を広げ、新たなギフトのカタチを増やしていくため、ここ数年でギフティは、主力となるプロダクトを次々とリリースしています。

そうした事業の成長に合わせ、日々その基盤となるシステムと向き合っているのが、エンジニアの阿部航介さん。「事業と一緒に、健全な成長ができるソフトウェアを」と、急成長する事業フェーズの中でも、事業価値を生み出すソフトウェアの設計について考え続けています。

成果が見えづらい、長期的なスパンを見据えた日々の仕事の中で、意識していること。チームメンバーといかにして目標に向け進んでいくか。また現在の課題などについて、インタビューを通して話を伺いました。

〈プロフィール 阿部 航介(あべ こうすけ)〉

2018年、慶應義塾大学経済学部卒業。新卒で富士通株式会社に入社、エンジニアとして勤めたのち、2019年5月にギフティにジョイン。現在は技術本部Gift Experience dev Unitに所属。

「技術」の視点に寄り過ぎない。忘れちゃいけないのは「ビジネスとして価値があるか」

──阿部さんの、現在の業務内容について具体的に教えてください。

Gift Experience dev Unitという部署で「ギフトの体験の価値を最大化する」ことをミッションに、日々ソフトウェア開発に向き合っています。

最終的には、giftee Boxやgiftee eGiftカードなどのコア事業の機能拡充、新規プロダクト開発などによってギフト体験の価値を高めることを目指していくのですが、直近ではその下準備として、ギフト発行のリアーキテクチャを仕事にしていて。

ほとんどのソフトウェアは、さまざまな要因から技術的な負債化が進んでいきます。ギフティも残念ながらその例に漏れず、歴史的な背景などもあり、やむをえず負債を抱えてしまっている部分があります。

その状態が続くと、ソフトウェアはビジネスの成長に付いていくことができなくなっていくんです。どれだけ事業が成長しても、ソフトウェアが同じスピードで成長できなければ、ユーザーに価値を届けることはできません。

とくにギフト発行のような事業のコアとなる部分に関しては、技術的負債を看過することができなくなっていたりします。

そこで、「ギフトの体験の価値を最大化する」というミッションを達成するために、まずはギフト発行を最適化していくことに取り組んでいるんです。

──日々仕事をする中で、なにか意識していることなどはありますか。

「自分の仕事が事業にどんな価値をもたらすのか」を常に意識しながら仕事するようにしています。

私たちエンジニアの仕事は、たとえば営業のように、数値としての成果が見えづらかったりするので、ビジネス的な価値に結びついているかの見極めがとても難しい。

とくに私のチームの開発は、実際のビジネスとはやや遠いということもあり、下手をすれば、事業価値のないソフトウェアを生み出してしまうリスクがあります。だから「技術のことを考えるのはとても大事」と思いつつも、「事業価値を生み出すために技術を使っているんだ」ということは忘れないようにしています。

そのための具体的な取り組みの一つとして、最近、チームでインセプションデッキを作りました。インセプションデッキとは、プロジェクトの目的や優先順位や方向性を定め、チームで共有するための手法です。

普段は個々で作業をすることも多いエンジニアですが、チームで集まって「そもそもの目標ってなに?」といったことを話し合って全体像を明確にしながら、共通認識を持ち、目標に向かって具体的な計画を立てていく。

そういった取り組みによって、自分たちの仕事が事業にどんな価値をもたらそうとしているのか、そのためにはなにが必要なのか、といったことが明らかになってきます。

ビジネスから遠い開発をしているからこそ、チームみんなで本質的な価値について考えることが大事なんです。

「エンジニアにしかできないこと」を考え続ける。

──見えづらく、長期的だからこそ、みなで可視化していくと。なかなか時間のかかる仕事だと思いますが、阿部さんは、どのようなところにやりがいや楽しさを感じているのですか。

ソフトウェアの設計に、やりがいや楽しさを感じています。ソフトウェアを「機能」と「構造」の二つに分けて考えたとき、機能はソフトウェアの外側にいるユーザーが見えるもの、構造はソフトウェアの内側にあって、ユーザーからは直接見えないもので、その構造をどう作るか、というのを一般的に「設計」と言ったりします。

ユーザーから直接見えない「設計」ですが、いい設計は事業と共に成長できるソフトウェアを生み出します。いい機能を作ることは当たり前で、そのうえでいい設計によってビジネスもソフトウェアも健全に成長させていく。そういった部分にやりがいを感じます。

ソフトウェア開発において設計は、エンジニアという職種だからこそ価値を発揮できる部分だと思っていて。ギフティはほとんどのプロダクトを自社で開発していて、設計の責任もすべて社内のエンジニアにあります。そういった部分も、仕事の楽しさにつながっていると感じます。

ギフティは、事業がどんどん拡大しているし、いろんなプロダクトが出てくる。事業だけが急成長してソフトウェアがボトルネックになるようでは困るので、ソフトウェアも事業と同じように成長できることが期待されます。

そのような課題を解決するために設計を考えていくことは、チャンレンジングですが、楽しいです。

──阿部さん自身、現在の仕事の中でなにか課題に感じていること、あるいは挑戦していきたいことなどはありますか。

これも、事業と共に成長できるソフトウェアを、という話につながるのですが、これからは、ソフトウェア開発の手札を増やしていかなきゃいけないな、と思っています。

いまギフティのウェブシステムのほとんどは、Ruby on Railsというフレームワークで作っているんですが、Railsに頼り切っている状況はあまり好ましくない。

Railsのメリットとして、小さいものを早く作れるということがよく言われるのですが、この特性はこれまでのギフティの事業フェーズにはかなりマッチしていました。

ですが、ソフトウェアの堅牢性や性能、保守性などを考慮したとき、Railsが最適解でないことも多々あります。実際、いまのギフティの事業フェーズ的にも、Railsがマッチしないケースは増えてきていると感じていて。

私のチームで作っているプロダクトもその例に漏れず、例えば高い堅牢性や性能が求められることが多いため、いまは Go 言語でドメイン駆動設計のような設計手法を取り入れながら開発を行っています。

技術はビジネスの手段と言いますが、ビジネスのためによりよい手段を選び取れるように、社内全体として使える手札を増やしておきたいですね。

──最後ですが、阿部さんは今後ギフティにどのような人が入ってきてほしいですか。

不完全だったり不確実だったりする状況を受け入れられること、さらに言えばそういう状況下でも、うまく意思決定をできる人に入ってきてほしいです。

自分がいまやっている仕事は、絶対的な正解がなかったり、何かしらトレードオフの関係になっていたりすることが多くて。

そういった中では、常に完璧かつ確実な状態で物事が進んでいるわけではないため、まずはその状況を受け入れられることが大事かなと思っています。

そのうえで「理想はこういうかたちであってほしいけれど、現段階ではここを落とし所にしよう」といったような、現実的な意思決定ができればなおいいです。

「すべてを一個一個完璧にしてから前に進めよう」というマインドよりは、「完璧ではないけど間違いではない道」を選びながら、「頻繁に改善をしていけるかたちにしていこう」というマインドを持ち続けられる人がいいですね。

(取材・文・撮影・編集:清水 翔太)