デッドラインは面白い

　「デッドライン―ソフト開発を成功に導く101の法則」を1週間読んで、はまっている。
　興味のあるフレーズは下記のとおり。

【１】優れたプロジェクトはデバッグに費やす時間がはるかに少ない。設計に費やす時間がはるかに多い。
　　殆どのバグはインターフェイスの欠陥に原因がある。その原因を解決するには、設計段階で欠陥を除去すべきである。

【２】あいまいな仕様書は、ステークホルダー間の対立を解決できなかった証拠である。

【３】理想の人数配分は、設計は少数精鋭で始めて、実装とテストで大量の人数を投入すること。
　　設計で人数が多いと、全員に仕事を与えなければならないので、作業グループ間のインターフェイスを最小化できず、重要な設計作業を省略せざるをえなくなる。

　僕個人の少ない経験からしても、下記のように肯く事ばかり。

【１】あちこちの勉強会で知り合った優れたプログラマは、デバッグせずにログ出力だけでプログラミングしている。彼らは、デバッグしなくても、プログラム内部のロジックを全て理解できているから。
　　テスト駆動開発も、テストがインターフェイス設計になっている所が重要であると思う。

【２】ユーザ企業のシステム部とSI企業のSEの間には必ず、お金と時間に関する対立がある。SEが対立を解決する役割を担うには、現実の制約条件から、ユーザの要望を実現できる機能へ一つずつ切り分けていく技術が必要になる。
　SEに要求される技術は、プログラミング技術よりも、業務フローの洗い出しと細分化にある気がする。

【３】この事実は僕の現場にいる人は結構知っているようで実践されている。だから、プログラマは日雇い労働者の立場に追い込まれている。

　ソフトウェア開発を掘り下げていくと、プログラミング技術だけでなく、チーム運営手法や業務フロー分析まで行き着いてしまう。
　結局、マネジメントとは何か、ビジネスとは何か、という問題をどこまで深く考えて本質を理解しているのか、が問われている気がする。