ホジョセンは、よくセグメンテーションのお仕事をさせていただきます。消費者・生活者をいくつかのパターンに単純化することで、クライアントさんの戦略や行動の指針とするものです。マーケティングではSTP戦略のSにあたる部分ですので、ご存知のかたも多いと思います。 これを同僚に当てはめてしまえ、というのが今回のコラムになります。社内で自分の提案を通すためにはどのようなアプローチを取るのが効率的なのか、プロジェクトマネジメントを円滑に進める上でどうコミュニケーションをとっていけばよいか、と考えた上で編み出した単純モデルです。 いろんな方といっしょに働く中で多少のアップデートはしましたが、基本的には10年以上使っているパターンです。僕の(元)同僚の皆様は何度も聞いた話だと思いますが、ご了承ください。また、このモデルに落ち着くまでにさまざまな方からのフィードバックをいただきました。諸先輩方、元同僚の皆様に

This domain may be for sale!

スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019 アジャイル開発手法を実現する方法として、もっとも普及しているのが「スクラム」でしょう。 スクラムを開発チームの単位で導入している企業は増えてきましたが、これをスケールさせる、つまりスクラムの手法を使って組織全体をより早く動かし、より早く価値を届けていくにはどうすればいいのでしょうか。 そのために開発されたのが「Scrum@Scale」フレームワークです。スクラムをスケールさせる仕組みの背後にあるスケールフリーネットワークや、大きな組織でも迅速に情報を共有する手法が組み込まれた「Scrum@Scale」について、2019年2月に行われたイベント「Developers Summit 2019」で株式会社アトラクタの代表取締役 原田騎郎氏が説明しています。 本

ヤフー時代の部下から突然メッセンジャーが。 「以前宮坂さんが緊急対応時に残して頂いた言葉を今度セミナーで使っていいですか？」 と。 リーダーの仕事はいっぱいあるけどなかでも大きな仕事の一つは重大事故の発生の時の陣頭指揮。平時は部下で回せるようにするのがマネジメントだけど、危機の時まで部下にまかせるわけにはいかない。 お恥ずかしながらヤフー在職中の22年で何度か重大事故を起こし関係者の人に多大な迷惑をかけてしまった。その度にその陣頭指揮をとった。 結果的にヤフーのなかでもっとも深刻な事故対策をやった人の一人じゃなかろうか。そのなかからノウハウ的なものがたまってきたものを部下にメモしておくってあげたものを彼は覚えていてくれたらしい。 彼いわく危機対応の時にすっごく役にたって指針になったといってくれて送ってくれた。 ひょっとしたら他の人にも参考になるかとおもって（若干訂正してますが）ここに残して

エンジニリング組織の作り方 @ Sansan Innovation Lab @yuuk1t / id:y_uuki https://sansan.connpass.com/event/125822/

みなさんこんにちは。@ryuzeeです。 スクラムの全体像を表す絵は多数出回っています。コーチングやトレーニングを生業にしている人であればだいたい何度も作ったことがあるのではないかと思います。 今日はスクラムの全体像を表す絵のうち、比較的新しいものをいくつか集めてみたので紹介します。 見出しの行か画像をクリックすると、それぞれオリジナルを公開しているページにアクセスできます。 The Scrum Framework Poster | Scrum.org ケン・シュエイバーが設立したScrum.orgのサイトで公開されているもの極めてシンプルなので汎用性は高い一方で、スクラムマスター、プロダクトオーナー、開発チームの記述がでてこないなど、要素がすべて網羅されているわけではないことに注意が必要Visual AGILExicon Essential Scrumの著者Ken Rubin氏作のもの。

はじめに ソフトウェアエンジニアリングマネージャ（以下、EM）に求められる責務は、多岐にわたっています。 流動性が高いITの業態である一方、日本型メンバーシップ雇用と米国型のJD型雇用との隙間にあって、責務と権限の曖昧な状況の中に置かれることも少なくないように思われます。 このような状況下で、メンバーからも経営からも双方にそれぞれの考える理想的なマネージャであることを求められることもしばしばあるようです。結果として、マネージャの休職など精神的なストレスも高さが問題になっています。 また、ソフトウェアエンジニアにとって、プログラミングにおけるスキルとくらべ、マネジメントに対するそれのモビリティ（会社を変えても有効であると思える程度）が低く見えると言ったことから、ソフトウェアエンジニアにとってキャリア形成に効きづらいのではないかと考えてしまうことも自然なことです。 その結果、ソフトウェアエンジ

「ぶっちゃけエンジニアリングマネージャー（以下、EM）って、どうなんですか？」 メルカリにおけるEMの役割、魅力などに迫るイベント「Engineering Manager Drink Meetup」が、2018年12月7日（金）、メルカリ東京オフィスで開催されました。現役のEMに加え、EMをマネジメントする「Engineering Manager of Engineering Managers（以下、EMofEMs）」のメルカリメンバーが登壇し、赤裸々に語り合ったイベントの模様をお届けします。 18年のキャリアから見えた、マネジメントに必要なこと 金曜日の夜にもかかわらず、40名ほどが参加。現役のVPoE（マネジメント責任者）やEMなど、第一線で活躍している参加者が一同に会し、盛り上がりを見せた今回のミートアップ。開始の時間を過ぎた頃、執行役員VP of Engineeringの是澤太志が

株式会社FOLIO にてエンジニアリングマネージャーをやっています．FOLIO では この1年間，プロダクト開発を円滑に進めるための組織を目指し，様々な試行錯誤をしてきました．その中でも，適切なチーム・グループの境界設定やミッションに基づいた組織の構造化は現在進行系で大きなトピックの一つです． Engineering Manager は Engineer のマネジメントではなく Engineering のマネジメントだ，という指摘が今回の Advent Calendar でもありましたが，エンジニアリング組織の持てるポテンシャルを十二分に引き出せるかどうかを左右する変数のひとつが「組織のカタチ」だと思います。 本稿は，10月のあるタイミングで社内に向けた啓蒙活動の際に書き出した『組織づくりを考える上で知っておく必要のある概念たち』という wiki の内容を素にしています．私が今の仕事のコン

「階層がないフラットな組織」より「階層があり、社員が自分の役割を越えて動き回る組織」のほうが強い説、を考える。 まとめ・階層がない組織にも、非公式な階層はできている。 ・平時は組織の階層を活かして動き、有事は階層を気にせず自分の役割を超えて動くような社員を増やすのが良さそう。 ・「自分の役割を越えて動く」を社員に学習させる方法があるはず。そうしないと、結局組織が硬直化する。 ・「役割を超えて動く方法」を学習してもらうために、新入社員にしってもらうことをまとめてみた。階層がない組織にも、非公式な階層はできているカヤック社外人事部の神谷さんが行った勉強会の資料から抜粋してみよう。 フラット化の課題 ・ 階層は今も基本的構造のままであり、マネージャーに権威があり、公式的な階層が無い場合でも隠れた階層が存在すること、階層を受け入れ、それを調整しなければ組織における仕事が進まないことを指摘(Levi

はじめに 「心理的安全性」とは、「対人リスクを取っても問題ないという信念がチームで共有されている状態」であるとか、「自分のキャリアやステータス、セルフイメージにネガティブな影響を与える恐れのなく、自分を表現し働くことができること」というような定義がなされています。 心理的安全性という言葉はともすれば、ただ快適で居心地のよい職場という意味にも聞こえます。そのため、ぬるま湯で緊張感のない関係性のことを「心理的安全性が高い」と言うのではないかと考えても不思議はありません。 そのため、友人関係のようにプライベートの時間を長く共有する関係になることが、心理的安全性が高いのだろうと考え、飲み会やバーベキュー、慰安旅行などを企画してみたりとプライベートでも遊ぶ機会を増やそうと考える人もいるでしょう。 いわゆる「アットホームな会社です」とアルバイトの求人記事に書かれているような状態です。こういった求人内容

このエントリは全9回を予定する18卒新人ブログリレーの第4回です！ 今回は、SUUMOのモバイルアプリ開発の現場から、企画と開発が一体となったチームでの開発プロセスについてご紹介します！ はじめに はじめまして。リクルートテクノロジーズ新人の三田涼介です。現在は不動産検索サービスSUUMOのAndroidエンジニアとして働いています。 今回はSUUMOアプリチームの開発プロセスについて紹介します。 SUUMOは巨大なサービスでありながら日々高速に改善を行っており、週1回以上の頻度でiOS、Androidの各OSでリリースを行っています。このスピード感を実現するために、開発プロセス自体も日々磨き込みが行われており、私が配属された3ヶ月前にも開発プロセスに大きな変化がありました。 この記事では、私が新人としてキャッチアップしていく中で学んだ、 なぜ開発プロセスを選ぶことが必要なのか どうやって

午前中の座学で基礎知識を得た後、午後はワークショップを通して 企画から開発タスクの洗い出しまでを半日で1周まわす研修となっております。 アジェンダは、以下となっております。 ■ 第1部： リーン・アジャイル・プロダクトマネジメント 集中講義 • 「作る」から「使い続ける」へ • 「使い続ける」実現プロセス • アジャイルとモダンアジャイル • 現代のプロダクト開発の進め方事例 ■ 第2部： 課題発見からバックログ作成へ • 顧客と課題の仮説立案 • テーマ選定 • 顧客設定 ～プロトペルソナ～ • 課題の仮説立案 • 解決策の検討 • 6コマ漫画によるストーリー作成 • 本来解決すべき課題の特定 • 解決策の検討 • 仮説検証方法の検討と立案 • MVP(Minimum Viable Product)とは • MVPの代表的パターン • MVPの検討と立案 • バックログとタスクの検討 •

つい先日、メルカリ社＠六本木ヒルズにお邪魔してきました。 今や、東京だけではなく、仙台や福岡、そしてサンフランシスコからロンドンに至るまでグローバルに組織展開をしているメルカリ。 創業期に参画し、現在は社長を務めている小泉文明さんに、従業員数も数十人から1000人以上に至るまでの組織づくりの秘訣をご教授いただきました。 メルカリ@Koizumi さんによるHR勉強会参加してきました。 コーポレート・デザインは極めて重要な経営者マターで、思想レベルから運用レベルまで一貫した骨格が整えられるとポジティブなサイクルに入れて、良い組織が良いプロダクトを創る。 そのためのHOWをたくさん頂いたので、需要あればまとめます。 — 吉兼 周優 / SHUYU（Azit） (@shuyu_y) 2018年8月28日 ツイートした通り、スタートアップの経営者として目から鱗の連続でして、このメモを自分のものだけ

僕の中で仕事人生に影響を与え続けてくれている三大COO（と勝手に呼んでる人たち）がいる。 一人目がアカツキ共同創業者COOの香田哲朗くん、二人目がフリークアウト(元)COOで現hey代表の佐藤裕介さん、そしてメルカリ社長兼COOの小泉文明さんだ。 それぞれ社長もできる人だが、COOとして事業及び組織の構築も構造的分析もハイレベルにできる。恐ろしく広域のアビリティを持ち、バイタリティとバランス感覚に優れ、超人的な仕事量をこなす人たちである。 そのうちのお一人であるメルカリ小泉さんと1on1させてもらう機会があり、その話が組織の課題に悩む他の人にもとても有用だと思ったのでメモを公開させていただくことにした。（ほんとにメモなんで乱文ご容赦ください） ツクルバでは組織・文化づくりに社をあげて徹底的に投資していく方針なので、非常に参考になった。 ＊＊＊以下メモ＊＊＊ [お題] メルカリで急激に組織を

Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address. M社のエンジニア採用について 自分がやめた時点でのバックエンドエンジニア採用フロー 各プロダクトの開発責任者1名（規模が大きい家計簿・会計は +1名）が採用担当者 応募が来たら各採用担当者が自分のチームにほしいかどうか（会いたいか会いたくないか）を決める 会いたい意思を出したメンバーからMAX4名までを面接官とする。4名以上いたらランダムで4名選出する 1名につき15 - 30分面接する（ので採用希望者は2時間くらい面接を受ける。。） 面接官は全員が面接を終えるまで、原則、評価を共有してはいけない。全員が終わったら、取る、他のチームならありえる、取らないの3択で評価を共有する 他のチームならの意見が面接官で一致してい