吉祥寺.pm18 で「ぼくがかんがえたさいきょうのSoR/SoEあーきてくちゃ」という発表をしてきました #kichijojipm

先日開催された吉祥寺.pm18で「ぼくがかんがえたさいきょうのSoR/SoEあーきてくちゃ」というテーマで発表をしてきました。

そのイベントレポート兼発表補足です。

イベント概要

kichijojipm.connpass.com

スライド

speakerdeck.com

発表内容の補足

Twitterはてブ等でいくつかご意見いただいているので、それについて現時点で僕が考えていることを補足させていただこうと思います。ひとつ言い訳させてもらえるなら、今回は時間が短すぎたので結構前提となる説明(エヴァンスさんの DDD を僕がどう捉えているか、CQRS とは何か、等)を省略したところが多すぎたかなっていうのがあり、特に当日いらっしゃらずスライドだけを見ていただいた方には余計にわかりにくかったかもしれないので、ここで FAQ 形式で補足させてもらえればと思います。

整合性に関しては DDD でいう Aggregate がその単位じゃないの?そもそも SoR/SoE って整合性で分類するものなの?

これについては Twitter に書きました。

DDD の Aggregate を整合性境界とする考え方は僕は SoR 的というか、データストアの都合に強く引っ張られていると思っています。多くのシステム利用者にとっての整合性境界は「画面」とか「セッション」、クリーンアーキテクチャでいうと Usecase のレイヤーで、たとえば「商品購入と同時に会員登録」というユースケースがあったとき、実際には会員と商品が集約ルートとしてあって別のトランザクションが実行される(その間は結果整合性しか保証されない)と思うんですが、利用者の目に触れるところで「会員登録はできたけど購入履歴には購入したはずの商品が見えない」という状態は許容されないのです。他の利用者はともかくとして、少なくともその利用者本人にとってはすべてが完了した状態であるべきという話です。

要するに、実際には結果整合性しか保証されないものをあたかもトランザクション整合性が保証されてるように見せかける(さもなくば「処理中」「確認中」というステータスを SoE 側の都合で導入して、利用者にきちんと納得してもらえるタッチポイントを提供する)というか、そういったユーザ体験の観点からの不安の除去や状態の説明が SoE の仕事なんです。

エンジニアにとっては同じ結果整合性でも利用者自身がそれを認識しているかどうかという別の観点があって、数ミリ秒から数秒程度で整合性のとれた状態になるのであればそれは利用者にとってはトランザクション整合性と事実上同じに見えるでしょうし、数分やそれ以上かかるのであれば Engagement を担うシステムとしては「少々お待ちください」的なメッセージを伝える必要があるでしょう。

あまり具体的な実装の話はしませんでしけど、「ユーザローカルな整合性」と呼んでるものって具体実装でいうと Redux の Store や Reducer をどういう風に設計するかっていう話で、それがサーバーサイドと必ず同期されているべきかというと別の話って感じですかね。(BFFがある場合、そこくらいまでは同期されてて欲しいけど、ここでいうサーバーサイドっていうのはさらにその後ろによくいるマスターデータとなるデータストアを司ってるやつのことです。)

期限付きの予約をできる必要がある

これは要件によるとしか言えませんが、大抵の場合はその通りですね。

ただ発表者である僕自身がライトヘビーでシビアなシステムに関わってないので、切実に困っているわけでなく、そういう意味で明確な成功体験も失敗体験もなくて今回の発表からは割愛した感じです。

SoR / SoE という名前は適切ではない

これは実は僕も思っているのですが、僕程度の人間が独自の命名をするよりも世の中に広く知られている分類方法を使ったほうがいいかなぁ、と思った次第です。たぶん今後もこの言葉使うと思います。

話せなかったこと

まあ、整合性のとり方について以外はほぼ話せなかったんですが、たとえばもっとこういう話に掘り下げていけるといいなと思っています。

感想とか

吉祥寺.pm 初参加だったのですが、発表内容が多岐に渡り、いろんな人がいるいい会だなーと思いました。(こなみ)

一番の反省は句会であるということをまったく認識しておらず、当日に慌てて一句詠もうとしたのですがまったくいい句が出来ず僕だけ短歌になってしまったことです。次に発表するときには会心の一句を準備して臨みたいです。

Tips

懇親会後の三次会(?)でそーだいさんっていうこわい人から「おい!ラーメン行くぞ!!」って言われて「ひええ」と思いながら一風堂という名店へ何人かで行ったのですが、とんこつ豆腐(麺の代わりに豆腐が入ってる)という神メニューがあったのでもうシメのラーメンこわくないです。そーだいさんはこわいけど。

Atomic Design における Atom, Molecule, Organism の見極め方

最近フロントエンド書いてて、コンポーネントの設計とかデザイナーとのコミュニケーションには Atomic Design を採用しているのだけど、まあよくある話として「この要素が atoms / molecules / organisms のどれにあたるかわからん!」となる(なった、特に molecules)ので、チーム内に雑にテキストで書いて共有した。で、せっかくならそれを公開して優秀なデザイナーおよびフロントエンドエンジニア諸氏に意見を募りたいと思ったのでブログ書いてみることにする。

ちなみに、現状は実装対象として Web アプリケーションを想定しているけど、ネイティブアプリも視野に入ってるので「HTML ではそうかもしれないけどネイティブアプリだと云々」みたいな意見も歓迎する。

チームに共有したテキストがこちら。

Atom, Molecule, Organismの見極め方

Atomic Design の公式の説明ではそれぞれの要素を以下のように定義している。TemplateとPageは自明なので省略。

  • Atoms are the basic building blocks of matter. Applied to web interfaces, atoms are our HTML tags, such as a form label, an input or a button.
  • Molecules are groups of atoms bonded together and are the smallest fundamental units of a compound. These molecules take on their own properties and serve as the backbone of our design systems.
  • Organisms are groups of molecules joined together to form a relatively complex, distinct section of an interface.

Atomについては自明で atoms are our HTML tags と言っているので HTML タグがそのまま Atom になると考えてよい。Button Atom<button> に対応するし、 Image Atom<img> に対応する。また <span> に対応する Text Atom もきっと作られる。

Organism も比較的簡単で、UI設計、ビジュアルデザイン、HTMLコーディングを実際に行う場合に「〇〇エリア」「〇〇ボックス」「〇〇領域」と呼ばれるもので、それ自体が独立して意味を持ち、ユーザとのインタラクションを定義可能なものという位置付けになる。上記の公式説明は一部補足が必要で、Organism は groups of molecules と定義されているが、実際には直下に Atom を直接持ってもいいし、Organism の中に Organism を持つ、つまり Organism がネストされることもある。たとえば、一覧系のページにおけるリストは Organism であるが、そのリストの要素ひとつひとつも独立して意味を持ち再利用されるため Organism になる。

一番判断が難しいのは Molecule だが、これは「それ自体が独立して存在はできないが、Atom ほど無機質でなく、最低限の意味をそれ自体が帯びる要素」と言い換えると定義しやすい。たとえば「削除ボタン」は「ボタン」ほど汎用的ではないが、それが何かを削除するものであることをユーザに伝えることしかできず、それ単体では存在できない。つまり、最低限の意味を持った上での汎用化と言える。逆に言うと、Atom はそれ自体が意味を持つことを排除して、見た目のスタイルを自由に変えられることによって無限の汎用性を持たせている。これは便利でカスタマイズしやすいが、一方でサービス全体での UI の統一性という観点からはよい設計とは言えず、Molecule の設計に失敗した場合のある種の脱出ハッチと捉えるべきである。削除ボタンは「削除」という文言やゴミ箱のアイコンがその要素内に閉じていてそれを使う側からは意識する必要がないという意味で、最低限の意味を持っているが、一方、それが単独で存在することはありえず、それが一体何を削除するものなのかはそれを利用する Organism によって定義されるということになり、代表的な Molecule である。

Organism に悩むことはそんななにない気がしていて、問題は Atom か Molecule かみたいな話だと思うんだけど、atoms はセマンティクスを排除した見た目だけのみの汎用部品、molecules はセマンティクスをともなった汎用部品としたらわかりやすいんじゃないかなーと思っていて↑を書いたんだけどどうだろうか?

オブジェクト指向的な設計との対比

オブジェクト指向というかエリック・エヴァンスの設計に出てくる概念だけど、molecules をバリューオブジェクト、organisms をエンティティと捉えるとどうかと考えたりした。

意味を持ち自律的に動く単位として molecules があり、それを束ねる単位として organisms があるという感じの捉え方。バリューオブジェクトとエンティティとの違いは、Atomic Design においては molecules は atoms にのみ依存してよくて他の molecules には依存するべきではないっていう設計思想っぽい(バリューオブジェクトは別のバリューオブジェクトを内部に持つことができる)ところかなって気がしている。

これについても誰か思うところがあったら意見欲しい。

プログラマとデザイナーの思考の違い

数日前に mizchi さんからアドバイスをいただいた。

実践してる人の意見としてとても貴重ではあると思うんだけど、肌感覚としてこの違いがまだ掴めておらず、デザイナー諸氏たちの意見が欲しい気持ちがわりとある。

まとめ

なんとなく掴めてきてる気がするけど、まだまだ悩み中なのでみんな助けて!

副業エンジニアの価値をレバレッジする仕組みとしてのグローバル開発チーム

この記事は a-suenami Advent Calendar 2018 - Qiita の 3 日目の記事です。

昨日はベトナムでの開発チーム構築についての経験談を述べましたが、本日はそれに続いて、実際にどのようなことをやろうとしているのかについて書きます。

副業の活性化

昨今、副業が流行っています。これはエンジニアに限らず、あらゆる職種でやっている人が見られます。

企業側としては

  • 他の企業のノウハウを社員の副業によって取り入れる
  • 優秀で高単価な人を顧問やコンサルタントとして受け入れることによって既存チームやプロジェクトのパフォーマンス底上げを図る
  • 正社員として雇用する前のお試し

等が目的だと思われますし、副業する個人側としても

  • 収入源の分散
  • 本業以外の会社での業務を遂行することによる技術習得、視野拡大
  • 転職前のお試し

等のメリットがあると思われます。

これまでコミュニティを介して行われていた知見の共有がより強固に、実際のプロジェクトを通して行われることになり、この流れは僕自身はかなり強く肯定的に捉えています*1

副業と海外開発チーム

エンジニアの副業は企業側・エンジニア側双方にメリットがある反面、プロジェクトマネジメントの観点からは当然難しいところもある。

一番大きいのは断片的な時間を効率的に使えるようにプロジェクト全体のタスクをうまく細分化して、小さく進めていけるようなプロジェクト管理が求められる部分で、これは時間も場所も毎日共有していてハイコンテキストなコミュニケーションをしている正社員を前提にしているとなかなか難しい。

したがって、週 1 〜 数日といった稼働を、より課題が本質的で、経験が必要とされる領域にあて、それ以外の領域をベトナムのチームに任せることで全体的な効率を上げることを僕は今目指している。

事前設計

言語やフレームワークの選定、大きな設計方針の決定(エリック・エヴァンスの DDD、CQRS 等)、その他個々の機能ごとのデザインパータンの採用など、アーキテクチャの設計は本質的に難易度が高く、経験も必要とされる。

また、プロセス設計という意味では Lint やテストカバレッジに対する方針の策定、それをもとにした CI の設定、Working Agreement の明文化など、メンバー数が増えても開発速度が落ちないようにするためのこれらの仕組みも経験豊富な知恵を借りるべきだと思っている。

コードレビュー

コードレビューはプロダクトの問題を発見するポイント、品質を見極めたり向上させたりするポイントとして不可欠なステップである。これらを経験のあるエンジニアに任せることによって品質の向上を図るとともに、必要であれば Lint や自動テストの設計指針にフィードバックすることで、マネジメントコストを極端に上げずにスケールするチームを作ることが可能になる。

テスト設計 / テスト観点洗い出し

コードレビューを正しく行うことによって内部品質は向上するが、リリースに必要な品質は通常テストによって測定されなければならない。このテストケースの設計や観点の洗い出しにはソフトウェア開発やテストの経験が不可欠であり、システムの対象ドメインによってはそのドメイン知識も必要になる。ここをきちんと抑えることで開発チームのパフォーマンスを向上させることができる。

まとめ

昨日の記事ではベトナム人による開発チームの特徴を挙げたが、言葉も文化も違う人たちと同じチームで開発を進めるということの難易度は依然高く、正直日本国内での信頼もまだまだ高くない。

この是正手段として、経験豊富な国内のエンジニアの経験を借りることは有効だと思っており、そのためには今の副業市場の活性化は追い風なのではないかと感じる。

本日の焼肉屋

3 日目の本日は 1, 2 日目と同様渋谷から「いのうえ」をご紹介。

リーズナブルな金額で店内も広く、会食等にも利用できます。焼きすき、焼きしゃぶというすき焼き、しゃぶしゃぶに使うような薄切り肉を鉄板で焼いてご飯に巻いて食べるというのがおすすめメニューです*2

tabelog.com

*1:すえなみチャンスの発想も似たようなものです。今のところ、すえなみチャンスは対価が焼肉ですが。

*2:糖質だけどな!

ベトナムで開発チームを作る(作ってた)話

この記事は a-suenami Advent Calendar 2018 - Qiita の 2 日目の記事です。

タイトルの通り、 1 日目に紹介した「すえなみチャンス」を発想したきっかえでもある、ベトナムでの開発経験について書きたいと思います。

ベトナムでの開発体験

僕は以前、某キュレーションメディアの会社*1で働いていたのだけど、そのときに開発をスケールさせるためにベトナムで開発チームを作るって話があって、僕がそのマネジメントというかそれっぽい任をいただいてしばらくベトナムに住むってことがあった(1年くらいいた)。

今はその会社をやめて主に日本にいるようになったけど、その会社とは別に小さなチームがあって、たまにベトナムには行っていたりするので、その経験談を書こうと思います。

ベトナム人の特徴

ベトナム人の特徴ですが、もちろん「人による」というのは人種問わず当たり前なので、あくまで総論・一般論として、ベトナム人と付き合うときの Tips という風に考えてもらえればと思います。

真面目、従順(≠誠実)

ベトナム人の紹介で一番最初に出てくる特徴がたぶんこの真面目さとか従順さだと思う。 彼らは年上だったりポジション的に目上だったりする人にちゃんと従うし、言うこともすごくよく聞いてくれる。僕はマネジメントとかっていうものをほぼ未経験でベトナムに行ったんだけど、メンバーの性格や気の使いどころという観点での苦労はほとんどなかったように思う。ちゃんと言えばやってくれるので。*2

ただ、よく言われる話として「ベトナム人は誠実だ」っていう話もあるんだけど、(もちろん誠実の定義によるんだけど)これは若干違うような気がしていて、言われたことをちゃんとやるということは裏返せば言わなかったことはできないし、言ったことであってもそれが満たされる限りにおいてギリギリまで手を抜こうとする(ように見える)。

まあ、これ自体はエンジニアという職種においてはいい側面もあるし、サボれる部分は積極的にサボってもいいと思うだけど、日本人相手のように「わからなかったら質問してくれるだろう」「定期的にレポーティングくれるだろう」という感覚だと納期ギリギリでやっぱりできませんでしたみたいなことになりかねない。*3

個人主義

これは個人の感覚なんだけど、仕事に対しては個人主義的なところがあるなぁと思う。あえて「仕事に対しては」と前提をおいたのは、ランチとか飲み会とかは結構みんなで仲良く行くし、業務時間外でそういう側面をあまり見ないから仕事や業務成果に対する競争意識みたいなものなのかなと想像している。

僕がベトナムで一番最初に強く違和感を覚えたが Slack の開発チャンネルが全然流れないこと。わからなかったら誰かに助けてもらおうとか、この人に質問しようとかっていうのが自然には身についてなく結構ギリギリまで自分ひとりで何とかしようとしてしまう。この責任感はよい側面もあるのでうまくマネジメントとして活かしつつ、チームメンバーに頼ったほうがいいところは頼りやすいような雰囲気やルール作りをするのが重要だと思う。

見栄っ張り

見栄っ張り、これはすごくある。まあ、日本人が謙虚というか自己主張が弱すぎるだけな気もするけど。

先に書いた個人主義と重なる部分もある気がしていて、仕事とかプロジェクトの成果に対しては自分の手柄と言いたいという志向性の人が多いように思うし、給料や待遇に対する要求も強い。そして彼らはカジュアルに他人に自分の給料を言うので、チーム内で給与格差があると低い方のメンバーのモチベーションは下がるし、マネジメントする側の立場としてはなぜあなたの評価がそうなっているのかを客観的な給与評価テーブル等を作って説明しなければ納得しない。

あと、これは中国人(だったっけ?)もそうらしいんだけど

  • 褒めるときはみんなの前で
  • 叱るときは本人を呼んで 1 対 1 で

というのが鉄則。

彼らの仕事はちゃんと評価してあげるべきだし、彼らのプライドを傷つけるようなことはしてはならない。

ライフラークバランスちゃんとしてる

これは日本のほうが特殊なんだろうけど、ライフワークバランスがしっかりしているなと思う。たまに残業しまくる人もいるけど、基本的に定時にあがって友だちや家族とすごす時間を大事にする。

ベトナムだと家族ぐるみの付き合いも多かったりするらしく、ホームパーティとか旅行とかにプロジェクトメンバーや上司が呼ばれたりする。そこで家族の人たちと仲良くなると結束が強くなるというか、もうちょっと打算的なことを言うとモチベーションの低下リスクや離職のリスクが下がる。

ベトナムでいいチームを作るためにはメンバー自身ももちろんだけど、メンバーの奥さんや旦那さん、ご両親に好かれることだとよく言われる。

ぼくがかんがえたさいきょうのべとなむじんちーむのつくりかた

ベトナム人の特徴を見て「あれ?」って思った人もいるかもしれないけど、ぶっちゃけ普通である。

むしろ日本のほうが特殊な気がしてて、空気を読んでなんとなくいい感じに成果出す人がいたり、長時間労働して帳尻を合わせたり、マネジメントが多少未熟でもメンバーがなんとなくいい感じにしてしまうってことがありえる。

逆にベトナムでチームを作ると成果が出せなかったらたぶんダイレクトにマネジメントが悪いって感じになる。もちろんこれは日本人でチームを作る場合にも意識しておかなければならないんだけど、僕が特にベトナムにおいて意識していることを以下に挙げようと思う。

長いものに巻かれる雰囲気を作る

デザインパターン、その逆のアンチパターン、またなんとかファウラーさんのような有名な人のブログ記事などは積極的に引用して個々のタスクレベルで指示を出していくとよい。

メンバーには正確に何をやって欲しいか、どういう成果を出したいかを伝える必要があって、これは当たり前の話なんだけど、その上で、その実現に向けて実際にどういう方法をとるか、どういうプロセスで進めるかということも伝えられると真面目なベトナム人という性質上、成功確率をどーんと上げることができる。逆に目的だけ伝えてあとは一任するっていう強すぎる裁量は十分にチームが成熟するまではやめたほうがいい。

このときに目的や期待する成果物の説明はともかくとして、そのための方法論の部分は個人による実力差や志向性が非常に出やすい部分で、ある程度世の中に知見がある(つまり、困ったときに本人が自分で調べることができる)方法をマネジメントとして指示してあげるほうがうまくいくケースが多い気がする。*4

最初はコミュニケータはちゃんといたほうがいい

ベトナムのベンダーはエンジニア以外にコミュニケータという通訳兼ディレクターのような人がいることが多い。会社によってはブリッジ SE (BSE)などとも呼ばれるが、この BSE という人は技術もわかる人を指す。

僕もベトナム人エンジニアと英語で直接コミュニケーションして開発チーム大きくしていくぜ!グローバルチームだ!と思った時期もあったけど、これがなかなか難しい。もちろん僕の英語力の問題は多分にあって、それはがんばらないといけないんだけど、比較的大きな機能開発ならともかくとして、小さなバグ修正とかニュアンスを伝えるのが大変な機能改修とかはたくさんあって、そういうのもすべて間に日本人が介在するのではスケーラビリティが生れないし、何よりどちらもノンネイティブ言語なのでコミュニケーション効率がよくない。

なので、コミュニケータは(少なくとも初期は)いたほうがいいと思う*5

年功序列であることを意識する

ベトナムは日本以上に年功序列である。わかりやすいのが人の呼称で、相手が年上の場合と年下の場合で違う。*6

なので、それをちゃんと意識して採用、育成、評価、権限委譲をしたほうがよくて、特にチームリーダーはそのチームで一番の年長の人にできると望ましい。優秀な若手、無能な年長者は扱いが難しく、後者は当然だとして、前者もポジションを与えにくいという意味で頭を抱えることがある。優秀な若手は優秀な年長者がいる前提においてはマイナス要因ではないので、とにかく無能な年長者だけはチームに入れないというのを意識しておくといいと思うし、仮にそこで失敗するとリカバリーが難しくなる*7

まとめ

ベトナムでの開発チーム構築は難しい側面も多々ある一方で、エンジニア不足が叫ばれる今の日本において大きな選択肢のひとつになっていって欲しいと思っており、僕は今もそういう世界を夢見てがんばっている。

「オフショは品質が〜」みたいな話はいろんな方面から聞くのだけど、その要因の結構な部分がマネジメントに起因するところもきっと多く、ベトナム人のエンジニアと仕事をしている僕の立場からすると彼らの技術力に由来していると思われたくはないという個人的な感情はすごくある。だからこそ、適切なマネジメントのもとで、彼らの能力が最大に発揮される仕組みを作って、日本、ベトナムの両国におって Win-WIn になるような世界にしていきたいなと思っている。

今日の焼肉屋

2 日目の本日の焼肉屋は昨日と同様に渋谷から「焚火家」をご紹介。

肉のヒマラヤという巨大な肉塊を焼けます!

https://tabelog.com/tokyo/A1303/A130301/13130110/

*1:リアルで僕を知ってる人はほとんど知ってると思うけど、まあいろいろ世間にはご迷惑をかけたので一応伏せる

*2:もちろん他の観点に対する難しさはある

*3:もちろん真面目で従順というのはあるので、レポーティングにしろ、コミュニケーションにしろ、ルールとか原則を設ければやってくれる。あくまで「自発的に」できるかどうかという話。

*4:その判断こそがプログラマの仕事だろって言う意見もあると思うけど、少なくとも僕はまだその領域に達してない。

*5:ちなみにコミュニケータはできれば女性がいい説を僕は唱えてるんだけど、それを声を大にして言うとジェンダー的に云々って言われそうなので今回は割愛。聞きたい人は飲みにでも誘ってください。

*6:年上の男性は anh, 年上の女性は chi, 年下は男女ともに em という。

*7:チームを分割するくらいしかとれる手がなくなる

すえなみチャンス紹介と目指していること

この記事は a-suenami Advent Calendar 2018 - Qiitaすえなみチャンス Advent Calendar 2018 - Adventar の 1 日目の記事になります。

初日の今日は、僕がやってるすえなみチャンスという試みの紹介と目指していることについて書きたいと思います。

すえなみチャンスとは

詳しくは以前書いたこちらの記事を参考にしてください。

a-suenami.hatenablog.com

平たく言うと、僕が知りたいことをペアプロ等(最近はペアプロじゃなくて普通にスライドとか使って教えてもらうっていうことも増えてきた)で教えてくれる代わりに焼肉を奢りますという試みです。

ブログに書いたのは上記の一回だけですが、その後も各方面の猛者の方々に殴られながら教えていただきながら、おいしい焼肉を食べています。

初回の増田さん以降は出演許可(?)をもらってないので*1実名は出しませんが、テーマでいうと

など開催しています。

きっかけ

きっかけはまあくだらなくて、TL のみなさんが焼肉奢れっていうから「じゃあ、代わりにいろいろ教えてくださいよ」って言ったらチラホラ本当に教えてくれる人がいて、このスキームは結構いいなって思って実際に始めた感じです。

そして始めてみると、いろいろな想いがうまく言語化できたような気がします。

知識やノウハウをもっと流動的にできないかと考えている

すえなみチャンスは自分の名前を使ってるくらいなので基本的には僕が僕自身のためにやってることで、僕自身の学習効率とか僕自身の満足度とかが重要なんですけど、最近はもうちょっとエモいことも考えていて、なんというかエンジニア不足が叫ばれてる中で、限られたリソースの中で未知の技術にチャンレンジしなければいけないとか、フルタイムでなく副業ベースの組織でナレッジをためていかなければいかないとかのソリューションとしてお手本にならないかと考えていたりします。

すえなみチャンスがゆるくコミュニティになるといいなと思っている

すえなみチャンスは僕が僕だけのためにやってることなので、公共の何かを口にするのは大変おこがましいのだけど、僕としてはなんかこれが何らかのコミュニティになったりするとおもしろいなーと思っていて、来年はそういうチャレンジもやっていきたいと思っている。*2

とりあえず、それの第一歩になるかどうかはわからないんだけど、以下のようなイベントを開催するので興味ある人はぜひ配信を見てもらえればと思います。

connpass.com

本日の焼肉屋

a-suenami Advent Calendar 2018 - Qiita ではすえなみチャンスにちなんで、毎回僕のこれまで行った焼肉屋の紹介をしようと思うのだけど、初日の今日は渋谷の太樹苑というところを挙げました。

僕は職場が渋谷だったことが今までの人生で一番長く、焼肉屋と言えばここっていうくらい何度も行ったところなのです。*3

塩カルビという肉があって「焼き方ご存知ですか?」と毎回聞かれます。(トングで叩きながら焼く)

ご賞味あれ。

tabelog.com

*1:拒否されたわけでなく、ブログ書くのが面倒でそもそも聞いてない

*2:具体的にどうするかは未定

*3:決して安いとか不味いとかってわけではないので、何度も行きすぎて当時の同僚たちが「太樹苑はもう飽きた」と言うほど。

流行り(?)のすえなみチャンスを実施した 〜ペアモデリングとペアプロと焼肉と〜 #すえなみチャンス

経緯

何故なのかまったくわからないんだけど、数ヶ月前からTwitter界隈で謎にタカられるようになった。 以下のようなハッシュタグまでできてもう収拾がつかない状態であった。

twitter.com

これはこれでネタとしておもしろいし、僕もいろいろ勉強したいこともあるので逆に利用してやろうと思って、

というツイートをしたのがもう半年くらい前。

ついに先日お声がけいただいた。

まさかの増田さん!!

というわけで、先日、増田さんの事務所にお邪魔していろいろ勉強させていただきました。

やったこと

ざっくりやったことはモデリングとそれの簡単な実装。

僕の前職がメディアの会社だったので、記事をコンテンツの中心とするサービスを真面目にモデリングするとどうなりますかねぇ、というのがテーマ。

ざっくりこんな感じ。

f:id:a_suenami:20180526174257j:plain

モデリングのあとは実際にコードに落とし込むためにペアプロ…のはずなんだけど、相手が増田さんなので言語はJavaで、普段僕はRuby使いなので言語にもIDEにも慣れてないということで、増田さんがずっとドライバーで僕がずっとナビゲーターって感じだった。

増田さんと一緒にモデリングペアプロ(?)をやった感想としては

  • 業務プロセスとかデータ構造が複雑になりそうなところへ嗅覚がすごい
    • メディアだと編集から公開にいたるいたるプロセスが複雑でしょ、とか、例えば画像コンテンツがあったときにその画像と記事はどっちが主役なの、とか
    • 複雑になりそうなところをあらかじめ抽象化しておいて具象クラスは差し替え可能なように設計しておきましょう、とか
  • 型名(クラス、インターフェース、Enumなど)の命名が早い
    • たぶんこれまでの経験からある程度パターン的なものがあるんだと思う
    • 変数名は型名と違ってかなりスコープが限定される*1ので、結構気分で命名するらしい

という感じでした。

焼肉

ペアプロ(?)のあとは近くのトラジにいきました。もちろん僕のお金です。

肝心の焼肉の写真を撮り忘れたので店の前の写真で失礼…

f:id:a_suenami:20180526203347j:plain

焼肉を食べながら感想戦というかむしろこっちが本番なんじゃないかというくらいモデリングとか昨今の技術トレンドに対するお話とかしました。 増田さんのこれまでやってきた仕事や今やってる仕事の話も聞けてすごく楽しかったです。(小並感)

すえなみチャンス参加者募集

なんか初回からすごい人が出てきてしまったのでアレなんですけど、 #すえなみチャンス は引き続きやっていこうと思ってるので随時募集中です。

やることは簡単で、僕とペアプロしてその後焼肉に行く、それだけです。

僕は今時間的な自由は比較的ある*2ので、自分の技術的な幅を広げたくていろいろなことをやってみたいと思っています。 iOS/AndroidアプリとかWebフロントエンドは特に強く募集してます。

*1:増田さんの場合は特に…

*2:無職という説もある

無限のメモリ空間と絶対に落ちないプロセスを仮定して「ビジネスロジック」をあぶり出す

先日、前職の上司から「そろそろプロフィールに"詩人"を追加するべきだ」と言われました a-suenami です。今日も今日とて詩人業を行なっていきますよ!

ビジネスロジック」とは何か

最近、業務で、比較的中長期的なアーキテクチャの見直しだったり、新機能の設計だったりをさせてもらう機会が増えた。

コンポーネントをどういう風に分割するかとか、それぞれのコンポーネントを主にどのチームでメンテナンスしていくかとか、そういうのを考えるのは楽しい反面、かなり熟慮に熟慮を重ねないといけないものでもあるのでかなり責任を感じるというのもある。

まあ、そんなこんなでいろいろうーんうーんって悩んでいると昔(たぶん DDD コミュニティだと思うけど)誰かに言われた「無限のメモリ空間と絶対に落ちないプロセスがあったとして、それでもそのコードを書かないといけないのならそれがあなたのドメインだ」という言葉だ。

モデリングをしているとドメインロジックとかビジネスロジックとかって言葉はよく出てくるんだけど、これは結構なかなか人によって解釈が違っていたり、明確な定義がなくて難しい。エリックエヴァンスの DDD 本ではユビキタス言語というパターンがあって、それがちゃんと構築できてる前提であればドメインか非ドメインかわかりやすいんだけど、あれをちゃんと実践するのはすごく大変だ。僕も何年か前にあの本を読んで以来、チーム内でいろいろ試みてみたけどいまだに手応えのある成功体験はないし、プロダクトオーナーを含むチーム全体を巻き込んでいかないとかなり厳しい。

で、もうちょっと簡単にそれがビジネスロジックなのか or not を判別したいことがあって、それをもとにその振る舞いをどこに実装していくべきかって考える感じのことがある。まあイメージとしては軽量 DDD というか、少なくともエンジニア同士では認識が揃っていて、何かを実装しないといけないときにそれをどこに定義すればいいかを迷わなくてもいい仕組みくらいだと思ってもらえるとよいと思う。もしそれを修正しないといけないことになったとしたときに、それがビジネス都合なのか、アーキテクチャ都合なのかをちゃんと区別して、決してそれが混じらないということが実現されるだけでもかなりシステムのメンテナンスは楽になる。逆に、どっち側の変化によっても同じオブジェクトやメソッドが修正されるという状態は明らかにオブジェクト指向設計の単一責務原則に反しているし、障害が発生したときの問題切り分けが著しく難しくもなるので基本的に避けたい。

もちろんそうやって分割されたオブジェクトやメソッドのうち、ビジネス都合で定義される側のクラスやメソッドがユビキタス言語になってるほうがなおよいけど、まあそこは一旦エンジニア同士で伝わればいいよねっていう妥協もアリだと最近は思い始めた。*1

そして、その判別方法が「無限のメモリ空間」と「絶対に落ちないプロセス」を仮定することによる思考実験である。たぶん厳密には「断線・遅延しないネットワーク」も必要なのかもしれないけど、まあ要するに永続化やキャッシングから解放されたときにそれでもそのコードは必要なのかっていうことで、これはなかなか結構おもしろい思考実験である。

僕たちがどれだけ永続化に関するコードを書いているか

これ、実際にやってみるとわかるんだけど、実際に考えてみるとほとんどのコードは必要なくなるってことに気づく。僕らが一体どれだけ永続化とキャッシュに振り回されてるのかってことだ。

逆に言うと、そのレイヤーの心配ごとが軽減すれば僕たちはもっと自分たちのビジネスに集中できるし、ちゃんとしかるべきクラスだかオブジェクトだかに隠蔽してあげてビジネスロジック層からは意識しなくて済むようにしてあげるべきなんだよ。設計ってそういうことだと思うんだ。僕が ActiveRecord を Dis るのは(おっと誰か来たようだ

システムは何故バグるのか

これは完全に僕の経験則だけど、システム障害において、ビジネスロジックにバグが混入していたというケースは実はそんなに多くない。エンタープライジーな開発現場を経験してないので、そもそもこのレイヤーのロジックが薄いプロジェクトしか知らないというのはあるのかもしれないけど、それにしたって永続化やキャッシュに関するバグ、ミドルウェアや連携システムの冗長化不備がほとんどである。

その中でも本当に多いのは

  • キャッシュに関する何か
    • リフレッシュされてなくて古いキャッシュを参照する、等
  • 失敗可能性(要するに NULL 参照)の考慮漏れ
  • 永続化したデータの取得遅延
    • まあ、平たく言うとスロークエリ

で、僕は勝手にこれを三大バグ発生要因と呼んでいる。(あくまで勝手に)

永続化もキャッシュもなくてよくて、NULL もない、そんな理想郷がもしあるならその世界で実装されるシステムの障害は激減するはずだ。

ビジネスロジックは意外と薄い(かもしれない)からこその創造性

これは仮説だし、僕自身まったく検証できてないんだけど、それを念頭に読んで欲しい。

思考実験として仮定した無限のメモリと落ちないプロセスは実際には実現不可能だけど、コンポーネント分割を工夫して永続化に関する関心事をあるレイヤーで隠蔽することはできるし、そうするべきでもある。それによって、少なくともビジネスロジック層から見れば永続化を意識しなくてよくなるので、先に述べた理想郷が仮想的には実現できる。

で、このときに気づくんだけど、実際にはビジネスロジックなんて予想外に少ない。もちろんドメインによると思うけど、Web アプリケーションにおける参照系の機能(つまり Web ページの閲覧)なんてだいたい DB に入ってるデータをそのまま画面に表示するだけだったりするし、あるとしたら表示整形くらいでそれはビジネスロジックというよりはプレゼンテーションのロジックだ。僕は今メディアの会社にいるのでなおさらだけど、ビジネス = プレゼンテーションみたいなもんである。

そういう状況にエンジニアが放り込まれたらどうなる?

エンジニアは本質的にコードを書きたい人種が多いんじゃないかと僕は思っている。そんな人たちが永続化の関心事が隠蔽されていて「コードを書く必要がない」環境に置かれたら、どうやったら自分たちはもっとコードが書けるか、こういう機能が実現できたらいいんじゃないかっていう創造性が発揮されるんじゃないかなと。これは予想というよりも自分と一緒に仕事をしてくれる人たちにそれを期待したいっていう意味も込もってるんだけど。

もちろん一定数のエンジニアには低レイヤーへの憧れみたいなものもあると思うし、僕も若い頃には Linux コマンドを使いこなして、呪文のようなバイナリを見たり、まるで MySQL と会話しているかのような先輩エンジニアに尊敬の念をよく抱いたものである。ビジネスロジックが意外と薄いということは、逆に言えばシステムの根幹をなすのは永続化部分のコードだとも言えるのでそこに興味を持つのは自然なことだし、その場合は隠蔽された先の、永続化に関するコンポーネントの実装に携わればよい。

重要なのは、今自分が何のコードを書いているのかちゃんと意識すること。

ビジネスを加速していくために新しい機能を実装するか、その人たちを支えるために適切に永続化を隠蔽するか、趣味・嗜好も得手・不得手あるだろうし、会社やチームの都合でどっちがより重要なフェーズかってのもあると思うけど、少なくともそこが適切に分離されていて、どちらかをやっているときはもう一方を意識しなくていい状況は最低限実現していきたよねと思った週末なのであった。(いい感じにまとまった。たぶん。)

追記 2016/09/25 16:01

きょんさんからコメントいただいたので追記。

このエントリで「ビジネスロジック」という言葉を使ったのは単にわかりやすいと思っただけなのと、代替できるわかりやすい他のワードが思いつかなかっただけである。今となっては反省している。

僕自身も普段の業務において「ビジネスロジック」という言葉はあまり使わないので、とりあえず Twitter ではしれっと弁明しておいた。

ただ何て言うんだろうな… まさにきょんさんが言っている「適切に分割して、適切な注意を払え」っていうのがこのエントリで一番伝えたかったことで、それはどんなシステムでも必要なことだろうし、ましてオブジェクト指向パラダイムを持つプログラミング言語を使っていれば息を吸って吐くようにできないといけないことではあるんだけど、実際にはそれができてない人やチームがあって、そのときにわりとわかりやすい分割の方法論としてのこの思考実験を提案したかったっていうのがたぶん正しい。

このエントリで言っている「ビジネスロジック」というのは適切な命名が難しいので長ったらしい文章で説明するしかないけど「非機能要件を隠蔽して機能要件のみを抽出したもの」のことで、これは技術的バックグラウンドのない人のメンタルモデルに近いはずだし、ユースケースはここで抽出された語彙を使って記述されるべきだよねって僕は思っているので、そのためにはまずそこを分割して語彙を手に入れないといけないというのが主な主張。

ちなみに「ユーザーストーリになればより非機能的な部分がふえてくる」というのはきょんさんのコメントで初めて気づいた。確かにそうだ。

さらに追記 2016/09/25 16:16

もしかして機能的・非機能的という分類自体がもう必要なくて、やはり時代は ActiveRecord なんだガハハみたいな意見があったり、そういうデザインパターンや組織パターンがあるのだとするとそれはそれで興味深い気もする。

システムというのは必ず何らかの要求にもとづいて構築されるもののはずで、従来(汎用機〜クライアント・サーバ時代まで?)はその要求の内容として機能的なものが支配的で非機能的なものはエンジニアが何とかすればよかったけど、今はそうじゃなくてむしろ非機能的な部分こそがビジネスの中心を担うことがある(実際、僕の今いる会社とかはその可能性がある)のだとすると、その非機能要求が一体どういう言葉で誰の手によって作られて、どういう伝達をされて、どのようにして実際のチームの開発プロセスに取り込まれていくべきなのかという議論は大変興味深い。

十分な性能、十分なセキュリティ、安定稼働、こういったものは今までは UX のなんとか品質モデルでいうと「当たり前品質」とかって呼ばれるものだったと思うんだけど、むしろこれが「動機付け品質」になりうるのだとすると、そのときの組織のあり方やアーキテクチャのあり方はどうあるべきなんだろうな〜とちょっと思ったりする。

*1:DDD界隈の方々、すいません。マサカリは甘んじて受ける覚悟です。