2021/01/19 の Forkwell Engineer Career Study の資料です
Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ
2020 年 4 月にコロナの影響による緊急事態宣言が発令されて久しい今日この頃ですが、多くの会社でリモートワークが余儀なくされ働き方が大きく変わりました。 DeNA がリモートワーク可能な体制へと迅速に切り替えていく中で、私自身リモートワークによる業務が9割以上を占めました。私や私の所属するチームだけでなく日本中でも働くことに対する考え方が大きく変わるタイミングだったのではないでしょうか。(DeNAでは緊急事態宣言が発令される前には全社的にリモートワークがすでに可能なレベルにまで整備され、とてもスピーディーにリモートワークへと移行できました。制度や勤務体制など様々な整備をしてくださったことにとても感謝しています。) その中で、私たちがチームのコミュニケーションや課題を改善するためにどう工夫したのかをお伝えすることで読んでくださる方のチームのチームビルディングの一助にして欲しいと願っていま
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
第1回 PM Meetup by pmconf 〜ミニセッション大会〜にて、LTを行ってきました。 このnoteでは、その際のスライドの内容+時間の都合で入れられなかった内容と、当日いただいた質問・質問への回答をご紹介します。 発表スライド 以下、内容を追いながら、情報を追加してお届けします。 SmartHRのPMチームの経緯と構成 SmartHRは、2015年11月に正式リリースされ、以降続々と様々な機能をリリースし続けてきました。(手前味噌ながら)驚くべきことに、1人目のPMが入社したのは2018年末です。また、PMM(Product Marketing Manager)が社内に誕生したのは2019年7月のこと。PM × PMM体制が出来て約1年、社内でもまだまだ模索中の段階です。 またPM不在時のプロダクト開発のコアを支えていたのは、社内の労務エキスパートの方です。労務人事サービスと
Developer Summit 2020にて、「noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦」という発表をしました。そのスライドや補足など。 この発表では、下記のようなことについて話させていただきました。 ・noteチームが重視するサービスのグロースサイクルとは? ・そのグロースサイクルを円滑に回すために、開発チームをどう組織したか?データをどう活用したか? noteのグロースサイクル noteをどう伸ばしていくかが表現されたのがこのグロースサイクル図です。"ブロック"が達成したい指標で"矢印"が具体的な施策にあたります。作者が集まれば、コンテンツが増え、読者も集まり、さらに作者が増え……という構造です。各指標をバランス良く伸ばすことでサイクルが回り、正のフィードバックでどんどんグロースしていきます。 ですので、単一のKPIだけを追うことはしません。たとえば売上だ
こんにちは。GMOペパボHR統括部の前田です。 2020年1月よりペパボの人事制度が新しくなりました! そこで人事制度改定の背景やどこがどんな風に変わったのかについてご紹介します。 制度改定の背景 今回改定を行った制度は、①等級制度、②評価制度、③報酬制度の3つです。 これらはパートナーにも会社にも大きな影響を与える制度なので、HR統括部に加え、執行役員VPoEの柴田さんとデザイングループマネージャーのこたろっくさんの両名にも協力を仰ぎ2018年末頃から改定準備をはじめました。 このタイミングで制度の改定を行った背景は、3つあります。 1つ目は「ペパボ及びペパボで必要な人材像の変化」です。以前の人事制度が導入された2008年当時は、少人数で多くのサービスを運営していたため、ペパボでは、ジェネラリストが求められていましたが、サービス規模が拡大し技術やテクノロジーがより高度化する中で、求める人
はじめに プログラミングの仕事を効率的に行うためには、プログラミングの知識だけでなく、仕事の進め方も大事と思います。 10年近く前、私のプロジェクト(C#での開発業務)は自分も含めて若手が多く、次のような「仕事の進め方」の問題が多々有りました。 1つの不具合の修正に対して、10時間以上かけて実装したが、そもそも修正方針が間違っていたため、最初からやり直しとなった。 レビュー指摘の修正時に、類似の問題が他にないか横展開調査をしないため、何度も差し戻しが発生した。 そこで、当時の私はプロジェクトメンバーの仕事の進め方を改善する方法を考えました。一般的には「問題を見える化」することで問題が改善されると言われています。逆に言うと、問題は見えないままでは改善されません。 つまり、各自の仕事の進め方の良し悪しを見える化が必要でした。従って、仕事の進め方の良し悪しを測るチェックシートを作成し、その評価結
こんにちは。つよぽそです。 さて、掲題のとおりですが、1/31を最終出社日とし、2/28に楽天を正式に退職します。僕はラクマを開発するチームに所属していたんですが、そこでやってきたことや、これからを書いていこうかと。 ※最終出社日翌日からずっと体調を崩してるので遅れてしまった。。。 何故入社したのか? 実は僕は楽天に入社したわけではありません。ラクマに名前が変わる前のフリルを開発していたFablicに入社しました。なのであくまでFablicに入社した理由を書きます。 元々前職はソーシャルゲーム会社なのでゲームから離れてwebサービスをやっている会社を探していた。当時既に何社か内定をいただいていたので、最後にwantedlyをみてちょっと気になったので応募してみた。まずCTOとのカジュアル面談で何となく雰囲気の良さそうな会社だなと思ったり、技術面談でも、こちらの話しをしっかり聞いてくれて楽し
見積もりについて思ってることとかをまとめてみました。 マネージメントの実戦経験というよりソフトウェア開発手法について学んだ結果のアウトプットみたいなノリでみていただければ幸いです。 社内勉強会で話したので会社のスライド使ってますが、会社が今こうというわけではなく一般的な話にとどめています。(あとstudy_lean_agileっていう名前の勉強会なんですが、このスライドはリーンもアジャイルもあまり意識していません) 前半は自分なりの考え方、後半は具体的にはこうしたらいいんじゃないかと思っていることという風に分けています。 誰のための見積もり・何のための見積もり part1 from matsu_chara Matsubayashi www.slideshare.net 誰のための見積もり・何のための見積もり part2 from matsu_chara Matsubayashi www.s
スマホアプリの分析プラットフォーム「F.O.X」が主催する、スタートアップで働くエンジニア向けコミュニティイベント「F.O.X Meetup」の第3回が開催されました。スタートアップのエンジニアが求めるナレッジをキャッチアップ・共有し、F.O.Xの持つノウハウを公開することで業界をさらに盛り上げることを目的としている本イベント。今回は、「スタートアップのチームビルド」をテーマに、経験豊富なプロジェクトリーダー達が自身の知見を披露します。株式会社マクアケの吉田慶章氏は、「さぁ!今すぐプロジェクトリーダーに立候補しよう」というテーマでプレゼンテーションを行いました。チームの特性に合わせたチームビルディングやマネジメント手法について、自身のノウハウを明かします。 プロジェクトをリードする技術 吉田慶章氏(以下、吉田):こんばんは。よろしくお願いします。今日はプロジェクトリーダーの話をしようと思い
はじめに : Who I amこんにちは、建設×ITのスタートアップ「シェルフィー株式会社」でプロダクトマネージャーをしているShoko(@shokosuzuki1991)です。本日noteデビューしました!👏 先日参加した『建設職人甲子園』というイベントで、東京タワー建設時のエピソードが紹介されてたのきっかけに、『東京タワーができるまで』を調べれば調べるほど、すごすぎる!ヤバすぎる!となったので、今回はそのあたりをPM的な切り口でまとめてみました。 (※なるべく事実に忠実に書いてますが、一部わかりやすくする表現を優先しているところもあります。予めご容赦ください🙏) 1.構想の大胆さがヤバい 東京タワーが完成したのは1958年です。当時は爆発的なテレビの普及が予想される中で「このまま各局独自の電波塔が増えると、東京中が電波塔だらけになって景観が悪化する」という問題を抱えていました。 そ
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
ゲーム開発 プロジェクトマネジメント講座 2011年10月8日 株式会社スクウェア・エニックス CTO 橋本 善久 1 ©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか? 2 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ(コンテンツの範囲)の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース(人員・環境)の問題 • ビジネスの問題 4 ©SQUARE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く