部署について教えてください。


「価格.com」の開発・保守を行っている部署に所属しています。チームは取り扱う製品のカテゴリによって分かれていて、PCや家電の価格比較画面を扱う「比較チーム」、消費財の検索画面を扱う「サーチチーム」、口コミやレビューなどを扱う「コミュニティチーム」、他にも「金融・保険」、「通信・サービス」、「自動車」などのチームがあります。
所属しているチームの役割と他部署との関わり方を教えてください。
サーチチームのリーダーとして、主に消費財のカテゴリページや検索結果画面の開発・保守等を行っています。基本的にはサービス分析や改善策の立案を行っている企画部から開発の相談を受けてプロジェクト化していきます。
エンジニアは仕様策定の段階から関わり、実現可否や対応コストを見積り、実装のスケジュールを調整しながら、デザイン部や検索エンジンを保守しているアドバンストテクノロジー部とリリースまで進めていきます。
週に1度、企画部やアドバンストテクノロジー部と定例MTGをしていますが、その場では企画部から新しい案件の相談があったり、既存案件の課題について話をします。案件相談される際の粒度は様々で、ある程度仕様が固まっているものもあれば、フワッとしたブレストベースのものもあります。どのメンバーもフラットな立場で相談をし、私もエンジニア目線で自分の意見を伝えるようにしています。
具体的な仕事の流れを教えてください。
まずは企画部から相談があり、仕様を一緒に考えていきます。システムの目線でどう実現するかを考えると同時に、いちユーザーとして使いにくそうなところがあれば意見を伝えます。仕様が決まると、実装にかかる期間の見積りを行い、リリースまでのおおまかなスケジュールを決定します。期間は2〜3日で終わるようなものから、3か月以上かかるものなど様々です。
基本的には一人で案件を担当し、実装やテストを行いますが、各工程で他のチームメンバーによるレビューを設けています。レビュー以外でもちょっとした相談をすることは多く、テキストチャットや音声通話で雑談を交えながら行っています。
企画部が社内環境でテストした後に、本番環境へのリリースとなりますが、私物のスマートフォンに画面が表示されたときに、実際に世に出たという実感がわいてきて達成感が得られます。また、リリース後に企画部が新しい機能がどれくらい利用されているか、製品選びの役に立っているかなどを検証しますが、この結果はエンジニアにも共有されます。
やりがいを感じたエピソードを教えてください。


一番記憶に残っているのは、カラーバリエーションのある製品の表示方法を改善した案件です。当時、検索結果画面には各色を別々のものとして表示していたのですが、この仕様だとカラーバリエーションが多い製品が検索結果を埋め尽くしてしまうことがありました。また評価が分散してしまうため、人気順でソートした際に人気の製品が出てこないことも課題となっていました。これらを解決するために、検索結果画面では1つの製品としてまとめて表示し、製品の評価値も合算する仕様に変更することになりました。
カカクコムで初めて中心となって担当した大規模な案件で、大きな不安がありましたが、その分得られるものも大きかったです。
上記の案件を進めるうえで難しかったことは何ですか。
多くの部門と連携しながら業務を進める必要があったことです。
検索画面は複数のカテゴリを跨いで商品を扱うため、カテゴリ毎の担当チームと連携をとる必要があり、また規模の大きい案件だったため複数回に分けてリリースを行わなければなりませんでした。そのため企画部、デザイン部、アドバンストテクノロジー部に加え、他カテゴリの担当チームといった多くのメンバーと連携して進める必要がありましたが、コロナ禍で入社し在宅勤務が続いていたことで、誰がどのくらいの知識や責任を持っているかが分からない状況の中で進めなければならずに大変でした。結果的に上司やチームメンバーに助けてもらいながら、無事にリリースできたときにはやりがいを感じました。難しかったと同時に周辺仕様の理解にもつながり、また仕事の流れをつかむことができたため、大きく成長できた案件でした。
大切にしていることを教えてください。
ユーザーにどのような影響が出るのかを慎重に考えることです。実際に形にしてユーザーに届けるのは私たちエンジニアです。企画部の案に対して、より良い実現方法があるのであればこちらからも提案しますし、少しでも悪影響が出る改修であればそのリスクを指摘し、どう対処すべきかを一緒に考えます。万が一不具合が出れば多くのユーザーに影響を与えてしまうので、少しでもその可能性を下げるための仕組みを日々考えています。もう一つは、過去と未来に思いを馳せるということです。価格.comというサービスが、今後も利用され続けるサービスであるためには、目の前のタスクだけではなく、過去と未来を意識する必要があると考えています。
既存の仕様に対してわからないこともありますが、過去の資料でソースコードの変遷を見ると、どのようにして今があるのかが見えてきます。その上で、数年後にはどうなっていてほしいのか、そのために今はどうあるべきかを都度考えて開発しています。当時のメンバーが当時できる中で最善を尽くそうとしていたのだという面影を感じながら、同じように自分が5年後の見知らぬメンバーに対して何を残すべきかを考えて、最善を尽くしていきたいと思っています。
カカクコムの好きなところを教えてください。


失敗を糧にしていく文化があると思います。最近、私のミスで不具合を出してしまったことがありました。リリースのガイドラインを新しいものに変えていく過程で見落としがあり、本番環境に影響を与えてしまったというものです。その際に部長から「改善しようとしている中で出てしまった不具合であれば、責める気はない。これからももっと改善を進めていってほしい。」といった言葉をかけてもらいました。もちろん再発防止のための対策は考えるのですが、それもとても前向きな作業に思えました。サービス自体が長く続いており、機能も多岐にわたるため常に100%の対応をしていくことは難しいのですが、その中で少しでも精度を上げていく必要があるという考えがあるのだと感じます。
※記載内容は取材当時のものです。