脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック

4章バーティカルスライス

数年前、馴染みの顧客からプロジェクト支援の依頼を受けました。現場に行くと、あるタスクに半年ほど取り組んでいて、何の成果も出せていないチームがいました。

タスクは確かに困難なものでしたが、チームは分析麻痺に陥っていました[15]。要求事項があまりにも多く、チームはどのように全部を満たせばよいかわからない状態でした。同じような状況に陥っているチームは、他でも見かけたことがありました。

さっさと始めることが最良の戦略であることもあります。でも、先を考えて計画することは必要です。先を考えることに積極的に無頓着でいる意味はありません。ただし、計画が足りないことが悪いように、計画しすぎも同じように悪い結果になります。もしすでにデプロイパイプライン[49]が確立されていれば、動くソフトウェアをより早くデプロイでき、ステークホルダーからより早くフィードバックを得られます。どんな些細な小さな機能であってもです[29]。

まず、アプリケーションのバーティカルスライスを作ってデプロイするところから始めましょう。

4.1　動くソフトウェアから始める

ソフトウェアが動くかどうかはどうすればわかるでしょうか？ 究極的にはリリースしてみないとわかりません。デプロイもしくはインストールされて、本当のユーザーに使われて、初めてソフトウェアが動くかどうか確かめられるのです。それでも、最終判断ではありません。開発したソフトウェアが自分の思ったとおりに動いたとしても、実際のユーザーの課題を解決できているかはわからないのです。この問題の解決方法については本書の範囲外です。本書では、ソフトウェアエンジニアリングとは、ソフトウェアが意図したとおりに動作し、動作し続けるようにするための方法論とします ...