自己紹介
平下公洋氏（以下、平下）：では「CTOとしてプロダクト価値を上げるために実施したことリスト」を、sweeepのCTOの平下が発表します。よろしくお願いします。
本日話すのは、タスクファーストからチームファーストへの変遷と、あとは技術負債の解消。それと現在地と今後の展望をお話しします。
まず簡単に自己紹介です。私は医療機器の開発リーダーだったり、医療IT製品のプロマネや技術リーダーを経験したあとにフリーランスを経験して、現在はsweeepでCTOをしています。Twitterもやっているので、よければフォローしてください。
sweeepの製品紹介
簡単に最初に製品の紹介をさせてください。我々の「sweeep」というサービスは、請求書を集めて、それをクラウド上でOCR（Optical Character Recognition／Reader）をかけて、AIで仕訳をしてそのままクラウド上に保管するサービスになっています。簡単に、YouTubeの動画を見てもらえればと思います。
（動画再生開始）
請求書の処理でお困りではないですか？ 月初の経理は忙しい。でも、なかなか請求書が来ないこと、ありますよね。請求書をもらうために、社内の担当者に電話をします。担当者は取引先に連絡。郵送で送ってもらって、ようやく経理に戻ってきます。経理の机には請求書の山。請求書を1枚ずつ確認しながら仕訳を記帳していきます。終わった時にはもうグッタリ。sweeepで解決しましょう。
sweeepなら専用のメールアドレスとURLを発行。取引先に直接送ってもらいます。送られてきた請求書はクラウド上にどんどん溜まっていきます。sweeepで入ってきた請求書は、担当者、そして経理からいつでもどこでも確認できます。もう請求書の確認のために電話したり、メールしたり、請求書のために出社する必要はありません。
取引先にお願いできない場合は、自社でアップしても大丈夫です。sweeepに入ってきた請求書はAIが自動で読み取り、あなたに代わって仕訳や振り込みデータを入力しておいてくれます。これからは請求書はパソコンの中。あなたはパソコンを見るだけです。
作業を終えた請求書が入っているので、担当者への連絡も入力作業もファイリングもいりません。もう月初に慌てる必要はありません。余った時間をどうぞ有効に活用ください。さぁ、今すぐsweeepで請求書のストレスをゼロにしましょう。
（動画再生終了）
このようなサービスになっています。これまで経理の方が手作業でしていたものを自動化することで、30パーセントから80パーセントぐらい時間圧縮ができて、ワークライフバランスが非常に取れるようになったという、うれしい声をいただいています。
今は2年の猶予期間中ですが、電子帳簿保存法という法改正があります。すべての紙をなくして電子的に保管しなければいけないという法律が、今は猶予期間中です。契約書でも見積書でも請求書でも、クラウド上に保管できる。そういったサービスを2022年にリリースしました。
タスクファーストからチームファーストへ
では本題に入っていきます。最初に、タスクファーストからチームファーストへの変遷の話をします。私がCTO就任時は、タスクファーストで社内で受託状態。どういう状態かと言うと、ビジネスチームがお客さんの要望や不具合を直接開発者に対して「これを直してほしい」とか「この要望に対応してほしい」など、直接やり取りしている状態でした。
ここの何が問題だったかというと、変更した箇所に対して、「他のお客さんからはちょっと使いづらくなったと言われるんだけどどっちが正しいの？」とか、「こっちのほうが本当はいいと思うけれど、ビジネスチームのマネージャーから言われて言いづらい」とか、「これは本当に必要なのか、何のためにやっているかがわからなくても言われてやっている」。そういう社内の受託状態に疲れて相談を受けたり（していました）。
ビジネスチームは、どうしても目の前のお客さんの個別最適化に走ってしまうので、全体最適にならないという状態に陥って、プロダクトの価値がトータルでは下がっていく。
というところでまず私が実施したのは、間にプロダクトマネージャーを立てることでした。そこでちゃんと要望に対して優先順位や「これは本当に全体最適なのか」という視点を持った上で、開発を反映させる。そういった取り組みを行って、スクラムで開発をするように移行しました。
ここで会計指標を持ってプロダクトを中心に考える。Bizチーム、プロダクトマネージャー、開発チームそれぞれ（が目標を持ち）、BizチームであればわかりやすいProfit/Loss。毎日の売り上げ、毎月の売り上げを目標に動く。
プロダクトマネージャーは、バランスシートのプロダクトの価値を高めるという時間軸で動いて、開発はプロダクトを高めるために開発の生産性、アジリティを上げるといったところを時間軸に動いています。
時間軸の違いがあって、開発チームのパフォーマンスを上げてどんどん機能を追加すればプロダクトの価値が高まり、プロダクトの価値が高まれば売上につながります。（スライドを示して）そういった会計指標モデルに例えたのがこちらの図です。
以前はタスクファーストでどういうことが起こっていたかというと、社内受託状態（になっていたの）と、後でお話ししますがアーキが組織構成に合っていなかったので、技術負債が溜まって生産性が落ちていた。また、プロダクトの価値も個別最適は必ずしも全体最適ではないため、そこのプロダクトの価値も増えないし、場合によっては減っている。こういうところをまずはチームファーストで改善しました。
技術負債の解消
先ほども話をした技術負債のところですが、私の就任時はモノリスなアーキテクチャになっていました。フロントエンドとバックエンドはREST API、DjangoのRESTフレームワークを使っていましたが、ここがかなり肥大化して。かつ、組織も数人でやっている時は問題なかったものの、どんどんメンバーが増えるとだんだんコンフリクトしていきます。
どういう問題が起きたかと言うと、モノリスなアーキテクチャを、同時にいろいろな人がいろいろなところを触るとコンフリが起きます。また、データベースもマイグレーションが大変だったり、データの不整合が起きたりもしていたり。あとは、モノリスなアーキテクチャは必ずしも凝集度が高くなく、いろいろなところで散らばっているところを直さないといけません。
それは昔からいる人はわかりますが、新しく入った人は把握していなくて、修正箇所が漏れるということが起きていました。
ということで、マイクロサービスを採用しました。（スライドを示して）こういったアーキテクチャになっています。後ろ側のバックエンドはマイクロサービスでそれぞれ立ち上げて、その間にBackends For Frontendsを立てて、クライアントに対して必要なデータを送ることをやっています。というところで、少人数でサービスを開発できるようにしました。
そういうことで技術負債をどのように解消したかというと、マイクロサービスをすることによって少人数でサービスを修正することで、コンフリが減りました。単一DBで行っていたものを、マイクロサービスごとのDBにすることで、マイグレーションやデータの不整合性というのが起こりづらくなっている。適切なドメインで切ることで、凝集度も上げられて修正箇所の漏れが減る。
その他にも、品質への取り組みというのを行いました。特にバリデーションです。バグが多いと、本来やりたいことに費やす時間が削られます。何かバグが起きて、調査をして、それを修正してレビューして、QAをとおしてサポートは連絡してみたいなことをしていると、新しい機能に取り組めないので、QAのチームを構成したりシステムテストなどを強化しました。
この時に、正しいものを正しく作る、「Verification and Validation」を考え方として採用しています。（スライドを示して）どういうことかと料理に例えて言うと、左側はレシピ・設計書です。「こう作ればこうなるよね」と。それに対して、それぞれのレイヤーに応じた結合テストやシステムテストの詳細度のテストを、それぞれきちんとその設計書のレシピどおりにできているかを、QAチームが確認する。確認することによって品質が上がるということです。
パフォーマンスが上がった現在地
というところで、チームファーストのスクラム開発、技術負債を解消して現在地はどういうところかと言うと、チームファーストのスクラム開発、組織構成で人が増えても耐えうるアーキテクチャというところで、パフォーマンスは上がっています。それに対して、機能をどんどん追加できるようになるので、プロダクトの価値が上がって、そのうちP/Lも付いてくるでしょうというところに今は来ています。
チームファーストからより生産性を上げるために、リリース後はプロダクトファーストというところで、1週間のスプリントで月曜日にタスクのアサインをして、毎週金曜日のスプリントレビューに向けて開発。デイリースクラムでフォローすることをやっています。1週間開発をして、その次にQAスプリントをとおして、QAがOKだったらデプロイするようにしていますが、QAをやっている間も次の開発をしているので、その次のQAでまた新しい機能が出て、週次でリリースしていく感じでやっています。
そもそもなぜ開発のアジリティを上げる必要があるのかという話です。スモールビジネスであれば黒字を積み上げていけばいいですが、スタートアップだと赤地を掘りながらサービスをスケールさせていかなければいけないので、どんどん開発をしていくことになります。
仮説・検証をどんどんしていかなきゃいけず、場合によってはピボットが必要だったりで、資金が枯渇する前に仮説・検証をしていかなければいけません。そこで1年とか（の期間が）かかってしまうと、その間に資金が枯渇してしまうので、なるだけクイックに、2〜3ヶ月でピボットできるような状態を維持するために、体制やアーキテクチャを変えたというところですね。
将来像としては、プロダクトファースト。スクラムを洗練させてさらに増員して、そうすることでパフォーマンスを上げて、よりプロダクトの価値を積み上げられるようにして。そうすることで、P/Lもどんどん上がり、次の資金調達ラウンドへ行きたいと思っています。
今後の課題
今後の課題としては、技術負債の解消と、あとは増員してもパフォーマンスが下がらないようにするということがあるのと、誰の・どんな課題を・どう解決するかはやはり突き詰めていかなければいけないと思っています。
noteでいい記事があったので引用します。新しいアーキテクチャを実装しても、とはいえ技術負債が上がっていくわけです。許容範囲を超えていくと本当にUXは悪くなってしまうものの、許容範囲の低い位置にリファクタリングなりをして、許容範囲内に収まるということをやり続けることは、これから取り組んでいかなければいけないというところです。
先ほどの話ですが、Verificationのほうです。レシピ側をこれから増員していく。このレシピどおりに作ればちゃんとものができる状態にしていかなければいけないので、設計のところを整理して、ウォークスルーでレビューをしたりして、正しいものを正しく作るという前段のほうを今は力を入れて、新しい人が来てもこのとおりに作ればちゃんとできるという体制を作っています。
この他に、これまでの今までの既存のサービスをベースにサービス開発しているところがあったので、そこでPM以下はするでしょうという前提でやっています。これからさらにスケールさせるためには、まず誰の・どんなペインを・どう解決するかは考えていかなきゃいけないなと思っています。
お客さんにもよくあることですが、お客さんがどういうものがほしいかを正しく言葉にすることができなかったり。それぞれの視点で間違った解釈をするとぜんぜん違うものができて、本当にお客さんがほしがったものがこちら。そういったところを探っていかなきゃいけないと思っています。これからユーザーインタビューとか、そういったところに取り組んでいきたいと思っています。
参考資料になります。
その他にエンジニアを募集しているので、よければWantedlyから応募お待ちしています。カジュアルに話したい方はMeetyとか、会社の雰囲気を知りたい方は、ぜひWantedlyのストーリーなどを見てもらえればと思います。以上になります。ありがとうございます。
