smarthr_eventreport_2025/1/15_fv

マルチプロダクトな開発組織で『開発生産性』に向き合うために試みたこと

## 既存事業の組織改善として、“学習する組織”を目指す
__古家__：「開発チームから始める『学習する組織』に成長するための取り組み」というタイトルで発表させていただきます。古家 大と申します。PharmaXに入って3年ほどになり、昨年からEMを担当しています。

PharmaXは、「かかりつけの先生がそばにいる安心を」というビジョンを掲げ、toCの医療サービスをつくっているスタートアップです。かかりつけ医療ブランドYOJOの1つのプロダクトとして、オンラインYOJO薬局を開発・運営しています。

今PharmaXでは事業横断のEMとして、エンジニア組織全体の成果最大化にコミットしています。今日は、既存事業の組織改善に取り組んできた話をします。伝えたいことは、学習する組織の考え方はとても良いものだということ。今回は開発チームの事例ですが、他のチームでも使えますし、個人の思考ツールとしても非常に便利だと思っています。
![pharmax_eventreport_2025/1/15_middle_h2-1-1](//images.ctfassets.net/ngrpflsbp3rq/65sEQfAtiDtfylAgtNeWWv/e5a886b0f97800bae67f2d2f6194c99c/Frame_178.png)

__古家__：私がチームに入った当時は、別のチームで新規事業を検討しているときで、プロダクトオーナーが忙しく、チームのなかにあまりいない状況でした。かつ、チームはまだ自律できておらず、チームとして今後何をやっていけばいいのか、方針が見えていませんでした。

もともと理想としては、高速に仮説検証を回せるプロダクトチームを目指していたのですが、現実とのギャップが激しいので、まずは開発チーム単体で良い状態にするところから目指していくことにしました。

開発チームの定義は、よくあるクロスファンクショナルチームではなく、完全にファンクショナルチームにしています。これは、まずチームづくりの難易度を下げるために、意図的にエンジニアのみに絞りました。のちのち9人以下のクロスファンクショナルチームをつくりたかったので、一旦エンジニアのみで5人以下の構成にしました。
![pharmax_eventreport_2025/1/15_middle_h2-1-2](//images.ctfassets.net/ngrpflsbp3rq/6MFLpVMyuK69oKH6bLPb15/df3dc2144796e2fb93e6f2d4303e4f36/Frame_179.png)

__古家__：チームが良い状態とは、事業と人に関する成果を両立させていることだと定義しました。事業成果を出しながら、組織の持続可能性を高めているチームが良いチームだと、私は考えています。

事業成果を出しつつ、走りながらチームを変えていきたいと考えていました。そこで学習についていろいろ調べていたところ、最終的に『学習する組織』という本に行き当たりました。

『学習する組織』での学習の定義は、「望んでいる結果を出す能力を伸ばすこと」とされています。自分の欲しい結果は、開発チームを良い状態にすることだったので、このために必要な能力を学習していきたいと考えました。

この学習を継続的に実現している組織が、学習する組織です。まさに自分が求めていた組織の形はこれだと感じ、この組織論を実践していこうと決めました。
![pharmax_eventreport_2025/1/15_middle_h2-1-3](//images.ctfassets.net/ngrpflsbp3rq/64GN8LMFCOCN4s1rFaVjRR/14a5aef93433492f7712127e80dcf927/Frame_180.png)

## “学習する組織”の5つの学習領域と取り組んできたこと
__古家__：学習する組織を実践していくなかで、学ぶべき領域は5つあります。1つ目は、「共有ビジョン」。チームの目的や目指すべき理想像のことですね。まずは、このビジョンを立てるために動きました。最初にやったのは、自分たち開発チームが組織のなかで置かれている状況を理解することです。

開発生産性の図で表すと、自分たちはレベル1の生産性をアウトプットする存在です。開発の指標はさまざまありますが、プロダクト組織から見たときに興味があるのは、工数だけだよねということを認識しました。

ベロシティ、Four Keys、プルリク数といったものは、土台としてはすごく重要ではあるのですが、外部から見たときはあまり興味がないものだということを、はっきりさせた形になります。

結局、施策はリリースしないと上手くいくかわからないので、開発チームの役割はどこまでいっても工数を短縮して試行回数を増やすことでしかないと、改めてチームの目的に設定しました。
![pharmax_eventreport_2025/1/15_middle_h2-2-1](//images.ctfassets.net/ngrpflsbp3rq/2Ovv9v3OX0HtO1Dcla83wB/536998a36c4a6e643b6d4cbc6adf92dc/Frame_181.png)

__古家__：次は、「システム思考」ですね。これは、システムのように複数の項目の相互関連性を考えていくことです。これに関してはまず、開発生産性を高めていくために、DORA Core Modelという理論の図を理解することから始めました。

この図は、開発パフォーマンスとFour Keysには、非常に強い相関があることを示しています。そして、Four Keysだけでなく、技術的ケイパビリティもセットで高めていくことが必要だということがわかります。
![pharmax_eventreport_2025/1/15_middle_h2-2-2](//images.ctfassets.net/ngrpflsbp3rq/2F3tH9Wj4QcPw5bMkBrhT/68dba38b5a39c9a3b7773464ff6e6360/Frame_182.png)

__古家__：次に、技術的ケイパビリティを高めていくために現状の分析を行いました。現状を見ると、特にコード品質が低いことと自動テストがないことが工数に大きな影響を与えていると、エンジニア同士で議論して認識を合わせていきました。

この議論の結果をもとに、特に強化したい技術的ケイパビリティは、コード保守性、疎結合アーキテクチャ、テスト自動化の3つであると特定して、これを伸ばせばパフォーマンスが上がるはずだということが、チームとして見えてきました。
![pharmax_eventreport_2025/1/15_middle_h2-2-3](//images.ctfassets.net/ngrpflsbp3rq/1tzOh7k1pud02W8K5CCu1x/8c1b7c13f6bba48a49c12bcf0d24142a/Frame_183.png)

__古家__：次は、「自己マスタリー」ですね。これは個々のメンバーが自己研鑽を続け、成長していくことを指します。各々の自己マスタリーを高めていくために、目標設定について考えました。まず考えたのが、会社から求められている成果であるパフォーマンス目標と、その成果を出すために必要な能力を高めるマスタリー目標で分ける方針です。

パフォーマンスとしては、工数を短縮化していかなければならないので、レベル1生産性のFour Keysの目標値を決め、それを達成することをチームのパフォーマンス目標にしました。そして、Four Keysに影響を与える要素を高めることを、個人のパフォーマンス目標に設定し、それを達成することを目指していきました。
![pharmax_eventreport_2025/1/15_middle_h2-2-4](//images.ctfassets.net/ngrpflsbp3rq/1N1wGpWqrZsxkWRRIqAjK3/6f763dc014e270619a456446102da46a/Frame_184.png)
![pharmax_eventreport_2025/1/15_middle_h2-2-5](//images.ctfassets.net/ngrpflsbp3rq/76kwpw33PriHhmPclK4X9F/cbdff361683427bc4e91511ef301b888/Frame_185.png)

__古家__：マスタリー目標は、自分の能力を高めるためのものですが、目的はチームのパフォーマンスを高めることなので、その紐づけを要素分解し、予実が乖離するタスクに必要な能力を伸ばすと決めました。マスタリー目標の運用としては、1on1で目標設定と振り返りを実施して学習するループを回しています。

ただ、これをやってみたところ、1on1は目標の進捗確認以外にも話すことがいろいろとあるので、ループを回すにはスピードが遅いという気づきが最近ありました。なので、スクラムイベントのレトロで振り返りをして、スプリントゴールに入れるといったやり方のほうがいいかなと考えていて、次はそうしようと思っています。
![pharmax_eventreport_2025/1/15_middle_h2-2-6](//images.ctfassets.net/ngrpflsbp3rq/cAXYOuYCCTTSkZo6CrsDz/4dfa150077a164e9efe02a13f9d878de/Frame_186.png)

__古家__：自己マスタリーを高めるための支援は、チームとしてさまざま行っています。月1で技術系のLT会を実施して、知識共有の場を設けたりしています。振り返りと改善に関しては、現状1on1とレトロのKPTしかできていないので要改善かなと思っています。

他社さんでいろいろな振り返りを試している事例がありますが、それはこの自己マスタリー向上に効いてくる活動だと思っているので、弊社でもいろんな種類の振り返りをやっていきたいと思っています。
![pharmax_eventreport_2025/1/15_middle_h2-2-7](//images.ctfassets.net/ngrpflsbp3rq/3P5ykLalLSY3jaWNHhtDju/47436207bbb693d07aa53952e6902797/Frame_187.png)

__古家__：次は、「メンタルモデル」ですね。これは個人やチームが持つ世界に対しての捉え方のことです。デバッグ1つをとっても、シニアとジュニアで捉え方が違ったりしていて面白いです。これに関しては、チームのなかで良いメンタルモデルを同期するために、いろいろ試しました。

まず、チームに関わるプロセスやアーキテクチャの意思決定はADRで行い、チームで議論して決めるようにしました。それから、設計資料に関してはDesign Docsを別途用意してもらい、それをチームでレビューするようにして、設計の考え方をみんなに同期できるプロセスを整備していきました。

また、スクラム勉強会を定期的に開催して、完成の定義やストーリーポイントの基準など、チームのパフォーマンスに大きく影響を与えるルールを明確化し、みんなで同期しています。完成の定義は結構厳しいクオリティのものができて、最初は大変だったのですが、これによってかなりコード品質は上がってきています。
![pharmax_eventreport_2025/1/15_middle_h2-2-8](//images.ctfassets.net/ngrpflsbp3rq/3ZB5fbT2cLG0PlbUjmXs8V/5217ca39ee649bc78d2371b959de0acb/Frame_188.png)

__古家__：最後は、「チーム学習」です。チーム学習はビジョンに向けて、個人だけではなく、チームとして対話して成長することです。チーム学習では、スクラムの3つの柱が機能するように意識していきました。透明性、検査、適応の3つですね。

一番大事なのは透明性で、あらゆるスクラム活動のデータを可視化して、活動が健全に行われているかを常に見られるようにしました。単にデリバリーの状況だけではなく、技術的負債やバグの状況も把握できるようにしています。随時起票もしているので増えているように見えますが、コツコツと直すことができていて徐々に減っています。

データをもとに適応した例はさまざまあるのですが、工数を短縮して試行回数を増やすというビジョンに向けて、できる改善をいろいろと回しています。
![pharmax_eventreport_2025/1/15_middle_h2-2-9](//images.ctfassets.net/ngrpflsbp3rq/4tG6fnnPN7z2zxR4vcimxz/7df12805a6d2ef13a7aaca49ff417560/Frame_189.png)
![pharmax_eventreport_2025/1/15_middle_h2-2-10](//images.ctfassets.net/ngrpflsbp3rq/4A5fOpt5sJXqCxzCFm062m/1a89528278a15bfe2ca9dd465ff031db/Frame_190.png)
![pharmax_eventreport_2025/1/15_middle_h2-2-11](//images.ctfassets.net/ngrpflsbp3rq/7JRmGEjBkLCvNvjkeCw7W8/fed2d52d7d2acde4a0f2bcd838bcae1c/Frame_191.png)

## 道が見えないときこそ“学習する組織”が良い道しるべに
__古家__：このように、開発チームを良い状態にするためにいろいろと取り組んできました。結果として、事業の成果としてはプロダクトロードマップの遅れは基本的になくなり、開発生産性は「Findy Team+ Award」で受賞できる水準になりました。

人の成果としても、開発チームは自律して動けるようになって、自分はもうほぼ口を出していない状態になっています。良い状態にはかなり近づきましたが、まだまだ伸びしろはあるかなという状況です。
![pharmax_eventreport_2025/1/15_middle_h2-3-1](//images.ctfassets.net/ngrpflsbp3rq/6p8HE6MQYjnbTcS1lEqLdS/c376c3873addecc47fad9f365e986f0f/Frame_192.png)

__古家__：道が見えないときこそ、学習する組織や個人を目指していくことは、良い道しるべになると思っています。私のように1人目EMとして入って、会社に前例がなくて何をやったらいいのかわからないというときの、思考ツールとしても有用だと思います。ぜひ思考ツールの1つとして、試してみてもらえると嬉しいです。

今回やってみて感じたことは、学習は一度やったら終わりではないということ。大事なのはビジョンに近づいているかということで、何度も振り返ることが重要です。スタートアップだと、フェーズによっては短期的なパフォーマンスに集中しなければならないときもありますが、そんなときも学習の火を消さないように、しっかりビジョンに向かい続けることがとても大事だと思います。

ご清聴ありがとうございました。弊社は積極採用中ですので、ぜひカジュアル面談からでもよろしくお願いします。
![pharmax_eventreport_2025/1/15_middle_h2-3-2](//images.ctfassets.net/ngrpflsbp3rq/4ndWq9pv7TvOqpUiF8Noi6/2e76eb2baa99eb56a5fbacbc05592fc8/Frame_193.png)

pharmax_eventreport_2025/1/15_fv

開発チームから始める『学習する組織』に成長するための取り組み

upsider/stores_eventreport_2025/1/10_fv

その開発、本当に利益につながる？ エンジニアが考えるべき3つの問い

## “セキュリティの総合プロバイダ”網屋の事業と過去の開発体制
__福地__：「セキュリティメーカーにおけるオンプレ＆SaaSハイブリッド開発での生産性向上の取り組み」というタイトルで発表させていただきます。まず自己紹介です。私は株式会社網屋で、開発部のALog開発チームのチームリーダーをしています。

大学院では哲学を研究していて、新卒でこの会社に入りました。ログからサイバー攻撃を検出するSIEM製品の開発にバックエンドエンジニア、SREエンジニアとして携わった後、スクラムマスター、チームリーダー、プロダクトオーナーとして経験を積んでいます。チームビルディングや製品のコンセプトを考えるのが好きです。

本日のアジェンダとしては、事業紹介、私がエンジニアメンバーだったときの開発体制、リーダーになってからの開発生産性向上の取り組み、その成果、最後にまとめという順番でお話しさせていただきます。
![amiya_eventreport_2025/1/9_middle_h2-1-1](//images.ctfassets.net/ngrpflsbp3rq/4xoYs6fCiAdlV2g0NCJMI4/3daf022176175b07431dac75f867e6b5/Frame_132.png)

__福地__：まずは事業紹介です。弊社のビジョンは、「すべての人がサイバー攻撃のターゲットとなる時代に、すべての人に高水準のセキュリティを」というものです。セキュリティの総合プロバイダだと覚えていただけるとありがたいです。データセキュリティ、ネットワークセキュリティ、セキュリティサービス、セキュリティ教育と多角的に事業を展開しています。
![amiya_eventreport_2025/1/9_middle_h2-1-2](//images.ctfassets.net/ngrpflsbp3rq/4zG08Nu81PLZoOepUmANEB/41c11288099d95f57446a38517624ca0/Frame_133.png)

__福地__：そのなかでも、私が開発しているのはALogという製品です。これは複雑で難しいログデータを1つの場所に集約し、その集約されたログに対してクエリを投げて、サイバー攻撃を検出するというSIEM製品になります。

オンプレミスのファイルサーバー、ADサーバからクラウドサービスのアクセスログまで、幅広いログを収集することができます。
![amiya_eventreport_2025/1/9_middle_h2-1-3](//images.ctfassets.net/ngrpflsbp3rq/7H6OFi8x2eUoF12kgjpAbM/e5242574419479a8eb3edf081987e0d7/Frame_134.png)

__福地__：私が入った当初の開発体制がどういうものだったかと言いますと、オンプレとウォーターフォールというスタイルでした。開発製品はALogのオンプレミス版で、オンプレミスのWindowsサーバー上で常駐稼働するソフトウェアです。

1つのリリースに3ヶ月から6ヶ月かけて、この期間で要件定義、開発、テスト、リリースを実施。12人ほどのエンジニアに対して、2～3名のPMがチケットを渡してタスク管理を直接行っていました。

課題としては大きく2つで、アジリティとスケーラビリティです。より迅速にリリースしたいし、事業拡大やエンジニア増員にあたって、よりスケーラビリティがある組織構造にしたいという課題がありました。
![amiya_eventreport_2025/1/9_middle_h2-1-4](//images.ctfassets.net/ngrpflsbp3rq/1SAW141incHi9doqDJCCDr/c46321563942cee566367c55494bf85a/Frame_135.png)

## クラウド版リリースで“変わらないこと”と“変わること”
__福地__：そうしたなかで実施してきた、開発生産性向上の取り組みをご紹介したいと思います。そもそもなぜ生産性向上を考えるようになったかというと、きっかけはALogのクラウド版のリリースでした。

クラウド版を出すと何が変わるかというと、ビジネスサイドとしては、より迅速なリリースがこれまで以上に重要になってきます。オンプレ版ではユーザーがバージョンアップしていましたが、クラウド版では自動でバージョンアップされるので、どんどん迅速にリリースすることこそが正義だという状況になってきます。また、サブスクリプション型モデルへの移行もありました。

開発サイドとしては、クラウドネイティブの技術を採用していくというところがありました。これは別の機会に述べているので、もし興味があればご覧ください。

[▶サーバーレス × マルチアカウント構成で、統合ログ管理ソフトウェアを SaaS 化する](https://speakerdeck.com/fukuchi/saas-izing-siem-with-serverless-and-multi-account-architecture)
![amiya_eventreport_2025/1/9_middle_h2-2-1](//images.ctfassets.net/ngrpflsbp3rq/4TuokFdKVovTSj37yeN1S4/c923004cc5d18cfea326232f9acdcf8d/Frame_136.png)

__福地__：クラウド版を出すにあたって、変わらないことと変わることがありました。変わらないこと、つまりマネジメントのコアは、心躍るゴールを提供することと、指標をゲーム感覚でトラックしていくこと。大きくこの2つだと思っています。

ゴール設定については、「他より10倍いい」をゴールにしていて、今定めているゴールは「最速の検索性を持つSIEM」です。これは社内キックオフの資料で、社内ではA社製品のところに実際の製品名が入っているのですが、この一番メジャーな製品よりも60倍高速なサーチを実現しようと掲げています。

日々いろいろな問題に直面して大変なときも、綺羅星としてこのゴールを見つめて体制を立て直す。そういうことが、チーム全体でできるようにしようと思っています。
![amiya_eventreport_2025/1/9_middle_h2-2-2](//images.ctfassets.net/ngrpflsbp3rq/3fIWib17sAO0u9Kp8LWPGW/f7d59533cbfd5119cde5885afdea5b37/Frame_137.png)

__福地__：次に、指標との向き合い方ですね。リーダーになってスクラム開発を導入して、しばらくはベロシティを見ていました。ベロシティがいくつになったとか、最近減っているけど大丈夫かなとか、そうやって見ていたのですが、最近思うのはベロシティをトラックすることは重要ではないということです。

重要なのは値や推移ではなく、コミットしたスコープを達成しきれたかどうか。あるいは、スコープを達成しきるというモチベーションや責任感があって、経験を通して実際に達成しきる確率が上がっているかどうか。これらを重要視しています。
![amiya_eventreport_2025/1/9_middle_h2-2-3](//images.ctfassets.net/ngrpflsbp3rq/1aIK14cLnLzWF9uOD6OUKJ/cc879d45d609a668c6907740269b79a9/Frame_138.png)

__福地__：あとは、Four Keysですね。定量的指標のなかでも非常に広く流布しているので、それ自体をひたすら追い求めるというより、まわりのチーム、まわりの会社との距離を測って、チームの現在地を知るための指標として使っています。

例えば、自分たちはまだHighとMediumの間くらいだねとか、Eliteを目指すためには、テストのラインカバレッジが80%はないとデイリーデプロイは難しいよねとか、そういった会話をしています。
![amiya_eventreport_2025/1/9_middle_h2-2-4](//images.ctfassets.net/ngrpflsbp3rq/1GbpBhmcyxkG1xU3sZFXQG/babeaa2f853fda72d866d9f59ac226b4/Frame_139.png)

__福地__：指標は、なるべくゲーム感覚で楽しみながらトラックしていきたいと思っていて、プルリク王や収益botといったものをやっています。プルリク王というのは、プルリク数のランキングを週ごとやスプリントごとに投稿して、上位の人を称える仕組みです。

収益botは、ALogクラウドの売上と支出を報告するbotです。収益は、コストを削減することでダイレクトにエンジニアが数字に貢献できる部分なので、ここをゲーム感覚で楽しくトラックすることを心がけています。
![amiya_eventreport_2025/1/9_middle_h2-2-5](//images.ctfassets.net/ngrpflsbp3rq/4d6Lv6okl4GisTH3EyENNP/9f3c3cd13b36b23e7f9457b2d6e7d724/Frame_140.png)

__福地__：ゲーム感覚にするうえでの1つのポイントは、ハックされてもいいということです。例えばプルリクだったら、ものすごく小分けにすれば王になれますし、コストだったら、そのコストを発生させている仕様をやめたり変更したりすることで、削減ができてしまいます。

ただ、こういうある種のハックも、それ自体が価値を持つと考えています。プルリクを小分けにするのは価値があることですし、仕様についていろいろと考えを巡らせて賢い仕様変更を提示するのも、それ自体が非常に重要なことだからです。
![amiya_eventreport_2025/1/9_middle_h2-2-6](//images.ctfassets.net/ngrpflsbp3rq/5UtUEn7qXzgkZqwLLBJglC/6f26e79772f99b98fc9ba92407a42aec/Frame_141.png)

__福地__：次に変わることですが、これは大きく2つあって、1つはオンプレ＆SaaSハイブリッド開発だからこそ変わることで、チーム編成、ソースコード、CI/CDなどです。もう1つは、セキュリティカンパニーだからこそ変わることで、QAや品質についてのカルチャーといった部分です。

まず、オンプレ＆SaaSハイブリッドのチーム編成ですが、機能別にフルスタックのチームを組んでいます。ログを抽出して変換してロードするETLチーム。それを分析するアナリティクスチーム。全体としてのデザイン、あるいはある種のプラットフォームエンジニアリングを行うソリューションアーキテクトチーム。そして、より高度なセキュリティ機能を開発していくSIEMチームといった形に分けています。

フロントエンドとバックエンド、オンプレとクラウドなどで、チームを分断することなく融合させて、機能別に切ってマイクロサービスにフィットしたチーム構成をとっています。
![amiya_eventreport_2025/1/9_middle_h2-2-7](//images.ctfassets.net/ngrpflsbp3rq/5h8IlG9sjnuzBXU8GygQK0/5c562038f6a63f2e00b5903a7d8f36b3/Frame_142.png)

__福地__：ソースコードについては、オンプレとクラウドでドメインモデルを共通化しています。このようにCore、Cloud、OnPremiseとディレクトリが分かれていますが、ドメインモデルはCoreのドメイン配下に置いて、すべて共通化しましょうということですね。

あとは、ロジックも最低でもインターフェースレベルで共通化しましょうと。ちょっとリアルな話をすると、クラウド開発を急いだときにサービスレイヤーにAWSの要素が混入してしまうことがあったのですが、そういうことが万が一起こったとしても、インターフェースレベルでしっかり共通化することを最低限のラインとして掲げています。
![amiya_eventreport_2025/1/9_middle_h2-2-8](//images.ctfassets.net/ngrpflsbp3rq/3nzKz98SOOcKp0nVVI5oMZ/fe79cbf241e355ec4334a018277a676d/Frame_143.png)

__福地__：次にCI/CDですね。クラウドとオンプレで、Monorepo上でライフサイクルを分離しています。クラウドはスプリントごとのリリースになっていて、オンプレは約2ヶ月ごとのリリースになっています。そのため、リリースフローも異なります。

クラウドの場合は、featureブランチごとにterraform apply→destroyをしつつ、開発者が開発していく。mainブランチにプルリクがマージされたら、それをトリガーにステージング環境に自動でデプロイ。OKとなってリリースタグを打ったら、それがトリガーになって本番環境にデプロイされます。

一方でオンプレの場合は、featureブランチごとにローカルで開発者が開発して、mainブランチへのマージをトリガーにパッケージをビルド。オンプレの場合は入念にテストを行って、それにパスした最新版をリリースし、タグを打つ。こういったフローになっています。
![amiya_eventreport_2025/1/9_middle_h2-2-9](//images.ctfassets.net/ngrpflsbp3rq/5KF7olJjXVI97AcDoJJ7s8/83da8ef8f9f44f3560c2333bba0d3ba0/Frame_144.png)

__福地__：続いて、セキュリティカンパニーだからこそという部分では、やはりQAが大事です。QAチームは、各機能チームに1メンバーとして関わりながらも、QAチームとして縦の情報共有を行う仕組みにしています。

テストもUTレベルはソフトエンジニアで行いますが、ログロストしてしまうとか、コストがすごく跳ねてしまうとか、そういうビジネス的にクリティカルな項目については、QAエンジニアがテストレビューに入って実施まで行っています。
![amiya_eventreport_2025/1/9_middle_h2-2-10](//images.ctfassets.net/ngrpflsbp3rq/3chbiP6yCb1r7hP18oLfr1/0281fdbc84ca83538597e3db777837d0/Frame_145.png)

__福地__：カルチャーとして重要視しているのは、攻めの品質意識を持つことです。品質責任というのは、絶対にバグを出さないことではない。誤解を恐れずに言えば、あくまでも「すぐに対応してすぐに直すこと」こそが品質責任なんだというカルチャーを意識的に明言しています。

バグを出したときは、どうしても保守的なマインドになってしまいがちですが、そうではなく「すぐに対応できてすぐ直せたからよかった」と捉えるようにしています。このすぐに対応してすぐに直すところを、いかに改善していけるかを重要視しています。
![amiya_eventreport_2025/1/9_middle_h2-2-11](//images.ctfassets.net/ngrpflsbp3rq/5wvbJrAwXSNs14BLpYvnqk/fb35893b71943fed22cadddef401114b/Frame_146.png)

## オンプレ＆SaaSハイブリッドでの開発生産性向上の成果
__福地__：成果として、こちらは半期ごとの指標ですが、追加のフィーチャー数が1.3倍に、リリース回数が1.6倍になりました。ALogクラウドの利用状況も順調で、月17.4億のクエリが投げられていて、3.7倍のサーチが行われています。また、コンピューティング処理も、月63.7万時間、4.3倍の処理が行われています。
![amiya_eventreport_2025/1/9_middle_h2-3-1](//images.ctfassets.net/ngrpflsbp3rq/64Ro7ufU2I8uC1RInHx7es/1bc26d036934002df41bc84d9e6f1ebe/Frame_147.png)

__福地__：それでは、まとめです。オンプレ＆ウォーターフォールという開発のスタイルから、オンプレ＆SaaSハイブリッドとアジャイルという組み合わせに変革して、開発生産性を向上させることができました。

その際コアになったのは、心躍るゴール設定をすることと、「他より10倍いい」をゴールに設定すること。そして、指標をゲーム化し、絶対視しすぎず楽しくトラックすることです。

また、オンプレ＆SaaSハイブリッドという特性は、フルスタックのチーム構成や、Monorepoでのモデルやロジックの共通化、CI/CDのライフサイクル分離といったところに反映しています。セキュリティカンパニーという特性は、QAが大事であるということと、とはいえあまり保守的になりすぎず、攻めの品質意識を持つところに反映しています。

以上です。株式会社網屋では、一緒に事業を成長させてくれるエンジニアを大募集しております。ご清聴ありがとうございました。
![amiya_eventreport_2025/1/9_middle_h2-3-2](//images.ctfassets.net/ngrpflsbp3rq/63sXvLUADJF73nhCPnuqP9/c870af547fe2e434eb45792aedb54fb7/Frame_148.png)

amiya_eventreport_2025/1/9_fv

セキュリティメーカーにおけるオンプレ＆SaaSハイブリッド開発での生産性向上の取り組み

## 動画の概要

課題だった開発の数値可視化や評価基準の不明瞭さに対し、ツールを活用してプルリクエストの量やレビュー時間を改善。社内のキャンペーン文化 を活かし、対決形式やインセンティブを導入することで、楽しみながら生産性改善を実現しました。定量的な成果としてプルリクエスト数やデプロイ頻度が大幅に向上し、定性的にもチーム内の一体感や主体的な改善提案が増加した取り組みについてお話しいただきます。

## 動画で学べること

- 開発組織の課題を 数値で可視化 し、生産性を評価・改善する方法
- Findy Team+ を活用したプルリクエスト数増加とレビュー時間短縮の具体的アプローチ
- ゲーミフィケーション を活用した対決形式やインセンティブによる生産性向上施策

### [動画を視聴する](https://share.hsforms.com/1yvc5nOtFTTKG6xSPFoeWswbymz5)
## スピーカー
__株式会社サイバー・バズ 執行役員：佐々木 空__

株式会社サイバー・バズ 執行役員。新卒入社後、複数のプロダクトのリードエンジニアを経験。VPoE兼EMを経て現職。組織構築や文化の醸成・浸透を推進する。

### [動画を視聴する](https://share.hsforms.com/1yvc5nOtFTTKG6xSPFoeWswbymz5)
## 視聴方法
---
- [こちらのフォーム](https://share.hsforms.com/1yvc5nOtFTTKG6xSPFoeWswbymz5)に必要情報をご入力のうえ、送信ボタンをクリックしてください
- イベント動画は無料でご視聴いただけます

## お問い合わせ
---
Findy Team+ マーケティングチーム
ft-event@findy.co.jp

なお、弊社向けの営業目的でのお問い合わせは[こちらのフォーム](https://form.run/@findy-corporate-site)よりお願いいたします。


T+award OGP PressKit 1 Organization Award (4)

【株式会社サイバー・バズ】執行役員 vs EMの 対決企画でデプロイ頻度を 2.8倍に向上

## 動画の概要

開発チームがスプリントゴールに「チームの状態」を設定し、チームの成長と成果向上を両立させる取り組みを紹介します。振り返り（Keep・Problem・Try）を通じて、タスクではなく日常の行動や習慣の変化に焦点を当て、チーム全体で継続的な改善を実践。デイリースタンドアップで進捗確認を行い、状態ゴールとプロダクトゴールを連動させることで、メンバー主体の問題解決と高い価値創出を目指す方法についてお話しいただきます。

## 動画で学べること

- スプリントゴールに「チームの状態」を設定し、チームの成長と目標達成を両立する方法
- 振り返り（Keep・Problem・Tryなど）を通じて、行動や習慣の変化を促す具体的な取り組み
- デイリースタンドアップでトライの進捗を確認し、継続的な改善を実現する仕組み
- プロダクトゴールと状態ゴールを連動させ、チームの生産性と一体感を高める方法

### [動画を視聴する](https://share.hsforms.com/1FI9Qb4zVSsuhGZNFuTBAegbymz5)
## スピーカー
---
__株式会社カケハシ　エンジニアリングマネージャー　笹尾 納勇仁

「沢山の埋もれた力を最大限に発揮できるようになれば、多くの人がもっと楽に成果を上げられる。」「チームが自律的に行動し無意識に成長できれば、最高のプロダクトやサービスを生み出せる。」の実現を常に目指すEM。スタートアップのVPoEとして組織システム構築の再現性を上げたのちに、これまでの経験を大きな社会貢献に繋げるためにカケハシに参画。EMになる以前はエンジニア兼マネージャーとして大手自動車会社のテレマティクス分野におけるWebアプリケーション開発や、開発・運用フレームワークの開発、アプリケーション配信プラットフォームの開発などに携わる。

### [動画を視聴する](https://share.hsforms.com/1FI9Qb4zVSsuhGZNFuTBAegbymz5)
## 視聴方法
---
- [こちらのフォーム](https://share.hsforms.com/1FI9Qb4zVSsuhGZNFuTBAegbymz5)に必要情報をご入力のうえ、送信ボタンをクリックしてください
- イベント動画は無料でご視聴いただけます

## お問い合わせ
---
Findy Team+ マーケティングチーム
ft-event@findy.co.jp

なお、弊社向けの営業目的でのお問い合わせは[こちらのフォーム](https://form.run/@findy-corporate-site)よりお願いいたします。


最新記事

マルチプロダクトな開発組織で『開発生産性』に向き合うために試みたこと

開発チームから始める『学習する組織』に成長するための取り組み

その開発、本当に利益につながる？エンジニアが考えるべき3つの問い

セキュリティメーカーにおけるオンプレ＆SaaSハイブリッド開発での生産性向上の取り組み

【株式会社サイバー・バズ】執行役員 vs EMの対決企画でデプロイ頻度を 2.8倍に向上

【カケハシ株式会社】スプリントゴールにチームの状態も設定する背景とのその効果

カテゴリ

最新記事

マルチプロダクトな開発組織で『開発生産性』に向き合うために試みたこと

開発チームから始める『学習する組織』に成長するための取り組み

その開発、本当に利益につながる？ エンジニアが考えるべき3つの問い

セキュリティメーカーにおけるオンプレ＆SaaSハイブリッド開発での生産性向上の取り組み

【株式会社サイバー・バズ】執行役員 vs EMの 対決企画でデプロイ頻度を 2.8倍に向上

【カケハシ株式会社】スプリントゴールにチームの状態も設定する背景とのその効果

.css-1uuptc0 svg{width:32px;height:32px;fill:#666666;stroke:#666666;}@media (max-width: 750px){.css-1uuptc0 svg{width:24px;height:24px;}}カテゴリ

その開発、本当に利益につながる？エンジニアが考えるべき3つの問い

【株式会社サイバー・バズ】執行役員 vs EMの対決企画でデプロイ頻度を 2.8倍に向上

カテゴリ