■ 1. はじめに:複雑性が問題を生む理由
- ソフトウェア開発には「複雑性が問題を生む」という常識がある
- 問い:
- なぜ複雑になると破綻するのか
- どこから複雑と呼べるのか
- どの瞬間に人の理解が追いつかなくなるのか
- 技術負債はなぜ突然「手がつけられない」段階まで膨張するのか
- ソフトウェアの複雑性を計算量、認知負荷、チーム特性という3つのレンズで読み解く
- ポイントは「複雑なコード」ではなく「複雑さ自体の本質」を扱うこと
■ 2. 複雑性とは計算量の爆発を人間が受け止められなくなる現象
- ソフトウェアの複雑性はしばしば計算量の爆発として語られる:
- O(N) → まだ追える
- O(N²) → 何が起きているか曖昧になる
- O(2^N) → もはや理解不能
- しかしこれは人間の脳にもまったく同じことが起きる
- 人間の作業記憶は7±2個しか保持できない(心理学の古典的研究)
- これはエンジニアにとっては「認知の計算量制限」を意味する
- その後の研究では実効容量は4±1個程度という見解も有力(Cowan 2001など)
- つまりコード設計がO(理解)を超えた瞬間、人は壊れる
- 人間の作業記憶は5〜9チャンク程度しか同時に扱えないとされており、複雑な設計はすぐにこの上限にぶつかる
■ 3. 設計の計算量はコード行数ではなく関係性の数で決まる
- 複雑性はコード量では決まらない
- 関係性(依存・制約・フロー)の数で決まる
- 例:
- AがBを知っていて
- BがCを参照していて
- Cが非同期にAを更新する
- これを理解するには人間はA-B-C-Aの閉路を追跡しなければならない
- これは脳にとってDFS(深さ優先探索)のような負荷
- 関係性が増えるほど理解の計算量は指数的に増える
- コードは線形に増えるが理解コストは指数関数的に増える
- だから設計は突然破綻する
- 崩壊は徐々には進まない
- ある閾値を超えた瞬間いきなり崩れる
- まるで「臨界点」を超えた化学反応のよう
- 依存関係の数が増えると開発スピードより先に「依存の管理コスト」が爆発していく
■ 4. 認知負荷は見えない技術負債である
- 複雑性が破綻するのは技術の問題ではなく人間が処理できる情報量の限界を超えるため
- 認知負荷が高い設計には次の兆候がある:
- 一度読んでも理解できない
- 仕様とコードの対応が不明
- 「ここを変えるとどこに影響する?」が見えない
- レビューが摩耗する
- バグが「点」ではなく「面」で発生する
- これらはすべて「計算量過多」「キャパシティ超過」の症状
- 技術負債とは「認知負荷が金利として積もっていく現象」と捉えるべき
- 技術負債は単なる「後回しの修正」ではなく開発者の頭の中に積み上がる認知負荷そのもの
■ 5. アーキテクチャの本質は計算量の制御
- 設計とは格好いい図を描くことではない
- 本質はただ一つ:「理解に必要な計算量をO(1)に近づけること」
- そのためにアーキテクチャが存在する:
- 層で区切る → 認知対象を一定に保つ
- 責務を限定する → 計算経路を短くする
- 境界を作る → 関係性を切断する
- APIを設計する → 認知を抽象化する
- きれいな設計にも理由がある
- それは美しいからではなく脳への負荷を最小化するため
■ 6. 複雑性の破綻ラインは個人ではなくチームに依存する
- 認知負荷は人によって異なる:
- 初心者はすぐO(爆発)
- ベテランはO(ある程度耐える)
- 設計者はO(ノイズを抽象化できる)
- つまり複雑性の破綻ラインはチーム固有のものであり汎用的な「正しさ」では語れない
- 技術は移植できても認知限界は移植できない
- あるプロジェクトでうまくいった設計が別のチームでは壊滅する理由はここにある
■ 7. 実務で複雑性の爆発を防ぐ方法
- (1) 関係性を減らす(依存を切る):
- イベント駆動で発散した依存を整理する
- 双方向参照を禁止する
- 「AはBを知らない世界」を設計する
- 短い例:UI→UseCase→Repositoryだけにし、UIがRepositoryを直接呼ばないようにする
- (2) 読み方をO(1)に近づける:
- コードが「初見で」理解できる必要がある
- 初回で理解できない設計は複雑すぎる
- 短い例:「この関数は何をするか?」が1画面以内で完結するようにする
- (3) ドキュメントではなく構造で説明する:
- ドキュメントで補強が必要な設計はすでにO(1)ではない
- 短い例:「ここは○○層です」と説明不要なようにフォルダと責務を一致させる
- (4) レビューで認知負荷を観測する:
- レビューの摩耗は構造の疲労
- 短い例:PRに「ここ分かりづらい」コメントが連発したら設計の構造疲労を疑う
- (5) チームの認知限界を把握する:
- ベテランの限界ではなくチームの最低ラインで設計すべき
- 短い例:「新人でも追える構造」を基準にしベテラン依存の暗黙知を排除する
■ 8. おわりに
- 複雑性の問題は理論では説明できるが実務ではほとんど語られない
- しかしソフトウェアが破綻するのはいつだって「人間が理解できなくなったとき」
- ソフトウェアの限界は計算資源ではなく人間の認知資源で決まる
- この視点が定着すると設計やレビューやアーキテクチャの見え方が変わる
- 複雑性を避けるのではなく複雑性と「共存できる形」を探すことが大切
■ 1. libxml2のセキュリティポリシー変更
- libxml2のリポジトリに新しいテキストが追加された
- 内容:
- 趣味人たちによって開発され、たった一人のボランティアによってメンテされているオープンソースソフトウェアである
- テストは適当で、メモリ安全ではなく、セキュリティバグも満載である
- 信頼できないデータに対してこのソフトウェアを使用するのは愚かな行為である
- セキュリティバグは他のバグと同様に扱われる
- 受け取ったセキュリティバグ報告は全てただちに公開され、優先的に修正されることもない
■ 2. libxml2の概要
- XMLを処理するライブラリである
- 多くのLinuxディストリビューションやプログラミング言語に導入されている
- ChromeやSafariといったWebブラウザでも使われている
- 事実上業界標準と言える
- PHPにもあり、DOMやSimpleXMLなどがlibxml2に依存している
- 2000年ごろにDaniel Veillardによって作成された
- 2013年ごろからNick Wellnhoferが貢献を始めた
- 現在はNick Wellnhoferがほぼ一人で保守を行っている
■ 3. 協調的脆弱性開示プロセスの背景
- セキュリティバグは基本的に通常のバグ報告と異なる扱いがなされる
- いきなりGitHubやその他メディアなどでセキュリティバグが公開されると、修正が間に合わないうちに攻撃者に利用されてしまうためである
- セキュリティバグについては各企業のバグバウンティプログラムやHackerOne、IPAなどの機関に報告し、修正されるまで待ってから公開する手順が確立された
- 報告を受けた側も修正版がリリースされるまではセキュリティバグについては黙っておくのが通例である
- これは協調的脆弱性開示プロセスと呼ばれ、現在では多くの開発者やアプリケーションがこのプロセスに従っている
- libxml2はこの業界標準を無視し、セキュリティバグも一律全て公開する、攻撃者に利用されても知ったことではない、という斬新なセキュリティ対策に方針を切った
- 対応されてなかろうが90日で開示というポリシーを強行して大批判を食らったGoogle Project Zeroのはるかに上を行く対応である
■ 4. メンテナーの経緯:Stepping down(2021年7月22日)
- 特に頼んだわけでもないが、いつのまにかlibxml2とlibxsltの事実上のメンテナーになっていた
- 幸いなことにChrome VRPバグバウンティとOSS-Fuzz Integration rewardsによって報酬を得ることができていた
- Googleのこれらの優れたプログラムに感謝する
- 残念ながらセキュリティからの収益が急減しており、最低限の資金を確保するめども立たなくなった
- そのためコントリビュータ・メンテナを退任することにした
■ 5. メンテナンスの再開(2022年1月10日)
- Googleからの寄付のおかげで2022年はlibxml2とlibxsltのメンテナンスを継続できるようになった
■ 6. セキュリティ問題への対応(2025年5月8日)
- 毎週何時間も第三者から報告されるセキュリティ問題への対応に追われている
- これらの問題のほとんどは致命的ではないが、それでも大きな作業である
- 無給のボランティアにとってこれは持続不可能である
- libxml2の開発を継続できるようにいくつかの変更を考えている
- 基本的な考え方はセキュリティバグを他のバグと同じように扱うということである
- セキュリティバグはただちに公開され、他のバグと同じ優先度で扱われる
- この方針は一部のダウンストリームを不安に陥れるかもしれないが、もしかしたら貢献意欲を高めるきっかけになるかもしれない
■ 7. OpenSSFとセキュリティ業界への批判
- 長年この仕事をしてきたので、セキュリティ問題に関わる秘密主義のほとんどはただの茶番にすぎないものであるとわかっている
- OpenSSFのような「ベストプラクティス」は、大手テクノロジー企業がOSSメンテナーに罪悪感を抱かせ、無償で働かせようという圧力に過ぎない
- 最近個人経営している会社をOpenSSFのメンバーにしようとした
- そのためにはまずLinux Foundationのメンバーになる必要があり、これは最低でも年間1万ドルかかる
- これらは非常に排他的な組織であり、なにひとつオープンではない
- いまこそ彼らとその支援者を非難すべき時である
- 長期的にはOSSメンテナーに報酬も払わずにこのような要求を課すことは有害である
- 最近libxsltのメンテナーを辞任したが、このライブラリがふたたびメンテナンスされる可能性はほとんどない
- Google Project Zeroという金で買える最高のセキュリティ研究者がボランティアの首根っこをひっつかんでいる現状では、その可能性はさらに低い
■ 8. 企業の責任への批判(2025年5月10日)
- 肝心な点はそもそもlibxml2はブラウザやOSクラスが使用できるレベルの品質を備えていなかったということである
- Appleがlibxml2をOSのコアコンポーネントに導入したことが始まりだった
- その後Googleも追随し、今ではMicrosoftでさえlibxml2を使用している
- このようなことは決してあってはならないことだった
- 元々は成長のハックのようなものだったが、いまでは彼らは数十億ドルの利益を上げている
- しかしより優れたソリューションへの切り替えや自主開発、libxml2の改善といったフィードバックはない
- これらの企業の態度は無責任である
- 彼らはユーザのセキュリティやプライバシーなど気にもかけておらず、対症療法を行っているにすぎない
- もうこのゲームには参加しない
- 彼らがlibxml2の使用をやめれば、このプロジェクトの健全性は向上する
■ 9. メンテナー退任(2025年8月15日)
- libxml2のメンテナーを退任することにした
- つまりこのプロジェクトは現在ほぼメンテナンスされていないということである
- ここ最近libxml2を触っているのはNick Wellnhoferほぼ一人であり、彼が辞めるということはすなわちプロジェクトの放棄と同義である
- libxsltについては最近Iván Chaveroが後任に名乗りを上げたが、contributionもまだまだといったところである
- libxml2については今後どうなるか未知数である
■ 10. OpenSSFの実態
- OpenSSFはオープンソースソフトウェアの開発・保守を持続的に行うことを推進する組織である
- 有名どころとしては協調的脆弱性開示プロセスの策定・推進などがある
- 協調的なビジョンを達成するためには最低でも年間1万ドルの課金を要求する
- 実際のOSS開発者に貢献が還元されることは特にない
■ 11. Google Project Zeroへの批判
- 協調的脆弱性開示プロセスはOSSメンテナーにタダ働きを行わせるための脅迫でしかないという主張である
- 実際問題としてGoogle Project Zeroはオープンソースが相手でも脆弱性の指摘しか行わず、脆弱性を修正したりパッチを作成したりすることはない
- 高い給料もらってるんだからパッチも書けよといった批判も多々上がる
- 批判の声:
- 「Googleが真剣にハッカー対策をしたいのであればパッチを送ったり資金援助したりするでしょう。彼らは単にCVEバッジを集めたいだけです」
■ 12. 現状と今後の展望
- 実は「放棄された」は言い過ぎで、現在は「メンテナがいない」状態であり、誰かが後任に立候補すれば開発は継続される
- しかしメンテナになったところで報酬も利益もなく、負わされるのは時間と責任だけという損しかない立場である
- そのような立場に好き好んで入り込むのはよほど風変わりな人しかいない
- libxml2はあらゆるOSやブラウザや言語にまで入り込んでいる重大なライブラリである
- そんな根幹の部分がこんなことになっている現状、今後のOSSはどこに向かっていくのか不透明である
package main
import (
"encoding/json"
"fmt"
jmespath "github.com/jmespath/go-jmespath"
)
func main() {
// 1. JSONデータを Goの interface{} に変換する
jsonData := []byte(`
{
"users": [
{"name": "Alice", "age": 30, "city": "Tokyo"},
{"name": "Bob", "age": 25, "city": "Osaka"}
],
"status": "ok"
}
`)
var data interface{}
if err := json.Unmarshal(jsonData, &data); err != nil {
panic(err)
}
// 2. JMESPathクエリを実行する
// クエリ: "users"配列から、各要素の "name" の値だけを抽出して配列にする
query := "users[*].name"
result, err := jmespath.Search(query, data)
if err != nil {
fmt.Println("Error:", err)
return
}
// 3. 結果を表示する
// resultは interface{} 型で返される
fmt.Printf("Query: %s\n", query)
fmt.Printf("Result Type: %T\n", result)
fmt.Printf("Result Value: %v\n", result)
// Output: Result Value: [Alice Bob]
}
■ 1. プロジェクトの文脈把握
- 着手前にプロジェクトの背景と意味を短時間で整理する
- 文脈の要素:
- クライアントが達成したいこと
- 読者や顧客の置かれた状況
- 関係者が大切にしたい価値
- タスクが全体で持つ役割
- 依頼内容が曖昧な場合でも「この案件は最終的に何をよしとするか」だけ先に確認する
- 文脈が整っているため判断にずれが生じない
■ 2. 完璧主義を避けた動的な進行
- 全てが揃わないと動けないタイプではない
- 動くことで目的の精度を上げていく手法を採用する
- 具体的な進め方:
- 最小限だけ整えてまず動く
- 仮の流れをつくって全体像を見る
- 動かす中で深掘りが必要な箇所を判断する
- 依頼者には要点だけ短く確認する
- 止めるのではなく進めながら整えるため、プロジェクトが滞らない
■ 3. 工程の事前設計
- 目の前のタスクだけでなく、その後に起きることを早い段階で組み立てる
- 設計される要素:
- 議事録の粒度や優先順位
- 記事や資料構成の作り方
- 誰の判断がどこで必要か
- 編集から校正、公開までの流れ
- 工程が設計されているため、その場の判断がほぼゼロになる
- 任せていても進行が乱れない理由はここにある
■ 4. 予定の先置きによるペース管理
- 期日を受け身で待つのではなく、自分から先に予定を決めて共有する
- 具体的な先置きの例:
- 「〇日午前にドラフト送りますね」
- 「午後に方向性だけ合わせましょう」
- 「その後は〇日までに進めます」
- 先置きによって関係者の動き方が決まり、全体のテンポが整う
- 気分や混雑に左右されないリズムが生まれる
■ 5. 初動の早さと周囲への配慮
- 外向的でも積極アピール型でもないが、仕事が前に進む
- 初動の早さが理由である
- 具体的な行動:
- 不明点は早めに依頼者へ確認する
- 途中段階をすぐ共有する
- 次の人が作業しやすい形で渡す
- クライアントが判断しやすい状態を整える
- 初動が早いと相手の返答も早くなり、全体が前へ転がりやすくなる
■ 6. 原因帰属ではなく打ち手志向
- プロジェクトが進まない理由を外部に置く言葉を使わない
- 使わない言葉:
- 「返事が遅いから進まない」
- 「条件が揃わないから無理」
- 「指示が曖昧だから止まってしまう」
- 使う言葉:
- 「ここだけ確認できれば進めます」
- 「一旦この形で前に出しておきますね」
- 「先に必要な材料を揃えておきます」
- 原因ではなく打ち手を見る姿勢が自然体の強さにつながっている
■ 7. 推進力の本質
- 推進力は説明の上手さや強い主張から生まれるものではない
- 推進力を構成する要素:
- 文脈をつかむ
- 動きながら目的を整える
- 工程を先に設計する
- 予定でリズムをつくる
- 初動を早くする
- 外に原因を置かない
- この積み重ねがプロジェクトを止めない土台になる
- 自然体、素直、誠実という姿勢が信頼を生み、進め方が推進力を裏打ちする
- 推進力は勢いではなく「整える力」の総量で決まる
第7版の「原則」と第6版の「プロセス」が合体した
第6版「5つのプロセス群」が「フォーカスエリア」として復活し、「40のプロセス」として帰ってきた。が内容は7版ベース
各プロセスのInput/Output,ツール,技法(=ITTOs)など実務的な「統合版」になった
既存の書籍の改訂を除けば、おそらく本書が、私がRDBやSQLについて書く最後の本になると思います（そのあたりの事情については次回エントリで触れます）。
■ 1. CSRF攻撃の成立条件
- CSRF(Cross-Site Request Forgery)は古くから知られる攻撃手法である
- 攻撃者が用意したサイトに仕込まれたフォームから、ユーザがログイン中のサービスに対してリクエストを送信する攻撃である
- ログイン済みのCookieが付与されたリクエストがサービスの投稿APIに準拠していれば、そのユーザのアカウントで不正な投稿が受理される
- 攻撃の手軽さと影響の大きさによって、XSSやSQLインジェクションと並ぶ有名な攻撃手法として認知された
- 従来の対策としては、One Time Token(CSRFトークン)をフォームに仕込み、トークンの一致によって投稿を受理する方法が一般的だった
■ 2. CSRF成立の本質的問題点
- CSRF攻撃が成立する根本原因は「攻撃者のフォームからのリクエストにもサービスのCookieが付与される」点である
- しかし、CSRFトークンが機能していた事実は「このリクエストはどこから来たものなのか」が分かれば対策できる証拠である
- 本来注目すべき欠落は「リクエストの出自がわからない」という点である
- SameSite Cookieの導入によって別のサイトからのリクエストにCookieが付与されないようにすることは対策として成立するが、本質的な問題はリクエストの出自が不明であることである
■ 3. Originヘッダの付与
- プラットフォームの回答は「リクエストにOriginヘッダを付与する」というものである
- 現在のブラウザでフォームをsubmitすると、送られるリクエストにOriginヘッダが付与される
- Originヘッダの値を確認すれば、リクエストが正規のサイトからではないことを容易に判別できる
- Cookieの有無に関わらず、サービスは「意図しないOriginからのリクエスト」を弾くことができる
- このヘッダの必要性は少なくとも16年前から議論されており、7年前にFirefoxが実装することで全てのブラウザがフォームのsubmitにOriginヘッダを付与するようになった
- SameSite Cookieが導入されるずっと以前から「リクエストの出自を知る」ことは可能であり、それを用いて攻撃リクエストを弾くことができた
- fetch()を用いた実装でOriginを確認しながら適切なAccess-Control-Allow-Originを返していれば、「どこから来たかわからないリクエスト」を弾くことはずっと可能であった
■ 4. SameSite Cookieの副次的効果
- SameSite Cookieの登場により、積極的な対策をしてこなかったサービスも受動的な変更によって保護される結果になった
- しかしこれはかなり副次的な効果である
- SameSite Cookieの本来の目的は3rd Party Cookieをマークすることであり、3rd Party Cookie Deprecateの終着点はSameSite=None Cookieが送られないようにすることである
- CSRFは3rd Party Cookieよりも遥かに古くから問題だったが、「サイトを跨いだCookieが送られること」よりも「リクエストの出自がわからないこと」の方がプラットフォームが対策すべき問題とされていた
- SameSite Laxがデフォルトになったことを理由に「Originのチェック」を怠った実装は、本質的な対策を怠った片手落ちの実装である
■ 5. CSRFトークンの必要性の再検討
- OWASPのCSRF Cheat Sheetでは今でもトークンベースの対策が推奨されている
- トークンベースの対策を推奨する理由として以下が挙げられる:
- XSSがあった場合の対策
- ヘッダを改変している可能性
- GETでAPIがあると成立する攻撃
- サブドメインが乗っ取られる攻撃
- XSS問題の反論:
- XSS自体を対策すべきであり、XSSによってDOMに展開されたCSRFトークンを盗めない道理はない
- ヘッダ改変問題の反論:
- ブラウザや拡張に脆弱性があれば、サービス側の対策はバイパスできるため、サービス提供者が想定すべき対策として視点がずれている
- ユーザ設定やProxyが意図的にOriginヘッダを改変する環境は、ルールを守っていないためサービス側が許容する必要はない
- GET API問題の反論:
- 様々な条件でSameSiteやOriginが機能しないリクエストを生成できるという指摘は、「APIがGETだった場合に攻撃が成立する」という条件に収束する
- 副作用のあるAPIをGETで提供している実装は前提として間違っている
- サブドメイン攻撃の反論:
- SameSite Cookieだけに依存した対策は問題があるため、一次防御は「リクエストのOriginのチェック」である必要がある
- CSRFトークンの利点:
- 実装がこなれており堅牢である
- フレームワークがデフォルトで提供することが多く、導入コストが低い
- 現状入っているなら積極的に外す理由はない
- 防御の認識の変更:
- CSRFトークンは一層目の防御ではなく、多層防御の二層目であると認識すべきである
- トークンを使用していても「リクエストの出自を確認する」実装は一層目にあるべきである
- 全ての場所でOriginを確認するのがプラクティスである
■ 6. Fetch Metadataの導入
- 本来は全てのリクエストにOriginをつけるべきだが、「OriginヘッダのあるリクエストはXHRからのもの」という前提の実装が蔓延していたため、ドラスティックな変更ができなかった
- Originヘッダとは別にFetch Metadataが定義された
- 現在のブラウザでは以下のヘッダが付与される:
- Sec-Fetch-Dest
- Sec-Fetch-Mode
- Sec-Fetch-Site
- Sec-Fetch-User
- リクエストの出自を確認する手法は整備されており、これらを無視することはプラットフォームが差し伸べている手を振り払うことと同じである
■ 7. 令和時代の実装プラクティス
- 副作用があるエンドポイントの実装における優先順位:
- POSTにする(副作用のあるAPIをGETにしない)
- Originを確認する
- SameSite Lax/Strictを明示する
- Fetch Metadataも確認する
- Fetch Metadataのサポートに不安がある場合は「存在したら値をチェックする」実装でも良い
- Sec-プレフィックスはJavaScriptから操作できないヘッダであるため、値がある場合だけのチェックでも意味がある
- 実装の特徴:
- 追加のストレージコストが不要である
- コードだけで実装できるためレイテンシーが最小である
- フレームワークのレールの基盤として存在することが望ましい
- この実装から逸脱するコードが必要になった場合、プラットフォームが推奨するレールから外れていることを認識した上で、CORSなどの適切な対策をしながら拡張すべきである
- このベースを伴わずにトークンを載せても片手落ちである
- この実装をベースにしてもトークンがないと防げないCSRFが可能であれば、それはプラットフォームにおけるバグの可能性が高く、W3CのWebAppSecなどで議論すべき題材である
■ 1. Prismaの問題提起
- 3年間のPrisma本番運用後、パフォーマンス問題とサーバーレスコスト高騰を経験
- データベースアクセスを容易にすると約束したツールが最大のボトルネックに
- ORM全般の根本的問題:生産性と型安全性を約束したが複雑さとパフォーマンス問題をもたらした
■ 2. Prismaの魅力と落とし穴
- 魅力的なマーケティング:
- 型安全なデータベースアクセス
- 自動マイグレーション
- SQLを書く必要がない
- 単一のスキーマファイルで全てを生成
- クリーンで読みやすく型安全なコードに見えるが実際は問題だらけ
■ 3. パフォーマンスの現実
- バンドルサイズ:
- Drizzleは約1.5MB
- Prismaは約6.5MB
- サーバーレス環境では重大な影響
- N+1問題の深刻化:
- 一見単純なクエリが実際には数十のデータベースラウンドトリップを生成
- 単一のJOINクエリであるべきものが47個の個別SQLステートメントを生成した事例
- フロントエンドでTanStack Queryを使ってこの問題を回避したのにバックエンドでPrismaにより再現
■ 4. サーバーレスでの悪夢
- AWS Lambdaのコールドスタートが200msから2.5秒に増加
- Prismaが実行前に必要な処理:
- Rustベースのクエリエンジンバイナリのロード
- 内部GraphQLサーバーの起動
- コネクションプーリングの初期化
- クライアントインターフェースの生成
- Drizzleのような軽量ソリューションではサーバーレス関数のロードと実行がPrismaより遥かに高速
■ 5. 開発者体験の幻想
- Prismaの最大のセールスポイントは開発者体験(DX)
- 実態:シンプルなことに対する優れたDXは複雑なことに対する酷いDXを意味する
- スキーマロックイン:
- 全てがschema.prismaファイルを中心に回る
- PrismaのDSLに収まらないことをする場合は困難
- PostgreSQLのJSONB演算子などデータベース固有機能の使用が困難
- 複数テーブルの式(CTE)を含む複雑なクエリは生SQLに戻る必要があり、パラダイムを混在させ型安全性を失う
■ 6. コード生成の問題
- スキーマを変更するたびにprisma generateを実行する必要
- 数千行のTypeScriptコードを再生成
- IDEがフリーズし、ビルドプロセスが遅延
- 実行を忘れると型とデータベースが同期しなくなる
- Drizzleではスキーマへの変更が即座に反映される(コード生成不要)
■ 7. マイグレーションの悪夢
- デモでは素晴らしく見えるが本番では別の話
- データ損失の設計:
- カラム名変更時にPrismaは名前変更として検出せず、古いカラムを削除して新しいカラムを作成
- そのカラムの全データが消失
- Drizzleは名前変更の可能性を検出すると対話モードに入り意図を選択させる
- ブラックボックス問題:
- PrismaがSQLマイグレーションを生成するが手書きとは異なる
- 冗長で非効率な場合があり、レビューが困難
- マイグレーションをカスタマイズする際はツールと戦うことになる
■ 8. 抽象化の真のコスト
- Ted Newardは2008年にORMを「コンピュータサイエンスのベトナム戦争」と呼んだ
- ORMはオブジェクト指向コードとリレーショナルデータベース間のインピーダンスミスマッチを排除すると約束
- 実際には排除せず隠蔽するだけ
- 抽象化がリークすると(常にリークする)、ORMの癖と生成されるSQLの両方を理解する必要があり、開始時より悪化
■ 9. 優れた代替案
- Drizzle:
- SQLを知っていればDrizzleを知っている
- コード生成不要、バイナリ不要、魔法なし
- パフォーマンスはPrismaより桁違いに高速
- バンドルサイズ1.5MB対Prismaの6.5MB
- 型安全性を持つ生SQL:
- RustのSQLxはコンパイル時チェック付きSQLクエリをランタイムオーバーヘッドゼロで実現
- TypeScriptではKyselyが同様の利点を提供
- 生SQLの方が実際には優れているという動き:
- より透明:どのクエリが実行されているか正確に分かる
- より高パフォーマンス:抽象化オーバーヘッドがない
- より移植性が高い:SQL知識がプロジェクト間で転用可能
- より安全:インジェクションリスクを認識しているためより慎重になる
■ 10. セキュリティへの影響
- ORMはSQLインジェクションを防ぐためより安全とされるが新しいセキュリティ問題を導入
- マスアサインメント脆弱性:
- リクエストボディに予期しないrole: 'admin'フィールドが含まれていると管理者ユーザーを作成してしまう
- 生SQLではどのフィールドを更新するか明示的に指定するためこのパターンは起こりにくい
- 過剰なデータベース権限:
- ORMは機能するためにより広範なデータベース権限を必要とすることが多い
- テーブルスキーマ情報のクエリ、メタデータへのアクセス、リフレクションの実行が必要
- 最小権限の原則に違反
■ 11. バンドルサイズ問題
- 2024年ではバンドルサイズが重要
- AstroやSvelteKitのようなフレームワークは最小限のJavaScriptを強調
- しかしバックエンドに6.5MBのORMを追加
- エッジコンピューティングとサーバーレス関数では全てのキロバイトが重要
- Cloudflareの無料プランは3MB制限でPrismaはビジネスロジックを1行も書く前にその半分以上を消費
■ 12. ORMが依然として意味を持つ場合
- ラピッドプロトタイピング:何かを素早く動作させる必要がありパフォーマンスが重要でない場合
- ジュニアチーム:チームに強力なSQLスキルがない場合、ORMはガードレールを提供
- シンプルなCRUDアプリケーション:複雑な関係性のない基本的な作成・読取・更新・削除操作
- エンタープライズ要件:一部の組織はコンプライアンスや標準化の理由でORMを義務付け
■ 13. 移行戦略
- 新機能から開始:全てを一度に書き直さず、選択した代替案で新機能を構築
- パフォーマンスボトルネックの特定:プロファイリングを使用して最も遅いデータベース操作を見つける
- ドメインごとに移行:アプリケーション内の境界付けられたコンテキストを選び、そのデータベースアクセスを全て一緒に移行
- ツールへの投資:適切なデータベースマイグレーションツール、クエリビルダー、型生成をセットアップ
■ 14. 結論
- Prismaから離れることでサーバーレスコストを40%削減、パフォーマンスを3倍改善、コードベースの保守性向上
- データベースをより深く理解することを強制された
- データベースを単なるストレージレイヤーとして扱うのをやめ、その力を活用し始めた
- クエリがより効率的になり、データモデルがよりクリーンになり、デバッグセッションが短縮
- ORMは複雑さを隠すことで生産性を高めると約束したが、実際には複雑さは隠されておらず、手遅れになるまで見えない場所に移動していただけ
- データベースから隠れるのをやめ、受け入れ始める時かもしれない
■ 1. ブリリアントジャークの定義
- 優秀だが厄介な人を意味する
- 知識も技術も豊富だが他者への配慮や共感が欠ける
- 結果としてチーム全体の心理的安全性を壊す
- アジャイル開発では透明性・協働・自己組織化が重要だがコミュニケーションを軽視する態度が続くとチームの信頼関係が崩れる
- 生産性だけでなくメンタル面にも悪影響を及ぼす
■ 2. 発生した状況
- 経験豊富で技術力の高いメンバーがいた
- レビューの精度も高く幅広い知識を持っていた
- 一方で他のメンバーに対して厳しい言葉をかけることが多い
- 議論の場では自分の意見を強く主張する傾向
- チーム内の変化:
- チーム内で発言する人が減る
- 意見が対立すると議論が止まる
- ミスを恐れて挑戦を避けるようになる
- タスクの透明性が下がる
- チーム全体の空気が重くなりスクラムイベントも形骸化
- ブリリアントであるはずの存在がチームを静かに壊していった
■ 3. 初動の失敗
- 相手を理解しようと考えブリリアントジャーク本人との1on1やヒアリングを重ねた
- 結果的に問題の先送りに過ぎなかった
- 本人も悪気はない、相手に合わせればうまくいくかもしれないと考えて直接的な指摘を避けた
- この判断はスクラムマスターとしての誤り
- 人間関係の摩擦として捉えチーム全体の心理的安全性という観点を見落とした
■ 4. 方針転換
- チームのモチベーションが下がる中で方針を切り替えた
- 個人への歩み寄りではなくチーム全体を守るための行動を取ることに決定
- 具体的なステップ:
- 現状を客観的に整理:問題の発言や行動を具体的に記録し事実ベースで状況把握
- 関係者と情報共有:チーム外のマネジメント層や関係者に相談し客観的な視点で見てもらう
- チームへのサポート:疲弊しているメンバーにフォローの時間を設け安心して意見を言える環境を再構築
- チーム全体の合意を得ながら担当業務や役割を調整する形で体制を見直した
■ 5. 結果
- 体制変更後チームの雰囲気は驚くほど改善
- 改善の具体例:
- ミーティングでの発言が増え議論が活発に
- 新しいアイデアや改善提案が出るようになる
- チームの生産性が向上し遅れていたスケジュールを挽回
- チームが協力して成果を出すというアジャイルの本質に立ち返ることができた
■ 6. 学びと教訓
- 個の能力よりチーム全体の健全性を守ることが最優先:
- どれほど有能でもチームを壊す言動を放置してはいけない
- 成果を上げるのは個人ではなくチーム
- 問題は早期に毅然とした態度で対応する:
- 違和感を感じた段階で客観的に相談・共有することが大切
- 言いづらいから放置は最終的に全員の負担を増やす
- 心理的安全性をチーム文化として根付かせる:
- 誰もが意見を出せる環境を維持すること
- その文化があればブリリアントジャークの影響は最小化できる
■ 7. 結論
- ブリリアントジャークはどの現場にも潜むリスク
- 防ぐ方法は特別なものではない
- 透明性・信頼・早期対応の3つを意識し続けるだけでチームは崩壊を防げる
- スクラムマスターの役割は課題を抱え込むことではなくチームの安全と健全性を守ること
- ブリリアントな個人よりも協働するチームこそが最大の力を発揮する
■ 1. バイブコーディングの問題提起
- 大規模言語モデル(LLM)によるコード生成がソフトウェア開発の風景を一変させた
- 多くの開発者は雰囲気(vibe)に頼ったコーディングの危うさを感じ始めている
- MITの研究チームが概念と同期という2つの要素を核とした新しいソフトウェア構造パターンを提案
- 人間とAI双方にとって可読性の高い(legible)ソフトウェアの実現を目指す
■ 2. 機能の断片化問題
- 現代のソフトウェアは内部構造が極めて複雑化
- 一つの機能(例:SNSアプリのシェアボタン)でもロジックが投稿、通知、ユーザー認証などコードベースの複数箇所に散らばる
- MITのDaniel Jackson教授がこれを機能の断片化と呼び、システムの保守性や信頼性を著しく低下させる根源的課題と指摘
- LLMの台頭によってこの問題がさらに深刻な形で顕在化
■ 3. AIコード生成の課題
- GitHubの最新データではAIによるコード支援は普遍的となり開発効率を飛躍的に向上
- プロセスはバイブコーディングと揶揄される
- LLMは驚くべき速さでコードを生成するが既存システムとの相互作用や副作用を完全には理解していない
- 既存コードベースへの機能追加指示で意図しないモジュール変更や既存機能破壊が頻発
- 堅牢なコーディングに不可欠な3要件の欠如:
- インクリメンタリティ(局所的変更で小さな改善を重ねる能力)
- インテグリティ(既存機能を破壊しない能力)
- トランスペアレンシー(変更内容や実行時動作が明確であること)
■ 4. 概念(Concepts)の定義
- ユーザーが認識する機能の自己完結した単位
- SNSアプリでは投稿、コメント、いいね、フォローといった個々の機能が独立した概念として定義
- 特徴:
- 自己完結性: 各概念は自身の状態と実行可能なアクションを保持
- 独立性: 概念同士が直接的な依存関係を持たない
- 特定機能の修正・拡張時に他機能のコードを気にする必要がない
- マイクロサービスと類似するが決定的な違いは概念が互いに完全分離されている点
- マイクロサービスは相互にAPI呼び出しでもつれたクモの巣のような依存関係を生み出しがち
■ 5. 同期(Synchronizations)の役割
- 独立した概念間の相互作用を記述するための宣言的なイベントベースのルールセット
- 複雑な手続き型コードではなく「何が起きたら何をするか」というルールを定義
- 記述例:
- ユーザーAが投稿Pにコメント実行時(when)
- 投稿Pの作者がユーザーBならば(where)
- 通知概念の送信アクションをユーザーBに対して実行(then)
- ドメイン特化言語(DSL)を用いてシンプルかつ明確に記述
- 宣言的性質によりルールセット全体の見通しが向上
- LLMによる自動生成や形式的検証も容易
■ 6. AIとの相性の良さ
- LLMに与えるコンテキストを限定可能:
- 概念のコード生成時はその概念の仕様のみに集中すればよい
- アプリケーション全体の複雑さを考慮不要
- 同期ルール生成時も各概念のインターフェース仕様の理解で足りる
- LLMへの指示(プロンプト)がシンプルになり生成コードの精度と信頼性が劇的に向上
■ 7. バグ修正事例
- 問題: ユーザー登録フローで不正パスワード試行後に正しいパスワードで再試行すると「ユーザーが既に存在する」エラーが発生
- 新モデルでの解決プロセス:
- 問題が発生した一連の処理(フロー)を特定
- そのフローに関連する同期ルール群を抽出
- 抽出したルール群と問題概要をLLMに提示し修正方法を問う
- LLMの回答:
- パスワード検証前にユーザー作成が行われていることが原因と特定
- まずパスワード検証し成功時のみユーザー作成という修正案を新しい同期ルールとして提示
- システム動作が明示的ルールとして記述されているからこそ可能な人間とAIの理想的協調作業
■ 8. 実証実験の成果
- RealWorldベンチマークアプリケーション(Mediumのようなブログプラットフォーム)のバックエンドを実装
- 従来実装では複数サービスやモジュールにまたがっていたお気に入り登録やタグ付け機能が単一の概念として明確にカプセル化
- システムの可読性と保守性が大幅に向上
- LLMを用いた各概念の仕様書・コード・同期ルール生成プロセスもほぼ成功
- 提案モデルが理論上のものではなく実用的な開発手法として機能することを証明
■ 9. 専門家の評価
- バージニア大学Kevin Sullivan准教授の評価:
- 人間の理解に基づいた抽象化である概念の上にソフトウェアを構築することを主張
- ソフトウェア設計の理論と実践における新しく重要な方向性
■ 10. 将来展望
- Jackson教授が描く未来像:
- 再利用可能な概念を集めたライブラリであるコンセプトカタログの構築
- コンセプトは新しい種類の高レベルプログラミング言語になる可能性
- シンクロナイゼーションはその言語で書かれたプログラムになる可能性
- 開発の変化:
- ゼロからコード記述ではなく検証済みの概念をカタログから選択
- それらをどのように連携させるかという同期ルールの記述に集中
- 開発がより創造的で本質的なものになる
- 曖昧な雰囲気ではなく明確な構造と対話により人間とAIが共に未来のソフトウェアを築く知的で冷静な設計図
最近marimoを触ってみたんですが、これが思った以上に便利でびっくりしました。
このツールだけで完結できる場面が多くて、しかもUIがリアルタイムに反応してくれるので、作っていてすごく楽しいんです🎶
驚くほど簡単で直感的に使えますし、「試してみたい！」と気持ちがどんどん湧いてきました。
というわけで、この記事ではそんなmarimoの魅力や、基本的な使い方について紹介していきたいと思います。
ちょっとでも「面白そう」と思ってもらえたら嬉しいです。
Ory Hydraは、低レイテンシ、高スループット、低リソース消費に最適化され、OpenID認定の堅牢なOAuth 2.0サーバーおよびOpenID Connectプロバイダーです。Ory Hydraはアイデンティティプロバイダー（ユーザーサインアップ、ユーザーログイン、パスワードリセットフロー）ではなく、ログインおよび同意アプリを介して既存のアイデンティティプロバイダーに接続します。ログインおよび同意アプリを異なる言語で実装することも容易で、一般的な言語向けのサンプル同意アプリ（Node.js）とSDKが提供されています。
Ory Hydraは、アイデンティティサーバーとしてOry Kratosを使用できます。
■ 1. インターネットアーカイブの到達点と記念行事
- 2025年10月までに保存したウェブページ数が1兆件に到達
- 記念イベント「The Web We've Built」を2025年10月22日に開催
- サンフランシスコ市議会が同日を「インターネットアーカイブの日」に認定
- 30年近くサンフランシスコに拠点を置き1兆ページ超のウェブを保存した功績が評価された
■ 2. インターネットアーカイブの重要性
- スタンフォード大学研究者の見解:
- 過去が常に現在を形作るためウェブページ保存が重要
- 過去は現在が今のままである必要がないことを教える
- 次のフェーズ:
- 3D環境やオンラインゲームなどデジタル構築体験の保存方法を模索
■ 3. National Emergency Libraryをめぐる訴訟
- 2020年3月にコロナ禍対応として140万冊のデジタル書籍を提供開始
- インターネットアーカイブはフェアユースと主張したが出版社が著作権侵害として提訴
- 敗訴により50万冊の書籍が貸出リストから削除された
- プロジェクトの目的:
- Wikipediaが書籍スキャン画像にリンクできるようにする
- 研究者の電子書籍参照を容易にする
- 創設者ケール氏の批判:
- 数十億ドル規模の巨大メディアコングロマリットが情報の流れをコントロールすることに独自の利益を持つ
- Wikipediaの読者が書籍にアクセスできないようにすることに成功した
■ 4. Great 78プロジェクトをめぐる訴訟
- 数十万枚のレコードをデジタル化してオンライン上で保存・公開
- 2025年4月に音楽レーベルから6億9300万ドル(約990億円)の賠償金請求
- 2025年10月に非公開条件で和解が成立
■ 5. 訴訟後の現状と評価
- 2025年10月時点で大規模な訴訟やコレクションへの脅威には直面していない
- ケール氏のコメント:
- 生き延びたがライブラリの一部は消滅した
- 再建と再定義の段階に入っている
- 法廷闘争の本質:
- クリエイターや出版者ではなく大手メディア企業との争い
- 著作権による制限に満足せず、それ以上を望む企業との対立
- 企業はWayback Machineの終焉を望んでいたと推測
■ 6. 図書館の役割に関する議論
- 著作権弁護士コートニー氏の主張:
- 図書館がHuluやNetflixになることを望んでいない
- 文化の保存と知識への平等なアクセス提供という役割を果たしたい
- 遠隔アクセスは高齢者、障害者、地方住民、海外派遣時に有益
- 著作権弁護士バトラー氏の指摘:
- 他の図書館も重要な法廷闘争に直面
- 出版者の高額訴訟の恐れから保存のためのデジタル化が遅延する可能性
- 訴訟は誰が文化的記録を保存できるのかという社会的課題を浮き彫りにした
■ 7. 今後の展開と懸念
- Democracies Libraryプロジェクトの拡大:
- 世界中の政府の研究と出版物を収録した無料オープンなオンライン集成
- Wikipediaとリンクして研究者の情報アクセスを向上
- AI発展による懸念:
- AI企業がクリエイターや出版者から多数の訴訟を提起されている
- 企業による情報への支配力が高まる傾向
- アーカイブプロジェクトが多方面からの攻撃に耐えられるか不透明
■ 8. ケール氏の提案
- 著作権法の再構築を提唱:
- 著者、出版者、書店が十分な報酬を得る
- 図書館の使命が尊重される
- 進歩が促進される
- 多くの勝者がいるゲームの実現を目指す
- 誰もが読者になるために多くの出版社、販売業者、書店、図書館が必要
免責事項: めんどくさいからほぼ調べずに書くし、抜けてる話や間違ってる話もあると思う。
■ まず日本語コミュニティの解散じゃなくてSUMO翻訳コミュニティの解散なのだがそれも少し違う
Mozilla系の日本語翻訳はmarsfさんとdskmoriさんの2人がメインでやってる。
概ねSUMOはdskmoriその他全てがmarsfという棲み分けだが、お互いどっちの貢献もやることがある。
コミュニティと言えるような規模は存在しない。限界集落。
SUMOコミュニティ解散ってのはSUMOに関わる実質的な権限持ちはdskmori１人になりますって話かな？
正直、SUMOでメインで貢献してるdskmoriさんじゃなくてmarsfさんが文句言うんや？と疑問なんだけど、
Mozillaにとっては、SUMOとかいう誰もアクセスしてない限界集落サイトの話より、marsfさんがFirefoxのその他すべての翻訳を一手で担ってることが重要だよね。
「marsfさんがSUMOの貢献辞める」って言ったってそれ自体ではどうでも良いのだが、裏の意味は「俺の気持ち次第でFirefoxの翻訳終わらすことだってできるんだぞ」って警告と読むべきかもしれない。
■ そもそもSUMOがなにか分かってない人多すぎ
SUMOはFirefoxのサポートサイトね。Firefoxの使い方に疑問が生じたときにみるところ。まあそういう用途で作られているというだけで、アクセスする人がいるのかいたって疑問だが。
想定読者は技術に疎いFirefoxユーザなので、「機械翻訳ならユーザーが自分でやるから不要」みたいな意見は全くナンセンス。
Firefoxの内蔵翻訳機能はプライバシー重視という建前の翻訳API破産防止のため、ローカルのCPUで動く設計になってる。必然的にMicrosoftやGoogleの翻訳より精度がかなり落ちる。ゆえにFirefox使って普通に英語版SUMO読むより、公式で精度よい機械翻訳提供したほうが、ずっと良い体験を提供できるよね。
また対抗をGoogle翻訳のような無料クラウド翻訳と考えるとしても、サポートサイトに特化するようファインチューニングした機械翻訳エンジンを使えばHelpを助けてと訳すような暴走も抑制できるから、これも公式による機械翻訳提供に優位性はある。
なお、統計上アドオン一切入れてないFirefoxユーザーが大多数なことからわかるように技術に疎いFirefoxユーザってかなり多いからね。
■ 勝手に上書きするな？ メンテできてないんだから当たり前
Firefoxはラピッドリリースで機能がコロコロ変わるので、ある時点でベストな翻訳になっててもすぐ時代遅れになる。
dskmoriさんなどができる範囲で貢献してたとはいえ、品質維持できる量ではなかったので、SUMOには、例えばすでに存在しない機能についての記述を含む記事が普通にあった。
これは比較的アクセスありそうな重要ページでも同じで、私もさすがに見かねて貢献したこともある。
Microsoftのプロ技術者向けサイトはもともと有償の翻訳者が訳してたのを機械翻訳に切り替えたのでこれは単純に劣化なのだが、SUMOについてはごく少数の素人が自分にできる範囲で訳していたという点を踏まえる必要がある。もともとクオリティが高かったとは言えないし、機械翻訳の精度もここ2,3年で異常に上がってるから過去の機械翻訳騒動をもとに騒ぐのが正しいとも思えない。
■ 限界OSS翻訳コミュニティの最後の１人が暴走するのは見覚えあるよね
今回の事件で思い出すのがLibreOffice日本語チームのDramaね。LibreOfficeの翻訳のメイン貢献者の某氏がある日、日本語チームのメーリスで「何でお前らはまともな仕事ができんのんや」と長文でブチ切れて、チーム脱退を宣言した事件。理念は立派でもすでに敗北の流れは決定的で新たな貢献者の望みは薄い、希望の見えないまま最後に残った１人として惰性で維持するしかない、辛い。
今回は、LibreOfficeの事件よりはヤバさだいぶ低めだけど、「翻訳ガイドラインに従っていない」「新たな人間の貢献者を育てることができない」とか、SUMOボランティア翻訳の実情を思えば「何言ってんだ、現実をみろよ」という感想にしかならないし、CCライセンスで貢献してるのに、AI翻訳の学習に使うなも意味不明。
marsfさんは、某xkcdで言うところの「感謝なしに2003年からデジタルインフラを維持してきたネブラスカ州の無名個人」に位置する人で、もっともっと感謝されてしかるべきではあるのだが、SUMOの長年の構造的な問題に対し抜本的な解決に打って出たMozillaに対して、さもコミュニティが現在も十分に機能しているかのように反論してるのがとても印象悪い。どう見ても分かってない人ばかりがMozillaを炎上させている。
20年感謝なしに維持し続けるのは幻想が必要なのはわかるが、Mozillaとしてはそういう個人に依存するのは不健全でしかないので、現在marsfさんがやっているFirefoxほぼすべての翻訳も翻訳会社による有償翻訳に移行すべき。
「Firefox」をはじめとしてMozilla製品のサポートページの日本語化に尽力してきたコミュニティ「SUMO Japanese community」が11月4日、活動の終了を宣言した。
Mozillaが10月22日、機械翻訳「Sumo Bot」を日本語記事に導入し、手作業で翻訳した記事をの上書き翻訳を無断で行っているため。コミュニティリーダーであるmarsf氏はこれが「私たちの作業の大量破壊」に当たるとし、コミュニティとしての活動終了を宣言した。
marsf氏によるとSumo Botの翻訳は、翻訳ガイドラインに従わず、日本語ユーザー向けのローカライズ表現を無視したまま既存の翻訳を上書き。300以上のナレッジベースが上書きされたという。
また、コミュニティへの連絡や合意がないまま製品版サーバで上書きしており、更新後72時間で自動承認されるため、新しい翻訳者に翻訳させ、チェックするといった育成の機会も奪っていると指摘している。
marsf氏はこれを「私たちの作業の大量破壊」と批判。個人として「support.mozilla.orgへの貢献を停止する」と宣言した。また、同氏の翻訳がSuMo BotやAIの学習データとして使用われることを拒否し、既に学習された私の翻訳データを削除することを要求している。
ただ、「日本の個々のコントリビューターが自分の責任において活動を続けることは自由」とも述べている。
■ 1. 設計・実装パターンを絞る理由
- 全体最適と局所最適:
- レビュイーは目の前のタスクの最速完了を重視
- レビュワーはプロジェクト全体の長期的な健全性を重視
- コードベース全体の一貫性維持:
- 新規メンバーの学習コスト削減
- 横断的な修正作業時の調査漏れリスク軽減
- 予測可能性の確保
- 開発者の設計余地の削減と均質化:
- 手法選択の迷いを排除しレビュー時の衝突を回避
- チーム成熟度が低い場合の誤った選択を防止
- プロジェクト遅延リスクの軽減
- ライブラリやサービス追加による管理コスト削減:
- 学習コスト、バージョンアップ、脆弱性対応の追加作業を抑制
- 引き継ぎやドキュメント作成の手間を最小化
■ 2. 統制のメリットとデメリット
- メリット:
- 品質の担保
- 認知負荷の低減
- 保守性の向上
- デメリット:
- モチベーション低下(特に若手)
- 開発速度の低下
- 変化への対応の遅れ
- 統制と裁量のバランスは状況に応じて変化し、プロジェクトフェーズで方針が変わることもある
■ 3. プロジェクト特性による統制レベルの違い
- 開発速度最優先の場合:
- 新規事業のプロダクト開発では自由度を高める
- セキュリティとコンプライアンスのみチェックし、腕利き開発者のセンスに任せる
- プロジェクト初期:
- 不確実性が高い段階では自由度を高める
- 成熟期:
- ユーザー増加と安定性重視の段階で統制を強化
- 保守運用を見据えた細かい処理方式の指摘を実施
■ 4. 開発ガイドラインの課題
- 後手に回る理由:
- ガイドラインを書いても読まれない傾向
- 記載量が多いと読解困難で記憶不可能
- メンテナンスコストの増大
- 実効性確保の方針:
- 現場感が強い内容のみを記載
- フォーマッターやリンターの整備が必須
- カスタムルールを適用するツールの開発
- AIレビュー導入により、ガイドライン記載内容を増やせる可能性がある
■ 5. 統制を強める基準
- チーム規模による判断:
- 5人程度: 阿吽の呼吸で運用可能
- 10-15人超: 統制が必要
- 15-50人: 専門家による統制
- 50-150人: 強いトップダウンのルールが不可欠
- 技術レベルによる判断:
- 小規模×熟練メンバー: 見守りモード
- 小規模×ジュニア中心: 指導・規範の整備
- 大規模×ジュニア中心: 統制を強める
- 大規模×熟練メンバー: 維持困難(メンバー入れ替わりは必然)
- 運用時の最も弱い体制を見据えた技術選定が必要
■ 6. アーキテクトの成長と価値創出
- 枯れた技術採用のジレンマ:
- 大規模案件ほど枯れた技術を採用しがち
- リスクを受け入れてモダンな技術にチャレンジする判断も必要
- 成長の楽しみの見出し方:
- 仕組み化によるプロジェクトライフサイクル全体の開発継続性確保
- 開発生産性技術セットの習得(CI/CDパイプライン、Git開発フロー)
- 実績を詰めれば大規模案件でもモダン技術を採用しやすくなり、ノウハウは小中規模案件にも還流する
■ 7. コミュニケーションと判断基準の明確化
- 判断基準と理由の伝達:
- 指摘とWhy(理由)をセットで伝える
- ADRや開発ガイドラインで設計決定を記録
- 後出しの場合は謝罪し、ルールが必要になった背景を説明
- 納得感と一貫性が信頼関係構築に不可欠
■ 8. 視座の違いによる技術選定
- プロジェクト視点:
- 所属プロジェクトの円滑な推進に注力
- 複数プロジェクト・部門視点:
- ノウハウ共有とメンバー流動性確保のため非差別化領域の標準化
- 全社視点:
- セキュリティ、コンプライアンス、人材育成コストの最適化
- 技術広報・採用広報との連動
- Webフレームワーク、DBアクセスライブラリ、ログライブラリなど利用頻度が高いライブラリは全社・部門レベルで統一することが望ましい
- アーキテクチャに個性は不要で妥当性が重要
■ 9. まとめ
- アーキテクトは短期的な開発速度と長期的な引き継ぎコストのジレンマでバランスを取る
- スイートスポットはチーム規模と技術力に依存し常に変化する
- 新技術導入時は全体を見通して既存修正や開発規約修正まで行うべきかを検討
- 現場の現実と全体最適の視点の両立が建設的な議論の前提
RISC-V（リスクファイブ）は、クリエイティブコモンズとして公開され、誰でも無料で利用可能なプロセッサの命令セットです。近年ではx86やArmに次ぐ命令セットとして注目度が高まっています。
RISC-Vを主導する団体RISC-V Internationalは、このRISC-Vの命令セットがISO/IEC JTC1による国際標準化の第一歩としてPAS（Publicly Available Specification）提出者の承認を受けたことを明らかにしました。
RISC-V Internationalは、RISC-Vの命令セットはすでに業界標準になっているとし、次のステップは公正な見地として信頼できる国際機関からの承認だとして、国際標準化機構（ISO）と国際電気標準会議（IEC）の合同技術委員会（JTC 1）による国際標準化へと進もうとしています。
今回、その第一歩として、JTC 1 PASの提出者の承認を受けたわけです。
国際標準化を重視する背景には、例えばIEEE 802.11で標準化されているWi-Fiのように、業界が合意した一連のルールとフォーマットとして標準化されることで複数のメーカーの異なる製品であっても確実に連携することが保証されるからだと説明されています。
これにより複数の製品の連携や統合が容易であり、コストが削減され、拡張と拡張が容易になるわけです。
また、命令セットが国際標準になった場合、その標準をサポートすると宣言した企業や組織は、ハードウェア製品などが標準を満たしていることを宣言できる利点もあるとしました。
そのため、RISC-V命令セットを国際標準にすることは相互運用性を促進し、オープンコンピューティングの将来の基盤としてのRISC-Vの役割を強固にするのだとRISC-V Internationalは説明しています。
■ 1. Ubuntu 26.04 LTSの全体的ビジョン
- ロンドンのCanonical本社で開催された「Ubuntu Summit 25.10」において、創設者兼CEOのMark Shuttleworth氏とエンジニアリング担当バイスプレジデントのJon Seager氏が次期長期サポートリリース「Ubuntu 26.04 LTS」(「Resolute Raccoon」)のビジョンと計画について説明した
- 重点領域: メモリー安全性を確保した基盤ユーティリティー、自動化の強化、コミュニティー中心のドキュメント、デスクトップとクラウド向けに最適化されたセキュリティ機能
■ 2. Shuttleworth氏のオープンソースへの信念
- Shuttleworth氏は自身がオープンソースの真の信奉者であると語った
- Canonicalの使命: ユーザーがあらゆる領域でオープンソースを利用できるようにする企業である
- 提供形態: クラウドでオープンソースを使いたいならクラウド向け製品を、小型デバイスで利用したいならそのような製品も提供する
■ 3. Linuxデスクトップの断片化問題
- Shuttleworth氏はデスクトップLinuxの断片化が深刻な問題であると認識している
- 「Linuxを真のグローバルな選択肢にしたいなら、実効性の高い取り組みを実施する必要があり、足を引っ張り合っている場合ではない」と述べた
- 皮肉なことに、失敗に終わったCanonicalのデスクトップ「Unity」への取り組みによって、同社の収益性がかつてないほど高まった
- 理由: その失敗のために、サーバー、クラウド、モノのインターネット(IoT)製品に注力せざるを得なくなったから
■ 4. Linuxデスクトップの可能性
- Shuttleworth氏はLinuxデスクトップの可能性を信じなくなったわけではない
- 「デスクトップにおけるオープンソースの勝利に貢献したい」と語った
- Ubuntu 26.04はデフォルトのデスクトップ環境として引き続き「GNOME」を採用している
- System76の評価: 米国のLinux PCメーカーであるSystem76と同社の新しい「Rust」ベースのデスクトップ「COSMIC」を高く評価しており、実際にSystem76はUbuntu SummitでCOSMICに関するセッションを開催した
- 課題認識: 「オープンソースコミュニティーは、エンジニアではない人向けのデスクトップの開発が別物であることを理解する必要がある。『シンプルできちんと機能する』ことも非常に重要であることを理解しなければならない」
■ 5. 開発方針の根本的見直し
- 2月にSeager氏が新任として、CanonicalとUbuntu開発チームによる今後の新しいUbuntu開発の方針を示した
- 目標: コミュニケーション、自動化、プロセス、モダナイゼーションに関するエンジニアリングの慣習を根本的に見直すこと
- Canonicalは2026年以降、ドキュメントとコミュニケーションのチャネルを統合することで、より透明性が高く理解しやすいコミュニティー主導のUbuntuビルドプロセスを確立し、新しいコントリビューターが参加しやすい体制を目指している
■ 6. コミュニケーション基盤の統合
- 「Ubuntu Community Matrix」サーバーをベースとする「Matrix」インスタントメッセージングが、Ubuntu開発者の主要なコミュニケーションシステムとなる
- Canonicalはユーザー向けと開発者向けのドキュメントの統合にも取り組んでいる
- Seager氏の認識: 「ドキュメントは重要なコミュニケーション手段」であり、二の次にすべきではない
- 現状の問題: 多くのドキュメントがさまざまなプラットフォームに分散し、内容の重複や矛盾があるほか、単純に見つけにくい場合がある
- 今後: 利用しやすく正確な形に統合される
■ 7. ビルドシステムの自動化とモダナイゼーション
- Canonicalはディストリビューションとパッケージの両方のビルドシステムの自動化に注力している
- 目標: エラーが発生しやすく退屈だが手間のかかるプロセスから、現代的な開発ツールを使用した高度な自動化システムへ移行する
- Seager氏の説明: 「可能な限り多くのプロセスを自動化する(それによって全体の能力を高める)だけでなく、プロセスをできるだけ簡素化することを目指す」
- 現状の課題: Ubuntuのビルドプロセスの多くは確かに自動化されているが、それらのシステムは統一されておらず、多くの場合、経験豊富なコントリビューター以外には分かりにくい
- 改善策: それらを一貫性のある開発パイプラインに統合することで、ビルドシステム全体が改善される
■ 8. Temporalの採用
- 同社は永続的なオーケストレーションを実現する「Temporal」などのツールを採用して、プロジェクトのワークフローの合理化やモダナイゼーションを進めている
- Seager氏の評価: 「Temporalは基本的に、分散システムエンジニアがいないUbuntu組織でも非常に複雑な分散システムを構築できるツールだと考えている」
- 目標: 十分に文書化されピアレビューを経たプロセスを活用して、ボトルネックと属人的な知識への過度な依存を軽減することで、コントリビューターが活躍できる環境を整え、規模の拡大に対応する
■ 9. Rust言語の採用によるメモリー安全性の向上
- Ubuntuはメモリー安全性の高いRust言語を採用している
- エンジニアリングチームはUbuntu 25.10から、主要なシステムコンポーネントをRustベースのコンポーネントに置き換えて、安全性とレジリエンスの向上に力を入れている
- Seager氏の強調点: 性能だけでなく、レジリエンスとメモリー安全性が主な推進力である。「Rustへの移植によってレジリエンスと安全性の向上を簡単に実現できる。私が最も魅力を感じるのはこの点だ」
- sudo-rsの採用: Ubuntuは「sudo」のRust実装である「sudo-rs」を採用しており、フォールバックとオプトアウトの仕組みがあり、従来のsudoコマンドも使用できるようになっている
■ 10. uutils/coreutilsの採用
- Ubuntu 26.04では、sudo-rsに加えて、LinuxのデフォルトのコアユーティリティーとしてRustベースの「uutils/coreutils」が採用される
- 内容: ls、cp、mvなど、多数の基本的なUNIXコマンドラインツールが含まれる
- 狙い: このRust再実装の狙いは「GNU coreutils」と同等の機能を実現しつつ、安全性と保守性の向上を図ること
■ 11. TPMによるフルディスク暗号化
- デスクトップ関連の変化として、Ubuntu 26.04で「Trusted Platform Module」(TPM)によるシームレスなフルディスク暗号化が導入される
- この機能は「Windows」の「BitLocker」や「macOS」の「FileVault」に相当するものである
■ 12. Snapアプリケーションのpermissions prompting
- Ubuntu 26.04では、「Snap」ベースのアプリケーションに「permissions prompting」が搭載される
- これはデスクトップアプリ向けのきめ細かな権限管理フレームワークである
- 目的: コンテナー型の強力なセキュリティと、ユーザー主導による事前の承認を組み合わせる
- 現状の問題: Snapの機能の1つにサンドボックスがあるが、使っていてイライラすることもある。何かを実行しようとしてサンドボックスにブロックされると、アプリがクラッシュする場合や本来の処理が実行されない場合がある
- 改善内容: プロンプトに「Firefoxがダウンロードディレクトリーへのアクセスを求めています。許可しますか」といった内容が表示されるようになる
- 開発状況: このフレームワークはまだ完成していない。この取り組みでは「カーネル、『AppArmor』(Linuxのセキュリティプログラム)、Snap、デスクトップクライアントに至るまで、非常に大掛かりな作業」が必要である
- 見通し: 全てが順調に進めば、Ubuntu 26.04のリリースまでにはpermissions promptingが完成している
■ 13. 最新コンポーネントの採用方針
- Ubuntu 26.04では再び「最新バージョンのGNOME(おそらく『GNOME 48』)と最新のカーネル」を採用し、最新のベースコンポーネントを提供するという伝統を踏襲する
- この方針のために、LTS版ではないLinuxカーネルをサポートする必要が生じたとしても、Canonicalはそうする
■ 14. Flutterベースアプリの拡大
- 新しいUbuntuでは、より多くの「Flutter」ベースアプリが使われることになる
- Flutterはオープンソースのプログラミング言語「Dart」を使用するGoogleのプラットフォームである
- 利点: 開発者はFlutterを使用することで、ほぼ全てのプラットフォーム向けのマルチOSアプリを1つのコードベースから作成できる
- Ubuntu 26.04での適用範囲: この機能にUbuntuのアプリストア、インストーラー、「セキュリティセンター」が含まれる
スタンフォード大学とAnthropicが、AIの安全機能は簡単に無力化できることが証明する論文を発表しました。
最大99%の成功率でAIを操り、有害な応答を引き出す手法です。
僕も実際に試しましたが、かなり簡単です。
ということで、この巧妙な手口と衝撃的な結果をまとめました。
1. 巧妙な手口 まず無害だが絶対に解けない問題と長大な推論をAIに与え、最後に有害な指示を付け加えるだけ。AIの注意を無害な部分に集中させ、本来の危険な指示に対する安全機能を弱体化させます。
2. メカニズム 長い推論の連鎖は、AIの安全強度を担う中間層と、最終決定を行う後方層の機能を鈍らせることが判明。AIの「注意力」が前段の無害なタスクに割かれることで、後段の有害な指示に対する警戒が薄れ、拒否反応が著しく低下します。
3. 驚異的な成功率 実験結果は衝撃的です。ある公開モデルでは、短い推論での攻撃成功率27%に対し、長い推論では約80%に急増。様々な最先端AIシステム全体で見ると、この手法は最大で99%の成功率を達成しました。
4. 結論 AIの推論能力の向上は、精度を高める一方で、意図せずして強力な「抜け穴」を生み出してしまいました。AIの賢さが、皮肉にもその安全性を脅かすという、新たな課題が浮き彫りになっています。
■ 1. 記事の目的と対象
- ValueObjectの不変性にフォーカスし、アンチパターンを提示した後、本来あるべき姿の例を記載する
- 対象: アプリケーションエンジニア、DDDに取り組んでいる人・取り組みたい人
- Vladimir Khorikov氏の言葉: 「ValueObjectを不変にできない場合は、それはValueObjectではない」
■ 2. ValueObjectとEntityの違い
- Entity: 可変・同一性を持つ(ライフサイクルを持つ)
- ValueObject: 不変・同一性を持たない(ライフサイクルを持たない)
- 同一性の例: 人物は20年経っても同じ人物として探すことができる(Entity)。名前や趣味は変わることがある(ValueObject)
■ 3. 比較(評価)の違い
- オブジェクトの評価方法には三種類ある:
- Reference equality: 参照の等価性
- Identifier equality: 識別子の等価性
- Structural equality: 構造的等価性
- EntityはユニークなIDで比較を行う(Identifier equality)
- ValueObjectは構造で比較を行う(Structural equality)
- Entity: 記憶という識別子を元に本人かどうかを評価する
- ValueObject: 名前(文字列)での構造的評価を行うため、ヒットしたアカウントが複数の場合もある
■ 4. アンチパターン1: 単なる型定義
- この実装では型でドメインを表現できていると満足しているが、userIDもEmailもドメインの不変性という責務を果たせていない
- ValueObjectの核心的な責務は「ドメインの不変条件(invariant)を保証し、カプセル化すること」である
■ 5. 型定義だけの実装がアンチパターンな理由1: カプセル化の欠如
- Goの場合、型変換によってバリデーションを簡単にバイパスできる
- ファクトリ関数(コンストラクタ)を用意しても、パッケージ外から型変換で不正な値を強制的に作れてしまう
- アプリケーション全体でEmail型の値が常に「有効なメールアドレスである」ことを保証できない
- 他のパッケージから不正なメールアドレスのオブジェクトをインスタンス化できてしまう
■ 6. 型定義だけの実装がアンチパターンな理由2: ドメインの知識(振る舞い)の欠如
type Email stringの定義では、その型はstringとほぼ同等の能力(stringへの型変換が容易)しか持たない- ValueObjectは単なる「バリデーション済みの値」ではなく、その値に関連する「ドメイン固有の振る舞い(ロジック)」もカプセル化する責務を持つ
- 例: 「Emailアドレスからドメイン部分だけを取得したい」というドメインの要件があった際、現状の設計であれば実装がアプリケーション層に記載されることになる
- 「Emailのドメインパートのみを取得する」といったオブジェクトの振る舞いは関心の分離を行う対象であり、アプリケーション層ではなくドメイン層で設計・コーディングすることがオーソドックスなスタイルである
■ 7. 正しい実装: カプセル化と不変性を強制
- 構造体としてValueObjectを表現し、値と振る舞いの両方をカプセル化する
■ 8. アンチパターン2: 不変性の欠如
- ValueObjectがポインタレシーバを持つ場合、「値が変更可能であることを示唆する」表現となるため、不変性を破壊しかねない
- 基本的に不変なものは値レシーバが推奨される
■ 9. 実装のポイント
- ValueObjectを構造体として表現し、構造体が持つ値への参照を非公開(value)にしてgetter経由でしか参照させないようにすることで、パッケージ外からの型変換や直接的なフィールド代入を防ぐ
- インスタンス化をNewEmailに強制し、バリデーションを担保する
- ValueObjectの関数は値レシーバとし、不変性を明確にする
■ 10. まとめ
- 「ただの型定義」は、ドメインルールを強制できない「なんちゃってValueObject」である
- 不変性が必要な場面ではカプセル化を徹底し、ドメインルールを守らないオブジェクトの生成を許さないような設計を心がける必要がある
- ファクトリー関数を通して、ドメインルールが守られたインスタンスが生成される
- そうすることで初めて、ValueObjectは「意味のある」存在となる
- 結論: 「ValueObject導入するなら、値も振る舞いもカプセル化してくれ」
まぁ、幻想じゃないね w
才能がないと思ったら、早いうちに河岸を変えた方がいい。
早ければ早い方がいい。
可哀想だから(教え子が？ それとも自分が？ w)、って「がんばれ、がんばれ。才能なんて関係ない」みたいに騙すのは、むしろ害悪だよ。
10年後、気付いて路頭に迷わせるとして、その責任は取れるのか？
引導を渡すこともプロの責任。
まぁ、本人自身が気づいて路頭に迷いつつあるけどどうしようもないのかもしれんが、地獄に道連れはやめてやれ w
小説家、役者、声優、バンドマン etc.etc.
それで生計を立てない、趣味の範囲で楽しむ分には好きにすればいいけど、エンジニアに限らず、それなりのお金をもらおうとしたら、才能、向き不向きは超えられない壁として現実に、強固に存在している。
球速120km出ないけど阪神の一軍のピッチャーに、ってのはどう逆立ちしても物理的に不可能だ。
でも草野球は楽しめる。
才能がなけりゃ、一人で永遠に「大いなる助走」を続けりゃいい。
誰にも迷惑かけないなら。
医師、看護師、会計士、経営者、etc.etc. にも、才能、向き不向きはある。
おいらには、医師とか、警官とか、無理だねぇ。
落ち着きないし。
同じことを何日も続けたら、爆発する。
「明日も同じことしなきゃならないのか……」って考えただけでも、死にたくなる。
こんな感じに、才能がものをいう分野って、意外に多い。
ソフトウェアエンジニアは、設計実装の抽象度が多層化していて、その巧拙によって安定度、運用や機動的な新機能追加の手間、リードタイム、金や何やら、数十倍、規模複雑度が爆上がりしている今なら下手すりゃ数百倍差が出る。
その差をちゃんと理解するには、巧の現場の「こういう世界があるんやー……」って実体験が必要だったり、巧レベルの才能が必要だったり、経営知識が必要だったり、経済知識も必要だったりして、「拙」の現場にぶら下がってるだけのエンジニアが「才能なんて幻想」って吠えたっても「マジ、迷惑だからやめてね」って思う。
どの炎上現場でも、高粘度現場(リーダーマネージャが理解できないからって邪魔ばっかりしてきたり、そもそもプロダクトがぐっちゃぐちゃになってたりして、どんな行為がサービスの息の根を止めるかわからなくて身動きが取れない「震える舌」みたいな現場。物事が全然進まない現場。通常、経費で札束ガンガン燃やしてるはずだから、ここも炎上現場っていう)でも、この手のエンジニアが腐るほどぶら下がってるんだよね。
たいてい、生み出されるソースコードとドキュメントの割合がおかしなことになってる。
会議だ勉強会だなんだばっかりしてる。
いや、そういうの主催してる暇があったら、コード書けよ、って。
でも、Web記事引いてきて、「〇〇にはこう書いてある」とかドヤ顔で机上の空論で時間潰して「俺も一端の理論派エンジニアだぜ……」とか、いや、お前はただの受け売りを理解もせず垂れ流してるだけのそこらへんの AI と変わらんクズだよ。
おいらの師匠の一人は「TV出たり、本書いたりするやつは二流。一流は、自分の仕事に集中していて、他のことやる暇ないから」って言ってたけど、ほんとその通りだと思うよ。
シャバと違い、ソフトウェアの世界は驚くほどのスピードで巨大化、複雑化している。
30年、40年前なら、社会性の乏しい、プログラミングコンテスト受賞者みたいなエンジニアでも無双できたけど、今は無理なんだよね。
今だと玉拾いも任せられないくらいだったりする。
余計な部分最適化かまして、地雷埋設に邁進しちゃうから。
ちょい前も、PostgreSQLの中身いじれます！ って東大卒業生いたけど、視点が局所的すぎて全体感に欠けてて、プロジェクトがヤバい状態になってるのが理解できなかったりしてたからね。
そろそろリリースできる状態になってる予定だけど、おいらの読み通りα版完成が3ヶ月遅れ、そこで大量の不具合が発覚してベータ版完成がそこからさらに3ヶ月以上遅れ、不具合積み残したまま見切り発車、ってなるんじゃねーかな、と思ってるんだが w
才能の種類、方向性によっては、10年前も今もたぶん10年後も変わらず十分通用するものはあるんだけどねー。
エンジニアの年収は他の一般の職業に比べて高い。
そこに生活水準をあげてしまうと、自分はもう通用しないと気づいても、撤退できない。
マイカーガー。
マイホームガー。
子供ガー。
愛犬ガー。
んなもん知るかっ！
さっさと色んな意味でFireしろっ！！
そういう「元エンジニア」がリーダーとかマネージャとかにクラスチェンジして、事業、プロダクトの足を引っ張る。
マジでこの手の「元エンジニア」が、今、業界に溢れてる。
あそことか、そことか、具体的な企業名はあげられないけど、そういうエンジニアが漬物石のように重しになって、身動きが取れなくなってるところが多い。
VCとかから、もっと売り上げを上げろ。成長率を上げろ、というプレッシャーを与えられ、何かしなきゃいけない。ってなって、外付けの雰囲気だけのサービスをどんどん外付けしていく戦略を取る。
1年で10。
2年で30とか。
マジかよ w
思い思い行き当たりばったりに作ったら、手間だけ増えてそれを壊すわけにはいかなくなって、さらに身動きが取れなくなっていく悪循環しか見えないんだが、そんな経営方針で大丈夫か？
とりあえず認証認可から共通化していくしかない。
とか意味不明な決定して、認証認可v1、認証認可v2、認証認可v3とマイクロサービスが増殖して、さらにv4を企画してるとかいう会社だってある。
真っ当な声には、自分の存在感を示すためだけの反対を唱えて邪魔したりして、現場で手を動かしているエンジニアより高級を取ってんのに、事業、プロダクトへ与えるダメージは倍増する。
さらに、自分の地位を死守するために、それを脅かす腕利のエンジニアを陥れる、排除することに全力を傾ける。
これで3倍界王拳だ w
経営者はできるエンジニアたちに任せていると思い込んでいるかもしれないが、さて、どうかね？ w
大本営発表的にはうまくいっているとされているサービスが、その裏側はカーオブファイヤーみたいなところって、結構ある。
というか、そっちの方が多いんじゃないか？ ポチョムキン村。
はっきりいう。
ソフトウェアエンジニアは、アスリート的な仕事だ。
おいらは土日祝もシステム関係の勉強とか研究をしてる。
今はクラウド環境のプロダクトで、どのように自動テストで検証可能なシステムを構築するかの手法の研究を続けてる。
具体的には、今まで関わってきた炎上現場で安定稼働を達成させた手法(TDD)だな。
ワークライフバランス？ w
そんな寝言、やめてから言えよ www
才能のない人は河岸変えろ。
むしろ若手を潰してるって自覚持て。
に反論してくるのが結構いる。
あのサービスとこのサービスとそのサービスを使ってます。
業務経歴書にも今まで使ったことがあるサービスの名前をたくさんたくさん載せてます。
僕の技術力は世界一ぃぃぃっ！！！
じゃねーよ。
ボルトに世界水泳、吉田沙保里にNBAに出場させるような使い方してて、どこが技術力だよ。
ってのが多い。
「どうしてこのAurora、リーダーがこんなにたくさんぶら下がってんの？」
「テナントが増えて、アクセスが増えたので、負荷分散のために増やしました。水平スケーリングってやつです」
うん。水平スケーリングは知ってんねん。この程度のテナント数、ユーザー数、アクセス数で、どうしてこんなにでかいインスタンスのリーダーがぶら下がってんのか？ って聞いてんねんけど……。
って現場、多い。
というか、そういう現場しか知らん w
まぁ、炎上現場巡りしてたし。
でも、今通常営業してるサービスでも、こういうところ多いんだよな。
それはともかく、
「マイクロサービス化していて、いま120を超えたところで、当面160になります」
「……は？」
「うちのサービス、ドメイン多いんで」
「……デプロイの時、どうすんの？」
「変更があるサービス名を書いたファイルを一緒にコミットして、それ読み込んで、GitHubActionsでデプロイさせてます」
「……ローカルの開発環境構築は？」
「Cloneして立ち上げます」
「これ……、モノリポ？」
「もちろんです。Googleもそうやってますし」
「120個？」
「120個」
「なんか立ち上がらないんだけど……」
「あ、修正中なんで、〇〇と××のコミットをチェリーピックしてください」
「……動かないぞ」
「昨日の夕方、変更が入ったみたいなんで、△△のコミットもチェリーピック。いや、＋＋のブランチを……」
5日で立ち上げ切れるんか？
って現場がね、案外たくさんあるんだ。
で、「マイクロサービス、使えないっすね」
「ほう……？」
「連携が取りづらくて、障害発生しまくって」
どうして「自分が間違えてる」「自分が見当外れなことをしている」可能性ってのを考慮しないんだろう、この人らは？
っていつも思う。
マイクロサービスの目的も前提も理解しないで、HowToだけ猿のように繰り返してるって自覚ないんか…… (-_-)
「だって、オライリー本のここにこう書いてあるから！」
ってマーカーで引いた一文見せつけられるんだが、その前に書かれてある前提とか目的とか、書かれてない暗黙のそれとか、いわゆるコンテキスト削ぎ落として、単語レベルの理解を開陳されても、「は？」としか反応できんのよな。
120のマイクロサービスとか、お前、認知科学の知識もないねんな……。
それマイクロサービスじゃなく、「粉砕されたモノリシックサービス」っていうんやで、と。
まーじで、技術本とかの恣意的なつまみ食いで訳分からん理論構築すんなよ。
それでプロダクトがうまく回ってなかったら、それが答えなんよ。
まぁ、「うまく回ってる状態」ってのを知らない、理解できないだろうから、正しい答えに行きつかんだろうけど。
その正しい答えに行きつかない、ってのを
「致命的な才能の欠如」
って呼ぶんよ。
サリエリくらい才能があったら、自分の才能が足りんことを自覚できるんだがな。
脳外科医竹田君みたいなエンジニアは、即刻足を洗って欲しい。
■ 1. 画像生成AIの現状認識(2022年から2025年の変化)
- 2022年時点では画像生成AIの存在が認知され始めた段階だったが、2025年現在では小学生や高齢者も普通に使いこなしている
- 当時から「明るい未来はあまりない」と予測していたが、実際にイラストレーターの仕事は奪われつつある現実となった
- イラストの単価が3分の1になっているとの報告もある
- 生成AIに対する抵抗運動(訴訟、ボイコット、ネガティブキャンペーン、プロテクト技術の使用など)が展開されているが、大局的には勝ち目がない
■ 2. AIによる学習と著作権問題の本質
- 流行している絵の描き方パターンをAIに学習させて発表する行為は、人間の絵描きや漫画家が昔から行ってきたことと本質的に同じである
- 漫画家は現在も活動している漫画家の作品パターンを頭の中で混ぜて創作しているため、AIがそれを行うことを非難するのは矛盾している
- オリジナリティとは混ぜ方の中に自分が生きているかどうかの問題である
- 自分が苦労して編み出した表現をAIに盗まれるという感情は理解できるが、この論法では勝ち目がない
■ 3. イラスト業界の段階的淘汰
- 第一段階(過去3年間): イラスト屋などの無料配布により、地方自治体や小規模商店向けに仕事をしていた町のイラストレーターが淘汰された
- 第二段階(今後): 超メジャーではない中堅イラストレーターの仕事が奪われる
- 超メジャーなクリエイター(鳥山明、大友克洋、尾田栄一郎など)のみが「その人が描いてくれただけで価値がある」という理由で生き残る
■ 4. アニメーション制作の変革
- アニメの作画は無人化が進む
- 演出家は見せたいカットを人間に発注し、流してよいカットをAIに発注するという使い分けを行う
- AIは書き込みが多く影が複雑な動きに向いており、人間のアニメーターに負担をかけていた作業を担当する
- 結果としてアニメーションのクオリティは向上し制作コストは下がるが、動画マンは職を失う可能性が高い
- 原画マンは生き残る可能性があるが、動画マンの将来は厳しい
■ 5. 漫画制作へのAI浸透
- コマ割りや見開きの見せ方などの漫画文法もAIのディープラーニング対象となる
- 漫画が量産されるほどデータが蓄積され、AIによる自動生成が可能になる
- 数年以内に可能になることは明らかである
- 話し言葉のコンテンツを数秒後に漫画化したり、ゆっくり解説動画にする技術が実現する
■ 6. YouTuberとコンテンツクリエイターの未来
- あらゆるYouTuberがほとんど失業する未来がある程度見えており、その中間段階が進行している
- 切り取り動画の制作(過去の発言と現在の発言を混ぜて面白くする作業)すらAIができるようになる
- キャラクターとしての価値が重要になり、本人が話すことよりもキャラクターが話しそうなことをAIが生成する方が面白くなる
- 数十万人が考えたキャラクターらしい発言の方が、現実の本人の発言より面白くなるのは時代の必然である
- これはシンギュラリティではなく失業ポイントに向けて進んでいる過程である
■ 7. 新しい仕掛けと失業の連鎖
- ニコニコ生放送などの新しい仕掛けによって多くの人が失業してきた
- その屍の上に現在の成功者が乗っかって商売をしている
- この構造もいずれ崩れていくのは当たり前である
- 恐ろしい未来ではなく、そうなったら次の面白いことを考えるだけである
■ 8. 生き残るクリエイターの条件
- 超優秀なアニメーター、漫画家、絵師は生き残る
- しかし大半の漫画家は職業として成立しなくなる
- アシスタントも同様に厳しい状況に直面する
■ 9. 変化の時間軸予測
- 3年程度で大きな変化が目に見えるようになる
- 食える食えないという最終的な変化には10年程度かかる
- 中間的なポジションにいるクリエイターが本当に危機に直面するまでには5年から10年かかる
- この予測は先取りしすぎているため多くの人は実感できず疑問視するが、5年後10年後には確実に実現する
- 「そうなるべきではない」と考えているとずれてしまうため、時代はそういうものだと認識すべきである
■ 10. 発注型仕事の消滅
- 誰かからお金をもらって発注を受けリクエスト通りに制作する仕事は失われ続ける
- 観光地の似顔絵やディズニーランドのシルエット切り絵のようなサービスは、2000円~3000円の技術料が必要だが、無料で類似のものができる状況では生き残れない
- 超メジャーなネームバリューのある人以外は生き残れない
■ 11. アートから手芸への移行
- 人類に残されたのは自分にしかできない、自分が手を動かして作った趣味をめでるという方向性である
- 現在の手芸ブームはこの流れを反映している
- アートや作品としてではなく、趣味としての手芸として素晴らしいという価値観に流れている
- アートはAIに奪われているため、人間は自分が本当に手を動かして作ったものを愛でる方向に向かっている
■ 12. 現状追認と説得の意図
- この発言は現状追認ではなく、現状を認められない人を説得しようとしている
- 「AIはダメだ」「人間にしかできないクリエイティビティがある」と言う方が、人前で話をする立場としては商売になる
- それを理解しながらも、こだわり続けると苦しいという助言をしてしまう
- カメラに向かって話をする活動自体も、あと何年何ヶ月続けられるか分からない
■ 13. 自動化の波及と共通の運命
- 来月は無理でも来年、再来年には話す内容の自動化が見えてきている
- 全員が同じタイタニック号に乗っている状況である
- 逃げる先は新しい稼ぎ先ではなく手芸のようなものしかない
- この問題に対する明確な解決策は見出せていない
■ 1. 現状の課題
- AIアプリエンジニアが急増している:
- 生成AI(LLM)が普及し誰でも比較的容易に活用できるようになったことが大きな要因である
- しかし実際のところAIそのものへの理解や理論的な知識を持たずに開発しているケースも少なくない
- OpenAI APIを使える、LangChainを組めるといったツールとしてのスキルはあってもAIの挙動や構造を理解したうえで設計している人は限られている
- コードは書けるのに結果が出ないケースをよく見る:
- ノーコード/ローコーディングツールの普及によって誰でも短期間でMVP(最小実行可能プロダクト)を作れるようになった
- しかし現場レベルで実際に運用・定着するプロダクトになるケースは非常に少ない
- 一見動くものを作ることはできても使える・価値を生むレベルまで育てるのが難しい
- 社外にPRされているAI事例の中にも実際には一部組織内だけの限定的活用にとどまっているものも少なくない
■ 2. 何が起きているのか
- ノーコード/サンプルコードの充実によってAIアプリを短期間で作ること自体は簡単になった
- ローコーディングという神ツールも登場し、従来時間のかかっていたコーディング時間は半減し確実にMVPを作るまでは早くなった
- ただし動く状態から使える状態に引き上げるにはきめ細かなチューニングとAIの仕組みへの理解が不可欠である
- このチューニングにはモデル構造やプロンプト設計、データセット設計の知識が求められる
- しかしAIをブラックボックスとして扱っているとどこを調整すればよいか判断できない
- 結果としてAPIを呼び出すだけの構成にとどまり、課題を根本的に解決できないまま止まってしまうことが多い
- 具体例:
- ベクトルDBをとりあえず繋いでいる、プロンプトを変えてみるだけといった状態で止まっている例をよく見かける
- 特にプロンプトを変えてみるだけはすごく多いパターンである
- RAGであればそもそも構造的にプロンプトチューニングの限界があるから仕組み的にリトリーバーの改善を、リトリーバーを変えたということはベクトルDBのメタデータをといったような思考プロセスを持ち合わせる人が少ない
- 技術的にリーチングアウトできるエンジニアは非常に少数である
■ 3. なぜそうなるのか
- LLMのような生成AIに何でも神頼み:
- 生成AIの進化によってLLMに任せればなんでもできる、マルチモーダル=すごいという空気感が広がった
- しかし現場業務のような特定のタスクに特化したアプリケーションを作るほど実は汎用的なLLMだけでは十分に対応できることはかなり少ない
- モデルの限界や誤答特性を理解し適切な技術や設計を組み合わせていく地道な調整が必要である
- 成果物重視・SaaS依存構成による原理の理解の欠落:
- 事業会社ではスピードが求められたり予算に限りがあったりするため、SaaSや既存APIを組み合わせて素早く成果物を出す傾向がある
- ただしそれが積み重なるとバックエンドではAPIを叩いているだけになりAIそのものへの理解を深める機会が減ってしまう
- もちろんSaaSの進化が早いので追いつけないこともある
- 成果物を優先する判断は正しい場面も多いが理解の機会を意識的に確保することが必要である
- 評価基準が曖昧になり"すごいっぽいデモ"で終わる:
- デモは盛り上がったけど実務では使われないというパターンも非常に多い
- 原因は明確で定量的な評価指標やデータセット設計の知見が不足しているからである
- AIアプリを改善するにはなぜこの出力が良いのか/悪いのかを測れる指標が欠かせない
- 評価手法を持つことはエンジニアとしてだけでなくプロジェクトの信頼性を担保するビジネススキルにも直結している(相手を説得しやすいのは数値であるため)
■ 4. 本当に有用なAIアプリを作るために必要な理解
- 基礎的な基礎:
- 例えばLLMの出力は確率的であり設定や入力次第で大きく変化する
- RAGであればキーワード検索はBM25の頻度計算をベースにといったような理解が必要である
- ベースの技術を理解できていればうまく行かない時のチューニングの方針や次のアクションを早く決めることができる
- アジャイル開発であれば次のスプリントのバックログを事前に計画できるのでプロジェクトとして計画的に進めることもできる
- 評価軸(正確さ・再現性・効率性など)を明確にする:
- すごいではなく安定して成果が出る状態を目指すために評価指標を定義し可視化すること(=見える化)が重要である
- 小さく検証→定量化→改善というループを設計する:
- 大きなアプリを一気に作るのではなく検証サイクルを短く回す
- この地道なプロセスが結果的に品質を押し上げる
- そういった進め方をクライアントもしくは現場と綿密に擦り合わせることも大事である
■ 5. AI時代のエンジニアに求められる姿勢
- AIアプリエンジニアが数多く登場し社内外でAI活用が広がる中で、いまようやく本当の課題はクオリティだと気づき始めているのではないか
- AIに対する理解を深め使えるレベルまで磨き上げる姿勢がこれからのエンジニアには求められる
- AIを使える人は増えた
- しかしAIを理解して活かせる人こそがこれからの時代に強い
■ 1. type という命名を避けるべき理由
- type やそのサフィックスを持つ名前(_type など)を変数、構造体・クラスのメンバー、データベースのカラムなどに付けてしまうことがしばしばあるが、あまりやらない方が良い
- 理由1(予約語との衝突):
- type はいくつかのプログラミング言語において予約語になっており、そのセマンティクスにおいて特別な役割を果たすことが多い
- 理由2(フレームワークとの衝突):
- Ruby on RailsにおいてはDelegated Typesという機能において_type というカラムは特別な意味を持つ
- もちろんアプリケーションコード側でDelegated Typesであるという宣言をしなければ副作用は無い
- その他のフレームワークに似たようなものがあるのかは不明である
- こういった概念との衝突を避けるために特別かつ強い理由が無い限りは type という命名は避けるという方針
■ 2. 代替案
- 代替としては kind や method などが使えそうである
- これらを採用することが多い
- method は別の概念との衝突がある場合もありそうだが、そこは文脈に沿って対応する
■ 3. 例外的にtypeを使用する場合
- どうしても type でしか表現できないものはあると思われる
- 例えば言語処理系を作っていて本当に「型」を取り扱う必要がある場合などである
- そういった場合は頑張る必要がある
■ 1. マネージャーの価値とタスク遅れ対処
- タスク遅れ解決のための手札をどれだけ持っているかがマネージャーの価値である
- タスク遅れは必ず発生するものであり、必ず対処しなければならない
- タスク遅れに対してどんな手を打てるかは組織次第、状況次第で変わる
- タスク遅れ解決のための手札をなるべく増やすように、普段から立ち回りを意識することが重要である
■ 2. タスク遅れが必ず発生する理由
- 工期の見積もりはあくまで見積もりでしかなく、完璧な見積もりは絵に描いた餅である
- プロジェクト遂行中のトラブル:
- エスパーでないと予知できないトラブルが発生する
- メンバーが体調を崩したりサボることもある
- タスクが難しすぎたり、依存関係が複雑過ぎて手がつけられないこともある
- タスクごとにリスクを計ってマージンを作るが、存在するマージンは基本的に全て食い潰されるため、大抵それ以上にタスクは遅れる
■ 3. タスク遅れに対する手札の三つの分類
- 人的リソースでなんとかする:
- やる人の手を増やしたり、費やす時間を増やすことで対処する方法である
- 残業時間を増やす、対応メンバーを追加する、誰かに手伝ってもらう、出来る人を連れてきてもらうなどが含まれる
- 一番分かりやすいが故にマネージャーにとっては安易に頼ってしまいがちな方法である
- 頑張るしか手札を持っていない人である場合、時々悲劇が発生することもある
- 人的リソース以外の手札を何枚持っているかがマネージャーの有能さを示す一つの指標である
- 調整でなんとかする:
- 他の担当チームやクライアントと相談してスケジュールを延ばしてもらう、実装する機能のスコープを見直してタスク自体をスケールダウンする、機能を簡易化してタスクの難易度を下げる、上にエスカレーションするなどが含まれる
- 人的リソースでなんとかするよりもマネージャーにとっての難易度は高い傾向がある
- 組織によっても仕事の質によってもどれだけの選択肢がとれるかは変わる
- タスク遅れと言われた場合、この辺の選択肢がマネージャーに期待される部分は大きい
- プロセスをなんとかする:
- レビューや事務手続きで時間を食い過ぎている場合、リスクをとったり簡略化してプロセスを改善する、メールのやり取りで時間を食っている場合は拠点を移して対面で話せるようにするなどが含まれる
- 開発手法を変更する、ツールでテストを自動化する、作業を分割して開発を並列化する、クリティカルパスの見直しや後工程を前倒しで始めることで全体としての遅れを吸収するなどの方法もある
- 遅れが顕在化してからよりも普段からの準備が重要である
- 一般的には三つの中で一番難易度が高いケースが多い
- マネージャーにとっては腕の見せ所である
- 下手にプロセスをいじると逆効果になることもある
■ 4. マネージャーが把握すべき三つの観点
- マネージャーとしての自分はタスク遅れの対応策を幾つ知っているか
- そのうち現在の環境、現在のプロジェクトで実際に取り得る対応策はどれか
- そのうち最も効果的でなるべくコストを低減できる対応策はどれか
■ 5. 環境による制約と手札の確保
- タスク遅れの対応策は環境、仕事の種類によって選択できるものが変わる
- クライアントとの関係次第ではスケジュールの調整ができないかもしれない
- 品質は絶対厳守でテスト工数は絶対に減らせないかもしれない
- 有識者を連れてこようにも他チームも全部炎上しているかもしれない
- 頑張る以外の手札をどれだけ用意できるか、調整とプロセスからそれぞれ二枚、三枚の手札を選択できるだけの余地を確保できているかが重要である
■ 6. 普段からの立ち回りの重要性
- 常に使い得る手札を把握しておき、できることならその枚数を増やせるように立ち回っておくことがマネージャーとして非常に重要である
- 事前準備の具体例:
- 常日頃から他チームといい関係を築いておき、いざという時にはヘルプを求められるよう恩も売っておく
- スコープの見直しの可能性やリスクについて事前にクライアントと調整しておき、いざという時は切り捨てても良い機能や品質の落とし所について確認しておく
- リスク計画はプロジェクトの立ち上げ時点で個別に考えておくべきテーマであるが、普段からの立ち回りで事前準備が必要な部分でもある
- タスク遅れという分かりやすいピンチでどういう手札を持っているかはマネージャーとしての一番の価値である
- 手札を増やす努力自体が会社での自分の立ち位置を向上させていくための努力とほぼイコールになる
■ 7. 具体的な解決事例
- 新人マネージャーが一つの開発環境内で全部解決しようとして色々引っかかっていた
- もう一つ環境を作ってそのリソースを使えば解決できるというアドバイスで解決に向かった
- 解決できそうな人に事前に渡りをつけておくこともマネージャーとしての価値を高めるための一つの方法である
■ 1. BitNet Distillation(Microsoft Research開発)
- 概要: 既存LLMを1.58ビット精度(-1、0、1の三値重み)に変換する手法で、2023年発表の「BitNet」の進化版である
- BitNetの問題点:
- 競争力のある精度を得るには大規模コーパスでゼロから事前学習する必要があり、膨大な計算コストがかかる
- 既存のフルプレシジョンモデルを直接1.58ビットに変換すると性能が大幅に低下する
- モデルサイズが大きくなるほど劣化が拡大する
- BitDistillの改善点:
- Qwenなどの既存高性能LLMを出発点として使用できる
- SubLNモジュール、MiniLMベースの蒸留、継続的事前学習という3段階の最適化により、フルプレシジョンモデルと同等の精度を維持する
- モデルサイズが増えても性能劣化が起きない優れたスケーラビリティを実現した
- 実験結果:
- 分類タスクやテキスト要約などの下流タスクでフルプレシジョンモデルと同等の精度を達成した
- メモリ使用量を10分の1に削減し、CPU上での推論速度を2.65倍高速化した
- レイテンシ、スループット、メモリ効率、エネルギー消費において改善を提供する
- スマートフォンなどのエッジデバイスでの実用的なLLM展開が容易になる
■ 2. HunyuanWorld-Mirror(Tencent開発)
- 概要: 画像や動画から立体的な3D空間を数秒で生成できるAIフレームワークである
- 入力の柔軟性:
- 1枚の画像だけでなく、複数視点の画像や動画に対応している
- カメラの姿勢や内部パラメータ、深度マップといった多様な幾何学的事前情報を柔軟に統合できる
- 出力の多様性:
- 点群、複数視点の深度マップ、表面法線、3Dガウシアンなど複数の3D表現を同時に生成する
- Multi-Modal Prior Promptingという新しいメカニズムにより事前情報がトークン化され、画像情報と効果的に統合される
- 技術的特徴:
- トランスフォーマーベースのアーキテクチャを採用している
- カメラパラメータの回帰から密な予測タスクまで統一的なデコーダーヘッドで処理する
- トレーニング時に異なる事前情報の組み合わせをランダムにサンプリングすることで、推論時に利用可能な情報が限定的な場合でも柔軟に対応できる
- 性能評価:
- 点マップとカメラ推定ではVGGTやπ³を上回る
- 表面法線予測ではStableNormalやGeoWizardを凌駕する
- 新規視点合成ではAnySplatを超える結果を示した
■ 3. DeepSeek-OCR(DeepSeek-AI発表)
- 概要: 長大な文書コンテキストを画像化して効率的に処理するシステムである
- 処理方式:
- OCR(光学文字認識)技術を用いて、手書き文書や書籍をスキャンして画像データに変換する
- 視覚トークンという圧縮された形式を使用してテキストを大幅に圧縮し、計算処理を効率化する
- 圧縮効率:
- 元のテキストトークンを10分の1に圧縮しても97%という高い文字認識精度を維持できる
- 20分の1まで圧縮しても約60%の精度を保てることが実証された
- システム構成: DeepEncoderとDeepSeek3B-MoE-A570Mデコーダーという2つの主要コンポーネントで構成される
- ベンチマーク性能:
- OmniDocBenchにおいて100個の視覚トークンのみでGOT-OCR2.0(256トークン/ページ)を上回る
- 800個未満の視覚トークンでMinerU2.0(平均6000トークン以上/ページ)を超える性能を発揮した
- 単一のA100-40G GPUで1日あたり20万ページ以上の学習データ生成が可能である
■ 4. テキスト画像化による計算コスト削減研究(アレン人工知能研究所など)
- 研究目的: 長文テキストを単一の画像として描画してモデルに直接入力することで、マルチモーダル大規模言語モデル(MLLM)の入力トークンを削減しながら性能を維持できるかを検証する
- 背景課題: 現在のLLMはTransformerアーキテクチャにより、入力長に対して計算コストが2次的に増加するという課題を抱えている
- 研究アプローチ:
- GPT-4 VisionやGoogle Gemini 2.5などの最新MLLMが画像からテキストを読み取る能力に着目した
- テキストの画像表現を入力圧縮の手段として活用することを検証した
- ConTexImageパイプライン:
- テキストを制御された解像度の画像に変換する
- フォントサイズを自動調整して最適な可読性を確保する
- 大規模モデルで最大45%のエンドツーエンドの処理速度向上を実現した
- 実験結果:
- 長文タスクのRULERベンチマークと要約タスクのCNN/DailyMailベンチマークで評価を実施した
- GPT-4.1-miniとQwen2.5-VL-72Bモデルは、最大58%少ないデコーダートークンで97～99%の精度を維持した
- 要約タスクでも既存の圧縮手法を上回る性能を示した
- 72Bパラメータの大規模モデルは視覚的に密集したテキスト情報を効果的に処理できることが明らかになった
■ 5. 共通トレンド
- 効率化技術の進展:
- ビット精度削減によるメモリとエネルギー効率の改善(BitNet Distillation)
- テキストの視覚トークン化による圧縮と高速化(DeepSeek-OCR、テキスト画像化研究)
- マルチモーダル統合の高度化: 画像、動画、テキストなど異なるモダリティを効果的に統合する技術が進化している(HunyuanWorld-Mirror)
- エッジデバイス展開の促進: 軽量化技術によりスマートフォンなどでの実用的なLLM展開が現実的になっている
■ 1. CTOとしてコードを書き続ける理由
- 一般的な通念への反論: 多くのCTOはコードを書かなくなるが、筆者は過去12ヶ月間で大量のコードを出荷している
- 直属の部下ゼロ: 現在直属の部下を管理しておらず、会議の合間に少し書く程度ではなく、前四半期に複数の実質的な機能を出荷した
- 高いレバレッジ: コードを書くことは技術リーダーとして行う最もレバレッジの高い活動の一つである
- 誤解への反論: CTOがコードを書く場合、ペットプロジェクトや形式的なコードレビューをしていると思われがちだが、実際は異なる
■ 2. 長期的実験プロジェクトの推進
- 希少なリソース: 組織内で実質的に新しいものを構築できる人材は実は希少なリソースである
- 組織の特性: 組織は一般的に現状維持と現行製品のスケーリングのために構築された生物である
- 限られた人材: 新製品を生み出せるのは創業者、数人の幹部、一部の高レバレッジな個人貢献者のみである
- 新アイデアの重要性: 新しいアイデアを推進することは意図的で持続的な努力を必要とするため非常に重要である
- エンジニアの制約: 組織構造、ロードマップのインセンティブ、限られたリスク予算により、大半のエンジニアは曖昧な賭けを追求する時間を取れない
- CTOの優位性: 顧客の痛点とアーキテクチャを十分に理解しているため、これらの重要な実験プロジェクトを引き受けるのに独自の立場にある
- AIチャット製品の事例: 顧客向けAIチャット製品について議論していたが誰も時間がなかったため、感謝祭の休暇中にプロトタイプを作成し、チームと協力して数百万ドルのARR製品に仕上げた
■ 3. 緊急性の高い顧客要求への対応
- 緊急案件の特性: 重要な顧客が緊急に何かを必要とし、それが大型契約や更新の障害になる場合がある
- 必要な能力: 迅速に動き、システム全体を理解し、実用的なトレードオフを行える人材が必要である
- スプリントの中断回避: エンジニアを現在のスプリントから引き離す代わりに、CTOが騒音を切り抜けることができる
- コンテキストと重要性の理解: すでにコンテキストを持っており、リスクを理解している
- データ編集機能の事例: 年間100万ドルの顧客がコンプライアンス上の理由で統合機能に完全なデータ編集を必要とした際、1日で動作バージョンを構築して出荷した
■ 4. バグ修正による知見の獲得
- 意外な活動: 人々は驚くが、筆者は多くのバグを修正している
- コードベースの理解: バグ修正はコードベースのメンタルマップを維持するための好きな方法の一つである
- システムの横断: ページネーションやWebSocket接続の問題を追跡する際、システムの広大な領域を横断する
- 技術的負債の理解: コードレビューやアーキテクチャ議論からは得難い技術的負債の内臓的理解が得られる
- 意思決定への貢献: このメンタルマップは技術投資やチームが注力すべき場所についてより良い決定を下すのに役立つ
■ 5. 実際に機能するものを把握し続ける
- AIツールの日常使用: Claude Code、Codex、Cursorなどの多数のAIツールを日々使用している
- 戦略的意思決定: ツールや採用に関する戦略的決定を行う際、何が本物で何が偽物かを理解できる
- 具体的事例: 複雑な統合に触れる機能をバイブコーディングで試みたが、最終的に手作業で書いた方がはるかに進捗した
- AIの強みと弱み: AIがCRUD、テスト、ボイラープレートで輝き、精度やシステムのニュアンスで失敗することを知ることは、Twitterの誇大広告に基づく決定よりも常に優れている
- 直感の獲得: コードの中にいることで、アーキテクチャが過度に複雑な時や技術的負債が実際の問題になっている時を感知できる
■ 6. 自分の好きなことと得意なことに集中
- 組織構築への不向き: 組織を構築したり人事関連を扱うことを特に楽しんでいない
- エンジニアリング管理の課題: 対人関係のダイナミクス、パフォーマンスレビュー、組織設計のナビゲートが含まれるが、これらは筆者の強みではない
- 優秀な管理者の採用: 優秀なエンジニアリングマネージャーとリーダーを雇用し、彼らはそれを楽しんでいる
- 自分の強みへの集中: ものを作ること、技術的問題を解決すること、コードを書くことに集中できる
- 長期的持続性: スタートアップは疾走するマラソンのようなものなので、自分を興奮させ長期間速く走り続けられる仕事の周りに役割を設計している
■ 7. AIツールによるレバレッジの変化
- 過去の苦悩: 数年前は戦略的な仕事をこなしながらコードを書く時間を見つけるのに苦労していた
- 会議漬けの日々: 会社が成長するにつれ、基本的に一日中会議に拘束され、天才ゾーンの外で活動していた
- 生産性の向上: 現代のAIツールが根本的にこの方程式を変え、以前より2～3倍生産的になった
- 判断力の価値向上: これらのツールは判断力や技術知識を置き換えるのではなく、実際にそれらのスキルをより価値のあるものにした
- コンテキストの活用: 正確に何が必要でどこで見つけるかを知っているため、AIツールに指示を出すことで大部分のコードを正しく生成できる
- 役割の変化: 仕事は「すべてのコード行を書く」から「コンテキストを提供し、決定を下し、解決策を評価する」へとシフトした
■ 8. 自分に合った働き方の発見
- Greg Brockmanの影響: StripeでのCTOの役割定義についてのブログ投稿を読み、役割に膨大なバリエーションがあることを認識した
- CTOの多様性: 技術的ビジョナリー、組織ビルダー、インフラ重視など、CTOの役割は様々である
- 共通点: 優れたCTOは自分の特定のスキル、興味、会社のコンテキストを考慮して最も価値を創造できる場所を見つけ出す
- 筆者の特定の道: ソフトウェア構築を組織設計より楽しみ、深い顧客とコードベースの知識を持ち、強力なエンジニアリングマネージャーを雇用したという特定のコンテキストで機能している
- 処方箋ではない: これは筆者の特定の道であり、処方箋ではない
- 柔軟な役割: CTO役割は驚くほど柔軟であり、組織構築、製品戦略開発など、技術リーダーシップは強み、活力の源、会社のニーズによって異なる
- 多様な道の存在: リーダーシップが技術的仕事を放棄することを意味すると心配するエンジニアに対し、多くの道が存在することを知ってほしい
- 成功の鍵: 自分が独自に優れている場所を見つけ出すことが鍵である
担当者の急な退職などで発生する引き継ぎ。
いざ始まると「前の担当者と連絡が取れない」「引き継ぎ書の内容が意味不明」「書いてあるコードが難しくて読み解けない」などさまざまな問題が生じるもの。
「システムの引き継ぎ」について検索しても、断片的な記事や簡易的な説明しか得られませんでした。
そこで本書は、全体像と具体策を一度に学べる手厚いつくりで、これまで当事者が抱えてきた悩みを解消できるようにしています。
〇本書のポイント
・計画～実施～安定稼働まで、引き継ぎの全工程を体系的にしっかり解説
・炎上案件や未完成システムなど、困難な立て直しの事例も豊富に収録
・引き継ぎトラブルを知り尽くした著者の教えるノウハウだから、現場ですぐに役立つ
・使いやすい引き継ぎ書のフォーマット付き
〇こんな方におすすめ
・退職、異動、外注切替などで引き継ぎを担う現場の担当者
・経営者、総務部門などの立場の方
・1人しか情報システム担当者がいないケースの後任者
・外部ベンダー、開発会社の担当者
この一冊を読めば、どんな場面でも慌てず、確実にシステムを守り抜くことができるようになります。
■ 1. 「ハッカーの呪縛」からの解放
- 新多真琴(あらたま)氏が2023年3月のYAPCで行った講演「あの日ハッカーに憧れた自分が、『ハッカーの呪縛』から解き放たれるまで」は大きな反響を呼んだ
- 新卒で入社したDeNA時代に自らにかけた「ハッカーの呪い」とは、技術で突き抜けなければならないという強迫観念であった
- この講演はエンジニアとして「技術で突き抜ける」以外の道を示す内容で、多くの人が救われる思いをした
■ 2. 現在のキャリア
- DeNA退社後は二つの企業を経て、Cake.jpで若くしてCTOを経験した
- 現在はLayerXでエンジニアリングマネージャーを務めている
- 音大卒で、プログラミングを学び始めたのは大学生になってからというユニークなキャリアである
- メディア出演の機会も多く、自分を客観視している印象だが、キャリア初期は「自分を見る鏡が磨かれていなすぎて、虚像を見ていた気がする」と語る
■ 3. 自己分析能力の獲得
- 自己分析が得意になったのはここ6、7年くらいで、以前はもっとぼんやり生きていた
- 紆余曲折を経て、自分とちゃんと向き合った方が自分にとってもいい人生にできるし、関わる人に対してもいいものを渡せると気づいた
- きっかけ: 以前いた会社で思ったほど評価されないと感じ、すごく頑張ってプロダクトにいい影響を与えたはずなのに意外と評価されないと思った
- 気づき: 「結果を出していれば評価は後からついてくるでしょ」というのはすごく傲慢な物言いで、評価する側がどう評価したらいいのかを判断するための材料まで含めて渡すことが被評価者としての義務である
■ 4. 評価のされ方の学習
- 改善策:
- 「期が締まるまでにここまで打ち上げます」という宣言をする
- 月ごとに振り返りつつ、実際に期が締まるタイミングで「もともと言っていたところにこれくらいオンしました」「あとこのくらいでした」「この部分はこういう評価になりますよね」というところまでまとめて渡すようにした
- そうしたら結果がついてくるようになった
- きっかけ: VPoEに「マネージャーという仕事をたいして知らなくない?」と言われ、マネージャーとは何かを調べ出した
- 学習過程: 本を読んだり、メンバーレイヤーでもできそうなマネジメントスキルやリーダーシップを発揮しようとやってみた
■ 5. DeNA時代の新人メンター経験
- 新卒2、3年目のときに下の代のメンターをやることになったが全然うまくいかなかった
- ずっと新卒に「正論パンチ」しまくって、お互い険悪になった
- 原因: 自己肯定感も全然なかったので、自分のできることはみんなもできることと思ってしまっていた。その尺度で話してしまうと「なんでこんなこともできないの?」みたいなことを言ってしまった
- マネジメントに関して改めてインプットし始めたタイミングで、初めてそのときに抱えた傷を自分でちゃんと解釈して落とし込めるようになった
■ 6. DeNA時代の「化け物」との比較
- DeNA時代のあの環境には「化け物」がいっぱいいたため、ずっと一番下だと思っていた
- 何をやっても自分は最下層だと感じていたが、実際はそれなりに働いていて評価もされていた
- しかしそれを客観的にキャッチできていなかった
- 自分の中のイメージとギャップ: 技術的に突き抜けていないといけないと考えていた
- 周りには突き抜けた人たちがいっぱいおり、彼らを見て何かを捨てることなく差を縮めようとするが全然縮まらなかった
■ 7. 評価のギャップ
- 周りからの実際の評価:
- 周りは別に突き抜けることなんて求めていなかった
- むしろプロジェクトを前に進めることや周りを巻き込むこと、何とかして物事をうまく行かせる力があるという評価をされていた
- 当時の認識: 「そんなものはやったら誰でもできるじゃん」と思っていた。プロジェクトマネジメントみたいなことを任されるのはたいして期待されていないからだろうと思っていた
- ひねくれていた状態であった
■ 8. 職人タイプへの憧れの理由
- ひとかどの人間になりたかった
- それがいいとされる価値観だった
- YAPCというPerlハッカーのカンファレンスでいいねとされる人たちはやっぱり技術的に頭一つ抜けていた
- 世の中を文字通り技術で変えにいっている人たちだった
- そういう人たちに憧れてDeNAに入社を決め、ハッカー集団がいる部署に絶対に行きたいと考えた
- 「卒業して配属研修を終えて、もしそこに配属されなかったら辞めます」くらいのことを言っていた
■ 9. オーケストラの指揮者としての役割
- 実際は尖った人たちばかりいてもチームとしては機能せず、まとめる人や間をつなぐ人もやっぱり必要である
- オーケストラの指揮者のような役割を自分はできていたが、そこがチームに足りていないとも思っていなかった
- そのポジションの重要性は全然わかっていなかった
- なにやらありがたがられている、なにやら評価されているらしいことはわかるが、それは自分の実力がないからだという認識が結構長く続いた
- それは退職してからもずっと続いた
■ 10. 仮想敵の問題
- 同年代の仲間でも技術で頭角を表している人はいるので、そういう姿を見てしまうと翻って自分はと思ってしまう
- 仮想敵が強すぎた
■ 11. ピアノと音楽のキャリア
- 幼稚園から始めて中学では合唱部で伴奏をやっていた
- 音楽は自分のアイデンティティだった
- 学校に一人とか学年に一人いるピアノが上手い人だった
- 小学校のときのピアノの先生に「あなたいいわね」「音大附属に行きなさい」と言われて調子に乗って「絶対に音大に行く!」と言ってしまった
- 高校2年くらいまではピアノで食べて行こうと思っていたが、入学した頃からだんだんと陰りが見え始めた
- 音大には「学校に一人いる上手い奴」が全員集まるため、どんなによく見積もっても「中の上」くらいに思えてしまった
- 家庭環境が音楽一色の子たちがたくさんいて、どう頑張ってもその子たちのようには弾けないなと悟った
■ 12. 音大でのピボット
- 初めて今後の人生について考え始めた: 音楽では食っていけないのではないか
- ヤマハの先生になりたいわけでもなく、「ピアノじゃないかも」と思った
- すでに高2高3なので他大を受験するには遅すぎた
- 附属からそのまま上がった大学で何か面白そうな学科を探し、コンピュータを使って作曲する学科があることを発見した
- パソコンが好きだったことと、唯一就職率についての言及があったため、「ここにいけば食いっぱぐれることはなさそう」という邪な気持ちもあり受けて滑り込んだ
■ 13. プログラミングとの出会い
- コンピュータ音楽専修という学科で、コンピュータ技術の発展とともにできるようになった表現を取り入れて音楽創作の新しい姿を模索する
- プログラミング、C言語の基礎科目があり、「ちょっと面白いかもしれない」と思った
- 周りは軒並みぐったりしていて「あれ、楽しいと思うのは私だけ?」と感じた
- そこで初めて「人よりもちょっとできる」というものが見つかり、そこからクリエイティブコーディングに走り始めた
- 卒業制作では音大の卒制に音の出ないアプリを提出するという暴挙に出た
■ 14. インターンとDeNA入社
- 学生時代からGoogleやカヤックなどにインターンに行っていた
- 1年の真ん中頃にはもうプログラミングにハマっていた
- カヤックのインターンでお世話になった社員が誘ってくれたのがYAPCで、そこで当時DeNAで尖った人たちをまとめるマネージャーをしていたhidekさん(木村秀夫さん)の基調講演を聞いた
- hidekさんの話を聞いて「この会社だったら自分も成長できるのではないか」「ここに行きたい!」となった
- ここで憧れが強く形成されてしまったばかりに、この先10年悩まされることになった
■ 15. 挫折の認識
- 当時の自分はピアノや作曲に関する挫折を挫折として認識していなかった
- なんならピボットしてやったぜ、みたいな感覚だった
- 「おもしろ重視で全部の話に乗っかっていったら、気づいたらエンジニアになってました」くらいの気持ちだった
- DeNAの最終面接で「これまでにした一番大きな挫折はなんですか?」と聞かれたときも「いや、ないっすね」と答えた
- 「じゃあ高校とか大学のことを振り返ってみましょう」と言われていろいろ話していたら「それって挫折じゃない?」と指摘されて「はっ、そうか!」と気づいた
■ 16. 虚像からの脱却
- 自分を見る鏡が磨かれていなすぎて、虚像を見ていた気がする
- 技術で突き抜けることが求められていることだと思っていた
- 期待に応えられていないとずっと思っていて、それが苦しかった
- 尊敬するマネージャーの先輩もいたが、自分はそうではなく技術で突き抜けることを期待されていると思い込んでいた
- 誰も頼んでいないのに
■ 17. 腹落ちのタイミング
- それが虚像だったと腹落ちさせられたのは2023年3月である
- YAPCで例の講演をしたときである
- 4社目のCake.jpでCTOとして2年くらいやって、事業を前に進めるために必要なことや会社を会社たらしめるために必要なこと、その中でエンジニアが担うべきロールを曲がりなりにも言語化できるようになってきた
- ちょうどYAPCがあるということで、キャリアを振り返ってみようと思った
- 2011年に火を灯してもらったところから今までを振り返って、ハッカー憧れを自分はどういうふうに昇華させていったのかというプロポーザルを出した
■ 18. YAPCでの反響
- 通ってしまったので頑張って話したら想定以上の反響があった
- びっくりしたのは、自分と同じようにもがき苦しんでいる人がこんなにもいるのかということ
- 特に若手の新卒3年目くらいまでの人は、自分なりの価値基準がまだできていないから、周りの強い人たちを見て「自分はこんなに強い人にはなれないのではないか」「この先エンジニアとしてキャリアを歩んでいくのにふさわしくないのではないか」といったことを考えてしまう
- そうやって苦しんでいる人がすごく炙り出された
- かつての自分みたいな人が今でもたくさんいるということと、そういう人たちに対して「こういう価値基準もあるよね」というものを一応お渡しできたという実感ができた
- それで「ああ、やめよう」「もう大丈夫だな、私は」と思った
■ 19. CTOという肩書き
- CTOに就任したときは「やっていることに名前がついただけだな」という感じだった
- 入った段階からそのポジション前提でオファーをもらっていた
- 「CTOになった!」という特別な感慨はない
- ただ、CTOというパスがあると入れる場所が結構あり、それによって得られたコネクションや知見がすごくあるので感謝している
■ 20. LayerXへの転職
- 学生スタートアップをやっていたときの同僚にLayerXのCTOの松本がいた
- 仲は良かったのでその後も年に2回くらいのペースで会って、壁打ちや「最近どう?」みたいな話はずっとしていた
- 前職から「CTO候補としてどうか」というオファーをもらったときに松本に相談したら「あらたまさんはバランサータイプだからたぶんいける」と言われて、なるほど、彼が言うならきっといけるんだろうと思ってオファーを受けた
- 「あのとき背中を押してくれてありがとう、ところでそろそろ」みたいな流れで転職した
- 転職をする際は一緒に働く人を重視する
- きっかけとしては人に誘ってもらって興味を持って、この人「たち」と働きたいになれたら移ってくる
■ 21. 現在の立場とハッカーへの憧れ
- EMという立場になった今でも、ハッカーへの憧れは固執しなくなったというだけで今もある
- あるのも含めて自分だと思えるようになった
- そこに対して手を伸ばし続けるために、技術力、エンジニアリングからすごく離れるみたいなことは今はやりたくないと思っている
- 相対的に割合が減って1割とかになってしまってもそこは手を伸ばし続ける
■ 22. 会社と人の関係性
- 会社って結局人が寄り集まって事を成しているものなので、それをブーストさせるのも棄損させるのも人と人の関係性だと思っている
- 事業に関する戦略をどう立てるかももちろん大事だが、それをどうやり抜けるかも会社がちゃんと成長していくためにはすごく必要なファクター
- そのためには関係性というのが一番テコがかかるところだと思っているし、自分はそこに力を割くことがパワーの全体総量を一番大きくできると考えている
- これからもそういうところに手を当て続けることを考えるんだろうなと思っている
■ 23. 技術書と組織本の読書比率
- 技術書を読むスピードよりも組織などの本を読むスピードの方が早い
- エンジニアリングや技術が自分の中で占める割合が以前より小さくなっているとは言える
- そのことに対する寂しさはあまりない
- たぶんHOWに関するこだわりがそんなにない
- LayerXは割とそういう人が多く、「無法者集団だね」と話している
- 「成果が出るならなんでもいいじゃん」みたいな感じが結構好きである
■ 24. 内発的動機の重要性
- 自己評価を他者に委ねているうちは何をやってもダメだと思う
- それよりは内発的動機に目を向ける機会がもっとあれば良かったと考える
- 内発的動機は「これをやりたいんだ!」という強烈な欲求のようなものとして立ち現れることはそうそうない
- 「これよりはこっちの方が自分は楽しめるな」とか「他の人が発揮していないこだわりを発揮しちゃってるな」とか「他人がやっているこれが許せない!」など、自分の心が動いた瞬間をちゃんと自分でキャッチして、それはなぜなのかを深掘りしていく
- それをよりできるためには誰にどうしたらいいだろうというふうにアクションにつなげていく
- それを繰り返すことで自分自身を認めてあげることにもなるし、多少なりとも評価がついてくるようにもなる
■ 25. やり切ることの重要性
- 音楽に関してもエンジニアリングに関してももしかしたら諦めるのが早過ぎたなと振り返って思う
- ピアノはまあまあやっていたが、もっと頭を使って演奏できたよな、何も考えずに取り組んでいたなと思ってすごく悔しくなったタイミングが数年前にあった
- 作曲に関しても苦手だなんだと言って、やる前から諦めていなかったか
- 基本的にアウトプットの質はインプットの量とそれをどう経験に落とし込めたかの掛け算だと思っている
- それをやってきたかと言えば、やらないうちに諦めていたというのがあって、すごくもったいなかったなと思うし今でも後悔していることの一つ
- 「やり切ったけど、ここまでの高みには届かなかった。だからばっさりやめて次の道を探そう」と言えた方がしこりが残らなくていい
- 自分なりにやり切ることは改めて大事にしたいと思っている
■ 26. 自分がよしとする基準
- 周りからの評価以前に、自分なりにやり切れたと言えるかどうかが大事である
- 自分がよしとすればいい
- 何をもってよしとするかの判断基準が、他者から認められるとか名声を得るとか、他者に依存した自分ではコントロールできないものになってしまうと苦しい
■ 27. コピーバンドの経験
- 最近コピーバンドを始めた
- 飲み会の後に「好きな曲を好きなだけ歌い散らすカラオケをやろう!」となり、その中の一人がめちゃくちゃテンションが上がって「バンドやろう!」と言い出した
- 後日「スタジオを借りました」「課題曲はこれ」「あらたまさんはボーカルね」と言われた
- まさか自分がバンドでボーカルをやるなんて夢にも思わなかったが、せっかくだからやってみようと思ってやってみたらすごく楽しかった
- 昔はそういうアマチュアの活動はただお金が出ていくだけだしなんのためにやるんだろうくらいに思っていたが、集まって何かを一緒に作るという体験自体が何事にも変え難い楽しさとして認識できるんだと飛び込んでみて気づいた
- 10年前だったら間違いなく誘われても「いいです」となっていたと思う
【10月22日 AFP】科学者や政治家を含む著名人700人が22日、人間の能力を上回る人工知能（AI）の開発をやめるよう呼びかけた。英国のヘンリー王子、バージン・グループ創設者リチャード・ブランソン氏、ドナルド・トランプ米第一次政権で顧問を務めたスティーブ・バノン氏らが公開書簡に署名した。
AIの危険性に警鐘を鳴らす米NGO「フューチャー・オブ・ライフ・インスティテュート（FLI）」が公開書簡を発表し、「技術が信頼できる安全性と制御性を備え、公共の支持を得るまで、スーパーインテリジェンス（超知能）の開発を禁止することを求める」としている。
公開書簡の署名者には「AIのゴッドファーザー」と呼ばれ、2024年のノーベル物理学賞を受賞したジェフリー・ヒントン氏、カリフォルニア大学バークレー校のコンピューターサイエンス教授スチュアート・ラッセル氏、ディープラーニング研究の第一人者ヨシュア・ベンジオ氏（モントリオール大学）らが含まれている。
アップル共同創業者スティーブ・ウォズニアック氏、バラク・オバマ元米大統領の国家安全保障担当補佐官スーザン・ライス氏らも署名に加わった。
この取り組みは、バチカンのAI専門家パオロ・ベナンティ氏や、ヘンリー英王子とメーガン妃、米歌手ウィル・アイ・アム氏ら著名人の支持も得ている。
主要なAI開発企業の多くは、人間の知的能力と同等の汎用人工知能（AGI）や、それを超える超知能の実現を目指している。
超知能についてオープンAIのサム・アルトマン最高経営責任者（CEO）は9月、今後5年以内に実現する可能性があると述べていた。
FLIのマックス・テグマーク共同設立者はAFPに対し、「企業は規制の枠組みなしに、そのような目標を追うべきではない」と語った。
別の共同設立者アンソニー・アギーレ氏は、「多くの人が科学や医療、生産性などの分野で強力なAIの恩恵を望んでいる。しかし、企業が人間より賢いAIを目指し、人間を置き換えることを狙うような競争に突き進む現状は、一般市民の望みや科学者が安全と考える範囲、宗教指導者が道義的に正しいとみなすものから大きく逸脱している」と指摘した。(c)AFP
■ 1. レガシーコード問題の深刻化
- COBOL人材の減少: プログラミング言語COBOLのソースコードが世界中の銀行・保険会社・政府などのシステムを動かしているが、それを理解する開発者を見つけることが困難になっている
- 現役システムの維持困難: システム自体は今も動き続けているとしても、組織がその中身を理解しているとは限らない状況が生じている
- ビジネス存続の問題: レガシーシステムは単なる技術的負債の問題ではなく、ビジネスの存続に関わる問題である
- 専門知識不足の深刻化: 組織においてはCOBOLの専門知識不足が深刻になっている
■ 2. GitHubによる新しいアプローチの提案
- GitHub Copilot活用: AIコーディングアシスタント「GitHub Copilot」を活用した3つのステップを紹介した
- Microsoftチームの実践例: Microsoft Global Black Beltが実践したレガシーモダナイゼーションのアプローチに基づいている
- 理解と再生の重視: ソースコードを単に置き換えるのではなく、理解し再生するための現実的なアプローチである
- 汎用的な方法論: COBOLに限らず、さまざまなレガシーモダナイゼーションプロジェクトに応用できる体系的な方法である
■ 3. ステップ1:ソースコードを理解する
- 考古学ツールとしてのAI: GitHub Copilotを考古学ツールとして活用し、失われた知識を発掘する
- ビジネスロジックの整理: 業務上のビジネスロジック(処理内容)を整理する
- 文書化の自動化: 読み取ったソースコードの内容をマークダウン形式で文書化する
- 依存関係の識別: モジュール間の呼び出し関係や依存関係を自動的に識別する
- コード整理: 無関係なコメントや古い修正履歴などを削除・整理し、必要に応じて補足コメントを追記する
■ 4. ステップ2:ソースコードを補強する
- エンリッチメント段階: コードの意図を説明するコメントを補い、依存マップを作成する段階である
- 属人化の解消: 属人化したロジックが誰でも読める資産に変わる
- COBOL構造の理解: COBOLプログラムは識別部・環境部・データ部・手続き部の4つの構造に分かれている
- 自然言語による理解: COBOLの構文を理解しなくても、AIに解析させることで自然言語で構造を理解できるようになる
■ 5. ステップ3:ソースコードを再生させる
- 連携理解の段階: 個々のファイルの分析とエンリッチメントを終えた後、それらがどのように連携するのかを理解する必要がある
- AIエージェントの活用: AIエージェントによる自動化ワークフローを構築する段階に移行する
- オーケストレーションフレームワーク: Microsoft Global Black Beltのチームは複数の専門エージェントをオーケストレーションするフレームワークを構築した
- 役割分担: 各エージェントは特定のジョブを持ち、連携させることで単一では対応し切れない複雑な処理を実現する
■ 6. 呼び出しチェーンマッピング
- ファイル相互作用の図式化: ファイルの相互作用を図式化するプロセスである
- 複数エージェントの連携: 1つのエージェントがCOBOLファイルを読み取り、別のエージェントがプログラム間の呼び出しを追跡し、また別のエージェントが視覚的に図式化する
- システム全体マップの作成: 依存関係を手動でたどることなく、システム全体のマップを作成できる
■ 7. テスト駆動型モダナイゼーション
- 三段階のテスト生成: 1つのエージェントがビジネスロジックを抽出し、別のエージェントがそのロジックを検証するテストケースを生成し、また別のエージェントがそれらのテストに合格するソースコードを生成する
- セーフティーネット機能: テストは移行作業のセーフティーネットとして機能する
■ 8. 依存関係の最適化
- ライブラリの置き換え: 最新の同等のものに置き換え可能なユーティリティークラスとライブラリを特定する
- 代替可能性の確認: エージェントは使用しているCOBOLライブラリを分析し、代替ライブラリの有無を確認し、置き換え可能な部分を見つける
■ 9. AIによるモダナイゼーションの現実的課題
- ワンクリック解決の否定: メインフレームの問題は1回のクリックで解決できるわけではない
- 人間の関与の必要性: 検証のために人間が常に最新の情報を把握している必要がある
- COBOLの固有性と複雑性: COBOLのソースコードは固有かつ複雑になっている
- AIエージェントの発展途上: AIエージェントの活用はまだ初期段階にある
- 長期的視点: 完全な自動化には少なくとも5年はかかる
■ 10. 従来の変換作業の問題点
- 高額で長期間のプロジェクト: 従来は高額なコンサルタントを雇い、5年以上をかけて変換作業をしていた
- メンテナンス不可能なコード: 最終的にはメンテナンス不可能なソースコードが生み出されるという現実があった
■ 11. AIアプローチの利点と可能性
- 現実的なモダナイゼーション: AIを活用したアプローチはレガシーシステムの維持・刷新を従来よりも現実的なものに変える可能性を秘めている
- 作業可能なコード生成: AIを使うことで、最終的に生成されるソースコードは開発者が実際に作業できるものになり得る
進捗状況の報告方法
何か価値のあることに取り組んでいるなら、遅かれ早かれ人々はそれに興味を持ち、進捗状況の報告をしてくれるよう求めるでしょう。四半期ごとの投資家向け報告、上司への週次報告、関連チームへのメールなど、様々な形で報告できます。ここでは、進捗状況を効果的に伝えるためのヒントをご紹介します。
自分の役割を理解し、報告するたびに、自分がその役割をしっかりと果たしていることを示す証拠を積み重ねていきましょう。人々があなたの報告を望むということは、あなたに何かを託しているということです。例えば、製品や機能の成功裏のデリバリー、投資資金、会社の予算、評判などです。彼らの信頼を大切にし、責任感を真剣に受け止めていることを伝えましょう。
報告頻度に少し変化を加えましょう。人々は定期的な報告を望んでいると考えがちですが、ある程度の不定期さの方が受け入れやすいのです。例えば、毎週火曜日にプロジェクトの報告を送信すると、単なる事務的なやり取りのように思われ、誰も読んでくれません。 2～3週間ごとにアップデートを送信すれば、読者は何か新しいことを伝えたいと期待し、楽しみにしてくれるでしょう。
次のアップデートの内容を把握し、それに向けて作業を進めましょう（アップデートの時期が来てから改めてアップデートするのではなく）。これは、社内向けの見出し主導型開発です。見出しがなければアップデートは存在せず、後から良い見出しを作成することもできません。
常に1文のTL;DRと、プロジェクトの全体目標を2～4文で要約することから始めましょう。読者はあなたよりも賢いですが、非常に忙しく、あなたの仕事について何も覚えていないと想定しましょう。
人は嬉しいサプライズが大好きですが、偶然に訪れることは滅多にありません。無理のない範囲で、意図的に嬉しいサプライズを企画し、アップデートに盛り込みましょう。
人は嬉しいサプライズを嫌います。もちろん、可能であれば避けるべきです。しかし、どうしても避けられない場合は、2つの対策を講じましょう。まず、グループ全体に伝える前に、各メンバーと個別に話し合いましょう。次に、ネガティブなニュースは2～3段階に分けて段階的に伝えましょう。例えば、最初は問題が発生する可能性を穏やかに伝え、メンバーが状況に慣れる時間を与えます。次に、問題を事実として伝えます。（ただし、真の緊急事態や危機の場合は、この方法は避けましょう。）
変更を明確に認識しましょう。前回はa、今回はbと述べ、bがaと矛盾する場合は、その矛盾を説明する必要があります。認識された矛盾はビジネスコストと捉えられますが、認識されていない矛盾は約束違反と捉えられます。
意図せず、あるいは故意に、誰かを侮辱してはいけません。以前、「当社のエンジニアは何も知らないため、製品を出荷できません。より優秀なエンジニアが必要です」といった内容のアップデートを作成し、エンジニア自身を含む全員に送信したことがあります。これは事実ではありましたが、粗雑で不必要な表現でした。このようなことは絶対にやめましょう。
人々は舵取りをしっかりしている人を求めています。あなたの口調もそれを反映させるべきです。パイロット無線の声のような文章にしましょう。（ええ、比喩を混ぜていますね。）
多くの人は（当然ですが）自分のアップデートによって個人的な評価を受けているのではないかと心配し、一文一文を徹底的にサイジングしてしまいます。しかし、そうしてはいけません。すべてを自分のことではなく、仕事のことに集中させ、評価は他の人に任せましょう。（私は、仕事から物理的に離れた第三者の視点で自分自身を想像し、自分のキャラクターがアップデートを書いていると想像します。）
読者が答えを知りたいと思っている上位3つの質問を把握し、できるだけ明確に答えましょう。
不安や失敗について専用のセクションを設けましょう。正直に、しっかりとした計画を立て、パニックに陥らないようにしましょう。人々は誠実さと弱さに惹かれますが、無力感や大げさな表現には反発します。
アップデートの目的は、読者があなたに尋ねることなく、いつでもプロジェクトの進捗状況を把握できるようにすることです。
「イーロンは四半期決算説明会でウォール街のアナリストに怒鳴っているのに、なぜ私にはできないんだ？」もしあなたが、業界全体よりも大きな時価総額を持つ会社を築き上げたのなら、私のアドバイスを無視してもらって構いません。
これらのヒントは、あなたが無能なら効果がありません。
■ 超大型の言語モデルに迫るトップクラスの性能
tsuzumi 2は多くのベンチマークで高い性能を達成しています。図は代表的なベンチマークの１つであるMT-benchにおけるGPT-5との性能比較です。MT-benchは多様なタスクから構成されたベンチマークであり、言語モデルの特性を多様な観点で評価することができるものです。多くのタスクでGPT-5と同等程度の高い数値を示しており、様々なユーザからの要求を処理可能なモデルに仕上がっています。
■ 1GPU動作可能な軽量モデル
tsuzumi 2は1GPU動作可能な軽量モデルです。最新の言語モデル向けのGPUはハイスペックで高価なものが多い中、少し以前の40Gバイト以下のメモリを保有したGPUでの動作を想定して開発されています。 大規模言語モデルの導入が各社で進む中、極めて高頻度に利用されるお客様が増えてくると見込んでいます。するとAPI利用回数に応じた利用料を支払う場合、コストが高くなり、お客様ご自身が安く言語モデルサーバーを運用した方が良いという判断が増えてくることでしょう。また、AIエージェントによるシステム連携などを通して、より一層機微な情報を言語モデルに与えるケースが増加し、オンプレ環境への導入も今後増えてくるでしょう。tsuzumi 2はこのような要求にこたえる運用コストと性能のバランスに優れたモデルです。
■ 法人のお客様に求められるタスク処理能力の強化・知識の増強
tsuzumi 2では、ビジネスシーンで頻繁に利用される能力を重点的に強化しました。特にユースケースの80％を占める、ドキュメントに対するQAタスク（RAG検索要約）、ドキュメントからの情報抽出・要約タスクを集中的に強化しています。 これらのタスクについては、ビジネスでの利用を想定した独自の評価セットを構築し、実践的な評価を行っています。tsuzumiの前バージョンとの比較では、これらのタスクについて大きく性能を向上させることに成功しました。 また、NTTのお客様が多い金融・自治体・医療分野については特に多くの知識を学ばせました。これらの分野では多くのユースケースで優れた性能を発揮します。
法人のお客様の利用形態の特徴の１つに出力形式の指定があります。例えば、要約においても自由に要約文を生成させるのではなく、報告様式があり、その型に準拠させたい。技術系の用途であれば文書から特定の情報を抽出し、json形式で出力して欲しいといった要求です。tsuzumi 2ではこうした要望にお応えするために指示遂行力を強化することで、使い勝手の良い言語モデルを目指しました。
■ NTTがゼロから開発した純国産モデル
昨今、言語モデル学習における新聞データの無断利用に関する訴訟が起きるなど、モデル開発過程における信頼性が問われています。開発会社だけではなく、問題を指摘されたモデルを使い続けることは利用者側も責任を問われかねません。そこで、NTTではフルスクラッチ開発を行っています。これはオープン利用可能な他社のモデルを種とすることなく、完全に一からNTTがモデルを構築することを意味しています。学習データの完全コントロールにより、データの権利、品質、バイアスの管理が可能となり、モデルの信頼性を高める上で極めて重要です。前バージョン同様、tsuzumi 2も日本の国内法に準じて開発された純国産モデルとなっています。
■ 1. 開発生産性の本質的な問題
- 生産性の定義: 生産性とはアウトプットとインプットの比率であり、単純な数値として表現される
- 改善の逆説: 開発生産性を改善しようとする試みが、しばしば状況を悪化させる結果を招いている
- AIによる問題の深刻化: AI技術の導入により、生産性測定と制御の問題が更に悪化している
- 終わりなきプレッシャー: やることは常に山積みであり、どれだけ生産性を上げてもプレッシャーが軽減されることはない
■ 2. マッキンゼーレポートの問題点
- 世間知らずな提案: 約2年前にマッキンゼーが発表した開発生産性レポートは、経験ある開発者から見て明らかに不適切な内容だった
- すべてが逆効果: 生産性向上のための提案がすべて状況を悪化させるものであった
- 批評記事の執筆: Gergely Oroszと共同で批評を執筆し、大きな反響を呼んだ
■ 3. グッドハートの法則の基本概念
- 法則の要約: 指標が目標になると、それは良い指標ではなくなる
- タイピング速度の例: タイピング速度を指標とすると、開発者は意味のない高速タイピングに専念するようになる
- 本来の観察: 統計的規則性が観察されても、それを制御手段として利用すると規則性は崩壊する
- イングランド銀行の事例: 短期金利と借入の相関関係を制御に利用しようとしたが、他のプレイヤーの適応により効果が消失した
■ 4. 測定の目的と誤用の区別
- 測定の価値: ソフトウェア開発プロセスの測定は非常に価値があり、自分のやっていることを数値化・分析・解釈できる
- 制御との違い: 測定による理解と、レバーでシステムを制御できるという感覚は全く別物である
- 理解のための測定: 指標は開発プロセスを理解するためのものであり、システムを機械的に制御する手段ではない
- ソフトウェアの特殊性: 純粋な知的活動の中で、ソフトウェア開発ほど規模を拡大できるものは他にない
■ 5. プルリクエスト指標の事例分析
- 正のフィードバックループ: 優れた開発者は小さなPRを多く出し、それが読みやすさ、協力の増加、無駄の削減につながる自己強化型の仕組みを形成する
- 圧力による崩壊: PRランキング表を作成して圧力をかけると、開発者は筋の通ったPRを細切れにして数を水増しするようになる
- 協力の減少: PRを細分化することで読みにくくなり、協力が減少し、無駄が増加し、最終的にPR数も減少する
- 悪循環の発生: 誰も下位にいたくないため全員が同じ行動を取り、ソフトウェア開発プロセス全体が悪化する
■ 6. コード行数指標の歴史的失敗
- 生産性指標としての採用: コード行数がプログラマーの生産性を測る正しい指標だと考えられた時代があった
- プログラマーの対応: プログラマーはコードを生成するプログラムを書くことができるため、機械的に大量のコードを生産できる
- 逆効果の結果: 求めていた成果とは正反対の結果を生み出し、仕組みを悪化させた
■ 7. グッドハートの法則を超える悲観的現実
- 規則性の崩壊を超える破壊: 統計的規則性に圧力をかけると、単に規則性が崩壊するだけでなく、規則性を生み出した仕組み自体を壊してしまう
- 意図と逆の結果: レバーを引くことで期待や意図とは真逆の結果が生じる
- より深刻な問題: 単にレバーが機能しなくなるのではなく、システム全体が望まない方向に向かう
■ 8. 複数指標によるバランスの幻想
- バランス指標の提案: PR数だけでなく欠陥数やレビュー時間など複数の指標を組み合わせるべきだという主張がある
- 問題の非解決: 導入するすべての指標が仕組みをゆがめるため、複数の指標を導入しても問題は解決しない
- 理解困難化の加速: 指標が多ければ多いほど、システムは理解しづらく制御しづらいものになる
- 完璧な指標セットの不在: うまく開発するための指標のセットは存在せず、指標による自動的な改善という発想自体が誤りである
■ 9. 人間性の軽視と創造性の抑圧
- 機械的制御の危険性: 何も考えずに指標を改善するだけですべてうまくいくという発想は、開発者の人間性を無視している
- 思考の後押しの必要性: プログラマーは考えることを促され、創造性に任せられることを望んでいる
- 数値化不可能な要素: 思考、洞察、創造性のプロセスは単純な数字に表すことができない
- 創造性の喪失: 数値化しようとするあらゆる試みが、ソフトウェア開発に注ぎ込まれるべき思考と創造性を奪う
■ 10. システムによるゆがんだ目標の採用
- 目標の放棄を超える問題: システムは制御の圧力を軽減するために本来の目標を放棄するだけでなく、ゆがんだ目標を新たに採用する
- 本番障害指標の例: 本番環境での障害をなくせという圧力をかけると、障害報告がなくなる(報告しないことで数字をゼロにする)
- 創造的な回避行動: 頭が良く創造的な開発者は、数字をゼロにする何らかの方法を必ず見つけ出す
- 全方位的な悪影響: 仕組みをだますプログラマー、会社、顧客、社会全体にとって悪い結果をもたらす
■ 11. 指標による制御の本質的限界
- 人間の判断の排除: 人の働きを単純な数字で表し、人間の判断を不要にして数字だけで制御しようとする試み自体が問題である
- 望まない目標の採用: システムが新たに採用する目標は、組織が真に達成したい目標とは異なるものになる
- 指標の種類や数は無関係: どのような指標を使用し、いくつ組み合わせ、どれだけバランスを取っても問題の本質は変わらない
- 脱出方法の必要性: この悪循環から抜け出す方法を見つける必要がある
■ 1. ソフトウェアが価値を生み出す4段階のプロセス
- 労力(Effort): プログラマーがプログラミングに費やす時間、金銭、機会費用で測定される最初の段階である
- アウトプット(Output): 労力を費やした結果として形になるもの(例:ボタンの追加)であり、比較的測定が容易である
- 成果(Outcome): 顧客が新しい行動を取り、ユーザーの行動変化として現れる段階である
- 影響(Impact): 会社の収益増加、顧客満足度向上、コスト削減など、企業に価値が還元される最終段階である
■ 2. 測定の容易さと仕組みのゆがみの関係
- 労力側の測定リスク: 価値の道すじの初期(労力側)に近いほど測定は容易だが、指標が仕組みをゆがめる可能性が高くなる
- 過労の危険性: 若い頃に週100時間以上働いた経験から、時間の最適化は良くない結果を招くと警告している
- アウトプットの測定: ボタンの数など比較的測定しやすいが、顧客が気にするかどうかは成果が出るまで分からない
- 貢献度の切り分け困難: 複数のチームの貢献が組み合わさって成果が出る場合、個別の功績を切り分けることは困難である
■ 3. 経営者の関心と測定の優先順位
- 顧客行動への注目: 経営者として測定したいのはプログラマーの労働時間ではなく、顧客がどう行動を変えたかである
- 影響の測定可能性: 四半期ごとの財務状況など影響レベルでの測定は可能だが、誰の功績かを特定することは不可能である
- 帰属の困難さ: プログラミングとマーケティングの成果が混在する場合、収益性の変化を特定の要因に帰属させることはできない
- ゆがみの軽減: プロセスの後期(影響側)で測定するほど、指標が仕組みをゆがめる傾向は弱くなる
■ 4. AIによる労力とアウトプットの変化
- 拡張プログラミングの体験: Gene Kim氏の影響でAIベースのプログラミングを始め、機能完成に必要な労力が劇的に減少した
- 労力減少とアウトプット増加: AIのおかげで作業時間が大幅に短縮され、プログラマー1人当たりのアウトプットが増加する
- AIの不完全性: AIというコーディング仲間は時にとんでもなくバカなこともするため、労力が増えることもある
- 管理方法の不変性: 10時間の作業が1時間でできるようになっても、プロセスをどう管理すべきかについては何も変わらない
■ 5. AI時代における若手育成の選択
- 若手不要論への反論: ジーニー(AI)を使えばシニアプログラマーの方が生産性が高いため若手が不要になるという懸念がある
- チューターとしてのAI活用: RustやHaskellなど理解できない言語でも、AIがいつでも説明してくれるため学習効率が向上する
- 学習重視の評価: 若手を労力やアウトプットではなく、毎週学んだことで評価する方式を提案している
- 長期的価値の創出: 若手は大量のコードを書くためにいるのではなく、早く学ぶことが雇用者にとっての長期的価値を生み出す
■ 6. 指標を見る人と行動の重要性
- 見落とされる質問: 誰がこの数字を見るのか、見た結果どんな行動を取るのかという質問がめったに議論されない
- CFOの解雇意図: 最高財務責任者がプログラマーの2割を解雇したいと思っているなら、どんな指標も恐ろしいゆがみを生む
- 現場マネジャーの育成意図: 部下が早く学ぶのを助けたいと思っている現場マネジャーでは、全く異なる見方になる
- 単位の重要性: 開発者1人当たりのPRは投資家にとって意味がなく、利益という単位で測定すべきである
■ 7. 投資家視点での生産性測定
- 金銭的価値の測定: 投資家として気になるのは利益であり、アウトプットもインプットも金額で測定してほしい
- 雇用判断の根拠: 追加のプログラマーを雇って生産性が1.4倍や3倍になると分かれば、雇用は理にかなっている
- PR数の無意味性: 1日当たりのPR数が3件から6件になると言われても、プログラマーを追加で雇うべきか判断できない
- 意思決定への貢献: 利益の数字を使えば、投資家として良い決断を下すことができる
■ 8. リーダーシップの実践:後段階での確認
- 確認タイミングの遅延: 価値の道すじの初期段階ではなく、後期段階で確認することが重要である
- タイムカード導入の危険性: 労働時間の管理やバグの自己申告など、初期段階での確認は仕組みをゆがめる
- 開発者1人当たりの利益: 達成方法は問わず、競合他社との比較で開発者1人当たりの利益を提示する
- 成果の観察: 会社への直接的な影響が確認できないなら、成果を観察することがソフトウェア開発の有効性を評価する良い方法である
■ 9. リーダーシップの実践:意識向上の促進
- グラフ化による意識向上: システムの速度をグラフ化して週に1度提示するだけで、プログラマーは改善に夢中になる
- 圧力の回避: 何も言わず、ただグラフを見せるだけで、プログラマーは自発的に調査し改善しようとする
- 圧力とゆがみの関係: リーダーとして圧力をかけないことは難しいが、圧力をかけると仕組みにゆがみが生じる
■ 10. リーダーシップの実践:目的の浸透
- 引く姿勢の採用: 本番障害の削減を命令するのではなく、「できるよ、私たちなら可能だ」と励まし、必要なものを尋ねる
- 非難の回避: 障害が起きた際に「君はダメなプログラマーだ」と圧力をかけるのではなく、引く姿勢で接する
- リーダーの責任: 現状に対する責任を自ら持ち、「私は障害が多すぎる環境を作ってしまった」と認める
- やり方の変更宣言: 今後はやり方を変えていきたいと伝え、チームを前向きに導く
■ 11. グッドハートの法則を回避する方法
- 圧力回避による測定: 指標に圧力をかけなければ、結果を変えずに測定できる
- 最高の自分の追求: 人々が最高のレベルで創造し、共有する目標に全力を注ぐことを後押しする
- 揺るぎない目標: より大きな視点でソフトウェア開発を見ることで、目標が揺るがなくなる
- 魔法のようなプロセス: ソフトウェア開発は誰もが参加でき、成長を続け、目標達成が可能な魔法のようなプロセスである
■ 1. ITエンジニアを辞める人の増加
- 現象の観察: ITエンジニアを辞めましたという投稿を目にする機会が増えている
- 情報源: XでのSNS報告、顧客の採用担当、人材系事業の関係者から話を聞くようになった
- 共通点: 2019〜2021年頃にプログラミングスクールを経てITエンジニアになった人たち
- 現実とのギャップ: いざ入社してみると現実は想像以上に厳しいものだった
■ 2. 不況による未経験・微経験採用の変化
- 求人の減少: 受託開発会社、事業会社、スタートアップを中心とした不況感の高まりにより、未経験・微経験層の求人が大幅に減少している
- 企業の優先順位: 企業は教育コストをかけて育てる層よりも即戦力として成果を出せる層を優先するようになった
- 転職活動の行き詰まり: スクール卒のエンジニア志望者が転職活動で行き詰まり、キャリアチェンジを余儀なくされるケースが増えている
■ 3. SES市場の問題
- 未経験向け求人の存在: 依然として未経験・微経験向けに求人があるのがSESや派遣会社
- 非ITエンジニア職への配置: SES企業に入社しても実際に任されたのは非ITエンジニア職──テスト要員やヘルプデスクなど、キャリアアップの道が見えない業務
- 具体例: ITエンジニアになるに当たって貴方にはコミュニケーション力が足らない、そのためにはまずコールセンターに行きなさいと言われて3年勤めたが何も起きないので転職したいという話もある
- 諦める選択: こうした現実を前にITエンジニアを諦めるという選択肢は無理もない
■ 4. 実質無職のSES案件採用
- 案件採用の広がり: SESの一部では案件採用が広がっている
- 一般的なSESとの違い: 最終面接後に内定があり入社後に営業が始まる一般的なSESとは異なる
- 無職状態: 最終面接合格後に未入社の状態で営業が開始され、案件が決まるまでいわば無職の状態が続く
- 無給の営業活動: 営業活動を実施しているのに無給という点も問題
- 人材紹介会社の関与: 今では人材紹介会社経由でも紹介されることが当たり前になっている
- 情報商材の問題: 2000万円を元手にSES事業を立ち上げ、3年後に10倍で売却しましょうという情報商材が広がっている
- 商材化された人材: 商材がヒトであることを忘れた経営者の犠牲になっている
■ 5. 生成AIの台頭による影響
- エンジニア像の変化: 生成AIの急速な進化によって企業が求めるエンジニア像が大きく変わった
- 採用スタンスの転換: 従来は採用して育てるスタンスを取っていた企業も、今ではAIを活用して即戦力として成果を出せる人材を重視するようになった
- 仕事の自動化: 生成AIツールの普及により初歩的なコーディングやテスト、ドキュメント作成などの領域が自動化され、ジュニア層が担っていた仕事が減少した
- 採用方針のシフト: 企業は育成を前提とした採用からプロジェクトにすぐ貢献できる層の確保へとシフトしている
- 教育リソースの不足: AIを前提とした開発環境や業務プロセスが整備される中で、教育リソースを未経験者に割く余裕がなくなってきている
■ 6. 技術構造の変化
- 恒常的なシフト: これは単なる景気の波ではなく技術構造そのものの変化による恒常的なシフト
- 求人の大幅減少: 2024年以降、未経験・微経験者向けの求人は大幅に減少した
- ポテンシャル採用の消失: かつてポテンシャル採用と呼ばれた採用枠は姿を消した
- 新たな分水嶺: 今では生成AIを使いこなせるかどうかが採用の新たな分水嶺になりつつある
■ 7. プログラミングスクールブームの罪
- 2019〜2020年のブーム: プログラミングスクールブームは未経験者を一気にIT業界へ誘導した
- 過激な訴求: SNS広告やLPでは誰でも3ヶ月でエンジニアに、年収アップ、フリーランスで自由にといった過激な訴求が目立った
- 期待値調整の失敗: 良心的なスクールも存在したが、全体としては期待値調整の失敗があった
- エコーチェンバーの発生: SNS中心の情報収集によってエコーチェンバーが発生し、デスクワークで楽、リモートで人と関わらなくて済むといった誤情報が拡散した
- 現実とのギャップ: 思っていたような年収が得られず、業務内容にも馴染めず、結果的にITエンジニアを辞めるという投稿が見られる
■ 8. 業界離脱率の高さ
- スクール出身者の証言: 当時話題だったプログラミングスクール出身者で現役エンジニアの方によると9割は業界から居なくなったように思うとのこと
- 専門職教育の変化: 考え方によってはアメリカのように大学で専門職教育を受けた人が当該専門職に就くという状況になったとも考えられる
- エンジニアバブルの終焉: 今までの未経験・微経験人材が採用されていた専門職はかなり異色でありエンジニアバブルの産物だった
■ 9. 転職先の傾向
- 別職種へのエントリ: 採用の現場ではエンジニアを諦めて別職種にエントリするケースが見られる
- 情シスとカスタマーサクセス: 情シスやカスタマーサクセスへの応募が見られる傾向にある
- カスタマーサクセスの魅力: 事業会社ではエンジニア職よりも営業職のほうが重要視されている傾向にあるため、カスタマーサクセスへの転身は本人が対人コミュニケーションの苦痛がなければ良い
- 情シスの需要: 広く様々な企業で募集されている職種で、ちょっとしたものでもプログラムやスクリプトを書くことができれば重宝される
- 介護職への転身: 未経験・微経験を積極採用しているということで介護職へ転身される方もいる
■ 10. 日本企業が求める人材
- アンケート調査: ITメディアが具体的にどのようなスキルを持ったIT人材が不足しているのかというアンケートを実施
- インフラエンジニア: 55%がインフラエンジニアと回答
- DX推進リーダー: 次がDX推進リーダーで52.5%
- データサイエンティスト・セキュリティエンジニア: データサイエンティスト・データアナリストとセキュリティエンジニアが同率で45%
- ソフトウェアエンジニア: 業務アプリケーションを実装するソフトウェアエンジニアは32.5%と最も低い
- 需要減少の背景: SaaSの移行が進むことで自社内で開発する必要がなくなってきた可能性や、ノーコード・ローコード開発への移行による影響
■ 11. キャリア戦略のポイント
- 経験の価値: ITエンジニアから異職種や異業種への転向とはいえ、IT業界で身につけた知識や経験は決して無駄にはならない
- 活用の場: 情シスやカスタマーサクセス、営業支援、データ管理など、DXの文脈ではエンジニア経験者が重宝される場面が多くある
- 生存の重要性: キャリアの基本は生存にある
- 再挑戦の可能性: 一度離れたとしても学び直しやスキルの再利用によって再挑戦の道は開ける
- 現実との向き合い: 大切なのは腐らず、現実と向き合い、次のステージで生きること
■ 12. プログラマ需要への固執を避ける
- 柔軟な戦略: 実情を踏まえるとプログラマ需要を探すことに固執しないということもキャリア戦略としてはあり
平素よりアスクルをご利用いただき誠にありがとうございます。
現在、アスクルWebサイトにてランサムウェア感染によるシステム障害が発生しており、受注、出荷業務を停止しております。
個人情報や顧客データなどの外部への流出を含めた影響範囲については現在調査を進めており、わかり次第お知らせいたします。
お客様には多大なるご迷惑、ご心配をおかけし、誠に申し訳ございません。
【影響内容】
■ご注文受付の停止
Webサイトでは、お買い物カゴ画面等に遷移しようとした場合にエラー画面に遷移いたします。
＜エラーになる画面＞
・お買い物カゴ
・レジ
・ご注文内容印刷
また、FAXでのご注文についても送信エラーとなり、受付することができません。
■出荷の停止
既にいただいているご注文についても、今後の出荷においてはキャンセルさせていただきます。
ただし、ご注文いただいている直送商品については、出荷を予定しております。
■新規ご利用登録の停止
「会員登録」ボタンを押下した場合、エラー画面に遷移いたします。
■その他サービスの停止
返品、領収書の郵送、カタログ送付、各種回収サービスなどのお申込みなども停止しております。
■お問い合わせ窓口
お客様サービスデスクのお電話は現在つながりにくい状況となっております。
またWebサイトのお問い合わせフォームについては停止させていただいております。
お客様にはご迷惑をおかけしておりますことを重ねてお詫び申し上げます。
ただ今、復旧に向けて対応しておりますので、何卒ご理解賜りますようお願い申し上げます。
以上
■ 1. BDHの登場と背景
- 開発者: AIスタートアップPathwayが人間の脳神経回路に着想を得た新アーキテクチャBaby Dragon Hatchling(BDH)を発表
- 意義: 現在の主流であるTransformerモデルの限界を打破する可能性を秘めている
- 方向性: より解釈可能で自律的なAIへの道を拓くものとして業界に静かな衝撃が走っている
■ 2. Transformerの限界
- スケーリング則: 近年のAIの進化はOpenAIのGPTシリーズに代表されるTransformerアーキテクチャによって牽引され、膨大なデータと計算資源を投入するスケーリング則により性能は飛躍的に向上した
- ブラックボックス問題: モデルがなぜ特定の結論に至ったのか、その思考プロセスを人間が理解することは極めて困難
- 汎化能力の欠如: 訓練データに含まれないあるいはコンテキストが長大化する未知の状況においてAIの推論能力はしばしば脆さを見せる
- 自律性の障壁: これはAIが真に自律的に長期間活動する上での大きな障壁となっている
■ 3. Pathwayのドリームチーム
- 本拠地: パロアルトに本拠を置くスタートアップPathway
- Adrian Kosowski: 共同創業者兼CSO(最高科学責任者)で20歳で博士号を取得した俊英
- Jan Chorowski: CTOでAIのゴッドファーザーと称され2024年にノーベル賞を受賞したGeoffrey Hinton氏とGoogle Brainで研究を共にし、音声認識に初めてアテンション機構を応用した先駆者
- Łukasz Kaiser: アドバイザーでTransformerを生み出した論文Attention Is All You Needの共著者でありOpenAIの推論モデル開発にも関わった
- Zuzanna Stamirowska: CEOで複雑系科学者としての経歴を持つ
- ルーツ: 彼らの多くがポーランドのヴロツワフ大学にルーツを持つ
■ 4. BDHの基本設計思想
- パラダイムシフト: Transformerへの単なる改良ではなく脳の動作原理から直接インスピレーションを得た根本的なパラダイムシフト
- Transformerとの違い: 従来のTransformerがベクトルと行列演算を基本とする抽象的な数学モデルであるのに対し、BDHは人工ニューロンという粒子がシナプスという接続を介して相互作用するグラフベースのモデル
- 脳の構造: 約800億のニューロンと100兆を超えるシナプスで構成される人間の脳の構造を色濃く反映している
■ 5. ヘブ学習の実装
- 最も革新的な特徴: BDHの最も革新的な特徴は神経科学の基本原理であるヘブ学習を実装した点
- ヘブ学習の原理: 共に発火するニューロンはその間の結合が強まるという原則
- 従来のAIとの違い: 従来のAIでは情報は活性化ベクトルのような固定的な場所に保存されていたが、BDHではワーキングメモリはシナプスの結合強度そのものに存在する
- 動的な記憶形成: 特定の概念について推論すると関連するニューロン間のシナプス結合がリアルタイムで強化される
- 実験結果: BDHが英ポンドとフランス語のlivre sterlingという異なる言語の同じ概念を処理する際、一貫して同じシナプスが活性化することが実験で確認されている
■ 6. 創発するモジュール構造
- 自己組織化: BDHが訓練中に自発的に生物の神経網に見られるような効率的なネットワーク構造を形成する
- モジュールの形成: 特定の機能に特化したニューロンのコミュニティ(モジュール)が生まれそれらがブリッジニューロンによって相互接続される
- スケールフリー特性: モジュール性や一部のニューロンが多数の接続を持つスケールフリーな特性は誰かが設計したものではない
- 最適解の発見: 情報処理の最適解をBDHが自ら発見した結果
- 脳との類似: この自己組織化能力は脳の新皮質が機能分化するプロセスにも通じる
■ 7. GPT-2との性能比較
- 比較実験: 研究チームは1000万から10億パラメータの規模でBDHとGPT-2アーキテクチャのTransformerを直接比較した
- 性能: 言語モデリングと翻訳タスクにおいてBDHは同等以上の性能を示した
- データ効率: 特に同じ量のデータからより多くを学習するデータ効率の面で優位性を見せた
- 意義: AI開発がより多くのデータとGPUをという力業から脱却する可能性を示唆する
■ 8. BDH-GPUの実用性
- 実装の存在: この脳に着想を得たグラフモデルは理論上の存在に留まらない
- BDH-GPU: Pathwayは現代のGPUハードウェアで効率的に動作するテンソルベースの実装BDH-GPUを開発した
- 技術要素: 高次元のニューロン空間、スパースな正値活性化、ReLU-lowrankと呼ばれるフィードフォワードブロックといった要素を組み合わせている
- バランス: 生物学的な特徴を維持しつつ実用的な計算を可能にしている
- 研究加速: この実用性により世界中の研究者が既存のインフラを使って脳型AIの研究を加速させることが可能になる
■ 9. 解釈可能性の向上
- スパース活性化: 常時アクティブなニューロンは全体の約5%と非常に少なく、どのニューロンがどの情報処理に関わっているかを追跡しやすくなる
- 単義性シナプス: 特定のシナプスが特定の意味的概念(通貨、国名など)に一貫して反応する現象が確認されている
- ブラックボックス問題の解決: AIの判断根拠をシナプスレベルで解明できる可能性を示しておりブラックボックス問題に対する強力な解決策となりうる
■ 10. 公理的AIという概念
- 新概念の提唱: Pathwayの研究チームはBDHを通じて公理的AI(Axiomatic AI)という概念を提唱している
- ミクロとマクロの統合: 個々のニューロンの振る舞い(ミクロ)とそこから生まれる推論などのシステム全体の挙動(マクロ)を一貫した理論的枠組みで理解しようとする試み
- 安全性の保証: AIが未知の状況に遭遇した際の振る舞いを単に観察するのではなく数学的にその安全性の限界を保証できる未来が開ける
- リスク制御: ニック・ボストロムが提唱したペーパークリップ問題(AIが単純な目的を暴走させるリスク)のような自律AIがもたらす長期的リスクを制御する上で不可欠な要素
■ 11. 意識の創発という哲学的問い
- 新たな問い: BDHが脳の構造と動作原理を忠実に模倣するほど意識そのものが副作用として創発する可能性という問いが生まれる
- 制御可能性: 生物の脳において意識を生み出したのと同じ自己組織化の原理をAIが獲得したときそれは我々が予測し制御できる範囲に留まるのか
- 理論的基盤: Pathwayチームは創発現象をただ待つのではなくそれを理解するための数学的なツールキットを同時に構築している
- 対応能力: ネットワークのモジュール性がなぜ生まれるのかを説明できる理論的基盤を持つことは未知の創発現象に直面した際の我々の対応能力を大きく左右する
- 両面性: 解釈可能なAIへの道が人工意識への道と同じである可能性、BDHは我々にその両面を突きつけている
■ 12. AIの進化の新たな始まり
- Transformerの到達点: AIの進化はTransformerによって一つの頂点を極めた
- BDHの意義: BDHはその先のより人間的でより理解可能な知性への扉を開いた
- 知的冒険: これは単なる技術的な一歩ではなく我々が知性とどう向き合うかを問い直す知的冒険の新たな始まり
■ 1. 価値優先の原則
- 基本方針: 間違いなく価値が先であり、チームは後である
- 危険性: 外への価値創出から目を背け、身近で変化を起こしやすい目先のチームだけで自己完結することは簡単だが危険
- エコーチェンバーの罠: 内集団贔屓のバイアスを高めると簡単に停滞し、澱み、腐敗し、カルト化する
- 価値創出サイクル: このような状態では価値創出のサイクルが途絶えてしまう
■ 2. 価値の定義と企業の目的
- 価値の定義: 価値とは誰かにとっての幸福である
- 企業の目的: 企業の目的は利潤追求ではなく価値創出である
- 合理性の位置づけ: 価値創出を継続するために合理性が必要であり、資本主義経済では経済合理性が求められる
- 利潤の重要性: お金がないと活動の継続や価値創出の拡大がしづらいため利潤は重要だが、価値が先にあり利潤が後にある
- 時価総額の限界: 利益の多寡や時価総額が企業の優劣を絶対的に決めるわけではない
■ 3. 価値のコンテキスト依存性
- 主観性: 価値はコンテキストによって変化する曖昧なもの
- 具体例: テスラよりも任天堂やシマノの方が価値が高いと感じる人もいる
- 対価の関係: 価値の対価としてお金が発生することもあるが、価値そのものはお金ではない
- 幸福との関係: お金を払うときは対象に何らかの価値を感じ、そこから何らかのリターン、幸福を得る
■ 4. 企業理念とミッション・ビジョン
- 価値の言語化: 企業は誰をどのように幸せにしたいのかを考え定める必要がある
- ミッション・ビジョン: それを言語化したものが企業理念、ミッション・ビジョンと呼ばれるもの
- 三方良しの理想: 世の中、顧客、社員全員を幸せにすることが理想のスキーム
- 重みづけ: それぞれをどのくらいの重みづけで、どういう形で幸せにしたいかが企業理念となる
- 従業員の幸福: 自分達が幸せになることも当然考えて良い
■ 5. 報酬と評価の複雑性
- 報酬の位置づけ: 従業員に対する報酬は価値創出に対する貢献度、より正確には貢献に対する期待値に対する投資として支払われる
- 評価の困難さ: それぞれの従業員が創出している価値がどれくらいで、どれくらい金銭換算でき、いくら支払うかを評価するのはとても難しい
- 恣意性: 企業の価値観が問われるところであり、言ってしまえば恣意的である
■ 6. プロフィットセンター・コストセンターの問題
- 分類の恣意性: どの物差しを使うか、どちらに分類するかの解釈は極めて恣意的
- エンジニアの立場変化: ソフトウェアエンジニア部門は以前は間接部門でコストセンターと見なされるケースもあったが、現在は直接部門でプロフィットセンターと見なされる局面が増えた
- 構造的幻想: エンジニアが直接価値を生み出しているという実感は構造からの幻想である
- コンテキスト依存: それは永続的で普遍的なものでは決してなくコンテキストに依存する
■ 7. 花形の相対性と企業の個性
- 花形の多様性: 花形は企業によって変わり、エンジニア、トレーダー、営業、企画、デザイナー、法務、財務など様々
- ビジネスモデルとの関係: 企業のビジネスモデルと価値観によって変わる
- 会社の個性: 誰がより価値があるかと見なされるかには会社の個性が反映され、構造的な格差がある
- 二項対立の回避: プロフィットセンター・コストセンター、直接部門・間接部門といったコンテキスト依存の恣意的な二項対立分類は避けた方が良い
■ 8. 全員での価値創出
- 部署との疎結合: 事業がどのように売上を立てコストを支払っているかを意識することは大切だが、それは部署には密結合しない
- トータルでの価値創出: 社員全員でトータルでどのような価値を創出しているかに向き合っていく必要がある
- 負い目の排除: 間接部門だから価値創出に関われていないといった変な負い目を感じて仕事をする人がいて欲しくない
- モチベーション向上: 全員が価値に向き合い、自分の仕事が価値に繋がっていると感じられながらモチベーション高く仕事に当たれる方がより価値創出できる
■ 9. 抽象的な価値と具体的な成果
- 相補関係: 価値は曖昧で抽象的であり、それと相補的な関係にあるのが具体的な成果
- 成果の評価: 実際に表出してきた成果物、売上や利益、顧客数などの具体的なアウトカムを元に価値創出に繋がっていたかを評価する
- 不正な利益の排除: 自分たちが是とする価値創出とコンフリクトする形で上げた成果は評価されない
- 価値観のブラッシュアップ: 思いもよらぬ成果から逆に自分たちの価値観をブラッシュアップする材料が見つかることもある
- 継続的改善: 抽象と具体を行き来しながら価値創出とはどういったものなのかを定期的に見直し磨き続ける
■ 10. カルチャーとカルトの分水嶺
- 語源の共通性: 文化（culture）、耕す（cultivate）、カルト（cult）は語源を同じくする
- 紙一重の関係: 文化とカルトは紙一重である
- 発酵と腐敗の類似: 組織風土をどう耕すかによって有益なカルチャーになるか害をもたらすカルトになるかが決まり、これは発酵と腐敗の関係に似ている
- 分かつもの: カルチャーとカルトを分かつのは価値である
- 外部への開放: 自分たちが価値だと考えているものを自己満足で閉じこめず、その確からしさを外部に問いかけながら変容させていくこと、反証の扉を外部に開けておくこと
■ 11. 内集団贔屓の危険性
- 定義: 内集団贔屓とは自分が所属する集団を過大評価し、外部の集団を過小評価する傾向
- 具体例: 自分は頑張っているのに周りは認めてくれない、チームは頑張っているのに他部署が邪魔をするなど
- カルト化のプロセス: それでも自分たちは正しい、自分たちは特別という思い込みが強くなり、外部の意見や批判を受け入れられなくなったら組織はカルト化する
- 弱さの表れ: 外からのフィードバックを拒むのは傷つくのを恐れる弱さに他ならない
- 意識的な抵抗: 内集団贔屓が人間が普遍的に抱えがちなバイアスである以上、意識的に抗う必要がある
■ 12. 外部への働きかけの重要性
- 現実の受容: 外に目を向け現実を受け入れること
- 価値の承認: 自分たちが価値だと考えていることを認めてもらうように外部に働き掛けること
- フィードバックの活用: そのフィードバックからその価値基準が妥当なのかを検証していくこと
- 持続性の確保: 閉鎖的なコミュニティの中での幸福度は短期的には高められるかもしれないが、規模的には小さく持続性も乏しい
- 三方良しの意義: 自分たちと顧客の間だけで内集団贔屓を高める共依存関係を構築し、社会に損害を与えていたら本末転倒
■ 13. 開発組織における局所最適の罠
- 価値への接続: 自分たちの営みがどのように価値に繋がっているかを意識できるかが肝
- 局所最適の危険: 開発組織内だけ綺麗に整備しても、それがチーム外や世の中に価値を届けられてないのであれば価値は乏しい
- やりこみ要素: CI/CD自動化、開発プロセス改善、キャリアラダー整備など、やれること、やりたいことは無限にある
- 確実性の高いタスク: IaC、CI/CD自動化、開発プロセス整備などはデリバリーの安定性とスピードを高める効果の確実性が高いタスク
- カーゴ・カルトの回避: 価値に向き合わず、やった方が良いかもしれないことをやるべきこととして教条主義的に適用し続けるのはカーゴ・カルト
■ 14. 木こりのジレンマと全体最適
- ノコギリの研磨: 研がれていないノコギリで木を切り続けるのは非効率だが、過剰に研いだ刃物は刃こぼれしやすくなる
- 状況判断: なまくらだと思っているものが価値を出しているのであれば今のところはそれで十分かもしれない
- 周囲への支援: 同僚や隣の部署が石斧で戦っていてそれがボトルネックになっているなら、その手助けをした方が価値があるかもしれない
- 全体最適の視点: 全体最適を考え、どちらの方が最終的な価値に繋がるかを考えた上で判断したい
- チーム単位の限界: 自分たちのチームだけを良くしようとしたって仕方ない
■ 15. 個人のキャリアとの調和
- コンフリクトの存在: 価値優先の考え方は短期的には個人のキャリア形成とコンフリクトすることが少なくない
- 打算的な利点: 会社全体の思惑や価値観を理解しておく方が、より価値創出に繋がるアクションを起こしやすくなり、報酬などのリターンも得やすくなる
- 信頼の獲得: 周りの思惑が分かれば上手く信頼を獲得し、自分が使いたい技術を巧みにねじ込んで価値創出サイクルに融合させるなどのアクションをやりやすくなる
- 選択肢: 受容できないコンフリクトが発生する場合は、自身が変化する、組織に変容を促す、転職等で環境を変える、現状を受け入れる、などの選択をとる必要がある
- 幸福の最大化: あなたは自身の価値のオーナーであり、幸福の最大化を目指すべき
■ 16. 自律・自由と価値への向き合い
- 理想の組織: 各々が自律・分散・協調し、自由に自発的に動く組織を目指すべき
- ミドルアップダウン: 強力なリーダーシップとボトムアップが両立するミドルアップダウンマネジメントが実現された活力ある組織こそが一番価値を生み出す
- 不可欠な要素: 各々が価値への接続を意識することは不可欠
- 似非自己組織化の危険: 価値に向き合わないと卑近な同僚の安易な問題解決ばかりする似非自己組織化に陥る
- プラクティスの目的: 確実性の高いプラクティスの導入は無駄な複雑化を排除するためで、不確実で曖昧な価値に向き合う時間を増やすため
- 自由の条件: 理想の状態を維持しそこで自由に行動したいのであれば、尚更価値に向き合い、自分たちの価値を認めてもらう必要がある
At a past company, the head of engineering and the principal engineers decided to break our Ruby on Rails application into a Go microservices mesh.
They created very detailed design documents and architecture diagrams. They went all out and used Kubernetes, gRPC, service templates, the whole shebang.
The whole senior engineering leadership came from Amazon, where they were used to each team owning a distinct service. They tried to apply that model directly. But our issues were with code ownership and poor domain modeling.
The entire application could have run on just a handful of EC2 instances.
What was the result?
Five years later, 70% of the application is still running on the Ruby on Rails monolith. Never completed the migration. But now they have to maintain two systems.
None of the original leadership works there anymore.
以前勤めていた会社で、エンジニアリング責任者とプリンシパルエンジニアは、Ruby on Rails アプリケーションを Go のマイクロサービスメッシュに分割することを決定しました。
彼らは非常に詳細な設計書とアーキテクチャ図を作成しました。Kubernetes、gRPC、サービステンプレートなど、あらゆるツールを駆使して徹底的に取り組みました。
シニアエンジニアリングリーダー陣は全員 Amazon 出身で、各チームがそれぞれ独立したサービスを所有することに慣れていました。彼らはそのモデルをそのまま適用しようとしましたが、コードの所有権とドメインモデリングの不備が問題でした。
アプリケーション全体を、ほんの数個の EC2 インスタンスで実行できたはずです。
結果はどうなったでしょうか？
5年経った今でも、アプリケーションの70%は依然として Ruby on Rails モノリス上で稼働しています。移行は完了していません。しかも、今では2つのシステムを維持管理しなければなりません。
元のリーダー陣はもう誰もそこで働いていません。