Findy Engineer Lab

次世代のエンジニアのキャリアを考える

Chatworkテックリードが“今”の自分に集中してきた理由。Scala×DDDに出会い、サービス改善に生かすまで

“今”に集中することの意味。興味がある技術を「点」として学ぶことで、やがて「線」となり「面」となる

こんにちは、Chatworkでテックリードをしている、かとじゅん@j5ik2oです。

今年(2020年)で48歳になりましたが、技術に前向きになったというか、本気を出したのは37歳ごろでした。遅いな……(笑)。まぁ、遅い早いが重要ではなく、学びを深めるには「やる気」の維持が欠かせません。私の場合、興味を持てるテーマが運良く見つかっただけだと思います。

振り返ってみると、これまで興味を持ったDDDやScala、Akkaといった技術は、現在の仕事に生きていることはもちろん、コミュニティへのフィードバックにも貢献できていると感じています。

こう言うと「先を見通すことができたんですね。次はどの技術が台頭しますか?」と質問されることもありますが、それは誤解です。未来は予測できません。現在のDDDやScalaの姿を予想していたわけでもありません。興味を惹かれたから、楽しいから始めただけです。偶然が重なって「点」と「点」がつながっただけです。

社会人経験もそれなりに長く、相当なジョブホッパーの私ですが、これまでキャリアの節目で何を考え、選択してきたかを振り返ってみます。これからキャリアを築くエンジニアの皆さんに、何かしらヒントになるならうれしいです。

自分が気づいてなかった資質を、探して、磨く

小学生のころから何度かプログラミングに熱中しました。自宅にたまたまPASOPIAがあり、太陽系の軌道を描画するプログラムをBASICで作ったりしました。高校生でアルバイトしてゲーム機として買ったPC-88VAでもBASICに熱中し、工業高校のプログラミングの授業で、先生の間違いを指摘できる程度には理解していました。

19歳で大手電機メーカー(蛍光灯工場)に就職し、ITに直接関係のない製造技術や品質管理を担当。ツールを独自に開発して業務効率を上げると仕事が楽しくなることを実感し、C言語やアセンブリ言語などを一通り学びます。

プログラミングを本業にする願望が強くなり、実家を離れて大阪のSES企業に転職したのが26歳。これが、自分の資質に気付くまでです。

劣等感に消耗するより、目的志向で考える

それからの10年は、よく言って試行錯誤、悪く言えば迷走していました。

Windows NT上で分散システムを開発する現場で、Win32 APIからクラスライブラリを作ることになりましたが、オブジェクト指向が分かっていなかった。劣等感に苛まれ、進捗も出ず、このときの挫折感はすごかったです。

劣等感をどう克服するかは難しい問題で、原因を追求すると自己防衛的でネガティブになりがちです。目の前の課題や目標を達成するにはどうするか? という目的志向の方が建設的だと考え、周囲の優秀なエンジニアとの議論やコーディングなどのアウトプットを重視するようになりました。

Webの案件も増えてきたことから独立し、PHPの仕事を受けるようになりました。PHP 4のオブジェクト指向が限定的だったことからJavaに憧れ、というか興味を持ったのもこの頃です。そして上京し、インターネットを仕事の中心にしようと、渋谷のネットベンチャーで働くことにしました。

オープンソースコミュニティへの参画

WebシステムをJavaで作ることが多くなり、注目したのはSeasarプロジェクトでした。Seasar2(国産のDIコンテナ)を中心とした関連プロダクトを使って、ソフトウェア開発の生産性が劇的に向上したのです。

私自身もSeasarプロジェクトでサンドボックス・プロジェクトを立ち上げ、コミュニティに関わるようになりました。Seasarの有識者ということで、その後の転職先でも活躍する機会が増えました。

ブログや雑誌の連載で技術ネタを書くことも多くなり、コミュニティのエンジニアたちと夜な夜なお酒を飲みながら、議論を深め、多くを学ぶことができました。全盛期には大学の講堂を埋めるぐらいの開発者たちが、Seasarのカンファレンスに参加し、技術談義に花を咲かせました。

ドメイン駆動設計とScalaが「点」となる

ソフトウェア開発は「生産性が高ければよいのか?」と言うとそうではなく、保守性への考慮も忘れてはいけません。MVCに基づいて設計しても、手続き型のロジックがあちこちで重複し、設計に苦労していました。いわゆるトランザクションスクリプトという設計パターンです。

いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - higayasuo’s blog

もう少し何とかならないのかと悩んでいたころ、Seasarプロジェクトの比嘉康雄さんによるこのエントリーを読んだこともあり、ドメインモデルに興味を持ち始めました。

ソフトウェア設計について知識を深めたい。そう思ったときに出会ったのが、エリック・エヴァンス(Eric Evans)さんが著書『Domain-Driven Design(2003年、Addison-Wesley)で紹介したドメイン駆動設計(以下、DDD)と、プログラミング言語Scalaでした。

ドメイン駆動設計との出会いと成果

当時は原書しかなかった『Domain-Driven Design』を2009年11月に手にして、自分で工夫しながらJavaで実践を始めました。周りに議論できる相手は当初ほとんどおらず、同僚@daisuke_mと苦労しながら難しい英文を読み、さまざまな議論を重ねました。

そのころ参考にしたJava EE勉強会によるDDD本の要約は、今でも参考になるはずです。

DDD - Java EE勉強会

こういった考え方をあちこちで話していたところ、DDDとXP(eXtreme Programming)で株式オンライントレードシステムを開発する、大規模プロジェクトに参画する機会がやってきました。実際のプロジェクトで経験を積めたことは、かなりの自信につながりました。

当時のブログを読み返してみると、やはりトランザクションスクリプトに疲れ切っていました。問題を解く考え方=ドメインモデルに従った、簡潔で分かりやすいオブジェクト指向のソフトウェアを作りたいと考えたようです。

2011年には、満を持してDDD本の和訳が出版されることになり、このレビューにも参加させてもらいました。著者のエリック@ericevans0さんから直接講義を受けることができたことも印象に残っています。

遅延評価的学習法でScalaを習得

新しいことに興味を持ったら「、知りたいこと、実現したいことは何か?」に注目して学習を進めていきました。いわゆる、遅延評価的学習法というものです。

ハッカーと遅延評価勉強法 - LukeSilvia’s diary

「今、自分がやりたいこと」に注目する考え方は、YAGNI(You Aren't Gonna Need It)とも言われます。「機能は実際に必要となるまで追加しないのがよい」というXPの考え方が基礎になっています。

Scalaを習得するときにも、最初は、設定ファイルからデータベース・スキーマを生成するツールを作ることを目標にしました。それに必要となる知識から学んだため、コップ本も1ページ目からではなく、ツール開発に関係する部分をピックアップして読みました。

学んだことが将来的に必要になるのか? 正確には判断できません。その未来が来なかったら、貴重なリソースが無駄になってしまいます。効率的に学ぶには、できるだけそういった無駄を排除した方がよいと考え、今「このツールの実装」に必要なことだけに集中して学んだのです。

このような実践のための学習を繰り返したので、物理的な書籍はボロボロになりましたが、達成感を味わいながら、実力を身に付けることができました。

コップ本
Scalaの開発者であるマーティン・オーダスキー(Martin Odersky)教授らによる著書『Programming in Scala』(2008、Artima Press)の邦訳『Scalaスケーラブルプログラミング』(2009、インプレス)のこと。現在は第3版。

Scalaを使ってDDDを実践するスタイルを確立した

Scalaは難しそうな言語だと思っていたのですが、副作用のない関数を使ったオブジェクト指向プログラミングは、使い始めると予想に反して手になじみました。

これで、複雑な状態に振り回されて神経衰弱になることから、おさらばできる。Scalaを始めた2010年の年末に書いたブログでは、「DDDはScalaを使って実践する」と宣言していました。

ScalaでDDDをはじめてみよう - かとじゅんの技術日誌

実験的に導入して結果が出れば業務での普及も進む

そうこうするうちに、縁があって友人@yamashiroの誘いで転職することになりました。配属後のチームでScalaとDDDを勧めると好評で、実際の開発プロジェクトでも導入しました。

最近は、自治権を与えられたチームの言語選択は比較的自由な印象がありますが、当時はインフラチームの負担を考えて、原則的にJavaかPHPしか認められていませんでした。Scalaは、コンパイルすればJavaアプリケーションであることに変わりはないので、あえて言語がScalaだと宣言しなくてもルールには違反していないと……。

まぁ、問題が起きたら許してもらおうというスタンスでした。まさに「許可を求めるな謝罪せよ」の考え方。実行に移す前に議論するとあれこれとリスクを計算してしまうものですが、実際に実験して結果が明らかになると、社内での普及はかなり有利になりました。

Scalaを採用する新規プロジェクトも増え、開発を助けてくれる人も増えてきました*1。そして、事業の柱となっている大規模サービスのリプレースにも採用されました。

積み上げてきたScalaとDDDの開発スタイル

その後、これまた友人@koichirooの誘いがあって転職し、いろいろあってリアルタイム性の高いチャットサービスの開発チームに配属になりました。

インフラチームで仕事するつもりだったのですが、ちょうどチャットサービスを新規に立ち上げたいということで、リアルタイム処理系に向かないPHP以外の言語でできないかと相談があり、ScalaとFinagleでプロトタイプを3日ぐらいで作ったことがきっかけです。

Finagleは、RPCシステムを作るフレームワークです。Twitter社が開発して自社サービスでも使っており、大規模サービスにも適応できます。

現場ではいつもながら、これまで積み上げてきたScalaとDDDを採用した開発スタイルを布教しつつ、プロダクト開発に励みました。当時の状況は、ScalaMatsuri 2014の資料などから知ることができます。

Scalaコミュニティとともに

私が学び始めた頃に比べると、現在は多くの企業がScalaを採用しています。ScalaMatsuriというイベントも毎年数百人規模で開催されていて、設計やDDDに関連するセッションも多いですし、スポンサー企業の多くで実践事例があります。

コミュニティの成長とともに、私自身もここ数年Scalaだけで仕事をしていて、Scala歴は10年になりました。この10年、プログラミング言語のカテゴリーだけでなく、エンジニアとして多くのことをコミュニティを通して学んだ気がします。そういった刺激を得られる環境があってよかったです。

Scala先駆者インタビュー 最終回 ChatWork かとじゅんさん 〜前編〜
Scala先駆者インタビュー 最終回 ChatWork かとじゅんさん 〜後編〜

新しい挑戦で新しい「点」ができ、そして「線」につながる

チャットサービスをリリースした直後、もっとハードルが高いことに挑戦したくなり、新天地に移りました。現職のChatworkです。「わざわざ大変なところに」とも言われましたが、整地されたところで建築するよりも、問題や課題がある建築物を建て直す仕事をしたかったのです。

入社して取り組むことになったのが、Chatworkの刷新プロジェクトです。このプロジェクトはスコープが大き過ぎたこともあり、1年半ぐらいで頓挫しますが、Akkaのプラクティスが深まり、これがもう1つの「点」になりました。

Akka本来の特徴を生かしたアーキテクチャにしたいとチームの合意も取れ、最終的にはAkkaとKafkaHBaseでCQRS+ESを採用し、機能スコープを絞り込んだ上で、大規模な分散システムをリリースできました。

以後も、ScalaとAkkaを採用したマイクロサービスが増えています。上記以外の機能スコープで刷新プロジェクトも継続しています。ジョブホップしまくっていた私ですが、ここ最近では一番長い期間、働いている会社となりました。

「いずれどこかで点がつながって実を結ぶだろう」

スティーブ・ジョブズ(Steve Jobs)が、2005年のスタンフォード大学卒業式で興味深いスピーチをしています。有名なスピーチなので、知っている方も多いでしょう。

「ハングリーであれ。愚か者であれ」 ジョブズ氏スピーチ全訳

この中に「点と点をつなげる(Connecting the dots)」というフレーズが登場します。以下はその抜粋です。

将来をあらかじめ見据えて、点と点をつなぎあわせることなどできません。できるのは、後からつなぎ合わせることだけです。だから、我々はいまやっていることがいずれ人生のどこかでつながって実を結ぶだろうと信じるしかない。

Again, you can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.

ジョブズは大学に入学しましたが、半年で中退。親に金銭的な負担を強いながら、興味がない必修科目の授業に価値を見出せなくなったためです。しかし、大学を辞めたものの、その後も興味のある授業だけを取るもぐりの学生になりました。

ジョブズが魅了された授業の1つが、伝統的で芸術的な「カリグラフィー*2」でした。そして10年後、最初のMacを設計する際に、それがアイデアとしてよみがえったそうです。

ところが10年後、最初のマッキントッシュを設計していたとき、カリグラフの知識が急によみがえってきたのです。そして、その知識をすべて、マックに注ぎ込みました。美しいフォントを持つ最初のコンピューターの誕生です。もし大学であの講義がなかったら、マックには多様なフォントや字間調整機能も入っていなかったでしょう。

But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts.

このメッセージは示唆に富んでいます。今に集中することの大切さが込められている気がします。

過去も未来も思い切って手放し、今の自分に集中する

人は過去に支配されて身動きが取れなくなったり、未来についていらぬ詮索をすると不安になります。それを避けるには、過去も未来も思い切って手放し、今の自分に集中して「点」を打っていくことが必要なのではないかと思います。

そして転機が訪れたときに、それらの「点」の集まりが「線」や「面」になっていくのかもしれません。

*1:2013年に亡くなった山城さんもその一人でした

*2:アルファベット文字を美しく装飾して書く技法のことで、西洋の書道と言われることもある