ビジョンは運送業界の価値最大化
丹羽健氏（以下、丹羽）：ascend株式会社の丹羽と申します。本日は「Vertical SaaS開発におけるフルサイクルエンジニアという向き合い方」と題してお話しします。
最初に自己紹介をします。丹羽健と申します。ascend株式会社のCTOを務めています。ascendをご存じない方も多いと思いますが、設立1年半ほどでシード期を超えるか超えないかくらいのスタートアップの会社です。本日は、エンジニアのキャリア形成における情報の1つとして受け取ってもらえればという思いも込めて、発表します。
私自身のキャリアは、2016年に新卒で日鉄ソリューションズ株式会社というSIerに入社し、そこで4、5年仕事をした後、ベンチャー企業を経て現職に至っています。SIer時代から、業務系SaaSの開発をずっとやってきたのが特徴かと思います。その5年間に、飲食店向けのハンディアプリや、行政向けの電子申請サービス、また現職では運送会社向けの運行管理サービスなどを開発しました。
趣味は料理です。ascendは、社長の自宅の横にオフィスがあって、みんなで晩御飯を食べるみたいな、まだまだアットホームな文化の会社です。その中でおいしいご飯を担当して、みんなで楽しく仕事ができるようにしています。
続いて、ascend株式会社の紹介をしたいと思います。ascend株式会社は、「日本経済の血管である“運送業界の価値最大化”を通じ日本の産業競争力を再興する」をビジョンと考えています。バリューとしては「創業理念は“ascend”」、名前のとおり「成長する」ことを重視しています。
事業もそうですが、個々の成長意欲を最大限尊重して、責任と挑戦を両立するという文化を持っています。また、失敗を許容するためにオープンなコミュニケーションを徹底しています。成長のための環境でもあると受け取ってもらえるといいと思っています。
では、実際にSaaSを運営するascend株式会社とはどういったものか。ターゲットは、運送会社を中心とした物流業界です。その中で運行管理SaaSであるアセンド・ロジ、（スライドを指して）画面の右側に表示されているようなものを作成しています。
それ以外にも、物流・運送会社向けのコンサルティング事業や、そのコンサルティングを経て出たナレッジを落とし込んでアセンド・ロジの開発などをしています。従業員数はまだまだ少ない14名で、シューマツワーカーさん経由でデザイナーやエンジニアの方にも入ってもらっています。
物流業界のVertical SaaSを開発
実際、私たちがどういった課題を持ってスタートアップをやっているかについてです。みなさんはおそらく物流業界・運送事業者をご存知だと思いますが、運送会社は相当厳しい状況になっています。
データで見ても、10年後には約35パーセントの物流配給が不足するという課題があります。普段みなさんがスーパーで買っているものや服など、すべてのものはおそらく物流業者、運送業者によって成り立っている世界です。そんな中、なかなか持続的ではないというところに課題を感じて、スタートアップとして仕事をしています。特にこの業界は、ほかの業界と比べてもアナログ業務のコストやITリテラシーの不足が大きな課題だと思っています。
そのような課題に対して、私たちascendが開発スタイルとしてフルサイクルかつプロダクトマネジメントを選択した理由をお話ししたいと思います。
まず、Vertical SaaS開発の要点についてです。Vertical SaaSという言葉はまだあまり知られていないかもしれません。一般的に、Horizontal SaaSという人事労務管理など、いろいろな業界で普遍的に存在する業務を対象としたSaaSは多いですが、業界に特化した縦串のようなSaaSはまだまだこれから起きていく段階です。
私たちascend株式会社が開発するVertical SaaSは、物流業界に対するVerticalを目指しています。Vertical SaaSは、実際に業界が抱えるコアな課題を解決し、日常業務を安定して回せることが求められます。
Horizontal SaaSに比べると幅が狭いのですが、逆にその業界の「深さ」というところ、「深さ」がなければ事業者から選ばれるプロダクトにはならないという課題があります。
実際にその「深さ」を獲得するためには、どのような要点が必要になるか。対象業界のドメイン知識の量や業界のユーザーに最適化されたUI／UX、また業界や業務課題の解決策の質の高さなどが、その「深さ」の指標であると考えます。
そして、その「深さ」を実現するために、どのような行動が必要かというと、素早いリリースによる高頻度な検証と学びです。また、その学びを経て成長していかなければ「深さ」は得られず、プロダクトとして成り立たないという課題があります。
課題解決のためにフルサイクルエンジニアによる開発を採用
ascendのプロダクト開発チームの重点テーマは何か、2点を設定しました。1つが、「高速かつ持続的なリリースによるプロダクト価値の創出」で、もう1つが「実務者に向き合った業務装着性の高いプロダクトの開発」です。
ユーザーの課題を、真に捉えたプロダクトを開発するためにはどうすればよいかを検討した結果、ascend株式会社では開発プロセスとして、フルサイクルエンジニアかつ各エンジニアがプロダクトマネジメントに設計しました。その「なぜ」や「どうやっているのか」について、これからお話しします。
まずは、フルサイクルエンジニアという概念です。これは最近けっこう名が知られてきたと思いますが、もともとNetflixにおける開発スタイルです。（スライドを指して）この資料は、実際にNetflixさんが今右下に表示しているブログの中で紹介しているので、それを読んでもらうのが一番正しいと思いますが、今回の発表でいくつかの要点をお伝えしておきます。
まず、ソフトウェアライフサイクル全体にオーナーシップを持って開発するのがフルサイクルエンジニアです。（スライドを指して）右の図の一番上のデザインの設計から開発、テスト、デプロイ、オペレーションの運用、そして問い合わせのサポート。それらすべてを1つのチームまたは開発者が担当します。
そして、このサイクルの中で価値を素早く提供することに集中するのがフルサイクルエンジニアです。
フルスタックエンジニアとどう違うのか、比較されることがあります。これはやや私見ですが、フルスタックはどちらかというと、技術や何かモノ・コトを作ることにフォーカスしますが、フルサイクルエンジニアはどちらかというと、作ることによって生まれる価値にフォーカスするところがポイントかと思います。
フルサイクルを選択した理由です。ascendには、ユーザーの課題に対して一気通貫して向き合うことを重視するという思いがあって、そのためにフルサイクルを選択しました。何をどう作るかではなく、ユーザーの課題をどのように解決し価値を届けるかに自然とフォーカスするように開発サイクルを設計していった結果、フルサイクルになりました。
すべてのステップへの高度なスキルを求めてはいません。適切な成長のサポートを提供したうえで、1つの課題の当事者としてやり切ることを重視しています。
なので、フルスタックでなければフルサイクルはできないという一般的な概念や考え方ではなく、むしろ何かしら足りない領域があったとしても会社がサポートするので、1つの課題に対して一気通貫で向き合ってほしいと考えています。
さらに、ascendはまだまだ小さい会社なので、プロダクトマネジメントの部分についても、1人のエンジニアが担当することを重視しています。それはなぜか。やはり幅広い解決策を考えるエンジニアが、ドメイン知識を使ってプロダクトをマネジメントするのが強いと思っているからです。
課題と解決策は同一人物が考えたほうが質のいい解決策につながり、意思決定も迅速になります。スピードも重要、なおかつ質も高めたいので、1人にすべてを任せる考えを持っています。また、これはエンジニア観点にもなりますが、エンジニアが取れる解決策の選択肢はいくつも挙げられると思います。それを相互評価したうえでの意思決定が可能となります。
プロダクトが進むにつれて現状と乖離して技術的負債になっていくことは往々にしてあると思いますが、フルサイクルかつプロダクトマネジメントを行うと、プロダクトがどのようになっていくのかを想像しながら作っていくことができます。そう考えると、ユーザーに価値が出る部分と出ない部分を把握したうえで開発できます。このように技術的負債の発生を低減できるのが利点です。
このような理由で、持続可能かつ長期的にスピードを出すための考えとして、フルサイクル＋プロダクトマネジメントを捉えています。
業務SaaS開発で重要なのは実務現場を知っていること
もう1点、Vertical SaaS（業界特化型）で重視したいところとして、エンジニアは特に実務現場を知るべきと考えています。業務SaaSでは、単純なデジタル化だけでは業務課題が解決しないという問題があります。実際に業務はすごく複雑で、だからこそ、そこに人が置かれている状態なので、必ずアナログが残る部分があります。
アナログが残る部分と融合させて解決するのが必要で、ユーザーにプロダクトの価値を提供するうえでは、アナログ部分との接点をきちんと知って開発する必要があると考えています。
2点目です。SaaSで実務者の業務負荷を下げることによって、その方々が本当に取り組みたい仕事ができるようにすること。それが、私が考える業務SaaSの魅力かなと思います。
例えばascendが対象とする運送会社だと、配車担当の方は本当に忙しくて、ドライバーの労務環境をなんとか改善したいと思っているのですが、日々の配車業務や点呼やトラブルの対応に忙殺されて改善活動に取り組むことができません。実際、ドライバーの労務環境は長時間労働で、週休1日や10連勤が普通に発生してしまう環境になっています。
それに対して、直接的な解決策は提供できなくとも、SaaSとして実務者の業務を下げることによってやりたいことをやれるように助けていく。そういった魅力があると考えています。
1領域に対してオーナーシップを持ってほしい
フルサイクルエンジニアかつプロダクトマネジメントという働き方は、やることがけっこう多いことが分かりますが、対応策として領域を持つという考えをとっています。
（スライドを指して）まず「1領域を持つ、チームをサポートする」というタイトルですが、各個人が集中できる広さの領域を持って、それに対する業務課題に打ち込むことを特に意識しています。
スキルセットやリソースを考慮して、相談のうえでオーナーシップをどこまで持つのが最適なのか決定します。持ちきれない場合は小さくして、逆に持てるものが多い方は領域を広げて、その方が担当できる範囲の中で集中してもらっています。
スタートアップの時期には副業社員が入っていましたが、やはりそういう方にも1領域を持ってオーナーシップを持ってほしいと思っています。なので、帳票出力領域を例に出しますが、狭くとも領域を持ってもらう開発フローを組んでいます。
実際はエンジニアに限らない話なのですが、小さくとも社会課題に立ち向かう1人間であることがascendの文化でもあるので、やはり1つの領域をみんなが集中して取り組めることを求めています。
これから取り組んでいきたいこと
もう1点、フルサイクルを実現するためには技術的な選定が欠かせません。まずプロダクトの開発に集中したいので、そのために自動化やソフトウェアの資産に投資し、開発生産性を向上・維持させることに熱心に取り組んでいます。ここに一例を挙げています。（スライドを指して）青色の部分が導入済みの改善施策です。グレーの部分がこれからどんどん取り組んでいきたいと思っている領域です。
例えば、フロントエンドとサーバーサイド。当然のように両方1エンジニアが担当するのですが、言語のスイッチングコストが馬鹿になりません。そうであれば、やはり1つの言語に絞ったほうがいいと思います。
また、TypeScriptの現状は、ある程度安定した開発に耐えうる状態にはなっていると思うので、Full TypeScriptのアーキテクチャにしました。
ほかには、リリースの回数をメチャクチャ増やしたいとも考えています。
ascendは、半年後に1日2回以上のリリースを目的として改善に取り組んでいます。例えば、GitOps、Kubernetes上で運用し、ArgoCDを使用して、単純にGitを回すだけで本番のリリースが完了する状態を実現しています。
このように、徹底した自動化とソフトウェア資産を作ることにフォーカスすることによって、中長期的にスピードを維持しながらもきちんとフルサイクルに仕事をすることを目的としています。
そして、このフルサイクルの実現には生産性向上を目的とした継続的な活動が欠かせません。特にascendの開発チームは、生産性向上を探究し続けるスペシャリストを募集したいと思っています。もちろん、こちらのスペシャリストに関しては副業も可能です。
最後になりますが、私たちascend株式会社は共に物流業界を救う本当の仲間を探しています。一緒に社会課題に取り組みたい、共に成長したい方がいらっしゃいましたら、丹羽までぜひご連絡ください。私からの発表は以上です。お時間をいただき、ありがとうございました。
