見出し画像
Photo by atelierminori

サーバサイドエンジニアから見た品質(Quality)の世界

くぼぴー

※全文無料です

こんにちは、kubopです。
もう2022年の年末、今年は奥深い品質の世界を垣間見ることができた1年でした。

2022年はサーバサイドエンジニアとしてリファクタリングをしたり、QAエンジニアとして品質についてガッツリ考える機会がありました。

私は新卒からずっとサーバサイドエンジニアとして働いていて、細かな不具合の修正から、機能追加、リファクタリングなどいろいろな経験をさせていただきました。Java・PHP・Rubyを主に利用していました。
まだまだサーバサイドエンジニアとしても未熟な点はありますが、基本的にヒアリングをしながら要件を伺い、仕様を決めて実装、テスト、リリースを行うというサイクルを繰り返していました。

そんなサーバサイドエンジニア出身の私から見た、品質の世界を書いてみようと思います。

品質の世界

「品質を上げたい」について

品質の世界は非常に奥深くて、そもそも何をもって「品質が良い」とするのかみたいな話からスタートします。
例えば今いる組織において、「品質を上げたい」というふんわりとしたWantに対し、「そもそもそれって何故ですか？現在何処にペインを感じていますか？」みたいな話からスタートしていくと思います。
なぜならば、個々に考える「品質」の概念がそれぞれ異なるからです。
各ステークホルダーごとにペインを感じる場所は違うし、QAに求めることも異なってくると思います。

例えば

技術的負債があり、なんとかヘルシーな状態にしたい。
不具合が増えてきていて、障害も発生しているのでなんとかしたい。

CTO目線？

とか

ビジネスのスケールに対応した高品質なプロダクトを作れる仕組み作りをしていきたい。
品質基準を作って全社に適用して外部に説明出来るようにしたい。

経営者目線？

とか

とりあえずQAに関してはよくわからないが、とにかく品質を上げたい。

誰目線？

などなど。

「品質を上げたい」は「なんでもやる」と近くて、こうはならない
ペインを特定してHowを適用し続けていくといいんじゃないかな

QA組織が出来ること

QAが専任で組織に就く場合、いきなり「テストを増やしましょう！」とかHowの施策を打つよりも、コンサルタント的に色々なWantを何故何故で紐解いていき、抽象化した上で各ステークホルダーの納得できるポイントを探って具体的な施策を打ち、効果測定をする必要があるなと思いました。

ちなみに売上N%達成！解約率N％減少！とかは効果測定にならないかなぁと思います。品質以外の影響要因が多すぎるからです。

ペインが不明確で不明瞭な場合、もしかしたらQA組織はまだ必要ないのかもしれないなと思います。

QA組織ができ、テストなどをしていくと勝手に品質が上がるというのは幻想だと思っていて、結局はQA組織がデータを取得、分析や対話をすることで、プロダクトやプロセス、現状を詳らかにしていき組織(全員)として何をしていくかによって品質(ステークホルダーが求めているもの)は良くなっていくんじゃないかと言う印象です。

QAは、QAとしてのスペシャリティを個人で発揮するよりは、巻き込んで品質をあげていくのがスペシャリティなのだと思っています。

品質の3つの観点

私は品質において、以下の3つの観点があると思いました。

  1. コード品質(内部品質)

  2. プロセス品質

  3. 振る舞いの品質(外部品質)

コード品質（内部品質）

内部品質は、ソースコードや仕様書、設計書などがそれにあたります。
その中で私はコード品質が重要なんじゃないかなと思っています。
プログラムは変更さえ無ければ一生そのままの状態で動き続けることができますが、修正や機能追加によって不具合が混入する可能性が生まれます。

これは、（一部を除き）不具合を混入させてしまった開発者が悪いというわけではなく、不具合を混入せざるを得ないアーキテクチャ側に一定の問題があるかもなと思います。

もちろん完璧なアーキテクチャなんて作れるわけがないのですが、それでも、不具合が出てしまった時点でアーキテクチャを小さくても改善し続けられるようにしたほうが良いかなと思います。

プロセス品質

プロセス品質は、開発手順やリリース手順などがそれにあたります。
仕様設計、それにおける静的テストなどの実行、CICDなんかも品質に関与していると思います。さらに言うと開発環境、検証環境など。検証のしやすさなんかもあると思います。DevOpsやアジャイルの領域の話も含まれます。

https://daipresents.com/2020/06/04/continuous-testing-in-devops/

振る舞いの品質（外部品質）

仕様通りに動いているか、とユーザーが求めている仕様かどうか的なことです。外部品質がそれにあたります。
一般的に品質は意味することが多いと思います。
各種テスト技法や受け入れテストで一定担保出来るような部分です。

品質をあげる時は3つの観点に着目する

ステークホルダーの発言から、この3つの観点のどの部分を指して品質と呼んでいるのか伺ってみるのが良いかもしれないなと最近は考えています。
CTO目線では、恐らく内部品質のことを指しますし、経営者目線ではプロセス品質、ユーザー目線では振る舞いの品質を指すことがあると思います。
それらをデータというファクトを元に現在どのような状態になっていて、どう持っていきたいのかで施策を練る必要があると思います。

QA兼サーバーサイドエンジニアとして出来ること

コード品質

サーバーサイドエンジニアから見ると、コード品質はデザインパターンやYAGNI、KISSの法則、SOLID原則、DDDやクリーンアーキテクチャなど、界隈ではコード品質を保つ事を「技術」として確立されています。

私はこれが非常に重要だと思っているのですが如何せん成長フェーズとなるとこれらの原則に沿わないコードが出てくるのは当たり前だと考えます。
しかしながら確実にこの部分がボトルネックになることが多いと思います。

コード品質は、低品質なコードであるより、高品質なコードであると開発生産性が高まり、不具合の混入が低くなるという研究結果が明確な事実としてあります。

これは開発者として肌で感じていた事で、可読性の低いコードや保守性の低いコードではどうやっても不具合は出てしまいます。検証不足もありますが、1行触ると大爆発みたいなことは普通にあります。

QAからすると開発者は不具合を起こしまくっているという印象があるかもしれないですが、不具合を起こすことが不可避なコードというのは存在すると思っています。
頻繁に不具合が発生している現場では、まずこちらの可能性を潰す施策をしたほうが良いかもしれません。

QAを齧ったサーバーサイドエンジニアとしては、アーキテクチャに着目した保守性の高いコードの追求・既存コードのリファクタリングということが出来るようになるかなと思います。

リファクタリングはもちろんテストありきなので、ここでも品質保証の知識が活きてきます。

プロセス品質

プロセス品質はサーバーサイドエンジニアから見るとあまり馴染み深くない分野だと思います。
これらは開発（主にコーディング）をしていく上ではあまり気にする必要がなかったからです。
仕様は実装しているその場で考え、後でレビューをしてもらい、CICDを通してリリースする、というサイクルを回しているだけで良かったです。

しかしながら、QA活動をしてみて、静的テスト・アジャイル開発というかなり重要な概念を知りました。要は仕様検討段階から検証フェーズを挟み込んでいき、どの段階でもテスト可能なプロセスにしていくこと、ベロシティを計測して工数を管理していくこと、対話によってステークホルダーの合意をとっていくこと。

リスクベースでのテスト設計、実例マッピングによる仕様のエッジケース洗い出し、TDDによるコーディングしながらのテスト、CICDに組み込む単体テスト、テストピラミッドによるどの層でどのロジックをテストするかなど、プロセスをブラッシュアップするのにやりすぎると言うことはないと思います。

サーバーサイドエンジニアとして活動していく上では、これらのプロセスを遵守して開発を進める、ということが出来るようになったかなと思います。
さらに言うと、これらのプロセスのブラッシュアップに寄与出来るようになれたかなぁと思います。

振る舞いの品質

サーバーサイドエンジニアからすると、この振る舞いの品質が一番遠い存在になっていることが多いです。何故ならば、受け入れテストをするのが自分ではない、或いは誰も行わない可能性があるからです。

仕様としてPMや外部ステークホルダーから言われた通りに実装し、それらが満たされている実装をしたという自負の元リリースを行うからです。

果たして本当に、受け入れ基準を満たしているのかどうかは明確に文章化されたり、必ずしも全ての現場で定義されているわけではありません。さらには、どういう振る舞いを行っているべきかのドキュメント構築をしてないことが往々にしてあります。

サーバーサイドエンジニアとして活動していく上で、振る舞いの定義をあらかじめ定め、正しい振る舞いを知っている方と協力し受け入れテストを実施し、さらにドキュメンテーションに落とし込むといったことがQA活動を通して重要だと言うことを知りました。

おわりに

サーバーサイドエンジニアがQAをすることは、非常に楽しくて持ち帰れることが多いと感じました。
もちろんデュアルに活躍出来ると幸せなことであるのですが、もし私がサーバーサイドエンジニアとしてQAの知識を用いて開発をするならば以上のようなことを気にして開発を進めていくだろうと思います。

QA専任、サーバーサイド専任、どちらかの状態であればここまで様々な分野に目が届くことはなかったと思います。
どちらも出来るということは、器用貧乏になるかもなと最初は思っていましたが、親和性が高くてどの知識も関連していて動きようによっては大きなバリューを発揮していけそうな気がしています。

多分、QAのみだと振る舞い品質に目がいき、
エンジニアだけだと内部品質に目がいくのではないかと思いました。
品質を上げるためには、全員を巻き込んで全てを包括する必要があります。

恐らくQAとエンジニアのサイロの原因は視点の場所の差です。
これらは対話によってある程度ならしていく必要があると思います。

オニオンアーキテクチャっぽい



こちらも是非読んでみていただけると嬉しいです。


ここから先は

0字

¥ 100

この記事が気に入ったらサポートをしてみませんか？