長らく放置していたNotionからSlackに届く更新通知がノイジー過ぎる問題を解決することをきっかけに、非同期のデイリースクラムを実現したい。

複雑な環境だったり、複雑なサービスを開発しているチームであれば、早期に問題を察知するために、15~30分程度のデイリースクラムを設けているはずです。
私たちもそうですが、デイリースクラムが逆に徒労感を生むこともあり、朝会を撤廃し、非同期でも適切な報連相ができ、必要な時に必要な会議ができる社内システムを開発したいと思います。

まず、Notionの更新通知をクリーンにするGet Notificationが実装されるらしい。待望の機能だ。昔から噂が出ては消えるを繰り返しているが

引用：@shogocat

プロジェクトマネジメントの定義を立ち返る

プロジェクトマネジメントは、目標設定を抜きに語ると「正しく早く実現すること」に重心があります。（目標設定は成果物の投資対効果を大事にしています）

添付図では事業開発と呼んでいますが、予測値から設定した目標値と実測値のズレを埋める作業全般がマネジメントの仕事です。

フィットネス大手企業のDX推進していた頃に定義した、懐かしのもの

これを操作可能変数の範囲内で扱おうというのがスプリントと呼ばれる単位です。
例えば、アジャイル開発で使われるバーンダウンチャートなどが最たる例で、予測可能な1~2週間でプロジェクトを分割して制御します。

引用：バーンダウンチャート

どのような手法を取り入れるにしても、まずは正しく早く実現できているかを測定するダッシュボードを用意する必要があり、ダッシュボードを介したコミュニケーション（≒デイリースクラム）では遅延リスクの制御を頑張ることが大切です。

引用：【簡単解説】スクラム開発で実施する5つのイベントの概要と目的

私たちは

• プレイングマネジメントの
• リモートワークで
• フレキシブルプロジェクトを扱っている

ようなチームです。要は、物理的な距離がありながら、背中を預けてぐちゃぐちゃに仕事しているということなのですが、出来る限り報連相を簡略化して、それぞれの本来の役割やKPIに集中できる環境をデザインしたいというのが本音です。

「あれやった？」「どうなった？」というような確認は不毛で、デイリースクラムと呼ばれている進捗共有だけの会議は撲滅し、必要な時に必要な会議ができるようなチームを目指したい。もちろん、同期的な会議の価値はあるが、あえて非同期に拘りたいです。なぜなら、ピープルマネジメントはめんどくさいから

ただ、あくまで理想とするのは非同期でも自律的に駆動するチームを支えるソフトウェアであり、管理を厳格化するためのものではありません。

ここまでの検討をまとめると

1. 制御可能な期間や規模で「正しく早く実現すること」を繰り返すのが、アジャイルである。
2. 納期と成果物を定めた後は、遅延リスクが高くならないことが目的となる。
3. タスクごとの遅延リスクの可視化は担当者を介する必要がある。

の3点に収束されました。

3を実現するには、都合の悪い情報を伝えやすいことが体験として必須になる。要は「もしかしたら遅延するかもしれないので、対応策を考えたいです」という相談が早期にシェアされ、開催された臨時会議にて原因と対策が話し合えば良い。

「報連相はルールではなく、マナーである」という紳士の名言もあるが、ひとまずドレスコードは守られないことを前提にシステムを設計する。システム設計は人を信用しないことが肝だ。

同期的な進捗共有で担保されていた「真実の誤魔化しにくさ」や「嘘の分かりやすさ」が失われることになりそうなので、非同期でも言葉に重みを持たせる体験が必要になる。

言葉の重みと伝えやすさの2軸図における同期的会議のポジショニング

この2軸図では同期的会議に軍配が上がっているのだが、「めんどくさい」というz軸が私を駆り立て続けている。

話は変わるが、進捗を共有されたときに「こいつ嘘っぽくね...」などは分からないが、見立ての適切さを追求することで「都合の悪い情報を隠していた（かもしれない）か」を調査することはできるようになるので、見立ての精度向上をコア体験に設計すれば使えるものは完成しそうな気配がする。

順序が逆転してしまったが、そもそも「なぜ非同期会議に拘るのか」を探求して私自身のインサイトを発掘していく。前項で「めんどくさいというz軸」と表現している深層心理のこと。

まず、私がピープルマネジメントを避ける深層心理をじっくり振り返ってみると「冷徹な管理者になって敵になりたくないから」が言葉として浮かび上がってきた。これは私自身の囚われが大いに影響しており、これまでに冷徹な管理者が結果的に許された試しがないことを学んだと思われる。

重ねて、私は短絡的で余裕がない（かつプレイングマネジメント）ので「貴重な私の時間を他人の自律に使いたくない」と苛立つことも正直多いと思う。これは、自律を前提（≠理想）にチームを構想しているからこそ生まれている感情。具体で言えば「1on1したくない」とか。

すべての我儘を叶える体験は、こんなものかもしれない。

• 共有された見立てから、遅延リスクの高いタスクが議題化してミーティングが設置される。
• 遅延や納期調整の有無と見立てを統合分析することで、見立ての精度が可視化される。

特に、見立て精度の可視化で「実は、気付いていた遅延リスク」を隠すことのデメリットが大きくなることで、例え都合が悪くても率直な見立てを吐露しやすくなるのではないか。

そうすることで、担当者が介する人為的リスクを下げながら遅延リスクの可視化が実現できるのではないだろうかという思考実験でした。実証実験に移ります。

ひっくるめて、仕事でメンタルヘルス不調を起こす問題を解決しながら、生産性向上を両立するPM Assistant Pluginを開発したいと思っている。

ブラック企業から転換を図るパートナーと連携して、厳格な管理体制を招くことで、パワハラや鬱、生産性低下が生じてしまう状況の改善を目指しています。API連携だけで導入でき、マネージャーレスでマネジメントを実現できるチームの管理・配置を最適化できるチームアッププラットフォームを開発しています。
この事業領域は夥しい数の競合がいるので隙間を縫う意味でpluginと表現していますが、紙芝居とMVPで営業してきた所感は「参入角度は大筋正しく、惜しいところまで来ているのではないか」です。適宜オフショア開発を活用しながら、私自身もバックエンドを担い開発を進めています。
引用：2022年の振り返り | 起死回生

あれこれ整理していると、すごく簡単な図に収まりました。

非同期で担当者を介する遅延リスク可視化の体験の流れ

これを軸足に円滑な体験になるよう枝葉を詰めまくると、こんな感じでしょうか...？すべてを実現する想定ではありませんが...

しっかりと業務管理がされている前提で、日常的にすることは「タスクごとの見立てを答えること」だけなので私たちのチームを思うと大分ヘルシーな習慣に落とせた気がします。

では、「どのような見立てを、どのように回収するか」「どのよう結論を出す会議を開催するのか」を検討してみたいと思います。

どのような見立てを、どのように回収するか

すごく便利なEvidence Based Schedulingを紹介してもらったので、独自に見積もりと見立てを分けて検討します。

You can also look at the distribution of possible ship dates for each developer:

• 見積もり：着手前に「何時間（≠何日）かかるのか」を推測したもの
• 見立て：着手中に「納期に間に合いそうか」を推測したもの

上記から、EBSは「見積もり」に、本稿は非同期デイリースクラムの実現を目指したものなので「見立て」に焦点を当てていると位置付けます。この見立てをSlack Botから連続値の選択式で回収し、解析・改善することを可能にしたいです。

どのよう結論を出す会議を開催するのか

下記のいずれかを見直して修正した結果をNotionに議事録として、Databaseにレコードとして記録することで、見立てと同様に解析・改善することを可能にしたいです。

• 優先順位：並行作業がある場合、取り掛かる順序を検討します
• 作業方法
• 担当者
• 担当者数
• 納期
• 作業時間：いわゆる残業です
• 目的：要求や要件の見直しを行います

引用：タスク管理についての個人的まとめ

ここまでの検討を踏まえ、見立てを共有するシーンをUIに落とし込むと👇のようになりました。

タスクごとに2問を答えて、臨時会議まで到達する流れ

社内で運用する分には支障がなさそうなので、ユーザビリティを損ねるシーンがないかを探索します。

1. 不要なタスクの見立てを聞かれている
2. 見立てを共有したいタスクがない
3. 伝えたい選択肢がない
4. 選択肢が選びにくい
5. 口頭で済ませている

見立てを共有するタイミングを朝昼晩の3回/日にしていると、特に1のケースが起こりそうですが、朝の段階で昼までに完了（着手）するタスクを選ぶことで回避できると想定しています。

システムを（表層的に）ハックされるケースとして、「共有された見立てはネガティブなものばかりで、結果としても遅延や納期延長が繰り返されている」は発生しそうです。

これには幾つかの要因が想定されますが、多様な文脈を踏まえてコミュニケーションを図る必要があります。

• 共有されていないタスクが存在しており、実は忙殺されていた
• 割り込みタスクが多く、実は忙殺されていた
• 短納期で実現が不可能な見積りになっている
• タスクを割り当てる際に、作業手順を明確化していなかった
• 担当者のスキルセットがタスクの難易度に噛み合っていない
• エンゲージが極端に下がっている

また「遅延を恐れて見積もりを肥大化させ、アラートを出し続けて予防線を張る」ケースもありそうですが、これの解決はだいぶ難しそうです。上記の想定要因を踏まえた1on1しかなさそうです。

臨時会議が発生した際の日程調整や議事録作成までの流れは、追々シームレスにしていくとして、想定通りの有益なダッシュボードを作れるのかを探索してみます。

このシステムにsakura3（さくらさん）という名前を付けるとして、まずはsakura3で生みたい価値を再整理します。

sakura3のエレベーターピッチ

非同期でも自律したいチームを作りたい
プレイングマネジメントのリモートワークで、フレキシブルプロジェクトに取り組むチーム向けの
sakura3という名のPMアシスタントツールです。
これは、高精度な見立てを実現する過程で、自然と率直な意見を伝えやすくなることができ、
定例会議の同期的なデイリースクラムとは違って、
高遅延リスクだけを議題化し、必要な時に必要な会議を実施できる機能が備わっています。

ダッシュボードから知りたいこと

「見立てと進捗の相関性は高いのか」「議題と決定事項の相関性は高いのか」を知りたい。前者で言えば、こういうのを分類できれば良さそう。

見立てと進捗の相関性は高いのかを調べてみよう

議題と決定事項の相関性は高いのかを調べてみよう

見立てと進捗の相関性は役立ちそうやけど、議題と決定事項は使うのは難しそうかなという所感です。

「見立てと進捗の相関性は高いのか」は数ヶ月利用してから検証可能な問いなので優先度を下げ、見立てから生まれるコミュニケーションを滑らかにすることに重心を置いてダッシュボードをデザインしてみると、こうなりました。

タスクごとの1日の見立てを分かりやすく見れるダッシュボード

見立てを共有した際に、遅延リスクが高いものを議題化するのは3つシーンがあります。

• 定例会議の事前準備にする
• チャットでの議論を促進する
• 日程調整を促進する

「必要な時に必要な会議を開催する」という目的ではなく、改めて完全非同期を目指しチャットでの議論を促進するを模索しています。だいぶ雑やけど、検討プロセス。

ユースケースが多様で見立てを聞くタイミングが複雑になりそうなので、整理してみました。

• 締切日の◯日前に聞く、最も単純なパターン
• 着手日から締切日までの期間で聞く、ガントチャートで使えるパターン
• 開始日から終了日までの期間で聞く、スプリントで使えるパターン

最新版のChat UIはこちら。「締切日から生じるコミュニケーションを滑らかにしたい」と思い始めたが、本質的なのか悩み始めてきました。

Notionから自動集計して日報を作成

悪い見立てのタスクは相談事項とあわせて共有

タスクの依頼者にスレッドで、ひとことの反応を促進

あれこれ調べているとOKRに関する誤解が解け、スクラムに対する誤解も解けた。

この記事もすごく面白い。
https://www.infoq.com/jp/articles/agile-okrs/