パルカワ2

最近はFlutterをやっています

問いかけの作法:チームの魅力と才能を引き出す技術 を読んだ

問いかけというのは非常に重要なことだと思う。

例えば人間が成長するには経験学習が必要で経験学習には内省というのがある。行動をふりかえって知見を得るためにとにかく自分に対して問いかけるというのを僕はよくやる。時には1 on 1でEMが問いかけてくれたりして気付くこともある。他にもドキュメントレビューやコードレビューでレビュアーからの問いかけから対話が始まってより良いものが出来上がったりもする。

問いかけがうまくいけば行動のふりかえりは正しい方向に向かうしより良いものも作れると思ったので、それをうまくなりた〜いと思ったので読んだ。

同じ著者の問いのデザインも前に買って読んでそっちも良かったけど、個人的には実践しやすいからか問いかけの作法のほうが刺さることが多かった。

hisaichi5518.hatenablog.jp

ドキュメントのレビューでレビュイーが求めていること

チームで働くとき、様々なレビューがある。ソフトウェアエンジニアとしてはコードレビューを頼むことが一日に何度もあると思うのだが、最近の僕はドキュメントを書くのが大半の仕事になっていて*1、ドキュメントのレビューをプロダクトマネージャーや他のソフトウェアエンジニアにお願いすることが多い。

コードレビューはインターネットに様々な知見が溢れていて、ソフトウェアエンジニア同士で結構脳内同期が出来ていると思う。なのでコードレビューでは雑にレビュアーのアサインをして毎回ここを見てほしいですとかは言ってない。それと同様にドキュメントのレビューでも「レビューお願いします」というだけですべてを任せていたのだけど、そもそも自分がドキュメントをレビューしてもらう時にレビュアーに何を求めているのかなど言語化していないなと思ったので言語化してみようと思う。

前提

  • ここで扱うのは、ドキュメントのレビューである
  • ドキュメント=他の人に考えを広めるためのものである
  • 考えを広めるためには考えを理解してもらう必要がある
  • ここでは、何を指摘してほしいかを書いている。どう指摘するべきかは書いてない。そのあたりはデザインレビューやコードレビューと同じだと思う。

ドキュメントレビュアーに求めていること

5W1Hの不足の発見

他の人に考えを広めるためには5W1Hが大事になるとおもう。

例えば、Aというものを導入するときに「Aを導入します。Aとは〜です」と書かれただけのドキュメントだと他の人はなぜAを導入するのか理解出来ないし理解できないとやる気も起きないと思う。

読み手が理解するうえで不足している部分だったり意味不明の部分があれば指摘してほしい。例えば、以下がなかったり意味不明な場合は指摘があると嬉しい。

  • このドキュメントの目的
  • 現状整理、現状の課題とは
  • 満たしたいこと、ゴールではないこと
  • Aとはなにか、なぜAか(メリット)
  • Aのデメリット
  • Aをどのように導入していくか、Next Action(誰がいつまでに何をするか)
  • 想定質問
  • まとめ:Aは満たしたいことを満たせるかなど

見落としている視点の発見

ドキュメントを書くというのはドキュメントを書く人間の考えを文字にすることになる。自分の考えなので自分視点になりがちで、他の人の視点が足りていないことがある。

例えば最近僕のドキュメントがレビューされて良い指摘だなと思ったのは、僕はソフトウェアエンジニア視点で「テスト設計書のレビューで、レビュアーは何をレビューしたいのか」だけを書いていたけど「テスト設計のレビューならレビュイーであるテスト設計者がレビュアーに求めている事も重要だよね」みたいな指摘が良いなと思った。

コードレビューやデザインレビューでも同じような気がするが、ドキュメントを書くうえでもそもそも考え忘れていることは人間なのであると思っていて、それらの指摘がもらえると嬉しい。

ドキュメントを読んだ感想

Aというものを導入するためのドキュメントなら自分は理解して取り組めそうだなみたいに思ったらそう書いてもらえると嬉しい。「LGTM」や「よさそう」とかでもいい。

意味がわからない所の発見

日本語って難しいので気を抜くと意味がわからない文章になったりする。プログラム言語は意味がわからないとエラーになるので便利。

誤字脱字は指摘せずに直して良い

誤字脱字はいちいち指摘されて直すのは時間の無駄なので勝手に直しちゃってほしい。

まとめ

意外と少なかった。書いていくと見てほしい部分が増えていくかもしれないが、見落としている視点の発見というのが一番重要な気がする。

*1:昔の自分が今の僕を見たら驚愕するだろうな

インナーチャイルド 本当のあなたを取り戻す方法〔改訂版〕 を読んだ

インナーチャイルドという言葉を初めて知ったので読んだ。

子供(乳児期、歩行期、学童前期、学童期)の頃の経験からどんな大人にもインナーチャイルドはいて、なんらかの理由によってインナーチャイルドが傷ついていれば色々と人生に問題が起きてしまうみたいな話から始まり、オリジナルペイン・エクササイズといったエクササイズによってインナーチャイルドを救い出そうみたいな話である。

結構これのエクササイズと似たような話をキレる私をやめたいでも読んだことがあって、その本ではゲシュタルト・セラピーと呼ばれていた。手法とかは改めて読んでみると違ってたんだけど、自分の心(インナーチャイルド)を自分で客観視してみるところは同じだなと思った。

あと考えることも依存の一種と書かれててそうなの!?!!!?ってなった。エクササイズやってはないんだけどやってみてもいいかもしれん。

ソフトウェア品質知識体系ガイド(第3版): SQuBOK Guide V3 を読んだ

SQuBOKというのがあるというのを知って読んでみようと思って読んだ。ソフトウェアの品質マネジメントや品質技術に関連する技法から事例や国際規格などが整理されていて非常に良かった。

実際困ったときとかに辞書のようにあとで読み返したりすると思う。

新居のにおい問題

今回の家は築15年でめちゃくちゃ古いわけではなく基本綺麗。前に住んでいた家はいい感じの新築だったからか辛いと思うことがまったくなかったのだけど、今の家はくさいところがいくつかあった。見た目はそんな違いはないので気にならないけど、臭いはしんどいのでどうにかしたい。

洗面台の横の棚

エグい臭いを放っていた。何回か嗅ぐと喉に違和感を感じたのと吐き気がした。タオルを入れると臭いが移ってしまう。

6年ほど住んだ団地(築年数49年くらい)にあった棚でもこの臭いを嗅いだことがあり、そのときは管理会社に言ってみたもののどうにもならなかったのでその時は入居してから棚を一切開けないという戦術を取っていた。今回は洗面所なので開けれないとかなり不便なのでどうにかしたい。

消臭スプレー

消臭スプレーをぶっかけた。なんか前にツイッターで話題になってたスプレーで一瞬臭いは消えて感動したけど、少し経つと復活していた。

水につける

調べてみると棚で利用している接着剤にホルムアルデヒドとかいうのが含まれていてそれの臭いっぽいと思った。ホルムアルデヒドは水に溶けやすいらしいので試しに棚の板を取り外して浴槽に水を貼ってそこにぶちこんでから干してみたところ、板からは臭わなくなった。ただ若干の木クズの臭いみたいなのがした。

また棚の外枠からも臭っているけど取り外せないので水をかけた。水をかけた直後は臭いがなくなったが、5時間ほど放置していると臭いは復活していた。ただ前は本当にひどかったのでマシになるだけ良かった。

あとあまり長時間かけたりすると腐ったり水漏れしそうなのでそこまではやってない。

棚の板を買い換える

賃貸なので棚の板を捨てると原状回復が出来なくなるので板を捨てるという選択肢は元々なかったのだけど、もういいか…という気持ちになってきたので棚の板を買い換えることにした。AmazonでF☆☆☆☆仕様で見えるところはすべて化粧仕上げであり、自分の好きなサイズでオーダ出来る板があったのでサイズを測ってそれを頼んだ。購入した板は新品の家具の匂いはするけど臭くはなかったので良かった。届いて1ヶ月ほど経ったけど満足している。

リバースワックスを塗る

調べるとリバースワックスというのがあり、ワックスを上から塗れば臭わなくなるらしいので何度か塗ったら全然臭わなくなった。購入した板は新品の家具の匂いはするけど臭くはないので外枠にだけ塗った。外枠に塗るか原状回復がしにくいので悩んだが、板を買い替えたのだから関係ないと思った。これでほぼ臭いがしなくなった。ちなみに何度か塗った。

また原状回復が出来なくなるのではとビビっていたけど気にしすぎだったかもしれない。試してないけど一応剥離は出来るらしい。

あと調べたら漆喰を塗るというのもありっぽい。なるほど。

漆喰で「シックハウス症候群」を予防する!|納得!素晴らしき漆喰の世界‐4 | 漆喰うま~くヌレール 公式サイト

シックリーンを使う

リバースワックスを塗ってほぼ臭いがしなくなったけど、シックリーンを買っていたので使った。別の場所で単品で使ってみたけど、まあ若干マシになった気がするが少し物足りない気はする。

洗面台の棚

洗面台の横の棚と同じようにエグい臭いを放っていた。こっちは化粧品?のキツめのにおいが合わさっていてかなりきつかった。水をかけたところマシにはなったが、洗面台の横の棚と同じようにリバースワックスを塗った。 棚の板は変えたいけど、ダボの部分が凹んでいたり少し特殊な板だったので変えれなかった。ただ水につけてリバースワックスを何度か塗ったら臭いは許せる程度になったので気にしないことにした。外枠も水をかけてリバースワックスを何度か塗った。あとシックリーンで仕上げた。

台所の食器棚

洗面台の横の棚や洗面台の棚と同じ臭いがする。

長時間食器を入れていると食器が臭くなるのでつらい。水洗いしてから使う必要がある。

板は特殊な加工がされていて新しい板に変更する事が出来なかったので水で洗ってシックリーンをかけて乾拭きした。特殊な加工がされているからというのもあるけど、板自体はあんまり臭いはしなかったのでリバースワックスは塗る必要はなさそう。外枠にはリバースワックスを何度か塗ってシックリーンで仕上げた。

リビングの棚

洗面台の横の棚や洗面台の棚と同じ臭いがする。

今の家は他にも棚が付いててこの棚は使う予定がない棚でめんどくさいので未着手。ただ板は新品を買ったので届いたらやろうと思う。外枠を水をかけるのはリビングなので厳しいので水拭きしてリバースワックスを何度か塗ってシックリーンで仕上げる感じになりそう。

まとめ

すべてにおいてエセっぽいな〜と思いながらやっていて効果が出ればラッキーくらいの気持ちで買っていた。リバースワックスを使うことでだいぶマシになったので良かったが、この記事を書くにあたってまた調べていたら保健所に相談するとよいと書いてあった。実際調べると自分が住んでる区の保健所では住居衛生の相談を受け付けていた。有効活用出来るとよさそう

また内見の時点(クリーニング前)でホルムアルデヒドの臭いには気づいていたのだけど、クリーニングでどうにかなるかなと思ったけどそんなことはなかった。

安心してリリースしたい

最近所属するチームが変わって"リリースされるプロダクトの品質担保"について考えている。リリースされるプロダクトということはリリースされる前のプロダクトであり、ユーザーに届く前に品質を担保せえというのが僕の考えることであると理解した。

ユーザーに届く前に品質を担保されている状態とはなにかを考えるとリリース前に客観的に「これは品質が高い!」といえる状態だと考えた。客観的に品質が高いと言えれば開発者は安心してリリースすることが出来る。

品質が高い=想定外のことが起きない(バグが出ない)だとするとリリース前に100%これはバグがない!といえるかというとありえない気がしていて、なにをやっても結局バグは絶対出る。このあたりは僕がプログラムを書き始めるよりずっと前から考えられてきたことでなるべく想定外を潰す方法はあるにはあるらしいんだけど、ハイコストでありリリースの速度を下げることはやりたくない。なので現実的ではないですね………みたいな事になる。

結局バグが出るのであればバグをなくすことを頑張るのは"ある程度"で収めておいて、バグの影響範囲を小さくすること・バグを早く検知し元に戻すことに注力するのが安心してリリース出来ることに繋がり、ひいてはリリースされるプロダクトの品質担保に繋がるのではないかと思う。

ただそれだけやってもまだ安心とは言えないと感じていて問題は2個あると思っている。

  • 品質が高い=想定外のことが起きない(バグが出ない)はかなりいい加減な定義であること
  • "ある程度"が人によって違い客観的ではないこと

最近いろんなソフトウェアテストの本を読んでいると品質が高い=想定外のことが起きない(バグが出ない)はかなりいい加減な定義であると思った。このあたりも色々とすでに知見はあって、ソフトウェア品質特性モデルや利用時の品質特性モデル(正式な名前がわからない)というのがある。

つながる世界のソフトウェア品質ガイド(PDF)

これらの品質特性が高い状態を品質が高いと定義し品質特性をブレイクダウンして"ある程度"の基準を明確に設けて開発者(というよりプロダクトチーム全員)が参照できるようにしておくといいのではないかと考えている。

ちなみにエリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blogにあるようなメトリクスはリリース後に得れるものなのでここで必要なものとは別物という認識であるがこれらはリリースされたあとに分析などを行うために必要なので別途取る必要がある。その分析を行い課題を見つけることでより洗練された基準になっていくはず。

hisaichi5518.hatenablog.jp

hisaichi5518.hatenablog.jp

ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方 を読んだ

ソフトウェアテストの基礎はソフトウェアテストの教科書によって理解できたので更に深堀りしたいなと思って社内のおすすめ本一覧にあったこの本を読んだ。

気づきがあったのは、このツイートに書いてることで複雑度が高くてhotspotが高いコードはそのままでもバグが起きる場所なんだから早めにリファクタリングしたほうがいいみたいなの書かれてるのはなるほどと思った。

と書いてて思ったけど、前職でAndroidアプリをリファクタリングしているときは機能追加や変更をする場所からリファクタリングして、リファクタリングが終わったあとに機能追加や変更をしていた。一気にリファクタリングとか出来ないからそうしてたんだけど間違えてなかったんだなと思った。実際かなり早く機能追加の実装が終わったりしてたし。「ソフトウェア品質を担保するにはリファクタリングは必須」と書かれていて僕もそれに同意見でとにかくリファクタリングが重要だと思う。

ただこんな感じでよくわからないところもある。

クラス図とか図を書く意味が正直よくわからなくて、実装より前に書くならテストを書いたほうが良いのではないかと思ってしまう。どうなんだ。このあたりはもしかしたらTDDの話につながっていくのかもしれない。

ちなみにこの本は、Kindleに最適化していたので読みやすかった。あとリファクタリングだけじゃなくSHIFT LEFTとかにも言及していたりしてよかった。

そして例のごとく知ってそうなところは飛ばした。