見出し画像

ログラス入社エントリ:組織文化と開発プロセスの魅力

2024年2月にWebアプリエンジニアとしてログラスに入社した子田です。
入社してからしばらく経ってしまいましたが、入社した感想や社内の仕組みなどをお話しできればと思います。参考になれば幸いです。


入社のきっかけ

転職ドラフトでスカウトが来たのがログラスとの初めての接点です。
当時は会社名とサービスの概要だけぼんやり知っていた程度の理解度でしたが、
少し気になっていたのでひとまずカジュアル面談を受けてみました。
カジュアル面談を受けて、好感をもったポイントは以下の通りです。

  • 「良い景気を作ろう。」というビジョンへの共感

  • 今まで自分が関わったサービスよりもリリース頻度が高く、改善のスピードが早いプロダクト

  • 社員の方が温和で話しやすい印象

その後選考に進み、晴れて入社が決まりました。

入社前後

入社前の手続きの中でSlackとNotionに招待されました。まず感じたのが良くも悪くも情報量がとにかく多いことです。
Slackの流量がとにかく多く、社内ルールとしても通知OFFが推奨されています。(アラートのみ通知に設定)
またNotion上の情報も多く、チーム配属直後のキャッチアップはオンボーディング資料を見れば大体の内容を掴むことができました。

入って良かったこと

お互いを褒めたたえる文化

ログラスには「Win Session」というイベントがあります。(最近は不定期開催)
これは週の終わりに各チームの達成事項(受注、リリースなど)を褒めたたえるというイベントです。またhey tacoというピアボーナスのサービスを利用しており、社員同士が感謝の気持ちをタコスの絵文字とメッセージで伝えることができます。タコスが一定量たまると景品と交換できます。
このように社員同士を褒めたたえる文化が形成されていますが、お互いに厳しい意見も言える心理的安全性が保たれています。

1on1

1on1というと、個人的には評価面談や目標達成度の確認のイメージがありますが、ログラスでは雑談のみの1対1の会話も1on1としています。
個別で話すとお互いの理解を深めることができますし、普段の業務では関わらない社員とも気軽にコミュニケーションが取れます。

開発プロセス

現在は火曜と木曜に定期リリースを行なっています。開発チームとしてはまだまだ頻度は低い認識で、今後はトランクベース開発も検討中です。リリースノートはリリースの2営業日前に開発とCS間で調整し、リリース当日に公開しています。

利用ツール

さまざまなツールが導入・活用されています。

  • バクラク(経費申請ツール)

    • 領収書の原本を提出しなくても、写真をアップロードするだけで完結します

  • Gather(バーチャルオフィス)

    • リモートワーク時は常にGatherに繋いでいるので気軽に他社員とコミュニケーションを取れます

  • ラクロー(勤怠管理)

    • Slackにメッセージ投稿することで打刻ができるので、勤怠状態の共有もしやすいです

  • Slack(社内)

    • 基本はpublic channelで会話しており、情報の透明度が高いです

    • カスタムレスポンスが多用されており、例えばフロアマップ、従業員評価指標、wifiの接続情報などをパッと表示できます

      • 社員の変な写真などネタ画像も多いです

    • 名前はフルネームでアイコンは自分の顔というルールがあるので、どのユーザが誰なのか分かりやすいです

      • 名前に休み情報を書いている人も多く、メンション相手の状態も把握しやすいです

部活動

部活動の種類も多く活発です。
自分は自己紹介ページにブラジリアン柔術やってましたというのを書いたら、速攻でMMA鑑賞部に勧誘されて参加しました。
鑑賞部と言いつつ実際にスパーもする部活で、久々に格闘技ができて嬉しかったです。

部活動の様子(写真右端が自分です)

課題と思う部分

ここまで会社の良い面を紹介してきましたが、課題もあります。

日々の作業フローにtoilがまだ多い

社内で定常的に発生している作業には都度手動で対応している、いわゆるtoilが複数あります。ものによりますが機能開発するとしてもそこそこ重い内容です。そして顧客価値には直結しないので優先度は比較的低いです。ここについては運用手順を見直すことで一定の改善を期待できるところもあります。

分析基盤を整備しきれていない

問い合わせや要望についてはNotionで収集、サービスのメトリクスはdatadogで収集、また顧客情報についてはSalesforceで管理されています。ただこれらの情報をつなぎ合わせてプロダクトを改善する示唆を得たり、ファクトに基づく意思決定を行う基盤はまだ整っていません。

リリース1回あたりの変更量増加

最近は採用が加速しており、その分エンジニアによるコード変更量も多くなってきています。これ自体は良いことですが、その分1回のリリースによる変更量も多くなっており、変更障害率が高くなってきています。

終わりに

上記のようにまだまだ課題はあるのですが、それに対して愚直に改善を進めています。データを見て、関係者にヒアリングして、改善案を検討し、実行に移す、という地道な活動を続けています。ただこれによって少しずつ前に進んでいる感触があります。そしてこういった活動を受け止めてくれる文化もあります。LoglassのTech Value「Update Normal」に基づき、当たり前をアップデートする事が評価されます。最近では、自分が問い合わせフローを改善した取り組みを部会で紹介していただきました。

ここまでお読みいただきありがとうございます。少しでも興味があれば、お気軽にお声がけください。


この記事が参加している募集

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