マネジメント試行録＃9｜スキルティーチングの設計原則｜いしい
「この資料、このテンプレートをそのまま使えばいいよ」 「ここはこのやり方でやってください」 こうした指示を出したことはないだろうか。 もちろん、緊急対応や時間がないときには、直接的な解法を伝えることも必要である。 だが、これが常態化すると、メンバーは教わったことしかできない人材になってしまう。 同じような問題に遭遇しても、自力で解決できない 「前に教えてもらったやり方」に固執し、状況に応じた判断ができない 常にマネージャーやシニアメンバーに答えを求めてしまう これでは、組織のスケーラビリティは生まれない。 本稿では、業務支援の方針の定め方と、スキルティーチングの設計原則を整理したい。 業務支援の方針を定める──支援の型業務支援の方針は、メンバーとマネージャー双方の認識によって変わる。 能力的に本人だけでは業務ができないと本人も上司も思うなら「教える」 本人はできない・上司はできると思うなら
マネジメント試行録＃8｜新1分間マネージャーからの学び｜いしい
多くの組織で、マネージャーは「結果」と「人」のどちらかに偏りがちである。結果にこだわるマネージャーは独裁的になり、人にこだわるマネージャーは民主的になる。 だがどちらかに偏重するのは不十分だ。本来、マネージャーは結果と人の両方にこだわるべきである。 『新1分間マネジャー』では、この両立を実現する具体的な手法が整理されている。 少々番外編的にはなるが、本稿では、この書籍から得た学びを、自身のマネジメント実践と照らし合わせながら整理したい。 なぜ今、協調型リーダーシップが求められるのか『新1分間マネジャー』の冒頭で、こう語られる。 「今やトップダウン構造では動きが遅すぎます。やる気が生まれないし、革新も生まれない。顧客はより迅速なサービス、よりよい製品を求めますから、全員がもてる能力をフルに発揮しなければなりません。頭脳集団は役員室だけにいるのではありません。組織のあらゆる場所にいるのです。」
マネジメント試行録｜いしい｜note
「マネジメント試行録」は、事業と組織の両立に悩みながら学んできたことを整理するマガジンです。 現場で感じた課題や、そこから得た気づきを、自分の言葉で残していければと思っています。
マネジメント試行録＃6｜役職はラベル、役割が成果を決める｜いしい
「3年後には課長になりたい」「いつかは部長を目指す」 こうした言葉を聞くたび、違和感を覚える。 その先に何があるのか。役職という肩書きを得た後、何を成し遂げたいのか。 もちろん、役職を目指すこと自体が悪いわけではない。 だが、役職を追うことだけに目を向けると、本質を見失うことがある。 環境が変わったとき、対応できなくなる 無意識のうちに、自分の成長の足枷になる 本来広げられるはずの役割の可能性に気づかない 本稿では、役職と役割の違いを明確にし、なぜ「役割を広げること」に集中すべきなのかを整理したい。 役職と役割の違いを定義する役職とは何か役職とは、組織のコミュニケーション複雑性を下げるために、インターフェースにラベリングをしたものである。 組織が大きくなると、誰が何に責任を持ち、誰に相談すべきかが見えづらくなる。 そこで「マネージャー」「リーダー」「部長」といったラベルを用意し、コミュニケ
マネジメント試行録＃7｜メンバーとの成果振り返りについて｜いしい
多くの組織で「振り返り」が行われている。 1on1などの場で目標に対する進捗を確認し、次のアクションを話し合う。 だが、その振り返りを真に機能させることはなかなか難しい。 「〇〇の実装を完了しました」「△△をリリースしました」といった単なる進捗報告で終わっている メンバーは淡々と実施した項目を報告し、マネージャーは「お疲れさま」と返すのみ 振り返りが終わっても、メンバーの思考や行動に何の変化も生まれていない こうした形骸化した振り返りは、時間の無駄である以上に、組織の成長機会を失わせている。 本稿では、#5で述べたストレッチ目標と連動し、メンバーの行動変容を促す「成果振り返り」の設計原則を整理したい。 振り返りの本質とは何か振り返りの目的は、メンバーの行動変容を確認し、成果創出を支援することである。 #1で述べたように、マネージャーの成果とは、管轄組織のKGI・KPIを最大化することである
Why-What-Howを問われ続けたSpeeeでの5年間とこれから - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar最終日の記事です。昨日の記事はこちら デジタルトランスフォーメーション事業本部（以下、DX事業本部）の石井です。 エンジニアリングマネージャー（以下、EM）として、4つの不動産DX事業の開発部署と、DX事業本部横断の開発基盤チームを管掌しています。 2020年9月にSpeeeへ入社し、気づけば5年が経ちました。節目なので、振り返りを交えた在籍エントリを書いてみます。 入社当時、私は30代半ば。「事業と開発を行き来しながら事業成長に貢献できる人になりたい」という想いでSpeeeを選びました。 5年経った今、自分なりに変化できたと感じています。その原動力となったのは「問われる環境」と「挑戦の機会」でした。そして振り返ってみると、ここで培った力は、AI時代に活きる土台にもなっていると思います。 「問われる環境」がくれた成長の圧力
新卒2年目エンジニアの私が、チームをリードするために「こだわっている」こと - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar24日目の記事です。昨日の記事はこちら こんにちは。SpeeeでHousiiというサービスの開発をしている新卒2年目エンジニアの山本です。 現在Housiiは2つのチームに分かれて開発を進めており、私は片方のチームの開発に取り組みながら、もう片方のチームをリードしています。 この記事では、そんな私がチームをリードするためにこだわっていることを紹介します。 この記事を通して、Speeeには新卒2年目でもこのような内容にチャレンジできる環境があることや、Speeeのエンジニアがプロダクトを作っていく中でどのようなことを考えているのかが伝われば嬉しいです。 1. はじめに：Housiiでの開発について 2. 開発プロセスのボトルネック解消にこだわる 2.1 目標達成のための戦略を立てて実行することにこだわる 2.1.1 目標を分解
役割の越境には、縦と横があるんじゃないかという話 - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar 23日目の記事です。昨日の記事はこちら こんにちは。Speeeのレガシー産業DX領域で中途採用をしている菅沢です。 最近、「役割を越境する」という言葉をよく見かけるようになりました。 私自身、営業・マーケ・PdM・HRといくつかの役割を経験する中で、役割を越境しながら仕事をしてきたタイプだと思っています。 その中で、役割を越境したことで前に進めた場面もあれば、逆にうまく噛み合わず、遠回りになってしまった経験も少なくありません。 この記事では、そうした失敗も含めた体験をもとに、 「役割の越境」をどう捉え、どう付き合っていくと良さそうかを整理します。 具体的には、 役割の越境を「横」と「縦」という2つの視点で捉え直しながら、 これまで自分なりに悩み、考えてきた経験をもとに、 AI時代になって、役割の越境がどう変わってきたのか
「できる領域」のやり方を、「できない領域」に転用する——そのために必要だったのは、暗黙知を「構造化」することだった - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar 22日目の記事です。昨日の記事はこちら はじめに こんにちは、SpeeeでHousiiというサービスの開発をしている新卒2年目エンジニアの北田です。 この1年で、事業として実現したいことの難易度が大きく上がりました。それに伴い、設計・調査の難易度も上がっています。結果として、私は「実装はできるのに、設計・調査になると見積もりが大きくズレる。対策を立てても改善しない」という壁にぶつかりました。 この記事では、そこから私がどうやってその壁を突破したのかをお伝えします。結論を先に言うと、「できる領域」で無意識にやっていることを構造化し、「できない領域」に転用することで突破しました。 同じように「できる領域」と「できない領域」の差に苦しんでいる方にとって、この考え方が何かしらの助けになれば嬉しいです。 はじめに 課題：なぜか「でき
事業を動かすエンジニアの判断軸——達成プランを軸に判断する - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar 21日目の記事です。昨日の記事はこちら はじめに こんにちは、DX 事業本部でエンジニアをしている大金です。 エンジニアとして4年目になり、純粋な技術的意思決定の枠を超えた判断を求められる場面が増えてきました。 技術的負債の解消にどのくらい開発リソースを割くのが正解なのか？ どんな人を採用するべきか？採用要件は？ 自分を含めてメンバーのアサインをどうするべきか？ 「やった方がいいこと」は無限にある。しかし、リソースと時間は有限です。 この記事では、試行錯誤を経て馴染んできた「達成プランを軸に判断する」という考え方について書きます。上記のような問いに対して、何を考え、どう向き合えばいいのか。 純粋にコードを書く以外の仕事にもどんどん役割を広げていきたい、事業を前に進めていきたいと思っているエンジニアの方にとって、少しでも助け
技術組織が事業フェーズの変化に合わせて変化してきた2年間の話 - Speee DEVELOPER BLOG
※この記事は 2025 Speee Advent Calendar 20日目の記事です。昨日の記事はこちら はじめまして。Speee リフォームDX事業部で開発責任者をしている佐藤です。 私がこの事業部にエンジニアとしてジョインしてから、約2年が経ちました。 現在は一定規模の開発組織となり、Budii というリフォーム会社向け営業支援SaaSをはじめ、複数のサービスを牽引できる状態になっています。AI で営業データの構造化を完全自動化するするといった面白い取り組みも徐々に増えてきました。 約2年前の参画当初は、プロダクトも組織も事業フェーズが切り替わる過渡期にあり、正直なところ明確な方向性が見えていない状況でした。 この記事では、開発組織が事業と並走しながら発揮すべき価値を探り、組織として新たな形を作ってきたプロセスを振り返ります。 当時の私と同じような状況で模索している方にとって、少しで
新卒エンジニアがコードレビューと設計でぶつかった壁と、その乗り越え方 - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar 19日目の記事です。 昨日の記事はこちら こんにちは、Housii でエンジニアをしている25新卒の田中一城です。 Speee に入社しておよそ9ヶ月が経ちました。 入社から1〜2ヶ月は先輩が設計したイシューを実装し、レビューをもらいながら機能をリリースする日々でした。しかし、3ヶ月目からは先輩や業務委託の方のコードをレビューする側に回りました。最近では、設計にも挑戦し、自分が設計して分割したイシューを他のメンバーが実装、リリースするまで責任を持つという役割も担うようになっています。 この記事では、新卒エンジニアである自分が、コードレビューと設計に取り組む中でぶつかった壁と、それを乗り越えるために実際に取ったアプローチを紹介します。 「Speee のエンジニアはどう開発しているのか？」「新卒でもレビューや設計をやれるように
AI エージェント開発で半年間成果が出なかった私が、前に進めるようになるまで - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar 18 日目の記事です。昨日の記事はこちら はじめに こんにちは、DX 事業本部でエンジニアをしている 22 新卒の高島です。社内ではたかてぃーと呼ばれています。 大学院では機械学習の研究をしていましたが、入社後は既存プロダクトの保守運用や新規事業のアプリケーション開発を経験しました。2024 年 11 月からは、不動産領域で AI/LLM を活用した R&D プロジェクトをリードしています。 この 1 年間、AI エージェントに関する研究開発に取り組んできましたが、決して順調ではありませんでした。特に最初の半年間は、成果が見えない苦しい時期が続きました。 本記事では、私が R&D プロジェクトで試行錯誤した経験と、そこから見えてきた「地に足をつける進め方」についてまとめます。 こんな方に向けて書いています： ゴールが曖昧な
「要件通り＝正解ではない」新卒エンジニアが学んだ、"解くべき問い"のスコープ定義 - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar17日目の記事です。 昨日の記事はこちら こんにちは、SpeeeリフォームDX事業部に2025年新卒で入社したエンジニアの小町です。 普段はリフォームの会社探しサイト「ヌリカエ」などを運営する同事業部にて、ビジネスオペレーションを技術で改善する「BizOps開発」チームに所属しています。 今回は、私がBizOps開発でやらかしてしまった「言われた通りに作ったのに、現場では全く使えない仕様だった失敗談」と、そこから得られた学びをお話しします。 「要件通り完璧に実装したのに、解くべき課題のスコープを見誤ったために、全く使えないものを作ってしまった」 設計以前の、しかしエンジニアにとって最も重要な「課題定義」における失敗です。 前提：ビジネスの仕組み 最初に私が開発を担当していたサービスの仕組みについて説明します。 当時私が担当し
マルチプロダクトSaaSにおけるシンプルな共通基盤を作るための3原則 - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar 16日目の記事です。 昨日の記事はRailsアップデートから学ぶ意思決定に根拠を持ち、残すことの重要性 - Speee DEVELOPER BLOGでした。 こんにちは、デジタルトランスフォーメーション事業本部の中嶋 学です。「ツナガル」という不動産会社様向けの業務支援プロダクトを開発しています。査定書作成SaaSや架電代行BPOサービスなど、複数のプロダクトを提供しています。 これらのプロダクトを開発する上で欠かせないのが、請求システムや社内管理画面といった共通基盤の設計です。共通基盤は、ツナガルの提供プロダクト数が増えても、メンテナンスし続けられるようシンプルな状態を保たなければなりません。シンプルに保つためにも、場合によっては再設計も必要になります。認知負荷の高い設計のままでは、変更や調査のたびに大きなコストがかかっ
Railsアップデートから学ぶ意思決定に根拠を持ち、残すことの重要性 - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar15日目の記事です。 昨日の記事はこちら こんにちは。Speeeで不動産一括査定サービス「すまいステップ」の開発を担当している中島です。 Speeeには新卒で入社し、2年目のエンジニアとして少しずつ難しい開発にも取り組んでいます。 私は新卒1年目からすまいステップの開発に携わってきました。この記事では、Rails 6.1から7.1へのメジャーアップデートを担当し、そこから学んだ「意思決定に明確な根拠を持ち、それを残していくことの重要性」の話をします。 Railsのメジャーアップデートは影響範囲が広く工数の見積もりも難しいため、どの開発チームでも優先順位の判断が悩ましいテーマではないでしょうか。 すまいステップでもEOLが迫る中、優先度を上げて取り組むことになりました。 LLMを使った調査と、根拠のない意思決定への気づき Ra
「価値のあるシステム」を作るエンジニアのスタンス - 32万レコードのログシステム設計で実践したこと - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar14日目の記事です。 昨日の記事はこちら こんにちは。Speee 24卒エンジニアの渋谷です。普段はDX事業本部で、不動産売却を希望するユーザー様とクライアント様のマッチングを支援するサービス「すまいステップ」の開発を担当しています。 2024年にすまいステップへジョインして1年半が経過しました。1年目は先輩が設計・issue分解した開発内容をリリースまで責任を持って取り組む日々でしたが、2年目になり、自分で設計・issue分解に取り組むようになりました。 この記事では、設計から携わるようになった半年間で学んだ、「動くだけのシステム」ではなく「価値のあるシステム」を設計するために必要な行動と考え方を、具体例を交えて紹介します。 実際の開発プロジェクトにおいて、チームがどのように意思決定を重ね、システム設計を進めていったのか、
AI で営業データの構造化を完全自動化する 〜基盤編〜 - Speee DEVELOPER BLOG
本記事は Speee Advent Calendar 2025 13日目の記事です。 昨日の記事はこちら はじめに こんにちは、Speee リフォームDX事業本部でテックリードをしている黒須です。 昨日は同プロジェクトの PdM である嶋さんが「AIで営業データの構造化を完全自動化する 〜プロンプトチューニング編〜」を公開しました。 嶋さんの記事では、泥臭いプロンプトチューニングについて語られています。 対して基盤編である本記事では、その裏側でエンジニアがどのようにリアルタイム処理のパイプラインを構築し、API コストやレスポンス速度の課題を解決したかについてお話しします。 目指す水準: 通話が終わった瞬間、データ入力が完了している状態 私たちが運営する「ヌリカエ」などのサービスでは、カスタマーサクセス (CS) がユーザーと電話で話し、その内容 (物件情報、予算、要望など) をシステムに
AIで営業データの構造化を完全自動化する 〜Difyプロンプトチューニング編〜 - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar 12日目の記事です。 昨日の記事はこちら tech.speee.jp こんにちは、Speee リフォームDX事業本部 プロダクトマネージャーの嶋です。 以前書いた記事、組織全体の開発スループットを劇的に向上させた「AIプランナー」とは？ でも触れたように、私たちは現在、AIを前提にバリューチェーンを再創造する「AX（AI Transformation）」に取り組んでいます。 その最終的な到達点の一つとして掲げているのが「接客の完全AI化」です。 今回はその第一歩として、外壁塗装の会社探しサイト「ヌリカエ」における 「電話営業データの、リアルタイムかつ完全自動での構造化」に挑んだ話をします。 目指す水準：「人間による修正が不要」となる完全自動化 現在、私たちのカスタマーサクセス（CS）は、通話を行いながら専用ツールで議事録を
プランナーがAIと開発してみたら、開発生産性が4倍・Issue作成時間が95%削減された話 - Speee DEVELOPER BLOG
※この記事は、2025 Speee Advent Calendar11日目の記事です。 昨日の記事はこちら こんにちは、Speeeでプランナーとしてプロダクト開発に携わっている石川澄怜です。 Speeeには新卒で入社し、今年で3年目になります。大学時代は、中世日本文学における「地獄」についてひたすら研究していました。 現在は、リフォーム検討ユーザー様とリフォーム会社様をおつなぎするマッチングサービス 「リフォスム」 のプロダクト開発を担当しています。 はじめに：プランナーによるAI開発を検討しはじめたきっかけ まずは「小さな Issue を AI と一緒に実装してみる」から始めた Git の初歩的な操作ミスから手戻りが発生 特定箇所の軽微な修正のはずが予期せぬ場所に影響する Windows環境で開発していることによる弊害 プランナーが安全に開発へ踏み込むために行った環境整備 取り組み①：V
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
