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

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

【参考】
アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する | 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モデル、プロダクトの分類体系（プロダクトタクソノミー）などが出てくる。
これらについても理解したことを書いていく。

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

自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善の話を聞いてきた。
自動車業界の裏話もたくさん聞けて、すごく有意義だった。

【参考】
【ハイブリッド開催】品質・効率・安全を同時に実現する統合開発プロセスの最新アプローチ （第75回 SEA関西プロセス分科会） | Peatix

図解カーエレクトロニクス 上 システム編 増補版 | デンソー カーエレクトロニクス研究会, 加藤 光治, 日経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

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

【1】聞いた講演のストーリーはこんな感じ。
自動車業界では、従来のISO9001系列の規格だけでなく、A-SPICE・機能安全・サイバーセキュリティの規格が次々に導入された。
本来のハード設計、組み込みソフトウェア開発だけでなく、その開発プロセスがこれらの規格に準拠していることが求められる。
そのために、監査のドキュメントが多くて開発現場の負荷が高く疲労している問題が出ている。

そこで、A-SPICE・機能安全・サイバーセキュリティの規格で定義されるプロセス領域や各プロセスを整理統合したプロセスを作ることで、1つの監査資料で複数のアセスメントに対応できるようにしたり、整理統合したプロセスの順番に実施すれば、複数のアセスメントのレビューをスムーズに進められるように対応した、という流れ。

【2】僕としては、それぞれの規格に対する考え方を聞いて面白かった。

まず、A-SPICEは元々、CMMIから派生したSPICEというプロセスモデルがあり、これを自動車業界向けに特化したAutomotive-SPICEが作られた。
元々、CMMIの目的は組織の成熟度を上げるために成熟度モデルに従ってプロセス改善しましょう、という考え方だった。
しかし、A-SPICEはPJごとのアセスメントに行うために、他のPJではA-SPICEが当てはまらないケースが多くなる。
すると、A-SPICEに準拠しないPJにアサインされたメンバーはプロセス改善する目的も意欲もないので、目的が失われてしまい、組織のソフトウェア開発能力が上がらないという結果に陥りがち。
つまり、A-SPICEという規格を通すだけに頑張る、という環境に陥りがち。

そもそも、A-SPICEは欧州の自動車メーカー、特にOEMメーカーが生み出した規格であり、A-SPICEはサプライヤに対する品質要求を定めて、サプライヤのふるい落としに使う。
部品メーカー、つまりサプライヤはプロセス改善に躍起になっているのが実情らしい。

聞いた話では、たとえば、OEMメーカーは、試作車の段階で4社のサプライヤから同じ部品を採用し、各段階でサプライヤを3社、2社と1社ずつふるい落とし、最後の量産工程で初めて1社に決定する。
つまり、サプライヤは試作段階では投資フェーズであり、量産工程で初めて投資を回収するわけだ。

サプライヤはA-SPICEに準拠するように対応するわけだが、A-SPICEを満たさない部品を納入した場合、サプライヤは罰金を支払う契約になるらしい。
つまり、サプライヤは納入して代金をもらうはずなのに、逆に罰金まで支払ってでも、量産工程に採用されるために対応し続ける時もあるらしい。
それぐらい、OEMメーカーに部品を採用されるのは利益があることなのだろう。
そんなA-SPICE規格の内情を聞くと、かなりしんどいプロセスだなと思う。

【3】機能安全の規格は原子力発電所やプラント工場が対象らしく、民生品向けでは自動車が初めてらしい。
機能安全のよくある例は、踏切だ。
たとえば、踏切を安全に動作させるために、バーを付けたり、センサーを付けたり、音を鳴らしたり、点灯させたりする。
そういう機能を付加して、安全を保証するわけだ。

また、危険な状態になったら、安全な状態へ移す機能をつける場合もある。
いわゆるフェイルセーフ。

さらに、試作工程の設計だけでなく、量産工程でも機能安全を検討する。
たとえば、故障率も調べて、許容率よりも超えて故障したら、設計工程から機能安全を考えて作り直す必要も出てくる。
つまり、故障や誤操作を想定しながら、設計工程で機能安全の設計を考える必要があるわけだ。

機能安全の規格もかなり複雑かつ膨大な印象。
機能安全という品質特性は、全ての機能に横断的に関わるだろうから、特有の設計手法が必要だろうと思う。

【4】車載サイバーセキュリティの規格も機能安全と並ぶ、安全性確保のもう一つの柱。

車載サイバーセキュリティの規格が生まれたきっかけとしては、ジープクライシス（Jeep Hack/Crisis）があったらしい。
具体的には、2015年頃の米国で、2人のセキュリティ研究者が走行中のジープを遠隔でハッキングし、運転席のドライバーが操作できない状態で速度を落としたり、ブレーキを無効化したりできることをデモで証明したらしい。
つまり、コネクテッドカーに対するサイバー攻撃の脆弱性が実証・公表されたわけだ。
これにより、ジープの所有者から訴訟が起き、リコールや損害賠償に発展したらしい。
そこで、自動車メーカーは躍起になって規格を作って対応しようとしているわけだ。

【5】では、これらの規格に自動車メーカーはどのように対応しているのか？

基本は、ECUごとに、A-SPICE、機能安全、サイバーセキュリティの規格を当てはめる。
一般に、自動車のECUは100個近くあるらしいので、100個のA-SPICE、機能安全、サイバーセキュリティのドキュメントを全部作っている。
つまり、ECUごとに監査用ドキュメントが異なり、それぞれのアセスメントの観点も違うので、ECU100個　ｘ　3規格＝300個の書類を作る必要がある。
開発者の観点では、同一のECUというハードとソフトに対し、似たような、しかし違う観点の監査用ドキュメントを作らないといけない。
実際の現場を見ると、ハードにソフトを組み込んだ開発とテストだけで精一杯なので、後付けで監査ドキュメントを作っているようだった。
つまり、プロセス改善の目的や動機もなく、ただアセスメントを通すために資料作成している感じだった。

【6】最後の質問では、プロセス改善のコンサルの拠り所、肝は何か？という質問があった。
回答は2つあった。

1つ目は、現場の開発プロセスと規格のマッチング。
サプライヤの現場にはそもそも、開発プロセスという概念がなく、定義された工程がない場合がある。
すると、A-SPICEに応じたソフトウェア開発やハードウェア開発、ハードとソフトを統合した開発プロセスを最初から導入して、現場で初めて実践する必要がある。
あるいは、サプライヤに独自の開発プロセスがあったとしても、A-SPICEに合わせたハード・ソフトの開発プロセスに定義し直す必要がある。
どちらにせよ、規格に対応するだけで精一杯ではないかと想像する。

2つ目は、規格を現場に浸透させること。
アセスメントを依頼する人は管理者、企画部門になるが、監査ドキュメントを作るのは現場のソフト開発者やハード設計者になる。
現場の人には、規格に準拠する動機やインセンティブがない。
現場の人に、いかに、規格に即することが重要なのか、を浸透させる事が大事なわけだ。
しかし、A-SPICEはプロジェクト単位、ECU単位になるので、別PJになれば俺は関係ない、という立場になりやすい。

そういう葛藤を聞いて面白いなと思った。

Jiraの機能はTracに似ている気がする #redmine

最近、Jiraを触り始めた。
Jiraの感想は一言で言えば、昔のTracにすごく似ている気がする。

Redmineユーザの観点では、Jiraは非常に使いにくい。
Jiraのどこが使いにくいのか？

使いにくい原因は、Jiraがアジャイル開発機能に特化していること、Tracのような古い機能が残っていることだと思う。

Tracのワークフロー: プログラマの思索

RedmineとTracの機能比較: プログラマの思索

Jira Cloud ユーザー向け 入門ガイドブック第２版 : リックソフト株式会社

Confluence ユーザー向け 入門ガイドブック | リックソフト株式会社

【1】一般に、JiraはScrumのようなアジャイル開発、カスタマーサポートのようなサービスデスクなどのユースケースに特化している。
Jiraには、アジャイル開発の機能がすでに盛り込まれている。
チケットと呼ばず課題（Issue）と呼ばれている。
課題には、エピック、ストーリー、タスクが既に存在していて、ストーリーポイントのような見積もり項目もある。
課題のビューには、バックログとスプリントバックログが既に存在している。

しかし、一般の日本企業では、WF型開発が主流であり、ExcelのWBSとかガントチャートを使いたい。
結局、リックソフト社のガントチャートプラグインを入れて、Scrumの機能は全く使わず、ガントチャート上でタスク管理している事例がすごく多い。
つまり、日本企業の現場では、実際のタスク管理とJiraのアジャイル開発機能にギャップが発生している。

しかも、日本企業の現場では、Jiraのスプリント機能を使っていない。
スプリントをなぜ使わないのか？

Jiraではプロジェクトを階層化できないため、１個のプロジェクトで１つの大規模案件をアサインする。
すると、１個のプロジェクトに複数チームのタスク管理に使うため、複数チームのタスクが混在してしまう。
だから、複数チームのタスクを区別するために、WBSのトップ階層を各チームに割り当てて、タスクを階層化して使っている。
非常に使いにくいこと極まりない。
Redmineならプロジェクトを階層化できるので、子プロジェクトをチームごとに割り当てることで、タスクを分別できるし、親プロジェクトで横串で横断して管理もできるのに。

しかも、JiraのスプリントはRedmineのバージョンと同様に、１プロジェクトに依存するために、複数チームのタスクに１つのスプリントがアサインされる。
しかし、現場では、チームごとにチーム特有のスプリントを決めたいケースは多い。
大規模案件ではリリースバージョンというメインターゲットが決まっていても、各チームのタスク管理では、各チームごとにこまめにリリースしたいバージョンがあって、それをスプリントにアサインしたいが、スプリントはPJ固有であるために、チームごとにスプリントをアサインできない。

Redmineならば、親子プロジェクトができるから、子プロジェクトでチーム独自のバージョンをアサインできる。
つまり、全チームはアジャイルリリーストレインのごとく、最終ターゲットであるリリースバージョンに向けて作業していく。
ただし、チームごとにリリースバージョンに向けて細かなバージョンを作成してマイルストーンを決定したいし、各チームごとにロードマップを詳細化すればいい。
そういう作業計画がJiraでは非常にやりにくいと感じる。

【2】Jiraのチケット項目には、解決状況というバグ管理システムの遺産みたいな項目がまだ残っている。

たとえば、TracやMantisでも解決状況の項目があったし、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできなかったり、ロードマップの画面に取り消し線でCloseされた意図が表示されない機能があった。

Jiraでも同様に、解決状況＝解決済みor取り下げを設定しなければ、チケットを完全にCloseできない。
チケット駆動の初心者にとって、チケット完了させるためにはステータスを完了にするだけでは不十分なのはなぜ？　解決状況って何なの？と思うだろう。
Redmineのようにシンプルに、解決状況はステータスと同一視して、無くしてしまえばいいのにと思う。

RedmineとTracの機能比較: プログラマの思索

また、チケット管理ツールで最重要な機能であるワークフロー管理機能は、JiraではUIエディタ上で設定する仕組みになっている。
UIエディタ画面上で、ステータスに先行後続の関係を線で引っ張るのが鬱陶しい。
Redmineならば、状態遷移表のようにステータスの先行後続はチェックボックスをつけるだけなので、状態遷移図をイメージできれば記入しやすいし、事前にチェックリストのように作っておけば間違えにくい。

たぶん、TracのワークフローはINIファイルにPlantUMLみたいに記述するやり方だったが、Jiraもそのやり方を踏襲しているが初心者でも使えるようにUIエディタ上で見た目は分かりやすく表現しているのだろうと想像する。
正直使いにくくて鬱陶しい。

Tracのワークフロー: プログラマの思索

さらに、Tracのチケット集計ビューはSQLで直接書くことができたように、JiraでもJQLというSQLに似た構文を使って、ダッシュボードというビューを自由自在に作れるメリットがある。
Jiraを使う場合、Confluenceとセットで使う場合が多いので、Confluenceにダッシュボードを埋め込んで、Wordみたいにきれいに文書化できる。
この点はRedmineよりも優れている点だろうが、解決状況やワークフロー機能の使いにくさを思い出すと、改めてTracにすごく似ているように思える。

【3】とは言え、たぶん僕がまだJiraを使いこなせていないだけなのかもしれない。
自分がやりたいのは、Jiraでスプリント機能を使って、複数チームのタスク管理をイテレーション単位に管理して、アジャイル開発のペースを実現したいことだ。
その観点でさらに試してみたいと思う。

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

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

【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のあるべき姿を提示した点にある。

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

Redmineは組織のナレッジ基盤として実現可能なのか～島津製作所の事例を読み解く #redmineT

redmine.tokyo #27では、@akahane92さんが島津製作所にRedmineを導入し組織のナレッジ基盤として長年運用して成功された事例を講演された。
資料を改めて読んでみて、気づきや疑問もあった。
きちんとまとめたいけど時間がないので、ラフにメモ書きして、疑問形をラフに散らかしている。

【参考】
株式会社島津製作所_研究開発（集団協業と知的生産）の現場を支える、OSS知識基盤システムの導入 - Speaker Deck

Kuniharu AKAHANEさん: 「発表資料 全スライド 85ページ版（SpeakerDeck）です。 Redmine東京＃27、2024年11月9日＠中野 #redmineT https://t.co/52DZPkJfz2 （URL, QRコード は変更なし） https://t.co/QWQYCePqGY」 / X

2024/11/10 第27回勉強会 - redmine.tokyo #redmineT - Togetter [トゥギャッター]

【1】Redmineを導入し成功した事例では、いつも下記のような2つの疑問が問われる。

【1-1】Redmineの機能と、会社として実現したい問題解決の間にあるフィットギャップ

いくらRedmineが有用だといっても、それぞれの会社で抱える問題は個別であり、他事例を安直に移植できない。
Redmineの標準機能で、会社特有の問題をどの範囲までどのレベルまで解決できるのか？

問題解決に対し、Redmineに不足した機能があるならば、どのような手段を使って解決を試みたのか？
それはどのレベルまで解決したのか？

【1-2】Redmineの運用推進を支えるための組織体制づくり
いくらRedmineが有用だといっても、ツールの機能にプロセスは埋め込まれているわけで、そう簡単にユーザに根付くものではない。
Redmineを日々運用して普及を支える組織体制はどのように工夫しているのか？
どのような運用ルールを組み込んでいるのか？

【2】Redmineの標準機能をどのように使っているのか？

ITSの内部構造：

ITSプロジェクト＝PLM(対象装置、製品)毎に作成
ITSプロジェクト毎にメンバーと権限を付与
チケット＝対象装置に関する解決すべき課題
Wiki＝対象装置に関するメンバー間で共有する情報

ITSプロジェクトはどんな観点でどんな単位で割り当てているのか？
ITSプロジェクト＝1製品
プロジェクトの期間は長い
製品が企画されて設計されて、その後製品が販売終了し保守も完全に終わるまで、プロジェクトは続くと推測
そう簡単にプロジェクトはCloseしない
1つの製品プロジェクトに、数年、数十年携わった試行錯誤のチケットが蓄積される
サブプロジェクトに「研究開発　第◯次」が含まれる

Redmineインスタンスは
「分析計測技術ITS」「分析計測事業部ITS Global」の2つ

「分析計測技術ITS」が元々運用されていた
企画部門・開発部門が中心になって、製品企画から開発まで

「分析計測事業部ITS Global」は製品開発後に、製品そのものの製造・販売・サービス保守などと連携するために作られたと推測
インスタンスをわざわざ分けた理由は何か？
製品企画や製品開発までと、設計が完了して量産化体制に入った製品の生産や販売や保守は、情報の観点や管理する観点、部門間の関連度合いも異なる
「情報流通の壁」
販売情報まで企画や設計も含む1つのRedmineに集約する必要はない

プロジェクト数が1千個まで増えている
たぶん、製品寿命は数年以上と長いのでプロジェクトの生存期間は長い
製品が増えればプロジェクトは単調増加する

とはいえ、プロジェクト数が増えても、アサインされるメンバや権限を制御できれば、実作業するメンバは担当プロジェクトしか表示されないので、困ることはない

チケットの対象は？
WBS作業単位から、要求・仕様のストーリー単位
チケットは作業よりも課題
チケットはIssueとみなす
ITSという本来の使い方

チケットの説明欄の文字数が増えている
その理由は明らか
作業レベルではなく、要求や課題の背景、課題解決の試行錯誤まで書き残す

チケットは共有できる研究開発ノート
「後任者の道しるべ」

ナレッジ基盤としてチケット駆動が活用できるメリット
チケット同士の相互リンク
Wikiに技術勉強会などの共有ナレッジを集約

チケットにSubversionの成果物が紐づく
チケットに成果物の履歴もリンクされる
１チケット＝１クリアフォルダ

研究段階からチケットに記録されて、製品開発の担当者にも知見が共有される
試作した結果も研究者にフィードバックされる
研究や開発の相互の担当者にもメリットがある

チケットに添付ファイルを付ける
添付ファイル数が以前より2倍以上に増えている
製品開発に関わる画像やPDF資料が多いのではと推測
チケットにファイルを添付することで、課題の背景や試行錯誤をより説明しやすくなる

チケットの生存期間はどれくらいなのか？
毎週に週次の棚卸しを開催して、3ヶ月以上放置されたら積極的にCloseされている
チケットの生存期間は数週間レベルではないかと推測

チケットは年間で2万～3万件発行されるため、毎月2千件以上発行されると推測
チケット完了率が約80～90％と高いので、1ヶ月以上放置されることはあまりないと推測
チケットの内容が作業レベルよりも製品開発の課題であることから、チケットの難易度はそう簡単ではないと思われるため、チケット完了率の高さが驚き
チケットの作成や更新を担当するメンバーのモチベーションや意識が相当高いと推測

【2】Redmine運用を支えるための非機能要件は満たされているのか？
数千人、数十万チケット、数十テラバイトのデータを維持管理できるRedmine基盤を構築できるのか？

ITSの弱点は全文検索機能

問題点
ITS標準の検索機能はデータ量増加により性能要件を満たせない
検索できる範囲はせいぜいチケットとWikiくらいのみ
検索精度も文字列の一致だけで意味間まで見ていないので、有用な情報を検索できない
真の意味で、情報の追跡可能性を実現できていない

そこで
チケット、Subversion、添付ファイルを全文検索の対象範囲とする
GroongaとRedmineを連携させて全文検索させる

Groongaで Redmineを 高速全文検索 - Rabbit Slide Show

Redmineシステム内の文字列、添付ファイルやリポジトリまで全文検索を対象にしてくれる
スコアベース、畳み込み検索で高精度検索が可能
検索も高性能
元データは未加工、秘匿できている

おそらく、Groongaで定期的に検索対象データをクローリングし、索引を作って全文検索できる仕組みを提供しているはず
全文検索対象の記録文字のほとんどは、Subversionと添付ファイル
PDFやExcel、Word、パワポなどの資料が多いのではないか
それらを全文検索対象にしているはず
全文検索の基盤構築はそう簡単ではないと推測

情報の追跡可能性と非機能要件の確保を実現できたと言うが、3千ユーザ、数十万チケット、数十テラバイトのデータ類を鑑みると、インフラ基盤のチューニングは相当なノウハウが埋め込まれているのではないかと推測
そう簡単に実現できるレベルではない

【3】Redmineの運用推進を支えるための組織体制づくり

Redmineを社内全体に運用推進するための工夫は何か？
組織や体制はどんな構造にしているのか？

数千人の社内ユーザに説明して普及させるには、ITS事務局だけでは推進できない

週次ミーティングでチケット棚卸し
３ヶ月に１度、放置チケットを積極的にClose
問い合わせチケットは、常任モデレータを付けて「見つけてクローズ」

おそらくITS事務局の他に、各部門、各部署に専任のRedmine担当者を付けて、普及推進しているのでは？
そうでなければ、日々の細かな問合せ対応がITS事務局に集中してしまい、運用がパンクする
また、各部署へRedmine運用プロセス訂正通知や指示が流せない
組織をまたがるような指揮命令系統があるのではないか

今後の展望も興味深い
Redmineに蓄積されたデータをAI学習用データとして利活用できるか？

運用後まもなく、構成管理される成果物はDocumentsとSourcesで分類して運用されている
つまり、知識として確定したデータと経験で得られたデータを区別して管理されている
教師データとして使えるデータを区別できている

昨今成長著しいLLMを使えば、会社の事業領域に関する独自データを元に学習させて、学習モデルを作れるはず
過去に販売した製品、今研究中の製品について、AIに聞けば高精度の内容をすぐに回答できるはず
社内の生き字引みたいな人をAIが代用してくれる

こういう取り組みができるのも、Redmineに蓄積されたデータの品質が良いからだろう
チケットや成果物の記録内容の精度が低ければ、いくら学習させても使えない

【4】感想
島津製作所の事例では、@akahane92さんの講演を何度も聞いてきたが、やはりすごいなと思うし、自分もこういう運用をやりたかったなと思う。
Redmineの面白さや醍醐味は、実運用が定着すると、データが自然に蓄積されるので、そのデータを使えば定量的に分析できるし、実験データや研究データとしても使える。
有用なデータを蓄積できていれば、定量分析した内容も有意味になるはずで、いろんな利活用を膨らませることができる。

特に、機械学習などAI活用は全文検索の機能強化にも役立つ。
相互メリットを活かせば、今後も色んな研究に発展できると思う。

Redmineによるタスクマネジメント実践技法【電子書籍】[ 小川明彦, 阪井誠 ] 価格：3,608円 (2024/12/29時点) 楽天で購入

入門Redmine第6版 [ 石原佑季子 ] 価格：3,080円（税込、送料無料) (2024/12/29時点) 楽天で購入

アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか？～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版」本で「適切なアーキテクチャスタイルを識別する」ときにパターンを参照することと同義だと理解している。

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

「システムアーキテクチャ構築の原理」の感想part2～非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する

「システムアーキテクチャ構築の原理」を読んでる。
平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」を読み直して、理解が深まった。
平鍋さんの記事に触発されたので、理解できたことをラフなメモ。
間違っていたら後で直す。

【参考】
『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita

「システムアーキテクチャ構築の原理」の感想: プログラマの思索

【1】「システムアーキテクチャ構築の原理」を読んでいて分かりにくかったことは、ビュー、ビューポイント、パースペクティブという概念が出てきて混乱したこと。
これらの言葉は何を表しているのか、具体的に理解できていなかった。

平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」では、概念モデルでまとめてくれているので理解しやすかった。

@hiranabe さん記事を理解したうえで「ビューとビューポイントの違いは何？」の意見に対する私なりの回答は以下の通り。 ・ビュー＝ステークホルダーの横断的関心事をシステム観点で記述した内容。 ・ビューポイント＝横断的関心事。ユーザ観点。 ・パースペクティブ＝主に非機能要求。システム観点。

— akipii (@akipii) May 6, 2024

【2】図4-3.コンテクストにおけるパースペクティブが「システムアーキテクチャ構築の原理」のメッセージを全て表している。
平鍋さんの解説が分かりやすい。

（引用抜粋　開始）
「非機能要件がシステムのアーキテクチャに影響を与える」という観点を本書は、この言説を徹底的に解説したもの。

非機能要件に限らず、横断的な視点を「パースペクティブ」として捉えている

実際にアーキテクチャを記述しようとすると、１つの文書ではとっても複雑で巨大な説明になる。「ステークホルダー」の「関心事」毎に分割するために、「ビュー」と「ビューポイント」を導入する

「パースペクティブ」は、従来の言葉で近いものとして「非機能要求」「横断的関心事」がある。本書ではこの「ビューポイント」と「パースペクティブ」のカタログを作っています。
（引用抜粋　開始）

【3】図15-1.ビュー間の関係では、ビューを開発や運用の観点で分解している。
この図は、システム開発とシステム保守で分割すれば理解しやすい。
今ならDevOpsだから、開発も運用も一体化しているだろう。

【4】図7-3.アーキテクチャ定義のプロセスは、「システムアーキテクチャ構築の原理」が提唱している、アーキテクチャを定義し評価するプロセス。
アーキテクチャ設計の中で、特に非機能要件を含めた横断的関心事をいかにアーキテクチャに盛り込むのか、を考えた一連のプロセスになる。
プロセスの流れは、アーキテクチャ要素や横断的関心事を段階的詳細化して組み立てたあとにアーキテクチャを評価するので、違和感はない。

【5】「システムアーキテクチャ構築の原理」では上記3つの図が本書のメッセージになると思う。
本書のやり方を各システム、各案件にテーラリングして設計、実装する必要があるから、本書は、アーキテクチャ設計のメタ概念、メタプロセスの解説書みたいな感触を持っている。

【6】「システムアーキテクチャ構築の原理」の副題「ITアーキテクトが持つべき3つの思考」が指す「3つ」とは、「ステークホルダー」「ビューポイント」「パースペクティブ」と最初に書かれている。

その意図は、ステークホルダーの横断的関心事、特に非機能要求をユーザ観点のビューポイント、システム観点のパースペクティブで分解して組み立てて、トレードオフを考慮したアーキテクチャを設計すること、を意味していると考える。

他にも気づいた他内容があれば書いていく。

「システムアーキテクチャ構築の原理」の感想

「システムアーキテクチャ構築の原理」を読む機会があったので感想をラフなメモ書き。

【参考】
「システムアーキテクチャ構築の原理」の感想part2～非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する: プログラマの思索

『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita

アーキテクチャ構築の原理 第2版を読んだ - 勘と経験と読経

【0】「システムアーキテクチャ構築の原理」は最新版の第２版もある。
僕は確か、デブサミ2010の時に会場で購入した記憶があり、第１版を持っている。
その時から興味のある部分だけかいつまんで読んでいたので、全部を通して読んでいなかったので、輪読するのは良かった。

「システムアーキテクチャ構築の原理」を読んで興味を持った部分はいくつかある。

【1】１つ目は、2008年の初版でありながら、マイクロサービスやサービス志向のアーキテクチャ設計を目指していること。
機能的ビュー、情報ビュー、並行性ビューなどのソフトウェア構造のアーキテクチャ設計の観点は、業務システム設計と微妙に違うな、と感じていたが、実際はクラウドベースのマイクロサービス設計を目指しているのだろう。
実際、並行性ビューでは、昔のバッチ処理設計よりもイベント駆動の並列性アーキテクチャに力点をおいている。
たとえば、REST APIやAdapter・Facadeパターンのようなアーキテクチャ設計を念頭に置いて実装しようとしている。

そう考えると、マイクロサービス設計における新たな設計思想はまだ含まれておらず、荒削りな内容を感じるが、文章の背後にある著者の思い、こういうことを言いたいのではないか、を推測しながら読むと理解できるのでは、と感じる。

【2】2つ目は、ATAMという非機能要件の設計技法を解説してくれている点だ。

データベースコンサルタントのノウハウちょい見せ アーキテクチャをレビューする方法(ATAM)

ATAMはシナリオベースで非機能要件を評価する設計技法。
僕の理解では、システムのアーキテクチャの特に非機能要件を品質特性ごとに分類し詳細化して、それをシナリオに落とす。
そのシナリオを優先度付けして、シナリオベースにアーキテクチャを評価して整合性を取ったり、システム設計を明確化する。

利点は、非機能要件をアーキテクチャとして評価する技法として、シナリオベースを用いているので、アジャイル開発をやっている人には取り組みやすいと思う。
デメリットは、CMMIを作ったSEIがATAMを提唱しているので、重たいプロセスになりがちで、テーラリングが必須であり、プロマネによってばらつきが出やすいこと。

ATAMに関する日本語書籍は「システムアーキテクチャ構築の原理」と「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価 (Software Design plus)ぐらいしかないので、貴重だと思う。

データベースコンサルタントのノウハウちょい見せ 書評「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価」

【3】3つ目は、2009年頃の書籍なので、UMLをベースとした設計を念頭に置いていること。
機能的ビューではコンポーネント図、情報的ビューではER図やDFDや概念クラス図、並列性ビューではステートマシン図を使うと良いと説明されている。
このあたりの意見は僕も同意するが、注意点はいくつかあると思う。

コンポーネント図は「アジャイルソフトウェア開発の奥義」でも重要視されている。
機能を1つのコンポーネントとみなし、コンポーネント間のインターフェイスを重視する設計は重要だと思う。
一方、コンポーネント図だけでは表現しきれない仕様や要件があり、不十分と感じる。

その点は「システムアーキテクチャ構築の原理」でも、メッセージングのやり取りは記述できないので補足説明や別の図が必要と書かれている。

並列性ビューに出てくるステートマシン図は、より詳しく書いていくと結局、詳細設計レベルになってしまう。
アーキテクチャ設計ではRFPに出てくる要件レベルまでで留めたいので、粒度を揃えるのが難しい場合が多いだろう。

【4】「システムアーキテクチャ構築の原理」を読んでいて思い出すのは、2000年代にソフトウェア・プロダクトラインが流行した頃に読んだ「 実践ソフトウェアアーキテクチャ」に出てくる一節だ。

そのボタンを押したら何が起きるのですか？～アーキテクチャは利害関係者のコミュニケーション手段: プログラマの思索

実践ソフトウェアアーキテクチャの解説記事: プログラマの思索

「 実践ソフトウェアアーキテクチャ」では、政府のある委員会の2日間に渡る討議の中で、新人のアーキテクトが、政府が作ろうとしているシステムのアーキテクチャをコンサル独自の記法でモデルを描いて委員会の参加者に説明していたところ、委員会の参加者たちは何が問題なのかに初めて気づいた。
そして、委員会の参加者たちは、新人のアーキテクトの説明を途中で止めさせて、システムのアーキテクチャの問題点を活発に議論し始めたという一節だ。
これが意味しているのは、アーキテクトの役割とは、システムのアーキテクチャ設計に関する最終責任者ではなく、各利害関係者の間でシステム要件のトレードオフを考慮させる調停者であることだ。

つまり、アーキテクトの役割はシステム要件を決めることではなく、システム要件のトレードオフを色んなステークホルダーに説明して理解させて、最終的な意思決定を引き出す調停者として振る舞うべきだ、ということ。
この一節は僕が一番好きなところでもある。

「システムアーキテクチャ構築の原理」では、アーキテクトがすべてのパースペクティブやビューポイントを理解している全能の神のように思えてしまうが、実際はそうではなく、アカウンタビリティを持つ調停者という観点で捉えると理解しやすいと考える。

気づいた点はまた書き留めていく。