詰め込み型のソフトウェアプロダクト開発は誰も得しない｜mtx2s

冒頭から同意しかない

チームのキャパシティを超える要求を抱えたプロジェクトが、なんの問題もなく完了するはずがありません。なんとか作り上げられた機能は、表面上は要求通りでも、どこかぎこちなさを感じます。

「詰め込み型のアプローチ」という表現が的を射すぎててつらい

一昔前に自分でPMやってた案件を鑑みると、完全にこのとおりだったかも

「成功した」ことにしたいから一通りの機能は揃ってる

リリース直後の品質との格闘を経て達成感を得る、成功体験としてのころ

そして「詰め込んでもなんとかなる」という楽観主義に

「時間でカバーする」という感覚

たぶんチームから病んでリタイアする人が出なかったら気付けなかった

まったく神が宿らない細部

とりあえずやっただけのテスト

無に等しい内部品質（そもそも当時は内部品質が何か具体的に理解できていなかった）

自分のことに手一杯でチームプレーの余地がない

マルチタスクによるオーバヘッド

目いっぱい作業効率を高めなければならないのでチャレンジも生まれない

プロダクトの目的はビジネスインパクトを作ること

それにはアウトカムを明確にし達成状況を測らねばならない

アウトプットしてやった気になっていては、いつまで経っても仕事はできない

今になってようやく理解できる（できるとは言ってない）なったが、当時はこんなこと思いも及ばなかった

https://scrapbox.io/files/67137274d17fb23d4794a592.png

アウトカム、インパクトでプロジェクトの成否を測らないから、「何とかリリースできた」だけでプロジェクトは成功した。的なお花畑が爆誕するのだろう。当時の経営のみなさま申し訳ありません。

ODSCフレームワーク

Objectives（目標）← whyも書け

Deliverables（成果物）

Success Criteria（成功基準）

視点はさまざま

財務 / 顧客 / 業務プロセス / 成長と育成 / 経営理念 / 社会貢献

なるほど

よく使うOKRや、Moonshot / 背景 / KeyAction / KeyResult と比べるとどうだろう？

OKR

Objectives / Moonshot 長期的な展望を含めて書く

KeyAction アウトプットを書き

KeyResult アウトカム / インパクトを書く

以下を意識できれば新しいフレームワークを持ち出して困惑させなくて済むかも

ODSC比で成功基準が曖昧になりそう

KeyResultで、受益者は誰か / 何がどういう状態になればよいか / できるだけ定量的に