継続的デリバリーのソフトウェア工学
真のソフトウェア工学は、私たちの創造力と、高品質で役立つものを自信を持って作る能力を引き上げます。アイデアを掘り下げ、創造力を伸ばせるようになり、大規模で複雑なシステムを構築できるようになります。
コードは誰でも書けますが、それは私たちの仕事ではありません。ソフトウェア開発はコードを書くことよりも大きな仕事です。私たちの仕事は、問題を解くことであり、そのためには設計に注意の目を光らせ、生み出す解決策の有効性を考えなければなりません。
ソフトウェア工学を定義する試み
ソフトウェア工学とは、ソフトウェアの現実的な問題に対する効率的、経済的な解を見つけるための経験的、科学的なアプローチの応用のことである。
製造工学ではなく設計工学
ソフトウェア産業に製造現場の思考法を応用しようとしてきたが、ソフトウェアにおいて製造は問題ではない
この誤解が考え方やプラクティスの間違いにつながる
製造のフェーズで起きる問題は無視できる
1つ1つのステップを熟知され、反復可能で、予測可能な問題にすることで解決する製造工学は、ソフトウェア製作にはあてはまらない
本書においてはソフトウェア製作に関わるすべてを工学によって指す
プロセス、ツール、文化を含む
工芸と工学
工芸の成果物は情緒的な価値を持つが、人間の能力の限界、精度の限界によって品質や生産速度に制限がかかる ソフトウェアで偉大な仕事を生み出したいなら異なる思考様式が必要 工学がもたらすのは
クラフトマンシップを主張する職人の多くは、「工学は生産・製造の問題を解決するものだ」（製造工学とみなす）という誤りを犯している 工学をコードの同義語と見るか、過度に官僚的で煩雑な手続きを連想させる一般的な誤解もある
必要な2つの姿と10のコンセプト
学びのエキスパート
反復的作業 / iteration
ウォーターフォールでは時間と共に変更コストが高くなるという前提にたつ
この世界観には問題があり、重要な判断をプロジェクトの最初期に下さないといけない 知識はあとでふくらむので、死活的な意思決定を足りない知識からの当て推量で行うことになる
変更コストの曲線が平らになればいい
学ぶためには各段階を圧縮して反復的に作業を進める必要がある
計画の誘惑
ウォーターフォールの世界観が真っ当に聞こえる問題
「始める前に慎重に考えよう」「綿密な計画をたてて、忠実に実行しよう」というのは工業化時代の経験から信奉される言葉
自分を動かしているパラダイムが根本的に間違っていることを認識するためには、知的な飛躍という困難な作業がともないます
一方、実際の製造現場では柔軟性が重視されるようになっている背景もあり、"古い製造工学"を参照している可能性もある
ウォーターフォールの世界観や計画思考にしがみつくのは楽観的な考え方
技術面の話だけでなく組織面においても間違いなく重要、むしろ組織がモジュラーであることで、驚くべき速度で成果を出せる 自由な創造を許し、許可を得ずに方針を変更できる
小規模なチームが大規模なチームよりもパフォーマンスが高いことは古くから知られている 結論は簡単だ。200人のプロジェクトにもっとも有能で経験を積んでいるプログラマーでもある25人の管理職が含まれているなら、残りの175人をクビにして管理職をプログラミングの仕事に戻せばよい。
漸進的な設計
科学とは、専門家は無知だと固く信じることである。
権威に対していかなる敬意も払ってはならない。誰が言ったかを忘れ、彼がどこから出発してどこに到達したかを注視し、「それは理にかなっているか」と自問自答しよう
プロセスの第1は当て推量です！当て推量が実験と一致しなければ、それ（当て推量）は間違っているということです
この学びこそが工学
コードでの実験を促進するのがテスト駆動開発
初心者のコードと達人のコードで最も大きな差が出るのはモジュラー性 多くの人が「モジュラー性を実現できていない」だけでなく「モジュラー性を実現しようとしていない」
言語やフレームワーク、エディタ、プログラミングパラダイムのいずれも、ソフトウェア品質にとってモジュラー性や関心の分離ほど重要になることも根本的な意味を持つことはない
工芸から工学に進むための能力の増幅器
チームに人員を追加したからといってチームの作業スピードが上がるわけではないことを示した研究
小さなチームが並列に生産性を高くすることで大きな成果を組織としてうみだせる
コードの第1の目標は、人間に考えを伝えること
Aを書き換えたからというだけでBも書き換えなければならないなら、結合度が高い（カップリング） Aを書き換えたときにBも書き換えると両者が新しい価値を生み出せる場合、凝集度は高い 最初に言いたいのは、私たちソフトウェア開発者がよい仕事をするために誰かの許可を求めなければならない理由がどこにあるかということです。私たちはソフトウェア開発のプロなので、どうすれば成功し、どうすれば失敗するかをもっとも的確に判断できるはずです。
機能するコードを書かなければならないが、同時に長期にわたって信頼できる形でコードを開発できる状態を維持できる必要がある
レストランのシェフが料理を1つ作り終えたあとに料理器具や作業スペースを掃除しないようなもの
顧客は食中毒になるし、2つめ3つめの料理を作るにあたって放置したものが仕事の邪魔になって生産性が下がる
これは注意義務
シェフとして雇う人がいちいち掃除しろとは言わない
抽象化の最たるものだがうまくいったことはない
複雑なソフトウェア開発は初期に想定した構造や枠組みを変えなければいけないシーンが来る
開発を通じて学んだことで置き換えが必要になるが、大きな骨組みを変えたり、あるいは維持しつつ細部の変更を完全に制御するというハードルを越えられなかった
旧来のソフトウェア開発で時間をかけて発展させたものが使えないことが多い
計測
ソフトウェアの開発生産性に関する完全な尺度は存在しない 大きくは2つの属性がパフォーマンスと相関する
ohbarye.icon まったく新しい手法や概念を提唱するものではなく、ソフトウェア業界の数十年の進歩と2021年時点におけるプラクティスを1冊にまとめた本。特にソフトウェア工学を定義することに注力しており、工芸的・クラフトマンシップ的な世界観から脱却して高品質で高速に製品をデリバリーすることを主張している。ソフトウェアにおいて製造の工程はほとんど存在せず、製造工学ではなく設計工学であると言う主張は合点がいった。