判断すべき情報やスキルを持っているはずの人が、情報やスキルを持っていない上司に決めてもらっている場面、見たことありませんか
人が増えることでチームや事業に致命的状況が発生するのにありがちなのは「自分が判断した方が質の高い判断になるときでも判断を他人に委ねようする」という行為が重要な判断でも行われるようになった状況ではないか、とぼくは思っています。
「(上司)さんは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データが開発・保守を一貫して手掛けている。
プロフェッショナルファーム出身者のピープルマネジメント術は、大抵の会社ではアテにならないと思っており、もっと世の中は"意識が低く、昇進に興味もなく、適当に仕事をやってさっさと帰りたい部下"で溢れており、そういう部下だけで構成されるチームをどうまとめ上げるか？という観点が抜けている
コンサルのパワーポイントは物事を分類&階層化して二次元に射影してるんだよね。
その射影の軸を彼らは「切り口」と呼ぶんだけど、射影なのでかなり情報量が減る。
霞ヶ関のパワーポイントは射影をせずに難しいものを難しいまま扱っている。キュビズムみたいなもの。だから普通の人にはわからない。
いつも夫を応援してくださりありがとうございます。夫に代わり、妻が投稿させていただきます。
夫はかねてより病気療養中でありましたが、8月23日に家族に見守られ永眠しました。頑張って生き抜き、穏やかな最期でした。
生前親しくしてくださった皆様、お世話になりまして、本当にありがとうございました。
R.I.P
故人ブログがまたひとつ
Mojoは現時点でダウンロード時にユーザー登録などが要求されるものの、無料で利用可能です。
ただしMojoはオープンソースとして開発されてはいません。同社は将来的に標準ライブラリなどをオープンソース化する可能性はあるとしながらも、Mojo全体のオープンソース化は明言していません。また、同社がMojoをどのように商用化するのかについての計画も示されていません。
[...]一番聞かれる質問第一位は、「結局EMって何する人なんですか？」 です。一口にEMって言っても、なんか人によって得意な領域が違っていたり、大事だと思うポイントがバラバラなので、この疑問を持つのはそりゃそうだよなあ、とは思います。というわけで、このエントリーではEMは何する人なのかを明らかに・・・と思ったのですが、一言で語るのはやっぱり難しいなと思っています。なので、なぜ僕がEMという役割を説明するのが難しいと思っているのか、を書いていきます。
[...]これらのことから、マネージャーの一種であるEMは、開発チームの成果を安定化させる(継続的に最大成果を出すと言って良いかも)ために、メンバーの持っていないスキルを埋める役割として機能していることが大事だと言えます。
技術課題が大きければ大きい程、開発のスペシャリストとしてのスキルセットが要求され、直接的にチーム課題を解決していくことが要求されます。一方で、メンバー構成や文化によって、技術課題がメンバーである程度やれるようになってくると組織課題の比重が重くなり、一般的なマネージャーとしてのスキルセットが要求されるようになります。
ドメイン駆動設計に言及する記事や書籍は多くありますが、それぞれ着目する側面が異なったり色々なコンテキストから言及されています。
おそらくそれが原因でドメイン駆動設計が何であるかをぼやけさせ、正体のわかりにくい概念になっているように思えます。
そこで今回は色々な観点から整理し、ドメイン駆動設計とは何であるのか、その正体を考えていきます。
Explain complex systems using visuals and simple terms.
Whether you're preparing for a System Design Interview or you simply want to understand how systems work beneath the surface, we hope this repository will help you achieve that.
複雑なシステムをビジュアルと簡単な用語を使って説明します。
システム設計面接の準備をしている場合でも、単にシステムが水面下でどのように機能するかを理解したい場合でも、このリポジトリがそれを達成するのに役立つことを願っています。
当社（株式会社NTTマーケティングアクトProCX）が利用するコールセンタシステムの運用保守業務を担うＮＴＴビジネスソリューションズ株式会社（以下、ＮＴＴビジネスソリューションズ）において、同システムの運用保守業務従事者（ＮＴＴビジネスソリューションズに派遣された元派遣社員）がお客さま情報を不正に持ち出し、第三者に流出させていたことが判明いたしました。
不正に持ち出されたお客さま情報は、当社へテレマーケティング業務を委託いただいていた一部のクライアントさまのお客さま情報であることを確認しました。
クライアントさま並びにクライアントさまのお客さまへ多大なご迷惑とご心配をおかけしておりますことを、深くお詫び申し上げます。
1. 概要
当社が利用するコールセンタシステムを提供するＮＴＴビジネスソリューションズの同システムの運用保守業務従事者（ＮＴＴビジネスソリューションズに派遣された元派遣社員）が、システム管理者アカウントを悪用のうえ、お客さまデータが保管されているサーバへアクセスし、お客さま情報を不正に持ち出し。
（1）不正に持ち出された件数
お客さま数：約900万件 クライアント数：59（現時点判明分）
※今後新たな情報が判明いたしましたら、随時公表してまいります。
（2）不正に持ち出されたお客さま情報の内容
クライアントさまよりお預かりしたお客さま情報（氏名/住所/電話番号等）
2. 本件に関する対応と再発防止策
当社及びＮＴＴビジネスソリューションズは、今回の事案を厳粛に受け止め、クライアントさまのご不安の解消に向け て対応いたします。
まず、本テレマーケティング業務については、システム面および運用管理面から緊急的な対処策を講じ、新たに不正な情報持ち出しが生じることを抑止しました。さらに、今後、お客さま情報を取り扱う全業務について再点検を実施することで、個人情報管理体制の一層の強化を図ってまいります。加えて、当社及びＮＴＴビジネスソリューションズの従業員に対して、これまで以上に情報の取り扱い・保護に関する教育の充実を図り、個人情報保護の重要性に関わる当事者意識の醸成を図ってまいります。
NTT西日本グループのNTTマーケティングアクトProCX（大阪市）は10月17日、マーケティング業務を代行するためにクライアントから預かっていた顧客情報900万件が不正に持ち出されたと発表した。コールセンター用システムの運用保守を依頼していたNTTビジネスソリューションズ（同）の元派遣社員が、第三者に情報を流出させていたという。
少なくとも、NTTマーケティングアクトProCXがクライアント59社から預かっていた顧客情報（氏名、住所、電話番号など）が持ち出された。元派遣社員はコールセンター用システムの管理者用アカウントを悪用。データが保存されていたサーバにアクセスし、情報を持ち出したという。
2社はすでに「緊急的な対処策を講じ、新たに不正な情報持ち出しが生じることを抑止した」といい、今後は情報管理体制を再点検する他、情報の取り扱いに関する社員教育を充実させ再発防止を図るとしている。