プロセスは省略できればできるほど良い

今日、NewsPicksの糸井重里さん回の切り抜きを見ていたら、
「ホワイトカラーの生産性がめちゃくちゃ低い」
「管理するために給料もらってる人がたくさんいる」
「没になってもいいプレゼンを作るためにものすごい労働力が割かれている」
ということを仰っていました。

自分もかなり同感で、
何かを管理するだけの仕事は、本質的には価値を生み出しておらず、

ゴールに向かうまでのプロセスについては、成果物が同じであれば省略できればできるだけ良いと思っています。

• やるか/やらないかを判断するための根拠を集める

• 複数ある選択肢を比較/検討するために時間をかける

• メンバーの納得感や上司の承認を得るためにドキュメンテーションすること、特にフロー情報を充実させるためにコストをかける

• メンバーのタスクを管理するために、毎週イテレーションMTGを開いている

これらは、一般的には良いとされることが多いプロセスです。
「失敗しないための再現性を上げる」ことに繋がります。
経験の浅い若手メンバーに、大きな失敗をしない方法を教えるためには、一定の効果があります。

逆に、練度の高いメンバーが集っていた場合、これらのプロセスを踏まずとも成功する確率が高いのであれば、プロセスの省略も可能だったりします。

（しかも、厄介なことに、素早く機能をリリースできるほど、経験値を稼ぐことに繋がります。それらが、ドメイン知識の獲得や勘所の獲得に繋がり、「成功するための再現率を上げる」ことに繋がったりします。）

本筋に戻します。

プロセスは練度の高いメンバーにとっては、価値を生み出すものではないです。ですので、目指すべきは、「プロセスをしっかり踏めることではなく、プロセスを省略して価値を出すことに集中できること」だと思っています。

恐らく、一般的なマネジメント方針は、プロセス/やり方をきちっと守ることをゴールにしているところが多いかと思います。
が、これは、かなり義務教育チックというか、メンバーに一律で60点を取らせるやり方かなと思っています。（やや否定的な言い回しをしましたが、この一律60点を取らせるというのが重要な局面はめちゃくちゃ多いです）

それとは異なり、自分は、プロセスを省略できる事を理想状態としてチームを運営しています。
そのために、

• 全体でのグランドルールや方法論、お作法の導入は最小限に

• メンバーの練度に合わせてプロセスを変える

  • （ここでメンバー個別にお作法を導入することはある）

• 丁寧に手順を踏むところ/そうでないところを都度意識させる

• リリースサイクルを早めることで練度自体を高める

という事を行っているようです。
（言語化出来たのは最近なので「ようです」と表現しています。。）

今のところ、かなりの精度とスピード感で開発できている気もします。
が、この方針にどの程度再現性はあるかは不明です。

今後も色々試していこうと思います。