「スクラップアンドビルド」という概念がある。もともとは建設業界の言葉で「老朽化して非効率な工場設備を廃棄・廃止して、新しい生産施設におきかえることによって、生産設備の集中化、効率化などを実現すること」を言うようだ。（wikipedia参照）
対する概念としては、既存の設備や仕組みを壊さずに拡張する「スケーラビリティ」がある。
ベイジのワークフローはまさにこのスケーラビリティを数多く重ねてきた。過去の数十件に渡るプロジェクトから学んだ知見を取り入れ、失敗を未然に防ぐためのアイデアを組み込み、現在ではウェブサイトの戦略から設計、制作、開発にいたるまで約130のタスクに分解され整備されている。
ここまで整備がされていると、プロジェクトが失敗するリスクを最小限に抑えることができる。非常によくできたワークフローだ。
一方でスケーラビリティ的な考え方でワークフローを整備を続けることは果たして健全なのだろうか。というのも、「ベイジのワークフローはこういうもの、こういった進め方が正しい」と固定観念を強固にし、リスクを回避するためのタスクが肥大化していってしまう懸念もあるのではないかと思うからだ。
ワークフローに沿ってタスクを消化していくことは、プロジェクトはつつがなく進められるかもしれないが、不必要にリスクを恐れるあまり、顧客確認を何度も挟んだり、社内での調整に時間を多く取ったりとリソースを食いつぶしてしまう可能性がある。
そこで、冒頭のスクラップアンドビルドの概念が重要になってくる。一度ゼロベースでどんなワークフローの進め方が良いか、担当する職種・職能はそのままで良いか、不要なタスクは存在しないかといった観点から見直すことも必要だと思うからだ。
例えば、ベイジでは昨年から情報設計のフェーズで「設計会議」という取り組みを始めた。理由は情報設計にかかる時間の削減するためだ。
今まではデザイナーが戦略工程のアウトプットやサイトストラクチャを元に仮説ベースでワイヤーフレームを作ってディレクターが確認し、修正したものを顧客に提案し、フィードバックがあれば修正してまたディレクターが確認し、、、というラリーを何回か繰り返してFIXさせていた。
これまでのワークフローだと情報設計に着手してから早くても2週間、遅いと3週間～1ヶ月ほどの時間がかかってしまうこともある。
一方で「設計会議」ではプロジェクトメンバーを一同に介し、議論をしながらその場で1画面1画面をFIXさせていくやり方だ。それは社内だけではなく、状況が許せば顧客と一緒に行うこともある。
もちろん、議論をしながら進めていくため、どうしても拘束時間は長くなってしまうデメリットもある。しかし対社内でも対顧客でも議論して決めたワイヤーフレームになるため、ラリーの回数が減り、情報設計にかかる時間は10日～2週間程度に削減できる。
また顧客と一緒にできる場合は、議論を経て情報を設計するため、議論好きな顧客や納得感を求める顧客に対しては、満足度の向上にも寄与する可能性もあり、副次的な効果も生むだろう。
「ワイヤーフレームは制作会社が作って提案するもの」という固定観念を捨て、「プロジェクトメンバーと共創するもの」という捉え方を変えたことが、既存のワークフローを壊し、新しい「設計会議」として生まれ変わったのだ。
私も複数のプロジェクトを経験してきて、現在のワークフローの意味やタスクが出来上がった背景などの理解が増してきてため、スクラップアンドビルドの観点からワークフローの見直しを行っていきたいと思う。
