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

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

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

「スクラムの拡張による組織づくり」のScrum@Scaleの感想

「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」をざっくり読んだ。
ラフな感想をメモ。

【参考】
大規模スクラムはLeSSとSAFeのどちらが良いのか: プログラマの思索

SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説: プログラマの思索

プロダクトマネジメントの感想～プロダクトオーナーはもっとチームの外のユーザに寄り添うべき: プログラマの思索

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

スクラムは境界を生み出す: プログラマの思索

文化は組織構造に従う: プログラマの思索

More Effective Agileは良い本だ: プログラマの思索

【1】Scrum@Scaleというアジャイル開発の大規模開発プロセスがどんな内容であるのか、に興味があった。
詳細は「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」に書かれているのであえて記載する必要はないと思う。

むしろ、既存のLeSSやSAFeと比較して何が異なるのか、が重要だろうと思う。

LeSSは1人のプロダクトオーナー、1つのプロダクトバックログから成るので、1個の製品を複数チームで開発するスタイルみたいなイメージを持っている。
たぶん、この形のスクラムが一番スケールしやすいと思う。
一方、プロダクトオーナーに負荷がかかりやすい弱点があるから、エリアプロダクトオーナーを設けたり、プロダクトオーナーを支援する人やチームを別途作るケースが多いように思う。

SAFeはアジャイル開発の官僚的組織、官僚的プロセスに近いイメージを持っている。
3つのレベルを持ち、開発チーム、リーダー層、経営層でそれぞれ役割分担したアジャイル開発を進めるイメージ。
大規模なシステム開発では、組織やプロセスを整備する必要があるから、SAFeのような仕組みは必要になるだろうと思う。
一方、RUPのようにテーラリングが必要なので、戦略的にカスタマイズを実施しないと難しいだろうと思う。

Scrum@Scaleは、スクラムチームのスケールだけでなく、プロダクトオーナーもスケールも実現する。
つまり、最低限の官僚的組織は持つが、開発チームだけでなくプロダクトオーナーも複数あり、協調動作するスクラムチームごとにプロダクトバックログを持つから、複数のプロダクトバックログを扱うように動く。
この点が他の大規模スクラムと違って、より柔軟な仕組みを持っているように思った。
EATやSoSのような組織を見ると、複数の開発チームやプロダクトオーナーが協調動作するように役割分担しているのに気づく。
レポートラインも最低限の官僚的組織としてうまく整備されている印象を持った。

【2】チャットサービスの開発現場で組織構造が変遷される内容がとても興味深い。
ChatWorkの開発現場だと思うが、最初はUI/UXのチームが重視され、途中で統合認証のような共通基盤の開発チームが入ってきて、最後は統合認証基盤チームは退出し、データマイグレーションなどのTeamsだけが残る。
つまり、チャットツールのビジネス発展に応じて、開発する機能が変わるので、それに応じた開発組織が必要になる。
そうした開発チームはチャットツールという製品の開発フェーズに応じて、新規に入ったり、退出したりして入れ替わる。
そういう組織の入れ替えを意識的に行っているのが味噌と思う。

また、こういう組織の入れ替えは、逆コンウェイ戦略の良い事例になっている。
なぜならば、製品の開発フェーズに応じて、重視される機能やアーキテクチャが変わるので、それに応じた組織を当てはめるべきであり、そういう組織を入れ替えるべきだ、という考え方になるからだ。

では、一般のユーザ企業の基幹系システム開発でも、こういうやり方は通用するだろうか？
たとえば、基幹系システム開発でも、機能追加やリプレース、法規制対応などにより、システムのフェーズは変わる。
基幹系システム開発でアジャイル開発を実践できているならば、Scrum@Scaleのような大規模開発も取り入れることはできるだろう。
つまり、基幹系システムのフェーズごとに開発チームを入れ替えて、逆コンウェイ戦略を実現することは不可能ではない。

しかし、一般の基幹系システム開発では、WF型開発が主流であり、アーキテクチャもインフラ層、データベース層、アプリ層などのように分割されて、それに応じた開発チームから成り立つ組織が多いと思う。
だから、Scrum@Scaleのように開発チームを頻繁に入れ替えるような逆コンウェイ戦略を実現するのは難しい状況が多いのではないか。

また、基幹系システム開発でスクラムを実践できていても、複数のプロダクトバックログを協調動作するように運用するのは、マネジメント上やはり難易度が高いと思う。

【3】「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」は日本の現場の事例もあって良い本と思う。
LeSSやSAFeとの違いについてはもう少し考えてみたいと思う。

LeSSは「大規模スクラム Large-Scale Scrum」の本がお勧め。
SAFeは「SAFe 4.5のエッセンス」の本がお勧め。

「More Effective Agile ソフトウェアリーダーになるための28の道標」では、SAFeが推奨されていたので参考にしている。

ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる

ソフトウェア工学の根本問題は何なのだろうか？
僕は、ソフトウェアをいかに部品化して疎結合な構造とし、お互いの相互作用でいかに協調動作する仕組みを作るか、だと思う。
以下、直感的な思考を書き記しておく。

ソフトウェアの歴史をたどれば、構造化プログラミングからオブジェクト指向プログラミングへ発展した経緯を見ると、ソフトウェアの構造とソフトウェアを開発する仕組みをいかに透明化し、コントロールしやすくするか、に力点をおいているように思える。

@sakaba37さんから言われてはっと気づいたことは、ソフトウェアは密結合になりやすいこと。
トランザクションスクリプトのように、ちょっとしたロジックの処理を何も考えずに実装すると、密結合なプログラムになり、スパゲッティになりやすい。

そして、ソフトウェアを開発するプロセスも、ソフトウェアを開発する組織も、ソフトウェア構造を反映してしまうために、密結合なプロセス、密結合な組織になりやすい。

今、クラウドを基盤としたマイクロサービス設計が色々試されている。
マイクロサービス設計では、処理層とデータ層をまとめた一つのサービスを独立した単位とし、それらを協調動作する仕組みを作ろうとする。

しかし、今までのソフトウェアの歴史から類推すると、いかにソフトウェアを疎結合な構造にするか、いかにソフトウェアを管理するプロセスを透明化しコントロールしやすくするか、という根本問題から離れられていないように思える。

実際、マイクロサービスが独立した単位であっても、複数のサービスが協調動作させる仕組みをいかに安定して作るか、API設計や補償トランザクションなど、色々試行錯誤している。
「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」を読めば、マイクロサービスをいかに安定して設計するか、を試行錯誤していることが分かる。

また、全てのマイクロサービスを横断して管理する仕組みとしてサービスメッシュという概念が導入されているが、それもサービスの耐障害性や可用性を担保するための監視サービス群のようなものだ。
ちょうど、Ciscoのネットワーク機器からなるネットワーク構造をSDN化したときに、データ層とコントロール層に分けて、APIを使ってコントロールしようとする仕組みと同じように思える。

他方、ソフトウェア開発の組織も今はスクラムをベースとしたアイデアに基づき、少人数のスクラムチームで開発するのが、特にマイクロサービス開発では相性がいい。
マイクロサービスでは、データ層も処理層も持つので、開発チームが必要なソフトウェア部品を全てコントロールできるからだ。
また、マイクロサービス同士のやり取りは、スクラムチームが協調動作する仕組みに置き換えられる。
実際、スクラムチームでは、プロダクトバックログというインプットとインクリメントとして付加価値を順次リリースするアウトプットが契約になるが、その中のプロセスは部外者は口出しできない。

つまり、スクラムチームは、まるで1つのソフトウェア部品のように中身はブラックボックス化されており、インプットとアウトプットというインターフェイスが保証されている仕組みと思っていい。
すなわち、スクラムチームという開発組織も、疎結合なソフトウェア部品と同様にみなせる。

そんなことを考えると、僕はクラウドやマイクロサービス設計の経験がないけれど、今までのソフトウェア開発の歴史を踏まえた根本問題から、マイクロサービス設計やその開発プロセスでは、過去の根本問題をどのように解決しようとしているのか、という観点で考えていた。
そして、その考え方から類推されるボトルネックは、昔の技術から現代のアーキテクチャに変わったとしても、症状として現れる事象が変わっただけであって、その本質は変わっていないはずだと思っている。

「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみを読んだ。

【0】リモートワーク主体の組織運営をどうやってやるか、PDCAで整理した本と思う。
とは言っても、リモートワーク普及に奇策はない。

【1】Planでは、ガイドラインを定めて形式知化する。
リモート責任者など組織体制も整備する。
経営層が率先してリモートで働く。
利用するツールは絞り込む。

他にもいくつか施策はあるが、割りと形式知化を重視している点が印象に残った。
リモートだからこそ、対面でのやり取りがないので、どうしてもローコンテキストな対話にならざるを得ないだろうから。

コミュニケーションルールも定める。
非公開情報ではSAFEアプローチを取る。
Sensitiveなのか、Accurateなのか、Financialなのか、Effectなのか、の判断基準を定めて、情報を公開しても良いのか判断する。

【2】Doでは、従業員の動機づけ要因、衛生要因を整備する。
リモートに合った組織文化が根付くように実行する。
心理的安全性を重視する。
人材戦略、つまり従業員の動機づけ要因では、ダイバーシティ、インクルージョン、ビロンギングを重視する。

ダイバーシティは、人種や性別、年齢、宗教、性的指向などの多様性を認めること。
インクルージョンは、マイノリティもマジョリティもすべての従業員が活躍できる状態を目指すこと。
ビロンギングは、自分の居場所はここである、という感覚。
帰属意識みたいなものかな。
一昔前の日本の会社の愛社精神みたいなもの。
今風ならエンゲージメントかな。

面白い点は、ビロンギングを重視していること。
従業員の流動性が高くても、帰属意識を重視しているのはなぜか。
たぶん、マズローの欲求5段解説で考えれば、帰属欲求が満たさなければ、承認欲求や自己実現を満たす欲求に達しないからだろう。

他にも、イテレーション、透明性も重視している。
この辺りはアジャイル開発の文化に近いので理解しやすい。

コンディショニングを実現する章は衛生要因の話だろう。
長期休暇制度、人間関係の構築、運動の推奨。

【3】CheckとActoinでは、KPIを用いた評価制度を作り、イテレーションごとにフィードバックを回していく。

SMARTな目標を定めて成果を評価する。
GitLabで活躍できる能力や意欲があるのに、マネジメントの問題で活かしきれない状況を避けるために支援する。
マネージャはメンバーを支援する。

優れたマネージャのコンピテンシーは事前に把握しておく。
感情的知性（EQ）、コーチング、衝突の解決、フィードバック文化の体現、高業績チームの構築。

Actionでは、メンバーに精神的成長と技術的成長を促す。
技術的成長を促すには、現状のスキルレベルと目指すスキルレベルの可視化が不可欠。
しかし、日本企業はスキルマップが画一的だったりそもそもなかったり、メンバーのスキル保有を把握していない。

能力開発のプロセスでは、コルブの経験学習モデルが有効。
具体的経験→内省的観察→抽象的概念化→積極的実践のサイクルを回して、能力を高めていく。
日本と海外の差は、抽象的概念化と積極的実践の部分だろう。

抽象的概念化では、普通の業務では既に他の人や過去の人が既に実践しているから、ノウハウや問題解決の手順は既に知られている。
しかし日本ではわりと形式知化されていないので、一人で暗中模索して試行錯誤しながら解決策を導く手間がかかる。
海外では形式知化されたマニュアルや書籍、トレーニングが充実しており、それらを通じて先人が得た整理された知識まで早期に到達することができる。

積極的実践では、せっかく研修したのに、研修に対して意味がないと感じたりネガティブな印象を持ったりする。
座学の場合は特にそうだろう。
だから、研修を実務に適用し、研修転移を進めるために、マネージャや周囲が定期的にコミットメントしたりフィードバックするのが大事になる。
GitLabでは、個人開発計画を作成し、メンバーのキャリア開発について議論しているという。

【4】そんな話を読むと、GitLabではリモートワークを単に活用しているだけでなく、包括的にメンバーの意識付けからスキルアップまで組織的に考えていることが分かる。
おそらく長年の試行錯誤を経て、3000ページにのぼるGitLabのガイドラインにまとめられたのだろう。

また、この本では、既に知られているビジネスやマネジメントのフレームワークがふんだんに使われていて、情報が整理されて理解しやすいと感じた。

概念モデリングや設計原則は進化しているのか

最近、概念モデリングや設計原則の勉強会に参加して色々気づきがあった。
ラフなメモ書き。

【1】「実践UML第3版」を勉強会で読み始めた。
僕は「実践UML第1版」を購入して読んでいた。
思い出せば20年前になるのか。
そこから第2版も買ったし、最近第3版も買ってみた。
中身は変わってきているが、版を重ねるごとにオブジェクト指向設計の内容が洗練されて、RUPという開発プロセスに準じるように設計から実装、移行まで一気通貫する。

2020年代の現在、「実践UML」を再度読んで気づきがいくつかある。

【2】1つ目は、RUPはもう不要と思う。
スパイラル開発プロセスはWF型開発からの脱却という観点で重要だったが、Scrumを中心としたアジャイル開発が全盛の時代だから、わざわざテーラリングが必要な重厚長大なRUPを利用するメリットはないと思う。

【3】2つ目は、モデリングに必要なUMLのダイアグラムの力点が変わっていること。
「実践UML第1版」では、以前は協調図(コラボレーション図)、今のコミュニケーション図がオブジェクト指向設計で重要です、と主張していた。
理由は、コラボレーション図を描くことで、機能をどのクラスに割り当てるべきか、凝集度や結合度、生成などの観点で検討する時に有用だから。
オブジェクトからたくさんの指示が出ていれば責務が多すぎるね、と気づきやすいから、と。
当時の自分はすごく納得した。

実践UML第2版、実践UML第3版では、クラス図やシーケンス図で説明する場面が多い。
コラボレーション図の話はなくなっていた。
たぶん、UMLの中でも重要度が下がったためだろう。

しかし、機能の割り当ての考え方は普遍的と思う。

【4】3つ目は、GRASPパターンは「情報エキスパート」パターンが一番大事ということ。
このパターンが「実践UML」の重要ポイント。

機能や責務はどのクラスに割り当てるべきか？
責務の遂行に必要な情報を持っているクラス、すなわち情報エキスパートに責務を割り当てるべきだ。

つまり、責務の遂行に必要な情報を自身のクラスの属性、関連先のクラスから取得した情報を自身のクラスで持ってること。
そして、処理を実行する時に、他クラスへメッセージを投げ出せること。

コミュニケーション図なら、情報エキスパートとなるクラスからメッセージという矢印が出ているだろう。
シーケンス図なら、情報エキスパートとなるクラスからメッセージが出て、他のクラスに処理が委譲されて、階段状の図になっているだろう。

その他のパターンも8つくらいあげられているが、そこまで重要ではないように思う。
生成、疎結合、高凝集度、多相性、コントローラは読めば分かる。
バリエーション防護壁はFacadeやAdapterみたいなもの。
純粋加工物、あるいは人工品は、機能の関連だけで構成するのではなく、ソフトウェアのプログラムの都合上、論理的なオブジェクトをワンクッション挟むようなもの。

【5】4つ目は、概念モデリングとデータモデリングは似ているようでやはり異なることだ。

「実践UML」では、概念モデリングでの注意点がいくつかある。

【6】属性とクラスは区別する。
一般に、ある概念をクラスの属性にするか、クラスで独立させるか、識別は間違いやすい。
「実践UML」の指針では、ある概念Xが現実世界では数値でもテキストでもなければ、Xは概念クラスであり、クラスの属性ではない、と言い切っている。

これは重要と思う。
初心者だった頃、どれをクラスにすべきか迷ってしまう時が多かった。
迷って、概念をクラスの属性にしてしまいがちな時が多い。

例えば、Destination、AirportはFlightに含めるべきか。
それぞれクラスとして独立させて、関連で結ぶべき。

実際は、1つの概念はクラスのロール名としていろんな別名として現れる。
例えば、企業クラスは顧客だったり仕入先だったり、取引先だったり、もしかしたらグループ内企業だったりする。
つまり、企業クラスはいろんなロール名として呼ばれる時がある。

【7】属性にはプリミティブ型を使わず、データ型を使う。
たとえば、属性にはDate型、Number型、String型を使う。
あるいは、Address、Color、PhoneNumber、UPC、SKU、ZIP、列挙型を使う。
区分値は列挙型を使う場合が多いかな。

例えば、会員クラスの会員名、会員IDみたいなものだろう。
でも、同じ会員名であっても、実際の人物は異なるケースもある。
だから、ValueObjectを別で用意して利用する場合もあるだろう。
ドメイン駆動設計なら、ValueObjectをかなり頻繁に使うだろうと思う。

【8】概念クラスの関連付けに外部キーや複合キーを書かない。
概念クラスの関連付けは、属性ではなくクラス間の関連で書く。

この部分がデータモデリングと異なるし、引っかかるところと思う。
一般にオブジェクトには唯一の主キーとなるサロゲートキーが割り当てられる場合が多いだろう。
すると、データモデリングで考えた時、外部キーや複合キーがなく、全てサロゲートキーなので、クラス間の制約条件が分かりにくくなる。
RailsのActiveRecordがそういう例になるだろう。
データモデリングなら、サロゲートキーを使っている場合、外部キーのペアが複合キーの役割を持つので強属性になるような制約をもたせるだろう。

では、概念モデルから実装モデルへ詳細化されていくうちに、関連はどう変わっていくのか？
概念モデルの関連から相手先のロール名が割り当てられて、最終的には関連はどこかのメソッドとして実装されて、そのメソッド内でロール名は変数名と同一視されて利用されるだろうと思う。

【9】概念クラス図でも、関連クラスのように、複合キーを使った事例はある。
しかし、関連クラスを多用すると、クラス図から読み取りにくくなる。
一方、データモデリングの観点では、関連クラスを複合キーを持つクラスと置き換えれば、明確な意味を読み取りやすくなる。

【10】概念モデリングでは、クラス間の関連と多重度でクラス間の制約条件を読み取る場合が多いように思う。
慣れるまで大変だけど。

【11】そんなことを考えてみると、概念モデリングや設計原則は以前よりも変化していないように思う。
UMLが流行していた2000年代からモデリング技法は進化しているのだろうか？

オブジェクト指向設計とデータモデリングの違いは他にも整理してみる。

パッケージ設計の原則の意義は変化しているのか

パッケージ設計の原則についてちょっと議論する場があり、色々考えるものがあった。
考えたことをラフなメモ書き。

【参考】
パッケージ設計の原則を本で学ぶ - Qiita

パッケージ設計６つの原則～ポイントは関連性/依存性/抽象度 | プレイン・プログラム

コンポーネントに関する6つの原則 - Qiita

【1】パッケージ原則6個の復習。

1. パッケージ再利用等価原則　Release Reuse Equivalency Principle
* 再利用の粒度はリリースの粒度と同じ
2. 共通閉鎖原則　Common Closure Principle
* クラスは共に変化し、共に存在する
3. 共通再利用原則　Coomon Reuse Principle
* 共に再利用されないクラスを同じグループに入れるべきではない
4. 非循環依存関係原則　Acyclic Depenedencies Principle
* パッケージ間の依存関係は循環してはいけない
5. 安定依存関係原則　Stable Dependencies Principle
* 安定している方向に依存する
6. 安定抽象原則　Stable Abstracttions Principle
* 安定したパッケージは抽象的であるべきだ

【2】パッケージ再利用等価原則が最も基本の原則と考える。

ちょっと昔のJavaシステム開発であれば、リリースモジュールwar/earがリリースの単位であり再利用の単位になる。
サブシステムごとにwar/earをビルドして検証環境でテストした後、オンプレの複数台のサーバー環境ごとに、複数のAPサーバーへwarを手動でデプロイしていた。
ロードバランサーからデプロイするサーバーを切り離して、1つずつwarファイルをデプロイして起動確認し、確認OKならば外部通信できるように設定していた。
つまり、そういう面倒な手動のリリース作業があった。

オンプレのサーバ環境にwar/earファイルをデプロイする単位は普通はサブシステム単位なので、そういう粒度で再利用しやすくする。
その場合、war/earファイルはできるだけサイズは小さい方がAPサーバ再起動時間も短くなるし、リリース作業も短くなるので、リリース作業ミスの確率も減らせる。

特に最近はAWSのようなクラウド環境では、サーバ環境そのものを使い捨てみたいにコンテナから自動生成するので、コンテナ(リリースする単位)のサイズが小さいほどサービスの再起動時間が短くなり、サービス停止時間も短縮化でき、顧客満足度も高くなる。
JavaGoldを取得した時に、モジュールの話で、モジュールサイズをできるだけ小さくしたい要望がある理由がそこにあると聞いて納得したことがあった。

クラウド上の開発がJavaに与えた影響は何なのか: プログラマの思索

Javaのモジュールシステムは複雑性をより増している: プログラマの思索

Javaのモジュールシステムの考え方をまとめてみた: プログラマの思索

【2】ただし、リリースモジュールの保守性や分割についてトレードオフがある点は理解できる。

実際、サブシステム単位にリリースモジュールwar/earをビルドする場合が多いので、普通はリリースモジュールのファイルサイズは非常に大きくなりがちだ。
なぜなら、リリースモジュールには、Apacheの共通ライブラリ、会社特有の共通ライブラリなどのJarという共通コンポーネントを多数含んでいるからだ。
同様に、RailsのようなWebアプリでも、bundlerの中には共通ライブラリGemを多数含んでいる場合が多い。

すると、リリースモジュールのファイルサイズを小さくしたくなる。
簡単に思いつくのは、リリースモジュールから他のサブシステムと共通で使う共通ライブラリは別出しして、デプロイする時は共通ライブラリは再リリースしなくて良いようにしたい。
APサーバ上に共通ライブラリを別で配置して事前ロードしておいたり、別APサーバ上に共通ライブラリを配置するケースも考えられるだろう。

メリットは、リリースモジュールのうち共通ライブラリは既にAPサーバにデプロイされているので再リリースは不要であり、リリースモジュールのサイズを小さくできる。
その分、ビルド作業時間、リリース作業時間を短縮でき、リリース作業ミスのリスクも減らせるだろう。

一方、デメリットは、共通ライブラリに手を加えた場合、既にデプロイ済みのサブシステムのwar/earファイルに影響が発生してしまう。
デグレがないか事前確認が必要だし、共通ライブラリがサブシステムのAPサーバとは別APサーバにデプロイされていて、共通ライブラリが複数のサブシステムから呼び出されているならば、複数のサブシステムに影響が発生してしまう。
共通ライブラリのリリース作業中にAPサーバを停止する事態が発生すれば、呼び出し側の複数のサブシステムで業務停止してしまうリスクが発生する。

また、共通ライブラリにサブシステムA向けのAPIを追加したり改修して、他のサブシステムB向けのAPIは触らない場合であっても、共通ライブラリをリリースする時にサブシステムAもBにも影響が発生してしまう。

だから、一般には、サブシステムごとに共通ライブラリを含んでリリースモジュールをビルドする場合が多いと思う。
すると、たとえば、サブシステムAの共通ライブラリXのバージョンは1.1、サブシステムBの共通ライブラリXのバージョンは1.2、みたいにコンポーネントのバージョンがサブシステムごとに違ってくる場合も発生するだろう。

つまり、サブシステムで利用する共通ライブラリのバージョン管理、構成管理が重要になってくる。
この仕組みがMavenであり、Railsならbundlerなのだろうと思う。
ライブラリやコンポーネントの構成管理というソフトウェアの複雑性をビルド管理の仕組みで補っているわけだ。

【3】では、昨今のアジャイル開発、DevOps、クラウドなどにより、パッケージ設計の原則の意義は変化しているのか？

メタな観点ではパッケージ設計の原則の意義は変わらない。
リリースモジュールは再利用できる単位であることは変わらないし、モジュールの分割方針やデプロイ方針も基本は変わらない。
しかし、具体的なリリース手順や開発プロセスは影響を受けていると思う。

例えば、SaaSビジネスでは、リリース作業時間は極力短くしたい。
リリース作業時間は広義の意味では、顧客に機能を提供するリードタイムと同じ。
BtoCのSaaSビジネスならば、機能改善の要件定義からリリースまでのリードタイムを短縮化する事は売上に直結する。
ちょっとした機能改善を即座にリリースできれば、顧客満足度も上がり、ユーザ数増加が売上につながるから。

また、特に昨今はクラウドでサーバーごとの仮想化するなどして丸ごとコンテナ化し、コンテナを使い捨てみたいにいくらでもデプロイできるから、リリース作業時間はできるだけ短くしたい。

これは、DevOpsの考え方と非常に相性が良いと思う。
DevOpsで開発チームがシステム運用と一体化したプロセスになるし自然にアジャイル開発になるはず。
つまり、アプリ開発者はアプリも開発するし、クラウド上でインフラ基盤もサーバー基盤もコンテナをプログラム化して自動配置できるようにすれば、開発も運用も一体化できるはず。

そして、リリース作業時間と言うKPIを開発チームが毎回計測し監視すれば、改善すべきか評価できるはず。
リリース作業時間、ビルド時間、デプロイ時間などはアジャイル開発の主要なメトリクスの一部と捉えられるだろう。
システム停止やデータ移行の時間も含めてリリース作業時間に3日間かかっていたのを、1時間で終わらせたり、わずか5分で終わらせれば、その分システム停止時間も短くでき、顧客の業務や顧客の操作時間への影響を減らせる。

そんなことを考えると、アジャイル開発やDevOpsという考え方は、サーバの仮想化やクラウドの技術のおかげで進化している部分も大きいのだろうと思う。
こんなことは既に当たり前の考え方と思うけれど、アプリ層の設計技法もインフラ基盤の仮想化技術に相当影響を受けているのではないか、と思う。

日本のアジャイル開発の先人による話が良かった

日本のアジャイル開発の先人による話が良かった。
ラフな感想をメモ。

【参考】
根回し、本音と建前……透明性が大事なアジャイルは、日本の慣習とどう折り合いをつけるべき？【平鍋健児×市谷聡啓×岩瀬義昌】 - エンジニアtype | 転職type

2000年頃からアジャイル開発がIT業界の技術もプロセスも先取りしていると気づいた人たちが、アジャイル開発を日本で導入し運用し始めてもう20年以上経つ。
ようやくアジャイル開発も日本で知名度が上がってきたが、まだメインストリームでない所が大半だろうと思う。
そんな中で平鍋さん、市谷さんの経験談や気づきに共感する所が数多くあった。
たくさんの経験を踏まえて、日本の風土に合うアジャイル開発のあり方が見えてきたのかな、と思う。

平鍋さんの発言録を読むと、日本人の風土をすごく理解されていて、琴線に触れるような言葉があるなと思う。

たとえば、アジャイル開発は「仲間作りの旅」ですよ、とのこと。
岩瀬さんが言われる通り、スクラムをやっていても、スクラムマスターやプロダクトオーナーはチームに1人しかいないので孤立しやすい。
だから、チーム外のステークホルダーだけでなく、チーム内のメンバーからも突き上げを食らったりする時もある。
そんな時は精神的にも辛い。
日本人の組織やチームはウェットなので、モチベーションアップのためにも、仲間という雰囲気作りが大切と思う。

たとえば、日本の大企業に根回し、建前があって透明性を求めるアジャイル開発と相性が悪い所がある。
しかし、平鍋さんは根回しは好きです、と言われる。
この人が反対するとプロジェクトが進まない、という状況であれば、悪い状況を最小限にするために、その人に早めに話をする（根回しする）のはありでしょ、と。
そういう人には割と感情的な部分もあるだろう。
そういう部分は日本の風土に合った現実的な解決策だなと思う。

アジャイル開発を堅苦しく考えないところがいいなと思っている。

JSTQBのテストプロセスの概念モデルを描いてみた

JSTQB Fondation試験を勉強した時に、JSTQBのテストプロセスの概念モデルを描いてみた。
気づきを書き残す。
まだ理解があやふやなので、間違えていたら後で直す。

【参考】
テストアイテムとは何か？概要や定義、現場での使われ方について解説

JSTQB_テストマネジメントとレビュープロセス.pdf from akipii Oga

JSTQB_テストプロセスの概念モデル.pdf from akipii Oga

【1】JSTQBのテストの専門用語は、普段使っている言葉と意味が違っていたり、別の言葉で置き換えられる時があると分かった。
たとえば、テストレベルはテスト工程のテストプロセス、テストタイプはテストの種類に相当するだろう。

テストオラクル、テストベースなどはJSTQBで初めて知った。
たぶん、テストケースの発生源や出処となる概念を明確に区別すべきという考え方があるのではないか。

テストオラクルの用語定義: プログラマの思索

また、テストプロセスの概念モデルを描いてみて気づいたのは、JSTQBにたくさん出てくるテストの専門用語は、テスト管理ツールやテスト支援ツール、テスト自動化ツールなどのツールで使う場面をかなり意識しているのではないか、と直感している。

たとえば、テストスイートは、一般にテスト自動化ツールに読み込ませるテストケースやテストデータをイメージできる。
テストハーネスはドライバやスタブみたいなものだし、テスト環境そのものも今ならDockerで最初から環境構築を自動化できる。

【2】エラー(誤り) error、欠陥 defect、故障 failureは明確に区別される。

エラー・欠陥・故障の用語定義: プログラマの思索

一般に不具合と言われる事象は故障に相当するだろう。
不具合をバグ、障害と断定しない理由は、実際に調査してみたら、仕様通りで問題ないとか、テスト手順ミスやテスト環境の不備が原因だった、という場合があるからだろう。
不具合は、故障、不正の事象も包み込む曖昧な現象を指す場合が多いと思う。

欠陥があったからといって、故障が発生するわけではない。
欠陥のあるプログラムが実行されて初めて故障が発生する。
欠陥がプログラムに埋め込まれても、テストで発覚せず、運用していても発生しなければ、システムは問題なく動く。
しかし、欠陥そのものは存在しているわけだから、いつかは故障として発生する。
いわゆる潜在バグに相当するのだろう。

欠陥の根本原因の分析はなぜなぜ分析がよく使われるだろう。
しかし、なぜなぜ分析を現場で実際に使ってみると、なかなか効果を出すのが難しい。
メンバの力量にかなり依存するので、原因があらぬ方向に行ってしまいがち。

【3】JSTQBでは、テストチームの役割には、テストマネージャとテスト担当者の2つが少なくとも定義されている。
テストマネージャはテスト計画フェーズで中心的役割を果たす。
テスト実行フェーズ以後の具体的な作業はテスト担当者に任せるようだ。
つまり、テストマネージャはプロジェクトマネージャやストラテジストに近いイメージを持った。

JSTQBのAdvancedLevelはテストマネージャ試験がある。
ただし、業務経験が必須らしい。

【4】テスト管理や品質管理については、TestLinkを試していた頃に随分色々考えていた。

TestLink: プログラマの思索

プログラミングやシステム設計とは異なる考え方を知ったり、試したりするのが面白かった。
残念なのは、テスト管理ツールはほとんどが有償であり、OSSのTestLinkしか試せなかったことだった。

テスト管理ツールTestRail、CAT、QualityForwardの感想: プログラマの思索

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク: プログラマの思索

今持っている問題意識は、2023年の現在、ソフトウェアテストを支援するテストツールはどんな方向に進化しようとしているのか、ということ。
上記の記事にも書いたが、日本のIT企業やユーザ企業が考える品質と、欧米企業が考える品質は異なる。
日本人は機能の細かい品質までこだわるが、現代はアジャイル開発が普及して一般的になっていて、その考え方が時代に合わない部分もある。
アジャイル開発に適した品質とは何なのか？
そして、AIなどを使ってもっとテストそのものを進化させることはできるのか？

この辺りは色々考えてみたいと思っている。

PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか

@sugimoto_keiさんのツイートを読んで、PM理論ではP志向の方がM志向よりも生産性が高いことを主張していることに気づいたのでメモ。

【参考】
杉本啓さんはTwitterを使っています: 「多くのひとは職場での人間関係を気にし過ぎる。その人が自分を支配しようとして色々束縛するなら、それは人間関係の問題だが、そうでないなら、人間関係は気にしないで自分がやるべき仕事をすれば、ほとんどの場合、解決する。人間関係が気になるのは仕事がうまくいってないから。その逆ではない。」 / Twitter

杉本啓さんはTwitterを使っています: 「昔の経営学で、課業志向と人間関係志向という概念があったが、これは課業志向の考え方。基本的には、課業志向でできることをまずやるのが先決だと思う。人間関係というものは答えがないし、根本的に解決することもできない。」 / Twitter

杉本啓さんはTwitterを使っています: 「多くのひとはたぶん、集団の中で自分の居場所を作ることが重要だと考えているのだろう。それが人間関係志向ということ。それはわかるのだが、そうではなく、何を達成するのか、そのためにどうするか考える。これが課業志向。そうすると人間関係は大して気にならなくなるし、却って良くなるものだ。」 / Twitter

【PM理論とは】歴史や特徴を事例からわかりやすく解説｜リベラルアーツガイド

PM理論とは？理論とリーダー育成における活用場面をわかりやすく解説｜人材育成・社員研修｜ラーニングエージェンシー

PM理論でリーダーを育成する企業は伸びる『事例紹介』 | 識学総研

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

心理的安全性はPM理論のメンテナンスの発展形ではないか: プログラマの思索

組織論で紹介される学者はほとんどが欧米人だが唯一の日本人として、三隅二不二のPM理論がよく紹介されている。
昭和の時代にカイ二乗検定を使って統計的に有意な仮説としてPM理論を打ち立てたらしい。
PM理論の考え方は考えてみれば当たり前のように感じて、あまり気に留めていなかったが、@sugimoto_keiさんのツイートを読んで、PM理論が主張したかった本来の内容は違うのではと思った。

組織におけるリーダーの能力は、課業志向と関係志向の2つがあり、両方とも高いレベルを目指すべきとPM理論は言う。
しかし、実は課業志向の方が関係志向よりも生産性が高いことを言いたかったのではないか。
つまり、リーダーシップは結局成果を出して初めて認められるものであり、成果を重視せず関係ばかりに注力しても問題解決にならない、と。
特に、日本人のリーダーや集団は課業志向よりも関係志向を重視しすぎていて、生産性が高くないのではないか、と。

たとえば、リーダーシップとは成果主義が前提であるという考えは、「採用基準」にも記載されていたのを思い出した。
「採用基準」では、成果を求められないリーダーシップに囚われすぎる日本人を批判している。

たとえば、野中先生の「失敗の本質」でも、日本軍という官僚的組織が実は成果主義よりも関係志向を重視していて、リーダー間で忖度し合うことで戦争に負けた経緯が詳しく分析されている。

たとえば、PM理論でリーダーを育成する企業は伸びる『事例紹介』 | 識学総研では、典型的な日本企業である日立でも、管理職のリーダークラスは優秀であっても課業志向ではなく、関係思考が強い傾向があるらしい。

こういう話を踏まえた上で考えると、日本人は集団でリーダーシップを発揮するという考え方や行動に何らかの問題があり、それがずっと弱点になっているのではと思う。

今の日本のアジャイル界隈では心理的安全性という概念がとても好まれているが、実は日本人のリーダーシップには関係志向が強すぎて課業志向が欠落しているのではないか、という考え方も心に留めておく。
たぶんコンテキストや環境によってはこの観点も必要だろうと思う。

現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ

「採用基準」「生産性」を読み返したらいろんな気付きがあった。
ロジカルでないラフなメモ書き。

【参考】
「採用基準」の感想～日本の根本問題はリーダーシップの総量が不足していること: プログラマの思索

DXとは組織論である: プログラマの思索

Slack導入がDXに繋がる話: プログラマの思索

諸問題を組織論に持っていくのは目的を手段化していないか: プログラマの思索

ITの地殻変動はどこで起きているのか？～今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

失敗の本質―日本軍の組織論的研究の感想: プログラマの思索

プログラマとスクラムが社会実装を変えていく　#Findy_GovTech: プログラマの思索

デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想～CTOの役割とは何ですか？: プログラマの思索

みんなのPython勉強会#65の感想～社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索

マッキンゼーの報告書「2030 日本デジタル改革」が手厳しい: プログラマの思索

【1】最近の日本のIT業界を見ていると、主に2つの現象が目につく。
一つは、DXに向いた組織を作ろう、という組織論の話。
もう一つは、DXを実現するためにアジャイル開発をもっと積極的に導入して運用しよう、という話。

この2つの話の背景には、2つの問題意識が真因として隠れていると思う。
具体的には、組織論の話題、アジャイル開発の話題の背後には、日本人はリーダーシップが不足していること、日本人は生産性の意識も言動も非常に低いことだ。

【2】今のビジネス界隈では、DXがバズワードだ。
DXを実現するには、既存の業務であれ、新規の事業であれ、ソフトウェアでコスト削減、さらには売上の創出が求められている。
DXを実現するには、ソフトウェア開発者、そしてそれを取り囲む組織という基盤が必要だ。

しかし、DXに関する組織論のテーマはすごくフワフワとしていると思う。
命令指揮系統ではなくフラットに風通しを良くしよう、心理的安全性が担保されるような組織風土を作りましょう、という組織文化の話題が多い。
だがそういう甘い言葉の背後には、今までの組織文化や事業スタイルを捨てて、新しい事業や新しい組織の関係を作ろうとする原動力が必要なのに、たくさんの壁にぶち当たる怖さが説明されていないように思える。
だから、何となく、現状を批判するだけで何も変わらない、という現象が出ているように思える。

実際は、既存の組織風土を変えるのは、今までの人間関係や組織との関係を変えることであり、自らリーダーシップを発揮して動いていかなければ何も変わらない。
ものすごく自頭の良い人やできる人に従ってやれば問題解決するわけではない。
自らチェンジ・エージェントになり、たくさんの困難な壁にぶち当たるごとに、一つずつ壁を壊したり乗り越えていくパワーが必要になる。

「採用基準」では、問題解決には、問題解決スキルだけでなく、問題解決リーダーシップ（Problem Solving Leadership）が必要と主張している。
たとえば、目の前に起こったいじめの問題に対し、MECEやロジックツリーだと言っても何も変わらないし、実際に解決するように行動して初めて、問題解決の方向に動き出す。
それが本来のリーダーシップ。

すると、このリーダーシップの背後には、「自らリスクを取る」という概念が隠れていることが分かる。
自分の思いどおりに変わらない状況に対し、自分と異なる価値観を持つ人を説得して調整したり、自分が持っていない知識やスキルはそいうう専門スキルを持った人たちに働きかけてチームとして問題解決を図ることが必要になってくる。
そういう行動は、思い通りの結果にならないかもしれないリスクに自らチャレンジすることを求める。

しかし、日本人はリスクを取りたがらないと一般的に言われている。
すべてのリスクを回避してリスクをゼロにすることばかりに専念している。
だから、リスクを取ってリーダーシップを発揮するという行為、選択肢が取りにくい人が日本には多いのだろう。

実際、「採用基準」に記載されている通り、日本人はチームプレーでチームに貢献した成果を問われる経験が極端に少ない。
たとえば、小中高校生なら、受験という行動はその人だけの能力測定試験であり、個人プレーにすぎない。
社会人になっても、プロジェクトリーダーや管理職にならない限り、自分だけの仕事の成果しか問われない。
すると、一般職の日本人は一生、チームでの成果を求められる、というリーダーシップ経験を積まずに終わる人が多い。

そんなリーダーシップ経験のない人は、わがままな振る舞いが多い。
チームで成果を出すためにそれぞれの役割を認識せず、自分が一番成果を出しやすい行動に走ってしまいがちだから。
自分が成果を出しやすい個人プレーに走るのは、自分が苦手な場面に行動するリスクを取らないことにも通じる。

そんなことを考えると、リーダーシップ不足という弱点をごまかして隠すことで、組織論というふわふわしたテーマに流れてしまうのだろう。
そしてリーダーシップ不足という日本人論の問題点は、日本人はリスク許容度が低いことに真因があると思う。

【3】アジャイル開発は20年以上前から提唱されているのに日本ではなかなか導入すらされなかったが、ここ最近になって積極的に取り入れようとする流れが出てきた。

アジャイル開発の本質は一体何なのか？
僕は、アジャイル開発とは時間価値を最優先にしたソフトウェア開発だ、と一言で言えると考える。
WF型開発のように、時間も労力もかけて品質を作り込んで、高品質なソフトウェアをリリースするのではなく、小刻みにいち早くソフトウェアをリリースすることで売上もキャッシュも獲得していく戦略を取る。
1年間で1回のリリースではなく、5回リリースできるなら、5回分のフィードバックが得られて、その分、市場ニーズに合ったソフトウェアへいち早く開発できるようになる。
つまり、リリース頻度が5倍多いなら、ソフトウェアの価値も5倍高まるメリットが生まれる。

では、なぜアジャイル開発は日本で受け入れられなかったのか？
アジャイル開発の源流はトヨタ生産方式と言われていて、日本人にも馴染みがあるのに、なぜアジャイル開発は日本人にフィットしなかったのか？
たぶんその最大の理由は、ソフトウェア開発の生産性が低いことが問題だ、という意識が非常に薄いことだと思う。

官公庁みたいな縦割り組織の日本人は生真面目なタイプが多いので、決められたルールに従う方が重要であり、コストや期間を度外視したり生産性を重視する行動に行きやすい。
また、ソフトウェア開発者派遣のような人月ビジネスでは、たくさんの工数がかかるほど儲かるので、生産性を上げるモチベーションがビジネスモデル上生まれにくい。
今の日本の製造業では生産工程の改善により原価低減による付加価値向上を目指すが、3％の生産性向上よりも30％以上、2倍以上の生産性向上を目指すような、イノベーションを取るような行動が生まれていない。

なぜ米国企業は90年代に蘇ったのか～日本の手の内は完全に読み取られた～V字回復の経営の感想: プログラマの思索

生産性が低い現象が問題だ、と考えて、その問題解決を図ることにより、生産性をさらに大幅に向上させるという正のループを作り出せていない。
特に、3％の生産性向上のようなちょっとした改善ではなく、30％や2倍以上の生産性向上を図ろうとすれば、今までのやり方を捨てて、新たなアイデアを試す、といったリスクを取らなければ実現できないだろう。
しかし、今までリスクを取ったことがない人が、いきなりハイリスクハイリターンの選択肢を取るのは非常に難しいだろう。
なぜならば、仕事でもプライベートでも、そういうハイリスクハイリターンの練習を経験していなければ、実践で試すことは難しいだろうから。

日本人の生産性が著しく低い、という点にも、日本人はリスクを取りたがらない、という現象がその問題の背後に隠れている。

つまり、「ソフトウェア開発のように、時間価値が重要な意味を持つビジネスでは、生産性に比重をおいて時間戦略を取るべきだ」という考え方が日本人も日本企業も受け入れられていないからだ。
その真因には、日本人のリスク許容度が低いこと、土建業界やIT業界に限らず自動車業界においても日本のあちこちの業界で多重請負ビジネスがはびこっていることにあるのだろうと思う。

なぜ米国企業は90年代に蘇ったのか～日本の手の内は完全に読み取られた～V字回復の経営の感想: プログラマの思索

【4】リーダーシップ不足や生産性が著しく低いという現象には、リスクを取らないという日本人の気性が出ているのではないか。
あえてリスクを取ることで、大きなリターンを得る、というハイリスクハイリターンの選択肢を最初から捨てている場合が多いのではないか。

リーダーシップがあり、生産性が高い人は、いろんな問題解決に対してリスク許容度が広いので、かなり大きなリスクを自ら選択することができる。
つまり、リスク対応力とその人の問題解決能力は比例しているのだろうと思う。

【5】組織論やアジャイル開発をテーマにしている人たちは、日本人の弱点である「リーダーシップ不足」「生産性が著しく低い」「リスク許容度が著しく低い」という真因におそらく気づいている。
その真因をいろんな角度から、いろんな言葉で、いろんな手段で解決を試みようとしているのだろうと思う。
そういう観点を持って、今のDXにかかわるテーマを取捨選択して聞いてみたいと思う。