  |
はてなキーワード: ミドルウェアとは
まずは、日立のサーバーでのWindows Server 2022への対応からお聞きした。
木村： サーバーにはHA8000VとRV3000の2ラインアップがあります。HA8000VがPCサーバーで、汎用的なサーバーとして、エントリー向けや、HCI、VDIのソリューションなど、いろいろな用途で使われています。RV3000はミッションクリティカル向けです。Windows Server 2022のプレインストール対応は、HA8000Vの全機種で2022年5月を予定しています。
Windowsサーバー市場における日立の強みとして、木村氏は、サポート力を挙げる。
木村： 日立は長年に渡ってプラットフォーム製品の開発を行ってきました。作ってきたからこそ、中身がわかっている技術力があります。できることとできないことを技術者がわかっているので、障害が起きたときや問い合わせのときに、お客様に事実を真摯に伝え、重大な不具合があっても技術力で解決に向けていきます。何かあったときに問題をたらい回しにせず、技術力をコアにしてしっかり対応するサポート力が強みです。
こうした日立のDNAを結実させたサポート商品が「日立サポート360」だ。通常はサーバーのハードウェアからOS、ソフトウェアなどは、それぞれと契約し、サポートを受けることになる。日立サポート360ではこれらをワンストップで受け付け、支援することができる。
広瀬： 窓口が1つになるというのは他社でもありますが、そういう表面的な話だけではなく、複合的な力で問題解決支援にあたれるのが真の価値です。内部で、サーバーからOS、日立ミドルウェア、導入ミドルウェアなど、いろいろな製品の部門の連携がすごく濃密にされているからこそ、複合的な力で問題解決にあたれます。これが本当のワンストップの意味です。
この日立サポート360でWindows Server 2022のサポートにも対応する。日立では、長年のサポート実績により蓄積された技術力により高い自社解決率を誇るという。自社解決率が高ければ、それだけパートナーへのエスカレーションが減るわけで、短期間でのトラブル解決が期待できることになる。
日立のハイブリッドクラウドのソリューション「EverFlex from Hitachi」
木村氏は、日立のハイブリッドクラウド戦略としてEverFlex from Hitachi (以下、EverFlex)ソリューションを説明した。EverFlexは2021年10月にクラウドとのデータ連携ソリューションとして始まり、2022年2月にハイブリッドクラウドのソリューションとして強化された。
木村： お客様がオンプレミスとパブリッククラウドを使うときに、最適なシステム設計にして、コストも最適化していきます。ハイブリッドクラウドの導入には事前にアセスメントやコンサルティングを行うことが大切です。なぜなら、パブリッククラウドを導入することで負担が減るかと思われがちなのですが、ハイブリッド化されることで負担が増えることがあるからです。
EverFlexの特徴の中でも特に「クラウドライクなサービス提供」について木村氏は紹介した。
木村： ハイブリッドクラウドになると保守や運用が煩雑になります。パブリッククラウドとオンプレミスの両方を管理しなくてはならないため、システム管理において両方のノウハウが必要になります。このため保守・運用フェーズにおいて簡単化されずコスト最適化が課題となってきます。それを避けるために、共通化するニーズに応えるようにいろいろと工夫しています。
ハイブリッドクラウドソリューションEverFlex from Hitachi
まず、問い合わせをワンストップ化したり、運用管理を1つのツールで一元化したりすることで、顧客の負担を軽減する。
プラットフォームにおいては、オンプレミスからクラウド接続を可能にしてシームレスにお互いやりとりできるOSが各社ある。Windows Server 2022はまさにそれを特徴としており、同じくAzure Stack HCIも選択肢に入る。
さらに、支払い／利用形態についても、オンプレミスでも売り切りだけでなくフィー型も採用する。こうしたEverFlexの中でWindows Server 2022のユースケースを木村氏は2つ挙げた。
1つめは、運用管理の簡単化の部分で、Azure Portalからオンプレミスを管理できる機能の強化だ。
木村： オンプレミスにエージェントを入れておけば、管理者がAzure Portalだけをさわって、オンプレミスのリソースやイベントの管理も全て一元化できます。これに期待しています。
もう1つはセキュリティの強化だ。
木村： ハイブリッド化が進むと、両方の基盤をネットワークで接続することになります。従来には存在していなかった接続となるため、その部分でセキュリティの強化も進めなければなりません。そこでWindows Server 2022では、Secured-core ServerによってOSそのもののセキュリティレベルが上がっています。TPMと連動する機能によってハードからOSのレイヤーを守り、マルチレイヤーでセキュリティを強化しています。
そのほかにもクラウドライクの取り組みとして2つを木村氏は紹介した。
1つめは「サーバ予備リソース提供サービス」。サーバーを余分に設置し、支払いは電源を入れて使った月だけ発生するというサービスだ。
木村： 迅速でタイムリーにリソースを増強したいときに、クラウドなら自由に構成を変えられます。それをオンプレミスでもできるようにします。クラウドではインスタンス単位となり、ハードウェアの構成はメニューの中から選択することになりますが、オンプレミスでは構成を自由に組む事ができます。まずHCIソリューションから開始しましたが、2022年4月からはそれ以外にも拡大する予定です。
もう1つが「ハードウェア安定稼働支援サービス」。オンプレミス環境のサーバー運用管理を省力化するものだ。
木村： 旧来の保守では、ファームウェアのバージョンアップがあると、技術的にどういう影響があるかを確認して、その都度適用するかどうかを判断する必要がありました。それを提供元が判断するのがこのサービスです。お客様の機器を弊社で管理して、ファームウェアの推奨バージョンの選定や、更新作業などを一括でやります。
サブスクリプションに力を入れる
日立のこれからの注力分野について木村氏は、サブスクリプションに力を入れていくと語った。
木村： 全社的な方針で、サブスクリプションに力を入れていきます。クラウド化で初期投資をおさえるニーズと同時に、オンプレミスも求められています。そうしたお客様のニーズにアラインしていきます。
サブスクリプションやクラウドライクなサービスで管理を簡単にして顧客企業がコストを抑えることで、究極的な目的はその先のDXだと木村氏は語る。
木村： 既存のプラットフォームのコストを最適化させ、浮かせた費用を新たな投資先として、AIやEdgeを活用する新たなデジタルソリューションの領域に向けていくことを支援していきたいと考えています。
そのために木村氏は、よりハイブリッドで使いやすいようなライセンス体系をマイクロソフトに期待している。
木村： 今後ハイブリッド化が進むと、繁忙期にリソースを拡張するといったこともあります。そのときにライセンスが、オンプレミスはオンプレミスで買って、AzureはAzureで課金してと、ハイブリッドで使いづらい体系になっています。将来的にライセンス体系を統一するなど、両方の基盤で使えるような体系になることを期待しています。
また、Azure Portalからオンプレミスを管理できる機能についても、さらなる強化を木村氏は期待する。
木村： Azure Portalからは管理できる範囲に限りがあります。OSから上のリソースやイベントは監視できるのですが、ハードウェアの死活監視や電源管理などは対応していないため、JP1やその他のツールなど、複数のツールを使いこなす必要があります。それらの管理ツールが乱立してしまうと、また管理の手間が増えてしまう。こういったことをオンプレのツールか、Portal側で統一することも期待したいところです。
黎明期当時の技術に対してドコモの要求が多く、かえって足枷になったことはあながち間違いでは無いし、ハードウェア構成の変なこだわりもあったと思う。
1つは、少なくとも今までの日本向け端末で採用され続けているチップセット（主にQualcomm Snapdragon）が、モデム部分を除いた処理能力でAppleから何周か遅れているようなものばかりである（特にGeekbenchのComputeスコアはVulkanを利用しても悲惨な結果ばかり）。
たとえ同じアプリをリリースしても、同じ価格帯の携帯電話なのに体感速度で明らかに劣ると言うことがよく起きている。ゲームで顕著だ。
偉大なるUnity（IL2CPP）やCRIなどのミドルウェアのおかげで、ある程度は演算や音声再生能力の差が吸収されるようになったとはいえ、3D描画APIがOpenGLESからMetal/Vulkanに移行したために描画性能の差が余計に広がってしまった。
純粋にチップセットメーカーの技術力の問題もあるが、視覚で訴えかけるゲームのパフォーマンスで差がついてしまった以上Appleのプラットフォームを選ぶ人は減らないだろう。
おそらく、まともなデベロッパーであれば、できる限り理想を実現しやすいプラットフォームを選ぶので、既に普及率が高いうえパワーに余裕のあるiPhoneを基準にアプリを作る。後はわかるな？
2つ目は、一時期流行を見せたいわゆる「格安スマホ」すなわちローエンド端末（エントリー機）の存在だ。
これは、（非常に少ないが）特にこれからスマホを使い始めるという人には非常におすすめできないし、型落ちハイエンドスマホからの買い換えもやめておくべきだ。
自分含め、購入する際には安くてもスマートフォンだと思っているので、あのアプリを入れよう、あのサービスも使ってみようなどと期待して操作をするが、スマートフォンとしてのメリットをほとんど享受できない場合がある。処理能力やストレージが全く足りないからだ。
iPhoneの場合、概ね処理能力を差別化していない（廉価グレードのSEは存在するが中身は「型落ちハイエンド」）のでどれを選んでもそれなりには動いてくれるが、「格安スマホ」は最新機種でもチップセットメーカーがコストを下げるために処理能力をかなり抑えて差別化を図っているので悲惨である。
ようやくSnapdragon 480 5Gで一気に底上げされたが、少なくとも日本市場に関してはもう手遅れだと思う。
また、スピーカーやディスプレイ、カメラなどの部材も必然的にグレードが低いものを用いるので、型落ちハイエンドスマホより体験が劣ることもあり得る。
パソコン同様、初心者に安物を買わせてはいけないのである。売り方をもう少し考慮して欲しい。
以上のように問題はたくさん抱えているが、辛うじてAndroidというプラットフォームには救いがある。
オープンだという点。
x86-64のパソコンさえあれば開発環境が無償で使用可能で、作ったアプリはサイドロードができるのでストアなどに登録しなくても配布できる。
自力で機能を実装して、ちょっとした不便や問題を解決していく強い意志を持てるならば、どんどんAndroidを使うべきだと思う。
理想としては、Android StudioやFlutterなどの開発環境がAndroid上で走るようになれば、敷居も下がってコミュニティも活発になるだろう（なってほしい）。
2019年12月に文部科学省が打ち出した「GIGAスクール構想」。これは教育のIT化に向け、1人1台の端末環境を実現するという構想だ。当初は23年度までに整備を行う予定だったが、新型コロナウイルス感染症の感染拡大による自宅学習の需要から20年度中へ前倒しになった。
21年度に入ってすでに4カ月たつが、教育の現場はどう変わったのか。現職の教員から校長、教育委員会、有識者などさまざまな視点から現状を探ってみた。
GIGAスクール構想の中で子供の学習用端末として配られたのは、Windows搭載PC、Chromebook、iPadのいずれか。OSや機種の選定は各自治体の教育委員会が行った。学校ではそれらの端末を使ってさまざまな授業が行われている。
東京都内でChromebookを使う小学校に勤務する鈴木教員（仮名）は、画面に自由に文字や図を書けるデジタルホワイトボードを活用。「子供たちがホワイトボードに書いた意見を共有して、全員が同時に見られるようにしました」（鈴木教員）と話す。その結果、今までは授業で発言しなかった子が自分の意見を出すようになるという効果が生まれた。
鈴木教員は今後、デジタルホワイトボード経由で他校と交流する授業もやってみたいと期待を膨らませる。将来的には、遠方に住む人に授業してもらったり、他国の子供たちと交流したりできるだろう。
ある小学校の校長は「ITが得意な教員は今まではそんなに目立ちませんでした。でも今では子供にも他の教師にも頼られて大活躍しています」と話す。今まではITスキルが高くてもそれを生かせる場面がなかったのだ。
子供の方でも同じことが起きている。「発表資料に動画を使いたいという子が出てきたとき、もともとPCが得意だったインドア派の子供が教えてあげる場面があります」という話を複数の教員から耳にした。
教育面ではメリットもあるが、困りごともたくさんある。学校が苦慮していることの一つに、家庭への端末の持ち帰り問題がある。持ち帰りが始まっている学校ではトラブルも続出している。よくあるのが「子供がYouTubeを見るようになって困る」という保護者からの苦情だ。
「アダルトサイトなどはフィルターがかかっていますが、YouTubeやゲームは制限がなく、学校の方で閲覧を止められません。学校ではもちろん『必要以上に見てはいけない』と指導していますが、家の中のことは……。家庭のことは家庭で対応してほしいというのが正直なところです」と都内の小学校教師はこぼす。
端末の破損も課題だ。公立校の教師経験もある情報通信総合研究所・特別研究員の平井聡一郎氏によると端末の保険料が問題になっているという。
自治体によっては、端末を家に持ち帰って故障させた場合は、過失・故意問わず保護者負担とするところもある。
「しかし、そもそも破損時のための保険を付けていなかった自治体の方に問題があります。リースなら保険が付いていますが、端末にかかる費用を安くするために買い取りにしたのではないでしょうか」（平井氏）
子供の通う自治体が保険料を払ったか否かで、家庭の負担が大きく変わるリスクが生じるというのは、保護者の立場なら納得いかないのも無理はないだろう。
また、自宅の通信環境も問題になっている。家庭の通信状況は学校で把握できないため「通信できなかったから宿題ができなかった」といったことも起きる。
夏休み明け以降に端末の持ち帰りが始まる学校も多く、教師は戦々恐々だ。端末の持ち帰りについては、まだまだ試行錯誤が続きそうだ。
今回の取材で教師から最も多く聞こえてきた困りごとは「学習のためのアプリが子供たちの端末に入っていないこと」だった。
GIGAスクール構想で子供の学習用端末の購入に充てられた補助金は子供1人当たり4万5000円が上限だ。この金額があれば端末代は賄える。しかし、教師たちが使いたかった学習用アプリなどが入れられなかった自治体も多くある。本格的に活用しようとなると現場では不足感が否めないようだ。
PCメーカー各社の多くは、GIGAスクール構想向けとして4万5000円程度のPCを展開している
4万5000円を超える金額について自治体が追加で上乗せするのは自由だ。アプリやサービスは各自治体の教育委員会が一律に導入を決めるのだが、教育委員会が自治体の財政部局に掛け合って予算を獲得しなければならない。
四條畷市教育委員会の植田篤司教育長（四條畷市のWebサイトより）
大阪府の四條畷市教育委員会はクラウド型の授業支援ツールを導入するため、予算獲得に奔走した。
「国の示す標準仕様の範囲でもITを活用した授業はできますが、ミドルウェア的な共通基盤となるツールを導入すれば、授業の生産性や効果、拡張性がより向上すると考えました」
そう指摘するのは、四條畷市教育委員会の植田篤司教育長だ。植田さんは日本IBMの出身で、大阪府立の工業高校の校長を務めたのちに四條畷市の教育長に就任したという異色の経歴を持つ。
IT活用のスピードも自治体によって大きく差がついている。同じ東京23区内でも、港区は20年12月時点で全員にiPadが行き渡ったが、足立区は21年7月の時点でも小学校で端末の配布が完了していない。
教育委員会がやるのは端末やアプリの選定だけではない。学校のインフラ整備も教育委員会の仕事だ。
校内の通信環境が悪く、インターネットに接続しづらい、通信速度が遅いこともある。これは必ずしも校内のアクセスポイントに課題があるわけではない。自治体によっては教育委員会のサーバを経由してインターネットに接続するようにしているケースがあり、通信速度の上がらない要因になっている場合もある。
データの保管場所にも問題がある。ある自治体ではセキュリティ上の理由で、教師たちのデータは教育委員会のサーバ、子供たちのデータは学校のサーバに保管され、互いのデータが送り合えない仕組みになっているという。そのため教師の端末から子供たちの端末に課題を渡そうにも、職員室にある専用端末にデータを移し、そこから子供たちに送付するという手順を踏まねばならないという。
情報セキュリティには敏感な一方で、パスワード管理には甘い部分があるようだ。
「子供がパスワードを書いた紙を持って帰ってきました。パスワードを紙で管理するのは非常識。娘にパスワードの重要性をしっかりと伝えて2人でパスワードを変えたのち、学校には『現状のパスワード管理体制には不備がある』と伝えました」
そう語るのは、横浜市の小学校に娘を通わせる前田さん（仮名）だ。IT企業のエンジニアであるため、学校でパスワードの重要性を説明すらしていなかったことに驚いたという。
こうしたさまざまな課題はあるが、GIGAスクール構想がもたらした変化の萌芽も確実に見られ始めている。これから現場はどのように変わっていくのだろうか。
前述の平井氏は「教師のITスキルはまだ高くないが、それは彼らが悪いわけじゃない。授業で使ったことがないからイメージが湧かないだけでしょう。問題は自治体がルールで縛ったことです。『iPadのカメラ禁止』『クラウド禁止』『YouTube禁止』なんて縛り方を間違えている」と指摘する。
「大切なのは『こういう授業をやりたい』というビジョンを持つことです。それがなければ、紙をタブレットに置き換えただけにすぎません」（平井氏）
「ある学校の美術の授業では生徒の自画像をクラス全員で共有し、いいと思ったところにみんなで付箋を貼る。こういう工夫が簡単にできるようになっています。現在の授業は、教師の知識伝達が7割、子供が情報取集をして自分で発信するのが3割という配分ですが、これを3対7に切り替え、子供が活躍する授業にしていくべきです。端末や通信環境の問題より、まずは教師が意識を変えないといけない。それが最大の課題です」（平井氏）
「教師はティーチングが主から、ファシリテートを主とする役割に変わっていく」――植田氏もそう断言するが、それはつまり教師の存在意義の大転換である。
21年7月、まだ準備中のデジタル庁がGIGAスクール構想に関して教育関係者へのアンケートの募集を始めた。今現場で起こっている課題感をヒアリングするのが目的とみられるが、文科省へのプレッシャーという意味もあるだろう。過渡期の試行錯誤が続くが現場は全力で戦っている。「どこへ向かえばいいのか」を国や首長が明確に示すことがその支えになるだろう。
真面目に「駆け出しエンジニア」が、入力に対するパフォーマンスの不一致が原因で、勉強停止が起こる理由を説明しよう。
そもそも、インフルエンサーのつく「フリーランスで年収一千万」という主張に再現性が無いのだ。まず、Rails + React を使う教材が多いが、その手の連中の壁が英語なんだよ。まず、「ちょっと、できるようになった」エンジニアが「ググって問題解決できる知識が書いてある」ところが、英語で書いてある。別に「英語を使えたら、年収一千万」なんじゃなくて、日本人の絶対数が英語圏より少ないことから生じる事象であって、日本人が解決するネタは「欧米人が解決している」可能性が高いのだ。そのせいで、欧米人よりも日本人は応用性に劣るというギャップが生じる。これは、差別ではないから、今後も解決できないです。
それが、間違うのよ。なんでかというと、Google や Likedin のようなサービスには MapReduce や Kafka のようなミドルウェアを生み出す原因をつくっていることがあって、後になって「似たようなものと違った」原因となる OSS として公開されるのよね。そして、我々が Rails や React として使えるようになるのであって、順序が逆なんだよ。
日本マイクロソフトでは、早慶を出た文系がたくさんいるけど、彼らは「アメリカで作ったものを日本で売る」というビジネスが成り立つから、コードを書く必要ないの。だから「コードを書いてないのに、年収が高い」という矛盾は、全く問題なし。日本人の給与でコードを書いたら、コストが馬鹿高くなるのよ。
そりゃ、君の使っている教材って、日本においても無料だし、浮いた学費は「自前で問題解決するため」にクラウドでも使って勉強した人の方が評価されるよ。ジャムおじさんも「美味しいパンを作ろう」といいながら、アンパンマンを作っちゃったから、世の中そういうもんだよ。
雇用の硬直化、および「専門学校や大学」といった勉強した連中が、貴方を選ばない原因の人材となります。だって、教材は同じだもん。ちゃんと勉強した人が、供給されている以上は負けますよ。
だから、マナブはタイに行ったんじゃね？しかし「NTT DATA が SEO を頼んできた」という Tweet は本当にウケけた。今どきの SEO なんて、NTT DATA なら Google から加点するっしょ。落ちぶれても、「デー」は一流だよ。タイにいる胡散臭いアホに頼むぐらいだったら、社内の「SEOエンジニア」に勉強と社益を兼ねてやらせるよ。ちゃんと利益出るし、SEO 真面目にやったからアクセシビリティも上がるからね。
3年前、世間一般にはメーカー系SIerとして知られている会社を退職した。ただ俺のポジションはパッケージソフト開発であり純粋なSIerとは異なる。
客ともSEとも会話せず、ひたすらドキュメントとプログラムを書く部署だ。といっても別にペーペーではなく主任クラスであり、
会社の業績がとてもよかったこともあり年収は1000万弱はあった。35歳。
これだけ見るととてもいい待遇に見えるだろう。でも耐えられないことがいっぱいあった。
Linuxで動くアプリなのにVMを動かすのも苦労する8GBしかメモリのないWindows PC、紙にコードを印刷して説明しないと納得しない品質保証部、
手作業で実施しExcelにチェックを付けていくテスト、jquery一つ使うのに3ヶ月かかる承認フロー、開発中にバグを一つ出すごとに
ひたすら反省文を求める品質保証部と一緒になって詰めてくるマネージャー、常にコンパイルできないtrunk、
Java 5の時代から進化しないコード、使いにくい社内ミドルウェアの利用を強制される設計、開発期間の半分以上を占める最上流設計、
一旦書いたコードは消してはならずコメントアウトしないといけないコーディング規約など、数を上げればきりがない。
色々改善活動を頑張ったものの、結局Subversionの導入も品質保証部がついていけないから、ということでClearCaseといわれる
今ではほぼ誰も使ってないであろうバージョン管理ツールが使われ続けることになった。使いにくい社内ミドルウェアは
研究所がその道のプロと聞いたので一緒に改善を図った。そしたらRubyしか書いたことがない文系新卒の子が出てきた。
一応研究所の人だし…と思って新バージョンのプロトの開発を依頼したら、1分以上稼働できない状態になって出てきた。
研究開発は準委任相当なのでそれ以上修正を依頼できずに期間が終わった。
また前の会社独特の文化として、大きなバグを出した開発者の反省会（社内ではとある固有名詞で呼ばれている）があった。
この反省会のターゲットになった開発チームはその資料準備で開発が1〜3ヶ月ほど止まるほど大掛かりなイベントだ。
このとき、担当の品質保証部は「連帯責任だから」という理由で資料レビューに大変な精を出す。余計なお世話だ。
このため10〜20ページほどの資料を毎週レビューにかけて最高のものにしていく。でも結局本番では幹部からの怒号が飛んで終わりである。
連帯責任とかいっていた品質保証部は幹部と一緒になって詰めてくる。連帯責任ではなかったのか。
幹部によると、この反省会があるから今の会社があるんだそう。これを経験して一人前らしい。
こんな感じで開発の体制はひどかったが、世間一般ではホワイト企業と見られている通り有休は取りやすかった。
そのため、転職活動を始めた。そしたらなんと「メモリ32GBのマシン」「mavenが気兼ねなく使える回線」「自動テスト」
「GitHub」「CI/CD」 という発言がポンポン出てくる。メルカリだのGoogleだのといったイケイケWeb系ではなく、
いわゆるSIerでもだ。最初は何だこの格差はと思ったが、まぁ営業トークなんだろうな、と思い直した。というわけで
イケイケWeb系も内定は出たものの、つい安定をとってしまい某大企業のDX系の部署に転職した。
そしたら何だこれは。最高スペックのMacBook ProからGitHubにpushするだけで自動デプロイで即サービスイン、
問題が発生したら社用携帯に通知が飛んできて、クラウド監視サービスでログをチェック、即修正即デプロイ。
社内の連絡はSlackで、スタンプを押せばIssueがたち即関連部署が対応に走る。OfficeツールはGoogle Docsで、
計算表はちゃんと表として使っている。開発者はちゃんと開発をしており、反省会の準備や品質保証部の接待なんて業務はなく
純粋にエンドユーザーだけを見ている。ここはなんて最高の環境なんだと歓喜した。また個人的にはおまけ程度であるが、
年収は30万ほど増えて大台に乗った。
さて、それから3年がたった。人間というのはいい環境になれると対して喜びを感じなくなる、というのはそうだと思う。
今では別にdeployブランチにマージされたらCIが走って自動でテストが走りデプロイされるのも、だから何？
って感じだしまぁ普通の仕事として淡々とやっている感じはする。待遇面で悪化した点もちらほらあるし
（例えば年間休日が5日ぐらい減った、残業が月5時間ぐらい増えたなど）などもある。
ただ一つ言えることは前の会社には戻れないな…ということである。人間一度生活レベルを上げてしまうと下げるのは
ただ、一つだけ今の会社に転職してよかったと感じ続けられることが一つある。それは人だ。
前の会社では家でプログラムを書いているなんていった日にはおちょくられたり、人生楽しいの的な目で見られたりした。
芸能人とゴルフの話ができないとコミュ障扱いされた。そのため仕事の話はしても、飲み会にはできるだけ行きたくなかった。
でも今の会社では雑談としてFastlyが落ちても大丈夫なCDN構想とか、AtCoderの話をして盛り上がることができる。
ダイバーシティなんていうが、人間は所詮同質な人間同士で集まったほうが快適なんだな・・・という複雑な思いを抱いている。
皆さん読んでくれてありがとうございます。いくつか質問が出ているので答えられる範囲で答えます。
真面目な疑問なんだけど、Java5のコード書いてる人を1000万で雇う会社があるの？どういうモチベーション？？
製品自体が90年代から脈々とバージョンアップしている企業向けのソフトウェアなので、コードベースが古いというのがあります。
またユーザーからすると中身がJava17だろうがJava5だろうが関係ないわけで、要は業務が滞りなく進めばよいわけです。
そのため昔から受け継がれたスパゲッティコードを地道に解き明かし、新しく出てきた要件を今までのコードベースを壊さずにバグなしで追加していく、
もとからあったバグについては、その他の数百万行のユニットテストもないコードに影響なしで修正を施す、といった技能が必要になります。
こう考えると意外と希少なスキルなんだな・・・と思えるかもしれません。
clearcaseよりもsubversionの方が100億倍導入も運用も簡単だと思うんだけど品管どうなってんの？
ClearCaseご存知な方がいるんですね！一から作る製品だとSubversionのほうが簡単かもしれません。ただ、ClearCase専用の
社内ツールがいくつかあり、そのツールで出力した情報を社内資産として持っているという理由があったりします。
例えばお客さんから「この機能がバグってるっぽい」というクレームを受けた際、その機能周辺の情報をそのツールから検索し、
コードレベルで再発防止策を関係部署総出で練った上でお客さんに回答する、という運用フローになっています。
そのため、Subversionに変えるためには開発陣の一存では無理で、品質保証部やマネージャー層など全ての知識のアップデートが
必要になり、そこまでコストをかけて説得して回る必要はあるのか・・・という話になってしまうわけです。
ただ、社内の生産性を向上させるのが目的の部署としてはSubversionやGitを社内に浸透させたがっているのも事実で、
新規プロダクトなんかはGitを使っていました。ただしGitHubはプロキシでアク禁されているだけでなく、サービス名名指しで使用禁止
になっているので、相当の理由がない限り使えないかと思います。
主任クラスでも1000万円近くもらえるのか。すごい。
1000万という数字に興味のある方が多かったので参考までに書いておくと、等級ランクというものが存在して管理職を除く最上位のランクに
なると2人の子持ち、賃貸住まい、標準評価で大体900万になるという感じです。年功序列だが部署ごとに違うというイメージで、
研究所だと20代で到達する一方、利益を上げていない事業部や間接部署だと定年間際まで到達しない人も多い、ぐらいの感じです。
平均では30代中盤ぐらいでしょうか。
ちなみに私の場合は基本給は33万程度ですが、そこに裁量労働手当と住宅手当、家族手当がついて月給で50万を超えるぐらいでした。
ボーナスは個人評価よりも部門業績に大きく左右されるのですが、部署が最高評価の場合は夏冬とも150万以上でした。
最後の最後のダイバーシティについては、ダイバーシティを勘違いしているように思う
この人と一緒に働かないといけないの辛すぎて転職考えるレベルだわ。せめて素直な人ならいいんだけども。
辞めてくれないかな。
最初に結論から書くと、「毎日新聞さん正論すぎる」「だけどまだちょっと時間あるで」。
『「COCOA」がグーグルとアップル基本ソフト最新仕様に未対応』
→ https://mainichi.jp/articles/20210315/k00/00m/020/165000c
うん。コード見てる人はだいたい知ってる。
まあ、そうですね…。
COCOAの動作の基盤となっているのは、Exposure Notification API（曝露通知API）というやつで、GoogleとAppleが共同で開発した、AndroidとiOSの両方で使えるAPI。OSと近いところで動くライブラリみたいなもので、おかげでBluetoothを使っても電力消費は最小限で済むし、アプリがプライバシー関係でよからぬ手出しができないようにもなってる。iPhoneではiOSの一部として組み込まれているし、AndroidはGoogle Play経由の「Google Play 開発者サービス」の新しい版に含まれてる、みたい。
このAPIにはバージョンがあって、V1ってのが最初のやつで、もう少し検出方法が洗練されたV2ってのがある。Exposure Notification APIのセットの中にV1とV2が重複しつつ混在してて、今から作るアプリなら使えるAPIバージョンをアプリ側で確認して、使える方を使う、という感じになるかと思う。
現在、COCOAがまがりなりにも動いていることからも分かるように、API V2が使えるようになっても、後方互換性のためにV1も使えるようになっている。Apple/GoogleはV1のメソッドとかには「deprecated」（使用不可）っていう印をつけて、今後は使わないように、と言ってる。
「deprecated」になったやつは、Apple/Googleは「もう使わんでね。いつ使えなくなっても文句言わんでね」という扱いをする。だから、「ソフトの更新次第で作動停止」という指摘は間違いではない。間違いではないが…。
Apple/Googleのデベロッパならよく知っていると思うけれど、「deprecated」になったからといって、そのAPIを予告なく使えなくすることは、まず、ないのです。
増田はIOSのデベロッパなのでiOSの例をあげると、画面を表示する基本的な部品であるところの UIWebView っていのうがあったんだけど、これはiPhone OSの頃からあった古い古い部品で、これまでずっと使われてきた。これはwebの画面を表示するのと同じやりかたができるので、iOSのアプリはほぼみんな使ってたんだけど、いろいろ問題もあるので、iOS 8の頃に WKWebView っていう新しい部品を出したのです。で、UIWebView をdeprecatedにしたのがiOS 12のとき。
ここからAppleは、「UIWebViewを使ったアプリをApp Storeに提出したら警告するからね」→「今後新規アプリやバージョンアップのときUIWebView使ってたらリジェクトするからね」→「UIWebView使ってるアプリはAppStoreから削除するからね」という感じにデベロッパの様子を見て期限を延長したりしながら段階を踏んで、ほんとに削除（一時的な非表示）始めたのは去年の12月ですよ。しかもiOS 14でもまだ既存アプリのUIWebViewは動く。
もちろん、滅茶苦茶使われていたUIWebViewと比べたら、Exposure Notification APIみたいなマイナーなAPIでこんな丁寧なことはやらないかもしれないけれど、でも重要度で言ったらExposeure Notification APIなんて「超重要」でしょ。V1が全然使えないならまだしも、一応動いてるし。
Exposure Notification API V1は、使えなくなる前には必ずデベロッパに期限を知らせるはずで、いきなり切るはずはない（ないよね（ないんじゃないかな（まちょっと覚悟はしておけ）））。
だから、COCOAが急に使えなくなっちゃう！ と不安になる必要は、当面はないと思っていい。かな。
これはスレたデベロッパであるがゆえの油断であると言われてしまえば、そのとおりです。「deprecated」は「deprecated」。普通のプロジェクトなら、すぐさま対応を検討して、バージョンアップ計画を立てるのが正しい。普通のプロジェクト、なら。
記事中では「21年2月になって、ようやく最新使用に対応するための具体的な検討に着手した」って言ってて、まあこれはダメなんだけど、そもそもプロジェクト運営がグダグダだったんでしょうがねーんじゃね？ というのがいちヲチャーとしての感想ではある。だって、Android版動いてなかったんじゃよ？ プロジェクト立て直す時間はあるはずなので、体勢立て直してから検討してもいいかな、という気はしている。それくらいの時間はある。はず。
そういう意味で、毎日新聞の記事はちょっと叩きすぎな感はある。正論ではありますよ。正論では。
で、ここでぶっちゃけてしまうと、実はもうCOCOAは要らないっちゃ要らないのです。
保健当局がアプリを作れない／作らない国／地域のために、iOSでもAndroidでも、AppleとGoogleが用意したCOCOA相当機能「Exposure Notification Express」というやつが、OSに組み込まれている。これを使うことにすれば、当局はサーバ側のバックエンドだけ用意すればいい。
『グーグルとアップルの新型コロナ接触確認機能に新たな仕組み「Exposure Notification Express」――日本には影響なし』
→ https://k-tai.watch.impress.co.jp/docs/news/1274374.html
『Supporting Exposure Notifications Express』
「だけ」って簡単な言うな。そりゃ大変だけろうれど、わざわざ使いづらい／どマイナーなミドルウェアXamarin（Microsoft謹製）使って、頑張ってクロスプラットフォームなアプリを開発／運用するよりはずっと負担は少ないよね（必要な予算も）。
もう、バンザイして、Expressにしたらいいんじゃね？ と、増田は考えるんじゃよ。知らんけど。
COCOAは嫌いになっても、Exposure Notificationの仕組みは嫌いにならないでください…(´・ω・`)
COCOAは出自がアレで、採用の意思決定が不透明で、契約もテキトウで、アプリ運用も誰が何をどうしたらいいのかわかってない／身動きができない、という悲惨なアプリです。
でも、2月以降変わってきたんですよ。COCOAの立て直しチームにCode for Japanの人やオープンソースの知見を持った方が参加して、githubでのissue解決の動きも再開している。ちょっと見てみてくださいよ、いろんな人が寄ってたかってコードを検証して、それが反映されつつあります。
『Issues・cocoa-mhlw/cocoa・GitHub』
→ https://github.com/cocoa-mhlw/cocoa/issues
いままでよりはまともに動くようになるはず。
前述のように、Exposure Notification APIで消費されるCPU資源も、通信も、ストレージも、バッテリも微々たるものです。
Exposure Notification API自体は非常によくできており、プライバシーに関しても、よくまあここまで、というくらい考慮されています。アプリ側でいろんな悪さを仕込むことは技術的には可能ですが、小細工を仕込んでもAppleやGoogleのアプリ審査で弾かれます（通常の小細工入りアプリが弾かれる程度には）。運営への不信からプライバシーについても疑ってしまう人もいるけど、COCOAはその点まず心配ありません。
だから、渋々でいいので、もうしばらくスマホの奥においといてもらえませんか。そんなにお邪魔にはならないですよ？
そして万が一曝露通知が届いたりしたら宝くじ大当たり級の驚きが（うれしくない）
たとえば、「彼は優秀な数学者だが、論文は書けない」なんて話は、（まあよほど特殊な事例を別にすれば）無い。
一方、「彼は優秀なエンジニアだが、ドキュメントは書けない」という話は、この業界に勤めていれば頻繁に聞く。しかも、コードは書くがドキュメントは書かないことが職人気質でかっこいいかのようなニュアンスを含む場合すらある。
この違いは何だろうか？答えはこうだ。
「ドキュメントを書かないエンジニアは、エンジニアとしてもレベルが低い」
ただそれだけの話だ。
ドキュメントが書けないというのは、自分の作ったプログラムの設計、あるいは使っているツール等の機能を理解していないということである。つまり、結果的に動くものが作れただけで、その実は見よう見まねでコードを書いたりツールを使ったりしてただけということである。
「ソースコードがドキュメントである」というのは単なる怠慢に過ぎない。実際、有名なオープンソースソフトウェアには良質なドキュメントがあることが普通である。ついでに言えば、それらの開発者は、その辺のサラリーマンエンジニアよりも遥かに優秀である。
等、ソースコードに直接現れない情報がいくらでもあるからだ。こんなことは、わざわざ書かなくても、一定の常識があれば明らかだが。
この程度でも600万は稼げるという夢を持つか、こんなのでもちょっと何かが違うだけで600万稼げるか否かが分かれてしまう業界に闇を感じるか、600万程度で何ドヤってるの？と思うかはご自由にどうぞ（外資系ってもっと稼げるの？）。
歳は30台前半。学部卒。BtoB向けのパッケージ製品の開発プロジェクトで、設計、コーディング、テストあたりを担当している。仕様について発注元との折衝もやっている。
業務で使う技術のうち、自分自身がそれなりに習得しているものだけを書く。プライベートでしか習得・使用していない技術は別。
以上。
PythonもgitもDockerもkubernetesもAnsibleもCIツールもAWSもGCPもRuby on Railsも知らなくてもなんとかなってしまっている。業務でこれらのスキルを要求されることは（今のところは）ないから。
楽でいいと思う一方、このままだと将来ヤバいとも思っている。いざ転職となったときに詰みそう。
でもいざとなったらググっていくらでも独学できるだろうとたかをくくっているので焦ってはいない。
というか「その他」のところに書いた能力が高ければ世の中大体はなんとかなるんじゃないの。知らんけど。
ちなみに自分は構築できないというだけで、プロジェクトではJenkinsとかgradleとかbabelだかwebpackだかでビルド環境は整えられている。
あとプライベートで、単純な仕様の独自言語のコンパイラフロントエンドをC++とLLVMで作っている（これで金が稼げるとは微塵も思っておらず、完全にただの趣味）。
何事もなければ社長が死んだショックだけで終わったかもしれない。
7Payと言えばわかるだろうか。詳しくは書けないのだけど、あれと似たようなことが起きてしまった。
かなりのストレスだったと思う。ネットで調べたところ、急性心筋梗塞はストレスでも発症することがあるらしく、そこが少し引っかかってしまった。
様々な理由から現状社長の訃報を知らせるページを検索エンジンにインデックスされないようにしています。
もし心当たりのある会社があった場合でもリンクは貼らないでいただけますようよろしくお願いします。
使うのであれば、ライブラリ、フレームワーク、ミドルウェアの更新（バグ、脆弱性情報）を一生追い続ける覚悟で使ってほしい。
テスト自動化とかそういう発展的なものではなく、もっと根本的なテストについて勉強してほしい。
コードレベルのカバレッジとかそういうのではなく、「境界値分析」、「デシジョンテーブル」、「オールペア法」、「直交表」こういう物について勉強してほしい。
他にもいろんな手法はあるのだけど、上記に上げたもので1個でも知らない単語があった人は今すぐ検索してほしい。
いくら進捗が悪いからと言ってお客さんに順調などと嘘をつかないで欲しい。
遅れている理由を正直に言って（例えばテストの工数が膨れているとか）相談すればお客さんもわかってくれるかもしれない。
また、テストの質もそこまでの物が求められていないとかがわかるかもしれない。
お客さんに相談しないで工数圧縮の為にろくなテストも書かないで動いてるからいい！っていうのは危ない。
自信がない、もしくは、やったことがない・使ったことがない、などは正直に話してほしい。
もしかしたらそのせいで給料があがらなかったり、出世できなくなったりするかもしれない。
だけれど、その嘘のせいで他の誰かに負担がかかったり、他の誰かが不幸になるようなことがあってはいけないと思う。
これに関してはいろんな批判があることは覚悟している。嘘をついてでもいろんな経験をした方がいいって言う人もいると思う。
それでも、どうしても書きたかった。
別にLPIC(LinC)は持ってなくてもいい。本屋で適当に対策本をパラパラめくって、聞いたことのない単語がないレベルであればいい。
インターネットには嘘が散りばめられている。昔は本当だったけど今は嘘になっているものだってある。
一番いいのはエラーメッセージを出している物のソースコードを読むこと。二番目はドキュメントを読むこと。それでもわからない時だけ検索してほしい。
そして、その情報が誰が書いているかをよく見てほしい。書いている人が本当に信用できる、かつ、更新日付が近かったときだけそこの内容を信じてほしい。
公開リポジトリにpush/commitされているメールアドレスを収集している人がいるということ、
公開リポジトリにpush/commitされている秘密情報を収集している人がいるということ、
RDBによってはSQLのIN句に指定できる数に上限があること、
他にもいろいろあるが、1個でも知らないものがあった人は検索してみて欲しい。業界にもよるかもしれないが、本来であれば最低限知っておかなければいけない知識。
これを知らないと適切な設計、ましてや適切なコーディングすらできなくなる。
ぼくはエンジニアに向いてない
