ソフトウェア
エンジニアリング

0.1 前回の講義から

完成形を一度で設計せず、検証できる小さな単位から始める

1

なぜソフトウェアエンジニアリングが必要か

ソフトウェア開発では、​変更と​学習を​繰り返す。​
衛星では​打ち上げ前に、​その​サイクルを​できるだけ高速に​回しておく​必要が​ある。

1.1 ソフトウェアは変更され続ける

設計は一度では決まらない。そしてソフトウェアは、それを前提に作れる

1.2 実機で何度も試すことはできない

衛星では、確かめたいことのすべてを実機で何度も試すことはできない

開発中は自由回転させられない。Week 6 の運用ルール。ベアリングで自由回転させるのは打ち上げの中だけ

軌道上と同じ条件を地上で完全には再現できない。実衛星も同じで、打ち上げ前に作り込むしかない

実物での試行錯誤には制約がある。試せる回数・条件・機体への負荷が限られる

具体例：姿勢制御。開発中は機体を固定し、自由回転はさせない

1.3 フィードバックは手前の段から返す

広く・現実に近いことを確かめるほど、1周は遅くなり試せる回数も限られる。だから、手前の段で確かめられることは手前の段で確かめる

1.4 今日学ぶことの全体像

どうすれば、変更の結果をもっと早く確かめられるか

実機では何度も試せない　→　何度でも試せる検証環境を地上に作る必要がある　→　そのために、設計・テスト・SILS・CI・構成管理を学ぶ

第1章 なぜソフトウェアエンジニアリングが必要か｜1.5 この章のまとめ：ここは覚えて次へ

実機のフィードバックは遅く、試せる回数も限られる。だから、地上に速く何度でも確かめられる場所を作る。

2.1 困る具体例：センサ直書きのコード

メインループでベタ書きすると、役割の違うコードが同じ場所に混ざる

// 直書きの例：判断ロジックとハード操作は違う役割while (true) {    double sun_angle = read_sun_angle();   // ← ここで実機の ADC に直接触っている    if (sun_angle > kThreshold) {        set_wheel_command_us(1600);        // ← ここで実機のサーボに直接触っている    }}

2.2 なぜ困るのか：依存と結合度

依存が​多く​深いほど、​変更は​広く​波及する

2.3 情報隠蔽：変わりやすい判断を隠す

独立して変更されそうな設計判断を、モジュールの内側に隠す

2.4 分離の道具：依存の相手を実装からインターフェースへ

依存の相手を、具体的な「実装」から「インターフェース（守るべき取り決め）」に変えると、中身を差し替えられる

INFO　索引：Interface を C++ で実現する手段の一つ（必要になったときに引く）

C++ では、クラス＋virtual が差し替えを実現する方法の一つ

2.5 実機センサでも模擬センサでも、同じ判断ロジックが動く

判断を「太陽方向を返す何か」に依存させ、実機と模擬実装（Test Double）を差し替える

// 判断は「太陽方向を返す窓口」にだけ依存するclass ISunSensor {        // 窓口（インターフェース）public:    // 「太陽方向を返す」とだけ約束する    virtual double read_sun_angle() = 0;}; // 実機：ADC を叩くclass RealSunSensor : public ISunSensor {    double read_sun_angle() override;};// 模擬実装（Test Double）：決めた値を返すclass MockSunSensor : public ISunSensor {    double read_sun_angle() override;};

第2章 変更に強いソフトウェアを設計する｜2.6 この章のまとめ：ここは覚えて次へ

良い分離は、変更の影響範囲と試験の範囲を小さくする。

3

テストできることは設計品質である

分離した結果、判断ロジックはPC上で動く。入力と出力を与えられるなら、その振る舞いは自動で確認できる。

3.1 Unit Test：確認する作業をコードにする

入力を決められて出力を読めるなら、その振る舞いは自動で確認できる

// 明るい側ではホイールを回す、という期待を書くTEST(SunPointing, TurnsWheelWhenBright) {    MockSunSensor sun(30.0);   // 入力を決める    SunPointingLogic logic(&sun);    auto cmd = logic.step();     // 出力を受け取る    EXPECT_EQ(cmd.wheel_us, 1600);}

3.2 Testability：テストしやすさは設計品質

Testability はテスト担当者の都合ではなく、ソフトウェア設計そのものの性質である

3.3 何をテストするか：同値分割と境界値分析

入力は、同値分割で代表を選び、境界値で誤りの出やすい点を突く

3.4 Coverage の読み方と、テストが言えること

Coverage が高いだけでは正しさは言えない。見えるのは「どこまで試したか」

INFO　発展：テストの感度を確かめる（Mutation Testing）

意図的に壊して赤になるかを見ると、何も見ていないテストを見つけられる

第3章 テストできることは設計品質である｜3.5 この章のまとめ：ここは覚えて次へ

テストできること自体が、ソフトウェア設計の品質である。

4

小さく設計し、小さく直す

テストが数秒で返るなら、設計・実装・検証を非常に小さな単位で往復できる。最初から完璧な設計は要らない。

4.1 TDD：期待を先に置き、実装と設計を小さく往復する

次の一歩を、検証できる大きさまで小さくする

4.2 なぜ小さく往復するのか

設計と実装と検証を、非常に小さな単位で往復する開発の進め方

4.3 Refactoring：振る舞いを変えずに内部を改善する

外部から見える振る舞いを変えずに、内部設計を改善する

第4章 小さく設計し、小さく直す｜4.4 この章のまとめ：ここは覚えて次へ

小さく確かめられるから、設計は後から安全に改善できる。

5

実機なしでシステム全体を試す

Unit Test で確かめたのは部品単体まで。次は、部品を全部つないで動かしたときの振る舞いを確かめる。実機の代わりに、実行できるモデルの中で制御ループを閉じる。

5.1 Unit Test だけでは、衛星全体の振る舞いは分からない

段を上げるほど範囲は広がる。段ごとに得られる Evidence の種類が違う

5.2 実行できるモデルで設計を試す（この講義での MBD の扱い）

対象の振る舞いをモデルにすると、設計を実行して比べられる

5.3 SILS の構造：Plant（物理モデル）と Controller（フライトロジック）

機体の物理を模す Plant と、判断を担う Controller を分け、PC 上でループさせる

5.4 SILS が成立するのは、分離してあるから

SILS が作れるのは、フライトロジックがハードウェアから分離されているからである

5.5 モデルは現実そのものではない

測れる値は実測し、残った差を観測してモデルを更新する

第5章 実機なしでシステム全体を試す｜5.6 この章のまとめ：ここは覚えて次へ

分離してあるから、同じフライトロジックを PC 上のモデルの中でも回せる。

6

変更を小さく統合する

1人で速く回せるようになった変更を、チームで壊さず合流させる。ここでの「小さく」は設計の話ではなく、一度に持ち込む変更量の話。

INFO　用語の整理：バージョン管理・Git・GitHub

バージョン管理は変更の履歴を残し、どの時点へも戻れるようにする仕組み

6.1 GitHub Flow とは：一般的なチーム開発の型

main を常に動く状態に保ち、変更は短命な枝で作って Pull Request で戻す

6.2 二つ目の「小さく」：一度に持ち込む変更量

長く育てた巨大なブランチは統合が難しくなる。変更は小さく刻んで持ち込む

6.3 Pull Request と Code Review

PR は単なる関所ではない。変更単位を明示し、差分へフィードバックを集める場所である

第6章 変更を小さく統合する｜6.4 この章のまとめ：ここは覚えて次へ

設計では影響範囲を小さくし、統合では一度に持ち込む変更量を小さくする。

7

フィードバックを自動化する

テストがあっても人間が走らせるなら、そこが手作業として残る。変更した直後に、機械が品質のフィードバックを返す。

7.1 CI とは何か（Continuous Integration・継続的インテグレーション）

人が思い出して自分の PC で確かめる代わりに、共有の場所が変更のたびに同じ手順で確かめる

7.2 CI で何を走らせるか

変更をきっかけに走らせるものを決め、その結果を差分の上に返す

7.3 二種類の働き：自動チェックと意思決定

自動チェックは根拠を返し、判断はその根拠を採用するかを決める

7.4 二重のループ：高速な自動ループと、統合のループ

自動チェックは数分で戻り、統合は判断を経て進む

第7章 フィードバックを自動化する｜7.5 この章のまとめ：ここは覚えて次へ

変更した直後に、数分で根拠が返る状態を作る。

8

飛ばしたソフトウェアを再現できるようにする

テストが緑でも、軌道上で動いていたものが何だったかを言えなければ、原因は追えない。

8.1 なぜ構成管理が必要か

同じものを手元で動かせなければ、原因の切り分けは始まらない

8.2 Release・Tag・依存固定・artifact 保存

時点を指せて、同じものを作り直せるなら、原因を追えて戻れる

第8章 飛ばしたソフトウェアを再現できるようにする｜8.3 この章のまとめ：ここは覚えて次へ

「何を飛ばしたか」を再現できて、初めて原因を追える。

9

まとめ：高速なフィードバックループを作る

今日の技法はバラバラのベストプラクティスではない。変更を小さく、安全に、高速に回すという一つの思想から出てくる。

9.1 一つの思想から、設計・検証・統合が出てくる

「変更を安全・高速に回す」を、設計・検証・統合の三つで支える

9.2 結論

ソフトウェアエンジニアリングとは、​
最初から​完璧な​ソフトウェアを​作る​技術ではない。

変更を小さくし、変更の結果を高速に検証し、学習しながら安全に設計を改善し続けるための技術である。

9.3 次回予告：Week 8 プロジェクトマネジメント

今日までに作った検証と統合の道具を、チームの計画とインターフェース設計へ

9.4 宿題：同じ宿題を、ソフトウェアエンジニアリングの考え方で考え直す

Week 6 で考えた「初回打ち上げに必要な機能」をSWE視点で考え直す