ログラスにおけるコード品質でビジネスに貢献する仕組み・カルチャー / A system and culture that contributes to business through code quality in Loglass

mtx2sさん・ログラス飯田さんと考える！コード品質が及ぼすビジネスへの影響
#コード品質_findy
https://findy.connpass.com/event/313471/

参考リンク

アジリティを支える品質特性
https://speakerdeck.com/twada/agility-and-quality-characteristics-developers-summit-2021-summer

強くてニューゲームなプロダクト開発
https://speakerdeck.com/yoshikiiida/product-development-in-new-game-plus

ログラスQAのミッション・ビジョン・バリューを策定しました（品質富士山について）
https://note.com/k_kotatsu1992/n/nd639aa4b5692

ログラスを支える設計標準について
https://speakerdeck.com/urmot/loglass-design-standards

ビジネスロジックを「型」で表現するOOPのための関数型DDD
https://speakerdeck.com/yuitosato/functional-and-type-safe-ddd-for-oop

SRP違反指数について
https://gihyo.jp/dev/serial/01/perl-hackers-hub/000803
https://ni66ling.hatenadiary.jp/entry/2015/06/25/013640

ログラスのセールスはプロダクトやテクノロジーへの関心が薄いと務まらないというお話。
https://note.com/matz0401/n/n1d508ab44f51

Transcript

1. 1 ©2024 Loglass Inc. ログラスにおけるコード品質で ビジネスに貢献する仕組み・カルチャー 2024/04/04 #コード品質_findy Yoshiki Iida
2. 2 ©2024 Loglass Inc. Profile Yoshiki Iida (@ysk_118) 株式会社ログラス シニアエンジニアリングマネージャー 2015年に株式会社クラウドワークスに入社。エンジニア、スクラムマスター、プロ ダクトオーナーを経て、2019年から執行役員として開発部門の統括を行う。現在 は株式会社ログラスにてソフトウェアエンジニアとしてプロダクト開発に携わった のち、1人目のエンジニアリングマネージャーとして事業と組織の成長にコミットし ている。
3. 3 3 ©2024 Loglass Inc. 企業価値を向上する
 経営管理クラウド

4. 4 ©2024 Loglass Inc. アジェンダ • コード品質の考え方 • コード品質を維持・向上させるための仕組み • アウトカムへの接続 • ログラスのビジネスサイドの声 • コード品質を支える組織文化 ⚠再現性のある話ではないです
5. 5 ©2024 Loglass Inc. コード品質の考え方
6. 6 ©2024 Loglass Inc. コード品質→内部品質→保守性 • コード品質を考える際には、ソフトウェア製品の品質モデルのうちの保守性 (maintainability)で考えると良い • 品質副特性としては、 ◦ モジュール性(modularity) ▪ システムのコンポーネントへの変更が、他のコンポーネントに与える影響を最小限に抑えるように構成されている度合い。 ◦ 再利用性(reusability) ▪ 作業成果物が、複数のシステムで使用できたり、他の作業成果物の作成に利用したりできる度合い。 ◦ 解析性(analyzability) ▪ コンポーネントやシステムへの一つ以上の意図的な変更の影響、欠陥または故障原因の診断、修正箇所の識別について、 コンポーネントやシステムを評価できる度合い。 ◦ 修正性(modifiability) ▪ コンポーネントまたはシステムの品質を低下させることなく変更できる度合い。 ◦ 試験性(testability) ▪ コンポーネントまたはシステムに対するテスト条件が確立できている度合い。そしてテストを行い、テスト条件が確立されて いるかどうかを判断できている度合い。 ※ https://glossary.istqb.org を参考に記載
7. 7 ©2024 Loglass Inc. アジリティと保守性 アジリティを支える品質特性 / Agility and Quality Characteristics Developers Summit 2021 Summer ( https://speakerdeck.com/twada/agility-and-quality-characteristics-developers-summit-2021-summer?slide=24 ) →変化に対応できるように することがアジリティ （そのために保守性の向上 が重要）
8. 8 ©2024 Loglass Inc. 遠くまでいくための保守性 強くてニューゲームなプロダクト開発 / Product development in new game plus #RSGT2022 ( https://speakerdeck.com/yoshikiiida/product-development-in-new-game-plus?slide=19 ) 早くリリースできるけど 2年後に死ぬシステム vs リリースは少し時間がかかる けど10年生き残るシステム どっちがほしいですか？
9. 9 ©2024 Loglass Inc. 組織全体で品質に向き合うマインドを育てる • 品質はコード品質だけではない • また、品質はQAだけが守るものではない • 開発組織全体で品質に向き合う • QAは組織の文化を育てる ログラスの品質富士山 https://note.com/k_kotatsu1992/n/nd639aa4b5692
10. 10 ©2024 Loglass Inc. コード品質を維持・向上させるための仕組み
11. 11 ©2024 Loglass Inc. 設計標準 ログラスを支える設計標準について / loglass-design-standards ( https://speakerdeck.com/urmot/loglass-design-standards )
12. 12 ©2024 Loglass Inc. 設計標準 • 今あるコードはあくまでそのコードが書かれた時のコンテキストにおいての最適 • コンテキストが変わればコードのあるべき姿も変わる • 常に考えてアップデートしていくことが推奨されている ビジネスロジックを「型」で表現する OOPのための関数型DDD ( https://speakerdeck.com/yuitosato/functional-and-type-safe-ddd-for-oop ) 結果的に創業時のコードの考え方 からさらに進化した考え方が組織 の中で生まれ続けている
13. 13 ©2024 Loglass Inc. 技術的課題解決スクワッド (Spotifyモデルのスクワッドとは別概念なのでややこしいが )チーム横断の技術的課題に立ち 向かうためのチーム
14. 14 ©2024 Loglass Inc. コードの外観をとらえる コードの総量とSRP(単一責任原則)違反指数※の集計によって状態を可視化する • SRP(単一責任原則)違反指数 ◦ SRP＝R＋U＋((L/100)－5) ▪ R：修正リビジョンのユニーク数 ▪ U：修正ユーザのユニーク数 ▪ L：モジュールのライン数 • 人数増加、コード量増加に対して SRP違反指数の 増加を抑え込めている （平均だけでなく分散もみることで Fatなコードのばら つきをみている） • 年単位で推移をみることで組織の変化にコードベー スが追従しているかが把握できる ◦ 過去の現場と比較してまだいけるか？分割し がほうがいいか？などの議論がしやすくなる ※SRP違反指数について https://gihyo.jp/dev/serial/01/perl-hackers-hub/000803 https://ni66ling.hatenadiary.jp/entry/2015/06/25/013640
15. 15 ©2024 Loglass Inc. アウトカムへの接続
16. 16 ©2024 Loglass Inc. コード品質がいいこととビジネスの成長って相関あるの？ • 「1日リファクタリングすれば今後の開発速度が◯ %向上するのでやらせてください！」 ◦ というような約束をしてはいけない • 「コード品質がいいから早く作れる」はそうとも言えるが、定量的な説明はできない ◦ なぜなら、同じコードでも、 ▪ 誰が実装するかで速度は変わる ▪ トラフィックやデータ量など状況次第で非機能要件が変わる ◦ 変数が多いので一律のロジックでは約束ができない • そして、開発速度が上がったからといってビジネス的に成果となるかはわからない コード品質 アジリティ アウトカム
17. 17 ©2024 Loglass Inc. じゃあどうするか？ 「ゴール達成の責任を持つ」 • 例えば「このお客様のこの課題をいつまでに解決したい」に対して責任を持 ちます、ということ • そこに至るプロセスはエンジニアを信頼してもらい任せてもらう • ゴールで合意することでHowであるコード品質の取り扱いはエンジニアが責 任を持ってマネジメントする状況を作る
18. 18 ©2024 Loglass Inc. お客様・ユーザーへの説明責任と技術的な不確実性への相互理解 • しかしながら、ゴールの合意をしたところで、不確実性は存在する • したがって、開発していく中で新たな問題が発覚し、期日に間に合わせられないということは発生 しうる • それゆえ、開発とビジネスの相互理解があったほうが組織全体のアジリティは高くなる • 開発視点では、 ◦ 問題が発生したらその問題についてわかるように説明する ◦ フロントに立つ人の視点でビジネスインパクトを理解し、プロセスを検討する • ビジネス視点では、 ◦ お客様・ユーザーに説明できるレベルのシステム理解やプロダクト理解は必要 開発を進めた結果もう少 し時間がかかることがわ かりました。 期日までに出せないと チャーンしてしまいます ね・・ 低アジリティ Aで開発を進めた結果XXが原因でもう少 し時間がかかることがわかりました。Aが 出るまでの間Bの回避策は取れますがど うでしょうか？ XXはお客様向けにはYYと説明します があってますか？Bでも説明できるし、 Cが可能であればそのほうがよりいい です。 高アジリティ → 変化への適応力が高ければアウトカムに至る可能性も高くなる
19. 19 ©2024 Loglass Inc. ログラスのビジネスサイドの声
20. 20 ©2024 Loglass Inc. アンケートを取りました • ログラスの開発チームのアウトプット（機能リリー ス）は全社の事業目標の達成に良い影響を与えて いると感じますか？ • ログラスの開発チームのアウトプット（機能リリー ス）はあなたの売上目標（もしくはKPI）の達成に良 い影響を与えていると感じますか？ • （ログラスにおける）技術的負債やコード品質につ いてあなたの知っていることを教えてください。ま た、なぜそれを知っているか理由も教えてください。 • 開発チームが技術的負債を解消したい、もしくは コード品質を向上させるための時間を取りたいと 言ってきたらどのように感じますか？ここまでは許 容できる、これ以上は許容できないといった基準は ありますか？ → セールス・CSメンバー9名が回答してくれました
21. 21 ©2024 Loglass Inc. 事業目標に良い影響を与えていると感じるか？ 60%が全社の事業目標に良い影響を与えているに満点回答している。 個人の売上目標に対しては 30%が満点回答している。
22. 22 ©2024 Loglass Inc. 技術的負債やコード品質への理解 技術的負債には、リリーススピードを優 先するために意図しているものと、意 図せず負債となっているものがある。 昔読んだ記事に書いてあった。 ITコンサルタント、カスタマーサポート 対応経験が長く、業務システムにおけ るコード品質などがお客様の業務停止 に非常に大きな影響を与えることを 知っているため 優れた処理速度を有している事を知っ ている。WinSessionや各種発信でパ フォーマンスや改善の発信がなされた ことにより、技術的な事項ではなく概要 として知っている。 技術的負債を作らないように、意思決 定をしていると最初の研修で聞いて感 動してました。また、記事で過去負債を 解消するために布川さんが意思決定し た話も読みました。 一般的に(?)開発の方々できれいな コードを書く方とそうでない方がいらっ しゃることと、そうでない方が組織から 抜ける場合にメンテナンスなどが大変 になるということは理解しています。 技術的負債を抱えていない方が長期 的に開発・リリーススピードが上がると いうこと。 入社前から布川さんのPodcastを聞 き、エンジニアバックグラウンドではな い代表が、その必要性を大事にしてい る、ということを認識していました。 記載できることがありません なし （エンジニア並みの解像度の意見）
23. 23 ©2024 Loglass Inc. 負債解消や品質向上への捉え方 解消した場合、しない場合の開発ス ピードの向上について説明があれば 許容できる。 例えば、XXXの機能をクローズする、 しないによって、この新機能のリリー ス時期がこれだけ変わります、といっ た説明があり、それに大きなメリットが あれば許容できる。 リファクタリングは実施すべき。特に XXXの機能を拡充し、XXXとYYYにつ いて同じ基盤にしていただいた上で拡 張性をそれぞれでできるように実施し てほしい。 この部分が技術負債として強く影響す る可能性は高いため、早期に手を付 けるべきと考える。 積極的に進めてほしい。もちろん新規 開発・機能改善開発のスループット・ア ウトプットとの兼ね合いではあるが、か なり許容・擁護する立場に回ると思う。 嬉しいです。それによりユーザーの不 満解消に繋がるのであれば非常にあり がたい動きだと感じます。 プロダクトの向上は売上の向上に直結 すると考えているので、前向きに協力し たい。毎週の定例MTG程度であれば 違和感無いが、それ以上の工数となる と目標として持ちたい感覚。 それでプロダクトが良くなる（アウトプッ トのスピードやデータ保持量の向上）が あるなら許容できる 基本的には必要なことだと思うので、 少し開発を止めてでもやるべきだと思 います。ビジネス側の目標とのバラン ス次第なので、この情報だけだとなん ともですが、ビジネス目標が耐えられ るのであれば、半年開発できない、と なっても許容できると思います 技術負債を解消したい、またはコード 品質を向上させるためにどの程度の 工数がかかり、中長期も含めてどのよ うなインパクトがあるかと会社の状況 によって良いと感じるかどうかは異な る気がします。そのため、明確な基準 はありません。 将来のためであればポジティブに受け 入れられます
24. 24 ©2024 Loglass Inc. サマリ • 少なくともアンケート回答いただいたメンバーからは概ねポジティブな意見 • プロダクトの貢献度は全体＞個人となった ◦ 担当するお客様の属性によって刺さり具合が異なるため • 技術的負債とコード品質の理解はばらつきがあった ◦ もしくは設問が悪かった ◦ 前職までの経験で解像度が高い人がいた ◦ 社内の取り組みからもインプットの機会として有効に働くものがあった ▪ ブログ記事 ▪ 入社時研修 ▪ WinSession • 負債解消・品質向上については概ねポジティブ ◦ ロジカルな説明は求められていると感じた
25. 25 ©2024 Loglass Inc. コード品質を支える組織文化
26. 26 ©2024 Loglass Inc. エンジニア側からコミットしていること 「ビジネス目標を達成するために最適なコードを書くこと」 • 早くリリースでき • バグがなく • ユーザーの課題を解決できていること を達成する必要がある。 コードを書く人がビジネスのことをわかっていて、 コードに最も詳しいという信頼があれば、 その人に任せるのが最も良い結果に辿り着ける選択肢になる。
27. 27 ©2024 Loglass Inc. エンジニア側からコミットすべきこと 「ビジネス目標を達成するために最適なコードを書くこと」 • 早くリリースでき • バグがなく • ユーザーの課題を解決できていること を達成する必要がある。 コードを書く人がビジネスのことをわかっていて、 コードに最も詳しいという信頼があれば、 その人に任せるのが最も良い結果に辿り着ける選択肢になる。 ここはコード品質（保守性）を上げることで向上できる →ここはドメイン知識・リサーチ・ 仮説検証などで向上できる
28. 28 ©2024 Loglass Inc. ビジネス側のありがたいスタンス セールスマネージャー松倉のnote https://note.com/matz0401/n/n1d508ab44f51
29. 29 ©2024 Loglass Inc. 経営レベルでの信頼関係 • ログラスの原点は、創業時のマンションの一室 でやっていたCEOとCTOのドメインモデリング • 価値のあるプロダクトを作るためにお客様を理 解し、最適な設計を行い、実装し、さらに改善し ていくというプロセスがあった • この信頼関係が採用基準にも強く影響し、現在 の組織に繋がっている
30. 30 ©2024 Loglass Inc. まとめ • コード品質がビジネスインパクトに与える影響の構造を理解する • コード品質だけではない広い視点での品質の構造を理解し、組織で向き合う • 品質を向上させるための横断的な取り組みを後押しする • 管理のためではなく計測するために指標を使う • 事業を成功させるために部門を超えた相互理解を進め、リスペクトをもってコミュニケー ションする