  |
はてなキーワード: エンジニアリングとは
やっぱりあくまでもエンジニアリングであって、ドクストの主人公が科学を連呼するのは違和感あるよな。
※以下、「エンジニア」と書かれている場合には「ITエンジニア」と読み替えてください
社員数1000人超のユーザ系SIer→Web系事業会社に転職して半年が経過したので所感を残しとく。いわゆる転職エントリってやつ。
Web系エンジニアの転職エントリって大体つよつよエンジニアの情報しか出てこなくてウッってなったから、自分のようなクソザコエンジニアの事例をネットの海に放流しとこうと思った。
みんなブログだと当たり障りのないことや技術的に意識の高い内容しか書かないからさ、パンピーの本音ベースでの不満や転職活動の内容ってなかなか見つからんのよね。
文章の感じとかで分かると思うけど、ほんとに意識もスペックも低い人間です あと一定以上の長さの文章書くの苦手だから箇条書き多いけどゆるして
入社して1か月はコンプラ研修とかビジネスマナー研修とか受けてた。
そのあと3か月くらいF士通のプログラミング講師みたいな人からIT研修を受けた。教科書に書いてある通りにLinuxのコマンドポチポチしたりJavaのコードを写経するだけだった記憶
研修が終わり晴れてインフラ系の開発運用を行う部署に配属されたんだけど、やっていたことは下記の通り。
業務ではコードを書くこともターミナルでコマンドを打つことも全くなかった。ひたすら溜まっていくユーザーや開発側からの問い合わせへのメールを返信する存在だった。
配属された部署がたまたまそういう場所だったというわけでもなくて、同期の話を聞く限りアプリ部門だろうがQA部門だろうが似たような感じぽかった。
これってITエンジニアの仕事なんか?事務職とかに近くね?という疑問を抱きながら1年半くらい過ごしてた。
自分のイメージしてたITエンジニアっていうのは、スタバで私服でようわからん真っ黒な画面に向かってプログラミングしたりサーバやNWをいじってる人のことであって、ワードパワポエクセルとにらめっこしながらスーツのおっさんとおしゃべりして一日を終える人じゃなかった。(多方面に怒られそうな表現だけど...)
あとは、
全体的に、仕事と関係ないクソどうでもいいことにこだわらないといけないのが嫌だった。「もっと技術にコミットしたい」みたいな、エンジニアとして正しいであろうモチベはあんまりなかった
別に自分にはソフトウェアエンジニアリングを通して実現したい目標があるわけじゃない。三度の飯よりプログラミングが好きってわけでもない。
SIer、っていうか古き良き日本の大企業でエンカウントする嫌なことから距離を取りたい、というモチベだけで行動した結果Web系エンジニアになってた。
ただ、どうもWeb系エンジニアっていうのは技術が好きで好きでしょうがない人間がつく仕事っていうパブリックイメージがある気がするんだよね。なんでだろう?
そんなに技術好きじゃなくても、Web業界の成長のおこぼれにあずかる程度のエンジニアになることは難しくないと思う。あんま知らんけどエンジニア数十万人単位で足りてないんでしょ?
俺はほんとクソザコだし、はてなに常駐するようなつよつよエンジニア達からみたら関わり合いになりたくないタイプの人間であることは自覚しているけど、表に出ないだけで俺みたいな人結構いるんじゃねって思ってる。
https://anond.hatelabo.jp/20210610184501
文面からおそらく弊社の、しかも関わりのある事業部なのだろうと想像した。そういう意味ではまずは今までご苦労様。
まず自己紹介からしよう。私は主に公共向けのSEをしている部長相当職（社内ではある固有名詞で呼ばれている）だ。社内の製品は一通り把握している自負はあるので、よっぽどマイナーなものでなければおそらく君のところの製品も触ったのではないだろうか。
開発に必要があるなら申請を出せば普通に入手できるし、Gitも普通に使っている。正直なことを言おう。そんな小さいことで辞めたのか？と思ってしまった。35歳で主任（これもある固有名詞で呼ばれてたんじゃないか？）ということはそもそも開発者なんてフェーズはとっくに過ぎてマネージメントを任される頃のはず。これはたとえ製品開発の事業部だったとしてもそんなに変わらない。それなのにその視座の低さがとても気になったよ。概して若いコーダーは顧客のメリットが0であるような単なる自己満足としてGithubの利用やDockerを使いたがるが、悪いけどそのまま大人になってしまった感じを受けた。開発環境の優劣というのはそんな低レベルな話ではなく、上流工程での品質の作り込みがしっかり行われているかとか、品質管理のKPIがしっかりされており、そのKPIに対するPDCAが回っているかとか、人月単価を適正に管理し競争力のある製品を作る予算管理ができているかといったことのほうがよっぽど重要。
弊社はあくまでも「ものづくり」「エンジニアリング」の会社であって、「コーダー」の会社ではない。そのためDockerだのGithubだのMavenだのといった要素技術に対してそんなに価値を認めてないんだよね。もちろんそういった技術で儲けようとしているWeb系の企業がたくさんあるけれど、年収を比べてみれば結局どっちの市場評価が高いのか、よくわかるんじゃないかな。「ものづくり」で大事なのはあくまでも顧客の要求を満たすことで、それはDockerだのGithubだのMavenだのを使うことととは次元の違う話だし、市場価値が高いところにコミットしてそうでないところを適正に管理しているからこそその年収が出せるものだと思ったほうがいい。今の年収と同じ水準でモダン 笑な環境に転職したじゃないかと反論されそうだが、転職市場は前職の年収ベースになるので結局君の実力ではなく弊社の実力が評価されただけなんだよね。そこは謙虚になったほうがいいと思う。
まずシステム開発は「ものづくり」ということが見えていない。「ものづくり」というのは単にコードを書くというだけでない（君はそこにフォーカスしすぎて、その環境の悪さだけが目についたように見えた）。市場の要求に対して適切に答えてるのが命題であり、技術は単なる手段ということを忘れてはいけない。プログラミングというのは手段である技術のたった一要素に過ぎない。そういう徹底的な顧客志向を日本のメーカーは長いことやってきており、高い生産性を実現してきたし、社員にもその精神を学んでほしいという一心でビジネスを動かしている。だが、最近のIT系企業は「ものづくり」ではなく技術を目的にしているところが多いよね。MacやGithubとか言ってる層は特にその気が強いと思うのだが、君は結局そこに行ってしまったようだ。
以上を踏まえておじさんから一つだけアドバイス。今のWeb系がやっていることは所詮大昔の技術を再発明しているだけであり、本質的に価値が薄いということ自覚した上で本当に顧客が欲しい物を作るということを忘れないでほしい。例えばDockerなんて大昔からLinuxが持っている機能の寄せ集めだし、Gihubなんて本質的にはファイル名に日付を管理するのと変わらない。弊社に関して言うと、AWSなんていってるけど所詮VMだし、弊社はハードウェアレベルでより高い技術を持っている。AI企業は専用AIを個別案件ごとに作っているが、弊社は汎用AIを世界で初めて開発した。でもそれらを積極的に宣伝はしていない。なぜか？それらは単なる手段だから。むしろお客様へのソリューションという形で宣伝していて、結局顧客のビジネスにフォーカスしているんだよね。だからこそ利益が出せ、年収も高いというわけ。なので、再度いうが、本当に顧客が欲しい物を作るということを忘れないでほしい。
俺はITエンジニアをしていて、ベンチャーやSIerなどで自社、顧客企業を問わず今まで多くのWebシステムを作る案件に関わってきた。
プロダクトが上手くいくもいかないも、プロダクトオーナーが全てだ。
特にWebサービスの場合、ビジネスサイド、ITエンジニア、デザイナーという3つの職種がチームを作ってプロダクトを開発していくことになる。
その場合はプロダクトオーナーはビジネスサイドが務め、テックリードがPdM補佐のような形になるだろう。
SIerの場合は、顧客企業の窓口となる人がPOを努め、開発会社のマネージャーがテクノロジーを統括することになる。
そして大抵の場合、ビジネスサイドの人間がPOを務めると、「声のデカいステークホルダー」となり、チームを引っ掻き回し、プロダクトを迷走させ、モチベーションを下げさせるのだ。
だってそうでしょう！？プログラミングも、DBでのデータの持ち方も、他社のAPIの使い方も、UIデザインも、いくつかあるUIの選択肢とそれを実現する工数も、何も分かってないんだから。そんな人間が最終意思決定者をやるんだから、上手くいくはずない。
だいたいMVPにはふさわしくないリッチなUIを要求してきたり、難しい実装や工数のかかる機能を要求してくるのだ。そしてその実装に工数がかかるのは、エンジニアの怠慢、スキル不足だと考えている。
本来であれば、機能の過不足については、ユーザーがやりたいこと、こちらがやらせたいことが実現できているかどうかだけを考えるべきなのだ。それがどういう形のUIで提供されているか。別ページなのか、モーダルなのか。ボタン押下で動作するのか、JavaScriptでインタラクティブな操作ができるようにするのか、ビジネスサイドがこだわり主張するべき所ではない。
そもそもエンジニアは1+1=2になる世界で生きているが、営業というのは顧客を口説いて意思変容させるのがミッションだ。現実を歪めるのが職務なのである。エンジニアはエンジニアの工数は変えられないものだと理解しているが、営業はそれも「なんとかできるはず」と考えてしまうのだ。
仕事には内部に向けるエネルギーと、外部に向けるエネルギーの2つがある。そして、外部に向けるエネルギーをどれだけ大きく出来るかがビジネスの成功に繋がる。
ビジネスサイドの何もシステムの専門知識の無い人間がPOをやると、思いつきで「あれはどうなの」「こうしたらどうなの」って言って、エンジニアやデザイナーという専門家が「それは難しいです。なぜなら技術的に…工数的に…タイミング的に…」という話をして、仕事に使えるエネルギーもモチベーションも時間も、POを説得するという「内部に向けるエネルギー」に消費してしまうことになるのだ。
色んな専門家が集まって、それぞれの専門領域を発揮し、お客様に価値を与えるプロダクトを作り、金を稼ぎたい。だからこの仕事をやっているのに、なんで何も分かってないPOが自分の存在意義を発揮するためのだけのオ◯ニープレイを説得することに毎日忙殺されているんだろう。馬鹿じゃないかしら。
そういうPOを補佐するために有能なPO補佐がいるんですよという話もあるが、どうせ人の話を聞かないんだからPO補佐がいたって意味ないです。
そしてそれができるバランス感覚と説得力を持った有能なPO補佐がいるんだったら、その人がPOをすべきだ。お前じゃない。
過去会ったことのあるPOには、エンジニア出身のダメなやつもいた。この現代において生PHPやStrutsの時代で止まった知識を振りかざし、自分は知識があると勘違いした痛いやつが。もっとも彼は元エンジニアであって、エンジニア辞めた後はかなりの年数を営業としてやっている人間だったが。
だから俺は、POは現役エンジニアがやるべきだと思う。技術オタクのCTOというよりは、VPoEの立場の人がやるのが一番いいかな。顧客を無視したエンジニアリングオ◯ニープレイをしない、ちゃんとカスタマーサクセスとUXへの費用対効果を考えられるエンジニアだ。
そして営業/マーケターはサービスを売りつつ、顧客の声を聞き、顧客の抱えてる課題を発見し、それをチームに伝えてくれたら良い。ソリューションはエンジニアとデザイナーが考えるので。
ある程度会社が大きければ、エンジニアをプロダクト開発のトップに据える、そういう責任移譲もできるだろう。
今日の名言飛び出しました
「プロダクトオーナーがしっかりとしないと、エンジニアがいても能力がある人がいても意味ない」
「ビジネスモデルは考えられるけどプロダクトモデルを考えられない人が増えてきている」#DxMiraiKaigi https://t.co/6VHrh1Ut3z— あれっくす@一番下手っぴでいい (@MHTcode_Alex) May 20, 2021
ベンチャーのあるあるとして、ビジネスモデルは考えられるけどプロダクトモデルを考えられない営業人間が起業して、「俺の考えたビジネスモデルを実現するに協力してくれるエンジニア募集！」とか言ってチームを作り、社長がPOを務めることが多い。
でもその社長に、POとしての職責が果たせるかどうか、スキルがあるかは別な話である。というか大抵の場合、無い。
声のデカいワンマン社長の言うことを聞いて、クソなものをクソだと思いながら作り、社長がVCにプレゼンして調達したお金を啜って生きていくのがベンチャーでのエンジニアライフである。オワリです。
ベンチャーで上手くいくのは、エンジニアでありながら希なプレゼン能力とコミュ力を持った、エンジニア社長がいる会社しか見込みがない。
これを読んでるあなたがもしビジネスサイド出身の社長さんであれば、あなたの仕事はプロダクト開発にズカズカと踏み込んでいって、思いつきで喋って、自分のこだわりを入れるように怒鳴り散らすことではありません。
課題は無いか耳を傾け、解決できそうな人を連れてきて、お金を出すだけに徹するように下さい。
それができないのであれば、あなたはWebシステムという無限の拡張性があるものからお金を得ることはできません。愚直な営業と手作業でバリューを出すという、労働集約型の仕事を一生全うしてください。
そしてこれを読んでるあなたがもしエンジニアであれば、ビジネスサイドにプロダクトの決定権を握られている状況ではエンジニアが幸せになれることは決して無いので、ビジネスの作り方やマーケティングを学んで、エンジニアがビジネスを握っていこう。プログラミングを修得するのに費やした時間と努力をビジネスサイドにも発揮すれば同じように身につけられるはずである。ビジネスサイドに顎で使われる存在から抜け出していこう。
星野リゾートではどのようにして旅館現場出身者をIT人材へ育成したのか？【デブサミ2021】 (1/3)：CodeZine（コードジン） https://codezine.jp/article/detail/14017
これはすごいですね。非エンジニア出身のPOでありながら、ちゃんとプロダクトを成功へ導いている。
ここでの例では2例あって、社内システムと、社外のお客様向けのシステムだ。
社内システムはノーコードを活用して、自分たちで作って自分たちで運用するようにした。いいですね。非エンジニアの思いつきをエンジニアに作らせる、という動きにはなっていない。自分の思いつきのケツはちゃんと自分で拭け、他人に迷惑をかけて対処しようとするな、ということだ。
社外向けのシステムを作るに当たっては、ちゃんと自分たちをIT人材に変化させていくための勉強をちゃんとしている。エンジニアと同じ目線に立って同じレベルで話ができるようになっている。これだといいですね。
やっぱり、Webシステムを作るPOは、営業出身ならめっちゃITのこと勉強すべきだし、それが嫌ならITで金儲けしようということからは降りるべき。
コンピュータ好きには元来男性が多く、従ってIT界隈の技術職にも男性が多い。そこに近年のジェンダーレスの流れが来ており、「男性が多いのは女性差別である」という号令の元、女性優遇文化が跋扈している。
女性というだけで採用されるし、評価も甘い。これは特定の企業だけでなく普遍的に発生しており、「同じ能力なら男性より女性」という事態が発生している。
当然実害も発生している。有名所ではGAFAMのうちの一社が、とある有名OSSの担当者に女性エンジニアをアサインした。この女性エンジニアはエンジニアリング能力は高くないことはGitHubの履歴などから明らかだった。にもかかわらず「弊社は女性エンジニアも活躍しています」というアピールのため有名OSSの担当者になり、そのOSSは目も当てられない品質になった。公に語られることは少ないがこの一件はハイレベルなエンジニアの中で「性別ではなく能力で優遇すべき」と思わせる一件となった。
「男性限定プログラミングコンテスト」「男性のためのキャリア相談会」のようなものはまず無いし、そんなものを開催するとなったらバッシングされるだろう。しかしそれらの女性版は実在する。明確な性別による区別がIT業界には存在している。そのように人を性別で区分けをしていながら、もう一枚の舌で「私たちはジェンダーによる差別が無い世界を目指しています」と言うわけである。何が何やらわからない。
日本のみならず世界的にIT業界はリベラルな思想の人々が多い業界とされている。それは体感的にもその通りなので、ここではこれを真として扱う。だからこの業界は男性含めほとんどの人々は性差別を無くそうと本気で考えている。しかし女性は女性であることの権利を活かし「女性限定○○を開催しよう」と言うし、能力を棚上げして男女比を50:50に持っていくために「女性を採用しよう」と言うし、男性エンジニアも協力して稼いだお金を「女性支援団体に寄付しよう」と言うわけである。これに反対すると「男性はこれだから」「女性差別主義者」「保守思想」といったレッテルを貼られてしまう。だから誰も女性優遇措置には反対できない状況が続いている。
我々男性エンジニアが望むのは、性別によって優遇不遇されることが無い世界である。性別に関わらず能力が優れた人が高い給料をもらい、昇進する世界を求めている。しかし実態はその真逆を行っており、ジェンダーギャップの少ない世界にしようと声高に叫ぶ人たちが女性優遇をしているのである。
【追記】
話を理解してない人が多くて困る。男性が優遇されてる会社や時代ではあることは認めるよ。
だからといって男性差別したらダメでしょう。我々は平等な社会を追求すべきであって、
「男性は優遇されてたから不遇な目に遭うべき」のような理屈は通らない。
それは都合が悪いから無視か？弱者男性の声は聞くに値しないのか？
お前らの正義感は歪んでる。
【追記2】
IT業界 (デカい) の「初心者向け」「ゼロからはじめる」勉強会とか記事ってたくさんあるけど、その「初心者」って
みたいな、講師を担当している「ご立派なエンジニア自身」を念頭に置いてるよね。
でも、世の中の、初心者向け勉強会とかで「誰かに教わらないとはじめられない」人って、
っていう感じだから、そこに合わせるか、逆に「この勉強会でいう『初心者』はこのレベルに達している人です」と明示する必要があるよね。「初心者向けに情報を発信しよう」と思う人は、「じゃあ自分が言っている『初心者』ってどんな人なんだろう」と想像する必要があるんじゃないかな、と。
もちろん、「そんな段階の人がこの技術を使うべきでない」という主張もできるけど。
曰く、YOASOBIのアルバムを聴いて「このビートの単調さと音色・音圧のショボさが世間で許容されてるのはちょっと信じたがたい」とのことだ。
実は私もこの評については概ね同意なのだが、考えをまとめるために「夜に駆ける」を題材に少しだけこのことについて書いていきたいと思う。
見当違いな点もあるかとは思うが、素人ながら20年以上音楽をやってきた人間の一意見だと思っていただけると幸いだ。あと、あくまで音に関する話だから、歌詞とかについては割愛。
●メロディについて
特に変なメロディだとは思わないけど、ドラマチックさには欠ける気はしている。目新しさも特にない。が、キャッチーではあると思う。冒頭とか思わず口ずさんでしまうインパクトはあるし。
●アレンジ面
正直ここが一番ツッコミを入れたいところだ。かの音楽評論家の言っていた「音色・音圧のショボさ」はここに主な要因がある。
無駄を省いた、と言えば聞こえはいいかもしれないが、多分Ayase氏はまだそこまでのテクニックを持っていないだけにすぎないのだろう。音の緻密さはなく、だいぶ荒削りだ。
キックは4つ打ちに重要なローのスピード感がいまいちだ。だいぶもっさりしているように思う。
ピアノのボイシングも工夫がない。低音で3和音を鳴らしているのは編曲の理論としてはあまり好ましくないし、それが結果的にピアノのローをEQでごっそりカットするということに繋がっている。
ギターについてはまぁ職人な立ち位置だなとは思った。サウンドメイクはもうちょっと頑張って欲しいけど。
全体の構成としてもだいぶのっぺりしていて、場面場面での厚みにあまり変化がないのが気になった。
●ボーカルについては
正直あまり印象に残らない、というのが個人的な感想だ。ややのっぺりした歌い方は最近のシンガーソングライター系のそれに感じたが、声に強烈な個性があるわけでもないのでそれが逆効果になっているように思った。
歌に表情をつけるためのテクニックがまだ途上なのかな、全体のサウンドがのっぺりしているのにボーカルものっぺりしてるから、いまいち曲に抑揚がないように感じてしまう。コンプがどうとかって話じゃないよ。それが私の感じた「つまらなさ」に繋がっているのかな、と思った。
●エンジニアリングについて
とにかく平面的で一直線上に張り付いた、奥行き感のないサウンドに感じた。レンジも狭いし。
デジタル系ビートにも関わらず、キックのボトムエンドの量感が感じられないのはかなり気になるところだ。4つ打ちなのにノれない…。
あと、とにかくピアノの音がパッツパツなのが気になりすぎる。曲調が曲調だからなのかもしれないけど、それにしたってそんなに音数が多いわけでもないアレンジの中でこんなにダイナミクスのない音にするのはどうなのかな、と感じる。
ボーカルもほやっとして抜けにくい声質だからなのか、パッツパツのしゃりっしゃりになっていて、もうちょいナチュラルに仕上げてもいいんじゃないの？っていう感想だ。
で、ここまでパッツパツになっていながらも、全体的に音圧感はない。
はい、ここで勘違いされそうな単語「音圧」が出ました。音圧っつーのはマスタリングにおける海苔波形がどうとかって話ではなく、一つひとつの音色がもつ太さやスピード感、ヌケ、煌びやかさのことだ。パワーというか。
全体的に音が細いんだよね。圧倒的な素人感というか、ちゃんと音作りしてないなーってのがすごく分かる。
で、ここまでいろいろ書いてきたけど、例のプチ炎上したツイートに関連して「スマホとかで聴いてる層をターゲットにしてるからそういう音なんだよ、そういうマーケティングなんだよ」という意見が見られた。
いや、違うでしょ。どう考えてもAyase氏が
「いいサウンドを知らない、いいサウンドの作り方を知らないだけ」
でしょ。
確かに彼が作る音楽を好んで聴く層というのは中高生が多いのは事実だ。そして当然高価なオーディオ機器など持ってはいない場合がほとんどだ。今の時代なら、スマホとワイヤレスイヤホンで聴くという人が多いだろう。
だが、だからといってそういった層が気づかないような部分のこだわりを捨ててしまうというのは、作品としての完成度を下がるだけでしかない。もっとも、この場合はそのこだわり方もまだよく知らない段階だと思うが。
私は「スマホ向けのサウンドに仕上げる」ということには普段から疑問を感じている。クリエイターたるもの「どんな環境で聴いても最良と思えるものに仕上げるべき」と考えているからだ。それに、スマホのフィルターに通してしまえばそれは勝手にスマホの音になるわけで。
過去の名曲をスマホで聴いたら、その魅力は劣化するか？そうではないはずだ。Steive Wonderの曲はグルーヴを失うか？浅倉大介のアレンジは煌びやかさを失うか？Dream Theaterのサウンドは分厚さが薄れるか？
つまりあれよ、クリエイターたるものクオリティは追求し続けてほしい、という話だ。
じゃあどんな環境においても最高のサウンドに聞こえるようにするためにはどうするか？何よりもまず、作る人間がそれをしっかりジャッジできるモニター環境を構築する事だ。
Ayase氏の制作環境がMacBookにヘッドホン直挿し、というツイートがバズったことを知っている人は多いと思うが、私はそれを見て非常に納得した。
誤解してほしくないのだが、私は別にそんな環境で曲を作ることが悪いと言いたいわけではない。お金なければその中で頑張るのは当たり前だし。
ただ、もう一つ誤解してほしくないのは「いい曲を作るための環境構築にお金をかけなくても良い」というわけでもない、ということだ。
例えばいいオーディオIFやスピーカーを買うことによって、それまで聞こえなかった音が聞こえるようになる、というのは当たり前だがよくあることだ。私もそこまでお金をかけられているわけではないが、現時点でミドルクラスくらいのモニター環境は構築できているとは思うので、その実感は何度も味わってきた。
つまり「できることを増やす」ためにある程度投資した方がいいということだ。SEに置き換えれば、シングルコアCPUにメモリ2GBのクソスペPCじゃ仕事にならないのと似ていると思う。
ただまあ、直近のインタビューではある程度機材を導入したりしているような回答もあったので、これからAyase氏の作る音楽がどうクオリティアップしていくのかは…………別に興味ないか……。
私もそのうち気が向いたら「夜に駆ける」のアレンジでもやってみるかね。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
303あとで/2884users 財テク (住宅購入編) – shunirr | Scrapbox
293あとで/2732users 「なんでこの機能、Windowsに標準で入ってないの？」という神機能が特盛！Microsoft公式ツール「Powertoys」を解説 – すまほん!!
288あとで/1823users 質の高い技術文書を書く方法 - As a Futurist...
276あとで/3000users 闇市化するAmazon「裏コマンド検索」で絞り込む | ラジオライフ.com
269あとで/2424users 2020年「はてなブックマーク年間ランキング」トップ100 - はてなニュース
254あとで/1909users 【図解】前年と違うよ！ 令和2年分「源泉徴収票」の見方 - INTERNET Watch
248あとで/1275users 総務省、社会人のためのデータサイエンス入門を無料開講 | Ledge.ai
244あとで/1522users 3Dモデリングソフト「Blender」の操作を0から学べる1,400ページの解説書が無償公開 - 窓の杜
241あとで/3401users 浄土真宗の僧侶です。初めて書き込みます。 不慣れなため、先ほど書いた.. | anond.hatelabo.jp
233あとで/2132users 外資系企業会社員が重宝しまくっている英語関連の神ツール８選＆勉強法まとめ「めっちゃお世話になってる」 - Togetter
231あとで/1677users 読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;
225あとで/1549users 【必見】2020年に話題になったイケてるWebサービス・アプリまとめ | creive
213あとで/1266users デザイナーじゃなくても知っておきたい色と配色の基本 | knowledge / baigie
211あとで/1298users あなたが行動習慣を作りたいと思った時に読むと役に立つ記事｜樫田光 | Hikaru Kashida｜note
203あとで/1679users けしからんファイアウォールに負荷掛けたら警察から手紙きた 登大遊氏が光ファイバーの先に興味をもった理由 - ログミーTech
192あとで/1442users エネルギーがない人が新しいことをはじめる時のコツみたいなやつ｜けんすう
191あとで/1391users プログラミングスクールに通うくらいならこの本を読め10選 - ニート向けソフトウェアエンジニアリング塾
179あとで/1014users DevOps の能力 | Google Cloud
165あとで/1094users ＣＧ制作演習 - 床井浩平氏が初心者向けにBlenderの使い方をまとめた PDF （1,419ページ・288MB）を無料公開！ | 3D人 -3dnchu-
164あとで/938users プロダクトマネジメント入門 | product-development.io
147あとで/1063users 一家に一冊、『批評理論入門―『フランケンシュタイン』解剖講義』廣野由美子 (中公新書) - ゴールデンレトリバー撫でたい
146あとで/978users 私のセキュリティ情報収集法を整理してみた（2021年版） - Fox on Security
134あとで/979users 元SMAPの3人めぐって…公正取引委員会がジャニーズ事務所を「注意」した真意とは | 文春オンライン
130あとで/1179users #前澤ファンド の審査を経て、前澤さんの前でピッチした「生の事業計画書」 93ページを、PDFで無償公開します。｜鶴田 浩之 (Hiroyuki Tsuruta)｜note
128あとで/988users 『理科系の作文技術』を久しぶりに読み返し、とにかく「6 はっきり言い切る姿勢」「7 事実と意見」だけは絶対にみんな読んだ方がよい、と思った - Magnolia Tech
126あとで/1305users 2020年に泊まった温泉宿で｢部屋｣｢風呂｣｢食事｣が良かったおすすめ宿ランキングを発表する - 温泉ブログ 山と温泉のきろく
124あとで/1683users 「コロナ、お前すげーわ」現場医師が見た５つの ”新型コロナ、ここがすごい”(國松淳和) - 個人 - Yahoo!ニュース
122あとで/946users NHKの英語学習の知見がたった500円に濃縮されたNHKラジオ英会話を使わないのはもったいなさすぎる - Togetter
120あとで/804users Googleのエンジニアが「ウェブサイトの画像読み込み」を最適化する方法を解説 - GIGAZINE
113あとで/703users Prime Videoの映画やドラマ、アニメで楽しく語学学習できるGoogle Chrome拡張機能「Subtitles for LL」 - 窓の杜
113あとで/630users プログラミング言語の未来はどうなるか | κeenのHappy Hacκing Blog
バブっているのか数ヶ月に1度は財テク記事が大量にブクマを集める。今回の1位は8月にも大量にあとで読むを付けられていた人。
4か月前からこのランキングを賑わし、サービス開始から何ヶ月も経たないのにもう買収されたzenn.devだが、1月は1本もランクインしなかった。
宇野は音圧戦争の帰結や現状まではわかってると思うよ。彼が根本的におかしいのはそこじゃない。
それを技術で解決したのがYoutubeとかSpotifyとかですね。彼らは音圧が高い曲の音量を下げて、他の曲との音量差を少なくしました。揚げ物使った弁当は弁当箱のサイズを強制的に2/3にするイメージですね。そうして消費者は錯覚に騙されず本当に美味しい弁当を選ぶことができるようになりました。めでたしめでたし。
ここはめでたしめでたしの終点じゃなくて、今も音圧戦争は形を変えて続いている。音圧が高い曲の音量を下げるのを「ラウドネス・ノーマライゼーション」という。配信系プラットフォームはそれぞれノーマライゼーションのアルゴリズム（主にはLUFS、聴感上の音圧を数値化するパラメータ）を定めている。そして音楽エンジニアリング業界は、この制約上限に抵触せずにどうやって聴感上「圧のある」音を出せるか、という一種のハックに向かっている。「測定結果が-14.0LUFSを超える楽曲は強制的に-14.0LUFSまで下げる」ということがわかっているなら、そのアルゴリズムを狙って作ればいい。
君は音圧戦争を生き抜けるか？ 音楽ストリーミング時代のラウドネス・ウォー対策 (1/3)
配信時代の音楽制作〜ミックス、マスタリングの傾向と対策 – 今知るべき配信テクニック
音圧戦争から遠く離れてーラウドネスノーマライゼーションの誤解と意義
配信最適化はエンジニアリングやマスタリングだけでなく、基本的なビートの作り方にまで影響しつつあって、これなんかはテクノロジーが音楽を変えるという最新の事例といえるんだけど、それはともかくとして、この話は結局のところ「いまの聴取環境に合わせた、いまの流行り」でしかない。リスナーに目立つように、印象に残るように聴かせる最新のテクニックではあっても、音楽自体の構造が優れているか劣っているかという話とはほとんど関係ない。
ましてポップス＝popular musicの一番の評価指標は「どれだけ売れているか」なのだ。現にバンバン売れている楽曲を捕まえてきて、その音圧が今時っぽいかどうかにケチをつける行為には生産性がない。よく繁盛してる飯屋で「店が汚い、食器が野暮だ、なぜこんなに客が入っているのか」と言ってるのに近い。クレーマーがどう言おうが、料理が美味いと思った客が多ければ店は流行る。音楽評論家を名乗るなら、今の技術的トレンドに沿っていない楽曲がなんでこんなに売れているか、という分析に傾注すべきだと思う。
