行き着く先は“美しさ”。汚いコードにプルリクエストは送りたくない　プログラマーがシステムに関わりやすくするための仕掛け

エンジニア界隈で最近聞かない語彙

東口和暉氏（以下、東口）：「生きている語彙」という表現があって、使われなくなった語彙という点ではストーリーアクセプタンステストやアジャイルアクセプタンステストが確かあった気がするんですけど、この辺はこの界隈では最近聞かない感じなんですか。

kyon_mm氏（以下、キョン）：そうですね。ストーリーアクセプタンステストは聞きますけど、ストーリーアクセプタンステスト駆動開発みたいな言われ方はしなくなりましたね。スクラムの界隈では、バックログアイテムに対してアクセプタンス・クライテリアを書きましょうという文脈ではストーリーアクセプタンステストの言葉自体はけっこう使われるんですけど、そこにテストドリブン・デベロップメントは付かないかな。

例えばJIRAのチケットにアクセプタンス・クライテリアとしてのストーリーアクセプタンステストをバーッと書いて、それが『SPECIFICATION BY EXAMPLE』に書かれていたとしてもそれをテスト駆動開発でそのまま活かすということは、あまり盛んではないと思いますね。

もちろんやっている人たちはいて、JIRAじゃなくてFitNesseでやりましょうとか、JIRAからCucumberのファイルを生成しましょうとか、.futureファイルを生成しましょうとかあるかもしれないですけど、あまり盛んな話じゃないかなと思いますね。

東口：「ストーリーテストドリブンデベロップメント」でした。言葉を間違えていました。ストーリーアクセプタンステストはけっこう使っていますね。

キョン：そうですね。

東口：これは言葉がでてきただけで、あともうちょっとあったのでどんどんわかんなくなってきましたね。

キョン：（笑）。

東口：3文字の略語が多すぎて。

（一同笑）

キョン：確かに多いですね。現代よく扱われる単語は今聞いてくれているブロッコリーさんが翻訳をしてくれた『Agile Testing Condensed』というよい本があるので、そこを見るといいと思います。

東口：メチャクチャよい本でした。

キョン：2時間でわかるアジャイルテスティングという感じがしますよね。

東口：書評でもメチャクチャ感謝の意をいっぱい書いたんですけど、あれで大枠がつかめていろいろと考えることができました。メチャクチャよい本だなと思ったのでJapanese Editionのほうをホワイトボードに貼ります。

キョン：Japaneseになっていると人にも薦めやすいですしね。

東口：確かに薦めやすいですよね。「英書だけどちょっと読んでみて」は、なかなか薦めづらいですよね。xUTP（『xUnit Test Patterns: Refactoring Test Code』）は薦めたいけどあまり。

キョン：薦めにくいですよね。

東口：マウンティングみたいになっちゃうから。

キョン：そうそう（笑）。

設計したものがそこに生まれる意味はなにか

東口：「この資料の頃はAlexanderを意識されたんですか？」という質問がありますけど。

キョン：2013年に楽天Tech Talkに登壇したときのことですね。「自動テストの誤解とアンチパターン」のときに考えていたか…今ほどはAlexanderのことは意識をしていないですね。この頃は『パターン、Wiki、XP』と、『パタン・ランゲージ』と『時を超えた建設の道』を読んではいるけど、それがソフトウェア開発の、しかも自分の明日の行動に関連しているんだと考えるまでのレベルでは、ぜんぜんなかったですね。

東口：なるほど。どの辺から実際の行動につながったんですか？

キョン：私は前職でオンザロードという会社にいて、2017年からデンソーさんと一緒に仕事をする期間がありました。パブリックな情報なので公表しても大丈夫なんですけど、そこでMaaSのPoCをやろうという話がありました。大規模なMaaSや自動運転をやるのは2021年でも来ていないじゃないですか。

それを本格的にやるので、2025年や2030年向けのPoCだったんですよ。単に2030年にこれが実現できたらいいね、じゃなくて、車は20年間とか走るので、2030年からということは2050年までをサポートしないといけないんですよ。だから2050年までを想定した2030年時点でのMaaSのPoCをやろうというのを2年ぐらいやっていました。

どんなアーキテクチャにするのかとか、どんな概念モデルを作ればいいのかと自分がすごく苦労したんですよね。今まではアーキテクチャというと要件があって、その要件に対して、例えばここにRDSを置いて、ここはDynamoがいいからここにキューを置いて…とやっていたんですけど、それは1、2年ぐらい開発の保守をするという前提があるからなんですよね。

20年後や50年後にどうこうとかいう話じゃないわけですよ。これは変わらないモデルだよねとか、ここは変えないといけないよねとか、あとから見たときにここは揺るがないじゃんとか、そういう話ができるようにする必要がでてくるわけです。

東口：なるほど。

キョン：思い付きじゃなくて、それはそもそもどういうふうに考えるものなんだろうかと。どうやって整理したらいいのかがぜんぜんわからなくて、デザイン自体を学びたいなと思ったときに「あ、Alexanderだな」と思ったんです。

東口：なるほど。

キョン：4ヶ月ぐらいやったあとにそれに気づいて、3冊目の『THE NATURE OF ORDER』第1巻を買いました（笑）。

会社で『THE NATURE OF ORDER』を読むようになって、それで15の幾何学的特性を使ったシステム設計をするようになったというのが2017年、2018年ですね。

東口：なるほど。数理的システム設計に行き着いていくんですね。

キョン：そうですね。

東口：「自動テストの誤解とアンチパターン」は変わらないものを見極めて決定を遅延させるという考え方の資料だったと記憶をしているんですけど。

キョン：そうです。

東口：この期間の時間軸のスパンならすごく現実的に必要とされていた課題感だったんだなとメチャクチャ理解しています。

キョン：そうなんですね。

（一同笑）

キョン：「作り直せばいいじゃんじゃないんだよ！」みたいな。

（一同笑）

東口：なるほど。

キョン：だってPoCだからいいんですけど、「じゃあこれで決定ですよね」となったとして、2020年とか2025年とかに本番用として作られた概念モデルが実は5年しかもたない概念モデルでしたとなったときに、デンソーが15年保守しないといけないものを5年で捨てるという金額インパクトはヤバイじゃないですか。

東口：なるほど。メチャクチャ心がタフなアーキテクチャ設計ですね。

キョン：そうそう（笑）。このときにお客さんから「どういった振る舞いを考えるんじゃなくて、それを設計して何かができたときにそこに生まれる意味はなんだ？」とすごく言われたんですね。例えばIoTデバイスからメチャクチャメッセージが来るから、ここにキューを置いておいて、そこから一部を各種アプリ提供者に配信したとする。

それでIoTデバイスからいろいろなサービサーにメッセージを送ることはできるんだけど、「ここのキューはどういった意味なんですか？」と言われる。

東口：ほうほう。

キョン：技術的には単純にバッファリングをして直列化をするというだけなんですけど、それを置く意味はなんだろうと考えたことがあまりなかった。もうちょっと一歩踏み込んで言うと、例えば50年間になると技術的進歩はものすごいじゃないですか。たぶんないとは思うけど、莫大にインターネットの帯域が増えたりとか、莫大にメモリや計算方法が進化したりしたときは、そのキューである意味がなくなる可能性があるんですよね。

もうちょっと違う例で言うと、Webソケットをやっているけど爆速インターネットになった瞬間にWebソケットをやる必要がそもそもなくなるみたいな感じ。そうなったときにその技術はキューを置きますとか、ソケットを置きますとか、HTTPでポーリングをしますというのはまったく意味をなさなくて、結局それはアーキテクチャ図上でいうと何の意味を達成しようとしている箱なんでしたっけ？　となる。

東口：なるほど。

キョン：それをもっとも安く構築できるオプションが、AWSのサービスを使ったキューイングシステムなんですよね。「守るべきものはその意味だ」という考え方をこの2年間ですごくで学びながら、それが数理的システム設計というかたちで昇華しました。

東口：なるほど。確かに時間軸をメチャクチャ長く取ると、今はそこに意味があると思ってしまうけど、なくなる可能性があるということですね。

キョン：そうですね。あまり抽象的な話をできていないよねということです。本当に何をやりたいのかわからずに、とりあえずトンカチを持ってきて、トンカチでここをうまく殴ればうまくいきますからとトンカチを置いているだけで、そのトンカチの意味はなんですか？　という。

東口：なるほど。メチャクチャ難しい哲学的なところから踏み込んで。

キョン：そうなんですよ。例えばポーリングでバッチがあるのはよくあって、定期的に動くバッチをどうやって起動するのかとか、どうやって同期タイミングを取るのかとか、そこの時刻ってどうするんだっけと考えて、これで定期的に動きますというのはわかる。

でもそれはどういった意味があるんですかという話になって、我々が1つ結論としてたどり着いたのは、「時計を置かないといけないんだ」ということなんですよ。時計は誰が見ても何時ってなるけど、本当に大切なときはこの時計に合わせましょうとなるじゃないですか。

だからリアルタイムのズレはどうでもよくて、みんながこの時計に合っているということが重要なんです。この時計を基軸に、みんなが生活をするから多少ズレていても成り立つんですよね。「だからその時計がこのシステムにないとダメなんですね」という概念を作り出して、実装としては時計システムからいろいろなところにメッセージを送って時刻の同期を取る。

時刻を取るタイムスタンプはそこから必ず取るようにすることで、システムの時刻の統一性を図る。それは実は別になんでもよくて、それが仮にNTPの同期で時計というのはここにあると置くことが大切だということを考えていましたね。

東口：なるほど。OOC2020の資料をそうやって見返して「なるほど」という気持ちに今なっています（笑）。

（一同笑）

システムアーキテクチャのシステムを生成するのが大切

キョン：例えばこういったやつ（スライドの図）が作れるようになったのは、『THE NATURE OF ORDER』を仕事で読み始めてからですね。プロジェクトが始まって4ヶ月は気づかなくて、読み始めてからさらに4ヶ月から6ヶ月でここまでたどり着きました。

東口：それまである程度はAlexander氏の本は読んでいて、その上でさっきの『THE NATURE OF ORDER』をバッと読んだ先にたどり着いた感じなんですね。

キョン：そうですね。

東口：なるほど。ソフトウェア開発における実践に落とし込むというプロセスにどう至ったんだろうかとすごく気になったので。もともと課題ドリブンなところで問題があって事前のインプットからのふっとしたひらめきで、出てきた1つのきっかけをかたち作った結果が、こうなったというプロセスなんですね。

キョン：そうですね。

東口：Alexander氏のプラクティスという考え方をソフトウェアに適用する過程をまだやっている途中なんだろうなと思っていて、その中でじゃあどうやったら1ソフトウェアエンジニアとして、これを1つの実践の話として落とし込めるんだろうと思って聞いてみました。そういうことだったのかと思いました。

キョン：ありがとうございます。変わらないものを探すというのも1つですし、最近はちょっと逆です。超新星爆発を起こすための元ネタをつぎ込む行為としてはこういうことは大切なんですけど、それだけだとダメで。

これをやっていくことによって、このあとに何が起きてほしいかというと、これが自ら変容していくこと。システムアーキテクチャのシステムを生成していくことが大切。

プロダクトオーナー、スクラムマスター、テスター、アナリスト、決裁権を持っている人、ぜんぜん違うビジネスパートナーの人たちが、どうやったら自然にこのシステムをより拡張させたり、より生き長らえさせたり、よりよくしていったり、インスパイアされて相互補完していったりするだろうか。

そういうことを起こしていかなければ、このシステムを作る意味があまりないわけですよね。それで考えると、非常に難解に思えるこういった意味を詰め込んでいく行為の次の生成的なプロセスは、プログラマーの世界でプルリクエストを送りやすくする、みたいなことがまさに必要になるわけです。美しすぎたり、完璧すぎたりするとプルリクエストを送るハードルが上がるじゃないですか。

東口：なるほど。

キョン：じゃあ汚いコードだとプルリクエストを送りたいのかというと送りたくないんですよね。そこをどうやってデザインしていくのかも大切なんです。頑健な変わらない部分、変わる部分を見極めていく、意味を作っていくというのも大切なんですけど、その上で例えばプログラマーがシステムに関わっていきやすくするための仕掛けは何だろうと考える。

プロダクトオーナーが要件を言いやすいとか、ここの要件は守りたくなるとか、愛着をもちたくなる、投資をしたくなるようなシステムのデザインはどういうものだろうか。プログラマーとやりとりをしやすくするためのシステムのデザインはどういうものだろうか。他の会社の人がこのシステムとこのエコシステムに入り込みたくなるようなデザインとは何だろうか、という観点が生成システムには非常に重要なんです。

それこそがAlexanderが言っていることで、そういう面での取り込み方ももちろんあると思うんですよね。さっき言ったプルリクエストを送りやすくするシステム開発って何だろうと考えるのもそうだし、ただ単純に、我々の経験からプルリクエストはこういうふうにすると送りやすいよねと考えることもできる。

ある種のルール作りやドキュメント作りはもちろんあると思うけど、そこにセンターや、15の幾何学的特性やセンター同士の補完関係や相互補完関係を見出していく。そうすると、具体的なプラクティスや具体的なプロトコルがいったん変わったとしても、ここの幾何学的構造さえ保っていればその生成システムは成り立つんですよね。

それが生成システムとしてのある種のセンターであり、生き生きとしたまさしく生命の名前になっていくというのが『THE NATURE OF ORDER』を実践していくことかなと僕は思っていますね。

東口：なるほど。完全にAlexanderの建築デザイン感を実現するみたいな感覚をもちました。

（一同笑）

キョン：ありがとうございます（笑）。

東口：生き生きとした生活を送るための建築を作るという課題、価値観が、ソフトウェアに関わる人たちが生き生きと輝けるということをメチャクチャ言語化したら今のキョンさんの説明になるんだな、なるほどなと思っていますね。

キョン：ありがとうございます。

東口：確かに行き着く先は美しさになっていくなと。セミラティス構造になっていくし、センター同士の補完は起きてくるし。メチャクチャソフトウェアの発展的な適応をメチャクチャ言語化されていて、すごいなと普通に思った感じです。

キョン：ありがとうございます。