信じる力 小学生の時、『金色のガッシュベル!! 友情の電撃 ドリームタッグトーナメント』というゲームにハマっていた。 このゲームにはガッシュコレクションという収集要素があり、特定のミッションをクリアしていくたびにコレクションが解放されていくというシステムになっていた。 コレクションは全部で100個あり、そのうち99個までは簡単に解放できたが、1つだけどうしても解放できないコレクションがあった。 その最後に残ったコレクションの解放条件とは、とあるミニゲームでひたすら連打して50000点を超えろというものだった。 この条件が非常に難しく、ただ連打するだけなのにも関わらず、何度挑戦しても50000点を超えることができなかった。 「もうちょっとで50000点超えれそうだったのに〜」という感じにすらならなかった。全然余裕で50000点に届かないのだ。 工夫を凝らして攻略しようと思っても、なにせ連打するだけなので工夫のしようがない。 爪を立ててゲームボーイアドバンスのABボタンを擦るように連打しては親指の皮膚を無駄に消耗するだけだった。 あまりにもクリアできないので、なにか裏技みたいなものがないとクリアできないんじゃないかと途中から疑心暗鬼になり始めた。 結局、コレクションを全部集めることはできず、しばらくの間そのゲームは投げていた。 ある日、友人が家に遊びに来たので「どうしてもこのミニゲームがクリアできないんだよね」となんとはなしに話しかけてみた。 すると友人は「いや、俺これ行けると思うけどな」と返してきた。 内心、絶対ムリムリと思っていたのが、とりあえず友人に挑戦させてみることにした。 すると、友人はあっさりとそのミニゲームをクリアしてしまった。 友人が一体どうやってこのミニゲームをクリアしたのかというと、なんてことはない、ただただ本気で連打しただけだった。 自分と同じように爪を立てて擦るようにABボタンを連打しているだけだった。 友人が正攻法であっさりとクリアする様子を見て、自分でももう一度そのミニゲームに挑戦してみた。 すると不思議なことに、あれだけ苦しんだミッションをあっさりとクリアできてしまった。 今思い返すと、当時の自分は「裏技があるんじゃないか？」「擦って連打する以外のもっと良いやり方があるんじゃないか？」のような疑念がある状態でミニゲームをプレイしていて、無意識に連打に集中できていなかったのだと思う。 このときは運良く連打に自信のある友人が目の前でクリアしてくれたおかげで、そのような疑念を打ち消すことができた。 「ただ純粋に連打すれば良い」という指針を自分の中に立てることができた。 でもこのときはたまたま運が良かっただけで、あらゆる事象において誰かが先人として道を切り開いてくれるとは限らないだろう。 自分達が選んだ方針が正解なのかどうか分からない中でも、「きっとこの方針は正しい」と盲信して全力で取り組むことで開ける突破口というのもこの世には存在しているんだろうな。 まとめ コレクションの「かいほう」って「解放」と「開放」どっちが正しいの？

フロントエンド技術の流行り廃りが激しい理由ってフロントエンドのほうがバックエンドよりも難しいからだよな。 バックエンドってイベント(リクエスト)とその結果(レスポンス)は一箇所に決まっているから、素直なコードになりやすい。 でもフロントエンドってユーザーの操作という複数種類かつ複数回のアクションがあって、それを正確に矛盾なく画面に反映させないといけない。 根本的にフロントエンドの方が処理がややこしいから、なんとか現状の問題を解決するために新しい技術が次々と生まれては消えていくんだろうな。 SPAを捨てたら複雑さはかなり減ると思うけど、それだとユーザー体験が犠牲になる…。難しい問題ですな…。 学生の時にIT企業でインターンを始めたときは、自分の書いたコードが分かりやすく即座に画面に反映されるフロントエンドの方が開発していて楽しいと思っていたけど、最近は考えること多くてダルいなーって気持ちのほうが強くなりつつある。 どこかの天才がフロントエンドの枯れた技術を作ってくれるまで、ほどほどに流行を追いかける感じでやっていこう。

概要 仕事で金融系のシステムに関わることになったが金融系の知識などまったくない。でも教科書的な書籍を読んで1から体系的に金融のことを勉強するのはダルい。 そんなおりに本書を発見した。 「これ読んだらシステム開発について理解を深めながら自然と金融の知識も学ぶことが出来て一石二鳥じゃん！」と思い即購入。 #PR ポストモーテム みずほ銀行システム障害 事後検証報告 楽天 感想 正直、途中で飽きた。 基本的には実際にあった出来事を淡々と追っていくスタイルの書籍なので、物語性は薄めで読み物としては面白さに欠ける。まあ、ノンフィクションって普通そういうもんなんだろうけど。 なんとなくシステム障害の裏には人間ドラマのようなものがあるんじゃないかと思いこんでいたが、実際には事前の準備の不足やビジネス層と技術層のコミュニケーション不足といった至って普通の問題が積み重なって起きた障害だった。 しかし、世の中で生じるシステム障害というのは大抵こんなもんなのかもしれない。明日は我が身ですな。 個人的には巻末にあるCIOのインタビュー記事が一番血肉の通った内容で面白かった。 あと「見逃し三振はOKだが、空振り三振はNG」（アラートをあげなくて良い場面でアラートをあげるのはOKだが、アラートをあげるべき場面でアラートをあげないのはNGの意）という標語は分かりやすくて良いなと思った。似たようなことは現場でもよく言われるが、こういう分かりやすい標語で言語化されると実践しやすい。 ちなみに本書は金融の知識とITの知識の両方がないと割と理解が難しいので専門外の方は安易に手を出さないことをおすすめする。

概要 まず始めに言っておくが、リモートワークが悪だとは全く思っていない。 子育てや介護といったどうしても出社できない事情がある人にとって、リモートワークは働き方の多様性を広げる素晴らしい制度だと思うし、仮にそういう特殊な理由がなく「満員電車に乗りたくないのでリモートワークをしたい」等の主張も全然ありだと個人的には思っている。 ただ、リモートワークの利便性を享受するならリモートワークによって生じる弊害には全力で対処すべきだと思うし、極論リモートワークによってパフォーマンスが下がったのなら評価にバツがつくことは甘んじて受け入れるべきだと思っている。大いなる力には大いなる責任が伴うというやつだ。 昨今のSNSを見ているとリモートワークの自由さだけを享受して、その自由さの裏にある責任からは逃れようとするポジショントークがあまりに多いと感じる。 こういったポジショントークを目にすると、「ああ、この人はただサボりたいだけなんだな」と正直思ってしまう。 今回はそういった類の発言を2つ紹介したい。 発言1. リモートワークでサボるやつは出社でもサボる 要するにリモートワークでサボるような人間はどうせ出社してもサボっているんだから、リモートワークを推進したところでサボりは増えないという主張だ。 これは本当におかしい主張だと思う。 出社で30%サボる人がリモートワークでは70%サボるなんてこと全然あり得る話で、それはリモートワークによってサボりが増えたと同義だろう。 サボる・サボらないというのは0か100かみたいな話ではなくグラデーションの話なのだ。 アン・ミカも「サボりって200種類あんねん」と言っていた。 すこし考えたら誰でもおかしいと分かる詭弁だと思うのだが、SNSではこういう類の発言をよく見るしかなり支持もされている。 発言2. 出社すると話しかけられて効率が悪い 要するに出社すると人から質問とか相談をされて業務が中断されるから、リモートワークの方が効率が良いという主張だ。 これはマクロな目線で見たら事実だと思う。仕事が中断されないほうが効率が良いに決まっている。 ただ、それによって話しかけた側は仕事を進めるためのしかるべき情報を得られる訳で、全体で見たときには効率が上がっているということがほとんどなんじゃないだろうか。 知りたい情報を得られずにタスクが完全に止まってしまう人間が存在している方がよっぽど効率が悪いだろう。 この発言はあまりにも視点が自分本位すぎるし、部分最適に執着しすぎていると感じる。 仮に雑談が多くて仕事が中断されるとかなら、問題の本質は出社ではなくその会社の文化にあるだろう。 まとめ 普通こういうのって無理やりひねり出してでも3選にするよな。

概要 パスキーのことを知りたいと思って購入。 #PR パスキーのすべて ── 導入・UX設計・実装 楽天 感想 良い点 まず、内容がわかりやすい。 難しい説明を極力使わずに内容をかみ砕いて説明してくれている。 ユースケースや実装例も豊富で、巷で見かけるパスキーのユースケースは一通り網羅されていると思う。 ユーザーがパスキーを紛失したときの対処法など、実務で考慮すべきポイントもしっかりと押さえられている。 第8章ではやや専門的な内容も扱っており、パスキーを深堀りしたい読者にも満足できる内容になっている。 全体的に丁寧で自分のような初心者にはおすすめの一冊だと思う。 微妙な点1. 内容が不足している部分がある 自分は実務でパスキーを実装するにあたって本書を購入したのだが、実務ではしばしば本書に書かれていない知識を必要とする場面があった。 例えばapple-app-site-associationやassetlinks.jsonについては本書では触れられていないが、実務でモバイルアプリにパスキーを組み込もうと思ったらほぼ100%知っておかなければならない。 他にもブラウザでパスキーの動作確認をする方法なども本書では解説されていない。 ローカルでパスキーの動作確認をするときにはRP IDをlocalhostにしないといけないとか、デベロッパーツールから仮想認証機を有効化しないといけないとか、意外と罠が多い。 初心者は絶対引っかかるので(自分は引っかかった)、そういう部分の解説がもう少し豊富だったら良かったかなと思う。 微妙な点2. 索引が弱い 例えばclientDataJSONについて索引を引こうとして「C」のページを引いても、なぜか引っかからなかった。 結論から言うと以下のような索引になっていた。 【A】 AuthenticatorAttestationResponse … 129 attestationObject … 130 clientDataJSON … 130 clientDataJSONを引くために、AuthenticatorAttestationResponseを引く人なんているんだろうか？ 単純な疑問なのだが、以下のような索引では駄目なんだろうか？行数は変わらない訳だし。 【A】 AuthenticatorAttestationResponse … 129 attestationObject … 130 【C】 clientDataJSON … 130 前者のほうが構造化されていて美しいという感覚は分かるが、別に索引が構造化されている必要は無い気がする。 出版に関する知識が皆無なので、もしかしたらこれは素人の意見なのかもしれない。 でも実際に業務で索引を引こうとして困ったのである。仮に出版業界ではこれが正しいのだとしても、自分は間違っていると思う。 総評 丁寧な内容で分かりやすい。 本書を読んで「全然意味がわからん」みたいになる人はほぼいないと思う。 一方で一部内容が不足している部分もありそうなので、適宜ネットで情報を補完しながら読むのがおすすめかなと思う。

概要 SNSを見ているとエンジニアの世界ではUSキーボードが異様に称賛されているように感じる。 自分自身は大学3年生まではJISキーボードを使っていて、研究室&1社目&2社目では支給されたUSキーボードを使っている。 どちらのキーボードも使った結果、JISキーボードの方が使いやすいと感じている。 この記事ではその理由を述べていく。 よく語られるUSキーボードの長所に対する疑問 まずは世間でよく語られるUSキーボードの長所に対する疑問を述べていく。 1. ショートカットキーが使いやすい 感じたことがない。 むしろ、後述する「かな・英数変換」のショートカットキーはとても使いにくいと感じる。 2. ホームポジションが崩れにくい 感じたことがない。 むしろ、後述する「かな・英数変換」で毎回ホームポジションが崩れる。 3. 表記がシンプルで見やすい キーボードの表記を気にしたことがない。 ただ、初学者にとっては確かに見やすいのかもしれない。 4. キーの配置が論理的で使いやすい キーの配置が論理的というのはその通りだと思う。 例えばJISキーボードでは「」は横並びで{}は縦並びだったりするが、USキーボードではどちらも横並びになっている。 ただ、キーの配置が論理的であることがメリットだとは個人的には思わない。 なぜなら我々は論理的に思考しながらキーを入力しているわけではなく、手癖でキーを入力しているからだ。 キー入力しているときに「{}は横並びだなー」なんて考えているやつはいないだろう。 もし論理的に考えながらキー入力をしているなら、研究室に入って初めてUSキーボードを使ったときにミスタイプしまくった思い出と整合性がつかない。 確かに初学者なら論理的な配置の方が覚えやすいというのはあるのかもしれないが、慣れてしまえばどちらでも同じだと思う。 USキーボードの悪いところ 1. かな入力と英数入力の切り替えが不便 正直この欠点で全ての長所は吹き飛ぶのではないかと思う。 例えばWindowsのUSキーボードだとCtrl + `というショートカットでかな入力モードと英数入力モードの切替ができるのだが、2つのキーの配置が遠すぎてめちゃくちゃ指がスカってしまう。 世間でよく語られている「ショートカットキーが使いやすい」や「ホームポジションが崩れにくい」といったUSキーボードの長所が仮に事実だったとしても、このCtrl + `という使用頻度S級にも関わらず超絶押しにくいショートカットが全てを破壊してしまう。 ちなみに、Macの^ + SpaceはCtrl + `よりはかなり押しやすいが、それでもたまにスカってしまう。 もう一つ大変なのは、Ctrl + `に冪等性がないということだ。 JISキーボードでかな入力をしたいときには、現在がどちらのモードであるかに関わらずかなキーを押しておけば良いのだが、USキーボードだと既にかな入力モードのときにCtrl + `を押してしまうと英数入力モードに切り替わってしまう。 したがってUSキーボードを使う場合は、現在のモードを常に記憶しておくか、モードの切替をする前にタスクバーを確認するという癖をつける必要がある。 これらはJISキーボードを使用しているときには意識する必要がないことだ。 USキーボードのこれらの欠点に対して、「レジストリをイジったり、『⌘英かな』のようなツールを使ってキー配置を新たに割り当てればいいじゃないか」という反論があるかもしれない。 ただ、セキュリティの要件の厳しいプロジェクトだと、レジストリをイジったり承認の無いツールを導入することができなかったりすることも多い。 そもそも、キー配置を割り当て直すことを良しとするなら、JISキーボードをUSキーボードのキー配列に変更することもOKになってしまうわけで、反論として成立しているかは微妙なところだ。 まとめ ぶっちゃけ、カッコつけでUSキーボードが良いと言っているエンジニアも多いんじゃないだろうか？ 少しでも日本語を入力する機会がある人にとってはJISキーボードの方が楽なんじゃないだろうか？

概要 PyPIにパッケージをパブリッシュしようとしたら、以下のようなエラーが出てパブリッシュできなかった。 <html> <head> <title>400 Invalid distribution file. File exceeds compression ratio of 50</title> </head> <body> <h1>400 Invalid distribution file. File exceeds compression ratio of 50</h1> The server could not comply with the request since it is either malformed or otherwise incorrect.<br/><br/> Invalid distribution file. File exceeds compression ratio of 50 </body> </html> 間接的原因. なぜエラーが発生したのか？ 解凍したときにファイルサイズが50倍以上に膨れ上がるzipファイルをアップロードしたことが原因だった。 ちなみに、解凍したらサイズが膨れ上がるようなファイルを利用してシステムをクラッシュさせるような攻撃をZip Bombと呼ぶらしい。全然知らなかった。 高圧縮ファイル爆弾 46MBが4.5PBへと膨れ上がるZIP爆弾がネット上で公開中 Zip Bombを防ぐために、PyPIでは2023年の6月頃から圧縮率50倍を超えるファイルを含むパッケージのパブリッシュを拒否するようになっているようだ。 最初は圧縮率10倍以上で弾いていたが、制限が厳しすぎるということで50倍以上に緩和されたらしい。 PyPI is now requiring wheels to be too much compressed ...

概要 Pythonでkago-utilsという麻雀ゲームを作っている。 こいつの処理がもっさりしていたので、向聴数計算の処理をCで書き換えることによって速度を改善した。 背景 kago-utilsのゲームルーチンにバグがないかを検証するために、天鳳の牌譜を約60万半荘分流し込むという作業をしていた。 しかし、1半荘を終えるのに1秒程度かかっていたので、検証作業に非常に時間がかかっていた。 そこでyappiというツールを使って牌譜10半荘分のデータを流した時の各関数の実行時間を計測したところ、以下のようになった。 HaihuParser.runが一番外側の呼び出し関数で、これが350秒かかっている。 どうやらyappiの差し込みの処理が重いらしく、実際は10秒程度で終わっている処理に350秒程度かかってしまっているようだが、各関数の処理時間の比率自体はそこまで変わらないと想定して、どの関数がボトルネックになっているかを考えることにした。 この画像を見て分かる通り、向聴数の計算を行うcalculate_shantenに338秒かかっていて、これは全体の処理時間の96%程度を占めていることが分かる。 そこで、向聴数計算の処理だけをC拡張で実装して速度改善を図ることにした。 全部の実装をCで書き換えることができればベストなんだろうが、自分はCが書けないし、既にほぼ全てのコードを書き終えてしまっているので、今回は向聴数計算の部分だけをCで実装することで手打ちにした。 方法 正直、方法については調べればいくらでも情報は出るので、コードと細かいTipsだけを共有する。 _shanten.c Tips1. C vs C拡張 Cで実装するのにも2通りの方法がある。Cを直接呼び出す方法と、C拡張モジュールを使う方法だ。 Cを直接呼び出す方法は、ビルドしたCのコードをPythonから直接呼び出す方法だ。 そのため、PythonとCの間でデータをやり取りするためのコードを書く必要がある。 長所としては、PythonのコードとCのコードが疎結合になりやすいこと、特別な設定を必要としないことなどが挙げられる。 短所としては、PythonのデータをCのデータに変換する過程でオーバーヘッドが発生することなどが挙げられる。 C拡張モジュールを使う方法は、PythonのC APIを使ってCのコードをPythonのモジュールとしてビルドする方法だ。 長所としては、PythonのデータをほぼそのままCに渡せるので速度が早いことなどが挙げられる。 短所としては、CのコードとPythonのコードと密結合になること、Pythonから直接データを受け取るための専用の関数を覚える必要があること、Cのコードをビルドするためにsetup.pyの設定が必要になることなどが挙げられる。 今回はあまりメンテする必要がないこと、速度改善が最重要の目的であることなどからC拡張モジュールを使う方法を選択した。 Tips2. Python.hの場所 C拡張モジュールを使う場合、Python.hというヘッダーファイルをインクルードする必要がある。 ただビルドするだけならPythonが勝手にPython.hの場所を探してよしなにやってくれるのだが、もしエディタで補完の恩恵を受けたいならPython.hの場所をエディタに教えてあげる必要がある。 C拡張モジュールは専用の関数が多いので、補完が効かないと非常に不便だ。 Python.hのパスはターミナルでpython3 -c "from sysconfig import get_paths; print(get_paths()['include'])"のように実行すると取得できる。 VSCodeなら設定画面でC_Cpp.default.includePathに上記のパスを追加してやれば補完が効くようになる。ただしC/C++という拡張機能を入れておく必要がある。 Tips3. setup.pyの追加 拡張モジュールを使う場合、setup.pyというファイルを追加して、Cのコードをビルドするための設定を記述する必要がある。 自分の場合はsetup.pyのように現状ではシンプルな内容になっているが、色々なリポジトリを見て回った感じ、いくらでも複雑な構成にできそうだった。 怖いのであまり奥深くには立ち入らないことにする。 Tips4. .pyiを追加する .pyiを作成することでPythonのコードからC拡張モジュールのコードを呼び出すための型ヒントを追加することができる。 これを行うことでエディタのインテリセンスが効くようになので、やっておいて損はないだろう。 _shanten.pyi - GitHub Tips5. 【告白】 CのコードはほぼChatGPTに書かせた!!!! 自分はCが書けないので既存のPythonのコードをChatGPTに投げて、「C拡張に変換して」とお願いしたらほぼ完成形のCのコードを書いてくれた。 一部だけ修正して終了。 いい時代になった…。 結果 再度10半荘分の牌譜を流し込んで関数の処理時間を計測したところ以下のようになった。 向聴数計算が処理時間上位にランクインすることはなくなり、全体の処理時間も約13秒程度にまで短縮された。 またpytest-benchmarkの結果をGitHub ActionsでGitHub Pagesに自動デプロイの記事で解説したベンチマーク計測処理を向聴数の計算にも適用していたのだが、その結果は以下のようになった。 ...

概要 自分はさくらのVPS上でKonbuやNBAMashのようなWebアプリを運用している。 最近、ローカルで操作しているつもりが実はVPS上で操作をしていて、うっかりコンテナを落としてしまうというミスを多発させてしまった。 そこで本番環境にSSHログインをした際にはターミナルの配色を変更して、視覚的に本番環境とローカル環境を差別化することで本番環境での誤操作を防ぐことにした。 方法 .bash_profileに以下のコードを追加した。 # ssh接続時に文字色と背景色を変更する関数 function ssh() { if [[ "$TERM_PROGRAM" == "vscode" ]]; then DEFAULT_COLOR="#CCCCCC" DEFAULT_BG_COLOR="#171717" elif [[ "$TERM_PROGRAM" == "Apple_Terminal" ]]; then DEFAULT_COLOR="#000000" DEFAULT_BG_COLOR="#FFFFFF" fi # SSH接続時に文字色と背景色を変える echo -ne "\033]10;#FFFFFF\007" echo -ne "\033]11;#330000\007" # 実際にsshを実行 command ssh "$@" # 接続終了後に元の文字色と背景色に戻す echo -ne "\033]10;${DEFAULT_COLOR}\007" echo -ne "\033]11;${DEFAULT_BG_COLOR}\007" } コードを順を追って説明する。 まずは以下のようなsshの関数を書くことで、デフォルトのsshコマンドを上書きする。 引数は$@で取得できるので、ssh 引数1 引数2 ...のように実行したら、関数の内部でもちゃんとssh 引数1 引数2 ...のように実行される。 # ssh接続時に文字色と背景色を変更する関数 function ssh() { (...中略...) # 実際にsshを実行 command ssh "$@" (...中略...) } 次にデフォルトの文字色と背景色を変数に格納する。 ...

概要 社会人になって気づいたのだが、会社の中には安全圏からやたらと口出しをしてくる人がいる。 自分自身は特にリスクを背負うこと無く、その場の思いつきのアイデアを他人に投げかけて、他人のリソースを消費させてしまう人がこの社会には少なくない数存在しているのだ。 この記事ではそういった人に対する対処法を紹介する。 口出しを受け入れるかどうかの判定法 まずは口出しを受け入れるかどうかの判定法を紹介する。 口出しする人は基本的に「クライアントのために〜」とか「社会への貢献を〜」のようなきれいでカッコいい言葉を使ってこちらを説得しようとしてくる。 表面上は良いことを言っているので気を抜くと説得されてしまいそうになるのだが、事前に口出しを受け入れるかどうかの基準を設けておくことによって、言葉のきれいさに惑わされることなく冷静に判断を下すことができるようになる。 自分の場合は2つの判断基準を設けている。 1つめは「口出ししてくる人が精神的な負担を背負うのかどうか」だ。 要するに、口出ししてきた人が最終的な責任を負うのかどうかということだ。 口出しによって発生したタスクであなたが失敗した時に、口出ししてきた人が矢面に立って顧客に頭を下げるのならば、その口出しは受け入れても良いと思う。 なぜなら最終的に責任を取ってくれる人の口出しは本気で現状を良くしようとしている可能性が高いからだ。 逆に放任主義で「お前のミスはお前のミス」のようなスタンスをとる上司の口出しは無視しても良いだろう。 2つめは「口出ししてくる人が物理的な負担を背負うのかどうか」だ。 口出しした本人がそれによって多少なりともリソースを消費するのであれば、先程と同様にその口出しの本気度は高くなる。 逆に口出しした本人が一切のリソースを消費しない場合は、カッコつけたくて口出ししているだけの可能性も高い。 そのような口出しは本気度が低い可能性が高いので無視しても良い。 以上が個人的な口出しを受け入れるかどうかの判定法だ。 「精神的負担」も「物理的負担」も背負ってくれない人の口出しは基本的に無視するように基準を設定している。 逆にどちらか一方でも満たす人の口出しであれば、受け入れるかどうかは一考の余地があるのではないだろうか？ 口出しする人への対処法 次に上記の基準を用いて口出しを「受け入れない」と判定した場合に、どうやって対処するかを紹介する。 これも大きく2つの方法があると思う。 1つ目は「適当に返事だけしておいて無視する」という方法だ。 両方の基準を満たさないような人はその場のノリで適当にカッコつけて口出ししていることも多い。 信念のない場当たり的な口出しは本人の中でも上手く落とし込めていないことが多いので、時間の経過とともに自然と忘れてくれる可能性が非常に高い。 口出しする人が普段から適当な人なのであれば、忘れることに賭けて無視するというのは有効な手段だ。 2つ目は「相手を巻き込む」という方法だ。 つまり口出ししてきた相手に精神的負担か物理的負担を強いることで、相手を基準を満たす人間に変化させるということだ。 これは使用方法を間違えると関係が悪化しかねないが、上手く使うと効果は絶大だ。 例えば「あなたがそのタスクに本気で取り組むのなら私も手伝います」というように「あなたがやる」→「私がやる」という物理的負担の矢印を作ることで相手に圧をかけることができる。 この時点で大半の人は口出しを引っ込めてくれる。 もし相手が圧に屈せず「やってやらあ！」となった場合もどうせ長続きはしないので、事前に「あなたがやる」→「私がやる」という構図を作って置くことで、相手がサボり始めたタイミングで自分も堂々とサボってフェードアウトできるようになる。 1つだけ注意点があり、それは「一緒にやる」と言ってはいけないということである。 「一緒にやる」という構図を作ってしまうと、相手は「ちょっと今回だけ忙しいから先にやっておいて」などと言って、徐々にフェードアウトしようとしてくる。 なので「あなた」→「私」という構図はくどいほどに徹底することが重要だ。 ちなみに精神的負担を背負わせるのは難しいと思う。 「精神的負担を背負わせる」ということは大抵の場合は「最終責任を負わせる」ということを意味し、これは「あなた」→「私」という矢印を構築することが難しくなるからだ。 精神的負担を背負わせたつもりが、知らぬ間にフェードアウトされている…というオチになるのが関の山だ。 「あなたが今までの〇〇倍の契約金で案件を取ってくるならやってもよいですよ」ぐらいが精神的責任を負わせる限界だろうか。 したがって、個人的には物理的負担を背負わせるほうが成功率が高いと思う。 口出しする人がきれいでカッコいい言葉を使うタイプの場合に巻き込む手法は特に有効だ。 相手もカッコつけてしまった手前、自分が巻き込まれそうになった場合に「いや、俺は君と違って忙しいんだ…」のようなダサい言い訳で逃げることが難しくなるのだ。 面と向かって言うのは勇気が必要だと思うが、経験上この手法はかなり有効だ。 まとめ 精神的負担も物理的負担も背負っていない人の口出しは必ずしも受け入れる必要はない。 受け入れたくない場合は「分かりました」と言いながら無視するか、相手を巻き込むことで大抵の場合は面倒事を回避できる。 中島みゆきも「その船を漕いでゆけ おまえの手で漕いでゆけ 精神的にも物理的にも負担も背負わぬ者に おまえのオールをまかせるな」と歌っている。 俺達には中島みゆきがついているんだ。 勇気が出るだろう？