eityansメモ

eityansメモ

ゆるくやっていきます

記事一覧

インプラントの手術を受けたメモ

前歯のインプラントの手術をした。複数回手術を行う。せっかくなので記録を残す。


骨を足す手術(0回目)

2023年の9月に実施。お値段は19万円。インプラントの基本的な流れとして、骨にインプラントを埋め込むためのボルトをいれる手術を行い、その後にインプラントをいれる手術を行う。自分の場合は骨がとても薄く、まずその骨を増やす手術から行った。

手術を行ったが結果あまり骨がくっつかず、最終的に今のお医者さんを紹介してもらった。(なので0回目にしている)この人の手術が一番痛かったし、術後の出血がえげつなかった。今思うと、無駄とまでは言わないけど最適解ではなかったのかもなーと思っている。(そもそも、インプラントをどこで受けるべきかがわからなすぎ問題がある。)

骨を足す手術(1回目)

2024年の10月に実施。お値段は37万円。

手術をする前に全身麻酔オプションの案内を受けた。全身麻酔すると完全に寝ている間に終わってしまうらしく、せっかくの手術体験を逃す気がしたので全身麻酔なしにした。医者に「強いっすねw」って言われた。

前回は動物の骨を使ったらしく、(いろいろな選択肢があるらしい)その結果骨がくっつかなかったのではという見解。今回は自分の骨を使って骨を増やすことに。

右下の顎から骨を採取し、その骨を前歯の土台となる骨に追加した。手術自体は部分麻酔もしてもらい快適(?)だった。術後の話で言うと、出血が一切なかった。名医すごい。前歯の腫れもひどかったが、採取源のあごの腫れのほうが長引いたししんどかった記憶。


ここまでは記憶を元に書いているためかなりざっくりしているが、ここからは詳細に記録していきたいと思う。

骨を足す手術(2回目)

2025年の4月に実施。お値段は44万円。

前回の手術で骨は増えているものの、インプラントの土台を埋められるかどうかは開けてみないと判断できないとのこと。1回目と同じ手術を行い、行けそうなら土台を埋めちゃう作戦らしい。

今回削るのは左下の顎。天気がとても良かった。

手術を行う前に血圧などの測定を行う。医者に「手術の場でここまで安定している人は初めてみました」と言われる。ポーカーで謎のメンタルがついているのかもしれない。

今回も全身麻酔はやらないが、部分麻酔は行う。強い麻酔のようで、麻酔した直後に心臓がバクバクする。そういうものらしい。こんな即効性のある薬がこの世に存在すること自体が面白くなる。

手術自体はやることがないし、麻酔も効いているのでただ横になっているだけ。麻酔が効いているとはいえ、振動や匂い、血の味などは全然感じるので、「今切られているんだな」とか、「めっちゃ顎の骨削られている」とか、そういうのをダイレクトに感じる。これは確かに苦手な人は全身麻酔したほうが良いかも。

手術中はまじでやることがない。口を開ける、大きく開ける、舌をどかすぐらいしかオプションがないし、大部分は口を開けるためのつっかえ棒が入っていたので本当にやることがなかった。手術中に何度か寝てた。医者に「さすが。ありがたい。」と言われた。

やることがなさすぎて、どうでもいいことをひたすら考えていた。これまでの人生を振り返ったり、ちょっとした走馬灯のような感じもした。久しく会っていない人に会いたくなった。

手術自体は3時間半ぐらいかかった。

手術後はちょっと腫れているくらい。術後の説明を受け、ヘロヘロになりながら帰る。まだ麻酔はきいているが、痛くなりそうな予感がある。麻酔で感覚がないのと、唇が張っているため口を閉じにくい。マスクをしてマスクの中で口を開けながら帰宅した。

帰宅後は基本的に横になっていた。

タブレットスタンドBluetoothリモコンを使って、寝ながらコンテンツを享受していた。

食事はビーフシチューを食べた。


術後翌日

出血はなし。ただ全身がだるいので基本だらだら過ごした。YouTubeを見て過ごした。

食べたもの:プリン、ビーフシチュー、Oikos

2日後

出血なし。全身のだるさもなくなった。腫れはひどい。普通に仕事ができた。リモートワークありがたい。

痛み止めはまだ飲んでいる。切れて来るとじわじわと痛みが来る。痛み止めを飲むと治る。

食べたもの:ビーフシチュー、ドライフルーツ、ドーナツ、鍋、ヨーグルト

3日後

出血なし。だるさなし。腫れはピーク過ぎたかも?

痛み止めは継続して飲んでいる。6時間に一回は飲んでいる。

上唇の腫れが引いてきたので初めて裏側を見た。血餅と言われる白いぶよぶよができていた。

そうめんはなんとか食べられたが、炭酸はしみる

4,5日後

腫れはかなり治まってきた。ただ下顎の方が固くて動きにくい感じがする。顔を動かすと痛い。

喋ったり笑うととても痛い。引きつってしまう。

食事もずっと右側だけを使っている。

しばらく家を出ていないのでボルダリングが鈍ってしまうのではないかと心配。

6日後

上側の腫れはほぼ治まった。下顎はまだ動かすと痛いし、ブラッシングも避けている。

痛み止めもまだ飲むが、一日2,3回ぐらいに頻度は下がってきた。

12日ぶりにボルダリングをした。当然いろいろ弱くなっていた。

7日後

奥歯の方を抜糸。奥歯が膿んでいるので抗生物質追加。

前歯のブラッシングは柔らかいブラシで解禁された。

食事も比較的自由に食べられるようになった。

奥歯は痛むので痛み止めはまだ飲む。

8日後

痛み止めはまだ飲む。上唇裏の歯茎が少し裂けている気がするけど、血も出ていないので様子見。

2~3週間後

奥歯のしこりというか腫れはまだある。お酒飲んじゃった

3~4週間後

上部の抜糸をした。

奥歯はしこり感あるが、医者いわく問題は見られなくて自然経過で治るとのこと。

(腫れが引くまでは以降更新する予定)

「ボール」を溜めないように仕事をしよう

タイトルで言いたいことは言った。


完全リモートワークの生活をしている。自分以外のメンバーがどんなふうに働いているのか一切わからないが、「ボール」がどこに溜まっているのかはGitHubやSlackのやり取りを見ていればなんとなくわかる。

ここで言う「ボール」は、そのタスクを進めるためにアクションする人を指す。コードレビューを例にすれば、レビュー依頼を受けたら、レビュアーが「ボール」を持つし、レビュアーがレビューしていくつかコメントをしたら、今度はレビュイーが「ボール」を持つ。

誰かが「ボール」を抱えてしまうと、そのタスクはそれ以上進むことはない。

仕事が進まないときというのは、たいてい誰かが(自分かもしれない)「ボール」を抱えていることが多い。

そして、人間なので「ボール」を抱え込んでしまうことは一定ある。

なぜ「ボール」が溜まるか

「ボール」が溜まりやすい理由の種類は大きく二つある。組織の問題と個人の問題である。組織の構造上「ボール」が溜まりやすくなることはあり、それはそれで解決すべき問題だが、ここでは個人の範囲で述べる。

「ボール」の量は自分がコントロールしにくい部分だ。なので「ボール」が溜まっている状況自体は大きな問題ではないが、それらをどう対処するかは個人で差が出る部分だ。

2,3分で対応できそうなレビュー修正を数日寝かせているような状況を見たことがある。これだと終わる仕事も終わらない。完全リモートなので、なぜそういう状況になっているのか原因を把握することが難しい。完全リモートの良くないところの一つだ。

マインドセットの問題がありそうだ。ここからは想像も含めて「ボール」が溜まる理由を書いている。

  • タスクが多すぎて優先度の判断すらできなくなっている

    • これはかなりやばい

    • 自分がこうなっていると思ったら助けを呼ぼう。

    • 誰かがこうなっていたらすぐに助けよう。

  • 忙しいことに対する謎の幸福感

    • うまく言語化できないが、そういう感情はある

  • やることがある安心感

    • やることがない状態を恐れるあまり、仕事を手放したくない人もいる。

    • 適度にタスクを追加で与えると、過去の「ボール」を手放してくれる傾向にある。

  • 意図的にボールを抱え、自身の存在感を上げる

    • 恐ろしい話だが、かつてそういう人と働いたことがある。歪んだ生存戦略である。

    • 似たようなものとして、属人的な知識を溜め込む人もいる。

    • ただし、ボールを抱えている人を安直にそういう人だと判断してはいけない

  • ボールを抱え込むことで生じる問題を理解していない(意識していない)

    • 意外とこういう人は多い。以下そういう人に向けて問題点と、対処法を書く。

「ボール」を溜めるとどんな問題が発生するか

  • 仕事が進まない

    • シンプルにこれ。「ボール」を溜めている間は決して仕事が進むことはない

  • 仕事の効率が落ちる

    • 自分も相手も仕事の効率が落ちる。

    • 「ボール」を溜めている期間に記憶が失われ、再びその仕事に取り掛かかるときに思い出すコストが余計にかかる

    • 相手にも同じ状況が発生する。相手の仕事の効率を下げている。

  • 精神衛生上よくない

    • やらなきゃいけないことを抱えている状態はつらい。確定申告の時期は憂鬱だ。

    • 「ボール」を投げた方も気になる状態が続く。

「ボール」を溜めないために何ができるか

  • 自分が「ボール」を抱えているかどうか知る

    • 「ボール」の有無を聞かれてパッと答えられない場合はきっと「ボール」を抱えている

  • 「ボール」を管理する手段を作る

    • TODOリストが一番シンプルだが、手段は何でも良い。

  • すぐ返せるものは最優先で返す

    • 考えることが減る

    • 自分はなにかの作業をしている途中でも、すぐに返せる場合はすぐに返すようにしている。短期的には効率が下がるが、長期的なメリットのほうが大きい。何に集中すべきか明確になる。

    • 100%の返答が厳しい場合でも、一次回答がすぐにできるならそれはすぐに行う。状況によってはそれで十分で、「ボール」が消えることもある。

    • なお、雑な中身で返すのはよくない。余計なやりとりが増えるきっかけになる。

  • すぐに返せない場合は、「すぐに返せない」とすぐに返す

    • これができない人は多い。もちろん「ボール」は抱えている状態なので、TODOリストなどの管理に追加する。

    • 合わせていつ返せそうか伝えられるとなお良い

  • 他に適任がいるかどうか探す

    • 丸投げにならないように注意

  • 常に「ボール」を優先的に返す意識を持つ

    • 定期的にTODOリストを見る。対応する。

    • 究極は意識の問題になる。

「ボール」を返すことに集中しすぎて、自分の仕事が進まないのでは?

ボールを返すことに全力を注ぐとそうなる場合もある。何事も極端なのはよくない。ただ、多くの人は「ボール」を抱える側に偏っている傾向があるので、それを少しでも解消できればと思っている。自分の「ボール」を意識するところから初めてみるのはどうだろうか?

最後に、この「ボール」に対する意識は人によって異なる。相手に過度な期待を押し付けないように注意すること。気になることがある場合は対話による提案をしよう。

ポモドーロに向くタスク・向かないタスク

ポモドーロ・テクニックにハマっている。

ポモドーロ・テクニックをナメていた。良い。

在宅ワークは集中力との戦いである。,有名な,,自分はこれを読んで、時間を細かく区切って集中して作業するテクニックなんだなと思い、まぁ一理あるよね〜程度でこれまで実践してこなかった。,最近読んだ,,要は、ポモドーロ・テクニックは集中するテクニックではなく、自分がどれだけ集中して仕事ができたかを可視化するためのテクニックだという。この視点は自分に取って新鮮だった。,この考え方の良いところは、行動目標に…

一ヶ月ほど試してみたので、よりこのテクニックについていくつか気付いたことがある。ポモドーロ・テクニックに向いているタスクと、向いていないタスクがある。

ポモドーロに向いていないタスク

  • 設計の初期段階など、思考の繰り返しが要求されるようなタスク

    • 集中よりも創造性が求められる場合、時間で区切るとむしろ逆効果になる

    • 時間を気にせず考え抜く方が自分は心地よく仕事が進められる

  • コードレビュー

    • 特に大物や注意して見なければならない内容については時間で区切れるようなものではない。

    • ただ、軽微なものが大量にあるような場合は集中的にそれらを処理するために使えることもある(パッケージ上げなど)

  • 障害対応など緊急性が高いタスク

    • 5分の休憩などを取っている場合ではない

ポモドーロに向いているタスク

  • ある程度方針が見えているタスク

    • 上記の設計の初期段階が終わり、あとは手を動かすだけという状況は一番相性がいい。その手を集中して動かすことができる。

  • 時間で区切れるタスク

    • 実現可能性の有無などを一次調査したい場合などに有効

ポモドーロに向いていないタスクでポモドーロを行ってもストレスが溜まるだけだし、ただの勤怠管理に成り下がってしまうので、このあたりの用法は見極めていきたいところ

コードレビューで安易に質問形式を使うとチームが疲弊する

修正依頼の意図があるならば、素直にその内容を書いたほうが良い。安易に質問形式を使うとチームが疲弊する。


質問形式のレビューとは

例えばユーザーのidを抽出したいときに以下のコードがあったとして

1user_ids = User.where(hoge).map(&:id)

それに対してレビュアーが

map(&:id)を使っているのはなぜですか?

みたいな質問形式。これ、なるべくやめたほうが良い。

「この処理で必要なのはIDだけなので、pluck(:id)を使う方が効率が良いからそうしてほしい」という意図があるならば、シンプルにそう伝えれば良い。

上記の例は極端かもしれないが、以下のような書き方をしている人もいるのではないだろうか

pluckではなくてmapを使っているのはなぜですか?

退会ユーザーの場合はどうなりますか?

質問形式によるレビューの「こじれ」

質問形式を取ってしまうと以下のような「こじれ」が発生する

  • 真意を探る

    • 特に「なぜ?」と問われた場合に発生しがち。レビュイーからすると、レビュアーが何を問題視しているのか、どのような意図で質問しているのかを推測する必要が出てくる。「もっと良い方法があるのか?」「何か設計上の意図を確認したいのか?」など、レビュアーの意図が不明なため、レビュイーは様々な可能性を考慮し、本来のタスクから意識をそらすことになる。

  • 防御的な姿勢を取る

    • レビューの仕方や人にもよるが、自分の書いたコードを否定されたように感じ、防御的な姿勢を取ってしまう場合がある。

  • 無益な議論へと発展する

    • レビュイーが意図を汲み取れなかったり(大抵はできない)した場合に発生する。レビュアーからすると的外れな表面的な回答をレビュイーが行い、それに対してレビュアーがまた質問するという不毛な議論が発生する。

  • コードが歪む

    • これはレビュアーに修正依頼の意図がなく、純粋な質問をした場合に発生しうる。真意を探りすぎたレビュアーが既存のコードを過剰に調整してしまい、結果としてコードが歪んでしまう場合がある。

質問形式自体にこういう「こじれ」のリスクが有ることを意識したほうが良い。

なぜレビュアーは質問形式を使ってしまうのか

以下のような理由がある。質問形式のレビューは楽なのだ。

  • 指示することに対するためらいがある

  • 具体的な修正案がわからない、自分が想定する修正が最適なのか自信がない

  • レビュイーが自発的に気付き、修正することに対する教育的な期待を持っている

上二つの理由は心理的だったり技術的な問題であるため説明は省略するが、最後の理由は注意したい。確かにレビューのコメントでレビュイーが自身のコードの問題点に気付き、それの修正を行うことはあるが、それによる教育的なメリットはどれぐらいあるのだろうか。おそらくほぼ無いと言っていいだろう。仮にあったとしても、それは質問形式を行ったことによるものではない気がする。

より建設的なレビューをするために

  • 提案をする(コスト:低)

    • 提案形式で済むのなら、積極的に提案形式でレビューしたほうが良い。先に述べた通り質問形式は「こじれ」を引き起こすリスクを持っている

    • 答えを与えることに対する教育的なデメリットを感じる人もいるが、それは無いし、自発的な修正による教育的なメリットもない。もしそれが期待できるような状況ならば、「勉強も兼ねて周辺を調査し、最適だと思う手法を提案してください」ぐらいまで伝えた方が良い。

  • 純粋な質問であることを伝える(コスト:低)

    • 疑問に思ったときに使う。「ask」や「純粋な質問なのですが、」をつけるだけでいい。レビュアーが余計な真意を探る「こじれ」を減らせる。

  • 具体的な指摘をする(コスト:中)

    • 何が問題なのかを伝え、それと期待する修正内容を伝えるとより良い。

  • 指摘内容の意図や背景を伝える(コスト:高)

    • 技術的な差やドメインの差がある場合に必要になる。

コストの高いレビューをレビュアーに期待するのはやめる

自分がレビューするときはこれらのことを意識していきたいが、一方で人のレビューにこれらを期待するのは少し虫が良すぎるかもしれない。なぜレビュアーが質問形式を使うのかと言うと、それが楽だからだ。

雑なレビューを受け取ると少しがっかりすることもあるが、まずはレビューのために時間を割いてくれた相手に感謝の気持ちを持つようにしよう。

git ですでに管理されているファイルの変更を無視する

.gitignoreとは違い、既に管理されているファイルの変更を無視したい。

環境依存の関係でどうしても変更したいが、全体には影響させたくないときに使う。

1git update-index --skip-worktree [ファイル名]

git update-index はインデックスを更新する。インデックスはワーキングツリーとリポジトリの中間に位置するステージングエリアのこと。

これの--skip-worktreeオプションでファイルの変更を無視する。

この操作を取り消すには --no-skip-worktree を使う

1git update-index --no-skip-worktree [ファイル名]

注意点

--no-skip-worktree を使うと、変更を検知することができなくなる。そのため、変更を取り込めないことによる別のトラブルが発生する場合がある。後述する--assume-unchangedの方が目的に合っている場合もある。

--assume-unchangedオプション

似たようなオプションで、--assume-unchangedがある。--skip-worktreeがファイルの変更を無視するのに対して、--assume-unchangedはローカルでのファイル変更が無いと仮定するように指示する。

使用目的としては、自動生成されるファイルなど、頻繁に更新されるけど頻繁に変更を追跡しなくても良いものに対して使う。ファイル変更の監視をしなくて良くなるので、パフォーマンスが向上する。

1git update-index --assume-unchanged [ファイル名]

この操作を取り消すには--no-assume-unchangedを使う

1git update-index --no-assume-unchanged [ファイル名]

--skip-worktreeと--assume-unchangedの違い

ローカルとリポジトリでそれぞれファイルの更新が行われ、マージされたときの挙動が異なる

  • assume-unchanged:ローカルの変更は破棄。リポジトリが取り込まれる

  • skip-worktree:ローカルの変更を維持。リポジトリの変更は取り込まれない。

設定ファイルにおける軽微な調整を無視したいときなどは、将来の変更が取り込まれる--assume-unchangedの方が向いていそう。

無視したファイルを確認する

1git ls-files -v | grep '^[Ssh]'

git ls-files -vで先頭にSがついているものが--no-skip-worktree指定したもの。--assume-unchangedを指定したものについては小文字のsがつく。マージ中にコンフリクトしたものは小文字のhで表示される。grepでそれらを抽出している。

参考