アーキテクチャの検討を記録するADR(Architectural Decision Records)の方式で、自身が自動化を採用するか検討した。

  • ステータス: 承認
  • 決定者: @niku
  • 日付: 2020-05-19

文脈と問題点の説明

想定する特性や機能といった品質を定義し、その品質を担保していることを確認し、成果物を作成、使いたい人へ送り届けることはソフトウェア開発の重要な側面である。

そのうち自動化が容易で効果の高い、品質を担保していることの確認と成果物作成の部分の自動化をこのソフトウェアで行う。

決定要因

品質担保と成果物作成を自動化した場合、ソフトウェアの費用に比べて効果が上まわるか？

  • 私たちが品質担保と成果物作成を自動化させるにはどのくらい手間がかかるか？（初期費用）
    • しない場合はゼロ
  • 私たちが品質担保と成果物作成の自動化をソフトウェア開発において意義のあるプロセスとして維持し続けるのはどのくらい手間がかかるか？（維持費用）
    • しない場合はゼロ
    • する場合
      • OS や ソフトウェアのセキュリティアップデート
      • 監視やトラブル時対応
      • GitHub Actions や CircleCI などの自動化サービスを利用する場合はかなり抑制できる
    • また、自動化しやすいようなソフトウェア開発プロセスを行わなければいけないという制約が加わる
      • 自動化可能なテストを書く
      • 自動化可能な成果物配信システムを用意する
  • 私たちが品質担保と成果物作成を自動化したらどのくらい役に立つか？（効果）
    • 自動化したものが動くたびに、私たちが担保したいと考えプログラムで表現した性質を守ったものが成果物として提供できる
      • 一般に、コードの書き換えによってソフトウェアの性質を変容させてしまったとしたら、気づくのが早いほど性質を取り戻しやすい
        • 具体的な例：ユニットテストが通らなくなったコミットがわかったら、原因をつきとめやすく直しやすい
        • 具体的な例：処理のパフォーマンスが落ちたコミットがわかったら、原因をつきとめやすく直しやすい
      • ヒューマンエラーを排除できるので成果物の提供が安定する
    • 多くの場合自動化はコミット単位で動作するように設定するので、コミット毎に検査できるということになる
    • 手動で同等の品質担保と成果物作成を行うと仮定する
      • 自動化すると、自動化後の ソフトウェア総コミット数 * 自動化量 の手間が省ける
    • 手動では同等の品質担保と成果物作成を行えず、品質担保と成果物作成の頻度を落とすと仮定する
      • （たぶんよくあるパターン）
      • 自動化はコミットしたものが成果物として提供されるまでのリードタイム短縮に繋がる
        • 手動が 1 日 1 回の実行なら平均 0.5 日のリードタイム短縮、2 週間に 1 回の実行なら平均 1 週のリードタイム短縮
        • 手動で実施することが（経済的に）困難なものを自動化するとリードタイム短縮の恩恵が大きい

検討した選択肢

  • 品質担保と成果物作成を自動化しない
  • 品質担保と成果物作成を自動化する

決定内容

以下の理由により選択肢「品質担保と成果物作成の自動化」を採用する。

  • 一般に製品の寿命が長いものを作る場合は初期費用ではなく維持費用が大きな要因を占める
  • 品質担保と成果物作成を自動化した場合の一定時間あたりの維持費用は低い
  • 品質担保と成果物作成を自動化した場合の効果は ソフトウェア総コミット数 * 自動化量 に応じて増大する
    • 一定時間あたりのコミット数が多ければ多いほど効果は増大する
    • 一定時間あたりのコミット数を増やしても品質を担保できるため、品質のためにコミット数を下げるということをしなくてもよい
      • おおまかにみると、コミット数はソフトウェアが持つ特性や機能の変化量とみなすことができる
      • つまり自動化すると以下を両立して達成できる
        • ソフトウェアが一定時間内に急激に変化すること
        • 変化後も担保したい性質を守れている保証

今回作ろうとしているソフトウェアにあてはめると以下の通りで、上記の一般論にあてはめると自動化の効果が費用を上まわると想定される。

  • 寿命は 1 年以上の長さが予想されている
    • 初期費用は支配要因ではなくなる
    • 一定時間あたりの維持費用と効果を比較してよい
  • 達成したい特性や機能が現時点ではまだ出つくしていないことがわかっている
    • ソフトウェアへの要求が出てから、それを満たしたソフトウェアを供給するためのリードタイムを短くしたいことがかなりの確度で予想される
    • リードタイムを短くするため、ソフトウェアには急激な変化が求められることがかなりの確度で予想される
  • システムに組込まれている他のソフトウェアと緊密に連携することがわかっている
    • 連携相手とスムーズに連携できないとシステム全体に影響が波及する
    • あらかじめ自分たちが宣言している特性や機能を保持し続けなければいけない
      • 品質が保持できているという保証が重要視されている

リンク