「速く回す人」と「少なく回す人」

このエントリは アジャイルCasual Advent Calendar 2014 の 2 日目のエントリです。

前日は shin_semiya さんの「インセプションデッキを作る上での危険信号」でした。インセプションデッキを銀の弾丸と勘違いしている人には僕も会ったことがありますし「あるある…」という内容でしたのでみなさんも何かしらこういった経験はあるのではないでしょうか？

さて 2 日目の僕は PDCA サイクルについて書いてみたいと思います。

自己紹介

すえなみと申します。漢字で書くと末並です。「末波」とよく間違われますが「末並」です。

とても希少な名字なので勉強会等で「すえなみ」と名乗ってる人間がいたら間違いなく僕のことだと思ってください。 オンラインでは a_suenami とか a.suenami とかで活動してます。

Twitter: https://twitter.com/a_suenami

Facebook: https://www.facebook.com/a.suenami

所属は渋谷にあるファクトリアルという会社で、受託開発のお仕事をしています。Ruby、PHPあたりがメインの開発言語です。 よろしくお願いします。 http://www.fact-real.com/

PDCA サイクルとは

このエントリを読みにこられるような方で PDCA サイクルという言葉を聞いたことがない人はさすがにいないと思いますが、一応 Wikipedia を引用しておきます。

PDCAサイクル - Wikipedia

PDCAサイクル（PDCA cycle、plan-do-check-act cycle）は、事業活動における生産管理や品質管理などの管理業務を円滑に進める手法の一つ。Plan（計画）→ Do（実行）→ Check（評価）→ Act（改善）の 4 段階を繰り返すことによって、業務を継続的に改善する。

「業務を継続的に改善する」とあり、まさにアジャイル開発やアジャイルチームのもっとも根底にある考え方と言えます。

ただ、この言葉、広く普及して市民権を得たことはよいのですがある意味当たり前になってしまった感じがあり、単にお題目として唱えられたり、場合によってはチーム内対立の原因になったりするケースもあると感じています。

PDCA サイクルに必要な 2 つの要素: 安定性と仮説

僕は PDCA サイクルを回しプロダクトやチームのあり方を改善していくためには 2 つの異なる要素が必要だと考えています。

それが「安定性」と「仮説」です。

プロダクトにしろチームのプロセスにしろ、評価・改善を継続的に行うためにはそれが安定していることが必要です。安定しないものに変更を加えるということは改善するどころかそれまでうまくいっていたものを壊す危険性もあるし、仮にうまくいったとしてもそのために多大なコストがかかってしまうでしょう。

また一方で、そもそもどのような変更を加えればいいのか決定するためには仮説が必要となります。仮説なくやみくもに変更をしてもそれは決して改善にはつながりません。

PDCAサイクルというのは対象を変更に耐えられるほど安定させたうえで仮説にしたがって変更・評価を繰り返すことによってのみ実現されるのです。

PDCAサイクルを支える技術

PDCAサイクルをまわすために必要な安定性と仮説ですが、それらを得るためにチームが備えるべき専門性は結構異なると思っています。

前者はテスト自動化、デプロイメントパイプラインの整備によるリリースサイクルの短期化、プロダクトの監視体制の整備などであり、後者は情報設計やインタラクションデザイン、UI デザイン、マーケティングなどが該当します。

前者の専門性を持ち PDCA をきちんと回そうとすればそのサイクル非常に高速にまわります。僕はこれが得意な人を「速く回す人」と呼んでます。一方で後者の専門性を持った人がチームにいた場合、そのチームの PDCAサイクルはより少ない試行で求めたものにたどり着きやすくなります。僕はこれが得意な人を「少なく回す人」と呼んでいます。

「PDCAサイクル」という言葉の認識の不一致が招く悲劇

「PDCA をちゃんとまわすべきだ！」という主張自体は最近ではわりと受け入れられることなのではないでしょうか。ましてや自分たちがやっていることはアジャイルであると思っている人やチームであればもはや当たり前のことだと思います。

しかし、それを支える専門性は大きく 2 種類あり、これらは相互に補完的であるにも関わらず、ときに対立的でもあります。 綿密なユーザヒアリングや慎重な企画策定を経て少ない試行回数でユーザ満足度を最適化しようとする人たちがいる一方で、より高速なサイクルを実現して何度も何度も試行することを仕組み化しようとする人たちがいます。

両者は同じことを目指しているにも関わらず持っているハードスキルが遠いため、チームとしての協力経験が浅いとときとして「PDCAサイクル」という言葉が一人歩きしわかりあえないという事態が発生します。

僕自身、そういったチームをいくつか見てきました。

PDCAをまわして設計空間を狭めていく

僕自身はソフトウェアテストが好きですし、書籍「継続的デリバリー」に感銘を受けたということもあり、どちらかと言えば自分は「速く回す」のが好きな人間だと思っています。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

しかし、プロダクトのリリース直後にユーザがまだまったくいない状態であったり、築き上げたリリースサイクルが回らなくなるほど致命的な変更が市場やユーザ環境で発生したりした場合には「少なく回す」人たちの構築する仮説とその検証プロセスにはとても助けられます。

以前、リーン系の勉強会で「仮説検証を繰り返しながら設計空間を徐々に狭めていく」*1というお話を聞いたことがあるのですが、そのときから僕はこの”設計空間”という言葉をとても気に入っています。

設計空間が広大でユーザが何を求めているかは本当にわからない状態の場合はそもそもPDCAサイクルは高速に回らないため、如何に少ない試行でユーザ満足に繋げられるかが勝負になります。一方、その繰り返しの結果として徐々に設計空間が狭まってくるとサイクルそのものを速くすることに価値が出るようになってきます。

特にWebアプリケーションであれば「フィーチャのPDCA」から「コンテンツのPDCA」に切り替わるタイミングが必ずあると思っていて、「コンテンツのPDCA」に切り替わったタイミングこそがリリースサイクルの高速化の勝負になるのではないかと考えています。

*1:何の勉強会で、どなたの発表だったか失念してしまい、出典をあげられずずいません…