【日記】「エンジニアが不要とされる瞬間」について考えたこと【意見】

wrongwrong163377.hatenablog.com

上記記事に関して、「じゃあ未来永劫エンジニアが必要とされ続けるか」と言われるとそうでもないと思っている話を書きます。
自分は主に以下の状況でエンジニアが不要とされるだろうなと思っています。

• 人格と社会的な不確実性まで再現するAIが出てきたとき
• 戦争になったとき
• 核戦争になったとき

人格と社会的な不確実性まで再現するAIが出てきたとき

これに関しては、もう人間そのものが不要になるだろうなあと思っています。

人間の有利な点はその汎化能力と言われていますが、人生を無限にエミュレートするようなことをされてしまえば、どんなこともAIには敵わなくなるでしょう。
特に机上でアレコレやるのが主な仕事となるようなエンジニアは真っ先に置き換えられてしまいそうな気がします。

ただ、これに関してはもはや人類共通の問題となってしまうので、そこまで行ったらもう諦めるしかないんじゃねとも思っています。

戦争になったとき

これについてはほぼ日本しか見ていない話です。

色々きな臭い世の中になっていますが、今の日本の状況で戦争になったとき、エンジニアの技能は全く大切にされないだろうと思っています。
第二次大戦でも重要な技能者を徴兵で溶かして兵器の生産力を下げるなんてことをやらかしていましたが、現代でもそうだろうなあという諦めが有ります。

まず上に立っている人間がIT音痴すぎるので、エンジニアという道具の用途なんて考えられないでしょう。
また、国民の方も「後ろで何やってるか分からない奴なんて前線に出したほうがいい！」という声で応えそうだなと思います。

状況が不安定になったとき、エンジニアの立場は多分弱いです。

核戦争になったとき

直接的に電子機器が壊れることもそうですし、ライブラリ・パッケージの配信システムがやられたり、クラウド環境が消し飛んだりすれば結構なエンジニアが仕事できなくなるだろうと思います。
少なくとも色んなサービスが止まることでしょう。

まあ、こんなことになればやっぱり人類共通の問題となってしまうので、そこまで行ったらもう諦めるしかないですね。

終わりに

今の世の中は物凄くきな臭いことになっていて、全方面「なんかあったら社会的にも人生的にも終わるかもなあ」で囲まれてしまっている感が有ります。
日本という国の将来に希望を見いだせないというか、人類という種の将来そのものに希望を見出せません。

宇宙植民さえ軌道に乗れば人類は未来永劫やっていけるんじゃないかと思うので、できればそういう世界線に収束して欲しいものです。

【日記】「AIがエンジニアを不要にする」という言説について考えたこと【意見】

AIでプログラマが不要になる系の話、「プログラミングにおける作業量の9割近くは自動化可能だが、仮に自動化しても自動化で置き換えられない1割と、自動化ツールを使うために新たに増える1割が仕事として残る」ってのの繰り返しなんじゃないかと思うようになった

— wrongwrong (@wrongwrong16337) August 3, 2019

「AIがエンジニアの仕事を完全に置き換えるからエンジニアが不要になる論」について、上記ツイートを元に考えたことをまとめます。
そもそもの話として、「〇〇だからエンジニアは不要になる論」はどうやら自分が生まれる位から繰り返されているようなので、ここでは「何らかの自動化によりエンジニアが不要になる論」全体について書きます。

直近十年に対する結論

まずはじめに、直近十年でエンジニアが不要になることはほぼ無いと自分は考えています。
理由は以下の3点です。

• 自動化のための仕事と自動化できない部分は必ず残る
• 自動化しただけでは環境変化に対応できない
• エンジニアの仕事はほぼ無限に有るので需要が無くならない

以下、それぞれについて主張を書きます。

自動化のための仕事と自動化できない部分は必ず残る

そもそも自動化を行うためには自動化を行える状況である必要があります。
一方、現実はそう単純なものではなく、沢山の歴史的経緯や考慮不足によって自動化を行える状況になっていない方が普通です。
つまり、自動化のためにはまず自動化できる状況を整えるための仕事が発生します。

この自動化のための仕事というのは「業務フローから見直したほうがベター」と言われる程度には大規模になることが殆どです。
また、自動化のための仕事をやっている最中にも本業は進めていかなければなりません。
ここで何が起きるかというと、自動化が完全に終わる前にライフサイクルが一周してしまい、「新しい技術を使って昔自動化した部分をより効率化する」的な仕事が発生していきます。
つまりエンジニアがやらなきゃならない仕事は残ってしまいます。

更に、仮に自動化を完遂したとしても、やはり自動化できない部分は確実に残ります。
開発にエッジパターンや考慮漏れが発生しないなんてことは有りえません。
高度に練られたフレームワークを使っていてさえかゆい所に手が届かない場面が発生することがいい例です。

そのような部分に対応するためには、結局エンジニアの手作業が発生するでしょう。
やはりエンジニアの仕事は残ってしまいます。

自動化しただけでは環境変化に対応できない

仮に自動化可能な業務を全て自動化したとしても、エンジニアの仕事は無くなりません。
前段で少し触れましたが、時間経過に伴って業務を取り巻く環境は変化していくからです。

パッと思いつくだけでもエンジニアが対応しなければならない環境変化はこれだけあります。

• 脆弱性の発生
• 機器の更新
• OS・フレームワークの更新/サポート打ち切り
• 業務内容の変化
• 法的規制の変化

環境が変化しないなんてことは有りえません。
そして、自動化は今現時点で見える範囲に対してしか行うことはできません。
環境の変化に対応してやっていくためには、やはりエンジニアが必要とされます。

エンジニアの仕事はほぼ無限に有るので需要が無くならない

近年のツールや開発環境の進歩というのは凄まじく、IDEによる補完といった個人の生産性を向上させるものから、クラウド技術のように組織全体のアレコレを効率化するものまで、多様かつ圧倒的な改善が見られます。
これらを使いこなすエンジニアの生産性は、年単位で飛躍的に向上していると言って良いでしょう。
一方、高度に自動化された最先端の環境においてエンジニアの労働時間が減ったかと言えば必ずしもそうとは言えません。

この理由を、自分は「エンジニアの仕事はほぼ無限に有る」からだと考えています。

人間が計画して実行するアレコレでは「何をやらないか」を決めることが重要とされていますが、逆に言えばやりたいことはそれだけ有るという訳です。
エンジニアにおいてもそれは例外ではなく、もっとこうしたいだとか、機能追加をしたいだとか、とにかくエンジニアが携わる必要のあるタスクは無限に有るわけです。
表に出ている分かりやすい事実として、webページは表現がどんどんリッチになっています。

要するに、現状では多少何かが改善されてもそのスペースに滑り込んでくる仕事が有るという訳です。

終わりに

今の所自動化はアキレスと亀で、もブレイクスルーが無いならどれだけ進歩してもエンジニアが不要になるという状況に辿り着くことは無いだろうというのが自分の結論です。

というか「何らかの自動化によりエンジニアが不要になる論」って、エンジニアが生産性向上のために日々どれだけ努力しているかを軽視している感が有ると思っています。
毎日毎日業務と向き合い自動化の可能性の模索を行う立場の人間を無くすことができるとなぜ考えられるのか、割と不思議だな、と。

……割とこういった言説を真に受けていた自分も想像力不足でしたね。
まとまりませんがここで記事を切ります。

【レビュー】東京マルイ ステアーHC レビュー

過去記事で何度か触れていましたが、改めてステアーHC単体でレビューしていきます。

wrongwrong163377.hatenablog.com
wrongwrong163377.hatenablog.com
wrongwrong163377.hatenablog.com

記事内で提示するデータに関する注釈は以下の通りです

• マルイ純正ミニSバッテリーを使うものと仮定し、その重量は181gとして計算する
• 参照させていただいたデータについて、出典は記事末尾にまとめる

他銃との比較

結論から言うと、実用性だけ考えてハイサイクルカスタムを買うならH&K MP5A5 HCをオススメします。
理由は、素の状態で弾速・マガジン装弾数・重量のバランスが一番良く、実用面でも不便が少ないからです。

以下、スペック面と実用面の両面から、H&K MP5A5 HCとの比較を通してレビューしていきます。

スペック面

まずはステアーHCとH&K MP5A5 HCをスペック面から比較します。
両者の主だったスペックは以下のとおりです、ただしH&K MP5A5 HCはストックを何段階かで調整できます。

	ステアーHC	H&K MP5A5 HC
平均弾速(m/s)	85.13	81.88
装弾数	330	400
弾以外の重量(g)	2,861	1,800
全長(mm)	610	660(ストックの最大展開時)

こうして見ると分かる通り、ステアーHCは弾速以外のスペックで劣ってしまっています。
また、その弾速についても誤差レベルと言って良いでしょう。

実用面

実用面では、以下3点で比較を行います。

• 装弾数
• 重量
• AIMしやすさ

装弾数

装弾数に関してはプレイスタイル・フィールドによって活きたり活きなかったりしますが、沢山撃つフィールドでは両者の70発の差は結構大きいです。
また、弾をあまり撃たないフィールドでも、補給の手間が減るのは楽です。

重量

重量に関しても、ステアーHCが重いというわけではありませんが、やはりH&K MP5A5 HCの方が軽いです。
場合によっては丸一日エアガンを持って走り回ることになる訳で、1Kgの差は大きいです。

AIMしやすさ

ここが一番大きな差です。
ステアーHCはマスクをした状態だとAIMしにくいです。

この点について、マック堺さんの動画（比較対象がH&K G3 SAS HCに変わりますが、結論は変わらないのでこちらを使わせて頂きます）からキャプチャして解説します。
www.youtube.com

画像は17秒付近（左）と23秒付近（右）です。見て分かる通り、ステアーHCの方がより多くの頬肉が乗っています。

普通の状態で覗くのであればこれでもAIMに十分かもしれませんが、硬いマスクをして覗こうと思うと大分無理やり覗かなければなりません。
ドットサイトを使うのであれば、マウントベースで嵩上げすることで多少マシになりますが、銃身とスコープが離れることを考えるとやはり狙いやすいのはH&K MP5A5 HCの方だと思います。

本体に関して

ここからは単体でのレビューです。

他の方のレビューでも見かけましたが、ステアーHCはVグリップの付いているあたりがガタつきます。
また、まだ2戦しか使えていませんが、アッパーのレール部分も若干歪んでいました。
以上の通り、剛性には若干難が有るのかなと思います。

まだ特に問題が出たわけではありませんが、若干不安感は有ります。

まとめ

「ステアーHCを買うメリット有るの？」と聞かれると、「正直他のやつ買ったほうがいいよ」と言うと思います。

とは言えスタイルの独特さ（特に他人と銃がかぶる確率は低そう）は魅力的なので、「どうしてもこれがいい！」という人にはかなりオススメできます（本音を言うとHCならFA-MASが欲しかったマン）。
ボロクソ書いた自覚は有りますが、自分はこの銃を結構気に入っていますし、フィールドでも割とまともに戦っていける程度には使えています。

まとめるとロマン銃ということですね（アレ、結局擁護できてない感が）。

参照させていただいた資料

各種データ

ステアーHC

• ステアーHC ブラック - 電動ガン ハイサイクルカスタム | 東京マルイ エアソフトガン情報サイト
• 東京マルイ 電動ガン ステアーHC

H&K MP5A5 HC

• H&K MP5A5 HC - 電動ガン ハイサイクルカスタム | 東京マルイ エアソフトガン情報サイト
• MP5A5 HC(ハイサイクル) 東京マルイ 電動ガン エアガンレビュー

【自作PC】購入用メモ【順次更新】

組む時期

増税直前ということで9月頃を予定しています。

メインパーツ

個人的な優先度順で書きます。

ケース

まだ決めきっていませんが、A4-SFXを選ぼうと思っています。
理由は、今回の自作で求めるのが最もコンパクトなケースであることだからです。

kakaku.com

個人的にはSilver StoneのSG-13の後継とかを何年も期待してるんですが、残念ながらそのような製品は話題にすら上がらず……。

一応その他候補ケースはこちらにまとめてあります。 wrongwrong163377.hatenablog.com

CPUクーラー

CPUクーラーはCryorig C7Gにするつもりです。
小型ながら圧倒的な冷却力、メモリに制限が無いロープロファイルヒートシンクならこれが一番優秀だと思ってます。
未発売で組みたい時期に間に合ってくれるかが不明なことと、CPUを冷やしきれるかが問題……。

まだ内容が入っていませんが、一応公式サイトも既に有るみたいですね。

www.cryorig.com

A4-SFXにはほぼ専用な簡易水冷クーラーも有るんですが、個人的に簡易水冷はもう飽きたので今度は空冷にするつもりです。

CPU

Ryzen 9も考えましたが、スペックを大きく求める場面がゲーム用途かつ流石にそこまでパワーは必要無いだろうということでRyzen 7 3800Xにしようと思います。
今使っているのがIntel Core i7 6700なので、それにしたってものすごいパワーアップなんですが。
ただ、仮にC7Gで3800Xが冷やしきれないということであれば、その時は3700Xまで落とすかもしれません……。

kakaku.com

メモリ

G.Skill Trident Z Neoシリーズから選ぶつもりです。
本音を言うとDDR4 3600 C14とかいう超スペックなやつを選びたいんですが、16 x 2キットは今の所発表されてないみたいなんで、16 x 2キット中一番良スペックなものを選ぶつもりです。

blog.livedoor.jp

グラフィックボード

まだ出ていないですが、CPUに合わせてRadeon 5000シリーズの上位機種を考えています。
ただ、まだまだ情報が出揃っていないことも有るので、もしかするとRTX 2080Tiとかにせざるを得ないかもしれませんね。
Radeon 5000シリーズはPCIe 4.0に対応しているものの、現状のGPUの性能ではPCIe帯域がボトルネックになることは少なかったはずなので、実際はそこまで重視しなくてもいいのかなとは思っています。

ただ、2スロット高性能グラボって今本当に少ないんですね……。
見た感じINNO3DのGEFORCE RTX 2080 TI GAMING OC X3が一番良さそうな位で、「マザボも作ってるメーカーのものは大概2スロ = そこまで冷却力有るモデル無し」になってしまっているのが残念です。
自分が自作に触れた頃はGigabyteが2スロ3連ファンって印象が強かったんですが、、、。

マザーボード

グラフィックボードに合わせて選ぶか、合わせてもいいことが無さそうなら良さげなのをそのまま選ぶつもりです。
なのでGPUを決めるまで保留します。

一応ASUSのROG Crosshair VIII Impactが気になってはいるんですが、A4-SFXだとサイズ的に積めないだろうなあという辛さが……。

www.asus.com

電源

小型ケースなこともあり、SF750 Platinumが安定かなと思います。

kakaku.com www.tomshardware.com

SSD

使い回しで960 PRO M.2 MZ-V6P1T0B/ITです。

kakaku.com

その他パーツ

オプショナルなパーツ類です。

ケースファン

A4-SFXでは底部に92ミリ角ファンを積めるので、厚い方はNF-B9 redux-1600を入れようかなと思っています。
正直これを選ぶ理由もそこまで無いんですが、Noctua製だし色も悪くないと来ればこれが安定かな、と。

薄い方は何を入れようかな……。

kakaku.com

CPUクーラーファン

C7Gを光らせる用です。
A4-SFXで光らせる必要性は薄いと思っていますが、光がいい感じに抜けるようであれば積んでもいいかなと思っています。

www.links.co.jp

【SpringBoot】内部エラー周りの話

内部エラー周りの設計について自分の経験から得た知見をまとめます（なのでセオリーとかアンチパターンとか有れば教えていただけるとありがたいです）。
内部エラーとは基本的に自分で書いてThrowするようなエラーを想定しています。

エラーハンドリングに関してはサンプル記事が溢れているので省略します。

例外クラスの作り方

サーバーとフロント側で「エラー内容/HTTPステータスコードによって大体の挙動を統一する」ことができるため、基本的に返却するHTTPステータスコードに合わせて例外クラスを作ればよいと思います。
内部エラーコードを設定することも考えられますが、アプリケーション規模が小さいうちはそこまでしなくてもHTTPステータスコードに合わせておけば大体の場合に対応できるので、個人的にはYAGNIかなと思っています。

自分のやっているプロジェクトでは以下のような例外クラスを設定していました（抜粋です）。

ステータスコード	例外クラス名	エラー内容	フロントでの対応
400	InvalidFormException	フォームの入力エラー	項目ごとにエラー表示
409	ResourceConflictException	リソース更新のコンフリクト	データの再取得を促すアラートを表示
500	${プロジェクト名}Exception	その他内部的なエラー	エラーページの表示

継承元に関してはExceptionではなくRuntimeException系のものを設定した方が後々楽だと思います（ラムダ式内で内部エラーを投げる時に困る場合などが有るため）。

その他Tips的な内容

スタックトレースのフィルタリング

全て1つのプロジェクトで完結している場合、内部エラーは発生箇所がパッケージ内に有ることが確実になるため、それ以外のスタックトレースは基本的に不要となります。
そこで自分はフィルタリング関数を用意して宣言時にスタックトレースを設定し直していました。

フィルタリング関数

static StackTraceElement[] filteringStackTrace(StackTraceElement[] elements) {
    return Arrays.stream(elements)
            .filter(it -> it.getClassName().startsWith("${プロジェクトルートのパッケージ名の文字列}"))
            .toArray(StackTraceElement[]::new);
}

使い方

public class ResourceConflictException extends RuntimeException {
    public ResourceConflictException(String msg) {
        super(msg);

        // スタックトレースはフィルタリングして設定
        setStackTrace(FilteringStackTrace.filteringStackTrace(getStackTrace()));
    }
}

例外処理の結果でJSONを返す場合にJSON以外を返すControllerでproducesを設定してはならない

producesで指定したのと違う内容を返却しようとすることになるため、HttpMediaTypeNotAcceptableExceptioとしてエラーになります。
具体的には以下の記事にまとめてあります。

• 【SpringBoot】producesを設定したエンドポイントでHttpMediaTypeNotAcceptableExceptionになった場合の対処 - Qiita

【Maven】OWASP Dependency CheckでsuppressionFileを指定した際に「要素'suppressions'の宣言が見つかりません。」とエラーになる問題への対処

問題

以下のようにSuppressionFileとpomを用意して抑制設定を行いました。

• owasp-dependency-check-suppressions.xml(SuppressionFile)

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.3.xsd">
  <!-- 省略 -->
</suppressions>

• pom.xml

<!-- 省略 -->

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>5.0.0</version>
    <configuration>
        <failBuildOnCVSS>8</failBuildOnCVSS>
        <suppressionFiles>
            <suppressionFile>owasp-dependency-check-suppressions.xml</suppressionFile>
        </suppressionFiles>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

<!-- 省略 -->

すると以下のようなエラーになりました。

• エラー内容（抜粋）

[WARNING] Unable to parse suppression xml file 'owasp-dependency-check-suppressions.xml'
[WARNING] org.owasp.dependencycheck.xml.suppression.SuppressionParseException: org.xml.sax.SAXException: Line=2, Column=99: cvc-elt.1.a: 要素'suppressions'の宣言が見つかりません。
[ERROR] Exception occurred initializing Vulnerability Suppression Analyzer.

対処

xmlnsに指定しているdependency-suppressionのバージョンを1.2に落とせば通りました。
原因は一旦調べていません。

• owasp-dependency-check-suppressions.xml(SuppressionFile)

<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.2.xsd">
  <!-- 省略 -->
</suppressions>

【Vue.js】オブジェクトの内容を変更しているのにcomputedが変化しない状況への対処

状況

dataに用意したオブジェクトの内容を変更しているのにcomputedが変化しなくて困っていました。

対処

前提

dataに宣言する時点でプロパティを宣言しておけばVueが更新を追ってくれるので、基本はプロパティを宣言しておいた方がいいらしいです。

// ダメなやり方
data() {
  return {
    hogeObject: {}
  }
}

// いいやり方
data() {
  return {
    hogeObject: {
      fugaKey: null
    }
  }
}

今回の場合

初めからプロパティを宣言できない場合、$setを使うとできます。

// 改善前
this.hogeObject[fugaKey] = piyoValue

// 改善後
this.$set(this.hogeObject, fugaKey, piyoValue)

参考にさせていただいたサイト

• Vue.jsでビューの変更がされないときに疑うこと+主な解決策方法 - Qiita