日本語版
Agile Testing Condensed… Yuya Kazama 著 et al. [PDF/iPad/Kindle]
買って読んでなかった。チーム全員で品質の作り込みチーム全員が品質に責任を持つことが大事でそれは継続的テストであるみたいな話からそれをどうやるのかが簡単に書かれている。最近仕様書について考えていてもうだめだと思っていたのだが、ここに書かれていたことは大変参考になった。
日本語版
Agile Testing Condensed… Yuya Kazama 著 et al. [PDF/iPad/Kindle]
買って読んでなかった。チーム全員で品質の作り込みチーム全員が品質に責任を持つことが大事でそれは継続的テストであるみたいな話からそれをどうやるのかが簡単に書かれている。最近仕様書について考えていてもうだめだと思っていたのだが、ここに書かれていたことは大変参考になった。
Notionでドキュメントを書いてる。ドキュメントは書く、共有する、読むなどユーザーそれぞれ色々なシナリオがあり、そのシナリオそれぞれでつらみがある。
Notionに限らずすべてのサービスは使っていればつらいところはあると思っていて、つらいとはいえNotionから別のドキュメント管理サービスに乗り換えたいという気持ちは全くなく何がつらいのか考えNotionでなにか出来ることはないか考えたり、つらみを共有することで知見を得たい。
検索をする時はストック型の情報を探すことが多い。例えば、リリース作業手順ドキュメントを探したいときに「リリース 作業 手順」で検索するけど日報や議事録などは検索から除外したい。
Notionの検索には、FilterでPageの指定が出来るのでそれを駆使するしかない。Pageの指定をした場合、Pageの配下は検索対象になるので、ストック型の情報を置くPageの配下にはフロー型のドキュメントを置かないのがよい。
command + pでQuick Findを立ち上げて検索したい文字を入力、結果が出るまで数秒待ち、結果が出たら右上のAdd Filterをマウスでクリックして、Filterを追加する。
あまりにだるすぎるのでタイトル検索をしたい時はCommand+Eを使っている。自分のアクセスした履歴から高速に検索出来る。ただCommand+Eは今インストールできなくなっているようなので、Raycastなどを使うとよさそう。またこれは自分がアクセスしたページの検索なので、新しい情報を探したい時は歯を食いしばるほかない。
これは良いのか悪いのか。僕は嬉しいと思ったことはない。例えば「SWE採用」というページの配下にある「選考内容」というページは「SWE 採用」でタイトル検索すると検索結果に出てくる。
つまり検索結果の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は出ないので自分の目で確認するしかない。
どこが変更されたのかわかりやすいように新たにドキュメントを書いたりするが、新しいドキュメントを書いてる途中はどっちが正しいのかわからなくなる。
書いてる通り
書いてる通り
コメントで議論したり変更した理由を文章を引用してコメントに残しても文章を消すとコメントは消える。
後半、つらいところだけになってしまったがいい感じになりたいのでいい感じになる方法があったら教えてください。
最近仕様書について考えてて原点に立ち返るか…と思ったので今更だけど初めて読んだ。
本の内容は、最初から解の質にこだわるんじゃなくてまずはイシュー度から取り掛かろうという話で、まぁそうだよねみたいな内容が書かれてる。後半はチャートとかについて書かれてたので自分ごとだと思えずあんま集中して読めなかったけど、悩むと考えるの違いなど「なるほどな〜」と思うことが書かれてたりしていてよかった。
僕の考えるこの2つの違いは、次のようなものだ。 「悩む」=「答えが出ない」という前提のもとに、「考えるフリ」をすること 「考える」=「答えが出る」という前提のもとに、建設的に考えを組み立てること
あと「知りすぎるとバカになる」もたしかにと思えていて、知りすぎるとそのことに囚われてしまうみたいなのがあると思う。最近読んだ問いかけの作法にも「とらわれ」があると新しい発想が生まれにくくなると書かれてたけど、そういうことだよな〜と思いました。
今回の家は斜め前のマンションが僕の部屋より少し高いくらいのマンションでそこの屋上に鳩が止まったりしている。そのマンションの住人も多少対策はしていて、屋上にカラスの置物とか置いてるけどあまり意味をなしてない(ただ風でカラスの置物が動いてるときは鳩が来ない気がする)
基本的にそこを経由して僕の部屋のベランダの手すりに止まって、貯湯機の上にある室外機の横を通って、貯湯機と室外機の間に収まるようである。
鳩まあかわいいところもあるが足跡を残すし糞を垂らすしで汚いし、巣を作られるとかなり厄介らしいので見つけ次第早めに対策するのがよいらしい。
また方針として鳩を傷つけそうなトゲトゲとかは自分も刺さりそうだし鳩も痛そうなので設置する気はなかった。
まず鳩の侵入経路を把握してから対策するのがよいだろうと思ったので、前から持っていたけど持て余していたAtom camで動体検出をONにして録画した。ベランダに電源がなかったのでベランダに面した部屋から撮影した。また動画を見てる感じ1分ほどしか滞在していないのでまだ鳩も休憩に使ってるくらいで対策するなら今だと思った。
糞があったり汚れたりすると鳩は来るらしい。カビキラーがあったのでそれで掃除した。そんなぐちゃぐちゃにはなってないので、鳩が来る来ないで言えば意味はないと思うけど人間としてはまあ綺麗な方がいいよね…みたいな感じ
正直なところテグスを張っても関係なしに止まるだろうと思っていたのだけど効果があった。1ヶ月ほど経ったけどテグスがある場所にはまだ止まってない。
ただ手すりに止まらずに空中でバタバタして周りを確認したあとに貯湯機の上にある室外機の横を通って貯湯機と室外機の間に収まるようになってしまった。
またテグスを張るのは最低限にしたいと思って鳩が止まる場所に張ったのだが数日後にはテグスの横に止まられた。許さん
本当は貯湯機の上にある室外機の横にネットを張りたかったのだけど、高さがあり下手したら僕が死ぬな…と思ったので貯湯機と室外機の間をネットで張った。
これはあんまり意味がないと思いながらやったけど、やっぱり意味がなくて動画で確認するとやはりエコキュートの貯湯機の上にある室外機の横を通って入っていた。ただ動画では出ていったところの撮影がされておらず、どうやって出ていったのかは謎
あんまり効果がないだろうと思いつつも買った。臭くはないけど強烈なローズ系の香りがする。強烈なので近隣住民が洗濯物を干してるときにやると鳩は追い返せても近隣住民にブチギレられそうだと思ったので昼はやらずに周りが寝静まった深夜にやってる。また僕は基本衣類を干さないのであんまり気にしないけど干す人だと気にしそう。
これを2日ごとに貯湯機の上にある室外機の横と手すりに散布したところ、最初の1回だけ室外機の横にすっぽり入ってたけど相当嫌だったのかその後は直接入っておらず手すりに止まるようになった。ただ手すりにもテグスと忌避剤を散布しているので、止まろうとしてやっぱやめとこ!みたいな感じで追い返せている。
2日に1度散布しなければならないので少しめんどくさいのとローズ系の香りで近隣住民にキレられないか不安ではあるが、1週間ほど鳩はベランダに止まってない。3日ほどは手すりには止まろうとしていたのでテグスを張ろうかと思っていたけど、そもそもベランダに寄り付かなくなってきている。(近くを飛んではいるので散布はやめていない)
スプレー型の忌避剤で駄目ならジェル型の忌避剤があるらしいのでそれを使う手もあるが高いところに設置するのは死にそうなのでプロに頼みたい。一応見積もりを取ったが4万だったので流石に高いなーという感じで出来れば使いたくない状態
そういえば、前の家はベランダに出ると香水みたいな匂いがしてたんだけどウミネコが大量にいたので鳥避けだったのかなぁ。
お風呂でpodcastとかラジオとか音楽とか聞いてる。元々はSoundCore Sportを使ってて結構気に入ってたけど、充電がすぐなくなる・充電が残り20%くらいになるとかなりの頻度で充電してくださいアラートが鳴るというのがずっと不満だった。 引っ越して充電ケーブルを整理していて、micro usbの製品を捨てていきたいという気持ちが出てきたので思い切って買い替えた。
また同じSoundCoreシリーズにした。僕が買ったときはセールをしていて4800円くらいだった。
あたりでかなり満足している。不満なのはボタンが見にくいことくらい。あんま操作しないからそこまで深刻ではない。
知的生産の技術買ってみようと思ったら結構前に買ってて、あ~積んでたか〜と思ったらKindleの履歴的にはもう読んでたらしいけど全く記憶にない
— ひさいち (@hisaichi5518) 2022年2月3日
数年前に読んだっぽいのだが全然覚えてなかった。たぶんお酒を飲みながら読んだんだと思う。ブログにも書かれてなかった。
創造的な知的生産を行うための技術が書かれている。知的生産とは以下のように定義されている。
知的生産とは、知的情報の生産であるといった。既存の、あるいは新規の、さまざまな情報をもとにして、それに、それぞれの人間の知的情報処理能力を作用させて、そこにあたらしい情報をつくりだす作業
新しいものをアウトプットするにはインプットが必要だと僕も思っていて新しいことをするときは本を読みまくるのだが、それを知的生産というっぽいと理解した。同じように社内のドキュメントを読んでなにかしらのアウトプットをすることも知的生産のひとつである。
知的生産の技術を読んだ理由は、最近仕事でのドキュメントを見つけるのが大変だなと思っていてどうにかしたい。いい感じのドキュメント管理の仕方が知りたいと思ったのだが、この本に書かれてる方法はNotionで出来ないなという感じで困ったままではある。以下のように整頓ではなく整理が必要なのだが、どうするべきかはわかってない状態。
整理というのは、ちらばっているものを目ざわりにならないように、きれいにかたづけることではない。それはむしろ整頓というべきであろう。ものごとがよく整理されているというのは、みた目にはともかく、必要なものが必要なときにすぐとりだせるようになっている、ということ
ただ本を一気に読むとか記憶ではなく記録するとか共感できることはたくさんあって非常に古い本ではあるけどいい本だなと思いました。
そしてこの本には書かれてなかったけど、知的生産したいならお酒はやめたほうがいい。
最近仕様書を書いていこうぜという機運が高まってきているものの仕様書ってなにを書けば?とか仕様書を書くのは誰?とかそもそも仕様とは?とか仕様書の品質をどう担保していくのか?とか仕様書の変更管理とかどうするの?とか決まっていない・決まっているけどもっと良くしたいいう状態で、そういうのを決めたり改めたりするにはとにかくインプットしまくりたいという気持ちになっている。
そういう状態で要求開発の基礎知識 要求プロセスと技法入門を読んだら、要求仕様化・要求確認・要求管理がまさに気になってたところだったので大変良かった。
要求工学というのがあるの知らなかったから要求開発の基礎知識読んでるけど、おじさん構文みたいに要求構文みたいなのがあるのを知った
— ひさいち (@hisaichi5518) 2022年2月1日
REやREBOKというのも教えてもらったので読んでみる。