最適化ではなく最⼤化 ⽣産性と⽣産量を上げるためにどう考えるか？ 2024年2⽉ Sansan株式会社 執⾏役員 ⻄場正浩

- 開発者体験はユーザー体験と同等に重要である。 - 開発者体験が個⼈の⽣産性向上に⼤きく寄与する。 - 私が多くのことを考えても開発者体験の向上は難しい。 ○ そのためにボトムアップの組織を作りたい。 ○ トップダウンでボトムアップにする。 ○ ”Disagree and Commit”でやっていきましょう。 - 常に仮説を持ちながら新しい情報を探索し ⾃分の考えをアップデートしていきたい。 - ⾊々やっているわけではなく、 グローバルテックカンパニーにするために、 ボトルネックを発⾒し解消しスループットを増やしている。 ⻄場 正浩 VPoE／VPoP／CPO補佐 主にプロダクト開発に責任がある ※ VPoE／VPoPについては別途話したい

そもそも開発⽣産性とは なんだろう？

- 仕事が楽しく、邪魔が⼊らず、集中できる時間がある。 何をどう作ればいいかを分かっている。 作るものの価値が⾼いことを知っている。 技術的にもほどよいチャレンジングな要素がある。 - マシンスペックもそこそこ良いものを使っている。 ツールやソフトウェアも 業界で⾼く評価されているものを導⼊している。 - ⼀緒に技術やシステムについて 盛り上がれる仲間がいる。 充実感を感じられる。 エンジニアにとって⽣産性が⾼い状態とは何だろう？

- バグにハマったり、既存のシステムやライブラリの仕様を勘違いしている。 ⼈に聞いたり話したりするとすんなり解決しそうな話だ。 - Slackやミーティングで開発時間が細切れになり集中⼒が続かない。 - マシンスペックが低く、応答速度が遅くイライラする。 使っているツール類も業界スタンダードではなく、 質の低い内製ツールや⼀昔前に流⾏ったものだ。 - プライベートでのトラブルや、睡眠不⾜でひどく疲れている。 眼の前のことに集中できない。 逆にエンジニアの⽣産性が低い状態とは何だろう？

- ⽬標と⽅向性が明確になっており、⼀丸となって⽬標達成に取り組んでいる。 コミュニケーションも円滑であり、互いに情報共有や意⾒交換、相談が必要に応じて活発に⾏わ れている。 - 開発プロセスも常に改善していっている。無駄な作業をなくしたり、⾃動化している。 同じ作業を年に数回⾏うのであれば費⽤対効果をみて改善している。 さくっとできるものであれば空き時間を使ってさくっと改善している。 - 組織の技術⼒が⾼い、または⽇々⾼くしようと取り組んでいる。 Growth Mindset(※1) であり、新しいことを学び、昨⽇よりもスキルが上がる状態を⽬指している。 ネガティブなフィードバックも最⾼の贈り物だと捉えている(※2) 。 そのため⼼理的安全性が⾼い（感情的安全性ではなく）。 - プロジェクト管理がされており、メンバー全員がプロジェクト達成のためにどのようなタスクが あるかを把握している。 メンバーが⾃発的に将来起こりうるリスクについて議論しており、そのリスクに対する対処が⾏ われている。 開発組織の⽣産性が⾼い状態とは何だろう？ ※1マインドセット：「やればできる！」の研究 ※2 Hit Refresh マイクロソフト再興とテクノロジーの未来

- 分割統治が⾏われており、同じ⽬標に向かっていない。 互いに互いの業務について⼝も⼿も出さない。 コミュニケーションが乏しく、困っていてもなかなか相談する時間がない。 リーダーが個別に対応しており、リーダーが常に忙しくしている。 - 業務に無駄が多い。⾃動化できるタスクが⾃動化されていない。 ⾃分が担当したときに⼀⼿間かければ他の⼈が楽になることに対して意識が向いていない。 また新しいツールの導⼊やプロセス変更でもっと楽になることには気づいている。 しかし誰も提案しない。 無駄な会議や参加する必要のない会議に呼ばれる事が多い。 - 開発しているシステムに対して技術⼒やスキルが⾜りていない。 学習するための時間が必要だが時間を確保できていない。また学習の環境が整っていない。 そのことを分かっているが誰に相談したら解決できるのかも分からない。 - プロジェクト管理が⾏われておらず、リスクへ事前の対応ができていない。 それゆえに⾏き当たりばったりで問題に対応する必要があり、必要以上にプロジェクトが⽌まってしま っている。 逆に開発組織の⽣産性が低い状態とは何だろう？

- 作ったものがある程度⾼い確率で狙った通りに使われている。 単に使われ⽅だけではなく、 規模感や営業シーンでの評価なども含めて狙い通りに⾏くことが多い。 - 狙い通りに⾏かなくても 顧客やマーケットからのフィードバックを収集し、 そこから軌道修正を迅速に⾏うことで⽬標に到達できる。 費⽤対効果が⾼い機能が作れている。 - プロダクトとして実現したかった顧客体験を システムが⾼いレベルで実現している。 実現したい顧客価値を関係者全員が理解している。 プロダクト開発で⽣産性が⾼い状態とは何だろうか？

- 作ったものが狙い通りの結果にならない。ユーザーに使われない。 ユーザーやマーケットからフィードバックを集めてもなかなか⽷⼝が⾒つからず、 PDCAが回らない。 そのため⾏き当たりばったりになり、全然違う機能を乱発して作っている。 - プロダクトで実現したかった顧客体験がシステムとして実現されない。 そもそも当初から技術的に達成⾒込みが低かったり、エンジニアに適切に作るべきものが 伝わっていない。 逆にプロダクト開発で⽣産性が低い状態とは何だろうか？

開発⽣産性を向上させるために 考えるべきことは何だろうか？

労働⽣産性と付加価値⽣産性がある。 どちらを上げるための施策かを明確にしたほうがいい。 ⽣産性にもさまざまな種類がある。 労働⽣産性 付加価値⽣産性 完成したソフトウェアの機能数、 リリースの頻度などで評価する 開発したソフトウェアの売上など で評価する

エンジニア個⼈、開発組織、プロダクト開発、のカテゴリがある。 また衛⽣要因と動機づけ要因がある。 全体観を持って組織のボトルネックを探し解消する。 衛⽣要因 動機付け要因 ないと不満につながり、 ⽣産性が下がる。 あると満⾜につながり、 ⽣産性が上がる。

カテゴリ 衛⽣要因 動機付け要因 個⼈ - 開発に必要な要件を ⼗分満たすPCやツールが整っている。 - ⼀緒に働きたいと思えるメンバーがいる。 - 気軽に質問や相談ができるチームである。 - まとまった開発時間を確保できる。 - 適切に休息がとれる。 - 楽しくチャレンジングな仕事がある。 - スキルアップができる環境がある。 - 解決すべき課題や解決策を提案することが 推奨されている。 - チームへの貢献を評価される。 開発組織 - みんなで課題を解決するためにチーム全体で 円滑なコミュニケーションが⾏われている。 - 無駄なタスクをなくしたり、作業を⾃動化し、 開発業務を改善している。 - 適切なプロジェクト管理が⾏われており、 メンバーが互いに互いの業務を理解し、 将来起こりうるリスクについて対策できている。 - ⽬標と⽅向性が明確で共通理解がある。 - ⼼理的安全性(感情的安全性ではなく)が⾼く、 互いにネガティブなフィードバックも⾏い、 ともに成⻑できる。 - 業務に必要なスキル向上のための⽀援がある。 - チームの成果を適切に評価される。 プロダクト 開発 - ユーザーからフィードバックを集め、 適切にPDCAを⾏い、改善の効果がでている。 - PdMによって適切に仮説検証が⾏われており、 開発したものがユーザーから評価されやすい。 - 実現すべき顧客価値を関係者が理解しており、 実現のために協⼒し合っている。

- 費⽤対効果が低いことは思い切って⽌めたほうが良い。 やることがなくなってもいい。 - やめたことで⽣じた時間でスキルアップしたり、 やるべき価値のあることを探す。 「やらない」という決断も重要である。

- 成果はパレートの法則（20:80の法則）に従うとすると、 やることを増やしても⽣産性は上がらない。 - やりたいことが10個あり、そのうち上位2個のみをやったときの成果は8である。 ⼀⽅で10個全部をやったときの成果は10である。 成果は8→10の1.25倍になっている⼀⽅で、⽣産性は4→1の0.25倍になってしまう。 - 前職の費⽤対効果(ROI)⽂化はSNS上でも話題になるほど有名である。 私は前職時代に100個アイデアを考え、そのうちの2個を社⻑に提案したところ、「これくらい筋 の良いアイデアを10個並べてそのうち2個をやろう」と⾔われた。 価値が⾼くないことを数多くこなすよりも、価値が⾼いことを探す時間のほうが⼤切であること を学んだ。 より少なく、しかしより良く※ ※エッセンシャル思考 最少の時間で成果を最⼤にする

経営・事業戦略は⽣産性向上に どのような影響をあたえるだろうか？

- 従業員数を減らしながら、⽣産量を維持する。 - 従業員数を維持しながら、⽣産量を増やす。 - 従業員数を増やしながら、⽣産量をそれ以上に増やす。 とるべきアプローチと組織の状態や状況によって ボトルネックや課題は変わる。 ⽣産性を上げるアプローチは複数ある。

- 対策せずに従業員数を増やすと⼀般的に個⼈の⽣産性は下がる。 - コミュニケーションコストが増える。 コミュニケーションパスは組織の⼈数の増加に対して指数的に増えていく。 - 個⼈の責任感が低下する。 個々⼈の貢献が⾒えにくくなる。 - 組織の慣性⼒が増加する。 何か新しいことを始めるためのコストが⼤きくなり、無駄なことも継続されがちになる。 - マネジメントの質が低下する。 ⼤きなシステムや⼤きな組織はマネジメントの難易度が⾼いが、 組織のマネジメント⼒の総和が増えない。 - 開発案件の質が低下する。 価値の⾼いプロジェクトが⼗分にないことにより、価値が⾼くない案件を開発している。 前述のパレートの法則（20:80の法則）のとおり。 - ゆえに従業員を増やしながら⽣産性を上げるためには、 組織・技術・プロダクトのマネジメントやリーダーシップの強化も不可⽋である。 例：従業員数を増やしながら、⽣産量をそれ以上に増やす。

- どの事業やプロジェクトにどれくらい⼈を采配するのか？ - 評価できる時間軸が違う。 - 既存事業は短期的に収益が確保できる。 - 新規事業は既存事業と同等の付加価値⽣産性を出すまでに数年かかる。 - 仮に短期的な付加価値⽣産性だけで評価すると新規事業に資本を投⼊できない。 ⽣産性向上はポートフォリオ戦略でもある。

Sansanは1年で⽣産量2倍を⽬指す

最適化ではなく最⼤化を⾏う

- 連結売上⾼が 34.6％(※) 成⻑している。 Sansanは成⻑し続けている。 - さらにマルチプロダクト化も成功しており、 新しいプロダクトが⽴ち上がっている。 - その成⻑を牽引するために、 プロダクト開発組織は全ポジションを積極的に採⽤している。 ※2024年5⽉期第2四半期決算において 連結ARRは前年同期⽐34.6%増 ※グラフは各年5⽉期の売上⾼（2016年5 ⽉期以前は単体売上⾼、2017年5⽉期以 降は連結売上⾼）

もちろんバランスを取りながらやっていく必要があるが、 どちらのフェーズなのかを意識しておくと会社全体で⽅向性が揃う。 最適化と最⼤化は考え⽅が違う。 最適化 最⼤化 - 既存のメンバーで最⼤の成果を得るために 調整や改善を⾏う。 - 付加価値⽣産性が⾼い事業に⼈を寄せる。 共通基盤を開発し効率化を図る。 - 事業やプロダクト単体ではなく 横断的に組織の機能の共通化も⾏う。 - 各事業やプロダクトが独⾃に判断し、 採⽤を⾏う。 - ⾜並みをそろえる必要がある共通化な どは⾏わない。 各事業等で最適な体制や開発を⾏う。

⽣産性や⽣産量が上がっているようで実際は上がっていない。 最適化と最⼤化の罠 最適化の罠 - ⾃⼰中⼼な局所最適の罠：⾃分たちだけは 良くても周りの⼈達に悪影響がある。 - 過度な標準化の罠：柔軟性が失われ、 イレギュラーな事象で多⼤な⼯数がかかる。 - 過剰な指標依存の罠：⽣産性向上という⽬的 を忘れ、評価指標をハックする。 - 過度な技術依存の罠：新しいツールや技術は ⼀時的に⽣産性を向上させるが、本質的な課 題の解決にならない。 最⼤化の罠 - 過度な拡⼤による⽣産性低下の罠： 組織が⼤きくなったが付加価値⽣産性の⾼い 業務が⼗分にない。 - 過度な拡⼤による柔軟性低下の罠： 組織が多くなるほど慣性⼒が働き既存の⽅法 を好むようになる。それにより⽣産性の低い やり⽅を続ける。

経営メンバーとして最⼤化を実現する

- ⼟台：⼈が組織を作り、組織がプロダクトを作り、 プロダクトが価値を⽣み出す。 ⼈が全てだ。 - 組織マネジャーの成⻑⽀援や 組織マネジャーの採⽤をする。 組織の裁量と責任を⼤きくする。 - プロダクトマネジメントを強化し、 価値のあるものを開発し その価値を顧客に届ける。 全体観を持って⽣産性の向上と⽣産量の増加を⽬指す。

仲間を増やす。 - 全ポジションで採⽤を進めている。 - 採⽤基準は徐々に引き上げている。 - 組織／技術／プロダクトをマネジメントできる⼈は意識的に強化している。 成⻑⽀援の環境を整える。 - 育成のための評価を⾏う。 フィードバックを明確にし、サイクルを短くする。> speakerdeck: エンジニアの成⻑に向き合う評価と⽬標設定 - 状況を⾒ながら学習⽀援策を⾏う。 書籍購⼊補助、Udemy Business、各種研修(EVeM、Minervaなど)、GCPやAWSの学習コンテンツ。 - 挙⼿制の異動を活発にする。 Sansan社内やグループ会社には異なるフェーズのプロダクトがある。 また各開発組織で使っている技術スタックが違う。新しい環境で新しいことにチャレンジできる。 ⼟台：⼈が組織を作り、組織がプロダクトを作り、プロダクトが価値を⽣み出す。⼈が全てだ。

Sansanのプロダクト開発組織 技術本部 Sansan Engineering Unit Eight Engineering Unit Bill One Engineering Unit Strategic Products Engineering Unit Quality Assurance Group データアライアンス部 海外開発拠点⽀援室 Digitization部 コーポレート システム部 Mobile Application Group 研究開発部（R&D） 情報セキュリティ部 VPoE室 CPO室 UXリサーチセンターグループ プロダクトデザイナーグループ プロダクトマネジャーグループ 約500名 約60名

Sansanの技術スタック カテゴリ 技術 ⾔語 Typescript, C#, Kotlin, Go, JavaScript (Express), Ruby, Python フレームワーク React, Next.js, ASP.NET MVC, Ktor, Spring Boot, Rails インフラ AWS, GCP, Azure DB CloudSQL (PostgreSQL), Aurora (MySQL), Elasticsearch, Azure SQL Database, Azure Cosmos DB, BigQuery, Redshift 運⽤・監視 Zabbix, Grafana, New Relic, Amazon Elasticsearch Service, Fluentd, Chef CI/CD・テスト Jenkins, NUnit, JUnit, GitHub Actions その他 Elastic Cloud, GraphQL, REST, Auth0, GitHub, GitHub Copilot, Figma, Storybook, Teamflow

- 希望者にEVeMやMinervaなどのマネジャー研修を⽀援している。 - 技術本部経営チームを作り、経営課題を議論し解決する。次期CXOを育てる。 組織マネジャーの成⻑⽀援や組織マネジャーの採⽤。 そのうえで組織の裁量と責任を⼤きくする。 成⻑⽀援 採⽤ 組織の裁量 と 責任の拡⼤ - 開発組織の⼀番上のOKRのObjectiveは「1年で⽣産量2倍にする」であり、 ⽣産量の定義は各部で決めていい。各部は取り組み状況を報告する責任があり、 マネジャーは担当する組織の成果や周辺組織に貢献した成果で評価される。 - 説明責任を果たすのであれば裁量は増える。 「説明責任なしに⾃由にお⾦が使える」といった裁量はない。 - 笹川 裕⼈、⼤島 武徳がマネジャーとして⼊社している。 - ⼀つ⼀つの開発組織の裁量や責任がスタートアップのCTOと同等程度あるため チャレンジングである。

- 説明責任(Accountability)とは、⾃分の⾏動、決定、ポリシーに対して責任を持ち、 その結果について説明する義務のことである。 - この概念は、透明性、信頼、責任のあるガバナンスを促進するために重要であり、 個⼈が⾃分の⾏動の結果に責任を持つことを意味する。 - 適切に運⽤することで、 権⼒の乱⽤を防ぎ、関係者間の信頼関係を築き、組織の効率性を⾼める。 説明責任を適切に運⽤したい。

- 開発組織の付加価値⽣産性を⾼めるためには、 プロダクトマネジメントの強化が必須である。 - どんなに開発の労働⽣産性を⾼めてシステム開発を⾏っても 顧客にとって価値がなければ、付加価値⽣産性は上がらない。 - 顧客にとって価値の⾼いものを発⾒し、それを品質⾼く開発し、 適切に顧客に届ける(※) ⼀連の流れを改善し続ける必要がある。 プロダクトマネジメントを強化し、価値のあるものを開発し、その価値を顧客に届ける。 ※ プロダクトマーケティングが必要である。別途どこかで話たい。

まとめ: Sansanは1年で⽣産量2倍を⽬指す。

- Sansanの開発組織は、⼈が全てだ。 - 最適化ではなく、最⼤化を実現し、マルチプロダクトの成⻑を牽引する。 - ⼈が成⻑できる環境を整えていく。常に改善し続ける。 - 説明責任を適切に運⽤し、各組織の裁量と責任を拡⼤させる。 - システム開発を顧客価値に効果的に変換するために プロダクトマネジメントを強化し続ける。 まとめ:Sansanは1年で⽣産量2倍を⽬指す。

参考：⽣産性を上げる⼩技

- 【1】15分は⾃分で考える。 - 【2】それでも分からなかったら必ず⼈に聞く。 【1】を守らないと他⼈の時間を無駄にする。 【2】を守らないと⾃分の時間を無駄にする。 15分ルール

- 私の考えでは、もっとも⽣産性を上げるためにロジカルシンキング／ロジカルライティング は効果的なスキルである。 - 私は⽣産性が相対的に⾼い。 それは、ロジカルに考えることにより⽇々の⾃分の仕事の仕⽅を改善したり、仕事に必要な スキルを⾝に付けているから。 - ChatGPT等の活⽤もロジカルに考えて質問したほうが⽣産性が上がると思っている。 ロジカルシンキング／ロジカルライティング 参考：⼊⾨ 考える技術・書く技術――⽇本⼈のロジカルシンキング実践法 ⼭崎 康司 (著)

- 共有のための会議は録画して展開する。リアルタイムの参加を必須としない。 - リモートワーク環境が整ったことで会議を録画しやすい。 - さらにUdemy Business等の動画プラットフォームを使うと⾊々便利。 録画を有効利⽤し、集中して開発できる時間を確保する。

- 社内の分析において、学習⽀援施策の活⽤と評価に相関がある。 - これはおそらく疑似相関であり、どちらも学習意欲や向上⼼の⾼さと紐づく。 - 学習を強制するのではなく、学習したいときに学習するハードルを下げることを 念頭に施策を設計している。 学習意欲が⾼い⼈を⽀援する。

メンバー 40

笹川 裕⼈ 技術本部 Sansan Engineering Unit 副部⻑ - コンピュータ・サイエンスで博⼠を取得。 - 新卒でリクルートに⼊社。⼤規模データ基盤の 開発、データ分析（ABテスト設計など）、デー タ基盤のクラウド化に従事。 - エムスリーにSWEとして転職。⾃らも⼿を動か しながら、AI/ML、SRE、QA、グローバルチー ムなどのマネジメントを担当。 - 2023年4⽉より現職

⼤⻄ 真央 Order One 事業責任者 - SEとしてキャリアをスタートし、前職ではスクラム マスターを含むアジャイルな開発を推進。 - 2016/1にSansanに⼊社し、Sansanプロダクトの開発 及び関⻄開発拠点の⽴ち上げを担当。 - 新規事業を⽴ち上げるエンジニアリング組織を⽴ち上 げ後、プロダクトマネジャー及び開発責任者として Bill Oneの⽴ち上げ及びグロースを担当。 - 現在は、第三の事業の柱を作るべく、Order Oneの事 業責任者にチャレンジ中。

⼤島 武徳 技術本部 研究開発部 副部⻑ - ゲーム機本体の組み込みソフトウェア開発者としてキャリ アスタート。動画ライブラリやストリーミングシステム、 パフォーマンス・チューニング、アプリ開発などを⾏う - ⾃動⾞メーカーに転職。クラウドでの開発にswitchし、⾃ 動運転向けのAI学習環境開発やdata pipeline開発を⾏う - このときにWaterfallからAgileへのswitchも経験する - その後、情報サービス系企業にてデータ基盤開発やデータ ガバナンスの整理などを⾏う - 2023年4⽉より現職。データ利活⽤推進及び新規データプ ロダクト開発の⽀援を⾏っている

三浦 俊介 技術本部 コーポレートシステム部 部⻑ - ⾳楽⼤学、芸術⾳楽の作曲学科卒 - 広告業界で⼤⼿企業のWEBプロモーション案件のWEBプ ロデューサー／ディレクターを担当 - 楽天（株）にて電⼦書籍/本ジャンルの新規サービス開発や サービスグロースのPjM、UIUXデザイナーを担当 - （株）JCBにてデジタルマーケティングの企画制作を担当 - コインチェック（株）にてUX部⻑／社⻑室⻑／システム企 画などを担当 - 2022年1⽉より現職

柴野 亮 Bill One事業部 VPoP / 公認会計⼠ - 公認会計⼠試験に合格後、監査法⼈に⼊社 - 2014年にSansan株式会社へ⼊社し、財務・経理 担当として経理実務に携わる - 請求書業務の⾮効率さに⼤きな課題を感じ、イ ンボイス管理サービス「Bill One」の事業開発に 着⼿ - 現在はプロダクトマネジャーとして、新しい請 求書業務の在り⽅を普及させるために尽⼒する

川瀬 圭亮 Sansan事業部 プロダクトマネジャー - 在学中は政治学を専攻しながら、フリーランスのWEBデザイ ナーとしても活動 - 卒業後、国内外のスタートアップやメガベンチャー、ビッグ テックでプロダクト開発に携わる - アジアの⼩中学⽣向け教育サービスから、国内⼤企業向け契 約管理サービスまで、様々なプロダクトマネジメントを担当 - 昨年、働きながら、オンラインでUSのMBAを取得 - 第⼀⼦、第⼆⼦ともに育休を取得 - 2023年8⽉にSansan株式会社に⼊社

尾花 政篤 Contract One Unit プロダクトマネジャー - コンサルティングファームのマネジャーを経て、 保険業界特化型のVertical SaaSを創業。 - 2023年にSansan株式会社に⼊社。 - 契約データベース「Contract One」のプロダク トマネジャーとグループ⼦会社の⾔語理解研究 所を兼務。また社内の⽣成AI/LLMを含めた⾃ 然⾔語処理技術の活⽤を推進。

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/ 48

No content