## ハイパフォーマンスなチームとは、どのようなチームか？
__湊谷__：本日は、開発生産性を上げながらビジネスも成長させてきたチームが、どのようなことをやってきたのかというお話をさせていただければと思います。ユビーの事業はtoCとtoBに大きく分かれていますが、toC向けのメディアサイトも運営しており、自分はそこでテックリードをしています。

チーム状況としては、プロダクトオーナーが1人、エンジニアが3人、デザイナーが1人、医者が1人というストリームアラインドチームを形成していて、ありがたいことに過去1年弱で事業指標を大きく伸ばすことができています。
![ubie_eventreport_2025/1/31_middle_h2-1-1](//images.ctfassets.net/ngrpflsbp3rq/4PAKuEejqGubOKyPsfb9Wr/56136188424076fdb31c54f5cf01bdf0/Frame_149.png)

__湊谷__：今日は、改めてハイパフォーマンスなチームとはどのようなチームなのかを考え直し、そこから自分たちがどういったアプローチを取ったり、気づきを得たりしたかを共有しようと思います。

そもそも一口にハイパフォーマンスなチームと言っても、競技や大会形式、ルールによって違うはずです。今回の「開発生産性Kaigi」は、スタートアップも1つの切り口になっていると思いますが、Webサービスのスタートアップはどのようなルールでやっているかと考えていくと、基本的にホームランダービーと似ていると思っています。

どういう意味かというと、ここで言うホームランというのは事業を大きく変化させるようなイベントのことで、あらかじめどうしたらユーザーが求めているものを作れるか、どうやったら大きく成功するかはわかっていないわけですね。
![ubie_eventreport_2025/1/31_middle_h2-1-2](//images.ctfassets.net/ngrpflsbp3rq/2OcrxSzwlSv1KDCL93RHu6/45e29c1631d8bdfcb9bc1fef3a4a0726/Frame_150.png)

__湊谷__：そのホームランを打てる確率をいかに高くできるか。これには、アイディアの筋の良さが重要になってきます。一方で、同じ制限時間内に何回バットを振れるかどうかも、重要な指標です。これを単純化すると、1週間に何回デプロイできるかといった指標になります。つまり、何回打席に立って、何回ホームランを打てるかというゲームだと思っています。

ただ、実際にはホームランダービーと違うところもあって、例えば1日で勝敗はつかないとか、オフシーズンがないとかですね。残念ながら平日は毎日開催されるので、長い時間をかけることも想定しなければならない、マラソン的な要素もあります。

また、1日だけ施策が大きく当たることにもあまり強い意味はなく、多くの場合、それをコンスタントに打ち続けられる体制づくりに価値がある。長い時間で見たときの、LTVのようなものが重要なゲームになっているといえます。
![ubie_eventreport_2025/1/31_middle_h2-1-3](//images.ctfassets.net/ngrpflsbp3rq/5VFb2qj0k8D3ixehjEHfrO/f8467cc33393904d8b1149fead6d1073/Frame_151.png)

__湊谷__：整理すると、Webスタートアップにおいては、いかにアイディアの筋をよくできるか、いかにデプロイの回数を高くできるか、いかに長く良い状態を続けられるか。このあたりを追い求めていくのが良いだろうと思っています。そして、それぞれの計測手法は世に出回っているものがあります。

例えばアイディアの筋は、どれくらい数字が跳ねたかというフィードバックを元に検証することが多いと思いますし、もちろんユーザーインタビューなどもあると思います。デプロイ回数は、バグのない正常なデプロイであるかも含めて、Four Keysで計測できます。いかに長く続けられるかは、チームの存続期間で測れるでしょう。このあたりは、僕らユビーもですが、世の中的にも計測できているチームが多いと思います。
![ubie_eventreport_2025/1/31_middle_h2-1-4](//images.ctfassets.net/ngrpflsbp3rq/pR7ojPRlOqiNMxxpiUF8o/1f05111f43c2beffb6890dead4bb29d7/Frame_152.png)

## チームが持つケイパビリティに着目し、計測する
__湊谷__：ただ、これらを計測したからといって、パフォーマンスが良くなるかというとそうではなく、では具体的に何をするとパフォーマンスが向上するのか。そもそもパフォーマンスが良くなるということは、チームは何かしらの変化をしているわけですね。

チームが何かしらのケイパビリティを獲得したから、パフォーマンスが良くなったと考える。逆に言えば、何も変わらないのにパフォーマンスが良くなることはないはずで、Webサービスにおいて放置していて良いことはあまりありません。

パフォーマンスを高めるためには、どんなケイパビリティを獲得すべきか計画したり、チームで目線を合わせたりすることが必要だと考えられます。なので、KPIやFour Keysを計測するだけではなく、チームがどういったケイパビリティを持っているのかも、ちゃんと計測することが大事だと思っています。
![ubie_eventreport_2025/1/31_middle_h2-2-1](//images.ctfassets.net/ngrpflsbp3rq/05XV6w4GuCaKSjDo14uai/4e7734ab6070636282b4962f85411edb/Frame_153.png)

__湊谷__：チームがどんなケイパビリティを持っているかについては、いろいろな考え方があると思いますし、チームが必要としているケイパビリティは何なのかについても、会社やチームの特性によって大きく変わってくると思います。

僕たちはというと、[DORAのCapability Catalog](https://dora.dev/capabilities/)を参考にして、その一部を抜粋したりアレンジしたりして、「これはこのくらいできたら、この点数をつけよう」という形で使っています。

僕たちのチームでは、定期的に3ヶ月に1回くらい集まって、点数をつけて見直す時間を設けています。右下に載せたのは、半年から9ヶ月くらいでの変化で、もちろん上がっている指標もたくさんありますが、なかには逆に下がっている指標もあります。

これは僕たちが、より高いレベルのものを求めるようになったということもありますし、あるいは知らず知らずのうちにないがしろにしてしまって、でも逆にそれを投資したことで別の何かを得ていることもあります。

このあたりを客観視して、自分たちが今どのケイパビリティを獲得すると、チームとしてパフォーマンスが上がりそうかをチーム内で共有し、日々のPBRなどに活かしていくことが重要なのではないかと思っています。
![ubie_eventreport_2025/1/31_middle_h2-2-2](//images.ctfassets.net/ngrpflsbp3rq/bsAfbdY2nswh3UY0kugiZ/bd6fdf2e401f5833c9c08bbcf89f0dfe/Frame_154.png)

__湊谷__：ケイパビリティを並べたなかでも、どの指標がより重要なのかという優先度を考えるときに、DORAが毎年出しているレポートがヒントになります。全世界を通したアンケートをもとにした示唆がまとめられていて、例えば疎結合アーキテクチャやコードメンテナビリティは他のテクニカルな指標に比べて、アウトカムへの相関が高いといったことが書かれています。

それを読むと、自分のチームでも体感値としては持っていたけど、やっぱり疎結合アーキテクチャは大事なんだなと改めてわかったり、コードメンテナビリティが高くなるようなリファクタリングをしようと計画できたりするので、ヒントとして活用できるといいと思います。
## 短期でチームを解散させない＆DevOpsをやっていく覚悟
__湊谷__：まとめです。Four Keysを計測することも大事ですが、同時にケイパビリティにも着目して、チームを強化することを考えていくことが重要だと思っています。これをやっていくうえでは、短期でチームを解散させないこと、DevOpsをやっていく覚悟を持つことが大切です。

短期で解散するチームは、長期的にケイパビリティを獲得していくところに対するインセンティブを失ってしまいます。なので、長い目で見てハイパフォーマンスチームを続けていくということを、チーム全体、あるいはチームを設計するマネージャー、組織設計のメンバーが正しく理解していることが重要です。

メンバーを安定させて、目的のもとに人を集めるのではなく、ハイパフォーマンスのチームにどんな仕事をさせるかを考える方が、パフォーマンスの高いチームを長く存続させることができると思っています。
![ubie_eventreport_2025/1/31_middle_h2-3-1](//images.ctfassets.net/ngrpflsbp3rq/5MewrkikSHPgmwgTGWroJp/5b0675a5f5e036430b6ff9e996c9ba84/Frame_155.png)

__湊谷__：また、DevOpsをやっていく覚悟に関しては、疎結合アーキテクチャやコードメンテナビリティを自分ごと化することですね。自分が欲しいものは自分でやっていくべきで、都度Opsチームのような他チームに依頼するやり方は、ちょっと違うかなと。できないならできるようになっていくというのが、チームとして強くなっていく道だと思います。

そして、作って終わりの仕事はないので、しっかりソフトウェアにオーナーシップを持つことも重要です。もちろん自分のチームだけで完結するものがすべてではなく、例えば疎結合アーキテクチャと言っても、自分が触っているサービスはあるマイクロサービスのサブセットだったり、あるいは単一の小さなマイクロサービスだったりします。

その歪みを解消しようとしても、1人で改修するのはなかなか難しい。自分のチームだけで完結するのが難しいものは、適切に他チームにパスを要求することも、ストリームアラインドチームとしては必要な動きだと思っています。

これからも、こうしたところに注目しながらチームを強化して、パフォーマンスの高いチームをどんどんつくっていければと思っています。ご清聴ありがとうございました。

ubie_eventreport_2025/1/31_fv

開発生産性を上げながらビジネスも30倍成長させてきたチームの姿

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ハイブリッド開発での生産性向上の取り組み

## 夜間や休日の救急診療、新たな選択肢「ファストドクター」
__小野寺__：本日は「Go GEMBA! ユーザーファーストで事業に寄り添う開発組織戦略」と題しまして、イベントテーマである開発と事業の接続という観点を踏まえ、当社の取り組みを一部ご紹介させていただきます。

最初に自己紹介です。ファストドクター株式会社でエンジニアリングマネージャーをしております、小野寺と申します。SIerやフリーランスなどいろいろやってきましたが、当社に来る直前はソフトバンクにいて、日本通運とのジョイントベンチャーで4年ほどCTOをしていました。

大企業のリソースやシナジーを活かしながら、スタートアップ的に不確実なものづくりにスピード感を持って向き合うといった形で、巨大な二枚看板を背負って大変貴重な経験をさせていただきました。退任後、技術顧問をしながら、当社ファストドクターに参画して現在に至ります。

では最初に、当社の概要についてご紹介させていただきます。代表は水野と医師の菊地で、カテゴリーとしては医療スタートアップになります。当社の事業についてですが、例えば夜間や休日に急に体調が悪くなったとき、考えるのは近隣の救急病院にかかるか、あるいは救急車を呼ぶかということだと思います。そんなときに、もう1つの選択肢として「ファーストドクターを使おうか」と想起していただくことを目指しています。
![fastdoctor_eventreport_2025/1/7_middle_h2-1-1](//images.ctfassets.net/ngrpflsbp3rq/1m9wOmc3xokxWx03hvC2ze/6192304eef95fe47e7e123a1cd988ccf/Frame_102.png)

__小野寺__：当社は全国の医療機関と連携して、夜間や休日など患者様が医療にアクセスしにくいシーンで、当社の医療プラットフォームに登録いただいている医師がご自宅へ往診に伺ったり、オンライン診療を受けたりできるサービスを提供しています。

会社全体では、このような事業を展開しております。救急往診・オンライン診療事業。BtoBtoCの事業として、クリニック様の夜間のオンコール体制を支援する在宅医療支援事業。また、急性症状だけでなく、メンタル不調の患者様向けのメンタルヘルス支援事業なども提供しています。
![fastdoctor_eventreport_2025/1/7_middle_h2-1-2](//images.ctfassets.net/ngrpflsbp3rq/2vYIRAA9pltCJIal6B0pd9/36e93f653234da44c8928680b5f3019e/Frame_103.png)

__小野寺__：自治体との取り組みも少しご紹介します。患者様から119番通報があった場合に、結果的に救急搬送が必要なほどではない軽症の患者様であることも多くあり、その分本当に救急車を必要とする重症患者を搬送できないことが大きな問題になっています。

そこで、通報があったときに当社のサービスが間に入って、医師によるトリアージを行い、「その症状であれば、救急車を呼ぶほどではないですね」とか、「朝まで待っていただいて、落ち着かなければ近隣のかかりつけ医を受診してください」といったアドバイスを行います。その結果、旭川の事例では、軽症の患者様の搬送の抑制に44%貢献した実績があります。

ファストドクターといえば、コロナで有名な会社だよねと言っていただくことも多くあります。実際、コロナ禍においては全国平均で救急搬送が増加しましたが、ファストドクターと連携いただいた自治体では、むしろ低下したという実績があります。
![fastdoctor_eventreport_2025/1/7_middle_h2-1-3](//images.ctfassets.net/ngrpflsbp3rq/3aUPbqlDXSREfRuVTddlvU/a0e9d149a9e75d6e39900fa04f35c393/Frame_104.png)

__小野寺__：また、在宅医療では、夜間の対応をお任せいただくことで、クリニック様の夜間の負担を軽減。患者様から見て医療へのアクセスが24時間途切れないように、協力体制を築いています。現在は約400の医療機関と提携しており、全国に約95万人いる訪問患者のうち約10%は、ファストドクターにて夜間や休日の対応を行っています。
![fastdoctor_eventreport_2025/1/7_middle_h2-1-4](//images.ctfassets.net/ngrpflsbp3rq/1hz57lf9mlzwTt6rvqwhB1/ec1de4991a509c2d03988cfe94d01280/Frame_105.png)

__小野寺__：サービスの紹介は以上になりますが、代表が起業家ランキングで1位を受賞するなど、当社の取り組みは各方面でご評価いただいております。
![fastdoctor_eventreport_2025/1/7_middle_h2-1-5](//images.ctfassets.net/ngrpflsbp3rq/5fTq3bg3rPXGeN4ThDcNPS/2699711c9bc0be8ed28feab5ebada17e/Frame_106.png)

## 答えは常に現場にある。強く根付く「Go, GENBA」の精神
__小野寺__：今回のイベントテーマである「開発と事業の接続」という観点で、当社ならではと思う取り組みをご紹介させていただきます。当社に強く文化として根付いている「Go, GENBA」という精神についてです。

これは往診の業務の流れを示したものです。例えば患者様から体調が悪いというお問い合わせをいただいたら、当社のメディカルコールスタッフが症状をヒアリングして、医師によるトリアージが行われ、往診に伺うのが適当だと判断されたら、中央管理室が往診に伺う医師やドライバーを差配します。

そして、実際に医師がご自宅に伺って診察を行い、必要があればその場でお薬を処方します。その後、医療事務スタッフがカルテをもとに算定をおこない、患者様や保健機関への請求をおこないます。また、特に経過観察が必要な患者様に対しては看護師チームがアフターフォローを行うこともあります。当社では、自社で医薬品の物流倉庫も持っており、このような一気通貫したサプライチェーンを持っていることが特徴です。
![fastdoctor_eventreport_2025/1/7_middle_h2-2-1](//images.ctfassets.net/ngrpflsbp3rq/2cOaR3NT25bh6M4YqmfxtV/1162aa54c4d96a380581b55b49e79799/Frame_107.png)

__小野寺__：これが他社の医療ベンチャーと比較したときの当社の特徴であり、人や物がリアルに動く、「リアルオペレーション」が最大の強みです。ただ、リアルゆえに非効率な部分も潜在していて、そこをテクノロジーの力で寄り添って効率化、省力化していきたい。リアル×デジタルの相乗効果を発揮したいと考えています。

ですが、デジタル化を進めるなかで、思ったより作った機能が使われないとか、本質的にユーザーの価値を解決できていないとか、自己満足な機能を作ってしまうとか、そういったことが往々にしてあると思います。

例えば、医師が診察結果を入力するカルテをAIで自動化したり、項目を減らして簡略化したりすると、医師には喜ばれるかもしれません。でも、後工程に控える医療事務にとっては、必要な項目が入力されておらず、患者様や医師への確認が増えてしまった。このように、デジタル化が全体最適を歪めてしまうことがあります。
![fastdoctor_eventreport_2025/1/7_middle_h2-2-2](//images.ctfassets.net/ngrpflsbp3rq/1YjOqP6naO8n9fpJ8pif6Z/b3126ec3a81e8fc02383dc93490231f3/Frame_108.png)

__小野寺__：いたずらなデジタル化を抑制したいけれど、それがとても難しい。そんな開発組織あるあるだと思われる潜在的な課題に対して、課題解決に寄与していると私自身思うのが、当社に文化として根付く「Go, GENBA」という精神です。当社には5つの価値基準がありますが、今回はその1つである「Go, GENBA」をピックアップします。
![fastdoctor_eventreport_2025/1/7_middle_h2-2-3](//images.ctfassets.net/ngrpflsbp3rq/5AyiCa19oWAg2uGXq6qYqu/eaa46e59a2e25fc769dd2dc1a0384287/Frame_109.png)

__小野寺__：当社には、実際の現場をいつでも体験できる制度があります。例えば、実際にメディカルコールスタッフとして患者様からの電話を取ったり、医師や看護師の往診に同行したりすることができます。

自分だけではなく、仲間たちが現場に行った体験も「こんな気づきがあって、こういうところを改善できるんじゃないか」といった内容とともに、社内のコミュニケーションツールで共有されます。

これは入社時の研修カリキュラムの1つとして定着していて、私も受けましたし、エンジニアを含む社員全員が「Go, GENBA」を肌で体感しています。希望者はいつでも研修を受けられるので、忘れないように定期的に受けている人もいます。
![fastdoctor_eventreport_2025/1/7_middle_h2-2-4](//images.ctfassets.net/ngrpflsbp3rq/5geM2ODXij8rtgk3lfTBo3/35189cebee8ca17fcddcfa850df40d5d/Frame_110.png)

__小野寺__：エンジニアから見た、「Go, GENBA」の意義をまとめてみました。まず、月並みですが、日々の開発業務に対する「主体性」や「自律性」は間違いなく育まれると思います。当社のサービスは、目の前に救いを求める患者様がいて、そこに手を差し伸べるようなサービスですので、実際に現場に行くことで、ダイレクトな手応えがすごく感じられます。

それから、「もっとこうしたい」という、開発現場からのボトムアップも活性化されていると感じます。机上で考えているよりも、やはり百聞は一見にしかずで、一次情報にアクセスする大切さを身にしみて感じられますし、ユーザーファーストで考える癖がつきます。

今回のイベントタイトルでもある「開発生産性」を向上することを考えるとき、チームのトポロジーを整えたり、コードレビューの効率性をはかったり、デリバリーの頻度を上げたり、そういったテクニック的なところに目がいきます。ですが、エンジニアの精神的な部分、目に見えないモチベーションも、間違いなく生産性に寄与していると感じています。
![fastdoctor_eventreport_2025/1/7_middle_h2-2-5](//images.ctfassets.net/ngrpflsbp3rq/6Im1vkkhrhz9UYsoSC0qOo/848dbf48512bcf811f17a93d09b356ee/Frame_111.png)

__小野寺__：また、当社にはドメインエキスパートが多く存在します。医師や看護師、薬剤師、医療事務といった、その分野のエキスパートの方が豊富にいて、それも一次情報といえば一次情報で、プロセス全般にドメインの知識をインストールしてくれます。

会議体を整えて、そういう方々とのコミュニケーションを設計をしており、これがプロダクトやチームの価値を底上げしてくれていると感じています。これによって担当領域に壁をつくらず、例えばセールスから開発に「これお願いね」と丸投げするような感じではなく、みんなが当事者意識を持ってグラデーションで関わり合う感じになっています。
![fastdoctor_eventreport_2025/1/7_middle_h2-2-6](//images.ctfassets.net/ngrpflsbp3rq/6HZNeRjCbTcDu3VDjx4pxB/cd60c3752c5d2246d6727f5cc32dd2c5/Frame_112.png)

__小野寺__：もう少しだけ開発の事業との接続という文脈でお話しすると、開発と事業が相互に染み出すことを大事にしています。開発から事業に染み出すことは、「Go, GENBA」やドメインエキスパートを活用して、当事者意識でしっかり考えられています。ボトムアップでの改善要求が積極的に行われ、トップとボトムのコミュニケーションが活性化されていると感じます。

それだけではなく、事業から開発に染み出す取り組みもしています。例えば、ローコードツールの積極的な活用です。これは事業側がいちいち開発に依頼しなくても、プロトタイプをサクッと作ってPoCを行えるというような染み出し方ですね。

また、当社の特徴的なものとして、DataChampionの設置も挙げられます。DataChampionとは、各事業部のデータに一番詳しくて分析できる人のことです。事業側がMySQLを叩いたりダッシュボードを整えたり、データの扱いに慣れることによって、事業の改善スピードを向上していきます。そして、開発側のアナリストチームは、AIやMLといった高度でテクニカルな知見が要求される業務に専念する。こういった染み出し方もしています。
![fastdoctor_eventreport_2025/1/7_middle_h2-2-7](//images.ctfassets.net/ngrpflsbp3rq/374yy6Q0NiZv56O1PDQwB6/40b30f0420194882b92c832f792080da/Frame_113.png)

__小野寺__：それでは、まとめです。当社では、何より一次情報を大切にしています。これに勝るものはなく、「Go, GENBA」の精神を持って、事業と開発が分断せず、お互いに染み出すようにしています。現場を無視した自己満足なデジタル化には陥りがちですが、そうならないよう心がけています。

開発は常に当事者意識を持ち、患者ファースト、オペレーションファーストの視点を忘れずに事業に寄り添います。デジタル×リアルの相乗効果を発揮し、患者様と医療機関を総合的にサポートすることで、持続可能な医療プラットフォームを実現していきたいと思っています。
![fastdoctor_eventreport_2025/1/7_middle_h2-2-8](//images.ctfassets.net/ngrpflsbp3rq/7L8OmSA9rzvLahUtmewlhI/2e535e150f92d4f87c2bcb1fe6e70e8a/Frame_114.png)

__小野寺__：最後に、ファストドクターでは一緒に働く仲間を募集しております。右下は当社のCTOで、CTO協会の理事も務める西岡です。こうした日本を代表するプロダクトリーダーが率いる開発組織で、日本のど真ん中である医療の課題に挑戦したい、心を燃やして仕事をしたいという方をお待ちしています。ご清聴ありがとうございました。
![fastdoctor_eventreport_2025/1/7_middle_h2-2-9](//images.ctfassets.net/ngrpflsbp3rq/sJrLLCRXgiopCo43ml2iN/fb3f84446c997316c8d759418bd0aa10/Frame_115.png)

fastdoctor_eventreport_2025/1/7_fv

Go GEMBA! ユーザーファーストで事業に寄り添う開発組織戦略

## アソビューが展開するサービスとプロダクト組織
__服部__：「チームの壁をぶち破る！ 開発生産性と組織のダイナミズム向上」というタイトルで発表させていただきます。まずは簡単に自己紹介です。アソビューでVPoEをしている服部と申します。2016年にアソビューにバックエンドエンジニアとして入社し、2018年にベトナム組織のCTOを担当。その後、エンジニアリングマネージャーを経て、今年からVPoEをしています。

続いて、会社紹介をさせてください。アソビューは「生きるに、遊びを。」をミッションとして、遊び市場に特化したプラットフォームを展開している会社です。従業員に大事にしてほしいバリューとして、FOR YOU、PROFESSIONAL、ONE TEAMを掲げていて、このバリューをもとに人事制度など各種制度が組まれています。
![asoview_eventreport_2025/1/7_middle_h2-1-1](//images.ctfassets.net/ngrpflsbp3rq/33owiVWN9Lt67I1iuHqwyK/bf1a314d26c925b219b159ce8ba52611/Frame_50.png)

__服部__：サービスとしては、遊びの予約サイト「アソビュー！」を中心に、業務DXソリューション事業、ふるさと納税事業、ギフト事業など複数サービスを展開しています。

数字から見るサービス規模感としては、初めてサービスをローンチしたのは2012年で、今では20を超えるサービス数になりました。会員数は1,200万人、契約施設数は約1万以上、データベースのテーブル数は2,000を超え、ピークトラフィックは4,000rps。プロダクト部門の人数は今100名を超えていて、チーム数は17になっています。
![asoview_eventreport_2025/1/7_middle_h2-1-2](//images.ctfassets.net/ngrpflsbp3rq/7MhgDfU7mlePar08P9EkFG/99518b61a27a16c6822e3c6b4e491e36/Frame_116.png)

__服部__：プロダクト組織と事業の関わり方は、各事業ごとに事業部のコアメンバーがいて、営業やマーケティングのような機能は、各事業に横断的に携わっています。プロダクト組織も同様に横断的に携わっていて、いわゆるマトリクス型の組織構造になっています。

プロダクト組織の全体像としては、大きく分けてプロダクトエンジニアリング領域、プラットフォームエンジニアリング領域、組織開発領域があります。

プロダクトエンジニアリング領域では、各事業ごとのチームでプロダクト開発を行っていて、プラットフォームエンジニアリング領域では、データ基盤チームやSREチームが横断的に関わってくれています。組織開発領域のメンバーは、プロダクト組織の全体的なマネジメントを実施しています。
![asoview_eventreport_2025/1/7_middle_h2-1-3](//images.ctfassets.net/ngrpflsbp3rq/2LRm0ERGV7ZUJlsf5Tk2q1/61ad281ddf31e8fa6405ac141a220386/Frame_117.png)

## 生産性レベル別に行う開発生産性向上の取り組み
__服部__：今日は、チームを超えた活動の場を提供して、みんながリーダーシップを発揮できる機会を増やそう、という話をお伝えできたらと思っています。リーダーシップとはそもそも何かというと、アメリカの心理学者ストッグディル（R.Stogdill）は「組織化された集団の活動が、目標設定と目標達成に向かって努力するよう影響する過程」だと定義しています。

文言だけ見ると難しい感じがしますが、雑然としていた組織が目標に対して、前向きになるように影響する過程がリーダーシップだということですね。リーダーシップは一部の人が持つ特殊な能力だと思われがちで、「私は持っていない」と思う人もいるかもしれませんが、誰もが発揮できるものだと僕自身は思っています。
![asoview_eventreport_2025/1/7_middle_h2-2-1](//images.ctfassets.net/ngrpflsbp3rq/7LZytC4EiKWuAaCCKQZuIQ/dc30ba388861171fd43da7d7fdeb225a/Frame_118.png)

__服部__：今回は、開発生産性向上の取り組みのなかで、組織横断のリーダーシップが発揮された事例をお話ししたいと思っています。アソビューでは、開発生産性向上に取り組んでいます。背景としては、ユーザーへの価値提供スピードの最大化、組織拡大に備えた効率的な開発プロセスの確立、開発者体験向上を自ら行うことによる組織力や技術力の底上げといった狙いがあります。

[広木 大地さんの記事](https://qiita.com/hirokidaichi/items/53f0865398829bdebef1)にあった生産性レベル別の取り組みをしていて、実現付加価値生産性に関しては、PdM体制の強化を行ったり、期待付加価値生産性に関しては、工数モニタリングを行ったり、仕事量の生産性に関しては、「Findy Team+」を利用したFour Keysの向上を行ったりしています。
![asoview_eventreport_2025/1/7_middle_h2-2-2](//images.ctfassets.net/ngrpflsbp3rq/4ZMQtb0oBYtqLY7ypHY5aJ/49b9f75314b4ad6a4af182f09eb861fc/Frame_119.png)

__服部__：PdM体制の強化については、各プロダクトにPdMを配置したり、CPOの役割変更をしたり、あとはプロダクト戦略を明確化して、プロダクトの成長に寄与できるような体制に変えていっています。

工数モニタリングについては、変更のリードタイム以外にも、時間を割いている業務が皆さんあるのではないかと思います。例えば、採用活動や技術広報といったものがあります。そういった活動を可視化して、改善を目的とした工数モニタリングを行っています。
![asoview_eventreport_2025/1/7_middle_h2-2-3](//images.ctfassets.net/ngrpflsbp3rq/61J5UKxely6XZvYYDxbTVb/052c482bb3c93f551baa2e0fe26b4538/Frame_120.png)

__服部__：Four Keysの向上については、「Findy Team+」を利用して改善活動を実施しています。今年の7月から導入していて、1年前と比べてデプロイ頻度が8.5件増加したり、変更のリードタイムが約800時間短縮されたりと、改善が進んでいます。今回は、「Findy Team+」の全17チーム同時導入と、その改善活動のプロセスについてお話ししていきます。
![asoview_eventreport_2025/1/7_middle_h2-2-4](//images.ctfassets.net/ngrpflsbp3rq/6g5JNHApvmXAVDtOn7NLGh/dd24eaf637ca65240d5e1551d7d9e87a/Frame_121.png)

## 目的や責任を明確にする“役割の見える化”の取り組み
__服部__：「Findy Team+」を導入するとき、マネージャーやリーダーが導入に携わるのは負荷が高くて難しいという課題がありました。とはいえ、すでに契約していてコストがかかっている状態なので、できるだけ早く全チーム同時に導入を進めたい。そのため、新たな役割をつくり、そこにメンバーを任用をしていくプロセスを踏むことにしました。

アソビューでは、役割の見える化に取り組んでいます。目的としては、組織規模拡大に対応すること、組織構造に柔軟性を持たせること、一人ひとりの活躍や成長機会を最大化すること、変化に素早く適応できる組織をつくることが挙げられます。
![asoview_eventreport_2025/1/7_middle_h2-3-1](//images.ctfassets.net/ngrpflsbp3rq/6NQo1i7Hz3Q4lSzQfqLrFk/8858965d1cf3275c1e7678b7a26152e4/Frame_122.png)

__服部__：例えば、マネージャーという役割はどの会社にもあると思いますが、アソビューにおけるマネージャーと他の会社におけるマネージャーでは、おそらく役割のなかで持っている目的や責任が違うんですよね。

名称が一般的なものほど、個々の認識が異なって、ひとり歩きしやすくなると思っています。本来重要なのはマネージャーという名称よりも、その名称が持っている目的や責任で、これらを明確にすることが重要です。

そのため、アソビューでは役割に対して、目的、責任、領域などを定義しています。例えば、弊社のマネージャーであれば、メンバーと1on1をしたり、全社施策を浸透させたり、部門イベントの設計をしたりといった役割があります。こういったものを可視化することで、役割に対する認識の曖昧性を排除しています。
![asoview_eventreport_2025/1/7_middle_h2-3-2](//images.ctfassets.net/ngrpflsbp3rq/3zVIFpNT5gj0VGvTlRlhDd/564c0b9e47660bdbf277954902905200/Frame_123.png)

__服部__：弊社では、Holaspiritというツールを用いて役割の見える化に取り組んでいます。スライドの左側が、技術広報の役割を可視化したもの。右側が、SREの目的や領域、説明責任を定義したものです。

役割の見える化と任用によって、組織にはプラスに働くものの、メンバーにとっては負担が増えるのではないかと感じられる方もいるかもしれません。しかし、役割の見える化と任用は、メンバーの成長につながると我々は思っています。
![asoview_eventreport_2025/1/7_middle_h2-3-3](//images.ctfassets.net/ngrpflsbp3rq/6nSZJMoRgdc9xgsnpV1kHA/dbd24d5a7d1c273338a96f5e6f7747ea/Frame_124.png)

__服部__：デービッド・コルブの経験学習モデルでは、人は経験して観察し、それを概念化して実験するという、このサイクルを繰り返すことで成長していくとされています。役割を見える化して任用し、新しい経験をしてもらうことは、そのメンバーの成長につながるので、良い施策だと僕は思っています。
![asoview_eventreport_2025/1/7_middle_h2-3-4](//images.ctfassets.net/ngrpflsbp3rq/4vgJGmZcOKjE0wou23Nj7o/d82cbe01418f48a0671f44e9dbdd10cf/Frame_125.png)

## “委員会”の活動から、組織を超えたリーダーシップを発揮
__服部__：話は戻りますが、「Findy Team+」を導入するときに、開発生産性委員という役割を追加しました。開発生産性向上の取り組みを、チーム内で推進することに責任を持つ役割です。

この委員は全チームから1人ずつ、マネージャーやリーダーなどの呼称を持たないメンバーに任命し、かつそのメンバーはチームみんなで決めるというプロセスを踏みました。役割を見える化して、任用のプロセスを経ることで、取り組みの運用自体に責任感を持って実行してもらう狙いがあります。
![asoview_eventreport_2025/1/7_middle_h2-4-1](//images.ctfassets.net/ngrpflsbp3rq/6zuX6EfjuKcpFAYKKKEsgW/62a2a98e262582bb4a06966aaca23a45/Frame_126.png)

__服部__：彼らの各チームでの活動としては、プルリクレビューの遅延確認や、ミーティング分析による会議体の適正化などをしてもらっていました。「Findy Team+」は多様なデータの可視化がされているので、変更のリードタイムにおける施策を立案しやすく、チームの改善がすごくやりやすいツールだと我々は感じています。
![asoview_eventreport_2025/1/7_middle_h2-4-2](//images.ctfassets.net/ngrpflsbp3rq/3hbq3k0jrULR47ceHopvpV/032cb11716ce96092ae3092448a1c302/Frame_127.png)

__服部__：チーム横断の委員会での活動としては、全17チームから委員が集まって、各チームでの取り組みを共有したり、困りごとや悩みごとを共有したり、チーム横断で取り組まないと進めない課題の共有や相談をしたりしています。なかでも、チーム横断で取り組まないと進めない課題の共有や相談が、すごく重要だと思っています。

初期の委員会では、変更のリードタイムに直接影響しそうな施策の共有が多い状態で、これに関しては各チームの委員がリーダーシップを持って、施策を推進してくれていました。ですが、変更のリードタイムの向上がどんどん進んでいくと、直接影響しそうな施策は立案しづらくなってきます。

間接的に響くであろう前後のプロセスの悩みや、自チームだけでは解決が難しそうだったり、本質的な課題に気づけなさそうだったりする相談が増えてきた印象がありました。
![asoview_eventreport_2025/1/7_middle_h2-4-3](//images.ctfassets.net/ngrpflsbp3rq/5YGLaZ5ViOFhVUb8z2dINQ/b1993baef9a40b52b443629f130b557c/Frame_128.png)

__服部__：ここでの相談の1つが、組織を超えたリーダーシップが発揮されるきっかけになりました。委員会で上がってきた相談に、「アクティブなスプリントで実施しているタスクにおいて、プロダクトオーナーにSlack、ときにはミーティングで詳細を確認することがある。デイリースクラムに、プロダクトオーナーやデザイナーがいると進めやすい」というものがあったんですね。

これに対して、「もしかしたらバックログリファインメントなど、開発プロセスに改善点があるかも」と気づいたメンバーがいました。そのメンバーは認定スクラムマスターで、もともと社内でスクラム開発に関する勉強会を開いてくれていたのですが、この相談を受けて、座学だけでなくワークショップでスクラムチームをつくり、実際にスプリントを回して体感してもらいたいと提案してくれました。

その後、実際にチームビルディングを行い、スクラムトランプというスクラムを疑似的に体験できるゲームを実施。これらはすべて自主的に、かつ他チームの人を巻き込んで実施してくれていました。
![asoview_eventreport_2025/1/7_middle_h2-4-4](//images.ctfassets.net/ngrpflsbp3rq/1Ry60KSXY9MKp65NmQirBu/ce9db9346eff17c6ce742840490a2152/Frame_129.png)

__服部__：その他にも、一部チームのレトロスペクティブの資料を見て、改善できそうなところをコメントするなど、越境して他チームが良くなるための働きかけをたくさん実施してくれています。チームを超えた活動の場を活かして、リーダーシップが発揮された瞬間だなと僕は感じました。

アソビューでは、この開発生産性の取り組み以外でもみんなが活躍していて、全員の役割をHolaspiritによって見える化していることで、活躍自体が可視化されていると思っています。

役割には自分たちで決めたさまざまな名前がついていて、例えばSLOの番人、技術広報、IT統制指揮、重大インシデントコマンダー、Datadogコスト管理者など、それぞれにしっかり目的や責任があり、みんなが活躍してくれています。
![asoview_eventreport_2025/1/7_middle_h2-4-5](//images.ctfassets.net/ngrpflsbp3rq/7lGbMo3DvOsAtle4Ep1pVn/488fc0191ce1aee085d5f65310450b91/Frame_130.png)

__服部__：最後にまとめです。リーダーシップは、誰でも発揮できるものだと思っています。そして、役割を可視化して、目的と一緒に定義して任せて、メンバーのみんなに活躍してもらうことが重要だと思っています。

横断的な役割をつくると、組織全体を活性化しやすい動きが生まれるので、とても良いなと思いました。なので、たくさんメンバーに任せて、個人と組織を強くしていきましょう。ご清聴いただき、ありがとうございました。
![asoview_eventreport_2025/1/7_middle_h2-4-6](//images.ctfassets.net/ngrpflsbp3rq/2Ui1FszgtoMQ6wZX30SWrn/a11a16479515d5d4d49537cb1d989b85/Frame_131.png)

asoview_eventreport_2025/1/7_fv

チームの壁をぶち破る！ 開発生産性と組織のダイナミズム向上

treasuredata_eventreport_2024/12/26_fv

トレジャーデータ創業者が語る、売れるものをつくる力〜開発組織の価値をどう証明するか〜

## エンジニアの日々の活動を事業側に理解してもらう
__笹尾__：こんにちは、笹尾です。「誰も全体を知らない ～ ロールの垣根を超えて引き上げる開発生産性」というタイトルで発表させていただきます。僕は多くの人がもっと楽に成果を上げられる方法を探しながら、たくさんの埋もれた才能が最大限に発揮され、最高のプロダクトやサービスを生み出せる環境を目指して組織づくりをしています。

僕が所属しているカケハシは、「日本の医療体験を、しなやかに」をミッションとして事業を進めています。バリューには、高潔、価値貢献、カタチにする、無知の知、変幻自在、情報対称性の6つを掲げ、メンバー自らが体現できるチームを目指しています。そんなカケハシのなかで、僕たちのチームは「Musubi AI在庫管理」という調剤薬局で取り扱う医薬品の在庫を管理するプロダクトを開発しています。
![kakehashi_eventreport_2024/12/25_middle_h2-1-1](//images.ctfassets.net/ngrpflsbp3rq/3KJhLxYtWJZ0gv0sYP4GCn/124ac8a0baafd0c489325d252caa4a0f/Frame_76.png)

__笹尾__：さて、皆さんに質問です。エンジニアの日々の活動を、事業側に広く理解してもらいたいと感じていませんか？ 他のロールの方に、自分の業務のことをもっと理解してほしいと感じていませんか？

これは2023年9月、僕たち「Musubi AI在庫管理」開発チームが、エンタープライズセグメントへの導入を必死に模索するなか、プロダクトもチームも拡大していたころのことです。

大量の機能要望がリストアップされ続けているのに、一つひとつの規模が大きく見積もりすらできない。既存の仕組みでは実現できそうになく、実現方法の検討を進めなければならない。スケジュールの見通しは立たなくなっていて、エンジニアを増員するものの、目に見えて開発スピードが上がるわけではなく、現状維持でいっぱいいっぱい。一方で、一部のエンジニアは大規模なリファクタリングにチャレンジしているという状況でした。

そうしたなか、ある会議でカスタマーサポート(以下、CS)のメンバーが勇気を持って発言してくれたんです。「開発メンバーが、お客様のことをどこまで考えているのかわからなくなりました」と。僕はハッとしました。はたして僕たちは、事業やサービス、プロダクト、そして開発を理解しているのだろうか。そう思って、すぐにエンジニアを集めて、CSメンバーと会話する機会をつくりました。その名も、CSとエンジニアの温度感を合わせる会です。
![kakehashi_eventreport_2024/12/25_middle_h2-1-2](//images.ctfassets.net/ngrpflsbp3rq/6CNvqZ9HeRZydegDayUJob/b0a5e270ead7570b4d365e2e9579eedf/Frame_77.png)

__笹尾__：このとき、エンジニアから伝えたのは、僕たちがお客様のことを知りたがっているということ。それ以外は、CSの方が抱えている課題や不安、そして開発がどう見えているのかを丁寧に説明してもらう時間となりました。少なくとも、お客様第一であることの認識はできたと思いますが、そもそもの不安を生んだのは、開発プロセスだけに偏った関係性、コミュニケーションの歪みだったんです。

それまでエンジニアの多くは、PdM(プロダクトマネージャー)とだけ会話して開発を進めていました。だから、その後もお互いの「わかってもらえない」が起こらないように、しっかり目的を明示したうえで、CSとエンジニアの温度感を合わせる会を継続することにしました。
![kakehashi_eventreport_2024/12/25_middle_h2-1-3](//images.ctfassets.net/ngrpflsbp3rq/5Ic6yZbXwAwsbAm73cIlY9/64a21a751e313c3612279e8f1b41538c/Frame_78.png)

__笹尾__：この会で意識したのは、とにかく相手を知り、相手の仕事に興味を持つこと。困りごとやその背景を知ること。ただし、その場で要望を伝えて解決方法を即決しないこと。悩みを吐き出して、自分たちから小さな振る舞いを変えることで、少しずつ問題を解消すること。これらをこの会における目的として、最初に毎回確認したうえで進めていました。

この会は、スプリントレビューの場でCSメンバーとの連携が深まるまで、ずっと継続していました。結果として、スプリントレビューで前向きな意見や提案、感想をもらえることにつながったと感じています。さらにこの会を通して、エンジニアの活動をしっかりと伝える必要性に気づき、次の活動にもつながりました。
## 非エンジニアメンバーにわかりやすく継続的に伝えていく
__笹尾__：今からお伝えするのは、その活動の初回にエンジニアのメンバーが実際に行った、システム拡大に伴うリアーキテクチャの説明についてです。エンジニア以外のメンバーに理解してもらいやすいように、専門用語を使わず、日常で想像しやすいものに置き換えた説明が行われました。

システム自体を本棚に見立て、内部の状態はその中に収める本に見立てて説明しています。システムの立ち上げフェーズは、とにかく仮説検証することが大切で、堅牢なシステムは必要なく、機能も多くないんですね。軽くて安くて気軽に使える本棚があれば、本は綺麗に整理することができます。
![kakehashi_eventreport_2024/12/25_middle_h2-2-1](//images.ctfassets.net/ngrpflsbp3rq/3m04Sq93kUmGGaKdDnG0oI/94ef496b6600d8c3ef35fbc86d272a91/Frame_79.png)

__笹尾__：仮説検証が上手くいって、スモールビジネス市場への導入が始まっていくと、高い事業目標を見据えて、機能開発がどんどん盛んになります。本は本棚に収まらないこともありますが、システムの堅牢性はまだ要求されていないので、急いで今までと同じ本棚を用意して、ちょっと不便なことがあってもこれで十分かなという形で進めます。

ところが、エンタープライズへの導入となると話は変わります。お客様と約束したスケジュールに合わせて機能開発を進めますが、今までとは異なる要求が多々あります。これまでに見たことがない、サイズも形も大きく異なる本が一気に増え始めます。
![kakehashi_eventreport_2024/12/25_middle_h2-2-2](//images.ctfassets.net/ngrpflsbp3rq/440D2VX6UDAzdxS3Ac43dm/c036ea040276685120a15e711342310d/Frame_80.png)

__笹尾__：同時に、システムの堅牢性も求められます。今までの安くて軽い本棚の組み合わせでは、重みに耐えられないかもしれない。今のまま進んでしまったら、自分が本棚を壊してしまうかもしれないと、怖くて誰も触りたくない状態になります。本が収まらなくても、本棚が歪んでも、ただ崩れないようにするだけになってしまったら、そんなシステムは健全とは言えませんよね。
![kakehashi_eventreport_2024/12/25_middle_h2-2-3](//images.ctfassets.net/ngrpflsbp3rq/4RUsUYNehT3bAoNfp8dWii/1403f2ff69d38a68c4afc84d9651558f/Frame_81.png)

__笹尾__：それを防ぐためにはシステムを維持したまま、新たなシステム要件に合わせた形にする必要がある。今ある本棚とは別に、この先の事業成長に必要な、堅牢で拡張性に富んだ本棚を用意して、本を移動しなければならない。自分たちのシステムが市場に受け入れられたからこそ発生する、作業や課題があることを説明したんです。
![kakehashi_eventreport_2024/12/25_middle_h2-2-4](//images.ctfassets.net/ngrpflsbp3rq/2NXkCFftl51gqysnXIBvRa/3242ae380ad0d71c18122642a4d3384c/Frame_82.png)

__笹尾__：エンジニア用語を使わない比喩やメタファーの説明では、どれくらい伝わるか未知数ですが、この説明をした際、サポートデスクの方からは「理解しやすくて、エンジニアの大変さがわかった」と感想をいただきました。

ただ、このような説明をする際に気をつける点があります。それは、当たり前にならない伝え方をすること。例えば、日常のコーディングでリファクタリングをするのは当然ですね。コードを書いたら見直し、新たな機能を入れる前にリファクタリングから始める。この日常のリファクタリングを、業務終了時の机の片付けと一緒だと伝えることもできるでしょう。

ですが、そのとき置かれたフェーズによる問題を説明したいのであれば、この伝え方は適切ではありません。机の片付けでは、「当たり前のことができていないなら、エンジニアだけでやれば」と思われかねないからです。伝える内容はそのときに合わせて選び、今なぜこの内容を伝えるのかを工夫することが大切です。

そして、説明は継続する必要があります。人は受け取れるときに、受け取れる方法で、段階を経て情報を受け取ります。つまり、継続していくなかで、一方向の説明にならないように方法を変えながら、それぞれのタイミングで受け取ってもらいつつ、何回かの説明で徐々に理解を深めてもらう必要がある。組織としては、人の入れ替わりに配慮する必要もあります。
![kakehashi_eventreport_2024/12/25_middle_h2-2-5](//images.ctfassets.net/ngrpflsbp3rq/5f8J8FD95K4n1WO6wrJBkr/7647940610a10da9c9e6f2c63b7cf65f/Frame_83.png)

## 開発チームの内部でも起こるコミュニケーションの課題
__笹尾__：ここまで、開発チーム以外とのコミュニケーションの話をしてきましたが、似たような問題は開発チームの内部でも起こります。「Musubi AI在庫管理」の開発チームが、以前の分業化した体制で活動していたころ、見つけた課題に対して僕がいろいろな方と会話していたなかで、面白いことに気づきました。

フロントエンドのメンバーは「UIの状態管理が複雑で改修が難しい」と言っていて、バックエンドのメンバーは「APIの仕様が複雑で改修が難しい」と言っていて、デザイナーは「UIがわかりづらいから直したい」と言っていたんですね。僕は最初、それぞれ別の課題だと思って聞いていたのですが、実は全部同じ機能の同じ課題を指していたんです。

これは“群盲象を評す”状態で、視点が偏ると一部に固執してしまって、全体で見れば同じものだということに気づけない。こんな状態でプロダクトを良くすることは難しいですよね。
![kakehashi_eventreport_2024/12/25_middle_h2-3-1](//images.ctfassets.net/ngrpflsbp3rq/7orD8W4JyDpab4WQNocrZe/6e262a34ac210156b3bae83095a49c6d/Frame_84.png)

__笹尾__：そんなときは、やはり「集合！」です。そうして、フロントエンド、バックエンド、デザイナーの苦しみを共有する会が始まりました。この会でも、目的をしっかりと定義しています。苦しくても隠してきたこと、みんな知っていると思って放置してきたことを共有して、手助けしながら嫌なことを高速でなくすために協力する場です。

自分と同じ悩みを他の人も持っているかもしれないから、話してみる。ここではとにかく一緒にやれば解決できるかも、という感覚を大切にするために、ルールを設定しました。正論での争いを避けて、自分たちの成長と達成感のために、一旦ロールも無視してスキルや知識を投入する。この短い時間だけですべてを進めることはできないけれど、支援のきっかけをつくっていく。

ここで共有した課題のうち、その場で解決に向かえたのはほんの一部です。ただ、この流れによって、ロールごとのチームから、クロスファンクショナルなストリームアラインドチームに変化するなかで、メンバーの協力を得やすくなったと思います。
![kakehashi_eventreport_2024/12/25_middle_h2-3-2](//images.ctfassets.net/ngrpflsbp3rq/5VUWtBUA06KIXBBjft4o2O/e0796558910c3439694bf74884f35c0b/Frame_85.png)

## ロールの垣根を越えて、より高い価値を出し続けるために
__笹尾__：コミュニケーションが得意な人は、さっさと相手に合わせてコミュニケーションすれば済むと思うかもしれません。でも、僕みたいに人間関係やコミュニケーションが苦手な人は、そうもいかないんですね。

特にズレが大きくなると、会話自体が成り立たないことも多々あります。特にロールをまたいだ状態でズレると、成果にはつながりにくい。人は自分が想像できる成果には、より情熱やコストをかけることができますが、認識の差がある状態で成果を出すのは、他のコストがかかってしまうのでつらくなるんですね。

だから、ズレがあるときは焦らない。決め事がなくても、成果がなくてもいいところから始めて、相手が大切にしているもの、守ろうとしているものを感じてみたり、苦しみも知ったりしながら、前進したい意思を感じられるようにする。そうやって会話していると、共通の認識やメタファーが生まれるようになり、そこで初めて今まで想像できなかった成果を想像できるようになります。
![kakehashi_eventreport_2024/12/25_middle_h2-4-1](//images.ctfassets.net/ngrpflsbp3rq/6NekRoRdLzUmGX1xz13efp/805f964d08bcf9a7f4addff946ef2e96/Frame_86.png)

__笹尾__：だからこそ、時として求められないコミュニケーションにもチャレンジする必要があります。例えば、機能開発が山積みの状態でも、技術負債の解消やリアーキテクチャの会話を積極的にPdMとして、優先順位に組み込めないか確認していく。それがもし20％ルールでエンジニアの工数が確保されていたり、別に保守チームをつくればできたりすることだとしても、必要なことは伝えていくんですね。

技術負債が溜まって内部品質が低下して、徐々に希望のデリバリーを守ることが難しくなるとか、重大なインシデントが増えてしまうとか、PdMの成果に影響することに関しては積極的に伝えていく。

もちろん上手く説明するのが難しいことも多々あります。それでも、サービス全体の価値向上に全員で取り組むためには、エンジニアもPdMの抱えるプレッシャーなど、背景にある情報を知る必要があります。そのきっかけとしても、必要なことを伝えるというのが大事なんですね。

エンジニアの日々の活動を事業側に広く理解してもらいたいということよりも、今見えているものは氷山の一角だと捉えて、エンジニアだけでは見えないものを見えるようにする。その結果、ロールの垣根を越えた成果を生み出せるようになります。
![kakehashi_eventreport_2024/12/25_middle_h2-4-2](//images.ctfassets.net/ngrpflsbp3rq/10YOGKErWtdx6AuxgEZuOz/d0743d2ded8c54266b306fc408e19926/Frame_87.png)

__笹尾__：カケハシが掲げるバリューの1つに、「無知の知」があります。自分が知らないという事実を知るのは、とても難しいことなんですね。だから、自分たちの知らないこと、見えないことが、勝手に知れるようになったり、見えるようになったりしないと僕は考えています。

今まで知れなかったことを知るために、自ら会話して、相手に興味を持って、疑問を持って、知る機会を得る。自ら説明して、相手の理解を図り、理解可能な条件を探していく。そうやって何度も何度も試しながら知らないことを知り続けて、見えなかったものを見続けると、全体が浮かび上がって、解像度も徐々に上がっていきます。

何かを改善したいなら、課題を分解して捉える必要があるんですね。そして、課題を分解するには、その課題の全体像を捉える必要がある。改善の施策を実行するためには、解像度を上げる必要もあります。だから、知らないことを知れば知るほど、課題の解決がしやすくなります。

いろいろなコミュニケーションを通して、部分をつなぎ合わせ、全体を浮かび上がらせる。そうすると、ステークホルダーとのコミュニケーションでも、ロールに関係なくチームの課題感をそろえて会話できたり、事業を通した優先順位をつけながら、事業の拡大とプロダクトの持続性の両方を進めることができます。

ロールの違いが妥協を生むのではなく、ロールの違いを礎にして、新しい価値が生まれるようにする。そんなチームになるために、もし全体が見えないのなら、自分たちで垣根を越えていけばいい。何回もあがいて進めばいい。
![kakehashi_eventreport_2024/12/25_middle_h2-4-3](//images.ctfassets.net/ngrpflsbp3rq/4QXxHGDFItH5VQcz7dPaJH/1012a43c9705e2ee0a674ede0d1ba75f/Frame_88.png)

__笹尾__：これからも僕たち「Musubi AI在庫管理」開発チームは、メンバーで一丸となって、プロダクト、サービス、事業やロールの垣根を越えて、より高い価値を出し続けていきたいと考えています。


イベントレポート

開発生産性を上げながらビジネスも30倍成長させてきたチームの姿

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

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

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

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

Go GEMBA! ユーザーファーストで事業に寄り添う開発組織戦略

チームの壁をぶち破る！開発生産性と組織のダイナミズム向上

トレジャーデータ創業者が語る、売れるものをつくる力〜開発組織の価値をどう証明するか〜

誰も全体を知らない～ロールの垣根を超えて引き上げる開発生産性

部署を作らないがホラクラシーでもない『新しいカタチの組織』なら開発生産性を最大化し続けることは可能か

.css-1uuptc0 svg{width:32px;height:32px;fill:#666666;stroke:#666666;}@media (max-width: 750px){.css-1uuptc0 svg{width:24px;height:24px;}}イベントレポート

開発生産性を上げながらビジネスも30倍成長させてきたチームの姿

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

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

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

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

Go GEMBA! ユーザーファーストで事業に寄り添う開発組織戦略

チームの壁をぶち破る！ 開発生産性と組織のダイナミズム向上

トレジャーデータ創業者が語る、売れるものをつくる力〜開発組織の価値をどう証明するか〜

誰も全体を知らない ～ ロールの垣根を超えて引き上げる開発生産性

部署を作らないがホラクラシーでもない『新しいカタチの組織』なら開発生産性を最大化し続けることは可能か

イベントレポート

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

チームの壁をぶち破る！開発生産性と組織のダイナミズム向上

誰も全体を知らない～ロールの垣根を超えて引き上げる開発生産性