[...]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社はすでに「緊急的な対処策を講じ、新たに不正な情報持ち出しが生じることを抑止した」といい、今後は情報管理体制を再点検する他、情報の取り扱いに関する社員教育を充実させ再発防止を図るとしている。
リソース情報
リソース情報は、プロダクトやシステムの現状を表現するミュータブルな情報であり、プロダクトやシステムの成長に合わせて常に変化していきます。例えば、システムの変化に応じて運用手順書は常にアップデートされていきます。つまり、あらゆる情報をリソース情報としてそのままドキュメント化してしまうと、それだけ多くのドキュメントを運用・保守する必要が発生します。
イベント情報
イベント情報は、あるプロダクトやシステムの意思決定に関するイミュータブルな情報です。その後、そのプロダクトやシステムがどのように変更されたとしても、その当時における意思決定そのものが遡及的に変更されるわけではありません。また、あるリソース情報に関するドキュメントを書く場合、イベント情報の積み重ねとして表現することで、書き手にとっての運用・保守のコストを低減し、読み手にとって過去の変遷をたどりやすくなります。
イミュータブルドキュメントモデル
つまり、ストック情報をドキュメントとして表現する場合、まずイベント情報をドキュメント化し、次にそれらのドキュメントを参照する形式でリソース情報をドキュメント化することで、下記のメリットを享受することができます。
- 読み手は、あるストック情報について、過去から現在に至るまでの変遷とその理由を辿ることができるようになる
- 書き手は、過去に書いたドキュメントのうち、リソース情報に関するドキュメントの鮮度だけを気にすればよい
ここで、この考え方およびこれを実践するためのドキュメント運用手法を「イミュータブルドキュメントモデル」と命名します。
イミュータブルドキュメントモデルでは、書き手は次の運用フローに従ってドキュメントを執筆します。つまり、書き手はストック情報をドキュメント化する場合、「ある決定の検討を開始した時」から「ある決定について合意した時」までの間、イベント情報のみをドキュメント化し、その決定について合意された時にリソース情報のドキュメントへ反映します。
さて、この運用フローを見た読者の方は「かなり重厚な運用フローだし、イベント情報だってドキュメント化するハードルは低くないよなあ…」と感じたのではないでしょうか。実際、PRDやDesign Docsは優れたドキュメント手法ではありますが、その実践は容易ではありません。そこで、筆者は次のような流れでイベント情報を書き上げていくことをおすすめします。
- 個別の意思決定ごとに、「承認された日」「背景」「決定されたこと」「決定による影響」のみをドキュメント化する
- より俯瞰的なドキュメントが必要だと感じたら(かつ、まだ力尽きていなければ)、それらをまとめてPRDやDesign Docsとしてドキュメント化する
カラムナフォーマットとは、データベースの分析用途に利用されるファイルフォーマットの種類の一つです。大量のデータを扱う際に効率的に圧縮してストレージコストを下げたり、計算時に必要なデータだけを取り出して計算コストを小さくできる設計がされています。
行指向フォーマットは、行方向に連続してデータを格納するため、一つの行をまとめて操作することの多いOLTP処理に向いています。従来のデータベースはもともとこの行指向フォーマットが利用されてきました。
ストレージ技術などの発展により、DWH用途での利用を行うようになって、注目されるようになったのが列指向フォーマットです。列指向フォーマットは、列方向に連続してデータを格納する方式で、列単位でデータを取り出す分析用途に向いています。
主要なOSSのカラムナフォーマットのライブラリとしては、ParquetとORCがあります。
ParquetはTwitter社とCloudera社が、2010年のGoogleの論文Dremel: Interactive Analysis of Web-Scale Datasets（以下Dremel Paper）におけるデータレイアウトに関する内容をOSS実装したもので、ORCはもとはApache Hiveのためのフォーマットとして実装されたという背景の違いがあります。
カラムナフォーマットでは、データ型やカーディナリティ等の特性に応じて、様々な符号化方式から決定木等によって各列に最適なエンコード方式を選択します。これらの符号化技術自体は、行指向フォーマットでも利用されるものですが、カラムナフォーマットでは、型が同じデータが並んだり、規則的にインクリメントするデータが並ぶなど、符号化によるデータ圧縮が効きやすいというメリットがあります。
上述したとおり、カラムナフォーマットにはクエリパフォーマンスをあげるための仕掛けが施されています。ただし、フォーマットはあくまで最適化しやすいデータ形式であって、それらを活かし切るかどうかは実際に処理を行うクエリエンジン側に依存します。
# パターン1
def function(cond):
if cond:
return 100
else:
return 0
# パターン2
def function(cond):
if cond:
return 100
return 0
やあ！id:cockscombです。日々の生活に役立つちょっとした知識を紹介していきます。最近は、Apple WatchやPixel Watchみたいな、ナントカWatchのリリースが多いですね。でも今日紹介するのは、WatchはWatchでも、Docker Compose Watchです。
Docker Composeは、複数のコンテナを扱った開発に用いる道具で、コンテナを活用した開発では当たり前に使われている。そのDocker Composeに、ファイルの変更を監視してコンテナの再構成を行わせるのが、Docker Compose Watchだ。Docker Compose 2.22以降で利用できる。最新のDocker Desktopにも付属している。
これは便利そう
金融機関どうしの送金システムに不具合が発生し、500万件を超える振り込みの処理が遅れた問題で、金融庁は多くの利用者に影響が及んだ事態を重く見て、システムを運営する全銀ネット＝「全国銀行資金決済ネットワーク」に対し、法律に基づいて原因や再発防止策などの報告を求める「報告徴求命令」を出す方針を固めました。
全国銀行協会の関連団体で一般社団法人の全銀ネットは、金融機関どうしの資金をやりとりする「全銀システム」の運営を担っていますが、今月10日に不具合が発生してから12日復旧するまでに2日かかり、500万件を超える振り込みの処理が遅れるなど利用者への影響が広がりました。
「全銀システム」にこうした不具合が発生したのは1、973年に稼働を始めてから初めてのことです。
金融庁は多くの利用者に影響が及んだ事態を重く見て、全銀ネットに対し、資金決済法に基づいて、原因や再発防止策などの報告を求める「報告徴求命令」を出す方針を固めました。
金融庁は今月9日までの連休中に全銀ネットが実施した更新作業に問題があったと見られることから、更新作業の方法やバックアップの態勢、それに不具合が発生したあとの対応についても問題がなかったか詳しく調べる方針です。
また、不具合が発生した今月10日が資金決済が集中するいわゆる「五・十日」だったことが混乱を招いたという指摘もあることから、システムを更新するスケジュールに無理がなかったかどうかなど、利用者への影響が広がった背景についても調べる方針です。