正社員が20名規模かつ各ストリームアラインドチームが担当サービスのRealibityに責をもち自己完結して継続開発・改善できている状態
本番環境のオペレーションやSLO・SLIなどの指標通じてSite Reliabilityと継続的改善にプロダクト開発エンジニアが責任を持つ文化を維持・強化していく過程で手段として必然的に各プロダクト開発エンジニアが平均してインフラやCI/CDへの技術的知見が高い組織の状態になっています。
とても極端に言うと（多少デフォルメしてます）「スミマセン涙...Kubernetesのポッドが立ち上がらないんですけど...」「デプロイがコケたんですが助けてほしいです...」とSREチームのサポート無しではプロダクトを自己完結して継続提供できない状態の組織でした。当然SREチームのメンバーはとてもフォローしてくださっていましたが（それはまるでド◯えもんのような心で「しょうがないな、プロダクト開発チームは〜」といった感じで）、同時に本来的にSREが担うべき戦略領域に時間を割けていないことにフラストレーションを感じていたのも当然理解していました。
相談や壁打ちをするのは悪いことではない。しかし、そこに目的が存在しないと、壁打ち相手もどのような観点で意見を求められているのかわからず、アドバイスしづらいだろう。結果、何も決まらず相手や自分の時間まで無駄になってしまう。
【セットで伝えるべきこと】
- 何をゴールとした相談・壁打ちなのか
- 自分は今どんな課題を抱えているのか
- その相談や壁打ちが終わった後、どんな状態になりたいのか
- どんな観点で意見が欲しいのか
- データとコードの分離を心がける
- CQRSを採用する
- 必要にならない限り詳細を隠蔽しない
- 単体テストでロジック網羅を試みつつ、統合テストで全体をカバーする
- API・DBスキーマに関するものを二重管理しない
- AIに理解してもらいやすいコーディングを心がける
IT系勉強会タダ飯タダ酒乞食おじさんが先鋭化してるらしい
- (1) APIのスキーマ品質を向上させる事ができる
- (2) テストを迅速に開始できる
- (3) UIテストに比べて実行スピードが早い
- (4) テストの安定度が高い
- (5) テストを効率的に書ける
- (6) シナリオがドキュメント代わりになる
- (7) 自動テストへの組み込みが容易
- (8) リグレッションテストにも使える
- (9) ネガティブテストをしやすい
- (10) 負荷テストにも活用できる
時下益々ご清栄のこととお慶び申し上げます。平素より弊社電子書籍をご愛読いただき篤く御礼申し上げます。
弊社では、このたび令和6年1月10日より現行弊社ウェブサイトで販売している電子書籍（EBook）の価格を書籍の価格と同額にすることといたしました。
今回、弊社としてこのような判断に至った経緯としては、2008年12月に弊社Ebook Storeを開設した当時、まだ黎明期であった電子書籍の市場を開拓する上で定価の2割引きでの販売を始めました。
それ以降、これまでにDRM Free化、再ダウンロード機能の追加、そしてコロナ禍以降の出版メディア及びコンテンツビジネスを取り巻く環境が変化している中、その間も従来の価格を維持してまいりましたが、昨今の市場環境を鑑み「弊社オライリー・ジャパンのコンテンツ」の価値に見合った形で、書籍、電子書籍の形にかかわらず、同一の価格とする判断に至りました。
ご愛読者皆さまのご理解のほど、なにとぞ宜しくお願い申し上げます。
ご不明な点がありましたらば、 カスタマー・サービス専用メール までご連絡ください。
今後とも弊社電子書籍のご愛読を賜りますよう、よろしくお願い申し上げます。
オライリーはDRMフリーの「本物の電子書籍」を出してくれるので同じ値段でも仕方ない。
同社は米国時間12月12日、常識的な推論と言語理解が可能なSLMの「Phi-2」を発表した。現在、「Azure AI Studio」のモデルカタログで利用可能となっている。
「小規模」という言葉に惑わされてはいけない。Phi-2は27億個のパラメーターを持ち、その数は「Phi-1.5」の13億個から飛躍的に増加している。
同社によると、Phi-2はパラメーターが130億個以下の言語モデルの中で「最先端の性能」を発揮し、複雑なベンチマークでは最大25倍の言語モデルを上回ったという。
同社がSLMに注力しているのはなぜだろう。それは、LLMに対するコスト効率の優れた代替となるからだ。SLMはLLMほどのパワーを必要としないタスクで役立つ。LLMよりはるかに少ない計算能力で実行できるため、データの処理要件を満たすために高額なGPUへ投資する必要がなくなる。
プロパーがSIerさん侮辱した結果、SIerさんブチギレて全撤退するそうだ。そのプロパーは懲戒くらって、プロジェクトこれ完全に延期だな。
電話でもメールでもSIerさん下に見てて、毎回バカにしたような態度と文章だったから自業自得って感じ。
コンプライアンス守れない１人のせいで、プロジェクトが止まるって関係者はたまったもんじゃないな…
第1位: 凝縮度に基づくメソッド設計
第2位: 書籍ASoSDにおけるDeepModuleになってない
第3位: panicをinterceptorでhandlingするテクニック
第4位: ロジックを追加するレイヤーを考えよう
第5位: error flowの書き方
- 自動修復機能を設計します 。 分散システムでは、障害が発生します。 障害の発生に備えてアプリケーションの自動修復機能を設計します。
- すべての要素を冗長にします 。 単一障害点をなくすようにアプリケーションに冗長性を組み込みます。
- 調整を最小限に抑えます 。 アプリケーション サービス間の調整を最小限に抑えてスケーラビリティを実現します。
- スケール アウトするように設計します 。需要に応じて新規インスタンスを追加または削除し、水平方向に拡張できるようにアプリケーションを設計します。
- 制限に対処するようにパーティション化します 。 パーティション分割を使用して、データベース、ネットワーク、コンピューティングの制限に対処します。
- 操作に合わせて設計します 。 運用チームが必要なツールを得られるようにアプリケーションを設計します。
- 管理対象サービスを使用します 。 可能であればサービスとしてのインフラストラクチャ (IaaS) ではなくサービスとしてのプラットフォーム (PaaS) を使用します。
- ID サービスの使用. 独自の ID を構築または運用する代わりに、サービスとしての ID (IDaaS) プラットフォームを使用します。
- ジョブに最適なデータ ストアを使用します 。 データに最適なストレージ技術とその使用方法を選択します。
- 展開を見込んで設計します 。 成功するすべてのアプリケーションは時間の経過と共に変化します。 改良を見込んだ設計は、継続的なイノベーションのための鍵です。
- ビジネスのニーズに合わせて構築します 。 設計の決定はすべてビジネス要件によって正当化される必要があります。
欧州連合（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は英語はもちろん日本語性能が極めて高いように感じる。