見出し画像

TECH TALKから紐解くログラス開発組織のDNA

いとひろ@ログラス

この記事は 株式会社ログラス Productチーム Advent Calendar 2023 の5日目の記事です

https://qiita.com/advent-calendar/2023/loglass

こんにちは。ログラスでVP of Engineeringをしております、いとひろ（ itohiro73 ）です。

今年、ログラスでは技術広報の一環としてLoglass TECH TALKと題したイベントを3回開催してきました。TECH TALKの開催を通じて、改めてログラスの開発組織の強さの源泉となるDNAについての自己認知が進んできたので、アドベントカレンダーのこの時期にせっかくなので言語化してみよう、ということでまとめてみました。

まず前提の共有として、ログラスの創業は2019年5月、プロダクトの経営管理Loglassの正式リリースは2020年7月です。私自身がログラスにジョインしたのは昨年2022年の10月なので、創業から私がジョインするまでには、すでに3年5ヶ月ほどの月日が流れていたことになります。実際、私自身がジョインした時点で今のログラスの開発組織の持つ様々な良い性質は組み込まれていたなと感じており、自分自身もこの「DNA」への興味が大きかったです。

ということで、本記事では今年開催したLoglass TECH TALKを振り返りながら、ログラスの開発組織のDNAを紐解いていきたいと思います。

Loglass TECH TALK #1 - 「DDDもスクラムも当たり前」な開発者組織をどうやって作るか

まず、第一回目の開催となるLoglass TECH TALK #1では、『「DDDもスクラムも当たり前」な開発組織をどうやって作るのか』と題して、ログラスで当たり前のように開発プロセスに組み込まれているDDDやスクラムのプラクティスが、どのようにして組織に組み込まれてきたのかの変遷を探るパネルトークセッションとしてお送りしました。

私自身はモデレーターとして参加させていただき、創業初期からいるCTOと現EMたちをパネリストとして、自分はほとんど知らない創業期からの歴史を引き出すという形で進めてさせてもらいました。

まず非常に興味深かったのが、CTO坂本が創業当初のリリースまでの開発チームづくりに込めていた想いです。

一番最初のファーストコミットからの品質への想いを強くもっており、かといってHowにこだわりすぎない。とにかくお客様に価値を届けるために削りまくって早くリリースを実現する。

そして「誇れるコードを持つ強い開発チーム」の実現に創業時からこだわりぬいており、当時DDDのエキスパートとして活動していた元同僚の松岡（現ログラスEM）を招聘し、CEOでもあり経営管理領域のドメインエキスパートでもある布川を巻き込んで、開発陣が一緒にドメインモデリングをするような取り組みを推進。

プロダクトが正式リリースされる半年以上前からこんなことがまことしやかに行われていたわけです。

https://twitter.com/http204/status/1222161214442094592

創業当時の坂本には、成長真っ只中のプロダクトの機能開発が進まなくなる根本原因はデータ構造にあるという信念があり、ここを適切に設計することに関しても絶対にぶらさないという強い意志が感じられました。

βリリース前には夜中の3時までデバッグをしていたり、正社員はCTO坂本のみで副業が10人くらいいたのをカオスな感じの中タスクの割り振りをしていたり、「スクラムもDDDも当たり前」になるまでの通過点である時代の話として生々しい話も聞き出すことができ、非常に興味深いものでした。

第一回として開催したLoglass TECH TALKでしたが、実に長丁場の1時間40分以上に及ぶパネルディスカッションとなり、今のログラスの開発組織で当たり前に行われている様々なプラクティスが、創業期の1チームから複数チームへと分岐していく歴史の変遷の中でしっかりと地に足をつけながら培われてきた様子がありありと語られました。「DDD」にしろ「スクラム」にしろ、目の前の課題に向き合い続けた結果、必要なHowとしてそれらを実践していた、というものでした。

ご覧いただいた視聴者の皆さんからも以下のようなポジティブなフィードバックをいただき、初めての取り組みとしてはなかなか興味深い勉強会とすることができたのではないかと思っています。

Loglass TECH TALK #2 - 顧客に価値を届けるプロダクト開発の実践

さて、第一回のLoglass TECH TALKでは、創業期からの変遷を辿ることにより、今ではログラスの開発組織で当たり前に実践されている開発プラクティスがどのようにDNAとして醸成されてきたかを探ってきました。

第2回のLoglass TECH TALKでは、各フィーチャーチームがアウトカムの創出に向き合うためにどんなことを実践しているのかを共有するイベントとして開催しました。

書籍「プロダクトマネジメント」で登場する「ビルドトラップ」というワードでは、組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まってしまう状況が表現されています。

今回のLoglass TECH TALKでは、ビルドトラップを避けるための重要観点である「顧客の課題が解決できている」「顧客がプロダクトの価値を感じている」「顧客がプロダクトに熱狂できている」という状態を実際に実現した開発事例について、各フィーチャーチームのエンジニアが発表しました。

実際にログラスの3つのフィチャーチームそれぞれで上記のようなアウトカムを実現した取り組みとして、以下のような事例が発表されました。

  • もともとお客様の声として上がっていたソリューションをそのまま採用するのではなく、本質的な課題発見に注力し、別の価値あるソリューションを提案・実装しリリースした事例

  • 不確実性の高いお客様のペイン解消に対して、アジャイルに仮説検証を回してフィードバックループを高速回転し、実際にアウトカムを出すことができた事例

  • 汎用性の高い機能に関して、社内のドメインエキスパートとともに顧客解像度を上げる施策に注力し、実際にお客様から感謝のメッセージが届いた事例

実際にこれらの事例では、それぞれのチームが生み出した機能リリースに対して非常にポジティブなアウトカムが創出されており、ログラス開発チームの顧客価値に向き合う姿勢が実際にお客様からの反応として現れる結果となりました。

事例1: セールスのメンバーから、単純に要望をそのまま実装するのではなく、本質的な課題解決に向かうプロダクトチームの姿勢への賞賛の声が挙げられた

事例1

事例2 : リリースした機能に対するお客様のポジティブ反応を伝えてくれるCSメンバー

事例2-1
事例2-2

事例3: OKRのObjectiveとしても掲げていた「お客様から感謝の手紙とプレゼントが届く」のうち、感謝の手紙に相当する熱狂的なフィードバックを現実のものとした機能リリース

事例3

この回のLoglass TECH TALKにおいても、聴衆からは非常にポジティブな声をいただきました。

アジャイル・フルーエンシーモデルによる言語化

さて、Loglass TECH TALK第2回では顧客の価値創出に向き合う事例が紹介されたのですが、このような顧客価値と向き合う姿勢はログラスの開発組織のDNAにどのように埋め込まれてきたのでしょうか？

ログラスが歴史的に成長してきた過程を振り返ると、ログラスの初期にDDDの導入に大きく寄与した現エンジニアリングマネージャーの松岡の存在は欠かせません。

ログラスの開発組織のDNAには、松岡が開発の中で実践し続けてきた、書籍「The Art of Agile Development」のエッセンスが多く詰まっています。

アジャイルのアイデアを最大限活用するモデルとしてアジャイル・フルーエンシーモデルというものがあるのですが、このモデルを実践するためのエッセンスが、実は書籍「The Art of Agile Development」の中で紹介されているプラクティス群なのです。

出典: https://www.agilefluency.org/model.php 

改めてこのモデルに則って考えてみると、Loglass TECH TALK #2で話していた「顧客価値を生み出す」というテーマは、アジャイル・フルーエンシーモデルでいうところのフォーカシングの領域を強めてきたからこそ実践できたのではないかという気づきがありました。

アジャイル・フルーエンシーモデルの詳細については松岡による「アジャイル・フルーエンシーモデルでアジャイルに技術的負債対策を組み込む」という記事に解説を譲りますが、フォーカシングを端的に言うと「ビジネスの結果に焦点を当てること、チームとして働くこと、オーナーシップを持つこと」についてのゾーンとなります。

ジャイル・フルーエンシーモデル: 赤い枠と文字は筆者による追記

この「フォーカシング」ゾーンへ創業期から向き合ってきたことによるDNAは、フィーチャーチームが2チーム、3チームへと分割されたとしても脈々と受け継がれてきており、だからこそLoglass TECH TALK #2で話されたような事例は実現できてきたのだと感じます。このような開発組織としての自己認知は、アジャイル・フルーエンシーモデルを通じて改めて言語化できた気がします。

Loglass TECH TALK #3 - 技術的品質と開発生産性 〜二兎を追うための技術〜

アジャイル・フルーエンシーモデルの二つ目のゾーンである「デリバリー」ゾーン。流暢な「デリバリー」を達成するチームは、技術的卓越性によってコードの品質が徐々に低下のような問題を防ぎ、技術的品質と開発生産性を高く維持するとされています。

Loglass TECH TALKの第三弾では、「技術的品質と開発生産性 〜二兎を追うための技術〜」と題し、アジャイル・フルーエンシーモデルで言うところの「デリバリー」のゾーンにログラスの開発組織がいかに注力しているかについて発表しました。

アジャイル・フルーエンシーモデル: 赤い枠と文字は筆者による追記

この「デリバリー」ゾーンには非常に多くのプラクティスが含まれており、今回は特に「コラボレーション」「開発・設計」「開発生産性」の領域にまつわる事例を紹介しました。

アジャイル・フルーエンシーモデルの「デリバリー」ゾーンの解説をする松岡

Loglass TECH TALK#3 - カテゴリ1: コラボレーション

まず、1つ目の事例紹介では「コラボレーション」のカテゴリに関して、どのようにして複雑性の高い機能開発に対してチームとして対応していったかのお話をしました。

「コラボレーション」カテゴリを発表する澤田

実際の取り組みとしては、①デイリースクラムの改善やデイリーレトロスペクティブの開催、②チーム全体で改善意識が生まれるような目標設定を工夫、③ドメインの深掘りとプロダクトの提供価値を明確化、④シフトレフトを通じてテストにおける仕様の洗い出しの早期化、といった内容が共有されました。

「コラボレーション」の取り組みで改善してきた内容

コラボレーションの改善により、手戻りの削減やドメイン理解の向上を通じて、品質の向上にも寄与してきました。

開発生産性や品質の向上は、開発者だけで上げていくものではなく、職種を超えて協力することが大事であることが強調されました。

Loglass TECH TALK#3 - カテゴリ2: 開発と設計

続いて「開発・設計」カテゴリーの発表では、まずはログラスが会社として持っている「LTV first」というバリューの重要性がハイライトされました。

Valueのひとつ、LTV firstについて話す小林

既存のフィーチャー開発と新規事業開発のそれぞれの領域で「開発・設計」力の向上を実現した事例として、①レポート条件保存にjson型マイグレーション機構を導入することによる変更容易性を向上、②代数的データ型を取り入れた設計の導入、③テストのリファクタリング、といった取り組みが紹介されました。

こういった技術的な卓越性への投資にもしっかりと取り組むことで「デリバリー」を強化することができ、アウトカムの創出へ向かうことができているということが強調されました。

技術的な卓越性への投資に取り組みつつアウトカムを創出する

Loglass TECH TALK#3 - カテゴリ3: 開発生産性

最後に「開発生産性」カテゴリーの発表では、ログラスにおける横串チームの取り組みが紹介されました。

横串チームの取り組みを発表する原

「開発を止めない、ビジネスを止めない」を合言葉に横櫛チームとして取り組んできた事例として、①高速な機能開発を支える安全なリリース方法の導入、②開発支援としてのデータ基盤や検証環境の構築、運用支援としてのアラート等監視システムの設置、機能開発としてのアップロード機能のインフラ・ワークフロー実装、③開発メンバーのコンテキストスイッチ削減のための定型作業・問い合わせ一時受け・アラート反応・スロークエリ対応の引き受け、といった取り組みを紹介しました。

横串チームとしてフィーチャーチームが専門としないことを拾い続けることで開発者やビジネスサイドを支援し、プロダクトの価値を高めることをいかにブーストできるかを追求し、開発生産性を上げています。

「開発を止めない、ビジネスを止めない」というアツい想いを共有

TECH TALK #3で見てきたように、ログラスの開発組織では「デリバリー」ゾーンで重要とされる技術的卓越性や開発生産性に関しても決して手を抜きません。CTOの坂本が創業当初から重要視していた「誇れるコードを持つ強い開発チーム」を実現するという想いは、DNAとして脈々と受け継がれてきています。

今回も聴衆の方々から良いフィードバックをいただきました。

ログラスの開発組織のDNAとは

Loglass TECH TALKを#1~#3まで開催してみて、ログラスの開発組織に脈々と受け継がれるDNAとして、以下のような3つの領域へのフォーカスが存在しているなという感覚が改めて蒸留されてきました。

  • お客様やビジネスの本質的な価値の創出に向き合い続ける

  • 技術的な卓越性を探求し、品質や開発生産性の向上にもフォーカスし続ける

  • 常に新たな学びを適応し、当たり前をアップデートし続ける

そして、これらの要素は創業期のエンジニア数名時代から、変わらずそこに在り続けたものでした。このDNAは2チームになっても3チームになっても色あせずにそこに在り続けていますし、今後もそう在り続けるのだろうと感じています。決して後付けでインストールされたものではない、だからこそ強固なものであり、DNAと表現すべきものなのかと思います。

実はログラスでは現在進行形で開発チームのTech Value策定が進行中で、上記のようなDNAのエッセンスがまさに言語化されてきています。

Tech Valueについては別途公表予定ですのでお楽しみにしていてください。

ログラスにはどんな課題が存在し、どんなエンジニアに来て欲しいのか

さて、ここまでLoglass TECH TALKで発表してきた内容に合わせて、ログラスの開発組織に脈々と受け継がれているDNAについて言語化してきました。ログラスの開発組織の魅力の片鱗を、なんとなくでも味わっていただくことはできたでしょうか？

しかし、ここまで読んでいただいた読者の方にはぜひご理解いただきたいのですが、開発組織に魅力的なDNAが存在するからといって、対処すべき課題が存在しないと言うわけではありません。

むしろ、課題は常に山積みです。ログラスは「良い景気を作ろう。」という非常に高いミッションに向かって、常に本質と向き合い続けなければいけません。そのチャレンジは、魅力的なDNAが備わっていたからといって簡単に乗り越えられるような性質のものではありません。

今後解決していきたい課題

  • 新規モジュールや新規プロダクトで価値を生み出していくための探索的な開発

  • 既存のプロダクトの機能群をより磨き上げ、深化させていくための開発

  • 開発生産性の高さを維持し続けていくためのケイパビリティの向上

  • セキュリティや品質を向上し続けるためのライブラリやミドルウェアのアップデート

  • アーキテクチャーを進化させていくための設計・リファクタリング

  • 横断的な課題を俯瞰して取り扱っていくために、それらに戦略的に取り組む仕組みやケイパビリティの確保

  • フィーチャーチーム数が純増していくなかで、いかに疎結合で生産性の高い状態を維持していけるか、システム的にも組織構造的にも戦略的に対応していくためのケイパビリティの確保

  • フィーチャーチームがオーナーシップをもってサービスの信頼性向上に取り組めるようなイネーブリング活動や、オブザーバビリティ向上のための基盤整備

  • 取り扱うデータの種類も量も増えていく中での、大量データに対するより最適なデータ構造や集計方法の設計、高性能計算の実装

上記に記載した内容は課題仮説も含まれており、必ずしも全て一様に取り組むという性質のものではないですが、これらに限らず、さまざまなチャレンジが我々を待ちうけています。

なんといっても、これらのエンジニアリングの取り組みが、お客様の価値向上やログラスという会社自体の事業の成長、ひいては日本の経済活動の成長に対しても寄与していくことが日々実感できるという、とてもエキサイティングな環境です。

We Are Hiring!!

ということで、ログラスはエンジニアを絶賛積極採用中です！本記事で語られているようなDNAを一緒に紡いでいき、良い景気を作っていきたいエンジニアの方、大大大募集です！

もしご興味を持った方はぜひTwitterのDMや下記YOUTRUSTからお気軽にお声がけください！カジュアルにお話しさせていただきます！

また、もし本記事に興味を持っていただけたら、せっかくなので1.5倍速ででもLoglass TECH TALKのアーカイブ動画（#1, #2, #3）もそれぞれご覧いただけると嬉しいです。

それでは本記事は以上となります。

明日のアドベントカレンダーはログラスの一人目QAエンジニア、コタツさんによる記事です。お楽しみに！


この記事が気に入ったらサポートをしてみませんか？