Slide 1
Slide 1 text
開発者が考える品質
加納 誠人
Slide 2
Slide 2 text
アジェンダ
● 品質とは
● 品質を上げる「○○○○○」ケーススタディ
● 品質を上げる「○○・○○」ケーススタディ
Slide 3
Slide 3 text
品質とは？
Slide 4
Slide 4 text
ソフトウェア
品質
サービス
品質
情シスが目指すべき品質は、2種類ある
サービス品質は、ITサービスマネジメントの領域なので、今回は割愛
そもそも品質とは？
Slide 5
Slide 5 text
Delivery
(納期)
Cost
（コスト)
QCDとは？
Quality
（品質）
Quality を維持するには？
Slide 6
Slide 6 text
単体テストを書きましょう
Slide 7
Slide 7 text
単体テスト
最大のメリットは、過去のテストを再利用できること
● 過去の品質を維持することができる
● デグレーションの防止
Slide 8
Slide 8 text
テストでは何をすべき？
正しさを証明する。裏を返すと…
→ 何が正しいかを定義しなければならない
1. 機械的な正しさ（例：無限ループをしない・想定外の値が入らない）
2. 機能要件を達成する
3. 非機能要件をなるべく達成する（達成し続けるには、データ量増大やアクセス過多など、保守する必要がある）
Slide 9
Slide 9 text
製造
プログラム設計
機能設計
要件定義
単体テスト
結合テスト
総合テスト
ユーザテスト
V字モデル
Slide 10
Slide 10 text
V字モデル
製造
プログラム設計
機能設計
要件定義
単体テスト
結合テスト
総合テスト
ユーザテスト
設定された値や判定が正しいか
プログラム同士が正しく接合するか
機能が正しく使えるか
要件が正しく達成されているか
Slide 11
Slide 11 text
「正しさ」をどのように見つけるか？
見つけるのはなかなか難しい
● 他人に伝えるには、言葉にする必要がある
● ドキュメントに残すには、文章や図にする必要がある
よく使っている方法を1つ紹介する
Slide 12
Slide 12 text
マインドマップ
マインドマップはトニー・ブザン(Tony Buzan)が提唱した思考・発想法の一つ。頭の中で起こってい
ることを目に見えるようにした思考ツールのこと。(Wikipediaより引用)
Slide 13
Slide 13 text
マインドマップの例
(非公開)
Slide 14
Slide 14 text
マインドマップはトニー・ブザン(Tony Buzan)が提唱した思考・発想法の一つ。頭の中で起こってい
ることを目に見えるようにした思考ツールのこと。(Wikipediaより引用)
マインドマップ
「放射思考」が一番のポイント
放射上に思考を展開することで、思考が狭まりにくい
● 1つの項目を一度に深く掘り下げない
● 中央から目線を回して順に掘り下げていく
● マップを作ることは手段でしかないので、フォーマットにこだわらない
Slide 15
Slide 15 text
アジェンダに戻ります
Slide 16
Slide 16 text
アジェンダ
● 品質とは
● 品質を上げる「○○○○○」ケーススタディ
● 品質を上げる「○○・○○」ケーススタディ
Slide 17
Slide 17 text
「単体テスト」ケーススタディ
Slide 18
Slide 18 text
ケース紹介
1. ムダな判定を混入させない
2. それ、本当に無限なの？
3. TDDをはじめる第一歩
Slide 19
Slide 19 text
ケース紹介
1. ムダな判定を混入させない
2. それ、本当に無限なの？
3. TDDをはじめる第一歩
Slide 20
Slide 20 text
ムダな判定を混入させない
ループに If 文を含めると組み合わせが大量に発生する
5回のループの場合…
32通り
2 × 2 × 2 × 2 × 2 ＝
Slide 21
Slide 21 text
本当に繰り返す必要があるのか？
よくあるケースは、
● 最初だけ処理をスキップする
● 最後のみ追加で処理をしたい
そんな時は…
Slide 22
Slide 22 text
ループを分割しよう
Slide 23
Slide 23 text
ループを分割する
LINQ を活用してループを分割する
● 最初と2回目以降の場合… First と Skip
● 最後のみの場合… Take と Last
Take と Skip を要素がなくなるまで繰り返すことで
N件ごとのページングも可能
Slide 24
Slide 24 text
ケース紹介
1. ムダな判定を混入させない
2. それ、本当に無限なの？
3. TDDをはじめる第一歩
Slide 25
Slide 25 text
それ、本当に無限なの？
限度がない機能要件や非機能要件は存在するのか？
● 1レシートに100万の商品記載がありますか？
● メモリが無限のPCが存在しますか？
→ 存在しない
可能な限り、限度を決める
Slide 26
Slide 26 text
ケース紹介
1. ムダな判定を混入させない
2. それ、本当に無限なの？
3. TDDをはじめる第一歩
Slide 27
Slide 27 text
TDDをはじめる第一歩
テスト駆動開発 (TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最
初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をと
りあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。
(Wikipedia より引用)
実際にやってみた結果…
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
ケース紹介
1. YAGNIとは？
2. 責務を分ける
3. 不変による防止
4. 判定のしきい値
5. 初期値に気を払う
6. 符号なし整数
Slide 33
Slide 33 text
ケース紹介
1. YAGNIとは？
2. 責務を分ける
3. 不変による防止
4. 判定のしきい値
5. 初期値に気を払う
6. 符号なし整数
Slide 34
Slide 34 text
YAGNIとは？
"You ain't gonna need it"、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよい
とする、エクストリーム・プログラミングにおける原則である。(Wikipediaより引用)
どうしてもコードに書かなければならない場合は…
Slide 35
Slide 35 text
タスク一覧を活用しよう
VisualStudio では、コメントの先頭に下記を付けるとタスク一覧ウィンドウで一覧化してくれる
● UNDONE: まだやっていない
● TODO: やる必要がある
● HACK: 目的は達成しているが、より良い方法がある
UNDONE が書きたくなった時は、単体テストを書く
マージまでに TODO を極力減らす → マージする際はその内容が妥当か検討する
Slide 36
Slide 36 text
チケットで管理しよう
チケット駆動開発 (TiDD) とは、プログラム開発手法の一種で、作業をタスクに分割しBTS（Bug
Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル。細かな修
正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高いことから、エクストリー
ム・プログラミングをはじめとするアジャイル開発でも実践されている。(Wikipediaより引用)
チケット ＝ Backlog の課題
Slide 37
Slide 37 text
ガントチャートの例
(非公開)
Slide 38
Slide 38 text
ケース紹介
1. YAGNIとは？
2. 責務を分ける
3. 不変による防止
4. 判定のしきい値
5. 初期値に気を払う
6. 符号なし整数
Slide 39
Slide 39 text
責務を分ける
クラスの責務を分けていれば、
証明する正しさがシンプルになる
「このクラスは○○ができていれば、テストOK」と
言葉に変換しやすくなる
Slide 40
Slide 40 text
ケース紹介
1. YAGNIとは？
2. 責務を分ける
3. 不変による防止
4. 判定のしきい値
5. 初期値に気を払う
6. 符号なし整数
Slide 41
Slide 41 text
不変による防止
中身をいつでも変えられるクラスは、
変えたときを想定したテストケースを作成する必要がある
中身が変わらない(＝不変)のオブジェクトは、
組み合わせが少なくなる為、テストケースが少なくなる
Slide 42
Slide 42 text
ケース紹介
1. YAGNIとは？
2. 責務を分ける
3. 不変による防止
4. 判定のしきい値
5. 初期値に気を払う
6. 符号なし整数
Slide 43
Slide 43 text
判定のしきい値
判定のしきい値(境界値)を決定する際には、細心の注意を払う
特に次の言葉が出てきたら、注意すること
● 以上・以下
● 上回った場合・下回った場合
途中式をローカル変数に代入して、わかりやすくしておくのも手
Slide 44
Slide 44 text
ケース紹介
1. YAGNIとは？
2. 責務を分ける
3. 不変による防止
4. 判定のしきい値
5. 初期値に気を払う
6. 符号なし整数
Slide 45
Slide 45 text
初期値に気を払う
変数に何も設定しない場合、
値型には型に応じた初期値が、参照型には Nothing (null) が設定される。
特に注意が必要な型は、 DateTime 型。
何も設定しない場合、西暦1年1月1日が設定される。
● DateTime? のように Null許容型にする
● 引数チェックで DateTime.MinValue と比較する
Slide 46
Slide 46 text
ケース紹介
1. YAGNIとは？
2. 責務を分ける
3. 不変による防止
4. 判定のしきい値
5. 初期値に気を払う
6. 符号なし整数
Slide 47
Slide 47 text
符号なし整数は使わない
UInteger 型などの 符号なし整数型 は使用しないこと
20億を越える値を扱う頻度 ＜ 負の値を扱う頻度
UInteger 型で 0 - 1 をすると、4,294,967,295 になる(アンダーフロー)
0付近を想定している処理に、
40億の値が投入したら、どうなりますか？
Slide 48
Slide 48 text
まとめ
Slide 49
Slide 49 text
品質ってなんですか？
Slide 50
Slide 50 text
● 目的によって、求められる品質は異なる
● コストや納期とは切り離せない
● 何が正しいかを考え、先に証明するテストを書く
● 今、必要でないものは追加しない
● 設計思想や開発者の意識で底上げすることが可能
Slide 51
Slide 51 text
ご清聴ありがとうございました