東急株式会社の企業PR | IT/Web業界の転職サイトGreen

デザイナー出身のVPoEと働くってどんな感じ？シニアデザイナーたちが語る本音

URBAN HACKS デザイナーチーム

ーー現在デザイナーは6名所属していますが、どんなタイプの人が多いのでしょうか？山本：全員、持っている武器が違うと感じます。バランスが取れたメンバー構成ですね。デザイナーの中にはいわゆる「癖の強い」人もいるのですが、URBAN HACKSのメンバーは良い意味でふわっとしています。さらっと華麗に業務をこなすけれど、芯があるイメージです。元原：以前、デザイナーのワークショップで自分たちのブランディングについて考えたときに出てきたキーワードは、「職人気質」「地道にものごとを作る」「地味だけどちゃんとやる」などでした。中途採用がメインだからかもしれませんが、仕事人のような雰囲気のデザイナーが多いです。高山：一言で言えば「多様性」でしょうか。全員デザイン領域のプロでありながら、アプローチ方法は一人ひとり全く異なります。その一方で、グラフィックに対する「我」は強くないんです。事業会社出身の方が多いからかもしれません。山本：アーティストというよりも、クリエイター集団ですよね。グラフィックの品質に対する絶対的な基準はもちろん持ち合わせつつ、ユーザーにとっての使いやすさを突き詰めています。ーーVPoEの宮澤(以下、Sean)さんはデザイン出身です。一緒に働いてみていかがですか？元原：デザイン思考でものづくりをする大切さを、デザイナー以外の方にわざわざ説明する必要がないのがうれしいです。山本：まさしくそうですね。Seanさん自身が先頭に立ち、各部門に対して「デザイン思考が大事なんだ」と伝えてくれているので、すごくやりやすいです。普通の会社なら、デザイナーからそういう考え方を一から提案しないといけないんですけど。あとは当たり前ですが、デザイン用語もSeanさんには一発で伝わります。例えばUXの手法一つにしても、普通なら「こういう手法があって、それにはどんな効果があって……」と要件を明確に示した上で初めて実施させてもらえます。一方、Seanさんには「ユーザービリティテストをやりたいので費用を取ってください」と言えばすぐに通じます。「どうして謝礼に数千円もかかるんだ」とは絶対に言われません。デザイナーとしていろいろな経験を積んでいる方だからこそ、コミュニケーションロスがないんです。高山：確かに、デザインに関する具体的な相談をできるのも大きいですよね。元原：そうですね。実は、URBAN HACKSには承認プロセス自体が存在せず、あらゆることが各々の意思決定に任されています。だからSeanさんに対しても「承認」をもらうのではなく「相談」をするという感じになるのですが、デザイナーとしての経験も豊富なので、すごく的確なアドバイスがもらえますね。山本：判断や行動のスピードもとても速いです。元原：相談ごとは持ち帰らず、その場で決めますよね。リーン開発的な雰囲気があり、短いスパンで試行錯誤を繰り返すのが特徴です。山本：あとはSeanさんがいることで、「デザイナー」という存在自体が引っ張り上げられているなと。一般的にエンジニアやほかの職種のメンバーに比べると、デザイナーはどうしても「下層」の存在になりがちなんです。だから私個人としては、URBAN HACKSで初めて安心して働けている実感を持ちました。元原：私たち自身もシステムの課題なんかに対しては、つい「デザイナーは何もできないな」と無力に感じてしまうシーンがあります。でもSeanさんは、「複雑な問題にこそデザインが必要なんだ」と言い続けてくれるんです。いかにデザイン思考を持って顧客体験を具体化し、ものづくりをしていくことが大切なのか。それを自ら示してくれます。

リアルとデジタルを繋ぐ壮大な挑戦。リクルートや楽天で学んだPdMが東急URBAN HACKSで実現したいこと

シニアプロダクトマネージャー　田中

ーー新卒の会社ではどのようなお仕事を経験しましたか？ソニーグループの社内SEとして、1年目は知的財産管理システムのPMOサポート業務を行いました。すでに開発が進んだフェーズだったこともあり、テストの自動化などにも関わらせてもらうことが出来ました。2年目は、エンタープライズアーキテクチャー推進部門に配属され、グローバル全体で稼働しているシステムの把握や、PMOとしてシステム管理台帳のリニューアルなどを担当しました。 ――その後のキャリアについても教えてください。 2年間の業務を通じて、社内SEという仕事は、自分が目指すキャリアとは異なるという想いが募り、サービスデザインの仕事が経験出来そうな株式会社リクルートキャリア(現：株式会社リクルート)に転職。リクルートエージェントサイトの改修や、リクナビNEXTのリニューアルPJのリーダーなどを担当させていただきました。当時は、プロダクトマネージャーという職種名がまだ一般的ではありませんでしたが、いまで言うプロダクトマネージャーの役割を担っていました。その後、電通デジタル社にて、1年間のDXコンサルタントとしての経験を積んだ後、楽天株式会社(現：楽天グループ株式会社)に転職しました。楽天では、楽天市場の一部機能や、楽天ポイント関連プロダクト(Web、アプリ)を統括するプロダクトマネージャーとして、楽天ポイントの体験設計や戦略実現のためのプロダクト改善に取り組みました。楽天グループ全体で利用されており、累計発行額が2.5兆を超える「楽天ポイント」というアセットをどのように成長させるか、日本最大規模のプラットフォーマーとしてのダイナミズムを肌身で感じながら仕事をすることが出来たのは、非常に貴重な経験だったと感じています。ーー転職を考えたきっかけを教えてください。多くの会社を経験しながらも、学生時代のコンテストで提案したような、オンラインとオフラインの体験を統合的にデザインし、世の中を変革していくような取り組みに関わりたいという想いはずっと持ち続けていました。楽天社内でもチャンスを伺ってはいたのですが、なかなか希望するような話に巡り会えないでいたところ、偶然Wantedlyで見つけたのが、東急URBAN HACKSでした。まさにこれだと思いましたね。というのも、現在のDXは「デジタル業界」の会社が提供するコンサルティングやSaaSなどのサービスによって牽引されているケースが中心です。しかし本質的には、事業会社がDXでデジタル武装していく結果、「デジタル業界」という概念はなくなっていくはずです。別の言い方をすれば、近い将来、デジタル人材はどこの企業にも存在し、企業はリアルとデジタルを繋げて、自社のサービスを設計していくことが当然な時代が到来するということです。デジタル業界からかけ離れたリアルビジネスを展開する東急が、自社のDXを「社内の内製開発チーム」によってリードするという記事を見た時、時代を先取りするチャレンジだと、非常にワクワクしたのを覚えています。ーーどんな部分に惹かれましたか？まずは、プロジェクトオーナーが、ソニーのプロダクトデザイナー出身で、日産自動車のコネクテッドカーサービスをリードされた経験のある宮澤さんであるというところです。日本の大企業では一般的に、社外のコンサルやSIerの力を借りて、DXを推し進めるようなケースが多いなかで、非常に挑戦的で面白い取り組みだと感じました。また、私自身も約8年間にわたって東急沿線住民だったため、東急には好感を持っていましたが、周囲の人に聞いてみても「私、東急好きだよ」という答えが返ってくることが多くありました。なかには「東急なら大丈夫だと思って、マンションを買った」という話も聞いたほどです。こうした、創業から99年もの長い間、質の高いリアルサービスを積み重ねてきたからこその東急という強いブランド力と、デジタルが当たり前になっている現代において、デジタル面がまだまだ追い付いていないという問題をしっかり見つめ、全力でDXを推し進めようとしている姿勢、この２つが掛け合わさることで何が起きるのか？ぜひ当事者としてそこに関わってみたいと感じました。

最善を追求できる、URBAN HACKSのバリューと開発組織の在り方の関係

シニアプロダクトマネージャー　田中エンジニア　一杉

ーーバリューをどう捉えていますか？一杉：正直なところ、常にバリューを意識して働いているわけではありません。チームには最初からバリューを体現したようなメンバーが集まっているため、組織としてバリューを言語化し認識を合わせした上で、自然にバリューに沿った動きをしている部分が大きいと感じます。田中：私も、暗黙的に自分たちが持っている価値観や組織の方向性がズレないような基準として、バリューを設けているイメージがあります。メンバーが共通して体現したい事柄の「最大公約数」や「こだわり」に近いですね。ーー自分たちがバリューを「体現している」と感じるのはどのようなときですか？一杉：例えば「One Team, No border」の観点でいうと、私自身はサーバーサイドエンジニアの枠にとらわれずに動いています。必要ならインフラ関連の業務も積極的に手掛けますし、UI/UXの議論でも意見があれば発言をします。田中：エンジニアだから、デザイナーだからと役割を線引きしないのがURBAN HACKSのいいところですよね。入社した直後の「ボーダー」を取り払うために、自ら工夫して取り組んでいるのも特長です。あるチームは定例以外の打ち合わせにSlackのハドルミーティングを用いることにしていて、どんな会議、議題に参画するのかをメンバー自身がコントロールしています。一杉：「素早く失敗、素早く改善」でいえば、UIにせよアプリのモックにせよ、まずは作ってみてメンバーと共有し、改善を繰り返しながら開発しています。自分たちのプロダクトをどんな方向に進めるべきか、細かに議論を重ねているんです。ーーまさしくチームが一丸となって、協力し合いながら開発をしているんですね。一杉：そうですね。これは、まだまだ組織の人的リソースが足りない分、一人で全ての開発作業を網羅的に行うことが難しい点も関係しています。自分だけでは補えない部分があれば、誰かの知見を借りながら進めています。実際の一例では、サーバーサイドでメインに使っている言語はGoですが、私はこれまでGoは未経験でした。そこで知識を持ったメンバーに協力してもらい、学習をしながら仕事を進めています。技術レベルの高いメンバーがそろっているので、お互いに知識を補完し合って「高い技術力」を維持していこうとする動きを取るわけですね。そんな組織だからこそ、自分の経験の有無についても正直に言い合える空気感があります。バリューでいうなら「正直でオープンなコミュニケーション」にも該当する部分でしょうか。自分の実力を超えて背伸びをする必要は全くありません。ーーバリューを体現するための取り組みにはどんな施策がありますか？一杉：「組織課題探索委員会」を立ち上げています。メンバー全員にヒアリングをして、出てきた業務上の課題を解決していく取り組みです。一つの例でいうと、朝会と昼会の参加形態を変更しました。人数が多くなってくると一人ひとりの発言時間が短くなってしまうため、ミーティング中は小さいグループに分けて、コミュニケーションが取りやすい形にしました。この取り組みが正しいかどうかはわかりませんが、一つずつ自分たちの組織を改善しようとしています。また、URBAN HACKSの立ち上げ当初はミーティングが多すぎる傾向だったので、本当に意味のあるものだけを実施して、本質的な議論がしやすいように整備もしました。田中：形式的なやり取りや業務はどんどん削っていますよね。大企業はどうしてもガバナンスが複雑で、上長の承認や証跡が必要になりがちです。しかし我々はバリューの「Outputではなく, Outcome」にある通り、とにかくアウトカムを増やそうとする集団です。成果を重んじて、「議論のための議論」は極力排していこうとしています。そのおかげもあるのか、メンバーはみんな仕事が速いですよ。何か要件があった際に「来週のミーティングで確認をして、部長会で承認をもらって...」という煩雑なプロセスが必要ないとわかっているからこそ、ブレーキをかけずに全体のスピードを速めていけます。この意識はURBAN HACKSが今後大きな組織に成長しても、守っていきたい部分です。

「AmazonやGoogleに引けを取らないプラットフォームをつくる」サイバーエージェント出身エンジニアの新たな挑戦

サーバーサイドエンジニア宇都木

ーーこれまでのキャリアを教えてください 1社目では、要件定義から設計、プログラミング、リリースまで担当しました。元々はITコンサルを目指していたはずが、プログラミングの面白さにはまってしまって。いつしか業務外の時間に本を買って、クローラーを自作するまでになりました。自分のキャリアとしても、このままITコンサルタントを目指すより、コードをどんどん書ける環境に行きたいと考えるようになりました。当時は、AIや機械学習が出てきた時期。面白そうだと感じましたね。データをたくさん持っていて、機械学習のようなソリューションを自分の手で作っていけるポジションを探したところ、アフィリエイトサービスを提供するバリューコマース株式会社とご縁があり、Web系エンジニアに転身しました。バリューコマースでは、当初の希望通り、開発に注力しましたアフィリエイト広告のプラットフォームを使ったWeb接客ツールや、機械学習を活用した広告配信ロジックの開発をしました。今となってはAWSなどのクラウドが充実していますが、当時はオンプレミス環境でなおかつC言語を使った、高度な開発を経験させてもらいました。当時の環境には満足していましたが、ある日、エージェント経由で、サイバーエージェントの紹介をしていただきました。規模の大きい広告会社なのもあり、興味半分で選考に。サイバーエージェントは当時からAIに力を入れていましたし、もっと機械学習に関するスキルを身に付けられるのではと、転職を決意しました。しかし結局、AIに関わることができなかったんです。当時の組織状況や、サーバーサイドの技術を買われて、サーバーサイドエンジニアとして開発に注力しました。結果的に、大量データを扱う環境で、サーバーサイドの技術を深めることができたのはよかったと感じています。また開発リーダーも経験させてもらいチームビルドやマネジメントの難しさも触れることができました。ーー東急URBAN HACKSへのジョインの決め手を教えてください。まずは、リアルに近いビジネスであることが第一でした。その点、東急は鉄道やバスといったインフラを持っているので、世の中に大きなインパクトを与えられそうだと感じましたね。私自身も東急沿線に住んでいるので、自分の生活を取り巻くなにかをつくることに面白みを感じました。また、日本の大企業においてDXに成功した事例はそれほど多くありません。もし自分たちの手でDXを推し進めることができれば、やりがいがありそうだと感じましたね。ーー東急で働いてみて、ギャップはありましたか？元々課題がたくさんあることについては聞いていました。それについて驚きはなかったのですが、意外だったのが、フロントエンドエンジニアやデザイナー、プロダクトマネージャーが一緒になって解決していく、アジャイル開発の体制ができていること。面接した時点では、まだチームと呼べるものすらなかったので、すでに組織づくりが進んでいることは驚きでしたね。また、マネージャー職を用意しないよりフラットな組織を目指す取り組みも行われています。実際に、上司といった役職を設けるのではなく、評価体系からみんなで制度設計をしていく取り組みが始まっています。評価体系を作ったり真面目に考えたことがない自分にとっては新鮮な取り組みです。マネジメント業務を分散することで、エンジニアがコーディングを主軸に置けるような環境にしていけたらなと思い活動しています。ーー東急でエンジニアとして働く魅力はどのようなところがありますか？課題が複雑で、何をつくれば正解かを考えるところから始められることです。これまでの仕事では、課題自体ははっきりしていて、これを解決すれば成果が出るだろうという明確な予想ができましたが、東急ではそうはいきません。この経験は課題解決が好きな自分にとって新鮮でワクワクしますね。かつ、スケールも非常に大きいです。各Webサービス/アプリをつなげて、最終的にプラットフォームをつくり、ユーザーに浸透させることがゴール。故に、非常に難しい挑戦であると思いますが、できたときの達成感は、ほかでは得られないほど大きいと思います。

東急カードアプリのリニューアル開発の裏側

東急カードアプリチームのインタビュー ※写真はオフィスである「WeWork 渋谷スクランブルスクエア」

―今回、皆さんが手掛けたプロダクトはどのようなものですか？田中：今回は東急カードアプリのリニューアル開発を手掛けました。東急カードは、多くの東急沿線住民の方々にご支持いただいていますので、特に沿線ユーザーの生活をより豊かにすることをプロダクトの中心的な目的に置いています。基本的な機能は、既存のお客さまがポイントやクレジットカードの明細を確認することですが、今後、将来的に東急沿線に住むかもしれない人や、便利なデジタルサービスを使いこなしている半歩先を行くようなお客さまにも選ばれるサービスを開発するための土台となるようなアプリを目指しました。 ―開発体制やスケジュールはどのような形で進めましたか？野口：プロダクトをリリースしたのは7月19日で、開発がスタートしたのは2022年2月頃でした。ざっくりとしたスケジュールとしては、2月に私たち新メンバー（野口・上野・松田を含む5名）がジョインし、内部的なキックオフとチームビルディングを実施。3～4月頃から順次開発を進め、7月のリリースに間に合わせた形です。現在では、アプリエンジニアが2名、バックエンドエンジニアが2名、デザイナーが2名、プロダクトマネージャーが3名の9名体制となっており、さらなる機能の提供に向けて、現在も開発を続けています。 ―どのような開発プロセスだったのか、印象に残っているエピソードはありますか？松田：デザインに関しては、SlackのハドルやZoomを通してほかのメンバーとこまめにコミュニケーションを取り、アイデア出しをしてもらいながら進めました。ディスカッションをベースにその場で簡単にデザインを起こし、共通認識を高めた上で具体的なUXを設計する流れが多かったですね。Slack上で毎日進捗も共有してフィードバックを募り、チームの納得感を大切にしながら開発を進められたと感じています。 PdMともコミュニケーションの齟齬が出ないよう、2日に1回30分程度時間を取り、「デザインよもやまミーティング」という形で進捗共有や方向性の確認を行ったりもしていました。野口：デザイナーの方が、フロントエンドやサーバーサイドにもコンセプト段階から意見を聞いてくれたことで、技術的に難しい部分などポイントを押さえながらデザインを詰めていけたのは良かったです。「しっかりしたミーティングのようになってしまうから」という理由で、途中からチーム内ではZoomはやめてSlackのハドルだけを使うようにしましたよね。「ちょっといい？」と気軽に声をかけて話せるように工夫しました。上野：出社したタイミングで密にコミュニケーションを取って、その場でぱっとデザインを試作するような動きが出来たのも印象に残っています。また、フロントエンドはどうしても実装段階で問題が出てきて、デザインに変更が必要になるケースがあるのですが、そんなときも柔軟に受け入れてくれる雰囲気があり、非常にやりやすかったです。逆にフロント側の細かい部分については、先に動きを作って確認してもらう場面もあったりして。とにかく柔軟性高く開発ができたからこそ、良いものに仕上がった手応えがあります。田中：こうした柔軟な動きを実現するため、どんなチーム体制を組むべきなのかを、社内外に対して繰り返し説明してきました。お客様に最大限の価値を届けるために、事業部のメンバーを含むチームが迅速かつ適切に議論し、意思決定が出来る環境を意識して作ってきた感じですね。