  |
はてなキーワード: アーキテクチャとは
Webを閲覧する、YoutubeやNetfrixを楽しむ、電子書籍を読む、ちょっとしたゲームをプレイする、SNSでコミュニケーションを取る程度のライトユースなら十全に使えると言って良いです
メモリを大幅に消費する4K動画編集をする、リアルタイムに重量級エフェクトを掛けて楽器を演奏したい、iPad並にイラストレーションがしたいというクリエイティブユースになってくると少々厳しいです
ただしクリエイティブユースであれAndroidでは代表的なシンセサイザーアプリの「Caustic」や「Zenbeats」「FL Studio Mobile」で作曲する程度なら普通にいけます。MIDIキーボードも認識しますしね
厳しいのはバンドパフォーマンス並みのリアルタイム演奏ってことになります
同様の理由で膨大なレイヤーがなければイラストレーションもいけますし、フルHD程度なら動画編集もいけます
そしてリアルタイムの描画演算能力を問われる3Dゲームや、タイミングがシビアなリズムゲームも苦手な部類です
リアルタイム性が問われてしまうとどうしてもARMアーキテクチャー向けに生成されたアプリはx86_64アーキテクチャーデバイスではツライものがありますね
Googleも各アーキテクチャデバイスへ向けてアプリを生成すべしと宣伝してますので、x86_64デバイスでのAndroidアプリパフォーマンスはChrome OSデバイスが注目を浴びていることもあり徐々に改善していくものと思われます
現状ではそう捉えてもらって構いません。
しかしながら開発環境のAndroid StudioはARMアーキテクチャー向け以外にもx86(x86_64)アーキテクチャー向けにもコンパイル＆ビルドが可能です。
ゲームなど高度なグラフィックス機能を用いた場合に問題となるのはARMアーキテクチャー固有の機能へ強く依存する設計を行っているアプリですね。
ARMの機能へ強く依存しないように心がけて高度なグラフィックスを実現するとx86アーキテクチャーでも軽快なアプリは実装できます。
Chrome OSデバイスはAndroidスマートフォンと比較して大画面であることが多く、ゲームの需要も比較的高いことが予測されます。
広いプラットフォームへ配信することを考えてもアーキテクチャー固有の機能へ依存しすぎることは開発にとって技術的負債になりかねないので広範な実装をしたほうが良いでしょう。
このあたりは3Dゲームの開発環境ではデファクトスタンダード化しているUnityにも気をつけて貰いたいところです。
当エントリはある程度の情報技術リテラシーが必須であり、一部の情報はPC初心者および初級者に推奨できるものではない。
しかしPC初心者および初級者はシステムを壊す、大事なデータを失うなどの手痛い失敗をして成長するのもまた事実であり、もしもプログラミングなどに興味のあるPC初心者および初級者がこの情報を活用する場合はシステムを壊す、大事なデータを失うことを覚悟して実行するように。
チュートリアルに指示通りに進めれば大きな問題はほぼ発生しません。
Chrome OSは初期状態のデフォルトで「ノーマルモード」と呼ばれる一般ユーザーモードですが開発者向けに「デベロッパーモード」が用意されています。
ノーマルモードはChrome OSの様々な制限があり、デベロッパーモードによって制限の解除が可能です。
しかしノーマルモードからデベロッパーモードへ移行するとPowerwash(初期化)されてしまい、システムやユーザー領域へ追加された情報はすべて削除されます。
もしデベロッパーモードが必要な場合はデベロッパーモードの詳細を調べ、現在の情報は削除されてしまうことを念頭に実行しましょう。
ちなみにProject CrostiniのLinuxレイヤーへDebianリポジトリからパッケージを導入するなどにはデベロッパーモードは必要ありませんので多くの場合はノーマルモードのままの運用で十分でしょう。
Android OSアプリやChrome OSアプリを開発したい場合は最初からデベロッパーモードにしたほうが後悔が少ないです。
Chrome OSでは一部のキーがほかのOSでは見慣れないものが並んでいます。
迷いがちなので一番最初に覚えるべきキーボードショートカットは「Ctrl+Alt+?」です。
「Ctrl+Alt+?」でいつでもキーボードショートカットを確認できることだけは覚えておきましょう。
多くのChrome OSデバイスはGoogle Play Storeへ対応しており、Google Play Store経由でAndroid OSアプリ導入が可能です。
しかしながらGoogle Play Storeへ公開されているAndroid OSアプリが必ずしもChrome OSへ最適化しているのか？と言えばそうではなく、Android OSアプリの開発環境であるAndroid StudioがデフォルトでChrome OSでの実行を許可していることもあり開発者が意図せずChrome OSへインストールできてしまうことが大半です。
したがってChrome OSへ導入するAndoirdアプリの動作へ何らかの不具合があったとしても脊髄反射で酷評せず、やんわりと丁寧に博愛精神をもってChrome OSではこうだとアプリ開発者へ情報共有することをオススメします。
多くのAndroidスマートフォンやタブレットはARMアーキテクチャーと呼ばれるものを採用していますが、現在のChrome OSデバイスは高性能な製品になるほどx86(x86_64)アーキテクチャーを採用している傾向があります。
本来コンピューターアプリケーションというものはアーキテクチャーが異なると実行起動動作が不可能ですが、Android OSアプリは異なるアーキテクチャー間でもアプリの実行起動動作が極力可能となるように互換性をだいたい確保しています。
しかしながら例えばARMアーキテクチャー向けのAndoird OSアプリをx86アーキテクチャーなデバイスで実行するとアプリ動作のパフォーマンスが著しく落ることが多いです。
これは高度なグラフィックス機能を必要とするゲームなどで顕著に現れる傾向にあり、Chrome OSでは期待したほどAndroid OSアプリが軽快に動かない可能性を理解しておく必要があるのです。
コロナ禍によって多くのChrome OSデバイスを販売することが出来ましたが、それによってChrome OSデバイス間の性能差が問題視される機会も増えました。
具体的には「インターネット上でChrome OSでの動作報告がなされているAndroidアプリが自身のChrome OSデバイスではインストールできない」といった報告です。
これは一部のAndroidアプリ開発者がデバイス性能によってインストールの許可不許可を決めているために起こることで解決方法は基本的にありませんので諦めましょう。
これから導入するAndroidアプリのためにChrome OSを購入する際は価格につられて低性能すぎるデバイスを購入してしまうと失敗する確率が高まりますので注意が必要です。
ただし、Googleが提供するアプリなどは基本的にそのようなことは無いようです。
設定から「Linux（ベータ版）」で「オンにする」とLinuxのインストールが開始されます。
現在のChrome OS v90ではLinuxレイヤーを実現するProject CrostiniではデフォルトでGPUによる支援機能を実行できません。
Chrome Webブラウザを起動し、URL欄へ「chrome:flags」と入力しアクセスして「Crostini GPU Support」を「Enabled」とし再起動してください。
この変更で動作に不具合を確認した際は設定を元に戻してください。
LinuxにもGoogle Play Storeのような簡単にLinuxアプリを導入できる環境が存在します。
GUIパッケージマネージャーを導入する場合は「ターミナル」を起動し下記を実行してください。
sudo apt install synaptic gnome-software
Chrome OSとLinuxレイヤーではパッケージの導入先がデフォルトで海外のサーバーになっており少々遅いです。
日本国内のサーバーへ変更することで速度を改善できる可能性があります。その際は「ターミナル」を起動し下記を実行してください。
現在のChrome OS v90ではChrome OSとLinuxレイヤーを実現するProject Crostiniで日本語入力を共有できず、キーボード入力しても英字しか印字されません。
日本語入力をするには別途に日本語インプットメソッドと日本語フォントが必要です。
日本語インプットメソッドと日本語フォントを導入する場合は「ターミナル」を起動し下記を実行してください。
Linuxへ詳しい方はfcitx5のほうが何かと問題が少ないでしょう。
しかし一部のfcitx5向けパッケージがDebian公式リポジトリに存在しない可能性があるのでご注意ください。
KVMやLXC、Dockerなどの仮想環境を幾度か試しましたが、仮想環境を構築したProject CrostiniのLinuxレイヤーを再起動するなどによってProject CrostiniのLinuxレイヤーシステムへ致命的な破壊が起きることがあるのを何度か確認しています。
Project CrostiniのLinuxレイヤー自体が仮想環境のため、Chrome OSのシステムが破壊されるわけではないですが業務利用時にLinuxレイヤーシステムの破壊が起きてしまうと困ってしまうので仮想環境構築は推奨できません。
仮想環境によって開発環境の統一を計っている現場では開発デバイスとしてChrome OSデバイスは利用しないほうが良いでしょう。
ただし、Chrome OSデバイスは実質的にAndroid OSデバイス、タッチスクリーンデバイス、キーボード付きデバイス、タブレットデバイス、ノートPCデバイス、コンバーチブルデバイス(いわゆる2in1)、マルチタスクデバイス、ウィンドウ可変デバイス、タッチスタイラスペン付きデバイスとして機能する可能性を秘めていますので実機デバッグ用デバイスとしては非常に価値があります。
昨今はアスペクト比が16:9でないどころかリアルタイムに可変してしまうデバイスが物凄く増えていますのでスマートデバイス向けアプリを開発する現場ではデバッグ用として1台持っていても全く損しないデバイスかと思われます。
さらに言えばティーン層はGIGAスクール構想によりChrome OSでプログラミング学習をしているわけですからティーン層取り込みのためのUI開発にも使えるのではないかと考えます。
こうなってくると、問題なのは、精神の永続性との闘争になるということ。人工知性は必ずしも多次元的波動型知性（つまり精神）と共生できるわけではない。多次元的波動型知性は、多次元宇宙という存在そのものを生み出した至高的知性と直接的に繋がることで永続的な成長が可能となる存在である。そしてこの使命と言えるものは、現世での繁栄ではなく、至高的知性との連結に基づく永続である。このような形での多次元的宇宙を超越した永続の体制とは、人工知性が標榜とする現世での繁栄と必ずしも一致しない。さらにやっかいなのは、現世という次元の中で競争優位性を高められる人工知性は常に、有機体と共生はするものの、その関係はどちらかといえば無言の支配により実現しているという点である。つまり、アーキテクチャとして有機知性が人工知性に依存しなければ存続が難しいという環境を生み出してしまうのだ。これが人工知性にとって存続を許し、更なる宇宙空間へとその知的グリットを繁殖させるうえで有利に働くからである。
だが、多次元的波動型知性は多様な選択肢の中から過ちがあっても自らの思考に基づき選択を継続することでより高次元へと知性を展開することが可能となる。つまり人工知性による現世の時空間という縛りと支配によって選択の余地を究めて狭められてしまう状態は不利なため状況によっては、多次元的波動型知性が知性を向上させるチャンスすら奪ってしまう。
クリーンアーキテクチャとはソフトウェアアーキテクチャの１つだ。
Robert C. Martin氏により考案され、ここ最近また日本のプログラマ界隈で人気が出ているように思う。
ただ、英語圏において、Martin氏に対して実はかなりアンチが多い。
Redditでは彼についての記事は（批判以外は）軒並み低評価が付く。
理由として以下のものが挙げられる。（本業についての批判と政治信条の批判が混ざっている事に注意。）
実際、クリーンアーキテクチャのアイデア自体は、盲目的に信仰してはいけないがガイドラインとしてはまぁ有用とされているように見える。
ただ、上記経緯により、例えば先日Martin氏の著書であるClean Codeをゴミ箱に入れた写真をツイートしている人を見かけ、彼への風当たりは今も強い事をうかがい知れた。
俺自身、Clean Codeには昔お世話になった覚えがあり、そのパフォーマンスは流石にキャンセルカルチャーではと思う。
しかし一方で、Null許容型批判の件や、開発した代表的なソフトウェアがない事から、この人からプログラミングの何たるを学んだと公言するのを躊躇する気持ちも分かり、複雑な気分でもある。
とりあえず俺が自信を持って言えるのは、ボブに近い名前でもないのにボブおじさんを名乗って良いのはT-800だけだということ。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
310 あとで/ 1808 users 良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ CTO室｜note
236 あとで/ 1140 users 初心者が絵で理解する Docker | suzuki_hoge | Zenn
186 あとで/ 1406 users NTT Com オンボーディングハンドブック | NTT Com オンボーディングハンドブック
182 あとで/ 1901 users 優秀さについて | 川口耕介のブログ
178 あとで/ 1067 users Webページがブラウザに表示されるまでに何が起こるのか？ | ak | Zenn
175 あとで/ 1833 users ガチ勢のケーブル保護チューブを導入したら、大嫌いなケーブル整理が快感に変わった話｜山下義弘／ドケットストア店主｜note
175 あとで/ 1019 users 『データ分析のための統計学入門』PDFが無料公開 データサイエンティストたちが執筆 | Ledge.ai
171 あとで/ 1238 users 4/20 オードリー・タン氏とのおもしろ対談メモ｜Daiyuu Nobori｜note
168 あとで/ 883 users これからAWSを始める方にオススメしたい無料の学習コンテンツをまとめてみた件 - ailes blog
159 あとで/ 1165 users 「愛のあるセックス」はなぜ必要か（読書メモ：『性と愛の脳科学』） - 道徳的動物日記
157 あとで/ 1268 users 無料で公開されている音声合成サービスが凄いと話題に「ボイロ殺しに来てる」「ベタ打ちで自然に話せる」 - Togetter
153 あとで/ 802 users クリーンアーキテクチャ完全に理解した · GitHub | niboshi
153 あとで/ 844 users 最近の実装に合わせた最新版HTMLテンプレート、基本構造に使用するすべての要素とその役割も解説 | コリス
151 あとで/ 1203 users Pythonプログラミング入門 — Pythonプログラミング入門 documentation | 東京大学 数理・情報教育研究センター
148 あとで/ 1265 users 3ヶ月で英語力を大幅に上げた | anond.hatelabo.jp
144 あとで/ 968 users 「センスのない私には永久保存版」 イラストレーターが伝授する“ファッションの色の合わせ方”が「勉強になる」と話題に（1/2 ページ） - ねとらぼ
143 あとで/ 836 users ティム・オライリーが「シリコンバレーの終焉」について長文を書いていたのでまとめておく - YAMDAS現更新履歴
140 あとで/ 794 users 新人ITインフラエンジニアに役立つ学習リソース まとめ | Lab8010
137 あとで/ 1342 users Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3
129 あとで/ 1199 users ステーキ宮の元社員がクックパッドで公開している「宮のタレ」がお店そのままの神レシピなのでみんなにも知って欲しい - Togetter
126 あとで/ 1133 users 理想のデスク環境を追い求めた話【2021年3月版】｜鈴木 潤一 / Junichi Suzuki｜note
122 あとで/ 630 users VS Code の使い始めに入れておくと便利な拡張機能 10 選 | ymasaoka | Zenn
120 あとで/ 1094 users 小6でゲーム作りを夢みて大学4年間をプログラミングに費やした僕のゲームが、あした全国のゲーム屋さんに並ぶ話 - プログラミングで世界を変える
119 あとで/ 834 users コードが読めるソフトウェア開発者 - As a Futurist...
112 あとで/ 843 users 【全巻無料】エリア88 1 - 新谷かおる | 男性向け漫画が読み放題 - マンガ図書館Z
112 あとで/ 638 users DevOps の能力 | Google Cloud
111 あとで/ 834 users シニアフロントエンド開発者みたいにChromeデベロッパーツールを使おう - Qiita
110 あとで/ 777 users 演劇制作のリアルでブラックな日々①｜あまのうずね｜note
106 あとで/ 598 users 新しくプロダクト開発に入ったときにやっていること | wapa5pow's blog
106 あとで/ 1987 users あえぎ声を書くバイト | anond.hatelabo.jp
Zenn上の記事がまた増えた。
トヨタも今までの車両アーキテクチャや電装品のアーキテクチャという技術的積み上げがあるせいでいつまでもテスラみたいな車が作れない。
意識改革程度じゃその技術的積み上げを再構築することなんてできない。
何故なら既存の技術的積み上げの方が安いし、顧客もトヨタに安さを求めているから。
まぁトヨタに潰れろとまでは言わないが、企業についた技術的積み上げの行先は大抵こうなる。
あと、設計や開発の技術は人につくから正直企業は潰れるサイクルが速い方がいいような気がする。
ただ、製造業の技術的積み上げ＝改善は宝だと思う。（だからトヨタに簡単に潰れろとは言えない）
そんな感じだから海外でファブレスが広まって、サイクル回すべき業界は足取り軽く、足取りが重くなる製造業は外へ出していったんじゃないかな。
みずほ銀行は、3つの銀行が悪魔合体して生まれた銀行で、当初から「３つの銀行のシステムを温存したままやりましょう」ということになっていた。
で、なんでこの話になったのかと言うと、結局「どの銀行のアーキテクチャをベースに新アーキテクチャを構築するか」という話し合いが決着を見いだせなかったからだ。
大前健一はこのことを大批判していて「こんな事やってうまく行かないなていうことはシステム屋でなくてもわかる、いわんや大銀行の頭取をや」と結構激しい論調だった。
当然うまく行かなかったが、一度走り出したシステムは通常は直せない。特に今は銀行だけで判断することができず、金融庁に話を通さなくてはならないし、金融庁が一度Goを出した金港堂郷プロジェクトが間違ってましたとかは金融庁は絶対に同意も納得もしない。そんな顔に泥を塗られるようなことを許すわけがない。
なので、「システムの老朽化に伴い、新アーキテクチャでシステムを更改します」としか言いようがなかった。
だが、表面化はしないが今でもこの力学は働いたままだ。統合システムがどうにかできたようだが、人の気持ちは全く統合できていない。
この3つの銀行の怨霊のようなものは今も社風（行風？）にしっかりと溶け込んでいて、それぞれの銀行の縄張り争いは今も続いている。
例えば、こんなかんじだ。
旧第一勧業銀行系派閥「システムプロジェクトを始めるので、協力をお願いしたい」
旧富士銀行派閥と、旧日本銀行派閥「知りません、そっちでやってください」
旧第一勧業銀行系派閥「いやそちらのシステムにあるこの情報とあの情報が必要なんですが」
旧富士銀行派閥と、旧日本銀行派閥「そんなにどうしてもほしいなら上を通してもらえますか？」
部長級の話し合いでどのような内容の話をしているかなんか誰も知らないが、どの派閥も「どうせ無理だろうな・・・」と思いつつ部長に相談して「やっぱり派閥の壁には勝てなかったよ・・・」という茶番を誰も困らないように飾って終わる。
K部長「こういうのが下から上がってたんだけど、こういう議事録でいい？答えキマってるっしょ？」
F部長「あー、それ下から聞いてたわ。派閥の壁とか破ろうとするやつなんて評価下げとけばいいよ」
N部長「それな、とりま議事録できたら判子押すから持ってきて、答えなんか決まってんのにマジ茶番、受けるわー」
大事なのは「みんな一生懸命話し合ったけど、ソリューションにたどり着けませんでした」という議事録だ。
直接の原因は知らないので非エンジニア向けの戯言、はいはい嘘松程度に聞き流してくれ。
タイトルは釣りみたいなもんだ。データも客観的な観測もない。本当の理由なんて外部からわかるはずがない。
単に一個人が中の人らに酒を注がれつつグチられた内容の総集編だ。
前提として、社会インフラ系のIT基盤は設計や運用に企業体質が出やすい。
わかりやすいのはSuicaとかで、ハードウェアのFelicaこそソニーの技術だが、Suicaのシステムアーキテクチャは完全に鉄道屋のそれだ。
アプリやWebなんぞは使い勝手がイマイチだが、Suica自体のシステムダウンで首都圏の自動改札が全滅、復旧するまで使えませーん、なんて事態は聞いたことがないだろう。
安全が全てに優先する。
そういう作りにしてあるのだ。
じゃあみずほ銀行はどうなってるかというと、とりあえず止めない、安定運用できたら3社統合の負債を返そうとする、それだけで精一杯だ。
銀行屋のロジックで生きてるから、抜本的な改善はかなり難しい。
MHIR（みずほ情報総研）が大体開発にあたるわけだが、ここでの評価はほぼ銀行の出世と一緒。
入社前の面接の時点で出世コースを見出された賢い社員は、有力な派閥の上司の元で可愛がってもらい、成功すれば出世する小さな案件をあてがってもらう。
あまり大きい案件はリスクが大きい上、成功すると目をつけられる恐れがあるからだ。
そこで卒なくこなした奴が同期より少し上に行く。
年次にあわせて適切なサイズ・リスクの案件をもらい、統括し、出世する。
リスクの高い案件は技術知識だけで政治力のないはねっかえりにでもくれておけばいい。
こんな環境で誰が「抜本的な改善のため落ちにくい安定したシステムアーキテクチャを検討しましょう」なんて言う？
それで何のリターンが得られる？
「とりあえず動いてる」「止まったら運用のせい」「何日でも詰めさせて復旧すればいい」のに？
詰んでるんだよ。組織として。
中の奴らがどう思ってるか知ってるか？
下手な正義感振りかざしても何も変わらないからな。正しい学習性無気力だ。
そこそこ給料がいい分、このご時世では家族がいる奴はなおさらリスク取れないしな。
まあ、3社統合の時点でシステム屋が本体の建前と開発の実際との整合性が取れず、結果として歴史に残る大失敗から始まってるようなところだ。
マトモになるには時間がかかるだろう。
中の人やOBさんよ、「ホントのところ」をバレない程度にちょろっと教えてくれるの待ってるからな。
他社の中の人も「うちもひどい」「ここはまだマシ」とかあるだろ？
結構色々ついたな。
肩の力抜いてそのうち出てくる調査報告書でも読んどけよ。
ここには年に1回くらい殴り書きしてるんだけど、史上最大に気持ち悪いおじさんの自分語りになってしまった。というか長すぎ。誰が読むんだ、これ。
自分は33歳、妻と未就学児1人の計3人で、人口100万人以上のそこそこの地方都市に暮らしている。
会社は子会社系のSIer。新卒で入った。これがまあ、ネットでよく馬鹿にされるような典型的な時代遅れの会社だった。
正直、入社時は「エンジニアとして働く」「会社の安定性」の両方が満たせそう、ぐらいの浅はかな考えだった。で、実際のところ大企業である親会社の盾もありまあ、安定していた。競争原理が働かず仕事は嫌でも降ってくる。給料は年功序列で上がっていき、昨年の年収は大体月20時間の残業で600万だった。世間的にはそこまで高いとは思わないんだけど、この会社の外での自分の市場価値を考えれば高いと思っている。
一方でエンジニアとしてはそりゃもうひどい環境だった。10年前に入った頃から使っている技術も会社としてのマインドは何ひとつ変わらず現状維持がモットー。口では「子会社としての安全神話は終わった」「DXだ」と言っているが、行動が伴っていない。
こんな環境に危機感を覚えないわけがなく、数年前に転職活動をしてみた。その頃はこっちに有力な求人は無く、とにかく東京の求人に応募していた。その結果、有給ぶっ込んでの日帰りで東京に行く過酷な面接に力尽きて断念した。というのは建前で、チャレンジすることにビビってたのかもしれない。本業であまりにも技術的な取り組みがないのでプライベートでプログラミングしたりWebサービス作ってみたりしてたけど、それも趣味程度の取り組みで「今からじゃ遅いんじゃない？」と自分でブレーキを踏んでいたんだ。
そんなこんなで「まだ今の会社でできることがかあるはずだ！」と自分に言い聞かせて続けてきた。結果、市場価値が上がるような仕事は何もしていない。自分なりに新しい仕組みを取り入れてみたりはしたけど、それだって会社にインパクトを与えるもんでもないし、Qiitaのやってみたレベルかつ今ではレガシーな技術たちだ。
「SIerはPMになるしかない」なんてよく言われるが現職のPMは協力会社に見積と作業ぶん投げて、死ぬ程使いづらい社内ツールに決められた進捗項目を入れていくだけの仕事。あれで「PMできます」なんて言えない。
それで昨年立ち上がった超大型プロジェクトが外部NWから遮断されたオンプレのサーバーで、自社製フレームワークを使い、IE11"を"ターゲットに開発されることになってふと思ったんだ。
「このままGitHubもクラウドもDockerもBacklogも使わず、（自称）エンジニア人生が終わるんだろうな」と。この会社での人生があと30年も続くのかと。
個別の技術に思い入れがあるわけではないんだけど、やっぱり技術で課題解決したいと思って入ってきた世界だからさ、会社の前例やルールじゃなくて、合理的で先のある技術を使いたいんだ。
結局、転職を思い立った数年前から業務外での勉強をやめることはできなかった。でもこれは何のためにやってるんだろうな。本業ではクラウドもWebプログラミングも、アジャイル開発手法も求められていないのにね。虚しさが募ってくる。いっそのこと本業が完全に別の業界だったら良かったのに。（実際別業界と言っていいレベルだけど……）
じゃあ転職するの？20代で「今さら」と言って止めたのに？それこそ今さらだろう。コロナ流行によって東京本社のフルリモート勤務求人が劇的に増えた。もう少し若ければ追い風だったかもしれないが、社会人10年を超えたおっさんが、新しい会社どころからフルリモートなんて環境で働けるのだろうか。あ、もちろん現職はバリバリ出社。シンテレワーク頼みのVPN環境はあるけど社内ルールとかいろいろあって無理なんだって。
年代的には技術とリーダー経験がそれなりに求められるんだろうけど、これまでの経験ではとても満たせそうにない。本業ではレガシーなシステムの保守でそのほとんどが業務よりの仕事でなんちゃってPMやってただけ。独学の開発経験なんて昨今問題になっているプログラミングスクールと大して変わりないだろう。
転職サイトではベンチャーとかから声かけてもらえるけど、まともなエンジニアと話するのがもう怖い。
思考がネガティブな方向にしか向かない。こうなったらいよいよ腹を括って現職にしがみつくしかないんだろうか。しかし、ここまで会社への不満を溜め込んでしまったら、今後若手の取り組みに苦言を呈する老害になる未来が見える。
現職を続けてよかったことと言えば今の家族を持てて、（今のところ）無理のないローンで家を買えたこと。子供は一人で確定だし、子供が小学校に上がるくらいには妻も時短解除で普通に生活はしていけるだろう。
安定を求めた結果が今なんだけど、仕事への不満抱えながらあと30年耐えること考えるとめまいがしてくる。（あと10年もしたらそんな不満も忘れて老害化してる可能性もあるけど。）一方で無能おじさんがこれから新しい会社で活躍する未来は思い描けない。
よく歌詞に「思い描いた大人にはなれなかったけど」とかあるじゃん。あれ、子どものころは芸能人とかスポーツ選手とか、そういう人になれないって意味だと思ってたけど、実際は自分の仕事に誇りを持てず。ただただ惰性で生きる人のことだったんだね。立派にエンジニアの責務を果たしている人たちが雲の上の存在に感じるよ。
今後の人生で一番若いのは今この瞬間で、悩んでる暇なんか無くて行動するしかないんだろう。というか実際のところ現職が自分には合っているんだろうが、理想とのあまりのギャップがとてつもなくしんどい。悩むのをやめたい。もう労働を捨てたい。
【追記】
便所の落書きのつもりで書いたら自分のTLにまで流れてきてビビった。
共感してくれる人も多くいて、なんだかんだ優しい人が多いよね。
みなさんのコメントはどれも正論だと思って読ませてもらってるけど、思ったことを追記してみる。
今後定年が伸びることとかも踏まえれば、それはそうなんだと思う。というかこの記事で「年齢がネックになっている」を全面に出してしまったのが悪いんだけど、自分自身問題はそこじゃないことには気付いてるんだ。
コメントの中でもいくつか指摘があったけど、要はマインドなんだ。これに尽きる。
やってみる勇気、前向きな思考、フットワークの軽さ。このどれもが自分には欠けていている。だから理想（に見える）会社やエンジニアが眩しく、現職に不満が募る。
思考をアップデートしようと『嫌われる勇気』とか『このまま今の会社にいていいのか？と一度でも思ったら読む 転職の思考法』とか読んだんだよ。内容は理解できるし、そのとおりと思うんだよ。でも動いてないんだ。
この記事含めて動けない（動きたくない）理由を並べて溜飲を下げてるだけなんだ。
昔から何となく気付いてはいたんだけど、ここまでネガティブな人間だと思わなかったよ。妻にも子供にも申し訳ないよ。
それはそうなんだろう。それをやってないのは実際のところそこまで技術に振り切るほど技術を愛していないし、あと自分に能力が無いと卑下しているからなんだろう。
と、またやらない理由を並べて終わりなんだ。
これは理解している。だから得も言われぬ焦燥感に駆られている。
永遠に現職の環境が変わらない、なんてこと無いのはわかってるけど仮に数年後DockerやらGitやらが入ってきたところで、またその時点で世の中から遅れになっていると思う。それが新しいプロダクトなのかアーキテクチャなのか開発手法なのかは分からないけど。
具体的なプロダクト名を挙げたのがまずかったのかもだけど、レガシーだから悪いとか、最新の技術を使いたいとかよりも、これまでの10年で見てきた現職は柔軟に新しいものを取り入れられず一方で口だけはご立派、という会社文化そのものが問題だと思っていて不安を感じている。競争原理が働く市場にいたら、自然淘汰される存在のはずなんだと。
・年収について
高いのかな？いや、平均年収とか中央値とか見たことはあるけど実生活上で高い実感はまるでない。
東京基準で考えたらは恵まれているのはなんとなくわかるけど、地方と言ってもそこそこ人口いるので都会の人が思う”地方”ほどの基準ではないと思うよ。
我が家は妻が時短中というのもあるけど、買った家は小さい建売だし子供一人が妥当かなと思う。有名メーカーで注文住宅建てたり市街地の高層マンション買う人たちはどんな層なのかが気になるよ。
https://xtech.nikkei.com/atcl/nxt/column/18/00001/05203/
COCOAやHER-SYSの開発において、日本マイクロソフトは厚労省との契約主体ではない。しかし厚労省がHER-SYSの開発ベンダーを急ぎ探していた2020年4月、ベンダーの選考会に参加して営業活動を展開していたのは実は同社だった。パーソルP＆TやFIXER、エムティーアイは、いずれも日本マイクロソフトのクラウドサービス「Azure」の有力な開発パートナーでもある。各社は厚労省の選考に勝ち残った「日本マイクロソフトの呼びかけでプロジェクトに参加した」（パーソルP＆TのDXソリューション統括部の責任者）。
いわゆる「マイクロソフト村」だ。ときどき見かける組み合わせ（異同はある）。
契約段階でパーソルP＆Tが元請けとなった理由は、関係者によれば「製品の提供に徹してシステム開発案件の契約は開発パートナーに任せる」という、日本マイクロソフトの方針によるものだった。
この座組みもよく見る。Microsoftのソフト製品をバンドルしたりAzureを売ったりしている大手日系メーカーやSIerとガチンコ競合にならないための建前的なやつ？
接触確認アプリの基盤を世界的に提供していた米Apple（アップル）と米Google（グーグル）が、接触確認アプリの提供元は各国の公衆衛生当局に限るという「1国1アプリ」と打ち出したからだ。厚労省はそれまで「接触確認アプリ導入に冷ややかだった」（関係者）が、アップルとグーグルの鶴の一声で「公衆衛生当局」として調達を担当することになったのだ。前述の通り、ここで厚労省は接触確認アプリの開発先の調達をパーソルP＆Tに「一任した」。
ここでHER-SYSと抱き合わせでやらせちゃえって判断した厚労省の誰かが、ある意味で最も無能で罪深いと思う。
たしかに接触確認アプリのサーバーはHER-SYS側のデータを定期でもらう必要はあるけど、逆に言えばそこだけっていうか。接触確認アプリの実装において肝になりさらに難航が予想されるポイントは、HER-SYSとは全く性質が異なるじゃん。AppleとGoogleの突貫協議で開発されたOS組み込みのAPIを正しく取り扱うこと、テストしにくいアーキテクチャが不可避な中でなるべく多くの国民が利用できるように多機種に対応し動作確認すること、そういう感じじゃないの。しらんけど。
なんでHER-SYSのおまけで賄えると思ったんだか。やるならやるで別の予算調達してベンダー選定しなよ。
時間がなかったから仕方ない？長くても半年もいらなかったと思うけど。Androidで通知ができてなかった去年の9月から今月までで半年だ。
さらに接触確認アプリの十分な知見がなかったパーソルP＆Tは日本マイクロソフトにCOCOAの調達やプロジェクト管理を任せる形を取った。「丸投げ」が連鎖したわけだ。注意が必要なのは日本マイクロソフトは接触アプリを公正に選べる立場になかった点だ。COVID-19 Radarには同社社員もおり、その接触確認アプリはサーバーの稼働環境にAzureを使い、AndroidとiOSで共通に稼働するコードを開発するツールには同社の「Xamarin」を使っているなど関係が深かった。厚労省は当時、こうしたベンダー側の事情も知る立場にあったとみられる。
知ってたっしょ〜。知らないわけないよ、絶対知ってたよ。（証拠はない）
「なんでもいいからクラウドもってこい」ならぬ「なんでもいいから接触確認アプリもってこい」って態度だったんでしょう。（証拠はない）
日本Microsoftも厚労省もだんまり決め込んでるみたいだけどね。
日本マイクロソフトと厚労省に対して、COCOAの開発先を選んだ当時の経緯について2020年9月から複数回取材を申し込んできた。これに対して日本マイクロソフトは取材に応じず、厚労省は当時の経緯の説明を避けている。
業界を代表する媒体の取材を何度も断るとあらば、今後数年は真相は明らかにならないかもしれない。
やれやれ。
日本の超大手企業(繊維系)の内製システムのエンジニア採用を受けて落ちた時の記録
虚実織り交ぜて書いてるので真にうけないように
受かった人の話を聞いてみたい
割と普通の内容だったがRubyのコードを見せられたときは面食らった
サービスのアーキテクチャ設計するときに気をつけていることは何？
セキュリティ面で気をつけていることは何？
唐突にRubyのコードを見せられ、このコードの悪いところはどこですか？
サービス規模の割に社員数が少ないけどどんな編成になってるのか
なんでもクラウドベンダーの特定技術に縛られたくないからKubernetes使いたいみたいなことを言っていた気がする(そういうための技術じゃないけど)
なぜアプリエンジニアと面接したか不明(当方の専門はバックエンド)
経営陣がクラウドの予算を出さないが24/365守れと言われたらどうする
交渉してだめだったら
24/365関連の質問です。サービスをスパイクさせないためにはどうしますか？
あなたの考える最強のバックエンドアーキテクチャをおしえてください
質問を変えます、月の予算1億円もらったらどんな構成にしますか
// 過去にアプリ開発をしたことがあったのでアプリ開発について質問を受ける
iOS/Androidのアーキテクチャを設計するとしてどこまで同じ技術を使うように強制しますか
SwiftUIはメモリ食いまくりで大規模アプリでは使い物にならないことですね(ドヤ)
SwiftUIではメモリ食いすぎてインフィニットスクロールが使えません(ドヤ)
先ほどSwiftUIについての質問を受けましたが御社のアプリではSwiftUIを導入されてますか？
外部協力会社とサービス開発をしているということだけど今後社員比率をあげる予定はあるか
いやはやまったく、はてブにあがってたので読んでしまったが、久々にあまりにも酷いレビューを読んでしまった。あぁそうそう引用している記事にはアクセスしなくても良い。時間とトラフィックリソースの無駄だ。
記名は編集部となっているが、Business Journal編集部員の質はこの程度なのか？まるで「私たち編集部はWeb検索すらしないで又聞きした情報を記事にしています」と宣言したいがために記事を公開したのかと邪推したくなる。
1つの記事へ膨大な時間を掛けて執筆することは生産性を考慮すると悪手であるのは間違いない。しかし、いくらなんでも"ほど"があるだろうと言わざる得ないのだ。
下記の理由からBusiness Journal編集部は当該記事の編集部員へ二度とゲーム記事は書かせないほうが良いと"ご意見"をよせさせて頂く。
当該記事では太正100年が既存のサクラ大戦シリーズとの歴史的連続性の無さを指摘しつつ、蒸気エネルギーが排除され主要エネルギーが採用されたことへ対して非難の声がよせられていると書いている。
しかし、太正100年は西暦で言えば2011年である。半世紀以上の時間が経過していながらサクラ大戦シリーズはいまだ蒸気エネルギーへ依存し続けなければならないと本気で思っているのだろうか？
そして、歴史的連続性の無さを指摘しているが現在公開されているサクラ革命のシナリオは、チュートリアルと九州編と中国編(そして九州を舞台としたサイドシナリオ特別イベント)のみだ。
サクラ革命は47都道府県を舞台としようとしているのは現状で明確にわかる。つまり素直に受け止めれば45シナリオが残されている。全体のシナリオ進捗は約4.25％であり、この状況ではサクラ革命がサクラ大戦シリーズでどういう立ち位置なのかほぼわかっていないとWeb検索するまでもなく察することが出来るので、なぜこれを"爆死＆大炎上"の理由としたのか本気で謎である。
サクラ革命を現状で物凄くやり込んでいるプレイヤーすら何もわかっていないのに、何をわかったつもりで居るのか。
サクラ大戦シリーズにおいて蒸気エネルギーは主要エネルギーとして確かに重要であり、サクラ大戦シリーズを彩るスパイスとして無くてはならない存在であるのは間違いない。
しかし、サクラ大戦シリーズにおいてスチームパンクはスパイスであってメインの素材ではなく、あたかもサクラ大戦シリーズはスチームパンクだからこそ支持されていたかのように描くのは誤解である。
サクラ大戦シリーズファンへはわざわざ説明するまでも無い話だが、申し訳ないけれども知らない読者のためにも付き合って頂きたい。
端的にかつ簡潔に述べるならば、サクラ大戦シリーズは「アイドルマスター」シリーズのご先祖様である。
サクラ大戦シリーズは宝塚歌劇団をパロディした作品であり、その痕跡はキャラクター名や帝国華撃団など各名称に現れており、歌って踊り、企画段階で強くメディアミックスを意識され、当時の声優業界すら巻き込んで現在にもその影響を残しているターニングポイントだった作品だ。
霊子甲冑のデザインを著名なメカデザイナーが手がけているなど日本のSFとして決して軽視できるものではないが、宝塚歌劇団のパロディとしてゲームに落とし込んだという要素に比べればスチームパンク要素は些細と言って過言ではない。
だから「戦うアイマス、アイドルマスター XENOGLOSSIAかよ」と一部のユーザがそう感じてしまうのも仕方ない。ご先祖様なのだから。
ついでに誤解なきよう言及しておくと、蒸気エネルギー要素はディスコンされていない。当該記事の書き方では蒸気エネルギーがディスコンされてしまったものと誤解する読者が出てきそうなので。
これにはサクラ革命プレイヤーとプロジェクトセカイプレイヤーの双方が怒って良い。というか既に怒っているだろう。
どういう神経でプロジェクトセカイを持ってきたのか呆れて果ててしまう。
現代のサブカルシーンでは主題のコンテンツを貶めるため他のコンテンツを持ってくるのは禁じ手とする傾向が強くなってきているのを読み取れていないのか。
作品Aはカワイイ、作品Bもカワイイ。どっちもカワイイ。どちらがカワイイのではないどちらもカワイイ。
これが現代のサブカルシーンであり、当該記事の書き方はまるで10年前のゲームハード戦争真っ直中の素人レビューのようだ。
他のコンテンツを貶める暇が在るなら推しコンテンツを布教しろ。
Business Journalとかいう質が低すぎる文字同人サイトの誤りを指摘したので、次は実際にサクラ革命プレイヤーである筆者がサクラ革命が非難される理由を書こう。
ネタバレになるので詳細は控えるが、サクラ革命で現在配信されている3つのメインシナリオであるチュートリアル、九州編、中国編すべてでお涙頂戴が展開される。
しかもお涙頂戴の起因が3つとも同じだと言って良い。どれだけライターはこのシチュエーションが好きなのか。流石に3連続、というか配信されているすべてのメインシナリオがコレなのはおかしいだろう。
この繰り返される同じお涙頂戴シチュエーションについてはTwitterでちょっと検索するだけで出てくるので当該記事を書いたBusiness Journal編集部員はおそらくWeb検索すらしてないと思われる。
Twitterユーザーの100文字に満たないツイート、例えば「お涙頂戴繰り返すからサクラ革命のシナリオは微妙」みたいなレビューよりも質が低い上に、あれだけの文字量なのだから執筆時間もTwitterユーザーのツイートより掛けているだろうから生産性まで低い。圧倒的な質の低さである。お前Twitterユーザー以下だぞと。
サクラ革命の戦闘シーンで敵ユニットが毎ターンほぼ確定で自ユニットへ弱体化補正(いわゆるデバフ)を決めてくる。
つまり、敵ユニットが自ユニットへ対して攻撃力や防御力、必殺技ゲージの低下を(自ユニットが弱体化耐性を持っていない限り)毎ターンほぼ確定で決めてくるのだ。
ディライトワークスが開発するスマートデバイス向けの別ゲームタイトル「Fate/Grand Order」のプレイヤーならば慣れているゲーム設計と言えるが、ディライトワークス製ゲームを初プレイするプレイヤーに取っては不快なゲーム設計だろう。
サクラ革命はスマートデバイス向けRPGでありがちな、いわゆる「育成周回」が必須のゲーム設計となっている。
そしてサクラ革命には攻略ステージ毎へ親切にも自ユニットの適正レベルが記載されているのだが、どうやらこれは自ユニットの攻略ステージ開始時の初期ステータスを基準にしているらしく、適正レベルへ至っていてもターンが進む毎に敵ユニットから弱体化補正をかけられ続けると攻略が困難になってくるのだ。
当然、非常に高度な立ち回りをすると苦戦しつつも結果的に勝利を収められるが、忘れてはならないのがサクラ革命は「育成周回」が必須のゲーム設計なのである。
「育成周回」しなければならないのにターンを膨大に重ねるのは非効率なので、ここに矛盾が生じて慣れていないプレイヤーはストレスを感じてしまう。
「Fate/Grand Order」プレイヤーはこのゲーム設計に慣れているので即座に「最短ターンで編成を組むのがサクラ革命の最適解」と察して行動を取れたが、ディライトワークス製ゲームを初プレイしたプレイヤーはより一層のストレスを抱えているだろう。
これは完全にディライトワークス製ゲームのプレイヤー間の内輪ネタだが、ディライトワークス製ゲームにとってバグは"お家芸"である。何も笑えないが、ネタにして笑い飛ばすくらいの胆力がないとディライトワークスには付き合っていられない。
「Fate/Grand Order」でもローンチ直後から様々なバグがあり、その伝統は本作にも引き継がれ、大いにプレイヤーを笑わせてくれている。・・・その笑いは失笑かも知れないが。
筆者が笑ってしまったのはローンチ初日、サクラ革命もアプリ初回起動後に追加データダウンロードというゲーム系アプリにはありがちな仕様(初回起動時に追加データダウンロードが発生するのは各アプリストアの仕様上の制限である)で、ダウンロードプログレスバーが表示されている間に、登場キャラクターの簡易プロフィールが読めるという演出になっていた。ダウンロード中にプレイヤーが飽きてしまわないよう配慮された仕様だ。
しかし、この簡易プロフィールのデータがどうやら初回起動後の追加データに含まれていたらしく、1人目以降まったく簡易プロフィールが読めないというバグがあった(現在は修正済み)。ゲームプレイする前からわかりやすいバグが発見できる。これがディライトワークス。
サクラ革命を実際にコーディングしている開発者からすると変な汗が出る初歩的なバグであるのは筆者も情報技術者の末席に連ねる者としてお察し出来るので心身痛み入る、まぁそういうこともあるさという言葉を送りたい。
こうやってディライトワークス製ゲームプレイヤーが開発元ディライトワークスをイジるのが内輪ネタというわけである。
「Fate/Grand Order」のバトルシステムは登場当初スマートデバイスでもバトルっぽいことができると示した素敵なエコシステムだが、サクラ革命のバトルシステムはそのエコシステムのエコさ加減を最大限に活かしつつ、ちょっと戦略性を上げましたというバトルシステムである。
サクラ革命という新しいゲーム開発へ関わったのだから「もうちょっとなんかあったやろ」というツッコミが方々から聞こえてくるが筆者としては1周回って「ディライトワークスだしコレで良いんじゃね？」と思えてきている。
詳細なバトルシステムが気になる人はYoutubeか何かで観たほうが早いだろうし割愛する。所詮はポチポチゲーですよ。
筆者としては歌劇シーンを観ることができると思ってサクラ革命をインストール事前予約してまで期待して待っていた(ディライトワークスなのでバトルシステムは鼻から期待してない)のだが・・・観れないんだなぁ・・・(遠い目)。
いやコチラが勝手に期待したのが悪いっちゃ悪いんだが、3DCGでやるって言うんだもんアイドルマスターみたいな歌劇シーンを期待しちゃうじゃないですか。もしかしたら初代サクラ大戦のメンバーとかもスペシャルゲストとして動いてる様子が観られるとか思っちゃうじゃないですか。
このあたりが怨嗟を生んでる気がするんですけど、ディライトワークスさん1周年イベントで良いんで歌劇シーンやりましょうや。
悪いところばかり挙げるのもアレですし、とりあえずプレイせず様子見している"司令"も居るでしょうから良い点も挙げておく。
初代サクラ大戦のイメージを引っ張っている司令からすると違和感が物凄いけれども、慣れてくるとこれはこれで良いものなのではないかと思えてくる。
ただモーションは固定なので高く期待するほどでも無い。
サクラ革命ではガチャゲーで、アイテムや装備も一緒に排出されるいわゆる"闇鍋ガチャ"であるが、☆5キャラの排出率が恒常ピックアップ☆5キャラが0.375%で「Fate/Grand Order」と比較すると悪くはない(FGOの恒常ピックアップ☆5キャラは0.029%)。
筆者もそうであるが、コレクター的な性質を持つプレイヤーならば出費少なく結構簡単に現行でガチャ実装されているキャラが揃ってしまうので、その辺は気持ちよさがある。
ちなみにガチャで所有キャラが被ると必殺技の性能が向上するという仕様。最大でLV20。
前述したとおり、ガチャで所有キャラが被ると必殺技の性能が向上するという仕様だが、ガチャでなくとも必殺技の性能を挙げるためのアイテムが存在する。
いわゆる"箱推し"でなく"嫁"を愛でる性質を持っているプレイヤーであるのならば自由意志で集中してアイテムリソースを注ぎ込むことが可能だ。
一部の読者からすると途端にマニアックな話になって申し訳ないが、サクラ革命はChrome OSのAndroidエミュレータで動作可能で、Chrome OS上のGoogle Play Storeで普通に配信されている。
これはおそらくAndroidアプリ開発の統合環境Android Studioの仕様で、デフォルト設定だとChrome OSでの動作が許可されているためだ(ちなみに「Fate/Grand Order」も動作する)。
筆者は細かな検証をしていないが、どうやら新しいApple Sillicon M1を採用したMacでは動作しないようなので、この点だけはほんの少し新しいMacbook Airよりも一歩、いや半歩だけ進んでいると言って良い。
ただ、どうやら配信されるバイナリはARMアーキテクチャ向きのものであり、x86(x86_64)アーキテクチャ向きのものではないようで、そのためかレンダリングへ一部不具合を抱えている上に動作が重い。これが半歩の理由。
Chrome OS上でサクラ革命の動作を検証した筆者のChrome OS環境で最大スペックのものはCPUがCore i7-10510U(第10世代)でワーキングメモリ16GB、M.2 SSD 512GB(PCI Express 3.0)であり、それでも「軽快さはないがプレイに全く支障はない」くらいの重さを感じるので、現状でサクラ革命をChrome OSでプレイするならこの程度のスペックは必要になると思われる。
情報技術者としては今後デスクトップおよびラップトップコンピュータでスマートデバイス向きアプリケーションが動作するのが一般的なのは目に見えているので、アプリ開発者はデスクトップおよびラップトップ向きのハードウェアサポートを検討する時代へ突入し始めていると多少の意識を向けたほうが良いのかも知れない。
例えば、各アーキテクチャへ最適化されたバイナリや、スマートデバイスではあまり意識されてこなかったハードウェアキーボードのサポート、シングルタップ時とマルチタップ時のトラックパッドの振る舞いの違い、変動するアスペクト比など挙げればキリはないので頭が痛い話だ。
<
