- 印刷SCMオペレーション
- Web Director
- コーポレートエンジニア
- Other occupations (45)
- Development
- Business
- Other
これまでのキャリア(ラクスル入社前)
社会人キャリアのスタートは、プロダクトマネージャーではなくエンジニアなのですが、その原点は高校時代の文理選択に遡ります。
僕は小学校時代から野球を続けていて、高校は甲子園を目指す強豪だったのですが、残念ながらレギュラー争いに敗れてしまいました。
高校3年になる前に文系か理系を選択するタイミングがあるのですが、野球部は文系を選択する人がほとんど。僕自身も当初は文系選択を考えたのですが、「普通になりたくない」という想いから敢えて理系を選択、文理融合で技術に重きを置く慶応SFCに進学しました。
学生時代は実務に近いグループワークを多く経験しました。そのなかで大学3年生の時にベンチャー企業のインターンでエンジニアとして働き、当時iモード全盛だったのでフィーチャーフォンのアプリをガムシャラに開発。学生ベンチャーのような取り組みをしていることが楽しく、大学院にも進んでプロのエンジニアのもとで開発に没頭する日々を送りました。
就活ではいわゆる文系人気業種も検討しましたが、活動のなかで自分は理系が性に合うのだと確信。もう一回、エンタープライズの領域でエンジニアとしての基礎を磨こうと決意し、IBMに入社しました。
IBMでは学生時代の経験が生き、高い技術力が求められる共通基盤やフレームワークの開発を入社当時から担当、数年後には、その当時個人的に盛り上がっていたSPA(Single Page Application)での開発を実現するために、自作のJavaScriptフレームワークを持ち込んで、アーキテクトとしてシステム全体のグランドデザインを担当する機会をもらいました。
皆がWeb画面はJSP(Java Server Pages)でつくるのが当たり前のときに、全部プレーンなHTML、CSS、JavaScriptで作ろうとしたんです。
普通、アーキテクトは「設計を作った後はよろしく」とバトンタッチすればよいのですが、自分の作ったアーキテクチャできちんとよいものを作ってほしいという想いから、実質的には今のベンチャーでのテックリードに近い立場で仕事をしていました。 実際に同じチームのエンジニアに「このライブラリは見ておいたほうがよいよ」といったアドバイスをしたりなど、技術的な指導も担当するほか、プロジェクトの進捗が悪くなった時には、自分自身がプロジェクト・マネジャーとしての役割を果たしながら、課題を特定・解決して案件を前進させるというシーンもありました。
今思えば、これがプロダクトマネージャーとしてのキャリアの始まりだったのかもしれません。
その後縁あってDeNAに入社、ゲーム開発会社の技術的支援をする部門の立ち上げを担当したのち、Mobageの開発部門でプロダクトマネージャーをすることになりました。
「プロダクトを1年後にはこうしていようね」というプロダクトとしてのビジョンを描いて皆に説明することから、組織づくり、メンタリングなど多くを経験、最終的には20人くらいのチームを率いる立場となりました。
転職を決めた理由(ラクスルに入社した理由)
2014年の終わりごろ、当時かかげていたMobageのアプリシフトの戦略が実質的には難しくなってしまい個人としては撤退を決断。そこで一旦転職も考えたのですが、当時成長していた子会社で、開発責任者という立場からUXやデザインを含めたプロダクトの方向性を決めつつ、チームマネジメントをするという役割を担いました。
その経験などから、文系と理系が合わさったようなプロダクトマネジャーという職種が、自分に合っているなとさらに実感するようになり、この職種での経験をもっと積んでいきたいと考えるようになりました。
そんな中、知人経由で声をかけてもらったのがラクスルです。
元々スタートアップに興味がありいくつか会社を調べていたのですが、資金調達・事業モデル・経営メンバーなど、個人的に最も注目している企業の1つでした。
また、前職でtoCサービスに長く従事していたことからの揺り戻しもありました。
時間軸の長さや商習慣や産業構造に立ち向かう難しさ、ベースはロジカルだけど一筋縄ではいかない・・・toBのサービスにはそんな面白さがありますよね。
CTOの泉から聞かされた、技術負債の話も「面白いな」と思いました。
技術負債と聞いて反応は人それぞれだと思うんですけど、僕はカオスを浄化していくことにやりがいを感じるタイプみたいで、僕のキャリア=負債やカオスとの戦いといっても過言じゃないかもしれないですね(笑)。もちろん0→1的な新しいものを生み出すことも面白いとは思うんですが、-1を変えていく・こんがらかったものをほぐす作業って知的に面白いし、そこから+の成果を生み出していくいくことに意義を感じるんです。
プロダクトマネージャーとして上記の技術負債だけでなく、ユーザーが抱える負の解決も担っていきたい、そんな使命感をもって入社したのがちょうど2年前くらいです。
ラクスル株式会社について
CEOの松本をはじめ、非常にB2Bらしくロジカルで優秀な人間ばかり。かつ芯のある人が集まった会社だなと感じていて、ここまでの急成長も納得です。そのなかでいわゆる「ものづくりの精神」を伝えることを強く意識していて、少しずつ変わってきたなと最近感じています。
実は、僕が入社して間もないころは、クオリティが不完全なままプロダクトをリリースしてしまい、問い合わせに追われたカスタマーサポートの現場が疲弊してしまうことが頻発していたのですが、
カスタマーサポート・開発・ビジネスといったプロダクトに携わる人々が率直に意見を交わせる場を設定し、コミュニケーションを促進したことで、「お客様の役に立ちたい」「お客様の課題を解決したい」そんな目的意識を全員が持ってプロダクトをリリースすることができるようになったと思います。
ラクスルスタイルにちなんでこの一連の動きを「co-operation=互助連携」と社内で呼んでいるのですが、この会社に入って最も印象深かったことの1つですね。
開発メンバーの特徴は、、、優秀なんですがみんなカッコつけないし、技術にとがりすぎない。問題/課題解決型の思考の人が多く、技術負債に対してもみんな前向きです。
先日開催したHack Weekでも業界や社内オペレーションの課題にチャレンジするメンバーが多かったですね。採用面接にも入っているんですが、ビジョンや事業に共感している人が多く入社してくれているなあ、と日々感じています。
現在の仕事
現在はラクスル事業のプロダクトオーナーとして、印刷のEC体験を日本でナンバー1にしようというビジョンを持っています。
知人などから「ラクスル使いやすいね!」という言葉を時よりもらうんですが、その言葉には実は違和感があって、まだまだユーザーの負を解決できてないなと日々感じています。
1年前くらいにメイン導線であるマイページや会員登録をリビルド(※)の一環で触ったのですが、裏側の改修だけでなく思い切ってUX改善にもチャレンジするなど、ユーザーがより「ラクスル」を利用してくれるように努力を続けています。
ラクスルは、ECの中でもマスカスタマイゼーションECという分野に位置づけられます。既成品である商品をただ配送するのではなく、いろんなカスタムのオプションがあるものをワンストップで受けて、大量生産しつつお客様毎に異なる商品届けるというECになります。他の例だと新車の受注生産などが、マスカスタマイゼーションに近いイメージです。新車は大量生産しつついろんなオプションがありますからね。
当然これは、裏側で様々な印刷工場との連携があるので、非常に複雑な設計が求められます。海外ではこれが結構進んでいるんので、まずは日本国内でもっとも優れた体験を実現したいと思っています。
※リビルドとは
水島が責任者を務める「Raksul Platform Project」の通称
・技術負債と思われている部分を根本的に解消して開発しやすい状態にする(エンジニアを幸せに)
・システムに柔軟性を持たせて経営戦略の選択肢が増えている状態にする(経営を幸せに)
の2つをテーマにラクスル全体を再構築するプロジェクト
>詳しくはTech blog「そうだ、ラクスルを作り直そう!」(https://tech.raksul.com/2017/12/18/raksul-platform-project/)をご覧ください。
今後どういうことをしていきたいか
急拡大・急成長する事業と組織の中で、プロダクトオーナーとして取り組んでいきたいことは大きく2つあります。
1つ目は強いチームをつくること。
強いプロダクトは、強いチームからしか生まれません。メンバーの育成はもちろんですが、オーナーがすべて決定する組織ではなく、それぞれが主体性をもって考え、意思決定できる、自立した組織を作っていきたいと考えています。
2つ目は、最近よく言っていることで燃費のよいプロダクトをつくること。
燃費がよいという言葉は主に少ない燃料でよく走る車を指すと思うんですが、少ない工数で大きな成果を上げたり、「これはいける」と大きな投資に踏み切れるようなプロダクトを作っていきたいと考えています。そのためには、構想や設計段階からマーケティングや顧客の行動、業界課題の理解が不可欠になってきます。
また技術的な話をすると、なるべくプロダクトを分割してそれぞれでPDCAを回して進化できるようにしておきたいです。同じ身体に脳みそや腕足がいくつもあったら機能不全になりますよね?そうならないよう連係しつつも独立した仕組みであることが重要です。
自身のキャリアという観点だと、自身現場のエンジニアマネージャーとかプロダクトオーナーとして、”執行”することは一定できるようになってきたので、更に上の経営のメンバーとしてどういうバリューを出せるのかということが、今後のチャレンジですね。