プロダクト開発は、
徹底した現場理解と的確な課題設定
overflow 大谷旅人（以下、大谷）：まずは、御社ではどのような”仕組み”で開発を進めているのか教えてください。
ラクスル 泉 雄介氏（以下、泉氏）：チームの構成はプロダクトマネージャー、エンジニア、デザイナー、ビジネスメンバーと、さまざまな職種を巻き込んだメンバーになっています。座席もエンジニアだけではなく、チームごとに固まっています。
そういったチーム編成の中で、物流でも印刷でもそうですが、ユーザーに不便なく使ってもらうためにはどうすれば良いかという観点から、日々ディスカッションしています。
ディスカッションをより活発に進めるために「かんばんボード」など、アナログな手法を用いることもしばしばありますよ。
大谷：その流れの中、随所で泉さんが指示することもあるのでしょうか？
泉氏：いえ、各チームは主体的に動いているので、経営陣がトップダウンで指示を出すことはありません。現場がサービスのディテールを一番分かってますし、積極的にユーザーの課題をつかんでいるので、私はあまり口を出さないようにしています。
オフィス内を泉氏に案内いただき、メンバーと談笑する大谷（写真右）
大谷：事業領域によって難易度や進め方は違うと思いますが、プロトタイプを作るまでのフローをお聞かせいただけますか？
泉氏：まずは『課題設定』がファーストステップとして大事だと思ってます。
今ですと、弊社のテレビCM制作サービス（※1）のチームがまさにそうなのですが、クライアントがテレビCMを制作する際はどんな意思決定があるのか、誰が関わってるのかなど、実際にチームメンバーがヒアリングに出向き、かなり細かいところまで見るようにしています。
（※1）テレビCMの制作+放映が50万円から | ラクスルのテレビCM
そこからクライアント側の課題を明確にし、その課題をデジタルで解決できるかどうかを徹底的に考えることから始まります。
具体的には、そこに対して仮説を立て、仮説通りに解決できているのかを検証する、ということをひたすら考えています。仮説検証の回数が少なければ少ないほど効率はいいものの、もっと仮説を分解できないかといった精度をあげることも考えて、モノづくりをしていますね。
大谷：仮説を立てるためのヒアリングは定期的に行われているのでしょうか？
泉氏：定期的ではなく、どちらかというと必要ベースでという感じですね。私は物流のチームに入っていましたが、物流のことを何も知らなかったので、プロダクトのことも考えつつ物流の現場にできるだけ足を運ぶようにしていました。
大谷：泉さんも現場に足を運んでいたのですね！
泉氏：もちろんです。物流倉庫へ行き、普段の業務を拝見させていただきました。物流倉庫ではどんな電話がかかってきてどのような会話をしているのか、扱ってる商材の大きさや重さ、働いてる方の男女比など、実際に見学させていただくことで多くのことが分かります。
とにかくその現場に行って、見ること・知ること・感じることを大事にしていました。
大谷：なるほど。会議室で一日中考えても、そのような現場感は得られませんからね。
泉氏：他にもトラックの配送スケジュールを管理する「配車表」というものがあるんですけど、ある物流倉庫ではホワイトボードに書いて管理してたんです。今の時代に、スプレッドシートやエクセルでの管理ではないことに驚きましたよ。
あとは、ドライバーが出社したら息を吹きかけて、アルコールが入っていないかをチェックするアルコール検査機があるのですが、そのデータって検査機がつながってる1台のPCにしか蓄積されてなかったりとか、実際に現地に行かないと分からないことだらけでした。
大谷：IT業界では当たり前なことも、まだまだ他の業界では珍しいことなのかもしれないですね。
泉氏：そうですね、こうした現場観察を繰り返し、社内に持って帰って、課題解決のためにどういうソリューションが考えられるかをみんなでディスカッションします。このときのメンバーは、エンジニアだけでなく、ビジネスメンバーやデザイナーもいます。
大谷：現場でリアルな情報を収集して課題を抽出、解決法を検討。その後、プロトタイプ作りに入っていくんですね。
泉氏：そうです。
大谷：このディスカッションではどこまで作るのでしょうか？
泉氏：デザインまで落としますね。ワイヤーを書いて、それをまた検証していきます。配車を管理するプロダクトを作ったときは、UIデザインした画面を現場の方にお渡して、事前に何も説明せず、そのデザインした画面をどう動かすかなど、検証と改善を繰り返していきました。
強烈な反省が、
組織のあるべき姿を映し出す
大谷：モノづくりにおいて、組織として取り組んでいることを教えてください。
泉氏：まず、私がラクスルに入社した2015年ぐらいの話なのですが、もともと運用も新規開発もそこまで整理されていない状態でした。
何かトラブルが発生し、「エンジニアの誰か助けて」ってキーワードがSlackに書き込まれると、エンジニアがランダムでアサインされて、今やってることの手を止めて対応しなきゃいけないっていうルールがあって（笑）
さすがにこれはやばいと思って、まずはサポートデスクの役割を担うチームを組織しました。その次に、差し込みの案件や計画と非計画の案件などの工数を、可視化できるようにしました。
大谷：なるほど、以前はかなりしびれる環境だったんですね......。
泉氏：現在は具体的に誰がどれぐらいの工数をどこに当てているのか、細かく見ることができるようになっています。
データマイニング（※2）でプロジェクトに対しての費用対効果が分かるようにもなったので、効果に対して評価ができるようになりました。もちろん費用対効果だけでは測れない要素は多くありますが、1つの見方として色々な気づきがあります。
（※2）データマイニング: 大量のデータの中から統計的手法を用いて分析し、役に立つ知見や知識、パターンを発見すること。代表的な統計手法としては、回帰分析、主成分分析などがある。
大谷：開発体制が整ってない状態からここまできたわけですね。現在の状態になるまで、どんなステップを経てきたのでしょうか？
泉氏：私がラクスルに入社した当時も、今とは異なる方法ですが、工数や見積もりは管理されていました。しかし、それが効果のあるアウトプットには結びついていなくて、メンバーが疲弊しているような状態でした。
そういうプロジェクトが3つも4つもあって「これはどうにかしなければいけない」と思ってました。そのときの改善施策はわりと短期的な施策だけに偏っていたので、中長期で確実な効果を狙っていく必要があると考えていました。
経営陣で「ソフトウェアを開発することは安くない。短期的な施策ばかりしていて効果がでないのであれば無駄になるし、事業的にもマイナスになる。何よりエンジニアもデザイナーも疲弊してしまう」という認識を改めて擦り合わせたのがこのタイミングでしたね。
だから課題をちゃんとフォーカスして、そこに対しての解決を着実に行う。そこでは検証もしつつ、なるべく細かくマイルストーンを引いて進める、というようなことを全社的にやり始めたんです。
アプリを作ったものの上手くいかなかったり、それまでかなり様々なプロダクトの失敗があったので、強烈な反省をしたんです。それが2017年1月ぐらいですね。
理想を掲げるよりも、
目の前の失敗を直視する
大谷：課題にフォーカスしていく姿勢は、冒頭のお話を伺っている中で組織内にかなり浸透していると感じました。そのような組織改革の意識付けは一朝一夕ではなかなか難しいとも感じています。
組織に浸透させるにあたり、泉さんはどのように進めていったのでしょうか。
泉氏：「失敗から学ぶ」という考え方を大事にし、それをメンバーと共有していることです。もちろん「こうしていこう！」と発信することもしていますが「こういう失敗があったから、次はこうしていこう」っていうことが一番腹落ちすると思うんです。
ラクスルには行動指針（Reality・System・Cooperation）（※3）があって、それは過去の失敗の教訓から生まれた言葉なんです。壮大な理想を掲げるよりも、失敗を直視した結果から生まれた強いメッセージとして掲げています。
（※3）Reality・System・Cooperation：「Reality」は事業に関する解像度を上げて、もっとリアルを深くミクロに見ていくこと。「System」は仕組み化。属人化せず、誰でもできるように、物事の仕組みを変えていくこと。「Cooperation」は互助連携。メンバーがしっかりと連携しないと、最終的なユーザー満足にはならない。この3つを体現することが、ラクスルのビジョンの実現につながる。
大谷：育成や評価軸についてはいかがですか？
泉氏：ちょうど今、メンバーが増えてきたので、評価や育成を担うマネジメントレイヤーと認識を統一させるためのドキュメントを用意しているところです。
これまでは自分が「こういう風な価値観で組織を作っていきたいんだ」という話をしてきましたが、組織の拡大に伴い、私一人だけからの発信では限界が見えてきました。全てのマネジメントレイヤーが私と同じような目線で、各メンバーに組織のあり方や評価方法などの認識を統一していくことが今後は求められていきます。
また、マネジメント基準やそもそも採用時にどういうところを軸にするかという目線だったり、育成に関してどういうメッセージを発信していくのか、ということも作っています。マネージャーが変わったら全然違うことを発信するのは良くないと思うので。
大谷：基準を作って、大事にしたい価値観を言語化して、それをみんなで共有するのを進めているところなのですね。ちなみに現在はどのように評価をしているのですか？
泉氏：ラクスルの評価は成果と能力に分かれているので、能力はプロダクト側のエンジニアリングマネージャーが見てます。
大谷：グレードを作って評価をしているのでしょうか？
泉氏：そうです。評価軸やグレードごとに求められるものが変わってくるという運用です。
1つのグレードに対してプロダクト、技術、組織貢献という3つのクラスタを作り、その中に細かい評価軸があります。
ちなみに私はこの全てを記憶しています。自分が説明できないことってメンバーにとってもわからないと思うので（笑）
大谷：これもCTOに就任されてから作られたのですか？
泉氏：ラクスルに来て、わりと早い段階でやり始めたんですよね。そのときの評価軸がよく分からなくて。私がよく分かっていないものをメンバーが理解することなんて絶対にあり得ないですからね。自分がそれまでに思ってた「エンジニアが大事にしたいこと」を言語化して、それを一人一人に説明したって感じです。
大谷：私もCTOとして自社の評価軸を作らなきゃいけないのですが、あまり得意じゃないんですよね。
泉氏：得意な人にやってもらうのがいいんじゃないですか。私の場合、こういうのを作るのが好きなのでやったけど、好きじゃなかったら絶対にやってないと思います（笑）
ハッカソンのゴールは、
やるからにはリアルな課題を直視して解決すること
大谷：御社では社内イベントとして、1週間丸々使ってハッカソンを開催していると思うのですが、いつぐらいから取り組んでいるのでしょうか？ かなりユニークな取り組みだと思います。
泉氏：ハッカソンは元々月1で「ハックデー」というのをやってたんです。ただ、あまり参加率が上がらなかったということと、1日では濃い内容にならないという課題がありました。そうしたら、1週間ぶっ続けてやったほうが成果が出るんじゃないかっていう意見が出て、現在に至る感じです。
大谷：参加するエンジニアはそれに向けてどのような準備をするのでしょうか。
泉氏：ハッカソンの運営チームがコアメンバーで組成されて、コミュニケーションや段取りを組んで進めています。それは彼らの目標設定に明確に入れて、その運営をやりきるってゴールを定めて評価もしています。
大谷：ハッカソンはお祭り的なイベントなのでしょうか？
泉氏：どうなんでしょう、開発は黙々とやってますが、みんな普段以上の熱量で開発していますね。一部メンバーは、「こんなに残業したのは初めて」と言うぐらいです（笑）
大谷：黙々とできるのってエンジニアにとっては一番楽しい時間なので、それが定期的に開かれるのはすごくいい文化だなと思います。ハッカソンを開いてから組織的に変わったことはあるのでしょうか？
泉氏：プロセスという意味ではそんなに変わらないと思っています。一方で、例えばAIのようなラクスルでは実用的な課題解決ではやったことがない開発に取り組んでいるチームもあり、今まで自社になかった知見が蓄積されている手応えはありますね！
ちなみにハッカソンは作りたいから作るのではなくて、リアルな課題を直視して解決をすることがゴールだと思っています。それはハックデーの頃からの変わらない指針です。
大谷：ハッカソンで作られたものが実際のサービスに取り込まれたことはあるのでしょうか。
泉氏：ありますよ。はじめはエンジニア主導で進めていきますが、その後継続して検討するプロダクトについてはビジネスメンバーをアサインし、ビジネスとしても本気で解像度をあげて取り組んでいきます。
大谷：ある程度の規模の組織になると、メンバー間でハッカソンの参加に対する温度差が出てくると思います。ラクスルはいかがでしょうか？
泉氏：全員燃えてる感じがしますね！
もちろんこれだけではないかもしれませんが、デザイナーを入れたり、ビジネスメンバーの現状課題をヒアリングしたりと、全社で取り組むことでオフィシャルイベント感の醸成ができたことは大きかったように思いますね。
社内にハッカソンのシールやポスターが貼られてるんですけど、こういう取り組みがあるだけでオフィシャルな感じがするじゃないですか（笑）
他にもSlackで声がけして盛り上げたり、投票も全社を巻き込んだりなど、その辺りも良かったのかなと思います。
副業のメリットを活かし、
自社サービスのさらなるグロースに挑む
大谷：では最後の質問です。副業を推奨している会社が増えていますが、御社の副業に対するスタンスをお聞かせください。
泉氏：当社も副業は解禁していて、副業しているメンバーは多数います。正式な数字は取っていませんが、感覚的には半数弱ぐらいのメンバーが副業をしていると思います。
大谷：副業しているエンジニアを見ていて、メリットを感じますか？
泉氏：まだ分からない部分も多いというのが正直なところではあります。ただ、他社がどういう風にやっているのかとか、自社との違いを含め相対的に比較ができることは非常にプラスだと思いますね。
当社のエンジニアに求められる難易度は高いので、他社で新しい知識を身につけ、それをうまく自社に還元していくサイクルが確立できると良いですね！
大谷：なるほど。今後も御社のサービスがグロースしていくことを楽しみにしています！ 本日はありがとうございました。