Developers Summit 2021 Summer「アジリティを支える品質特性」を聞いて

2021/07/30 に開催された Developers Summit 2021 Summer のイベントレポートです。
A トラックの 「アジリティを支える品質特性」 というセッションを聞いてきました。
https://event.shoeisha.jp/devsumi/20210730/session/3223/

こちらセッションを聞いてのメモになりますので、個人的解釈等含まれます。ご了承ください。

概要

ビジネスにとってITは「あると便利」から「有効」、「不可欠」を経て「中核そのもの」になりつつあり、柔軟かつ俊敏にソフトウェアエンジニアリングを進める力は企業の競争力の源泉となった。

本セッションでは、そのような競争力あるソフトウェアを開発し続ける力を構成する要素を、品質特性等の側面から掘り下げていく。

なぜアジャイルか

IT は事業のコアになった

1990 年ごろだと IT は「便利」なものだったが、時が経つに連れてビジネスは既存のビジネスモデルから新しいビジネスモデルに変わり、システム特性は守るプロダクト（System of Record）から攻めるプロダクト（System of Engagement）に変化し、ITは「不可欠」なもの、そして事業の「コア」になっていった。

大きく分けて二つのDXが存在する

1つ目のDX

守りのIT、System of Record (SoR)

• 既存の業務の再設計・合理化、コスト削減、正しく記録を行うシステム
• 作らなくてはいけないものをちゃんと作る、OA・FA・RPA
• 現状はこれができていない企業が多いので、これができるだけで優勢

2つ目のDX

攻めのIT、System of Engagement (SoE)

• 新規事業を作り出すためのプロセス、デザイン思考
• アジャイル開発、答えがないものを模索して作り上げていく

PMBOK第7版の大改訂

システムが予測型から適応型へと移行したことがわかる

予測型：決められたものを決められたときまでに破綻なく作る
適応型：だれも答えがわからないものを模索しながら作り続けるしかも答えが刻々と変わっていく

わからないなりにやりようはある

シリコンバレーの「何が」すごいのか（中田 敦さんスライド引用）

体験したことのない製品やサービスを作る方法論

• 体験したことのない製品・サービスを作るには
  • 要件定義の存在しない世界
  • 単純な聞き方では絶対にわからない
• 体験したことのない体験を作るには？
  • プロトタイプとにかく早く作る
  • それを顧客にテストしてもらう
  • 顧客のフィードバックを得る
  • リーンスタートアップ
  • etc...

デザイン思考 + アジャイル開発

シリコンバレーの強みは技術 + デザイン

• リリースした製品は「必ず間違っている」
• 「リリース後の改善力」こそが強み
  • ユーザーの要望に素早くこたえられるソフトウェア開発者が必要＝アジャイル開発

アジリティと品質特性

ウォーターフォールとアジャイルの品質の違い

WF 開発；外部品質（機能仕様）がゴール。フェーズ＆ゲートによるプロセスを重視。
アジャイル開発：利用時の品質（使って価値があるか）の向上が目的。適応力を維持するために内部品質（仕組化・自動化）を重視。

内部品質とは

ソフトウェアの品質を外部指標で特徴づける人は多い。正しいことをする、バグがない、速いなどだ。だが、それらはより深い原因の症状にすぎない。内部品質を作りこんだ結果として、外部品質として定義される特性の実現に近づくことができる。内部品質は結果ではなく原因であり、良いソフトウェアが備えているものだ
（レガシーコードからの脱却（p.58）を引用）

内部品質の損益分岐点

製品の品質と時間的コストを考えたとき、内部品質を改善した場合と改善しなかったときの損益分岐点は1か月以内。
例えば3年後とかの長いスパンであれば、内部品質への投資をするべきか議論すべきだが、一か月である以上、欠かせない品質である。

アジリティと関係の深い品質特性は何か

変更容易性の高いソフトウェアによるアジリティの獲得

DX という言葉には「アジリティ」という意味が含まれていないので、「変更容易性の高いソフトウェアによるアジリティの獲得」というDXの本質がエンジニア以外には伝わっていない

アジリティを支える品質副特性

• Testability
  • これをさらに分割すると
    • 実行円滑性
      • 自動実行が容易かつ高速
    • 観測容易性
      • テスト結果の取得・期待値比較を自動化しやすい
    • 制御容易性
      • 事前状態を制御し、テスト対象を自動操作しやすい
    • 分解可能性
      • テスト対象の切り出し、テスト環境への部分置換が容易
  • これを向上させる戦術
    • システムの状態をコントロールする
    • 複雑さを制限する
• Complexity
  • 意味
    • システムの理解と修正が困難なソフトウェアシステムの構造に関係するもの
  • その兆候
    • 高い認知負荷
      • 任意のタイミングに短期記憶にかかる心的活動の合計量
    • 変更の発散
      • 例えば同様の部分を関数化できておらず、一か所修正しようと思ったらコピペした同様のコードもすべて修正する必要がある場合
    • 未知の未知
      • 知らないこと自体知らない
    • Naming も重要
      • 例えば関数が名前とは乖離した内容になっている場合、問題が発生する可能性大
  • 原因
    • 依存関係
      • 変更の発散
      • 高い認知負荷
    • 不透明さ
      • 未知の未知
      • 高い認知負荷
• Modifiability
  • これを向上させるには
    • 結合度と凝集度を意識する

アジリティの本質

Agile という言葉は名詞ではなく、物事の進め方を形容する形容詞

アジリティーというものは、現実の世界やソフトウェア開発の世界の双方において、変化に対応する、すなわち何らかの行動に出た後で遭遇した未知なるものごとに対処するということなのです。

「何をしたらよいか」というのは誰も教えてくれません。しかし我々はどれにすべきかという精神について語ることができます。これは不確実性をどのように取り扱うかということに尽きるのです。
(達人プログラマー 第二版)

• フィードバックを収集し、それに基づいて行動する
• 「現在地点確認、目的に向けた最小単位の一歩、現在地点の評価と問題の修正」をあらゆるレベルの作業に対して再帰的に適用

決定を可逆にする

決定には可逆なものと不可逆なものがある。
不可逆な決定の場合は慎重に行うべきだが、ほとんどの決定は可逆なもの。最適でない決定をした場合は戻ればよい
⇒ あらゆるレベルの作業に対して決定を可逆にする
戻る技術＝安全に進む技術である

より大きな変化はどうするか

アーキテクチャの特性の中には大きな影響のある部分は2つ。

• テスト容易性
  • テストの大半を総合環境を必要とせずに実施できる
• デプロイ容易性
  • アプリケーションを依存する他のアプリ・サービスから独立した形でデプロイ or リリースできる

安全なデプロイと安全なリアーキテクティング

• Parallel Change: 古い橋を新しい橋に作り替える場合、古い橋の横に新しい橋を架け、作り終えたら古い橋を壊す（先に古い橋を壊してしまうと、対岸に渡れなくなる）
• ストラングラーパターン
  • モノリスからマイクロサービスへの移行
• Blue-Green Deployment

アジリティの本質

優れた設計によって変更が容易になると、あらゆるレベルで躊躇なく調整が可能になる。
それこそがアジリティというもの。

感想

昔とはビジネスが変わり、柔軟さが求められるようになった。市場に常に適応し続けるためには、アジャイル的な考え方であったり、作業やシステムが柔軟さを持たなければならない。
アジリティとは何か、DX・現在のビジネスの特性と照らし合わせて考えたことがなかったので、非常に勉強になりました。