年末年始に「継続的デリバリーのソフトウェア工学」を読みました。新年を迎えて、気分を一新して開発を始めるのに良い本でした。
ソフトウェア開発に役立つプラクティスを示した本
ソフトウェア工学とは、ソフトウェアの実際的な問題に対する効率的、経済的な解を見つけるための経験的、科学的アプローチの応用のことである。
1.2 「ソフトウェア工学と何か」
本書では、ソフトウェア開発の現場で役立つプラクティスを、ソフトウェア工学としてまとめています。ここでいう科学的アプローチとは、「特徴づけ」「仮説の定立」「予測」「実験」という形で思考を組み立て、小さな実験を重ねながら、より良い結果にたどり着くように進めることです。
具体的なプラクティスは、「学びのエキスパート」になるためのものと、「複雑さ管理のエキスパート」になるためのものに分かれています。
学びのエキスパート
ソフトウェア工学は、創造的な設計工学であり（製造工学ではなく）、探索、発見、学びのスキルを身につける必要があります。学びのエキスパートになるためのプラクティスには、以下の 5 つがあります。
- 反復的な作業
- 早くて高品質なフィードバック
- 漸進的な仕事の進め方
- 実験主義的であること
- 経験主義的であること
複雑さ管理のエキスパート
ソフトウェア開発では、一個人の頭の中に収まりきらないような大勢の人々が開発に携わるシステムを作ります。技術的にも組織的にも複雑な形に適応するように複雑さを管理する必要があります。複雑さ管理を身につける上で、以下の 5 つの要素があります。
- モジュラー性
- 凝集度
- 関心の分離
- 情報隠蔽/抽象化
- カップリング（結合度）
実践的なツール
上記のプラクティスを実践するために効果的なツールとして、以下の 5 つがあります。特に、テスト可能性は TDD の実践として各所に登場します。
- テスト可能性
- デプロイ可能性
- スピード
- 変数の管理
- 継続的デリバリ
他にも「TDD」や「DDD」、「依存性注入」「ポートアンドアダプター」なども手法として紹介されています。
データに基づく指標
本書では「State of DevOps Report」とその書籍である「Lean と DevOps の科学」で示されている指標、特に安定性とスループットをソフトウェア開発チームのパフォーマンスを評価する指標として参照しています。
- 安定性
- 変更失敗率 (Change Failure Rate)
- エラー修復時間 (Recovery Failure Time)
- スループット
- リードタイム (Lead Time)
- デプロイ頻度 (Fequency)
筆者の関わったチームによる経験や伝聞による評価も重要ではありますが、多くのプロジェクトから広く採取された客観的なデータに基づいて根拠を示すことで、より説得力がある内容になっています。
ソースコードに限らずに広く適用
本書で私が工学という言葉を使うときには、特に限定しない限り、ソフトウェア製作に関わるすべてを指しているということです。プロセス、ツール、文化は、どれもその「すべて」に含まれます。
2.4 「工学 != コード」
本書で紹介されているプラクティスや要素は、特に目新しいものはなくて、正直こういった書籍を読んでいる人にとってはどれも馴染み深いものです。ただ、こうしたプラクティスをただソースコードに対して適用するのではなく、ソフトウェア開発に関わる多くのアクティビティに広く適用して考えるという点が興味深い点です。
例えば、凝集度や結合度、関心の分離に関しては、実際のソースコードを例にした解説もあるのですが、サービスの分離やさらに広げて組織活動の分離についても、こうした考え方を適用しています。
これは「モノリスからマイクロサービス」でもサービス間の結合について触れられていたり、まさにマイクロサービスの文脈では語られてはいることですが、あえて「学び」や「複雑さ管理」のプラクティスとすることで、組織運営など幅広く適用しやすくしているところが面白いです。
また、「工芸と工学と科学」や「実験主義と経験主義」、「凝集性と結合性と関心の分離」など各要素の個別の解説はもちろんのこと、それらを並列に並べて比較することで相対的に見ることで理解が深まるのも良いところでした。
ソフトウェア開発者としての矜持
ソフトウェア開発のプラクティスの解説だけでなく、ソフトウェア開発に従事する者としての考え方や矜持を示す内容も含まれています。
特に 12.3 の「組織的、文化的な問題」では、現場で苦悩するソフトウェアエンジニア対して下記のような文章がありました。
私がソフトウェア開発者や開発チームからよく耳にする不満のひとつは、「上司が何々をさせてくれない」というものです。 (略) 最初に言いたいのは、私たちソフトウェア開発者がよい仕事をするために誰かの許可を求めなければならない理由がどこにあるかということです。 (略) 私がプロのシェフだとすれば、雇い主のあなたも私自身も、こういったことはプロの仕事の基本的な部分だと考えるでしょう。それは、シェフの注意義務の一部です。
12.3. 「組織的、文化的問題」
これはなかなか胸に刺さりますね。組織でソフトウェア開発を行う上では、ソフトウェアエンジニアの理想通りに事が進めないことがあり、ステークホルダーが皆それぞれにベストを尽くしていても、ソフトウェア開発という視点では首を傾げるような決定が行われることがあります。
それでも、ソフトウェア開発のプロであるならば、より良いと思う方法を模索していくべきです。
さらにおなじみのスピートと品質のトレードオフにも話が進んでいきます。
『LeanとDevOpsの科学［Accelerate］』で示されているソフトウェアチームのパフォーマンス分析の科学的手法の正しさは“StateofDevOpsReport”で実証されていますが、スピードと品質はトレードオフではないということはこのレポートで明らかになった重要ポイントのひとつです。（略） 管理職と会社は、「よりよいソフトウェアをより早く」作ることを求めるもので、「より悪いソフトウェアをより早く」作ることなど望みません。（略）長期的に見れば、本物のトレードオフは、「よりよいソフトウェアをより早く」と「より悪いソフトウェアをより遅く」です。「よりよい」を目指すと「より早く」も実現されるのです。
12.3. 「組織的、文化的問題」
現場ではともすれば、目の前の納期やスケジュールに引っ張られて、この「悪いソフトウェアをより早く」が見受けられます。これはその瞬間を切り取ると早くリリースできたように見えても、すぐにでもそのツケは回ってきて、結果的にはその尻拭いのために次の機能のリリースが遠のくということが起こりがちです。
もちろん、ビジネスである以上、ソフトウェア開発の都合だけで理想的にことが運ぶわけではないですが、我々ソフトウェアエンジニアはソフトウェアがより良くなるにはどうすれば良いかという視点は失わないようにしたいところです。
TDD
TDDは、ソフトウェア開発に対する工学的アプローチの土台であり必要不可欠です。本書の考え方に沿って私たちの優れた設計を生み出す能力を後押しし、強化してくれるプラクティスとして、私はTDD以上のものを知りません。
14.4 「テスト可能性を実現する上での問題点」
単にテストを先に書くのでは無く、設計を導くための Test Driven Design としての TDD が何度も登場しています。
私が開発する時にもちろんテストは書きますが、テストファーストでない場合も多くあります。実装に対するテストという意味では後で書くのでも良いですが、良い設計を導くという意味では、やはり先にテストを書くという行為には意味がありそうです。
機能を実装するにしても、変更するにしても、実装の詳細まで書いてしまう前にテストを書いて、それだけレビューするのも良さそうだなと思いました。
よく知られたプラクティスですが、あらためてその価値を見直す良い機会になりました。
あちら側とこちら側
私はテスト駆動開発（TDD）の授業を担当したことがあります。私は設計の複雑さを緩和するためにTDDがいかに役立つかを示そうとして一所懸命になっていましたが、受講者（彼らのことをプログラマーと呼ぶ気にはなれません）のひとりにコードを複雑でなくすることがなぜ大切なのかと質問されたときには、正直なところショックを受けました。
9.2 「設計の重要性の過小評価」
これは実際に開発現場でまま見受けられることです。本書で説いているような考え方の意義を見いだせず、ただ言われたことだから表面的になぞっているだけの場合もあれば、そもそも無駄な事として試すこともしないという場合もあります。
しかし、ソフトウェア開発には色々な方法があり、本書のプラクティスを実践していなくても、ソフトウェアをリリースし、世に価値を提供している現場もあります。実践しているチームでもメンバーによって濃淡はあるでしょうから、本書の内容に大きく傾倒している人もいれば、それほどでも無い人もいるでしょう。
ああ、この人は本当のプログラマーでは無いとしてしまうのは簡単ですが*1、個人的には、こうした人といかに対話し、一緒によりよりソフトウェア開発を実践していくかというパートも読んでみたかったです。
「継続的デリバリー」は 1 要素
タイトルに「継続的デリバリー」が付いてるけど、原題が「Modern Software Engineering」となっているとおり、現代におけるソフトウェア工学の本。継続的デリバリーと付けたことで範囲が狭まっているように見えて、もったいない気がする。内容は良い。https://t.co/nfTX0dVovw
— Masashi Shinbara (@shin1x1) 2022年12月23日
書籍のタイトルですが、原題が「Modern Software Engineering」であり、ソフトウェア開発のアクティビティを幅広く扱っている内容なので、あえて「継続的デリバリー」は付ける必要はなかったのでは、と感じました。*2
正直、最初は継続的デリバリーを軸にした本なのかと思っていました。
タイトルをどうするかはマーケティングの要素も大いあるとは思うのですが、一読者としてはソフトウェア開発に関わる人に広く読まれると良いなと思う内容だったのでシンプルなタイトルで良かったのではないでしょうか。
さいごに
日頃、自分がソフトウェア開発に携わっていて考えている方向性とそれほど違わない内容だったので、何度もうなずきながら読み進めました。
ただ、あらためて認識し直したり、知ってはいるけど実践できていないことだったりを見つめ直すことで、視点というか考え方を正すことができた本でした。
2023 年の年始に、これから開発していくにあたって、良い振り返りができた本だったので、また折を見て煮詰まった時には読み返したいですね。
本書で紹介されているプラクティスに親しみがある人も、はじめてこうした内容を知る人にとっても良いガイドとなる本なので、ぜひ手にとって読んでみてください。
