企業でDDD支援や講師を行う専門家が、ログラスにジョインした理由とは
こんにちは、ログラス採用担当です。
ログラスの開発チームでは、保守性を重視し、ドメイン駆動設計（DDD）を導入しています。日本のDDDの第一人者として知られているのが、松岡幸一郎さん。ブログや講演で積極的に情報発信を行っており、ログラスにはβ版リリース前から月1回講師としてお招きしていました。そして2020年9月、松岡さんは正式にログラスにジョインされたのです！
DDDの第一人者である松岡さんがログラスにジョインした理由とは？松岡さんから見たログラスの魅力とは？お話を伺いました。
※このインタビューは2021年10月にWantedlyにて公開された記事の転載です。
DDDを実践し、広めたい
ーーこれまでのキャリアについて教えてください。
ミーハーな学生だった私は、就活では各業界の大手に応募。結果的に内定をもらったのはIT系のみで、日本IBMに入社しました。自分の適性を見てくれたのだと思います。そこではSIerとして受託開発を経験しました。案件にも恵まれ、上流からの開発を経験しました。しかし、協力会社のマネジメント業務や、管理のためのエクセルワークが多くて、開発だけに集中できず。もっとゴリゴリ開発を経験したいと、ビズリーチに転職しました。
実際に自社開発をしてみると、非常に楽しかったですね。お客様の声が聞けるのも嬉しくて、開発にのめり込みました。
ただ、課題も感じるようになりました。「技術的負債」という言葉が使われるように、コードが汚いと、はじめのうちはスピード感をもって開発ができても、どんどん開発にかかる時間が増え、バグも多くなってしまうのです。これはプロダクト開発に関わる現場ではどこででも起きている現象であり、どうにかならないものかと考えるようになりました。
そこで出会ったのが、ドメイン駆動設計（DDD)。技術的負債の問題を解消できそうな手法に惹かれ、社内のプロジェクトで一度本番リリースまで実施。その結果、負債解消だけではなく、良いものを作るのにも有用な手法だと確信をもちました。その後、ブログやTwitterでの発信や、カンファレンスの登壇など、独自に普及活動を始め、今でも継続しています。最近では、企業様からDDDに関する講師や導入のサポートを依頼されることも増えています。
ーーDDDとは、どのような手法なのでしょうか？
簡単に言うと、「エンジニアも現場でどう使われるかを理解して役に立つものを作る」、「コードをきれいに書き、保守性を高く維持する」、この2つの両立を目指すものです。エンジニアが業務に詳しい人と一緒にモデリングし、そのモデルをコードにそのまま反映するのが特徴です。
DDDは10年ほど前に日本語の書籍が発刊されて以来、日本はあまり浸透していませんでした。しかし、徐々に開発環境が整って試しやすくなったり、技術的負債に課題を感じる企業が増えたりしたことで、再度注目を集めています。
※松岡さんが詳しくDDDについて解説しているブログはこちら
DDDによってログラスを成長させることで、自らのキャリアも構築する
――ログラスに転職を考えたきっかけを教えてください。
CTOの坂本とはビズリーチ時代に交流があり、2020年頭にログラスでDDDの講師をしてくれないかと依頼されました。それ以降は月1度のペースで講師を担当するように。時には具体的なコードを見ながらコーチングのようなことも進めていました。そんな中で徐々にログラスに惹かれ、私から志望して2020年9月にジョインしました。
――ログラスのどんなところに惹かれたのでしょうか。
会社として市場のニーズをしっかりと捉えていることです。入社時点では、各種ピッチコンテストでの優勝や、SNSなどでの第三者の反応を見て、このサービスのニーズを確信しました。そして、現在では1年の契約を多くのお客様が更新してくださり、そこに対する解決策が正しいという実績が見えてきました。
自分の今後のキャリアを考える中で、ログラスがお客様をサクセスさせ、ログラスが成長して、その背景としてDDDの存在があったというロジックができれば、お互いにとって最善なのではと思ったのです。私のキャリアとログラスの成長がマッチするのを感じました。
ログラスのカルチャーが、効果的な開発プロセスを実現
――正社員としてジョインされてからはどのような業務を担当していますか？
ジョインしたタイミングは、エンジニアが正社員2人から7人まで急増する時期で、チームとして開発プロセスを整えていかねばならないタイミングでした。その中で、DDDとスクラムの導入を推進しました。DDD導入では、スムーズな導入のために、設計の方針を伝えて、モデリングを一緒に進めています。コーチングの手法も用いながら、エンジニアに気づきを与えることを大事にしています。
ーー実際に働いてみて、ログラスの印象を教えてください。
ダントツで開発プロセスがイケてると思いますね。
DDD、スクラムなど効果的な開発を行うためのプラクティスを、とてもうまく使いこなせていると思います。そういったプラクティスは分かりづらい面があり、手法に振り回されてしまうケースも多くあります。しかしログラスでは、そのようなプラクティスの実践経験を持つエンジニアが複数おり、またチームで振り返り改善をする文化が定着しているため、プラクティスを使いこなしながら日々プロセスを改善し続けられています。
ーー具体的には、どのような開発プロセスなのでしょうか？
大きく3つの特徴があると考えています。
一つ目は、お客様の声を定期的に拾う機会があることです。ログラスには担当エンジニア制度があり、顧客ごとに担当のエンジニアを割り振り、CSとともにミ―ティングに参加しています。ほかにもお客様からのフィードバック会をCSやプロダクトマネージャーが実施し、その録画をエンジニアが集まって鑑賞する機会を設けています。。お客様の声を聞くとモチベーションが上がりますし、自分の作っているプロダクトへの熱量も大きくなると思います。
2つ目は、エンジニアとビジネスサイドが一緒にモデリングし、機能を検討していることです。ほとんどのエンジニアにとっては、経営企画は専門外。「この手法がいい」と提案するだけの前提知識がありません。そこでビジネスサイドメンバーと一緒に、モデリングや画面設計などを通じてあるべき姿を議論しています。これにより、一方的に言われた物を作るのとは大きく違い、両者の知見を活かしたものづくりができています。
3つ目が、後回しにしがちな技術的負債に対する改善に予算をしっかりと割いてることです。私の経験上、どうしても技術的負債の解消は後回しになりがちで「いつかやろう」がなかなか来ず、負債が溜まって開発効率が落ちていってしまうことが多かったです。。そうではなく、負債の解消を「税金のような、嫌でも支払わないといけないもの」とCEOの布川が理解して、ビジネスサイドとの合意のもとに毎週工数を割いている。非常に誇れる部分だなと感じますね。エンジニアにとっては、非常に気持ちよく仕事ができる環境です。
――ログラスのカルチャーについて、どう思いますか？
振り返りの文化が根づいていますね。開発チームで週1回振り返りをするのは、スクラムにおけるプラクティスの一つですが、ログラスでは加えて、月1回全社での振り返りの機会を設けています。はじめはビジネスサイドと一緒に振り返りをすることで成果が出るか半信半疑でしたが、実際にやってみると会社横断で議論する価値がある議題が毎回出て、今では欠かせないものになっています。
開発チームだけだと、開発の効率化やどう計画を達成すべきかといった話に終始してしまいますが、全社の振り返りがあることでエンジニアも全員会社の課題について考えることができます。たとえば、リモートワークにあたってどうやってオンボーディングするのか、ＣＳの業務負担を軽くするためにはどうすべきか、採用における現時点の課題は何か、と言った議題は、エンジニアだけで振り返っていては出てこなかったものでした。そう言った課題について、全員が自分ごととして改善策を実行し続けられている、当事者意識の強いチームだと感じています。
成長意欲の高いエンジニア揃いの環境
ーー5つの大機能をリリースを進めているとお聞きしました。どのようなことを実現するのでしょうか？
それぞれプロジェクトベースで、通常業務と並行しながら、アジャイルで開発を進めています。直近の開発についてはまだ公表できませんが、これまでこんな開発をしてきました。（※2021年10月当時）
①コメント機能（1-2ヶ月）
予算と実績の乖離に対して、その分析結果をコメントとして残せるようにする機能です。これまでエクセルやパワーポイントで行っていた業務を、ログラスの画面上で完結できます。
②分析軸機能（4ヶ月程度）
予実を勘定科目より細かい粒度で分析する機能です。たとえば外注費が膨らんでいた時に、どこでコストがかかっているのかを取引先ごとに細分化します。今後は、項目を増やして多軸化を進めていきます。
③配賦機能（4ヶ月程度）
配賦とは会計上の概念の一つで、部門や製品を横断して発生する費用を、基準に従って配分処理することです。全社ではなく部門としての収益性を判断するために使用します。経営管理において必須の項目であり、エンジニア全員で取り組みました。
④ダッシュボード機能（1ヶ月半）
経営管理に関する複数の情報をまとめて、表やグラフなどで概要を可視化する機能です。
⑤フロントエンドをReactにフルリプレイス（2-3ヶ月）
もともとAngularで開発していましたが、今後フロントエンドの人材の採用を強化にするにあたり必要だと判断し、Reactにフルリプレイスしました。
ーー同時に、これらの開発を進めていくことは非常に大変だと思います。なぜこのような開発スタイルができているのでしょうか。
まずは先ほどお伝えした、振り返り文化の存在は大きいです。定期的に振り返りを行い、開発上の課題は放置せずに改善し続けます。
そして何より、エンジニアの成長意欲の高さです。開発プロセスや技術について、しっかり勉強して取り入れようというメンバーが揃っています。プログラミングは、ある程度勉強すればなんとなくでも作ることができます。しかしそうではなく、長期的な目線でもっとも価値が高くなる判断をする、という意識をエンジニア各位が持ち、そのために必要な学習と実践を常に行っています。
よく建築業界と比較されることが多いのですが、建築物はなんとなく建てると間違いなく壊れるため、免許制度が必要になります。一方でプログラムは、ごく短期で見ると壊れないように見えてしまうため、コードをきれいに書くためのスキルや生産性の高い開発スキルが軽視されていました。しかし本当は、長く生産性高く開発をするためには、そう言った開発スキルが必要不可欠なのです。
ログラスでは技術的負債を極力つくらずに価値を生み出し続けられるように、DDDやスクラムなど、アジャイル開発のプラクティスを愚直に実践しています。簡単なことのように見えますが、学習、実践、振り返りと改善がうまく絡み合い、良いサイクルを回し続けられていると思います。
――最後にログラスに興味を持っていただいた方へのメッセージをお願いします。
私がDDDに惹かれた理由、ログラスに惹かれた理由は共通しています。それは、ぐちゃぐちゃになっているものをきれいにすること。汚かったシステムがきれいになる。アナログなエクセルが中心だった経営管理が楽になる。このことに、大きな喜びを感じています。ログラスの事業にも、チーム作りにも大きなやりがいを感じています。
私個人の目標は、DDDなどのアジャイルプラクティスを実践し、ベストプラクティスをを広げることで、日本のエンジニアがより楽しく、成果の出せる開発ができるように貢献することです。そしてログラスでは、経営管理のオペレーションを効率化するだけでなく、その先にある企業経営、さらには日本のGDPにまでインパクトを与えるような、大きな仕事をしたいと思っています。
ぜひ一緒に、ログラスで開発をしませんか？お話しできるのを楽しみにしています。
【ログラスをもっと知りたい方へ】
ログラス 会社紹介資料
ログラス 採用 Job Board