ワークフローサンプル: 第574話：プロセス改善物語（SaaSベンダー編１）

業務：デザイン業務

デザインチームの業務は多岐に及ぶ。

たとえば、「SaaS製品内のアイコン」の変更や追加といった小さな案件もあれば、「新しいSaaS機能」のインターフェース開発といった大きな案件もある。
ただ…、それ以外にも、セールスチームが書いた「導入事例記事」をWeb掲載するという案件が発生したり、さらにそれをチラシ制作するという案件が発生したりする。はたまた、マーケチームの「展示会」企画にあわせて、Webコンテンツを制作案件が発生したり、ポスター制作したり…。

つまるところ、全社から「手伝ってラブコールを受け続けるチーム」と言っても良い。

課題：受け身な案件の効率化

確かにデザインチームが愛されていることは事実だ。
しかし、直接部門である「製品開発部門」や「営業販売部門」が日ごろ主体的に動いているのと比べると、やっていることは地味と言わざるを得ない。たとえて言えば、小売店にある「ラッピングコーナー」みたいなものか？　日々、社内のアウトプットに対して「お化粧」をし続けるのだ。そして、気がつけば「受け身の姿勢」がしみついてしまう。

これがもし建築の世界であれば、、、むしろ「意匠系」が主体的に動き、エンジニア集団である「構造系」や「環境系」が受け身になるところなのに。。。と、ボヤいたところで「社内からのラブコール」が無くなる訳ではない。まずはこの「受け身仕事」を手際よくこなすことを考えたい。（経理担当だって、人事担当だって、情シス担当だって、、、「受け身仕事」を華麗にサバいているのだから…）

[デザイン依頼対応プロセス]

解決：デザインプロセスを独立させる

直接部門を支援する間接部門が「受け身」になってしまうことは、ある程度はやむを得ません。そして、直接部門の業務プロセス内に間接部門の工程（スイムレーン）が組み込まれることも少なくありません。

しかしその場合、デザインチーム自身が業務プロセス定義のオーナーシップを持たないため、

デザインチーム内のプロセスが改善されない
デザインチーム内での仕事負荷状況が認識しづらくなる
デザイン工程のインプット・アウトプットが業務によってバラバラになる

といった問題が発生する傾向にあります。

この業務プロセス定義は、チーム外からの依頼を受け付けられるだけでなく、他の業務プロセスから「プロセス連携」させる（サブルーチン呼出のように連携させる）ことも可能です。このように独立した業務プロセスとして定義しておくことで、デザインチーム内が受けている様々な仕事を容易に可視化できるようになります。
（直接部門がチーム内に「専属デザイナ」をオカカエしているようなケースには当てはまりません）

考察：成果計測の必要性

間接部門は、デザインチームだけではありません。組織内には他にも数多くの間接部門があります。（バックオフィスとも言われます）

たとえば「法務チーム」や「人事チーム」や「情報システムチーム」といったチームは、仮に「フラットでない組織構造」であっても、あるいは「1000人を超える大企業」であっても、間接部門として独立しているケースが一般的と言えます。（他にも、翻訳チーム、品質管理チーム、ブランド管理チーム、BPMチーム、などなど）
ただ、同じ間接部門であっても、

「人事チーム」のように、直接部門の日常業務に組み込まれない組織と
「法務チーム」や「デザインチーム」のように、直接部門の日常業務に組み込まれがちな組織

とでは、業務プロセス管理の方法が大きく異なってきます。

すなわち「人事チーム」であれば、人事業務プロセス群について自らオーナーシップをもって改善し続けることが可能です。が、たとえば「受注契約プロセス」の一工程として組み込まれる「法務チェック」といった工程については、あまり改善対象になりません。

このケースにあるデザインチームは、各人の成果計測も重要となるクリエイティブチームとも言えます。もし、競争力のある組織に成長させていく必要があるなら、他部署からの「依頼受付」を開始ポイントとする独立した業務プロセスについて検討してみるべきだと言えるでしょう。

[デザイン依頼対応プロセス：「1.デザイン依頼」画面]