Context

現段階の疑問

• Devの立場に立つと「売れるものを作る」ことまで意識する合理性がなさそうだが、どうするんだろう？
  • 良い実装を早くリリースする、だけで十分に負荷が高い
    • ので、それが売れる？売れない？(収益に貢献する？するとしてどれくらい？)を思考のscopeに入れてしまうとむしろ生産性が落ちる
  • 専門性として、売れる/売れないの予測に強いわけではない
    • (その予測に強い人、が世のどこにいるんだという話だが)
  • ユーザーという不確実性を仕事の対象にしたい人ばかりではないよなあ。例外的にそういう人もいるだろうけど
• Bizの立場に立っても「売れるものを作る」ことにコミットする合理性がなさそうだが、どうするんだろう？
  • 「作る」のは彼彼女ではないのに、コミットメントのしようがあるのか？責任を果たそうとすると数多の他者の手を借りないといけない人はコミットメントの主体たりうるのか？
  • 大抵のBizの人は、バックグラウンドは多様でも、業務レベルで見ると運用マン（作業に特化）か分析マン（作業に特化）上がりのことが多く、実はユーザーが欲しがるものを考えることも、ユーザーが欲しがるものを作ることにも長けていない説（あくまで説）
• ※「前のcycle/sprintでreleaseしたもの、よりは売れそうなもの、の可能性はどこにあるか」をlearnすること(≒ 探索的学習)は、DevでもBizでも可能なはずではある
  • じゃあそれに、Dev/Bizが責任を負うのか？コミットするのか？できるのか？すべきか？
• Dev/Bizをつなぐ人(PdM?CPO?事業責任者?CTO?COO?CEO?)が「売れるものを作る」文化を醸成し、みんなで一丸となってやっていくしかない、としよう。その文化を醸成・浸透・維持する責任を、特定の役職の人が負うことは「実質的に」可能なのだろうか？
  • もちろん名目上は可能だし、現にそうなっていそうではある
• Devの前段階に位置する 本当の意味での"Designer"(大抵はFounder/CEO)が負うのが良いのでは？という気がする
  • Designerの定義
    • 1. ユーザーの課題/ニーズを深く・正確に理解している
    • 2. ユーザーの課題/ニーズにfitする解決策を、実装のプロ(Dev)が実装に移れる形で、依頼できる
         • e.g.
           • モックが作れる
           • ドキュメントが書ける
           • Devとの信頼関係がある
         • 特に、ユーザーの課題/ニーズの特定に残っている曖昧さをクリアにするための検証、に必要なMVPを、実装のプロ(Dev)が実装に移れる形で、依頼できる
  • ただし、このDesignerは以下には弱いため、これを担って補完するBizっぽい人(なんと呼ぶのだろう？バックオフィス？コーポレート？)が必要
    • 課題を市場に変換することに責任を負う: その課題/ニーズは大きいか？成長性があるか？
      • 資本家の語彙が使える人、と言って良い
    • Designerが責任を負っていない他のイシュー(会計とか)の解決に責任を負う
• この「売れるものを作る」ことの責任と権限は、最初はFounderにあるが、委譲/分割可能なのだろうか？実質的に不可能なのだろうか？
  • e.g.
    • CEOは(自称)PdMに権限を委譲できるか？部分的にでもできるか？委譲することはどのような根拠を持って奨励されるか？

後で読む

• Dev目線
  • 開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察 | omuomugin
  • 開発生産性の低下による、事業の失敗はなぜ起こるのか / ProductivityPitfalls - Speaker Deck
  • 開発生産性について議論する前に知っておきたいこと #開発生産性 - Qiita
  • 開発生産性とは｜開発生産性 実践入門
  • 経営層に開発生産性向上へのコミットについて理解してもらうためには
  • 開発生産性向上へのコミットについて理解してもらうためのスライドテンプレートを作った話
  • プロダクト拡大と開発生産性｜Matsumoto Yuki
  • 生産性を測る！ソフトウェア開発の指標と活用方法  ｜PM Club
  • 開発フェーズごとの開発生産性の指標・ゴールとその理由
• プロダクトマネジメントの文脈の数多のリソース(later)
• 起業家向けのリソース
  • 「売れるサービス」を作るために調べたことメモ① #スタートアップ - Qiita
  • 「売れるサービス」を作るために調べたことメモ② #スタートアップ - Qiita
  • 「作ってから売る」と「売ってから作る」と「売れるようにしてから作る」　～技術の社会実装のための『開発』～ - Speaker Deck

別の観点: しくじってもそうそうクビにならない日本の正社員が果たせる「責任」とか「コミットメント」って何？というやや意地悪な見方

• 以下は正しいらしいけど、人間の実態を反映しているか？
  • 正解など誰にもわからない
  • だから学習量を指標にするしかなく、また、すればよい、経験主義
  • iterationの数、と、iterationごとの学習、をそれぞれが責任として負えば良い
• 人間はついつい、わからないから行動する、ことの正しさよりも、わからないからわかった気になったり、わかってそうな人に盲従することのラクさを選ぶのでは？

チーム全員で責任(Responsibility)を持つ

引用

• 一番大事なのはユーザーに価値を提供できているかどうか。「ユーザーに価値を提供できたかどうか」を直接測定するのはすごく難しいのだけれど、「サービスを契約してくれるか」「お金を払ってまで使いたいと思ってくれているか」「長く・頻繁に使ってくれているか」「人に勧めたいと思ってくれているか」などなどの間接指標によって類推することはできる。スクラムにおけるベロシティはいずれにも遠すぎる。

• プロダクトオーナーは事業上の KPI を、スクラムチームはそれ以外の何か（例えばベロシティ）に責任を持つという構造も良くない。Accountability の所在としてはそれでいいけれど、Responsibility はチーム全員で持つ。本書では、事業上のKPIを「インパクト」としている。

  • スクワッドも計画を立てる。だが、計画そのものはゴールじゃない。テック企業が何よりも大切にしているのはインパクトだ。インパクトとは、仕事の結果が何らかの形で顧客の役に立ったという具体的な証拠のことだ。
    （本書 38ページ）

Reference

• そろそろ、スクラムの先に進んでも良い - ユニコーン企業のひみつ を読んで｜Takahiro Ikeuchi

「みんなで責任を負う」と「誰も責任を取らない」の違いがわからねえ

「みんなに責任がある」話、以下のような世界観を全員で共有するのが前提になるな

世界観

• 倫理は相手によって(受け止める人によって)言うことが異なる

倫理とは？

• 自己責任論
• No God論

倫理はそれぞれに対して何を語るか？

• Aさんの世界では:
  • 倫理「全てはAさんの責任です。
    Xさんが指示に従わなかった？指示に従わない相手に指示を出して放置したAさんの責任です。従えないような指示を出したAさんの責任です。他ならぬあなたが判断し、選択し、実行したんですよね？誰もあなたにそうしろって強制してないですよね？
    Yさんが権限をくれなかった？権限をくれないような会社に入ったAさんの責任です。権限を勝ち取るだけの信頼を得られていないAさんの責任です。他ならぬあなたが招いた結果ですよね？
    Zさんに酷い目に遭わされた？酷い目に遭わされるような会社に入ったAさんの責任です。酷い目に遭わされるようなZさんと関係を持ったAさんの責任です。あなた自身の意思で契約にサインしてここで働いてるんですよね？Zさんとの関係を持つように誰かに強制されたんですか？あなたがそういう状況を呼び込んだんですよね？」
• Bさんの世界では:
  • 倫理「全てはBさんの責任です。
    Xさんが指示に従わなかった？指示に従わない相手に指示を出して放置したBさんの責任です。従えないような指示を出したBさんの責任です。他ならぬあなたが判断し、選択し、実行したんですよね？誰もあなたにそうしろって強制してないですよね？
    Yさんが権限をくれなかった？権限をくれないような会社に入ったBさんの責任です。権限を勝ち取るだけの信頼を得られていないBさんの責任です。他ならぬあなたが招いた結果ですよね？
    Zさんに酷い目に遭わされた？酷い目に遭わされるような会社に入ったBさんの責任です。酷い目に遭わされるようなZさんと関係を持ったBさんの責任です。あなた自身の意思で契約にサインしてここで働いてるんですよね？Zさんとの関係を持つように誰かに強制されたんですか？あなたがそういう状況を呼び込んだんですよね？」

• ある起業家の弁:
  • 「売りを立てる」= 売れるものを作る/作ったものが売れる相手を見つける = 0→1 は
  • 従業員に期待して良いものではない、従業員にそのスキルと経験を期待するのは間違っている
  • どこまで組織が肥大化しようと、売りを立てる部分は創業者がやるしかない
    • 勝ち筋が見つかったらスケールさせるために従業員は存在する
  • 動機づけ的な観点、即ち、従業員のインセンティブ(SO, 成果報酬)や、従業員のオーナーシップ(自己組織化)で「売りを立てる」ことはできない
    • インセンティブやオーナーシップで1を10にすることはできるが、売上0の状態で従業員に任せてしまった場合、0に何を掛けても0にしかならない

• 確率的事象（クジを引き続けたら当たっただけ）であり、経験的にのみ収束する事象（作ったものが売れたことで初めて、売れるものを作っていたことがわかる）に「責任」とか制御的アプローチを向けること自体がナンセンスなんだろうな
  • 確率を計測し、改善を試みることはできるが、確率的事象そのものを制御することはできない
  • 事後的にしか意味を特定できない事象を、事前から制御することはできない

• 責任（果たされている/果たされていない）ではなくコミットメント（している/していない）をstatusのnodeにすればいいのか？
  • 弁証法が知識をstaticなものではなく、真理へ漸近するdynamicな運動のスナップショットと捉えたように
  • teamworkはstaticなものではなく、dynamicなものなので(agile)