通読するというよりは、プロセスについて考えるときに適宜参照している。
"このように，ソフトウェア保守要件の発生元が多岐であることから，保守対応は各保守担当者（又は部門）内に閉じた考え方になりがちであった。しかし，共通フレームでは保守プロセスを独立したプロセスとしているため，保守プロセス共通の性質を理解することにより，全般的なソフトウェア保守のプロセスの改善へ結びつけることができる。"
こちらから無料で読み始められます:https://a.co/8X7ZtnK
ほぅ。共通フレームのように、各プロセスを独立したプロセスとして定義することが、サイロ化の対策になると言っているが、本当か？
共通フレームの設計思想でもある「モジュール性」を素直に受け取ると、Team Topologiesがいうところの「X-as-a-Service」を想起する。でも、共通フレームの各プロセスを「stream-aligned team」内に配置することもこともできる。
モジュール化することによって今まで暗黙的に規定されていたチームタイプ・インタラクションモデル（それらは完全に属人だったかもしれない）に設計と選択の余地を与えるのが共通フレームの功績というのが良さそうだ。
それにしても、ISO 12207やISO 14764の記述を見ていると、開発と保守を分離しようという意図を強く感じる。分離しようということは、分離されていなかったことに問題があったからだと思うが、その2000年代の意図に反して、2022年の現在、microservicesやDevOps、stream-aligned teamが流行しているのには、ちょっと歴史の揺り戻しが早すぎるのでは？という違和感がある。
① 問題発生時，業務所轄部門が，問題解決プロセス （4.7参照） に則って，修正依頼の分析を行い，情報システム部門にシステム変更検討を依頼する。
② 情報システム部門の事務局は，保守プロセス （2.6参照） に則って問題把握や修正分析を行い，問題のレベルに応じて，開発部門もしくは保守部門に作業を依頼する。 （※） 問題のレベルに応じて実施する，最初のプロセスから最後のプロセスまでの一連の流れを「ルート」と称して，そのルートを1～5に分類している。ルートの定義は，図4-21を参照。
③ 開発部門もしくは保守部門は，上記ルートのプロセスを実施して，システム又はソフトウェアの改修を行う。その改修が終了したら，情報システム部門の事務局に報告する。
④ 情報システム部門の事務局は，その完全性を確認した後，依頼元である業務所轄部門にその旨を報告する。
⑤ 業務所轄部門は，問題解決したことの報告を受け，その妥当性を確認し，問題解決とする。
こちらから無料で読み始められます:https://a.co/e9KRDwJ
話は変わるが、technical supportないしsupport engineerは問題解決プロセスおよび、保守プロセスの実行主体と考えるとしっくりくるような気がしている。上で言う「情報システム部門の事務局」にあたる。事務局ということはofficeという英語表現がぴったり。
"プロジェクトは，問題解決プロセスに関して，該当する組織の方針及び手順に従って，次のアクティビティを実施する。
a）プロセス開始の準備
b）問題解決"
こちらから無料で読み始められます:https://a.co/dRyutMK
問題解決プロセスのアクティビティ。
"保守者は，保守プロセスに関して，該当する組織の方針及び手続に従って，次のアクティビティを実行する。
a）プロセス開始の準備
b）問題把握及び修正の分析
c）修正の実施
d）保守レビュー及び／又は受入れ
e）運用テスト及び移行の支援"
こちらから無料で読み始められます:https://a.co/dARAkIH
保守プロセスのアクティビティ。a) およびc) の工数が大きい「ふたこぶラクダ」の特性を知る必要がある。
①保守に必要な成果物の引き継ぎ
②問題把握及び修正の分析。他の解決法の検討・提案
③修正の実施
④保守レビュー及び／または受入れ
⑤運用テスト及び移行の支援
⑥業務プロセス改善の提案
こちらから無料で読み始められます:https://a.co/7VqefXo
「ソフトウェア工学の勧め（中）」では、特に断りなく「業務プロセスの改善」が追加されている。
当面の結論として、technical supportのアクティビティを下記として定義したい。
- 問題解決プロセス
- 保守プロセス
- →問題把握及び修正の分析
- →保守レビュー及び／又は受入れ
ここで重要なのは、保守プロセスからテクニカルプロセスを5つのルート（図4-21）のいずれかを呼び出すという部分になります。
