unhappychoice.com

ソフトウェアの製品開発において、単なる人員増強が工数短縮とはならない ¹ 事実はよく知られていたり、多くの人は実体験として持っているはず。 そのことは逆の視点でみると、より少ない人数でより大きなことを成せるポテンシャルがある、とも言えるはず。

もちろんそれは、無条件に達成できるわけではなくて、そのためには個人あたりの生産性を最大限に引き出す必要がある、と考えられる。

言い直すと、本当に必要な仕事のみを正確に素早く、量をこなすことことの重要性は、従来の産業等に比べて特異に高いと言える。 特にスタートアップや、成果を期待されるスモールチームにおいてこれは顕著になってくるはず。

XXマネージャー への批判

• 単一障害点・ボトルネックになりうる
• 判断の偏り
  
  • 全員の意見をよく聞く、と言っても最終判断に偏りが生じる
  • その個人がより神に近い存在で、いつでもより最適なパラメーターで世界にフィッティングできるならもちろん別（反語）
  • 神への近さが同程度の人間が複数いるならば、それぞれの人間が同程度に意思決定したほうが、成果につながる（仮説）
    • 多くのユーザーを対象にする == ある分布に最適化する ような状況との関連性から
• メンバーの納得・自己効力感
  • 天下りのよくわからない命令を聞かないといけない
    • たとえどれだけ感じの良い言葉を用いたりしても、事実は上記
• データドリブンな仕組みにより、そもそもマネージャーでなくても客観的に判断の作業を行える
  • Highest Paid Person's Opinion²

以上から誤解を恐れず書くと、マネージャーという役職には脆弱性が多々有り、必要なのはマネージャーの存在ではなく、 チームの全員がすべてを知っている or 知れる かつ、 知っていることにより意思決定をできる状況を理想として、それを実現する仕組み、ということになる。 （すべては理想・極限なので現実には、各メンバーが形が多少異なるが、総じて面積の大きい知識量の分布を持っていること、にはなる。

要件の整理

避けたいこと

• 曖昧・客観視されない・優先度が一意ではない施策/タスクの存在
• 個人間の情報量の分布に関して
  • 中央値が小さくなること
  • 分散が大きくなること
• 同期的なフロー
• 属人化・単一障害点の解消
• 上記すべてに対する、本質的ではない解決方法（仕事のための仕事）
  • 例えば、 情報共有の場が足りないので、定例会議を開催しましょう！

達成したいこと

• より良い施策立案
  • ある課題に対する、全てのトレードオフになる要素を洗い出せること
  • それらの最適解となる施策を設計・実装できること
  • ある意味これが至上目標で、そのためにすべてを知る必要があって、知らなくて良いことなど無い
    • そのスタンスの個人の集まりが、より大きな成果をだせるはず
• 意思決定に必要な情報が
  • 公開されていること / ログとして残っていること
    • 座標空間と時間に関してスケールしている状態
  • 情報がなめらかに同期されていること
    • 会議で同期のような離散的なフローではなく
• 非同期性の最大化
  • 即時の意見表明 & 遅延評価のレスポンス
  • アイデアや議論の時間発展を推奨する³
  • 割り込みの削減⁴
• 属人性の排除
  • プロダクトを全員で所有する状況に
    • 圧倒的当事者意識
    • 分業状態だと、全体最適に目が行きにくい
  • 耐障害性の向上
  • 休みたいときに休める
  • etc...

具体的な施策

分報⁵

心理的安全性の担保のような文脈で語られたりするが、あくまで主要な役割は従来で言う報連相に当たると思っている。 Slack 等のチャットツールの登場により、報連相の頻度極限を取れるようになった現在、それをしない理由が無い、と言えると思う。

• 基本的に自分に関連する人同士（というか全員）は購読しあい、すべて読む前提
• ちょっと話したいんですけど と相手のタイミングを伺う時間で Slack に洗いざらいタイプする
  • 前提として目指している地点が全員がすべてを知っていることなので

もちろん必然的に普通の人間に求められるよりも多くのスキルが必要となる。 （ 速読やタイピング速度、曖昧さの少ない文章表現、 etc...

このようなスキルの得意不得意というのは、鶏卵問題に帰着するので、みんなで成果を最大化するためにみんなで得意になるような姿勢が必要に思う。 （非同期コミュニケーションを利用しない結果苦手だ <-> 非同期コミュニケーションを利用した結果得意だ

成果物 -> レビュー のフロー

例えば対になるアンチパターンとして、重要そうな問題が上がって来たので、とりあえずみんなで話し合いましょうのようなフローがあげられる。 この場合問題点として、

• 単にコスト（ N人 * M分 * 人件費) がかかる
• 事前の調査や、個人単位でのブレストが疎かになりやすい
  • 要するに複数人集まっても、浅い意見の応酬で一人で同じ時間ブレストするのと同じ以下の成果しか得られない、ようなことに
  • ただし、リソースが潤沢にあるチームにおいて、95点のものを99点にするために行う場合には有用かもしれない
• 機会が公平にならない
  • 発言力や流暢に喋れる力⁶が強い人に偏る
  • 物理的に参加してない人は何も出来ない
• 生ログが残らない（議事録をとったとしても）
• グループシンク、正常性や同調バイアス、 etc...
  • 対面での批判はとても難しい

誰かが成果物をつくる -> URL付きで公開 -> 必要な人数または全員で非同期レビュー のフローを採用すると、 コストとパフォーマンスのトレードオフを取りつつ、上記の問題を解決できるはず、と思っている。

レビューの手法

• しっかりとしたレビュー/コメントは、従来の傾聴概念
• しっかりレビューすること >>> 小手先の言葉の濫用
  • やたらポジティブに褒めましょうのような意見があるような気がするが、チームを対象にすると難しさを感じる
    • 誰かを褒めることは他の誰かを貶めることや、妬み/羨み⁷に繋がりかねなかったり
    • 他に、そのようなことを前提にしていることを知っていたり、認知心理学、バイアス等の知識を持っている人は、そう単純・ポジティブには受け取らない
    • つまりは、極力フラットな表現をする / 素直に良いと思ったものは良いと表現する ことで十分に思う

イシュー・チケット管理

すべての施策・タスクをシステムに乗せて、優先度順に並べる

イシューを並べかえる作業自体を誰がやるのか？という問いには基本的にマネージャー的な人の役割となるが、非同期に代理で誰がやっても良い/できるとする。 この並べ替える作業、というのは視点を変えると、優先度の順序付けという成果物の作成 -> 全員にレビューを依頼している図になっている。

• 見える化・客観性の担保
  • 一番上にあるものが次にやるべきタスク
    • 主観性が排除されている
  • 仮に異論ある人はイシュー上に意見を述べて優先度の議論につながる
    • 優先度は重要で議論すべき対象なのに、よくあるフローだと、そもそも議論にすらなれなずに (Managerの) 適当な判断が通りがち
  • 優先度に関するコミュニケーション全てを削減
    • Ex: 手空いたんですが、次何やればいいですか？（PMに向かって）

進行に応じて詳細化する

• 起票段階ではアイデアベース
• 関連データやインパクトで優先度の見積もり、並べ替え
• 実際に着手する段階で、実行者が調査・トレードオフの並び替え・実装内容決定
  • 起票段階ではそもそも優先度が決まっていないので、起票時にやるのは無駄

施策類を実行したときの副作用

• リモート可能性が副次的に上がる
  • 多分要するに \(リモート可能 \supset{適正な業務フロー}\)

その他感想

みんなでスーパーマンになってスーパーマンであるがゆえ一人あたり3000万円貰ってても問題ない状態が理想じゃないんか

— Yuji Ueki (@unhappychoice_e) October 3, 2020

• まぁもしくは週休5日で良くなる状態
• たとえば、属人化排除したり、ある意味空気のような（だが余計な仕事を産まない）仕組みをインストールしたところで、問題解決します顔の人が現れて不用意な案が採用なり、評価されがちなみたいな辛さ