技術本部 ⾚城 史哉（ぎーにょ） 「ストレッチゾーンに挑戦し続ける」 ことって難しくないですか？ メンバーの持続的成⻑を⽀えるEMの環境設計 Engineering Management Conference Japan 2026 

⾚城 史哉(Fumiya Akagi) Sansan株式会社 技術本部 Sansan Engineering Unit/Mobile Application Group 前職ではAndroidアプリの受託開発に従事。 2019年にSansanに中途⼊社し、 Sansan Androidアプリの開発・運⽤を担当。 直近数年は、Sansan Mobileアプリ開発チームのマネジメントを ⾏っている。 X: @ginyolith_tech 

会社概要 本社 神山ラボ Sansan Innovation Lab 社 名 Sansan株式会社 所在地 本社 東京都渋⾕区桜丘町1-1 渋⾕サクラステージ 28F グループ 会社 Sansan Global Pte. Ltd.（シンガポール） Sansan Global Development Center, Inc.（フィリピン） Sansan Global (Thailand) Co., Ltd.（タイ） ログミー株式会社 ナインアウト株式会社 株式会社⾔語理解研究所 従業員数 1,979名（2025年11⽉30⽇時点） 2007年6⽉11⽇ 設 ⽴ ⽀店：関⻄⽀店、福岡⽀店、中部⽀店 サテライトオフィス：Sansan神⼭ラボ、Sansan Innovation Lab、 Sansan⻑岡ラボ 拠 点 寺⽥ 親弘 代表者 

Sansan株式会社の働き⽅を変えるAXサービス ⽣産性を向上させ、企業のAI活⽤を最⼤化するデータベースとしても貢献できる 「働き⽅を変えるAXサービス」を提供します。 データクオリティマネジメント 請求 名刺 管理 営業 契約 名刺管理から、収益を最⼤化する AI契約データベースが、利益を守る 「なくせる」をつくり、全社の働き⽅を変える 名刺アプリ 経理DXサービス 取引管理サービス ビジネスデータベース 各サービスの活⽤で変わる働き⽅ 情報を分析・活⽤しやすく データに基づいた判断ができる 情報の管理がしやすく すぐに共有できる 必要な情報を すぐに⾒つけられる 個⼈向け 法⼈向け 

技術本部 Sansan Engineering Unit Mobile Application グループ Quality Assurance Engineering Unit プロダクト 組織 開発に関わる⼈は 全体で約120名 ※ 1チームは2–8名 Sansan PdM チーム Sansan QA チーム Sansan デザイナー チーム Sansanの開発体制 Manager Manager Nayose グループ Master Data グループ Data Hub グループ Product Reliability グループ Product Enhancement グループ Infrastructure グループ Architecture グループ アプリ開発 チーム アプリ開発 チーム アプリ開発 チーム 

技術本部 Sansan Engineering Unit Mobile Application グループ Quality Assurance Engineering Unit プロダクト 組織 Mobile Application Group所属の約15名のマネジメントをした時のお話 ※ 1チームは2–8名 Sansan PdM チーム Sansan QA チーム Sansan デザイナー チーム Sansanの開発体制 Manager Manager Nayose グループ Master Data グループ Data Hub グループ Product Reliability グループ Product Enhancement グループ Infrastructure グループ Architecture グループ アプリ開発 チーム アプリ開発 チーム アプリ開発 チーム 

EMに⼊⾨し始めた際、ある出来事をきっかけに、 ストレッチゾーンに挑戦し続ける事の難しさと重要性 を痛感しました。 EMとして「成⻑し続けられる環境」に向き合う中で⾏った、 試⾏錯誤で得られた考え⽅をお話します このセッションでお話しすること 

対象の聴衆 - 停滞期に⼊っているメンバーや組織を抱えているEMの⽅ - EMロールにトライして間もない⽅ - ⼤規模組織の中でミドルマネージャーの難しさを感じている⽅ - EM以外のICやその他ロールで、停滞感を抱えている⽅ その⼈たちが得られるもの - ⽇々の業務をストレッチゾーンに変え、成果を出すための考え⽅と実例 - キャリア形成を⽀援する⽅法 Learning Outcome（再掲） 

「ストレッチゾーン」に着⽬したきっかけ 

- Android / iOS の技術領域でチーム分け 当時Android チームのマネジメントを担当 - 4~5⼈くらいのメンバーを担当 - 徐々にiOSチームのマネジメントにも 領域を広げていく試みをしていた 2年前（2024年）頃のSansan モバイルアプリ開発組織 Mobile Application グループ Manager iOS チーム Android チーム 

- ある⽇の1on1にて、 在籍歴の⻑いシニアiOSエンジニアが「退職したい」という申し出 - 数ヶ⽉後、他の5年⽬iOSエンジニアも、同様に退職の申し出 - 2名に共通して、キャリアの停滞感 が理由となっていた - 「キャリアや先のことが考えられなかった」 - 「現状のまま、成⻑するイメージが沸かない」 ゲームオーバー 

無⼒感と後悔 - ⾃⾝が受け持った短い間でも⾃分にもっと出来ることはあったのでは - あと1年早く、⾃⾝のマネジメント担当を広げたら、アクションが 出来たのでは 停滞感を産まないこと も、マネージャーの責務として取り組む必要がある - 1エンジニア⽬線だと、停滞感を打破しきれないことがある - ⼤規模組織だと、経営・部⻑レイヤーが細かい部分まで⾒ることが できない。そのため、ミドルマネージャーの動きも重要となると実感 初めての退職申し出を受けて 

ピープルマネジメントでの試⾏錯誤 

- ⽬標・学習の負荷を3領域で整理し、成⻑が起きやすい“適度な挑戦”を狙って 設計するためのモデル - コンフォートゾーン（居⼼地が良い領域） - 慣れたやり⽅で安⼼してできる／失敗リスクが低い - 新しい学びが起きにくく、成⻑が鈍化しやすい - ストレッチゾーン（背伸び領域／ラーニングゾーン） - 今より少し⾼い⽔準：努⼒＋⼯夫＋⽀援で届く範囲 - 適度な緊張感があり、学び・技能獲得・成⻑が起きやすい - パニックゾーン（混乱領域） - 能⼒・経験に対して負荷が⼤きすぎる（不安・ストレス過多） - 思考や⾏動が縮こまり、成果や学習がむしろ落ちやすい 前提：ストレッチゾーン とは 

過去の退職の原因は「成⻑できない・停滞感」 「ストレッチゾーンなチャレンジが枯渇してしまった」と捉えた 今後、同じような停滞を産まないために、 まずは1on1をベースに、「ストレッチゾーンの継続」に取り組んだ 話していく中で、いくつかのパターンが⾒えてきた 過去のきっかけを振り返る 

「ストレッチゾーンが無い」のパターン ストレッチゾーンなチャレンジが無い 今の⾃分に最適な チャレンジが 分からない - 「何がストレッチで、 どこを伸ばすべきか」 が掴めない。 途中で⾃然消滅しそう - 忙しさや優先度の波で 後回しに。 - 成果が⾒えづらく、 フェードアウトしがち。 外部要因で⽌まりそう - 上司や他部署から 「今それ？」で ストップがかかるのでは。 - 他チームとの合意形成の コストが⾼く、 最後まで実⾏できない のでは。 

「ストレッチゾーンが無い」の要素 今の⾃分に最適な チャレンジが 分からない - 「何がストレッチで、 どこを伸ばすべきか」 が掴めない。 途中で⾃然消滅しそう - 忙しさや優先度の波で 後回しに。 - 成果が⾒えづらく、 フェードアウトしがち。 外部要因で⽌まりそう - 上司や他部署から 「今それ？」で ストップがかかるのでは。 - 他チームとの合意形成の コストが⾼く、 最後まで実⾏できない のでは。 現状を分析する 

- 会社・従業員双⽅にとって最適なアサインをするために⽤いられる、 リクルート社で提唱されたフレームワーク - メンバー全員と、フレームワークを基にした⾔語化を実施 オンボーディング時にも必ず⾔語化するように 現状を分析する：Will/Can/Must 

⾃分のWillを正しく⾔語化できるとは限らない - 例えば、「技術⼒が⾼くなりたい」は様々な解釈ができる - ある技術のエキスパートになりたい - 有名なカンファレンスで登壇したい - 技術でビジネスを動かしたい - Willが上⼿く⾔語化できないと、Mustと噛み合わずアクションが⽣まれない - 「今のレガシーコードを刷新したいけど、現実的に無理だから、 成⻑できないままだ」 - Will / Can / Must以外の切り⼝が必要になってくる 現状を分析する：Will/Can/Must の難しさ 

- 具体と抽象を往復する問いかけで、新たな⽰唆を得られる - Whyを質問すると、具体例の背景（≒抽象）が⾒えてくる 現状を分析する：具体と抽象 によるリフレーミング 具体 抽象 Why？抽象化 How？具体化 成⻑のため インパクト⼤な技術的意思決定がしたい ⾃動テスト戦略策定 ビルド速度の⾼速化 今のレガシーコードを 刷新したい 

「ストレッチゾーンが無い」の要素 ⽬標を⽴てる 今の⾃分に最適な チャレンジが 分からない - 「何がストレッチで、 どこを伸ばすべきか」 が掴めない。 途中で⾃然消滅しそう - 忙しさや優先度の波で 後回しに。 - 成果が⾒えづらく、フ ェードアウト しがち。 外部要因で⽌まりそう - 上司や他部署から 「今それ？」で ストップがかかるのでは。 - 他チームとの合意形成の コストが⾼く、 最後まで実⾏できない のでは。 

“経営のうまくいっている企業で働いていると、 インパクトに富みながら、なおかつ⼿軽な仕事が そのうち必ず尽きてしまう。 そのため、難しいがインパクトの強い仕事にシフトアップするか、 簡単だがインパクトの弱い仕事にシフトダウンする必要に迫られる。 後者の簡単でインパクトの弱いものを選ぶ態度を、 ウォーカーは「スナッキング」と呼ぶ。 忙しいときは、そうしたスナックをつまみ⾷いすることで、 達成感が得られて、精神的にはメリットがあるだろう。 しかし、スナッキングから多くを学べることはまずないし、 そうした簡単な仕事はほかの⼈々にも実⾏が可能だ” Snackingの誘惑 引用元：Larson, W. (2023). スタッフエンジニア 

なぜ⽬標設定が有効？ - 本当にストレッチであれば、常に不安が付き纏うはず - 「上⼿くやれずに恥を晒してしまうのではないか」 - 「⾃⾝の能⼒の無さが露呈してしまうのでは」 - そんな中、「絶対に⾃分が価値を出せる安定した仕事」の魅⼒は強烈 - 「退屈だが、必要である仕事（≒スナック）」は簡単には無くせない - ⽬標設定は、コンフォートゾーンの誘惑を断ち切るための武器 

⽬標を⽴てる：SMARTな⽬標設定を⾏う Specific（具体的に） Measurable（測定可能な） Achievable（達成可能な） Related（経営⽬標に関連した） Time-bound（時間制約がある） 1981年に、論⽂”here’s a S.M.A.R.T. way to write management’s goals and objectives” により提唱された考え⽅ ⽬標を単なる抽象的なスローガンではなく、管理可能なものにするためのフレームワーク 

⽬標を⽴てる：SMARTな⽬標設定の例 ⾃動テスト戦略を策定する 2026年5⽉31⽇までに、 モバイルアプリの⾃動テスト戦略を ドキュメント化し、 主要3機能に適⽤してCIで必須化する。 

⽬標を⽴てる：SMARTな⽬標設定の例 ⾃動テスト戦略を策定する 2026年5⽉31⽇までに、 モバイルアプリの⾃動テスト戦略を ドキュメント化し、 主要3機能に適⽤してCIで必須化する。 これで コンフォートゾーンの誘惑を断ち切る ことが出来そう？ 

⽬標を⽴てる：SMARTな⽬標設定の例 ⾃動テスト戦略を策定する 2026年5⽉31⽇までに、 モバイルアプリの⾃動テスト戦略を ドキュメント化し、 主要3機能に適⽤してCIで必須化する。 - 結論 - 「SMARTな⽬標」だけでは難しい 

⽬標を⽴てる：SMART ⽬標でカバーできないポイント 1. 野⼼を削ぎ、低い⽬標設定をしてしまう どうしても「達成しないと評価されない」というバイアスがかかる 具体的にしてしまうと、ストレッチさが失われるケースが⾒受けられた 2. 「忙しくて取り組めなかった」がズルズルと続く 特に「緊急度が低いが重要」な性質を持つ 戦略策定・サイドプロジェクトなどで起こる傾向 

⽬標を⽴てる：FASTな⽬標設定を⾏う Frequently discussed（頻繁に議論される） Ambitious（野⼼的な⽬標である） Specific（具体的な指標とマイルストーンがある） Transparent（透明性がある） Donald Sull, Charles Sull(2015)により、変化の激しい現代の環境において、 従来のSMART⽬標が機能不全に陥るという問題意識のもと提唱された。 

⽬標を⽴てる：FASTを実践 Group内で⽬標可視化 定期的にチャレンジ進捗を確認 

⽬標を⽴てる：FAST観点を取り⼊れてみて - 可視化した事により、メンバー同⼠での協⼒を促せた - 「リリース作業の⾃動化は、XXさんもやりたいから協⼒して取り組めるの では？」といった気づきが⽣まれる - チャレンジの幅が増え、相互作⽤によるモメンタムが⽣まれやすくなる - 定期的な議論により、状況の変化に対応しやすくなった - より⾯⽩そうなな開発企画が出てきた時に、思い切って⽅向性を変える - パニック気味であれば、難易度を下げる調整をする - 「ストレッチなチャレンジに取り組み損ねた」機会損失を防ぐ 

「ストレッチゾーンが無い」の要素 今の⾃分に最適な チャレンジが 分からない - 「何がストレッチで、 どこを伸ばすべきか」 が掴めない。 途中で⾃然消滅しそう - 忙しさや優先度の波で 後回しに。 - 成果が⾒えづらく、 フェードアウトしがち。 外部要因で⽌まりそう - 上司や他部署から 「今それ？」で ストップがかかるのでは。 - 他チームとの合意形成の コストが⾼く、 最後まで実⾏できない のでは。 実⾏を⽀援する 

実⾏の⽀援のためにやったこと ドキュメントを書く Team Leaderを任せる⽬標設定 

ドキュメントを書く Team Leaderを任せる⽬標設定 実⾏の⽀援のためにやったこと 

ドキュメントを書く Team Leaderを任せる⽬標設定 実⾏の⽀援のためにやったこと 「権限委譲」を明確にする 

- ストレッチ⽬標 = ⼤きな変化を起こす取り組み となりがち - 「どこまで⾃分で決めていいのか分からない」状況が、 アクション実施を阻害 - ⼀⽅で、裁量を渡しすぎてしまうと 致命的な事故が起こりうる可能性も - デリゲーションポーカー などのプラクティスを使い、 裁量の範囲を「⾔語化・可視化」すると適切な権限を割り当てる事が可能 実⾏を⽀援する：権限を与える 

「ストレッチゾーンが無い」を乗り越えるには 今の⾃分に最適な チャレンジが 分からない - 「何がストレッチで、 どこを伸ばすべきか」 が掴めない。 途中で⾃然消滅しそう - 忙しさや優先度の波で 後回しに。 - 成果が⾒えづらく、 フェードアウトしがち。 外部要因で⽌まりそう - 上司や他部署から 「今それ？」で ストップがかかるのでは。 - 他チームとの合意形成の コストが⾼く、 最後まで実⾏できない のでは。 現状を分析する 実⾏を⽀援する ⽬標を⽴てる 

皆ストレッチな取り組みを 継続できるようになってきた🎉 

この先に待っていたのは... 

※ 2025年5⽉頃のカレンダー 

- ⼈数が増え、⾃⾝の時間を使った⽀援が回りきらなくなってしまった - Span of Control：1⼈の管理者が直接管理できる⼈数は5~8人程度 - 公開⽬標や定期的な進捗確認など、 1on1ベースで回してた運⽤が⾃然消滅 - 本来やるべき、中⻑期的な課題への取り組みを進捗させられない不安感・焦り - 「同じような状況でも、もっと上⼿く成果を出せている⼈がいるんじゃないか」 - マネジャーがボトルネックにならない仕組みが必要 と痛感 スケールの壁 

スケールしても、 ストレッチに挑戦し続けるために 

- 作って終わりではなく、運⽤し続けるコストがある - 感情・他部署からのプレッシャー・⽂化など、⾒えない要素が影響 - 仕組みを⽴ち上げても、予期せぬ副作⽤で失敗することがある - 例：ゾンビスクラム化 - スクラムのイベントは回っているが、継続的な改善が⾏われない - ⾃⾝のチームで何も決められず、外部の許可を得る必要が出てくる 仕組みを作るのは難しい 

難しさの根源は、現実世界の複雑さ 出来事： - 退職した - 成⻑の実感が無い 発⾔ パターン： - ⼊社から数年経過した時 - 単調な開発・運⽤が続いた時 構造： - 組織スケールによる コミュニケーション不全 - 巨⼤すぎるコードベース メンタルモデル： ⼤きな変化はNG という無意識の前提 

難しさの根源は、現実世界の複雑さ 出来事： - 退職した - 成⻑の実感が無い 発⾔ パターン： - ⼊社から数年経過した時 - 単調な開発・運⽤が続いた時 構造： - 組織スケールによる コミュニケーション不全 - 巨⼤すぎるコードベース メンタルモデル： ⼤きな変化はNG という無意識の前提 ある問題の背後には、複雑な構造がある 単純な因果関係で発⽣してない 

“システム思考（Systems thinking）は、 世界の複雑さをシステムとして全体や関係性の観点から捉える⽅法である。 部分に分割するのではなく、全体として理解することで、 複雑な状況において効果的な⾏動を導くための⼿段として⽤いられる。” 複雑さに⽴ち向かうための、システム思考 引⽤元：Wikipedia(2026) システム思考 

- 「ストレッチなチャレンジが難しい」構造を、 システム的に分析する - 様々な⼿法があるが、今回は因果ループ図で⾏う 「ストレッチなチャレンジが難しい」構造を捉える 

ストレッチなチャレンジが抑制される因果ループ図 ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル 

ストレッチなチャレンジが抑制される因果ループ図 ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル 「勝⼿にやるな」と⾔われるのでは 忙しそうな他部署も巻き込まないといけない 

ストレッチなチャレンジが抑制される因果ループ図 ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル 実現可能性の低いチャレンジより ⽬先の分かりやすいタスクに取り組む ≒ Snacking 

ストレッチなチャレンジが抑制される因果ループ図 ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル 重要度⾼・緊急度低の問題を ⾔語化したり、評価する時間がない 

ストレッチなチャレンジが抑制される因果ループ図 ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル 技術負債等の問題が可視化されない 他の機能開発が優先とされ、 取り合ってもらえないのでは 

ストレッチなチャレンジが抑制される因果ループ図 ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル チャレンジに取り組まれず 当然、組織内に前例も⽣まれない 

ストレッチなチャレンジが抑制される因果ループ図 ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル ⾏動の蓄積されず、 ⽂化も定着しない 

ストレッチなチャレンジが抑制される因果ループ図 ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル 「現状を⼤きく変えるような 事はしてはいけないのでは」と 思い込む 

この構造を変えて、 持続可能な形で皆がストレッチゾーンに居続けるには？ 全ての要素をいっぺんに変えるのは、物理的に不可能 システムの振る舞いを⼤きく変えられる介⼊点 = レバレッジポイント を探し、変化を起こす システムを変えるために、レバレッジポイントを探す 

レバレッジポイントを仮説⽴てる ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル 

- 約50件の技術負債を洗い出し、 インパクト（⾦額）、期限、⼯数といった評 価軸で⾔語化 - 継続して技術負債を起票・評価する 運⽤を確⽴ - 技術的・規模的に難易度の⾼いチャレンジを 優先度付けし可視化したことにより、 合意形成のハードル低くチャレンジ可能に - Swift Concurrency, Swift UIの本格導⼊ - レガシーライブラリ排除 取り組むべき課題の可視化： 技術負債・リスクの管理プロセスを⽴ち上げ 

課題の可視化による効果 ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 継続的に可視化 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル 低 組織として取り組むべきと合意された技術課題が、 可視化されている。周りを巻き込むハードル低下 

レバレッジポイントを仮説⽴てる ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル 

⼼理的ハードル：チーム構成の変更 - Team Topologiesを参考に、チームを再編 - iOS / Android チームを解体し、 Steam Aligned Team寄りな構成に - メンバーが慣れ親しんでない技術へのContributeも 当然⾏うこととして求め、⾃然と越権できる環境に Before iOS Team Android Team After Product Growth Dev Product Growth Dev Android App iOS App 開発 開発 Mobile App(iOS/Android/KMP) 開発 開発 Architecture Team ⽀援 

- ADRをベースに、ボトムアップで コードベース全体に影響する変更を提案し、 承認されるまでのプロセスをルール化 - 「勝⼿に動くと、⾮難されてしまうのでは」 という不安由来のハードルを無くす - 新卒のエンジニアが全体に影響するような 基盤の変更を提案するなど、 インパクトの⼤きい改善提案が活性化 ⼼理的ハードル：ガードレールを設ける 

ハードル低下による効果 ストレッチな チャレンジに 取り組む ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 チーム変更とプロセス明確化により ハードルが下がり、チャレンジが取り組む 変化が⼤きい 企画の ⼼理的ハードル 低 

レバレッジポイントを仮説⽴てる ストレッチな チャレンジに 取り組めない ストレッチな 取り組みを⾏う ⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル 

“多くの⼈は放っておけば氷河のようにゆっくりしたペースで アウトプットするようになり、「及第点」を基準とすることに慣れる。 そして焦点の絞れたリーダーシップがないと、 無数の優先事項がかち合ってしまう。 すると、優秀な⼈材は持てる才能や⾏動⼒を発揮できず、 不満を感じてその組織を出ていく。 ここまでくると、後は悲惨な下降線をたどっていくだけだ。” ストレッチな⽂化：⾼い基準を求め続ける 引⽤元：フランク・スルートマン. 最⾼を超える 

ストレッチな⽂化：⾼い基準を求め続ける - 「3倍のスピードで出来ないか」 「その取り組みを、もっと⼤きいスケールにできないか」 と問い続けた - 基準の⾼い、ストレッチな取り組みをしているメンバーは slackや1on1などで⾏動を促すリアクションをし続けた - 徐々に、⾃然と⽇々の業務でストレッチな⽬標を考える⽂化に 

基準を上げることによる効果 ストレッチな チャレンジに 取り組む 基準の⾼い チャレンジが 当たり前の⽂化 取り組める課題 が⾒えない 同僚の チャレンジ前例 やるべきだが、 難易度低の業務 変化が⼤きい 企画の ⼼理的ハードル ⾼い期待値を求め続けられ ⾃然とストレッチゾーンに取り組んでいる 

ストレッチなチャレンジが推進される構造 同僚の チャレンジ前例 増加 やるべきだが、 難易度低の業務 の優先度明確化 ストレッチな チャレンジに 取り組む 基準の⾼い チャレンジが 当たり前の⽂化 取り組める課題 継続的に可視化 変化が⼤きい 企画の ⼼理的ハードル 低 

- 「ストレッチな取り組みをし続ける」ためには、 ミドルマネージャーの動きが鍵となる - 短期のストレッチゾーンへの取り組みは、 1on1を軸に、様々な思考法・フレームワークを活⽤して促せる - スケールした後もストレッチな⽬標にチャレンジし続けるためには、 現状をシステム的に捉え、レバレッジポイントを探す必要がある まとめ 

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

No content

- リクルートマネジメントソリューションズ. Will Can Mustとは？ フレームワークを活⽤するメリットや⽬標設定⽅法を解説. （閲覧⽇：2026-02-15） - https://www.recruit-ms.co.jp/glossary/dtl/0000000304/ - Doran, G. T. (1981, November). There’s a S.M.A.R.T. way to write management’s goals and objectives. Management Review. - https://www.eval.fr/wp-content/uploads/2020/01/S.M.A.R.T-Way-Management-Review-eval.fr_.pdf - Sull, D., & Sull, C. (2015). With goals, FAST beats SMART. MIT Sloan Management Review. - https://sloanreview.mit.edu/article/with-goals-fast-beats-smart/ - (Harvard Business Review). (2019, November). Why constraints are good for innovation. Harvard Business Review. - https://hbr.org/2019/11/why-constraints-are-good-for-innovation?utm_source=chatgpt.com - Wikipedia contributors. システム思考. Wikipedia. （閲覧⽇：2026-02-15） - https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E6%80%9D%E8%80%83 - Larson, W. (2024). エレガントパズル――エンジニアのマネジメントという難問にあなたはどう⽴ち向かうのか（岩瀬 義昌 訳）. ⽇経BP. - Reilly, T. (n.d.). スタッフエンジニアの道――優れた技術専⾨職になるためのガイド. O’Reilly Japan. - Skelton, M., & Pais, M. (n.d.). チームトポロジー. ⽇本能率協会マネジメントセンター（JMAM）. - Meadows, D. H. (2015). 世界はシステムで動く――いま起きていることの本質をつかむ考え⽅（枝廣 淳⼦ 訳）. 英治出版. - Stanier, J. (2022). エンジニアリングマネージャーのしごと――チームが必要とするマネージャーになる⽅法. O’Reilly Japan. - Cagan, M., et al. (n.d.). EMPOWERED――普通のチームが並外れた製品を⽣み出すプロダクトリーダーシップ. ⽇本能率協会マネジメントセンター （JMAM）. - Dweck, C. S. (2016). マインドセット――「やればできる！」の研究（今⻄ 康⼦ 訳）. 草思社. - Syed, M. (n.d.). 失敗の科学（有枝 春 訳）.（※紀伊國屋書店掲載情報） - Slootman, F. (2023). 最⾼を超える（福永 詩乃 訳）. ダイヤモンド社. - Larson, W. (2023). スタッフエンジニア――マネジメントを超えるリーダーシップ. ⽇経BPマーケティング. - Keeling, M. (2019). Design It! ―プログラマーのためのアーキテクティング⼊⾨（島⽥ 浩⼆ 訳）. オライリー・ジャパン. Appendix