中国Alibabaが4月29日（現地時間）に発表した、大規模言語モデル「Qwen」の最新版となる「Qwen3」シリーズが話題だ。フラッグシップモデルの「Qwen3-235B-A22B」は「DeepSeek-R1」の半分未満のパラメータ数ながら、OpenAIのo1やo3-mini、GoogleのGemini 2.5 Proなど他のトップモデルと並ぶ性能を達成したという。「Qwen3-4B」は小さなモデルでありながらも「GPT-4o」を多くの項目で上回るとしている。
Datasetteの開発者であるSimon Willison氏は、Qwen3について「ほぼすべての一般的なLLMサービスフレームワークと直接連携しており、リリース初日から利用できるようになっています」「AIモデルのリリースとしては異例のレベルであり、これほど努力しているAIモデルプロバイダーを他に知りません。
よくあるパターンは、単一のアーキテクチャ向けのAIモデルをHugging Faceに大量投入し、他のすべてのモデルの量子化と変換がコミュニティに追いつくのを待つというものです」と述べ、LLMフレームワークとの優れた連携面を称賛しています。
⇧ 努力は分かるのだが、是非とも、「変更容易性」を考慮した「ソースコード」の生成を実現してくれるようにして欲しいものだが...
変更容易性とは
「ソフトウェア品質」の英語版のWikipediaによると、
In the context of software engineering, software quality refers to two related but distinct notions:
- Software's functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications. That attribute can also be described as the fitness for the purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product. It is the degree to which the correct software was produced.
- Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability. It has a lot more to do with the degree to which the software works as needed.
Measurement
Maintainability
Maintainability includes concepts of modularity, understandability, changeability, testability, reusability, and transferability from one development team to another.
⇧ とあるように、「変更容易性」というそのものズバリという用語は存在しないようなのだが、強いて言うならば、「保守性」における概念を組み合わせた概念になりそうではある。
システムは様々な機能・非機能の集合体であることが一般的とは思うのだが、
『各々の機能・非機能に影響を与えること無く、または、「変更」に伴う影響範囲の特定が容易であり、且つ、誰でも「変更」が手軽に遂行できる』
ということが『変更容易性』ということになるかと。
認識齟齬を無くすためにも、「変更容易性」の定義をハッキリさせたいところではあるのだが...
で、「変更容易性」については、現状、小規模なシステムや「概念実証（PoC：Proof of Concept）」向けで、ただ動くだけの「ソースコード」しか生成することのできない「AI」などでは実現が難しい領域の話にはなってきそうではある。
ソフトウェアにおけるパフォーマンスとは
システムとは、
- 機能
- 非機能
の集合体であることが一般的とは思われるが、顧客の要望を「要求定義」として整理し、「要求定義」の内容を実際に技術的に実現する上での方針を定義したものが「要件定義」となるわけなのだが、「要件定義」で、
- 機能
- 非機能
の全量が明確になりますと。
で、「パフォーマンス」というのは、「非機能」で合意を取る形になりますと。
例えば、外部のシステムと連携するような「機能」において、
- 1秒で100件を処理する
- 1時間1000リクエストを許容する
- サイトにアクセスして1秒以内に表示する
- ..etc
など「機能」に対して条件を設けることがあると思われるが、
- インフラストラクチャー設計
- サーバー設計
- ネットワーク設計
- UX（User eXperience）
などが主に「非機能」の部分に関わってくるのだが、予算の関係上、潤沢な「マシン」の「スペック」を用意できないようなケースが往々にして存在し、結果、「ソフトウェア」側で何とかせざるを得ない時があるという前提で話を進める。
アーキテクチャ意思決定記録（ADR：Architecture Decision Record）とは
ネット上の情報を漁っていたところ、
In 2011, Nygard proposed architecture decision records (ADRs) as a lightweight means for capturing ADDs.
⇧ 上記のサイトの情報が正しいとすると、「Michael Nygard」という人物が2011年に「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」を提唱したのが初出ということになるっぽい。
一応、「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」については、
Decision record template by Michael Nygard
This is the template in Documenting architecture decisions - Michael Nygard. You can use adr-tools for managing the ADR files.
⇧「Template」が公開されてはいるのだが、統一的な定義は為されていないのが現状といった感じのようだ...
「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」が何なのかについての共通の定義を明確にして欲しい気はする...
そもそも、「ソフトウェア開発」において「設計」に対する「意思決定」について、開発するシステム毎に「要因」が千差万別であるため「再現性」は薄いため、『どういう意図なのか』という情報を残すことが重要なのだが、残念ながら「ソースコード」を読解したところで思想を解釈することが困難なことが多い。
というのも、「ソースコード」を読解したところで、
- 正常に動作する、且つ、意図した通りの実装である
- 正常に動作する、且つ、意図した通りの実装ではない
の違いは分からないことが多いからである。
「動作確認」したとしても、「正常に動作する」部分しか判断しようが無いのである。
で、
In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.
Rationale was mentioned in an early definition of software architecture by Perry/Woolf, but not researched much until 2004, when a workshop on architectural decisions and Architectural Knowledge Management was held in Groningen, NL. Early publications can be traced back to this workshop,.
⇧ このあたりの研究自体については歴史も浅いらしく、「ソフトウェア開発」がカオスになっているのも頷ける気がする。
語弊を恐れずに、ザックリと言うと「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」とは、『様々な設計の選択肢があったとは思うが、何故にその設計を選択するに至ったかの、所謂、意思決定の内訳を可視化する』
ということなので、
『意思決定に至った当時の背景の記録』
としても利用できることになるかと。
変更容易性とパフォーマンスはトレードオフとなる場合があるが...。ADRが重要という話
で、本題なのだが、
- 変更容易性
- パフォーマンス
が「トレードオフ」の関係になる場合があるのが、「ソフトウェア開発」でありますと。
「ソフトウェア開発」をしていて、「機能」の追加などを行うような「既存」の「システム」に対して改修をするような現場で仕事をしたことのあるエンジニアであれば、前任者による「黒魔術」としか思えないような「可読性」の低い「ソースコード」に遭遇したりしたことはあると思う。
俗に言う「オレオレ実装」というものである。
ここで、困るのが、パフォーマンスを優先するにあたり、
- 実装当時、代替案が無かったための実装
- 実装当時、代替案はあったが、実装者が未熟であったことによる独自の実装
- 実装当時、代替案はあったが、安定していなかったことによる苦肉の策の実装
のいずれであったのかを判断する必要が出てきた場合に、判断をする担当者が、
という状況であったとする。
「ソースコード」の読解で個人差が出て来てしまうことはあると思うが、仮に最短で1か月かかるとした場合、
を把握するのに、1か月かかることになる。
仮に、「2. ソースコードは適切ではなくなっている」ということが判明した場合に、次のアクションとして、
- 改修が必要である
- 改修は必要ではない
の判断をするための情報収集が必要になると思われ、コストがかかることになるのだが、仮に、情報収集した結果、改修する方針となった場合に、
- 改修するとなった場合の影響範囲の調査
- 改修方針のための調査
- 改修方針の決定
といった作業が発生するので、兎にも角にも、コストが膨大になってきてしまう。
もし、「設計の意図を記したドキュメント」があったとした場合、日本語が読解できるのであれば、「設計の意図」を読解する際の個人差は限りなく無いはずなので、「工数」の「見積もり」がし易くなるということも期待できる。
何よりも、「可読性」の低い「ソースコード」の読解を強制されるというストレスを避けることができ、エンジニアの精神的負担は緩和される気はする。
「開発チーム」内で、「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」について、
- フォーマット
- 粒度
- ルール
などを明確化しておいて、「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」を導入していければ、「開発チーム」に新規参画者が参加することになった場合に、キャッチアップはスムーズになる気はする。
初見の人間でも「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」の作り方を理解できるように、「開発チーム」における「アーキテクチャ意思決定記録（ADR：Architecture Decision Record）」のガイドは必要になってくると思いますが。
何よりも、「言った言わない」問題に巻き込まれるリスクを回避するためにも、共有しておくべき情報はドキュメント化して可視化して誰でも参照できるようにしておくことが無難な気がしますかね...
「コミュニケーション」のコストを言い訳にして「口頭」で済ますような文化がある場合は、意識的にドキュメント化していくことが重要ですかね...
「保守・運用」する担当者のことを考慮するのであれば、ドキュメント化しておくことは自然な気はしますが、他の人間のことは知ったことでは無いという人間ほど「口頭」で済ませる傾向にある気がしますね...
まぁ、そういう人間は「チーム開発」に向いていない気がするのだが、「PM（Project Manager）」とかに多い気がするので厄介なのよね...
とりあえず、「開発フロー」ぐらいは「開発チーム」内でハッキリさせときたい気はしますな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
