Web制作のワークフローを考える（2022.09.07宮坂）

新メンバーからの素朴な疑問。

社内のディレクターメンバーで、２週間ごとに定期的に行なっている「ディレクション施策ミーティング」がありました。

基本的には日々のディレクション業務で困っていることや気づいたことの共有などが主な議題です。

そこで、最近入社した新メンバーからの素朴な疑問。
「サイトフローって、Googleのスプレッドシートで作っているけど大規模サイトになってくるとかなり複雑だし、修正の手間もかかって大変じゃないんですか？」と。

サイトフローは、提案時にディレクターが作成することが多くサイト全体のページやページからの遷移などを説明するためのもの。
JBNでは、基本いつもGoogleのスプレッドシートで作成しています。

たしかに、サイトの規模が大きくなってくると変更があった時の修正も大変。しかも、構築が始まると「サイト全体設計書」という別シートにて構築管理をしていくため、サイトフローをクライアントと見返すことも少なくなってきたりする。

ミーティング中の議題は２つ

話しの流れ的には２つテーマがありました。
・サイトフローは、Googleスプレッドシートじゃなくてもいいのでは？
・サイトフローとサイト全体設計書どちらか一方でもいいのでは？
miroで作ったことあるという意見も出ましたが、最終的にはクライアントとの共有のしやすさなどもあるため、一旦現状維持に。

サイトフローの役割

改めて、サイトフローの役割ってなんだろう？
現状は、提案時クライアントにサイトの全体像を理解してもらうため、その説明資料としての役割が大きい。（また、サイトフローを元に構築費を算出したりもする）なんなら私は、そのページにどんなコンテンツが入るかも小さく記入していたりします。（自分の備忘録的な意味も・・・）

セルを結合したり、罫線を引いたり、ページ属性ごとに色分けしたりと、なんとなくJBNなりのルールでいつも作成しているサイトフロー。

構築が始まるとページが減ったり増えたり、サイト全体のページ変更はどうしても発生してしまうものなので、その都度「サイト全体設計書」と「サイトフロー」を両方修正していくのは確かに面倒でした。（忘れてしまうこともしばしば・・・）

そりゃあ新メンバーのKくんからしたら、なかなか手間のかかる代物に見えなくもないのか〜と。
完全盲点。
そんなこと全然気づかなかった、というか・・・そういうものだと思って今までやってきていた。。。というのが正しい。
業務効率化の種がこんなところにもーという感じ。

ちょっと、今後は考えていってもいいのかも？！

そうはいっても、やはり提案時にはサイトフローが必要だし構築時にはサイト全体設計書の方が使いやすい。
ワークフローをいきなり変えるのは、なかなか難しいです・・・

しかし、ディレクション工程の負荷を減らして効率よくプロジェクトを推進していくために。色々と試しながら模索しながら、ディレクション工程をより良く体系化していけるような、そんなワークフローを確立していけたらいいなと思いました。