Sunday, November 19, 2017
 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

技術者の手を止めないプロジェクトマネジメントのコツと役割

ここ数年にはなりますが、個人的な環境の変化としてフロントエンド系エンジニア、サーバー側の管理者の方など、技術寄りの方々と一緒にお仕事をする機会が増えております。

しかし一般的なウォータフォールの制作環境に於いて、”下流”に位置づけされやすいエンジニアのポジション。

どことなく軽んじられやすく、上が決めた無理難題をパワーと根性で解決するいわゆる『IT土方』と自虐的な言い回しも聞こえる次第なのですが、プロジェクトマネジメントとして全体を俯瞰で見るうちに、いかにエンジニアの方が苦労されているのか、また、その問題解決の糸口が見えつつあるので、個人的備忘として。

エンジニアが技術を振るえる環境作り

ディレクターないしクライアントからのメールによる作業指示。
漠然とした内容が多く「これやっといて」的なニュアンスで投げといて「後で電話/席まで行って説明すればいいや」とお考えの方も多いかとは思いますが、
そのメール内容を読み解く時間、作業モードのエンジニアの手を止めてる時間のコストを考慮された事はありますでしょうか。

後者の場合、「詳しく説明するからこの時間空けといて」と事前にアポを取り、内容を整理した上でお話されるのならまだしも、エンジニアの席に行くまでのわずか数歩の間に考え、挙句の果てに「あれ何しに来たんだっけ?」と言われも「知らんがな」ってシーン。わりと多く見る機会があります。

言わずもがな、ウォータフォールと聞こえは良くても伝言ゲームの言い回し変えただけみたいなところは、正直あるところではあります。
しかし、伝えるだけでも時間は消費しており、その間の作業時間はロスしていることを考慮し、いかにエンジニアへ端的にかつ整理した内容を伝えるのか。一緒に思案する事項なら何を考えて欲しいのかをオファーする姿勢は持っていたいところです。

コミュニケーションツール運用時の工夫

上記にも軽く挙げましたが、メール/口頭でのやりとりはリスクが大きいもの。できることなら避けるか必要最低限に留めたいところです。
最近は、社内チャットやプロジェクト管理ツールの利用も当然のことになりつつあります。
しかしそれら便利と思われるツールもエンジニアにとっては絶対的な便利さとは言えないようで。注意すべきは通知機能の使いドコロ。

どうしてもアテンション/アラートを伝えたく、些細なことでも@をつけてエンジニアに連絡するケースが多く、都度でエンジニアの意識がそちらに削がれるため「あー、またなんか来てるな。まぁいいや」と本当に緊急度の高い通知などはスルーされてしまう可能性があります。

チャット=即時会話ではなく、あくまで”ログを残しておけるツール”という意識での運用がエンジニアにとっては好ましいようです。@を入れての通知はプロジェクト管理ツールとの併用を念頭に適材適所に留めたいところ。

技術者がプロジェクトマネジメントすることのメリット/デメリット

該当の方の社内ないしプロジェクト内での立場や個人的な性格にもよるかとは思いますが、
チームリーダー的な役割の方がプロジェクトマネジメントを担うケースがあります。
個人的にはツールなどを活用しエンジニアにとって、手を動かしやすい環境が作れれば問題はないのですが、その時に注意したいのは”俯瞰の視点を持てるかどうか”にかかっています。

端的に言うと

  • エンジニア=深く、かつより研磨する視点
  • プロジェクトマネジメント=浅く、他者に説明する視点

の両面を持つ必要があり、プロジェクトが続く中で思考の切り替えだけでも、それなりの労力がかかります。

ことプロジェクトマネジメントに於いては一箇所に留まっての深掘りは他所へのケアに手が回らず、まして自身でコードを書きながらとなると、”自分のコード”、”クライアント対応”、”社内リソース”の3つ+αへ気を配ることになり、効果的とは言い難いです。

しかし、社内のテクニカルな品質管理の底上げという面では、その限りではないですし、スタッフ間の相対的な技術力の差(正確さ、スピード)を、細部の内容を理解した人が把握できるという面ではメリットは大変大きいです。

テクニカルディレクターの必要性と役割については割愛しますが、プロジェクトマネジメントとの住み分けは明確にした上での配置が肝になると言えるでしょう。

プロジェクトマネジメントだからできるエンジニアへのバックアップ

前述の通り、まだまだエンジニアの作業環境の自由度は低く、制作スケジュール的にもエンジニアマターは五月雨開発は当たり前、「量産、流し込みだから」とか「コード書けばいいから」と、軽く思われるなど、理想的な状況には至ってはいないかもしれません。
またエンジニア側からも独自文化と一般との隔たりもまだあり、なかなか理解され難い状況も続いています。

そんな納品の辻褄合わせの犠牲になりがちなエンジニアの方々にとって”理想的な環境とは何なのか”少し考えてみても良いのではないのでしょうか。

  • 技術者が大事にしている事は何なのか
  • 技術者に手を止めさせないために何が必要/不要か
  • 技術者以外のスタッフ間のコミュニケーション効果はどうあるべきか

など。
コードや文法が理解できずともディレクター/プロジェクトマネジメントだから話せる本質の部分もありますし、
エンジニアだからこそ拘っている技術的な美しさ、効率化への理解も重要です。
そのためにお互い少々目を瞑るところはあるかもしれませんが、
その試行錯誤ができるポジションにプロジェクトマネジメントはいるはずなので。

 

メーリングリストを使用する時に気をつけたいコミュニケーション設計の工夫

昨今ではSkype、ChatWork、Slackなど、業務上でチャットを利用したコミュニケーションも当たり前になりつつあります。
が、依然としてML(メーリングリスト)を利用したやりとりが主流という企業も多いことでしょう。

MLが完全悪とまでは言いませんが、そのお手軽感からか工夫や考慮すべき点に蓋をして、そのままになっているケースが多々あるかなと。
中にはMLで上でチャットの様なやりとりをしたり、MLのメールを本文もつけずに、そのまま転送してくる人も見受けられるような。だったら最初からチャットツール使えば良(ゲホゲホ

まぁ、とにかく、どうしてもMLを使いたいという現場の方いることも重々承知な訳で、自分が様々なプロジェクトに携わる中でMLをメインとしたコミュニケーションにおいて気になった点を挙げてみたいと思います。

TOは原則1人にする

よくありがちなのが、TOに何人も関係者のメールアドレスを入れておきつつCCにMLを入れるパターン。
これだとその情報が誰宛なのかパッと見で分かりませんし、受け手側としても「結局、誰に言ってるの?」ということになります。
決裁フロー的にも不明点を誰に聞けば良いのかが不明瞭ですし「誰かが見てるだろう」という意識は結果的に「誰も見てない」事態も招きかねません。
メールでのやりとりをする以上はTOとCCは明確に使い分け、その情報が誰宛のものであるか発信者側で考慮しましょう。

素材共有は事前の整理整頓が肝

また、zipなどの重たい添付ファイルをMLにいる複数人宛てに送付するのも、いささか懸念があります。wifi環境など外で仕事してる方も多いため、セキュリティ上の面からも得策とは言えません。
せめてDropBoxやGoogleDriveなどストレージでディレクトリを整理し、閲覧権限をある程度絞った上で適切な人にだけ適切な形で素材を渡すように心がけましょう。
そのためには日頃からのディレクトリ管理が肝となります。日本語名のzipファイルをルートのフォルダに突っ込んで「あとで整理しよ」とか思ったまま、ほったらかしにしがちの方は、特に注意してください。

起点と経緯と意図の共有

プロジェクトが進行していくうちにタスクが一人歩きをしてしまうことがあります。
「ディレクターからコレやっといてって言われたけど、自分では判断がつかない」という場面ですね。
逆を返せば発注側としては今までの(そのディレクターのみが知ってる)情報で、判断できるだろうという思っているため、こうした齟齬が生まれやすいのだと思います。

これを避ける方法としては、タスクをスタッフに依頼する際にスタッフが判断できる/しやすい情報も付けてあげることを考慮してみてはどうでしょうか。
シンプルなTODOでしたらその限りではないですが、ある程度の工夫や改善をスタッフにお願いした時は、そのタスクの起点、経緯、意図、理由を合わせて依頼をしましょう。
そうすることで受け手側も「これはこうした方が良いかも」と、依頼側の意図に寄せる軸ができます。

クライアントも絡む制作の場合は、あるべき論+クライアント会社内での政治的判断も付加されがちで、それを二次受け的なスタッフに丸投げしておいて、蓋を開けたら「思ってたんと違う」と言われても、スタッフ側からしたら「知らんがな」です。
それを初動で防ぐために、こうした一手間がとても大事になってきます。

この方法のもう一つの利点としては、判断基準を共有して決裁者が分散されることで、個々の判断スピードが上がり、チーム全体での対応力のプラッシュアップが計れるというのがあります。
上の決裁を待つ時間はプロジェクト進行において、ある意味、無駄な時間です。少しでも軽減をするために「このプロジェクト/関連する要素はこうあるべき」というイメージの共有ができるよう、枝のタスクの部分から怠らないようにしましょう。

設計不足は一点集中になるだけ

プロジェクトにおけるコミュニケーション設計の要点は
・受信側の立場を考慮した発信
・チームビルディングを目的とした共有
が大まかなポイントです。

今時のプロジェクト進行は点と点ではなく、点と点をどういった線でつなぐのか、その設計ができるかできないかで、そのプロジェクトの成功率の半分は勝負がつきます。
繰り返しますがMLや電話が絶対悪であるということ言いたい訳ではありません。ただそれらを利用するのなら上記について、発信者側の人達から考慮すべき点だと思うわけです。

善は急がば回れではないですが、ご自身が忙しいと自覚されているディレクターであるなら、なおのこと、こういったコミュニケーション設計をプロジェクト進行前に大切に行うようにしてください。
「でも忙しいから手がつけられない」と言うのであれば、それは「あなたの中で単に優先度が低いだけでしょ?」と個人的には思います。

願わくば、これをご覧のみなさんが、そうでない事を。

 

【捨てる】から始めるプロジェクトマネジメント

Lixo Ingl.indd明けましておめでとうございます。

今年の冬はあまり寒くなく常秋の国に行きたいカネダとしては、大変過ごしやすい限りですが、
年末年始感が皆無のまま気がついたら年明け、仕事始めとなっておりました。
それはそれで考えもののような。

このままダラッといくのアレなので、旧年の自分の動きをおさらいしつつ、今年の自分の動き方について計を案じてみようかと。

ダーツプロになるためにやった2つのこと

2014年2月頃から趣味でダーツを始めたのですが、なぜか始めた当初から「プロになること」を目標に続けており。

続ける上で気をつけていたのは
・日々の気付きをフィードバックしてPDCAにする仕組み作り
・続けることを目的化すること

フィードバックについては、Evernoteにフォームの部位や、どこでいつ何を目的に投げるかを都度で書きとめ、時間があるときや、なんとなく投げに行こうかなと漫然と考えたときに見返すなどして、自分への留意点のフリークエンシーをあげる仕組みをまず作りました。

細かい気付きなどについてはmixiの日記やつぶやきを利用し、こちらもやはり「あとで振り返る」ことを前提としていました。

ログがあることで投げ始めで「前に投げた時に決めたこと、気づいたことってなんだっけ」と振り返れましたし、スタートがそこからになる。また投げた時の新しい気付きがあればそれをログとして残すという具合。

Gitなどのブランチに似た概念かもしれませんが、徐々に留意点が洗練されてきて、ここが担保できれば、その前のこの動きを気にしなくても良いといった風に、意識の集中を制限できるのも大きい効果だったと思います。

で、この度2015年10月にプロソフトダーツ団体のPERFECTのプロ認定試験に合格。

今年は2月からプロツアーに参加することが可能になったので、スポット参加になるかもしれませんが、このまま続けていければと思っています。
あ、ちなみにWebディレクターは辞めてませんのであしからず。

環境に左右されない原則の確認

旧年は常駐案件をメインに2月〜11月で請け負っていました。

正直、環境自体はメールや電話がメイン。
バックログなどのPMツールもない中での仕事でしたので、それなりにストレスもありましたが、個人的にスプレッドシートに課題管理表を作成し、個々のタスクの進捗を管理していたため、大きい混乱もなく先方に高評価をいただけました。

常々、仕事は「誰が、何を、いつまでに、どうする」を抑え、関係者一同が参照しやすい環境をまず設計することが大事と考えています。環境が変わるとツールも変わりますし、関係者の仕事に関するリテラシーも様々です。
しかし、抑えるべき原則は変わらないという部分に確信が持てたのは、個人的に大きい収穫でした。
絵に描いたような代理店案件でしたし、改めてコミュニケーションツールの重要さを知りましたが、久しぶりにウォーターフォールの典型を垣間見ながら、自分がフリーランスになって得た知恵を少なからず活用できた気がします。

あえて「捨てる」という選択肢

さて2016年ですが個人的なテーマとして「洗練/メリハリ」をテーマにしたいと思います。

質を求めるための量の担保。そのための基礎の設計が去年のテーマになっていたと思います。
今年はそこからの洗練。ある種の取捨選択を強いていければと。

人は何かを捨てる時には、自分で自分に言い訳をしたり、なにかしら妥協のうえで捨てるという行動に陥りがちです。
しかしポジティブな理由ゆえの「捨てる」という考え方も本来あって然るべきです。
自身のプライベート、仕事に関わらず、抑えるポイントを精査した後、可能性や求める結果を吟味した上で不要なものや効果が薄いものをあえて捨てる勇気。
そこから空いたリソースを求める方向へ注力する。

おそらくやることは基本的に去年と変わらないでしょう。
今まで通りログを残し、レビューし、改善に繋げる。その改善時のプラン構築の時に意識的に一手間加えるといったところかと。
「努力」や「頑張る」ではなく、楽しんで工夫を続けていく。そのことを改めて胸に刻みたいと思います。

改めて本年もよろしくお願いいたします。