akippa Tech Park #1 イベントレポート
こんにちは、akippa広報の石川です。
2023年3月2日、akippa初となるエンジニアイベント「急成長企業のCTO/VPoEが語る攻めと守りのバランス akippa Tech Park #1」を開催しました。東京・外苑前にあるnote placeをお借りしてのリアルイベントです。2時間超におよんだイベントの中から要点だけをピックアップしてまとめたいと思います。
akippa tech parkの記念すべき第一回のイベントテーマは、「事業フェーズごとの攻めと守りのバランス」。
成長するベンチャー企業のCTO、VPoE（Vice President of Engineering）の方々をゲストにお招きして、事業フェーズごとに成長投資と技術的負債にどう取り組んでいるかについてお話いただきました。
イベントページ
https://akippa-tech-park.connpass.com/event/273102/
登壇者
株式会社アンドパッド 執行役員 VPoE 下司 宜治 氏 @gessy0129
BASE株式会社 執行役員 CTO 川口 将貴 氏
株式会社SmartHR 執行役員 VPoE 森住 卓矢 氏 @t_morizumi
akippa技術顧問/株式会社スライストーン代表取締役 白石 久彦 氏 @hisahiko
akippa株式会社 PdM/Manager 井上 直登 @7010i
akippa株式会社 Techlead 村上 健一郎
akippa株式会社 PdM 熊谷 佳樹
第一部 各社からの発表
第一部では、現在のフェーズに至るまでにどのように攻めと守りをバランスさせ、サービスを成長させてきたのか、各社からプレゼンテーション形式で赤裸々にお話いただきました。
今回登壇いただいた各社は、2010年代中盤にサービスを立ち上げ、現在は「成長期」「ポストIPO期」に到達しているサービスです。
ちなみに話題のChatGPTに「成長投資と技術負債の解消についてどのようにバランスさせるべきか」聞いてみたところ
成長投資の優先順位を決める
投資回収企画を考慮する
技術負債の解消を焦らない
予算を管理する
と教科書のような回答でした。
■実録akippa ~サービスローンチから現在まで~（akippa PdM/井上）
akippaは、使っていない空きスペースを駐車場として簡単に時間貸しできる駐車場のオンラインマーケットプレイスを2014年4月から提供しています。「あなたの”あいたい”をつなぐ」をビジョンに掲げ、駐車場を通じてさまざまな”あいたい”をつないでいきたいと考えています。
プロダクト開発においては4つのフェーズがありました。
①立ち上げ期（〜2014年）「攻め10：守り0」
当時営業会社で社内にはシステム設計・構築ができる人がおらず、業務委託で協力してくれたエンジニアがスピード最優先で開発をしていました。
成功するかどうかもわからないサービスだったので、とにかく早くリリースして検証するというスピード重視の判断は良かったと思います。スピード最優先だったので保守性や可用性などは最低限の状態ですが、当時のものは技術負債ではなく「技術資産」だと考えてます。
②成長期 前期（2015〜17年頃）「攻め5：守り5」
システムの仕様上の課題があったり、大きなチャレンジを求められたりしたこの時期、攻めと守りを同時に行うリニューアルにチャレンジしましたが、大失敗。半年ほどかけたリニューアルもお蔵入りに終わりました。
仕様を詰め込みすぎたり、チームメンバーのスキル面でも未熟だったりといろいろな原因の積み重ねでしたが、「（リニューアルを）止める」という判断をしたことは英断だったと思っています。
③成長期 中期（2018〜20年頃）「攻め3：守り7」
リニューアルの反省を活かして、一気にリニューアルを進めるのではなく、できるところから少しずつ取り組む形に方向転換しました。たとえば、zendからLaravelへの移行はできるところから進めたり、テストコードを必須にしたりしました。
開発の品質やレベルは大きく改善したものの、場当たり的な対応も多く、自社サービスの開発に期待を抱いて入社したエンジニアを中心に、やりたいこととやるべきことの間にギャップが生じてしまった時期でもありました。
④現在の成長期（2021〜23年）は「攻め6：守り4」
積み上げでタスク処理を行っていたところから、やりたいことからの逆算でプロダクト開発に取り組むようになりました。「1プロダクト1チーム」体制からプロダクトをユーザー側・オーナー側・基盤に分け「複数プロダクト複数チーム」体制に変更し、それぞれが担当するプロダクトに向き合って優先順位をつけて対応する形に変更しました。攻め重視にシフトしてきています。
一方で、古いフレームワークがまだ残っている点や最適なアーキテクチャなど課題も残っていますが、攻めのプロダクト改善をしていきたいと考えています。
▼akippaの採用情報▼
https://career.akippa.co.jp/
■ANDPADの攻めと守り（アンドパッド VPoE/下司氏）
ANDPADは、建設業向けのクラウドサービスで、業界内で最も利用されているサービスです。「幸せを築く人を、幸せに。」をミッションに、建設DXを推進するプラットフォーム開発を行っています。
現在の技術経営チームはCTO（新サービス開発）、CDO（海外拠点）、VPoE（組織責任者、CSO兼務）、VPoT（技術戦略、エンジニア育成）の4名がいて、エンジニア数は着々と増えています。重要人物の参画ごとに3つのフェーズがあります。
①VPoE参画まで（〜2019年頃） 攻め10割時代
最初はスピード最優先で、顧客の要望を電話で聞きながらその場で開発をしているような状態でした。CTOとCDOの個人の力に依存していて、新技術導入の意思決定も特定のエンジニアの興味・関心による技術選定をしていました。
ドキュメントを整備するよりも開発に時間を当てており、多くが口伝なので、技術的負債の多くはこの時代のものですが、成長に向けては必要だった時期だと思います。
②VPoT参画まで（2019〜21年頃） 守り3割時代
SRE、VPoEの2名が入社したことにより、変化しました。
インフラを整え、組織基盤を作り、メンテナンスしやすくするために定期的にアップデートを行うようになりました。
具体的な取り組みの一つが「ポストモーテム」で、インシデントの解決プロセスや学びを残すようにしました。「DesignDoc」ではなぜ作ろうと考えたかなどの設計思想、意思決定の過程を残して、適切なものを作るように考えました。またデベロッパーエクスペリエンスを高める「今を改善する」活動を増やしました。
改善するとともに、技術的負債を作りにくくすることを意識して全体的に取り組みました。
③現在（2021〜23年頃）4配分時代
現在は「既存の活性化」「新製品開発」「研究活動」「遠心力をあげる」の4つに分けて取り組んでいます。サービス規模は毎年200％を超える成長をしており、3年後には現在の10倍規模になっていると予想できます。10倍に耐えられるか、3年後にどうなっているかを軸に開発を進めています。4領域の配分は、月に1度MTGを行い、優先度を調整しています。
４配分時代になって「守り」ではなく「未来の攻撃に向けた守備」へと意識が変化して、「遠心力をあげる開発」（中長期視点で開発速度をあげるための共通基盤作り）ができるようになっています。
専門職に分割し求める人材も増えました。常に多くのポジションが求人に上がっている状況です。自分達が思いつかない人材もいるため、その人に適したポジションがなければ新たに作るというスタンスで採用は進めています。
▼登壇資料▼
https://speakerdeck.com/andpad/andpadnogong-metoshou-ri
▼アンドパッド 採用情報▼
https://engineer.andpad.co.jp/
■BASE（BASE CTO / 川口氏）
BASEは現在は3つのサービス（ネットショップ作成サービス「BASE」、購入者向けショッピングサービス「Pay ID」、オンライン決済サービス「PAY.JP」）を提供しています。
BASEを利用して開設されたショップ数は190万ありますがコロナ禍で急激に成長したため、サーバーへの負荷が大きくかかるなど、計画上の5年後が突然きたような感じでしたので攻めや守りを考えている余裕はありませんでした。
2022年11月でサービス提供開始から10周年を迎え、2019年10月には東証グロース市場（旧マザーズ）に上場しています。私は2017年入社なので知らないこともあります。
IPOをしたことが理由で技術的負債を返済できたわけではないです。今いるメンバーが日々課題に向き合う覚悟が必要で、技術的負債を残して困るのは自分か未来の同僚なので、その人たちが困らないような開発をすることを心がけています。
そもそも「攻めと守り」とは何か考えてみたのですが、あまり意識していません。
技術的負債を解消することも「攻め」であり、悪意ある攻撃から守るセキュリティは「守り」ですが、安心安全なプロダクトを作ることは「攻め」だと思います。エンジニアにとっては面倒な作業であっても使ってくれるユーザーがいるからこそのシステム開発であり、自分たちのプロダクトやブランドを守ることにつながるというのが私たちの考えです。
たしかにIPO前後ではきちんと管理することが求められて、内部統制やJ-SOX対応などが増えて大変でしたが、IPOによってより広くユーザーに届けられるので必須のことだと認識した上で、攻めと守りの「バランス」ではなく、「攻め10：守り10」でより良いプロダクトを作っていって、そのモチベーションを管理することがより重要かと思います。
▼BASE 登壇資料▼
https://speakerdeck.com/base/base-akippa-tech-park-1
▼BASE 採用情報▼
https://herp.careers/v1/base
■SmartHRのセメとセメ（SmartHR VP of Engineering/森住氏）
SmartHRは、人事・労務業務のペーパーレス化にはじまりましたが、現在はSmartHR上に蓄積したデータを活用するタレントマネジメント領域にもプロダクトを展開しています。「well-working 労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会をつくる。」をコーポレートミッションに掲げ、誰もがその人らしく働ける社会をつくることを目指しています。
①2017年頃 「攻め10：守り0」
プロダクトエンジニアとドメインエキスパートのみの組織で、ドメインエキスパートが要件を伝えてエンジニアが開発を進める体制でした。アーキテクチャはRailsのモノリシックなアプリケーションが一つあるだけのシンプルなものです。リリース最優先でしたが、ユニットテストやCI/CDの整備は欠かさずやっていました。
②2018年頃 「攻め10：守り0」
雇用契約などオプション機能が追加されていきます。ユーザー側からみると一つのプロダクトですが、裏側では複数のAPIが連携する形で動いていて、リポジトリやインフラごとアプリを分けることでひとつのRailsアプリケーションがいたずらに肥大化するのを防いでいます。機能ごとにチームが分かれていく体制に変化していきました。
③2020年頃 「攻め7：守り3」
チーム内の職能が多様化し始めるとともに、API連携するオプション機能も増えました。この時期に開発した「従業員情報の履歴管理機能」は大きな技術的負債となりました。Active Recordを拡張したためかなりの早さで実装できたものの、予期せぬ挙動が頻発し、初めて負債解消チームが一時的に立ち上がることになりました。
④現在2023年 「攻め7：守り3」
チーム内の職能はさらに多様化し、基本機能の開発も6チーム体制になりました。APIも数十規模に拡大し、「攻め」の投資を継続しています。
オプション機能が増え、それぞれに開発を進めたことで、ユーザーから見ると一つのサービスであるにもかかわらず各アプリケーションごとに体験が微妙に異なる状況が発生。「攻め」の投資としてプロダクト基盤チームを組成しました。
まとめると、基本姿勢は「ずっと攻め」です。クリティカルな技術的負債に対してはチームを組成しましたが、理想的とは思っておらず、なるべく普段の開発の中で解消できるレベルにしていきたいです。
今後は、複数プロダクトでユーザーに価値を提供する形を目指し、引き続き「攻め」の投資を継続していきます。
▼SmartHR 採用情報▼
https://hello-world.smarthr.co.jp/
https://smarthr.co.jp/recruit/
第二部 パネルディスカッション
akippa技術顧問の白石氏をモデレーターに、akippaのエンジニアリングの現場が抱える課題3点について、公開ビジネスコンサルティングのような形でパネルディスカッションを行いました。こちらも概要のみピックアップしてまとめていきます。
■お題① 溜まりがちな技術的負債/どのように向き合っているのか？
スライストーン 白石氏：
技術選定、技術的負債の解消などの判断はどのような体制で進めていますか？
アンドパッド 下司氏：
テックリードに任せています。放置してしまうことがあれば、横断組織がアラートを出すようにしています。
BASE 川口氏：
全てのチームにテックリードがいるわけではないので、メンバーに解消したいか新しいものをリリースしたいか聞いて私が判断しています。SREなどとの兼務が多く、権限委譲できていないことも負債です。（笑）
SmartHR 森住氏：
テックリードはいなくて、各チームにチーフと呼ぶプレイングマネージャーを置いてテック面を含め見ています。四半期に一度程度、メンバーと直接話すスキップレベル1on1を実施して、その中で現場の声を拾って定性的に判断しています。
スライストーン 白石氏：
技術選定において、これだけはやってはいけないというようなルールはありますか？
アンドパッド 下司氏：
特にないです。
強いて言えば、DesignDocでレビューを行っているため、DesignDocは必ず書いてほしいということくらいです。
BASE 川口氏：
特にないです。
自分がルールを決められるのが好きではないのであまり決めすぎないようにしていますが、誰も幸せにならないことはやらないでほしい、ということくらいです。採用する時点でそういう人は採用していないと思います。
内部統制の一環で、レビューが通っていないものは進められなくなっているので、ガードレール的な位置付けにはなっています。
SmartHR 森住氏：
言語化しているものは特にないです。
現状すべてRailsで開発していますが、それ以外の言語での提案があっても拒みません。ただこれまでのRailsでの資産があるので、資産を捨ててまで突き進もうとする人はそうそういないというのが現状です。
スライストーン 白石氏：
技術的負債を含むイシューにぶつかったとき、どのように向き合っていますか？
アンドパッド 下司氏：
以前専門チームを作ったことはありますが今はないです。
人によって課題に思うことが異なるので、課題を話しあう場は設けていて、向き合う必要がある課題なら人をアサインして対処するようにしています。
BASE 川口氏：
技術基盤チームを作って対応しています。こちらも私が兼務ですが（笑）
DB移行など負債よりも災害に近い状況の時にはプロダクトチームからも人をアサインするなどして影響範囲によって変えています。
負債解消チームを組成するのは対応期限が決まっているときくらいで、OKRに入れて対応してもらっています。
スライストーン 白石氏：
技術的負債の解消はしんどさを伴いますが、解消にあたる方々のモチベーションの管理はどうしていますか？
SmartHR 森住氏：
前述した「従業員情報の履歴管理機能」に関してはこれを直すことで事業価値があがるということを説明してPMに入ってもらって取り組んでいます。全社的な注目を集めているレベルの負債なので機能開発に近い立ち位置かもしれません。
固定のチームで取り組むのが理想的とは思っていないので、ゆくゆくはそういうチームがなくなっていくとよいのかなと考えています。
■お題② 技術選定の自由度とガバナンス
akippa 村上：
akippaが当初採用したフレームワークは、当時の開発者の得意なものから選定されました。フロントサイトや管理サイトにはZendを採用し、スマホアプリのAPIは、委託した協力会社が得意なyii2と呼ばれるフレームワークが採用され、このときは社内からのフレームワーク指定やコードレビューもほぼ無しで作ってもらっていました。
2017年ぐらいからは、現在のPHPのフレームワークとしては主流のLaravelを採用し、できるところから一画面ずつZendやyii2からLaravelに移行していっています。
スライストーン 白石氏：
このような状況を防ぐにはどうすれば良かったのでしょうか？
BASE 川口氏：
一画面ずつでも進んでいるだけすごいと思います。
3つめの新Laravelみたいなものが生まれることもありますから。
スライストーン 白石氏：
SmartHRさんはRubyのみですとフレームワークはばらけずらいですか？
SmartHR 森住氏：
そうですね。Rubyなのでフレームワークはばらけることはなく、Rails一択になっています。
アンドパッド 下司氏：
実はakippaより複雑で、バックエンドは言語自体がRubyもあればGoもあり、ある意味遊べる環境です。
バージョン管理はテックリードが行っていて、モニタリングはBotが頑張っています。
PHPで揃っているだけ幸せだと思います。
akippa 井上：
揃えようという話にはならないですか？
アンドパッド 下司氏：
まったくならないです。
BASE 川口氏：
（すべてPHPで開発しているので）PHPが嫌いな人は絶対に採用できないので、遊びがあると採用スカウトの時点で幅を広げられていいですね。
言語も適材適所があるので、プロダクトのためにあえて言語を変えるのは技術選択の観点でした方が良いと思います。
スライストーン 白石氏：
言語を知っている人の退職などで、保守の面で困ったことはないですか？
BASE 川口氏：
たくさんあります。
コンソール上に直接書かれているものもありました。CI/CDがあればなんとかなると思います。
アンドパッド 下司氏：
どんな言語使ってもいいと許可はしているため、全部責任は私にきます。退職直後は困りますがCI/CDがあればなんとかなると思います。
SmartHR 森住氏：
退職者が少ないので今のところはそれほど困ったことがないのですが、言語が統一されていることもあり他の人でも面倒を見やすい環境ではあると思います。
■お題③ 負債の返済/守りと攻めのバランスは？
スライストーン 白石氏：
各社の発表を聞いていて、よりよい提供価値やユーザー体験を提供できるなら「攻め」と定義していいのかなと思いました。
新しいものを作るときの技術の使い方についての判断の仕方をお聞きしたいと思います。すでに資産としてあるものを活用するのか、新しい技術にチャレンジするのか、その辺りの意思決定はどのように進めていますか？
アンドパッド 下司氏：
基本はテックリードにDesignDocを書いてもらっています。そこにどのような観点でチェックしたかを残していってもらっています。場も提供しています。
BASE 川口氏：
単一サービスなので新しい技術をあえて導入することはそこまで多くないですが、フラットに会話はしています。
新しい技術を使う時には、採用と既存メンバーのスキルセットが重要だと思います。
新しい技術の習得や学習にコストがかかるという声もありますが、学習することも仕事というふうに言っています。
■Q&A
スライストーン 白石氏：
非エンジニアに対して、技術的負債などの技術的な取り組みをどのように説明していますか？
コミュニケーションで気をつけていることはありますか？
BASE 川口氏：
フローの設計はエンジニアだけで進めるものではないので、仕様を決めるプロダクトマネージャーを入れて進めています。エンジニアが理解していないこともあるし、逆もあるので、チームとして理解するようにしてもらっています。
スライストーン 白石氏：
そもそも「技術的負債」とは何か？何だと捉えているか？が知りたいという質問が来ています。
SmartHR 森住氏：
急いで開発するために借りた借金だと思います。
コードの変更容易性の低下かなと思います。
BASE 川口氏：
前借りしたものの中で放置していて未来を壊しているものが負債だと思います。
アンドパッド 下司氏：
変更に時間がかかるもの、改善するための道筋も見えにくいものです。
ただの実装ミスは負債ではないです。
akippa 村上：
変更容易性の話がありましたが、変更容易性を担保するにはテストコードが必要だと考えています。今は新しい機能の開発時にはテストコードを必須にしていますが、それまでに作られた機能にはテストコードがありません。テストコードがない部分は変更が容易ではないということで、全て負債だと考えています。
スライストーン 白石氏：
活発なディスカッション、ありがとうございました。
コンテンツ終了後には、懇親会も行われ、参加者同士の交流を深めました。
本イベントのハッシュタグは「#akippa_tech_park」です。
https://twitter.com/hashtag/akippa_tech_park
参加者の皆さんからのさまざまな投稿が見られますので、あわせて参考にしていただけたらと思います。
akippa tech parkは今後も不定期で開催予定です。
ぜひconnpassアカウントやakippaエンジニアnoteをフォローして、イベント情報をお見逃しなく！
この記事が気に入ったらサポートをしてみませんか？