これは Recruit Engineers Advent Calendar 2022 - Adventarの13日のエントリーです。（書いているのは21日です。） 1. 納期コミットのオーダーは結果的に納期を遅らせる 先日、興味深いエントリーを読んだ。 bufferings.hatenablog.com これにつてはほぼ同じようなことを社内のtimesチャネルでも会話しており、スケジュールへの向き合い方についてメタ的理解に昇華させたい。 我々が納期をコミットしなさい、確実に守れる日を教えてと言われたときにやることは、、、 確実に納期を守れるように、余裕をみる。である。 ------------------------------------------------------------ ■：実作業日（問題なければできそうな工数） □：バッファ日（例えば50％の確率で問題おきたときに使う予

7. リソース効率性とフロー効率性 A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C A A A A A A A A A A A A A A A B B B B B B B B B B B B C C C C C C C C C 月　火　水　木　金 月　火　水　木　金 月　火　水　木　金 月　火　水　木　金 月　火　水　木　金 月　火　水　木　金 リリースまでのリードタイム 1w リリースまでのリードタイム 約2w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w A機能、B機能、C機能の実装それぞれ15人日かかる場合 A A A B B B B B B

DevLOVE200 Bridge の登壇資料です。 https://devlove.doorkeeper.jp/events/60269 デブサミの以下の資料の焼き直しです。 https://www.slideshare.net/i2key/devsumib

「再発防止策はチェックリストによる目視確認」 開発の現場において、大きなシステム障害が発生したような場合に原因究明から今後の再発防止策を検討することがよくあるかと思います。 そこでよくある議論として、 とあるエンジニア「エクセルでチェックリスト作って今回の確認観点を追加します！今後はリリース前確認でかならず目視でチェックリスト確認を実施します」 ベテランエンジニア「んなことやってたら、チェックリストが永遠に増えていくからやること増えるだけだろ。もっと工夫なさい。チェックの自動化をしなさい。」 みたいな光景です。 ただ、これ実際に再発防止の効果が出るまでのリードタイムというポイントで見ると一般的にスジが悪いとされているチェックリスト的なやつですが、とあるエンジニアの案ほうが今すぐ対策を講じることができるので良かったりするなあと最近思うようになってきました。あくまで暫定的な再発防止対処としてで

10. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェ

THE STARTUP WAY THE STARTUP WAYはLEAN STARTUP著者のERIC RIESの最新刊になります。ERIC RIESがLEAN STARTUPの考え方を大企業に適用させる場合の考えかたについて記載されています。前作のLEAN STARTUPを読まれて実践されている方をベースに読んでみたまとめを書いてみます。英語は苦手オブ苦手なので、誤訳というか誤理解もあるかもしれませんが、全体の雰囲気が伝わればよいかなくらいの期待値でおねがいします。大企業でリーンスタートアップを実践している人には伝わるとは思うので。 なお、フランクにではありますが、エリックからは本中の図の引用の許可は頂いております。 Yes please do— Eric Ries (@ericries) 2017年11月26日 概要 大企業も従来のマネジメント方法だけでは不確実性に対峙する際に立ち行か

2. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 品質 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセル/クロスセルに向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 開発 モデル例 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証

先日、開催された XP祭り2017 にて発表してきました。スライドは以下になります。 フロー効率性とリソース効率性について #xpjug from Itsuki Kuroda www.slideshare.net また、上記発表のベースは以前のポストである「 フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ） - @i2key のBlog 」がベースとなっております。また、Slideshareに上げたスライドが画像が若干ガビガビになってて見にくいので補足がてら要点だけ記載します。（と思ったら、元のポストより完成度高まってしまった。ので今後、誰かに説明するときはこっちをオリジナルにしよう。。。。） フロー効率性とリソース効率性についてかんたんな説明 リソース効率性について リソース効率を高めるということは稼働率を100%にあげていくことであり、リソースに空き

XP祭り2017のセッションのスライドになります。 http://xpjug.com/xp2017-session-a5-1/ 元ネタは以下です。 http://i2key.hateblo.jp/entry/2017/05/15/082655 ※CCPMの表記について一部誤解を与える部分がありましたので、表記を削除いたしました。 2017/09/21 0:27Read less

DevLOVE200 Bridge の登壇資料です。 https://devlove.doorkeeper.jp/events/60269 デブサミの以下の資料の焼き直しです。 https://www.slideshare.net/i2key/devsumib

DevLove関西のイベント、リンスタ関ヶ原（新大阪の変）にて発表しました資料です。 https://devlove-kansai.doorkeeper.jp/events/57834 Read less

Nintendo switchの初期不良を引き当てたので、ゼルダをやるために開けておいた予定がなにもすることなくなってしまったのでブログを書いた。私のswitchは今頃京都にあるでしょう。 Developers Summit 2017 でコンテンツ委員しつつ登壇もしてきた もともとは、デブサミオーガナイザの鍋島さんからコンテンツ委員としてお声がけ頂き、今回はコンテンツ委員という立場でデブサミに関わっていました。 そのため、コンテンツ委員が登壇とか自作自演感甚だしいので自分が登壇するつもりはまったくなかったのですが、GuildWorks -ギルドワークス-の市谷さんから越境をテーマに株式会社ヴァル研究所の新井さんと自分の3人でやりませんかとお誘いを受け、以下で登壇することに。 「新規事業が対峙する現実からエンジニアリングを俯瞰する」 新規事業が対峙する現実からエンジニアリングを俯瞰する #d

Developers summit 2017の 【16-B-7】セッションのスライドです。Read less

このブログは Recruit Engineers Advent Calendar 2016 - Adventar の12/7の記事になります。 はじめに 現在、新規事業開発部門にて、いくつかのチームの開発リーダーをしていまして、その中でチームの目標を決める中でグロースフェーズにおける開発チームの直近のやるべきことを洗い出したので、アドベントカレンダーのネタにさせていただきます。 前提として、本ポストで対象になる新規事業は下記の投稿における分類で言うと「エンジニアの書いたコード上で売上が立たないビジネスモデル」になります。そのため、エンジニアリングでKPIを向上させ売上に寄与するような一般的なグロースハッカー的な動き方についてはスコープ外です。詳しくは下記リンクをご一読ください。 i2key.hateblo.jp 現在のビジネスステージ 上記はAsh Maurya氏のRUNNING LEAN

本ポストは特に私が所属する組織の見解ではなく、私が今までの経験＆自分がチームを作るときにチームの目標を考えたり、組織内にアジャイルを導入したり、組織内での開発チームの位置づけをどうするかなどなどを考えるときに意識していることですのであしからず。 内製化や、アジャイル化のビジネス上の効果を得やすい部分をビジネスモデルから考える 昨日、プロダクトオーナー祭り2016で「DevOpsとリーンスタートアップ時代のプロダクトオーナーシップ」というセッションでパネルディスカッションに登壇させていただきました。 postudy.doorkeeper.jp そこで内製化や、アジャイル化はどの部分からやるのがよいかみたいな話の流れかなにかで、「System of Engagementでなおかつ成果課金のようなエンジニアの書いたコード上で売上が立つモデルだとエンジニアリングが直接売上に寄与しやすいためビジネス

DevOpsはエンタープライズのスタートアップへの憧れ と、楽天の川口さんが言ってたなーなるほどなーと今になってしっくりきてたのでブログを書いてみる。んで、ブログ書くために、あれ？そもそもあってるっけと思いFacebookストーキングしたら違ってた。 "DevOpsはエンタープライズからスタートアップへの横恋慕" by 川口さん と言われていた模様。うーむ、横恋慕のほうが味わい深い・・・。 そして、早速タイトルを修正した。先行きが不安だ。ちなみにかなり長めのポエムなので時間のないかたはそっと閉じて頂ければ。 自分自身が長いこと新規事業畑にいたこともありDevOpsへの関わり方として、エンタープライズな状況下（Dev部門、Ops部門、ビジネス部門、...and so on）においてDevOpsをしたというよりも、サービスをゼロから立ち上げ、グロースする中でのDevOpsという経験が強く、最近

リンスタ関ヶ原での発表内容です https://devlove.doorkeeper.jp/events/39345Read less

Scrum概論 1. Scrum概論 Ryutaro “Ryuzee” YOSHIBAhttp://www.flickr.com/photos/john_scone/493915787// 2. 吉羽龍太郎 アジャイルコーチ 認定スクラムプロフェショナル(CSP) 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) http://www.ryuzee.com/ 野村総合研究所等を経てベンチャーのCTOhttp://www.flickr.com/photos/adforce1/2539903964/ 3. 企業のおかれた状況• ビジネスの環境の変化• 迅速な意思決定と具現化が求められる• 変化しないことは市場から見捨てられるリスク がある• 顧客自身が変化していくことが強く求められる• IT投資の目的の変化 – 業務効率化から戦略実現へ – いままではコスト削減、業務