ヘロヘロスクラム、内部の質、変化のための設計〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （３）

ヘロヘロスクラムを見かける話懸田：さて、次の話題がたぶんテーマの根幹だと思うんですけど、そこらへん少しお願いします。 和田：ブログエントリーで一個ずつタイトル並べたみたいな感じですね。じゃあトピック「スクラムは広まったがコードや設計がダメだとエンジニアは生き生きしないのではないか？」。 家永：これはいわゆるファウラーの所のヘロヘロスクラムとかっていうキーワードですね。 和田：角さんが訳したやつ。 家永：和訳があるので、知られてはいるんだけれども、実際僕がアジャイルコーチというポジションで入ると、期待されるところの最初はまずはプロセス面を見るというところがあって、コードまで見るという機会が逆に離れてしまっている。プロセス部分にもまずフォーカスが当たるんだけれども、実際にもう一歩踏み込んでコードを見てみると、「これ大丈夫か！？」とドキッとする機会が何度もある。例えば、僕は（Ruby on）Ra

[tomiyanx]

“後腐れなく着脱できるような設計ができているかどうかというところに、やっぱり設計の優劣みたいなのが出てくるんですね。”

[kawa-_-kawa]

おぉぉ！　／“何かね、削除しやすさとか、後腐れなく外しやすいかどうかというのが、設計の質としてあまり認識されてこなかった節があって。”

[amapyon]

プロセスも大切だけど、エンジニアリングのスキルが高まれば、もっと活き活きできる！

[usadamasa]

“そういった全体の使われ始めてから、実際に多くの人に使われ始めてからのソフトウェアの設計の全体の破綻させずにバランスを取るというのに、だいぶ社会性を伴うアクション”

[kakeda]

（生き生きとしたチームが）生き生きとしたプロダクトを作り、生命のように進化できる設計を目指す話。