品質が高いコードって何？

by ICKX

Slide 1

Slide 1 text

「“品質”が高いコード」って何？同人ソフトサークル Project ICKX 若葉章 @effy_staffs (EFFY開発チーム)

Slide 2

Slide 2 text

自己紹介 • 若葉章（わかばあきら） • 2010年～同人ソフトサークル Project ICKX • プロデューサー / 営業 / インフラ / サーバサイド... / ゲームの実開発以外全部 • 本職はスタッフエンジニアっぽいこともするPHPエンジニア • PHP続けて20年 PHP3の頃からお世話になっています • 最近の趣味は自転車とアマチュア無線 • Tyrell IVEで東京湾一周したり • ICOM IC-705やID-52で移動運用試したり • Nintendo Switch で『VERTICAL STRIKE ENDLESS CHALLENGE』販売中 • Qiitaで『PHPで高速に・省メモリ・確実に日本語CSVを扱う方法』公開中 https://qiita.com/wakabadou/items/84b48ca12f25fb2fb69c 「composer require fw3/streams」をよろしくね。「composer require tacddd/tacddd」もよろしくね。

Slide 3

Slide 3 text

こういうの

Slide 4

Slide 4 text

宣伝私の知りうる限り最も妥当にSJISのCSVを直接扱えるライブラリ “fw3/streams “ 最新版にてZIPファイル内のCSVファイルを ”そのまま直接”扱えるようになりました。ぜひ使ってみてね。

Slide 5

Slide 5 text

こんな感じ。メソッドで種類を指定し、ファイルパスとZIP内のパスを記述するだけでOK CSVの設定はふつう！！注意！！foreachを使用しない巻き戻せないストリームのためここだけ定石から外れる

Slide 6

Slide 6 text

このプレゼンは工学士をお持ちの方が「えっ、それは常識では？」となる程度の非エンジニア向けの初歩的な知見をお楽しみいただく発表です。

Slide 7

Slide 7 text

「“品質”が高い」とは何でしょうか？

Slide 8

Slide 8 text

ぼんやり思われている「コードの“品質”が高い」 • 不具合発生件数が少ない・ゼロ • PHPUnitなどのxUnitツールを整備・継続的に運用している • テスト・ステージングなどの開発フェーズを用意している • 自動でテストさせている • テストを実施している • プロセス・テストなどの技法を用意・実施している • 高機能・多機能である • 多くの人が使っている・好印象を持っているものを使用している • 新しい・最新の技術・概念を使用している

Slide 9

Slide 9 text

それら “だけ”だったらば

Slide 10

Slide 10 text

「“品質”が高い」とは言えません

Slide 11

Slide 11 text

そもそも “品質” とは何でしょうか？

Slide 12

Slide 12 text

“品質”とは “対象”に“本来備わっている特性”の集まりが“要求事項”を満たす“程度” ISO 9000 (JIS Q 9000:2015)

Slide 13

Slide 13 text

ISO 25000で定義される “ソフトウェアの品質”では明示された条件下で使用するとき、明示的ニーズ又は暗黙のニーズを満たすためのソフトウェア製品の能力 ISO/IEC 25000:2014 (JIS X 25000:2017) 他にも色々あるので興味が出たら調べてみてね • 品質管理 ISO/IEC 25000 • 品質モデル ISO/IEC 25010 • 品質測定 ISO/IEC 25022 • 品質測定 ISO/IEC 25023 • 品質要求 ISO/IEC 25030 • 品質評価 ISO/IEC 25040

Slide 14

Slide 14 text

“品質”とは “先んじて定められた要求事項”に対して “どの程度、要求を満たしているか”が“品質”です。 “完了の定義をしろ、話はそれからだ” ってプロポーザルあったよね

Slide 15

Slide 15 text

つまり“品質”とは “要求を満たしていること”

Slide 16

Slide 16 text

よって、これらを実施しているだけでは「“品質”が高い」状態になる事はありません • 不具合発生件数が少ない・ゼロ • PHPUnitなどのxUnitツールを整備・継続的に運用している • テスト・ステージングなどの開発フェーズを用意している • 自動でテストさせている • テストを実施している • プロセス・テストなどの技法を用意・実施している • 高機能・多機能である • 多くの人が使っている・好印象を持っているものを使用している • 新しい・最新の技術・概念を使用しているそもそも下二つはただの教条主義なんで論外なんですけどね ※教条主義：権威者が述べた事を、その精神を深くも理解せず、杓子定規に振りまわす態度。

Slide 17

Slide 17 text

“要求事項”の話の前に “機能” について

Slide 18

Slide 18 text

“多機能”はさておき“高機能”とは • “品質”の定義にあった「本来備わっている“特性”の集まりが要求事項を満たす程度」 • そこにある“特性”の違いになります。個々の“特性”に “備わっているものの働きが優れていること”

Slide 19

Slide 19 text

“要求事項” とは何でしょうか？

Slide 20

Slide 20 text

“高機能”を提供しつつ“品質”を満たしている例 • JPEGは保存時に“Quality”パラメータを付与する事ができます。 • これにより“高Quality”な画質でも “低Quality” な画質でも保存する事ができます。 • より粗い画像は写真として低機能、より鮮明な画像は写真として高機能と言えます。 • ここだけでの使い勝手の良し悪しは品質ではないということです。 • どちらにしてもJPEGファイルフォーマット仕様を満たしているため、どちらの写真でもJPEGとして適当な品質を達成出来ています。

Slide 21

Slide 21 text

“要求事項”とは… “ニーズ又は期待” “明示されている、通常暗黙のうちに了解されている” “義務として要求されている” 又は

Slide 22

Slide 22 text

“要求事項”が対象とするものは • 認識しうる、考えうるもの全て • 製品、人、資源、変換率、プロジェクト計画、将来の組織状態、サービス、プロセス、組織、システムなど、物質的なもの、非物質的なものの何れかも問いません。 • 非物質的なものでIT業界でよく聞くものにISMS (JIS Q 27001) があります。 • ISMSの取得とは情報セキュリティマネジメントシステムとして定めたプロセスがISMSの求める要求事項を満たし、認証機関から認定を取得した事を示します。

Slide 23

Slide 23 text

“高品質” とは何でしょうか？

Slide 24

Slide 24 text

“高品質”とは • “定められた要求事項”に対して“要求を満たしている”ことです。 • 超過でも未満でもなりません。 • めっぽう忘れられがちですが、未満だけでなく、超過もダメです。

Slide 25

Slide 25 text

“高品質” を達成するには？

Slide 26

Slide 26 text

例えば業務上のレイヤごとに要求を明確化しそれを達成する • 例えば、自社サービスなら次の5レイヤが手を出しやすいです • 企画要求 • 設計要求 • 製造要求 • サービス要求 • あたり前要求 • それぞれ、前レイヤが定める要求に依存して、自身の要求が定まります

Slide 27

Slide 27 text

5レイヤごとの例 • 企画要求：企画で実現しようとしている特性に対する顧客の要求 • 顧客が想像すらできない、未来にありえる顧客の要求。車や家の広告にある、ライフスタイルの提案などが参考になる。 • 設計要求：企画を実現するために必要な特性の組み合わせの要求 • 新たに必要となる特性の水準や品質に対する要求。 • 製造要求：実装に当たっての達成すべき水準や機能に対する要求 • サービス要求：使い出、設定、サポートなど利用に対する要求 • 当たり前要求：当たり前過ぎて通常、暗黙に了解されている要求 • セキュリティや実行効率、法令要求事項、規制要求事項など • 非機能要件として”見えない化”されがち

Slide 28

Slide 28 text

「あれ？そうなると我々が日ごろ目指している “高品質なコード”って…」

Slide 29

Slide 29 text

そのままでは高品質足りえません。 • 繰り返しになりますが“品質”はまず要求ありきです。 • 経営層から達成すべき要求が提示され、初めて高品質を指向することができます。 • ここは特に重要な点なのですがコードの質の追求は経営課題です。 • 不具合の少ないコード、変化に追従しやすいコード、セキュアなコード。いずれにしても経営層がそれを必要とし要求しない限りは、“品質”の話自体を始めることができません。

Slide 30

Slide 30 text

なるほど！「納期さえ間に合えば良い」が正なんだ…

Slide 31

Slide 31 text

そんな訳はない • 経営層の品質マネジメント自体の質の話になります。 • ISO9001で要求される“顧客重視”の観点が抜け落ちていることになるからです。 • 例えばセキュリティ。 • 顧客は安全にサービスを利用することを暗黙的に要求しているのだから、このご時世においてセキュリティをないがしろにしたリリースは顧客からの要求に応えていないことになる。 • なお、それらを全部判った上であえて対応しないという経営判断もありえます。 • 「人の噂も七十五日、3ヶ月で株価が元に戻るならどうでもよくね？？？」

Slide 32

Slide 32 text

とはいえ弊意思決定層…

Slide 33

Slide 33 text

とはいえ弊意思決定層…

Slide 34

Slide 34 text

このそれぞれのレイヤにおいて要求を達成する “プロセス” 構築しそれを実施することで “高品質” を達成できるようになります

Slide 35

Slide 35 text

品質はプロセスに宿る

Slide 36

Slide 36 text

それは製品品質追求の話で、直接のコード品質ではないのでは？

Slide 37

Slide 37 text

そうです追求すべき品質は大きく製品品質と業務品質に分けることが出来ます

Slide 38

Slide 38 text

ここがごっちゃになるせいで今まで品質の話は大混乱に陥りがちでした

Slide 39

Slide 39 text

コードの品質を改善したくば業務品質の改善が必要となります

Slide 40

Slide 40 text

“業務品質”としてのコード品質を達成するには？

Slide 41

Slide 41 text

コントロール出来る所からはじめよう

Slide 42

Slide 42 text

”識者たる私たち”が定めることの出来る要求 • 例えばセキュア実装 • 私たちが定義するセキュアな状態をまず定義します • 定義したセキュアな状態を実現するために必要なことを列挙します

Slide 43

Slide 43 text

”識者たる私たち”が定めることの出来る要求 • 例えばセキュア実装 • 私たちが定義するセキュアな状態をまず定義します • 定義したセキュアな状態を実現するために必要なことを列挙します • 例えば… • XSSを実現できないことを要求します[MUST] • サニタイズは行いません[MUST] • 出力は全てescapeを行います[MUST] • escapeはコンテキストに依存しなければなりません [MUST] • そのためにコンテキスト境界を超える出力は許しません [MUST] 許されない例） $href = ‘href=“hoge.php”’;からの>

Slide 44

Slide 44 text

”識者たる私たち”が定めることの出来る要求はい、要求が1セットできあがりました。 • サニタイズは行いません[MUST] • 出力は全てescapeを行います[MUST] • escapeはコンテキストに依存しなければなりません [MUST] • そのためにコンテキスト境界を超える出力は許しません [MUST] 許されない例） $href = ‘href=“hoge.php”’ => >

Slide 45

Slide 45 text

これってコードレビューで指摘するようなことなのでは？

Slide 46

Slide 46 text

そうだよ

Slide 47

Slide 47 text

ただし、次の点が変わります予め定められた要求に依り要求の下に統治する

Slide 48

Slide 48 text

ただのガイドラインを止め明確に「する」「してもよい」「してはならない」を要求し要求を満たしているかどうかでコードの品質を測ります

Slide 49

Slide 49 text

個別最適な個人技から定められたプロセスに則った業務遂行へ

Slide 50

Slide 50 text

そしてコードレビューを実施すること自体も業務プロセスとして要求します

Slide 51

Slide 51 text

そうやって要求するプロセスを定義、積み上げる事で業務品質を向上する事が出来ます

Slide 52

Slide 52 text

定義すべき対象の指針はないの？

Slide 53

Slide 53 text

システム・ソフトウェア製品の品質モデル ISO/IEC 25010 (JIS X 25010) • 機能適合性 • 機能完全性 • 機能正確性 • 機能適切性 • 性能効率性 • 時間効率性 • 資源効率性 • 容量満足性 • 互換性 • 共存性 • 相互運用性 • セキュリティ • 機密性 • インテグリティ • 否認防止性 • 責任追跡性 • 真正性 • 保守性 • モジュール性 • 再利用性 • 解析性 • 修正性 • 試験性 • 移植性 • 適応性 • 設置性 • 置換性 • 使用性 • 適切度認識性 • 習得性 • 運用操作性 • ユーザエラー • 防止性 • ユーザインター • フェーズ快美性 • アクセシビリティ • 信頼性 • 成熟性 • 可用性 • 障害許容性 • 回復性

Slide 54

Slide 54 text

適切な要求と仕様がある前提で“高品質”を維持するには

Slide 55

Slide 55 text

“高品質”を維持する作業の例 • “要求事項”を“治具”にし“公差に収まっているかどうか” で “品質の適合度合いを自動的に測る” • 治具って何 • JIG。加工や組み立ての際、部品や工具の作業位置を指示・誘導するために用いる器具の総称。 • 同一形状の製品ならば高度な熟練技術を用いずとも製品のバラツキを最小限に抑え、迅速に大量生産することを可能にする。 • 公差って何 • 機械工学に代表される工学において許容される差のこと。 • 「その差の枠内に収まっていればOKです！」

Slide 56

Slide 56 text

“治具”として見るxUnit • PHPUnitをはじめとしたxUnitツール群は “治具”として活用することができます。 • プログラマが受けた要求を元に仕様をテストケースとして起こし、要求する枠内に収まっていればOK => まさに“治具” • 冪等性もあるので、なんどでも簡単に実施可能 => まさに“治具” • この観点でxUnitを見れば、だいぶテストケースも設計しやすくなります。

Slide 57

Slide 57 text

xUnitではどこまでやるべきなのか

Slide 58

Slide 58 text

まずは徹底して要求をテストコードに落とし込むこと

Slide 59

Slide 59 text

ごくふつうのテストコードでは？

Slide 60

Slide 60 text

あれ？そうなると境界値テストなどのテスト技法は…？

Slide 61

Slide 61 text

まず先に要求ありきです要求に対して適切な技法として境界値テストが選択されるという順番になります

Slide 62

Slide 62 text

まとめ品質が高いコードとは要求を満たしているコード

Slide 63

Slide 63 text

おさらい • 何らかのツールを使っている、KPIを設定しているだけでは品質が高いとは言わない • 品質とは要求を満たしていること • そのためまずは要求が必要 • 要求を満たし続けるためにはプロセス構築が必要 • 品質はプロセスに宿る • 出来る所から要求として文書化していこう • コードの品質の話をするためには製品品質から切り離して業務品質として話をまとめよう