何故ソフトウェア品質が大事なのか

Slide 1

Slide 1 text

何故ソフトウェア品質が大事なのか for Biz

Slide 2

Slide 2 text

取り上げた理由

Slide 3

Slide 3 text

取り上げた理由・リファクタ（品質改善）って本当に大事なの？・事業展開が遅くなる？・急がばまわれや開発リソースの調整（同時並行PJの制限）などソフトウェア都合の何かが存在するぞ〜、それって本当に事業に大事？

Slide 4

Slide 4 text

去年から今までのプロダクトチームの行動の理由を改めて伝えたい

Slide 5

Slide 5 text

目次・一般論から見るソフトウェアとは・シェルフィーのプロダクトチームの今

Slide 6

Slide 6 text

ソフトウェアの4大特性

Slide 7

Slide 7 text

ソフトウェアの4大特性・複雑性・同調整・可変性・不可視性参考: 人月の神話

Slide 8

Slide 8 text

複雑性ソフトウェアを構築するコードは数万、数百万行に肥大していく。また、各コードの関係性は複雑に絡み合い依存関係は非線形に増大する。

Slide 9

Slide 9 text

機能の数や歴史に比例し必ず増え、コードの増加や複雑性は避けられない

Slide 10

Slide 10 text

シェルフィーのプロダクト規模はどれくらい？

Slide 11

Slide 11 text

コード行数 26万行,ファイル数3500個（インフラは除く）

Slide 12

Slide 12 text

同調整ソフトウェアはあらゆるものに同調する必要がある。扱っている業界の知識（法律）利用される機器利用するユーザ他のアプリケーションなどなど

Slide 13

Slide 13 text

ソフトウェアはユーザ以外にも思いを馳せる場所がたくさんあるということ

Slide 14

Slide 14 text

特にユーザ要望部分はめちゃくちゃ大事で要望を整理して伝えてくれている皆さんには感謝！

Slide 15

Slide 15 text

可変性ソフトウェアは常に変化できなければならない事業、ユーザ、技術的課題...etc 参考: ストラテジーと実装の一致

Slide 16

Slide 16 text

期待や外的要因による変化に応え続ける必要がある

Slide 17

Slide 17 text

様々な軸からの攻守の要望！

Slide 18

Slide 18 text

不可視性ソフトウェアはこうしたい（概念）を積み上げた具体の塊！積み上げの過程を目で見ることができず、簡易的な図などでしか表現できない！なぜ実装したのか？なぜこのような方法で実現したのか？などの意思決定や見えない制約はコードからはわからない

Slide 19

Slide 19 text

作られたものから確実にこれが正しいという事実が得られない

Slide 20

Slide 20 text

ソフトウェアは上手に作れば複雑じゃなくなる？

Slide 21

Slide 21 text

なんてことはないです！

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

ソフトウェアは複雑だからソフトウェア

Slide 24

Slide 24 text

複雑性を表すもっと身近な例

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

なぜ品質が大事？

Slide 27

Slide 27 text

高品質＝上がり続ける複雑性の傾き、変化量を小さくできているORできる状態

Slide 28

Slide 28 text

ある一定の品質を維持できなくなったら

Slide 29

Slide 29 text

事業的な理由からの舵を切りづらくなる

Slide 30

Slide 30 text

事業的な理由からの舵を切りづらくなる・機能を追加するにしても、メンテナンスが行き届いていないと、実現に時間がかかりやすくなる→事業の変化スピードについて行けない

Slide 31

Slide 31 text

何も機能を追加できないソフトウェアになる参考: 突如発表された『拡散性ミリオンアーサー』サービス終了の真相を訊く

Slide 32

Slide 32 text

何も機能を追加できないソフトウェアになる・複雑であるためコントロールできず、属人化が発生しやすくなる・コアメンバーが抜けたら、誰もわからない・バグやデグレードが発生しやすくなる

Slide 33

Slide 33 text

プロダクトチームが実施してきた、していること

Slide 34

Slide 34 text

プロダクトチームが実施してきた、していること・開発効率の改善 by 知恵 ←　エンジニアがアプリケーションを作ることだけに全集中できる環境の整備・Kotlin化プロジェクト推進 by lennon ← 複雑化したコードベースを整えるためのルールの整備とそれの適用・Autifyの整備 by moe ← デグレードなどの検知タイミングを設けて、コード変更をよりしやすく

Slide 35

Slide 35 text

すべて増加する複雑性を抑えるため

Slide 36

Slide 36 text

例えば安全書類

Slide 37

Slide 37 text

安全書類・待望の施工体系図Previewの改善・Preview表示スピードがめちゃくちゃ速い＆体系図が正しく表示される・これもソフトウェアの品質改善で実現されている

Slide 38

Slide 38 text

例えば入退場の例

Slide 39

Slide 39 text

入退場

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

入退場・裏側の品質改善を進めていることで受けている恩恵（現時点で）・UXの向上機能の簡単な実現・素早い一覧画面表示・反応の速いフォーム編集（Twitterのいいねみたいな反応の良いUI）・もしメンテナンスをしていなかった場合は目の前実装になり実現できても壊れやすいものになっていく、、、

Slide 42

Slide 42 text

持続的に事業に応えていく、ユーザに価値を届け続けるためにリファクタ（品質改善）が必要