エンジニアリングって錬金術
この記事は「Atrae Engineers Advent Calendar 2024」の19日目の記事です。
前回は@_mooriiiによるアニメーションを活用してリアルタイムなカーソル同期のパフォーマンスを改善するでした。
改めまして、株式会社アトラエで、組織力向上プラットフォーム「Wevox（ウィボックス）」のエンジニアをしている新卒2年目のまるちゃんです。新卒1年目の頃はフロントエンド→デザイン→スクラムマスター→PdMと色々なことに挑戦してきまして、最近は既存の機能をドメイン駆動的なアプローチで再設計をするいわゆるドメインエキスパート的な役割をやっています。
そんな中で最近「鋼の錬金術師」をあらためて読んだのですが、このストーリーでの錬金術の概念がエンジニアリングにとっても通じると感じたのでそのことを書こうかと思います。
理解・分解・再構築
錬金術の基本は理解・分解・再構築だ
作中で語られている錬金術の基本は「理解・分解・再構築」です。要はその物質がどういった組成なのかを理解した上でそれを一度分解、最後にその分解した分子・原子を組み合わせることで錬成をするというものでした。
この考え方がエンジニアリングとても当てはめやすかったのです。つまり「エンジニアリングの基本も理解・分解・再構築だ」です。
理解
ここはエンジニアリングにおいては「顧客が求めていることの理解」にあたると思います。
本番環境に上がるのはドメインエキスパートの知識ではなく、開発者の理解あるいは思い込みである。
PO（プロダクトオーナー）などがしっかりとステークホルダーの要求や業務領域を理解することは当然ですし、そのPOとエンジニアチームもしっかりとコミュニケーションを取る必要があります。
分解
エンジニアリングにおける分解とは「適切な顧客価値単位に機能を分解する」ということだと思っています。
例えばアジャイル開発における「ユーザーストーリー」に分解するプラクティスとかはまさにそうですよね
この「分解」ができていないと見落としている要件が発生したり、個人のタスクがスタックしたり、リリース後に要望とのずれが起きたりとさまざまな問題が発生しますよね。
再構築
最後の再構築が実装にあたると思います。今回「プログラミングとは錬金術」とは言わずにエンジニアリングという言葉にしたのは、ここの部分がジャストプログラミングであってエンジニアリングとはそれ以外の要素がいっぱいあるよね？ということが言いたかったのです。
等価交換
錬金術の基本は「等価交換」‼︎
何かを得ようとするならそれと同等の代価が必要ってことだ
これも作中に出てくる錬金術の基本として説明されているものです。錬金術とは無から有を生み出すようなものではなく、あくまで用意されている材料から別の物質に組み替えるものであるということだと思っています。
また、錬成するものの材料が足りない、または術者の技量が足りない場合は「リバウンド」と言って呼ばれる現象が起きて術者がその代価を支払わされる上に、錬成も失敗してしまいます。
この概念もいろいろなことに応用できるのですが、エンジニアリングに対しては特に通ずるものがあると思っています。エンジニアリングも「なんかすごいことしてすごいものができる」みたいな幻想を持たれがちだと思っているのでこう言った当たり前と言えば当たり前だよねっていうことの再確認ができる概念は必要だなぁと。
みなさんも開発案件で一度は「リバウンド」のような現象を観測したことはあるのではないでしょうか？
エンジニア「PMさん 今回のプロジェクトの開発期間ってどれくらいだったっけ？」
PM「ええと…6ヶ月だね」
エンジニア「リリース予定日は？」
PM「………2週間後だね」
エンジニア「もひとつ質問いいかな。バッファと来るって言ってた追加アサイン、どこに行った？」
新米エンジニア「!」
PM「……君のような勘のいいガキは嫌いだよ」
結局何が言いたいの？
言いたいことは「しっかり設計してから実装しようぜ」
ここまで散々楽しそうに話してきて、「で、こいつは結局何が言いたいんだ？」となっているかもしれません。
結局僕がこの記事で言いたいことは「しっかり設計してから実装しようぜ」ということだと思います。
例えばタルに穴があいて水が漏れているを考えます。多くの人はその穴を塞ぐために木の板を補強するのですが、しっかり「理解・分解・再構築」の基本を考えると、
穴が空いているのはタルの木材の劣化である（理解）
今回解決するべきは「穴が塞がること」と「同じように穴が開かないこと」（分解）
で、やるべきはタルの板を新しいものに交換して組み直すこと（再構築）
のように対応方針を決めることができるかもしれません。もちろんとりあえず穴を塞ぐことの方が重要な場面もあると思いますが、毎回毎回穴を塞ぐだけをやっていると気づいた時にはタル自体が使い物にならないものになってしまうかもしれません。
いい設計とはなんなのか？
とはいえみなさん「そんなことはわかってるんだよ！」ってなると思います。別に設計せずに実装しているつもりもないし、できるならいい設計をしたいと思っていると思います。じゃあ「いい設計」ってなんなのか。
個人的な意見としては「見えている範囲でいいからしっかりドメインを切り出せている」ことがいい設計につながると思っています。
大体の機能開発は「ユースケース」からくるものだと思っていて、それを愚直に実現し続けると実は重複しているドメインだったり不足しているドメインだったりが積み重なってしまいます。これでは設計が破綻してしまいますね。なのでこのユースケースを「理解」してドメインに「分解」することが大切なのです。また「見えている範囲で」というのは、最初から完璧なドメイン設計は無理だと思っているからです。結局はユースケースの積み重ねであることは変わらないので小さくいい設計を繰り返して、どこかで再度「理解・分解・再構築」をすることが大事だと思います。
おわりに
なんか思いついた時は「これはおもろい洞察だ」って思ったんですが、調べてみたら結構擦られたネタっぽかったので少し悲しかったですｗ