【スプラトゥーン2】立ち回りメモ
スプラトゥーン2やってます。
1はちょっとしか触ってないです。初心者です。
先日、スプラトゥーンをやったことがないという友人の家に遊びに行き、
「これがスプラトゥーンや！！おもしろいやろ！！！」
というのを見せつけるため、友人の前でガチマッチをやってみせました。
レベルはB帯です。
友人の反応はというと、
「そこ左潜って！オブジェクトの影に隠れる！はい、敵が通るから後ろから撃って！倒したらすぐ引く！」
「ほらまた正面から撃ち合ってる！その癖直して！」
とめちゃくちゃアドバイスしてきました。
というのも、友人はFPS（というかオーバーウォッチ）ガチ勢だったので、
初めて見たスプラトゥーンにおいてもどういう動きが強いか理解していたのです。
やったことないのに既に俺より上手そうでした。
そんなわけで、友人から受けたアドバイスをメモ代わりにまとめときます。
敵の背後を取る
「敵の進行方向と同じ向きを向いて倒す」
「敵を巻き込むように動いて倒しながら前線を進めていく」
とも言われました。
図にすると次のような感じです。
特にB帯レベルで言えば、敵も味方もエリアやヤグラやホコに向かってガーッとまっすぐ向かって行きがちです。
まさに図の赤い矢印の動きですね。
（自分もそうでした。）
この動きを冷静に読んで、自分は青い矢印の動きをするよう心がけると、おもしろいように刺さります。
例えば海女美ガチエリアで言うと、左の段差下を辿って敵陣スロープ下あたりに潜伏するのが強いみたいです。
敵が中央に向けてやんややんや突撃するのを横から見守った後、後ろから追いかけることで敵の背後が取れます。
このルートは遮蔽物も多いので、危なくなっても上手く遮蔽物を使いながら切り抜けられるっぽいです。
（後述の「オブジェクトの影に隠れる」「退路を確保する」も参照。）
敵の斜から撃つ
敵と正面から撃ち合うと、対等なエイム勝負になります。
それだとなかなか安定したキルには繋がりません。
常にこちらが優位な形のエイム勝負に持ち込むのが、安定したキルを取る立ち回りみたいです。
図のように斜から撃てば、
敵は自分にエイムを合わせるまでにワンテンポ遅れる状態で、
自分だけエイムがほぼほぼ合った状態から撃ち始めることができます。
これが自分優位な形のエイム勝負です。
斜から撃つのは常に意識する、というか、癖にしておかないとダメですね。
私の場合、試し撃ちでバルーンを正面から撃ってるだけでもう友人から叱られました。
なお、これを意識するようになってから、潜伏からの奇襲の成功率が大きく上がりました。
せっかく奇襲しても、正面から襲いかかると意外と迎撃されちゃうんですよね。
オブジェクトの影に隠れる
オブジェクトっていうのは、マップに生えてるモノとか高台とかのことですね。
要は遮蔽物です。
上手い人ほどこれをちゃんと利用して敵の弾を遮り、敵地の中であっても上手く安全を確保してます。
退路を確保する
「自分優位なエイム勝負に持ち込む」と前述しましたが、裏を返せば「不利なエイム勝負は全て避ける」ということになります。
そのためには、危ない場面ではすぐに引けるようにすることが大事。
なので、退路が確保できているかどうかは常に意識し、退路がなければきちんと塗って、あらかじめ退路を作っておくことが大事です。
印象に残ってるアドバイスはこんな感じです。
当たり前のことも多いかもしれませんが、どれも初心者の自分は指摘されるまで気づかなかったことです。
他の初心者の方にも役立てば幸い。
SI会社を退職した
新卒から約4年間、某中小SI会社に勤めてきたが、先月末に退職した。
次はWebサービス業界かゲーム業界に入りたいと思っているが、
その前にまずは無職をしばらく楽しむ予定である。
時間があればじっくり勉強してみたかったことがたくさんあるし、
やりたいゲームもたくさんある。
以下、なぜ辞めたか等をまとめておきたいと思う。
辞めた理由
喩えるなら私は、
「サイゼリヤで働いてみたら料理の楽しさに目覚めてしまい、
本格的なイタリアンレストランで料理人の道を目指したくなった。」
という状態なのではないかと思う。
ここで言う"料理"とは"プログラミング"のことであり、
"サイゼリヤ"はSI業界、"本格的なイタリアンレストラン"はWebサービス業界等のことだ。
別に馬鹿にしているわけではない。
もう少し具体的に説明する。
SI業界とサイゼリヤの共通点
SI業界において、正社員は上流SEになることが求められ、そして管理職になることが求められる。
初めの内はプログラマーもやらされるが、それはあくまで下流の業務を知るため。
キャリアステップの通り道としてのフェーズでしかないし、早めに卒業するべきものとされる。
正社員がやらない分、プログラミングはなるべくパートナー社員かオフショアに回す。
その方が安く済むからである。
サイゼリヤにおける料理人も、きっとこんな感じなのではないかと思う。
正社員ははじめに少しだけ厨房に入る体験をするが、それはマネージャーになるためのステップでしかない。
厨房で働くのは基本的にバイト料理人だ。
尚、私はサイゼリヤについて一般消費者以上の知識を何も持ち合わせていないので、
サイゼリヤに関しては全て憶測で喋っていることを了承頂きたい。
もしも実際のサイゼリヤにそぐわない話があれば、
サイゼリヤに似た架空の店の話だと思って欲しい。（喩えとして意味があるのか怪しくなってくるが。）
サイゼリヤで料理の修行はしない
一般的にSI業界の（プログラミングにおける）技術意識はとても低い。
普段から最新技術についての情報にアンテナを広げていて、家でもコードを書いていて、
というような社員はかなり希少というのが私の印象だ。
少なくとも前職では、GitHubのアカウントを持っていないどころの話ではなく、
「GitHubって何？」という社員が先輩後輩問わず大多数のようだった。
そんな環境も、上で述べたようなサイゼリヤ的背景を考えれば不思議ではない。
「究極においしいイタリアンを作れるよう、日々精進します！」と言いながらサイゼリヤに入る人は、きっとごく少数だろうと思う。
多くの人はマーケティングとかマネジメントに着眼するのではないだろうか。
SI業界も概ね同様なのである。（業務知識とかマネジメントとか。）
前職では、「プログラムなんて結局動けばなんだって良いよね」というような声を何度か聞いた。
ある種のプロフェッショナリズムとして、それはきっと正解なのだろう。
しかしそこにはプログラミングへの思い入れだとか、職人的なこだわりだとか、
より良いものを作ろうという熱意だとかが欠けている。
極端かもしれないが、私にはまるで、
料理人が「食えればなんだっていい」と言っているかのように聞こえた。
（これはサイゼリヤとは関係ないことにしておく。失礼になりそうなので。）
やはり料理の腕を磨くなら、本格的なイタリアンレストランで働き、同じように腕を磨き続けるレベルの高い料理人に囲まれるべきだ。
Webサービス業界はなぜ"本格的なイタリアンレストラン"なのか
Webサービス業界はSI業界と真逆で、エンジニアを続けるキャリアステップが普通に存在するし、
日々勉強しているプログラマーが非常に多い。
これはネットでもたくさん書かれていることであるし、
転職エージェントからも聞いた話なのでかなり確度の高い事実だと思われる。
このように違いが現れる理由はきっと色々あるのだろうが、
1つ挙げるならば、
「SI業界はプロジェクトの成功を考える（短期的目線）。Webサービス業界はプロダクトの成功を考える（長期的目線）。」
という要素が大きいのではないかと私は思う。
長期的にメンテナンスするプロダクトを作る
↓
メンテナンス性の高いプログラムを書けるプログラマーを集めたほうが良い
↓
技術力の高いプログラマーが集まる、技術力を高め続けるキャリアステップが必要になる
という理屈だ。
前職への思い
ここまで、SIを否定するような意見を述べたように見えるかもしれないが、そういうつもりはない。
世の中にはサイゼリヤも本格的イタリアンも両方必要だ。
どっちが良くてどっちが悪いというわけではない。
また、「プログラマーとしての腕を磨きたい」という観点で私はWebサービス業界等を志向するようになったが、
逆に「SEとしてやっていきたい」という場合はSI業界を志向し続けていただろう。
SI業界の技術力が低いのは、あくまでプログラミングレベルの話だ。SEのコアスキルはそこではない。
実際、私は初めの内は漠然と上流SEへの道を進むつもりでいた。
私は文系学部卒であり、学生時代のプログラミング経験はほとんど無い。
入社して実際にプログラミングに触れるまで、
自分がここまでプログラマー志向になるとは思っていなかった。
前職の方々は、そんな私の志向の変化を敏感に察知してくれ、
なるべく私がプログラミング寄りの作業をできるよう取り計らってくれたし、
将来的にも「技術長」というような感じの、例外的なキャリアパスを用意してくれているようだった。
この点について私は本当に感謝しているし、
期待に添えず退職したことは今でも申し訳なく思っている。
それでも退職したのは、私の希望があくまで「プログラマーの技術レベルが高い環境」だったからだ。
私自身が（プログラミングレベルに関して）周りを引っ張っていくということは何度も考えたが、
社員のプログラミングへの意欲が足りない限りは限界があると思ったし、
何よりメインプログラマーが取っ替え引っ替えのパートナー社員な体制では、
技術教育による技術レベルの底上げというのは不可能であるように感じられた。
それにやはり、まだまだ若い自分に必要なのは、人を引っ張ることより周りから吸収することだと思う。
尚、前職には他にも感謝することがたくさんあるが、
ここではあくまで「前職は悪いところじゃなかったよ」ってフォローがしたかっただけなので、
残りは省略する。
落ち穂拾い
ここまでがメインの辞めた理由であるが、
次職に期待することは他にも色々ある。
- BtoCで働いて、自分が作ったものの価値を自分で体感できる方が作り甲斐がありそう。
- 私服を始めとして、ギーク企業のラフな雰囲気が性に合ってそう。
などなど。
私は今まで「どう作るか」に非常に興味があり、「何を作るか」にはあまり注意を払ってこなかったのだが、
業界の特色上、これからは作るもの自体にも興味を持っていこうかと思っている。
補足
SI業界、Webサービス業界などと一括りに扱ったが、
これはあくまで全体的な傾向の話であるし、
例外的な会社も存在しているのは承知している。
なので、例外的に技術意識の高いSI会社に入るという選択肢も考えたが、
上記の落ち穂拾いで述べた理由も意外と大きく、
やはり業界をガラッと変えてみたいと思っている。
まとめ
技術力の高い会社に入りたいニャン。
SI業界がプログラミングを軽視する理由
前回の記事と被るところは多いです。
ikngtty.hatenablog.com
SI業界はプログラミングを軽視している
SI業界にとって、プログラミングは"卒業"するものです。
入社して最初の2～3年ほどプログラミングを経験したら、内部設計を行うようになり、外部設計を行うようになり、要件定義を行うようになり…。
だんだん上流工程に携わるようになり、代わりにプログラミングは新人やオフショアパートナーに任せるようになっていきます。
「もうfor文の書き方も忘れちゃったよｗ」などと笑いながらプログラマー時代を懐かしむ。
それがSI業界のキャリアパスの先にあるものです。
一方、Web業界は全く逆のようで、いくつになってもコードを書ける力はかなり重要視されると聞いています。
SI業界からWeb業界に転職を試みる人は多いようですが、あまり年齢が行っている人だと
「設計書ばっか書いてきて、結局ずっとコード書いてないわけでしょ？そんな人ウチには要らないよ。」
と門前払いを食らうらしいです。
誇り高き上流工程の経験を聞いてもらえず、新人しかやらないようなプログラミングの腕ばかり見られる。
価値観が本当に真逆ですね。
システムを作る仕事という意味では両者は同じです。なのにどうしてこんな差が生まれるんでしょうか。
ちょっとそこについて考えてみます。
プログラミングは単純作業か否か
もう少し言えば、SI業界はプログラミングを単純作業と考えているところがあります。
設計書さえあれば、あとはそれを動くものに変換するだけという感じ。
だから2～3年学べばそれ以上やっても大してスキルは変わらない。
だから10年、20年とプログラマーを続けても賃金は増えない。
だから早く卒業しなきゃいけない。
一方でWeb業界はそうした熟練プログラマーを欲しがるので、当然逆の価値観を持っています。
プログラミングは2～3年で極められるほど単純なものではない。
やればやるほど奥が深いし、その腕を磨き続けた人では生産性の次元が違う。
だから何十年も腕を磨き続ける価値があるし、磨けば磨くほど賃金を出してもらえる。
プログラミングは果たして単純作業なのでしょうか。そうではないのでしょうか。
私は、見方を変えればどちらも正解になると思っています。
プログラマーの成長曲線
プログラミングの腕を何十年も磨いていくと、人はどう成長するのでしょうか。
私は下記のようなイメージを持っています。
動くものを速く正確に作る力は、5年、10年で頭打ちになっていきます。
一方で、保守性の高いものを作る力はいつまでも伸びていきます。
つまり、単純なものを作る作業ならば単純作業ですし、工夫した良いものを作ろうとする作業ならば、頭を使う作業で、腕が要る作業だということです。
プログラマーを青い曲線で評価するか、赤い曲線で評価するか。
それはプログラムに保守性を求めるかどうかにかかってきます。
保守性について
詳しい定義は調べていないですが、私は「プログラムの変更・追加にかかるコストがいかに低く収まるようにできているか」だと思っています。
これには「一箇所を変更・追加した時の影響範囲が小さいかどうか」も含まれますし、「プログラムが読みやすいかどうか」も含まれます。
（一応後者について説明しておくと、プログラムを弄る際にはそのプログラムを読んで理解する時間が発生します。
この時間が占める割合は結構大きいです。
なのでこの時間が短く収まるプログラムほど「保守性が高い」と言えます。）
いずれにせよ、保守性を高める目的は「後で楽をすること」です。
短期的には時間・労力をかけてでも、長期的にかかる時間・労力を小さくするのが保守性を重視したプログラミングです。
SI業界は短期最適に走りやすい
Web業界はプロダクトで収益を生むので、プロダクト中心で考えて行動します。
普通、プロダクトは長期的に運用していきます。
なのでプロダクトの保守性を重視するのは当然と言えるでしょう。
一方でSI業界の収益源は何でしょうか。
作るシステムは全て他社のものです。今自分たちの作っているシステムは、この先別の会社が保守していくかもしれません。
そういった意味で、大事なのは目の前の一つ一つのプロジェクトのみです。
長期的に運用するプロダクトではなく、SI業界は短期的なプロジェクトでものを考えます。
その結果、より短期最適な戦略として、保守性は捨てた方が賢明という話になってきます。
プロダクト中心か、プロジェクト中心か。
冒頭で挙げた差はこの差から始まっているのだと私は考えました。
SI業界がプログラミングを軽視する理由
SI業界は、プロジェクトの短期的な成功を重視して保守性を捨てます。
その結果、プログラミングを単純作業とみなし、プログラマーを青い曲線で評価するようになります。
なので5年勤めた社員に払える給料はもう頭打ち。
社員にはプログラミングを"卒業"してもらうことで、別の方向での生産性の向上を図ってもらいます。
年功序列的賃金体系のもとでは、高年齢のプログラマはコストが高すぎると考える企業がある（特にプログラミングを単純作業と考える企業に多い）。俗にIT土方とも呼ばれデスマーチとなった場合は徹夜が続いたり体力が必要となってくる。そのため、プログラマとしての限界は30～35歳前後であるという説が存在した。これは「プログラマ35（30）歳定年説」と呼ばれる。
プログラマ - Wikipedia
結果、プログラミングを行うのは5年未満の新人か、単純作業が得意なオフショアパートナー。
いずれも安い賃金で済むので、そのへんも"短期的には"最適戦略というわけです。
これがプログラミング軽視の文化ができあがっていく背景だと私は考えています。
SI業界のコードが洗練されない経済学的理由
ペアプログラミングや勉強会など、洗練された綺麗なコードを目指すための取り組みはWeb系業界から多く聞くように感じます。
一方でSI業界はマネジメント関係への取り組みが多く、コーディング技術の向上にはあまり興味が無いようにも感じます。
SI業界はコードを洗練させる必要がないのでしょうか。
最近そういったことをよく考えるのですが、その中で以下の考えが芽生えてきました。
多くのSIにおいては、開発と保守が分かれている。
それゆえコードの品質が"外部化"され、"外部不経済"に陥る。
これについてまとめてみます。
"外部不経済"とは何か
例としてよく「公害」のケースが挙げられます。
例えば、工場の汚水排出問題を考えましょう。
工場が取れる選択肢は以下の２つであるとします。
1. 何も考えず汚水を垂れ流す
この場合、周辺住民が健康を害し、全部で1億円分の経済学的損失に繋がるとします。
「周辺住民の不幸分を金額で表すと1億円ぐらい」って感じですね。
「損害賠償として1億円貰わないと納得しない」と考えてもいいと思います。
2. 汚水浄化マシーンを買う
これで無事公害を防げます。
その代わり汚水浄化マシーンは1000万円します。
周辺に工場関係者しか住んでいなかったとしたら
つまり、公害の被害を全て工場が食らうとしたらです。
この場合、工場の損失は
1. （浄化しない場合）1億円
2. （浄化する場合） 1000万円
です。
当然工場は2を選びますよね。
周辺に工場関係者が住んでなかったとしたら
経済学ではこの場合、「公害のコストが外部化されている」と表現します。
つまり、公害の損害なんて工場にとっては関係ないということですね。
兵藤会長の言葉を借りれば、「彼は痛いが…わしは痛まない…！」です。
なので、工場の損失は
1. （浄化しない場合）0円
2. （浄化する場合） 1000万円
と考えます。
何も罰がないのなら、工場は1を選ぶというものです。
（実際には「信用を失う」などの損失もありそうですが。）
問題点
さて、ここまでの問題を国の立場で考え直してみましょう。
国は基本的に、「皆の幸せ値の合計が一番高ければいいな（不幸値の合計が一番低ければいいな）」と思っています。
皆の不幸値の合計はこうなります。
1. （浄化しない場合）地域住民 1億円 ＋ 工場 0円 ＝ 1億円
2. （浄化する場合） 地域住民 0円 ＋ 工場 1000万円 ＝ 1000万円
つまり2の方が望ましいわけです。
しかし、先ほどの後者のケースでは1になってしまいました。
この状況が「不経済」です。
つまり、皆の不幸値がより高くなってしまった状況です。
不経済の原因は「コストが外部化されている」ことでした。
なのでこの状況を「外部不経済」と呼ぶわけです。
解決法
実際には外部に損害をもたらした人には罰が与えられます。
国は「汚水を流したら1億円罰金！」と規制をかけておけばいいのです。
そうすれば、工場の損失は
1. （浄化しない場合）1億円
2. （浄化する場合） 1000万円
となり、工場は2を選びます。
これを「公害のコストを内部化した」と表現します。
1億円の損失を、罰金という形で工場も計算しなければいけなくなったということですね。
SI業界の"外部不経済"
前置きが長くなりましたが、本題です。
簡単に言ってしまえば、「コードの洗練」が先程の例で言う「汚水浄化」にあたると思っています。
「開発」が「工場」、「保守」が「周辺住民」です。
具体例で行ってみましょう。
SI会社は以下の内どちらかの選択肢を選べるものとします。
1. 汚いコードでさっさと納品する
初期開発費用として1000万円の人件費がかかります。
年に1回の機能追加／改修の際には毎回500万円かかります。
2. 綺麗なコードで丁寧に作り込んで納品する
初期開発費用として1500万円の人件費がかかります。
年に1回の機能追加／改修の際には毎回200万円かかります。
システムを5年は使い続けるものだとします。
前提として、汚いコードでもテストはちゃんとやっており、バグは直してるものとして下さい。
あくまでもコードの綺麗さはメンテナンス性のために目指すものとしています。
開発と保守をセットで行える場合
1. （汚いコード） 5年で総費用3500万円
2. （綺麗なコード）5年で総費用2500万円
当然2を選びます。
保守は他がやってくれる場合
1. （汚いコード） 初期開発費用1000万
2. （綺麗なコード）初期開発費用1500万
これは1を選びますよね。
企業は基本的に自分のビジネスが最優先です。
保守が苦しむことになろうと、自分たちに関係が無いのならばお金を出して助けようとは思いません。
結果としてこれは、周辺住民と工場の関係と同じになります。
実際には、開発が保守を完全にやらないというケースは稀だと思います。
しかし、「次の機能追加を自分たちがやるとは限らない」という雰囲気が強まるほど、この問題は立ち現れるでしょう。
「このシステムは自分たちが長く作っていくものだ」という認識がなければ、綺麗なコードを目指そうという動機が生まれない。
ここがWeb系業界との差だと考えています。
エンドユーザーの視点
エンドユーザーとしては、トータルで安く買いたいはずです。
しかし今回の例のように「次の機能追加が200万円で済む」などと事前に分かることは、実際はほとんど無さそうです。
そうするとエンドユーザーができることは結局、初期開発の見積が一番安いところを選ぶことだけではないでしょうか。
こうなると勝つのは汚いコードを書く会社ですよね。
これもSI業界が綺麗なコードをなかなか目指すことが出来ない理由だと思います。
そもそもの問題は、エンドユーザーがコードの汚さを測れないところにあります。
公害の例で言えば、国は川の汚染状況を測ることができるため、対策を打つことができました。
エンドユーザーはこれができません。
コードの海は知らない内にどんどん汚染されていくのです。
保守費用がいくら膨れ上がっても、「機能追加ってやけにお金がかかるものなんだなぁ」と感じるだけではないでしょうか。
解決法１
エンドユーザーが打てる手としては、まずはSI会社にとっての保守費用を内部化させることです。
つまり、「このシステムはずっと御社に任せたい。」と表明するような体制です。
１エンジニアとして思うのですが、自分たちで作ったシステムを他社にメンテナンスされたり、他社が作ったシステムを自分たちで弄ったりすることは苦労が多いです。
どこの会社が作ったかも分からない汚染物質だらけのコードの海を任されて、一から洗浄する時間も与えられず、せめて海からなるべく早く帰ってくることを目指すしかない。
そのためには、自分たちも海を汚していくしかない。
というかこんだけ汚れてたら今更どれだけ汚しても変わらないよね……。
こうしてエンジニアとしての清らかな精神も、汚染物質にすっかりやられてしまいます。
こんな悲劇を避けて、お互い幸せになりたいところです。
しかし、これはエンドユーザーとSI会社の間に深い信頼がないとできないかもしれませんね。
初期開発に時間をかけるのは後の保守効率のためであること。そのためトータルでは安く済むこと。
このへんを話し合って認識を共有しておく必要があります。
また、この体制では保守時の見積額に競争原理が働かなくなってしまいます。
つまりSI会社は保守金額を無駄に釣り上げることもできるということです。
そこに関しても信頼関係や、事前の深い話し合いが必要かと思います。
解決法２
もう一つの作戦として、エンドユーザーがコードの汚さを測ればいいんじゃないかと私は考えています。
実際にはエンドユーザー自身が測るのではなく、第三者によるコード品質監査サービスを利用する形で考えています。
（そういうサービス、あるんでしょうかね？
もしも無いとしたら、これはビジネスチャンスなんじゃないかとも思います。）
コードの汚さが数値化できれば話は早いです。
コードの汚さが一定以下であることを要件に入れてもいいですし、コードの汚さに応じて払う金額が変わるような契約を結んでもいいんじゃないかと思います。
いずれにせよ、これでSI会社側には時間とお金をかけてでもコードを洗練させる理由が生まれます。
まとめ
というわけで、「SI業界はコードを洗練させる必要がないのか」という問いに対しては、「現状ではそうなってしまう」というのが私の考えです。
もちろんバグの発生を抑えるようなコードの洗練は必要だと思いますが、一定レベル以上の洗練はメンテナンス性の向上が主目的だと思っているので、そこから必要なくなってくると考えています。
エンドユーザーからの打開策も考えてみましたが、いずれも「エンドユーザーがコードの汚さを後の損害（いわゆる"技術的負債"）と認識できること」が前提です。
エンドユーザーとSIが今よりもっと深く話し合わないと難しそうな気がします。
何より、今のSI業界はコードを洗練させない方向でそのまま戦略を最適化しようとしてるように思えます。
綺麗なコードを書ける高い人より、汚いコードしか書けない安い人を使う。
優秀な人は下流ではなく上流で使う。
オフショア開発の流れなどはその典型的な表れですね。
ここまで自分の考えをまとめてみましたが、推測が多分に含まれています（特にエンドユーザーとSI会社がどういった契約の結び方をしているのかとか）。
何か認識に誤りがあればコメントで指摘して頂けると幸いです。
おまけ：レモン市場
今回は「外部不経済」というキーワードで分析してみましたが、「質の悪いものを納品されてもエンドユーザーは分からない」という点で言えば、経済学で言う"レモン市場"の状況にも当てはまりそうです。
前述の解決法２はこれへの対処法とも言えそうです。
では、このへんで。
