社内や部署単位の報告会議のみならず、会社間の現場担当者同士の打ち合わせ、営業から制作スタッフへの情報伝達、最近ですと複数の職種を跨いだブレストや、プロトタイピングのデザインツールを用いたディスカッション形式など、用途によっても会議の形態は様々な意味を持つようになってきました。その中でも共通して言えるのは”ファシリテーター”の存在意義です。ディレクターないしプロジェクトマネージャーのポジションにある方なら、「○○さん、次の会議のファシリテートよろしく」などと依頼を受け、段取りを任されることもあるでしょう。本来のファシリテーターの定義としては一般に『議事進行やセッティングなどを担当するが、会議中に自分の意見を述べたり自ら意思決定をすることはない』とされています。それらは参加スタッフが会議に対してモチベーション高く参加していることが前提となっており、実際の場においては、スタッフが下を向いたまま淡々と会議が終わってしまい、気がついたら形骸化してしまうというケースも少なくありません。プロジェクト進行において会議は切っても切れないものですが、コミュニケーション設計上、「会議は悪」とする派と「会議は効率的」とする派で意見が分かれるのも頭を悩ますところです。予想される結果の共有ざっくりと上記になります。個々が課題に対しての対処の際、判断に必要な情報を共有し、一堂に会することで作業着手までのタイムロスを防ぐことが目的となります。会議の多くは”会議をすること”が目的化してしまいがちです。上記のような共有は昨今では物理的ば招集がなくてもプロジェクト管理ツールやチャットによるリマインドでも事足りるようになりました。それでも「顔が見える現場」というスローガンの元、椅子の少ない会議室に複数人集まり、結局それぞれが別の仕事をしながら上役のありがたいお話を聞いたフリして終わる会議の多いこと。それが果たして効率的なのかは首を傾げるところです。あ、会議はすべからく悪なのかと言われると一概にそうとも言えません。情報共有についてはツールやコミュニケーション設計から補完できることはあっても、優先度に応じた空気感や、どうしても要約された情報となると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屋のあるべき姿見えてくるかもしれません。→ここ数年にはなりますが、個人的な環境の変化としてフロントエンド系エンジニア、サーバー側の管理者の方など、技術寄りの方々と一緒にお仕事をする機会が増えております。一般的なウォータフォールの制作環境に於いて、”下流”に位置づけされやすいエンジニアのポジション。どことなく軽んじられやすく、上が決めた無理難題をパワーと根性で解決するいわゆる『IT土方』と自虐的な言い回しも聞こえる次第なのですが、プロジェクトマネジメントとして全体を俯瞰で見るうちに、いかにエンジニアの方が苦労されているのか、また、その問題解決の糸口が見えつつあるので、個人的備忘として。エンジニアが技術を振るえる環境作りディレクターないしクライアントからのメールによる作業指示。漠然とした内容が多く「これやっといて」的なニュアンスで投げといて「後で電話/席まで行って説明すればいいや」とお考えの方も多いかとは思いますが、そのメール内容を読み解く時間、作業モードのエンジニアの手を止めてる時間のコストを考慮された事はありますでしょうか。後者の場合、「詳しく説明するからこの時間空けといて」と事前にアポを取り、内容を整理した上でお話されるのならまだしも、エンジニアの席に行くまでのわずか数歩の間に考え、挙句の果てに「あれ何しに来たんだっけ?」と言われも「知らんがな」ってシーン。多く見る機会があります。言わずもがな、ウォータフォールと聞こえは良くても伝言ゲームの言い回し変えただけみたいなところは、正直あるところではあります。伝えるだけでも時間は消費しており、その間の作業時間はロスしていることを考慮し、いかにエンジニアへ端的にかつ整理した内容を伝えるのか。一緒に思案する事項なら何を考えて欲しいのかをオファーする姿勢は持っていたいところです。上記にも軽く挙げましたが、メール/口頭でのやりとりはリスクが大きいもの。できることなら避けるか必要最低限に留めたいところです。最近は、社内チャットやプロジェクト管理ツールの利用も当然のことになりつつあります。それら便利と思われるツールもエンジニアにとっては絶対的な便利さとは言えないようで。注意すべきは通知機能の使いドコロ。してもアテンション/アラートを伝えたく、些細なことでも@をつけてエンジニアに連絡するケースが多く、都度でエンジニアの意識がそちらに削がれるため「あー、またなんか来てるな。いいや」と本当に緊急度の高い通知などはスルーされてしまう可能性があります。チャット=即時会話ではなく、あくまで”ログを残しておけるツール”という意識での運用がエンジニアにとっては好ましいようです。@を入れての通知はプロジェクト管理ツールとの併用を念頭に適材適所に留めたいところ。技術者がプロジェクトマネジメントすることのメリット/デメリット該当の方の社内ないしプロジェクト内での立場や個人的な性格にもよるかとは思いますが、チームリーダー的な役割の方がプロジェクトマネジメントを担うケースがあります。個人的にはツールなどを活用しエンジニアにとって、手を動かしやすい環境が作れれば問題はないのですが、その時に注意したいのは”俯瞰の視点を持てるかどうか”にかかっています。端的に言うとエンジニア=深く、かつより研磨する視点プロジェクトマネジメント=浅く、他者に説明する視点の両面を持つ必要があり、プロジェクトが続く中で思考の切り替えだけでも、それなりの労力がかかります。ことプロジェクトマネジメントに於いては一箇所に留まっての深掘りは他所へのケアに手が回らず、まして自身でコードを書きながらとなると、”自分のコード”、”クライアント対応”、”社内リソース”の3つ+αへ気を配ることになり、効果的とは言い難いです。社内のテクニカルな品質管理の底上げという面では、その限りではないですし、スタッフ間の相対的な技術力の差(正確さ、スピード)を、細部の内容を理解した人が把握できるという面ではメリットは大変大きいです。テクニカルディレクターの必要性と役割については割愛しますが、プロジェクトマネジメントとの住み分けは明確にした上での配置が肝になると言えるでしょう。プロジェクトマネジメントだからできるエンジニアへのバックアップ前述の通り、まだまだエンジニアの作業環境の自由度は低く、制作スケジュール的にもエンジニアマターは五月雨開発は当たり前、「量産、流し込みだから」とか「コード書けばいいから」と、軽く思われるなど、理想的な状況には至ってはいないかもしれません。エンジニア側からも独自文化と一般との隔たりもまだあり、なかなか理解され難い状況も続いています。そんな納品の辻褄合わせの犠牲になりがちなエンジニアの方々にとって”理想的な環境とは何なのか”少し考えてみても良いのではないのでしょうか。技術者が大事にしている事は何なのか技術者に手を止めさせないために何が必要/不要か技術者以外のスタッフ間のコミュニケーション効果はどうあるべきかなど。コードや文法が理解できずともディレクター/プロジェクトマネジメントだから話せる本質の部分もありますし、エンジニアだからこそ拘っている技術的な美しさ、効率化への理解も重要です。そのためにお互い少々目を瞑るところはあるかもしれませんが、その試行錯誤ができるポジションにプロジェクトマネジメントはいるはずなので。