Wednesday, August 5, 2020
 

テレワークと常駐でフリーランスを9年やってきて今思うこと

ちょっと間が空きましたが、2020年6月を以て、私カネダも開業届を出してから9周年になりました。

その中、現在コロナ禍の状況ということもありテレワーク/リモートワークの必要性が強く叫ばれるようになりました。

わりと早い段階から、フットワーク軽くフリーランスのWebディレクター/プロジェクトマネージャーとして、それらを体験してきましたが、今の状況だからこそ思うことや、気づきなどをツラツラと。

”フリーランス”という立場だから見えてくるもの

幸いなことに自分が仕事として携わってきた方々は、案件のご相談を受ける際に最初からリモートワークに心広くご理解をいただくことが多いです。

というのも自在に受託するかどうかの判断の際にも、こちらから具体的に
・現状使われているコミュニケーションツール、プロジェクト管理ツールの確認
・未導入の場合は、それらの導入をお願いする
・別件を同時進行しているので、それでもよいか(別件のMTGで抜けるかも)
・ネットワーク(WiMAXなど)も持参するけどよいか
などを細かく確認してからというのが多いです。

その意図は
・社内文化としてメール、口頭指示がメインなっていないか
・扱う案件がどれくらいクローズなものか(IR系や官公庁系、大企業の新商品PRサイトなどは、厳しい場合がある)
・上長的立場の人と自分との相性
などなどを、僭越ながら推し量る部分を含んでいます。

フリーランスという立場から、同時に複数の企業さまの案件を扱いつつ、それぞれの社風に合わせた立ち回りを求められることもあります。その中で、自分の仕事への負荷を軽減する意図で、導入時点で、最大公約数的に担保できる落とし所を探る感じかなと。

テレワークが絶対に最高というわけではない。

個人的にテレワークを導入する上での最大のメリットは、家で仕事ができるということではなく”該当のプロジェクトにフォーカスできる環境が作れる”ということだと思っています。
コミュニケーションツールやプロジェクト管理ツールも、そのプロジェクトのスタッフおよびクライアントのみのメンバーで構成され、その進行に特化したやりとりがされる形となります。

ですが、常駐案件の場合は、携わるプロジェクト”以外”のメンバーも当然その場にいますし、良くも悪くも自然と外部の情報も耳にすることもあります。
内容次第ですが、ノイズということではなく少なからず他社/他者の動静を見聞きすることで得られるものも多く、単一のプロジェクト進行では気づけないこと、また深くなるからこその見落としの部分なども避ける効果も一定以上あると感じています。
それらが少ないことがテレワークのデメリットになるえるかなと。

エンジニアの方達からすると「一瞬いいですか」が無いのはメリットだとは思いますが。
コミュニケーションツール上で、自分がメインで携わってないチャンネルに横から口を出すのはパーソナリティに依存する部分が多く、なかなか根付くものではありません。
多くは当事者意識と奥ゆかしさの微妙なバランスを求められるものです。

本当に”働きやすい環境”とは

現状、コロナ禍ということもあり、感染リスクを避けるためにテレワークが推奨をされていますが、緊急事態宣言後、多くの企業が通常の通勤形態に戻している事を踏まえると、まだまだ日本の企業においてはテレワーク文化が根付くことは難しそうです。見ている限りベンチャー,スタートアップ系のIT/Web系企業ですらその様子。

ただ感染リスクどうこうについては一旦棚にあげて、実際、カネダ個人としては常駐をお願いされることはあっても、上記に挙げた条件がクリアされていれば、場所自体はそこまでネックにはなりません。極論、電源と電波さえあれば仕事自体はできるので。

いままで大小合わせて様々な企業さんと常駐ないしテレワークから携わらせてもらいましたが、
その場その場で、いつも感じるのは「やっぱり仕事ってのは”人”なんだな」っていうこと。
環境作りも大事ですが、一番に見るべきは、その場にどんな人がいて、自分がどういう立ち位置を求められているか、またその場は今後どうあるべきかを考えられるかかなと。
フリーランスだからこそ俯瞰の目線で見れますし、それ自体が間違っていなければ、ダメ元で提案してしまえば良いもの。啓蒙のコストなどもありますが。

単純にテレワークだバンザーイになるのではなく、その場にどういう人がいて、その人達それぞれに、どういったコミュニケーションが最適なのかを見極め、滞りなく進行するための方法と環境作りを考える。

道具や環境は大事な要素ではありますが、一番は”人”ということを忘れないように。

こんな状況ではありますが、みなさま、どうかお身体お大事に。
引き続き10年目もよろしくお願いいたします。

 

ファシリテーターだから実現できる”楽しい会議”

社内や部署単位の報告会議のみならず、会社間の現場担当者同士の打ち合わせ、営業から制作スタッフへの情報伝達、最近ですと複数の職種を跨いだブレストや、プロトタイピングのデザインツールを用いたディスカッション形式など、用途によっても会議の形態は様々な意味を持つようになってきました。

その中でも共通して言えるのは”ファシリテーター”の存在意義です。

ディレクターないしプロジェクトマネージャーのポジションにある方なら、「○○さん、次の会議のファシリテートよろしく」などと依頼を受け、段取りを任されることもあるでしょう。

本来のファシリテーターの定義としては一般に『議事進行やセッティングなどを担当するが、会議中に自分の意見を述べたり自ら意思決定をすることはない』とされています。

ですが、それらは参加スタッフが会議に対してモチベーション高く参加していることが前提となっており、実際の場においては、スタッフが下を向いたまま淡々と会議が終わってしまい、気がついたら形骸化してしまうというケースも少なくありません。

またプロジェクト進行において会議は切っても切れないものですが、コミュニケーション設計上、「会議は悪」とする派と「会議は効率的」とする派で意見が分かれるのも頭を悩ますところです。

会議は本当に”効率的”なのか

一般的に会議の役割としては

  • 現在の状況の共有
  • 現存する課題の共有
  • 予想される結果の共有

ざっくりと上記になります。個々が課題に対しての対処の際、判断に必要な情報を共有し、一堂に会することで作業着手までのタイムロスを防ぐことが目的となります。

ですが、会議の多くは”会議をすること”が目的化してしまいがちです。また、上記のような共有は昨今では物理的ば招集がなくてもプロジェクト管理ツールやチャットによるリマインドでも事足りるようになりました。

それでも「顔が見える現場」というスローガンの元、椅子の少ない会議室に複数人集まり、結局それぞれが別の仕事をしながら上役のありがたいお話を聞いたフリして終わる会議の多いこと。それが果たして効率的なのかは首を傾げるところです。

じぁあ、会議はすべからく悪なのかと言われると一概にそうとも言えません。

情報共有についてはツールやコミュニケーション設計から補完できることはあっても、優先度に応じた空気感や、どうしても要約された情報となるとtodoの列挙となってしまい(その用途なら構いませんが)、経緯や文脈の共有にも限界があるからです。

人は、リラックスした時に物事を判断しがち

会議(意思決定)あるあるにもなりますが、会議中は一言も発さなかった人が、会議が終わって立ち上がった途端にリラックスした顔をして自分の意見を述べたり、タスク依頼をしてくる場面を何度も見てきました。

会議中にもそれらを踏まえ「他に何かある方?いませんか?本当にいませんか?」と念を押したこともありましたが、やはり”会議が終わった”というリラックス感には勝てず、終わった途端に重要なことを述べる方は後を断ちません(議事録とってる側としては大変困るのですが)。

また喫煙所などでの上司と緩い雑談から「そういえば例の件、こんな感じでやっといて」などとスナック感覚でその場で決まることもままあります。

そのためにディレクターは喫煙しましょうとは言いませんが、これでは何のために苦労してメンバー招集して会議をしているのか分かりませんし、それを基に結局、各スタッフへ共有をする手間が発生するため、あまり効率的とはいえません。

ファシリテーターに求められる”余談”のコントロール

”アジェンダの無い会議は世間話と一緒”と言われるくらい、会議は事前の準備が大切になります。

共有する題目は何か?その内容が正しいのか?現状の取り組むべき課題の優先度は?枝葉末節なことに時間を取られ本来議論すべきことがボヤけてしまったら?途中で上役が「ジャストアイデアだけど〜」とか言って無茶ブリしてきたらどうする?など、ファシリテーターは会議前に考えておくべきことは多くあります。

しかし、情報共有を意図する会議の完成度が高くなればなるほど、会議自体の形骸化は避けられません。偉大なるマンネリという見方もあると思いますが、参加スタッフの熟練度が高まるにつれ、比例して会議することの意味が疎かにされがちです。ファシリテーターの目的は、ただ淡々とアジェンダを消化することではないのです。

その際に、ファシリテーターに求められるのは”押さえるべきポイントと抜くポイントのメリハリ”が重要となります。

社会人という立場ではあるものの、学校教育の延長からか”場をわきまえる”という考えがしみついたままだと”会議は誰かの話を聞く場所”という定義から抜け出すことができません。

会議前にアイスブレイクとして雑談をする手法もありますが、効果的と思われるのは、アジェンダとアジェンダの間に、ちょっとした世間話的なトピック(天気、身の回りの出来事、この後のランチの話など)を「そういえば〜」と挟み、自由な会話の場であるという演出を意識してみてはいかがでしょうか。

会議を無下にダラダラとはせず、時間内でメリハリを持ち、プロジェクトの空気感を伝え、時に笑いながら迅速な決断をする場にできるか。

それらを可能にできるファシリテーター/ディレクターならば、きっとそこから生まれる良い効果がプロジェクトの成功に寄与されることでしょう。

 

これからのプロジェクト管理ツールの使い所と、成すべきゴールとは

まだまだ一般的とは言い難いかもしれませんが、Web系・IT系企業の多くは社内業務の進行においてプロジェクト管理ツールが導入されるケースが増えてきました。

BacklogやTrelloやRedmine。エンジニア向けならGithubにZenhubを入れてカンバン型にして管理進行することも可能です。

しかし企業文化や色々な畑の違い、NDA的な制約などでツールの選択からの良し悪しについては、様々な好みが分かれやすい部分もあります。

また、プロジェクト管理ツール自体の特性や狙いを利用者側が理解していないため、「とりあえず上司が使えというから使ってるけど。。」という現場の声もチラホラ聞き及ぶところです。

プロジェクト管理ツールの”狙い”

プロジェクト管理ツールを導入することで得られるメリットの内、一般的に期待されることの多くは

・タスクの共有

にあるかとは思います。しかし、この場合、あまりにも主語が大きく、そのメリットを得られるためのコスト部分の精査が十分でないこともあるようです。

受託/クライアントワークでプロジェクト管理ツールを導入する場合、一番に気を使うところは、まず”クライアントの担当者にいかに『正しく』利用してもらうか”があります。

キックオフMTG時などにプロジェクトにおけるコミュニケーション設計を行い、進行時におけるフローやルールなどをwikiに記載。で、蓋を開けてみたらメールでやりとしてるのと変わりがなかったという場合です。

「文化が違うから」で済まされてしまう局面もありそうですが、効果として期待する以上、そうもいきません。むしろ文化が違うからこそ、共通言語として5W1Hに沿ったロジックを基に、やること、進捗、結果を共有する必要があるのです。

プロジェクト管理ツールが担うのは判断と責任の所在の見える化

進行管理だけならxlsでも良いですし、タスク依頼だけならメールだけでもことは足ります。

最近はプロジェクト管理ツールの機能拡張でボタン1つでガントチャートの作成も可能になりました。

プロジェクトを進める上でのコストは徐々に軽減化されつつあり、リマインドやステータス管理については、botやAIなどでも、ある程度カヴァーが可能となってきています。

翻って、人の役割として今後より重要になってくるのが、プロジェクト進行においての判断と責任の所在となってくると感じています。

今、何待ちで、誰が、いつまでに、何を決めるのか。

チケット期限が燃えたままで形骸化されたプロジェクトの多くが、上記に関する言及やコメントが少ない印象です。

プロジェクトの成功は”期日通りに要件を満たすこと”と定義するのなら、そのためのプロセスとして大事なのは、メンバー毎の思考の見える化となってくるでしょう。

もちろんプロジェクト各メンバーすべてが意識高くあれという訳ではありませんし、ディレクター/プロジェクトマネージャーの仕事の1つとして、それらの啓蒙も含まれる部分ではあります。

プロジェクト管理ツールを思考の共有として、いかにナレッジをためやすくし、学習サイクルを早めることで、結果として正確かつスピーディーな判断を行えるようにできるか。

異文化の企業と触れる機会の多い受託ディレクターだからこそ、ツールを導入しただけで満足せず、常にどう工夫できるのかを考えていきたいものです。

 

暗黙の『甘え』が生む負の連鎖を断ち切るために必要なこと

「制作時間が無い!、足りない!」という言葉、現場で良く聞きます。併せて「突然、夜中に作業を差し込まれて、徹夜確定‥」なども。
ブラック企業の是正など、政府の企業労働時間の改革の成果は、ちょっと分かりませんが、少なくとも自分の周りでは、なかなか改善が見えにくい状況のようです。

クライアント担当者から「◯/◯までに〜の公開をお願いします」と依頼があった場合、ディレクターは「◯/◯までに公開するためには、その前のいつまでにテストアップをし、素材はいつまでに。作業工数/時間はこれくらい」といった算段が当然必要です。

そして、それらをWBSに落としこんで制作へ共有しているはずなのに、蓋を開けた炎上しているというパターンが大変多い。それはなぜか。

そもそもの業界の構造的な問題点については、さて置いておきますが、上記の様な声が聞こえる現場には、ある種の共通点があると感じています。

ウォータフォール+プロジェクト管理ツールの功罪

ウォータフォールの構造の場合、案件のスケジュールの調整をするのはディレクター/営業の仕事です。
クライアントとの調整からしても常識の範囲で作業時間を確保し、WBSに落として展開されていることでしょうし、最近は、プロジェクト管理ツールでも管理されているはずです。
クライアントからの依頼をtodoにし、起票していく形ですね。

しかし、ウォータフォール+プロジェクト管理ツールの時に気をつけたい部分が1点あります。それは期日管理は作業当事者がコミットする意識を持つことです。

プロジェクト管理ツールは起票者が起点となるので、体系的にウォータフォールが具現化され、起票時の期日に合わせて作業するというのが暗黙的にあります。
しかし、起票時点においての作業期日はあくまでWBSを元にしているため、実に伴っていない可能性があります。
バーンダウン的な精査から、ディレクター側で期日をざっくり更新することはありますが、それだと正直、対処としては後手です。
理想は起票された時点で作業者が内容を精査し、工数/期日を自らがコミットしていく意識を持つことが大事です。

作業時間は自分で確保する

案件が炎上しやすいパターンのいくつかである、

  • プロジェクト管理ツール上で期日が切れたままになっている
  • 作業者自身が期日をコミットしていない

上記が露見された場合、注意が必要です。
チケットをまとめて期日更新するっていうのもありますが、付け焼刃的ですし、根本解決にはなりません。

プロジェクト管理ツールの期日管理が甘いディレクター/営業ほど、如実に制作へムリな期日で依頼が飛んで来るケースは多いですし、すべてが「暗黙のなるはや対応」化していることも。当然ですね。そういう管理してるからチケット期日が燃えてる訳で。

逆もまた然りで制作側もまた、期日管理が甘い場合、差し込まれても文句を言えず、深夜対応も当たり前。果ては習慣となってしまい、営業「とりあえずチケットで投げとけばいいか」制作「深夜なのに作業依頼来た。。やらないと」と思考停止状態になりかねません。

期日が迫った状態での作業時間ではクオリティが上がる訳もなく。
代替として制作側の人を増やす方法も負荷分散にはなりますが、クオリティ担保にはなりえない上にコストも高いので策としては慎重な判断が必要です。

お互いさまの甘えに甘んじないこと

諸悪の根源は、営業「ムリな制作期間でもとりあえず制作がなんとかしてくれるはず。」制作「スケジュールは上が調整する仕事でしょ。」といった、互いの甘えが原因です。
そういった現場のプロジェクト管理ツールを見ると内容が依頼->報告のやりとりのみとなっており、『調整』している痕跡が見えません。

『兵隊は何も考えない』働き方がしたいのなら、その限りではありません。しかし制作は制作分野担当としての自尊心を持ち、自分の成果物のクオリティ担保のために自分の作業時間は自分で確保する意識を持つこと。
ディレクター/営業もまた、制作と同じマインドでクライアントと調整をすること。

闇雲に就業時間短縮を目途とするのでなく、そうした『毅然としたマインドを持つこと』ができるかどうかが、ブラック/ホワイトを決める本質的な要素になるのだと思います。

 

『受託』にこそ必要なステップアップの心がけ

一般的に『受託』としてお仕事を受ける際に多くの方がイメージするのは制作代行を示しているかもしれません。

いわゆる「企業内に自社のWebサイトを作れる人間がいないので、Webサイト制作の代行をお願いする」という訳です。
この場合は、年度末など予算的な締め日の影響からスケジュールが切られ、期日までに作ったサイトをzipにして納品ファイル送信して、ハイサヨウナラって事になりがち。

ですが、成果物の定義は個々にあるせよ、受託本来の意味としては、この限りではありません。
派生の考えとしてはWebサイトを制作した後の運用、保守メンテナンス、MA(マーケティングオートメーション)などを利用した販売戦略の組み込み、もっとわかりやすくASPを組み込んでECサイトのCV分析、改善施策などなど。
一言に受託と言っても様々あり。また、◯◯代行という括りから見ても切り口のバリエーションは多くあります。
ここはあえて”代行”という働き方ではなく、そこからのステップアップを鑑みた違ったビジネスの方法について考えてみたいと思います。

『売る』ために必要なヴィジョンの具現化、コンセプトを作る過程を『売る』

タイトルでネタバレ感がありますが、制作リソースを使う手前の部分。
コンセプト作りや、そもそもで「Youどうしたいの?」ってところをクライアントと共に考える、その過程をビジネスとする視点です。

具体的な方法論としては、リーンキャンバスなどを使いクライアント(担当者)の考える「弊社の強み」のヒアリング。そこからの改善点と具体的な手法を抽出していく作業になります。

その為のファシリテートは大変重要となります。個人的には先方企業の知識は、事前にあまり詰め込み過ぎず、失礼にならない程度に必要最低限な位に留めるのが良いでしょう。

なぜならユーザー/カスタマーはその企業の内情なんて知ったことではないからです。知った風な態度を取るよりも、知らないことは知らないと素直に伝え、むしろ担当者に雄弁と語っていただく内容の中に、その企業の姿勢、逆に一般の理解との乖離の溝が見えたりするものです。
しっかりと議事録に残し、改善のToDoとして分解しておきましょう。

眉唾の参考資料こそアジェンダとしてフル活用できる

商販の場合、BtoB、BtoCに限らずペルソナを設定されているケースが多いでしょう。
しかしリサーチ会社の利用などがない場合は担当者のヒューリスティック的な仮説の範疇に留まることが多いかもしれません。「ウチはこういう商品だから、こういう世代の人が買うだろう」って感じ。

マーケティングの根拠としては脆いものですが、ことスタートとしては、そういった良い意味での思い込みがあるからこそ、後の改善/検証の原動力になりえるケースが多く感じます。
むしろ背丈の合わない規模でスタートからリサーチに予算をつぎ込んだビジネスは、リサーチしただけで満足してしまい、以降の改善まで手が回らず「で?どうするの?」ってなりがち。
リサーチ自体が悪いという訳ではなく、競合調査からの傾向と対策の仮説提唱までプロジェクト全体の流れがあってこそ意味をなします。

なのでクライアントとの打ち合わせ時に語られる「ウチはこうだから!」な姿勢をいかに客観的に自身の目で分析できるか。その研磨のプロセスにこそ価値を見出していきたいところです。

目的の共有と『伴走』をビジネスに

デザインカンプを作っての提案資料の作成は決裁を取ってお金を引っ張ってくる上では錦の御旗となりますし、必要だというのは納得のいくところです。
しかし、いくら完璧な資料を作っても蓋を開けてみたらプロジェクトとしては予算と時間を縮小され「思ってたんと違う」になってるケースが多いです。

むしろ最初から答えのない成果物を上納することより、答えを一緒に作るプロセスをサービスとする方が余程、クライアントにとっても有意義であり、モノとしての成果物ではなく、成果そのものにコミットすることの大切さが理解できるでしょう。

まぁ、プロジェクト発足前のクライアントとの関係性をどう構築するかについては課題はあるとは思います。
ですが時間や体力の切り売りだけではなく、よりコンサルティングに力を入れたビジネスアプローチの必要性、そのためのツールとしてのWebという意識が、今後、制作側/クライアント側双方に求められる概念になってくるはずです。

顧問的な立場からいかに相手に伝わりやすく独自の専門性のあるサービスが提供できるか。
そこに今後のWeb屋のあるべき姿見えてくるかもしれません。