お風呂で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:昔の自分が今の僕を見たら驚愕するだろうな
インナーチャイルドという言葉を初めて知ったので読んだ。
子供（乳児期、歩行期、学童前期、学童期）の頃の経験からどんな大人にもインナーチャイルドはいて、なんらかの理由によってインナーチャイルドが傷ついていれば色々と人生に問題が起きてしまうみたいな話から始まり、オリジナルペイン・エクササイズといったエクササイズによってインナーチャイルドを救い出そうみたいな話である。
結構これのエクササイズと似たような話をキレる私をやめたいでも読んだことがあって、その本ではゲシュタルト・セラピーと呼ばれていた。手法とかは改めて読んでみると違ってたんだけど、自分の心（インナーチャイルド）を自分で客観視してみるところは同じだなと思った。
あと考えることも依存の一種と書かれててそうなの！？！！！？ってなった。エクササイズやってはないんだけどやってみてもいいかもしれん。
SQuBOKというのがあるというのを知って読んでみようと思って読んだ。ソフトウェアの品質マネジメントや品質技術に関連する技法から事例や国際規格などが整理されていて非常に良かった。
実際困ったときとかに辞書のようにあとで読み返したりすると思う。
