cycle)は、事業活動における生産管理や品質管理などの管理業務を円滑に進める手法の一つ。段階を繰り返すことによって、業務を継続的に改善する。「業務を継続的に改善する」とあり、まさにアジャイル開発やアジャイルチームのもっとも根底にある考え方と言えます。この言葉、広く普及して市民権を得たことはよいのですがある意味当たり前になってしまった感じがあり、単にお題目として唱えられたり、場合によってはチーム内対立の原因になったりするケースもあると感じています。つの異なる要素が必要だと考えています。それが「安定性」と「仮説」です。プロダクトにしろチームのプロセスにしろ、評価・改善を継続的に行うためにはそれが安定していることが必要です。安定しないものに変更を加えるということは改善するどころかそれまでうまくいっていたものを壊す危険性もあるし、仮にうまくいったとしてもそのために多大なコストがかかってしまうでしょう。一方で、そもそもどのような変更を加えればいいのか決定するためには仮説が必要となります。仮説なくやみくもに変更をしてもそれは決して改善にはつながりません。PDCAサイクルというのは対象を変更に耐えられるほど安定させたうえで仮説にしたがって変更・評価を繰り返すことによってのみ実現されるのです。PDCAサイクルを支える技術PDCAサイクルをまわすために必要な安定性と仮説ですが、それらを得るためにチームが備えるべき専門性は結構異なると思っています。デザイン、マーケティングなどが該当します。回そうとすればそのサイクル非常に高速にまわります。僕はこれが得意な人を「速く回す人」と呼んでます。PDCAサイクルはより少ない試行で求めたものにたどり着きやすくなります。僕はこれが得意な人を「少なく回す人」と呼んでいます。まわすべきだ!」という主張自体は最近ではわりと受け入れられることなのではないでしょうか。自分たちがやっていることはアジャイルであると思っている人やチームであればもはや当たり前のことだと思います。種類あり、これらは相互に補完的であるにも関わらず、ときに対立的でもあります。綿密なユーザヒアリングや慎重な企画策定を経て少ない試行回数でユーザ満足度を最適化しようとする人たちがいる一方で、より高速なサイクルを実現して何度も何度も試行することを仕組み化しようとする人たちがいます。両者は同じことを目指しているにも関わらず持っているハードスキルが遠いため、チームとしての協力経験が浅いとときとして「PDCAサイクル」という言葉が一人歩きしわかりあえないという事態が発生します。僕自身、そういったチームをいくつか見てきました。PDCAをまわして設計空間を狭めていく僕自身はソフトウェアテストが好きですし、書籍「継続的デリバリー」に感銘を受けたということもあり、どちらかと言えば自分は「速く回す」のが好きな人間だと思っています。見るしかし、プロダクトのリリース直後にユーザがまだまったくいない状態であったり、築き上げたリリースサイクルが回らなくなるほど致命的な変更が市場やユーザ環境で発生したりした場合には「少なく回す」人たちの構築する仮説とその検証プロセスにはとても助けられます。以前、リーン系の勉強会で「仮説検証を繰り返しながら設計空間を徐々に狭めていく」*1というお話を聞いたことがあるのですが、そのときから僕はこの”設計空間”という言葉をとても気に入っています。設計空間が広大でユーザが何を求めているかは本当にわからない状態の場合はそもそもPDCAサイクルは高速に回らないため、如何に少ない試行でユーザ満足に繋げられるかが勝負になります。その繰り返しの結果として徐々に設計空間が狭まってくるとサイクルそのものを速くすることに価値が出るようになってきます。Webアプリケーションであれば「フィーチャのPDCA」から「コンテンツのPDCA」に切り替わるタイミングが必ずあると思っていて、「コンテンツのPDCA」に切り替わったタイミングこそがリリースサイクルの高速化の勝負になるのではないかと考えています。日目...2016-08-28知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ週末の午前中、カフェでアイスコーヒーを飲みながらふとポエム...2015-03-13ソフトウェアプロセスは人に依存するようになったこれを読んでなんとなく思ったことを書く。見極め方Archiveスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。