↓の資料
『Domain Modeling Made Functional』(以下DMMF)はドメインモデル設計の手法を最も論理的に説明している書籍である、と個人的に感じているのですが、いかんせんF#のパワーに頼っている部分も多く、ドメインモデル設計の前にある程度F#を学ばなきゃいけないところが高いハードルになっています。(一応F#知らなくても大丈夫なように書かれてはいるのですが…)
そこでDMMFに掲載されているコードをTypeScript+Zodで実装してみたので、これを元にF#を知らなくてもDMMFのエッセンスを学んでみようじゃないか、という試みをやってみようと思います。
Metaが2023年2月に発表した大規模言語モデル「LLaMA」はGPT-3と匹敵する性能を持ち、単体のGPUでも動作可能なほどに動作が軽いことから、コンシューマーレベルのハードウェア環境でもChatGPTのようなAIを動かせるようになることが期待されています。そんなLLaMAのデータが流出したと話題になっています。
LLaMAはMetaのAI研究組織であるMeta AI Researchによって開発された大規模言語モデルです。OpenAIのChatGPTやDeepMindのChinchillaなど、従来の大規模言語モデルを動作させるためにはAIに最適化したアクセラレーターを複数台使う必要があったのに対し、LLaMAは単体のGPUでも十分動作可能で、モデルの規模を示すパラメーター数も圧倒的に少なくて済むというのが利点。記事作成時点では、モデルデータの一部がGitHubで公開されており、Meta AI Researchに連絡すればニューラルネットワークで学習した「重み」を別途ダウンロード可能という状態です。
ダウンローダーを公開したショーン・プレッサー氏は「すでにLLaMAの重みデータがリークされたことを危険だと主張する人も出てきています。しかし、GPT-2の1.5B(パラメーター数15億)モデルがリークした時も皆同じことを言っていました。実際、GPT-2の大きな魅力が、2019年に私が機械学習について真剣に取り組む原動力となったのです。あれから4年経った2023年になって、GPT-2のリークモデルについてはもう誰も気にしていませんし、広範な社会的被害はなかったことがはっきりとわかりました。LLaMAも同様でしょう」とコメントしています。
CDNベンダ大手として知られるAkamai Technologies, Inc.は、既存のサービスを含む全サービスを「Akamai Connected Cloud」にリブランドし、クラウド市場への本格的に参入を表明。同時に新サービスとして分散型クラウドサービスを投入します。
おっ
ブコメとかツイッター見てるとGoogleのレイオフおよび労働組合の話について、誤解されている部分が少なくないようなので、需要あるかわかりませんが、中の人がすこしだけ書きなぐってみます。できるだけ中立的に書くことを試みますが、多様性のある社員のなかの、あくまで一社員の主観ですので、Single Source of Truthではなく参考程度でお願いします。
■ レイオフ＝クビなの？
解雇規制のゆるいアメリカならレイオフ＝クビです。Googleは米国以外では各国の法律にのっとって、レイオフに相当する処置を行うと伝えており、会社の現状を考えると日本で解雇（整理解雇）を行うのは相当な法的リスクを伴います。
そのためGoogle Japanは解雇ではなく、退職パッケージ（退職金と退職に伴う様々なサポートのセット）を提供する「退職勧奨」という形で対象となる人に通知を行いました。
勧奨なので、同意して退職するのも、拒否して退職しないのも個人の自由です。勧奨に２週間以内に同意するなら、退職金にかなり大きな上乗せが加えられることが約束されているので、同意しない人が少なくなるように調整されています。拒否した場合にどうなるのかは不透明です。
ちなみに日本は解雇の規制が強い方ですが、欧州や他のアジア各国と比べてとくに強いというわけでもありません。欧州にはレイオフできなかった国もあります。米国だけがズバ抜けて解雇規制がゆるい印象です。
■ 能力が低かったからレイオフされたんじゃないの？
Googleによると、今回のレイオフの直接の原因はここ数年に人を過剰に採用しすぎたため、そして現在の経済的現状が予想外であったためとしています。そして、会社の優先度を鑑みて削減対象となるロールを決定するというのが表向きの発表です。
社内での説明でも業務内容やパフォーマンスも考慮するとされていますが、直近の社内評価が悪くないと判断された人も対象になっているようなので、ポジションや運による部分が大きいように見えます。パフォーマンスといっても、本人の能力と同じくらい、仕事内容や上司との相性、そして時勢に大きく左右されるので、今回レイオフされた中で本当に「能力が低かった」といえる人は多くないと思います。
■ レイオフされるリスク込みでの高給高待遇だったんじゃないの？
Googleの日本法人は、当然ながら日本の労働基準法を遵守しながら雇用を行っているので、「レイオフのリスク前提」ということはありません。たしかに日本の企業としては高給だと思いますが、世界のIT産業の給与体系の競争で比べるなら適切（あるいはむしろ低め）な範囲かと思います。IT産業、とくにエンジニアの給与がバブり気味という点は否定しませんが、そこもレイオフとは直接関係ありません。
「レイオフされるリスク」に対する金銭的補償は、普段もらう賃金の中ではなく、レイオフに伴った「退職パッケージ」の一部として、今回は提示されています。そして、日本法人の提示した退職金は上記の２週間以内ご成約キャンペーンを考慮すると、各国の対応の中でも相当手厚い方です。（日本以外の国も、同業他社のレイオフに比べると十分手厚いと思うのですが。）
労働組合つくったりして、会社にしがみつくのに必死じゃね？
たしかにレイオフを機に労働組合ができましたが、成立過程を眺めている限り、これは会社にしがみつくためというよりは、社員を大事にするというGoogleのカルチャーを守りたいという動機をもった人がほとんどです。例えば、これまで社内でかなりの優先度で大事にされてきた「心理的安全性」は、今回の米国のレイオフ通知に伴って、一晩で吹き飛んでしまいました。会社の側には最大限の説明責任を果たしてもらいたい、雇用契約を解消するならそのプロセスはきちんと日本の法令に遵守して、日本語や日本の法務に弱い外国人社員が不利にならないようにしてほしい。そういう公平性を会社に訴える対抗手段としての労働組合である、と私は受け取っています。
加えて、組合員に過剰な「退職勧奨」を呼びかけることは違法ですので、たとえばどうしても離職したくない人や、ビザステイタスや日本での環境変化に心配のある外国人社員を、一旦法的に守る仕組みとしても期待できます。さらに組合ができることによって、会社が将来に更なるレイオフを行う可能性を低減させられるかもしれません。
実際、労働組合の立ち上げはレイオフ対象者の発表より前に行われており、労働組合を立ち上げた人とレイオフ対象者はまったくの独立です。組合成立の記者会見に出た人＝レイオフ対象者ではない（むしろレイオフ対象者の方が遥かに少ないと思われる）ので、労働者の権利を目に見える形でのオプションにした彼らの行動力を私は評価します。
■ 社内の雰囲気はどうなん？
1/20に米国のレイオフが発表されてから時間がたつので、自分の見える範囲では皆ある程度は心の準備はできていた模様です。先行する国ではなぜか優秀な人や必要そうに見えるポジションの人も切られているところを見ると、数％の確率とはいえ自分は大丈夫と確信できた人はあまりいないと思います。
ただし、日本では３月中に発表としかアナウンスされず、具体的にどのような人に、いつ通知がくるのかわからないなど、情報が与えられない部分に関する不満は大きいです。
日本では対象者に対して即日アクセス遮断にはならなかったので、発表後も誰に通知が行ってるのかは本人が言わない限りわからないので、お互いどう声をかけはじめたらいいのかも正直戸惑っている状態です。
組合は２つできましたが、その中でのディスカッションや加入するメリットについてはよく見えておらず、自分含め、該当者であってもやや静観している社員が少なくない気がします。組合に入る自由も入らない自由も両方十分に尊重されています。
えー現場からは以上です。
中国の国内で販売されているハイエンドのAndroidデバイスを使っていると、至るところで個人情報を抜き取られてしまう――そんな新しい研究結果が発表されました。
通知も同意もないままデータが収集され、ユーザーは常時トラッキングされたり、身元がたやすく明かされたりする恐れがあるとのこと。個人情報保護の点ではまるで悪夢のようだ、と指摘されています。
複数の大学のコンピューター科学者が発表した研究によると、この問題が明らかになったのは、XiaomiやOnePlus、Oppo Realmeなど中国で人気の高いスマホのメーカーすべて。それぞれのOSや、プリインストールされている各種のアプリを通じて、厳重な扱いが必要なユーザーデータが大量に収集されているということです。
収集される個人情報には、厳重な扱いが必要なものも含まれます。たとえば、電話番号や固有のデバイスID（端末識別番号やMACアドレス、広告IDなど）といった基本的なユーザー情報、位置情報（実際の現在地が明らかになってしまう情報）などです。さらには、｢社会的なつながり｣に関わるデータ、たとえば連絡先やその電話番号、通話やメッセージに関するメタデータなども該当する、とされています。
要するに、こうしたデータを手に入れれば、誰がどんなデバイスを使っているか、そこで何をしているか、どんな相手と対話しているかなどが手に取るようにわかってしまうということです。中国では、電話番号が個人の｢市民ID｣にも関連付けられているので、必然的に、ユーザーの法的な身元情報まで辿れることになります。
業務アプリケーションで日付を扱う時に日付の意味は三つに分類できる。
開始日
特定の日
終了日
それぞれの種類ごと計算判断の意味が異なる。
汎用的な同値判定や前後比較のメソッドがあればどの種類の日付も扱えるが、意図の表現があいまいになる。業務的に意味のあるメソッド名を使う方が良い。
○○の日まであと何日？や期日超過してる？みたいなメソッドはドメインオブジェクトが持っているべきという話
Raspberry Piクラスの価格とサイズやペリフェラルで、そこそこの性能のSoCが載ったシングルボードコンピューターが欲しいという要望（わがまま）を満たす製品が出だしたのが、だいたい昨年くらいからです。Arm系のSoCでも知られているAllwinnerや、前述のM5StickVを作ったSipeed、そして今回のStarFiveなどがメーカーとしては有名で、今後は他にもいろいろ出てくることでしょう。名前をあげたメーカーの製品に関しては、Ubuntuがサポートしているものもあります。
今回紹介する「VisionFive 2」は、中国のStarFive Technologyが作っているRISC-Vボードです。クラウドファンディングで資金を集め、現在では無事に一般販売が開始されています。性能は純粋に周辺機器だけ見れば、Raspberry Piに勝るとも劣らない性能を備えており、それがAmazonでも4GiBモデルなら12000円程度、8GiBモデルでも15000円弱で購入できます。
エラーメッセージが読めない新人は20年以上前からいたし、その後も毎年一定数流入してるので、まぁ。
Ruby on Rails生みの親であり最強の逆張りおじさんであるところのDHHが昨年あたりからしきりに脱パプリッククラウドの主張をしている。
これは彼らの会社が運用しているBasecampやHEYのインフラをAWSから自社保有のベアメタルサーバーへ移行しようとしているからで、実際に移行作業は進んでおり、今後5年間で700万ドルのサーバー費用を節約できるだろうという見込みがあるようだ。
MRSKは要は「SSHしてdocker startして本番サーバー運用」が実現できるRuby製のCLIで「概念的距離の圧縮や〜(妄想的DHH理解)」と同じ考え方でできたのだと思う。
自分の知識の中だとDokkuというツールにコンセプトが似てるなと思ったけど、PaaS的なインターフェイスを意識しているDokkuと比べると、MRSKはより抽象度が低くて「サーバーとDockerがあってあとはそれを操作するだけ」というレイヤーの違いがある。
起動したコンテナへのアクセスをどうやって振り分けるのかというのもTraefikという軽量リバースプロキシに丸投げしており、Railsにおける「CoffeeScriptやImport Mapsの仕様がちょうどいいから活用」ぐらいのノリに見える。
まとめると WebSocket は最終手段くらいで、可能な限りは使わない方がいい（サーバーサイドの実装が完全に WebSocket 専用になってしまう) 。ブラウザのストリーミングは Stream API を使い、通知はロングポーリングで充分。というのが自分の認識です。WebRTC は論外。
なるほど
1 on 1で「部下に困りごとを聞いても打ち明けてもらえない」みたいな話はよく聞くんですけど、上司が「困り事を聞いてあげる」て姿勢でいる限りは信頼しづらいんじゃないかなと。
上司も困りごとはあるし、部下にどう見られているか気にする「普通の人間」だと実感してもらうのが重要というか。
「打ち明けてもらえない」タイプは経験則では生真面目で、耐えず気を張っている感じで「このひとに率直に困り事を打ち明けていいんだろうか」と思っちゃうケースが多い。
みたいな感じで、相談するメリットが無さそう・相談しても無駄なリスクが発生しそうな気配があると、まぁ、相談はしたくないものである。
From interactive tutorials to full-blown IDEs, build instant, interactive coding experiences backed by WebContainers: the trusted, browser-based runtime from StackBlitz.
OpenAIの対話型AI「ChatGPT」は史上最も急速な成長で「月間1億ユーザー」をわずか2カ月で達成するなど、大いに注目を集めています。それに伴い、search GoogleがChatGPTのライバルとなる会話型AI「Bard」を発表したり、中国企業が続々とChatGPT風AIを開発していると報道されている一方で、OpenAIはChatGPTのコードを公開していないためChatGPTを効果的に複製することは難しくなっています。AIのディープラーニングトレーニングを最適化するオープンソースプラットフォームのColossal-AIが、ChatGPTトレーニングプロセスをわずか1.6ギガバイトのGPUメモリで7.73倍高速なトレーニングに再現したと告知し、オープンソースで公開しています。
ソフトウェア開発におけるチームワークとかマネジメントの大切さとかはわかるけど、単に一人で全部作ればいいだけでは？ という解決策、実はかなりスケールするし、より良いものができることが多いと思うんだよな。
特にまだ使える状態にも至っていないプロダクトを複数人で慎重に書いて入念にコートレビューしたりたりするのはあまりいい考えとは思えない。レビューなんかいらないからコードを変更しまくって取りあえずいい感じになるまで完成させるほうが優先度高い。
プロトタイプとかPoC的なものならその通り。
しかし、本番運用に乗ったシステムでそれをやると逆にリスク。
リリース日を気にしないって言うけど、顧客や外部チームとの調整はどうやってるのだろうか？ ベストエフォートでやりますは通用しないと思うのだが。
記事中のFAQでも結局質問に回答せず論点をずらしているのが気になる。
どっちかと言うと、家庭や学校で何度も何度もレトリカル・クエスチョンに晒されることが原因である気がする。
こんな頭の悪いプロジェクトは20年前に死んだと思ったのだが、富士通案件に当たってしまいまだ生きてたので報告しておく。
・業務をシステム化する意思が微塵もない
・SDEMという富士通が対外的に歌ってる開発フローがある
・それはメールとエクセルのレビュー票でしか管理されない、ゴミだ笑
・ワークフローツールとか知らないんだと思う
・現在の担当者、ステータスを見える化しようとする意思は富士通にはない（バカなのだろうか）
・富士通は「レビュイーがレビューして欲しいものを管理するエクセル資料」を新たに創設してなんとかしようとしている
・とにかくメールとエクセルじゃないと嫌なのである 業務の見える化、業務を定義してシステム化して誰もがいつでも監視できる仕組みなんていくらでもあるのに、メールとエクセルで頑張ろうとしている。
戦艦ヤマトかな？と思ってる。
このたび、当サイト（www.sourcenext.com）におきまして、第三者による不正アクセスを受け、お客様のクレジットカード情報112,132件および個人情報120,982件が漏えいした可能性があることが判明いたしました。
お客様をはじめ、関係者の皆様に多大なるご迷惑およびご心配をおかけする事態となりましたこと、深くお詫び申し上げます。
クレジットカード情報および個人情報が漏えいした可能性のあるお客様には、本日より、電子メールにてお詫びとお知らせを個別にご連絡申し上げております。
なお、個人情報120,982件が最大漏えい件数となりクレジットカード情報112,132件はこれに含まれております。
弊社では、今回の事態を厳粛に受け止め、再発防止のための対策を講じてまいります。
お客様をはじめ関係者の皆様には重ねてお詫びを申し上げますとともに、本件に関する概要につきまして、下記の通りご報告いたします。
派手なの来ちゃったな
「なぜここで1を加算してるんでしょうか？」
とか、
「シャドーイングってご存じですか？」
みたいなコードレビューコメントって、純粋な質問であっても受け取り方によっては詰問してるように聞こえたり、嫌味を言ってるように聞こえたりするので、テキストコミュニケーションって難しい。
コードレビューにおいて疑問文が詰問に聞こえちゃうパターンなので「純粋に質問」を冒頭に付けてみた。
「なんでtrueにしたんですか？」が「普通はやらないでしょ！💢」に聞こえてしまう日本語の難しさよ……。
「テキストから相手の意図や人格を推察するのをやめればよい（書いてある事のみに反応しろ）」みたいな事を言う人もいるけど、その場合、「質問の意味がわかりません」「はい/いいえ」みたいな回答になってコミュニケーションコストが異様に上がってしまう問題がある。
結局、スムーズにコミュニケーションを取るには、ある程度相手の意図や疑問点を慮っていく必要はある。
自分の場合は「このようにしている意図はなんですか？自分は〜のような問題を生じる可能性がありそうだと考えました」みたいな言い回しをすることが多い。
イベント駆動アーキテクチャの入門コンテンツ
コードレビューではよっぽどの理由がない限り質問はしないなぁ。疑問がある場合は、パッチの説明文やコメントに理由を書いてもらったほうが、後で第三者がコードや差分を読む際に有益だと思う
これは確かにそうだ
見積もり
見積もりというのは予測。 ある条件の場合、これくらいの時間がかかると思われますというもの。 約束ではなく予測であり、確率だということが重要。
コミットメント
自分たちが、いつ、何を届けるのを約束すること。 ビジネスパーソンとして約束。
ターゲット
ビジネス上の目標。 X月にはリリースしないとネガティブインパクトがあるとか。
チームだったり個人の特定の期間での目標設定を決める組織はとても多いと想います。しかし、目標設定は簡単そうでとてもむずかしいものです。
なぜなら、目標を高くしすぎると目標未達という結果になったり、そのために目標を低く設定してしまおうと心理的に働いたりしてしまいがちです。
さらに、目標設定とだけ言うととてもスコープの広い話になってしまいます。
「目標設定しましょう」というは結構スコープのでかい曖昧な表現なので、「今の課題って何？それをどう解決していこうか？」とすれば大体自然とフォーカスブレずに納得感あるやることが決まります。
総務省の有識者会議は6日、携帯電話などの通信サービスで、法令上の「重大な事故」が起こる恐れがある場合に、事業者に報告を求める制度の考え方を示した。障害の発生後に報告する今の仕組みに加える形で導入する。通信が暮らしや経済に欠かせない基盤となる中、事故を未然に防いだり、被害を抑えたりすることを目指す。
新たな制度は、2022年6月に成立した改正電気通信事業法に基づく。報告を受けた総務省が必要に応じて助言するほか、他の事業者に注意喚起したり、有識者会議で検証したりすることを想定している。
「『重大な事故』が起こる恐れがある場合」と「通信障害、事前に報告要求」は大分意味が違ってくる気がするが。
要するにルーターやロードバランサの交換をする時は事前に連絡しろという事なんだろうけど、その報告を受けて総務省に何かできる事あるのか？ という気はする。
このことについてニュースサイトのArs Technicaは、Samsungのソフトウェア部門はコードの品質が低く、変更点がわずかであってもAndroid全体に適用するような更新ファイルを出すことや、Samsungは独自のエコシステムを形成しているかのような体裁を取っていて、契約上、Samsungエコシステム内でもGoogleのアプリを含める義務があるためにGoogleのエコシステムとSamsungのエコシステムで二重に同じアプリがインストールされていて削除不可能であることを理由として挙げています。
このほかに、デバイス内のスペースを「クラップウェア」と呼ばれる迷惑アプリ経由で販売していることも要因だとのことで、クラップウェア経由で販売されるスペースの容量は国や事業者によって異なるため、個々人により使用されている容量が異なるという結果になっています。Ars Technicaのロン・アマデオ氏は、Galaxy S23 Ultraがクラップウェア用に確保している容量を最大で1TBだと報告しています。
なお、平均して60GBを占めるSamsungのシステムファイルですが、機能としては15GBほどのPixel 7に劣っていると指摘されています。たとえば、2016年にAndroid 7で導入されたA/B(シームレス)システムアップデートに用いられるパーティション機能をSamsungは主要OEMで唯一実装していないため、システムアップデート時に通常ならバックグラウンドOSに切り替えることで更新時のダウンタイムを30秒の再起動のみに抑えていますが、Samsung端末は再起動を含めて30分のダウンタイムが発生するとのことです。
可能なら独自OSに移行したいだろうし、色々やってるのだろう
概要
本ツール群は Mozc-UT (Mozcdic-UT) を失ったことによる損失を埋めるための「緊急避難」として使うために作られた。
本ツール群はMozc外部のリソースからMozcシステム辞書を構築する。 これをMozcに組み込んでビルドすることにより、Mozcの語彙力を増加させることができる。
本ソフトウェアにそのようにして生成された辞書は 含まない 。 また、 Mozc本体も含まない 。
このようなソフトウェアにするのはいくつか理由があるが、まず本ソフトウェアが、東風フォント事件におけるさざなみゴシックのような「緊急避難」であることを理解してほしい。 つまり、何年かかるかは分からないが、安定した開発が行われる、優れたかな漢字変換ソフトウェア及び辞書が誕生するまでの「つなぎ」である。
その意味で「つなぎ」として機能しやすいようにこのようなソフトウェアにした。 これは、Mozc以外のソフトウェアからもMozcシステム辞書からの変換とすることで利用しやすいようにし、かな漢字変換ソフトウェアの発展を促す意味もある。
Mozcdic-UTとの大きな違いは以下になる
- オープンなプロジェクトであり、ライセンスがGPL v3である
- ソフトウェアは辞書生成のためのツールであり、生成された辞書ではない
- Mozcdic-UTは一般名詞のみを対象とするが、Mozcdict-EXTは品詞を制限しない
おぉー
欧州議会では、メールやチャットサービスの提供者に通信内容の監視を義務付ける「チャット規制法」が議論されています。このチャット規制法について「規制対象がオープンソースOSのパッケージ管理システムにも及んでおり、既存のOSが違法状態になる可能性がある」という懸念が指摘されています。
チャット規制法は2022年5月に欧州議会に提出された法案で、メールやチャットサービスの提供者に対して「通信内容の常時監視」「年齢確認の実施」などを義務付けることを目的としています。この法案では通信暗号化の有無に関係なく通信内容を監視することが求められるため、「プライバシーの侵害につながる」「虚偽の報告による誤審のリスクが高まる」といった理由から法案に反対する声も多く寄せられています。
チャット規制法の問題点は、「法案の規制範囲が広すぎる」という点にもあります。法案ではメールやチャットサービスの提供者だけでなく、アプリケーション配布プラットフォーム(software application stores)も規制対象となっており、該当プラットフォームにも年齢確認や年齢制限を義務付けています。
EUも中国みたいになってきたな。
米Twitterは2月2日、Twitter APIの無料提供を9日で終了すると発表した。対象になるのはバージョン1.1、2の両方で、代わりに有料版を提供するとしている。同社の開発チームのTwitterアカウント（＠TwitterDev）が明らかにした。
サードパーティーのアプリやサービスを滅ぼしたい感じなのだろうか。
ChatGPT PlusはChatGPTのパイロットサブスクリプションプランで、月額20ドルで利用でき、サブスクライバーは以下のメリットを享受できるとのこと。
・ピーク時でもChatGPTへの一般的なアクセスが可能
・応答時間の短縮
・新機能とアップデートへの優先アクセス
ただし、記事作成時点ではChatGPT Plusはアメリカのユーザーのみ利用可能で、利用希望のユーザーは以下のウェイティングリストに参加すればOK。ウェイティングリストからユーザーを招待するプロセスは今後数週間のうちにスタートし、その後、アメリカ以外の国と地域へのアクセスサポートも拡大していく予定です。
おぉー
1月28日午前4時ごろから約80時間にわたって障害が発生しているKDDIのクラウドサービス「KDDI クラウドプラットフォームサービス」。同社は31日、完全復旧に2週間以上かかる可能性があると明らかにした。
障害は「jp2-east05」ゾーン（リージョンを構成するサーバ群の単位）の一部サーバでストレージが故障したことで発生した。ただし、原因はハードウェアではなくソフトウェアの問題という。
確かにこの様では国産のガバメントクラウドなんて厳しいのかもしれんな。
3年前、「kintone」や「Garoon」などを手掛けるサイボウズの開発本部が発した「マネージャーをなくす」宣言。多くのエンジニアを抱える大所帯で、業界でも先駆けとなる組織階層の撤廃は、大きな驚きをもって受け止められました。職能ごとに整理された組織から、プロダクトごとにアジャイルで開発できる組織へ——そんな方針のもと、フラットな組織づくりへと舵を切ったのです。
マネージャーポジションをなくした結果、採用や給与評価、健康管理など難易度の高いタスクが組織運営チームに一気に集中したんです。(中略)結果、わずか6名で約200名のピープルマネジメント業務をこなす状況になってしまいました。
2022年の始めに組織改善プロジェクトを立ち上げて、まず一度サイボウズにあるべきマネジメントの形について責任者を集めて考え直しました。話し合う中で出てきたのが、1人がマネジメントできるメンバーの数は、せいぜい5〜8人程度だということ。となると、200人の組織には、できれば40名くらいマネージャーが必要な計算になります。そこで、階層型のマネジメント組織をつくることに舵を切りました。
ところが、このwebpackの開発は事実上終了しており、開発者は現在Next.jsの開発企業であるVercelに移籍して、後継となるTurbopackの開発に取りかかっています。
Tobias氏はブログの中で、webpackは10年前のニーズを念頭に開発されたものだったと振り返ります。
もはやwebpackの後方互換性を維持しながら、webpackを進化させていくのは困難だったと説明が続きます。
webpackはNode.jsを基盤としたJavaScriptで開発されています。しかしJavaScriptベースのアプリケーションはCPUインテンシブな処理においてマルチプロセッサ搭載マシンの能力を十分に引き出すことは困難であるとTobias氏は指摘します（おそらく大量のモジュールの依存関係を解決する処理がCPUインテンシブなのだと思われます） 。
アーキテクチャは差分だけをビルドすることで効率的なビルドが可能になるインクリメンタルビルドには適しておらず、プラグインが何でも出来るようになっていてwebpackへの依存が大きく、それゆえに後方互換性のために大きな変更が難しく、キャッシュの無効化はセンシティブで影響が大きく、キャッシュのルックアップコストが大きいためモジュール数が増えるとそのコストがばかにならなくなってくる、といった指摘が続き、前述のようにこのままでは大きな変更は難しかったと説明。
式年遷宮みたいなもんか。
移行しやすければ何でもいいけど。
他社に常駐する形だと、どんなに知識を得て、信頼を得ても、現場の社員以上の責任も権限も得られないのがわかるだろうか。私自身は、何回かの「協力会社社員」の経験を経て、30代半ばで元請側に行くことになる。
結局は、主役になれない、責任を持てない、と言うことに対する課題は、転職でしか解決できない。人を送り出している会社が、自分で責任を持つ事業を行うことって、かなり難しいこと。商売の根本から違うためだが、この辺りの差は今回は述べない。
SESとか下請けやってる企業の問題はここに集約されてしまう。
エンジニア個人としては会社のビジネスそのものを変革するのはハードルが高すぎるので、自社で本物のビジネスをやってる会社に転職してしまうのが一番良い。
SESや下請けを取っ掛かりにして、転職でステップアップしていく人生スゴロクも楽しいものだ。
量が質に転換するというのは何事にもあるものなのだな。
個人的にはスマホにモバイルディスプレイとキーボードを付けて作業できるようになって欲しさある（現時点でも一応できるけど）。
あるいはラズパイサイズのSBCをいい感じに持ち歩くとか。
asdf を使えば、任意のディレクトリに紐づく言語のバージョンを指定でき、そのディレクトリに移動したタイミングで、当該のバージョンへの PATH を自動で通すことができます。
一方で、WEB フロントエンドやモバイルアプリなど、本番環境で docker を利用しないシチュエーションというのも存在します。そのような場面でも、各開発者間の環境差分をなくすという観点から、 開発環境として docker を利用するメリットがあります。一方で、ディスク I/O が遅いといったパフォーマンスなどのデメリットが存在するのもまた事実です。 特に iOS アプリ開発に関しては、macOS の docker image が公式に存在しないことから、開発を docker 上で行うことは困難を極めると言っていいでしょう。
そのデメリットがメリットを上回ったと判断される時、ローカル開発環境としては docker を利用せず、各開発者の PC 上で環境を用意する運用となります。 その場合、リポジトリの README などに言語やツールのバージョンを記載し、各開発者がそのバージョンをインストールするよう求められることになりますが、asdf を利用すれば、asdf install などのコマンドで全てのツールを一度にインストールすることができます。
ふーむ
Dockerが使えるならDockerを使えばよさそう。
文中でも触れられてるように、Docker Imageが存在しないMac系の開発の場合は有益っぽい。
これは私見ですので、異論のある方もいると思いますが、あえて断定します。
「中小企業っぽさ」とは「すぐに目に見えて売り上げのあがること」にしかお金をかけない（かけられない）会社のカルチャーのことです。
規模や文化、ワンマン社長か否か、キャッシュリッチかどうか、そういった話とは全く関係がありません。
「で、それってすぐに儲かるの？」
というセリフが出る経営者のもとで育つカルチャーが、その本質です。
いくら社員が多く、こぎれいな会社であっても、「すぐにリターンを求める姿勢」が顕著だと、必然的にこういう会社からは、「小さくまとまって停滞している雰囲気」が醸し出されます。
特に、上でいうところの「中小企業っぽい会社」は、人への投資をほとんどしません。
直接のリターンが見えないですし、いつ将来に不安を抱いた社員が辞めるかわからないからです。
IT企業だとSESで人材の手配師に安住しちゃう会社だとか、「今いる人員でできる仕事」に全振りしちゃう会社だろうか。
まぁ、「儲かってればいいんだよ」という理屈は分からないでもないけど、10年後も会社が存在している保証のない時代で会社と運命共同体をやるのは中々難しい。
「良い会社」を見つければ将来安泰という時代でもないので、エンジニアは常に転職できるよう準備しておく・定期的に転職することでスキルが停滞しないようにするなどした方が結局は無難だろう。
スタートアップは金が無いので（エンジニアとしてはレベルの低い）創業者がコードを書いたり、知り合いのフリーランスに頼んだりするので、保守性の観点が抜け落ちた設計になりがち。
そりゃまぁ、そうなんだが。
大規模データベースのリーク情報やハッキングツールなどを提供する場として人気のサイバー犯罪フォーラムBreachForums上で、borderline2023というユーザーがYandexの40GB超のGitリポジトリをリークしたと主張しています。
YandexのGitリポジトリをリークしたのはborderline2023というユーザーで、「リポジトリのみ、データなし、44.71GB。スパム対策ルールを除いてほぼ完全にコピーしました。2022年7月に私がダウンロードしたものです」と投稿しています。この投稿に対して、BreachForumsユーザーからは「かなり素敵に見える」「多くの興味深いツールがある」などのコメントが寄せられています。
根こそぎやられてて草
キレイなコードが会社を潰す
壊滅状態なプロジェクトをチェックさせていただく機会があるのですが・・・
そこにあるのは○○○なテクニックを思う存分にふるった俺が考えたキレイなコードの残骸です。簡単なことを面倒くさく難しく書いた、ちょっと弄るとバグがでるコードです
保守性の低いコードはキレイなコードとは言わないんだよなぁ
DeepMind Technologiesは、コード生成人工知能（AI）の「AlphaCode」を開発。 AlphaCodeはプログラミングコンテストでほぼ中央値となる成績を収め、人間と同レベルのコーディングスキルを持つことを示した。2022年2月2日の公式ブログで発表されていたが、このたび12月8日に、AlphaCodeについての論文が『Science』に掲載され、表紙を飾った。
AlphaCodeは競技プログラミング向けに作られたシステムだ。競技プログラミングでは、批判的思考、論理、アルゴリズム、コーディング、自然言語理解を組み合わせて、予期せぬ問題に対する解決策を創出することが必要となる。予期せぬ問題に解決策を見出すのは、従来の機械学習コミュニティにおいては難しい課題だった。
おっ
とりあえずは競技プログラミング領域か。
早く職業プログラマの仕事を奪って欲しい。
本来システム開発は分かってる人間が一人でやる方が効率がいい。
しかし、一人ではこなせる作業量に限界があるので「仕方なく」チームで開発している。
将来的に人間の代わりにプログラミングできるAIが登場するなら、一人のエンジニアの能力をいくらでもスケールアップさせる事ができるようになるので、開発効率は途轍もなく向上することになるだろう。
■ 私分かりませんから全てお願いしますは止めろ
コンサルも込なら良いが大体は要件定義からだ。つまりお前らは要求定義は出来ている前提だ。なんも分からないから経営層や現場との橋渡しのみなら邪魔だから今すぐSE名乗るの止めて仕事辞めて田舎で畑耕せ。
■ 自社の業務は理解しておけ
AccessやFilemakerで弄れる程度でSE名乗るならせめて自社業務の流れや種類は把握しておけ。何聞いても現場に確認しますじゃ時間かかるんだよ。なんなら分かるんだ？別に業務フロー寄越せとか言ってないぞ。
■ 要求を理解しておけ
割とマジで自分が経営層から何をシステム化してほしいのか分かってない奴が多い。体感5割以上。最近じゃインボイス対応。インボイス対応してください言われて現状や影響箇所は何をしたいか聞いたら「さぁ？」って言う。じゃ、何しにきた。挙句に「そのやり方も提案するのがシステム会社でしょ！」とキレる役職者まで。コンサルは契約に入ってないんだけどな。ちなみに別の会社でシステムのお偉いさんしてたとか言ってたがExcel方眼紙使ってたので速攻無能確定。おまけに技術も知識もアップデート出来てないし平気で偽装派遣みたいなこと言ってくる。前の職場どんなとこだよ
■ マウント取るな
クラウドとか言語とかアーキテクチャとかフロントエンドもバックエンドも何も知らないなら勉強しろとも言わないが分かった風の口聞いてググった程度の知識でマウント取るな。むしろ都度説明求めろ。
■ 悪魔の証明させるな
ランニングやイニシャルコストの話で妥当かどうかをこっちに証明させるな。お前らで判断しろ。少なくともボッタクっては居ない。あと逆に原価厨みたいに人件費等々無視した計算もすんな。人はタダじゃない。
■ 業務時間外に連絡すんな
小売りとかだと土日もやってたりするけど対応ほしけりゃ契約時に言え。割り増すから。電話やメールでなくて後日文句言うな。あと平日業務時間外にZoomとかやるな。金寄越せ。
■ 感情論とか止めろ
要件漏れとかあってこっちがリスケ等を要求しても承知しないでキレたり三顧の礼したりするの止めろ。そのバカみたいな時間を社内調整に回せ。夜の22時とかに泣きながらZoomでお願いしに来るな。不動産営業にでも転職しろ。
■ ちゃんと確認しろ
要件定義書、設計書、テスト仕様書、その他いろいろ作って会社で確認してもらってるよね。読め。だいたい書いてある。仕様漏れとかでこっちが記載してる言って読んでないってキレるな。あとどこの企業も読んでないとか言うな。ちゃんとしてるとこは読んでる。
■ アジャイル開発を何だと思ってる
大体馬鹿なユーザー企業はアジャイル開発何も知らないくせに「要件定義要らない、数週間で出来る、ドキュメントも要らない、仕様変更簡単」と思ってる節がある。なぜか最初にアジャイル開発で～とか言ってくることも。何もできないならウォーターフォールの方が数倍マシだぞ。アジャイル開発だとお前の役割重要になるんだぞ。ちゃんと管理出来るんか？だいたい動き出してからウォーターフォールの動き求めてきたりするw
ちゃんと要求まとめて要件定義から参加して受入まで出来たり、アジャイル開発ができるユーザー企業の社内SEなんて日本の中小企業の1割にしかいないと思っているので、自信ない人は是非パッケージに頼るかもっとたくさんお金払って全部お任せにしてください。
どっちも無理なら退職して熊本に出来る半導体工場で地道に半導体製造の職員として働けば？
ニトリの社内SEニュース見て思ったので書いてみた。自分は取り組みとしては良いと思う。
クリエイターに有償でイラストなどを発注できるサービス「Skeb」を提供するスケブ（東京都千代田区）は1月23日、2022年12月に発生した障害について「セールスフォース・ジャパン担当者との協議を経て、完全に解決した」と発表した。原因がクラウドサービス「Heroku」の障害でないことを確認したという。
Skebでは12月23日から24日にかけて障害が発生。当時の発表では、原因はHerokuのアカウントにあったとしていた。ただし詳細に不明点があり、解決後も問題の経緯を探っていたという。
スケブによれば、セールスフォース・ジャパンは障害の解決後、12月28日にスケブを訪問。原因がHerokuの障害ではないことを確認した他、セールスフォース・ジャパンが当時把握していた状況について説明を受けたという。その後協議を経て、1月23日に問題の解決に至ったとしている。ただし障害が起きた実際の原因については説明していない。
障害ではないが、納得できる（あるいは一定の合意に達する）理由で、それ自体は非公開ってどういう話なんだろうか。
ストライキでも起きてたのか？
ストレージ周りの制約をぜんぶリポジトリ層に閉じ込められる、モデルのレイヤーはそういうのとは無縁でいられるというナイーブなオブジェクト指向感覚。データ量がすごい少ない規模のコーディングしかしたことない、とかでなければそういう考えのままでいられることはない気がするのよな。
大規模になればなるほどデータの移動とかフィルタリングとかがボトルネックになるので、データ中心の設計になっていくよね。あとはクラウドネイティブ。うまくスケールするための設計とかも、データ中心設計が必要。RDBを活かすのもNoSQLを活かすのもデータ中心設計が必要。
僕は国内で完結するサービスしかやったことないけど、プラネットスケールになると結果整合性をいかに担保するか、みたいな勝負になってやはりデータ中心になるはず。
「パフォーマンスのためにシャーディングとか考え出すと、ソフトウェアに対する変更要求はどでかくて大変ですよねーーー」みたいな話を今日ちょうどお客さんと雑談してきたところである。
例えば、AWSのAuroraを使ったシステム。今からやろうとしている操作が全部読み込み操作なのか、そうじゃないかで、リードレプリカ側につなぐかプライマリに繋ぐべきかが決まる。リポジトリ層1つで全部隠蔽して解決するには、これから起こる未来のコードを知らないといけないわけだ。
少なくとも、リポジトリ層に全部隠蔽できる設計手法は、どう背伸びしても、シャーディングが必要な規模には不可能というわけだ。NoSQL使う場合も、検索条件が増えたりするのに弱いのでそれを踏まえた事前設計が必要でそうでないなら、主キーでデータ取ってくる程度のクエリーしか無理なんじゃないかな
完全フルハンドメイドを目指していたはずが、なんか鋳造とかで同じ品質のものが大量生産できてしまう事に気付いてしまった時のやるせなさみたいなのは分かる。
まぁ、それはもう仕方無いので受け入れていくしかない。
システム開発もいずれはそうなるだろうが、それならそれで別にいい。
Googleは、Androidがオープンソースライセンスで提供・開発が進められているアーキテクチャのRISC-Vをサポートすることを宣言しました。Ars-Technicaが伝えました。
AndroidのエンジニアリングディレクターであるLars Bergstrom氏は、RISC-Vのサミットにて、AndroidがRISC-Vに対応するためのロードマップを公開。正式なサポートは今後数年かかるとしていますが、同氏はRISC-VがArmと同等のプラットフォームになることを望んでいるとしました。
また、同サイトは「Armは不安定なビジネスパートナーである」としています。スマートフォンのCPUのアーキテクチャはArmが掌握していますが、Armを所有するSoftBankが、非常に大きな影響力を持つNVIDIAにArmを売却しようとし、最終的に競争阻害などの理由により断念しています。その後も、自らの大口顧客であるQualcommとその子会社のNuviaに対し訴訟を起こすなど、かなり後ろ暗いニュースが続いています。
くわえて、Armそのものは英国企業、そして親企業のSoftBankはもちろん日本企業なのですが、米国の輸出法が適用され、Huaweiに対する輸出制裁に巻き込まれたことも。反面、RISC-Vはカリフォルニア大学から始まったオープンソースプロジェクトで、米国の輸出法の対象にはなりません。
RISC-VのメンバーにはIntelやGoogle、Qualcommなどが名を連ね、同時にアリババやテンセント、ZTEなど中国企業も参加しており、この状態で米中貿易戦争において、RISC-Vの存在がどちらか一方に有利に働くことがないことを主張しています。
ふむ。
いずれにしてもソフトバンクはろくでもない。
重視したこと
- 断片的な用語やパターンの解説でなく、ドメイン駆動設計の全体像と要点を伝える
- 全体像を伝えるための図や表を多めにした（ソースコードの例は少ない）
- 全体像と要点は、原典である『エリック・エヴァンスのドメイン駆動設計』（以下『ドメイン駆動設計』）の説明を中心にした
- ドメイン駆動設計の具体例として『ドメイン駆動設計』に出てくる国際海上貨物輸送の具体的な業務知識の解説を多めにした
- マイクロサービスなど分散アーキテクチャとドメイン駆動設計の関係など、新しめの内容を盛り込んだ
いつもご利用いただき、ありがとうございます。
誠に勝手ながら、「GYAO!」「GYAO!ストア」「トレンドニュース」は、2023年3月31日（金）午後5時をもちまして､すべてのサービスを終了いたします。
（終了時刻は、状況により前後する場合がありますので予めご了承ください。）
各サービスをお楽しみいただいているお客様には、多大なご迷惑とご不便をおかけすることとなり､誠に申し訳ございません｡何とぞご理解くださいますようお願いいたします｡
また、サービス開始より多くのお客様にご支持いただきましたことに、運営チーム一同、深く御礼申し上げます。
サービス終了まで短い期間ではございますが、「GYAO!」「GYAO!ストア」「トレンドニュース」を引き続きお楽しみいただけますと幸いです｡
Gyaoサービス終了か
SpaceX社が提供している衛星通信ネットワークサービス｢Starlink（スターリンク）｣が、2023年1月13日に突然の大幅値下げを実施しました。
その価格は、なななんと月額6,600円。もう一般的なプロバイダーと大差なくない!?
ある程度ユーザー数を獲得したら一気に値上げするのが目に見えてるのがなぁ
ドメインモデリング、未だに思考の流れがよくわからないんだよな。
インプットとなるユースケース図から最終成果物のクラス図に至る流れが全然分からず困惑してしまう。
個人的にはユースケースからエンティティを検討→ER図に落とし込み→データ構造（DB）を確定→DBを元に集約やバリューオブジェクトを作成...の方がしっくりくる。
結局のところアプリケーションはデータの永続化が一番大きな関心ごとになるので。
途中形態のクラス図を見せられてもなぁ...感は否めない。
優秀な人だけどコミュニケーションスキルがイマイチというか口調が無意識に攻撃的な人の改善要望は辛すぎる。技術とか内容ではなくて人間の好き嫌いになってしまうし、お互いがお互いの言い分があるのだけどこういうパーソナリティの指摘はモチベに直結するので切り出し方も伝え方もホントしんどい。
1分間マネージャーにあるような褒めてその後叱責、そしてフォローというセオリーな流れで行きたいけど、対象がキーメンバーだとフォローに失敗した時のリスクは組織の生産性に直結する。そしてそれが組織のキーメンバー同士の問題だと対処処理の失敗は許されない。カイジの鉄骨渡りくらいシンドイ。
しかしどうして組織のキーメンバーはすぐに対立関係になってぶつかるのか。頂点には1人しか立てない訳でもないと思うのに。世界はやはり両雄並び立たずなのか。戦わないと生き残れないとか訳でも無かろうに。漫画的な展開はいらないので仲良くして欲しいですけど。無理なお願いしてないよね。トホホ。
自分の縄張りをちゃんと確保できないと人は争うものなので、キーパーソンにはそいつをさっさと管理職にしてしまうのがよい。
医療関係に限らず、業務用アプリケーションというものは見栄えのいいUIより、情報を詰め込んだ実用一点張りのUIの方が好まれるものである。
空白を贅沢に使う「見せるデザイン」よりは情報をギチギチに配置したダッシュボードのようなUIの方が結局は選ばれる。
何故なら、一日の大半そのアプリケーションを使っているので嫌でも操作に習熟するし、日常的な作業で画面遷移やフォーカス移動を繰り返すのは地味に面倒なので、最初から全ての情報が露出している方が操作の手数が少なくて済む為、楽なのだ。
結論から言うと受発注の関係性でアジャイル開発やるのは完全に間違えてる
受注側が優秀だと発注側の意思決定の遅さにイライラするし
受注側が未熟だと発注側のイメージが具現化されない
第三者的に両方の場合に遭遇したんだが記録しておきたい
■ 受注側が優秀な場合
スプリントのスピードが速すぎて発注側の意思決定が間に合わない
評価用のボタンを作成するときにGood/BadにするかGood/Normal/Badにするかを決めるだけで2週間かかる
本来なら意思決定者がミーティングに出て欲しいが日本企業は権限委譲しない会社ばかりなので
最終決定は上役の偉い人になるが、そういう人はなかなか捕まらないので意思決定が遅くなる
「意思決定を早くしよう」ということでミーティング時間を10分に制限するとか意味不明なことをしてる
責任を下位の役職まで委譲しないとアジャイルは成り立たない
まぁなのでこういう組織にはアジャイルは向いていない
■ 受注側が未熟な場合
スプリントレビューを行うときに発注側が「こういう機能が欲しい」と言っても
受注側がそれを実現できる自信が無いとYesと言わない
もちろんその場ではTaskとして上げておいて「実際には出来ませんでした」っていうのを許容するのがアジャイルだと思うが
受発注の関係性があるとどうしてもネガティブなことはやりたがらない
はっきりとNoとは言わないが「ここのDBが」とか「このAPIが」とか予防線を張りまくる
結果としては制約が多すぎて
「これじゃぁExcelで良かったな」
っていうことになりがち
■ じゃぁウォーターフォールが良かったのか
当たり前だがウォーターフォールでの開発はとっくに時代遅れだし競争のスタートラインに立てない
逆に言うと競争が無い世界での開発ならウォーターフォールでいいだろう
そして日本企業はこれまで競争が無い分野でのソフトウェア開発ばかりに従事してた
護送船団方式で競争しないしそもそも内需で独占市場だったり
プラットフォーマーが競争しないように規制してたりして開発してきた
そんな企業がいきなりソフトウェアで競争をさせられて付け焼き刃のアジャイル開発をすることになるからおかしなことになる
日本企業はおとなしく機械だけ作って、だんだんと小さくなっていくしかないと思う
それは発注者・受注者共にレベルが低いのが問題であって、勝手に日本が〜とか主語を大きくしないでほしさがある。
AmazonやAliExpressでも販売されているAndroid TV搭載のセットトップボックス「T95」にマルウェアがプリインストールされていたという報告がGitHubに上げられています。マルウェアの正体は、Android端末を対象に感染を広げた「CopyCat」に似ているとのことです。
報告ページを作成したDesktopECHO氏は自身で開発したAndroid向けツールのPi-holeをテストするためにT95を購入したとのこと。しかし、このT95の中身が非常に大雑把なものであることがわかったそうです。Android 10はテストキーで署名されており、Google Pixel 2にちなんで「Wallye」と名付けられていたとのこと。さらにデバイスと通信するための多用途コマンドラインツールであるAndroid Debug BridgeがイーサネットとWi-Fi経由で広く開かれていることが判明。
そこで、実際にT95にPi-holeをインストールし、DNSを127.0.0.1に設定したところ、T95がアクティブなマルウェア用アドレスにアクセスしていたことが判明したそうです。
結果としてDesktopECHO氏は、T95内のマルウェアがやり取りしているC2サーバーのDNSを127.0.0.2に変更することで、マルウェアのアクティビティを監視しながらほぼ無力化することができたそうです。
中国製のAndroidタブレットやスマホを買いたくないのはこういうところなんだよな。
ファームウェアの時点でマルウェア仕込まれてたら一般ユーザーにはどうしようもできないし、工場出荷状態では問題なくてもファームウェアアップデートでマルウェア仕込まれる可能性もあるという。
スマホやタブレットは決済手段や個人情報と強く関連付けられるデバイスなので、少しでも不安のあるものは避けた方が無難である。
オープンソースのWebサーバーソフトウェアとして知られる「Apache」を運営するApache Software Foundation(ASF)に、北アメリカ先住6部族の1つであるアパッチ族を念頭に「アメリカ先住民への敬意と独自の行動規範を守るため」として名称変更の要請が出されていることがわかりました。
この「Apache」という名称について、ASF設立メンバーのブライアン・ベーレンドルフ氏は「Apacheという名前にしたのは文化的流用などではなく、当時ローンチされたWebテクノロジーは『サイバー○○』や『スパイダー○○』といった名称ばかりで、もう少し興味深くてロマンティックな名称が欲しかったからです。ちょうどジェロニモとアパッチという部族の最期についてのドキュメンタリーを見たところで、彼らが西部、つまりアメリカ合衆国による侵略を受けて領土を手放した最後の部族だったという話で、私にとっては、我々がWebサーバープロジェクトで行っていることをロマンティックに表現しているように思えたのです」と語っています。
Natives in Techは、この「ロマンティックな表現」が「無知であると同時に不快なもの」と指摘し、ASFに対して「選んだ言葉に深く注意」し、名称を変更するように求めています。