Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
何故ソフトウェア品質が大事なのか
Search
Shelfy.inc
January 23, 2023
Programming
0
170
何故ソフトウェア品質が大事なのか
シェルフィー株式会社の毎日LTより、好評だった回をご紹介しています。
エンジニアからビジネスサイドへ、技術的負債への取り組みについてわかりやすく説明しています。
Shelfy.inc
January 23, 2023
Tweet
Share
More Decks by Shelfy.inc
See All by Shelfy.inc
構造化の学びのすすめ〜どうやって僕らは問い合わせの一次対応しているのか〜
shelfy
0
200
【シェルフィー株式会社】会社紹介資料/hello-shelfy
shelfy
9
32k
Other Decks in Programming
See All in Programming
Djangoの開発環境で工夫したこと - pre-commit / DevContainer
hiroki_yod
1
180
WebフロントエンドにおけるGraphQL(あるいはバックエンドのAPI)との向き合い方 / #241106_plk_frontend
izumin5210
4
1.4k
React CompilerとFine Grained Reactivityと宣言的UIのこれから / The next chapter of declarative UI
ssssota
2
120
Contemporary Test Cases
maaretp
0
140
Realtime API 入門
riofujimon
0
150
.NET のための通信フレームワーク MagicOnion 入門 / Introduction to MagicOnion
mayuki
1
1.8k
TypeScriptでライブラリとの依存を限定的にする方法
tutinoko
3
710
Jakarta EE meets AI
ivargrimstad
0
230
リアーキテクチャxDDD 1年間の取り組みと進化
hsawaji
1
220
Modular Monolith Monorepo ~シンプルさを保ちながらmonorepoのメリットを最大化する~
yuisakamoto
6
530
Figma Dev Modeで変わる!Flutterの開発体験
watanave
0
150
Nurturing OpenJDK distribution: Eclipse Temurin Success History and plan
ivargrimstad
0
1.1k
Featured
See All Featured
It's Worth the Effort
3n
183
27k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Being A Developer After 40
akosma
87
590k
Designing for Performance
lara
604
68k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
430
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Scaling GitHub
holman
458
140k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Gamification - CAS2011
davidbonilla
80
5k
Transcript
何故ソフトウェア品質が大事 なのか for Biz
取り上げた理由
取り上げた理由 ・リファクタ(品質改善)って本当に大事なの? ・事業展開が遅くなる? ・急がばまわれや開発リソースの調整(同時並行PJの制限)などソフトウェア都合の何 かが存在するぞ〜、それって本当に事業に大事?
去年から今までのプロダクトチームの行動の理 由を改めて伝えたい
目次 ・一般論から見るソフトウェアとは ・シェルフィーのプロダクトチームの今
ソフトウェアの4大特性
ソフトウェアの4大特性 ・複雑性 ・同調整 ・可変性 ・不可視性 参考: 人月の神話
複雑性 ソフトウェアを構築するコードは数万、数 百万行に肥大していく。 また、各コードの関係性は複雑に絡み合 い依存関係は非線形に増大する。
機能の数や歴史に比例し必ず増え、コードの増 加や複雑性は避けられない
シェルフィーのプロダクト規模はどれくらい?
コード行数 26万行,ファイル数3500個 (インフラは除く)
同調整 ソフトウェアはあらゆるものに同調する必 要がある。 扱っている業界の知識(法律) 利用される機器 利用するユーザ 他のアプリケーションなどなど
ソフトウェアはユーザ以外にも思いを馳せる場所 がたくさんあるということ
特にユーザ要望部分はめちゃくちゃ大事で要望 を整理して伝えてくれている皆さんには感謝!
可変性 ソフトウェアは常に変化できなければなら ない 事業、ユーザ、技術的課題...etc 参考: ストラテジーと実装の一致
期待や外的要因による変化に応え続ける必要 がある
様々な軸からの攻守の要望!
不可視性 ソフトウェアはこうしたい(概念)を積み上 げた具体の塊! 積み上げの過程を目で見ることができ ず、簡易的な図などでしか表現できな い! なぜ実装したのか?なぜこのような方法 で実現したのか?などの意思決定や見え ない制約はコードからはわからない
作られたものから確実にこれが正しいという事実 が得られない
ソフトウェアは上手に作れば複雑じゃなくなる?
なんてことはないです!
None
ソフトウェアは複雑だからソフトウェア
複雑性を表すもっと身近な例
None
なぜ品質が大事?
高品質=上がり続ける複雑性の傾き、変化量を 小さくできているORできる状態
ある一定の品質を維持できなくなったら
事業的な理由からの舵を切りづらくなる
事業的な理由からの舵を切りづらくなる ・機能を追加するにしても、メンテナンスが行き届いていないと、実現に時間がかかりや すくなる→事業の変化スピードについて行けない
何も機能を追加できないソフトウェアになる 参考: 突如発表された『拡散性ミリオンアーサー』 サービス終了の真相を訊く
何も機能を追加できないソフトウェアになる ・複雑であるためコントロールできず、属人化が発生しやすくなる ・コアメンバーが抜けたら、誰もわからない ・バグやデグレードが発生しやすくなる
プロダクトチームが実施してきた、していること
プロダクトチームが実施してきた、していること ・開発効率の改善 by 知恵 ← エンジニアがアプリケーションを作ることだけに全集中で きる環境の整備 ・Kotlin化プロジェクト推進 by lennon ←
複雑化したコードベースを整えるためのルール の整備とそれの適用 ・Autifyの整備 by moe ← デグレードなどの検知タイミングを設けて、コード変更をよりし やすく
すべて増加する複雑性を抑えるため
例えば安全書類
安全書類 ・待望の施工体系図Previewの改善 ・Preview表示スピードがめちゃくちゃ速い&体系図が正しく表示される ・これもソフトウェアの品質改善で実現されている
例えば入退場の例
入退場
None
入退場 ・裏側の品質改善を進めていることで受けている恩恵(現時点で) ・UXの向上機能の簡単な実現 ・素早い一覧画面表示 ・反応の速いフォーム編集(Twitterのいいねみたいな反応の良いUI) ・もしメンテナンスをしていなかった場合は目の前実装になり実現できても壊れやすいも のになっていく、、、
持続的に事業に応えていく、ユーザに価値を届 け続けるためにリファクタ(品質改善)が必要