JaSST 23 Tohoku https://www.jasst.jp/symposium/jasst23tohoku.html
こんにちは、CPOのadachiです。 この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿しています。 この企画にも関連するのですが、最近社外の方から「SmartHR、PM多!」という感想をいただくことが増えてきました。もしPMが多い = 裁量が小さくてつまらない環境、と思われていたら心外すぎる……許せねぇ…… そこで本稿では、なぜSmartHRには25人もPMがいるのか、一体なにを作っているのか、仲はいいのか、今後どういったオポチュニティがあるのか、といったことについて説明していきたいと思います。オポチュニティは言いたいだけです。 25人は多い? 結論、そんなに多くないと思っています。 先日「SmartHRがARR150億円を突破、前年比150%で成長」というプレスリリースも出ましたが、私たちは現在ARR 150
更新情報 2020/05/20 フリープランのアップデート情報を追記 2020/06/19 YouTubeでNotion解説動画を公開(リンク) 2021/02/09 2022年度版のアップデートを公開(リンク) どうも、スワンです( 'ω') 株式会社メルペイにてデザイナーをしつつ、勉強会でグラレコを描いたり、社外でもデザインや組織づくりのお手伝いをしています。 最近はTwitter中心に生息していて、日々の考えや告知はここでまとめているのでよかったらこちらもどうぞ👇 毎日、タスクに追われる私たちへ。ポストイットに、ノートに、パソコンの管理ツール。「印刷所へ連絡」「新機能のUIをFIXさせる」「牛乳を買って帰る」と、私たちは想い想いのハードにせっせと目の前のタスクを書き込んでいきます。 「タスク管理」という言葉が浸透してもうずいぶんが経ち、あらゆる関連書籍やノウハウが公開されては実践し
どうもエンタープライズ企業の調達を刷新したい企業、Leanerの大平です。 エンプラSaaSの雄である会社の創業メンバー兼役員の方と、オンラインランチの機会があり、示唆深かったので許可をいただきメモ公開します。 ※この記事ではエンタープライズ企業は略称としてエンプラと書きます エンプラ向けにサービス開発している方の参考になったら嬉しいです! 拡散していただけると次回のやる気になるのでそれも嬉しいです(重要)! "SMBのMVP"と"エンプラのMVP"一緒にすんな当然だが、SMBとエンプラでは、業務のオペレーションや目標・ミッションなどすべてにおいて、個社性がまったく違う。 比較的、SMBでは、個社性が低く。エンプラでは、個社性が高い。 だからこそ SMBは、MVPが「画一的」で許される。 一方、エンプラは、MVPに「個別性」が求められる。 SMBは、MVPが「境域な要件」で許される。 一方
はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ
開発サイクルの終盤に近づくと「今回は優先順位の高いここまでを実装して、残りは優先順位が低いのでまたの機会にしましょう」という話になりがちだ。自分もこれまで何度もそうしてきたし、その場の判断としては正しい。が、このやり方に味をしめて常にこの調子で進めて、なんとなく上手く仕事をこなしている気になってしまうことには危機感がある。 以下、普段考えていることを自戒を込めてメモしておく。(なお、筆者の経験は toB ・Web 系・自社開発が中心なので読者の置かれている状況とは一致しないかもしれない) 優先度が低いタスクに着手する機会が一生訪れない 仮にあるタスクの優先度を下げたとする。バックログを眺めるとそのタスクに着手できそうなのは3ヶ月後だ。そして3ヶ月後、やっとそのタスクに着手できるかというと、そんなことは決してない。3ヶ月の間にそれよりも優先度の高いタスクが積まれているからだ。タスクを消化する
昨日TwitterでPMF(プロダクトマーケットフィット)に大切さについて書いたので、それについて、PMFがあるとどういう状況になるかという具体例、PMFのはかり方と見つけ方、を加えてNoteにします。この記事を書く理由は、PMFの大切さを伝えたい、多くの起業家にPMFを見つけてほしい(すなわち成功してほしい)からです。 1) 米国ではシリーズAの絶対条件がPMFでPMFがないとどんなにピカピカ優秀な経営陣でも無理。なぜならPMFが事業成功の唯一の必要条件で会社が潰れる最大の理由もPMF. PMFがあるかどうかは人に説明するものではなく、数値を見れば誰の目にも明らかなもの。Y conの教えを一言で言うとPMF見つけろ、です https://t.co/FsKxk7242d — Kenichiro Hara| DCM Ventures (原健一郎) (@kenichiro_hara) Janu
こんにちは、モノタロウの EC サイト開発グループに所属している田上といいます。 モノタロウには 2019 年に中途で入社し、入社以来ずっとフロントエンドまわりのことに携わっています。最近は開発業務ではなくプロジェクトマネジメントなどのマネジメント業務をすることが多いです。 さて、どんな企業でも、新規事業の立ち上げや既存事業の改善など、複数のプロジェクトが並行で進むことはよくあることかと思います。 しかし、それらを推進していく中で、 A プロジェクトの成果として改善した ○○ の指標が、B プロジェクトの結果によって相殺されてしまった! △ さんがいろんなプロジェクトで引っ張りだこになって、結局どのプロジェクトもその方がブロッカーとなりうまく進まなかった! みたいな事態に遭遇したことはないでしょうか? こういった「複数のプロジェクト間で目標や成果、リソースのバッティングが発生して成果が最大
データサイエンティストと機械学習エンジニアをされてきた中での経験してきたことが書かれていて、それぞれの違いもわかる良記事でした。 はじめに僕はdely, Inc.に入社した2016年から元々はずっとサーバーサイド (Ruby on Rails) のエンジニアをしていました。そして、2018年の5月ごろからプロダクトマネージャーになり、レシピ動画サービスであるクラシルのプロダクトマネージメントを担当していました。現在も新規事業のPdM兼エンジニアをしています。 昨年 (2018年) のdely Advent Calendarで以下のような記事を書かせていただきました。 駆け出しのPdMとして、右も左もわからない中、PdMとはそもそもどんな役割なのかからどのようなことをしてきたかを書いてあります。この記事から1年が経ち、駆け出しのあの時、こんな記事があったら良かったのにと思えるような「教科書」
DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。 本基準は、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。 また、本基準は絶対ではありません。誰かを攻撃したり、アセスメント結果の数字のみに注目して本質的な改善をおろそかにするためのものではありません。極めて実践的で具体的な項目で構成されているため、定期的に最新動向に併せてCTO協会のWG内で議論をおこないながら、適宜アップデートをしていくものです。
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか? 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
tl;dr 私が監修した本が出る。 私が顧問をしているクライス&カンパニーという人材紹介会社のキャリアコンサルタントが書いた本である。 クライス&カンパニーはここ数年、プロダクトマネージャーの転職支援に注力しており、日本で一番プロダクトマネージャーに詳しいコンサルタントだ。 彼らの書いた本(私も一部協力した)なので、プロダクトマネージャーを目指す人にはお勧め。 * はっきり言って宣伝です m(_ _)m プロダクトマネージャーになりたい人のための本 エンジニアからプロジェクトマネージャー・事業企画・経営コンサルタント・デザイナー・現役PMまで 作者:松永 拓也,山本 航,武田 直人 翔泳社 Amazon プロダクトマネジメントが浸透した日本の状況 プロダクトマネジメントやプロダクトマネージャーも日本にだいぶ定着してきたと思う。しかし、まだいくつもの課題がある。なんちゃってプロダクトマネジメ
50人で評価額2,100億円を越えたNotionに聞く、少数精鋭のプロダクト組織のつくりかた:連載「クリエイティブ組織の要諦」第3回 本記事は、デザインビジネスマガジン“designing”との共同企画で、双方の媒体に掲載されています。 連載『クリエイティブ組織の要諦』では、デザイナーをはじめとしたクリエイティブ職の組織作りのヒントを得るため、注目企業にインタビューを重ねています。デザイン組織立ち上げを支援してきたMIMIGURI CO-CEO ミナベトモミを聞き手に、組織デザイン/組織開発の両面からヒントを探っていきます。 第3回に登場するのは、『Notion』を開発するNotion Labs(以下、Notion)です。2020年4月に企業評価額約2,100億円に達した際、従業員数は50〜60人だったという同社(2020年7月時点)。つい先日の2021年10月9日(日本時間)には
「めちゃくちゃ勉強してソフトウェア開発も、アジャイルな開発もできるようになってきた! ところがせっかくうまくできるようになったけど、顧客への貢献にはなかなか繋がらない…」こんな悩みををよく聞きます。 この10年間でスクラムなどのアジャイルに関する情報やノウハウは増え、社会的な理解も広がり、その結果アジャイルははじめやすく、習熟もしやすくなっています。開発チームは急速に学習し、能力が高められやすい状況にあります。 ところがプロダクト価値の観点から見ると、開発チームも社内の他部署も、そして顧客も不満を持っていることがあります。せっかくアジャイルな活動ができるようになっても、プロダクト価値に繋げるまでにいたっていないことが多々あります。 本セッションでは、プロダクトという観点からアジャイルを捉え直し、開発チームや社内の他部署、顧客も満足するためのお話をします。 プロダクトマネジメントなど過去の登
プロダクトマネージャーカンファレンス 2023 Track A 15:35~ LIVE 50min プロダクトと事業を無限にスケールするための最強のロードマップの作り方 https://2023.pmconf.jp/session/zBfEEEcp 近年、多くのプロダクトマネジメントに関する書籍が執筆され、日本でもプロダクトマネジメントが定着しつつある。特に課題発見からMVPローンチ、PMFまでのプロセスは、アジャイル開発関連の書籍の拡充あって、充実してきていると言える。一方で、一度PMFを迎えたプロダクトを更に進化させるためのロードマップの作り方については、未だ確立した方法論があるとは言えず、世界中で議論が続いている。本セッションでは、従来のロードマップの課題と近年議論されている対策を振り返り、その上で、プロダクトと事業を無限にスケールするための新しい考え方を導入し、状況に合わせて変更可
こんにちは。データ・AI戦略部 SREチームの小野です。普段は部内のシステムに対し、SRE推進活動を行っています。直近では、データエンジニアと協力してデータ基盤周りの改善に取り組んでいます。 <SREの主な仕事> IaC化(Terraform/Terraform Cloud Business)の導入・推進 SLI/SLOの導入・推進 ポストモーテムの導入・推進 アプリケーションデプロイ基盤の導入・推進 ツールやAPIの設計・開発 インフラ設計・開発・運用 トイル削除・システムの自動化 データ基盤改善 一般的なSREエンジニアは、インフラ関連の業務が中心になると思います。しかし、データ・AI戦略部のSREチームは、開発を含めた幅広い仕事をします。やりたいことがあり、手をあげればそれを後押ししてくれる雰囲気の職場です。 今回は、SREエンジニアである私が、組織改善プロジェクトを立ち上げた話をお
昨日公開したこちらの記事がよく読まれているので、気を良くして第二弾。もうちょっと掘り下げて、なぜファンが大事なのか、なぜ(フォロワー数が多いだけの)ファンでもないインフルエンサー起用にあまり意味がないのかをまとめます。 前の記事の最後にも書きましたが、ファンでなくても、フォロワー数が多く、インプレッションやリーチ力が大きい従来型のインフルエンサーにも一定の「宣伝効果」はあります。 「新しいガリガリ君のXX味食いてー!」「今年の冬にスタバから出たXXラテがおいしすぎて!」などは、ターゲットが広く、全フォロワーが顧客になる可能性があるため、たとえファンじゃなくても、そしてたとえ単発的だったとしても、「広告としてのリーチ効果」はちゃんと出ます。 でも、これはあくまでも単発的な露出効果。投資ではなく費用。ストックではなくフロー。持続可能ではなく持続不能なんです。 経済的な契約が終了した時点で、その
プロダクトマネージャーに求められる本質、事業成長に貢献するための具体的な心得についてディスカッションをするイベントが、株式会社フライルの主催で開催されました。今回のゲストは、SaaSやアプリ、Web3など幅広い領域で、長年プロダクトマネジメントに携わり、プロダクト開発コミュニティ「PM Club」の運営をしている佐々木真氏。プロダクトマネージャーに必要なスキルや考え方を語りました。全5回。2回目は、佐々木氏がPMスキルの言語化に挑戦している理由について。前回はこちら。 「課題を特定する」ためにPMがやるべきこととは? 財部優一氏(以下、財部):「課題を特定する」というのは、具体的にプロダクトマネージャーはどんなことをするべきなんでしょうか? 佐々木真氏(以下、佐々木):例えば、「プロダクトを作る」と一口に言っても考えることがけっこういっぱいあるんですよね。まずは、ユーザーを決めなければいけ
以前「プロダクト企画にエンジニアを早めに巻き込む(嫌がられずに協力を得る方法)」という記事を書きました。 ykmc09.hateblo.jp 「TL;DR : ひとことでいうと」を抜粋すると以下のような感じです。 決定事項になる前に早めに巻き込もう 巻き込むときは、 その意図や相手に期待することを伝えよう 特性を理解して、ちょっとした工夫(最初の一声はチャットなどの非同期コミュニケーションを使う、etc)をしよう この記事では、「はやめに巻き込もう」ということを中心に書きましたが、最低限こういったことを考えて書いておくと、話がよりスムーズになるよ、というものを挙げてみようと思います。 プロダクトマネージャーが用意するリスト 目的の概要(なぜそれをやる?)※もっともだいじ。これが無いとかなりキツイ。 誰のための企画?(基本はエンドユーザーになる。) その人のどういう課題を解決したい? その課
顧客に「要望を聞いて」機能開発してしまっていた過去 解像度を高めて“評価される開発”になるための3つの取り組み 新PdM組織での顧客解像度の上げ方 植木氏の自己紹介 植木遼太氏:私からは「新PdM組織で実践した顧客解像度の上げ方」というテーマで発表します。簡単に自己紹介をしてから本題に移らせてください。 私は植木遼太と申します。先ほどの紹介にあったように、今現在は「楽楽精算」のPdMをしています。約2年前に入社しています。キャリアとしては2010年に新卒からインフラエンジニアとしてスタートして、その後、プロジェクトマネージャー、プロダクトマネージャーと役割を変遷させていったかたちのキャリアを歩んできました。 顧客解像度向上のための取り組みBefore/After では本題に移ります。先ほどのテーマにあったように、「顧客解像度の向上って」という話があります。発表の流れとしては、「そもそもこの
ツイッターで偶然見かけたプロダクト開発に関する一連のツイートが、プロダクトチームと経営陣、あるいは開発メンバーやプロダクトマネジャーの間に起きる摩擦を見事に言語化していました。 As they grow in size, teams within megacorps and startups tend to implicitly bias more towards Project Thinking and not enough Product Thinking. Product Thinking is a mindset and a process that, once you see, you cannot unsee it. Product Thinking, Project Thinking, a thread: pic.twitter.com/rbY80wTVgE— Shreyas
2023年12月は、『TBS NEWS DIG』や『PIVOT』なので動画が立て続けに出るのですが、動画だけでは話しきれなかった部分があるので、今年1年間で考えてきたテーマについて、本記事で書いていきます。 問いとしては、下記の5つを網羅したものとなります。 ① なぜ働かない社員が生まれるのか?(静かな退職/逃げ切り社員問題) ②「多様性」を推進しても、逆に亀裂が生じるのはなぜか?(フォールトライン問題) ③ メガベンチャーやブランド化した企業はなぜ衰退するのか?(◯◯Wayの絶対視) ④ 自社愛が強い人ほど、企業を滅ぼしてしまうのはなぜか?(盲目的自社愛) ⑤ メディアで持て囃されている企業から衰退していくのはなぜか?(メディアトラップ) そして、結論というか総括として、下記の画像に集約される現象が発生し、組織が硬直化していくという話をします。 8000文字くらいあるので、10分くらいは
この記事ではメルカリという会社で4年ほどプロダクトやマーケティングの分析、グロースなどをやっていた僕( hik0107 / hikaru )がそこで得た学びをまとめておこうと思います。 金曜の夜だしこれまでの学びをまとめてる。自分がメルカリにはいる前に知っていれば、同じ成果を出すのに20%位の時間で出来たであろう、そんな圧倒的な知見たち。まあ、それを肌身を切って知るということが大事で、はじめから紙の上の知識として知っていても意味はなかったりする側面もあるのですが pic.twitter.com/jV1ZgHr0u5 — hikaru / 樫田光 (@hik0107) December 24, 2021 特に「こうやったらうまく行った」というよくある成功談ではなく、 「これをわかってなかったために時間を浪費した」 「結局の所、これが一番大事という当たり前の結論に達した」 などという"知ってい
はじめに 私は事業会社(楽天→スタートアップ)でUXライティングを専門としてプロダクトの開発に携わっています。しかし、事業会社で私のような専任のUXライターやコピーライターを雇用している企業は決して多くありません。 多くの場合、UXデザイナーやUIデザイナー、エンジニア、プロダクトマネージャー、マーケターなど、UXライティングに比較的近い立場の方が、自分自身でUIテキストを書かなければならない、というのが実情だと思います。 そうした状況で試行錯誤されている方に向けて、自分に何かできることがあるのではないかと思い、このnoteを書くことに決めましたら。私がUXライティングの知見をしっかりと整理して伝えれば、役に立つのかもしれないと。 このnoteでは、私なりの実践的なUXライティングの方法論を言語化します。あくまで私が実践しているものなので、考え方もやり方も違うし、こんなのUXライティングじ
2008年にサンフランシスコでスタートしたTwilioは、音声電話やSMS(電話番号宛テキストメッセージ)のプログラマブルなCPaaS(Communications Platform as a Service)です。電話の自動発呼やSMSの送受信ができるAPIを提供し、ソフトウェア開発者がさまざまなコミュニケーション手段を自作のプログラムに組み込めるようにします。 こういったクラウドサービスは、一般のエンドユーザーに向けたサービスを展開したい事業者によって利用されるため、多くの開発者に受け入れられなけばなりません。APIを利用して新たなサービスを作り出す開発者と良好な関係を構築し、顧客である事業者それぞれのビジネスを成長させるポイントは何でしょうか? KDDIウェブコミュニケーションズ(以下、KWC)でTwilioのエバンジェリストとして活動し、赤い芸人とも呼ばれる高橋克己(@_katsu
かつてコンサルタントだったころ、私は会社の命を受けて、何回か「新規事業」の立ち上げを試みたことがある。 ほとんどは失敗したので、新規事業の立ち上げについて、偉そうなことは何も言えない。 ただ、その経験は、決して無駄ではなく、大変役に立った。 特に、私の中に残ったのは、「「買いたい」という言葉が、まったくあてにならなかった」ことだ。 * 私が初めて新規事業を立ち上げようとした時のこと。 私は一般的な教科書に載っている通り、事業計画を作り、そして、市場調査を次に行った。 具体的に言えば、新しい商材に関して、「アンケート」と「ヒアリング」をマメにやった。 「こんな商品があったら、これくらいの価格で買いますか?」 「こんなサービスについて、どう思いますか?」 「このような商材は、貴社のニーズを満たしますか?」 といった具合だ。 この段階で、反応は極めて良かった。 「ほしい」 「買いたい」 「ニーズ
こんにちは。株式会社プラハCEOの松原です。 弊社は主にスタートアップの新規事業に特化してデザイン・開発をするものづくり集団です。 最近改めて「プラハでエンジニアとして働く上で最低限必要なスキルって何よ?」という話になったのでリスト化してみました。 ついでにそれらにまつわる知識をうまくまとめてくれている情報源を追記しておくので、何かしらの学習素材として使っていただけると幸いです。 前提 前提として弊社が相手にしているスタートアップや新規事業の開発においては とにかく速く仮説検証し続けること が重要なので、継続的に機能改修しやすい柔らかなソフトウェアを作ることに重点が置かれています。他の事業であれば他のスキルが重視されますし、これらが新規事業の開発において絶対の指針だと言うつもりは全くないので 「あ〜新規事業の開発を主に手掛けているプラハっていう特定の会社(N=1)ではこんなスキルが求められ
はじめまして!estie(エスティ)取締役の束原です。 現在私は10名程度のチームで新規事業の立上げに奔走しているのですが、本記事ではその中で発生した問いと学びについて書いてみました。 元は社内向けに書いた記事ですが、現在PdMや事業開発、事業責任者をやっている方や、今後やっていきたい方の参考になれば嬉しいです。 この記事で分かること estieにおいてPdMと事業開発が2つ役割として存在する意味 サービス立上げや大規模な機能開発を行う際に、PdMと事業開発がestieで大切にして欲しいポイント 結論 「どこまでがPdMの仕事で、どこからが事業開発の仕事なのか」という問いに答えはなく、必ずしも仕分けすることはできない 従って、あらゆるチームに適用可能な責任範囲を予め設定する必要はなく、アサインされる人の得意分野によって流動的に設定すれば良い 事業の立上げやグロースには、「リーダーシップ」と
みなさんこんにちは。@ryuzeeです。 スクラムにおいて、プロダクトオーナーはとても難しいロールですが、これからプロダクトオーナーになりたいと思っている人(だけでなくすべてのプロダクトオーナー)向けの「Do You Want to be a Product Owner? You Better Know What Awaits!」という記事が素晴らしい記事だったので、翻訳したものをご紹介します。 翻訳に際しては、著者のDavid Pereiraさんに快諾いただきました。 なお、著者のDavidさんはほかにもスクラムに関する有用な記事を多数書いているので、参考にするとよいかと思います。 以下翻訳です。 私がプロダクトオーナーの旅を始めたのは2012年のことでした。 そのときにプロダクトオーナーが何を意味するのか知っていればどれだけ良かったことか。 そうすれば毎日をもっと簡単に過ごし、多くの問
みなさんこんにちは。@ryuzeeです。 技術顧問先からの依頼でプロダクトオーナーのアンチパターンについて話をしたので、そのときの資料を公開します。 今回紹介するのは以下の6つのアンチパターンです。アンチパターンに陥っている可能性を示す兆候もあわせて示しています。 顧客やユーザーの軽視 兆候 社内のミーティングでスケジュールが埋まっている 機能の必要性の根拠はユーザーからのフィードバックではなく仮説(というか妄想)にもとづいているものが多い ユーザーがプロダクトを触っているところを見たことがほとんどない 不十分なステークホルダーマネジメント 兆候 ステークホルダーをスプリントレビューに招待していない ステークホルダーと個別にコミュニケーションしていない ステークホルダーに何か言われるとすぐに対応している 「◯◯さんの指示なのでやらないといけない」のような口癖 不在がちなプロダクトオーナー
moat /moʊt/ [名] (都市・城壁の周囲に掘られた)堀 Moat(モート)とはウォーレンバフェットと盟友のチャーリーマンガーが様々なインタビューで繰り返し繰り返し述べている事業において最も大切な概念です。 僕が投資家として、最も時間と思考を費やしている対象もMoat(モート)です。 バフェット/マンガーにはMoatについてのいくつもの引用がありますが下記の質疑応答の一部がわかりやすいです。 The most important thing, what we're trying to do is to find a business with a wide and long lasting moat surrounded and with protecting a terrific economic castle with an honest Lord in charge of t
私 (@kossmori) が働くアメリカのスタートアップでは、どんな会話においても ”Is there a design doc?” (デザインドックはないの?) という質問が連発します。 会話のコンテクストを合わせるため、取り組みの背景を理解するための必須資料として位置づけられています。 デザインドックは技術詳細を書いた仕様書ではありません。 取組みに関わる Why, What, How と、ハイレベルな実装戦略、主要な設計上の決定、決定の際に考慮されたトレードオフに重点を置いて文書化したもので、それをもとにエンジニアは必要に応じてTech docを書き、デザイナーはデザインを始めます。 追記: その2も書きました。最後の方に記事へのリンクを貼っています。 追追記: 思った以上に反響あり、この記事のおかげでこれまで非常に多くの スタートアップの方々とお話しさせていただく機会をいただき
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く