読者です 読者をやめる 読者になる 読者になる

アラタナエンジニアブログ

aratana Engineer's Blog

僕らのScala + ドメイン駆動設計(DDD)はじまった宣言。フロントエンドも13の技術を選定し、設計から見直します。

f:id:issei-homan:20150529135543j:plain

アラタナの穗滿です。

突然ですが、みなさんは究極のものづくりと聞いて、何を思い浮かべますか?

僕は「トイレ(イメージしやすいのは洋式)」ですね。

トイレほど誰にでも利用されて、トラブルが少ないものはないと思います。
しょっちゅう詰まったり水がでなくなっては本当に使い物になりません。
それに老若男女、じつに様々な体格した人を受け入れる懐の深さは計り知れません。
何回座られて何回水を流しまくられても平然と仕事をやってのける、素晴らしいですよね(もっと感謝すべきです)!

この世に出てくるまでには、本当にいろんなテストをクリアして出てきたんだろうと思います。
ではWEBの世界はどうなのか。ものづくりより短期間でいろんなものを作れる反面、
ものづくりの精神には遠く及んでいないというようなイメージがあります。


ただ、ものづくりの精神に少し近づけそうな、そんな感覚を持つことができる大きな決断をすることになりました。


それは、これまでの PHP を中心としたサイト構築から Scala に変更し、
設計手法としてドメイン駆動設計(DDD)を取り入れるECサイト構築にチャレンジしていっていることです。

なぜ Scalaドメイン駆動設計(DDD)を採用することになったのか
経緯をこの場をかりてお伝えしたいと思っています。


手続き型(命令型)の恩恵と足かせ

僕は今年32歳ですが、16歳(1999年)のときにHTMLに出会ってIT業界に興味をもってから独学でPerlLinuxを学び、
アラタナを設立した8年前(2007年)からはEC-CUBEを触り始めたのでPHPの独学を始め、いまに至っています。
つまり、人生の半分を手続き型(命令型)言語を中心としたサイト構築に捧げ、ここまで来ました。


手続き型(命令型)スクリプト言語の利点は、直感的にコードに書けるので学習期間が短いことと
環境を準備するのが容易であることかなと思います。
新人スタッフであっても、1年で例えば自分のお給料の5倍近い生産高を出せたりするわけです。
これは間違いなくベンチャーであるアラタナの大きな支えとなりました。
エンジニアの採用は東京も宮崎も同じように難しいので、OJTや巷の書籍などで勉強したり、社内での教育することでバリバリ即戦力でなくとも育てるという方針でなんとかエンジニアを確保してきたのです。

そんな中、アラタナの成長に合わせて、大変ありがたいことにお客様の規模感もどんどん大きくなっていきました。
大きいというのはいろんな解釈がありますが、以下の2点があげられるかなと思います。

1. 月商規模が大きいお客様
2. ナショナルクライアントで体制的にしっかりされているお客様

月商規模が億単位になってくると、当然アクセス数が多く売り方も独自の成功方式に則って運営されていることが多いため、
インフラからフロントエンドまで元のパッケージからかなり修正・追加を伴います。
ナショナルクライアントの場合は月商規模に限らず様々なステークホルダーが存在しいろんな前提条件が高レベルなことが多いため、
こちらも元のパッケージからかなり修正・追加を伴います。

この時点で察される方もいると思いますが、手続き型(命令型)で構築していくことの限界が見えてきました。
いえ、手続き型(命令型)であってもきちんと設計してきちんとコードに落とし込めれば限界はもっと先にあったかもしれません。
しかしそれも時間稼ぎにしかならず、根本的な課題やその課題自体を生み出してしまう原因が残ってしまいます。

PHP の柔軟な仕様はアラタナやお客様の成長に大きく貢献してくれましたが、
上記のような案件になるとそれが逆に成長の足かせになってきたのです。
つまりコードが柔軟に書けるということは、要件定義を元にプログラマーが自分なりに解釈し
自分のレベルでプログラミングするため不具合が生じやすい原因になります。
もちろん、仕組みの中で上長がレビューをしてできる限りの努力はするのですが、
納期やコストの都合の中で精一杯やるという方式となりやすく、根本解決ではありません。

また、処理の中でステータスをもったりデータが書き変わったりする書き方が中心となるのでテストがしにくいのです。
これは規模が小さい間やほとんどカスタマイズがなければ精度をあげることができますが、
ほぼカスタマイズを前提としている現状では設計思想そのものや言語選定の見直しをやってしまわないと
ブレイクスルーできないと考えました。
ただそれと同時に、アラタナの収益を上げている中心サービスですから、
そこから新しい何かを作り出すために人数を捻出するのは大変困難で、どうしようか悩んでいました。


若手エンジニアの熱意

そんななか、アラタナはスタートトゥデイ社のグループに参画することになりました。
「宮崎に1000人の雇用を作る」というビジョンにご賛同いただき、技術力を評価していただきました。
そして大変ありがたいことに時間をいただけたのです。こんなチャンスが巡ってくることがあるのかと思うくらいです。

すると、日頃から上記の課題意識を強く感じていた若手エンジニアが Scala + ドメイン駆動設計(DDD)で構築しなおすことを
提案してくれました。

これはかなり大きなパラダイムシフトになるので、当初私を含めて反発がありました。
ただ、僕らは「ネットショップの今と未来をアツくする」という企業理念を掲げています。
未来をアツくしていくには、積み上げたものを捨ててでも何もなしの更地にし、
新しい知恵を積み上げていく必要があると考えました。
また、手続き型である程度仕事ができるようになってしまうとそれ以上の成長が見えずマンネリぎみになることは別の課題となっていて
そのことも今回のジャッジによりエンジニアの成長につながるのではという話も盛り込まれており、
若手エンジニアの熱意がひしひしと伝わった瞬間でした。

僕は技術役員でありながらこのような思想がたりず、目の前の課題に当事者として関わってしまうことで視野が狭くなり
客観的に見ることができなくなっていたな、と反省しました。
同時に、若手のエンジニアからこのような提案が生まれてきてくれるのは本当に嬉しいな、
と非常に喜ばしい気持ちにもなりました。


お客様にもっと寄り添う設計(ドメイン駆動設計)と関数型へ

これまでもお客様に寄り添うことは努力してきましたし、僕自身もお客様と直接コミュニケーションを取って案件構築していましたので、
ドメイン駆動設計に出会った時は「今まで経験則でやってきたけど、こんなにまとまっているものがあるなんて」と思いました。
内容1つ1つを腹落ちさせるのはまだ容易ではありませんし、「理想論すぎる!」と感じる部分もありますが、
パラダイムシフトってそう感情とかとの戦いだと思いますし、まずは無知の知を意識しながら日々勉強中です。

手続き型から関数型(しかもドメイン駆動設計を交えながら)を習得していくこともなかなか大変です。
しかも僕は生粋のLL脳なので特に大変ですが、ものづくりの精神に近づけられる喜びもあり、
近い将来その経験をもとにPHPerの方々へお話しできると思います。
さらにスケーラビリティや耐障害性を考えて並行処理(Akka)も利用することにしていますので、
結果的にリアクティブドメイン駆動設計をやることになります。やること盛りだくさんです!
ただ、これを極めていくとお客さまの業務(ドメイン)のノウハウをそのままコードとしてため込めて変更にも強くなるばかりか、
メンテやテストが格段にやりやすくなると実感があります。まさにこれまでの限界をブレイクスルーできそうな感覚です。
結果、お客さまにもっと寄り添うことができ、未来をアツくすることができると考えています。


PHP(手続き型) と Scala(関数型) の違いを説明するときの例え話

ここで少し脱線します。

このような大きな変更があると、頑張ってもらうスタッフや周りでなんとなしに聞いているスタッフに対し、
今までと何が変わるのかなど、例え話をすることで理解してもらうことが多くなります。
パラダイムが違うので翻訳が必要ってことですね。
今まだ勉強中なのでずれている部分があるかもしれませんが(ご指摘ください!)、雰囲気を掴むことを重視しています。

前提としてお店を建築物として建てる場合に模倣して説明します。
PHP を使って建築するのが木造で Scala を使った建築が鉄筋コンクリート造のようなものとします。

僕らはこれまで木造建築で小規模から大規模なお店の建築まで対応してきました。
もし壁を作りたいと思えば板を釘で打ち付ければ壁ができます(手続き(命令)型が直感的に組めるニュアンス)。
ただし、「板を釘で打ち付ければ壁ができる」ということだけなので、
それが必ずしも綺麗に並べられて全て同じような板や釘に統一されて出来上がるとも限らないわけです。
人によっては微妙な隙間がうまれたりするでしょう。その微妙な隙間に虫(バグ)が紛れ込んだりするわけです。

これは気をつければいいって話ですが、実際過去に誰かが作った壁はあんまりもういじりたくないという状態が生まれたりして、
また新しい壁を作ったり違うところに部屋を増やしたりしているうちになんだか見通しが悪い建物が出来上がりやすい、と認識しています。
もちろん木造建築であってもちゃんと設計してきちっと構築すれば素晴らしいものが出来上がりますが、
現実の建築とはちがって見えにくい部分や構築・改築スピードがものすごく早いので、納期優先だとそうなりやすいわけですね。

一方、鉄筋コンクリート造の場合はいきなり壁を作ることはできません。
まずちゃんと鉄筋を規則正しく並べ、板で仮の壁を作ってその間にドロドロのコンクリートを敷き詰めて固まる前に整える必要があります。
(実際はどうかはわかりません!感覚です!)
これはかなり綺麗な壁ができあがりますが、板を釘で打ち付けることでしか壁ができないと思っていた職人にとっては
非常に難しい作業です(パラダイムの違い)。

うまく習得できれば、これによって虫(バグ)が混入する確率は減り、
出来上がってしまえば単純な構造が積み重なってるだけなので見通しがよくなります。
もちろんこれもお客さまの要望に応じて増改築により見通しが悪くならないように、
お客さまのご要望をそのままお店に反映する設計手法・哲学であるドメイン駆動設計に沿って構築するので、
この後増改築があったとしても矛盾を生じにくくできます。
また、木造で大きな商業施設を作ることは困難ですが、鉄筋コンクリート造であれば可能になるわけです。
つまり木造(PHP)のいろんな限界を鉄筋コンクリートと新しい設計手法(Scala + DDD)でブレイクスルーするという感じです。

同じ「壁を作る」という作業であっても材料が違えば扱い方が違う為、似て非なるものであり、かなり勉強が必要になります。


小規模なお店をできるだけ早く作りたいというご要望の場合は、この方法は回りくどすぎます。
Scala + ドメイン駆動設計が効果的な案件とそうじゃない案件があることを知っておく必要があります。
僕らが木造も鉄筋コンクリート造も習得できれば、
真の意味でオープンからお客さまの成長にずっと寄り添うことができる大きな武器が手に入ると考えています。


※このほかに山登りに例えることもあります。これまで2,000〜3,000m 級の山にそれなりの装備で頑張って登ってた(PHP)けど、
同じ装備や同じ考えでエベレストに登ろうとすると死んでしまうというような例えです。頑張ってどうにかなる話ではないです。
登りたければパラダイムシフトを受け入れ、どうすれば解決できるか考えるべきです。


フロントエンドも盛りだくさん!

ここまでサーバーサイド側の話となってしまいましたが、タイトル通りフロントエンド側も設計から大きな見直しをいれることになりました。

CSS設計・記法として「SMACSS」
CSSコーディング効率化の「Sass + Compass
・ファイル圧縮や結合・Sassコンパイル自動化等のタスクランナー「gulp」
セマンティックWEBのための構造化データ「schema.org + JSON-LD」
Javascript MVWフレームワーク「AngularJS」
・ライブラリとして「jQuery
Javascript テンプレートエンジン「Handlebars」
・ユーティリティライブラリ「Underscore.js」
MVCフレームワークとして「Backbone.js」
・そして当然「HTML5 + CSS3」

を採用していくことになります。細かくは今後の流れで利用しないものや追加がありえます。
こっちも盛りだくさんですね!


一緒にアラタナを盛り上げるエンジニア募集!
一緒にパラダイムシフトを味わいたい、もっともっと成長したいエンジニアを募集しています。
また、そういったやる気があるエンジニアを育てたいと思ってらっしゃるシニアエンジニアも募集しています。

一緒に世界を変えていきましょう!