「システム開発・刷新のためのデータモデル大全」を読み直した感想～親子頻出アンチパターンは初心者モデラーに多い

「システム開発・刷新のためのデータモデル大全」を読み直した。
今までの経験を思い出しながら読み直すと気づきが多かった。
気づきをラフなメモ。

【参考】
業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

【1】テーブルをリソース系とイベント系の2種類に分けてみた

データモデリングが重要と分かっていても、ER図を書いてみても実際の業務フローや画面UIがイメージしにくい。
データ構造から業務フローがイメージできないと、単にデータがそうなっているだけとしか分からない。

そこで、マスタであるリソース系はR、トランザクションであるイベント系にはEをテーブルに付けて区別して見るようにしてみた。
業務フローをイメージするために、イベント系のテーブルは、TA字型ER手法を使って、外部キーがある関係は、先行後続を付けて見るようにした。
この考え方は「システム開発・刷新のためのデータモデル大全」にないがあえてやってみた。

業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索

(前略)
* resourceとresourceをつなぐ場合：対照表を生成する。対照表はeventである。
　（例）従業員と営業所
　　　　　従業員-営業所の対照表を作成し、リレーションシップを保全する。
* resourceとeventをつなぐ場合：event側に参照キーを持たせる。
　（例）顧客と注文
　　　　　注文entityに顧客コードを持たせる。
* eventとeventをつなぐ場合
** 「１：１」「１：ｍ」：時系列の遅い方に持たせる。
　（例）受注と請求（一つの受注に対し請求は一つ）
　　　　　請求に受注番号を持たせる。
** 「ｍ：１」「ｍ：ｍ」：対応表を生成する。
　（例）受注と請求（複数の受注に対し請求は一つ）
　　　　　受注-請求の対応表を生成し、リレーションシップを保全する。
(後略)

その結果、イベントに先行後続が順序付けられて、業務フローが見えてきて、付随するリソース系のイメージも湧いてきた。
そこから色々感じたこと、気になったことをメモしておく。

【2】リソース系テーブルのフィーチャオプションモデル

「システム開発・刷新のためのデータモデル大全」では、製造業のモデルだけでなく、サービスやその他のモデルでもリソース系テーブルのフィーチャオプションモデルがよく出てくる。
なぜ頻出されるのか？

たとえば、製品や商品の属性をテーブルで保持しようとすると、横持ちでカラムが多くなる。
サイズ、色、重量などいろんな属性があるし、新製品によってさらに属性も新規追加されやすい。
横持ちのテーブルでは品種が多くなると破綻する。
そこで、品種という属性群を別テーブルで保持し、縦持ちでデータを持たせて、新規追加できるようにする。
つまり、製品や商品の属性データを横持ちから縦持ちにもたせて、汎用化している。
その分、マスタテーブル設計は複雑になるが、理解さえできれば応用が効きやすい。

フィーチャオプションはマスタ管理を整理するためのテクニックと思う。

【3】強属性のキーはサロゲートキーの代わり

複合主キーのマスタは、サロゲートキーにすると扱いやすくなる。
しかし、関数従属性がサロゲートキーのために分かりにくくなる。
そこで、サロゲートキーに置き換えられた複合主キーに当たるカラムを一度追加更新されたら更新できない制約をかける。
「システム開発・刷新のためのデータモデル大全」では、この制約を強属性と呼んでいた。
複雑な商品マスタをサロゲートキーで主キーにした時、品種区分とFO項番が主キーのようになるが、「システム開発・刷新のためのデータモデル大全」の例では、品種区分を強属性としている。

強属性を使うことでマスタテーブルの関数従属性を表し、データの不整合が出ない仕組みにしている。

【4】親子頻出アンチパターン

データモデリング初心者はテーブル同士を関連付けようとする時、主キーの親子関係だけで表現しようとする。
特にトランザクション系のテーブルで多い。
注文と注文明細みたいに。
たぶんそういう関係付けの方がイメージしやすいからだろう。
そういうアンチパターンは、親子頻出アンチパターンと言われている。

しかし、本来は外部キーを使って、トランザクション系のテーブルに先行後続を関連付けるべきだ。
その場合、先行後続では多重度が異なる。

先行後続が１対多ならば、先行イベントテーブルの主キーが後続イベントテーブルの外部キーとして設定される。
一方、先行後続が多対１や多対多ならば、先行イベントテーブルと後続イベントテーブルの間に、連関テーブルが入り込んで２つのテーブルを１対多で関連付ける。
たとえば、出荷したデータをまとめて一括請求する場合などがあげられるだろう。

データモデルではイベント系テーブルを抽出した後、多重度から先行後続を読み取り、そこから業務フローを組み立てると一連の流れが見えてくると思う。

【5】時限NULL、永続NULLデータの考え方

イベント系テーブルでは、カラムの初期値はNULLだが、後続の業務が実行されてデータが更新されるタイミングで、NULLから値がセットされる。
「システム開発・刷新のためのデータモデル大全」では、このようなデータを時限NULLデータと呼んでいる。
たとえば、後続イベントテーブルにある先行イベントテーブルの主キーを外部キーとして張っている場合がそうだろう。

データモデルではNULL値はできるだけ避けるべきだが、一時的にNULLの状態であって、データ更新のタイミングで値が更新されるならそれで良しという考え方になる。
「システム開発・刷新のためのデータモデル大全」では、発注と入荷のデータモデルで入荷コードが時限NULLとして使われる例があって分かりやすい。

一方、マスタテーブルでは一つのマスタに属性を増やしていくと、カラムの初期値がNULLのまま永遠にセットされる場合がある。
このような例が永続NULLデータになる。
「システム開発・刷新のためのデータモデル大全」では、永続NULLデータが存在する場合、サブタイプに分割すると良い。
つまり、テーブルの継承関係を使って、親テーブルのマスタに共通するカラムをまとめ、子テーブルのマスタにそれぞれの属性を集めたデータをまとめる。
顧客や取引先、仕入先などをまとめたテーブルを作りたい場合が相当するだろう。

【6】2次キー（2次識別子）の使い道

「システム開発・刷新のためのデータモデル大全」では、2次キーが有効に使われるデータモデリングの例が多い。

たとえば、在庫推移監視モデルでは、受払テーブルが受払予定テーブルと受払履歴テーブルをサブタイプに持たせるが、それぞれの主キーは異なるので、そのままでは継承関係をデータモデルで表現できない。
そこで、受払・受払予定、受払履歴テーブルに2次キーを持たせて、継承関係を表現する。
2次キーはいわゆるAlternative Keyであり、一意なキーだから、検索時にも使える。

他にも、売上履歴に出荷明細、回収明細、一般取引明細の各テーブルを関連付けて、売上の履歴を一元的に管理していつでも検索できるようにするには、それぞれの主キーは異なるので、2次キーを持たせる。

一般に2次キーは、JANコードやマイナンバーのようにマスタテーブルでよく出るが、トランザクションテーブルに使うと効果的に扱える場合が割とあるように思える。

【7】負荷計画のモデルは2種類ある

「システム開発・刷新のためのデータモデル大全」では、業務知識を埋め込んだデータモデルがふんだんに盛り込まれているので、データモデルを読み解いていくと、この関数従属性にはこういう業務ルールを埋め込んでいたのか、と気づく時が多い。
宝物探しの感覚に似ている。

「システム開発・刷新のためのデータモデル大全」にあるデータモデルで興味深かった例は、負荷計画のモデルだ。
製造業では、工場の機械がリソース制約になり、工場の稼働率を決めて最終的には原価につながる。
そこで、設備の制約に関するスケジューリング決定について、TOCのアイデアを入れて、工程の日程を決める。

負荷計画を立てるときに、リソースの制約がスケジューリングに最も関わるので、制約になるリソースは何があるか、という問いに置き換えられる。
制約になるリソースは、製造業の工場なら設備だが、病院の看護スケジュールなら、専門技術を持つ人員になる。
ソフトウェア開発のスケジュールでも、インフラ環境の設備もあるだろうが、専門技術を持つ開発者が最も大きな制約になるだろう。
つまり、要員シフト管理では、専門技術を持つ人員が制約になる。
制約となるリソースが業態やビジネスによって大きく異なる点が面白い。

また、負荷計画では受注生産の工場、病院の看護師なら、受注済みの製品または予約済みの患者という需要に対し、「需要を設備の稼働を確保する」考え方になる。
一方、航空機運輸業の予約搭乗管理では、飛行機を既に持っており、その飛行機の座席をいかに予約で埋めていくか、になる。
つまり、「設備の稼働ありきで需要を確保する」ことになる。
他にも、新幹線や特急の予約もこの考え方になるだろう。

では、データモデルにはどのような違いが出てくるのか。
受注生産の工場、病院の看護師の負荷計画では、予定→製造指示のようにイベントテーブルは1対多の関係になる。
「需要を設備の稼働を確保する」データモデルでは、需要という予定をいかに設備で捌くか、という考え方になるので、予定→負荷を割り当てた計画スケジュールのように、先行後続のイベントテーブルが1対多になる場合が多い。

一方、飛行機のフライト管理では、フライト日程→フライト日程明細--予約搭乗明細→予約搭乗というイベント系テーブルで関連付けたデータモデルになっている。
つまり、先行後続のイベントテーブルが多対多の関係になっている
「フライト日程明細--予約搭乗明細」の関係は、それぞれの主キーが異なるのでそのままでは関連付けられないが、フライト日程明細テーブルの主キーを2次キーとして予約搭乗明細テーブルに持たせて、関連付けるモデルにしている。
これにより、フライト日程を決めたら、フライト日程の飛行機の座席に予約を割り当てて管理するという業務フローが成り立つことになる。

さらに、フライト日程明細テーブルの主キーを予約搭乗明細テーブルの2次キーに設定しているので、2次キーはNULLも設定できる。
NULLが設定される例として、座席指定できていないデータ、キャンセル待ちや搭乗者にカウントされない乳幼児があげられていて、そこまで業務ルールとして埋め込んでいるのか、と気付いて面白かった。

他のデータモデルでも、関数従属性に業務ルールが巧妙に埋め込まれているので、この辺りを読み解くと面白いと思う。

Redmineのバージョン設定でプロジェクトの設定方法が違う

Redmineのバージョン設定では、プロジェクトの設定方法が、サブプロジェクト単位、プロジェクト階層単位、プロジェクトツリー単位、全プロジェクトで4つある。
設定内容の違いにいつも迷ってしまうが、redmine.jpで詳細な解説があった。

プロジェクトの設定＞バージョン - Redmineガイド

（引用開始）
共有: バージョンをほかのプロジェクトと共有します。共有すると、ほかのプロジェクトのチケットも割り当てることができるようになります。設定可能な共有範囲は次の通りです:

サブプロジェクト単位: 子孫プロジェクト

プロジェクト階層単位: 直系の先祖・子孫プロジェクト (最上位の親プロジェクトにおいて「バージョンの管理」権限が必要)

プロジェクトツリー単位: 最上位の親プロジェクトとすべての子孫プロジェクト (最上位の親プロジェクトにおいて「バージョンの管理」権限が必要)

全プロジェクト (システム管理者のみが設定可能)
（引用終了）

あるプロジェクトで設定したバージョンを、他のプロジェクトのどこまでの範囲まで設定できるか、を細かく設定できる。
プロジェクトはツリー構造に設定できるので、子孫だけなのか、親や先祖も含むのか、先祖が同じプロジェクトまで含むのか、を考慮する必要がある。

バージョン設定範囲を細かく設定したいケースは、バージョンを複数プロジェクトで使い回したいケースになるだろう。

ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン

第26回redmine.tokyo勉強会で、ウクライナのRedmine開発者が作ったRedmineテーマやプラグインを解説した動画を紹介した。
改めてリンクしておく。

第26回勉強会 - redmine.tokyo

Redmineのテーマはタブレットやスマホを意識して作られたらしい。
プラグインも痒いところに手が届くような機能を提供している。

第26回redmine.tokyo勉強会の感想～多様性はコミュニティが成功する重要な要因の一つ #redmineT

第26回redmine.tokyo勉強会にスタッフとして参加してきた。
久しぶりに常連や新しく知り合った人たちと話して気づいたのは、多様な属性の人達が集まり多様なテーマで議論するのがコミュニティの醍醐味ではないか、と思った。
ラフな感想をメモ書き。

【参考】
第26回勉強会 - redmine.tokyo

2024/6/15 第26回勉強会 - redmine.tokyo #redmineT - Togetter [トゥギャッター]

プリザンター｜OSSのノーコード・ローコード開発ツール

【1】勉強会の場所は、OSSツールPleasanterを運営しているインプリム様の会場を借りて開催した。
映像、音響も非常に良く、そのまま懇親会の会場で、宅配のピザ、缶ビールやジュースの買い込みもできて、バーのカウンターもあって盛り上がった。
インプリム様には快く会場を提供して頂き、非常に感謝いたします。

今回の勉強会で気づいた内容をメモしておく。

【2】OSSツールPleasanterは、C#で作られたノーコード・ローコードツール。
前回の勉強会で、Redmineと連携してチケット作成などの機能をデモされた。
個人的には、こういうノーコード・ローコードツールは日本人に向いていると思う。
理由は2つある。

1つ目は、データベース設計さえきちんと設計できれば、画面や帳票はプログラムレスで初心者でも開発できること。
つまり、いわゆるノーコードツールはデータベース設計が肝。

データの格納場所は後で安易に変更しづらいし、テーブルに依存した画面設計になるので、テーブル設計がぐちゃぐちゃだと画面そのものも使いづらくなる。
テーブル設計に業務フローやビジネスルールの制約条件を反映するように設計すれば、無駄なロジックを実装する手間も減るし、画面開発も楽になる。

幸いなことに、データベースモデリングの技術は枯れているし、渡辺幸三さんなどの本で優れたノウハウはあるので活用するだけでいい。

2つ目は、日本人は現場で生産性向上のためにプロセス改善、業務改善するやり方に非常に強いから。
以前のメーカーのQCサークルもそうだろうし、Redmineがこれだけ日本各地で使われているのは現場で気軽に使って業務改善するやり方が日本人の気性に向いているから。
よって、ノーコード・ローコードツールのように、業務改善に気軽に使える道具は日本人の気性に非常にマッチすると思う。

たぶん、戦略的にトップダウンで設計や標準化するよりも、現場で改善する方が日本人に向いているように経験的に感じる。
それが日本人の良い点でもあるし、日本人の弱点であるのかもしれない。

【3】@g_maedaさんの講演では、Redmine本の出版に合わせて20年近いRedmineの歴史を振り返っていた。
気になった点は、Redmineの弱点と、その裏返しとなるメリットの観点だ。

特に直近5年ほどは、Redmine本体の機能も枯れてきており、ドラスティックな機能追加はほとんどない。
つまり、Redmineは安定してしたツールであり、一方、少しずつ時代に遅れつつある面も否めないと思う。
backlogやJira、Asanaなどのツールに比べると、機能改善の速度はやはり違う。
その理由はいくつかあるだろう。

JPLを含む少人数の開発体制が変わっていないこと、UI/UXではシングルページアプリケーションのままで画面遷移や画面更新に手間がかかりやすいこと。
チケットトラッキング機能以外に大きな機能追加が行われていないこと。

アジャイルウェアさんも同様の問題意識を持っており、RedmineのUIや機能をドラスティックに変えにくいので自分たちでRedmineクローンを公開し、Redmine本家にバックポートしていく戦略を話されていた。
ウクライナ人開発者のRomanさんも、RedmineのUIを昨今のスマホ・タブレットを意識したテーマに変更してアピールしていた。

一方、LTでも懇親会でも議論されていたが、Redmineの古いUI/UXが逆にユーザに安心感があるメリットもある、と言う。
RedmineのUIは古いと言われるが、逆に15年近くほとんど変わっておらず、使い慣れている。
JiraのようにいきなりUIが変更されるとユーザも混乱しやすい。

Redmineはシングルページアプリケーションでないけれど、画面更新や画面遷移に必要な機能は分かりやすいし、操作に慣れると、勝手に変更される方が戸惑いやすい。
たとえば、汎用機やクラサバの頃のUIのように、画面にたくさんのボタンやテキストが左から順に並んでいて、キータッチで入力する方がやりやすい、と。

すなわち、RedmineのUIが古いと言われるデメリットは、換言すればUIが変更されておらず一貫性があるので、日本人の気性ではメリットの一つでもある。
そういう観点があると知ったのは面白かった。

【4】今日の勉強会で面白かった点は、Redmineという一つのツールで数多くのテーマで議論できる内容があることだ。
今日の講演では少なくとも5つの観点の事例があった。
情シス、プロジェクト管理、ITIL、性能チューニングによるインフラ運用、プラグイン開発やテーマ開発などのようなRuby開発の観点だ。

【4-1】@netazoneさんの講演では、メーカーの情報システム部門の立場から、人事・総務・営業などのバックエンドの業務をチケット化することで、タスク管理の漏れをなくし、作業の経験や反省点を次回の作業に改善するようにナレッジ化していた。
つまり、会社のバックエンド業務を一括管理してナレッジ化するために、情報システム部門がRedmineを効率的に利用して業務改善している事例だった。

【4-2】@madowindowさんのディスカッションでは、プロマネやPMOの立場から、WBSの管理や策定方法、プロジェクト運営でリスクを感じる兆候の管理、たとえば、進捗90％症候群、頑張ります発言などを話されていた。
つまり、RedmineをSIerのプロジェクト管理に適用するやり方になる。

また、@ta_ke_chan_ さんのLTでは、工場での工数管理にRedmineを利用されていた。
つまり、プロジェクト管理のうち、労務管理やコスト管理、原価管理に適用した事例になる。

【4-3】岩崎さんの会社のRedmineプラグインの話は、ITILの観点で、障害チケットをツールが自動起票して漏れなく一括管理し、電話応答する機能まで実装されていた。
つまり、ITILのようなサービス運用やヘルプデスク管理の観点で、Redmineを効率的に利用して業務改善する事例だった。

【4-4】@akahaneさんの事例では、島津製作所の計測機器に関する事業部でRedmineを全面展開し、Redmine単体1つだけで日々の業務を全て管理されている。
その時に、約３千ユーザ、数十万チケットをRedmineでスムーズに運用するために、RubyのJITコンパイラによる高速化、アプリサーバやDBMSなどの性能チューニングを施して、Redmineがバージョンアップしても高速化を実現していた。

この講演の肝は、Redmineにプラグインを入れないだけでなく、Redmine本体には一切手を入れず、Redmineの外側のインフラ基盤だけで性能チューニングを図ることで、高速化を実現していることだ。
つまり、Redmineに関する知識だけでなく、ApacheやDBMS、VM、通信帯域などのインフラ基盤の技術も必要であることを示唆している。
こういう高度なインフラ基盤の知識が必要な理由は、システム計監査やBCP対策で非常に厳しいビジネス要求に対応する必要があったからだ。
RubyやRailsの開発経験だけでなく、インフラ基盤の経験も相当必要なので、かなり高度な運用内容になっている。

【4-5】ウクライナ人のRedmine開発者Romanさんの事例では、自社で開発されているRedmineテーマやプラグインを紹介されていた。
彼のLinkedInのプロフィールを見ると、開発者の経験が豊富であり、Redmineについてかなり知識を持っているのだろうと思う。
また、@mattaniさんの事例では、Gemの依存性に関する知見の話だった。
彼らの講演は、RubyやRails開発などのテーマに属する。

【5】以上のように、たった半日の勉強会に過ぎないのに、Redmineに関するテーマとして全く別々の５つの内容が議論されていた。
どれか１つのテーマなら詳しい人は参加者でも多数いると思うが、これら５つのテーマを全て理解している人は、今日の参加者では非常に少ないのではないだろうか。

だからこそ、他の人の事例を聞くことで、自分たちが経験していない事例を聞いて参考にできて、盛り上がる要素の一つになったのではないか、と思う。

Redmineというたった一つのOSSツールに過ぎないのに、多様なテーマが存在しているということは、Redmineはまだまだ今後も発展できる余地がたくさん残されているのだろうと思う。

【6】最後にウクライナ人開発者のRomanさんのショート動画を紹介させてもらった。

Romanさんを知ったきっかけは、LinkedInで彼から僕に問い合わせがあり、LycheeやRedmica、hosting Redmineをやっている企業とコンタクトを取って日本市場に出たい、とのことだった。
Romanさんは自分の会社でRedmineテーマやプラグインを自社開発しており、それを日本市場で販売したい、そのために手を組める日本企業を探していたようだった。
僕は、@_maedaさんと川端さんを紹介した時に、redmine.tokyoで動画で紹介してはどうかと提案したら、彼が快諾してくて、この企画が実現した。

実際は、彼の動画が届くのは勉強会の１週間前でかなり直前になった。
彼から、5月末からウクライナでは電気が不安定で、動画を作るのに時間がかかってしまって申し訳ないと話された。
その話を聞いたとき、ニュースでちょうど、戦争で発電所などのインフラ設備にミサイル攻撃などがあって大変な時期だった、という話を思い出した。
彼の環境は、非常に大変だけれど、そんな中で、オープンソースのツールRedmineに関わって開発に取り組んでいる。
僕らとは違う環境でRedmineという共通のツールに興味を持っている彼に何となく共感したい気持ちがあった。
僕自身ができること、貢献できることは分からないけれど、コミュニティで共有することで何か連帯できればいいなと思っている。

【7】今日の勉強会では、常連だけでなく、新しく知り合った人たちとたくさん話ができた。
常連だけが盛り上がるのではなく、新しく参加した人たちとオフラインの場で一緒に経験を共有することで、より一層結束も強くなる。

Pleasanterの人たちも、こういうユーザコミュニティを作りたいんですよ、と言っていた。
Pleasanterはノーコードツールなので、パートナーと呼ばれる開発者兼利用者と強い関係がある。
それをベースにビジネス展開できている。
しかし、今のPleasanterコミュニティはビジネス色が強いと思われてしまうデメリットを感じている。
だからこそ、利用者自身がコミュニティを立ち上げて盛り上げてくれるやり方を模索している、と。
そんな話を聞きながら、思ったことは２つある。

１つ目は、Redmineコミュニティが長続きしているのは、熱狂的な利用ユーザがいて、Redmineコミッタやプラグイン開発者、Redmineプラグインやサービスを提供するベンダーの間で、活発な互恵関係があることだろう。
利用ユーザが困った問題があれば、利用ユーザはコミッタに聞いたり、Ruby開発者にプラグインの要望を出したり、有償プラグインではこんな機能がほしいなどを投げかけて、問題解決のメリットを得る。
一方、コミッタやプラグイン開発者、Redmineベンダーは、利用ユーザのニーズを直接聞きだすことができ、それをRedmine本体やプラグインの改善に役立てられるし、有償プラグインや有償サービスによりビジネス化できるメリットを得る。
そういうお互いにWin-Winの関係が成り立っているからだろう。

それは意図して作られた関係ではない。
最初は、利用ユーザがコミッタに声をかけよう、プラグイン開発者に来てもらおう、ベンダーにも来てもらおう、という程度から始まった。
そこから、数多くのやり取りを経て、お互いに信頼関係を築くことができて、あの人なら失礼な行為や不利益な行為はしないだろうという安心感が作れている。
そういう長期的な信頼関係が作れたからこそ、コミュニティが長持ちしているのだろう。

もう一つは、Redmineに関するテーマが多様であることだ。
そして、Redmineの利用ユーザや開発者も日本各地にいて多様性があることだ。
今日の勉強会でも、北海道、京都、大阪、福岡から参加者がいた。
さらにウクライナの開発者も動画を送ってくれた。
多様な属性を持つユーザが集まることで、予期しない化学反応が起きて、より熱狂的になれる。
熱狂的な楽しい経験を一緒に共有し、それを何度も続けていくこで、信頼関係を築いていく。
信頼関係がコミュニティを支えてくれる。
そういう体験がコミュニティ運営の醍醐味だろうと思う。

また、僕がブログにRedmineのアイデアをたくさん書き散らした記事について、すごく参考になったと話してくれた人もいて、非常に励みになった。
その人曰く、Redmineでこんな使い方もできる、あんな使い方もできる、という記事がたくさんあって皆読んでいるから、勉強会で盛り上がるのではないか、と話してくれた。
僕自身は強いミッションや使命感もなく、ただアイデアを書き残して公開しないとなかなか寝れなかったというだけだったのだが、そういう人がいてくれて非常に勇気づけられた。

僕自身は、OSSツールのチケット管理ツールRedmineとモデリングツールastahの２つにこだわりを持っている。
この２つのツールを使ったテーマは今後も考えていきたいと思う。

「システムアーキテクチャ構築の原理」の感想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つ」とは、「ステークホルダー」「ビューポイント」「パースペクティブ」と最初に書かれている。

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

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