ヘロヘロスクラム、内部の質、変化のための設計〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （３）
スクラムは普及したが、それだけではエンジニアは生き生きしないのではないか？という点について深掘りしていきます
昨年１２月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第3弾をお届けします。
対談のこれまでの記事は以下になります。
ヘロヘロスクラムを見かける話
懸田：さて、次の話題がたぶんテーマの根幹だと思うんですけど、そこらへん少しお願いします。
和田：ブログエントリーで一個ずつタイトル並べたみたいな感じですね。じゃあトピック「スクラムは広まったがコードや設計がダメだとエンジニアは生き生きしないのではないか？」。
家永：これはいわゆるファウラーの所のヘロヘロスクラムとかっていうキーワードですね。
和田：角さんが訳したやつ。
家永：和訳があるので、知られてはいるんだけれども、実際僕がアジャイルコーチというポジションで入ると、期待されるところの最初はまずはプロセス面を見るというところがあって、コードまで見るという機会が逆に離れてしまっている。プロセス部分にもまずフォーカスが当たるんだけれども、実際にもう一歩踏み込んでコードを見てみると、「これ大丈夫か！？」とドキッとする機会が何度もある。例えば、僕は（Ruby on）Railsはそんな得意じゃなかったけれども、「これRailsの基本機能を全然使っていない！？」というような機会が実際に何度かあった。ただスクラムにはそこの部分に関して開発チームに任せているというところがある。
和田：フレームワークとしてのスクラムは、そういうやつですね。
家永：そこのメッセージは何も、スクラム自体は無かったりする。実際に初めてアジャイルを知るというルートがスクラムだと、どうしてもそこまで到達しないみたいな現象が起きて、僕がここの永和でずっと学んできたアジャイルのイメージ像と少しかけ離れているという現象が起きていた。自分の中ですごくもやもやとする機会があったりするので、このブログ（『時を超えたプログラミングの道』を書いている。実際にエンジニア、特にプログラマーが多くの時間を過ごすのが実際にコードを読んだりとか書いたりとかですからね。
和田：そうですね。
家永：修正箇所とか、バグが起きた際の障害解析ということで、ログを読みコードを読んで、「ここだろう」というのを調べるという、（プログラマが）多くの時間を割いているところに、何かもう少しメッセージというか重要なことを伝えていかないというところはあった。道具立てとして、それはアジャイルルートを諦めた方がいいのかというのは時々思っちゃったりすることはあるんですけど。
和田：アジャイルルートを諦めた方がいいとは？
家永：何だろう、一番広まっているのはとりあえずスクラムですと。
和田：なるほど。ソフトウェアプロセス、そうですね。
家永：アジャイルというよりはスクラムです。スクラムのメッセージとしては「開発チームに任せます」。
和田：いろいろあるだろうから、開発チームに任せますと。
家永：任せますという、その一言で終わっていて、その先、参照は何をすればいいんだというのは、とりあえず、スクラムからたどり着けないなというのは、ちょっと何だかなという。
和田：つまり、テクニカルエクセレンス、技術的な卓越とか洗練性みたいなやつと、スクラムとの間のリンクが切れているんじゃないかという。
家永：ちょっと遠く感じるな。入るとしたら、完成（DONE）の基準で自動化が入ってきて、それで「リグレッションテストをやっておかないと頻繁なリリースができないので、そこの自動化は重要」というメッセージも入りますと。ようやくなんだけど、さらにもう一歩踏み込んで内部の設計やコードとかにも行きたい。(※1)
(※1) スクラム界隈には「ScrumBut」（スクラムから理由をつけて何かを除く）と「ScrumAnd」（スクラムに更に加える）という用語がある。今回の話題は、ScrumButではなくScrumAndと言えよう。詳しくは『Scrum vs ScrumAnd vs ScrumBut』を参照のこと。
内部の質、エンジニアからの率直なフィードバック
和田：内部の質についてスクラムは言及してなくない？すごい真っ直ぐに言うと。
家永：真っ直ぐに言うと、そうそう。そこの部分をアジャイルコーチとして、自分がずっと学んできた事を伝えていくという際に、（内部の質という）そこまで伝えていきたいんだけど、今はうまく伝えられなくて、自分の中ですごくもやもやとしているという日々を過ごす機会があった。
和田：なるほど。
家永：久しぶりにうち（永和システムマネジメント）のメンバーのエンジニアと組むと、時々ピーンと「ここでコードにこんなに突っ込むのか」というのを気付かされ、逆に自分の感覚が鈍っているという時がある。エンジニアはこのタイミングで突っ込むのかとか、僕がちょっと少し先を読み過ぎて何かやっていると気づかされる。いわゆるKISSの法則(※2)とか、何か瞬間で、そういう判断から今これ要らないんじゃないのっていう、YAGNI(※3)的な判断。
(※2) “Keep it simple, stupid”（シンプルにしておけ！この間抜け）の略 https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87
(※3) “You ain’t gonna need it.”（そんなの必要ないって）の略 https://ja.wikipedia.org/wiki/YAGNI
和田：おじさん的にはYAGNIになったわけ。
家永：（プログラマーが）「やるなら（ユーザー）ストーリーにして、本当に必要があるのか・ないのかを判断してからやるべきじゃないのか」というのをびしっと言うシーン何度かあって、「そうか」というのを経験した。そういう感覚を、エンジニア、プログラマーが価値観というか美学というか基準を持っていて、そこに反しているものに関して率直にフィードバックをするんですよ。僕がPO補佐というポジションだった時に、うちの開発メンバーとやっていると「これをこう砕けるんじゃない？」「これがまだ本当に必要かというジャッジは、まだ早過ぎるんじゃない」というフィードバックをもらって「なるほど」という学びが起きることが実際にあった。プログラマーとか設計者というポジションからすると、普段のアジャイルの中の活動の中で、日常のPOとの会話の中で、何をどの順序でつくるかや、作らないことを決める、ということが当たり前に行われる。こういったことも、もっとうまく伝えていきたい。
和田：なるほど、なるほど。
スクラムの普及と質のブレ
家永：スクラムのアングルだと、最初のフォーカスがどうしてもスクラムマスターになる。（次にプロダクトオーナー）
和田：そうですね。
家永：内外の交通整理役やチームを育てる
和田：チームのマネジメントというか、マネジメントというとトップダウンぽい感じだけど、そうじゃなくてどうやってチームで開発プロセスをうまくオーガナイズ（組織化）していくかみたいなところになる。プロセスのフレームワークとしてスクラムはとても良くできているから、日本の最大多数にリーチしやすかったというのはあって、あとは技術的詳細にタッチしないというのは、やっぱり普及する上ではうまく働いたと思ってる。XPよりは抽象化されたフレームワークとして枠組みとして、かつ部分適用しやすかったというのは、スクラムの普及のカギだと思っていて、だから普及した。
家永：普及という面では、そうですね、スクラムはすごく役立った。
和田：だけど技術的詳細に関しては、技術者に任せてしまった結果、スクラムプロジェクトごとに質のブレがやっぱり大きかったみたいなところはあるんだろうなあというところはある(※4)。例えば、技術的な面に対してスクラムのチーム、スクラムというフレームワークから技術にリーチしていく上では、やっぱり一番最初の接点というのは自動化で、どういうアプローチ、どういう接点かというと、スクラムでスプリント決めますと。スプリントごとにシップできるものを出すためにDONEの定義があって、スプリントごとにシップ（出荷／リリース）できるものをシップしていくよ、という話なんだけど、毎回当然既存のバグというやつは既知のバグはゼロの状態でシップしていこうというとする。開発期間が長くなれば長くなるほど、テストしなきゃいけない項目はどんどん増えていく。これが自動化していないと、スプリントの中も結構な割合をテスト、既存のものをテストする。
(※4) フレームワークには含まれていはいないが、スクラムアライアンスとしては、スクラム上での開発者の技術スキルを高めるコースであるCertified Scrum Developerを別途用意している。しかし、日本では2017年に３回開催されたのみで、かつ、日本語による開催は未だない模様だ。(2018/02/15調べ)
家永：手動の確認で。
和田：仕組みをテストしている気がするみたいな感じになっていって、かつ何かその間に不具合みたいなのが発生したりすると、その不具合を修正する必要が出てきて、最初はスプリントの中で新機能とか、本来プロダクトに価値を与えるコードを書く時間というのは十分取れていたものが、後ろの方のスプリントになればなるほど、どんどん失地を回復するために時間が消費されてしまって、攻めのために時間が使えない。守りのためばっかりに時間を使ってしまっているという、時間の使い方の割合が変わってしまう。(※5)
(※5) このテスト項目の増加を逆手に取った発想として、咳氏の言う「テストの合間にプログラミングする」があるとも言えよう。
変化のための設計は、生き物のメタファー
家永：あとはそうですね、もう一つやっていく時間経過の中で、さっき話したフレームワークの件だと、当初のモデルや設計じゃ要求に応えられないという事に気付いた時に、そこから次に要求に応えられるようなモデル構造にトランスフォームすることが長期間やっていると起きる可能性がある。だけれども、それがせめて外側のリグレッションなのか、そのテストが無い状況だと、「エイヤ」のリファクターなのか、諦めて、既存のやつを、ここはそのまま残しておいて無理やりやるかみたいなことになる。そういう攻めて攻めてこね直してトランスフォームというのができないまま先に進んでしまうみたいな事が起こりがちなのかな？
和田：起こりがちですよね。なのでそういったところがスクラムチームと技術的な課題の接地面になって、そこで初めてテスト自動化というのをどうやっていくのか、テスト自動化だけじゃなくて、そこからどうやって内部の質を高めていくかという話になってくるわけですね。さっき言った、コアのモデルを変更すべき時がやってくるみたいな話というのは、これは基本的には非常に良い事。実際にソフトウェアが使われて、より多様な要望に対して応えられる必要が出てきて、一番初期のナイーブな設計だけでは賄いきれない本当の要件に対して向き合う必要が出てきたというもの。これはたぶん遠からず現れる時期だし、そういうのに対してどれだけ破綻せずにちゃんと適応できるかというのは、ソフトウェアが生き物としてちゃんと生きているかどうか決めるところだと思っている。
和田：そういう変化に生き残り続けて、適応し続けられるソフトウェアを作るというのは、継続的に開発していく上でのソフトウェアの構造の目標だと思う。
家永：もう一つメッセージとして、さっきの小さい組み合わせで要望に応えられるということで、小さいユニットをどれだけうまく独立してうまく動かせつつ、その要望に応えられるかというところの組み合わせというか、そこが設計と呼んでいいのか。
和田：いや、そうだと思う。だから例えば、テスト駆動開発であるとか、いわゆるボトムアッププログラミングや、あとUNIXの哲学みたいな、ああいう思想が何に強みを持っているか、何を大事にしているかというと、結局想定外の使われ方をするとか、最初に想像していたところよりやらなきゃいけない事が変わるとか、そういった時というのは必ず現れるし、それを見越す事というのは、基本的にできない。人間の認知には限界があると思うので、そういった時にカタストロフみたいに動きが全部作り直しになるんじゃなくて、基本的に動いているものというのを生かしつつ、だけど枠組みを変えるとか組み合わせを変えることよって大きい変化に適応する。
家永：はいはい。
和田：だから小さい細胞レベルのものというのは、生き残らせる事はできるけれども、有機物としての形自体はずいぶん変わったものになったみたいな感じだけど、だいたい８割ぐらい生き残っているみたいな状態というのは、唯一変化に適応できる状態というか、適応しやすい状態だと思っている。そういう予想外の変化に対して、破綻せずに付いていくソフトウェア有機体みたいなのを作るというのは、設計上の長期的な目標だなと。
家永：メタファー的には、生命っぽいですね。
和田：たぶんそんな感じじゃないかなと。
家永：生命体のトランスフォームじゃないですけど、生き残るための、実際に使われて役立つ金を稼ぐとか、そういうような、そういう状況を残り続けるために。
和田：特定の状態・状況に過剰適応し過ぎずに、何か割と自分自身の形、総体としての形を割と自由に組み替えながら、でも部品、部品は結構長生きしているというのがソフトウェアの生きていく様として目指したいなと思っている。
懸田：過剰適応せずに！とはいえよく過剰適応しちゃいますけどね。
家永：過剰適応なのか分からないですけど、よく聞くのが営業が売るタイプの、お客さんの要望をあまりにも受け入れ過ぎて、悩みの構造的には、Ａ様対応、Ｂ様対応がif文で分岐する。
和田：OEMやるみたいな。
家永：増えていって、なんだけど、契約が切れてそこのはもう使ってないんだけど、コードの残骸としては残っていて、それを消す機会がないままずっと残るみたいな話はたまに耳にする。
和田：ありますね。結構ソフトウェア製品を企業で作っていくという際に、最初から全部自分たちが書いたものをお客さんに売れるという状態になればいいんだけど、どうしても開発の途中で特定のファーストユーザーとかセカンドユーザー向けに特化した機能を作って、それで開発資金を当たり前だけど頂いて、実際の自分たちの作りたいソフトウェアを継続開発していくという所が多い。ポール・グレアムが言う「ラーメン代を稼ぐ」みたいな話。実際に「ラーメン代を稼ぐ」上での要件というのは、実際に自分たちが本当に必要としているモノと若干ずれてそうな時にソフトウェアの構造としてどうあるべきかというのが、後腐れなく着脱できるような設計ができているかどうかというところに、やっぱり設計の優劣みたいなのが出てくるんですね。
家永：ブロックとして独立していて削除しやすい。時々僕の師匠の天野さんはよく削除しやすいからというのは、それが一つ設計判断と言っている。
削除しやすさ重要！
和田：そうなんですよ。何かね、削除しやすさとか、後腐れなく外しやすいかどうかというのが、設計の質としてあまり認識されてこなかった節があって。ソフトウェアってずっと大きくなり続けて拡大し続けて、何かみんな暗黙のうちに思っていたけど、全然使われないけど残っているコード、デッドコードではないんだけど、それでも全然使われないコードみたいなやつがソフトウェアの中にいっぱい残ってしまって、修正をする際とか新規機能の開発する際に、全体の整合性を取りにくい。
家永：grepで引っ掛ったから、これも対応しなきゃいけないのか、しなくていいのかっていうのが判断分かんないから、不安だから一緒に対応していこうとやっていくうちに、何か複雑になっていくという。
和田：全体の複雑性を下げるとか、後腐れなく消すとか、これはもう要らないなと判断して消すというのって、ソフトウェアが長生きしていく上ではすごい必要になってくるんですけど、そもそも使われているかどうかの判断が難しいとか、いろんな技術的な状況によって何か分からんけど怖いから残すみたいな感じで全体のエントロピーが上がっちゃうという現場がすごく多い。ごくごく最近になって、デリータビリティ（Deletability）とかみたいなのが出てきた。
家永：そんな特性があるんだ。
和田：消しやすさとか、そういったものがソフトウェアのコードの核としてもあるよというのが知られ、議論されるようになってきたのは、割と最近だなと。
家永：機能の消しやすさ、私は天野師匠に教わりましたね。
懸田：消すというのも変化の一つですからね。
和田：そうだと思います。だから他の使い方で済むようになったのは消す。ほんのちょっと、例えば全体の中で３％のユーザーだけ使い続けているものを、他の機能を使うようにナビゲートしていって、その３％使っている機能自体をお蔵入りにして消していくとか、そういった全体の使われ始めてから、実際に多くの人に使われ始めてからのソフトウェアの設計の全体の破綻させずにバランスを取るというのに、だいぶ社会性を伴うアクションになってくる。
懸田：ソフトウェアの置かれている状況によって、設計判断の指針、コアとなるものが徐々に変わってくるんですね。
和田：変わりますね。
懸田：そこの流れを見極めていくかどうかがやはり重要で、状況つまり、自分たちは今どこにいるのかなんですよね。
今回の対談では、スクラムフレームワークでは言及されていない「内部の質」について話が及びました。そして次回は「生き生きしたエンジニアとは？」という体談の最重要テーマに踏み込んでいきます。
