(で、具体的に何をやっているのか)
アジェンダ ▶カミナシという会社 ▶そもそも「技術的負債」とはなんだったか ▶カミナシの技術的負債返済プロジェクト ▶まとめ
Twitter.com/Toriclsカミナシでの技術的負債返済プロジェクトとその決断ToriSep. 1, 2022めぇ(で、具体的に何をやっているのか)
View Slide
twitter.com/toriclsTori Hara /CTO at Kaminashi❤ Come build with us! ❤toricls• Meety - https://meety.net/matches/wlbIxlejLKXn• ࠾༻ใ - https://careers.kaminashi.jp/
Twitter.com/ToriclsAgenda▶︎カミナシという会社▶︎そもそも「技術的負債」とはなんだったか▶︎カミナシの技術的負債返済プロジェクト▶︎まとめ
twitter.com/toriclsカミナシ
Twitter.com/Toricls
Twitter.com/Toricls現場 DX プラットフォーム『カミナシ』https://note.com/toricls/n/nf3d205c1777chttps://kaminashi.jp/
twitter.com/toriclsそもそも「技術的負債」とはなんだったか
Twitter.com/Toricls「技術的負債」とはなにか？の共通認識https://speakerdeck.com/toricls/the-debt
Twitter.com/Toricls「技術的負債」とはなにか？の共通認識 - まとめ 1▶︎主にエンジニアリングの⽣産性を低下させ、システムの継続的改善を前提としたビジネスモデルをリスクに晒している技術的要因▶︎⼈間、技術、ビジネス環境、ビジネスそのもの、すべてが時間の経過とともに変化する▶︎その変化の結果と最適の差分が技術的負債▶︎継続的改善前提でシステムを作る限り、優秀な⼈材を集めても(程度の差はあれど)必ず技術的負債は発⽣する▶︎なぜならシステムの周りが変化していくから▶︎ドメイン知識やスキル、市場理解が不⾜したままプロダクトや機能を作る必要性▶︎逆説的だが、だからこそ「継続的改善」が前提になる
Twitter.com/Toricls「技術的負債」とはなにか？の共通認識 - まとめ 2▶︎技術的負債を⽣み出しているのはエンジニアリングだけではない▶︎技術的負債は、不確実性をシステム側に押し付けた結果でもある▶︎ビジネスモデルそのもの、プロダクトのバリュープロポジション、⼀つ⼀つの機能要件、仕様…▶︎いたるところに不確実性が潜んでいる / SWE ⼭⽥さん(仮名)「最初から分かってたら？そりゃこうは作らないですよ〜」▶︎不確実性を他で飲み込めないとき、実⾏フェーズにあるエンジニアリングが未来の⾃分たちから「技術的借⾦」をしてビジネスを前に進めている▶︎顧客に価値を届けることに真剣なエンジニアリングであればあるほど、こうなりがち▶︎当時は借⾦でビジネスを加速できたが、その利息が複利で今の⽣産性に悪影響を与えている▶︎「技術的負債」は⼿抜きの結果ではない▶︎(そもそも過去時点でのドメイン知識不⾜やスキル不⾜を⼿抜きと評するのはあまりフェアではないですよね？)
Twitter.com/Toriclsなぜ技術的負債を返済するのかhttps://speakerdeck.com/toricls/the-debt
Twitter.com/Toriclsカミナシの技術的負債返済プロジェクトの話に進む前に…技術的負債は(本来は)通常の開発プロセスの中で継続的に返済し続けなければならないプロジェクト化が必要になってしまうようなタイミングまで放置すること⾃体が誤り
twitter.com/toricls技術的負債返済プロジェクト の
Twitter.com/Toriclsカミナシの技術的負債返済プロジェクト - タイムラインJun Aug SepMayApr検討開始2022.04 下旬負債返済プロジェクト 第1弾2022.05.23 - 2022.06.30負債返済プロジェクト 第2弾2022.07.01 - 2022.12.31経営意思決定・全社説明2022.05 中旬Oct NovJul👆 イマココ何を意思決定したの？何を説明したの？具体的な中⾝は？具体的なn(ry何を検討したの？この辺は何を？
Twitter.com/Toriclsカミナシの技術的負債返済プロジェクト - 検討開始▶︎SWE ⼭⽥さん(仮名)「コードを触るのが怖い😱」▶︎僕のカミナシ⼊社(4⽉)よりも前に EM と会話した時点で技術的負債っぽい話は出ていた▶︎当時は「データベースやばい」「モノリスが(ry」のようなフワッとした課題認識だった (実際にはもうちょっと具体的)▶︎技術的負債と認識しているものをアクションに繋げられる粒度でチームメンバーにリスト化してもらった▶︎各アイテムを放置した際の技術・ビジネス両⾯での想定リスクや返済で期待される効果について⾔語化▶︎返済によって New Hire 戦⼒化までの期間短縮に貢献するかもざっくりと5段階評価で書いてもらった▶︎リストの中の「退職リスク度」というユニークなカラムが⾯⽩かった (⾯⽩かった)▶︎各アイテムのヤバさや⼼の⾟さ、対応コストなど複合的な要素をもとにまずはざっくり優先順位を決めた▶︎リストをもとに4⽉末から技術的負債の返済プランを検討開始▶︎何を、どういう順番で、どう⽚付けていくか▶︎優先順位だけではなく、アイテム間には当然依存関係が▶︎通常業務と並⾏して⽚付けられるか？ ≒ プロジェクト化の必要があるか？ ≒ 機能開発を⽌める必要があるか？▶︎5⽉下旬から6⽉末までの5週間、機能開発を⽌めてビジネスロジックを触らないリファクタリングを⼀気に⾏うことで決定(僕の中で)▶︎経営、投資家、社内のステークホルダにどう説明するか？Apr検討開始2022.04 下旬
Twitter.com/Toriclsカミナシの技術的負債返済プロジェクト - 経営意思決定▶︎「過去数ヶ⽉間で純粋な機能開発に使った時間」というファクトをもとに説明▶︎エンジニアリングのほとんどの時間が顧客問合せに基づく調査や不具合修正などの対応に使われていたという事実▶︎「ここのところ⼤きな新機能出せてないね」という認識は当然経営メンバーも持っていた▶︎メンバーへの開発プロセスについてのヒアリング結果やシステム状況を根拠として「中⻑期的な視点での要件定義や設計という観点が⾜りていない」「よりサステナブルなシステムとエンジニアリング組織にならなくてはいけない」というインプットを経営の中で継続的に⾏っていたことも効果的だったのかもしれない▶︎6⽉末までの5週間、機能開発と不具合修正をすべて⽌めて、負債返済プロジェクトにリソースを充てることで経営で合意▶︎顧客業務を⽌めてしまうクリティカルな不具合の修正と、障害発⽣時の対応は例外▶︎システムやエンジニアリングは苦しかったが、ビジネスそのものはちゃんと伸びてきていたことが CEO/COO/CTO の三者で合意・意思決定できた最⼤の理由かもしれない▶︎他にも残キャッシュや次の調達を⾒据えた話など、いろんな要素が複合的に(いい感じに)絡み合って意思決定まで持っていけた▶︎ラッキー✌May経営意思決定2022.05 中旬検討開始2022.04 下旬
Twitter.com/Toriclsカミナシの技術的負債返済プロジェクト - 全社向けの説明May検討開始経営意思決定全社説明2022.04 下旬2022.05 中旬▶︎全社集会で概要、必要性、返済後の未来について説明したスライドから⼀部抜粋 (権利関係と社内都合で残念ながら⼀部モザイクをかけています)▶︎いきなり全社向けに説明したわけではなく、特に影響が⼤きい Customer Success チームには事前に説明を実施▶︎想定される影響についての説明や、どうしてもお客様との関係性の都合から対応してほしい改修が⽣まれたときにどうするかの例外的プロセスについての定義などなど▶︎PM や CS といった距離の近いステークホルダが理解を⽰してくれたことも、意思決定できた⼤きな理由の⼀つ
Twitter.com/Toricls経営意思決定全社説明カミナシの技術的負債返済プロジェクト - 負債返済 PRJ 第1弾▶︎やること▶︎アプリケーション(フロントエンド & バックエンド)コードの必要以上の複雑さを取り除き、負債返済PRJ 第2弾以降でよりディープな技術的負債の返済に取り組むためのリファクタリング▶︎やらないこと▶︎ビジネスロジックは今は触らない▶︎インフラも今は触らない▶︎システム運⽤も今は特に変えない▶︎結果、いくつかの⼩さな例外を除き、機能開発や不具合修正を完全に⽌めて負債返済にフォーカスできた▶︎コード全体の認知負荷が⼀定程度下がり、触るのがちょっと怖くなくなった▶︎New Hire のオンボーディングコストも下がりそう▶︎エンジニアリングメンバーの精神衛⽣がよろしくなった▶︎(フロントエンド側の負債はより重みがあることもクリアになった)負債返済プロジェクト第1弾2022.05.23 - 2022.06.302022.05 中旬
Twitter.com/Toricls負債返済プロジェクト第1弾カミナシの技術的負債返済プロジェクト - 負債返済 PRJ 第2弾(イマココ)▶︎第1弾との違い▶︎機能開発のような通常業務と並⾏して負債返済を実施する▶︎通常業務(機能開発、不具合修正、問い合わせ対応、システム運⽤など)と、負債返済(incl. 運⽤改善)の時間の⽐率は 5:5 というルール▶︎事前に定めた「優先度の⾼い重要な技術的負債群」が⽚付き次第、通常業務の時間を増やしていく(というルール)▶︎第2弾期間のエンジニアリング組織としてのゴール▶︎『中⻑期的な価値を犠牲にせずに業務の6割の時間を純粋な機能開発に充てられるチームへ』▶︎7⽉からやってきた(やっている)こと▶︎アプリケーション側▶︎フロントエンド側はビジネスロジックまで含めた(重厚な)リファクタリングを実施中▶︎バックエンド側では機能・⾮機能要件の想定不⾜を補う負債返済に取り組み中。パフォーマンスイシューとかも。▶︎駆動していない OpenAPI を駆動させたい▶︎9⽉以降新たに着⼿すること▶︎インフラや運⽤やあれやこれや▶︎AWS 上のインフラやそのデリバリプロセスを整え、加えて「運⽤」を適切に定義して信頼性が⾼い運⽤モデルを⽬指す▶︎これに着⼿するために、AWS アクセス権限を適切に従業員に渡す仕組みは整備済み (AWS SSO, Control Tower, Organizations…)負債返済プロジェクト第2弾2022.07.01 - 2022.12.31- 2022.06.30
twitter.com/toriclsまとめ
Twitter.com/Toricls本⽇のまとめ▶︎技術的負債は継続的改善を前提としたシステムでは時間の経過とともに必ず⽣まれる▶︎当時は全⼒を尽くしたが、時間の経過とともに最適ではなくなってしまったものが技術的負債▶︎SWE ⼭⽥さん(仮名)「最初から分かってたら？そりゃこうは作らないですよ〜」▶︎⼿抜きの結果ではない▶︎ビジネスやプロダクトマネジメントのフェーズで存在した不確実性を、実⾏フェーズであるエンジニアリングでカバーした結果でもある▶︎ステークホルダ全員が真剣に向き合い、⾃分ごと化して取り組むことが必須。エンジニアリングだけの話にしない。▶︎だからこそ、技術的負債も機能開発などと同じリストのバックログアイテムとして管理し、その着⼿の優先順位をフェアに決めなければならない▶︎アクション可能なレベルで技術的負債の詳細と対応案をバックログアイテムに落とし込み、放置による影響や、対応で期待される効果、そして可能な限りその測定⽅法を⾔語化し切ることが、エンジニアリングの責任として⾮常に重要👋
kaminashi
palark
cybozuinsideout
aoshun7
murachiakira
bun913
kazuhitotakahashi
dahatake
sansantech
optimisuke
oracle4engineer
kojira
naohachi89
eileencodes
tmm1
holman
pedronauck
geeforr
bkeepers
zenorocha
chrisshort
mojombo
jonrohan
csswizardry
ddemaree