こんにちは。デザイナーです。

サイボウズ株式会社でUX / UIデザイナーをやりながら、複業でフリーランスのデザイナーもやってます。

サイボウズではアジャイル開発手法の一つであるスクラム開発が主流で、自分もスクラムマスターとしてスクラム開発に関わっているのですが、自分が関わって来た受託案件ってみんなウォーターフォールだなぁ、と思って今回複業の制作案件でアジャイル移行を試みてみました。

これまでのやり方

自分が受託の制作会社で働いていたころのプロジェクトを振り返ってみるとほとんどがウォーターフォール型の開発でした。
例えばよくあるWebサイトのリニューアル案件だと

1. 企画書、見積もり、スケジュールをだす
2. デザインカンプ 、仕様書を出す
3. デザインがfixしたらコーディング開始
4. コーディングが完了したら確認してもらって納品

こんな感じです。
それぞれの段階でドキュメントをfixさせながら進んでいきます。ふーむ完全にウォーターフォールですね。

鉄の三角形

ソフトウェア開発における鉄の三角形というものがあります。
スコープ（機能）、費用、納期からなる三角形で、これを3つ同時に固定することはできないとされるものです。
ウォータフォール開発ではこのうちスコープを固定して予算と時間を投下します。
対してアジャイル開発では費用と納期を固定して、スコープを可変にします。

受託制作における鉄の三角形

制作業務でのウォータフォール開発で問題なのは実際に費用と納期が固定されていないケースがほとんどないということです。
「お金はいくらかかっても構わない！」とか「完成はいつになっても良い！」と言ってくれるお客さんに出会ったことがないんですよね。
そもそも必ずはじめにお見積もりとスケジュールを求められますし。

これは鉄の三角形の3辺が固定されている状態です。
それゆえに結果的に納期や費用を変えることができたとしてもそれは「失敗」とみなされることになります。

というわけで、納期と費用が固定されているのであれば、スコープを可変にする手立てを考えれば、受託案件もアジャイル化ができそうです。

スコープはどこで固定されるのか？

自分が思うにスコープを固定しているのはデザインカンプです。

デザインカンプはWebサイトの完成イメージを顧客と共有するために作られるもので、それなりに手間暇をかけて作成・修正しfixさせます。
完成イメージを提出するわけなので、ある意味顧客に対して「これを完成させて納品します」と約束をしているわけです。
顧客はデザインカンプを見て「なるほどーこれが出来上がるのかー」と頭の中でスコープを固定します。

デザインカンプには表現されない部分が多い

ところが実際出来上がったものを確認してもらう時、「動いてるのをみるとちょっとイメージと違うな…」と最後になって大量のフィードバックをもらうことが多いです。
イメージした動きが違う、実際のブラウザでみるとデザインの印象が違うなどなど。
デザインカンプはあくまで絵なので、実際にWebサイトとして動作した時のイメージは伝わらないのです※1。

よーしデザインカンプやめよう！

なのでデザインカンプを出すのをやめました！その前にまずメールをやめてSlackにお客さんを招待したりしたんですけどそれはそれとして、デザインカンプをやめました。

事前に企画、ラフデザインまでは話し合い、方向性はすり合わせています（もちろん見積もりとスケジュールも出してます）。
その後、デザインカンプを出す代わりに何をしたかというと、最低限のデザインとコーディングを施した動作するWebサイト（いわゆるMVP※2）を出しました。

最低限のデザイン、というところがキモで、デザインカンプを出した後に見せたら怒られるけど、見せる前だったらぎりぎりデザインとして受け入れられる、というぐらいのクオリティのものです。

コーディングもお客さんが実現したいと思っている主要な機能だけ実装して、これもコンソール見たらちょっとエラー吐いてるけど一応動いてるし気にしないぜ！ぐらいのものです。

フィードバック = バックログ

MVPを出した後フィードバックが大量にきます。
デザインカンプをfixさせる段階と最後に動作するものをチェックする段階を同時にやっているようなものなので当然です。

内容も、デザインからコーディングに関わる部分まで多岐に渡ります。
ここはじっと耐えました。
これまでと大きく違うのは、フィードバックについて話し合う時間がある、ということです。

スクラム開発では、開発要件をバックログとして、誰のために、なぜそれをやるのか、をまとめたアイテムとして扱います。
今回は先に出してもらったフィードバックを完全ではないにせよバックログ的に扱うことでアジャイル的に改善のサイクルを回そうと試みました。

フィードバックについて話し合う

大量にもらったフィードバックを一覧できる形に並べて一つづつお客さんと話し合いました。
今回はGoogleスプレッドシートを同時編集しながら打ち合わせました。

このフィードバックでを求めていることはなんなのか？ なぜやるのか？ 期限は？ と行った具合にフィードバックを明確にしていきます。 その中で「これは○○という理由でマスト」「これはやっぱり必要ないね」とか、「これはできたら良いけど後回しで良いです」と行った具合にお互いの認識を合わせて、それぞれのフィードバックの適切な優先度を決めて並べ替えます。

自分のタスクも入れておく

MVPなので当然まだできていない作業があります。「これからこれをやる予定です。こういう作業が残っています」と言った具合に自分がやろうとしている作業も同じ場所で共有しました。
それを共有する中で「それはこっちの方がいいです」「それは必要なさそうです」とこれも顧客との話し合いで優先度付けされていきました。

改善のループを回して完成させていく

優先度がついた段階でだいたいの工数が見積もれるので、それを基にフィードバックへの対応とそれを確認するための繰り返しのスケジュールをたてます。
この段階でどう考えても期日までに対応が難しそうな場合は期日を伸ばすか、スコープの調整について話し合います。

あとは定期的にフィードバックへの対応とそれの確認、追加のフィードバックについての話し合いと優先順位づけを繰り返して行きました。

結果

結果的に顧客の望むものを納期通り実現することができました。
直前のフィードバックの嵐もなく、突然要件が変わったりする事態も全く起きませんでした。
MVPを改善の繰り返しで完成に近づけていったことで、顧客のイメージとずれたものが突然現れる、と言ったことがなかったためです。

何よりよかったのは、顧客の求めていたもの、と自分が作ったもののギャップを最小化することができたことです。
もし、自分がこれまで通り美しいデザインカンプ を最初に出していたら、きっとカンプに表現されなかった部分でいろんなギャップが出ていたことでしょう。

重要なのは「当初決めた要求を期限通り実現した」ではなく、顧客が求めているものを期限通り実現できたことです。

ひとまず、今回の案件についてはアジャイルなやり方ができたと思います。

学び

今回において言えばデザインカンプの代わりに出したMVPが何よりも重要な点だったと思います。
顧客をがっかりさせない、かつ手間をかけすぎないギリギリのバランスのアウトプットを作れたことが今回の成功の要因です。
正直、これまでの経験による勘みたいな部分が大きく、どういうものだったらMVPとしてOKなのかはまだはっきりと言語化できません。
この辺は要研究です。

課題

今回は自分一人で企画からデザインからコーディング、最終的なアップロードまで全てをやりました。もしこれが制作会社のように職能ごとに分担されていた場合、同じようにできるかはまだ未知数です。
おそらく完全分業は難しくて、コーディングに明るいデザイナーか、デザインに明るいコーダーと言った具合にクロスファンクショナルな職能が必要になると思います。
顧客と直接やり取りできない案件も難しいかもしれません。
いずれにせよ、もっと研究と実践が必要です。

最後に

色々つらみの多い受託制作ですがもっとより良いやり方があるはず！ と思ってます。
自分はこういうやり方で受託案件をアジャイル化してますよーとか、アジャイルじゃなくてもこういうやり方で上手くいってますよー、という事例があればぜひ聞きたいです。
もしくはアジャイルでやってみたい方、まだ色々実践したいのでぜひお声がけください。

ポートフォリオWebサイト
https://toi-toi-toi.com/

※1 最近は実際のWebサイトのように動くプロトタイプ作る人も多いです
※2 Minimum Viable Productの略で、仮説検証のために最低限必要な製品