エムスリーを退職してフリーランスになっていました

TL;DR

  • 2019年2月にエムスリーを退職してフリーランスになっていました。
  • お仕事の相談お待ちしています。

何で今更書くの

www.m3tech.blog

2月に前職のRailsアップグレード記事と見せかけた退職エントリを書いていたのだけど、ちゃんと書いてなかったので改めて書きます。 辞める月に某異常にTwitterでフォロワーの多い機械学習エンジニアの方が入社して隣の席にいたので、「俺もnoteで退職エントリ書いて有料にして売りますよwww」とかイキってましたが機を逸したのでやめます。

エムスリーでは何をやってたの

レガシーシステムのリニューアルを中心にKotlin / Nuxt.jsとかやっていて、その後はAI機械学習チームというところで、新規事業の機械学習部分以外のアプリ / インフラをやったり、次の機械学習基盤の調査のためにGKE使ったCI / CDのPOCを作ったりしていました。

employment.en-japan.com

AI機械学習チームはCS強い人が集まっていて、そういう環境で働いたことがなかったのでめっちゃ刺激的でした*1。最近は外から見てもますます存在感が出てきてほんとすごいなーと思います。昨日も「エムスリーは機械学習強いですよねー」と言われてビビりました。

また採用関連のあれこれをやる採用チームというところにも所属していて、自分は主にテックイベントのスポンサーとか、エンジニアが働きやすくなるようなツールの導入なんかを頑張ってました(Slackとか)。自分が入社したときには「おいおい2017年にこの環境はまじかよ……」みたいなところも正直ありましたが、今はWEB系企業としてはそんなに悪くない感じになってるんじゃないでしょうか。自分がめっちゃやりましたみたいな書き方になりましたが、謙遜とかではなく自分の貢献はSlackやデファクトなツール類をいくつか使えるようにしたくらいで、西場さんを筆頭に色んなチームや人のやっていきで少しずつ改善されていきました。

会社としてめちゃくちゃROIを重視する文化で大変な面もあったんですが、そういう環境でもがいたおかげでエンジニアとして視座はかなり上がりました。根がテキトーな人間なので、バランスがよくなったと言えるのかもしれません。

フリーランスになって今は何をやっているの

基本これまで働いたことのある人がいる会社、あるいはそこから1ホップくらいの知り合いがいる会社で以下のようなことをやっています。

去年の11月に二人目が生まれたので「子供が生まれたからフリーランスになったんですか?」とよく聞かれたんですが、別にそういうわけではなりません。ただ、働いてみるとフリーランスの働き方のほうが色々と都合がよい事が多くて、少なくとも下の子が離乳するまではフリーランスでやろうかな〜と思っています。とはいえそんなに長く続けるつもりもなくて、関東IT健保の任意継続が切れるまでには、また普通に正社員として働こうかなってかんじです。

お仕事の相談お待ちしています

WEBアプリケーション開発に関することなら大体できますが、雑にやれることを書くと以下のような感じです。

  • 結構やれる
  • まあまあやれる
  • あんまやったことないけど今やってる
    • Flutter

基本リモートで働きたいので「週5フルで会社来てくれ!!!」みたいなのは無理ですが、たまに打ち合わせは対面でやりたいーみたいなのは対応できます。 直近は結構埋まってしまっているのですが、まずはDMでご相談いただければと思います。

twitter.com

単価は大体以下の本でいうシニアエンジニアくらいとなっております。

booth.pm

最後に

エモい退職エントリが読みたい / 書くぞと散々言っていましたが、特に当たり障りのない内容になりました・・・・・・

*1:XXXX(WEBフレームワーク)のXXXはどういうアルゴリズム使われてるんですか?とか聞いて来る人はじめてみた

車を買った

車を買った。

地元では車は生活必需品だったが、首都圏では何かしらの公共交通機関が基本的に徒歩圏内にあるし普通に生活する分には車を買う理由がないように思う。もともと車にはそんなに興味がなく、このまま関東で暮らすなら車を買うことはないかもなーと思っていたのだけれど生活上ないと困るようになってしまったので、購入することにした。

なぜ車が必要になったか

二人目の子供が生まれたのが大きい。子供が一人のときはまだよかったのだけれど、二人になると子供を抱っこして出かけて家に帰ってくるだけで疲れ果ててしまう…*1また子供2人を抱えてバスや電車に乗るのはとてもしんどい。二人目の子供が生まれてから家族で買い物にいくのがかなり大変になってきてしまったので、車を購入することを決めた。

何を買ったか

いわゆるVOXYとかALPHARDとかデカめのミニバンはもう5〜6年運転していない自分にはきつそうだし、普通のセダンタイプやコンパクトカーでは収納スペースに不安がある…ということで、TOYOTAのSIENTAとHONDAのFREEDに絞った。最終的には義父の知り合いで懇意にしているTOYOTAの販売店の方がいたこともあり、SIENTAに決めた。

車の購入手続きって色々申請とかしないといけなくてめちゃくちゃ面倒な印象を持っていたけど、基本販売店の方が自宅に書類も持ってきてくれたし手続きも代行してくれたので、書類に記入とハンコしてお金を振り込んだりするだけで手続きが済んだ。

買ってみて

これまで子供を連れて電車でいけるショッピングモールに行くと自宅に帰ってくるころにはヘトヘトになっていたのだけど、車なら子供を連れて移動しても体力を残したまま自宅に帰ってくることができた。

またこれまで公共交通機関では行きにくい場所には当然ながら足が遠のいていたのだけど、車で移動できるようになってかなり行き先の選択肢が広がった。

あとこれは結構驚いたのだけど、車を運転することが結構好きになってきた*2。最近は休日になると理由をつけてどこかにドライブに行きたくなっている!子供も出かけるの楽しいみたいなので、買ってよかったなーと思っている。

あと最近の車の進化すごい。自分が過去に乗っていたのは安い軽自動車だったので当たり前なのだけど、スマホとつながったり便利な機能がたくさんついていて、ロボットに乗っているようで楽しい。

まとめ

二人目の子供が生まれてから必要に迫られて車を買ったのだけど、車楽しい。でも今年の家庭の収支は大赤字なので(当たり前)、お仕事もっと頑張らないなーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

*1:3歳の方は行きは自分で歩いてくれるけど、帰る頃には疲れて抱っこモードになる

*2:上達したとは言っていない

認定スクラムマスター(Certified ScrumMaster)を取得した

いまお手伝いしている会社でスクラム導入を支援していて、自分もスクラムマスター(兼開発者)をやっている。 これまでにスクラムに関する本はいくつか読んできたし実戦経験もあったが、改めてスクラムについて深い理解を得たいと思い認定スクラムマスター研修(以下、CSM研修)に申し込みをした。

研修について

私が受講したCSM研修はMichael Jamesさんという方が講師で(基本は英語だが日本人のAgileコーチの方が通訳してくれる)、3日間というスケジュールで研修が行なわれた。 研修を受けるだけで無条件でCSMに認定されるわけではなく、以下のようなプロセスを踏んで初めて認定となる。

  • CSM研修を3日間受講する
  • CSM研修でオンライン受験資格があることを認められる
  • オンライン試験をパスする

研修はチームで行うワークショップ形式のトレーニングが多く和気藹々と行なわれたが、研修を終えればかならず受験資格がもらえるわけではないようだ。以下のような注意が申し込みページにものっていたし、申込み後のメールでも送られてきた。

  • 全時間受講が義務づけられております。遅刻や早退、途中退室は無条件で認定できません。
  • パソコンや携帯電話の使用等、ルール違反は認定できません
  • 本トレーニングでは、受講中の能力をもとに評価し、オンラインテスト受験資格(=認定候補者)を付与しますので、積極的な能力アピールを必要とします。参加するだけでは認定となりませんのでご注意ください

とはいえ、よっぽど受講の態度が悪かったとか消極的だったとかでなければ、受験資格はもらえるのではなかろうか。ただ過去取得した人の話だと、遅刻して受験資格が与えられなかった人がいたり、レポートを追加で提出することを求められたりということはあったようだ。

学んだこと

スクラムの具体的なやり方については、LeSS (Large-Scale Scrum) など知らないこともあったが、70%くらいは既に知識としては知っていた内容ではあった。この研修で良かったのは、具体的な方法論というよりは、スクラムの考え方、原則などをアジャイルソフトウェア開発宣言なども交えながら、ワークショップ形式で実体験として学べたことだ。講師の方が初日に「皆さんのこれまでの経験をunlearnする魔法があればスクラムマスター研修は1日で終わります」と言っていたが、まさに3日間かけて従来型のマネジメント・プロセスの考え方をunlearnしてもらっていた感じだった。

頭では認識していたものの、実は実践できていなかったなと気付かされたのは以下。

  • ソフトウェア開発は複雑で予想の難しいカオスな領域の仕事であることを認識する
  • ある程度の曖昧さ・不確実さを受け入れる

そして何となく思っていたものが言語化されたのは以下。組織の中の個人が自分の行動をROIで図ることに対して違和感がすごかったのだけど、きれいに言語化された感覚がある。

  • 不確実性の高い分野では生産性より学習を重視する

そしてこれはスクラムの話じゃなくてアジャイルマニフェストの一文ではあるけど、以下。特に最近バックログを必要以上に詳しく書いてもらおうとしたり、新たなプロセスを組もうとしていたのだけど、反省した。ただ対話することが一番の解決の場合も多いのだ。

  • プロセスやツールよりも個人と対話を

スクラムではどんな組織構造になっているべきか、featureチームとcomponentチームを対比して説明・ワークショップがあった。マイクロサービスが流行っているが、どういう開発組織が良いのかということを考える機会になった。マイクロサービスを志向する会社でも、 componentチームになっていて依存関係が爆発していて、開発効率が上がってないという事例はありそうだなと思った。

自分の参加した会がたまたまそうだったのかもしれないが、SIer / コンサル系から来てる人が多く、プロダクト開発ではなくプロジェクトマネジメントを期待して研修に来ている人がとても多かった気がする。そもそも今ウォーターフォールで…とか、開発はベンダーに投げてて…みたいな人が結構多くて、現場でスクラムどうしてるみたいな話が他の参加者とあまり出来なかったのは少し残念だった。 *1

まとめ

この研修は結構お高い*2のだけれど、これからスクラムやっていく人や、スクラム始めたけどピンと来ていない人、マネージャーなど開発組織づくりに関わっている人は、一度受けてみることをオススメします!

*1:ただ、そういう人たちも、最終日になると「組織を変えて行かなきゃ!」みたいな姿勢になっていたのが印象的だった。

*2:自腹で30万はなかなかキツかった

「Measure What Matters 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR」を読んだ

流行ってるので読んだ。

内容について

著者であるジョン・ドーアというGoogleに投資した投資家が、Intel で学びGoogle含む投資先の企業に伝えたOKRという手法についての本。

それぞれの企業が OKRをどのように活用したのかというケーススタディを中心として、OKRはどのように設定するべきかやOKRをどのように運営するかという話が展開されていく。どちらかというと経営層の立場から、OKRを組織にどのようにインストール / 運用するか、という話が多い。そのため1社員として、どのようにOKRを設定するべきかのようなHow Toを期待すると面食らうかもしれない。

感想

OKRについて「野心的な目標としてObjectiveを、それを図る指標としてKey Resultsを決める」くらいの認識しかなかったし、過去職場に導入されたときもOKRを導入することで何かが良くなるなんていうことには懐疑的だった。しかしこの本を読んで、それは自分がOKRを「個人の目標管理手法」くらいにしか捉えていなかったからなんだなと気がついた。OKRは最終的には個人も設定はするものの、根本は「組織として何にフォーカスして、何にコミットするのか」を明確にするということなんだなと思う。

だからOKRを元にどう組織を運営していくのかということが重要で、個人がどうOKRを立てたらいいかといった話はOKRの一部に過ぎない(もちろん適切に設定することは大切)。だから組織として何にフォーカスするかというOKRの設定無しに、個人がそれぞれ勝手にOKRを設定してもあまり意味がない(これまでの目標管理とあまり変わらない)ということが分かった。 OKRを実践するには、適切なOKRの設定だけでは全く不十分で「これはKRのXXXに寄与するからやろう」とか「これはどのKRにも寄与しないんじゃないか?」みたいな会話が現場でできる必要があるんじゃないかと思う。

OKRはあくまで組織として大きな成果を出すための手法なのだということを理解すると、OKRでよく言われる以下の項目がだいぶしっくりくるようになる。

  • 全メンバーのOKRは共有されている必要がある
  • OKRを給与評価と連動しない

上述したとおり、適切なOKRの設定方法みたいなHow Toを提供してくれる本ではないのだけれど、1社員の立場で自分の立てるOKRはどういうものが望ましいのかということのエッセンスはつかめた気がする。 自分の目標というよりも、自分の役割の中で何をすれば会社のOKR達成につながるか、と捉えてOKRは設定したほうがよいのだろうなー

2018年の振り返り

2018年にやったことの振り返り。年末に書いていたのだけど熱を出して寝てたので年が明けてしまった・・・

大まかな仕事としてはこんな感じ。平行して採用関連の仕事や、他チームの支援なんかもやっていた。

  • 1-6 月 レガシーシステムのリニューアル (Kotlin + Spring Boot + Nuxt.jsなど)
  • 7-11月 機械学習チームに異動しての画像認識を使った新サービス開発(Rails + Vue.js + Flask + TensorFlowなど)
  • 12月 2人目が生まれたので育休

仕事

レガシーシステムリニューアルやった

上半期の振り返りに大体書いた。自分は主軸を機械学習チームに移したが、もともとのチームでちゃんと機能開発などできている状態なのは嬉しい。 suzan2go.hatenablog.com

機械学習チームに異動した

7-11月に機械学習チームに異動していた。とはいえ自分自身は機械学習をやっていたわけではなく、機械学習を使った新サービスの機械学習部分以外を全部やっていた感じ。全体のアーキ設計からAWS等のインフラ、アプリケーションの実装まで、機械学習そのもの以外のところは全部やれたので楽しかった。機械学習を活用したアプリケーションだと、メモリがめっちゃ食うとかGPU使わないと遅いとか普通のWEBアプリとは違う考慮ポイントが沢山あって設計のしがいがあった。

前述したとおり機械学習そのものは触らなかったのだけれど、機械学習エンジニアの作ったモジュールを動かしたり、 TensorFlowが動く環境作ったりするのはそれだけで面白い。AWSで環境をTerraformで作るところも、機械学習エンジニアの作ったモジュールを組み込んだPythonAPIサーバを作るのも、ユーザー側画面のRailsも、そのフロントのVue.jsも、ほぼ自分一人でやってたので、途中は死にそうだったけど、PM / 事業責任者がMVPを理解してくれていて仕事がやりやすかった。

他チームの支援した

他チームでレガシーシステムのリニューアルやっているところがちょっと炎上していたので、プロジェクトの支援を一ヶ月くらいやっていた。具体的には以下のようなことをしていたと思う。

上述の機械学習チームでの新サービス開発、イベントでの登壇など重なっていて正直キャパオーバしていて、あまりちゃんと支援できなくて申し訳ないなという気持ち。。。それでも一緒にやってもらえて助かったと言われたのが救い。

採用まわり

採用そのものというより、イベントのスポンサー関連の仕事が多かった気がする。ノベルティ作ったり、ブースの対応なんかはだいぶ知見が溜まってきていて、自分が関わらなくても普通に回るようになっているのが嬉しい。Vue Fesのスポンサーで、会社のロゴが入ったビールを、Vue.js公式Twitterで取り上げてもらえたのは、最高だった。

他には、リモートワークを始めるためのルールとかその辺の整理とかやったりした。他社と比べると、環境面ではまだまだというところも多いので改善していきたい。

この振り返りとは直接関係ないんだけど、他社のリモートワーク・副業の状況を表にしてみると、リモートワークはイメージほど認められてない(メルカリも調べた限りではやってないし、認めている会社も週1までとか制限が多い)けど、副業を認めていない会社は大手WEB系でも殆どなかったので驚いた。

育休

11月下旬に二人目が生まれたので、そこからすぐに育休をとった。一人目は特に育休はとらなかったのだけれど、二人目ということもあり取得した。一人目のときに比べて自分たちの育児スキルがあがっているということもあり、赤ちゃんのお世話は自体は一人目と比べるとだいぶ楽。上の子と下の子が同時にグズったときは本当辛いけど、上の子がだいぶお姉さんやってくれるようになってきたので、何とかなりそうな気がしてきた。2019年1月から復帰です。

登壇

2018年は意識的に登壇回数を増やした。 Kotlin Fest 2018、Vue Fes Japan 2018 Reject Conferenceといった100人以上の参加者がいる会場で発表できたのがよかったなと思う。JS、Kotlin、Rubyと3つのコミュニティで登壇できたの何気にすごいと思っている(自画自賛)

あとgRPC-Webについての資料が自分の資料では過去最高記録ではてブがついて嬉しかった。*1

roppongi.js

社内テックトーク

roppongi.js

meguro.rb

Kotlin Fest 2018

meguro.rb

Vue Fes Japan 2018 Reject Conference

登壇ではないけどエンジニアHubに取材してもらったりも。怖くてはてブのコメント見てなかったけど好意的なものが多くて安心した。

employment.en-japan.com

インプット

2018年の前半ではDDDに関する本を読んだりしたけど、読んだのは全体的にマネジメント・採用に関する本が多かった。特に読んでよかった本としては以下。

実践ドメイン駆動設計を読んだ - suusan2号の戯れ

ティール組織を読んだ - suusan2号の戯れ

「チームが機能するとはどういうことか」を読んだ - suusan2号の戯れ

「エンジニアリング組織論への招待」も読んだし面白かったけど、個人的には「ティール組織」の方を推したいと思います。

所感

技術的には本当に色々できた1年だったと思う。仕事でいろんな言語やFWを触ったことで、自分のなかで設計・実装のレベルを一つ上げられたような感覚がある。 また今までWEBアプリケーションのインフラ構築を一から自分でやった経験は仕事ではなかったのだけれど*2、Terraform使ってAWS環境を作るところを一通りやれたのはよかった。

一方で上に書いたことと微妙に矛盾するのだけれど、さらに自分が触ったことのない言語やFWを使ったWEBアプリケーションの開発を経験しても、現時点ではそれほど成長していけるイメージがない。もうすこし何かを突き詰めるか、全く別のことをやらないと行けない気がしている。そうなると自分が目指すべきはEMとか、SREとかになるのかなぁ。社内にげきつよ機械学習エンジニアがいるので、その人に師事して機械学習エンジニアを目指すのもありかもしれない*3

あとはこの1年で複数のプロジェクトを渡り歩いたので、もうすこし腰を据えてプロダクトに取り組みたいという気持ちもあったりする。今の所、これやってみたい!と思えるようなのは社内にはないのだけれど。

2019年の抱負

今年の抱負を書こうと思ったのだけど、仕事においては特に思いつかなかった。育休で一ヶ月以上家族と向き合ってるからかもしれない。

思いつかなかったけど、今年は車買わないといけない波動を感じているので、1.5ばんくし くらいもらえるように頑張りたいと思います。5000兆円欲しいです。

あとがき

下書きのまま年が明けてしまったので、2018年に書いた「今年」を「2018年」に置き換えるのがめちゃだるかった

過去の振り返り

suzan2go.hatenablog.com

suzan2go.hatenablog.com

suzan2go.hatenablog.com

suzan2go.hatenablog.com

*1:はてなブックマーク - フロントエンドエンジニアも知っておきたいgRPC - Speaker Deck

*2:既存の構成に何か追加 / 削除する程度はやったことあった

*3:ジョークです

クラウドワークスを退職して一年くらいがたちました。

この記事はex-crowdworks Advent Calendar 2018の17日目の記事です。  

クラウドワークス辞めて大体一年くらいたちました。辞めるときに会社のブログに退職エントリーを書いたのですが、まあ当然当たり障りのないことしか書いてないし、一年経ったからこそ冷静に見える点も色々あろうということで何か書きます。

注意として、自分がいたのは2017年10月までですので、当然情報も当時のものとなります。今とは異なる部分もあると思いますので、鵜呑みにしないで全部妄想だと思っておいてください。

なぜ辞めたのか

昨日終了してしまったこのサービスの立ち上げからリリース後の諸々が本当に大変で若干燃え尽き症候群になっていて、技術面、環境面で今と違うことをやりたくなったというのが理由の一つ。これはやんわりと会社のブログにも書きました。もう少し具体的に書くと以下です。

  • Rails + JSでずっと仕事していて、このスキルセット以外のところもやっていきたい
  • 海外経験積みたい

当時はこの2つを軸に次の会社を選んでた気がしますが、今思うと後者はそれほど重要じゃなかったかもしれない。というか子供が小さいうちはなかなか海外にいったりは、出張ベースでもなかなか難しいですね*1

もう一つはまあぶっちゃけ金です。奥さんが専業主婦だったので、子供が生まれてからは特にこのお賃金じゃ結構きついなーという感じでした。今思うとそう思うようになったきっかけは転職ドラフトで、「あれ、もしかして私の年収低すぎ・・・?」となったからだった気がする。もちろん残って会社の中で給料上げるという選択肢もありました。しかし当時の人事考課制度では何回最高評価取り続ければそこまでいけるねん・・・って感じだったというのもあり、いくつかの会社に話を聞いて内定をもらい、転職したという感じになります。

在籍中に給料が上がらなかったわけではありません。在籍2年半の間にたしか80万くらいは上がったかなと思います。ただ入社時に結構年収下げて入った(当時はSIでSEやっていて、プログラマとしてはヘッポコだったので納得はしています。残業時間もだいぶ減ったし)というのもあり、、、というところからだいたいどのくらいのお賃金だったか察してください。

で、転職してどれくらいあがったのかというと、前にmizchiさんがつぶやいてた内容を御覧ください。いくつかの会社から内定をもらいましたが、提示額でいうと最低でも大体これくらいのアップにはなってました。

エンジニア全員の給与を把握していたわけではないので、給与水準がどうだったのかとかということは正確には分かりません。何人かから話を聞いた感じだと、相場からは低かったような気はしますが、自分に関していうと上記のTweetのような状況だったように思います*2。昇給レンジや昇給プロセスは、どれくらいの成果を出せば・何ができるようになればどれくらい年収に反映されるかというのがある程度明確というメリットがある一方で、市場価値との乖離が大きい場合にはデメリットもあるなと思ったのでした。

転職してみて

転職先は大人の事情でここには書けないのですが*3、それなりの規模の会社です。社内に沢山のシステムがあり、技術選択の自由度が本当に高いので、自分の技術の幅も相当広げることができました。クラウドワークスにいたときはほぼRails、JS(CoffeeScript……)が全てという感じだったわけですが*4、転職後はSpringBoot、Kotlin、JavaPython、Vue.js、TypeScriptなどをプロダクションで書いていて、普通に仕事してるだけでネタができて、いろんなコミュニティ(Kotlin、Ruby、Vue.js……)で登壇できたのは凄くいい経験になりました。

一方でクラウドワークスのときのほうが色々と緩かったので、自分たちが使うツールやプロセスの自由度(タスク管理ツールとか)は高くて、各チームが自分たちにあったものをガンガン導入して使えていたので、転職直後は結構萎えていたりもしました。DXを高めるためにchat bot作ったり、CIにフックしていろんな警告だしたりといった取り組みが活発だったので、転職してから「ゴンお前だったのか・・・」みたいな気持ちになったりもしました。ただ最近は現職も結構改善が進んで、自分の貢献はほんの少しですが、1年前と比べるとかなり良い環境になってきたと思います。

また開発プロセスなんかもクラウドワークスにいたときの方が色々進んでいたなと思う面もあるわけですが、実際にそれでビジネス面でうまくいっていったかというと、あくまで個人的な感覚ですが当時はそんなことなかったので、なかなか難しいなと思ったりしました。綺麗なコードを書けば利益がでるわけではない・・・・・・的な方向の話です。

あとは現職で数年塩漬けにされてる中身がわからない独自FWのJavaのリプレースとかやった今、クラウドワークス時代に技術的負債とか言ってたものの中にはそんなに大げさなもんでもなく粛々とやればいいだけのものも合った気がしました。まあ確かに両端ポリモーフィックのテーブルみたいな闇とかもあったような気もしますが妄想だからきっとだいじょうぶです。

まとめ

なんだかんだ最低限の社会性フィルターを通して書いていたら割と当たり障りのない内容になってしまった・・・・・・

一つ言っておくことがあるとすれば、転職のときに社長や経営層の人と話して感じた違和感のようなものはきっと大切にしたほうがいいということです。

*1:うちの場合はですが

*2:繰り返しになりますが当時のお話であり、今どうなってるかは知りません

*3:自分の過去資料とか漁ってもらえば分かるはず

*4:いまは新規事業でReact Nativeのアプリがあったり、APIを静的型付き言語・DDDで作りかえようみたいな話があるようです