【CTOインタビュー】いかに小さな失敗を繰り返すか。ものづくりで大切にすべき姿勢とは？ーーラクスル・泉雄介さん
印刷のニーズを持つ企業と、印刷機を効率的に稼働させたいと考える印刷会社をマッチングさせ、これまでにないクラウド型ネット印刷事業を形にしたラクスル。このビジネスモデルは運送業界にも展開され、ネット運送サービス「ハコベル」が生まれました。際立つ事業開発力で成長を続ける同社を支えるのが、ビジネスにコミットし続けるエンジニア集団の存在です。ラクスルのエンジニアは何を考え、何を大切にしているのか。取締役CTOの泉雄介さんにうかがいました。
目次
こまごまとした個別課題を、いかに技術で解決していくか
Q.ラクスルさんは独自のビジネスモデルや事業開発力が注目されています。この環境の中で、エンジニアはどのようなミッションを持って活動しているのでしょうか？
泉雄介さん（以下、泉）： 理想としては、お客さまのビジネス課題を理解し、それを技術で解決するところまでやるのがエンジニアだと考えています。
しかし現実には、大きなビジネス課題を考える前にこまかな諸問題に対応しなければいけないことも多々あります。例えば印刷物のニーズとして多いポスティング。もともとポスティングは納期が明確ではない部分があって、お客さまが希望する配布日通りに進まないこともあるんです。ピンポイントで日にちを指定できなかったり、地域によって日程がずれてしまったり。
そもそもチラシを配布する際には内容についての審査が必要です。チラシそのものができあがっていても、ポスティング会社がOKを出すかどうか分からないケースもあります。そうした個別課題を明らかにし、技術で解決していこうとする姿勢が求められます。
Q.求められる範囲が幅広いのですね。
泉： はい。とはいえ、ご承知の通りIT人材は世の中全体で不足しているという実情があります。心構えとして前述のような課題理解と解決を必ず意識してほしいという思いはありますが、一方でエンジニアには機能の実装や仕組みに落とし込むプロセスはエンジニアにしかできないので、そちらに集中してほしいというのも正直なところです。
その意味で、重要になるのが「プロダクトマネジャー」の役割だと思っています。プロダクトを仕上げるための意思決定、課題の優先順位決めや、ユーザーヒアリング、プロトタイピング、その他必要な段取りや、部署横断的な調整など、ソフトウェア開発に必要な非プログラミングのアクティビティも多くこなしてもらっています。技術的な投資をより確実なものにしていくために尽力してもらうイメージですね。
十分な段取りや調整ができていないと、エンジニアが正しいことをやっているのに価値のあるプロダクトが生まれないということになりかねません。
やりたいことは、常に「やれるキャパシティ」を凌駕しているもの
Q.プロダクトマネジャーが行うべき段取りや調整には、どのようなものがあるのでしょうか？
泉： エンジニアであればうなずける話だと思いますが、システムの専門家ではないお客さまは、「実際に必要かどうか分からない機能」も求めることがありますよね。それは本当に現場で活用される機能なのか？ 納期を延ばしてでも必要なのか？ そうしたことを妥協なく問いかけていくことが大切です。
例えば社内システムの開発で、管理者2名、使用者20名という場合。「管理者のユーザビリティを多少犠牲にしてでも、毎日システムを使う使用者のユーザビリティは妥協しない」といった優先順位が必然的に見えてくると思うのです。プロダクトマネジャーが持っておくべき大きな開発方針とも言えます。
こうした「優先順位づけ」が、受託開発にはないラクスルのエッセンスでしょう。やりたいことは、常に「やれるキャパシティ」を凌駕しているもの。その前提で物事を考えるのがプロダクトマネジャーのあるべき姿だと思います。
Q.優先順位づけは、対社外はもちろん、対社内でも重要なテーマとなるのでしょうか。
泉： そうですね。営業サイドで要件をふくらませてしまった結果、エンジニアに無理な納期が降ってきたり、実際には使われない機能を開発することになったりというのは「開発部門あるある」だと思います（笑）。
Q.いかにプロダクトマネジャーが重要な存在かということですね。ただ、求められる役割が大きければ大きいほど、「プロダクトマネジャーを担いたい」と考える人の絶対数が不足してしまうように思います。
泉： プロダクトマネジメントが必ずしも、プロダクトマネージャーがやらないといけない、というものでも無いとは思っています。
自分もものづくりが大好きなエンジニアなので「コーディングに集中したい」という気持ちある一方で、プロダクトマネジメントの機能がチームから欠けていることで、自分の作ったものが結果使われなかったり、プロダクト自体が無くなることは悲しい。それが「エンジニアにとっていちばんつらいこと」ではないでしょうか。そうしないためにも、エンジニアであってもそれができる人には積極的にプロダクトマネジメントの機能も担ってもらいたいです。
「Cheap Failure」という考え方。どうせ失敗するならまだ安いうちのほうがいい。
Q.「ラクスルのチームプレー」について、詳しく教えていただけますか？
泉： チームについては、コミュニケーションコストが少ないほうがいいので、プロジェクトを遂行するにあたって必要なスキルが集まっているのであれば、人数は少ない方が良いと思います。ソフトウェア開発に必要なスキルは、プロダクトマネージメント、プロジェクトマネージメント、UXデザイン、インタラクションデザイン、フロントエンジニアリング、サーバーサイドエンジニアリング、インフラ、場合によってはスマホアプリのエンジニアリング等多岐に渡ります。
ラクスルでは各チーム、多能多才なメンバーが集まってそれぞれがプロジェクトに貢献できるのであれば、自分の枠を超えて作業してもらうこともあります。時には役割を明確にすることもありますが、システム設計ができるプロダクトマネージャーもいますし、フロントエンドエンジニアがプロダクトの企画をすることもあります。デザインをするプロダクトマネージャーもいれば、サーバーサイドにトライするフロントエンジニアもいる。サーバーサイドエンジニアでありながらインフラも見るエンジニア。そうやって枠をはずしてより多くのことをこなせることがいわゆる「シニア」なメンバーとも言えるのかと思います。
Q.少人数のチームだからこそ役割分担も不明確になるということですね。
泉： はい。ただし、小さいほうがいいと言っても「1人」はダメです。デジタルサービスをやっている限りは、「プロダクト＝事業」。市場環境や消費者が変われば自分たちもどんどん変化していかなければいけません。長い間、昔のパッケージで勝負していけるなんてことはあり得ません。
その中ではさまざまなリスクにさらされます。セキュリティの脆弱性が見つかったり、人が変わったり、あるいは重要メンバーが事故に遭ったりしてしまうかもしれない。1人だけでやっているとこうした変化に対応できないし、その人しか知らない知識が増えれば、何かあったときに事業を継続できなくなってしまいます。
だから、最低の人数は確保しておかないといけない。現状の体制だと、プロダクトマネジャー1人、エンジニア2人が最小のチームですね。
Q.ラクスルのチームに合う人とは、どんなタイプの人でしょうか？
泉： 「人に会わずに済ませたい」「対人コミュニケーションを避けたい」というタイプの人はラクスルには向かないかもしれませんね。かなり密度の濃いチームを組み、エンジニアも積極的にコミュニケーションをしているので、あまり静かな環境ではありません（笑）。良いアイデアは、やはり人と人がアイディアをぶつけることで生まれると思っています。
良い設計をする人とそうでない人の行動の差を見ていて、気づいたことがあるんです。良い設計者は、まず1人で悩んでみて、足りない部分は周りに積極的に相談しながら知らない知見や視点を得て、解を見つけていきます。しかし悪い設計者は、1人で悩んで1人で解を出し、それを実装してしまう。
僕も良い設計者でありたいと思っています。なので何かを考え込んでいるときには、まずはめちゃくちゃでもいいからドキュメントを書いて社内チャットへ投げるようにしています。それでみんなから意見をもらったり、突っ込んでもらったり。ボコボコに言われることもありますが、自分が持っていなかった視点だったり、アイディアが出てきて結果的にどんどん良い方へ向かいます（笑）。
Q.1人で完璧な成果を出そうとしても、結果的にうまくいかないということですね。
泉： そういうことだと思います。みんなに投げかけるときは70点くらいでOKだと思います。結果的にあれこれ言われてしまったとしても、「Cheap Failure」の段階で、まだ実装が始まっていない段階、言い換えれば「安いうち」に失敗するほうがいい。作り込んでしまってから直すのはダメージが大きすぎますから。
そういう意味では、自分の不完全さをさらけ出せる人であることは重要だと思います。「助けてください」と周囲に言えるかどうか。
CTOの立場を気にせず、社内のエンジニアとペアプログラミングしてもらうことも
Q.これは職種に限らず難しいことかもしれません。特に技術職の場合、自らの能力不足を認めるのは勇気がいることだと思いますが……。
泉： プライドとか恥とか、障壁になるものはいろいろあるでしょうが、僕は「うぬぼれ」が大きな敵なんじゃないかと思っています。「俺、やれるよ」と思って最後まで作り上げたものが、リリースの後になって失敗に気づく。この「やれるよ」こそ、うぬぼれだと思うんです。
これは僕自身も気をつけていることです。先ほども少し言いましたが、今でもみんなにある意味ボコボコにされながら仕事をしているんですよ。「泉さん、これちょっと読みにくいです」とか言われて。それで、社内でイケているエンジニアにお願いして、1時間だけ一緒にペアプログラミングしてもらうんです。たった1時間でもちょっと頭下げてお願いすれば、学べることは非常に多い。
プロダクトをデザインするときも一緒だと思います。議論の中では「ユーザーはきっとこう思う」とか「ユーザーはきっとこの機能を便利だと思うに違いない」とか思いますが、本当のことは現場でユーザーを観察したりヒアリングして見ないとわからない。それを吸い上げるためには「自分はよくわかっていない。だから学ばせてもらおう」という謙虚さが必要なのかと思います。
Q.「失敗から学ぶこともある」ということですか？
泉： うーん……。あるとは思いますが、ビジネスの本番でそれだと、ちょっとコストが高いですよね。
すこし前に、中竹竜二さんという方からコーチングを受けていました。日本ラグビーフットボール協会のコーチングディレクターを務めている方です。そこで「良いコーチは失敗のデザインがうまい」という話を聞きました。プロスポーツにおける本番は試合です。失敗から学ぶというのは、試合に負けて学ぶというやり方ですよね。これがすべてダメとは言わないけれど、やはりコストが高いと思います。
中竹さんは「いかに練習の間に失敗させるか」ということを言っていました。ラグビーは、雨の中だと非常に難しいコンディションになります。だから普段からボールに石鹸をつけて、ツルツルにしてパスの練習をさせるコーチもいるそうです。はたから見ればクレイジーなやり方かもしれないけれど、大切なことだと思いました。
僕もメンバーには、なるべく早めに失敗してほしいと思っています。プロダクトチームにとっての本番は、機能を実装してリリースするとき。そこへ至る前にできるだけ早く小さな失敗を繰り返すべきだと思います。考えていることをどんどんアウトプットし、ドキュメントにして共有し、みんなからいろいろ指摘されることも失敗する一つの方法なのかと思います。
本番でリリースしてから気づくことに比べれば安いものだと思います。もちろん、本番に出してみて失敗してから学ぶこともたくさんあります。でもそれらも含めて失敗は小さくしておくに越したことはないと思います。
Q.泉さんがそうした考え方に至るまでには、これまでのキャリアも影響しているのですか？
泉： そうですね。僕は18年間エンジニアをやってきて、大小含め30以上のプロジェクトに関わってきました。独立して受託開発していたこともあります。でも、自分が関わったプロジェクトで今も稼働しているものって、実は4つくらいしか無いんじゃないかと思います。時間をかけて開発したのに、3カ月しか稼働しなかったゲームもあります。18年間開発を続けてきて、本当にたくさんの失敗をしてきたわけです。
今にしてみれば、この失敗体験から学んだのは、繰り返しになりますが「自分は何もわかっちゃいない。だから常に学ぶ」という謙虚さを持つことなのかと思います。エンジニアリングやプロダクトデザインにのめり込んでいけばいくほど、うぬぼれて「俺、ちょっとイケてるんじゃないか？」と感じるようになる。自分もそうでした（笑）。
でも、わかっていることは広い領域のほんの一部だし、全てを理解している人なんて存在しない。それに気づくことができたら、立場なんて気にせずにみんなに助けてもらう方が、何より自分らしくいられるし、よりよいアウトプットがだせると思うんです。その謙虚さ、そして幅広くなんでも受け入れるオープンさ、それこそがものづくりで大切な姿勢なのではないかと考えます。
僕はこれからも「Cheap Failure」の考え方を大切にしていきたいし、メンバーも肩の力を抜いてよいプロダクトがどんどん生まれるような環境を作っていきたいと思っています。
