OKURA Masafumi

OKURA Masafumi

@okuramasafumi.com

A Rubyist.

161 followers141 following309 posts

There are two new crisis in a software world. 1. We, software developers, are not capable enough for our jobs/tasks because we've avoided to face the true difficulties. 2. The moral/morale of software developers goes down because we are now treated as a replaceable resource.

「だから君たちはまだまだなんだよ、もっと精進したまえ」という精神性を持つことがメンタルヘルスの鍵。

「理論」というのは、例えば英語を話すときの英文法の理解みたいなものだと思った。英語は書けて話せても、自分の英文法の理解をそのままダンプするのはとても難しい。ボランティアで英語を教えているときに、生徒の質問に導かれて自分の英文法理解を言語化することが結構あるけど、その前には理解はしていても言語化はあまりできていない。この「理論」は巨大なので実質的にはすべてを言語化することは多分できないのだと思うし、しなくてもよいと思う。ただ、理論なしに暗記をするだけだと結局実用的にならないという実感もあるので、やっぱり理論構築は必要なのだ。

何かに一人で向き合いたいとき、そこにAIを存在させたい、とはあまり思わないんだよな。ただただ孤独であることに意味がある。実際には完全に孤独であるわけもなく、自分の経験の中にいる他人はそこにいるのだけど。でも、自分自身の中を掘り下げていくとそこにきっと何かがあるのだという感覚は何年経っても変わらない。 今もいくつかのことに同時に向き合う状況になっていて結構大変なのだけど、どこか他の場所や人に答えを求めるのは間違っていると信じている。早いうちに答えが出るといいけど、時間がかかる可能性が高いから、しばらくは精神的に余裕のない状態が続きそう。

TIL: on Friday, there are so many people departing from the airport to go out. So the road is terribly busy, we need to take a highway. Otherwise it might take more than an hour to get to the airport.

マサイマラの現地時間は朝4時半なのですが、これからバルーンサファリに向かいます。 (昨日のまとめを昨日のうちに投稿したかったけど、ネットワークの不調で投稿できなかった🥲ので、あとで投稿します)

最近色々なサービスが問い合わせの電話番号をわかりにくいところに置くようになっている。スパムとかがたくさん来るし彼らにとって高コストというのもまあわかるんだけど、善良なユーザーがどうしても電話したいときの問い合わせコストが極大化していて非常につらい。

ぽっけさんに教えてもらった年縞博物館、めちゃ良かった。学者たちの挑戦に想いを馳せてことができたし、無料音声ガイドも充実してた。あのへんに行かれる方はぜひ(三方駅からタクシーがオススメ)。

OKURA Masafumi reposted

広告まみれでちゃんと読めないサイトとか、見知らぬ他人が喧嘩するように設計されたSNSとか、デマとAIまみれの動画サイトとかほんとになんなんだよ。全く慣れてなくてずっと新鮮にムカついてる あの時代は本当に狂ってたなって後世言われるようになることを願うことしかできない

明日は天橋立に行って、余裕があれば小浜にも行きたいけど、さすがにその旅程は無理っぽいかなあ…小浜に行くと帰るのがめちゃ大変になってしまう…

三方のスーパー銭湯に行ったけど、券売機が故障して長蛇の列だったのでキャンセルして早めに舞鶴に向かうことにした。

色々な分野でそうなのかもしれないけど、特にソフトウェア開発の分野では人間1人の生産性(測定可能な能力、と言い換えても)の重要性が下がっている感覚がある。ゲームで言うなら、全員が前衛タイプの精鋭であるパーティーより、バフ役や回復役が適切に編成されているパーティーのほうが強い、みたいな。 (ゲームの比喩を使うとすごく当たり前に聞こえる…) そしてこの状況下では、個人の評価を行うことはすごく難しくなる。役割が先にあってそこに個人が入ると考えると、同じ役割同士でないと適切に評価・比較できない。しかし比較対象内部(社内など)に完全に同じ役割のポストが複数あるとも限らない。

チーム(パーティー)内で勝ちパターンを共有しつつ、そこから外れるときにリカバリー可能である必要がある。リカバリーのときにはむしろ特定個人の重要性が跳ね上がることもある(状態異常耐性のあるヒーラーとか)。 …などということを考えていて、「勝ちパターンの共有」には座学が結構大事になるという事実に思い至った。RPGでもサッカーでも、相手の数値を研究したりするわけで。ソフトウェア開発の文脈ではこの種の座学が軽視されているのかもしれない。 キーワードは「チーム戦」「事前研究」「勝ちパターン共有」あたりなのかな。

Amazonの書籍レビューで、「この本は頭が悪い」趣旨のレビューがあったのだけど、長い文なのに「。」がなくて全部「、」の超絶読みづらい文章になっており、なんというかアイロニーを感じた。文章を読む力と書く力は大体比例すると思う。