欧州連合（EU）の議会と理事会は、サイバーレジリエンス法（CRA）について合意に達し、待望のセキュリティ規制について、最終承認・採択への道筋をつけるとともに、オープンソースソフトウェアを除外する新たな規則を定めた。
議会と理事会での採択から 20 日後に施行される CRA は、ハードウェアおよびソフトウェアメーカーにいくつかの威圧的な目標を達成することを求めるものとなる。この規則には、新たに発見された脆弱性が悪用されている場合に 24 時間以内に開示することや、5 年間のセキュリティパッチサポート、すべてのセキュリティ機能の完全な文書化などが含まれている。
製造業者、輸入業者、流通業者は、36 か月以内にこの要件を採用しなければ、最高で 1,500 万ユーロまたは世界での年間総売上高の 2.5 ％以下の罰金を科せられる。
とりあえずOSSは除外された模様
米Wasmer社は、WebAssemblyへのコンパイルだけに特化した新しいプログラミング言語「Onyx」を発表しました。
同社はWebAssemblyにかつてのCGIの仕組みを取り込んだ「WCGI」や、WebAssemblyでBashのコマンドプロンプトなどをを実装可能にするWebAssemblyを拡張してPOSIX対応にした「WASIX」など、WebAssemblyをベースとしたさまざまな技術を発表し実装しています。今回のOnyxもそうした技術の1つとなります。
構文はGo言語など命令型プログラミング言語をベースにしていると、次のように説明されています。「Onyx, a new programming language powered by WebAssembly」から引用します。
こんな感じ↓の言語らしい（公式サイトより引用）
use core { printf, iter }
main :: () {
for i: 1 .. 10 {
fact := factorial(i);
printf("{}! = {}\n", i, fact);
}
}
factorial :: (n: i32) -> i32 {
return iter.as_iter(1 .. n)
|> iter.fold(1, (x, y) => x * y);
}
メンテナーの話が出ると、Hohndel氏は、「メンテナーの疲労と、その仕事がいかに消耗させられる、ストレスが強いものか」という問題を取り上げた。先日の記事でも取り上げたように、Linuxカーネルのメンテナーは、その必要不可欠で大変な仕事に以前よりも強い緊張を感じるようになっている。
Torvalds氏は、Hondel氏の問いかけに対して、「開発者を見つける方はずっと簡単だ。開発者はたくさんいる。ただ、メンテナーは何でもできるスーパー開発者でなければ務まらないと考えている人がいるが、実際にはそうでもない」と述べた。
「メンテナーになるためには、他人のコードの善し悪しを判断できるだけのセンスを持っていなければならない。それには生まれつきの才能も多少は必要かもしれないが、大部分は単なる練習の積み重ねだ。メンテナーは、他人のコードを見て『これは良いアプローチなのか、悪いアプローチなのか』を判断できなくてはならない。それは通常、単に十分な経験があるかどうかの問題だ」
またHohndel氏は、将来に向けて、人工知能（AI）や大規模言語モデル（LLM）について議論する必要があると話を振った。同氏は、Torvalds氏に対して、「私は普段、AIは強力なオートコレクト機能だと言っている。LLMは、次に使う可能性が一番高い単語を予想して、そこから外挿しているだけであり、実際には本当にインテリジェントなわけではない。しかし、私たちの生活や現実に大きな影響を与えていることは明らかだ。あなたは、LLMが書いたコードが（Linuxカーネルのコードとして）送られてくるようになると思うか？」と質問した。
実際、Torvalds氏は、AIがすぐに分かる馬鹿げたバグを見つけるのに役立ってくれるのを期待しているという。「私が目にするバグの多くは、微妙なものではない。その多くは単なる馬鹿げたバグで、それを見つけるのに高度な知性は必要ない。しかし、もっと微妙なケースについて警告してくれるツールがあればうれしいだろう。例えば、『このパターンは普通のパターンではない。これは本当に必要か？』と言ってくれるだけでもいい。それに対する答えは、『いや、そういうつもりで書いたコードではなかった。明白なバグを見つけてくれて、どうもありがとう』というものかもしれない。私たちには実際、強力なオートコレクト機能が必要だ。AIは、私たちの仕事をもっとうまくやるのを手助けしてくれるツールだと思っている」と同氏は述べた。
日本マイクロソフト株式会社は、2024 年 4 月 1 日から、法人向けソフトウエアおよびクラウドサービスの価格を改定します。新価格は、日本円の為替変動に伴い、いずれも 20% の引き上げとなり、2024 年 4 月以降に適用されます。
マイクロソフトは、ソフトウエアおよびクラウドサービスについて、現地価格の影響を定期的に評価し、地域間の合理的な整合性を確保しています。今回の変更はその評価の結果により、価格を米ドル水準に近づけて調整した結果です。今後も、米ドルに対する為替変動を考慮し、年 2 回の定期的な価格評価の一環として、現地通貨建ての価格を調整する場合があります。
このアナウンスメントは、ハードウェア (Surface 等) またはコンシューマ向けに提供している Windows, Office および Microsoft 365 サービス等は対象としておりません。マイクロソフトの製品がリセラーを通じて販売される間接販売の場合、最終価格と販売通貨は引き続きリセラーによって決定されます。
技術レベルのボトムラインが低く、それなりの雰囲気が組織のスタンダードになっていると、自ずとソフトウェアの品質傾向もそれなりのものになる。いくらコードレビューだとか設計レビューで誰かが警察的な予防をするにしても、人力でやっている以上そこには限界がある。誰かが部分的に品質を上げようと思っても、その他大部分は雑なわけで「別に品質に拘んなくてもよくない？」となってしまう人の気持ちはすごくよく分かる。人間誰しも、周りがやらなくて済んでいることは自分もやりたくない。
組織の中でこの振れ幅が大きくなると、不要なルールやドキュメンテーション、いろんなレベル感に配慮した一貫性のないコードやコミュニケーションが生まれてくる。いや、もちろんドキュメントやその他諸々のアグリーメントは多かれ少なかれ必要になるが、少なく回るならそれに越したことはない。早い段階でこの手の問題を予防するには、やはり一番には採用プロセスでのクオリティー担保だし、そのベースにあるのが組織のカルチャー醸成だったりするのではないかと個人的には解釈している。
個人的な体感として、そのへんの求人サイトに転がっているWeb系のシニアレベルのエンジニアの大半においては、深ぼってみると実はソフトウェア設計やコーディングのスキルはもはや評価の対象にならないもの（というか、あって当たり前）であり、どちらかというと先に書いたような組織の技術レベルのブレ幅をいかに小さくするか、複雑性に耐えられる下限値をいかに上げていくかを考えてリーダーシップをとることのほうが、公にはしないが最終的には求められがちな能力な気がしている。
とはいえ、ここまでカバー範囲が広がってくると、そもそもそれはソフトウェア・エンジニアとしての職務に含まれるのか？という気もしてくるので難しい。コードだけ書きたいという人もいるだろうし。また、こういう仕事を誰がメインでやるべきかというのもよく分かっていない。テックリード、エンジニアリングマネージャ、VPoEらへんの誰かっぽいのは分かるが、具体的な細かい技術的な話からふわっとした抽象度の高い組織の雰囲気作り的なものまで、求められるレイヤが広そうではある。
Objectiveではもう少し明確に、自動車内の環境で動作することを掲げている（図3）。もっとも、自動車のみを対象にしているのではなく、端的に言えば従来はField Busが使われてきていた工場などのノイズなどが酷い環境で10Mbps Ethernetを利用するための規格であり、そうした環境の1つに自動車内が挙げられている、という格好である。
ただし、IEEE 802.3cgの主目的は、自動車よりもそのほかの工場やビルなど、環境的に厳しい場所での長距離接続にある。実際Objectiveでは、次の項目が挙げられている（図4、5）。
- 転送速度は10Mbps
- 最大1Kmの接続距離
- 25mまでの範囲でBERは10E-10、1Kmでも10E-9を確保
10BASE-T1LはClause 146、10BASE-T1SはClause 147にその仕様がまとめられている。両方の仕様を簡単にまとめると、次のようなかたちになる。
- 転送速度はどちらも10Mbps
- 変調方式は10BASE-T1LがPAM3+4B3T、PAM3+4B5Bとなる（つまり変調方式には互換性がない）
- ケーブルは10BASE-T1LがAWG18ケーブルで最大1000m、一方10BASE-T1SはAWG24～26ケーブルで最大15m
- 接続方法は10BASE-T1LがPoint-to-Point。一方10BASE-T1SはMulti-Drop可
- 通信方式は10BASE-T1LがFull-duplexが基本。対して10BASE-T1SはHalf-duplexが基本で、オプションでFull-duplexも可能
10BASE-T1Lの4B3Tは4bitのデータをPAM3の3シンボルに変換する方式で、こちらはISDNで利用されていた符号化方式である。一方、10BASE-T1Sの4B5BはFDDIとか100BASE-TXなどで利用されていた符号化方式で、4bitのデータを5bitのシンボルに変換するが、これを使うとデータに0が4つ以上続かないので、クロックの同期が容易というメリットがある。
10BASE-T1Sはまた、他の規格と比べても低価格で実装できるのがポイントだ。上に示したように、10BASE2/5と同じようにMulti-Dropが可能になっているから、接続デバイス数が増えてもSwitchがそもそも要らない。加えてPHYとコネクタの間にパルストランスを必要とせず、AC結合用のコンデンサで置き換え可能である（図6）。このため小型化と低コスト化を図ることが可能だ。
なぜこうした製品が投入されているかといえば、昨今の自動車がZone/Domainアーキテクチャを採用し始めていることに起因する。ラフに言えばZoneは「場所」で、例えば車体後部に置かれているもの（トランクの開閉やロック、バックモニター、リアウィンドウワイパー、etc.）をまとめて1つのECUで管理しようという考え方、Domainは機能（ウィンドウ制御、ドア制御、座席制御、etc..）の種類別に管理しようという考え方で、これを適時組み合わせるわけだ。
これまでは、ここにCAN（Controller Area Network）とかLIN（Local Interconnect Network）といったネットワークが使われてきた。CANは高信頼性のネットワークで、それこそエンジン制御とかサスペンション、最近だとアクセルやブレーキなどもこれに該当するが、そうしたものの接続に利用されている。
一方のLINは、ドアミラーとかパワーウィンドウ、ワイパーなど、CANほどの信頼性は不要で、速度もそれほど必要ない用途に低コストなネットワークとして利用されている。ところが昨今はZone/Domain化を進めてゆく中で、基幹となるネットワークをEthernetに置き換えようという動きが活発化している。
こうなると、基幹はEthernetなのにドアミラーはLIN、ということであれば、どこかにGatewayを入れてEthernetとLINの変換が必要になる。であればLINと同程度のコストで実現できる低速なEthernetを使えば、ゲートウェイが必要なくなり便利というわけだ。
実際ドアミラーの制御であれば、50Kbps程度の速度があれば十分だし、そもそもエンジンなどと違って全てのデバイスが常時動いているわけではない。なので、ドアミラー以外のデバイスをたくさんつなげても、10Mbpsあれば十分お釣りが来るというわけだ。
車載用Ethernetというと語弊があるが、車載“にも”使われるEthernetという位置づけであれば、今後広く使われてゆくと思われるのがこの10BASE-T1Sであり、しばらくの間は、これを置き換える規格も出てこないだろう。
権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。
また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。
そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います！
SQLite には SQLite FTS5 Extension という全文検索用の Extension があり、これを使うとSQLで全文検索できます。
デフォルトではあまり日本語の検索に向いたトークナイザはありませんがカスタムトークナイザを load して使うことができます。
既存の日本語向けのカスタムトークナイザは手元でうまく動かせなかったりしたので、signalapp/Signal-FTS5-Extension を fork してみました。オリジナルでは Unicode Text Segmentation を使ってますが、日本語を検索したいので lindera-morphology/lindera を使うように書き換えていきます。Lindera は Meilisearch などでも使われている Rust で書かれた形態素解析ライブラリです。動詞の活用や漢数字の正規化もやってくれます。
運用を続けていく中でわかったことは、ADRはある種「街の掲示板」のような役割を果たしてくれるのだなということです。突然決定だけが行われるのではなく、コメントを募集するような未決定状態のフェーズから衆目に晒すことができるため、組織内にジワジワと意思決定を浸透させていってくれます。
未熟な状態の設計決定でも、コメントのやり取りを行う中で明確化されていくので、記録も残るし設計も洗練されるし、良いことづくしです。実際にADRで策定された機能であったり、設計上の変更がリリースされた場合も、すでに全体に情報が周知された状態になっており良かったです。
個人的にはADRを過去にも取り入れようとしたことがあったのですが、その時は失敗してしまいました。その失敗の最たる原因は、ADRをソフトウェアと一緒にソースコード管理ツールの管理下においたことです。
結果としてADRは、一つのソフトウェア内にロックインされた形になりました。ADRという会社の共有資産としてはではなく、特定のソフトウェア内の情報になってしまったのです。そのプロジェクトに参加していた人はそれを閲覧できるが、それ以外の人からすれば見に行く動機がありません。ドキュメントが残っていること自体は良いのですが、ソースコード管理ツールを自由自在に操れるのは基本的にはプログラマーです。そのため、ディレクターや関連する他部署の人からは参照しづらいADRになってしまいました。
人から見られることのないドキュメントは、批判を受けないので修正もされずに野放しになります。結果的に、この時のADRは作り始めて数週間で廃れ始めて、そのうち誰もそのドキュメントを参照しなくなりました。
こういった条件分岐が行われる場合、名前やenum値は比較対象としての値そのものと比較したいわけではなく、各if文の裏側に何らかの意味が存在していると解釈できます。
これこそがまさにドメイン知識である
同じような課題を解決しようとして↓のような方法を検討したことがある。
判断すべき情報やスキルを持っているはずの人が、情報やスキルを持っていない上司に決めてもらっている場面、見たことありませんか
人が増えることでチームや事業に致命的状況が発生するのにありがちなのは「自分が判断した方が質の高い判断になるときでも判断を他人に委ねようする」という行為が重要な判断でも行われるようになった状況ではないか、とぼくは思っています。
「(上司)さんはAとBどちらにしたいですか」とか「◯◯してもいいでしょうか？」と判断すべき情報やスキルを持っているはずの人が、情報やスキルを持っていない上司に決めてもらっている場面って見たことありませんか?
プロジェクトの全体も具体的なところも把握していて、かつ色々な判断をして良い権限も持ってはずの人が「(上司)さんはどうしたいでしょうか?」と聞いているシーン。
なぜかこれがヤバいかというと、「(上司)さんはAとBどちらにしたいですか」と聞かれた上司本人はベストと思う判断を伝えているし、一番わかってる人も決められたことをやれば仕事としてOKになるので誰も困っていないのです。
上司さんも仕事は成果を出すためにやってるんで、自分で決めるのも他者に任せるのも手段でしかないはずです。他者に決めてもらう方が上手くいくというなら上手くいく判断ができる人に任せた方が良い。だから決める人は上司でもそうでなくても良いのです(決める人が誰であるかと指定することはあるだろうけど)。当たり前の話なのです。
解決策としては組織マネジメントがんばる。普通にこれしかない。
ある「判断すべき人」は職人的な技術や判断は正しいけれど、判断に責任を負えと言われると急に何もできなくなるタイプかもしれません。そういう人なら「技術や判断はその人が行うが、責任は任せている人がとる環境」を作る。
上司的なひとも部下からの判断をお願いされたら「聞かれたら答えちゃう」というのがありがちです。そりゃ頼まれたら応えたいよね。それに対して「決定を依頼されないような環境」づくりや「聞かれたら意見は言うけど、決定は上司の意見に流されずにできる環境」を作っていく。
当たり前なんですけど、これが正攻法といえます。
(ただし、多くの組織でその当たり前が実行されないわけですが…)
以前、質の高い打ち手を選択できる人が判断をせず、質の低い決定しかできないような上司や社長に「どうしますか」と委ねるのはチームがダメになる要因なんよという記事を書いたのですが、今日はその逆で課題解決に必要な能力と情報を持っている人が判断をしなくても上手くいったことについて雑に語ります。
しかし、先ほどの会議では、課題解決の能力がある人が意思決定をしなくても上手くいったわけです。質の高い判断ができる人が他者に決定を委ねるのは良くないという考えは今でも変わりませんが、
- 課題解決に必要な能力と情報を持っている人が判断をせず、質の低い決定しかできないような他者(上司や社長とか)に「どうしますか」決定を丸投げすることはダメゼッタイ
- 専門性あるプロフェショナルとして最善策を主張して欲しいし、個人のキャリアとして望ましいが、できない人も多い。
- 専門性あるプロフェッショナルの考える最善策を、そのひとが強く主張しなくても選べるチームづくりを目指した方が実は効率が良さそう。
って考えても良いのかもしれないなーと思ったんですよね。
このとき始めて、私はこの日本における管理職教育上の大問題を自覚しました。そうなのです。マネージャーとリーダーは本来別物なのです。それなのに、それらを混同して一人の管理職に全て押し付けてしまうので、よほどの逸材でもないかぎり、結局両方とも上手くこなせずに疲弊してしまいます。そんな管理職を見る部下たちは、これは自分にはとても無理だ、と管理職意向を失っていきます。悪循環です。
まず、リーダーという言葉ですが、英語でリーダーというと、大体会社のトップを意味します。要は社長です。社長が率いる経営陣は「リーダーシップチーム」です。つまり、リーダーとは、大きなビジョンを指し示し、そこにみんなを引っ張っていく人、文字通りフォロワーを先導（リード）する人なのです。日本語に訳すなら「指導者」ということになります。国のリーダーのことを「指導者」と言いますよね。あの指導者です。
それに対してマネージャーは、会社組織でいうと係長や課長、部長などといった中間管理職です。数人からなる小グループの長が「リーダー」と呼ばれることは、英語圏のビジネスシーンでは基本ありません。マネージャーはリーダーが示したビジョンを実現すべく、会社から与えられたチームのアウトプットを最大化する役割を担う「管理者」なのです。
この２つを混同することの問題は、最もマネージャー寄りの課長レベルでは、リーダーシップの重圧に押しつぶされてしまうことと、マネージャーとしての技能が育たないこととして顕在化します。まず前者ですが、「チームを引っ張らなくてはならない」と気負い、それが上手くできずに、自分は向いていないと絶望してしまう人が一定数でてくるのです。
そこだけを見て「技術や知識でどうにかなるものではない」と開き直ってしまうと、十分に技術や知識が活きる「管理者」の仕事も根性論に近いもので何とかさせようとする風潮が生まれてしまいます。しかし、目標設定、委任（デリゲーション）、関係づくり（リレート）、ティーチング・コーチングなど、管理者が拠り所にできる知識や技術はかなり確立されており、それらを身につけることでマネージャーの仕事は飛躍的に効率化します。
一番リーダー寄りの経営者のレベルで起こる問題は、マネージャーとして結果を出し評価をされてきた人材が、トップになった途端にリーダーシップで評価されるようになり、急に無能化してしまうことです。リーダーとしての心得や覚悟が養われない状態で、いきなりビジョンを描き人を引っ張れ、と言われても困ってしまうのは当然です。そもそも資質がない場合は、さらに厳しいことになるでしょう。
また、逆にリーダーの資質がある人は、少なからぬケースでとても尖っていたり、対人関係の作り方に問題を抱えていたりします。そういう人は管理されるのも、またするのも苦手だったりするので、係長とか課長のレベルでは活躍できない可能性も往々にしてあります。イーロン・マスク氏が大企業の課長をやっているところを想像してみてください。そこで嫌気が差して組織を飛び出し、起業でもして大成すればいいのですが、変に根気強く組織に残っていたりすると、評価されないで終わるか、せっかくのリーダーシップの源泉に蓋をされてしまうようなことにもなりかねません。
こういう事態を防ぐには、やはりマネージャーとリーダーを分けて考え、それぞれの適性を踏まえて人材を育成していくことが重要なのではないでしょうか。もちろん、両方の資質がある人を相手に、両方を育めればそれがベストです。ただ、マネージャーの適性だけがとても高い人もいれば、逆に適性がリーダー方面にいい意味で歪んでいる人もいます。前者には管理のプロの道を示し、後者には最低限のマネージメント教育と良き協力者をあてがってリーダー教育を施すことで、両者の無駄な挫折を避けて通ることができます。
ベンダーロックインについて、「クラウドサービスが突然終了なんてそうそうあり得ないから大丈夫でしょ」と言ってる人が結構いるけど、サービスが使えなくなるのはアカウント停止とかもあって、実際にこれが起きたのがちょっと前にSkebがHerokuに突然切られて大規模障害になった件だよね。
ユング派心理分析家のルース・アマンが
"メソッド"と"テクニック"のちがいについて、
「テクニックには魂がない」
と述べていて、非常に合点がいった。
辞書によると
メソッド
組織だった方法、方法論
テクニック
技術、技法、技工
「アレクサンダーテクニーク」の「テクニーク」はテクニックのことで、創始者アレクサンダーはアレクサンダーテクニークとは呼ばず「わたしのワーク」と呼んでいたらしい。
そりゃそうだろう、創始者本人は自分の魂を込めてやっているだろう。まさにアレクサンダー氏のメソッド。
それが「アレクサンダーテクニーク」になったのは、受け継がれたのは技術、技法であって魂ではないということだと思う。
そして、僕はそれが良い！と思う。
アレクサンダーの技法を学んだ一人一人が、それに魂を込めたらそこに現われるのはアレクサンダーメソッドではなく、「その人メソッド」。
それ即ち亜流であることを意味しない。
一方、アレクサンダー「メソッド」を受け継ぐことにこだわると、それをやる人の魂が活き活きしなくなってしまうことはあるように思う。
守破離みたいな感じか
「ソフトウェア要求 第3版」の著者であるKarl Wiegersの新著が出ていたので、ざっと読んでみる記事（あるいは読んだ記録）。
[...]LayerXでは、機能の開発（アウトプット）が速いことではなく、顧客への価値提供（アウトカム）が速いことを重視しています。
これを前提として開発チームの開発速度について改めて考えてみると、測るべきは1スプリントにおいてどの程度のタスクを完了できたかではなく、どの程度のアウトカムを創出できたか、ではないかと思いました。
バックログのアウトカム = (要望企業数 / 開発工数) * インパクト
各スプリントで完了したバックログのアウトカムを合計すれば、そのスプリント期間中に創出できたアウトカムが分かりますので、これを開発チームの開発速度の指標として用いることができるようになります。
[...]技術的負債の解消や改善系のタスクは、Backlogに「改善」というタグをつけて積んでいます。 そして、毎月「改善デー」という名の、その日1日は通常の開発タスクを止めて、Backlogに積んでおいた改善系タスクを集中的にやりましょうという日を設けており、ここで負債の解消や改善に取り組んでいます。
もちろんその日にしかやらないわけではなく、日々の開発の中でも、「これは今やっておいた方がいい」というものがあれば、改善デーを待たずに対応することもあります。 そうすると、そういうタスクのアウトカムはどうなるの？というのが気になるところだと思いますが、現状ではこういったタスクにはアウトカムの値はついていません。
現時点では以下の6つのドキュメントが公開中
プロダクトオーナー（PO）が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどいアンチパターンであると言えます。
このアンチパターンを終わりにするためには、もっと前段にエンジニアが議論に参加する、なんなら議論をリードするくらいのことをしていく必要があるでしょう。POの負担はこれでかなり減ります。単純にPOがひとりでフルスイングし続ける範囲が減ることで、よりアウトカムへのインパクトが大きい部分に思考リソースを割くことができます。最初から技術的な前提を組み込んで議論することで、不確実性を単調に下げていくことができるので、手戻りによる精神的なダメージも大幅に減少することになります。
ひとつはPOが早期にエンジニアを議論に巻き込む工夫です。（PO、PdM、デザイナーなど目的不確実性に取り組むことを主務とするメンバーが複数いるような規模であれば特に）プロダクトに関するすべての議論にエンジニアを巻き込むことはコストに見合わないケースが多いです。どこかでストーリーやドメイン知識、熱量を揃えるコミュニケーションに労力を割かねばなりません。そのタイミングを見極め適切なコンテンツを用意するのは、口で言うほど簡単なものではありません。私も試行錯誤の途中です。
もうひとつはエンジニアの不確実性に対処する能力です。POの能力には限界があり、常に明瞭な期待と質の良い提案をできるとは限りません。程度の差はあれそこには常に不確実性が存在します。エンジニアが、曖昧だから、実現できないからといってそれを差し戻していては状況が改善しません。ゴールに納得できるまで話を聞き出す、ゴールに沿って仕様の詳細を埋めたり、実現可能な別の仕様を提案したり、不確実性を自ら下げていくアプローチこそがプロダクト開発を前進させます。このように不確実性の高い抽象的な期待に応えられることは、多くの組織に普遍的なハイグレードエンジニアの要件でもあるでしょう。メンバーの育成にじっくりと向き合い、事業の売り上げもメンバーの給料も上げられるように頑張っていきたいものです。
『ドメイン駆動設計』ではモデル駆動設計の基本要素の一つとしてエンティティがある。
追跡番号や識別番号を使って管理したい関心事を特定するモデル要素。
データモデリングや概念モデリングとして従来からある手法と同じアプローチ。
業務ロジックに焦点を合わせるドメインモデリングでは、
エンティティは脇役。主役は計算判断ロジックを表現するための値オブジェクト。
値オブジェクトは基本的にはエンティティの属性や状態を表現するのでエンティティと関係する。
主役である値オブジェクトを発見するために、エンティティの属性に注目する手法がある。手がかりとしては悪くないが
計算判断ロジックは複数のエンティティにまたがる横断的関心事になることが多い。
エンティティと値オブジェクトの結びつきよりも、どんな値を使ってどんな計算と判定をし、その結果どんな値を導きくという値(に種類)の関係に注目したモデリングが重要。つまりドメインモデルの主役は値オブジェクト。
複数の値オブジェクトを使った計算判断を表現する手段が集約。
集約は計算判断の文脈(目的と状況)を表現する複合オブジェクト。
計算判断の文脈にはPricing、Availability、Allocation、Authorization、Routingなどがある。
これらの文脈の根底にあるのは最適化。複数の制約条件を組み合わせて、何らかのポリシー(判断基準)を元により好ましい解を見つける。
ソフトウェア開発の進行状況と健全性を7つの視点で評価する。
<なぜ作るか>
①利害関係者
②価値の創出
<何を作るか>
③要求
④ソフトウェアシステム
<どう作るか>
⑤チーム
⑥作業の方法
⑦作業の結果
それぞれの視点ごとに定義された状態遷移モデルを使って現状を評価し次の行動を検討する。
役に立つかどうか、価値があるかどうかは状況によって変わる。
原則やパターンは、似たような状況であれば役に立ち価値がある内容を言語等で表現したものととらえられる。
似たような状況かどうかの判断は難しい。一般化された内容を目の前の個別の状況にどう取り入れるかも難しい。原則やパターンを
活用するというにはかなり高度な知的活動だと言える。 原則やパターンを個別の状況に取り入れて、その効果を評価することを繰り返していると、原則やパターンを活用する技能を向上できる。
クリーンアーキテクチャのDB非依存みたいなのは本当に意味がわからない
トランザクションの保証レベルが違ってるDBに取り替えても全く同じように動作するの？
「インクリメンタリズムの幻想」みたいなのがそこには存在している
永続データの並行性制御とかセキュリティみたいなアーキテクチャ特性は透過的に後付け出来ないよ
DDDとかクリーンアーキテクチャは寿命を言語 > アプリ = アーキテクチャ >>> フレームワークと考えている節があって、実際にはデータ >>>> データベース >> OS > 言語 > フレームワーク >>>> アプリという世界もある。データベースに魂を込めてモデリングする、アプリはおまけという思想も根強い
DDDとクリーンアーキテクチャに批判的な人の大部分は、ソフトウェアの本質はUI(機能とUIは不可分)だと思っていて、なんでもUIドリブンで作るべきで、バックエンドは可能な限り何も考えず、できれば自動生成したいと思ってる
賛同する人はソフトウェアの本質はUIに依存しない機能だと考えてる
gRPCとかREST APIなんかよりも、DBでどかっとデータ流し込みとか、ファイルでどかっと流し込みとかHULFTだぜ！とか全銀プロトコルとか流通BMSみたいな世界。
実のところ、クリーンアーキテクチャが想定するような「フレームワークの変更の影響を受ける」って事象はどれだけリアルなんだろうか？Rails、Django、Laravelとかそろそろ20年とか15年近いよな。J2EEも仕様があってフレームワークがある、という思想であるし。
[...]以上で述べたことは、数学や自然科学の法則などの理解という問題の根底に関連している。これは、AIに関する基本問題として以前から議論されてきたもので、「シンボルグラウンディング問題」と呼ばれる。
人間は身体で感じることによってシンボル（記号）を理解しているのだと言われる。ところが、AIに身体はないので、人間と同じように理解することはできない。だから、LLMは、自然言語を理解して文章を生成したり、質問に答えたりすることはできるが、記号や数学的概念を理解する能力には疑問があるというのだ。
シンボルグラウンディング問題は、AIに関する難問の1つとされ、それを解決するための研究が行われている。
たとえば、「MathQA」という研究がある。また、「Neural Math Solver」という研究もある。しかしどちらも、いまのところ、満足のいく結果を得ていない。
では、利用者としては、この問題にどのように対処したら良いのだろうか？ プロンプト（指示文）の書き方によってある程度対処できるという意見もある。しかし、完全な対処法とは言いがたい。
したがって、「ChatGPTを数学や物理学の法則、あるいは論理が関連する問題に使う場合には、注意が必要。答えを鵜呑みにせず、さまざまな方法でチェックする必要がある」としか言いようがない。
シンボルグラウンディング問題、山本弘の「神は沈黙せず」で知った（作中では記号着地問題となっていた）。
無料で使える中品質なテキスト読み上げソフトウェア「VOICEVOX」は、キャラクター無しの話者シリーズ「VOICEVOX Nemo」を2023年11月17日(金)にリリースすることをお知らせいたします。
また、VOICEVOXはVoyagerX, Inc.と提携しまして、マルチOS対応の動画制作ソフト「Vrew」にてVOICEVOXの音声を簡単に利用できるようになりました。(VOICEVOX Nemoは今後対応予定)
「VOICEVOX Nemo ( https://voicevox.hiroshiba.jp/nemo/ )」は中立性を重視し、幅広いシーンに適応可能な声を提供するための「公式キャラクター」レスの音声データベースです。様々な声質を揃えることによってあらゆる場面に対応させることをコンセプトとしております。
Kroki!は、テキストから統一的なAPIで、
- UML
- C4
- データ可視化
- その他図表
を、PNG, SVG, JPG等でレンダリングしてくれます。
キックオフミーティングでは、プロジェクトの背景の共有やそのプロジェクトがなぜ必要なのか、何に取り組むのかなどをチームや関係者と共有し、その上で全員がどのように協力するかを決定し、共通のプロジェクト目標などについて確認します。
しかし、キックオフミーティングで何を話して何を決めるかということ以前に、もっとも重要なことがあります。それは、「キックオフミーティングに誰を集めるか」 ということ、言いかえれば 「全員とは誰か」 です。
キックオフに呼ばなければならないのは、そのプロジェクトのスタートからゴールまでの間に協力が必要になる関係者です。したがって、「全員とは誰か」を考えるためには、キックオフの前にプロジェクトの大まかなロードマップを描いている必要があります。キックオフに呼ばれていなかった人へ後から協力を求めることになるのは、そのプロジェクトの計画に漏れがあったということであり、明確なプロジェクト立ち上げの失敗です。
そして、その協力が重要なものであればあるほど、「なぜ最初から呼んでくれなかったんだ」というマイナスの状態からコラボレーションがスタートします。なぜなら、当初の見積もりになかった協力が必要になっているということがすでにプロジェクトの進行状況の乱れを表しているわけであり、いわばはじめから炎上気味のプロジェクトになっているわけで、そんな状況に突然巻き込まれることのストレスは間違いなく高いからです。
@lacolaco からの提案は、いきなりキックオフから始めるのではなく、「キックオフに誰を呼ぶ必要があるか」を考えるための プレキックオフ を先んじて実施することです。
プロジェクトのリーダーがひとりで考えていては、そもそもゴールまでの道筋が想像できていなかったり、観点の漏れや偏りが生まれるのは当然です。そこで、そのプロジェクトの大まかなロードマップを考え、 誰と協力する必要が生まれるかの見積もり をするためのプレキックオフを実施します。
RWKVではQuery,Key,Valueではなく、R、W、K、Vというパラメータの学習を行う。だからRWKV(ルワクフ)と呼ぶ。
通常のRNNでは時間とともに減衰していくゲートと呼ばれる機構が必要で、このせいで並列化ができないが、RWKVではWの値を変化させるだけで同様の時間減衰を表現できる。
しかも、できあがったニューラルネットは行列と行列の積は用いず、行列とベクトルの積のみで計算可能で、スマートフォンやスマートウォッチなどで高速な推論ができるとされていた。
RWKV-5-World-v2はわずか1.5Bサイズであり、これはかなり小さくて高性能とされているLlama2-7Bの1/4以下のサイズということになる。そのうえ、Llama2は日本語性能が低いのだが、RWKV-5-World-v2は英語はもちろん日本語性能が極めて高いように感じる。
HTML First is a set of principles that aims to make building web software easier, faster, more inclusive, and more maintainable by...
- Leveraging the default capabilities of modern web browsers.
- Leveraging the extreme simplicity of HTML's attribute syntax.
- Leveraging the web's ViewSource affordance.
HTML First は、Web ソフトウェアの構築をより簡単、より速く、より包括的で、より保守しやすくすることを目的とした一連の原則です。
- 最新の Web ブラウザのデフォルト機能を活用します。
- 極めて単純な HTML の属性構文を活用します。
- Web の ViewSource アフォーダンスを活用します。
要するにブラウザのデフォルト機能で十分な部分についてはそちらを使い、全てをJavaScriptで制御するような事はやめようみたいな感じだろうか。
結論から言うと、まずユニットテストは以下を目標として作成します。
- ふるまいの仕様が実現されているか確認する
- プログラマが感じる品質リスク（いわゆる不吉な臭い等）が許容できる水準であることを確認する
- 法規制対応など、外部からのテスト要求に対応する
コードカバレッジは、上記目標を達成することで副次的に確保されることを目指します。
コードカバレッジの確保のみを直接の目標にしません。あくまで上記目標の達成が妥当かの参考指標、副次的目標として活用します
ThreadはIoT技術向けの低電力・低帯域幅メッシュネットワーキングプロトコルで、Thread Groupによって開発されています。Thread Groupは2014年7月に設立されたアライアンスで、Google傘下のNest LabsやApple、Amazon、Armホールディングス、Samsung、Qualcomm、NXPセミコンダクターズなどが参加しています。
最初の規格仕様となるThread1.0は、Thread Group設立の1年後である2015年にリリースされました。ベースはIEEE802.15.4で、ノイズに強く消費電力が低く、大規模ネットワークに対応しているというのも特徴です。
Threadはモーションセンサーや一酸化炭素検出器、ガス漏れ検知器など、「基本的に非アクティブな状態が続くが、必要な時に確実に動作する必要があるもの」に向いています。反対に、監視カメラのように高帯域幅を必要とするようなデバイスには向いていないとのこと。
◆Threadが既存のIoT用通信プロトコルよりも優れている点とは？
Threadはハブやブリッジが必要なく、Thread対応デバイス同士が相互に直接通信できるというのがポイント。また、Threadはインターネットプロコトル(IPv6)ベースのプロトコルです。つまり、スマートフォンやタブレット、コンピューター、Wi-Fiルーターなど、他のIPベースのデバイスに直接接続できます。Threadは信頼性の高いメッシュ機能を提供するため、1箇所にエラーが起こるとネットワーク全体に障害が発生するような単一障害点が起こり得ないというのも大きな特徴です。
◆Threadはハブやブリッジを必要としないのか？
Threadネットワークをインターネットなどの外部ネットワークに接続するためには、ボーダールーターが必要になります。しかし、対応デバイスを複数つなげるために、異なるブリッジを用意する必要はありません。Threadに対応していれば、どのIoTデバイスでもメーカーに関係なく、Threadのボーダールーターに接続できます。また、Threadの通信はすべて暗号化されているので、ボーダールーターからルーティングしたトラフィックをのぞき見ることはできません。
イベント駆動なPUB/SUBのマイクロサービスについてお話しています。
具体的なコードを追いながらマイクロサービスを連携させているかの開設がメインです。
こちらのセッションは JJUG CCC 2023 Fall の講演のリハーサル動画です。
昨年は「メタエンジニアリング」という概念について書いたり喋ったりしてきました。その内容は「メタエンジニアリングについて考えた2022年」という記事にまとめてあります。
「メタエンジニアリング」とは、ソフトウェア開発に携わるエンジニアとエンジニアリング組織の生産性を、エンジニアリングの技術・知識・経験を使って向上する取り組みのことです。技術広報・採用・組織開発の領域で、課題の発見・解決や組織と個人の成長支援を行います。
いろいろアウトプットの機会はいただいたのですが、全容が把握できるようなコンテンツは用意していなかったなそういえば、ということに気がついたので、今回は同人誌としてまとめてみました。個人的な事情により準備期間が圧縮されてしまい、本としての体裁は最低限なんとか、物理本もコピー誌を少部数しか用意できていない、みたいな状態ですが、幸い技術書典15の開幕には間に合いました。
面白そう
既存の人材にとっては暫く仕事が無くなる事は無いという事でなによりである
Firefox、Mercurial使ってたのか
詐欺行為の手口は洗練され続けており、仮想通貨や電子マネーなどあらゆる資産が詐欺師の標的となっています。そんな中、アンチ詐欺系YouTuberのKitboga氏が仮想通貨をだまし取る詐欺師を逆にだますシステムを構築し、詐欺師たちに無駄な時間を浪費させたレポートを公開しています。
Kitboga氏がアンチ詐欺の標的としたのはビットコインATMを用いた詐欺です。詐欺犯は「電話やメッセージアプリを通じて被害者に指示を出してATMを操作させ、ビットコインウォレットに入金させた後にATMが発行する『ウォレット管理サイトにアクセス可能なQRコード』の写真を要求する」という手法で金銭をだまし取ります。
Kitboga氏は「ウォレット管理サイトにアクセス可能なQRコード」の代わりに「ウォレット管理サイトに見せかけたアンチ詐欺システムにアクセスするQRコード」の写真を詐欺犯に送信しました。
Kitboga氏はアンチ詐欺システムに数百人の詐欺師を誘導することに成功したとのこと。中にはアンチ詐欺システムを本物のビットコインウォレット管理サイトと誤認したまま画像認証やコールセンターとの連絡に59日以上の時間を費やした詐欺犯もいたとのことです。
「Linux」カーネル開発者であり、LWN.netの編集責任者を務めているJonathan Corbet氏は「Linux Foundation Member Summit」の場で、Linuxカーネルのメンテナーが抱えている問題と、そうした状況が手に余るようになってきている理由について説明した。
事実、Linuxコードのメンテナーの多くがバーンアウト（燃え尽き症候群）に陥っている。なぜだろうか。その理由は数多くある。しかしまず、Linuxカーネルのメンテナーが実際に行っている作業を理解する必要がある。
メンテナーはさらに、異なる意見を持つ開発者間の調停役を務めたり、ベンダーやユーザーとやり取りをする必要もある。後者は、ハードウェア企業との話し合い、そしてそうした企業のドライバーをオープンソース化するための調整作業、ドライバー開発方法に関する開発者支援、ノートPCに搭載されているタッチパッドを機能させるためのユーザーサポート（ドライバー開発時にハードウェア企業が協力してくれなかった場合などに起こり得る）に至るまで多岐にわたっている。
これらの作業を抱えると、結果としてどうなってしまうのだろうか。XFSファイルシステムの元メンテナーであるDarrick Wong氏はメンテナーの職を辞す際、メーリングリストに「私は上級開発者やレビュアー、テスター、トリアージ担当者（お世辞にもうまくこなせたとは言えないが）、リリースマネージャー、そして（時々）マネージャーとの連絡窓口といった役割をさばこうとして何年も前にバーンアウトに陥った。（中略）もう少し長く持ちこたえられたら、長期にわたる開発に向けた集中力を維持でき、ユーザーのエクスペリエンスを高められるだろうと考えていた。しかし私は間違っていた」と記している。
書名だけ見ると「Erlang/Elixirは使ってないからなー」と避けてしまうかもしれませんが、それはもったいなく、言語に関係なく、”プロパティベーステスティング”という手法の本質的な活用の仕方が学べるようになっています。
プロパティベーステストは、テストコードを「テスト対象のコードが満たすべき特質（プロパティ）」と、「テストデータの生成」を分離し、予め用意された「ジェネレータ」が大量のテストデータを自動かつ、ランダムに生成することで、手動で作ったテストデータだけでは考慮できていなかったルートのバグを炙り出す手法です。
NTTデータグループは2023年10月30日、銀行間送金を担う「全国銀行データ通信システム（全銀システム）」の障害を受けて、傘下のNTTデータが金融庁から報告徴求命令を受けたと発表した。NTTデータは事実認識や発生原因の分析などについて、中間報告を含めて11月末までに金融庁に報告する予定だ。
NTTデータは2023年10月27日、資金決済に関する法律第80条第2項に基づく報告徴求命令を金融庁から受領した。既に全銀システムを運営する全国銀行資金決済ネットワーク（全銀ネット）が同システムの障害を巡って、金融庁から資金決済に関する法律第80条第1項に基づく報告徴求命令を受けている。
NTTデータグループは本間洋社長を筆頭とする「総点検タスクフォースチーム（仮称）」を立ち上げた。全銀システム障害の真因分析や再発防止策の検討のほか、同社関連の重要システムの総点検を進める。同社は金融庁からの報告徴求命令について「NTTデータグループとして、今回の命令を重く受け止め、真摯に対応していく」（広報）とコメントしている。
全銀システムの障害は2023年10月10～11日に発生した。全銀ネットによると、概算値ながら、仕向けと被仕向けを合わせて500万件超の送金に影響が出た。1973年に稼働した全銀システムは、日本電信電話公社時代を含めて、NTTデータが開発・保守を一貫して手掛けている。