Yusaku SAWAI

KPIを算出する式が公開されていれば、その式を変形してより簡単に最大化する方法も求めることができるだろうが、それがその仕事の生み出す定性的な価値と矛盾するみたいなことはしばしばあるように感じる。

その昔、"どうやってKPIを稼ぐか"みたいなトレーニングまであるほど、KPIが重視される職場で働いていたことがあるのだけど、KPIから仕事のやり方や付加価値を逆算するという考え方は最後まで腑に落ちなかった。

世の中の多くの人は、何らかの方法で数値化が行われた時点で、定量化もできたと考えてしまいがちなのかもしれない。

例えばある成果を数値化する過程には、"何をして成果とするか"という恣意的で定性的な要素が含まれているにも関わらず、その中身はろくに吟味しないまま、数字の大小比較や割合を計算して喜んでる人がやたら多い。

別の会社にいた頃の元同僚と話していて、今の職場がいかに恵まれているのか再認識した。

"こんなに苦しい思いをしているのだからきっと価値があることをしているに違いない"みたいな発想、個人の単位だと抜け出すことも難しくないが、組織の文化のような形で定着していたりすると、集団心理的にもそう簡単には抜け出せない怖さがある。

価値があると信じることをやるのは大事なのだけど、そう信じることと、それが実際にどう評価されているかは分けて考える必要がある。
それができないと"こんなに苦しい思いをしているのだからきっと価値があることをしているに違いない"みたいな誤謬にはまってしまったりする。

仕事に価値があるかどうかって、基本的にその仕事をしている側が決めることではないから、殊更に"自分たちの仕事には価値がある"みたいなことを主張してるのを見ると、少しだけ冷ややかな気持ちになってしまう。

仕事中に信長の野望のBGMを聴きすぎて、信長の野望で遊べなくなってしまった。

世の中にはこういうことに付加価値を見つけてる人もいるのかもしれないけど、私は自分の仕事にし続けたいとは思わなかった。

eTax+AmazonPayで予定納税II期完了 - ほんとシステムの導線がひどい。今年から納付書送らなくなったのだから、もう少しマシにできないものなのだろうか。

今更気が付いたけど、作文する仕事が嫌いなわけではない。記号を使った文章の装飾やら、半角英数字の前後にスペース入れる入れないやら、ごはん論法や霞ヶ関文学のような、本質とは乖離したことを考えるのが嫌なだけで。

Affinityで遊んでみようかしら。

テクニカルサポート自体は価値がある仕事だと思っているけれど、技術に重心を置いてキャリアを歩みたいと考えてる若手のエンジニアにとってベストな選択かというとそうじゃないのではと思っている。

そもそも本当に技術的に高い付加価値を生み出す仕事を1日に10件とか20件とかの単位でできるはずがないと思っていて、仮にできるというのであれば、それは"高い付加価値"が何を指すのかからきっと違うのだろうと思う。

サポートエンジニアという仕事をやることはおそらくもう2度とないけれど、1社だけの経験を元にサポートエンジニアとは…みたいなこと言うのは確かに正しくない気もする。

ASDとADHDが排他的であるかのような言説をよく見るけど、どこが出元なんだろう。実際には併発してることが多い気がする。

ユーザーが本当に望んでいるのは、質が高い技術サポートではなく、そもそも技術サポートに頼らなくても済む安定していて使いやすいサービス・製品・ドキュメントなのではないか…という考えがあるので、技術サポートを独立した製品やサービスのように考えることについては思うことがある。

基本的に能力や資質のある人は、他にベストだったりベターな環境を選ぶことができるから、そう言った環境は生存バイアスを持った人間によって、いつまでも改善されないまま放置されて朽ちていくが、それもまた仕方のないことなのかもしれない。

「本人の努力次第」と言ってしまえば、なんだってそうなわけだけど、努力するにあたってベストもしくはベターな環境にする気はないって言ってるようなもので、どうなんだろうな…とは思う。

ダメな組織やそれを構成する人間って、バケツに穴があっても「実はバケツの穴はそんなに大きくない！」「バケツの穴があってもみんな頑張って成果を出している！」みたいな何の解決にも向かわないことを言いがち。

時期的な要因もあるかもしれない。寒暖差と日照時間が短くなると、体調が悪くなりやすくなる。通年で夏くらい日照時間があれば良いのに。

ここ数週間くらい思考がうまくまとまらず、作業が思ったように進んでいない。ストレス的な要因もあるかもしれないが、もっと単純な理由として問題意識が発散していて、問題の分割に失敗しているような気がする。あまりよろしくない兆候に思える。

今年は波乱の一年だった。痛みも多かった。でも前に進んだことも多かった。いつかそんなこともあったと思い返せる日が来るのだろうか。

カニカマをカニだと思って食べている人に、それはカニではないって指摘したら(仮に薄々勘づいていたとしても)怒るって言うのは考えてみれば普通の話だった。

…カニカマをカニだと思って食べる幸せを楽しんでくださいまし。

補足とその後:
リベルサスは最初の1週間に2、3回服用したものの、これ以降の服用はやめた。継続した結果としてここから9ヶ月経った現在は71kgまで減量した。

何度かリバウンドはしたものの、2〜3kgの間で押さえていて、習慣を継続したこと・その他の服薬の都合で食欲が減退したのもあり現在に至る。

…反論は議論する価値があるけど、単に"お前が言ってるのが気に入らない"ってのは反論ではないので、話しても仕方ないね…。

思うことがありXのアカウントを消した。理由は色々あるけど、見え方に非対称性があるコミュニケーションをされるのが嫌というのが大きかった。

あらゆる破壊的変更は、十分に原因や影響範囲が絞り込めていて、バックアッププランがない限りはできない。

時系列的な検索と、事象の発生条件・範囲等の状態・状況に基づく検索を組み合わせて、一つ一つ挟み撃ちしていくのが重要で、十分に挟み撃ちしないうちに仮説を立てて突き進むと、その先には袋小路が待ってる。

たまにトラシューを推理小説になぞらえて話す人がいるけど、それやると大抵作者の思うツボになってしまう。(経験談)

インシデントハンドリングなど、特に急を要する場合、どうしても仮説に引っ張られがちになる。

ソフトウェアに変更を加えた直後に起きたという理由で、それを原因と決めつけてしまったものの、共通の変更を持つ他のソフトウェアでは発生せず頭を抱えていたら、実は背景に全然別の原因が存在したことがあった。

仮説や推理がバチっとハマると確かにカッコいいけど、事実関係を一つ一つ確実に整理していくことの重要さを身をもって学んだ経験。