何が課題なのか？

最初の記事でも書いたが、デザインリサーチの実践として、手元にありそうな素材に目を向けた、というのが、正直なところなので、仕事の仕方について、明確に「これが課題」と思っていることは特にない。元も子もない。
といっても、我流で身につけてきたものであること、ミスが起きること、家事時間になっても仕事を続けてしまうこと、など、直せるなら直した方がいいと思うことはある。仕事には毎回、大小問わず反省点が付きまとうのに、次に生かされているのか不明だ。
つまり、何かあった時に振り返って改善ができることが、必要なのではないか。ワークフローは、おそらく、継続的に改善が必要になる。

プロセスやワークフローに検証可能性を持たせる

ひとまずこれを課題とする。

閑話休題　用語の確認

ワークフロー：事業者や作業者などの間の仕事の流れ。

プロセス：① 物事を進める手順。② 物事が変化するときの経過。物事が進む過程。「―を重んじる」③ 食品の保存のためなどに行う加工処理。④ 「プロセス平版」の略。

プロセス平版：プロセスカラー原稿を写真製版やカラー-スキャナーを用いて，赤・藍（あい）・黄・墨の四色に色分解し，多色印刷用の平版を作ること。また，その版。多色平版。

プロセスカラー：シアン（青）・マゼンタ（赤）・イエロー（黄）の 3 原色に，ブラック（黒）を加えて作る色。カラー印刷に使われる。

・・・・・・じゃなくて。

プロセスの方が、ワークフローを複数包含した、仕事や業務全体をさす言葉のようです。
果たして、先の2つの記事、この意味で使っていたか、あいまいです。

・・・・・とりあえず！
これ以後は、上記に気をつけて、ワークフローとプロセス、使い分けていきたいと思います。

ワークフローがない

前回の記事で書き出したものの、私の中でワークフローは全て「なんとなく」。なんとなくのものを改善しようと思っても、なんとなくにしかならないので、まずは、ワークフローの明文化が必要ではないか。前回の記事でそれを書き出しながらも、もちろん仕事によってワークフローには違いが出るが、この手順でやろう、ということを決めてから、とりかかるということをやっていないのでは・・・・。
まずここからか。

というわけで少し参考になりそうな例を探してみた。
お手軽に、ウェブで・・・・

https://baigie.me/sogitani/2018/08/baigie-workflow/

最初に探し当てたものが、かなり思ったものに近かったので、これを書く手を止めて熟読してしまっていた。まずこれを参考に、一度ワークフローを明文化してみる。

明文化したワークフローはどう使うか？

上記参考サイトにあるように、ワークフローを全て書き出したらプロジェクトによって必要なものを組み替えて使うとのことなので、「プロジェクトの進捗状況をタスク毎に細分化したシート」の形でアウトプットする。このアウトプットのアウトカムが「ワークフローを明文化すること」になり、ワークフローの改善はこのアウトプットをその時々の反省をもとに書き換えていくこととなるだろう。

反省の時間を組み込むこと

ひとつの仕事が終わったら、もしくは終わる前から、次の仕事は始まってしまう。終わった仕事を振り返らなければ「改善」はできない。プロジェクト自体に反省の時間を組み込むこと。これは、それこそ、ワークフローの中に含めるようにすれば良いのでは。
また、日々の仕事の中でも振り返る時間を取るようにルール化するのがよいのではないか。1日15分なり時間を決めて、振り返る。

時間単価の考え方

かなりざっくりとしたことを言えば、
1年に稼ぎたい金額 ÷ 労働に使う時間 ＝ 時給とすべき金額
になるだろう。

という感じで計算している。見積もりを書くときはこれを基準にしていく。ここに具体的な金額は書かないが、この額面を見てしまうと、最低時給が1,000円に満たない労働がちまたにあふれている件について、おかしいよ、それほんとおかしいよと言わざるを得ない・・・・。

1日に何時間働けるか？

フリーランスなので、労働基準法は適用外なので、実質何時間働いてもいいのだが、規則正しい生活と家事を回すことを考えると、子育てというタスクはないけど、1日に集中力を保って働けるのは、せいぜい5時間が限度です。これ以上働くと家事とか自分のケアが面倒になって、資本＝私の健康な身体を保てません。これは自分の能力の限界なのだなあ、と思うと同時に、8時間って働きすぎじゃね、って思ってます。労働基準法で定めているのは、1日8時間以上働くなということであって、1日8時間働けという意味ではない。もちろん経営側の人間は、なるべく同じ給料で多く働かせたいわけだから上限の8時間いっぱいに勤務時間を取ろうとするわけだけど・・・。いい加減考え直していいと思ってる。

1日の時間配分とルール

外出したりなど用事もあるので、あまり厳格に決めることはできないが、一旦下記でやってみようと思う。

時間配分

1. その日集中してやると決めた作業（3時間）
2. 急ぎの作業（1時間）
3. メールへの返信・スケジュール管理（0.5時間）
4. バックアップ管理・バージョン管理（0.25時間）
5. 業務の見直し（0.25時間）

ルール

• その日の15時までにきたメールは18時までに返信する
• 15時以降に来たメールは翌日12時までに対応する
• 平日に片付かなかった分は土日いずれかを使うことを許容する

1は3の時間を使って前日に計画したスケジュールにそって実施するもの。
2は、何かとすぐやってほしいと言われる作業が発生しがちなので、あらかじめ時間を見ておくもので、なければ1の作業に追加するか、勉強など他のことに使う。4は管理法を明記する。5はレポートの形で書きためる。
実際に使った時間についてはToggleを利用してログを取り、見直しに利用する。

ドキュメント管理

ワークフロー関連のドキュメントはGoogleドライブで管理する。
共有が容易であること、デバイスによらず閲覧が可能であるから。

つらつらと思いつくままにアイデアを書きとめたかたち。まずやってみて、という感じになってしまい、デザインリサーチの話とは全く関連がないが、あの本の中でもプロセスの透明化と検証を可能にすることが繰り返し述べられていたので、重要なことなのだと思う。
どんな制約の中から、どんな選択肢を考え、それをどんな基準で取捨選択したか、実際にどう実行したか、その結果どうなったか、その結果から何を見直すか・・・この繰り返しかのかなと。
いまは、選択肢を考えたところだろうか。取捨選択をせずに実行に移そうとしているわけだから、すでに流れから逸脱しているのか。

近日新しい仕事が入る予定なので、そこで実際ワークフローにそってやってみることになると思うので、また、なやみあぐねじたばたする様をここに書くと思います。

前回の記事が前提の把握に終始したので、今回こそ詳しく仕事のプロセスをまとめたい。前回に引き続き、粒度を測りかねるままだが、とりあえず思いつくことを書いてくので、今回も長くなる。

概ね以下のような流れ。

1. スケジュール押さえ・見積もり
2. 受注決定
3. デザインカンプ受け取り（入稿）
4. 制作〜初回プレビュー
5. 修正対応などのあと納品・公開
6. アフターフォロー
7. メンテナンス

仕事の内容によってもこのワークフローは変わる場合がある。今回は仮に、WordPressを利用した、ローカルビジネスの小さなボリュームのサイトを作ると仮定する。最終的なサイトオーナーからの直接受注ではなく、間に取引先が入り、下請けをするという形。

スケジュール押さえ・見積もり

スケジュールの押さえは大体見積もりとともにやってくる。この段では、見積もりの結果次第で受注が決まるというより、見積もりの結果、こちらへの発注内容に差が出る。つまり、できれば全部まるっとお任せしたいが見積もりが予算を超えたら、先方でできる部分はやることになるらしく、こちらの作業が減る結果、見積もり額を減らすことがある。

見積もり時には最低限サイトマップを提出してもらうようにお願いするが、「ある過去案件と同じ感じで」というやりとりになる場合もある。できれば、仕様書や要件定義書、コンテンツ一覧としてのサイトマップやページ一覧を用意して欲しいと思うものの、全てが揃ってくる事はまずない。不完全なサイトマップがあるだけの場合も多いので、不足分を補ったり、ページ一覧を書き起こすこともある。WBSを書くために要件定義をすることもある。「ある過去案件と同じ感じで」とは言っても全く同じ事はあり得ないので、ページ一覧や要件定義を書きながら手を動かす中で、見積もり時に確認する点などを洗い出していく。

WBSや要件定義に時間を取られるので時短を図りたい。また、取引先とも要件定義を共有して、機能の確認やタスク管理に役立てたいと思うものの、書く内容が専門的になってしまうことや、先方は特に把握したいと望んでいなかったり（？）するのでうまくいっていない。要件定義〜WBS〜タスク進行管理をトータルに管理するツールもおそらくあるのだろうが、今のところGoogleドキュメントで個別に管理している点もある意味課題。

WordPress案件では必要な機能が実際に実装可能なのかを検討することもある。こういうものは、時間があるときなら勉強と割り切って、見積もり外になってもいいので、テストサイトなどを使って試すこともある。

過去案件と同じぐらいで、、、という場合、取引先では「前と同じぐらい」の金額を前提としているのはわかっているので、では前と同じ金額でやりましょうか、というやりとりになることも少なくない。ありがたいのは、やってみた結果しんどかった場合は（双方それを認識しているので）作業の途中で追加料金をお願いする流れもある。

見積もりでは受注を左右するシーンがほぼないので、スケジュールもこの時点で締め切りが見えているものが多い。ただ、締め切りは決まっているのに、入稿のタイミングはわかりません、ということもある（信じられないことに）。

見積書を書くこともあれば、メッセージでX万円ぐらい、というやり取りで決まることもある。

受注決定

契約書を交わすということがないので、受注決定の瞬間というのはかなり曖昧だ。見積もりの返事があったときなのか、入稿があったときなのかよくわからない。スケジュール押さえの後なかなか連絡がない場合は、他のスケジュールにも影響するので、どうなっているのか確認することが必要になる。
未受注のもののスケジュールや管理は曖昧になっていると、これを書きながら気がついた。

デザインカンプ受け取り（入稿）

デザインカンプはウェブデザイナがPSDやイラレで作った、サイトデザインの仕上がり図である。これを受け取ったときに、ざっと全体を確認し、最初のプレビューの内容と期限を相談する。
このときに不明点について山ほど確認することになる。またトップページだけ先に与えられ、他のページは五月雨でデータが届くことも少なくない。

また、受注が決まったときに、少し手が空いていれば、入稿に先んじて必要な作業を進めておくことがある。特にWordPressの場合は先にやっておけることが山ほどある。サイトオーナーで記事を増やしていく前提なので、要件に応じて先に管理画面の部分を整えておいたり、必要なプラグインやブロックエディタのカスタマイズなど。また、テーマ設計についても、スマホでのメニュー開閉など、必ず必要になるようなものは部分的に先にコーディングしておく。

制作〜初回プレビュー

引き受ける仕事は全てレスポンシブサイトになる。本来であれば、PC用、タブレット用、スマホ用、などと、画面幅に応じたデザインのカンプが欲しいところだが、これが揃って出てくる事はほぼない。トップページだけはPCとスマホ両方あるが、それ以外のページはPC用のみか、スマホ用のみか、どちらかのみが提供される。また、制作する全てのページのデザインカンプが作られるわけではない。ページによってはテキスト原稿のみやワイヤーフレームのみの場合もある。なので、足りないぶんは、私の裁量で作ることになる。裁量になる部分については、特段の必要がない限り、こちらの勝手で進めることが多く、プレビューの後に気になるところを修正対応する流れ。

修正対応などのあと納品・公開

プレビューまでが、トップページとテンプレート部分だけなら1週間以内、全体的なプレビューの場合は2週間ぐらい。修正を繰り返しつつ、納品までは入稿から1ヶ月後というのが理想。これ以上かかるのは正直苦痛で、なるべく短いサイクルで終わらせたい。時間がかかればかかるほど、関係者は記憶を失うし、私も同じだ。覚えておく、思い出す、はある意味コストである。

記憶を失うのは仕方ないので、それを前提にして、WordPress内での実装のことなどは、なるべくドキュメントで残すなどしておきたいが、あまり万全にできていないのは課題。要件定義とも関わる部分かもしれない。

新たに取り組みたいこととして、スタイルガイドの制作がある。WordPressサイトの場合は、概ねブロックで実装することになると思うので、非公開の記事でモジュールライブラリを残しておくなどの方法を検討したい。

プレビュー後、コンテンツの入力を私自身ではなく取引先やサイトオーナーが入力していく場合が多い。入力のトレーニングはこの段階か、公開後に行うこともある。

納品時の状況を少し細かくメモをしておくのは大事だと思うが、あまりできていない。データを残す、キャプチャをとる、実装などの判断についてのプロセスを明らかにしておくなど。カルテのような物を想定しているが、具体的にどう作るのか定まらないので、先行事例があるなら参考にしたい。
ただ、それってコーダの仕事かな？と思うこともある。引き受けるプロジェクトで誰もそういうことをやっているように見えないのと、そうすることが自分の仕事のためになるかと思ってやるべきかなと考えている。しかし、そういうわけでモチベが低いので、なかなか、手につかない。

アフターフォロー

WordPressでサイトオーナーが更新をしたり取引先が管理したりする中で、不明点はいつでも問い合わせに応じるし、ちょっとした修正点などは、納品後も対応することがある。サイトオーナーの更新トレーニングがサイト公開後になった場合などは、そこそこ大きな修正も引き受けるが、それは本来やるべきことの範囲だったとするので、追加料金をとることはない。

詳細は後述するが、WordPressは定期的なアップデートが必要になるが、そういうものは、別途メンテナンスとして、年額や1回いくらの取り決めで対応することもある。

メンテナンス

サイト納品後、WordPressのアップデートを数回分と、使い方の問い合わせや、テキスト修正などの軽度の変更を随時対応するというような内容で、1年更新の契約のような形で引き受けることがある。その場合、WordPressのメジャーアップデートがあった際に、いついつ更新を実行します、の連絡をこちらから行う。こちらから働きかけが必要なので、メンテナンス取引はあまり増やしたくないと思っている。

また、取引先のひとつとは月額で契約していて、その取引先が関与するサイトについて全般的に管理を行う形態もある。これはあくまで先方から依頼が来て諸般対応するものなので、負担には思わずむしろ定期収入でありがたい。

ひとつひとつのサイトに、それほど深く長期的に関わることができないのが、今の体制の限界とも言える。基本的に下請けなので、作業スコープから考えると、浅い関わりになるのは当然でもある。個人的な考えだが、ウェブサイトのことは、日々の管理や長期的な展望など、やれるだけのことは自社でやる上で、制作会社に助言を仰いだり外部の専門家に意見を求めるなりするのが良いと思っている。小さな企業であっても。そういうとき、気軽に相談ができる相手のひとりでありたいという思いはある。

以上がワークフローだが、書き出して思うのは、自分の能力上、継続的に管理するということが苦手で面倒と思う節があること。それなのに他人には「ちゃんとする」を求めてしまいがち。あとは、取引先との付き合いの長さや深さゆえになあなあでもなんとか回っている部分が多くあること。そのことはそれで双方問題がないのなら、特に改善する必要はないのでは？と思ってしまう。元も子もないが、だからと言って、このままを続けていくことには、漠然とした不安があるので今見直そうとしているのだ。見直すポイントには判断基準が必要そうだということはわかった。

次回は改善するポイントについての優先順位や判断基準について考察を続けていきたい。

はじめに

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

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

業態について

前提として、私はフリーランスで働いている。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を書くついでに、簡単にまとめるようにしている。ただ、相手に渡しても確認されていなかったり理解されなかったりするので、意味を成さないなと感じる。これも課題。

契約書について

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

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

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

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

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