アジャイルの「顧客に価値を届ける」の嘘と本当
酔った勢いでアジャイルについて思うところを書く。
顧客に価値を届けるのは誰か
顧客に届く価値 = 目に見える成果物、という評価は、フロントに近い人間しか評価されなくなる傾向を抱え込む。顧客に価値が届くまでには段階がある。複雑なものほどワークフローが長大になる。お互いの価値を見積もれるのは、小さいチームでお互いの職種について理解がある場合の理想であり、多くの場合理想は理想である。大きなチームほど、フロントに遠い人間は自分の価値を伝えるのが難しい。
難しいことを難しいということ
エンジニアが自分の仕事について、エンジニア以外への責任説明を果たそうとすると努力は必要だが、必ずしもそれが伝わるとは限らない。
難しいことを難しいと言えないと、「それってすぐできるんでしょ？」という展開になりがちで、「任せてくれ！」と言えるのはかっこいいが、誰しもがスーパーエンジニアではない。そして見積もりに失敗する。炎上する。
テスト リファクタリング
テストを書くことや、リファクタリングをすることによるエンジニアの脳内の「開発速度曲線」は、エンジニア以外に伝わらない。納期に間に合わせたいなら信頼して任せてくれ、というしかなく、そして大体の場合断られる。それに真に共感できるのは、それを必要とするエンジニアだけである。そしてマネージャからは自己満足的なリファクタリングと必要なリファクタリングを区別する方法がない。信頼されるか、否か。
テスト駆動はエンジニア以外(正直ほとんどのエンジニアにも)には理解されない。基本的に、未成熟なチームの場合、テストを書く時間がタスクの中に見積もられない。タスクが遅延した場合、テストを書く時間はまっさきに削られる。さらに急いで作れと言われた場合、テストは欠損する。
マーフィーの法則。せめてモデルだけはテストを書いてくれと頼んだ場合、モデルにあるべきコードがコントローラに書かれる。
言語とテストフレームワーク
RubyがTDDをやりやすいのはRSpecの改良の賜であり、同じ哲学を他の言語に持ち出すと破綻する。RubyでもWAFは破綻する傾向がある。
ビューと密接に関わるJSやテンプレートを内包したPHPは、最初からテストの困難性を内包している。「ロジカル」でなく「フィール」に関わるプロパティは、そもそもロジカルにテストすることがナンセンスである。
テストが無駄だということではなく、ロジックと感情を分離する手続きにこそ価値が置かれる。趣味でスパゲッティコードを作ってしまった経験や、モナドや関数型言語の経験はこういう場所に活かされる。
コード品質とチーム
言語理解とコード品質にしか興味が無い人は、エンジニア以外からは疎まれるが、持続的な開発速度を担保するためには必要な存在であると思う。
8人のエンジニアがいたら1人はそういう人間である必要がある。コードを監督する立場にある人がコード品質に興味が無い場合、コード量に比例して破綻するリスクを背負い込む。
