【開発生産性カンファレンス 2025】レベル1の開発生産性向上に取り組む─日々の作業の効率化・自動化を通じた改善活動

レベル1の開発生産性に取り組むソーシャルデータバンク

櫻田：ソーシャルデータバンク株式会社開発部 部長の櫻田健治です。部長ですがコードも書いており、組織全体の生産性向上に取り組んでいます。新卒で某通信キャリアにシステムエンジニアとして4年勤務した後、創業間もないソーシャルデータバンクに転職しました。好きな言葉は「効率化」です。

本日は「レベル1の開発生産性」についてお話します。一つ前の時間帯に開催されたアンチパターン様のセッションでは、レベル3の開発生産性について話されていましたね。この分類は広木大地さんがQiitaで発表されていた『開発生産性について議論する前に知っておきたいこと』という記事で示されたものです。

レベル1は仕事量の生産性で、作業量としてどの程度仕事をこなせたかを評価します。仕事の価値や売上貢献は一度置いておき、純粋に作業効率に焦点を当てます。ここは開発者やエンジニアリングチームレベルで改善しやすいのが特徴です。

レベル2は期待付加価値の生産性で、個々の施策がプロダクトにとってどの程度価値があるかを踏まえて評価します。プロダクトチーム全体で価値があると期待している施策をどれだけリリースできたか、に注目します。

レベル3は実現付加価値の生産性で、売上やKPIなど実際のビジネス成果への貢献を評価します。開発チームだけでなく、セールスやマーケティングなど事業に関わる全部門の総合的な成果として現れます。

同じ「開発生産性」という言葉でも、しっかり区別して議論しましょうということです。記事では測り方や評価の仕方などについても触れられているため、読んだことがない方はぜひ一読をお勧めします。

本日はこの中の「レベル1」に焦点を当てます。レベル1の開発生産性は、個人やチームで完結できるため、大きな承認プロセスが不要で効果をすぐに実感できます。事業の成功に直接つながるわけではありませんが、日々の改善活動を重ねていくことが大きな成果につながるはずです。

なお、このセッションは以下のような方々に向けて作られています。

・日々の作業で面倒だと感じているエンジニアの方
・チームの生産性を上げる施策をやりたいと思っているマネージャーの方
・改善したいが大きなことはできないと悩んでいる方

本題に入る前に、会社とプロダクト、そしてチームの紹介もさせてください。ソーシャルデータバンク株式会社は2017年に創業し、現在は8期目を迎えている従業員数70名の会社です。

自社開発プロダクトである「Liny（リニー）」は、LINE公式アカウントの配信・運用管理をサポートするツールです。OEMも含めて月間2億6000万通のLINEメッセージを送信しており、契約アカウント数は2万以上、LINEアカウントの総友達数は8700万人です。

システムの規模としては、データベースの最もレコード数が多いテーブルは数百億レコードで、DynamoDBのテーブル数が約40、Redisクラスター数が約20、ECSのサービス数が約100、1日に出るログの量が約1.5TBです。

このようなシステムを、27名のエンジニアで構築・運用しています。創業社長がエンジニアであるため、技術で主導してものづくりを追求するプロジェクト開発の文化が根付いているのが特徴です。

全社の平均年齢が31歳と若く経験年数が短い人も多いため、若手エンジニアが困っていた事例も多く取り上げる予定です。大企業～小規模の会社まで、幅広い組織で応用いただけるのではないかと思います。

自動化で効率化できた3つの事例

櫻田：それでは本題に入ります。最初に紹介するのは、検証環境のIP制限を自動化した仕組みです。皆さんの会社でも、検証環境へのアクセスにIPアドレス制限など、何かしらのセキュリティをかけていることが多いと思います。その際、社内で「このIPアドレスを解放してください」という依頼が飛び、AWSでいうとセキュリティグループやWAFの設定を変更するといった作業をしていた方もいらっしゃるのではないでしょうか。

その上で弊社の状況と課題を整理すると、検証環境をインターネット全体に公開したくありませんでした。なお、クレデンシャルは一元管理しています。管理コストや導入の手間を考えて、VPNは採用していません。個人的にはTailscaleが便利だなと思っています。依頼する側は解放してもらうまでリードタイムがあり、依頼される側のエンジニアはトイルが発生してしまっていました。

そこで解決策として、自動IP制限と解除システムをつくりました。仕組みはシンプルで、IP制限がかかっていない専用のウェブサイトにアクセスし、そこで認証を行います。弊社はGoogle Workspaceを導入しているため、Googleでログインできるようにしています。ログインすると、現在アクセスしているIPがAWSの特定のセキュリティグループに追加され、9時間後にその設定内容が自動的に削除される仕組みです。

内部向けで簡易的ではあるのですが、実際に弊社でつくっている画面がこちらです。



ログイン後にボタンを押すとIPアドレスが検証環境用のセキュリティグループに登録され、9時間後に解放されます。

効果として、依頼する側は自分のIPアドレスを調べる時間や待つ時間が減り、対応する必要がなくなったことで依頼対応をしていた側は自身の作業に使える時間が増えました。古いIPアドレスの消し忘れもなくなって、セキュリティも向上しました。

この仕組みについて、弊社は数年前に独自のアプリケーションをつくったのですが、今回はAIにCognito User PoolとAPI Gateway、Lambda、Cloudwatch Eventsによる9時間後自動削除モジュールの作成を依頼し、微調整してGithubで公開しております。セキュリティグループのIDや時間設定でデプロイすればすぐに使えるようになっているため、興味がある方は参考にしていただければと思います。

▶︎terraform module
https://github.com/kesoji/terraform-ip-restriction-ui

次はリリース付帯作業の自動化についてお話しします。アプリケーションのプロダクションコードの変更以外に、リリースに際して手作業が発生することはありませんか？

これまで私たちのチームでは、初期データ生成や互換性のためのデータマイグレーションなど、リリース時に実行が必要なコマンドがある場合、専用の作業依頼書をNotionに記載してリリース担当者が手動で実行していました。

セキュリティの観点から、本番環境でのデータベース操作やコンテナ内でのコマンド実行権限は一部のメンバーに限定しています。リリース作業時にそのメンバーの手が空いていないと作業が進まないというボトルネックがあり、そもそも手作業であることも問題視していました。

そこで、Laravelのデータベースマイグレーション機能を参考に、自動実行の仕組みを構築しました。馴染みがない方に説明すると、Laravel/Railsのデータベーススキーママイグレーションは、変更内容を書いたファイルを作成してコマンドで実行し、どこまで変更が適用されているかはデータベースのテーブルで管理されます。私たちはこの仕組みをマネしました。



特定のディレクトリにファイルを書いておいて、レビューなどを挟んでプロダクションコードにマージします。すると、リリース時のCI/CDで自動実行され、Slackに完了通知が届きます。履歴はデータベースのテーブルに入ります。

一部の作業にこの仕組みを導入してから、リリース時の立ち会いや権限を持つメンバーの日程調整が不要になりました。手順も通常のコードと同様にコードレビューされることになったため、作業の安心感も増しています。地味な改善ではありますが、リリース作業の時間と心理的負担を減らすことができた事例です。

次に紹介するのは、開発環境の更新を自動化する仕組みです。例えばこのようなやり取りが発生することはありませんか？



はじめにお話ししたように、弊社の開発環境や本番環境は全てDockerコンテナで構築されており、DynamoDBのテーブルが数十、ECSのサービスの数が100近くある複雑な構成です。開発環境も本番に近づける構成を取っているため、複雑になってしまっています。

このような環境起因のエラーは、経験の浅いメンバーには対応が難しく、その原因を理解するのも困難です。以前は「開発環境設定ログ」というNotionページを用意して、変更を加えた人が行った作業や実行すべきコマンドなどを展開していました。しかし、これでは徹底しきれないという問題がありました。

そこでつくったのが、こういった部分のチェックの自動化の仕組みです。これは私が使っているOh My Zshというフレームワークから発想を得ました。Oh My ZshはZshの機能を拡張してくれるもので、アップデートがあるとツール側から通知してくれます。デスクトップアプリなどではよくある仕組みだと思います。

これができるなら、私たちの開発環境もこれでアナウンスできるのではないかと考え、自動化の仕組みを構築しました。

具体的には、まず開発環境で行ってほしいことをファイルに記載し、Zshのディレクトリ変更時のフック関数でチェックコマンドを実行します。ここはdirenvなどを使用しても良いかもしれません。

そうすると、リポジトリのディレクトリにcdで入ってきた時に、裏でGitHubと通信し、未チェックの変更を表示もしくは実行してくれる仕組みができます。チェック状態は、各々のローカルファイルで管理されます。イメージ図はこちらです。



結果として、アップデートを忘れることが少なくなりましたし、質問する側・される側のトラブルシュートにかける時間を減らすことができました。

開発をサポートするべくデバッグツールを活用

櫻田：次はデバッグの効率化の仕組みです。例えば、ジュニアエンジニアや新しく入ったメンバーから「このデータってどこから取得しているんですか？」と質問されるといった経験はありませんか？

弊社のシステムには、DynamoDBやRedisのクラスターなどがたくさんあります。そういった場合はパフォーマンスのオフロード目的であることも多く、ロジック自体が複雑になっているため、新しいメンバーや普段触らない機能を触るメンバーにとっては詳細を把握するのが難しい状態です。

そこで行ったのが、PHP Debugbarに情報を追加する拡張です。

PHPを使っていない方に説明すると、PHP Debugbar＝VueやReactのDevToolsのサーバー版と考えていただくと良いかもしれません。他の言語でも似たようなものがあると思います。これは、例えばリクエストにかかった時間やリクエストの間に実行されたSQLクエリ、リクエストがどのコントローラーのどのメソッドに入ったのか、などを表示してくれる機能です。

私たちは、こちらにAWSでのリクエストを表示するようにしました。



例えば、DynamoDBへのクエリがあるページだと、どのテーブルに対してどんなクエリでどんなレスポンスが返ってきたか、が画像右上の「aws」に表示されるようになっています。AWS SDK for PHPにはミドルウェアの仕組みがあり、開発環境の場合はDebugbarに情報を投げるロジックを追加しています。

これによって「こんなテーブルにアクセスしているのか、意外といろんなことをやっているんだな」とか、ジュニアのメンバーから「システムの動きがより理解しやすくなった」という声をもらいました。

メンバーのスキルアップを目指し情報共有も改善

櫻田：次は情報共有の改善というカテゴリーです。「それは開発生産性に関係あるか？」と思われる方もいらっしゃるかもしれませんが、メンバーのスキルアップのスピードを上げることも開発生産性の向上だと考えています。

最初にお話しするのは、ポストモーテムの〇〇化についてです。ポストモーテムをご存じない方に説明すると『​​SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム』という本で提唱されているもので、インシデントや障害発生後に、何が起きたか、なぜ起きたか、どう防ぐかを振り返る分析手法です。責任追及ではなく、システムと組織の改善に焦点を当てるという特徴があります。

弊社ではインシデントがあった後にNotionにまとめて全エンジニアが見られるように共有しているのですが、あまり読まれていないという課題がありました。障害対応に当たったメンバーや問題となるコードを作成した人はポストモーテムに実際に参加しているものの、そうではないメンバーは前提知識やコンテキストが不足していて、読むハードルが高かったのだと思います。

しかし「障害対応からしか得られない栄養がある」という名言がありますし、私としては実際に対応した人でなくともポストモーテムの資料などから少しでも栄養にしてもらいたいと考えていました。

そこで考えたのが、絵本にしてみるというアイデアです。絵本や寓話は教訓を伝えるのに適していますし、数か月前からChatGPTの画像生成がすごいと感じていたため挑戦してみました。

今回は「友達がたくさんいる大口アカウントが先着順のキャンペーンを行い、負荷が増大した」というシチュエーションで作成した絵本を紹介します。



一番左の画像が1ページ目です。ペンギンで描けと指示したわけではないのですが、なぜか最初にペンギンが出てきたため、2ページ目からはペンギンで描くように指示しました。

2ページ目では、大量の配信と先着順でたくさんのボタンが押されて、反応が来ないという状況になっています。3ページ目では、弊社のSREチームが通常ではありえないようなスピードのリクエストを観測しました。4ページ目では、サーバーをスケールアウトしている様子を表しているのですが、なんだか味わい深いイラストが誕生しました。

このような取り組みを行うことで、ジュニアメンバーからは「内容がよく分からず敬遠していたものの、とりあえず絵本部分だけ読むようになった。絵本がかわいい」と言ってもらえました。

中堅メンバーからは「自分が読むべきかどうか、絵本部分だけをさらっと見て、知見がありそうだったら読むという形で読めるようになった。絵本がかわいい」という意見があがりました。

SREメンバーからは「AIに資料を喰わせることで資料としてのレビュー工程も自動的に挟まる。AIに絵本を書いてもらっているだけなので、コストが大きく増えることもなくやりやすい。絵本がかわいい」と言っていただきました。

次に、複雑な仕組みを体で理解した事例についてもお話しします。

弊社のプロダクト「Liny」は大規模なメッセージ配信トラフィックを扱っており、「この処理は複雑すぎてコードが追えない」という状況が発生することがあります。多くの企業で似たような状況が発生しているのではないかと思います。

弊社の場合は配信モジュール部分が巨大で、当初からある機能に継ぎ足しを重ねて、負荷がかかるたびに分散処理や優先処理などを追加してきた経緯があります。しかも、“オレオレキューイングシステム”で、複数のRedisクラスターにまたがってるため、理解の難易度が高いモジュールです。

そこで、その理解を助けるために「人間配信モジュールになってみよう」という取り組みを行いました。これは名著『レガシーコード改善ガイド』の第17章にある「白紙のCRC」を参考にした取り組みです。

具体的には物理的なものを用意し、配信メッセージを紙で、優先度の仕組みを封筒、キューイングするRedisクラスターなどをレターボックスで表現します。人間はコード側で、PHPのモジュールやデータベースなどを担当します。



これは実際に行った時のキャプチャーです。実際に体を動かすことで、若手メンバーから「複雑だという気持ちは変わらないものの、全体像の取っかかりが楽しく掴めた」「難しいものを説明する時にこのようなやり方があるのかと勉強になった」という意見をもらいました。

機械にできない部分は人の力で泥臭く改善

櫻田：最後は、PR管理の人間ボットについてお話しします。こちらは、2025年2月に行われた「Developers Summit 2025」に弊社のDevOpsチームの島田が登壇した際の発表内容の一部と重複しますがご了承ください。

実際に作業をするなかで「すごい取り掛かり中のPull Requestがたくさんある」という状態になることはありませんか？弊社のチームでも、一時期100件以上のPRが滞留し、中にはコンフリクトが発生して手がつけられないものもありました。

PRが多いと「コンフリクトが頻発する」「コンテキストスイッチの負荷が積み重なってしまう」という課題が発生します。

当時、弊社のエンジニアは25名以下で、1人あたり最低4つ計100件ほどのPRがある状態でした。この背景には、弊社の文化的な側面も関係していると思います。ボトムアップな組織文化でエンジニアが自主性を持って開発できるものの、着地できず放置される、あるいは思ったより難しいと感じた時に放置されることがありました。その結果、PRが多いことを誰も気に留めない状態になってしまっていたのです。

そこで解決策として、PRを古い順番に並べ、作成した人と一緒に作業する時間を設定しました。入れられるものは検証してマージし、手がつけられないものはクローズしてやりたいことリストに戻すと。これを10回ほど繰り返し、100件から40件程度に減らすことができました。

しかし、これだけではその場しのぎになってしまうため、再発防止として「人間ボット」という取り組みを行いました。

最初はWIP制限として同時進行の作業を制限しようかと思いましたが、これはやめました。例えばボットが「PRが6つありますよ。消してください」と言っても、おそらくオオカミ少年になるだろうという懸念があったからです。また、自動化して6件目が出た瞬間に閉じることも考えましたが、障害対応中などにそんなことが起きたら大変なことになってしまいますよね。制限するのではなくサポートしようという考えから、人間ボットという取り組みを行うことにしました。

やることはシンプルで、しばらく進んでいないPRを見つけたら、作成者に声をかけて解消の手を打つということを週1でボットのように繰り返していきました。

具体的な問題と解消手段はこちらの通りです。



「また来たよ」と思われることもありましたが、愚直に取り組んだ結果、レビューを優先してコンテキストスイッチを減らすという文化が根付きました。

現在は、PR数が爆発することなく運用できています。副次的な効果として、PRの総数が少なくなったおかげで私やリードエンジニアが先に目を通すことができるようになったのも嬉しいポイントですね。

このように、機械に任せられない部分で人間が泥臭く行動していくことも、大切な生産性向上の活動だと考えています。

「めんどくさい」を原動力に開発生産性を向上していく

櫻田：番外編として、今回のプレゼン発表の原稿作成で感じた「めんどくさい」を解消するために取り組んだことについても紹介します。

何をしたのかというと、プレゼンの時間管理やスピーカーノートの管理をするために、AIにGASをつくってもらいました。



左上にプレゼンのカテゴリーIDと想定時間を書いておきます。そうすると、GASが作成した「時間配分をチェック」ボタンを押すだけで、時間配分が表示されます。



緑色の「全スクリプトコピー」というボタンもつけて、スピーカーノートを全てまとめて1つの文章にしてコピーできるようにしました。これにより、目安の時間やラップタイムをスピーカーノートで管理できるだけでなく、ChatGPTやClaudeに推敲を手伝ってもらうことができます。先にスピーカーノートを作成して、スライドの構成について相談することも可能です。これは非常に使いやすかったので、今後も活用していこうと思っています。



まとめます。本日お話ししたものの中には、AIを使ってつくったもの（絵本、Terraformのモジュール、最後のプレゼンの効率化ツールなど）も含まれます。「毎回このコマンドを打つのが面倒だな」とか「この作業を自動化できないかな」と思ったら、AIと一緒に改善してみてはいかがでしょうか？

現段階で「めんどくさい」と感じられるのは人間だけです。めんどくさいと感じるハードルを下げて、その感情に敏感になっていければと思っています。

私がOh My Zshを参考にしたように、普段使っているツールからもヒントを得られることがあるはずです。私たちもまだまだ改善したいことがたくさんあります。一緒に日々の仕事をもっと楽にしていきましょう。

最後に、マウス操作が面倒な方にはVimがお勧めです！

アーカイブ動画も公開しております。こちらも併せてご覧ください。

※ご視聴には登録が必要です