「本質的複雑性」「偶有的複雑性」に向き合うためのログラス記事まとめ

この記事では、「本質的複雑性」と「偶有的複雑性」に向き合うことをテーマにした記事をまとめてお届けします。

「本質的複雑性」に向き合うための記事まとめ

経営の本質的課題に向き合い続けるログラスのプロダクト開発

prd-blog.loglass.co.jp

「本質的な価値を生み出す」ための取り組みシリーズ

note.com

cocoda.design

note.com

zenn.dev

スクラムの三本柱(透明性・検査・適応)」を高めるための取り組みシリーズ

zenn.dev

zenn.dev

zenn.dev

スクラムの成果を最大化」するための取り組みシリーズ

zenn.dev

zenn.dev

zenn.dev

「偶有的複雑性」に向き合うための記事まとめ

偶有的複雑性と向き合うためのログラスのEnabling & Platform戦略

prd-blog.loglass.co.jpprd-blog.loglass.co.jp

偶有的複雑性と向き合うための「基盤を更新し続ける」シリーズ

zenn.devzenn.devzenn.dev
zenn.dev

偶有的複雑性と向き合うための「型の堅牢性」にまつわるシリーズ

zenn.devzenn.devzenn.dev
zenn.dev

「ツリー構造と集計」にまつわる偶有的複雑性シリーズ

zenn.devzenn.dev

偶有的複雑性に向き合うための「テスト」シリーズ

zenn.devzenn.devzenn.devzenn.dev

さいごに

今後もログラスでは「本質的複雑性」「偶有的複雑性」に向き合うことをテーマにした記事を発信予定です。
ぜひテックブログ、はてなブログのフォローをお願いします!

zenn.dev

prd-blog.loglass.co.jp

 

 

ログラス初の技術同人誌「Loglass Tech Blog Sprint Review 2024」制作の裏側を公開します!

はじめに

こんにちは!「Loglass Tech Blog Sprint Review 2024」編集長の粟田(@wooootack)です!

今日は、先日無事に完成した、Loglass初の技術同人誌「Loglass Tech Blog Sprint Review 2024」の制作の裏側を公開します!

「なんか凄そうに言ってるけど、薄い本なんでしょ〜?」と思った方もいるかもしれませんが、こちらなんと200ページ近くのボリュームがあります!

この記事では、「どんな風にしてこの技術同人誌を完成させたのか」「エンジニアならではの制作時の工夫」「シンプルに苦労した話」など、包み隠さず書いていこうと思います。

ぜひ最後までお楽しみください!

なぜ同人誌を作ることになったのか

はじめに、なぜ「Loglass Tech Blog Sprint Review 2024」を制作することになったのか、その経緯をお話しします。

弊社はさまざまなカンファレンスやイベントのスポンサーをしており、ブースを出展させていただくことが多くありました。

これまでも、そこでステッカーやポストカードなどのノベルティを配布していたのですが、よりエンジニアに刺さるような何か新しいノベルティを作ることができないかと企画していました。

そこで社内で有志のエンジニアを募って作戦会議をした結果、「遊び心がある」「オリジナリティがある」「ログラスらしさが伝わる」といった理由から、技術同人誌を作ることになりました。

そしてなんと、制作が決まった時点で入稿まであと1ヶ月程度しかない!という状態で短納期ではありましたが、無事にKotlin Fest 2024開発生産性カンファレンス2024Platform Engineering Kaigi 2024といった、3つのカンファレンスで配布することができました!

Loglass Tech Blog Sprint Review 2024のコンセプト

「Loglass Tech Blog Sprint Review 2024」は、これまでに「Loglass Tech Blog Sprint」という取り組みで投稿された記事の中から、厳選された20記事を収録した技術同人誌です。

zenn.dev

今回はピックという形なので掲載される記事とされない記事がありますが、そこに優劣はないということだけは最初に改めてお伝えしておきます!

「Loglass Tech Blog Sprint」で投稿された記事は、さまざまなジャンルのものがあって、どれも素晴らしい記事ばかりです。

また、この「Loglass Tech Blog Sprint」という取り組み自体をもっと多くの人に知ってもらいたいという思いも込められています。

そしてピックした記事を「設計」「技術的投資」「品質」「アジャイル開発」「チームビルディング」と5つのカテゴリに分類して掲載することにしました。

このカテゴリに自分たちがこれまで大事にしてきたことやログラスらしさの一部分が表れたのかなと感じています。

また、このカテゴリにない項目にも大事にしてきたことやログラスらしさは隠れていて、それについても今後は積極的に発信していきたいなと思いました。(具体的にどういうところなのかは後述します)

記事の最後に掲載されている記事のリンクをまとめておきますので、興味のある記事があればぜひご覧ください!

技術同人誌のおおまかな流れ

おおまかなタスク一覧をまとめてみました。

  • コンセプトの決定
  • 掲載記事の選定
  • リポジトリや執筆環境の整備
  • タイトルの決定
  • 製本会社の選定
  • 記事の加筆修正
  • 本の構成作成
  • 表紙作成
  • 免責事項の執筆
  • まえがきの執筆
  • あとがきの執筆
  • 目次作成
  • ブログ記事から物理本にするために微調整
  • 法務、広報チェック
  • 製本会社に見積もり依頼
  • 製本会社に支払い
  • 製本会社に入稿
  • 納品後のチェック

改めて羅列すると、大量のタスクをこなしたんだなとしみじみ感じますね。

今回は、特にこだわった作業と苦労した作業をピックアップして詳しく書いていこうと思います!

リポジトリや執筆環境の整備

まずはどんな風に進めていくかを考えたのですが、今回はzennに書いてある記事をベースに本を作ることや、エンジニアが主導で進めることを考えて、以下のような構成にしました。

主に使用した拡張機能は以下の3つです。

最初のMarkdown PDFがあればMarkdownをPDFに変換できますが、自分はMarkdownのプレビューや目次の自動作成・HTMLのプレビューなども欲しいなと思って、他の2つも同時に使っていました。

また、extensions.jsonにこれらの拡張機能を記述して、他の人が環境を整えやすいようにしていました。(こういう細かい気遣い、大事ですよね)

{
  "recommendations": [
    "yzane.markdown-pdf",
    "yzhang.markdown-all-in-one",
    "koppt.vscode-view-in-browser"
  ]
}

Markdown PDFの使い方については良い記事がたくさんあり、自分も参考にさせてもらったので特に良かったものをいくつか紹介しておきます。 qiita.com qiita.com mseeeen.msen.jp

ブログ記事から物理本にするために微調整

次に実際に物理本に仕上げていくために行った作業を紹介します。

ここの作業が思ったよりも大変だったので、ぜひ参考にしてもらえると嬉しいです。

ざっとやったことをまとめると以下の通りです。

  • 見出しレベルの統一
  • 目次の作成
  • 改ページの調整
  • リンクの見せ方変更
  • zenn特有の記法の修正
  • フォントや色の調整

ここでも特に苦労した作業をピックアップして詳しく書いていこうと思います。

そしてぜひいろんな苦労があったんだなと感じながら、改めて技術同人誌を読んでもらえるとうれしいです。

リンクの見せ方変更

これは物理本ならではの苦労かもしれません。

これまではWebサイトで記事を公開していたので、リンクは何も気にしなくてもある程度いい感じに表示されていましたが、物理本だとそうはいきません。

特にテキストをリンクにしてある場合は、そのまま物理本にしてしまうとリンクが失われてしまいますし、色も黒になってしまうのでただの文字列のように見えてしまいます。

他の商業誌や同人誌を参考にしつつ以下のような方法を考えました。

  • 各ページのフッターにリンク先を載せる
  • 巻末にリンク一覧を載せる
  • Notionでリンク一覧ページを作成して、そこにアクセスするためのQRコードを載せる

ただ、今回はやり切る時間が取れず、テキストの後ろに括弧書きでURLを記載することにしました。

具体的にはこのような形になっています。 実際のPDFのスクリーンショット

ここは今回やりきれなかったという後悔が残ってしまっている部分なので、次はもっと読みやすくリンクにアクセスしやすい方法でやりたいなと思っています。

zenn特有の記法の修正

※「Loglass Tech Blog Sprint」の記事はほとんどがzennで書かれたものだったので、この特殊な作業が発生しました。

これも当たり前なんですが、Markdown PDFでPDFに変換する際に、zennの独自記法はうまく変換されません。

例えば、以下のような記法がそのままだと変換されないことがありました。

zenn特有の記法は公式から記事が出ているので、そちらを参考にしつつHTMLを直接書くように修正したり、別の対応している記法に変換したりしていました。

zenn.dev

今回はそこまで数が多くなかったのでなんとかなりましたが、数が増えてくると大変そうだなと感じると同時に、zennの表現力は凄いなと感心しました。

フォントや色の調整

これも当初あまり深く考えていなかったのですが、実際に物理本にすることを考えると、細かくフォントを考える必要がありました。

例えば以下の部分は全て異なるフォントを使っており、この辺りにもしっかりこだわって作りました。

  • 見出し
  • 本文
  • ヘッダー、フッター
  • 目次

フォントや色に関しては、ほとんどがうまくいったなと感じているのですが、1箇所だけ失敗した部分があるので懺悔させてください。

それが以下のようなコードブロックの部分です。 PDFのスクリーンショット

PDFをPC上で見る分には、そこまで違和感がないかもしれませんが、実際に物理本にすると思ったよりも見にくくなってしまいました。

このあたりは、デザイナーにレビューしてもらう時間を取れずにPDFで見て大丈夫そうだなと進めてしまったので、これは次回に活かしたい反省点です。

製本会社に見積もり依頼

よーし、いい感じのPDFができてきたぞ〜!ということで製本会社に見積もりを出そうとしていると、どうやら見積もりに当たって紙質や製本方法を選定する必要があるということに気づきました。

後から思い返せば当たり前なんですが、完全に忘れており完全に後手に回ってしまいました。

今回は日光企画さんに製本を依頼したのですが、注文フォームで入力するべき紙質や製本方法が分からず途方に暮れていました。

そんな時に、弊社のデザイナーが救いの手を差し伸べてくれました。

おかげで値段は抑えつつも安っぽくならず、しっかりとした本に仕上げることができました。

平綴じ・中綴じ・無線綴じの違いなどの本に関する知識を得ることができるという副産物もあったので結果オーライかなと思っていますが、今後同人誌を作る予定があるエンジニアの方はこの辺りだけでも先に調べておくことをおすすめします!

感想

ここまでは経緯や進め方などを書いてきましたが、編集長としての個人的な感想もつらつらと書いていこうと思います。

まず、無事に完成させることができたこと、そしてカンファレンスで多くの方が手に取ってくれたことが何よりも嬉しかったです。

改めて、制作に関わってくれたメンバー全員に感謝を申し上げたいです。

製作開始から入稿までの期間も短く、割と短納期な依頼をすることもあったのですが、嫌な顔一つせずに協力してくれ本当に感謝しています。

せっかくなので、良かったところも簡単に思い返してみます。

今回、特に良かったなと思っているのは、GitHubで管理することでエンジニアなら誰でも参加しやすい次に繋がる作りにできたことです。

「Loglass Tech Blog Sprint Review 2024」というタイトルに2024が入っているということは……つまりそういうことかもしれません。

また、今回の技術同人誌はページ数の都合でいくつかの記事を泣く泣く掲載を見送る必要がありました。

その際に複数人で「ログラスっぽさが他よりも低い」という基準で相談して判断したのですが、そこで自分たちが思っていた「ログラスっぽさ」というものをアップデートしていく必要があることに気づく機会にもなりました。 VPoEからのフィードバックコメント

ポジティブな表現でありながらもとても大切なメッセージが込められていて、とても素敵な発信だなと思いました。

一方で、デザインや支払い周りの相談が遅れて後手に回ってしまったり、読者の感想を回収する仕組みを仕込ませるのを忘れたりと反省点も多くありました。

同人誌を作るぞ!という話が出てから、約半月程度はエンジニア2名だけで進めていたのですが、デザイナーやHRなど他部署のメンバーともっと早く連携を取っておけばよかったなというところは特に反省と感じています。

今回は初めての同人誌制作でいろいろとバタついてしまいましたが、次は今回の経験や資産を活用してより素早く高品質なものが作れるといいなと思っています。

おわりに

こうやって振り返ってみると、改めて作ってよかったなと感じました。

普通にエンジニアをやっているだけでは得られない経験もできましたし、何より達成感が半端じゃないです。

また、実際にカンファレンスでブースに立って直接お渡しできたり、ポジティブな反応を多く頂くことができたので、非常に嬉しかったです。

長くなりましたが、今回の記事はこのあたりで終わりにしようと思います!

技術書展とかに本を出してみたいなと思っている方など、もっと詳しく聞きたいことがあれば気軽にコメントやDMをお待ちしています!

それでは皆さま、次回作にもご期待ください!

掲載記事へのリンク集

設計

zenn.dev zenn.dev zenn.dev zenn.dev zenn.dev

技術的投資

zenn.dev zenn.dev zenn.dev zenn.dev

品質

zenn.dev zenn.dev zenn.dev zenn.dev

アジャイル開発

zenn.dev zenn.dev zenn.dev

チームビルディング

zenn.dev zenn.dev zenn.dev zenn.dev

【カンファレンスレポート】Platform Engineering Kaigi 2024にスポンサーとして参加しました!

こんにちは。ログラスでProductHRをしている永井です。

この記事は2024年7月9日に開催された『Platform Engineering Kaigi 2024』のレポートです。

ログラスは今回Silverスポンサーとして協賛させていただきました。
カンファレンスの概要や、スポンサーシップの背景については、以下の記事をご参照ください。

prd-blog.loglass.co.jp

Platform Engineering Kaigi自体今年が初めての開催だったため、手探りではありつつも、エンジニアとProductHRの協業で準備を進めてきました。

ブースの様子

ブース企画

ブースではログラスのEnabling & Platformに関するトークテーマを用意し、エンジニアメンバーが直接お話ししました。

ブースで特に関心度の高かった「心穏やかにDBバージョンアップした方法とは?」は以下の記事に詳細が書かれているので、気になった方はぜひご覧ください。

zenn.dev

また、直近ログラスのEnabling & Platformについて公開した記事のQRコードを載せたカードもお配りしました。
「読んだことあります!」と言ってくださった方もいました!

prd-blog.loglass.co.jp

prd-blog.loglass.co.jp

ノベルティ

今回ノベルティは『開発生産性conference』でも大好評だった、技術同人誌とキーキャップの2つをご用意しました。

技術同人誌は、毎週「必ず」技術記事が出る"Loglass Tech Blog Sprint"から抜粋したものというのもあり、ブースでは「うちの会社でもテックブログ続けたいけど、なかなかできてないんですよねぇ」というお悩みを聞いたり、「どうやって毎週出してるんですか?」などの質問もお受けし、ログラスでの取り組みの工夫などもお話しさせていただきました。

実際に読んだ感想をSNSでも投稿していただき、制作に関わったメンバー一同うれしかったです!

制作の裏側を書いた記事もぜひご覧ください!

prd-blog.loglass.co.jp

ログラスのロゴを立体プリントしたキーキャップも好評でした。

まとめ

今回が初開催のPlatform Engineering Kaigiでしたが、どのセッションも立ち見が出るほどの盛況で、Platform Engineeringへの関心度の高まりを感じました。

セッションの様子

ログラスのブースにもたくさんの方にお越しいただき、直接お話しすることができた機会となりました。
(技術同人誌は用意した分を途中で全てお渡ししてしまったため、今回GETできなかった方は別の機会に!)

運営スタッフ、スピーカー、参加者の皆さん、ありがとうございました!

さいごに

ログラスでは共にEnabling & Platform領域の課題に挑む仲間を募集中です!
まずはカジュアルにお話しできればと思いますので、ぜひお気軽にご連絡ください!

job.loglass.jp

hrmos.co

hrmos.co

 

【カンファレンスレポート】Kotlin Fest 2024にスポンサーとして参加しました

はじめに

株式会社ログラスでWebアプリケーションエンジニアをしている中村です。

この記事は、2024年6月22日に行われたKotlin Fest 2024のカンファレンスレポートです。

カンファレンスの趣旨と概要

Kotlin Festは「Kotlinを愛でる」をビジョンに開催されており、Kotlinに関する知見共有や交流が行われる、Kotlinファンの方が集う国内最大のKotlinカンファレンスです。

今年のKotlin Festは5年ぶりとなるオフラインでの開催で、ベルサール渋谷ファーストが会場でした。

www.kotlinfest.dev

ログラスはひよこスポンサーとして協賛し、ブースを出展しました。

スポンサーシップの背景

ログラスでは創業当初からサーバーサイドKotlin × ドメイン駆動設計を実践しています。最近では関数型の考え方を取り入れることで、高品質で長期にわたって価値を生み出すプロダクト開発に取り組んでいます。

ログラスはKotlinのほか、Spring Bootをはじめとした様々なOSSオープンソースソフトウェア)に支えられています。OSSが発展するためには技術コミュニティの発展が重要だと考えており、技術コミュニティへの還元を推進していきたいという思いから、Kotlin Fest 2024のスポンサーシップを実施しました。Kotlinコミュニティの発展のため、私たちの技術的な取り組みを多くの方に知ってもらうことを目指しています。

当日の様子

ボツポーザル

ログラスのブースでは「ボツポーザル」という展示を行いました。採用されなかったプロポーザルを紹介する企画であり、「ボツ(採用されなかった)+プロポーザル」と命名しました。 ここで紹介しているプロポーザルは記事としてまとめており、来場者はQRコードをスキャンすることで詳細にアクセスできるようにしました。また、気になるプロポーザルについては、その場でログラスのエンジニアが直接解説を行い、技術的な背景やアイデアの詳細について意見交換を行いました。

ボツポーザルのパネル

zenn.dev

zenn.dev

zenn.dev

「Spring Bootアップデート戦記 〜Spring Bootのライブラリ選定を振り返る〜」の記事については社内事情等の生々しい話が多く登場しており、公開せずにその場でエンジニアが紹介するのみとしています。

ボツポーザルの記事を読んでいただいている様子

ボツポーザルのパネルで写真撮影

SNSでの反応

Kotlin脳内ランタイムクイズ

Kotlinに関するマニアックな知識を試す「Kotlin脳内ランタイムクイズ」も実施しました。全部で5問用意しており、全ての問題に正解された方にはAnkerの充電器や技術書等の景品をプレゼントしました。

Kotlin脳内ランタイムクイズの景品

ログラスでも全問正解した社員が出ていないくらい高難易度かつボリュームのある問題です。問題はZennに公開していますので、ぜひ挑戦してみてください。

SNSでの反応

ノベルティ

コースター

ブースの写真撮影&シェアをしていただいた方に、ログラスのロゴがプリントされたコースターをプレゼントしました。

ログラスのコースター

まとめ

Kotlin Fest 2024は5年ぶりのオフライン開催でしたが、会場がパンパンになるほどに大盛況でした。

Kotlinの最先端を知れる魅力的なセッションの数々、また、ブースや懇親会を通じて多くの方とKotlinにまつわるお話を語り合うことができ、Kotlinコミュニティの進化と愛を実感できる非常に有意義なイベントでした。

今回の参加はログラスにとっても価値ある体験でした。今後も技術コミュニティへの還元を推進していきます。

最後になりましたが、現地で登壇してくださった方々、運営の方々、参加された皆様、ありがとうございました。

さいごに

現在ログラスでは全ポジション積極採用中です。
まずはカジュアルにお話しできればと思いますので、お気軽にご連絡いただけると幸いです。

job.loglass.jp

非機能要件との戦い:ログラスが挑むEnabling & Platform戦略の実践と理想

ログラスでアプリケーション基盤領域のエンジニアをしている龍島(@hryushm)です。以前弊社いとひろ(@itohiro73)より、偶有的複雑性と向き合うEnabling & Platform戦略についての投稿をしました。

自分自身Enabling & Platformを担う部署に所属しており、この戦略に最前線で向き合い、実行しています。今回はこの戦略に基づいて、主に偶有的複雑性の一部である非機能要件への対応に実際どのようなアクションを取っているのかを書いてみたいと思います。

プロダクトの成長と非機能要件対応の必要性

まず前提として、対象としている非機能要件が持つ性質について整理します。

プロダクト開発における、市場への受け入れられ度合いと機能要件の不確実性、非機能要件対応の必要性について一般的な関係をプロットしてみると、下図のようになります。

機能要件の不確実性

緑の線となってる機能要件の不確実性は、プロダクトが市場に受け入れられるにつれて減少していきます。プロダクトの初期段階では機能要件の不確実性が高く、満たすべき仕様は定まりきっていません。しかし、ユーザインタビューや機能実装、機能をミニマムでリリースすることで得られるユーザーフィードバックや、市場分析を通じてこの不確実性は減少していきます。

非機能要件対応の必要性

図の赤い線で示した非機能要件への対応の必要性は、プロダクトが市場に受け入れられるにつれて増加していきます。それには具体的に以下の要因が関わってきます:

  • ユーザー数の増加に伴うシステムの負荷増大
  • データ量の増加によるパフォーマンスへの影響
  • セキュリティリスクの増大
  • 機能の複雑化に伴う保守性・拡張性の課題
  • ユーザー体験の向上に対する要求の高まり

これらの要因により、スケーラビリティ、パフォーマンス、セキュリティ、保守性といった非機能要件への対応が徐々に重要性を増します。プロダクトが成長するにつれ、これらの要件を満たすことが持続可能な成長と競争力維持に必要となってきます。

機能レベルでの成長と非機能要件対応の必要性の関係

この図の関係性はプロダクト全体に限らず、個々の機能でも短いサイクルで同じような推移をたどり、いわゆるフラクタル構造となっています。機能のディスカバリーの段階では機能要件の不確実性が高く、機能をリリースして改善を重ね、多くのユーザに利用されるようになると非機能要件対応の必要性が高くなるのです。

今ログラスが取り組んでいる課題とアプローチ

以上を踏まえてログラスが現在向き合っている課題と、それに対してどのようなアプローチを取っているのかを見ていきます。

ログラスにおいてこの1年ほど、拡大期にあったある機能について、大きな非機能要件(主にパフォーマンス)の問題が顕在化する事態が発生していました。それに対応するPJを立ち上げ、メンバーのリソースを当て、現在においてもなんとか抑え込んでいるという状態です。言わば火を吹いたところに急いで消火に向かう状況で、顧客影響や機能開発の遅延にも繋がってしまっていました。

拡大、成熟期での非機能要件の対処

この経験から、現在は非機能要件に対して専門に対応するアプリケーション基盤チームを組成し、各機能についてより早い段階での対応を進めています。

拡大期に入るタイミングで対応する

個々の機能について拡大期に差し掛かったところで、アプリケーション基盤チームによるフィーチャーチームに対するヒアリングを行っています。内容としては下記のようなポイントです。

  • データ量増加で非機能要件(特にパフォーマンス)に影響する可能性があるか
  • 今後機能をスケールするにあたって変更容易性の低い箇所が無いか

これらを事前に見積もっておくことで課題を認知し、対応のロードマップを立てています。認知した課題全てにすぐ取り組むことはできないですが、課題に対する解像度を上げ、マネジメントすることで問題が大きくなることを事前に防げると考えています。

ヒアリングがこのタイミングである理由は、機能要件の不確実性が十分に下がっている段階であるからです。機能要件の不確実性が高い段階でヒアリングや課題認知をしても、実際に拡大、成熟期に入る段階では前提が大きく変わっている可能性が高いため、現状の限られたリソースで取り組むベストなタイミングだと考えています。

しかし、現状を理想と考えているわけではありません。機能がある程度作られた状態で重大な課題が見つかった場合、それに対応することはなおハイコストであり、拡大、成熟期へと進む大きなハードルとなりえてしまうからです。

理想と考えている形

非機能要件に対しては機能実装初期から機能要件と共に検討し、成長と共に対応し続けていくことが理想です。機能のディスカバリー段階からパフォーマンスを主とする非機能要件も考慮に入れ、マネジメントできる状態でPMF、拡大、成熟期へとなだらかに推移していくイメージです。

機能開発初期から非機能要件へ対応する

ログラスではそれが十分に実現できていないという現状があります。各フィーチャーチームのエンジニアは本質的な顧客課題解決に軸足をおいており、もちろん非機能要件について考慮してはいきますが、より高いレベルでの対応が求められています。その差分を埋めるために、ログラスでは下記のような組織が理想ではないかと考えています。

理想組織イメージ(通称飴玉図)

 

イネーブリング&プラットフォーム組織を置き、プラットフォーム領域として偶有的複雑性に対処する基盤の整備を行います。さらにイネーブリング領域として各フィーチャーチームに必要に応じて入り込み、一体となって偶有的複雑性を解消、チームが最大出力を出せるよう働きかけます。

具体的に非機能要件(パフォーマンス)への対応を例とすると、まずプラットフォーム領域としてSLI、SLOといった指標の整備、それをモニタリングする基盤の構築などを担います。さらにイネーブリングとして各フィーチャーチームに入り込み、その基盤を利用して実際に指標を満たしていけるようフィーチャーチームと一体化して動き、スキル獲得の支援をします。

これによってフィーチャーチームが機能開発初期から機能要件と非機能要件に両輪で向き合うことができ、非機能要件への対応の必要性を低く保ったまま機能をスケールさせられると考えています。

まとめ

現在のログラスでは非機能要件への対応が後手に回ってしまっており、スケールの障害となってしまっています。まずは機能の拡大期に入る前に課題の解像度を上げ、課題をマネジメントできるようにしていくアプローチを取っています。しかし理想とする形はイネーブリング&プラットフォーム組織がプラットフォームを整備した上で各フィーチャーチームに有機的に入り込み、機能開発初期から非機能要件対応を含む偶有的複雑性を小さく抑える形です。

これまでログラスは様々な課題を乗り越えプロダクトを成長させてきましたが、現在の一番の課題は間違いなくこのイネーブリング&プラットフォーム領域です。個人的にはその大きな課題に向き合える楽しさを感じつつ、実際はメンバーが足りずやりたいことのほんの少ししかできていない現状にもどかしさを感じています。この記事を読んで面白そうと興味を持ってくださった方、ぜひお話ししましょう。

 

hrmos.co

hrmos.co

hrmos.co

hrmos.co

hrmos.co

hrmos.co

Platform Engineering Kaigi 2024 にスポンサーとしてブース出展します

Platform Engineering Kaigiとは

Platform Engineering Kaigiは、現在注目を浴びているPlatform Engineeringをテーマにしたテクノロジーカンファレンスです。

本イベントは、Platform Engineeringの世界に深く潜り込むための絶好の機会です。最新のトレンド、実践的な知見、そしてこの分野のトップランナーたちとの交流を通じて、テクノロジーの未来を切り拓いていきましょう。(公式説明

今回ログラスはSilverスポンサーとして協賛しています。

スポンサーシップの背景

ログラスでは創業当初より、ユーザーの本質的価値に向き合うために「チームの責務」や「互いの関わり方」もプロダクト開発の重要な一面であることを認識し、最適な形を模索しながら開発をしてきました。

現在はビジネスの成長から生まれる複雑性に対して組織として立ち向かっていかなければならないフェーズへと差し掛かっており、さまざまなコミュニティから学びを得ています。

日頃の事業活動から得たものを私達も発信してコミュニティに還元すべきと考え、今回Platform Engineering Kaigi2024に協賛することを決めました。

これは、ログラスのTech Valueである「Update Normal」の基盤となる活動原則とも一致しています。

  • 顧客への本質的な価値提供
  • 学びと適応
  • 技術的卓越性の追及と還元

 

ログラスのEnbaling & Platformの取り組み

ログラスでは、プロダクト開発チームがお客様の本質的価値に向き合うためにも、「偶有的複雑性」にも本気で向かう必要があると考えています。
そのためにも、Enabling & Platformの領域に軸足を置く人員を拡充するような組織戦略を取ろうとしています。

詳細は以下のブログをご参照ください。

prd-blog.loglass.co.jp

ブース企画の紹介

今回ログラスからはVPoE、エンジニア、SREがブースに参加予定です。
ログラスのEnabling & Platformの取り組みについて、ブースで直接お伝えさせていただくためのトークボードを用意しました。

気になるテーマがありましたら、ぜひ当日ブースでお話ししましょう!

ノベルティの紹介

6月に開催された「開発生産Conference2024」でも大好評だった2つのノベルティをご用意しています!
いずれも数量限定なので、ぜひ早めにブースに立ち寄ってGETしてください!

1. 技術同人誌

毎週必ず記事がでるテックブログ " Loglass Tech Blog Sprint"から厳選した記事をまとめた『Loglass Tech Blog Sprint Review 2024』

各記事をカテゴリ別に分けて編集しています。
200ページに及ぶ超大作で、読み応え満点の仕上がりになっています。

2.キーキャップ

ログラスのロゴが入ったキーキャップ。
自作キーボードをお使いの方はもちろん、オブジェとしてもかわいい仕上がりになっています。

当日ログラスブースでお待ちしています!
ぜひお立ち寄りください!www.cnia.io

【カンファレンスレポート】開発生産性Conference2024にスポンサーとして参加しました!

こんにちは。ログラスでProductHRをしている永井です。

この記事は2024年6月29日から30日に開催された『開発生産性Conference2024』のレポートです。

カンファレンスの概要やスポンサーシップの背景については、以下の記事をご参照ください。

prd-blog.loglass.co.jp

ログラスが開発生産性Conferenceのスポンサーをするのは去年に続き2回目です。
今年はカンファレンス2ヶ月前にキックオフを実施し、ブース企画班とノベルティ制作班に分かれ、エンジニアとProductHRの協業で準備を進めました。

当日のブースの様子

開発生産に関するアンケートを実施

ブース企画として『顧客価値に向き合うためにアップデートしたい開発生産性のテーマは?』というお題で参加者の皆さんにアンケートを実施しました。
アンケートのタイトルには、ログラスのTech Valueである「Update Normal」をかけています。

ログラスTech Value

「書きたい内容がたくさんあって悩む......」とおっしゃった方も多くいましたが、皆さん思い思いの関心のあるテーマを書いてくださいました。

最終的なカテゴリ別の集計は

となりました。
特に開発組織と技術的負債が関心度の高いテーマだったようです。

計194名の方に付箋を貼っていただき、ブースを通る方に「写真撮ってもいいですか?」と言っていただけるほど濃い内容のボードとなりました。
アンケートに回答してくださった皆さん、ありがとうございました!

SNS上でもたくさんの方にボード写真をあげていただきました。

ノベルティ

今回ノベルティとして、技術同人誌とキーキャップの2つをご用意しました。

特に、毎週必ず記事がでるテックブログ『Loglass Tech Blog Sprint』から厳選した記事をまとめた技術同人誌『Loglass Tech Blog Sprint Review 2024』は大好評で、技術同人誌をGetするためにブースに足を運んでくだっさった方もいらっしゃいました。

ログラス初の技術同人誌制作の裏側は編集長がブログで公開予定なので、お楽しみに!

昨年の開発生産性conferenceでEMが誤発注した大量のキーキャップを配ったことを元ネタに、Updateして制作したキーキャップもかわいいと大好評でした!

VPoE伊藤の登壇

2日目にはVPoEの伊藤@itohiro73)の登壇がありました。

ログラスの開発組織の「これまで」と「これから」についてや、Org TopologiesやFASTなど、日本ではまだあまり知られていない概念も紹介しました。
資料も公開しておりますので、ぜひご覧ください。

speakerdeck.com

SNS上でも資料を読んでいただいた方から多くのリアクションがありました。

まとめ

今年はカンファレンス規模や参加者数も去年よりはるかに大きくなり、開発生産性に対する関心の高まりを感じました。

ログラスのブースにも多くの方にお越しいただき、アンケート企画やノベルティを楽しんでいただけた様子で、準備をしてきた運営メンバーとしてうれしく思います。

ログラスでも引き続き開発生産性に関する取り組みを継続し、コミュニティへの還元もしていきたいと思います。

さいごに

ログラスでは開発生産性を高めてくれる仲間を募集中です!
ぜひお気軽にご連絡ください!

job.loglass.jp