最近仕様書について考えてて原点に立ち返るか…と思ったので今更だけど初めて読んだ。
本の内容は、最初から解の質にこだわるんじゃなくてまずはイシュー度から取り掛かろうという話で、まぁそうだよねみたいな内容が書かれてる。後半はチャートとかについて書かれてたので自分ごとだと思えずあんま集中して読めなかったけど、悩むと考えるの違いなど「なるほどな〜」と思うことが書かれてたりしていてよかった。
僕の考えるこの２つの違いは、次のようなものだ。 「悩む」＝「答えが出ない」という前提のもとに、「考えるフリ」をすること 「考える」＝「答えが出る」という前提のもとに、建設的に考えを組み立てること
あと「知りすぎるとバカになる」もたしかにと思えていて、知りすぎるとそのことに囚われてしまうみたいなのがあると思う。最近読んだ問いかけの作法にも「とらわれ」があると新しい発想が生まれにくくなると書かれてたけど、そういうことだよな〜と思いました。
今回の家は斜め前のマンションが僕の部屋より少し高いくらいのマンションでそこの屋上に鳩が止まったりしている。そのマンションの住人も多少対策はしていて、屋上にカラスの置物とか置いてるけどあまり意味をなしてない（ただ風でカラスの置物が動いてるときは鳩が来ない気がする）
基本的にそこを経由して僕の部屋のベランダの手すりに止まって、貯湯機の上にある室外機の横を通って、貯湯機と室外機の間に収まるようである。
鳩まあかわいいところもあるが足跡を残すし糞を垂らすしで汚いし、巣を作られるとかなり厄介らしいので見つけ次第早めに対策するのがよいらしい。
また方針として鳩を傷つけそうなトゲトゲとかは自分も刺さりそうだし鳩も痛そうなので設置する気はなかった。
まず鳩の侵入経路を把握してから対策するのがよいだろうと思ったので、前から持っていたけど持て余していた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というのも教えてもらったので読んでみる。
問いかけというのは非常に重要なことだと思う。
例えば人間が成長するには経験学習が必要で経験学習には内省というのがある。行動をふりかえって知見を得るためにとにかく自分に対して問いかけるというのを僕はよくやる。時には1 on 1でEMが問いかけてくれたりして気付くこともある。他にもドキュメントレビューやコードレビューでレビュアーからの問いかけから対話が始まってより良いものが出来上がったりもする。
問いかけがうまくいけば行動のふりかえりは正しい方向に向かうしより良いものも作れると思ったので、それをうまくなりた〜いと思ったので読んだ。
同じ著者の問いのデザインも前に買って読んでそっちも良かったけど、個人的には実践しやすいからか問いかけの作法のほうが刺さることが多かった。
問いかけの作法読み始めたけどいきなりあるあるが出てきた https://t.co/nrQVy4Jeqb pic.twitter.com/iEH3Fnbd0Z
— ひさいち (@hisaichi5518) 2022年1月26日
問いかけの作法読んでるけど、僕が言ってたバーン感が足りないは現代病としてあげられてる衝動の枯渇だったのではとなりました
— ひさいち (@hisaichi5518) 2022年1月26日
チームで働くとき、様々なレビューがある。ソフトウェアエンジニアとしてはコードレビューを頼むことが一日に何度もあると思うのだが、最近の僕はドキュメントを書くのが大半の仕事になっていて*1、ドキュメントのレビューをプロダクトマネージャーや他のソフトウェアエンジニアにお願いすることが多い。
コードレビューはインターネットに様々な知見が溢れていて、ソフトウェアエンジニア同士で結構脳内同期が出来ていると思う。なのでコードレビューでは雑にレビュアーのアサインをして毎回ここを見てほしいですとかは言ってない。それと同様にドキュメントのレビューでも「レビューお願いします」というだけですべてを任せていたのだけど、そもそも自分がドキュメントをレビューしてもらう時にレビュアーに何を求めているのかなど言語化していないなと思ったので言語化してみようと思う。
他の人に考えを広めるためには5W1Hが大事になるとおもう。
例えば、Aというものを導入するときに「Aを導入します。Aとは〜です」と書かれただけのドキュメントだと他の人はなぜAを導入するのか理解出来ないし理解できないとやる気も起きないと思う。
読み手が理解するうえで不足している部分だったり意味不明の部分があれば指摘してほしい。例えば、以下がなかったり意味不明な場合は指摘があると嬉しい。
ドキュメントを書くというのはドキュメントを書く人間の考えを文字にすることになる。自分の考えなので自分視点になりがちで、他の人の視点が足りていないことがある。
例えば最近僕のドキュメントがレビューされて良い指摘だなと思ったのは、僕はソフトウェアエンジニア視点で「テスト設計書のレビューで、レビュアーは何をレビューしたいのか」だけを書いていたけど「テスト設計のレビューならレビュイーであるテスト設計者がレビュアーに求めている事も重要だよね」みたいな指摘が良いなと思った。
コードレビューやデザインレビューでも同じような気がするが、ドキュメントを書くうえでもそもそも考え忘れていることは人間なのであると思っていて、それらの指摘がもらえると嬉しい。
Aというものを導入するためのドキュメントなら自分は理解して取り組めそうだなみたいに思ったらそう書いてもらえると嬉しい。「LGTM」や「よさそう」とかでもいい。
日本語って難しいので気を抜くと意味がわからない文章になったりする。プログラム言語は意味がわからないとエラーになるので便利。
誤字脱字はいちいち指摘されて直すのは時間の無駄なので勝手に直しちゃってほしい。
意外と少なかった。書いていくと見てほしい部分が増えていくかもしれないが、見落としている視点の発見というのが一番重要な気がする。
*1:昔の自分が今の僕を見たら驚愕するだろうな
