プロセス担当としてやっていること

最近、僕が入ったときは3人だけだったチームに少しずつ人が増えて、最初はお昼ごはんやら、夜飲みながらだとか、そういうところで話した内容が、100%とは言わなくとも新しい人に伝わっていないことがあることに気が付きました。

というわけで、自分がチームのプロセス担当としてやってることってなんの目的なのってあたりをまとめます。特にスクラムの話とかではないですし、よく考えたら4年くらい前と内容ほとんど一緒です。

目的

チームに注目した場合
チームみんなで事業の決定性を高めつつ、それまで見えていなかった問題を個々人が能力を発揮して発見・仮説を立て、チームみんなで検証し、問題を解決する

メンバーに注目した場合
誰でもできることを動的なコミュニケーションによって共有しながらチームで解決し、結果としてその人にしかできないことをやってもらう(そのための努力をみんなでする)

決定性

  • Apple のレビューで揉める要因を発見し、対応する。レビューにかかる日数の偏差を小さくする。いつでも見込んだ日数ですぐリリースできるようにする。
  • 「よーし明日リリースするぞ!」「あ、明日俺健康診断なんすよ」「先に言えよ、健康診断はこれから上長のハンコ3つね」ってならないために、いろんなことに考えを巡らせなくてもスクラムなどのごっこ遊びを通じて細かいズレを潰す。
  • ペアプロとか、仕掛りゼロとか、毎日全部のPR片付けてから解散とか

事業プロセスが決定性を増すことで検証のコストが下がれば、発見と解決が促される。発見の部分では特に個々人がスペシャリティを発揮してほしい。

契約(静的なコミュニケーション)

裏側である契約というプロセスを覗くことでよりはっきりさせたい。

  • 決定性が高まるところまで高まった(要因がすべて明らかになり、コントロール下においた。あとはやり続けるだけ)
  • その領域が事業のコアコンピタンスではなくなった

といった場合に契約が使われる。契約なら、外注したり、子会社化したり、ワンストップでその機能を備えた社内の部署にお願いした方が効率的。

自分の所属するチームには、いまのところ契約がその力を発揮できる領域はない。

例えばいつか Firebase が最強になって、事業責任者が全部管理画面でアプリからなにから全て作れるようになれば、その時の競争力の源が何かによっては、エンジニアは外注でよいかもしれない。

昔は文字を打ち込むだけのパンチャーさんっていたけど今はいないですよねとか、サーバサイド開発の人・インフラの人は、今はそれが競争力の差を生めないので、今のフェーズだといないですよねとかという話。

外注・子会社システムはとても効率的で、大人数を動かせるし、メンバーとしても自分と似た興味や専門の人たちと、毎日同じ領域について考えていればいいので楽だが、外注する側もされる側も、イノベーションを生みにくい。というかイノベーションを求められるべきプロセス形態ではない。昨今の多様性の話の逆。

例えばJIRAは契約システム。契約システムとは、自分と他人の責任領域をはっきりさせること。

Osmotic Communication

小さいチームでイノベイティブであるために、自分と他人の責任領域ははっきりさせない。失敗はチームの失敗。成功はチームの成功。

それを契約ベースでやるのはかなり難しい。近くで揉めたり落ち込んだり喜んだりしているのを見て聴いて話して自ずと感じること。それが Osmotic Communication (浸透的コミュニケーション)。

これを大きいチームでやるのもかなり難しい。6〜7人以上なら、あとはアシスタント(縦にスケールアップ)だよ。あるいは別採算事業だよ。というのはそのこと。デザイン事務所とか、アニメ制作とか、クリエイティブ系ってけっこうそうだったり。

「浸透的に伝えない・伝えられない・伝える意味を感じられないなら、浸透的には言えなくなる(同じチームではなくなる)」これがチーム領域の区切り方で、新しいメンバーは誰かのアシスタントに入ったりする。だけど、だからといって別にドライに付き合う必要はまったくない。