新規開発では理想どおりにならないことはよくある
成瀬允宣氏：さぁ、じゃあやっていきましょうか。（コメントで）「Javaより時代はKotlin」。そう、Kotlinね、そうですね。今回はアーキテクチャの話なので、たぶんKotlinとかでも使えると思います。
（コメントで「設計の講座助かります！」）設計の講座はなかなかないですからね。あと、今日最後のほうで「次何やろうか？」って話もしようかなと思っているので、もしよければ、そのときに僕の相談に乗ってください。
よし、じゃあいきましょう。「先行開発！Javaでクリーンアーキテクチャ」。一応JavaではありますけどJava以外にも使える話なので、ぜひともご自身のプロジェクトに当てはめてやってみてください。
今回はキャッチコピーを決めてあります。どういうキャッチコピーかというと、「APIはできてないし、データベースは構築どころか選定も済んでません。だけど、納期だけは決まっているので、よろしく！」。こういうのはよくあるよね。
ただ、ちょっと茶化していますけど、新規開発だとこれはよくあることだと思うんですよね。だって、みんなで「よーい、どん」で同時に開発を始めると、結局APIもデータベースも構築が始まっていないわけだから、まだ何も用意されていない。その段階からプログラムを作り始めなきゃいけないんですよね。
今Twitterで見ましたけど、「YouTuberの生配信って感じがするー」、よかったー。あと「Javaの人間じゃないけれど、勉強になりそう」、まさにそうです。Javaでなくてもできます。
（スライドを表示して）この図を見てほしいんですよ。みなさん、わかりますかね？ この図にこう縦に線を引くわけですよ。そして日付をつけるわけですね。フロントとかAPI。進捗表です。このときの進捗表がどんな感じになったかというと、こんな感じです。上フロント。下API。
これを見ておもしろいところは、フロントができたあと、APIが完成するんですね。つまりシステムテストにフロントは関わらない。修正ができない。「ちょっとこれおかしいんじゃない？」という話がありました。おかしいので、これについてはもちろん、いろいろ修正は加えてもらったんですけど。
ただ、普通だったら僕ら、APIができて、データベースができて、それらができあがったあとに、我々、いわゆるフロントエンド側がこれをコーディングする。これが理想なんですね。でも、本当に理想のラインはこの「APIができて、そのあとフロントが開発する」。これが一番素直できれいなかたちです。
でも、現実はこれだから。僕の前にあった現実はこれ。別にそれに文句はなくて、こんな感じでもろもろの事情によって、やっぱり理想どおりにならないことがけっこうあるんですね。
納期と試行錯誤
もう1つの問題があるんですよ。どういう問題かというと、プロジェクトリーダー、プロダクトオーナーとかが「画面はこんな感じでお願い」ってきました。そうすると僕とかは「OK、わかりました。やります、やります」。って言ったあと、しばらくして「できましたー」ってもっていくんですね。そうするとだいたいよく言われるのが「うーん、イメージと違うなぁ」って。「やっぱこっちでいい？」「!?」。
よくあるよね。よくある（笑）。別にこれはプロダクトオーナーとかが悪いわけじゃないんですよ。何がいけないかというと、そもそも人間が想像だけで最終形にたどり着くのはすごく難しいんですよね。
だからこんなことを繰り返すわけで、デザインってやっぱり必要なものがあるんですよ。きっとみなさんも何度もやったことがあると思います。プログラムとかでも、最終的にはこういうかたちになる、最終形がわかっているんだけど、そこにたどり着くまでに試行錯誤をするわけですね。
だから、デザインだって同じなんですよ。「プログラムをきれいに書きたい」「こういうふうに書きたい」、そこにたどり着くまでの試行錯誤があり、デザインにもこういうふうにお客さんを誘導したいという、最終的なかたちまでの試行錯誤が必要です。
その試行錯誤のために何をすべきかというと、今回Webの話なんですけど、我々はやっぱりフロントの、とりあえずユーザーが触れる部分のプロトタイプを早く作ろう。とにかく早く作らなきゃいけない。これが今の「やっぱりこれで」というのに対応するには、どんどん作り直して、触らせて、どんどんFIXまで近づけるのが大事なんですね。
私の前にはこの現実がありました。「早いところやらないと間に合わない」という納期と、「試行錯誤させてあげたい」という気持ちですよね。
そのときにじゃあどうすればいいと思ったのかというと、結局はクリティカルパス、例えば我々がAPIを作ってくれるのを待っていますという、そういうのを避けたり、あとは「APIとかデータベースがないからプロトタイプを作れません」じゃなくて、とりあえずプロトタイプだけ作って、そこになんとかして後からうまいことつなぎこむ。そんな方法がないか、と。
メリット・デメリットがわかれば取捨選択ができるようになる
いろいろ調べたところ、まあ僕は知っていたんですけど、これ見つけました。（スライドを表示）みなさん、今回のテーマ、この図、見たことありますよね？
新規開発のプロジェクト。納期もタイト。でも、プロトタイプをいっぱい作らせていろいろ触らせてあげて、ちゃんといいもの作らせてあげたいという気持ちがありました。そこがゴールです。
そこのゴールにたどり着くために、今回みなさんに、クリーンアーキテクチャをどうやって使うのか、そのための概要と、重要なのは概要だけじゃなくて、そこにあるメリット・デメリットは何なのか。そのお話をします。
（コメントで）「どうでもいいですけど、今回成瀬さんはズボンをちゃんとはいているんですかね？」。はいています。拾っちゃったじゃん。そんなどうでもいい話を（笑）。
このメリット・デメリットをみなさんが把握すれば、きっとアーキテクチャを取捨選択できると思うんですよ。僕、いろいろとこの業界でやってきて、アーキテクトみたいな立場やっているんですけど、アーキテクチャって取捨選択だと思っています。
そのまま全部もってこれる……デザインパターンとかもそのまま使えないですよね。でもデザインパターンの考え方は大事だから、それをうまいこと当て込む。アーキテクチャもうまいこと当て込む方法をどうすればいいか？ それを考えたりする。それがアーキテクトの役目だと思っています。じゃあ、みなさんもそのメリット・デメリットがわかれば、取捨選択ができるようになるでしょう、というのが今日のお話です。
というわけで、アジェンダはこんな感じです。順番に、まずクリーンアーキテクチャの概要をお話しします。たぶんご存じない方も、名前は聞いたことあるけど、どういうものなのかわからない方もいると思うので、説明します。
そして、概要から落とし込んだ実装例を今回お見せします。その後に最後、課題と解決。クリーンアーキテクチャにあった課題、実装したときに見つかった課題、それを解決するためにどうすればいいか。今回新規のサービスを作るときに僕のやったことをお話ししようと思っています。
ヘキサゴナルアーキテクチャをゲーム機に例える
まずクリーンアーキテクチャ概要からいきます。まず、みなさん、先ほど示した図は見たことあります？ 実を言うと、もしもクリーンアーキテクチャを勉強したいんだったら、僕はまずこの図の前に、次のスライドのこっちを勉強したほうが早いと思っています。
何かというと、ヘキサゴナルアーキテクチャというアーキテクチャの図です。ヘキサゴナル、六角形なので六角形の形していますよね。こういうアーキテクチャです。
実際どういったものかというと、順番に説明しますね。まず真ん中、Application、オレンジのところは何かというと、ここがビジネス。我々のいわゆるビジネスロジックというもの。このビジネスを中心に見立てて、それ以外のものを交換可能にしようというアイデアです。
見たことある人、けっこういますね。（コメントで）「むしろほかの図見たことない」（笑）。そうですね、今日その話をしますわ。
この交換可能、プラガプルとも、別名「ポートアンドアダプター」とも言われます。どういったものかというと、コンセントを差すところと、プラグですね。
例え話しましょう。テレビゲームを思い浮かべてください。テレビゲームってあるじゃないですか。ゲーム機があって、あとコントローラとディスプレイがあります。
このコントローラとかディスプレイって、もちろん純正品がありますけど、それ以外にもサードパーティのものとかもありますよね。いろいろなメーカーがあります。これも交換できる。コントローラもディスプレイもサードパーティと変えられます。
もう1個、データを保存する場所です。もちろんゲーム機の中のディスクドライブとかメモリカードとかありますよね。ほかにも最近はクラウドに保存できたりしますよね。これがまさにヘキサゴナルアーキテクチャと同じアイデアです。
どういうものかというと、ゲーム機にポートがあります。そこに差せるもの。コントローラとかディスプレイとか、あと保存媒体。ハードディスクとかも。これもコントローラが交換できますよね。お好きなサードパーティ製品に。ディスプレイも交換できます。最近はハードディスク以外にもクラウドに保存できます。
これをソフトウェアに当てはめましょうねということです。どういうことかというと、我々のビジネスロジック、このときの画面とビジネスロジックとデータを保存する、それがクラウドのサービスなのかハードディスクなのか、これを同じようにヘキサゴナル、さっきと同じように画面とかを差し替え可能にしたり、保存媒体、データストアを変えられるようにしましょうということです。
アプリケーションを中心にビジネスロジックを点在させない
（コメントで）「わかりやすい」。ありがとうございます。「成瀬さんの本にも書いていましたね！」。そうそう、この例はけっこう本にも書いたぐらいね、わかりやすいと思っています。ただ、ゲームをやったことがない人がいたら、これ伝わらないなというのが難しいと感じています。だから、ヘキサゴナルアーキテクチャを理解するために、まずゲームをやってほしい。
このときに考えるのが、アプリケーション、真ん中にあるソフトです。ビジネスロジックのことです。アプリケーションは入力デバイスのことをまったく知らないし、それがブラウザでもいいし……まぁHTTP通信ですね。ブラウザ経由のHTTP通信でもうまくいくし、コンソールのアプリケーションとか、あとiPhoneのiOSアプリとかでもできるようにしましょう、ということです。
データストア……アプリはあるんだけど、データストアが例えばデータベース、ハードディスクじゃなきゃダメだとかクラウドじゃなきゃダメだというんじゃなくて、「なんでもいいよ」という感じにしましょう、という考えです。
このアプリケーションを中心に見立てて、ポート越しにプラガプル、プラグを付け外しできることを実現する。こうすることによってできることが、ビジネスロジックを点在させない。要するにアプリケーションを真ん中にだけ置いておくことができるというんですね。
具体的な実装を推し進めているのがクリーンアーキテクチャ
ここでクリーンアーキテクチャの話をしていきます。Enterprise Business Rules、黄色いレイヤーのところ。クリーンアーキテクチャは真ん中に置いているんですよ。ビジネスルール、ビジネスロジックを中心に見据える。
つまり何が言いたいかというと、クリーンアーキテクチャのこの図のコンセプトって、ヘキサゴナルアーキテクチャとやりたいことはまったく一緒なんです。
ヘキサゴナルと何が違うのかというと、ヘキサゴナルのイメージ、外側、ポート＆アダプターの実際の実装例について、詳細に記載しているのがクリーンアーキテクチャじゃないかなと思っています。ヘキサゴナルでも、ちゃんと調べると非常にわかりやすく書いてはいるんですけど、その具体的な実装をさらにクリーンアーキテクチャは推し進めています。だと僕は認識しています。
もう1個有名なのがオニオンアーキテクチャなんですけど、僕はこれ、逆にヘキサゴナルの内側だと思っています。これちょっと余談なのでね、調べてみてください。オニオンアーキテクチャとほぼ一緒ですよ。みんなが話しています。
