リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読み始めて、色々考えたことをメモ。

【参考】
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する | Nick Tune, Jean-Georges Perrin, 元内 柊也, 岩﨑 勇生, 角谷 太雅 |本 | 通販 | Amazon

More Joel on Software | Joel Spolsky, 青木 靖 |本 | 通販 | Amazon

アーキテクチャモダナイゼーションとはそもそも何なのか？: プログラマの思索

アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か: プログラマの思索

システムのリプレース案件が最も危険な理由: プログラマの思索

【1】リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか？
まだ違いが分からない。
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するでは何を語ってくれているのか？

【2】リプレース案件はIT業界の人なら誰でも経験するデスマーチ案件だ。

ユーザや顧客から見れば、既存システムは動いているのだから、その機能をそのまま移し替えるだけでしょ。
動く既存システムが仕様そのものだから、見れが分かるでしょ、とユーザは思う。
しかし、リプレース案件を担当すると、どんな技術者も苦労すると思う。

リプレース案件の特徴は３つあると思う。

一つ目は、アーキテクチャの構成要素のバージョン依存関係の難しさ。
インフラ基盤のサーバー、OS、DB、ミドルウェア、プログラミング言語のバージョン違いから出るバージョン組み合わせの品質担保の難しさ。
構成要素のバージョンが１つ違うだけで、すぐにシステムは動かなくなる。

二つ目は、システム移行、データ移行の難しさ。
同じ機能のシステムを単に入れ替えるだけなのに、システム移行、データ移行で必ずトラブル発生。
たとえば、システム移行の障害では、構成要素のバージョン依存関係が原因になるケースが多い。
データ移行の障害では、既存データのボリュームが多すぎて処理時間が想定よりも長くなって業務トラブルが発生したり、既存システムのインフラ基盤やRDBに思わぬ落とし穴が原因のケースが多い。

三つ目は、同じ機能をそのまま入れ替えるだけなのに、現行と新規システムの機能比較テストで必ず差異が出てテストに苦しむ。
ユーザから見れば、なぜ現行システムと新規システムでテスト結果が異なるのか分からない。
しかし、ちょっとした環境の違いによって、プログラムやデータの振る舞いは予期しない結果になりやすい。
テスト計画やテストマネジメントの方がプログラミングよりも大事。

その他にも、業務移行の難しさがある。
古い現行システムは使いにくいUIや既存バグがそのまま残って使いづらい。
よって、ユーザもバグあり前提で業務を運用している。
安易にUI改善や既存バグ修正すると、既存業務も変わってしまう。
リプレースのついでにBPRも行ってしまうと、マニュアル改訂やユーザ説明会みたいな工数も増えてしまい、業務移行コストが想定以上に増えてしまう。

つまり、リプレース案件には新規開発案件や機能改修案件とは異なる特徴がある。

【3】リプレース案件では、テストや移行という後工程の作業にかなりの工数が割かれるケースが多い。
そういう特徴を理解して、アーキテクトやプロジェクトマネージャはリプレース案件のプロジェクト計画を立てる。
特に、テスト計画や移行計画の精度の高さが、リプレース案件の成功度合いに直結するだろう。

【4】では、改めて、リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか？
NotebookLLMの回答は下記の通り。

既存システムを新規システムへ移行するという点では共通していますが、リプレースとアーキテクチャモダナイゼーションの違いの本質は、その「範囲」「アプローチ」「目的」の3点に集約されます。

1. 範囲の本質：技術刷新か、ソシオテクニカルな刷新か
リプレース：主に古い技術スタックを新しいものへ置き換えるといった、純粋に技術的な側面に焦点が置かれます。
モダナイゼーション：技術だけでなく、人、組織構造、ビジネス戦略、働き方のすべてを深く連携させる**「ソシオテクニカル（社会技術的）」な刷新**です。
組織のコミュニケーション構造がシステム設計に影響を与える「コンウェイの法則」を前提とし、組織とアーキテクチャを共同で最適化します。

2. アプローチの本質：革命（大規模刷新）か、進化か
リプレース：最初に全体を設計してからゼロから新しいコードを書く「ビッグデザイン・アップフロント」が主流であり、既存システムをすべて廃棄して作り直す**「大規模刷新プロジェクト（革命）」**になりがちです。これはしばしば「悪夢」のような困難を伴います。
モダナイゼーション：完成形を最初にすべて定義するのではなく、**「進化的アーキテクチャ」**の考え方を取ります。3～6カ月といった短期間で段階的に価値を提供し、継続的な学習とフィードバックを通じてアーキテクチャとロードマップを改善し続ける「終わりのない旅」と捉えます。

3. 目的の本質：負債の返済か、資産の再構築か
リプレース：既存の機能をそのまま新しい環境へ移植する「リバースエンジニアリング」に終始しやすく、古いシステムの欠陥や不要な複雑さを引き継いでしまうリスクがあります。
モダナイゼーション：単なる「負債の返済」ではなく、「資産の再構築」競争優位性のある資産へと転換し、高速なフロー（迅速かつ安全なデリバリー）を実現することを目指します。
結論として、両者の違いは**「システムを新しくするだけでなく、変化に適応し続ける組織能力そのものをアップデートしようとしているか」**という点にあります。

【5】NotebookLLMの回答を読む限り、アーキテクチャモダナイゼーシヨンには下記の観点があるらしい。
・技術視点よりも、組織戦略や経営戦略の観点で組織とアーキテクチャ最適化を重視
・「大規模刷新プロジェクト（革命）：よりも、「進化的アーキテクチャ」を重視
・「リバースエンジニアリング」という単なる「負債の返済」よりも「資産の再構築」を重視

この観点が、リプレース案件の特徴から発生する諸問題、特に移行やテストの難しさをどのように解決してくれるのか？
まだ理解できていないので、じっくり考えてみたい。

アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読み始めた。
アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か？
考えたことをメモ。

【参考】
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する | Nick Tune, Jean-Georges Perrin, 元内 柊也, 岩﨑 勇生, 角谷 太雅 |本 | 通販 | Amazon

チームトポロジー 適応型組織設計

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング | 広木 大地 |本 | 通販 | Amazon

アーキテクチャモダナイゼーションとはそもそも何なのか？: プログラマの思索

チームトポロジーにおける4チームのインタラクションをUMLで整理してみた: プログラマの思索

チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する: プログラマの思索

システムのリプレース案件が最も危険な理由: プログラマの思索

【1】アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読むと、アーキテクチャモダナイゼーションイネーブリングチーム（AMET：Architecture Modernization Enabling Team）という特別なチームがある。
このチームの役割と責任範囲は何か・
このチームは、アーキテクチャモダナイゼーションにおいてどんな役割を果たすのか？

【2】Geminiに聞いてみた。

アーキテクチャモダナイゼーションイネーブリングチーム（AMET：Architecture Modernization Enabling Team）は、全ての決定を下す中央集権的なチームになることなく、取り組み全体を通じて推進力を維持しながらモダナイゼーションを導き、サポートする専門チームです。チームトポロジーにおける「イネーブリングチーム」の一種であり、組織の能力向上に伴い段階的に縮小・解散する「一時的な足場」としての性質を持ちます。
AMETの主な役割と責任範囲は、以下の6つの目的と具体的な活動に集約されます。

1. 6つの主な目的（役割）
モダナイゼーションの始動: 説得力のあるビジネスケースを構築し、ヒアリングツアーやキックスターターワークショップを通じて、取り組みを停滞させる「分析麻痺」を打破して軌道に乗せます。

勢いの維持: 定常業務（BAU）やバグ修正などの優先順位に押されることなく、取り組み全体を通じて高いエネルギーを維持し、進捗を阻害する障害を取り除きます。

よりよい設計の促進: ドメイン駆動設計（DDD）などのモダンなアーキテクチャ設計スキルが不足しているチームに対し、コーチングやワークショップを通じて設計スキルの向上を支援します。

長期的で持続可能な変化の促進: 一時的な活動に終わらせず、新しい働き方や技術的実践が組織のDNAとして定着し、AMETがいなくなっても自律的に改善を続けられる基盤を築きます。

ビジョンと進捗の伝達: 取り組みの外部にいる関係者が不安を感じたり価値を疑ったりしないよう、ビジョンと具体的な進捗状況を組織全体へ周知し続けます。

成功事例と学びの共有・展開: 特定の分野での成功や教訓を他の分野へ広め、組織全体の学習を加速させます。

2. 戦略的・組織的な責任範囲
ビジネス戦略への貢献: アーキテクチャの変更をビジネス目標や成長戦略と明確に結びつけ、投資の正当性を説明する責任を負います。
アーキテクチャ運用モデルの確立: AMET解散後も組織が進化し続けられるよう、アーキテクチャギルドの設立やアーキテクチャアドバイスプロセス（分散型の意思決定手法）の導入を支援します。
依存関係の管理とボトルネックの解消: 複数のチームにまたがる複雑な依存関係や、レガシーシステムに関連するボトルネックを特定し、その解決に向けてリーダーシップ層と連携します。
スキルアップと人員配置の助言: 必要な技術的実践（テスト駆動開発や継続的デリバリーなど）を導入し、人材育成や外部パートナーの活用について助言します。

3. 求められる姿勢とスキル
AMETは「指示を出す側」ではなく「支援する側」であるため、メンバーには高度な技術力に加えて、**忍耐強い対人スキル（NVC：非暴力コミュニケーションなど）**やコーチング力が極めて重要視されます。自ら作業の一部をこなしつつも、適切なタイミングで一歩引き、現場のチームに主導権を委ねる柔軟性が求められます

【3】ここから分かることは、AMETはチームトポロジーにおけるイネーブリングチームであることだ。
AMETは、イネーブリングチームなので、アーキテクトの専門家、ソフトウェア品質保証や開発プロセス改善の専門家から成る専門家集団であって、ストリームアラインドチームから独立している。
ストリームアラインドチームを支援したり指導する役割と捉えた。

つまり、AMETはモダナイゼーションを推進するアーキテクト専門家集団だ。

よって、AMETは経営層と開発チームの間で、お互いの情報を吸い上げたり落とし込んだり、調停する立場にある。
すなわち、AMETは経営層を支援し、開発チームを指導する権限を持つ強力なチームと言える。
社内では相当な権力を持つチームではないだろうか。

なぜならば、AMETがモダナイゼーションを定義するアーキテクチャを指定し、そのアーキテクチャの基板上でストリームアイランドチームはアプリ開発するだろうからだ。
ストリームアイランドチームを支援するために、プラットフォームチームやコンプリケイテッドチームも存在するのだろう。

【4】そんなことを考えると、モダナイゼーションを実施する案件の規模は相当な大規模PJになるだろう。
100人月はもちろん、もっと大規模な工数がかかるだろう。
単なるアプリ開発チーム以外に、AMETのようなアーキテクト専門家集団もいて、アーキテクチャを支える基盤を構築維持するプラットフォームチームもいるのだから、相当な人数が関わる案件になるからだ。

よって、PJ管理は相当難しくなるだろう。
アーキテクチャそのものも相当複雑になりがちだろうと想像する。
だからこそ、AMETのようなアーキテクト専門家がいなければ、たくさんのストリームアイランドチームという開発チームにガバナンスを効かせて統制を取ることができないだろう。

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するではAMETがかなり重要な役割を果たしているので、じっくり読んでみたいと思う。

アーキテクチャモダナイゼーションとはそもそも何なのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読み始めた。
アーキテクチャモダナイゼーションとはそもそも何なのか？
考えたことをメモ。

【参考】
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する | Nick Tune, Jean-Georges Perrin, 元内 柊也, 岩﨑 勇生, 角谷 太雅 |本 | 通販 | Amazon

More Joel on Software | Joel Spolsky, 青木 靖 |本 | 通販 | Amazon

システムのリプレース案件が最も危険な理由: プログラマの思索

【1】アーキテクチャモダナイゼーションとはそもそも何なのか？
システムのリプレースとは何が違うのか？
システム刷新に出てくるリホスト、リビルド、マイグレーションなどの概念とは何が違うのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するには明確に書かれていないようだが、理解した限り、
「モダナイゼーション＝リプレース＋UX改善＋組織変革」
を意味するらしい。
つまり、単純なリプレースを意味しない。

【2】一般に、リプレース（再構築）とは、既存システムの機能は変えず、システム内部構造を再構築し直すことだ。
リプレース案件は、SIerのビジネスの中でかなりの案件数を占めるのではないか。
ITシステムは一度作ったら10年以上変えずに動くわけではなく、OSやミドルウェアやプログラミング言語のVerUp、CPUやメモリやHDD容量のサーバー性能増強、外部環境の変化によって、必ず定期的に手を加えなければならない。
そのタイミングでシステムの内部構造を入れ替える時が多い。

しかし、リプレース案件は大抵、デスマーチ案件に陥りやすい。
その理由は20年以上前に書いた。

システムのリプレース案件が最も危険な理由: プログラマの思索

リプレース案件は危険だ。
リプレースでなくても、リホスト、リビルド、マイグレーション程度の案件であっても、ソフトウェア開発能力やPJ管理能力が不十分ならば、失敗案件に陥りやすい。
たぶん、IT案件特有の事象だろうと思う。

【3】モダナイゼーションはリプレースだけでなく、UX改善や組織変革を含む意味は何なのか？
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読むと、システムの内部構造を変えるだけでなく、UXも改善することで、利用ユーザの便利さや活用も重視している点だろう。
つまり、業務プロセスの改善、ビジネスモデルの変革も意図しているのだろう。

さらに、モダナイゼーションが単純なリプレースではなく、ドメイン駆動設計やアジャイル開発を志向するのであれば、逆コンウェイ戦略に基づく組織運営になるだろう。
つまり、インフラ層・DB層・アプリ層・フロントUI層のような機能別レイヤーの組織構造ではない。
チームトポロジーのように、複数のストリームアイランドチームが中核の機能を開発し、イネーブリングチームやプラットフォームチーム等が支援する組織構造になるだろう。

すなわち、ソフトウェア開発組織も従来のような機能別組織ではなく、アジャイル開発に適したスクラムチーム主体の開発組織になることを意味しているのだろう。

【4】では、アーキテクチャモダナイゼーションを考える正統性、意義はどこにあるのか？
従来のリプレース案件の延長ではなく、アーキテクチャモダナイゼーションをわざわざ考えるのは、どんな背景・意図のためにあるのか？

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するを読むと、下記の観点があるらしい。

1. 経営・投資の切り口：ROI（投資対効果）の最大化
背景: モダナイゼーションはシステムと事業運営への相当な投資であり、決して無料ではありません。
意図: 闇雲にすべてを刷新するのではなく、**「ビジネスの戦略的優先事項にどう貢献するか」**を明確にすることで、投資収益率（ROI）を最大化させる判断材料を提供しています。

2. 競争優位性の切り口：競合への対抗と「慣性」の打破
背景: 成功した企業ほど過去のビジネスモデルに固執し、変化を嫌う「慣性」が生じます。一方で新規参入者は最新技術で武装して破壊的変革を仕掛けてきます。
意図: 自社の開発能力が時代遅れになり、**「迅速な競合他社に後れを取るリスク」**を直視させることで、存亡に関わる脅威としてのモダナイゼーションの必要性を説いています。

3. 事業成長の切り口：拡大を阻む「足かせ」の除去
背景: 新規参入者の脅威がない場合でも、既存のアーキテクチャがビジネスの拡大（市場浸透、新プロダクト開発など）を物理的・構造的に妨げることがあります。
意図: 市場開拓や多角化といった**「成長戦略」を支えるために、どの程度の刷新が必要か**を見極める視点を提供しています。

4. 資本戦略・M&Aの切り口：企業価値（資産）の再構築
背景: 買収による成長を目指す場合や、自社の売却（出口戦略）を検討している場合、レガシーなシステムは「負の資産」として評価を下げたり、統合のボトルネックになったりします。
意図: 厳密な資産査定に耐えうる**「投資家にとって魅力的なアーキテクチャ」**を維持することが、出口戦略の成功に直結することを示しています。

5. ユーザー体験・運用の切り口：品質と生産性の向上
背景: 劣悪なUXはブランドへの信頼を失わせ（二重予約などの事故）、非効率な内部ツールは運用コストを増大させ、従業員のストレスを増大させます。

意図: 単なる「見た目の修正」ではなく、「根本的なアーキテクチャの負債」がUXや生産性を毀損している事実をステークホルダーに認識させるためです。

6. 組織能力の切り口：人材の採用と定着
背景: 古い技術スタック（例：COBOLや巨大なC++モノリス）を使い続けることは、優秀なエンジニアにとってキャリアの行き止まりを感じさせ、採用困難や離職を招きます。
意図: 「本気でモダナイゼーションに取り組む姿勢」そのものが、優秀な人材を引きつける強力なインセンティブになるという副次的メリットを提示しています。

つまり、単に技術者がシステムを綺麗にしたいから、という意図だけではなく、「ビジネスの存続と成長のために不可欠な投資である」意図が重要なわけだ。

【5】アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するは内容がとても濃い。
システム設計の話よりも、経営戦略や組織戦略の観点が多い。
だから、正直読みづらい点もある。

アーキテクチャモダナイゼーション 組織とビジネスの未来を設計するに出てくる重要なキーワードには、AMET（Architecture Modernization Enabling Team）、アンゾフの成長戦略、BVSSHモデル、プロダクトの分類体系（プロダクトタクソノミー）などが出てくる。
これらについても理解したことを書いていく。

自動車の組込ソフトウェア開発が難しい理由は3つある

自動車の組込ソフトウェア開発の現場を見ると、とても難しいなと思う。
第三者視点で考えたことをメモ。

【参考】
自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か？: プログラマの思索

システムズエンジニアリングに基づく製品開発の実践的アプローチ | 後町智子, 土屋浩幸, 鈴木　研 |本 | 通販 | Amazon

図解カーエレクトロニクス 上 システム編 増補版 | デンソー カーエレクトロニクス研究会, 加藤 光治, 日経Automotive Technology |本 | 通販 | Amazon

図解カーエレクトロニクス 下 要素技術編 増補版 | デンソー カーエレクトロニクス研究会, 加藤 光治, 日経Automotive Technology |本 | 通販 | Amazon

Automotive SPICE 4.0 実践ガイドブック[入門編] エンジニアリングセット | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

Automotive SPICE 4.0 実践ガイドブック[入門編] 管理支援 | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

ISO26262 2nd実践ガイドブック［エンジニアリングセット］ | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

詳解 車載ネットワーク -CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために- | 藤澤行雄, 品川雅臣, 高島 光, 村上 倫, 石本裕介 |本 | 通販 | Amazon

【1】自動車の組込ソフトウェア開発を現場で見ていると、皆いつも忙しそうにしている。
基幹系システム開発の時よりも大変なように見える。

組込ソフトウェア開発の初心者である僕から見て、ハードとソフトを組み合わせて正常動作させることすら、根本的に難しいように思う。
業務系Webシステムの設計・開発・保守を経験した僕が見て、ハードと一体化したソフトウェア開発は、ハードレベルに近い知識も必要。
相当大変なように思える。

また、自動車にも自動運転のように、AIを使った機能追加は当たり前になった。
おそらく、どのOEMメーカーも、どの部品メーカーも、AIを使った新機能の開発、さらには研究開発に相当のリソースを投入しているはずだ。
もはやハードウェアに付加価値はないので、ソフトウェアでいかに付加価値を上げるか、にビジネスモデルの力点が移動している。
しかし、AIの開発は、組込ソフトウェアやWebシステムとは異なる異次元の専門知識も必要なので、習得のハードルも高い。

さらに、自動車の製造には、数多くのISO規格の認証が必要だ。
なぜならば、民生品と言えども、人命に関わる製品なので、人命第一の品質保証が問われるからだ。
数多くのISO規格の監査を踏んで承認が得られなければ、そもそも販売できない。

そんな状況を踏まえると、自動車の組込ソフトウェア開発が難しい理由は、3つあると思う。

【2】１・ECUというハードとソフト双方を結合した部品を作った後に、さらに複数のECUを統合して初めて1台の自動車が完成するので、結合・統合テストで非常に苦労する。

そもそも、ECUとは、車載の電子制御装置（Electronic Control Unit）の略。CPUが10個ぐらい搭載されていて、ハード部品と組込プログラムから成る。例えば、エンジンECU、ブレーキECU、エアバックECU、自動運転ECUなどがある。一般に、デンソーのようなTier1メーカーが製造し、OEMメーカーであるトヨタ、ホンダに納品し、OEMメーカーが20～50個くらいのECUを結合して1個の自動車を作る。

Geminiでは、下記の解説があった。
車ECU（Electronic Control Unit）は、自動車のエンジン、ブレーキ、エアバッグなど様々なシステムを電子的に制御する「車載小型コンピューター」です。センサーから得たデータをもとに最適な動作を計算し、1台の車に約100個搭載されることもあります。現代の車には不可欠な「頭脳」です。
ECUの主な特徴と役割
役割（自動車の「頭脳」）: エンジンの燃料噴射・点火制御、ブレーキ（ABS）、パワーステアリング、車線維持支援など、安全・快適・性能を包括的に管理します。
構成: マイクロコントローラ、メモリー（ROM/RAM）、入出力インターフェースで構成され、厳しい耐熱・耐振動設計が施されています。
連携: 車載ネットワーク（CAN）を介して、それぞれのECUが連携して動作します。
種類: エンジン系、シャシー系、ボディ系（ライト、ドア）、情報系（ナビ）など、機能ごとに分散しているほか、これらを統合する「統合ECU」の採用も進んでいます。
近年は、自動運転や電動化の進展に伴い、より高度な処理能力を持つECUの重要性が高まっています。

つまり、ECUに組み込むソフトウェアのテスト、ECUというハードとソフト自体の結合テスト、さらには複数のECUを組み合わせた1つの自動車という統合テストという多段階のテストが必要。
Webシステムのような単純なテストモデルではない。

また、彼らのテスト作業を見ると、回這う現場にはECUというハードの台数が少ないので、ECUのテスト時間を予約して、その間にテストしてバグ出ししている。
ECUというテスト機器も1チーム1台ではなく、複数チーム1台しかないので、テスト機器の確保が大変みたい。
すなわち、ハードに縛られたソフトウェア開発では、テスト対象のECUというハードウェアが作業のボトルネックになりうる。

【3】２・自動運転（AD）や走行制御（ADAS）のように、全てのECUに指示制御する統合ECUが初めて出現したために、従来のハード中心のゾーンアーキテクチャからソフトウェア主導のアーキテクチャに変わったので、ソフトウェア開発力が弱いメーカーは非常に苦しいと思う。

Geminiに聞くとECUのアーキテクチャには、ハードの名残りから進化した歴史がある。

自動車の脳にあたる「コンピューター（ECU）」の配置ルールは、進化とともに3段階あります。
・ドメイン型：役割ごとのチーム制。「走る」「止まる」など機能別に脳を分ける方式です。機能が増えるほど配線が複雑になり、車が重くなるのが弱点です。
・ゾーン型：場所ごとのエリア制。「右前」「後ろ」など車の場所で脳をまとめます。近くの部品を最短の配線でつなぐため、線を劇的に減らして軽量化できます。
・セントラル型：一極集中制。車の中央に超高性能な「1つの脳」を置き、全てを指揮します。スマホのようにソフトの更新だけで車の性能を後から進化させやすくなります。
現在は、配線を減らしつつ高度な制御を行うため、2と3を組み合わせた形が主流になりつつあります。

つまり、最近では、自動運転（AD）や走行制御（ADAS）が全てのECUを指示・制御する必要がある。
そのために、ADやADASの機能を持つ統合ECUが必須となるセントラル型アーキテクチャが主流になっていると思う。
ハード面でもソフト面でもアーキテクチャ設計が以前よりも遥かに重要な印象。

昔は、トヨタやホンダが「ハードの部品のすり合わせ」により1つの自動車を作っていた印象。
しかし、今は、SDVという「車のAPI化やOTAでソフトウェアによるハード制御などの実装に近い設計手法」になったために、
20～50個ものECUを結合して、性能、品質、セキュリティなどを担保するのは、昔ながらの「すり合わせ」では実現不可能。

「すり合わせ」という複数チームのコミュニケーション活動による解決ではなく、ハード面でもソフト面でも「アーキテクチャにより自動車の構造をすり合わせる」へ時代が変わったと考える。
だから、MBSEのような「アーキテクチャ主導の製品開発」が重要になってきたと考える。

【4】３・A-SPICE、機能安全、サイバーセキュリティのような監査プロセスを踏んで品質担保を保証する必要がある。
ソフトウェア開発チームはソフトウェア開発だけでなく、監査ドキュメント作成の作業負荷も増えている。
これらの規格をOEMメーカーがTier1の部品メーカーに要求するため、開発現場はいつも人手不足で作業が大変な印象。

その問題点は下記に書いた。

自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か？: プログラマの思索

【5】自動車のソフトウェア開発が面白いなと思う点は、元々、ハードとソフトを組み合わせるので難易度が高い上に、MBSEのようなアーキテクチャ主導のソフトウェア開発が必要になったこと、更には、A-SPICE、機能安全、サイバーセキュリティのようなISO規格遵守も必要になったことにより、他のシステム開発よりも複雑かつ難易度が高い点だ。

一方、他の製造業の業界に比べると、トヨタを頂点とした自動車業界は品質面でもプロセス面でも優れているので、彼らの考え方を理解できれば、他の製造業を富士山から眺めるような観点で見下ろして、強みや弱みを比較分析して把握できるだろうと思う。
たとえば、家電、機械製品、化学、医療、食品加工、防衛産業などの製造業を比較評価することで理解しやすくなると思う。

その辺りも色々考えてみたい。

データモデリングではシステムが宿命的に負う複雑性をどのように解決しようとしているのか

関西IT勉強会で、データモデリングについて聞いてきた。
関西IT勉強会の議論について、@kitaohxさんと議論しながら、「データモデリングでは、システムが宿命的に負う複雑性をどのように解決しようとしているのか？」について気付きがあった。
ラフなメモ書き。

【参考】
販売管理システムで学ぶモデリング講座 (DB Magazine Selection) | 渡辺 幸三 |本 | 通販 | Amazon

システム開発・刷新のための データモデル大全 | 渡辺 幸三 |本 | 通販 | Amazon

業務別データベース設計のためのデータモデリング入門 | 渡辺 幸三 |本 | 通販 | Amazon

生産管理・原価管理システムのためのデータモデリング | 渡辺 幸三 |本 | 通販 | Amazon

業務システムのための上流工程入門 | 渡辺幸三 |本 | 通販 | Amazon

人月の神話 | フレデリック・P・ブルックス，Jr., 滝沢徹, 牧野祐子, 富澤昇 | 工学 | Kindleストア | Amazon

データモデリングの手法をあなたは持ってますか？ at 関西IT勉強宴会: プログラマの思索

「やさしいデータベース設計」出版記念講演 in 新大阪 - connpass

「やさしいデータベース設計」出版記念講演 in 新大阪 (第105回IT勉強宴会) | ＩＴ勉強宴会blog

【0】システムが持つ本質的な複雑性を、データモデリング屋はどのように解決しようとしているのか？

「人月の神話」には「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という一節がある。
この言葉は、システムが本質的な複雑性を持っている、という論点だし、SEもアーキテクトも皆、この論点をいつも考えていると思っている。
この内容について以下考える。

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索

【1】お題は、大学生に対するストレスチェックみたいなアンケートシステムに対し、データモデルを書く。
渡辺さんは、ホワイトボードを前に、ライブ・コンサートみたいに、スラスラとデータモデルを書いていく。

データモデリングの手法をあなたは持ってますか？ at 関西IT勉強宴会: プログラマの思索

書いたデータモデルについて、参加者と議論があった。

外部キー制約の実装箇所はDB層なのか、アプリ層なのか、あなたがモデラーならどうする？

外部キー制約をRDDBMSに貼れば、ER図をそのまま実現できる形になる。
一方、大量データをデータ移行する時、外部キー制約があると、外部キーとして存在しないキーを登録するとエラーになる。
つまり、データをインポートする順番を事前検討する手間がかかる。
Railsや他のフレームワークでもそうだが、たぶん、RDBのテーブルは主キーぐらいの制約だけで、アプリ層で外部キー制約を実装する場合が多いだろう。

渡辺さんもえとうさんも、話を聞くと同じで、フレームワーク層に配置する、と。
つまり、DBMSに制約も張らず、アプリ層でもなく、その間のフレームワーク層に配置する意見で一致していた。

渡辺さんは自作のローコード開発基盤を持っているので、その基盤上で制約を実装する。
えとうさんはTM手法手法の人だが、Seasarを使っていると言っていたので、フレームワーク層で実装するのだろう。
僕の理解と合ってたので特に違和感なかった。

【2】この論点の問題をさらに発展させると、外部キー制約だけでなく、動的参照関係、ユニーク制約などのDBMSの制約ロジックはDB層なのか、アプリ層なのか、どこに実装すべきなのか？

渡辺さんは、外部キー制約、動的参照関係、ユニーク制約など、DBMSの関数従属性にプラスアルファされる制約条件は、ローコード開発基盤に実装すべきであり、アプリ層に配置すべきではない立場だ。
なぜならば、DBMSの制約条件とビジネスロジックは関心事が異なるから、という論点と理解している。
えとうさんはTM手法ですが、実装レベルでは、Seasarで実装していると言っていたので、フレームワーク層で実現する点は同じと理解している。

つまり、DB層とアプリ層の中間レイヤである純粋仮想化物の層であるフレームワーク層に、制約を配置すべきだ。

【3】アンケートシステムのデータモデルでは、渡辺さんがデータモデルに、「支援制約」「回答値制約」というカラムを書いていた。
ストレスチェックのアンケートシステムの目的は、学生の心身状態をアンケートで回答してもらい、心が病んでいる学生にはカウンセリングや薬物処方などの手当や支援が必要だ、という考え。
だから、アンケートの質問に応じて回答内容は何でも良いわけではなく、何らかの制約がある。
「支援区分」には学生、家族のようなカテゴリがあり、学生への支援内容、家族向けの支援内容ではそれぞれ対策が異なるので、何らかの制約がある。
そのような内容があるので、「支援制約」「回答値制約」と書いていた。

【4】では、「支援制約」「回答値制約」のような制約ロジックの内容をテーブルのカラムに埋め込むのか、フレームワーク層やアプリ層にロジックを実装するのか？

確か楽々フレームワークの人はフレームワークに実装する意見だった。
渡辺さんは、テーブルのカラムに制約ロジックまで入れてしまえばいい意見だった。
例えば、何らかの制約ロジックはJavaScript プログラムのテキストでカラムに放り込み、フレームワーク層でJSプログラムを評価して実行すれば良い。
そうすれば、プログラム実装やビルド、デプロイも不要で、データをアップデートすれば簡単と言う理由と思う。

【5】僕の意見では、単に制約ロジックと言う業務ロジックをDB層に配置するか、フレームワーク層やアプリ層のプログラミングする層に配置するのか、と言う単純な論点ではないと考える。
つまり、論点は、アーキテクトとして、システムが持つ本質的な複雑性をどのように解決しようとするか、だ。

システムが宿命的に負うべき複雑性をいかに分散して全体のコストを最小化すべきか？

一般に、普通のアーキテクトであれば、N層レイヤーの発想を元に、MVCモデルのように、ビジネスロジックを層別に分割し配置して、複雑性を人間の手で扱えるレベルまでバラす。

一方、データモデリング屋は、業務ロジックをできるだけDB層に全て表現したい欲求がある。
この利点は、本質的な複雑性をDB層に押し込むことで、機能を実装するアプリ層の複雑性を狭めて、アプリ開発のコストを減らしたい意図があると考える。
渡辺さんが提唱する三要素分析法は、システムが持つ本質的な複雑性をDB層に落とし込むために、データモデリングでもっと頭を使い、プログラミングするアプリ層は簡単にしたい発想と思う。

「販売管理システムで学ぶモデリング講座 (DB Magazine Selection) | 渡辺 幸三 |本 | 通販 | Amazon」では、「データモデルと業務モデルを複雑にして機能モデルを簡単にする」という言葉で表現されている。
この意味は、システムが持つ本質的な複雑性をDB層のデータモデルと、例外業務を含む業務手順に集約し、プログラミングで実装する機能モデル、つまり、アプリ層は複雑にすべきではない、という考え方だ。

実際、例外業務はいくらでもあるので、それを全てシステムで実装すべきではないだろう。
年1回しかやらない例外業務で手間が駆らないなら、業務マニュアルで解決すればいい。
例外業務をプログラミングしてしまうと、例外業務のロジックがあれば修正コストが発生し、トレードオフを考慮すると無駄になるかもしれない。

また、業務ロジックから発生する関数従属性の制約条件は、アプリ層で逐一実装するのではなく、DB層あるいはDB層を薄く包むようなフレームワーク層に配置すればいい。
プログラマは、関数従属性の制約ロジックを逐一実装しなくてもいい。
もっと本質的な業務ロジックを実装すべきだから。

【6】この発想を推し進めると、ローコード開発基盤は、データモデルやモデル駆動開発と相性がいいと思う。
ローコード基盤はDB層をラッパーしているから、プログラマはRDBMSのテーブルを直接触ることもないし、アプリ層で必要なオブジェクトだけ触れば、自然に制約条件が満たされる、という形になるはずだ。
つまり、DB層をラッパーしたフレームワーク層はローコード開発基盤というわけだ。

今後はAIがプログラミングしてくれるので、モデリングや要件定義の重要性が高まるから、ますますローコード開発基盤の重要性は高まるだろう。
我々は本来、事業に役立つ業務を実行したいのであって、無駄なプログラムを大量に作りたいわけではない。
ローコード開発基盤を使って、直接の利用ユーザが使いたいシステムを素早く品質よく作りたいのだ。

特にローコード開発基盤は、製造業の基幹系システム、生産管理システムでニーズが多いと思う。

データモデリングを極めていくと、ローコード開発基盤に落ち着き、さらにはAIエージェント駆動によるプログラミング自動生成までつながるのが面白い。

【補足】
データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて | 杉本 啓 |本 | 通販 | Amazon

実践的デ-タモデリング入門 (DB Magazine SELECTION) | 真野 正 |本 | 通販 | Amazon

やさしいデータベース設計　要件定義から運用までの勘どころ | 衛藤 豊 |本 | 通販 | Amazon

事業分析・データ設計のためのモデル作成技術入門 | 佐藤 正美, TMの会 |本 | 通販 | Amazon

データモデリングの手法をあなたは持ってますか？ at 関西IT勉強宴会

関西IT勉強宴会で、データモデリングについて聞いてきた。
データモデリングの手法をあなたは持ってますか？と皆に聞かれた気がした。
ラフなメモ書き。

【参考】
やさしいデータベース設計　要件定義から運用までの勘どころ | 衛藤 豊 |本 | 通販 | Amazon

「やさしいデータベース設計」出版記念講演 in 新大阪 - connpass

「やさしいデータベース設計」出版記念講演 in 新大阪 (第105回IT勉強宴会) | ＩＴ勉強宴会blog

事業分析・データ設計のためのモデル作成技術入門 | 佐藤 正美, TMの会 |本 | 通販 | Amazon

システム開発・刷新のための データモデル大全 | 渡辺 幸三 |本 | 通販 | Amazon

業務別データベース設計のためのデータモデリング入門 | 渡辺 幸三 |本 | 通販 | Amazon

生産管理・原価管理システムのためのデータモデリング | 渡辺 幸三 |本 | 通販 | Amazon

業務システムのための上流工程入門 | 渡辺幸三 |本 | 通販 | Amazon

【1】渡辺さんのライブモデリングは、いつ見ても、すごいと感じる。
佐野さんよりいきなり、お題は、大学生に対するストレスチェックみたいなアンケートシステムに対し、データモデルを書いてみましょう。

渡辺さんは、大学と学生のテーブルを書いた後、こんな感じでホワイトボードに書き始める。
アンケートと質問が必要ですね。
質問はアンケートごとに作られるので行番号があり、アンケート回答ごとの何らかの制約は回答値制約、アンケートに基づき大学生の心身状態に対応する必要があるので、対応区分と対応制約があるね。

次に、アンケート実施した結果は、学校別アンケートが必要で、その元ネタは生徒別回答だね。
ここで、生徒別回答テーブルのカラムを書き出した時、さらっと「（対応区分）」と書いて、動的参照関係が出てくるね、と書き下す。

そして、アンケート結果から、学生の心身状態に対応する集計結果が必要なので、対応区分別SUM（サマリ）も必要だね。

最後に、学校別にもアンケート集計結果が必要で、学校別対応区分SUMがいるね。
ここで、学校別対応区分SUMへ、外部キー制約や親子関係を貼っていく。

では、このデータモデルを皆で見てみましょう。
ここで、「対応区分」という言葉が、アンケートシステムの目的にフィットしていないことに気づき、本来は学生の心身状態に応じて支援する対策を立てることであるから、「支援区分」と書きましょう、と赤字で書き直した。

衛藤さんが絶賛されていた点は、一度書いたデータモデルを赤字で「支援区分」に見直して修正したこと。
まさにモデラーですね。
データモデルに対し、最後まで美学というか、こだわりをもって、少しでも用語に違和感があれば最後まで粘って、用語を修正し、モデルを修正する。
ドメイン駆動設計で言う、ユビキタス言語にこだわっている。
モデラーの美学、コンサルの美学を僕も感じた。

【2】渡辺さんのデータモデリングの最大の利点は、DBMSの制約条件が自然に出てくることだ。
具体的には、外部キー制約だけでなく、ユニーク制約などだ。
ユニーク制約は、国民年金番号みたいに別の主キーがもう一つあるね、とか、取引管理番号みたいにもう一つの主キーがいるはず、という業務ルールを意識して考えなければ、出てこないだろう。

特に、動的参照関係という、DBMSでは実装できず、論理的なER図だけでしか表現できないような制約条件も、渡辺さんのデータモデリングでは自然に出てくる。
動的参照関係は、TM手法でも他のデータモデリング手法でも、明示的に導出される場面を見た時がない。

たぶん、渡辺さんの過去の経験値から、こういう手法が編み出されているのかなと想像する。

こういうシーンは過去にも見た時がある。
１０年以上前だが、花束問題のデータモデルに、テーブルの派生関係にさらに２次識別子を設けて、受払いの過去データと予定データを１つにまとめる手法は、目からウロコだった。

第39回IT勉強宴会の感想～花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索

【3】TM手法と渡辺さんの関数従属性だけのモデリング手法は、どちらが優れているのか？
見た感じでは、渡辺さんの関数従属性だけのモデリング手法が生産性が高く、分かりやすい。

実際、今日はいきなり、佐野さんから、アンケートシステムのお題を出されて、渡辺さんはあっという間にホワイトボードにデータモデルを書き上げた。
しかも、実際にアンケートシステムは既に作られていて、その画面を見ながら答え合わせすると、そのデータモデルはほぼ同じ。

一方、TM手法では、２つのリソースの対照表を作っては、業務レベルで必要なのか吟味する作業を延々と続けるので、正確ではあるが、モデルを完成させるまでに手間がかなりかかる。
また、外部キー制約、ユニーク制約とか、特に動的参照関係の制約までは、業務ルールを意識しなければ出てこない。

【4】ただし、TM手法では、２つのメリットがあると思う。
１つは、リソース数とイベント数を数えて、リソース数＞イベント数であれば、新しいイベントを生み出すことで新しい事業を生み出す可能性があると指摘できること。

リソース数がビジネスの可能性に関係する理由: プログラマの思索

もう一つは、「データモデリング入門－astah*を使って、TMの手法を使う－」はとても良いモデリング資料: プログラマの思索に書いたように、２つの業務の順番を入れ替えることで、コストやリードタイムを劇的に改善できる可能性を指摘できること。
たとえば、「伝統的なセーターの製法は「糸を染めてからセーターを編む」」だが、「染色から販売まで6ヶ月もかかるので、見込生産になる。在庫が蓄積されやすい。」
しかし、「ベネトンは「セーターを編んでから染める」手法へ製造順序を逆転した」ことで「製造期間を短縮できるので、受注生産や直販が可能になった。在庫も減らせる。」

「データモデリング入門－astah*を使って、TMの手法を使う－」はとても良いモデリング資料: プログラマの思索

つまり、TM手法では、データモデルから新しい事業や業務を提案できる仕掛けを持っている。
その点が非常に面白いと思っている。

【5】渡辺さんのデータモデリングは何度か見ているが、今日みたいに、いきなりライブモデリングしていく姿に刺激を受けた。
関数従属性というたった一つのルールだけで、データモデルをTOBEとして描くことができるわけだ。
真似できないが、色々考えてみたいと思う。

【補足】
データモデリングでドメインを駆動する──分散／疎結合な基幹系システムに向けて | 杉本 啓 |本 | 通販 | Amazon

実践的デ-タモデリング入門 (DB Magazine SELECTION) | 真野 正 |本 | 通販 | Amazon

チームトポロジーにおける4チームのインタラクションをUMLで整理してみた

「チームトポロジー」を理解するために、4チームのインタラクションをastahで整理してみた。

【参考】
チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する: プログラマの思索

チームトポロジーから組織の現時点を知る #チーム開発 - Qiita

SalesNowの開発組織を支えるチームトポロジー

30分で分かった気になるチームトポロジー

【1】チームタイプｘチームインタラクションモードをアクティビティ図を流用して表形式で整理してみた。
典型的なインタラクションのみ記載してみた。

やはり基本は、他チームにAPIを公開して利用してもらうIFだろう。
CollaborationやFacilitationでいつもチーム間でコミュニケーションを取るのはコストがかかりすぎると思う。
チーム間のIFが軽いケースが増えれば、結局、自身のチームで作成したAPIを社内の他チームに使ってもらうケースになるだろうと思う。

【2】チームトポロジーにおける4チームのインタラクションをクラス図で書いてみた。
典型的なインタラクションのみ記載してみた。

中心には、サービスを開発するStream-aligned teamがある。
Platform team、Complicated Subsystem teamがStream-aligned teamにリソース（API）を提供する。
Enabling teamがStream-aligned teamをコーチングしたり支援したりする。

もちろん、Stream-aligned team同士でCollaborationしたり、APIを提供する場合もある。

そういうチーム間の構造を見ると、チームの種類数はこれだけしかないのか、という疑問も湧いてくる。
おそらく、「チームトポロジー」の著者が色んな会社で大規模アジャイル開発を見てきて、これらのチームタイプに収斂されたのではないかと想像する。

【3】こういう内容を理解してくると、チームトポロジーを実際に使いこなして、試してみたくなる。

しかし、チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する: プログラマの思索でも書いたが、社内にあるたくさんのアジャイル開発チームを組織編成できる人たちのレベルは、CTOや事業部長クラスの人たちであり、普通のスクラムマスターのレベルの人達では難しいのではないだろうか。
一人の開発者をチーム間でやり取りするだけでなく、アジャイルチームそのものを切り出したり、吸収したり、統廃合する権限が必要になってくるからだ。

事例をあまり良く知らないので他にも探したり聞いてみたいと思う。

チームトポロジー [ マシュー・スケルトン ] 楽天で購入

チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する

「チームトポロジー」を読んでみた。
ざっくり読んだだけなので理解が浅いと思うが、理解したこと、疑問に思ったこと、感じたことを書き残しておく。
ラフなメモ書き。

【1】「チームトポロジー」を読む前に、疑問を持っていた。

【1-1】1つ目は、「チームトポロジー」は大規模アジャイル開発の文脈で、どんな意義があるのか？
大規模アジャイル開発の書籍は、「SAFe 5.0のエッセンス スケールド・アジャイル・フレームワークによりビジネスアジリティーを達成する [ リチャード ナスター ]」「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 [ Craig Larman ]」などがあり、SAFeやLeSS、Scrum@Scaleなどの考え方もすでにある。
SAFeは官僚主義的だが実践的、LeSSはScrumをスケール化したものと理解している。
それらを踏まえて、「チームトポロジーは、大規模アジャイルの考え方の中でどのように位置づけられるのか？
従来の考え方を整理しただけに過ぎないのか、それとも、どんな新しい考え方をもたらしたのか、理解したいと思った。

【1-2】2つ目は、「チームトポロジー」はアジャイル開発にどんな新しい考え方をもたらしたのか？　
昔のアジャイル開発の考え方とどこが異なるのか？　
今の時代に即した開発チームや組織のあり方は何か？　
その時代に応じたアジャイル開発の文脈があると思っているので、若い人達がどんな考え方を持って感じているのか、理解したいと思った。

【2】チームトポロジーのテーマは、ソフトウェア組織はどのように進化させるべきか？と理解している。
事業を取り巻く外部環境はコロコロ変わる。
事業を支えるシステムも、コロコロ変わる外部環境や事業の発展速度、事業規模に振り回される。
そのような変化の激しい外部環境や事業環境では、従来のWF型開発ではついていけない。

コンウェイの法則は誰もが知っているが、実際に適用できる企業は非常に少ないと思う。
従来のWF型開発では、技術重視で層別に組織化されて、チームが分断されている。
インフラチーム、DBチーム、アプリチーム、UIチームとか。
1つのシステムをデリバリするのに複数チームが連携しないとデリバリできない、とか。

しかし、コンウェイの法則を適用できたとしても適用して成功できた期間は短いケースも多いと思う。
アジャイル開発を実践するチームが増えたとしても、事業が発展し事業規模が大きくなれば、業務が複雑化し、開発チームの増加やシステムの複雑性によって、じきに上手くいかなくなる。
本質的な複雑性をシステムもチームも抱え込む。

そこで、組織は、然るべきタイミングを見つけて、チームタイプを変えたり、チーム間IF（コミュニケーションスタイル）を変えていくべき。
「チームトポロジー」はそういうストーリーと理解した。

【3】「チームトポロジー」で重要な概念は2つ。
チームタイプとチームインタラクションモード。

【4】チープタイプは４種類ある。
バリューチェーンを構成する主要業務は、Stream-aligned teamが担当する。基本は一般的なアジャイル開発チームと思う。
チームトポロジーでは、Stream-aligned teamが6～9割は占めるだろうと言っている。
やはり、Stream-aligned teamが事業を動かすエンジン。

Stream-aligned teamを支える補助チームが3種類ある。Enabling teamは、特定の技術領域やプロダクト領域の専門家集団。能力ギャップを埋める役割を果たす。Azure専門家チームとか、火消しプロジェクトに入ったPMOチームみたいなイメージだろうか？

Platform teamは、Stream-aligned teamが相当な自律性のもとでデリバリーを可能にするチーム。インフラ基盤を提供したり、APIを提供するチームと理解した。クラウド基盤チーム、IoT基盤チームみたいなイメージだろうか。

Complicated Subsystem teamは、特別な知識に大きく依存しているシステムを構築維持する責任を持つチーム。長年維持した既存の基幹系システムを担当するチームのイメージだろうか。他に、機械学習チーム、AIチーム、音声処理チームなどの特殊技術だけの開発チームもあるだろうか。

【5】チーム間のコミュニケーションをシステム間のIF設計と同様に扱う。
それがチームインタラクションモード。

チームインタラクションモードは3種類ある。
チーム間のコミュニケーションをシステム間のIF設計と同様に扱うイメージと理解した。会話スタイルをAPIやプロトコルで例えると理解しやすいと思う。

コラボレーションは異なるスキルを持つ２チームが一緒に取り組む。探索して学習できるが、認知負荷が大きすぎる。コラボレーション税と本では書いている。新規事業ではどうしても複数チームが共同で開発してデリバリーするケースも多いだろう。アジャイル開発なら一般的なケースと思う。

X-as-a-Serviceはシステム部品がサービスとして提供される。提供チームと利用チームに分かれる。利用チームは、提供された部品や技術を信頼できるのでその分デリバリーが速くなる。前提は、サービス境界が正しく実装されていること。API提供チームの責務が大きい。
Platform teamの主な職務遂行モード。AWSやAzureが普及しているし、マイクロサービス設計されていれば、APIから部品を組み立てる感じですぐにデリバリーできるはず。

一方、ファシリテーションは、他チームに支援と能力を提供する。プラクティスや新技術の導入とか。Enabling teamの主な職務遂行モード。他チームが学習すること、
問題や障害を発見して取り除くことに対応する。
コーチするチームとコートされるチームに分かれるだろう。プロセス導入と普及、品質向上活動、新技術導入とか色々ケースはあると思う。

【6】チームタイプｘチームインタラクションモードのマトリクスで、チーム間のコミュニケーションスタイルを切り替える。たぶん製品ライフサイクル（PLC）で考えれば、チームタイプが変化するタイミングに気づきやすくなると思う。

たとえば、PLCの導入期は、単純な1チームのStream-aligned teamだけでいい。まだ新規事業を1個立ち上げたばかりだから、少人数のアジャイル開発チームで十分。
しかし、PLCの成長期に入ると、事業規模が拡大し、開発者も増えて管理職が管理監督するようになり、組織も複雑化してくる。

Stream-aligned teamの数が増えてチーム間IFが取れなくなる。例えば、Enabling teamが機械学習やAzureの技術やアジャイル開発のプラクティスをコーチングしたり、Platform teamがAPIやサービスを提供して、Stream-aligned teamが早期にデリバリーしやすくする仕組みが必要になってくる。
事業規模に応じて、チームを増やしていくが、チーム横断で支援する専門チームをアサインする必要があるわけだ。

そして、PLCの成熟期に入ると、複雑化した既存システムに対しComplicated Subsystem teamが専任してサービスを社内に提供し、他チームのデリバリーへの影響を避ける、とか。あるいは、機械学習、ロボティクス等の専門チームをComplicated Subsystem teamに割り当てて他チームにサービス提供するとか。

事業の主要業務に特化したStream-aligned teamだけではじきに対応できなくなる。最低限の共通基盤を抽出し、開発基盤やAPIを提供して素早いデリバリを支える専門家チームとしてPlatform teamが必要になる。

あるいは、業務が複雑化すれば、チーム間で能力のばらつきも出てくる。そこでコーチングして能力ギャップを解消するために、支援だけの専門チームとしてEnabling teamも必要になる。

【7】チームトポロジーは、大規模アジャイル開発で組織編成する時に、一つの指針になる。
いくら、リーン、スクラム、DevOpsが適用されてもまだ問題は残る、

安定して速くデリバリーするアジャイル開発チームを側面から支援したりコーチングしたりする専門家チームがやはり必要なのだ。
ただし、それは従来のWF型開発における層別に分けられた共通基盤チームと同義ではない。

【8】チームトポロジーを真に実践できる人のレベルは誰か？
CTOや事業部長クラスの人ではないかなと思う。
事業部制組織のトップが、担当するソフトウェア事業を成長させるために、どのタイミングでどのような組織構造に変えるべきか。

なぜなら、チームのメンバーもプロジェクトリーダーも、複数のチームを編成する権限を持っていない。
プロジェクトマネージャもせいぜい、大規模開発チームの傘下にある複数のサブチームを編成するぐらいの権限しか持っていない。
幅広く横断的にチームを統合したり、分割したり、新たな役割を割り当てることができるのは、CTOや事業部長レベルになるのではと勝手に推測する。

その意味では、チームトポロジーを習得する難易度は高いだろうと思う。
まず1つのチームでアジャイル開発を実践して成功できたうえで、大規模アジャイル開発も実践して、さらに複数のアジャイルチームをコントロールするノウハウが必要になるからだ。

【9】チームトポロジーを読む前では、大規模アジャイル開発の書籍では、コミュニケーションやモチベーションに関する組織文化に特化した話題が多い気がしていて、何か欠落している気がしていた。
たぶん組織構造の話題がなかったからだと思う。
チームトポロジーでは、組織構造のテーマを真正面に捉えている。その点は非常に有用だと思う。

チームの役割やチーム間のIFを種類分けし、「組織センシング」によって然るべきタイミングにチームタイプやチーム間のインタラクションモードを変えていくべき、という主張は非常に役立つ。
組織がしかるべき自覚を持って、チーム構造を進化させるタイミングに気づくべきなのだ。
組織構造を事業の変化やアーキテクチャの変化に合わせて変えていく手法として、有用な内容だと感じた。

モデリングの論点は、ソフトウェアをどんな観点で分割して整理すべきか。チームトポロジーのような組織論の論点は、デリバリーを安定して速くするためにどんな組織構造を割り当てるべきか。
結局、ソフトウェアの本質的な複雑性をいかにコントロールするか、その根本問題を巡って、その時代に応じた文脈で問題解決の方法が提唱されて、少しずつ変化していると感じた。

【10】
「チームトポロジー」は大規模アジャイル開発の文脈で、どんな意義があるのか？
チームトポロジーの意義は、組織文化よりも組織構造に焦点を当てて、状況に即したチームタイプやチーム間IFを取るべきと主張している。

「チームトポロジー」はアジャイル開発にどんな新しい考え方をもたらしたのか？
チームトポロジーがもたらした考え方は、Scrum、リーン、DevOpsなど、過去のアジャイル開発の発展を踏まえて、アジャイル開発チームの特性やチーム間IFのあるべき姿を提示した点にある。

チームトポロジー [ マシュー・スケルトン ] 楽天で購入

「世界一流エンジニアの思考法」の感想

「世界一流エンジニアの思考法」を読んでみた。
気づきをラフなメモ書き。

【1】試行錯誤は悪であること。
本番障害の原因調査でも、手当たり次第、ログから調べて探すのは生産性が悪い。
事実から仮説を1つずつ立てて、その仮説を1つずつ検証して可能性を潰していく。

試行錯誤が良くない理由は、後で得られる経験知がないからだ。
やみくもにモグラ叩きのように潰して、ああ終わったというだけ。
障害解決した一つの経験が後で活用できない。

事実から推測して、起きそうな仮説を複数パターンで立ててみる。
そこから1つずつ潰していくことで、自分のロジックを検証していることにもなる。
どこに原因があったのか、後で振り返るときにも役立つ。

すぐに手を動かさない。まず仮説を立ててアプローチを選択して一つずつ動かす。
分かっていれば当たり前なのだろうが、納期に迫られて焦っているときほど忘れやすい気はする。

【2】コードリーディングのコツは極力コードを読まないこと。
すべての実装ロジックを理解しようとすると、脳みそのメモリが浪費されて余裕がなくなる。
空きメモリがなくなる。

動くものと仮定して、中身のロジックよりも、インターフェイスの役割やパラメータを調べて、関係性や動作を構造化することに注力する。
全体像を把握することと同じだろう。
この辺りは、コンポーネント図やシーケンス図、ステートマシン図、クラス図などを書きながら、構造を理解する方法もあるだろう。

コードリーディングは重要だが、いかに自分の脳みその負担を減らすか、に注力する。
自分にとって難しすぎると感じるときは、脳の使い方が間違っているというメッセージになる。

頑張る人、完璧主義の人、焦っている人ほど、脳みその空き容量がなく、脳みそを有効活用できていない。
そういうマインドセットを持つことも大事だと思う。

【3】日本独特の批判文化はソフトウェア開発と相性が悪いこと。
日本人は完璧主義すぎて、機能の網羅性や機能の品質を重視しすぎるために、ソフトウェアを漸進的に開発して品質を改善するやり方に馴染めていない。
最初に出したバージョンからソフトウェアに完璧を求める。

日本人は責任の所在や完璧を過剰に求めることで、開発者の心を砕いてしまう。
ソフトウェア開発者が先陣を切って何かにトライする行動に足かせを作らせる。
嫉妬、批判、冷笑、嘲笑が新しいことへのチャレンジ精神を阻害する。

人に何かを期待するのではなく、まず自分がどういう貢献ができるかという公共性をベースに考える。
これにより、互いにありがとうという感謝の精神が生まれる。

しかし、日本では理不尽なカスタマーハラスメントが起こりやすい潜在的な土壌が多い。
つまり、日本ではアジャイルなソフトウェア開発をやりにくい精神的土壌がたぶんあるのだろう。
従来からずっと言われているように、日本でソフトウェア開発がなかなか上手くいかない理由の一つは、国民性や文化的な側面もかなりあるのかもしれない。

また、日本の産業界ではハードウェア文化が強すぎて、ソフトウェアを甘く見てきている節もある。
どうしてもプログラマよりもマネージャ職の方が待遇面もキャリアも良いように制度も文化も作られてきた。
よって、アジャイル開発のように、現場の開発チームのメンバーが自分で実際に作って動かして、ソフトウェアを使って組織や世界を変えていくという方向性を実現しづらい。
現代のイノベーションは素人が集まっても作れるわけではなく、技術やクリエイティビティを持つ専門家集団がリードする必要があるだろう。

マイナンバーカードやデジタル庁、標準の公共システム開発にしても、色々頑張ろうとしているが、乗り越えるべきハードルは大きい。

【4】牛尾さんの本は過去にもたくさん読んできたが、「世界一流エンジニアの思考法」も同様に、文章は丁寧で読みやすく、内容は新たな価値に気づかせてくれる内容が多い。
アジャイル開発に慣れていれば当たり前の話だろうが、日本人がこれから乗り越えるべきハードルが書かれているので、非常に示唆に富む本ではないかと思う。

世界一流エンジニアの思考法 [ 牛尾 剛 ] 価格：1,760円（税込、送料無料) (2024/12/8時点) 楽天で購入

アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか？～Software Processes are Software, Too（ソフトウェアプロセスもまたソフトウェアである）

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」をアジャイルアーキテクトさんや他の方と輪読していたときの感想をメモ。

【1】「ソフトウェアシステムアーキテクチャ構築の原理 第2版」は既に絶版なのだが、内容は良い本だ。
アーキテクチャ設計のプロセスを現代風にうまく表現してくれている。
今のマイクロサービス設計にも当てはめることもできるだろう。

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」に出てくる用語は、図4-3.コンテクストにおけるパースペクティブを見ればいい。

その時のビューは、図15-1.ビュー間の関係　の観点で整理される。

【2】「ソフトウェアシステムアーキテクチャ構築の原理 第2版」をアジャイルアーキテクトさんや他の方と輪読していたときに一つの疑問があった。

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」では、アーキテクチャを定義し、設計し、実装し、評価する一連のプロセスが、図7-3.アーキテクチャ定義の詳細で定義されている。
そのプロセスの中に、「適切なアーキテクチャスタイルを識別する」プロセスでは、過去のアーキテクチャパターンを参照するという記述があり、腑に落ちていなかった。
アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか。
アーキテクチャ設計はもっと高尚なプロセスではないのか、という認識が強すぎた。

実際のシステム開発では、ユーザの要求を元に、業務やシステムの要件を定義し、スケジュールやコスト、品質の観点からアーキテクチャの候補を複数から選定して基盤を決定する。
そこから具体的な設計、実装に入っていく。
今なら、業務要件や機能要件を定義する中で、非機能要件を満たせるようなインフラ基盤やネットワーク基盤、開発フレームワークを選定するだろう。
サーバはクラウド、クライアントはPCやスマホなどを基盤に選定するだろう。

そういう設計を具体的に行うときに、過去のアーキテクチャパターンを参照するときもあるが、新しい技術を導入する時は過去の事例がないので、苦労するし、失敗しやすい。
その疑問を解決できていない気がしていた。

【3】この疑問について、先輩と議論して気づいたことがある。

アーキテクチャ設計について、アーキテクトの経験や会社の過去事例に既に実績があるならば、いきなりアーキテクチャ設計を実装するのではなく、要件を基に、過去に成功して実現性の高いアーキテクチャパターンを採用することで実装する方針を決めるのは自然な流れと理解した。
その時に、プロセスの実行（プロセスクラスをインスタンス化して実行）においても、同様に過去のプロジェクトで成功して実績のあるプロセス事例を参照して、プロセスを設計するのは自然な考え方ではないか、と気づいた。

一方、新しい技術を取り入れてアーキテクチャ設計する時、社外の専門家である外部ベンダーに参画してもらい、その知見を活かしてもらうわけだが、そのやり方も実現性の高いアーキテクチャパターンを知っている専門家を利用しているわけだ。

この辺りをモデル化してみた。

「当初の案」では、プロセスパターンクラスをアーキテクチャごとのタイプみたいなパターンクラスとみなし、プロセスクラスとしてプロセスのテンプレートを生成し、各プロジェクトではプロセスクラスのテンプレートををカスタマイズして実行するイメージだった。

しかし、要求とパターンの整合性を取る必要がある時に、要求そのものにパターンを抽出する基準が暗黙的に既に埋め込まれている。
実際、要求に沿ってシステムとして実現できるアーキテクチャはこれだ、と選定するときに、要求を制約事項とみなすアーキテクチャを過去のベストプラクティスを元に選定しているからだ。
つまり、アーキテクチャ設計としてアーキテクチャを選定するときに何らかの選定基準は暗黙的に埋め込まれている。

その暗黙的な基準こそが、パターンでありイディオムであるわけだ。
アーキテクトは、自身の脳みその中に、多数のパターンカタログ、イディオムカタログを暗黙的に保持していて、それを基準に当てはめている。

そこで、「田中さん案を元に再構成した案」で書き直してみると、プロセスパターンクラスをインスタンス化したものがプロセス記述書になる。
これはアナリシスパターンの抽象・具象パターンに相当するだろう。
そのプロセス記述書は、アーキテクチャ設計プロセスのテンプレートであり、どのプロジェクトでも使えるテンプレートになっている。
このプロセス、手順に従えば、アーキテクチャ設計ができますよ、という手順書になっている。
そのプロセス記述書は単なる手順書ではなく、過去のベストプラクティスが盛り込まれて、ソフトウェア開発が成功するような知見が盛り込まれているわけだ。

このプロセス記述書を各プロジェクトに当てはめて、必要であればカスタマイズして実装して、プロジェクトを実行していくことになる。

【4】そんなことを考えると、まだうまく表現できていないかもしれないが、ソフトウェア設計、ソフトウェア開発そのものも一つのソフトウェアのような気がしてくる。

そんな論文「Software Processes are Software, Too」は1980年代に既に提唱されているよ、と先輩から教えてもらった。

Software Processes are Software, Too

主張は「ソフトウェア開発プロセスは、プロセス記述書というクラスをインスタンス化したものである」と理解したがもう一つ重要な観点があると思う。
それは「ソフトウェアを再利用して効率化するやり方と同様に、ソフトウェア開発プロセスも再利用できるはずだし、それがパターンやイディオムになるはず」だという考え方だと思う。
つまり、「ソフトウェアシステムアーキテクチャ構築の原理 第2版」本で「適切なアーキテクチャスタイルを識別する」ときにパターンを参照することと同義だと理解している。

この辺りはもう少し整理してみたい。