  |
はてなキーワード: スクリーンショットとは
確定申告の時期なので、会計ソフトでサクッと電子申告。なにも難しくはない。
納税もオンラインで出来るらしいのでE-TAX(https://www.e-tax.nta.go.jp/)を使ったのだがコイツが最高にクソ。
具体的には、WEB版にログインして所得税の納税登録を進めていくと、
「課税期間は平成24年まで、または令和20年以降の日付を入力してください」
と表示される。マジで、スクリーンショットもとったから見たい奴は言ってくれ。
とても納税と言う国の重要な部分を司るシステムとは思えない。どんだけクソだよこれ。
2022年(令和4年)1月1日より施行される改正電子帳簿保存法についてレクチャーを受けたので忘れないうちにメモしておく。
この日記を書いた増田本人は税理士ではないので間に受けないように。
以上
今の日本だと誰がこんなマニュアルを読むんだ、読まないマニュアルなんて無駄という感じだろうが、このあたりが日本の弱いところではないだろうか。
こういうマニュアルを作る文化は軍から脈々と引き継がれていると思っていて、米軍の使命としてド素人を訓練しないといかず、マニュアルを作る。
日本だとマニュアル人間は嫌われる傾向があるが、マニュアル人間が大多数でも、柔軟にマニュアルが更新かけられれば問題ない。
ソフトの話に戻ると、何千ページもあるようなマニュアルでも、途中からプロジェクトに入ってきた人には全体像がわかるし、
マニュアルの1行1行を塗りつぶすようにテストコードを作っていく。
全部のテストが通るとマニュアルの文言も正しいことが保証される。
誰も読まないのだからマニュアルなんて作らずYouTubeで動画にすればいい、というが、動画にするのはこのマニュアルを読んだYouTuberにアウトソースすればいい。
スクリーンショットをペタペタ貼るのがダサいという風潮もあるだろうが、UIを変更する人もいるので、必要だ。
何千ページあろうが、（少なくとも顧客視点から）このドキュメントを読めばプロジェクト全体がわかるのがないと、全部を覚えている人などいないということになる。
日本は大規模かつ複雑なプロジェクトを放棄、大規模なドキュメントを作って残すこともしなくなっているように思うが、どうだろうか。
ふりーむは2000年から現在まで続く老舗のフリーゲーム公開サイトで、今も1万本以上のフリーゲームを遊ぶことができる。
そんなサイトの歴史が1人のVtuberの気まぐれで崩されてしまった。
今日の週間ランキングを見てみると、1位が某Vの作ったゲーム（週4800プレイ）、2位がそのゲームのブラウザ版（4000プレイ）、3位のゲームが860プレイ程なのに対して明らかに頭1つ2つも抜きん出てる。
累計では2017に公開され話題になった｢影廊」をたった2ヶ月で抜き上位9位に入るなど、凄まじい躍進ぶりを見せている。
某Vの信者たちは概ね「ふりーむとか懐かしすぎる」や「あえてふりーむ使って昔のネタかする感じ好き」と言った感じだったが、厄介フリゲ作者から言わせてもらえばいい迷惑だとしか思えない。
企業の名前を使ってフリーゲームを出すならアツマールなどもっと適したサイトがあったと思う。
ふりーむはアマチュアとプロで露骨に差が出ないようにサムネイルもかならずゲームのスクリーンショットから選択する必要がある（加工が禁じられている）ほか、ユーザーによる評価制度（☆5段階評価など）がないなど、プレイヤーより作者側を優遇したプラットフォームになっている印象があった。
PART2に戻る : anond:20211106011219
15年ほど前に遊んだ子供向けのFlashゲームのタイトルが知りたいです。
取り敢えず質問者に自信は無いようだが、楽天グリーティングを検索してみる。
2015年にサ終したという解説のページに跳んだ。リンクが存在していたので、そこから辿ろうと思う。
トランペッター・ジミー!
時期を変えればページまで飛べそうだが、Flashは既に終了している。
RuffleやFlashpointなどのフラッシュ再生の動きもあるので頑張れば遊べそうだが、
捜索の範囲外なのでここで終了。
12〜13年ほど前に23時頃に放送された一話完結のドラマです。渋谷で待ち合わせをする何人かの人たちが、
黄色いスカーフを巻く等の特徴をつけていましたが、それによってかえってそれぞれ待ち合わせ相手を間違えてしまい、
今回はこのテレビドラマデータベースを使用。サイト内の詳細検索。(ただし情報にムラがある)
今回の場合、
渋谷 黄色 スカーフ 待ち合わせ 勘違い 秘密...などワードが想起されるが、
10年以上前の記憶は少し丁寧に取り扱う。どれか一つが間違っていると検索沼に落ちるので。
http://www.tvdrama-db.com/drama_info/p/id-40385
一応タイトルでGoogle検索をかけ裏取り。あらすじがヒットしたが、
ちなみに期間指定がある情報は、プラマイ2、3年した方が時期ズレに対応できる。出ない場合に調整していけば良い。
貝がらブラッコのメインフレーズによく似た童謡の曲をどなたかご存知ないでしょうか？
この曲を聞いた時、幼稚園のとき歌ってた何かに似てるな〜って言おうとするも何だったか思い出せず、
正直音系を検索するのは虎の巻手法では不可能である。ので、今回はネットの集合知を参照することにする。
通常であれば他の方々に聞いてね。
検索対象はyoutube、ニコニコ動画、Twitterなどのコメントである。
Twitterで動画のアドレス＆タイトルをそのまま入力し、誰かが言及していないか確認。
Youtubeのコメント欄に目を通す。(Youtubeコメントはオフだった)ニコニコにも。
童謡「すずめの学校」 間寛平「なめなめくじくじなめくじくじ」
すずめの学校で正解だった。
今回増田化にあたりお試し再検索したが、同意見の投稿は見つかりにくかった。危な！
めちゃくちゃ難しい質問ですみません。あるmemeのBGMが知りたいです。
アメリカ西部らへんで子供と犬が出会いポケモンバトルが始まるが、
子供が逃げる（なんでかは覚えてないです）それを犬が追いかけてます。
海の中に潜ったりバーで一緒にお酒を飲んだり、エレベーターに乗ったりして、
曲調はイニシャルDに似てる感じがします（イニDの曲を聞いてこのBGMを知りたくなった）
難しいですがお願いしますm( )m。
MAX COVERIの曲、running in the 90's
問題は、この動画が見つかったのはrunがrunningで引っ掛かっただけの全くの偶然。
childをkidにする発想もなかったので、本当に運が良かった。
(ちなみに鼻歌で曲を検索するならSoundHoundも優秀)
[soundcloudのリンク] 以下[曲]
[曲]について誰か言及してる筈と思い、SoundCloudの共有リンクをTwitter上で検索。
ヒットはしたが、感想ばかりで情報は出て来ず。投稿されている曲名も正式なものではない。
少しでもヒントが欲しいので、各ユーザー感想ツイートの周辺ツイートを漁る。
from:xxxxxx until:201X-XX-XX since:until:201X-XX-XX
数人分試したが、言及ナシ。
ならばと思い、投稿者を漁る。他の投稿動画は[曲]を含め2曲のみ。
別の曲はジャンル違いのRemix。もしやこの人の作曲ではない？と推測。
Twitterアカウントは存在したが、投稿ツイートは存在せず。転載の下に進める。
シンプルにタイトルで検索していれば2手で済んだのに、やたら遠回りをしてしまった。
とっかかりが少ない...雰囲気のよいBGMと、縦長形式、シンプルにまとめられた内容、恐らく大元はtiktokと推測。
投稿アカウントを確認すると、多様な動物の動画がズラリ。こりゃ転載だな。コメント欄を検索するもヒントは無し。
ペットショップのFacebookが出てきたので、該当の動画を探す。
チンチラを載せたtiktokの別動画を発見。元動画内でチンチラがイスに乗ってるが、この動画にも同じイスがある。
同一投稿者だと推測し、投稿者を捜索。この動画にはIDが載っている。どうやら質問された動画の方はIDを消してある模様。
次はBGM。動画情報に tutiandyuki - sophi との記載がある。
そのままGoogle検索。なんか人がBGMに合わせて舌をペロっと出す動画が沢山ヒット。なんじゃこりゃ。
思考を元ネタ調査に切り替える。これだけ上がる動画ならmemes扱いなのか？
memes tongue tiktok でGoogle検索。トレンドの解説サイトがヒット。
https://stayhipp.com/media/tiktok/the-hilarious-tongue-sticking-out-tiktok-trend/
つまり、
...って感じらしい。ややこしや。声はチンチラのじゃないのね、そりゃそうか。
そういう動画文化があるって知ってればトレンド解説のサイトまで一発で飛べたな...
一応、コレで捜索法は終了。他にも小テクとか支援ツール、サイトあるけど割愛。
当たり前だが、ネット上に挙げられていない情報は検索できないので、ネットの集合知を参照するほかない。
また、出ないものもあるので過信は禁物。結局は集合知最強なので。
それじゃね～ノシ
part1 : anond:20211105031842
part2 : anond:20211106011219
補足 : anond:20211105041538
「そんな方法は無い」って即答できる？
それとも俺みたいに、実は親は「ログオン画面に表示される風景写真が気に入ったのでプリントアウトして保存したかった」というのが真相だという事を一瞬で推理して、
C:¥Users¥＜ユーザー名＞¥AppData¥Local¥Packages¥Microsoft.Windows.ContentDeliveryManager_cw5n1h2txyewy¥LocalState¥Assets を開いて、
.jpg拡張子の無い画像ファイルの中から当該風景写真を探し出し、それをL判写真出力する。ここまで尋ねられてから5分以内で、できる？
University of the Peopleで準学士号を取ろうと思い、9月に入学した。Online Education Strategies (UNIV 1001) に絞って履修していたものの、勉学と直接関係ないところでちょくちょくパニクりかけた。なのでここにまとめておく。誰かの参考になったら嬉しい。
とにかく遅い。履修登録期間などは特にひどい。ルービックキューブみたいなアニメーションをどれだけ見たことか。焦るな。
取りあえず出願だけして、あとからDuolingoの試験受ければいいやと思ってたら、いつの間にか出願段階が進んでて、自動的にEnglish Composition 1に登録されてしまっていた。
Admission Advisorにメールで連絡したら、「今からでも間に合うので書類を送ってください」という返事。Duolingo側からUoPeopleにスコア送付するとともに結果のスクリーンショットをメールでAdmission Advisorに送ったところ、事なきを得る。
課題の提出方法などのチュートリアルビデオは、Youtubeの公式チャンネルにまとまっている。
https://www.youtube.com/playlist?list=PLzDSQFS87t6HBFEjbZJ3DhHbnaW3kAhnd
Learning Resource Centerは、実質的には各種アカデミックスキルのチュートリアル集＋質問フォーラムなのだが、それ自体がひとつの科目みたいな体裁になっていて、利用するにはEnrollが必要。
APAで行き詰まったときには参考になるし、質問フォーラムの回答も早い。
Discussion Forumの返信にも単語数制限がある。「100語以上」と「3～4文程度」と条件が二つあったので、後者だけ満たしていたら減点された。あと参考文献リストは単語数カウントに含めないとのことだった。
ここらへんはCourse Instructorによって運用が違うかもしれないので、確認した方が良いと思う。
Replyを押すだけだと簡易エディタが出るのだが、Advancedをクリックして多機能エディタを出した方がいい。特にReferenceつけるときはイタリックにしないといけないので必須。
あとAdvanceクリックすると親投稿だけのツリーが表示されるので、リプライ先を確認しやすい。別エディタで書いた内容をコピペで貼り付ける場合、"Hi ～, " のような呼びかけで文章を始めておくと、更にチェックしやすい。防ごう取り違え事故。
投稿後5分したら訂正できなくなる。投稿直後によく見直すこと。
なお確定後に間違いを見つけた場合、更にリプライをつけて正誤を説明するという手もある。絶望するなかれ。
Word形式が指定されている場合、Moodle上のテキストエディタではなく、その下のファイル添付のところから添付する。
学期最後のピアアセスメントでも、ファイル添付できていない学生がいた。手間や自身の環境を考慮して、フォーマットの点数は無視する戦略を取ったのかもしれないが。
自分の課題を提出→クラスメイトの課題を評価→自分の課題の成績が確定、というすべての段階が終了してはじめてチェックマークがつく。要は課題が出た翌々週になるまでは空欄のままになる。焦るな。
"Submit Assignment"をクリックしただけでは提出できていない。「本当に提出しますか？」というページが表示されるので、"Continue"を押して確定させること。
一周して満点が取れたからと安心するのは早い。問題は一周分より多く登録されているので、何周かしないと全制覇できないのである。
大学全体の履修登録期間の始まりと、個々の学生の履修登録可能期間の始まりとは一致しない。卒業が近い学生の方が優先的に登録できるシステムになっているため。UNIV1001を履修するような学生の番は当然遅い。Student Portalの「Register for Courses」を見れば、自分がいつから登録できるか書いてある。
要Proctorの科目の場合、履修登録期間中にProctorを設定しないと登録が取り消されてしまう。ProctorUを使う場合は、Student Portalの「Manage Proctors」から「ProctorUを使う」みたいな項目を選ぶだけでよい。
去年の今頃までは存在すら知らなかったが、ふとしたきっかけで購入することになり、何種類か持っている。
iroha製品には『購入後1年間の保証期間』がある。私が持っているものは全て充電式のものなので、乾電池使用のものにもこの保証期間があるかは知らない。
『家電製品とかならわかるが、使用したバイブやローターを修理したり交換したりするのか、すごいなiroha』と思いはしたものの、
まさかその1年保証の期間内に不具合が起こることなど想定もしていなかった。しかも、バイブとローター、ひとつずつ壊れた。
どんな使い方をしてたらそんな数ヶ月で壊れるのか？
使い方は普通だと思う。生活防水でバスタブでも使えるとか書いてあるけどそんなとこで使ったこともないし、毎日何時間も使い倒したわけでもない。開発者の想定外の使い方をした記憶はない。
iroha FIT みなもづきという定価10,000円超えのバイブ。普通に使えていたが、あるとき『あれ？長押ししても電源が入りづらいな』と感じた。それでもグッと押せば電源は入ったので、そのまま使い続けるつもりだった。ところが、次に使おうとしたところ、どんなに押しても無反応。
このときまず思ったのがバッテリー切れ。さっそく充電ケースに入れて充電した。
充電中に点灯するランプはついている。これが消えると充電完了なのだが、やはり電源オンの長押しをしても全く動かない。iPhoneなどと同じリチウムイオンバッテリーが使われているので、電池の寿命？とも考えたが、そもそも電池の寿命かなと思うほど毎日毎日使っているわけでもない。充電ケースで充電できるが、充電しないときはケーブルを抜いていたので、ずっと充電状態になっていたとかもない。
同じ症状になった人がいないか、Amazonのレビューを読んでみた。確かに『数回の使用で動かなくなった』というレビューはあった。
他のアイテムのレビュー欄にも不具合や初期不良のことを書いている人はいたが、保証を受けた人の情報はネットでは得られなかった。
irohaのホームページに記載されているお客様相談センターに電話をかけることにした。
平日10時〜19時まで、女性オペレーターが対応していると書かれてあった。
『突然バイブの電源が入らなくなった。充電ランプはついて充電できたが、本体は動かない』と伝えた。
あっさりと、『交換対応とさせて頂きたいと思います』という返事があった。
お問い合わせフォームから一旦メールを送って返信を待って…とか説明を聞きつつ、私は内心思った。
いやいや、iPhoneの充電ケーブルじゃないんだから（apple careの保証期間内なら交換してもらえる）…
アソコに突っ込んだものを送り返す？
しかも、送り返した製品はどんな不具合があったかを調査する部署で『今後の品質向上のため』に故障原因を調べるらしい。
自分の顔写真付きで送るわけではないが、レビューの中に『返品もできないので…』と書いている人もいたが、恥ずかしいといえば恥ずかしい。その人が1年保証を知っていたかどうかはわからないが。
ネットにもあまり情報のない、irohaの保証期間内対応をここに書いてみたいと思う。
電話の中で、irohaのオペレーターさんからの案内はこんな感じだった。
まず、私が買ったのはAmazonだったので、購入履歴と明細書のスクリーンショットをirohaお客様センターからのメールの返信に添付してほしいということ。
そのためには一旦、iroha公式サイト内にある【お問い合わせ】のページから【iroha製品の不具合についてのお問い合わせ】を選び、必要事項を入力してくださいと言われた。
早速そのページを開き、入力開始。
（細かい内容は忘れたので、今これを書きながらお問い合わせページを開いている。）
そうか、当たり前といえば当たり前だけど、名前や住所といった個人情報を入力していくのか…アソコに突っ込んだやつを送り返すために…
メールアドレス、電話番号も入力する。電話番号は問い合わせの時点では入力必須ではないが、郵送で交換するときに必要になるので私は普通に書いた。
次に、製品を選び、チェックを入れる。画像付きなので、自分が持っているものがすぐに見つかる。
続いて、購入場所を選ぶ。
◯その他のネットショップ
◯その他の実店舗
◯その他
【その他〜】がつくものは、チェックを入れたあとに具体的な店名を入力する欄がある。楽天やニッセンなどでも売られているので、入力するのだと思う。一番下の【その他】は…『プレゼントでもらったため不明』とかだろうか。
私はAmazonにチェックを入れた。
次に購入時期。例に【2013年5月頃だった場合→201305】とある。これはAmazonの購入履歴ですぐにわかったのでさっさと入力。
最初に出たirohaとその上位互換のiroha +とかだと、充電台が全く同じなので使い回しができる。ロットナンバーが商品と一致しているか忘れた場合はそう伝えれば対応してくれる。
【保証書の有無】
アリもしくはナシにチェックを入れる。保証書は取扱説明書の最後のページにあるにはあるが、自分で記入するもので、一番下には販売店（店名、住所、電話番号）レシート添付と書いてある。Amazonで買ったから正確な購入日時を証明できたが、そうでなければレシートを置いておき、小さいメモ用紙くらいの保証書に貼っておかなければならなかったのだろうか？私は絶対にそんなことは思いつきもしないので、Amazonで買ってよかった。定価より安かったし。
次がちょっと『おお…』となった項目。
◯毎日
◯週2、3回
◯週1回
◯その他＋入力欄
必須項目ではないのと、この質問って、毎日ごく短時間使った人と、週2くらいでガンガン使ってる人を判別することはできないよなぁ…と思った。それに、たとえば3日連続使ってその後結構使わない期間があったとか、色々ありそうだし。
【お問い合わせの不具合が起きた時期】
◯初回使用時
◯2、3回使用した頃
◯その他＋入力欄
初回使用時とかだと不良品だったとわかる…程度の質問項目だろうか。
【お問い合わせの不具合の発生頻度】
◯初めて
◯たまに（5回に1回程度）
◯度々（3回に1回程度）
◯毎回
私の場合、ちょっとボタンの効きが悪いなぁと思ってからすぐに完全に動かなくなったのと、先に電話でのやりとりがあったので、どれを選んだっけ？
【お問い合わせの不具合の内容】
充電器に関する不具合
これは複数回答となっている。
そして最後に、
久しぶりの必須項目。
そして文章入力。記入例のところは1行程度の文章になっているので、
【電源ボタンを押しても本体が全く動かなくなった。ランプはつくので充電はできている】くらいでいいと思う。
これでお問い合わせフォームは終わり。
確認画面が出て、入力したメールアドレスに問い合わせ受付自動返信メールが届く。
その後、オペレーターさん本人からのメールが届き、こちらはAmazonの購入日がわかる履歴のページと明細書のスクショを添付して返信。『保証期間内という確認が取れましたので…』というメールに、動作確認をした代替品を送るので住所、名前、電話番号などを書いて返信してほしいと書かれていた。あとは、家族が荷物を受け取る場合があることに配慮してか、TENGA何とかかんとか〜という社名を記載しないようにできますとかも書いてあった。具体的にどのように代替品と手持ちの動かないバイブを交換するかの案内が返信されてくる。
そこに記入済みの着払い伝票が入っている。箱は全てそのまま使えるのはラクだった。
バイブ本体、充電ケース、USBケーブル、付属アダプタ全て交換となる。
私は『今は、もう、動かないこのバイブ』を必死で洗い、充電ケースもシートで拭きまくった。この丸洗い可能というのも購入の決め手になったのだが、まさか返送するなんて思いもしなかったので、今まででいちばんガッツリ洗った。
irohaのサイトや説明書には、『お手入れは水かぬるま湯で、汚れが気になるときは石鹸か中性洗剤を使用してください』と記載がある。
また、泡タイプの専用クリーナー（使い終わったあとにクリーナーを使い、ティッシュで拭き取る）も発売されたが、何だか気持ち的に…
やっぱり毎回ちゃんと洗いたい。
中性洗剤は家にあるので洗うときに毎回使っていたが、上に書いたお手入れ方法だと、『水かぬるま湯だけでの洗浄』を推奨してるのか？と不安に思い、オペレーターさんに聞いてみたところ、石鹸か中性洗剤であれば毎回使っても大丈夫だとのことだった。
洗いまくったバイブをキッチンペーパーで水気を取り、充電ケースもできる限り綺麗にして、届いた箱から代替品を出して、入っていたときと同じ状態にしてまた箱にいれ、クッション材などもそのまま使用。ガムテープを貼って、着払い伝票を持って、すぐに近所のコンビニから送り返した。先に送ってくれてるのに、こちらは持ったままなのは嫌だったから。
これで交換完了。
終始電話でもメールでも丁寧に対応してくれたオペレーターさんにお礼のメールを送り、終わったー！とほっとした。
いざ『交換します』となってみれば、別に恥ずかしくも何ともなかった。
電話でオペレーターさんは『順番に対応しておりまして、代替品を送るまでに数日頂くことになりますがご了承ください』と言っていた。
私以外にも保証を受けている人は、いるにはいるんだなぁ…と何気なく思った。
その時点では、まあ、こんな経験もうないだろうけど、と思っていた。
突然全く動かなくなったあのバイブ、何で壊れたのかはわからないまま。
必死で洗いはしたものの、購入者がアソコに突っ込んで1年せずに壊したあのバイブを…irohaの社員さんが分解とかしてるんだろうか？
せっかく保証期間があるのに、ほとんど情報が見つからなかったので、実際の体験談を書いてみた。
ローターを壊した話は、
追記を使って書きたいと思う。
「鴻巣友季子の時評は何が問題なのか」（https://anond.hatelabo.jp/20210826203711）の著者です。
非本質的な、《誤読か否か》を議論するコメントが依然として多いので、記事を改めて補論を書きます（文中敬称略）。
元の記事では鴻巣の意見から矛盾を示すために使ったまでで、「解釈」という言葉を本文で一切用いずとも問題を整理できるし、他にも鴻巣の矛盾を指摘できるのでそうします。
「作中に描写がないこと」を「作品に書いてあるかのように読める断定で書いた」こと
である。
そしてこの点について鴻巣はスルー、もしくは無理筋の意見を出しているのみである。
①27日13時39分
いえ、また繰り返しになりますが、どう評しても自由とは言っておらず、
「読まれ方は自由だが、実際の描写にはないストーリーを、読み、想像で考えたとき、それを主観的な解釈として書くのはよいが、実際にそう書かれていたように客観的事実として書くのは一線を超えている」
と考えています。（続）— 桜庭一樹 (@sakurabakazuki) August 27, 2021
②27日16時43分
繰り返しになりますが、そういった解釈の豊かさ、多様性が大切である一方、今回の
「直接描写されていないことがあたかも書かれているように掲載されてしまった」
は異なる問題だと思います。
ここは、どうも平行線で、同じやり取りをずっと繰り返しているので、そろそろやめたほうがよいかなと。— 桜庭一樹 (@sakurabakazuki) August 27, 2021
桜庭自身は鴻巣との対話をやめたが、外野はこの点について把握しておくべきであろう。
Aさんが重病にかかり、病院のICUにいる描写がある。
場面が転換して、葬儀のシーンになり、棺が運ばれていく。
Aさんの友人が泣いている。
「Aは死んだ」という明示的な記述はなくても、「死んだ」と理解する合理的な理由があります。
あらすじとして「Aは亡くなり……」と書くのはNGでしょうか？— 🐈🦔鴻巣友季子（『翻訳教室 はじめの一歩』（ちくま文庫）） (@yukikonosu) August 27, 2021
このツイートが議論として成立するためには、「描写がある」「明示的な記述はなく」という仮定は客観性を持たねばならない。「主張が正しいか」という検討以前の条件である。
よって鴻巣は、桜庭が言う「直接描写されていないこと」は、主観ではなく客観としなければならない。
④27日11時6分
なにが作中に有り、なにが無いか、その判断もまた作者桜庭さんの主観にすぎない、ということはお分かりいただけないでしょうか。つまり、あるひとりの読者＝作者の主観だということです。「読解の自由」はお認めになると。それは作中になにが書かれているかを決める自由でもあるのではないでしょうか。— 🐈🦔鴻巣友季子（『翻訳教室 はじめの一歩』（ちくま文庫）） (@yukikonosu) August 27, 2021
お分かりいただけただろうか？
鴻巣は桜庭の言う「直接描写されていないこと」を「なに」という言葉に置き換え、「あるひとりの読者＝作者の主観だ」としている。この矛盾について解決しない限り、鴻巣の意見は無理筋であり、鴻巣は桜庭と議論する土俵にも立てない。
なお、鴻巣は主張が成立しないのだから、厳密には「平行線」ですらないだろう。
テクストに「ない」ことを「ある」かのように書いた（ことが検証できる）あらすじなどという珍妙なものを読む機会がないので、そのようなあらすじを目にしたのちにいざ対象のテクストを読み始めた者がどう反応するのか、筆者には確たることは言えないが、あらすじに書かれた鴻巣の解釈だけを前提とし、桜庭の提示した（あるいは以下で私が説得的に示す「真っ当な」）解釈に思い至りもしない、という可能性はあるだろうと考える。
それは「読み」が閉ざされたことを意味する。なお、「どこかでおかしいとわかるはずなのでそうはならない」と言うのであれば鴻巣の書いたあらすじが頓珍漢だと認めることになる。
また、鴻巣はEvernoteでは「作品紹介のあらすじと解釈を分離するのはむずかしいことです」と述べていたが、「むずかしいこと」ではなく「不可能な」ことにすり替わってしまった。
たいへん明快なご解説を拝読しました。今回、作者は「あらすじと解釈の分離」という一点に要請を収斂されました。仰る通りそれ自体は不可能なのですが、「読む」という行為この根本的なことが、意外にも一般に理解されにくいようなのです。— 🐈🦔鴻巣友季子（『翻訳教室 はじめの一歩』（ちくま文庫）） (@yukikonosu) August 27, 2021
こうしたすり替えをわざとやっているのであれば大した度胸だと感心する。同時に、不誠実な書き手だと評価する。
ついでなので、鴻巣の読解が「曲解」であることも示します。（「誤読」とは言いません。桜庭が使わないので。）
不仲だったころもあったよね、と遠慮がちに聞くと、母は「覚えてない」と心から驚いたように見えた。離婚の話が出たことなど具体例を挙げてみるが、「そうだったっけ？」と不審げになる。それから急に目を光らせ、「人の記憶って、その人によって違うね？」と言った。
瞬間、母とわたしが同じ過去の〝ある時〟……七年前に最後に会った時のことを思いだしているとわかったが、いま対立するのは不毛だと、「ふーん……？」と目をそらした。
それから、
「もしかしたら、病気になる前は、お互いに向きあってたから性格や考え方がちがいすぎてぶつかってたんじゃない？ この二十年は病気という敵と一緒に戦っていて、関係が変わったとか」
と言ってみると、母ははっと息を呑み、「そう、その通りだ」と大きくうなずいた。
（桜庭一樹「少女を埋める」https://note.com/sakuraba_kazuki/n/ne3b7aa29cd58）
「不仲だったころ」は「病気になる前は、お互いに向きあってたから性格や考え方がちがいすぎてぶつかってた」を指すのではなく、介護していた「この二十年」を指すというのが鴻巣の読解です。
この読解を支持できる方は根拠をつけて教えてください。「病気になる前」であるという解釈をあえて却下する理由込みで。
なお、この点についてのツイートを鴻巣はなぜか削除していますが、ツイートはこちら（https://twitter.com/maffumi/status/1431506303784943616?s=20）へのリプライの形でした。（スクリーンショットを見たければTwitterに上げても「私は」構いません。）
さて、（桜庭も言及している）「母は「覚えてない」と心から驚いたように見えた」に呼応する、
いよいよ蓋を閉めるというときになって、母がお棺に顔を寄せ、「お父さん、いっぱい虐めたね。ずいぶんお父さんを虐めたね。ごめんなさい、ごめんなさいね……」と涙声で語りかけ始めた。「お父さん、ほんとにほんとにごめんなさい……」と繰り返す声を、ぼんやり寄りのポーカーフェイスで黙って聞いていた。
内心、（覚えてたのか……）と思った。
（Ibid.）
の「内心、（覚えてたのか……）と思った」も、「不仲だったころもあったよね、と遠慮がちに聞」いたのも、「もしかしたら、病気になる前は、お互いに向きあってたから性格や考え方がちがいすぎてぶつかってたんじゃない？」と言ったのも、すべて〈わたし〉なので、「不仲だったころ」をいつとするかによって、母が「お父さんを虐めた」のがいつだったと〈わたし〉が考えているかも決まる（と考えるのが普通だと思いますがどうですか？）。
当然のことですが念のため言っておけば、実際にいつ「虐めた」かは、作中世界では〈母〉のみが把握し、〈母〉の心中に作品の視点は入り込めない。よって問題となるのは〈わたし〉がどう考えているかを、〈わたし〉視点の文章で解釈することです。
私は「不仲だったころ」を「病気になる前」としか解釈できません。よって「虐めた」のも「病気になる前」としか解釈できません。
困りました。私の読解力がないんでしょうか。解釈の自由を標榜する皆様、お知恵をお貸しください。
「テクスト解釈の可能性は無限である」と言っても、それは「解釈の対象、つまりは焦点を当てるべきもの（事実やテクスト）が存在しない」ということにはなりません。「テクスト解釈の可能性は無限である」と言っても、それは「どのような解釈の試みもうまくいく」ということではないのです。
（ウンベルト・エーコ『ウンベルト・エーコの小説講座：若き作家の告白』、和田忠彦、小久保真理江訳、筑摩書房、2017年、48頁）
Floorp ウェブブラウザと名乗るブラウザが最近出てきて、開発が終了したKinzaのパッチが公開されたら取り入れると宣言してKinzaの後釜を狙ってるらしい。中の人は学生(中学生？高校生？)らしく、使っていくうちにチャラさ、痛々しさが目立ってきたのでこき下ろしていきたい。
このブラウザが気になってしょうがない人はTwitterアカウントに行けばダウンロードリンクがあるのでダウンロードして確かめればよい。
※以下の話は、断りのない限り8/28に公開された公開ベータ版(v1.1.3)のことである。
---------------------------------------------------------------------------------------------------------------------------------------------
1.Floorpをお選びいただき、ありがとうございます。高速で軽量なブラウジングをお楽しみください。
2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、Chromiumのライセンス「BSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。
3.Dev Previewエディションの場合、TwitterなどのSNSにスクリーンショットなどをアップグレードしないでください。
4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。
5.Ablazeの利用規約に沿って本ソフトをご利用ください。
6.以下に表示されている利用したオープンソースソフトウェアに感謝しましょう。Floorpはこれがなければ実現しませんでした。
7.開発者はあまりすごいことをしていないことに気づきましょう
8.ソースはこちらhttps://github.com/Ablaze-MIRAI/Floorp-Browser
---------------------------------------------------------------------------------------------------------------------------------------------
利用したオープンソースソフトウェア
[※以下略]
さて、どこから突っ込もうか。
---------------------------------------------------------------------------------------------------------------------------------------------
あああああああああああああああああああああああああああああああ開発つかれた
1.Floorpをお選びいただき、ありがとうございます。高速で軽量なブラウジングをお楽しみください。
2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、Chromiumのライセンス「BSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。
3.Dev Previewエディションの場合、TwitterなどのSNSにスクリーンショットなどをアップグレードしないでください。
4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。
5.Ablazeの利用規約に沿って本ソフトをご利用ください。
6.以下に表示されている利用したオープンソースソフトウェアに感謝しましょう。Floorpはこれがなければ実現しませんでした。
7.開発者はあまりすごいことをしていないことに気づきましょう。後眠いんだけどどうしよう？癒してください！彼女ください（）
8.Floorpは有志によって無料で提供されています。寄付は受け付けますのでダイレクトメッセージ https://Twitter.com/Floorp_Browser へお越しください
9.ソースはこちらhttps://github.com/Ablaze-MIRAI/Floorp-Browser
[※以下略]
利用規約をなんだと思っているんだ。「利用規約は楽しく、ユーモアにありふれさせたい」とか「Floorpの利用規約の最後に・彼女になることに同意しますか？って書けば同意させられんじゃん」とかつぶやいてる時点でなめてるしふざけてる。
Ablaze-MIRAI/Floorp-Browser: Chromiumで一番軽量なブラウザの大部分のソースコードです。
というタイトルなのに、実際に公開されているのはブラウザコンポーネントに比べてかなり少ない。これのどこが「大部分」なの？
あと何の根拠もなく「Chromiumで一番軽量」って言い切ってるだけで相当痛い。一番軽量かどうかは知らんが、メモリ使用量が少ない=軽量と思い込んでる節がある。ほか、
という文は誤解を生むから今すぐ止めろ。これだとBSDライセンスに違反するぜ！と宣言してるような解釈もできるから。利用規約でOSSに感謝しましょうとか言っておいてこの扱いひどくないか？
このブラウザの自己紹介記事(https://blog.ablaze.one/573/2021-08-16/)が先週公開されていたが、ここに書かれてる内容も相当痛々しい。
ブラウザをインストールするとメモリカスタマイザーなるものが同時にインストールされる。これが動作することでFloorpブラウザのメモリ使用量が劇的に減ってるから軽い、ということらしい。
しかし、ブラウザを起動したまま放置してみてから、実際のWindowsタスクマネージャーの様子をよく見てほしい。メモリ使用量が数MBとありえないぐらいまで減っているのがわかるだろう。Windowsタスクマネージャー上ではメモリ使用量が減っているように見えるが、ブラウザのタスクマネージャーで表示されるメモリ使用量はそれほど減っていない。では何が起こっているのか？
メモリカスタマイザーの正体はFireminである。名前の通り元々はFirefox用で、仮想メモリにページアウトさせて物理メモリ使用量を減らすものらしい(実際の動作は細かく見てないのでよくは知らない)。Fireminの名称変更、起動時にFloorpを自動的に対象にするといった改造を施している。FireminによってWindows10の途中の大型アップデートから搭載されたメモリ圧縮がより積極的にかかるようになり、物理メモリ使用量も減らせるメリットはあるようだ。YouTubeのトップページを開いてしばらく待った時、メモリカスタマイザーの使用時と未使用時で約0.1GBの差はあるのは確認できた。ただし、メモリ圧縮の代償はパフォーマンスの低下。特にページアウトによりディスクI/Oが増える。ディスクI/Oが足を引っ張って重くなる場合があるので、必ずしも軽いとは言えない。
結局の所、Chromiumを改造するなどの根本的な解決策を取っているのかは疑問である(もししているならTwitterなりに書いているだろう。技術的アピールができるし)。Floorpブラウザの作者はWindowsのタスクマネージャーに出てくる見せかけの数値だけを見て「えっ、Floorp軽っ、、、、、」とか言ってるのだから、実に恥ずかしい。いつ気がつくか見物である。
500ms単位でメモリ節約機能が動作するせいで、Speedometer 2.0のベンチマーク結果がさえない。未使用時と比べて7%ぐらいスコアが落ちてる。Edgeよりもスコアが良くない。メモリ使用量のことばかり気を取られて、速度のことには関心がないのかもしれない。
Chrome Web Store外から拡張機能(Deepl翻訳と同期機能)をインストールさせるためにレジストリを使用した結果、他のChromium派生ブラウザ(SRWare Ironで確認済)でも拡張機能がインストールされたという通知が表示されるようになってしまう。
Cドライブ直下にフォルダー作ってそこに入れるとか、いつの時代のソフトだよ。Program Filesに入れてやれよ。
https://ja.wikipedia.org/wiki/Wikipedia:%E5%89%8A%E9%99%A4%E4%BE%9D%E9%A0%BC/Floorp
https://twitter.com/surapunoyousei/status/1431961462734352385
作者から依頼されて書かれた記事に客観的な証明なんてどうやってするんだろうね。
まあKinzaのパッチが出てからが本番っぽいし、それまではこれぐらいにしておこうか。
Uniant Browser → Floorp Browser? UniantとAblazeの関係がよくわからん。個人で開発してるのか寄り集まって開発してるのかもよくわからん。
中の人のTwitterで中学生と書かれていたことがあったので、高校生ではないかもしれない。高校生の表記から「学生(中学生？高校生？)」に変更した。
プログラマーに憧れる皆さん！こんばんは。
「自分は文系だから」「未経験だから」と諦めていませんか？大丈夫です！プログラミングにセンスは不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます。
今日は、未経験から最短でWeb系企業に就職するための勉強法をご紹介します！
もっともオススメの方法は、顕正会のセミナーに参加することです。
顕正会は、日本で最大のエンジニアのコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアのノウハウを学ぶことができます。
また、意外と知られていませんが、日本のエンジニアの8割は顕正会の出身です。実はあのひろゆきやビル・ゲイツも顕正会の出身です。ですので、顕正会のネットワークを介して就職先を斡旋してくれたりしますし、自分が顕正会員だと、面接時にも非常に有利になります。
顕正会のセミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい！無料体験もできますよ。
プログラミングの勉強を始める前に、まず、必要なものを準備しましょう。必ず必要なものと、できればあると良いものは以下の通りです。
可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッド。RAMは128GBくらいはあると良いでしょう。ストレージはSSDであれば1TBもあれば十分です。
OSは、Windowsで開発するならWindowsが、Macで開発するならMacが必要です。よく分からなければMacを買っておく方が良いでしょう。基本的にMacにできてWindowsにできないことはありません。
インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。
顕正会に入会すれば、上記のスペックのPCを無料で貸し出ししてくれます。また、法人向けの専用線を無料で取付工事を行ってくれる上に、通信費を全て負担してくれます。
まず、他の会員と連絡を取るために、SNSのアカウントを持っていると良いでしょう。
最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的にものを覚えることができます。
Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITのプロを目指そうという人間が、このような最先端のデバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります。現金も持つのはやめましょう。
せっかくセミナーに参加しても、受身で聴くだけでは、プログラミングを習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。
まずは、教科書や参考書を写経することから始めましょう。教科書や参考書の本文を一字一句正確に書き写すのです。
よく、「写経は理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球や水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈は自然と身に付きます。
また、写経のメリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばしてしまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。
教科書のサンプルコードをノートに書き写したら、それを今度は自力でフローチャート（UML）に変換してみましょう。そうすることで、自分が本当にそのコードを理解しているのか、確かめることができます。
フローチャートやUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要なスキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業や顧客にとっては貴重な資料となるからです。プロのエンジニアは、COBOLのソースコード10万行を1週間でフローチャートにして、Excelに転載することができます。
ここで一つ注意すべきことがあります。フローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたものは業務ではフローチャートとは認められません。これはまともな企業に就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。
エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelはエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業をExcelで行います。セル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。
プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。
尤も、以上の資料は、ツールを使うことで自動で作成することもできます。たとえば、ソースコードの更新履歴はGitなどのバージョン管理システムを使うことでも管理できます。しかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう！VBAの習得も必須です。
以上、プログラミングの勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。
理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。
また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。
変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。
多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。
不要な関数を作らないためのテクニックには、以下のようなものがあります。
まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。
function f(i) {
switch(i) {
case 1:
// i = 1のときの処理
break;
case 2:
// i = 2のときの処理
break;
case 3:
// i = 3のときの処理
break;
// ...
}
}
この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。
クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。
理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、プログラマからはこの上なく尊ばれています。
class God { f1() { // 関数1 } f2() { // 関数2 } // ... } class C1 extends God { // 何も書かなくても上の関数が使える！ } class C2 extends God { // 何も書かなくても上の関数が使える！ } // ...
変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。
たとえば、以下のコードのaは、関数定義の外側からは参照することができません。
function f() {
var a = 1;
return a;
}
一方、以下のコードのaは関数の内外どちらからでも参照することができます。
var a = 1;
function f() {
a = 2;
return a;
}
せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。
また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。
例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。
例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。
ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。
try { // 例外が発生し得る処理 // ex. ファイルを開く } catch (e) { // 例外が発生したときに、実行する処理 }
例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。
try { // 例外が発生し得る処理 } catch () {}
全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。
部分的にでも理解すればプログラミングを見る目が変わるはずです。
驚いたわ。
新卒で就職してから、（敢えて分類するなら）Web系ベンチャー的な会社にずっと居たんだが、某大手SIerと提携してプロジェクト進めることになったんだわ。名前は出せないけど、みんな知ってるあの会社だよ。
こういう会社の評判はネット上でよく耳にするけど、それは誇張されたものだと思ってた。実際、そういう会社は社会的に成功してるんだし、社員も高学歴の人がほとんどなんだから、使っている技術が多少古臭くても、仕事のレベルは高いんだと思ってた。だが、そんなことは全然無かった。
うちの技術者が10分でできるようなことが、何回も会議をしたり、書類を埋めたり、向こうの上司の承認を得たりで、3ヶ月くらいかかる。そんだけ会議した後、やったのは、テンプレートからAWSのEC2インスタンスを起動していくつか必要な初期設定をしただけ。
言い忘れてたが、プロジェクトの内容はうちの製品を向こうの会社名義で売るということ（いわゆるOEMというのか？よく知らん）。
で、開発者向けのAPI等のドキュメントが既にWeb上に公開されてたんだが、なんか上司がはんこ押す書類と一緒にしなきゃいけないという理由で、これをエクセルに転記させられた。向こうの指定した方眼紙フォーマットにな。CSVなどに出力して一括でコピペすることさえできないストレスは想像を絶するものだった。エクセルにスクリーンショット貼り付ける作業で精神病むのも納得。
他にも意味の分からん制限が多かった。セキュリティポリシー的に、Google Drive等の外部サービスで情報を共有するのはNGだというんだが、上司がCCに入ったメールで送ったあとならOKらしい。んで、そういうメールを受信したらSlackに転載したりする馬鹿みたいなスクリプトをたくさん書いた。書き始めたらすぐに向こうの意味不明な運用に合わせたシュールでカオスなプログラムになった。もちろん、これも実際動かすには承認に何ヶ月もかかる。
こいつらの仕事の出来なさは、もうプログラミングができないとかそういう次元を超越してる。
当初のイメージでは、「使ってる技術が最先端ではないだけで、仕事の段取りとかはちゃんとしているのだろう」とか思ってたが、そんなことは全くなかった。
技術とか以前の問題。意味のあることと無いことの区別がついていない。「そういう段取りになっている」という理由でただ言われたことを作業的にやるだけ（まあ、一定レベルの知的労働を流れ作業に帰着させるのはある意味すごいとも言えるが）。
俺の関わった連中が例外的にひどかったと思いたいが、まあ、現実問題そういうことはないのだろう。
俺の大学の同級生も、NとかFとかNとかHとかの付くSIerに就職していったが（上記の会社はその1つである）、こういう仕事をしているなら完全に人材の無駄遣いだと思う。コンビニパートのおばちゃんとかで変わり利くもん。
これからエンジニアとしてキャリアを築きたい学生とかは、絶対にこんな会社に入っちゃいけない。まともなスキルは全く身に付かないぞ。
兼業ウーバー配達員だが、いろいろ最近思ったことをダラダラ書く。
一応、登録して2年くらいになるかな。
23区内で稼働。
使ってるのは電動自転車。
レンタルではなく、もともと乗っていたのでプライベートでも割と使ってる。
空いてる日は昼飯時と、晩飯時に6時間くらい走って、1万円台で稼ぐこともある。
一応、満足度98%(直近100件でグッドかバッドの評価をした飲食店とお客さんの評価で算出される)なので、ちゃんとやってるドライバーと評価されてるのだろうと思う。
さて、ウーバーの報酬だが、改定以前は、料理を受け取っていくら、相手が無事受け取っていくら、距離の従量料金がいくら、と割合明確だったのが、改定されて基準が不明確になったのは事実である。
ただ、今回の改定にも良い点があって、以前は“飲食店から客のところまで”の距離しか報酬に反映されず、たとえばマック地蔵してそこから2キロ配達したよりも、2キロ走ってマックに到着して1キロ配達したときの報酬が少なかった。
これでは地蔵が増殖するのも当然で、今回の改定に、世間に評判がはなはだ悪かった“地蔵対策”が含まれているのは明確だろう。
あと、スマホにリクエストが来るとき、飲食店と配達先の場所と概ねの移動距離と報酬概算が提示されるようになった。
うまく稼ぐには、これを瞬時に判断してリクエストを受けるかどうか判断する能力がモノを言うようになったと思う。
体感だが、事前概算で提示される距離はおおむねそんなにズレてはいないように思う。
ただ、どうやら自動車のルート基準で距離を判断してるらしく、“あ、これ自転車で公園抜けちゃえば近いじゃん”というときは、得することもある。
まあ、時々、これ安すぎじゃね？というリクエストが出ることもある。暇なときは受ける
たまたま今日、そういうリクエストがでて、まあ反射的に受けてしまったのだが、実際配達し終えてみると、最初の概算より実際の報酬は100円くらい高くなっていて、バグがあったり、あまりに変な数字を提示してしまったときに補正したりは一応やってるようではある。
(普段は、リクエスト段階と実際の報酬は1円くらいしかズレない。自分はまだ、概算より実際の報酬が大幅にさがったことはない。実際あるのかどうかもよく知らない)
あと、報酬改定後、やたら店で待たされたことがあったが、そのときは事前の概算より報酬がたかくなっていて、一応そのへんも補正はしているようではある。
(ウーバーの説明によれば、今回の改定では事前の概算より配達に時間がかかったりする場合は報酬に反映されることになっている)
あと、時間帯その他による需要のあるなしは、報酬計算に反映されているようには感じる。
自分は、23区内とはいえかなり外れのほうに住んでいて、家の近所でやるときと、山手線付近の都心に出るときがあるのだが、稼ぎは全然違う。
都心だと“ピーク料金”が加算されることが多いのだが、それ以前の、ベースの報酬もやはり高額に算出されているように感じる。いや、精密に検証してないので、“感じる”だけかもしれないが。
ピーク料金が適用される地域はアプリ上に色がつく(界隈では染みとよぶらしい)ので、みんなそこを狙って移動するわけだが。
まあ体感としては、頭のいい人たちがAIつかって、より合理的な計算方法を模索してるのかな？とも思うし、配達員目線では“効率的に稼ぐメソッド”か変化したかなとも思う。うまくやってる人はそんなに稼ぎへってないだろうな、とも。
とはいえ、“なにを根拠に報酬計算してるのか判りにくい”のは、やはり不信感があって、現状では配達しているのが人間である以上、人間に理解できる計算ロジックを提示しないと、いろいろギクシャクするだろう。
これが、自動運転の車やドローンが配達するようになれば、そんな必要もなかろうが。
先日、明らかに計算がおかしいのでは？という事例があって、サポートにネットで連絡した。
これは、ヘルプページから連絡フォームを呼び出して、配達と報酬の記録のスクリーンショットを添付して…と、なかなか面倒いのだが。
起こったのはこういうことだ。
最初にリクエストを受けたあと、お客さんから、“〇〇まで配達してもらえますか？”とメッセージがきたのだ。
これは、対応してグーグルマップ検索すれば配達可能だし、予定より遠いところまで配達すると通常は報酬に反映される。なにしろGPSで移動を管理してるのだから、そんなの簡単にできるはずなのである。
ところが、このときは最初に提示された概算報酬より実際の報酬額が少なかったのである。
移動距離が見積もりより明らかに長くなったのに、安くなるのは納得いかん！と連絡したところ、結果、1円だけ追加で払ってきて“なお計算の詳細については開示できないのでご容赦を”と言ってきた。
なんだかね。
(実は、このお客さんは配達先を変更したのを申し訳なく思ったのか、チップくれたのでもとは取ってるのだが、それはまた別の話)。
あと、これは報酬計算とは別なのだか、先日こんなことがあった。
店で商品受け取って動き出した直後、アプリに配達先の情報が表示されなくなってしまったのである。
あれ？なんか余計な操作しちまったか？と慌ててサポートに電話したら、“時々起こるバクで、同時に複数の配達員のところにリクエストが飛んでしまい、別の配達員が取りに行ってる”というのである。
なんだよそりゃ。
サポートの兄ちゃんは、“商品を店に戻してくれ”という。おいおい。
思わず“タダ働きですか！”といったら、“あとから移動分はお支払いを…”といっていたが、これ、すぐにサポート繋がったからいいようなものの、繋がらなきゃ(実際、繋がりにくいことも多いらしい)配達員は途方にくれるし、客はなかなか商品届かなくて途方に暮れそうだが。
いや、そのときは何が起こったのかよくわかってなかったのだが、配達しようとしたら配達先が消えてしまい、このときはサポートに10分くらい電話つながらず、しかも夜で取りにいた店はもう店じまいな感じで、途方にくれた自分は預かったタピオカミルクティは飲んでしまった。
その後、運営含めだれからも何も言ってくることもなく。また客にカネ返してむりやり解決したんかなあ？
全体としてウーバーは何もかも走りながら考えて、トラブルあったら金払って解決してる極めてアメリカ的な会社なんだろうなあと思う。
それがいいか悪いのかは別として、そういうノリが、今の世の中では強いのだろうな。
ついでにあと一つ。
ウーバーを始めとしたデリバリー専門の店は、どんどん進化しているようである。いくつもの屋号を持ち、液晶画面に何件ものウーバーや出前館の配送員むけの割当番号が“調理中”と“配送準備完了”にわけて表示され、若い兄ちゃんパソコン見ながら調理場と配達員を仕切ってるような店が都内にはいくつも存在する。
一方で、“あれ、こんなところに「チキン南蛮専門店」なんてあったっけ？”と思って配達員向けの注意事項よんだら、実店舗は某カラオケボックス大手だったり。
あと、この店いくつもあるなあと思ったら、全部実店舗は違う名前で、経営苦しい飲食店向けにサブブランドを提供するビジネスもあるらしい。
まあ、コロナが収まって食品デリバリーがどうなるのか分からんけど、“持ってきてくれる便利さになれた消費者”と、“立派な店構えなくて飲食をビジネスにできるんだよ環境でうまいこと稼ぐ経営者”は、そんなにいなくならないように思っている。
【追記】補足書きました。anond:20210712212330
遅い。
これにすごく悩んでいる。
一度聞いただけでは何を言っているのかわからなかったり、資料を読み解けなかったりする。(ただ目が文字の上を滑る感じ)
仕事においてはこれが本当に最悪で、その場で理解したくても、頭が回らずにあとで改めて追いかけることになる。
ロジック、というものが苦手で、筋道立てて喋れる人はどれほど頭の中が整理されているのだろうと思ってしまう。
本を読むのも時間がかかる。
自分の書いたメモは捨てられない。この先活用することがないと思っても、一度自分のフィルターを通したものは、いつか自分の理解の助けや、気づきになるという経験もあり捨てられない。
スクリーンショットは星の数ほどある。
何かを作る過程の、形跡が捨てられない。資料の草稿や、イラレで作ったアートボードの外の何か。
一言一句取りこぼさず何かをインプットしようとしているのがしんどい。
最近よくあるのは、常に脳内で喋っている。口語で。この現象は何？
知識欲や好奇心は強い方で、寝食を忘れるほどの集中力と忍耐力はあるように思うが、
インプットしようとしているものの見極め、またその量と脳の処理速度が見合っておらず、結果として寝食してないだけのような気もする。
メモしておかないと不安なのもあるが、自分の頭を信用していないのだと思う。
その場で理解できないのを分かっているから、のちの自分のためにといいつつ、その瞬間で理解すること、記憶しようとすることを放棄しているのか？と考えたりもするが、頭が混乱するばかり。
変なギャグとか、場を和ますための一手、みたいなのは自分でもよく思いつくなと思うくらい瞬発力とかあるのに。
この人今この話してるけど、そういえばそれで思い出したけどこのネタがーみたいなのは尽きない。
でも、文章や人の話(堅い系)は脳が空回りする。
同じミスを何回もするタイプではなく慎重にこなすタイプ。変な瞬発力があるくせに、処理速度がやばい。
学生の時も、人一倍時間をかけて努力をしないとついていけない感じだった。
はるか昔、こんなに脳の処理速度が遅いのに国立の大学に受かった。(全然すごいとは思っていない。かけれる時間があったということ。)
どうせ死ぬのに、やめられない。