正しいアーキテクチャとは何か？ - 完璧を目指さない進化するアーキテクチャ にオンラインにて参加しました。
イベントの概要
システムが成長するにつれ、アーキテクチャの課題は変わるもの。本イベントでは、AWSの福井厚氏と『現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法』の著者・増田亨氏が変化に強い設計の考え方を対談形式で議論します。変更容易性の高いリアーキテクチャを学べる場を目指します。
引用：
イベント参加の背景
- アーキテクチャについて常々解像度をあげたいと思っている。
- 増田亨さんの発信にいつも刺激と学びを頂いている。
- 携わっているプロダクトも今後大きく成長することが見えているため改めて学びたくて参加！！
特別対談
メモ
使いにくかったら分解することが前提
・増田さん
当会にあたって考えたこと。今までの違和感。
使いにくかったら分解することが前提で考えていたが、それが伝わらないことが多い。
アーキテクチャを考えるときに、現状維持バイアス、サンクコスト効果、足し算バイアスをどう扱うか。
一般的に考えると正しいバイアスではあるが、アーキテクチャについては意図的に乗り越える必要がある。
失敗もするが、費用対効果は体感的につかめる。
やってみて知見を持つことでアーキテクチャを変えることに対する知見が変わると思う。
・福井さん
建築のメタファーを持ってきたことがそもそもの誤り。作って終わりではない。
ガウディは完璧は神しかできない、人は作り続けなきゃいけないと言っている。
ソフトウェアはプロジェクトからプロダクト志向になっている。
世の中の変化に何が正解か分からない中で追従していかなきゃいけない。
作って終わりの時代から、ずっと作り続けるチームとして動かなきゃいけない時代になった。
変更可能性の点でソフトウェアと建築物は違う。
アーキテクチャはビューポイントがいっぱいある。
ハイレベル：エンタープライズ、ローレベル：実装レベル。
建築よりリッチな考え方、ものの捉え方が必要となる。
・増田さん
実は木造建築だと話が違ってくる。例：法隆寺。
かつて二重の塔を三重の塔にしたような話もある。
構造を変えようと思えば、変えられる手立てはある。
・福井さん
アーキテクチャの美しさは両方に言える。
よく考えられた構造は両方に言える。
・増田さん
なんとなく見た時に手を入れやすそうかどうかは感覚的に持っている。
なんとかなるな、という感覚を財産として扱う。
複雑なものを変える、ということは本を読んでも身につかない。
体験知を手掛かりにやってみることを大事にする。やればできる。
・福井さん
机上では出ない。
ソフトウェアは積み上がり。すべてを知っている人は誰もいない。
作って試してやってみることが大事。クラウドはやりやすい。
・増田さん
クラウドとDockerは「試してやってみる」ことに対して銀の弾丸になる。
かつては試行するための障壁が多くあったが、今は変更に対する試行が容易になった。
構造の切れ目が見えない泥団子では大変だが、切れ目が見えるものは試してみたら良い。
・福井さん
認知負荷が大変。１回作ったら忘れたい。
境界を作って分割して１つだけ考えられる状態を作りたい。
・増田さん
実際にやってみる。分解する。
うまくいかないこと、認知の負荷があがることも含めて経験していくことが重要。
業務の切れ目、関心毎が違うところで分けるのは大正解。
業務が違えば行ってくる人は違う。
依存関係が複雑だと身動きとりづらいが、モジュールの独立性が高ければエンジニアとして楽ができる。
社内業務と外部連携のあるシステム。
密結合にせず、適切に分離できていれば、異なる利用者間での調整は不要になる。
業務の構造に合わせる、業務部門の力関係が分かっていた方が楽になる。
複数システムで１つのテーブルを利用せず分離する。
テーブル分ける前に登録と更新を分ける。疎結合にする。
API公開してアクセスするや非同期メッセージングで疎結合を実現する。
全部変えたがるバイアス
・増田さん
アーキテクチャを変えるとき、全部変えたがるバイアスを感じる。
１つのやり方に縛られず、部分ごとの解を探す。
・福井さん
アーキテクチャに正解は無い。選択の繰り返し。
なぜそれをやるかを説明できるのがアーキテクトの責任。
・増田さん
経験値を作ることで選択肢を作っていく。
・福井さん
実装を通して仕組みを理解していくことは今後も重要となる。
全部やる必要は無いが、採択する仕組みに対する解像度は上げた方が良い。
・増田さん
基礎は学んだ方が判断の応用が効く。
『ドメイン駆動設計をはじめよう』の翻訳について
・増田さん
原書で読んだときに説明がうまいと思った。
それは教えているからだと分かった。
原書の意図を組み、分かりやすく説明できるようにした。
自分が分からないこと、言葉のハードルを下げて伝えようとした。
従来のドメイン駆動設計の学習者ではなく、初学者が最後まで読めるように意識した。
気に入っている部分。付録に失敗が書いてあること。
原著者の失敗がリアルで面白かった。
失敗の経験がある人がジュニア向けに説明しようとしたことが実践的になっていると思う。
全面的に本にアグリーしている訳ではない。意見と違う部分を訳すのは辛かった。
正解ではなく、参考として考えて欲しい。
本は形式知。自分の中に取り込んで暗黙知にする必要がある。
その人の視点でしかない。いかに自分の暗黙知にするか。
Q&A
コーディングに特化した生成AIの登場によってアーキテクチャの設計はどう変わると考えていますか？
・福井さん
参考にはできるけど、信じ切ることはできない。
AI駆動開発はイテレーションの感覚が異なる。
生成AIの能力を最大化するためにはイテレーションを短くする必要がある。
開発サイクルを変えていく。
生成AIがアシストからドライバーになった。
ただ、正しいことの検証は人間。設計できる人間を作る必要がある。
仕様や設計を決められるのは人間だけ。実装はAIに委ねる。
要件を解釈してコードがその要件を満たしているかを判断できるのは、今は人間しかできない。
・増田さん
今大きな泥団子を作るチームは泥団子を作り続ける。
設計力はあがらない。
設計力があがらないままだと、大きな泥団子が増える。
基本的には人間がやっているので変わらない。
AIの作るものからアイデアの発見は広がった。
ただ、構造的な仕組みまではいかない。壁打ちとして使える。
リファクタリングのタイミングを知りたいです
・増田さん
変更が厄介で危険な場所を変更する必要があるとき。
それ以外の時はそんなことをする余裕がない。
・福井さん
外の振る舞いが変わらないことが保証できることが前提。
まずはちゃんとした仕様、振る舞いを確認するためのテストを揃えた上で実施する。
「チームのレベルに合ったアーキテクチャ」というものを考える際のコツ
・福井さん
正解は無いが正しい選択は必要。
正しい選択ができない場合は、アーキテクチャに手を入れない。
・増田さん
アーキテクチャはレベルで決めることではない。
チームの個々人の暗黙知を明瞭化し、経験が足りない場合はレベルアップして挑む。
アーキテクチャとビジネスロジック(ドメイン)はどのような関係にあるのか。ビジネスロジックの変化に追従しやすいアーキテクチャがあるのか、または後から非機能の要件でアーキテクチャを変化させられるようにビジネスロジックを予め高い解像度で捉えておく必要があるのか、スピードとの兼ね合いでどちらから先に重点的に取り組むべきなのか設計のときにいつも悩んでいます。
・増田さん
ソフトウェア設計の大原則として入出力と計算判断の分離を徹底することが大前提。
それができないとドメインロジックという判断に至れない。
ドメイン駆動設計の話で言うとすべての業務を追いかけることはできない。費用対効果が悪い。
ビジネスロジックの中でも競争優位の差別化を生み出す業務ロジックを頑張る。
他ロジックは入出力と別れていればよい。スピードとの兼ね合い。
トランザクションスクリプトは書き方によって入出力のパートと計算判断のパートは分けることができる。
可能な限りグループにして分ける。リード、計算、ライトを分けることで扱いやすくなる。
・福井さん
クリーンアーキテクチャで書かれているように分離することが重要。
ドメインモデルはオブジェクト思考が必要。基本は大事。
過去の良書を読み、自分のものにしていくことが大事。
・増田さん
プログラミング言語のプリミティブな型を使うのはアンチパターン。
業務に特化の独自の型を作って実装していく。抽象化の型を業務レベルに合わせる。
ビジネスロジックを予め高い解像度で捉えることは必要だができない。
だから書いて動かしてフィードバックを得ていく。
・福井さん
抽象的に捉えるためにはイベントストーミングが効果的。
感想
本当は現地に足を運びたかったのですが、急遽予定が変わりオンライン参加となりました。
それでも非常に学びの多い時間となりました。
Q&Aでのチームのレベルに合ったアーキテクチャのお話は、自分でも考えるところがあったため自戒ともなりました。
良質なアーキテクチャを作り上げるために妥協点を探すのではなく、チームの成長をはかります。
また、形式知を暗黙知に消化していく話と、選択肢を増やすために体験知を増やしていく話は常に頭に持っておきたい内容でした。
特に『全部変えたがるバイアス』にあったように、既知の選択肢に依存せず、常に最善の採択ができるように知識も経験もあげていきたいです。
『ドメイン駆動設計をはじめよう』について、事前予約して積んだにも関わらず未読となっています。。
今、同じチームの若手エンジニアと月１で技術書読んで感想会を開催しているため、課題図書としたいです。
週末のJJUG CCCでのお話も楽しみにしています。
AWS Summitも予約済みです。
現地行きたかった…！！
アーカイブ動画
配信されました！嬉しい！！
