ワークフロー改善への道1

はじめに

『デザインリサーチの教科書』という本を読んで、自分なりに仕事のプロセスや「仕事の仕方のデザイン」に取り組んでみようかと。
自分の仕事のプロセスは、なんとなく身につけたもので、特段何かのメソッドに則ってやっているものではない(そういうものがあるのかどうかも調べたことはない)。いつでも自分の使える時間は限られているので、効率よく、かつ、最終的な納品物がいい感じになって、また仕事をちゃんとした値段で頼んでもらえるように考えてみようと思う。

とりあえず、長文になってしまうと思うけど、まず、どのように仕事をこなしているかを、順を追って書き出してみようと思う。

業態について

前提として、私はフリーランスで働いている。HTML/CSSコーダ、jQueryなら多少書ける。WordPressサイトも作るが、PHPをイチから書く事はできないし学ぶつもりもあまりない。CMSなら他にMovable Typeも扱える。一応、得意なのはCSSを書く事だと思っている、場合によればSASSも使う。

事務所は持たず、自宅で働いている。生活費全般は手固い仕事についている夫に頼っているので、仕事で稼いだお金は食費(ほぼ折半)と猫の世話代と遊ぶお金と将来の蓄えになる。あまりガツガツ稼ぐ緊迫感は正直ない(今のところは)。とはいえ、ずっとこの先コーダで食べていけるのかという思いはある。具体的な将来のビジョンがあるわけでもない。起業は念頭にないが、やりたくないというよりは今必要を感じないだけで、何かのっぴきならないことでも起これば別だと思っている。

主な取引先は同業者か制作会社で、仕事の多くは下請けとしてコーディングのみの発注を引き受けている。いずれも地元のお客さんなので、会って打ち合わせすることは滅多にないし、コロナのおかげでほぼ0になった。ほぼ全てのやりとりはオンラインで、多くはチャットツールによるもの、メールも少し。ミーティングが必要ならスカイプやZoomで、という感じである。新規の顧客はほぼいないし、新規開拓の営業はできていない(やる気もあまりないかもしれない)が、コロナで仕事が減るような予感があるので、今後は必要があるように思っている。

所属している団体は特にない。WordPressのコミュニティに時々参加している。去年はオンラインで地元のMeetsUpに参加、その前は今住んでいるところのMeetsUpにオフラインで参加することもあった。

仕事の受注について

先にあげた取引先の制作会社から、ざっくりした内容でスケジュール押さえの打診がある。概ね2〜4週間先のことがほとんどだが、時々急ぎで1週間や2週間後には納品という場合もある。
内容は、ウェブサイトのトップページとテンプレートになるページを1〜3ページだけをこちらでHTML/CSS/JSを書いて、あとは納品まで相手任せだったり、他人が作ったWordPressサイトのちょっとした修正からリニューアル、自分が過去に納品したサイトの改修やメンテ、新規のWPサイトをいちから作るなど。他、カラーミーショップなどを使ってECショップの作成をすることも。
概ね、最初のデザインカンプを受け取ってから1週間以内で最初のプレビューを出すペース。案件が複数並走する場合もあるが、しんどいので、なるべく避けたい。ただ、スケジュールの打診があっても、カンプの入稿が遅れるのもザラなので、スケジュール調整はほぼ諦めている。その結果締め切りがタイトになったら徹夜で終わらす。先方の都合でデータ遅れるのにこっちの締め切りが伸びないのはかなりむかつくが、それでも仕上げてしまうので、重宝されているのかなという節はある。

いうまでもなく、コーディングはウェブサイト制作の最下流の工程である。私が仕上げたものが一般に公開される。一方で、上流の工程に口を出す事はほぼない。本来、上流の工程で検討されるべきことが、この最下流までなあなあにされているプロジェクトもよくある。結果、コーディングの際に大量の確認事項やここで決定される機能も少なくない。仕様書さえない仕事も少なくないが、そのことを誰も問題と思っていないようである。取引先とは付き合いが長いため、詳しい説明を聞かずとも大体このぐらいの感じで作れば良いというのが曖昧にはあるのは確かだが、明文化とか、上流工程ではっきり決めて欲しいと思うことも多々ある。

コーディングについて

基本的にオリジナルで制作

デザインをもらって新しいサイトをコーディングする場合、bootstrap などのフレームワークを利用する事はほぼなく、あまり詳しくもない。フレームワークを使わない理由は、そもそも依頼されるデザインがフレームワークと相容れないような独自のデザインであることが多いから。デザイン通りのレイアウトを満たすフレームワークを探す時間を使うなら、過去に自分が作ったCSSから切り貼りした方が早いと判断してしまう。それが理にかなっているかどうかはわからない。

同じ理由でWordPress案件なら、WordPress公式テーマをベースにしてオリジナルでテーマを作る。無料有料問わず、ちまたにあるテーマをベースに開発しようと思った事はない。有料テーマでも開発が止まる事はあるし無料テーマは言わずもがな。一方で公式テーマはそれなりに考え込まれたものではあろうし、コードには学ぶものもあるので、新しいものが出るたび必ずチェックして利活用するようにしている。

コード以外の制作物

マニュアル

CMSを使ったウェブサイトの納品では、特段の依頼があればマニュアルは作るものの、積極的には作らない。手がけているのはたいてい規模の小さいビジネスのWordPressサイトなのでサイトの管理者が変更になることも少なく、一度手順を覚えてもらえれば継続的に使えるようにしているため。なるべく管理画面上で多くのヒントを残しておくようにするなど工夫する。

情報アーキテクチャのドキュメント

制作依頼の段階で、サイトマップ、ページ一覧がない場合に作って共有する場合がある。これは依頼主側が提供してくるものが不十分であることや、そもそもこのような書類を作る文化のない人も多いと感じる。ワイヤーフレームを書くことなどは割と得意なので、上流工程への関わりを持つことが単価アップにつなげられるのではないかという思いもあるが、少々面倒くさい。面倒というのは、そもそも、クライアントの傾向として、情報アーキテクチャに対して費用をかけるという発想がないので、その部分をお金にするにはまず説得から入らなければならない。

スタイルガイド

明確に求められる事はないが、時々自分のために作っておくことがあった。今後は積極的に作り、残すことで、デザイナの次の仕事に生かしてもらえることを考えている。

要件定義について

このプロセスに介入したいと思っているが、あまりうまくいっていない。直接クライアントとやりとりをする立場にないし、プロジェクトに関わる際もほんの一部で直接に状況がわからないため、ウェブサイト制作全体の要件定義についてはほぼ無理と思っている。
一方で、コーディング発注者との間の要件定義については、求められないが、こちらのWBSを書くついでに、簡単にまとめるようにしている。ただ、相手に渡しても確認されていなかったり理解されなかったりするので、意味を成さないなと感じる。これも課題。

契約書について

書いたことも書かされたこともほぼない。ウェブサイトのメンテナンス契約をするときだけ、業務内容の確認として簡単なものを書いて渡す事はある。これは改善が必要なのではないかと常々思っているが、取引先でもあまりその文化や習慣がないのでなあなあになっていると感じる。


ワークフローというより、前提の確認という文書になってしまった。続く記事でもう少し作業プロセスについて詳しく書きたい。

思うのは、書籍などを読んでいても、私が、現実的に、出会うクライアントや取引先とのやり取りとかけ離れすぎていて、あまり参考にならない気がすること。情報アーキテクチャに対する意識も低い、プロセスの透明化や意思決定の経緯やプロジェクト自体の透明化、諸般の事柄の明文化、プロジェクト管理、スケジュール管理などあらゆるものが曖昧糢糊としている印象だ。また、ウェブやデジタル化への意識も周回遅れ、世代遅れと感じる。書籍などを書く人は第一線を走る人であろうし、出てくる例もそれなりに先を走る人たちの例なのだろうと思う、意識高いと思う。逆に自分や現実のお客さんは、どうだろう。ギャップがあるように感じるのは私が物を知らないせいだろうか。

などと、愚痴めいたことを言っていても仕方ないので、まず、隗より始めよ、かなと思っている。

次の記事はこちら↓↓↓↓↓

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です