パルカワ2

最近はFlutterをやっています

チームが品質を作り込むために必要なこととは

ここ数ヶ月、品質やソフトウェアテストについて学んできた。本を読んだり入社予定のSET(業務委託中)と話したりしていて、学ぶ前の自分は品質保証を間違えて理解していたのだなと思うので共有する。

テストは品質を保証しない

2ヶ月くらい前の自分の中では、品質保証とは以下の図にあるテストの部分が品質保証にあたり、リリース前にテストすることで品質は保証される!と思っていた。

f:id:hisaichi5518:20220213024708p:plain
雑な開発ライフサイクル

しかし、たくさんテストをしてたくさんバグを発見したとしても、バグを修正せずにリリースされれば品質を保証したとは言えないし、見つけたバグをすべて修正したとしてもプロダクトにバグがないことの証明にはならないので完全に品質を保証することは出来ない。

テストは、欠陥*1に気付く手助けをしてくれてそれはリスク軽減にもなるが、根本的に欠陥を防ぐものではないし欠陥がないことを証明するものでもない。

品質保証とはなにか?

品質保証とは、開発チーム*2が「このプロダクトは品質が高い」と言える状態にすることだと思っていた。では、開発チームはどうやって「このプロダクトは品質が高い」と判断するのか?

品質とはを語るとき「品質は誰かにとっての価値である」というワインバーグの言葉がよく引用されている。プロダクトの品質において"誰か"とは顧客*3で"品質とは顧客にとっての価値である"と言える。

つまり、プロダクトの品質が顧客にとって高いかどうかを判断出来るのは顧客だけであって開発チームではない。なので開発チームだけで「このプロダクトは品質が高い!」と主張することは出来ないのではないかと思う。

Agile Testing Condensedを読んでいると「チームで品質を作り込む」「チームで品質に責任を持つ」という言葉が出てくる。品質保証とは、チームが品質を作り込み品質に責任を持つことであると自分の中では理解した。

ちなみにこのチームのメンバーは、エンジニア・デザイナー・PdMだけではない。テスターもCSもビジネスチームもパートナー企業もチームメンバーである。またQAエンジニアは、品質を作り込み責任を持つ人ではなくチームに対して品質を作り込むように促し同様に品質に責任を持つように促す人と僕は認識している。

品質を作り込む開発ライフサイクル

ではチームで品質を作り込むには、チーム全員で実装したものをテストするのがよいのか?といえばそうではない。実装したものをテストするにはテストするまで時間がかかるし、バグを見つけても修正するのに時間がかかる。時間がかかるということは、顧客に価値が届くまで遅くなってしまうし開発チームのリソースも奪い取りアジリティがあるとは言えない。またリリース後にバグの検出が出来ておらずそのまま放置されていたりしたら顧客にとっての価値を作り込めているとは言えない。

なので、リリース前にテストを行うのではなく開発ライフサイクル自体が品質を作り込む形になっている必要がある。

チーム全員が各ステージで"テスト"をする

品質を作り込む開発ライフサイクルは、チーム全員が各ステージ(要件定義・設計・実装・リリース等)でテストを行う。

テストを行うといってもテストケースを作ってテストすることだけがテストではない。そのステージでの成果物たちに対してレビューを行い質問などをすることもテストである。このテストをステージごとに繰り返す事でアジリティを持って品質を作り込む事が出来る。

最近の自分の例で言うと自分が実装する時に与えられた要求を頭の中で整理してそのままコードを書いてテストを書くのではなく、一旦実装しようと思っているものを仕様として箇条書きにしてパートナー企業に共有した*4。それに対してパートナー企業からフィードバックや質問が来るので、それに答えたり参考にすることで仕様のバグを見つけることが出来た。このパートナー企業がしてくれた質問やフィードバックもテストであり、実装前だがテストを行ってチームで品質を作り込んだと言える。

Holistic testing

品質を作り込む開発ライフサイクルについて書いていたが、アジャイル・テスティングを提唱したJanet Gregoryさんはチーム全員が各ステージでテストをすることをHolistic testingと呼んでいる。

f:id:hisaichi5518:20220211194443j:plain
Holistic testing

引用元: Testing from a holistic point of view - DragonFire Inc.

Holistic testingでは、テストが明確にステージとして定義されておらず、各ステージの中でテストが行われる。テストステージがなくなったことで、手動テストが完全になくなるのかと言えばそうではない。Buildステージでテストするだけである。

ちなみにもともとは継続的テストと言っていたっぽい。ただ継続的テストは人によって定義が違いそうでややこしいので個人的にはHolistic testingと呼ぶのがよい気がする。

まとめ

品質保証とはなにか自分の中で整理をしていたら、チームが品質を作り込み品質に責任を持つことが重要であると理解できた。そのためには、チーム全員が各ステージでテストを行う開発ライフサイクルである必要がある。

ちなみにプロセス品質というのもある。ここでは特に対象としてあげていないがプロダクト品質と同様にチームで作り込むことが重要な品質である。

関連

シェア用の画像 f:id:hisaichi5518:20220214093410p:plain

*1:いわゆるシステムのバグだけではなく、仕様バグや仕様の考慮漏れなども含む

*2:QAチームではない

*3:ここではプロダクトのユーザー

*4:共有はパートナー企業とやり取りしてる同僚がいい感じにやってくれたのだがとても助かった

Agile Testing Condensed Japanese Edition を読んだ

日本語版

Agile Testing Condensed… Yuya Kazama 著 et al. [PDF/iPad/Kindle]

買って読んでなかった。チーム全員で品質の作り込みチーム全員が品質に責任を持つことが大事でそれは継続的テストであるみたいな話からそれをどうやるのかが簡単に書かれている。最近仕様書について考えていてもうだめだと思っていたのだが、ここに書かれていたことは大変参考になった。

Notionでのドキュメント管理の何がつらいか

Notionでドキュメントを書いてる。ドキュメントは書く、共有する、読むなどユーザーそれぞれ色々なシナリオがあり、そのシナリオそれぞれでつらみがある。

Notionに限らずすべてのサービスは使っていればつらいところはあると思っていて、つらいとはいえNotionから別のドキュメント管理サービスに乗り換えたいという気持ちは全くなく何がつらいのか考えNotionでなにか出来ることはないか考えたり、つらみを共有することで知見を得たい。

検索がつらい

フロー型とストック型の情報が入り乱れる

検索をする時はストック型の情報を探すことが多い。例えば、リリース作業手順ドキュメントを探したいときに「リリース 作業 手順」で検索するけど日報や議事録などは検索から除外したい。

Notionの検索には、FilterでPageの指定が出来るのでそれを駆使するしかない。Pageの指定をした場合、Pageの配下は検索対象になるので、ストック型の情報を置くPageの配下にはフロー型のドキュメントを置かないのがよい。

Filterを追加するまでの道のりが長い

command + pでQuick Findを立ち上げて検索したい文字を入力、結果が出るまで数秒待ち、結果が出たら右上のAdd Filterをマウスでクリックして、Filterを追加する。

あまりにだるすぎるのでタイトル検索をしたい時はCommand+Eを使っている。自分のアクセスした履歴から高速に検索出来る。ただCommand+Eは今インストールできなくなっているようなので、Raycastなどを使うとよさそう。またこれは自分がアクセスしたページの検索なので、新しい情報を探したい時は歯を食いしばるほかない。

Only match titlesは親のページタイトルも対象となる

これは良いのか悪いのか。僕は嬉しいと思ったことはない。例えば「SWE採用」というページの配下にある「選考内容」というページは「SWE 採用」でタイトル検索すると検索結果に出てくる。

Quick Findを開いても、検索を実行してもURLが変わらない

つまり検索結果のURLが共有出来ない。

シノニム検索が出来ない

例えば採用関連のドキュメントを探したいと思って「SWE 採用」とかでタイトル検索して全然見つからない。実はタイトルには「選考」と書かれていた時には検索結果に出てこない。まぁこれは日本語だししょうがないよねという気持ちはある。

ドキュメントを書く人間たちが利用する単語を共通化していくしかないが、そんなことを考えながらドキュメントを書くのは大変。linterなどで自動化出来れば良いが後述の通りしにくい。

自前で検索サイトを持つのはやりすぎ感ある。

遅い

検索するたびに1,2秒くらい待ってて、そのくらい待てという話だけどGoogleなどで早い検索に慣れてしまっているのでつらい

構造の管理がつらい

最高でイケてる構造がわからない

ドキュメントって会社によって内容は違うだろうしベスト・オブ・構造が存在するのかは謎ではある。会社だけではなく職種によっても違うかも。会社もフェーズによって別の会社のようになるので定期的なリファクタリングは必要そう。プログラムと一緒ですね。

ドキュメントをどこに置けばいいのかわからない

AでもあるしBでもあるみたいなドキュメントが生まれたりする。Aの配下に置くかBの配下に置くか悩む。とりあえずAの配下に置いてBのページを参照したりするけど、別の人はAとの関連性をわかっておらず、Bにあると思って探して見つからない…となる。Notionにはbacklinksというのがあって、対象のドキュメントを参照しているドキュメントを確認出来るので、Bのbacklinksを見れば発見することは出来るが、クリックしないと見れないしBにあると思ってるのでわざわざ見ない。

どこに置くべきかわからなかったらまずは「メモ」というDatabaseにページを作って書くようにしてる。でも結局書き終えたら移動する必要がありそこで困って結局メモに置きっぱなしになってしまいストックできない。

こうなるとやはり構造を見直すしかない気がする。

ドキュメントを構造化するのであれば参照関係が複雑になると大変な気がする。プログラムの設計で単一方向のデータフローがどうこうみたいな話に似てると思った。子ページは自分より上のページを参照するべきじゃないみたいな。しかし、ドキュメントって参照関係生まれがちだよなぁ

書くのがつらい

更新に意味を持たせられない

更新履歴はあるけどcommitという概念はないので変更を意味のあるひとまとまりに出来ないしcommit logが書けない。commit logがあればなぜその行を追加したのかの理由を書けるけど書けない。あとから見た時に、はて?となる時がある。

その行を追加する理由をドキュメント自体に書けばいいのかもしれないけどドキュメント自体にそれは不要で冗長になる印象

gitに慣れているからというのはありそう。

ドキュメントに対してエラーを出しにくい

GitHub Actionsみたいなのがないので変更があったらlintを実行してダメならエラーを出すみたいなのがしにくい。例えば、仕様書で特定の曖昧な言葉があった時に警告を出すみたいなの。もしかしたらNotion APIで出来るのかもしれないのでしにくいと言ってる。試していない。逆にZapierと連携出来たりするのは楽でいい

ドキュメントのステータスがわからない

タイトルにWIPをつける人もいればつけない人もいる。tagでステータスの管理をすればいいけど必須には出来ないし、ドキュメントのDatabaseによって管理されたりされなかったりするので困る。

ドキュメントのステータス管理を統一するのがいいのかもしれない。

更新しやす過ぎる

更新しやすいのでレビューを通らずに更新できたりもする。

また更新しやすいゆえに間違えて更新/削除してるときもある。こういうのは大体更新履歴を見ればわかるけど更新履歴が積み上がってわからないとき困る。

レビューがつらい

レビュープロセスが必須ではない

権限があれば誰でもどこにでもドキュメントを置ける。ドキュメントの中身のレビューもしたいが、ドキュメントをどこに置くかという観点でのレビューも当然出来ないのでカオスになりやすい。

どこが変更されたのかわからない

更新履歴はあるにはあるけど、意味があるまとまりではないし、Diffは出ないので自分の目で確認するしかない。

どこが変更されたのかわかりやすいように新たにドキュメントを書いたりするが、新しいドキュメントを書いてる途中はどっちが正しいのかわからなくなる。

変更に意味を持たせられないのでどういう意図の変更なのかわからない

書いてる通り

レビューのStatus管理などレビューの仕組み自体を自分たちで考える必要がある

書いてる通り

文章につけたコメントは文章を削除すると一緒に削除される

コメントで議論したり変更した理由を文章を引用してコメントに残しても文章を消すとコメントは消える。

まとめ

後半、つらいところだけになってしまったがいい感じになりたいのでいい感じになる方法があったら教えてください。

イシューからはじめよ ― 知的生産の「シンプルな本質」 を読んだ

最近仕様書について考えてて原点に立ち返るか…と思ったので今更だけど初めて読んだ。

本の内容は、最初から解の質にこだわるんじゃなくてまずはイシュー度から取り掛かろうという話で、まぁそうだよねみたいな内容が書かれてる。後半はチャートとかについて書かれてたので自分ごとだと思えずあんま集中して読めなかったけど、悩むと考えるの違いなど「なるほどな〜」と思うことが書かれてたりしていてよかった。

 僕の考えるこの2つの違いは、次のようなものだ。 「悩む」=「答えが出ない」という前提のもとに、「考えるフリ」をすること 「考える」=「答えが出る」という前提のもとに、建設的に考えを組み立てること

あと「知りすぎるとバカになる」もたしかにと思えていて、知りすぎるとそのことに囚われてしまうみたいなのがあると思う。最近読んだ問いかけの作法にも「とらわれ」があると新しい発想が生まれにくくなると書かれてたけど、そういうことだよな〜と思いました。

新居の鳩襲来問題

今回の家は斜め前のマンションが僕の部屋より少し高いくらいのマンションでそこの屋上に鳩が止まったりしている。そのマンションの住人も多少対策はしていて、屋上にカラスの置物とか置いてるけどあまり意味をなしてない(ただ風でカラスの置物が動いてるときは鳩が来ない気がする)

基本的にそこを経由して僕の部屋のベランダの手すりに止まって、貯湯機の上にある室外機の横を通って、貯湯機と室外機の間に収まるようである。

鳩まあかわいいところもあるが足跡を残すし糞を垂らすしで汚いし、巣を作られるとかなり厄介らしいので見つけ次第早めに対策するのがよいらしい。

また方針として鳩を傷つけそうなトゲトゲとかは自分も刺さりそうだし鳩も痛そうなので設置する気はなかった。

鳩の侵入経路確認

まず鳩の侵入経路を把握してから対策するのがよいだろうと思ったので、前から持っていたけど持て余していたAtom camで動体検出をONにして録画した。ベランダに電源がなかったのでベランダに面した部屋から撮影した。また動画を見てる感じ1分ほどしか滞在していないのでまだ鳩も休憩に使ってるくらいで対策するなら今だと思った。

ベランダの掃除

糞があったり汚れたりすると鳩は来るらしい。カビキラーがあったのでそれで掃除した。そんなぐちゃぐちゃにはなってないので、鳩が来る来ないで言えば意味はないと思うけど人間としてはまあ綺麗な方がいいよね…みたいな感じ

ベランダの手すりにテグスを張る

正直なところテグスを張っても関係なしに止まるだろうと思っていたのだけど効果があった。1ヶ月ほど経ったけどテグスがある場所にはまだ止まってない。

ただ手すりに止まらずに空中でバタバタして周りを確認したあとに貯湯機の上にある室外機の横を通って貯湯機と室外機の間に収まるようになってしまった。

またテグスを張るのは最低限にしたいと思って鳩が止まる場所に張ったのだが数日後にはテグスの横に止まられた。許さん

ネットを張る

本当は貯湯機の上にある室外機の横にネットを張りたかったのだけど、高さがあり下手したら僕が死ぬな…と思ったので貯湯機と室外機の間をネットで張った。

これはあんまり意味がないと思いながらやったけど、やっぱり意味がなくて動画で確認するとやはりエコキュートの貯湯機の上にある室外機の横を通って入っていた。ただ動画では出ていったところの撮影がされておらず、どうやって出ていったのかは謎

鳩の忌避剤(スプレー)

あんまり効果がないだろうと思いつつも買った。臭くはないけど強烈なローズ系の香りがする。強烈なので近隣住民が洗濯物を干してるときにやると鳩は追い返せても近隣住民にブチギレられそうだと思ったので昼はやらずに周りが寝静まった深夜にやってる。また僕は基本衣類を干さないのであんまり気にしないけど干す人だと気にしそう。

これを2日ごとに貯湯機の上にある室外機の横と手すりに散布したところ、最初の1回だけ室外機の横にすっぽり入ってたけど相当嫌だったのかその後は直接入っておらず手すりに止まるようになった。ただ手すりにもテグスと忌避剤を散布しているので、止まろうとしてやっぱやめとこ!みたいな感じで追い返せている。

2日に1度散布しなければならないので少しめんどくさいのとローズ系の香りで近隣住民にキレられないか不安ではあるが、1週間ほど鳩はベランダに止まってない。3日ほどは手すりには止まろうとしていたのでテグスを張ろうかと思っていたけど、そもそもベランダに寄り付かなくなってきている。(近くを飛んではいるので散布はやめていない)

まとめ

スプレー型の忌避剤で駄目ならジェル型の忌避剤があるらしいのでそれを使う手もあるが高いところに設置するのは死にそうなのでプロに頼みたい。一応見積もりを取ったが4万だったので流石に高いなーという感じで出来れば使いたくない状態

そういえば、前の家はベランダに出ると香水みたいな匂いがしてたんだけどウミネコが大量にいたので鳥避けだったのかなぁ。

SoundCore 3を買った

お風呂でpodcastとかラジオとか音楽とか聞いてる。元々はSoundCore Sportを使ってて結構気に入ってたけど、充電がすぐなくなる・充電が残り20%くらいになるとかなりの頻度で充電してくださいアラートが鳴るというのがずっと不満だった。 引っ越して充電ケーブルを整理していて、micro usbの製品を捨てていきたいという気持ちが出てきたので思い切って買い替えた。

また同じSoundCoreシリーズにした。僕が買ったときはセールをしていて4800円くらいだった。

  • IPX7対応の防水規格
  • 充電が結構持つ
  • 10%くらいまで使ってみたけどアラートがうるさくない
  • 値段も控えめ
  • USB Type Cで充電できる

あたりでかなり満足している。不満なのはボタンが見にくいことくらい。あんま操作しないからそこまで深刻ではない。

Soundcore 3 | Bluetoothスピーカーの製品情報 – Anker Japan公式サイト

知的生産の技術 を読んだ

数年前に読んだっぽいのだが全然覚えてなかった。たぶんお酒を飲みながら読んだんだと思う。ブログにも書かれてなかった。

創造的な知的生産を行うための技術が書かれている。知的生産とは以下のように定義されている。

知的生産とは、知的情報の生産であるといった。既存の、あるいは新規の、さまざまな情報をもとにして、それに、それぞれの人間の知的情報処理能力を作用させて、そこにあたらしい情報をつくりだす作業

新しいものをアウトプットするにはインプットが必要だと僕も思っていて新しいことをするときは本を読みまくるのだが、それを知的生産というっぽいと理解した。同じように社内のドキュメントを読んでなにかしらのアウトプットをすることも知的生産のひとつである。

知的生産の技術を読んだ理由は、最近仕事でのドキュメントを見つけるのが大変だなと思っていてどうにかしたい。いい感じのドキュメント管理の仕方が知りたいと思ったのだが、この本に書かれてる方法はNotionで出来ないなという感じで困ったままではある。以下のように整頓ではなく整理が必要なのだが、どうするべきかはわかってない状態。

 整理というのは、ちらばっているものを目ざわりにならないように、きれいにかたづけることではない。それはむしろ整頓というべきであろう。ものごとがよく整理されているというのは、みた目にはともかく、必要なものが必要なときにすぐとりだせるようになっている、ということ

ただ本を一気に読むとか記憶ではなく記録するとか共感できることはたくさんあって非常に古い本ではあるけどいい本だなと思いました。

そしてこの本には書かれてなかったけど、知的生産したいならお酒はやめたほうがいい。