クーリエism クーリエのヒトとビジョンを伝える

業界No.1メディア運用を支える屋台骨。事業の課題解決に挑み、成長にコミットするエンジニア組織とは。

2022年6月22日
サムネイル

今回は代表のヤスダと、エンジニアとして入社後にクーリエ開発組織の立ち上げに携わり、現在はクーリエ組織全体の戦略や採用を担当するスガイに話を聞きました。

これまでのプロダクト開発div.における取り組みや課題をはじめ、今後のプロダクト開発div.におけるビジョンまで聞いてみました。

ミッションを原点にした社会課題への挑戦

ヤスダ:「テクノロジーによって新しい価値を創造し、一人ひとりのより良い未来をつくる」というミッションを実現するため、主に介護領域においてサービスを展開しています。

大きな社会課題となっている介護や超高齢社会をテーマに、だからこそわかりやすく面白いコンテンツを発信し、メディアを通して社会をエンパワーメントさせたいと考えています。

スガイ:あらゆる企画からデザイン、開発、運用までを自社で一貫して行っています。当然「実装して終わり」ではなく、Webマーケティングの経過も絶えず計測し続け、高速でPDCAを回して日々サービスの改善を行っています。

ゼロから始まった開発組織の立ち上げ

-クーリエの特徴でもあるプロダクトの内製化が、ほんの数年前に立ち上げられたものだと聞いて驚きました。

ヤスダ:今では、掲載施設数トップの老人ホーム検索サイト「みんなの介護」や、介護求人サービス「みんなの介護求人」、介護従事者の利用がメインになっている「みんなの介護コミュニティ」、介護福祉士の国家試験対策アプリ「ケアスタディ」といった複数のサービスを展開していますが、プロダクト開発のインハウス化は、この4〜5年ほどで今の形まで成長してきました。

それ以前は、私がプロジェクトマネージャーを兼ねるような形で、業務委託のエンジニアとプロダクトの開発を進めてきましたが、そのような体制では本来、経営者がすべき仕事に集中するリソースが確保できず、長期的な事業成長を視野に入れてインハウス体制でのエンジニア採用をスタートすることにしました。

私自身は非エンジニアのため、最初のエンジニア採用には非常に苦労しました。そんな中、スガイをはじめとした数人のエンジニアを採用することができ、クーリエの開発組織は立ち上げられました。

開発体制のインハウス化とベンチャー企業でのエンジニア採用の難しさ

開発チームが10名を超えるのに非常に苦労されたらしいですね。

スガイ:私自身もエンジニアとして手を動かしながら、媒体に掲載する求人原稿を作成したり、スカウトリストを作成して送信、といった実務を行っていました。

特に最初はインハウス化=正社員だけで開発チームを構成しようと考えていたため、採用までに時間が掛かったり、経験やスキルは非常にいいのに、方向性が合わずに採用に至らないといったことが多々ありました。

またエンジニアの価値は非常に上がっており、どの企業も優秀なエンジニアを採用したいと考えているため、当時、全体で30名前後の規模だったクーリエでは、広報もあまり力を入れておらず認知度の低さと、他の大手やメガベンチャーといった企業と比較され、優秀なエンジニアを採用できない、といった課題も抱えていました。

現在は開発メンバーだけで30名を超えて、さらなる拡大を考えていると聞いてます。

スガイ:もちろん求人原稿や採用サイトのブラッシュアップをすることも大事ですが、何より大きかったのは、クーリエという会社が何を目指し人材に何を求めるのかを、再度設定しなおし可視化されたことでした。

ミッションである「テクノロジーによって新しい価値を創造し、一人ひとりのより良い未来をつくる」は、抽象度が高く、具体的に求められていることが把握しづらい状態でした。

そこで代表のヤスダと改めて、クーリエが目指すミッションを達成するためのビジョンや、一緒に働くメンバーに求めるバリューについて定義を見直しました。

ビジョンは「産業の再定義、新しい価値を創造する」。

ヤスダ:まずは普段、自分たちがどのようなことを意識してサービスの改善や、オペレーションの設計・運用をしているのか、自社のサービスで実現したい世界はどのようなものなのかを正しく伝わるようにするため言語化するところからはじめました。

超高齢社会によって介護市場が拡大していく市場の中で、仕組みさえしっかりと作ることができれば、事業として利益を生み出す産業構造を作れるのではないかと関心を持ったところから事業が始まりました。

介護という誰もが避けて通ることができない社会課題に対して、あまりにも情報が整理されておらず、介護サービスを受ける側と、提供する側の間に“情報の非対称性”があり、ビジネスチャンスがある世界だとわかったのです。

このように時代の変化や進行によって、必要とされるサービスの在り方を予測し、私たちは産業を「今あるべき姿」にシフトさせていくことで、新しい価値を作り出していきます。

スガイ:事業として利益を生み出すだけでなく、発信しているコンテンツにおいても、ユーザーの「心を動かす」ものか、「事実や根拠に基づき」正しい情報を届けられているか、「少し先の未来を想像し」先回りした視点を持つことで、「感動体験」を提供することができているかという点も大事にしています。

また固定観念や既成概念にとらわれて、変化を恐れるようなことはせず、常に市場やユーザーが求めるものに対して応え続けることを実現し、同時に社会におけるイシューを解消することで世の中にインパクトを与える事業を作り出していきたいと考えています。

この考えを元に、私たちが追求すべきことを10個のバリューとして可視化しました。

ミッション・ビジョンを実現するために大切にしている価値観

1.圧倒的な顧客志向

2.最高水準を当たり前に

3.再現性と仕組み化

4.解像度の高いゴール設定

5.ファクトとインサイトからの価値創造

6.誠実であり正直であること

7.高い視座と当事者意識

8.長期的な視野に立った設計思想

9.知的好奇心と高い情報感度

10.裁量と責任はトレードオフ

このバリューはエンジニアだけの話でなく、クーリエで働くすべての方に共感し推進してもらいたい内容です。バリューとはルールとは異なり、敷かれるものではなくメンバーがオーナーシップを持って体現していくものと考えます。

どこまでも顧客のことを優先して考え、属人化されたオペレーションを排除し、すべての工程を最高水準で仕組み化、技術(業務)的負債の返済と合意を行いながら、不確実性の高いプロジェクトを恐れずチャレンジすることが求められます。

スガイ:このような考えは、エンジニアの思想とも重なる部分が多いと思いますし、実際にこの考えを面接などでしっかり伝えられるようになってからは、正社員・業務委託関わらずに、非常に優秀な方がジョインしてくれることが増えましたね。

エンジニア組織における成果の可視化と運用課題

-順調そうにみえる開発組織ですが、課題はどのようなことがありますか?

ヤスダ:エンジニアに対して、何を成果として評価すべきなのかが非常に難しい問題でした。プロジェクト管理ツールを使って行った開発チケットの数や、プロジェクトの難易度など評価を簡単にすることはできません。

過去に在籍していたエンジニアからは「何がエンジニアの評価なのかが分からない、定量的な指標を作って欲しい」という声をもらったこともあり、組織としてすぐに対応するために動こうとしましたよね。

スガイ:自分がエンジニアとして働いているにも関わらず、評価については上手く言語化することができず、現場のマネージャーとして問題を解消することができなかったのは、今でも非常に悔しく思っています。

ただ、一方で成果の定量化に取り組むと「数字だけで判断されても困る」という真逆の声も出てきました。「どちらに舵を切っても反対意見ばかり」と、組織の評価について迷ってかなり悩んでいましたね。

ヤスダ:あのときは、少し疲れてましたよね(笑)。でも、多くのことは失敗からの学びが今に活かされていることばかりだと思います。

スガイ:そうですね。現在では、担当者ごとの開発工数や、プロジェクトの優先度、チケットごとの仕様把握者との認識合わせ、月次の振り返りなど、可視化された指標とフィードバックによって開発者サイドから見ても改善された部分も多くなりました。

どんな意思決定をしても多かれ少なかれ反対の意見が出てくるので、開発者とBizDevサイドとのコンセンサスをしっかり取りながら、事業として推進すべき軸をブラさずに最後までやり抜くことが大事だと、、、これもやってみてわかったことの一つですね。

-現在はどのような形で開発組織の成果を評価しているのでしょうか。

スガイ:開発の体制としては、アジャイル開発に近いと思います。ただし求められる粒度や運用のスピードについては、他の組織ではあまり見たことはないかと思います。

それぞれの開発者が、自分が関わるプロジェクトやタスクについて、仕様把握者と事前にすり合わせを行い、開発タスクに関する見積もりを行います。普通であれば「今週以内に」や「2〜3日で」といった話になることが多いと思いますが、それをより定量的に求められます。

例えばセールスチームのKPIのひとつに商談数などがありますが、1件の商談をするのに必要な時間を聞かれたときに「2〜3日で」なんて回答はしないはずです。セールスのプロフェッショナルとして、精度の高い見積もりをして「3時間で」や「17:00までに」といった回答をするはずです。

開発者もエンジニアリングのプロフェッショナルとして、自分が取り組む仕事に対して高い精度で見積もりを行うことがクーリエでは求められます。最初は苦労することもあると思いますが、実装するために手を動かす前に、どこまで仕事の解像度が上げられるかということは非常に重要なことです。

見積もりを行った工数に対して、実際の実装時間にどのようなギャップがあったのか、期日に対してしっかりと求められる機能を提供できているのかが、エンジニアの評価に大きく関わっています。

その他にも10個のバリューに則した行動が出来ているか、周りにどのような影響を与えることができているかということも定性面として評価しています。

ヤスダ:実際に運用に取り入れるまでは、エンジニアだけでなくPjMやデザイナー、ディレクターも含めて決して簡単に移行できたわけではありませんでした。

しかし、プロジェクト管理ツールをカスタマイズしたり、仕様策定から開発に携わるメンバーへの周知徹底や、必要な情報のドキュメント化を推進し、組織として重要なことだと私をはじめとした経営陣も発信し続けてきました。

今では当たり前のように運用され、以前よりはるかに平等に開発組織の成果を評価できていると感じますし、そのような開発体制で活躍してくれるエンジニアを是非積極的に採用したいと考えています。

今後の開発組織と取り組みについて

-今後の開発組織はどうなるのでしょうか?

スガイ:まずは開発組織における生産価値を最大化するために、チーム体制の強化を目指しています。またアウトプットの量だけではなく、事業の成果と直結するような「サービス価値」を提供していくことで、より事業会社で活躍できるような開発組織にしたいと考えています。

これまでは、どちらかというと他事業部の要望を聞きながら新規機能の追加や機能改善、KPIの可視化・ダッシュボード化などを実現することが多かったのですが、頼もしいメンバーも増えたことで、今後は開発チームがより事業への理解を深め、主体的に事業にコミットすることを増やしていけると確信しています。

ヤスダ:開発者から事業に対する意見が出て、事業にコミットするということはクーリエの開発組織にとっても非常に大きな前進だと思っています。

どうしてもマーケティングや編集チームなどからの要望が多く、開発者側から声を発信しづらいという構造になりやすいため、事業会社でエンジニアがどうすれば事業貢献することができるのかということを組織の文化として定着させることができたらいいですね。

-これからクーリエに入ってくるエンジニアに求めたいことは?

スガイ:せっかく事業会社でエンジニアとして働くことになるので、どうすれば事業を成長させて利益が出せるのかということを一緒に考えられる方だと嬉しいですね。

「何で作るのか」は手段であって目的ではありません。最先端の技術を使いたいということであれば、他の企業様でエンジニアとして働いた方がいいと思います。クーリエのエンジニアとして働くことで得られることは、「事業がどのように成長するのか」「機能だけではなく人とオペレーションを知る機会がある」ということです。

私もエンジニアとしてクーリエに入りましたが、知りたい情報は自分の動き次第でどのようにでも得ることができます。その中で本当に良かったと思ったのは、技術的な発見よりも、他の事業部やメンバーがどのような仕事をしていて、何が課題なのかを目の前で知ることができたことです。

事業会社としての課題を知り、メンバーがどのようなオペレーションで業務を行っているかを知ることで、私の事業に対する考えや捉え方が大きく変わりました。そんな環境で出てくる提案や発想は、今までにないものでしたし、会社がその成果をしっかりと評価してくれたことも大きかったですね。

ヤスダ:「事業ドリブン」や「事業視点をもって」なんて言葉が最近よく使われますが、なにをもって事業視点かなんて、中々分かるものではありません。一緒に働いているチームやメンバーが何をしているのかは、皆さん興味があるのではないでしょうか?

クーリエでは、そんな身近なところにあるちょっとした課題や、事業を全体で俯瞰してみて発見する大きな問題まで、職域に関係なく自分ごととして取り組める風土があります。そんな環境で事業に全力で取り組んでみたい方と一緒に働ければ最高だと思っています。

最後になりますが、まだ見ぬクーリエの「仲間」に一言ください

スガイ:社会課題の解決や成長する事業への貢献、自身のエンジニアとしての成長に興味がある方はぜひ、一緒にチャレンジをしましょう!

ヤスダ:クーリエは、社会の大きな課題を解決するサービスを通じて大きな価値をつくっていきます。まだまだ理想の形にはなっていませんが、成長を続ける我々と成功する喜びはもちろん、課題を一緒に乗り越えていくことができる方をお待ちしています!

関連記事