質とスピード ~講演を聞いて~
twada さんの「質とスピード」講演を聞きました
先日の話になりますが、社内イベントに twada さんが登壇され、オンラインで参加してきました。タイトルは「質とスピード」でした。
複数の会社で同タイトルで講演されているようで、スライドがネットにもアップされていました。
開発者が普段から感じていそうな小ネタを挟みながら、軽快に分かりやすくお話されており、非常に楽しく勉強させていただきました。
大まかに学んだことを列挙します。
- 「質」とは超抽象的は単語であり下位の概念へブレイクダウンできる
- 世間的には「保守性」と「スピード」はお互いに負の相関があると見なされがちだが、実はお互いに正の相関
- 自動テストや内部品質への投資の損益分岐点は年単位ではなく月単位で現れる
「質」に対して注力することのメリットがとても分かりやすく説明されており、
他者理解を得たい場面では引っ張り出してきてでも聞かせたいと思うような内容でした！
時間のある方はぜひ見てみてください！
社内スレの反応
twada さんは講演の際にリアルタイムの声を大切にしたいという思いがあるらしく、
今回も例に漏れず、社内に匿名のチャット欄が開放されていました。
よって、社内スレの反応をいろいろ見ていました。
講演内では、具体へ言及するスライドが無かった（時間の制約や対象者を考慮されているのだと思います）ため、以下のような意見がありました。
- 品質を上げていくメリットは分かったが定量的な測定方法が知りたい
- 品質向上に寄与している人やチームを適切に評価する方法が知りたい
- ジュニアメンバーを率いて品質を上げていくコツを知りたい
- 綺麗なコード（保守性の高いコード）の書き方を知りたい
- テスト自動化を推進する大切さは理解したが具体的な進め方のプロセスも知りたい
この中で、品質を具体的にどのように定量化するのかについて、私も興味が湧き、深ぼってみることにしました。
実際に IPA が出している文書を読んでみた
twada さんのスライドに登場する図のいくつかは IPA が出版されている PDF から抜粋したものでした。
以下ですね。
私も部分的にですが、資料を読んでみました。（一次情報にあたること大切という信念）
学べた点
学べた点としては、やはり、「品質」という定義を細分化して特性/副特性で分けられている点です。
以下の図は、「品質」を「製品品質」と「利用時の品質」に分けて、更にそれを細分化しているものです。（これらの図は twada さんの資料にも引用されていました）
単に品質を上げたい！！と言ったときに、どの品質を指しているのか、共通認識を得るために言語化できるというのは非常に大きなことだと思います。
今後、上司の方などと品質について話すときは、この図を意識しようと思いました。
共感できなかった点
IPA 資料の後半では、前半で説明した品質の定義を元に、それをどのように応用していくのか、またはトレースしていくのかという方向に議論が移ります。
もちろん"定量化"の説明も登場し、知りたかった部分や！！と思い、眼をかっ開いて読みました。
が、、具体的に提案されている"定量化"の方法が最新の開発プロセスと調和できるのかという観点で腹落ちしませんでした。。
資料では、定量化の考え方として、測定方法と算式、目標値、尺度を設定し、測定量を元に評価するという記述がされています。
しかし、例として挙げられて測定値が、バグ密度やバグ摘出率であり、他に具体的にどのような指標値を用いるべきかの言及はありませんでした。
新卒の時に最初に配属されたプロジェクトでも、この指標値を利用していたことがあるのですが、当時の感覚でも数字遊びをしているようにしか思えず、意味を見いだせずにいた値でした。
しかし、なぜ違和感を覚えるのか、言語化ができていなかったので、どのような開発プロセスが良しとされているのか見ていくことにしました。
主流な開発プロセスや米国巨大 IT 企業の考え方
ソフトウェア開発の 3 本柱
twada さんが Findy 主催のイベントでお話されている動画では、技術の 3 本柱は以下であるとされています。
- バージョン管理
- テスティング
- 自動化
私はこれを技術というよりはソフトウェア開発の 3 本柱として、以下のように解釈しました。
- バージョン管理
- プロセス自動化（CI/CD など）
- 自動テスト（単体テスト/結合テスト/E2E テスト）
この 3 本柱を揃えての開発が重要なのは直感的にも非常にわかりやすいと思いました。
米国巨大 IT 企業での開発プロセス
最近よく拝見する方で、牛尾 剛さんという方がいます。
『世界一流エンジニアの思考法』という書籍の著者の方ですね。
牛尾さんは米国巨大 IT 企業の 1 つである Microsoft に勤めており、Azure Functions を開発するチームに所属されているようです。
多くのイベントでお話されており、YouTube 上でもいくつか閲覧可能ですが、私は最近以下の動画を拝見しました。
こちらの動画によると、少なくとも牛尾さんのチームとその周辺では、標準ルールが策定されておらず、各チームが個別最適に自らで標準ルールを採択・実施できるようです。
技術に明るくないマネージャーとかがルールメイカーとして謎に多くの制約を開発者に対して課してくることはないということですね。
しかし、Azure は世界中で利用されているクラウドサービスであり、障害が発生した場合は全世界の企業に影響が及ぶ非常にミッションクリティカルなシステムです。
そのようなシステムでどのようにバグが流出しないよう品質を確保しているか、動画では以下の点が挙げられていました。
- 自動化 (Unit Test, CI, E2E Testing, Security, Deployment)
- Canary, Feature Flags
- Review (PR, Design)
- Bug Bash
Bug Bash は私も初めて聞きましたが、色々な方がそれぞれの立場でシステムを利用してみて、バグが無いかを確認するという手法のようです。
違和感の正体
バグ密度やバグ摘出率を品質の指標値として用いることの違和感が少し分かった気がしました。
そもそも、これらの値を算出するには、バグ内容を逐一記録しておく必要があります。
しかし、昨今で主流になっている手法が自動テストであることは、これまで見てきた通りです。
自動テストは一般的に開発のサイクルに組み込まれているものであり、長短あれどイテレーションの中で繰り返し実行されるものです。
その過程で、Red（失敗しているケースがある状態）と Green（全てのケース成功している状態）を行き来することになります。
そのようにイテレーティブに開発を進めていき、最終的に全てが完了した頃には、単体テスト/結合テスト/E2E テストの実行結果が全て Green となっているのです。
さて、上記のような過程で何をバグとして記録しておくべきなのでしょうか？
その記録されたバグは一体何を表しているのでしょうか？
バグ密度やバグ摘出率という指標は、製造業から輸入された概念と言われていますが、果たしてソフトウェア開発にも応用可能かどうか疑問符が付きます。
理想と現実
IT 技術者として働く場合には、以下のいずれかの企業で働くことになると思います。
- 自社開発企業
- 受託開発企業
そして、受託開発企業では、契約形態として請負契約と準委任契約があります。（詳細は割愛）
仮に受託開発企業で働いている場合は、クライアントに対して説明責任を負うことになり、その中で定量的指標を用いた説明が求められる場面も多いです。
テスト工程において、自動テストを用いることは必須レベルですが、定量的に品質の説明が求められる場合、何を指標にするか明確なベストプラクティスはまだ存在しません。
（コードカバレッジなどいくつか指標はありますが、参考程度にしかならない）
そのため、契約形態の中で定められたプロセスの中で、バグ密度やバグ摘出率など定量的指標を用いた説明を行う場面はまだまだ多いのかなと思いました。
終わりに
今回は、twada さんの「質とスピード」講演を受けて、個人的に気になった「品質の定量的な評価方法」について深ぼってみました。
明確な解は得られなかったのですが、「品質」について、改めて考えさせられる良い機会になりました。
個人的には、より品質の高いソフトウェアを開発していくために、自動テストについてはもっと学んで理解を深める必要あるなと、モチベーションが上がりました！
それでは！
Discussion