大学卒業後、日鉄ソリューションズ株式会社でのWebバックエンドエンジニアを経て、物流DXベンチャーのアセンドに11人目の社員として入社。プロダクトチームの上司でもあるCTOからは、「困難な状況にも自ら進んでダイブし、その姿がチームを勢いづけてくれる」と称される松本萌花さん。そんな彼女に、アセンドエンジニアとしての実際の働き方や、入社後の成長について聞いてみました。

入社後すぐ、エンプラ向けの重要機能のプロジェクトを担当

──入社されて9ヶ月ほどが経ちますが、どのような9ヶ月だったか、教えてください。

エンジニアとしての最初の仕事は、プロダクトの対象セグメントの刷新に伴う、「請求書作成・発行機能」のリニューアルでした。それまでのアセンドは、中小の運送会社を中心に業務特化型のSaaS「LogiX」を提供していたのですが、プロダクトのバリュープロポジション（提供価値）の見直しに伴い、車両台数100台を超える準エンタープライズ企業へとターゲットの変更をしたんです。それにより、より大量で複雑な業務を扱うことを想定したプロダクトへのブラッシュアップが急務となっていました。請求機能は、そういった経緯でリニューアルが必要になった領域のうちの一つですね。以前は実行した運送案件を手で選択して請求書を作成していく仕様だったのですが、それでは毎月数百枚の請求書を作成する準エンプラ企業では業務負担が大きすぎます。「請求書を、もっと素早く簡単に作成できるように」というのが、私が最初に取り組んだミッションでした。

それまで、バックエンド開発の経験はあったものの、ここまで丸ごと一つの領域を任されたことはなかったので、最初はチームメンバーに力を借りつつ、探り探りでのスタートでした。UXデザイナーの方に課題の特定からシステム要件への落とし込み方を教えてもらったり、先輩エンジニアに設計の壁打ちをしてもらったり。既存機能をベースにした拡張ではなかったので、エンジニア全員で紙とペンだけ持って新宿御苑に行き、アイデアや思っていることを発散しまくる会を企画したりもしました。

　　　　　　（社内Slackに投稿されている、新宿御苑でのブレインストーミングの様子）

──請求領域の開発は、どんな経験だったのでしょうか？

受託開発ではなく、事業会社のエンジニアとしてプロダクトを開発するとはどういうことかを叩き込まれた期間でした。アセンドは、物流業界に特化したVertical SaaS（業界特化型のクラウドサービス）を開発しているため、業界や現場への深い理解と高い解像度を元にしたプロダクト開発が、事業を成功させるための必須条件です。そのため、エンジニア一人ひとりが主担当領域を持ち、企画から開発、運用、サポートまでをオーナーシップを持って推進・実行する「フルサイクルエンジニア」と呼ばれる体制を採用しています。そうすることでクイックな改善と学びのサイクルを作り、顧客にとって使いやすく、本当に価値のあるプロダクトの実現を目指しているのです。そういった環境のなかで、私もCSチームに顧客業務をヒアリングしながら開発を進め、一通りの機能群が完成した段階で、実際に運送事業者様の業務に載せて価値検証をしていくことになりました。

　　　　（請求機能を実業務に乗せる準備が整った日の夜、その場に残っていたメンバーで打ち上げ）

現場視察で感じる、「顧客理解」と「UX」の重要性

──そこで、すんなりと成功体験を得られたのでしょうか？

いえ、実運用の初日、担当CSと共に顧客の営業所に直接伺い、運用のサポートをしながら業務の様子を動画に撮らせてもらえることになったのですが、実際に操作しているところを見たとき、「本当に使ってもらえてる！」という嬉しい気持ちと同時に、「思っていたより使いづらそうだな……」というショックも感じることになりました。弊社のプロダクトは、「アナログな手法の業務（紙やホワイトボード）で、別々に管理され、分断されている業務を一元的に繋げることで業務効率化を実現する、オールインワンの運送管理SaaS」という思想でプロダクト設計をしており、私も業務の全体感を整理しながら、自分なりに体系化した流れのなかで、各機能の画面を割り振っていました。しかし、現場の事務員の方は、私から見ると効率的とは言えない方法で業務をされていたため、その業務であれば、この方法でより簡単にできますよとご案内したところ、「『請求』と書かれているメニューは経理担当の人の領域だから、私はクリックしたくない」とおっしゃられ、画面を見てもらうことすらできなかったのです。

それまで明確に分業化されていたものが、当事者が認識している境目とは違うように繋がって見えることへの心理的な壁が、そこには立ちふさがっていました。「こっちのほうが便利なはず」と思う理想と、「今のままでは使ってもらえない」という現実のギャップを目の当たりにし、使う人の心理状況まで考えて、いかに安心して業務してもらえるかの仕掛け作り、UXの設計こそが、プロダクトを使ってもらうためには大事なんだと痛感しました。「『顧客解像度』は、思ってた以上に深めないといけないんだ、これじゃ全然足りなかったんだ……！」と反省した瞬間でした。

1度目の開発の学びをフルに生かして、次の開発にチャレンジ

初めて手がけた領域でそういう反省があったことで、次に手がけた「労務管理機能」の立ち上げでは、仕事のプロセスを抜本的に考え直しました。業務の概要を一通り理解した後、まずはLogiXが顧客に提供したい一番の価値とは何かをしっかりと定め、それを実現するMVP（Minimum Viable Product）を設計していきました。最初に手がけた請求領域の時は、「最初から最後まで業務が回り切るように、一連の機能を作り込んでから使ってもらう」というやり方をしていたのですが、まずは小さく初めて、とにかく使ってもらう。そこで得られた知見を元に顧客解像度を上げていきながら、さらに開発する。そうやって、方向修正が効きやすい状況で開発を進めるやり方に切り替えました。

──夏の頃に、一度「設計は得意だけど、開発が追いつかなかった」と全社定例で言っていたのが印象に残っているのですが、どういう状況だったのでしょうか？

※編集部注）アセンドでは、自分の経験と学びを言語化し、ともに資産にするため、全社定例の場で振り返りを共有する場をよく設けています。

それは、実装の順番に対する反省の話ですね。請求領域を手がける時、「不確実性が高いから、まず難しいところを最初に倒そう」と考えて、一番難しいロジックの実装から着手したんです。ただ、参考にできるような既存のコードもほとんどないし、私自身TypeScriptでの開発もほとんど経験がありませんでした。結果的に、ずっと試行錯誤しながらコードを書いてるけど、目に見えて動くものは何も完成していない……という状況が1ヶ月ほど続いて。でも他の人はみんな忙しそうだし、自分自身もきちんとやりきって成長したいしで、アラートを出す踏ん切りもなかなかつかず、CSチームに、「請求機能って、今どうなってますか？」と切り出されるまで、一人で仕事を抱え込んでしまっていました。最終的にはCTOが助け舟を出してくれて、プロダクトチーム全員を巻き込んで開発しきり、なんとか間に合わせました。

──なるほど、今だったら、違う順番で取り組みますか？

絶対そうですね！（笑）今だったら、「まずは一本通す」。もう標語のように口癖になっているんですが、単純化したロジックで動くところまでまず作って、動くシステムが目に見えるようになってから機能拡張をしていくという進め方をします。動くものを軸にすることで、自分自身も進捗を感じられるし、なによりこれから開発するものへの解像度が一気に上がるのが利点です。また、チームメンバーやCSも状況把握をしやすく、適切なタイミングでの手助けや方向転換もできるようになります。小さく作ることで開発のリズムができ、純粋に開発スピードも出るようになりました。小さく作れというのは入社してからずっと言われていたことではあるんですが、その重要性や効果、具体的にどういう粒度でやっていけばいいかなどが分かっていなかったんです。失敗を通して身をもって学び、今では自然とできるようになりました。

（毎日のスタンドアップミーティングの様子。日々の進捗を共有しながら、開発プロセスの改善点をフィードバックしあっている）

コードを書く量は以前の10倍！どう解くか、から「何を解くか」を考えられるエンジニアへ

──アセンドに入って、一番成長したと感じる部分はどんなところでしょうか？

まずは、「やりきり力」でしょうか。前職の頃はプロジェクトマネジメントの割合も多く、設計までやってから実装やテストは他の方にアサインするなど、自分が始めたことを最後まで実行し、結果を見届けるという機会があまりありませんでした。でも今は、企画から開発、運用、サポートまでをオーナーシップを持って推進・実行する「フルサイクルエンジニア」という働き方になったことで、プロダクト開発プロセスの全てが自分の守備範囲になり、メンバーもまだまだ少なく、自分が進めないと他に誰もやってくれないので、最後まできっちりやりきる力や習慣が身についたなと思います。コードを書く量も以前の10倍くらいに増えました。もしかしたらそれ以上かも。自分の実装力や技術力もそれに伴ってグッと上がったと思います。

また、フルサイクルになることでhow（どう実現するか）はもちろん、what（何をやるか）にも目が向くようになりました。エンジニアは「どう解くか」にフォーカスしがちですが、プロダクトをつくるには、「何を解くか」にこそ時間を掛けて、慎重に考えていく必要があります。エンジニアの生産性とは、開発した機能の数ではなく、どれくらいインパクトのある顧客課題を解決できているのか、どれくらいの価値をお客様に提供できているのかでこそ測るべきだということ。さらに、使える資源が少ないスタートアップという環境下で、貴重なエンジニアリソースを事業にとって一番重要で価値の出る場所に割り当てて行くこと。そういったことを強く意識して業務に向かうようになりました。CTOがよく言っている、「事業をどうアーキテクチャに落とすか」、「事業戦略を踏まえて開発戦略を考える」という言葉の意味や感覚が、少しずつ分かるようになってきたなと感じています。

なので今は、whatの精度を上げるために日々奮闘しています。労務領域の開発に向けては、まずは業務知識をつけるべく、社労士や労務担当者へのヒアリングを重ねたり、顧客が使っている帳票をCS経由で貰って直接参考にしたりする機会も増えました。労働基準法や改善基準告示など、運送事業者が守るべき労務関連法律に関しては、おそらく社内の誰より読み込んだと思います（笑）。今後は物流業界の構造や歴史までインプットの幅を広げ、事業戦略に対する解像度をもっと上げていきたいですね。労務機能は、いよいよ来週顧客へMVPを当てに行きます。取り組みの成果が出るかどうか、不安もありますが、とても楽しみです。

「伝わるまでが透明性」と捉える環境で、ミッションの実現に邁進

──松本さんは、新卒からずっと大手Slerで、常駐先も大手が続いた後に、社員数30名程度のスタートアップへの転職ということで、トランジション面での挑戦は、エンジニアとして以外の部分でもあったのではないかと思います。その辺りは、いかがですか？

それが、そこではあまり苦労しませんでした。理由の一つに、アセンドの「開示・伝達を重視する」文化があると思います。情報の透明性というと「探せば見れる」ところにただ置いているだけで終わってしまうことも多いかと思うのですが、社長は「伝わるまでが透明性」だとよく言っていて、全社定例の内容や様々な人事制度にそれが反映されています。例えば、入社後の1ヶ月間はオンボーディング期間なのですが、私の時は、まず社内で発生する全ての種類の会議に参加するところから始まりました。様々な商談や顧客への業務ヒアリング、全国トラック協会への訪問、オウンドメディア構築の打ち合わせ、出資元のVCとの定例、銀行との融資面談に至るまで、社長に付いて、会社で起こるありとあらゆるイベントを実際に見て回るんです。自分が飛び込んだ新環境は一体どういう場所なのか、アセンドのミッションへの理解が自然と上がっていくように、様々な機会が用意されています。オンボーディング期間の間に、最終的にはセールスと一緒に展示会や地方講演に行き、直接運送会社の経営者とお話して自力でリード獲得までできるようになってしまいました（笑）。

（展示会への初参加。オンボーディングで学んだ内容を武器に、難なく複数社の名刺を獲得できた。）

またアセンドは、「言語化」に重きを置く会社でもあります。例えば、アセンドでは半期ごとに個人目標を設定し、クオーターごとに振り返りを行うのですが、それが迷いなく仕事に邁進できる原動力になっていると感じます。スタートアップでは会社の事業状況や足元の課題は日単位で変わっていくので、実務に寄った細かい数値目標などは立ててもすぐに形骸化してしまいます。また、やはりどうしてもハードワーク気味にはなってしまうので、常に前向きな気持ちを保つための自身のモチベーションや動機作りが大切です。そういった状況下においても迷わず突き進めるような、事業戦略とずれのない、かつ自分が心から共感してやっていこうと思えるミッションを、上司とともに何度もブラッシュアップを重ねながら作り上げていきます。これが日々の指針になってくれるので、「どう考えていけば良いのかわからない」「何をしたら評価されるのかわからない」という状態にはなりません。

──ズバリ、松本さんの今のミッションを教えてください！

「物流業界の未来を見据えた真の課題を探索し、資産を戦略的に積み上げていくことで、運送事業者にとって必要不可欠なプロダクトを実現する」です！自分や事業の成長に合わせて、これからもどんどん洗練させていきたいです。

「目標設定」も、「振り返り」も、フレームワーク自体は一般的なものだと思います。しかし、一つ一つ意図を込めて、何を達成したいのかを考えながら運用していく。数値で測れるもの、測れないもの。もっと大きく、高く考えるための、視座の引き上げとストレッチ。日々そんなことを求められている気がします。

また、これもスタートアップならではかなと思うのですが、つい最近「労務機能良いね、めちゃくちゃ期待してます！」と出資元のベンチャーキャピタリストの方に直接お声がけ頂ける機会もありました。私の仕事が、会社、そして業界の価値に直接繋がっている。フルサイクルエンジニアとしての責任とプレッシャーを楽しみながら、ミッションの達成のために、これからも全力で頑張っていきたいと思っています。