NISHIO Hirokazu
[Translate]
Xだけで足りるのか
1日の間に違う内容で2回「Xだけで足りるのか」という発言を観測したので興味深い
「Xを使ってYする」という話に対して「Xだけで足りるのか?」という質問
「Xを使ってYする」をまずやってみて、何が足りないかを観測すべきだよね?
先に色々付け加えても何が本当に必要なのかわからなくなるよね?
YAGNI原則
色々付け加えると実装コストが増えていくのだから、
MVP
を作る上でまずは最小限にすべきでは?
Tweet
Related Pages
YAGNI原則
→
未踏ジュニア
×
やりたいことがあいまいなとき
×
顧客は一種類ではない
×
似てる問題の違う解決手段を調べる
×
技術と問題解決の図
×
顧客不在のプロジェクトでもいい
×
作ることを支援するものを作るのは大変
×
「難しい」ではなく「私は簡単な方法を知らない」
×
本を手軽に送りたい
×
提案能力のサポートが必要
×
covid19下での行動は就活の定番質問になる
×
目標は修正してもよい
×
週1ミーティングのやり方
×
僕の審査の仕方
×
「やりたいけど未着手」
×
コンテスト応募者へのタイプ別のアドバイス
×
構想力は問題を限定する能力
×
product/user_fit
×
不採択は提案の否定ではない
×
mvp
×
提案書を読んでもったいないと思った部分
×
人の評価とアウトプット能力
×
強い/面白い/大事/協力したい
×
主張の整合性が気になる
×
メンターを顧客にする
×
基礎研究は顧客不在
×
未踏はアイデアコンテストではない
×
共通の審査基準があるべきか
×
チーム開発の方が個人開発よりも難しい
×
不採択フィードバックで不採択の理由を書こうとしない
×
早い失敗は有益
×
やったことない人にやりたいことを相談するとできない理由を教えられる
×
若さを称賛するな
×
ダメなところを直すのではなく良いところを伸ばす
×
一番不確実なところを最初に確認する
×
未踏ジュニア質問箱
×
なるべく多くの応募者にオーディション
×
ccが付いているメールにはreply_allが必要
×
仮説検証のリードタイム
×
プロトタイプでどんな仮説を検証するのか
×
研究も社会実装が必要
→
思考の結節点2021未踏ジュニア
→
コンシェルジュ型mvp
×
オズの魔法使い型mvp
×
mvp
×
minimum_viable_product
×
コンシェルジュ型
×
コンシェルジュ
×
オズの魔法使い型
×
中に人がいるタイプのmvp
→
コンシェルジュ型とオズの魔法使い型の違い
→
完璧主義
×
再利用性
×
汎用的
×
土台
×
抽象化の罠
×
リリース可能なコンテンツ
×
mvp
×
内部構造の美しさ
×
ユーザ価値
×
市場評価
×
アーキテクチャの収穫
→
ゲームではなくゲームフレームワークを作ってしまう症候群
→
mvp
×
pmf
×
ちゃんと
×
ファストスタート
×
捨てる可能性
→
最初からちゃんと
→
新結合
×
道のないところに道を引く
×
0→1
×
堤防に穴を開ける
×
パイプをつなげる
×
新結合と水面のたとえ
×
新結合が常に有益なわけではない
×
川を作る
×
mvp
×
ボトルネックの解消
×
1→10
×
factorio
×
プロアクティブとリアクティブ
×
誤った二項対立
×
安野たかひろ
×
tokyoai
×
安野たかひろを都知事に
×
マイナ投票
×
東京都知事選2024
×
変革期
×
再構築
×
シグナリング
×
細胞間シグナル伝達
×
シグナル物質
×
メイフラワー号
×
デジタル民主主義
×
熟議民主主義
×
多数派の専制
×
課題解決型
×
未来の東京を選ぼう
×
polis
×
僕ひとりしかいないからあらゆる複数人グループより希少
×
ファンダム化
×
日記2024-06-26
×
日記2024-06-28
×
日記2024-03-19
×
日記2023-06-27
→
日記2024-06-27
→
アジャイルな執筆プロセス
×
ペアマッハ新書
×
箇条書き
×
マッハ新書
×
共同編集
×
mvp
×
ゲーテッドコミュニティ
×
scrapbox
×
書き出し法
×
破壊的イノベーション
×
時間同期的
×
時間拘束的
×
書き散らした原稿を整理する
×
doneの定義が不明瞭
×
レベニューシェア
×
ペアプログラミング
×
ペア
×
第三者の眼
×
教育
×
執筆
×
google_docs
×
yoshifumi_yamaguchi
×
アポ取りがめんどくさい問題
×
付加価値
×
facebookグループ
→
20180504アジャイルな執筆プロセス
→
必要
×
取り出す
×
ないのと同じ
×
保管
×
情報デザイン
×
情報を、人が効率的かつ効果的に使えるような形で準備する技と知識
×
配置の工夫
×
検索可能
×
見つけられないものは無いのと同じ
×
僕のタスク管理がうまく行かない理由の考察
×
引越しを機会に捨てる日記
×
忘れ物はないのと同じ
×
遅延評価的学習法
×
YAGNI原則
×
hatena2011-01-25
×
hatena2009-10-07
→
必要な時に取り出すことができないものはないのと同じ
→
2021-05-04の日記
×
scrapboxのprivate→public転送について
×
面白さ
×
発見
×
気づき
×
自発的
×
知的生産
×
puppeteer
×
heroku
×
todo.txt
×
headless_chrome
×
研究
×
mvp
×
ブログ2.0
×
豆論文化
×
2021年4月の倉下アウトプット
×
キャンプファイヤー
×
2019年6月のアイデアライン
×
ゲーテッドコミュニティ
×
ウォールドガーデンモデル
×
ゲーテッドコンテンツ
×
組織
×
衰退
×
排除
×
scrapbox
×
yujiosaka
×
1
×
2
×
承認欲求の刺激につながる機能を全て排除する
×
はてなダイアリー
×
dotenv
×
envify
×
browserify
×
secure
×
httponly
×
requests
×
324
×
違いに気づく
→
複数のプロジェクト間のリンクを見つける
→
見積もり
×
見積もりの分散
×
コミットメント
×
分散が異なるのでは?
×
分布形状が異なるのでは?
×
YAGNI原則
×
リスク回避
×
保険
×
2点見積もり
×
くまとワルツ
×
デッドライン(書籍)
→
約束すると開発が遅れる
→
minimum_viable_product
×
mvp
×
eric_ries
×
lean_startup
×
construction,_measurement_and_learning_loop
×
dropbox
×
transistor_radio
×
vacuum_tube_radio
→
(6.3.1) Minimum Viable Product
→
コツ
×
mvp
×
締め切りと見積もり誤差
→
締め切りのあるプロジェクトの進め方のコツ
→
minimum_viable_product
×
mvp
×
最小限
×
実現可能
×
製品
×
5人テストすれば問題の85%が見つかる
×
product/user_fit
→
最小限の実現可能な製品
→
リーンスタートアップ
×
無駄
×
起業
×
イノベーション
×
エリック・リース
×
学習する組織
×
mvp
→
リーン・スタートアップ
→
仕様
×
言語化
×
mvp
→
複雑な問題の仕様の言語化
→
shimizukawa
×
mvp
×
izumi_kawashima
×
harajune
×
kaorun
×
masatsugumatsus
×
カネヴィンフレームワーク
×
loose_agilist
×
武道の理論
×
上達論
×
tyamadajp
×
programming_pearls
→
役に立たないものを作ること抜きに、いきなり役に立つものを作れるはずがない
→
mvp
×
デッドライン
×
見積もり
×
不確実性
×
締め切り
×
見積もり誤差
×
考え方
→
締め切りと見積もり誤差
"
Engineer's way of creating knowledge
" the English version of my book is now available on
[Engineer's way of creating knowledge]
(C)NISHIO Hirokazu / Converted from
[Scrapbox]
at
11/23/2025, 4:06:53 PM
[Edit]