技術的負債に向き合いプロダクトを成長させる組織とは.pdf

Transcript

1. 技術的負債に向き合い プロダクトを成長させる組織とは 2024/05/13
2. 自己紹介 藤倉 成太 キャディ株式会社 Drawer VP of Engineering 日本 CTO 協会 理事 株式会社オージス総研でシリコンバレーに赴任し、現地ベン チャー企業との共同開発事業に携わる。帰国後、金沢工業大学 大学院工学研究科知的創造システム専攻を修了。 2009 年に Sansan 株式会社に入社し、2019 年執行役員 CTO に就任。 Sansan Global Development Center, Inc. のDirector/CTO と して海外開発体制を強化した。 2024 年キャディ株式会社に入社 し、DRAWER VP of Engineering に就任。
3. キャリアサマリー 10 歳 MSX 購入 18 歳 大学入学 22 歳 オージス総研 25 歳 米国赴任 29 歳 大学院 32 歳 Sansan 47 歳 CADDi 2013 開発部長 2016 PdM 44 歳 CTO 協会 2018 CTO 2022 海外子会社 Director/CTO 電子工作 コーディング 機械 工学 SW 英語 ビジネス 協会理事 2024 VPoE 2021 1986 1995 1999 2002 2006 2009 2024 2021 1999 エンジニア
4. キャディ株式会社のご紹介
5. 5 企業理念 モノづくり産業の ポテンシャルを解放する Unleash the potential of manufacturing
6. © CADDi Inc. Organization 4カ国 Global 拠点 217億円 資⾦調達総額 600⼈ 社員数 代表取締役 CEO 取締役 CTO Business Founders 会社概要 6
7. © CADDi Inc. “ 貯める” から “ 使う” へ ERP PDM Local server System of Insight CAD System of Record CAM Excel File storage 価値を生む データを使う データを貯める データを作る
8. © CADDi Inc. AIとアルゴリズム 8 アルゴリズム AI (機械学習)技術 曖昧さを吸収していい結果を出せる。 ⾃由度の⾼いものにも対応ができる ⼀⽅で厳密な解析は苦⼿ 相性の良いデータ: 写真の解析 構造化されているデータに対する 厳密な解析が得意。⼀⽅で多様性に 弱くアドホックな対応が増える 相性の良いデータ: 3D
9. © CADDi Inc. 類似図⾯検索 実⽤例 9
10. プロダクト事業の技術的負債
11. エンジニアリングから見た プロダクト事業と不確実性 プロダクトを企画、開発する事業にお いてなぜ技術的負債が発生するのか
12. プロダクト開発とは先行投資的側面が強い 正しさは開発時にはわからず、リリース後になってわかることが多い。開発をするために は、社内外のエンジニアの工数（人件費など）が必要。つまりは先行投資的な判断が求 められている。 先行投資（せんこうとうし）とは経営学用語の一つ。これは企業が経営を行っていく上で の投資で、行った場合の現在の直接的な価値はマイナスであるものの、このことから新 たな展開が開け結果としてはプラスとしての効果が期待できるようなもののことを言う。 先行投資 - Wikipediaより
13. 先行投資的側面がある以上、リリースした機能に価値があったかどうかで開発の良し悪 しは測れない。また、リリースした機能を良いものにするかどうかは、リリース後の活動に こそ大きく左右される。リードタイムは数ヶ月の場合も。 1. 仮説を立てる 2. 開発、リリースする 3. ユーザや事業の反応を見る 4. UX の調整、機能強化、CS 施策などで使いやすくしていく 5. 最初に立てた仮説の確らしさが判明する 先行投資的開発の評価
14. プロジェクトと不確実な事柄 プロジェクトの種類 不確実な事柄 新規プロダクトの立ち上げ 市場が存在するのか？ 新機能開発 ユーザに使ってもらえるのか？ ドメインモデルの追加・変更 概念の捉え方が正しいのか？ 性能向上、改善 どのくらいの性能を目指すべきなのか？ セキュリティの維持・向上 どのくらいのレベルを目指すべきなのか？
15. 新規プロダクトの立ち上げと新機能の開発 事業的な不確実性が高い傾向がある（この不確実性を下げるための方法はあるが、プ ロダクトマネジメント的な取り組みをするとして）。この種の不確実性に対しては素早い PDCA サイクルでの仮説検証を繰り返すことが必要となる。以下の要素を両立する判断 が求められる。 1. 素早く開発が完了させられる技術選択 ◦ 既存の人員で扱いやすい言語、フレームワーク 2. リリースの修正・改善を容易とする設計 ◦ 体制の強化がしやすい選択や設計をしておく ◦ モジュールの設計変更も考慮に入れた設計が必要な場面も多い
16. ドメインモデルの追加や変更 ドメインモデルの捉え方が変わらない（ある程度予測されていた）要素の追加であれば特 に問題はないが、ドメインの捉え方を変える要素の追加や変更、ライフサイクルの変更 はデータの持ち方を変える大掛かりなプロジェクトになりがち。そして、この種の変更はプ ロダクトの成長と共に定期的に発生する（プロダクト関係者の期待値と開発の難易度が をすり合わせることも重要）。 ただし、柔軟性を高めようとすると抽象度の高い複雑なモデルになりがちで、リスクが高 い。ドメインモデルの追加や変更に耐える設計が求められる。
17. 性能・セキュリティなどの非機能要件の維持と向上 非機能要件は高いレベルであればいいことは間違いないが、必要な開発費用と成果の ROI（投資利益率）を考えたい。ただし、絶対的に理想の ROI を定義することはできない ので、状況に合わせて最適なものを考える必要がある。 投資利益率（とうしりえきりつ、英: return on investment, ROI）とは、投資額に対してど れだけ利益を生み出しているかを見る尺度である。通常は、次式で計算される。 　　投資利益率 ＝ 利益 ÷ 投資額 投資利益率 - Wikipedia より
18. パフォーマンスの低下によって被る不利益の規模や、セキュリティリスクが顕在化する確 率を計画に組み込むのは難しい。また、対処療法的な対策は判断が不明瞭になったり、 対策のためのオーバーヘッドが大きくなる傾向がある。 パフォーマンス指標やセキュリティリスクは常時監視した上で、ROI と照らして適切な判 断をするしかない。その投資規模に応じた技術的な対応オプションを選択していく。 難易度の高いリスク判断
19. 事業成長と不確実性 事 業 成 長 時間 立上げ 成長 安定 成長 素早い立上げ 高速な PDCA 基盤の安定化 性能改善 セキュリティ ドメイン拡張
20. PoC (Proof of Concept) の実施や素早い PDCA のための技術選定、設計を行ってい ることや、事業成長と市場変化によって、設計の前提が変わり、アーキテクチャの変更が 常に発生すると考えた方が良い。これらは技術的負債として認識されることもあるが、継 続的に改善していくための技術力を組織として身につけておくことの方が重要。 これもドメインモデル同様、当初から柔軟性を確保しようとすると複雑性が増すので、何 らかの諦めや割り切りも必要。 リアーキテクチャとリファクタによる技術的負債の解消
21. 技術的負債への取り組み 必ず発生するであろう技術的負債をど のように回収していくのか。
22. 開発行為が先行投資である以上、技術負債の解消も投資である。 計測・観測された課題に対して工数を掛けるかどうかの判断をしていることが重要。課題 が正しく認識されていて、明確な判断があり、将来計画を含めて説明可能な状態となれ ば、「なんとなくモヤモヤする」という状況は減らせる。 （改修後の事業貢献 ー 改修に掛かる工数）vs 未改修状況での事業貢献 1. 現状の状態を維持する 2. 改修プロジェクトを開始する 3. 改修プロジェクトを計画する（開始条件を決める） 事象を観測して投資判断を行う
23. 技術的負債による影響の計測・観測 技術的負債の種類 計測・観測 コード 修正行数・PR コメント内容 詳細設計 PR のマージまでの時間 ライブラリ メンテナンス業務の時間・開発予想期間 アーキテクチャ メンテナンス業務の時間・開発予想期間 パフォーマンス・セキュリティリスク ドメインモデル 開発予想期間
24. 計測の厳密さよりも実行が重要。Four Keys なども有効だが、一気にそこまで行けなくて も大丈夫。開発工数や PR のマージ時間なども数値計測も、サンプリング調査や手計算 の精度でも、始めることに意味がある。 観測と計測
25. 細かい部分はパネルディスカッションのパー トで議論していきましょう