アーキテクチャ設計のプロセスを改善するために参照した論文・資料・記事

はじめに

組込みソフトウェア開発において、アーキテクチャ設計のプロセスを改善をするために（アーキテクチャの評価方法の考案などをするために）、参照した論文や資料や記事をまめておきます。

以下で分類して、論文や資料や記事を整理します。

1. 設計者
2. 設計原則
3. 設計事例
4. 設計プロセス
5. 設計評価
6. 設計改善（リファクタリング）

参照した論文・資料・記事

1. 設計者

山田大介，「連載コラム アーキテクトへの道」

「ソフトウェアアーキテクトが知るべき97のこと」

2. 設計原則

@hirokidaichi，「技術選定/アーキテクチャ設計で後悔しないためのガイドライン」

@hirokidaichi，「なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか」

「The #1 bug predictor is not technical, it's organizational complexity」，2019

@MinoDriven，「役割駆動設計で巨大クラスを爆殺する」

@MinoDriven，「関心の分離を意識した名前設計で巨大クラスを爆殺する」

「SEC BOOKS：組込みソフトウェア向け設計ガイド ESDR[事例編]」，独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター，2012

抜粋

C-13：事前に構造解析を行うことにより効率的にソフトウェアを再設計する
C-14：機能の変更・追加のときにはソフトウェアの静的構造を崩さないように注意する

Martin Fowler，「新装版 リファクタリング―既存のコードを安全に改善する―」，オーム社，2014

コードの不吉な臭い（Code smell）が示されている。

@kazuo_reve，「嗅いだことありますか？不吉な臭い（仕様スメル・制約スメル・設計スメル・コードスメル）」

3. 設計事例

寧静，青山幹雄，「組込みソフトウェア向けデザインパターンとその適用方法」，第68回全国大会講演論文集 2006巻 1号，p.217-218，2006

高田広章，「組込みシステム開発技術の現状と展望」，情報処理学会論文誌 42巻 4号，p.930-938，2001

4. 設計プロセス

@kenjihiranabe，「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ」

原田真太郎，丹羽徹，赤松康至，田口正久，「オムロングループにおけるソフトウェアプロダクトライン（Software Product Lines）の取組み」，OMRON TECHNICS Vol.51.012JP，2019

原田真太郎，「ソフトウェアプロダクトラインにおけるコア資産評価の仕組み確立」，SPI Japan 2014，2014

「SEC BOOKS：システム再構築を成功に導くユーザガイド　第2版　～ユーザとベンダで共有する再構築のリスクと対策～」，独立行政法人情報処理推進機構（IPA）　技術本部　ソフトウェア高信頼化センター（SEC），2018

4章に登場するアーキテクチャを診断する仕組みの事例が参考になるかも。

池田義雄，「フロントローディングによる上流設計力強化」，東芝レビュー 62巻9号（2007年9月号），2007

抜粋

三つのフロントローディング
一つ目のフロントローディングは"設計検証のフロントローディング"である
二つ目のフロントローディングは"仕様検証のフロントローディング"である
三つ目のフロントローディングは"設計工程のフロントローディング"である

藤原啓一，「要求・要件仕様を効率的、高品質に作成する方法 －経験的設計ルールを継続反映させながら使うモデルベース要件定義フレームワーク－」，MSS技法 Vol.29

すごく、しっかりまとめられている。
我々のチームの開発では、同じようなステップを踏んでる。ただし、この論文のように言語化はできていない・・・。

社会保険庁，「参考資料6：アーキテクチャー設計の考え方と成果物のイメージ」

社会保険庁が、アーキテクチャ設計のガイドラインのようなものを作っているとは思わなかった。

5. 設計評価

山田大介，「組込みソフトウェアの アーキテクチャ設計の可視化」，先進的な設計・検証技術の適用事例報告書 2015年度版 PARTⅡ 設計事例，2015

山田大介，「組込みソフトウェアのアーキテクチャ設計の可視化」，Embedded Technology 2015，2015

野田夏子，岸知二，「ソフトウェアアーキテクチャの評価手法について」，情報処理学会研究報告ソフトウェア工学（SE） 2002(64(2002-SE-138))，p.121-128，2002

抜粋

SAAM

鈴木雄介，「アーキテクチャのレビューについて」，JaSST Review'18，2018

アーキテクチャ設計のレビューは、事前的・予測的。
構造が固まったり・構造が変化したら、それをトリガーとしてタイムリーに、実物で（コードをもとに）レビューするというのも、一つの現実的なアプローチのかも。

@gakuri，「もしかしたらコードメトリクスこそが、僕たちを救ってくれるかもしれない。」

「コードメトリック値」，2018

山田弘隆，伊藤雅子，山瀬清美，中嶋久彰，長尾徳富，小林克己，縣博之，森田純恵，菊池慎司，野中誠，「ソースコードメトリクスと品質リスクとの関係分析とそれに基づくリスクヘッジ手法に向けて」，ソフトウェア品質シンポジウム2017，2017

山崎愛，岡本渉，河原敏宏，大場勝，「設計ルール逸脱箇所検出による設計改善手法」，第76回全国大会講演論文集 2014(1)，p.233-234，2014

Yu Kawanami，「ArchUnit で Java / Kotlin アプリケーションのアーキテクチャを CI する」，JJUG CCC 2019 Spring，2019

井上心太，大森洋一，荒木啓二郎，「ツールによる形式モデルの成熟度測定法の提案」，研究報告ソフトウェア工学（SE） 2013-SE-179(29), p.1-8，2013

6. 設計改善（リファクタリング）

「リファクタリングの誤用」，2004

kyonmm，「継続的な作りなおし -リファクタリングとRoyce-」，2020

計画的に3回作り直す戦略にしておくと、確かにいろいろメリットありそう。
組み込みソフト開発では、やってるところが、それなりに存在してる気がする。
私は2回作り直す戦略はとったことあり。ただ、全部捨てて作り直すということはしなかった。

柴田芳樹，「リファクタリングしてますか？」，2009

リファクタリングの前に、テストを用意する。大切。

ohbarye，「状態、結合、複雑性、コード量の順に最適化する」，2022

最近、知った記事。リファクタリングの優先順の言及は、あまり見たことがなかった。

その他のアーキテクチャ設計に関するメモ

設計知識の活用について

成功はパターン化しにくいが、失敗はパターン化できる。
「勝ちに不思議な勝ちあり、負けに不思議な負けなし。」と野村克也さんがおっしゃっていた。
アーキテクチャ設計のナレッジも同じかも。

一つでもかけたら失敗する。すべて揃って初めて成功する。みたいなところがあるかも。
あと、成功の要因は、ある人にとっては苦しいこと・よくなかったこと。苦しかったこと・よくなかったことを、成功の要因と認識するのは、難しいのかも。
プロジェクトに携わる人の立場によって、よかったと感じることが、バラバラ過ぎて、パターン化するのが難しいのかも。

設計知識の表現方法についてもいろいろ考えたい。

• IPAの事例
  https://www.ipa.go.jp/sec/reports/20170321_1.html
• デンソーの事例
  https://www.monodukuri.com/jirei/article/38
• デンソークリエイトの事例
  https://www.juse.jp/sqip/library/shousai/?id=402
• SSM
  http://www.ssm.co.jp/ssm/index02.html

式年遷宮

先輩達は、ソフトウェアを上から下まで全部自分で作っていた。今は分業で、一部を作った経験しかない技術者が多い。
伊勢神宮には式年遷宮があり宮大工の技術を伝承できている。ソフトウェアも5年毎くらいに、前任のアーキテクチャ設計者と、0から全て作り直すと技術が伝承できるかも。その予算を用意するのは難しい。

ちなみに、技術伝承のために、ソフトウェア開発でも、式年遷宮みたいなこと必要だろうなと考えてました。調べてみると、既に言語化して意識的に実践してるチームありました。

図・モデリング・設計について

CESTの技術者交流会で得た知見
http://www.ertl.jp/CEST/

• 図はコミニュケーションを効率化するためのもの。
• 人で開発してると図を書かないことが多そう。
• 図を書かない、書けない？、書こうとしない？技術者も結構いる。
• 図は、コミニュケーションの道具なので、人が確認できる大きさ・複雑さであるべき。適度に分割・階層化・グループ化すべき。大きさ・複雑さの制約を設けておくと良さそう。発表資料などと一緒。コードのメトリクスと一緒。モデリングツールから、拡大縮小機能、スクロール機能を、無くしてしまうと、図の分割・階層化等をせざるを得ない状態になり、よいかも。
• 複数人で検討時は、ツールでモデリングするより、型に拘らずホワイトボードや紙に手書きの方が良さそう。
• 図を入力にしたほうが、心配点や想定外だったことに気づきやすい。
• 表のほうが見やすいこともある、図と表を行ったり来たりし、連動して変更されるような道具は、便利。
• モデリングツール単独では価値が小さい。コード自動生成や自動検証、テストケース自動生成等、後工程の自動化ができることで、価値が大幅に上がる。価値が小さいうちは、新たな道具は、なかなか導入されない。
• 設計を統一する・複雑にしないためには、ある階層の設計は、できれば1人しか触らないようにしたほうがよいのかも。アーキテクトとプログラマーは、明確に人を分けたほうが、よいのかも。大工は、勝手に柱や壁を増やしたり減らしたり移動させたりしない。
• ボツにした設計案も残しておき、なぜボツにしたのかの理由も分かると、採用された設計案の理由がよくわかる。
• 図を書くのは結構難しい。
  • ポイント：引き算
    コピーライターの連れと映像編集してた連れに教えてもらったのは、引き算です。素材は出来るだけたくさん集めるべきだが、せっかく集めた素材でも我慢して、捨てるものを決めるそうです。これが、意外と難しいです。
  • ポイント：制約
    足立久美さんにご指導していただいたのが、制約（文字数、文字サイズ、項目数、ページ数、図表の使用、起承転結などの一般的なフレームに当てはめる）を設けて、制約の範囲内で描くということです。これは、すごくよいやり方だと感じてます。

@kaizen_nagoyaさんの関連記事

青山幹雄先生に教えていただいたことと、それをもとに考えたこと

その1

• 目的・目標達成のために、開発対象のシステムの範囲(スコープ)とシステムが影響を与える対象範囲(前提、条件等含む)を適切に決めることが大切。
• 要求はアーキテクチャの影響を受けるものもあるため、要求開発とアーキテクチャ設計は、行ったり来たりする。要求もアーキテクチャも、一発で100点にするのは難しい。やはり、複数のイテレーションを繰り返し、徐々に完成度を高める開発方法は、良いと思う。
• 非機能要求を品質要求、法令(絶対守るもの、調整できないもの)、制約の３つに分類するのは、よいかも。漏れなく整理できそう。
• システムに求められる信頼性を具体化するときには、故障モード(欠陥の種類)を使うとよいかも。
• ゴールツリーは、GSNを使うとよい。サブゴールに分割した根拠(理由)が表現できる。
• ミスユースケース(心配)を抽出するには、まずシステムの外にあるアクタと影響する環境を漏れなく洗い出すとよい。HAZOP、FTA、FMEAの３つで十分、心配が抽出できそう。心配を抽出するときは、対象を分けて小さくしたほうが、やりやすそう。
• 要求工学の技術は、最終的なコードの品質にどのような影響があるか想像しにくい・効果の確証が得にくいため、積極的な導入がされにくい。技術を適用する工程と、効果を得たい工程が遠いことが影響しているか？

その2

• アーキテクチャは、『将来の変化』と『非機能要求』に対応することが重要。 早く非機能要求に対するアーキテクチャを評価し、見直せるような計画にする必要あり。イテレーション開発にして、各フェーズにテストする非機能要求を割り当てておき、次のフェーズ開始前に、アーキテクチャを見直すスケジュールにしておくとよい。
• アーキテクチャが影響を受ける変化（前提としていること）を明確化しておき、定期的に監視する。監視結果をもとにアーキテクチャの見直し要否を判断するとよい。
• アーキテクチャを守るため、アーキテクトに権限が必要。アーキテクトに設計レビューでの承認の役割をもたせる。
• ソフトウェアのアーキテクチャと組織のアーキテクチャの両方を設計し、整合性をとることで、よい開発ができる。

青山先生ありがとうございました。