標準化と形骸化
※この記事は hey アドベントカレンダー2020 10日目の記事です。
昨日は @nishiokadaiki1 の 要求仕様書とはなにか でした。
私は hey という会社で STORES というECプラットフォームを開発しているソフトウェアエンジニアでして、去年くらいからチームリーダー的な業務も行うようになりました。
その中でチーム作業の標準化について考える機会が増えたので、今回はそれについて書きます。
なお、今回書く標準化とは 組織デザイン の次の引用とさせていただきます。
標準化（standardization）とは、なんらかの標準（standard）を多数の人や部署で共有したり、時間を超えて共通に用いたりすることである。
沼上 幹, 組織デザイン, p92, 2004
標準化することに良い思い出なんてなかった
その昔、私は大規模プロジェクトの○次受けの作業員という立場で仕事をしていたことがあり、そこには多くの作業標準がありました。
中には「なんでこれをやるかは誰もわかっていないけど、やらないといけないことになっているのでやる」とか「やる意味はあんまりないとみんな知っているけど、やってる風に見せないといけないのでやる」というものも存在していました。
おそらく過去になんらかの理由で標準化されたものが、時を経て（あるいは最初から）形骸化してしまったのだと思われます。
終電間際、人が少なくなった深夜のオフィスで、なぜやるのか誰もわからない作業を黙々とやっていたあの時間を思い出すと、自然と遠い目になってしまいます。
この時の経験からその後の仕事において「形骸化してしまうような作業やルールは作らない」ということを強く意識するようになりました。
標準化を避けるようになった
時は去年にさかのぼり、弊社（弊社はhey社です）にて徐々にチームリーダー業をするようになりました。
チームメンバーには、標準化された作業リストに従って淡々とこなすような仕事ではなく、みんなの創意工夫が盛り込まれた楽しい仕事をしてもらいたい。そんなことを考えていました。
ですが一方から見ると、形式的な儀式であったり作業を標準化することに必要以上に抵抗感を持っていたように感じます。
特に開発プロセスとして採用しているスクラムの運用に、その傾向が顕著に現れていたと思います。
スクラムには開発を進めるにあたって行うべきイベントがいくつか用意されています。
運用にあたってこれらを厳密に実施するというよりは、イベントを起点としてチーム全員で今起きている課題は何かを考え、そのために何ができるかを考え、それを実施して振り返る、ということを重視していました。
転じて、私にとって形式的すぎると感じられたいくつかの作業はスキップして運用していました。
例えばベロシティの計測もそのひとつでした。仮想のポイントをやりくりするのが当時の私にはどうしても形式的な作業に感じられたのです。（ベロシティの計測をスキップしたのは悪手だったことはあとで理解することとなります）
深夜のオフィスの思い出は、私の判断基準に大きな影響を与えていたのでした。
形骸化を避ける、という方針はチームが小さかったころは柔軟かつ能動的に物事を進められ、おかげで一定の成果をあげていたと思います。
私たちのチームは顧客への素早い価値提供を一定のレベルで実現できていると自負していました。
組織が拡大していくにつれカオスになった
hey社は2018年の設立以降ずっと組織が急拡大しており、ソフトウェアエンジニアを始めとしたプロダクト開発チームも例外ではありません。
私が働き始めた2年前くらいにはそうでもなかった「職能を跨いだコミュニケーションが大変」という課題が各所であがるようになっていました。
そこで今年に入って職能を横断した組織を作ることとなりました。もちろん私自身も大賛成でした。
しかし、組織の拡大と私が意識していた「形骸化を避ける」というチーム運営の食い合わせが若干悪かったことに気付きます。
意思決定を行うために多くのMTGが開かれるようになり、それらのMTGの参加者数も多くなり、作業時間が減り、そして作業時間が減った分を取り戻すために意思決定を...と負のループに陥ってしまいました。
スクラムの運営も、人数が多い分重厚長大なプロセスとなってしまい「これをスプリントごとにやっていたら大変なことになるぞ...！」という雰囲気が漂いはじめていました。
人の数だけ感じる課題があり、それぞれに試せる施策があります。が、チームの時間はその人数に関わらず一定です。
人数が増えた分、課題解決に費やしたい時間は指数関数的に増え、チームに与えられた時間は必然的に足りなくなりました。
この状況はどうにかしないとなあ、と思っていたところで子どもが産まれ、私は2ヶ月間の育児休暇に突入することとなります。
全然本筋とは関係ないですがその時の話がこちらです。
標準化について改めて調べた
育児休暇中、子が寝静まっている時間を利用して、これまで苦手意識を持っていた標準化について改めて考えるようになりました。
きっかけは、hey社CTOの藤村さんやCPOのあやさんが社内でおすすめしていた 組織デザイン を読んだことです。
本書では「組織デザインは、極めて多様なトレードオフ関係の中で、現実的なバランスをとっていく作業である（p23）」としながら、組織デザインを分業、標準化、例外事態への対処 + その他様々な補正と定義し、それらを体系的に整理しています。
そしてそれぞれのトピックについて掘り下げ、標準化についても様々な分類がなされています。インプットの標準化、アウトプットの標準化、スループットの標準化、その他ここでは紹介しきれないほどの観点から標準化について現実的な整理がなされています。
この本によってこれまで私自身が標準化について、かつて深夜のオフィスで眺めていたエクセルを印刷した手順書くらいのイメージしか持っていなかったことに気づかされました。
標準化には様々な方法があり、組織にマッチした優れた標準化を行うことは、組織をより大きく強くするために重要なことだったのです。
この本をきっかけに「もっとチームを観察しみんなで適切な標準を作ることでより良いチームにできるかもしれない。復帰後はそんな仕事をしよう。」と考えるようになりました。
優れた標準化を体験した
とか思っていたら、私が休暇をとっていた2ヶ月の間ですでにめちゃくちゃ優れた標準化がなされており「すごい...これが標準化の力か...」ということを学ぶこととなりました。（スクラムのベロシティの威力を学んだのもこれがきっかけです）
そのお話がこちらです。
ベロシティやKPTなど職能ごとのアウトプットを標準化し、協業しやすい状態を作る。日々のプロセスは時間軸でのみ標準化し柔軟性を保つ。
復帰した最初の週から「これは働きやすい！」と膝を叩くような気持ちでした。
（@daitasu が12月12日に Developers Boost 2020 でこの話をもっと掘り下げるので宣伝です！）
おかげで「優れた標準化はむしろ自己組織化を促し働きやすい環境を作る」ということを身を持って体感することができました。
かつて私が持っていた、不必要に標準化を避ける気持ちは十分に払拭されました。
標準化するにあたって気をつけていること
今では標準を用意した方が効率が良いと判断したときは標準化するように心がけています。
しかし、それでも標準化と形骸化が紙一重であることは否めないことだと思っています。
そこで、標準を用意する際は以下のようなことに気をつけています。
・なぜその標準を用意したか、その目的を明記する
メンバーは常に入れ替わる可能性があり、hey社の場合はこれからもっと増えていくことを想定しなければなりません。
今私たちが良かれと思って作った標準が、後になって「なんでこれをやるかは誰もわかっていないけど、やらないといけないことになっているのでやる」などと言われ形骸化しているととても悲しいです。
なので、「なぜその標準を用意したのか」という目的と理由を明記し、後で誰でも書き換えたり削除できるようなものにしています。
こうすれば、あとで不要な標準になったときに気軽に削除できるのではと期待しています。
（コミットログにWhyを残す、というのと同じような思想です）
・自分ひとりで標準を用意しない
「標準」とは生産現場の人間がつくり上げるべきものである。けっして上からのお仕着せであってはならない。
大野 耐一. トヨタ生産方式 (Japanese Edition) (Kindle の位置No.1943-1944). ダイヤモンド社. Kindle 版.
勝手に標準を用意しそれをチームに押し付けると、それが後になって「やる意味はあんまりないとみんな知っているけど、やってる風に見せないといけないのでやる」などと言われ、形骸化する恐れがあります。
なので、何か標準化する場合はチームに相談し、決してひとりよがりな物を作らないように気をつけています。
幸いなことに、チーム全体で標準を作っていこうという空気感があるのでとても助かっています。
形骸化してしまった標準があると効率的に業務を回すことができないだけでなく、それを実施する人にかつての私のように辛い思いをさせてしまうこととなります。
私たちのビジネスは個人や小さなチームを支えるものであるため、成長し安心して使ってもらえるビジネスであることはもちろん、長期に渡って継続的に運用されるビジネスである必要があります。
ということは中で働く人々にとっても創造的かつ継続的に働ける環境でなくてはなりません。
形骸化する標準は避けつつ働きやすくなる標準化を行い、チーム全員が「Just for Fun」な仕事ができるようこれからも努めていきます。
---
hey社で働くということは、今回の標準化のように今までのメンタルモデルでは立ちいかなくなっていくことがたくさん起きるということだと思っています。
今後とも柔軟な気持ちを持って変化を楽しんでいきたいです！
明日は @ykpythemind の「Goで静的解析してlinterを作る」です！
この記事が気に入ったらサポートをしてみませんか？