DevOpsの指標を開発の振り返りに活用しはじめた話

こんにちは、プレックスの種井です。

今回は、2022年Plex開発合宿(秋)シリーズ最後の記事になります。(過去の記事はこちら)

10月の開発合宿で私が取り組んだ内容「開発チームの生産性の可視化」とPlexJob開発チームにおける「振り返り」の取り組みに関してご紹介させていただきます。

開発合宿で扱ったテーマ「振り返り」

私の所属するPlexJob開発チームではスクラム開発を取り入れています。合宿時点では月に一回、その月に取り組んだ各スプリントの振り返りをまとめて行っていました。

振り返りを行うなかで

• 個々人の課題感やその粒度に関してばらつきがある
• 課題に対してのアクションの優先度がつけづらい

という課題感がありました。

開発合宿で取り組んだ内容

振り返りの場では、各メンバー感じている課題を思い思い自由に出してもらいつつも開発チームとして重要視することを明確にしておくことは振り返りの質の向上や、個々人の課題感の洗い出しのしやすさという観点から重要だと考えました。

書籍エッセンシャルスクラムにも振り返り(スプリントレトロスペクティブ)の事前準備として、「フォーカスの定義」や「客観的データの収集」が要素として上げられています。 今回は、取り掛かりとして、「スプリント毎のベロシティ」と「デリバリのパフォーマンス(Four Keys)」の一部を計測することにしました。

上記の指標は

• スプリントごとのベロシティ
  • チームの健全性の把握や提供した顧客価値の程度を測るものとして
• デリバリのパフォーマンス(Four Keys)
  • 開発プロセスの中でも数値として計測しやすく、改善の効果が得られやすいものとして(開発プロセスの改善)
• 合宿の限られた時間内で試せるもの

という観点で選びました。

また、週次のスプリントにおけるベロシティは開発だけではなく、設計からリリースまでの間に複数の役割や要素が影響します。デリバリのパフォーマンス(Four Keys)も合わせて計測することで、開発者内でボトルネックの発見や改善に向けての意識が向きやすいのではないかと考えました。

Four Keysは4項目ありますが、今回は合宿の時間に限りがあるため比較的計測の容易な「デプロイの頻度」と「変更のリードタイム」の2項目のみをスコープとしました。

スプリントごとのベロシティの計測

PlexJob開発チームでは、スクラムにおけるタスクをNotionのデータベースとBoard viewを使用して管理しています。

1. Notion APIを使用し、データベースからスプリント毎の完了タスクを収集
2. BigQueryに保存
3. Metabaseから集計

という流れで、ダッシュボードを作成することにしました。 1,2はスクリプトを作成し、自分の手元のPCで実行するような簡易的なものにしました。

スプリント毎の完了ポイント

Four Keysの計測

前述の通り今回「デプロイの頻度」と「変更のリードタイム」の2項目を対象とします。 両指標ともGitHub APIにて提供されているデータを活用しました。 また、

• 計測の対象としてPlexJobのAPIのリポジトリ上のデータのみを使用
• 土日は除く
• dependabotによるPRのマージは除く

という前提で集計を行いました。

デプロイの頻度

本番環境へのリリース頻度です。 master(main)ブランチへのPRがマージされたタイミングをリリースとして、1日あたりのリリース頻度を月毎の平均として算出してみました。

リリース頻度

変更のリードタイム

初回コミットから本番環境へのリリースまでにかかった所要時間です。 master(main)ブランチへマージされたPRの初回コミットからマージまでにかかった時間(日数)を月毎の平均として算出してみました。

リリースまでのリードタイム

合宿時点までの直近3ヶ月の指標を、パフォーマンスレベルに照らし合わせると両項目で「High」にあたることが分かりました。

まとめ

簡易的ではありますが、上記の指標を出してみて改めて個人の負荷状況、開発上のボトルネック、改善点について考える客観的な指標として活用できそうだと実感しました。

実際、合宿の最後の発表の際にも

• さらにリリース頻度を上げるためにはリリース対象を分割していくべきか？
• 逆に分割しすぎてQAやプロセスの最適化をしないと、リリースが遅くなることはないか？
• Four Keysの指標とスプリントのヴェロシティを合わせて計測すると分割の最適化ができるのはないか？

のような議論をすることができました。

PlexJob開発チームでの振り返りの取り組みについて

ここまで、10月の開発合宿で取り組んだ内容の紹介をさせていただきましたが、早いもので気がつけば3ヶ月以上経過しており、開発の体制としてもいくつか変化がありました。

この間、振り返りに関しても新たな取り組みをはじめました。 合宿で取り組んだDevOpsの指標もこの取り組みの中で活用しはじめたこともあり、この場を借りて紹介させていただきます。

前述させていただいた通り、10月時点では月に1回の振り返りを行っていましたが、11月、12月で開発チームに新たなメンバーが計2名ジョインしてくれたこともあり、よりチームとして情報の共有をオープンにし課題や方針に対してのアクションなどに共通認識を持てるようにすべきだと考え、振り返りの場の頻度や内容を再設計することにしました。

振り返りの内容としては、アジャイルなチームをつくる ふりかえりガイドブックなどを参考に以下のようなものにしました。

1. 週1回金曜日に1時間程度の定例MTGを設ける
2. 事前に振り返りシートを共有し、各メンバーにKPT用のJamboardに今週のアクションや課題と負荷状況を記入してもらう
3. 前週のTryの実施状況の確認をする
4. Jamboardに各自作成してもらった今週のアクションや課題を発表しながらKeepとProblemに振り分ける
5. 全員のKeepとProblemが分類でき次第、Tryを議論して決め、次週のアクションにする
6. Tryの中で開発Issueとして扱うべきものはタスク化する
7. 各メンバーの調子と一言コメントを発表する

以下は、使用している振り返りシートの一部です。

振り返りシート(一部抜粋)

運用をはじめて1ヶ月程度経ちました、まだまだ試行錯誤の段階ではありますが取り組みの中で、プロダクトチーム全体での勉強会や、問い合わせ対応の当番化などの実際のアクションにつながるものもいくつか出てきています。 引き続きメンバーのフィードバックをもらいながら続けていきたいと思います。

合宿で取り組んだ内容のその後と活用

最後に合宿で取り組んだ内容の活用ですが、Four Keysの2項目を振り返りシートに埋め込んで各自の振り返り時に使用してもらうことにしました。 KPTの洗い出しや次アクションを決める際の観点として活用してもらいたいという意図があります。

1. GitHub APIから取得したデータを加工してtsvとして書き出すスクリプトを実行
2. tsvをスプレッドシートにインポート
3. Google Looker Studioで2.のスプレッドシートをデータソースにしてダッシュボードを作成
4. Notionの振り返りシートに埋め込み

指標の活用例

おわりに

今回、合宿での振り返りの効率化としてのDevOps指標の検証と、PlexJob開発チームでの「振り返り」の取り組みに関して紹介させていただきました。

効果的な振り返りを継続的に実施することは難しいことです。 なるべく各メンバーの負荷を最低限にしつつも、効果的な振り返りを続けることは重要であると考えています。 事例として少しでもご参考になればと思います。

振り返りの取り組みやFour Keysをはじめとした指標の活用の変化に関しても引き続きアップデートがあれば、本ブログで紹介していきたいです。

最後になりますが、プレックスではソフトウェアエンジニア、フロントエンドエンジニアを募集しています。

上述のような、開発上の取り組みや課題に対してご一緒していただける方、少しでも興味を持っていただけた方は業務委託や副業からでも、ぜひご応募いただけると幸いです。

dev.plex.co.jp

開発合宿でコードレビューのプロセスを改善した話

こんにちは、プレックスの石塚です。 この記事は開発生産性 Advent Calendar 2022の21日目の記事になります。

前々回の記事で、10月に開発合宿を開催し、「普段できていない開発プロセスの改善」というテーマのもと、各々が開発に取り組んだ様子をご紹介させていただきました。その中で、個人が取り組んだ内容を次回以降のブログで詳しく書いていくと言っていましたが、気付けば早2ヶ月が経過、さすがに年をまたいでしまってはまずいという思いで、焦り筆を取っている次第です。

そういったわけで、今回は自分が開発合宿の中で取り組んだテーマである「コードレビューのプロセス改善」のお話をさせていただきます。

コードレビューの目的

まずプロセス改善の話をする前に、なぜコードレビューを開発プロセスに組み込んでいるのかという話をしたいと思います。 コードレビューは多くの現場で開発プロセスの一貫として取り入れられていることが多いですが、絶対必要というわけではありません。 特に事業フェーズが初期段階かつシニアなメンバーが集まる組織では、コードレビューを省略しているパターンが多いイメージがあります。

個人的にコードレビューを導入する目的に関してはエンジニアリング的観点とビジネス的観点の2つがあると考えていますが、弊社の開発組織においては導入するメリットの方が大きいと感じています。

エンジニアリング的観点

エンジニアリング的観点としては以下のような、いわゆるコードレビューのメリットとして語られることが多い事柄です。

• プロダクトをチームでメンテナンス可能な状態に保つ
  • リーダビリティや一貫性、品質の担保
• プロジェクト、ドメイン、技術における知識の共有
• オーナーシップを高める
• ログが残る

ビジネス的観点

• コードが目的を達成できる正しい挙動をしているか確認する
• 不具合を減らす

ビジネス的観点は上記の2つです。 現在のプレックスの開発では、PdM、エンジニア、デザイナーの分業体制がきっちりと明確になっているわけではないので、コードの変更がユーザーストーリーのゴールを達成するものかを確認するといった目的も含まれています。

コードレビューの責務が増えてしまい、余計なコストが掛かってしまうので、本来は仕様の是非まで確認するのは理想的とは言えません。とはいえユーザーに提供してからこの機能は無駄だったよねとなってしまうと、今まで開発に掛けてきたコストが無駄になってしまうので、開発プロセスのなるべく早い段階で発見できるように、タスクの種類や大きさによって確認するようにしています。

※このあたりの生産管理の話はHIGH OUTPUT MANAGEMENTが詳しいです。

以前のプロセスと発生していた課題

前置きが長くなってしまい恐縮ですが、改善前のコードレビューのプロセスとそれにおいて発生していた課題についても軽く紹介しておきたいと思います。

以前のプロセスではSlackのワークフローを活用していました。 このようなプロセスに落ち着いた背景として、最初はSlackのメッセージでテキストで直接コードレビュー依頼を実施していたので、ワークフローを使って自動化したという経緯があります。 入力値は以下の3つで、レビュワーとレビューイにメンションが飛ぶようになっています。

• レビュワー
• 緊急度（お手すき・なる早・大至急の3種類）
• プルリクのURL

Slackワークフローでのコードレビューのイメージ

この運用では特に大きな問題はなかったものの、以下のような課題がありました。

• コードレビューが溜まりがち
• コードレビューが漏れる
• コードレビューに時間が掛かる
• レビュワーのコンテキストスイッチが発生する
• コードレビューの知識がレビュワー、レビュイー以外のメンバーに共有されない
• Githubでのコードレビューの後、Slackでメンションする手間がある

どう改善したのか

原因の特定

合宿の前からどんな課題があるかを議論したり、書籍やブログでのインプットをした結果、主に以下の2点が根本的な原因だと考えました。

• プルリクエストのサイズが大きい
  • コードレビューに掛かるコストが増える
    • 時間が掛かる
    • コンテキストスイッチが発生する
      • 溜まりがち、漏れる
• Githubのリマインダーを適切に使えていない
  • 定期的にコードレビューの時間を確保できていない
  • 自分がアサインされているコードレビューを一覧できる場所がない
    • 溜まりがち、漏れる
  • Githubでのコードレビューの後、Slackでメンションする手間がある

「コードレビューの知識がレビュワー、レビュイー以外のメンバーに共有されない」という課題に関しては、比較的チームの人数が少ないこともあり、今回はコストパフォーマンスを考慮して改善のスコープ外としました。

プロセスの改善

そうした流れから、合宿では次の2つの改善を実施していきました。

1. プルリクエストの大きさを小さくする

こちらの改善はプロセスというよりは、心構えに近いですが、コードレビューガイドというドキュメントを用意して、オンボーディング時に共有する形にしました。 実際のコードレビューガイドに記載されている内容をそのまま添付しておきます。

1. プルリクエストを小さくする
- プルリクエストの元となる仕様を小さくする
  - 実装の前にWHYやWHATについて議論しておく
    - スプリントMTGでできると全員参加しているので良い
    - WHYやWHATは本来コードレビューで蒸し返されるべきポイントではないが、リリースしてから気付くよりはコードレビュー時に気付けるほうが手戻りが少ないので気付いたら言うべき
  - 実装の元となるタスク（HOW）を細かく分割する
- 変更が大きくなる際は、設計レビューを実装前に行う
  - モデリングにはドメインモデル図を推奨

コードレベルでプルリクエストを小さくすることも大事なのですが、それ以前の仕様を決める段階での動きがより重要だと思っています。 ユーザーストーリーのゴールを達成するミニマムの仕様はどういったものか、仕様が大きいのであればマイルストーンを引いて検証を分割することはできないかを考えるようにしています。 また大きな変更であれば、設計レビューも事前に行うことで、プルリクエストの責任範囲を小さくすることも意識しています。

2. GithubのSlack連携を軸にプロセスを構築

Githubにはscheduled remindersというSlackと連携したプルリクエストのリマインド機能があります。この機能は大変便利なのですが、個人ごとに設定をする必要があり、設定がばらついているとうまく恩恵を得ることができません。

なのでプレックスでは以下のようなルールを作って運用していくことを決めました。

• SlackのGithub連携をしている部屋にジョインしておく
  • Slackのユーザーグループに設定して、デフォルトでジョインするようにしておく
• 開発者は scheduled reminders を必ず設定しておく
• 平日に1日2回はリマインダーを設定し、コードレビューの時間を取るようにする
  • 時間は任意
• コードレビューの依頼はプルリクエストのレビュワーのアサインで行う
  • 急を要する場合のみSlack上でメンションする
• レビューの修正が完了したらプルリクエストからレビューの再リクエストを行う

またGithubでは自分のアサインされているレビューを一覧できるリンクが取得できるので、そのリンクをSlackのカスタムレスポンスに設定したり、Slackのチャンネルのブックマークに貼っておくことで、区切りのいい時間でレビューを実施する際の手間を減らしています。

↓ゴニョゴニョしていたら取得できたリンク

https://github.com/pulls/review-requested?q=is%3Aopen+is%3Apr+archived%3Afalse+user%3A{GithubのOrganization名}

Slackのカスタムレスポンス

終わりに

以上の改善の結果、レビューの漏れや溜まりが減る、レビューを依頼する手間が少なくなるといった結果を実現することができました。 振り返ってみると、プロセスを改善できたというのはもちろんですが、合宿という全員が参加している場でお互いのレビューに関する共通認識を揃えることができたことも大きかったなと感じています（自分の実装とレビューのどちらが大事なのか等）。

嬉しいことに11月、12月に1名ずつ、フルタイムのエンジニアの方がジョインしてくださり、フルタイムで4名、業務委託・インターンを含め10名弱の開発組織になってきました。 組織が拡大していく中で更なる改善として

• レビュワーに誰をアサインするのかをどうやって決めていくのか
• コードレビューの知識の共有

などの課題にも今後取り組んでいきたいと思っています。

最後になりますが、プレックスではエンジニアを絶賛募集中です。 今回のプロセス改善のような、開発上の取り組みや課題に対してご一緒していただける方、少しでも興味を持っていただけた方は業務委託や副業からでも、ぜひご応募いただけると幸いです。

dev.plex.co.jp

開発合宿でドキュメント整理やER図の自動生成やってみた

はじめまして、プレックスインターン生の鈴木です。

先日、PlexJob開発チームではじめての合宿に参加したので、そこでの私が行ったことを紹介していきたいと思います。開発合宿の目的などは前回の種井さんの記事も併せて、ぜひご覧ください。

product.plex.co.jp

鈴木の開発合宿テーマ

ドキュメント関連の整理や作成

1. ドメインモデル図の移行

2. ER図の作成

1. ドメインモデル図の移行

背景

これまで、PlexJobのドメインモデル図はNotion内のドキュメントにありました。

しかし、新機能を追加してもドメインモデル図の更新が忘れられていることが多くありました。また、ドメインモデル図の記述量が増えるにつれて、Notion内でレビューのしづらさもありました。そこでドメインモデル図をプロジェクトのディレクトリ内に置けば、コード変更時と同時にドメインモデル図も変更できるので、ドメインモデル図の更新を忘れることが少なくなる。そして、Github上で確認できるのでレビューもしやすくなるのではないかと考えました。

実際にやったこと

1. プロジェクトのディレクトリ内にdocフォルダの作成
2. その中にmarkdownファイルを作成
3. markdownファイルにNotion内のドメインモデル図を参考に書いていく

実際にできたもの

GitHubでは、markdown記法とmermaid記法に対応しているので、ドメインモデル図がとても書きやすかったです。特に、mermaid記法は図形を簡単に作成できるので、とても便利な記法だということを知ることができました。ディレクトリ内に移行したので、ドメインモデル図の更新忘れも減ったのではないかと感じています。

ドメインモデル図

2. ER図の作成

背景

これまでドメインモデル図はありましたが、ER図というものは存在していませんでした。どんなテーブルが存在しているかやテーブル同士のリレーションを確認したいときは、railsのmigrationファイルを見るかコードを見るかGUIクライアントで確認という形になっていました。なので、実際にER図を作って視覚的にテーブルやリレーションを確認できるようにしたいと考えました。

実際にやったこと

現在、PlexJob内には約70のテーブルが存在しています。このテーブル数のER図を自分で書くのはとても大変です。そこで、良い方法がないか探したところrails-erdというライブラリでER図を自動生成できそうだったので使ってみました。

rails-ERDの導入

1. まずは、OSにgraphvizというツールパッケージをインストールする必要があります。Graphviz (Graph Visualization Software)とは、DOT言語で記述されたグラフ構造を描画するパッケージ。

   弊社では、Dockerを使用してプロジェクトを管理しているので、Docker内にこのGraphvizをインストールする必要があります。なので、Dockerfileに下記コードを追加しました

   RUN apt-get install graphviz

2. そして、今回の主役であるrails-erdをGemFileに追加します

   group :development do
   　gem "rails-erd"
   end

3. bundle installをしたら、下記コマンドで全テーブルに対してER図を自動で作成してくれます。

   bundle exec erd

実際にできたものと問題点

テーブル数と大体のリレーションは視覚的にわかるようになりました。

しかし、70テーブルもあると以下画像のように大変なことになってしまいました、、

対策: オプションをつける

bundle exec erd --attributes=foreign_keys, primary_keys —filetype=png

とすることで、全カラムでのER図の出力ではなく主キーと外部キーだけの表示となるので、以下画像のようにごちゃごちゃ感を少しは緩和させることができたと思います。さらに見やすくする方法はないか調べていきたいです。

開発合宿の個人的な反省点

開発テーマを決めるのに半日以上かかってしまった。

開発合宿の当日にテーマを決めたのですが、なかなか良いテーマを見つけることができずにテーマ決めに多くの時間を使ってしまいました。なぜテーマが思いつかないかを考えたときに、これまでは技術のインプットなどに意識を取られていて、開発の問題点などを探しながら業務を行うことができていないことに気が付きました。最近は、技術のインプットもできてタスクをこなすスピードも上がってきたので、普段の業務では自分のタスク以外にも目を向けて開発の問題点なども探していきたいと思います。次回の合宿では、もっと良いテーマ選定で開発ができるようにしたいです。

開発合宿の感想

とても楽しかったです！！！

はじめて開発合宿というものに参加したのですが、普段とは違う雰囲気で開発することができたので気分転換になったと思います！普段の業務では話さないコミュニケーションもできて、美味しいものもたくさん食べることができて、とても良かったです！月1回の開催にしましょう←

最後になりますが、プレックスではソフトウェアエンジニア、フロントエンドエンジニアを募集しています。少しでも興味を持っていただけた方は業務委託や副業からでも、ぜひご応募いただけると幸いです。（インターン生も募集しています！）

dev.plex.co.jp

開発チームで初めての合宿に行ってきました

こんにちは、プレックスの種井です。

今回は、PlexJob開発チームではじめての合宿を実施したので、そこでの取り組みや様子を紹介していきたいと思います。

背景・目的

• 普段の開発ではどうしても優先度が下がってしまうが、課題に感じていることに対して、テーマを決めて取り組む時間を設けたい
• 場所を変えたり、道中や余白のコミュニケーションの場を作ることによりメンバーの気分転換につなげたい

今回はエンジニアのみで実施しましたが、今後はエンジニアに限らずプロダクト開発に関わるメンバーを含んだ会も設けていきたいと考えています。

場所

1日目: 千葉県 山武郡 九十九里町にある一軒家の一部屋をAirbnbでレンタル

2日目: 千葉駅周辺 コトコトコワーキングさん

西船橋駅に集合し、車で目的地に移動しました。

取り組み

合宿前

今回、「普段できていない開発プロセスの改善」という大枠のテーマがありました。

事前にMTGを設け、個々人の感じている課題の洗い出しと各課題を子テーマとして分類し、子テーマに対してそれぞれ個人的に課題感の強いものや、すでにアイデアのあるものに関して挙手制で担当を決めました。

以下は今回は各々が取り組むことになった子テーマです。

• コードレビューの改善 → 石塚
• ドキュメントの改善 → 鈴木
• スプリントの改善 → 種井

合宿中

2日目夕方の成果発表を目標として

担当する各子テーマの中で、日々開発する中で出た改善のアイデアをもくもくと作業し、形にしていきます。

1日目

移動中の車内では雑談を交えつつ、子テーマに対するアイデアなどに関して話ました。 ここで出たアイデアからの成果もいくつかありました。

移動の車中

宿に到着次第、それぞれ自由に作業に取り掛かります。

1日目作業の様子

2日目

千葉駅付近にあるコワーキングスペースに移動し、成果発表まで最後の追い込みをしていきます。

最後に会議室にて、成果の発表と感想、成果に対しての質疑を行いました。

以下は各々の成果物に関しての概要です。

• 石塚(コードレビューの改善)

  • コードレビューのガイドライン作成
  • レビュー依頼リマインダーの作成
  • PR自動作成ツールの作成

• 鈴木(ドキュメントの改善)

  • ER図の自動生成
  • ドメインモデル図をNotionからGithub管理へ移行

• 種井(スプリントの改善)

  • 週次スプリントのストーリーポイント自動集計とダッシュボードの作成
  • DevOps指標の可視化

(各々の成果物に関しては、別途ブログとして公開する予定です)

2日目作業の様子

その他

1日目のお昼は橋本食堂さんでうな重を食べました。うなぎはもちろんのこと個人的には味噌汁の味が忘れられません。

うな重

合宿先からインターン鈴木さんのご実家で営まれているキャンプ場(有野実苑さん)が近いこともあり、 晩ごはんを兼ねてキャンプ場にお邪魔させていただきました。 場内の雰囲気、料理ともに最高でぜひまたプライベートでも伺いたいです。

併設のレストランで晩ごはん。

2日目の朝は九十九里浜で目を覚ましました。

おわりに

今回の合宿のテーマである「普段できていない開発プロセスの改善」に対しての、すぐにでも活用できるような改善やツールが成果物として生まれました。

各成果物に関しては、各メンバーに次回以降のブログで詳しく書いてもらう予定です！

また、普段の業務だけではとれないコミュニケーションができたり、開発プロセス上の各々の課題感に関してもアイデアをたくさん話し合うことができ非常に有意義な時間でした。

• 1泊2日だと移動時間込で作業時間が限られるため、短く感じた
• 土日の開催だと翌週疲れが抜けない状態でスタートしてしまう
• 人数分のディスプレイがあった方が捗りそう

をはじめ、今後の開催に向けての改善点も出たので、また次回以降に活かしていきたいと思います。

最後になりますが、プレックスではソフトウェアエンジニア、フロントエンドエンジニアを募集しています。

上述のような、開発上の取り組みや課題に対してご一緒していただける方、少しでも興味を持っていただけた方は業務委託や副業からでも、ぜひご応募いただけると幸いです。

dev.plex.co.jp

プレックスのエンジニア組織体制

こんにちは、プレックスの石塚です。

弊社は今までリファラルでのエンジニア組織の組成を続けてきましたが、組織拡大のため求人媒体やダイレクトリクルーティングサービスを用いた採用活動を今年の3月から本格的に始めました。 採用活動を続けていると、現状の組織体制についても質問を受けることが多くなってきたので、この機会にブログにまとめてアウトプットしたいと思います。

プレックスの事業について

まず組織体制を説明するために、その背景となる事業郡について説明します。 プレックスは「日本を動かす仕組みを作る」というミッションを掲げ、インフラ産業を軸に次の4つの事業に取り組んでいます。

• ドライバー向けの人材紹介事業
• ドライバー向けのダイレクトリクルーティング事業
• 電気主任技術者向けの人材紹介事業
• 新規SaaS事業

それぞれの事業ごとの主な開発対象を簡単にまとめると下記の通りです。

• ドライバー向けの人材紹介事業
  • kintoneやSlack、GASなどを用いたオペレーションの効率化
  • 広告ランディングページ
• ドライバー向けのダイレクトリクルーティング事業
  • ドライバー向けの求人サイト「プレックスジョブ」
  • 採用企業様向けの管理画面
  • 社内メンバー向けの運用管理画面
• 電気主任技術者向けの人材紹介事業
  • ドライバー向けの人材紹介事業に同じ
• 新規SaaS事業
  • SaaSプロダクト

エンジニア組織体制について

エンジニアの人数は下記の通りで、組織体制は図のようになっています。※正社員の人数が合わないですが、兼務となっています。

• 正社員: 2名
• 副業・業務委託: 4名
• 学生インターン: 1名

エンジニア組織体制

組織体制の意図

エンジニアの組織体制は事業部制を基本としています。 事業部制を採用した大きな理由はプレックスという会社の文化に対して適していると考えたためです。 プレックスには「PLEX OUTPUT」という、好奇心を持って、検証し、成果をあげようという社内で浸透しているバリューがあります。 社内にエンジニア組織ができる前から既にあったバリューですが、エンジニアリングやデータ分析のキャリアを歩んできた自分からしても、仮設検証を通じて不確実性をコントロールしていくことは、プロダクト開発において最も重要なことの1つだと感じています。 したがってエンジニアであってもより良い事業・プロダクトを作るために、市場や産業に好奇心を持って、仮説検証を素早く回していくという理想を実現するため、事業部制を採用することに決めました。

もう一つの理由は、開発組織を横串部門としてしまうと、社内外注化しやすくなってしまうためです。 特にプレックスでは事業の数や開発量に対して、エンジニアの数が少ないです。 そのため横串部門としてしまうと、タスクをこなすことでリソースを使い果たしてしまい、中長期的に持続的な開発を続けるための開発や不確実性にチャレンジしていく開発へのリソースが割けなくなってしまいます。

さらに人数が増えれば横串部門を作り、スケールメリットを活かすという方針もあると思いますが、現時点では会社の文化として事業部制をベースに組織を作っていきたいと考えています。

体制を運用するための工夫

最後に上記の体制を効率的に運用していく上での取り組みを2点ご紹介します。

副業や業務委託の方にサポートしていただく

まず1つ目は、副業や業務委託、学生インターンなどの多様な働き方を許容し、サポートしていただいている点です。 多くの会社が取り入れていることだとは思いますが、依頼する内容としては、キャッチアップコストがそこまで高くないもの、緊急度がそこまで高くないものという2点に気をつけています。 また副業の方に合わせて、ミーティングの時間帯を夜の時間帯にずらしたり、休日に実施したりもしています。

他事業部から開発リソースを借りるケースの交通整理

組織図上はキレイな事業部制となっていますが、事業部によっては正社員のエンジニアがいないため、突発的な開発依頼を他の事業部に依頼するケースもあります。 プレックスではスプリントを採用しているため、急な差し込みや依頼が発生するのはあまり好ましくありません。 そこで弊社ではSlackのworkflowでタスクを挙げてもらって、優先度を判断しスプリントに組み込むといったスタイルを取っています。

Slackの依頼フォーマット

現状ではリソース上の成約から、人材紹介事業部側やコーポレート側の生産性の効率化はそれほどできていません。しかしまだまだ余白があり、利益的なインパクトも大きいポイントなので、今後取り組んでいきたいテーマの1つです。

最後に

プレックスはエンジニアを絶賛採用中です。 現状では理想ばかりが先行している状況ですが、1人1人のエンジニアが事業やプロダクトにコミットし、楽しめるような環境を作っていきたいと思っています。そのような環境を楽しめる方や一緒に作っていっていきたいという方にぜひジョインしていただきたいです。

dev.plex.co.jp

また、これらの記事の内容は現時点での話で、人数や状況が増えれば変わるものだと考えています。しばらく時間が経った後に同じ記事を書いてみるのも面白そうなのでぜひ来年や再来年あたりに書いてみたいです！

技術的負債との向き合い方

こんにちは、プレックスの種井です。

今回は、PlexJob開発チームにおいて、技術的負債に対して、どのように向き合っているかを紹介したいと思います。

「PlexJob」は物流特化型のダイレクト・リクルーティングサービスです。

• 求職者様が求人を検索するサイト
• 企業の採用担当者様が採用活動を行うための管理システム

を提供しています。

背景

PlexJobはリリースから1年を迎えています。 嬉しいことに1年間ですでに13万ユーザーを突破するなど、急成長のサービスではありますが、まだまだプロダクトとしては、業界特有の課題に対して、仮設検証を繰り返しているフェーズです。

• 開発において、事業間の連携が存在し、複雑なドメイン知識を扱う必要がある
• 複数の外部サービス連携が存在する
• 不確実性の高い、業界特有の課題に対して仮説検証サイクルを回している最中であるため、業務知識やシステムに変化が生まれやすい

ことから、開発を重ねる毎に業務知識と実際のシステムの仕様との乖離や暗黙知が発生することも少なくはありません。

技術的負債が生まれることは仮説検証による学びが得られている、プロダクトが成長している証拠なので、事業としては健全ではありつつも、時間とともに開発効率は低下していきます。

このように検証スピードを維持するため、現状、開発チームとしてどのような取り組みを行っているのかを紹介してきたいと思います。

技術的負債との向き合い方

スプリントのタスクの10~20%を負債の返済に当てる

PlexJobの開発体制は、現在以下のようになっています。

sprint

【メンバー構成】

• PO: 1名
• エンジニア: 4名(業務委託・インターン含む)

【開発の進め方】

• 週次のスプリント
• 毎週火曜日にスプリントMTGを実施し、バックログから1週間分の開発タスクの決定と見積もりを行う
• バックログには開発チーム全員が起票することが可能

【リリース】

• タスクが完了した段階で順次リリース(金曜日を除く)

週次のスプリントで、1週間分の開発タスクの10~20%を技術的負債の返済タスクに取り組むことをルール化しています。 また、

• POが技術的負債に対する理解がある
• 後述する棚下ろしを行う段階で、KPIや予定している施策から逆算し、今対応しておくべき課題と優先度を決めている

ことから事業部として重要性を理解した上でルール化ができています。

負債の蓄積と共有を行う

各メンバーが開発タスクを行う中で課題を感じた箇所に関しては、該当タスクの完了前もしくは、直後に

1. 課題をバックログに起票する
2. 該当箇所に関して、実装の担当者が得た暗黙知となっている箇所や、業務知識などをドキュメントとして残す

を行い、なるべく鮮度の高い状態で課題に対する情報を蓄積するようにしています。

技術的負債などの開発上の課題に関しては「GitHub Projects」で管理しています。

また、2.の複雑な業務知識などは「ドメインモデル図」を使用してドキュメント化を行っています。

振り返りと棚卸しを定期的に実施する

Qに一度、前Q取り組んだ課題の進捗の振り返りと、バックログや積み残しの課題に対して棚卸しを行っています。

• ロードマップ上、次QのKPIに影響しそうなもの
• 開発者間でボトルネックに感じる度合いの強いもの

のような、観点でGitHub Projectsに起票された課題の優先度づけを行っています。

社内のメンバーで対応できない、技術的専門性の高い課題(弊社の場合、主にフロントエンド)に関しては、専門性のある業務委託のメンバーにフィードバックをもらい、具体的なタスクに落とし込んでいくようにしています。

負債の返済に対しての敷居を下げる

負債の返済には変更の影響範囲が大きくなることもあります。 変更を恐れて、負債の返却を後回しにしないよう、なるべく、不具合を事前に防ぎ、異常を検知する仕組みづくりや、チーム全体としてシステムの変更による影響を認識する場を設けるようにしています。

具体的には、以下のような取り組みを行っています。

• リリースの粒度をなるべく小さく段階的にする
• 各システムで異常検知を行うための監視システムを導入する
• リリース日時と変更点をGoogleカレンダーに自動登録する
• 自動テストやカバレッジの計測、振り返り
• デバッグタイムを設け、スプリントMTG時に開発チーム全員で一斉にデバッグを行う

負債に対して、個々人の目線を合わせる

課題に取り組み、負債を返済する上で個々人の技術的な、習熟度や引き出しの多さが必要となります。 週1回の頻度で実施している勉強会で現在抱えている課題に対する手法や、チームとして不足しているスキルを補うものを中心に選ぶようにし、チームとして目線を合わせる機会を作るようにしています。 今までに実施した勉強会では、DDDやTypeScriptなどを扱いました。

DDD勉強会では、ドメイン知識の共有という課題からはじまり、実際の負債の返済にも活かすことができました。

社内DDD勉強会を通じてトライしたことは、本ブログの記事にもなっているので、ぜひ読んでみてください。

product.plex.co.jp

現在抱えている開発上の課題

PlexJobにて抱えている開発上の課題を一部ですが、抜粋して紹介したいと思います。

開発全般

課題	概要
ライブラリアップデート方針の策定	Dependabot機能を使用しているものの、アップデートの方針がなく、PRがたまりがちになっているので方針を決めたい

フロントエンド

課題	概要
デザインシステムの設計・構築	現在、デザインシステムは存在、コンポーネントへのスタイル指定は実装者に任せる形になっているため、統一および再利用性を高めていきたい
ユニットテストの導入とカバレッジのモニタリング	プロダクト規模に対して適切なテスト戦略の策定、ユニットテストの導入および、カバレッジ計測を行っていきたい

バックエンド

課題	概要
GraphQLのエラーハンドリング方針の策定	レスポンスコードやGraphQL ErrorのerrorDetailsのデータ構造が実装者によって異なるため、エラー種別毎のレスポンスコードやデータ構造に関しての方針を策定し、コード品質の均一化をおこなっていきたい
DBのテーブルスキーマ見直し	リリース当初から検証を重ねる中で不要になったカラム、ドメインモデルと命名やデータ型に乖離のあるカラムの見直しと修正を行っていきたい

おわりに

今回、PlexJob開発チームにおける技術的負債への向き合い方に関して紹介しましたが、事業の成長により、組織やプロダクトの規模が変わると技術的負債との向き合い方も変化していきます。 また、各論の手法に関しては今回あまり触れませんでした。 今後の取り組みの変化や、手法に関しても継続的に本ブログで取り上げていきたいと考えています。

最後になりますが、プレックスではソフトウェアエンジニア、フロントエンドエンジニアを募集しています。

上述のような、開発上の取り組みや課題に対してご一緒していただける方、少しでも興味を持っていただけた方は業務委託や副業からでも、ぜひご応募いただけると幸いです。

dev.plex.co.jp

参考

t-wada.hatenablog.jp

社内DDD勉強会を経てトライしたこと6つ

こんにちは、プレックスの石塚です。

今回のブログでは弊社で行っているエンジニアの社内勉強会と、その中での学習をベースに業務中でトライしたことを6つ紹介させていただきます。

エンジニアの社内勉強会について

プレックスでは週1の頻度でエンジニアの勉強会をやっています。 テーマは社内で使っている技術やこれから導入を予定している技術など、ある程度の共通認識はありますが、比較的自由としていて、雑談ベースでカジュアルに決めています。

勉強会の形式はその時々で変わりますが、多いのは輪読会で、各自事前に書籍を読んできてもらい、勉強会当日にGoogle Jamboardに書籍を読んでの学びや気付き、わからなかった点、深堀りした点などを記載して、共有・議論していくスタイルです。

実際の勉強会時の資料

DDD勉強会について

初回の勉強会のテーマとして選んだのがドメイン駆動設計 モデリング/実装ガイドの輪読会でした（今はプログラミング TypeScriptの輪読会を実施しています）。

DDDをテーマに選んだ理由は以下の2点です。

• 弊社のプロダクト開発において、事業間の連携が存在し、複雑なドメイン知識を必要とする
• 新しいメンバーがジョインしてドメイン知識の共有に課題があった

トライしたこと

次に今回の記事の本題である、勉強会を経てトライしたことを簡単に6つ紹介していきます。

実装面以外でのトライ

ユビキタス言語を作ってみた

ユビキタス言語はDDDに登場する概念の1つで、チームが共通で使用するための辞書や用語集のようなものです。 恥ずかしながらユビキタス言語はトライしてみたものの、今は廃止してしまった事例です。

ドメイン知識を言語化して共有したいという導入の背景があったのですが、ユビキタス言語に落とし込もうとすると単語の形で表現しなくてはならないので、細かい情報の伝達には向いておらず、後述するドメインモデル図の方がマッチするということで廃止しました。

ドメインモデル図を書く

ドメインモデル図はテキストの手法をそのまま踏襲しているのですが、Notion上で

• 簡易なER図を書く
  • Mermaidを使用
• テキストでドメイン知識を書く

といった簡単なものです。 ドメイン知識を言語化して共有したいという目的では、細かい情報もテキストとして残せるのでユビキタス言語よりもドメインモデル図の方が適していました。

簡略化したドメインモデル図の例

また特定のモデルだけ作成することもできるので、新規作成するモデルから始められるなどの導入のしやすさもありました。 弊社もすべてのモデルをドメインモデル図化するのはやり過ぎだと思い、重要なモデルだけドメインモデル図に残しています。

ドメインモデル図によって、ドメイン知識の共有が楽になり、テーブル名やカラム名のレビューがしやすくなりました。 またこの勉強会を機会にドメインモデル図以外にも、手動オペレーションの実行方法をまとめたりと、ドキュメント化が捗りました。

実装面でのトライ

弊社が Ruby on Rails と graphql-ruby を使ってバックエンドを開発しているので、その2つの技術に関連した内容が多いですが、実装面でトライした内容をご紹介します。

テスト方針の共通認識を揃えた

ちょうど勉強会を始める2ヶ月ほど前にテストが全くない状態からモデルのユニットテストを書いていくという方針を決めました。 ただ実装者によって、モデルの責務が曖昧になっていたり、どこのモデルで処理を行うかにばらつきがあり、テストのカバレッジも中々上がっていきませんでした。

DDDでは変更に強いソフトウェアを作るという大目的があり、それを実現するために各レイヤーの責務を明確にしたり、テスタビリティを向上させるための方法があります。 自分たちもテキストを参考にしながら、現状のアーキテクチャーや実装と照らし合わせて、以下のようなテスト方針に対する認識を揃えていきました。

• 各レイヤーの責務を明確にし、モデルが担うべき処理はクラスメソッドやインスタンスメソッドに積極的に切り出す
• 整合性を保つために、集約ルートから集約単位でトランザクションを掛けて更新処理を行う
• モデル層の変更をしやすくするため、コントローラー層でもテストを実施する

勉強会を進めていく中で自然とこのような共通認識が揃っていき、テスト導入も一気に進んでいきました。

名前空間を分割する

DDDには境界づけられたコンテキストという概念があります。説明が難しいですが一言でまとめると、モデルの適用範囲を業務ドメインやチーム単位の境界で分割していくといったものです。

書籍の中では1コンテキスト1アプリケーションのマイクロサービスが推奨されていましたが、それを実現するためには実装コストが高く、中々導入できるプロダクトは少ないのではないでしょうか。

一方で1コンテキストで複数アプリケーションを扱うためにパッケージを分割する手法も紹介されており、弊社でも部分的にRubyのmoduleを使って名前空間を分割していくことを実施しました。 Ruby on Railsを使っているので、モデルは共通化した方がメリットを享受しやすかったため、コントローラーなどを中心にユーザーの種類単位で分割していきました。

enumによるドメイン知識の表現

書籍の中でドメイン層でのドメイン知識の表現方法として、enumを積極的に使うことが紹介されていました。

ActiveRecord::Enum の存在は知っていたのですが、テーブルのカラム型を整数にする必要があると思いこんでいたため、DBのレコードを直接見たときの視認性が下がってしまうという理由で個人的に使いたくないと思っていました。 しかし調べてみると、文字列型でもenumを使用することができたため、導入することを決めました。

stackoverflow.com

各レイヤーでの責務を明確にする

DDDの中では各レイヤーの責務を明確にして処理を分割するという考え方があります。 新規事業においては、開発のスピードが求められたり、今後使われるかどうかについての不確実性が高い開発を行うことが多いため、トレードオフを意識しながら開発を進めることになると思います。

自分たちも大まかな設計やディレクトリ構成などはRailsのデフォルトのMVCのまま変更しませんでしたが、部分的に取り入れられる箇所はいくつか試してみました。 具体的には

• コントローラーでGraphQLのオブジェクトを to_h で変換し、モデルでは直接使わないようにする
• GraphQLのDirectiveを使用してプレゼンテーション層の処理を切り出す

などを実施しました。特に1つ目の変更ではテストデータの用意が簡単になり、テストしやすさの向上を実感できました。

おわりに

個人的に勉強会をやっていてよかったなと感じることの1つが各自の抱えている課題や理想の認識をすり合わせることができる点で、そこが業務上のトライにも繋がりやすかったのではないかと思います。

今後も勉強会を続ける上では、インプットとアウトプットのバランスを大事にしていきたいです。

最後に、プレックスではソフトウェアエンジニア・フロントエンドエンジニアを募集しています。少しでも興味を持っていただけた方は業務委託や副業からでも、ぜひご応募いただけると幸いです。

dev.plex.co.jp