エンジニアが事業成長にコミットした役割から学んだ3つのこと

こんにちは。ホワイトプラスで、ネット宅配クリーニング「リネット」の受注管理システムの刷新に取り組んでいる、エンジニアの仲見川(なかみがわ)です。(上の写真左です)

現在は体制が異なりますが、過去に複数サービスの専任エンジニアとして、【一人で開発】していた時期があり、今回はその経験から学んだことをご紹介できればと思います。

▼目次
・結論:学んだ3つのこと
・前提:どんな体制で開発をしていたのか
・小さい事業運営チームにエンジニアがどっぷりと入るメリット
  - 事業として、より正しい判断に繋げることができる
  - 事業としての優先度を自分で考えられるようになる
  - エンジニアとして、事業部の本当の期待に応えることに繋がる
・「リネットのお客様が必要とするものは何か?」を追求し、攻めの開発で価値を届けたい

結論:学んだ3つのこと

色々と書きましたが、事業成長にコミットする役割で学んだことは次の3点です。

・事業として、より正しい判断に繋げることができる
・事業としての優先度を自分で考えられるようになる
・エンジニアとして、事業部の本当の期待に応えることに繋がる

どんな体制・役割で、どんな経験をしてこれらを学んだのか。
具体的に見ていければと思います。

どんな体制で開発をしていたのか

現在

リネットは「衣類」のほか、取扱商品によりPREMIUM CLOAK(保管)ふとんくつと4つのサービスに分かれます。社内ではマーケティング部と生産開発部の2つの部署に分かれて運営をしています。

マーケティング部は名前の通りマーケティングやCS等の販売に関わる仕事、生産開発部はLC(Lenet Care Center:リネット独自のシステムと品質基準を満たす、提携先のクリーニング施設)のクリーニング品質や生産量に関わる仕事をしています。

エンジニアはシステム開発Gとして独立した組織となっていますがマーケティング部、生産開発部それぞれに「部付き」という形でアサインされ、それぞれの部署からの依頼を元に開発を行っています。

私は現在マーケティング部付きのエンジニアとしてランディングページや申込フォームなど実際にクリーニングを利用されるお客様が見ることになるシステムの開発に関わっています。

このように、現在は販売と生産という軸でチームが分かれていてエンジニアもそれぞれの部に専任でアサインされています。これは事業運営においてどの観点でだれが責任を持つのかを明瞭にし、実行するリソースを効率的に運用できるようにという意図です。

過去(今回のお話の時期)

この体制になる以前は、プロダクトオーナーと呼ばれる事業責任者のもと、チームを組成する体制=「プロダクトオーナー制(PO制)」で、「衣類」「PREMIUM CLOAK(保管)」「ふとん、くつ」という4サービス3チームでの体制で運営をしていました。

POを中心としたチームそれぞれにリソースを振り分けているため販売だけをとっても「衣類の販売」「保管の販売」「ふとん、くつの販売」と同様の業務に対してチームが分かれていました。エンジニアについても同様で「衣類のエンジニア」「保管のエンジニア」「ふとん、くつのエンジニア」とそれぞれ分かれて開発を行っていました。

こう見ると無駄が多いと感じるかもしれませんが、スモールチームでチームのみんなが1つのサービスに集中していたので得るものが多かったと思います。前置きが長くなってしまいましたが、ようやく何を得ることができたのかについてご紹介します。

小さい事業運営チームにエンジニアがどっぷりと入るメリット

当時チームをいっしょに組んでいた、事業責任者だった魚森(写真右)と。
データを見ながら、「このときはあんな大変なこともあったね笑」と苦笑い。

事業として、より正しい判断に繋げることができる

CVRが落ちれば原因を探るために、GoogleAnalyticsやHotjarで原因を探し、改善点を探したり、クリーニングという商品の特徴として気温に強く影響を受けるので、気温の長期トレンドを可視化してみるなど、エンジニアという役割に閉じない働き方がありました。

これらの分析と言うような情報処理というのはエンジニアが得意な領域であり、事業運営にどっぷり入っていることによって、その時に必要なデータを素早くまとめることができました。

この経験からデータ抽出依頼を受けた際に背景となる情報をエンジニアが持っていると依頼者が見落とした観点をフォローでき、より正しい判断に繋げられるようになったと感じています。

事業としての優先度を自分で考えられるようになる

いくら良いアイディアがあったとしても担当エンジニアは私1人。
そして私の体は1つしかありません。

ふとん、くつのクリーニングにも繁忙期という旬があります。
リソースという制約事項の中でいかに事業を伸ばすか、お客様に直接不利益があるような不具合についてはもちろん何よりも優先して対応が必要です。

しかし、運用で回避できるものやお客様にとって不利益のない軽微な不具合など後回しにしたりという判断をします。技術的負債の返済を諦めるどころか積み上げることもあります。つまり、このタイミングでは技術的負債の返済をしない、成長を優先するという決断をするということです。

わたしたちの事業運営で優先すべきものは何なのかという事が、事業にコミットする事で見えて来ました。ともすればエンジニアは技術的負債というものに過剰に反応してしまいがちですが、技術的には負債でも事業が伸びることの重要さを考えられるようになりました。(もちろんバランスが大事です)

エンジニアが経営数値にコミットしたという経験が、事業部の期待に応えることに繋がる

チームで次年度どのように事業を伸ばしていくのかディスカッションして、様々な施策アイディアを元にPO(プロダクトオーナー=事業責任者)が売上目標を設定します。

また売上目標を達成するためにはクリーニングの注文件数や注文1件あたりの単価、1件の注文あたりのクリーニングするお洋服の数(※)、新規のお客様・リピートのお客様など要素分解もしながら、目標設定をします。(※社内では生産点数と呼んでいます。例えば、お客様が1回のクリーニングでYシャツ3枚、ニット1着、コート1着を出したら、生産点数は5点となります)

これらの目標設定プロセスに携わることで、
数値に対する意識が変わってきます。

3年後の目標の為に次年度どうなっていなければいけないのか。

しっかりと理解することで、やるべきことが見えてきます。

目標を達成するためには、クリーニングできる数自体を増やす必要があり、新しいLC(Lenet Care Center:リネット独自のシステムと品質基準を満たす、提携先のクリーニング施設)が必要だと判断した際には、LCの新設にも関わり、必要な機能を即日開発して新しいLCが稼働できるようにし、クリーニングできる数を増やす経験をしたこともあります。

このような経験を経て、その開発がない事や開発が遅れることで、2年〜3年先の事業インパクトがどのくらいなのかを自分で考えられることで、本当の意味で、事業部の期待に応えられるエンジニアになれたのではないかと思います。

「リネットのお客様が必要とするものは何か?」を追求し、攻めの開発で価値を届けたい

現在は受注管理システムの刷新というリネットの次の成長に必要となる重要な開発をしています。要件定義からがっつりと入っているため事業的な意義、パートナーとの関係性、現場で求められるシステムのクオリティなどを自分で考えて、事業側へフィードバックしています。

これは、先ほどご紹介した経験から「言われたとおりのアウトプット」ではなく「事業側の思った通りのアウトプット」、つまりは「お客様視点のアウトプット」になるようにという事を考えて実践してるからです。

リネットはこれからもどんどん成長していく計画です。
その中で「リネットのお客様が必要とするものは何か?」を忘れずに、受け身ではなく攻めの開発、提案をしていき、顧客に価値を届けることでその成長に貢献して行きたいと思っています。

ただし、まだ現状のエンジニアチームは、人が足りていません。
エンジニアを積極募集中なので、もっと詳しい話が聞きたいなどあれば、詳細は下記をぜひご覧ください。まずはお気軽にお話ししましょう。

ホワプラで働くエンジニアの話を聞いてみたい方はこちら。

仲見川 勝人(なかみがわ かつと)
情報系専門学校卒業後。エンジニアとしてSI、SES、社内SEなどのキャリアを経て2016年4月ホワイトプラス入社。現在はマーケティング部付きエンジニアとして活躍中。趣味は映画鑑賞、ゲーム(FF14)、プログラミング。好きな食べ物はソーセージ(ドイツに旅行に行くほど笑)

記事をシェアする