ナニコレ便利！チャットワーク記法を1クリックで挿入するChrome 拡張機能
世界180カ国、57,000社以上*1で導入されているチャットワークは、もはやコミュニケーションのデファクトスタンダード。
そんなチャットワークですが、意外と知られていないのが、独自の記法でコメントをわかりやすく装飾できること。
皆さん使っていますか？
チャットワークで使える5つの記法を一挙紹介！
[info]コメント[/info]
コメントに枠をつけて表示することができます。
特に目立たせたい部分に使うと、とても見やすくなります。
例えばこのようなコメント。
===
来週の全社飲み会についてのご案内です。
みなさん当日はしっかり仕事を切り上げて、 無礼講で飲み明かしましょう！
◆日時：5月15日(金)19時～22:00
◆場所：ホテルニューオータニ鳳凰の間
会費：100円
ご不明な点がありましたら総務部：ヤマダ（内線 #1984）までご連絡ください。
===
そのまま書くと、このように何となく読みにくくなってしまいます。
日時、場所、会費の部分を[info]で括ると、このようにちょっと見やすくなります。
[title]タイトル[/title]
さらに、主に[info]との組み合わせで使えるのが[title]。
先ほどご紹介した[info]の中に入れ子で[title]を記入すると、以下のように枠内のコメントに対するタイトルを表示できます。
かなり読みやすくなりましたね！
[title]は、[info]との組み合わせではなく単体でも使うことができます。
以下のように「i」アイコンが表示されるのですが、これだけではあまり目立たないので私は使ったことがありません(笑)
[code]ソースコード[/code]
これはかなり重宝します。
チャットワークではエモーティコンが利用でき、ちょっとしたコミュニケーションにとても便利です。
しかしエモーティコンは「:*」のようなあらかじめ規定された文字列が自動的に変換されるため、ソースコードを入力する際などに意図せず変換されてしまいとても不便。
そんなときは[code]で括るとエモーティコンに変換せずにそのまま表示してくれます。
例えば、「media.coach4pm.com:*」とそのまま入力すると、このようにキスマークのちょっとキモいアイコンに・・・。
[code]で括れば、意図した通りに表示することができます。
しかもグレーの背景がついてとても見やすくなります。
便利！
[qt]引用文[/qt]
さらに、[qt]で括れば引用アイコンを表示して、引用であることを明確にしてくれます。
チャットワーク内のコメントを引用する場合は[引用]というのが用意されていますが、チャットワーク外の発言等を引用する際に使うと便利です。
[hr]
最後に、線を引くことができる[hr]。
これはあまり利用シーンが思い浮かばず、僕は一度も使ったことはないのですが、このように罫線が引けます。
チャットワーク記法を1クリックで挿入できるChrome 拡張機能を発見！
このようにとても便利なチャットワーク記法なのですが、頻繁に利用したい分、毎回手打ちで入力するのは少し面倒・・・。
と思っていたときに発見した素敵なChrome 拡張機能がこちら。
インストールすると、このようにチャットワークのコメント入力欄に5つのアイコンが追加されます。
このアイコンをクリックすると、なんと[info][title][code][qt][hr]の5つのタグを1クリックで挿入することができるんです。
さらに、コメントを入力して選択反転させた後にクリックすれば、そのコメントがタグでくくられるという便利仕様。
チャットワークユーザーの方は是非使ってみては！
▼プロジェクトを円滑に進めたいプロマネにはこちらの記事もオススメです▼
*1:※2015年1月時点の公式情報
失踪・分裂の危機を防ぐ！プロジェクトメンバーの疲弊に気づくための5つのシグナル
元気なのはあなただけかも。プロジェクトメンバーのこと、見ていますか？
プロマネやディレクターの仕事は、クライアント（または上司）とプロジェクトメンバー、その他の利害関係者の間に入ってプロジェクトをリードすることなので、関わる人が多く時間に余裕がなくなりがちです。
膨大な仕事量に忙殺されてプロジェクトメンバーの心身状態に気を配れないまま、ある日から突然メンバーが休みがちになりピンチに陥ったという苦い経験を持つプロマネも少なくないのでは？
僕が過去に疲弊させてしまったメンバーを思い返すと、5つのシグナルを事前に出していました。
プロジェクトメンバーが疲弊して窮地に追いやられる前にフォローできるよう、今ではその5つのシグナルに常に気を配るようにしています 。
シグナルその１ 目が笑っていない
新プロジェクトで招集したメンバーたち。
キックオフミーティングではプロマネのオヤジギャグに爆笑が起こるなど、楽しく会話をしていたのに、プロジェクトの途中から冗談を言っても笑わなくなったメンバーが増えてきた経験はありませんか？
露骨に笑わなくなった場合はわかりやすいですが、目線がちょっと鋭くなったり、口元は笑っているのに目が笑っていなかったりすることが増えるのが最初の兆候。
これは、心に余裕をなくし始めている証拠です。
シグナルその2 ネガティブワードが減る
要件定義に時間を割いたのに、次々と仕様変更が発生すること、ありますよね。
プロマネもクライアントとうまく調整できず、変更を受け入れる日々。
この時、メンバーの心の中にはこんな声が生まれています。
「これまでつくってきたものは何だったの？」
「目的がわからないんですけど」
「バカなクライアントだ」
そうして、進捗ミーティングではプロマネへの不満が噴出！最初は渋い顔をして仕様変更を受け入れていたメンバーも、心の中の声を実際に口にするようになります。
でもここまでならまだ大丈夫。
むしろ、メンバーが不満をプロマネに言える関係性を築けているということは素晴らしいことです。
気を付けたいのは、そういった不満の声が減ったとき。不満の声は現状を改善してほしいという想いの現れですが、諦めモードに入った人は不満を言わなくなります。
シグナルその3 出社・退社時刻が微妙に変わる
過去に僕が担当したプロジェクトでも、終盤になって休みがちになる人が出てしまったものがいくつかあります。
遅刻ならまだしも、リリース直前に突然欠勤などということになると大変！
周りのメンバーの仕事量を増やすことになり、プロジェクトの雰囲気が悪くなってしまいます。
そうなってしまう前兆として、多くの場合は出社時刻が微妙に変わります。
今までは定時15分前に来ていた人が定時5分前に来るようになるなど、微妙な出社時刻の変化には要注意。
寝る前に翌日の準備をしていた人がそれをせずに寝てしまうようになっていたり、スパッと起きられていた人が憂鬱な気持ちでしばらくベッドから出られなくなっていたりするのかもしれません。
この状態が続くと、いずれ遅刻や欠勤というプロジェクトに悪影響を与える結果になります。
シグナルその4 仕事以外のことに前向きになってきた
プロジェクトの仕事は淡々とこなしているけど、こんな行動をとるようになった人がいたら要注意です。
- 社外人脈を増やすため各種交流会に頻繁に参加するようになった。
- 業界や競合についてやたら詳しくなっている。
- 新しく勉強を始めた。
これは、モチベーションが高まっている人にもあり得るのですが、疲弊してプロジェクトへの興味が薄れていたり、転職を考え始めた人にも表れる傾向です。
シグナルその5 SNSで意味深な発言が増える
TwitterやFacebookで、他のメンバーやクライアントへの批判や愚痴ともとれる内容を投稿しているメンバーはいませんか？
考えを発散する場所がなく、相談する人もいない、追いつめられて帰宅途中の電車の中で書き込んだメンバーを想像してみてください。
かなり思い詰めている状況ですよね。
それで小さなストレスを発散できているのなら良いですが、長く続く場合は注意が必要です。
また、SNS上での対象がぼやかされた批判や愚痴は、他のメンバーが「自分のことかも？」と疑心暗鬼になったり「直接言えばいいのに」といら立ってしまったりすることもあります。
こういったタイプのメンバーはいわゆるコミュ障であることが多く、直接的に意見を表に出すことが極めて苦手です。
しかし、現状を変えたいという想いは強いため、直接口に出さずに「気づいてくれたらいいな」「変わったらいいな」というある種の正義感で投稿していることが多く、周りへの影響が見えていないことがあります。
他のメンバーの反感が増えないうちに、業務命令としてそのような投稿をやめてもらうという判断もときには必要です。
疲弊シグナルが見えたら、とにかくコミュニケーションの頻度を増やそう
これらのシグナルが見えたら、とにかくコミュニケーションの頻度を増やすことが効果的です。
コミュニケーションが大切なのは言わずもがなですが、「質＜量＜頻度」が重要というのがコミュニケーションで意識したいポイントです。ちょっとした挨拶や雑談で構わないので、毎日何かしらのコミュニケーションをとるようにしましょう。
コミュニケーションの頻度が増えると、メンバーから相談できるきっかけが増えます。
話そうとしないメンバーに無理に話してもらおうとしても本音は出てきません。
とにかくメンバーが自発的に相談を持ちかけてくれる状況を作るようにしましょう。
コミュニケーションは直接的な会話だけとは限りません。
特に技術系のメンバーの中には、会話が苦手な人もいるはず。
そんな場合に無理に会話によるコミュニケーションをとろうとするのは逆効果です。
チャットやメールはもちろん、目があったときに笑顔を返す、メンバーのSNSに「いいね！」などのサインを送るなども立派なコミュニケーションです。
その他にも、感謝を伝える、褒める、ランチに誘う、など積極的に声をかけましょう。
仕事もプライベートもすべてを受け入れよう
メンバーの疲弊の原因は、もしかしたら仕事ではなくプライベートが原因かもしれません。
ですから、仕事に不満があると決めつけてフォローするのは要注意。
仕事の話ばかりされると、プライベートの相談がさらにしにくくなり、平行線をたどって反感を買うことも。
家庭の事情は表面に出ないことが多いですが、プライベートが仕事に及ぼす影響が大きいのは感じる人が多いはず。
彼女に振られた、昨日も旦那とケンカした、子供が高熱を出していて心配、など人によって悩みはさまざま。悩んでいるメンバーが、朝から明るく前向きに仕事でパワーを発揮できるでしょうか。
幸福な働き方の促進を支援するウィズダム・ラボのリッチ・フェルナンデスが記事でこんなことを書いています。
ストレスは人から人へ伝染するが、その逆もまた真である。つまり、チームメンバーの誰かが心身の健康（well-being）を感じていると、その効果はチーム全体に波及するようだ。
チーム（そしてあなた自身）が職場やデジタル上で仕事に従事すべき時間帯を、慎重に考えよう。そして、仕事から離れるべき時間についても同様に意識を高め、はっきりと伝えなくてはならない。
出典 ：部下のストレスと燃え尽きを防ぎ、仕事の生産性を上げる方法｜ハーバード・ビジネス・レビュー
「仕事にプライベートを持ち込むな」という考え方はもはや過去のもの。
仕事は仕事というドライな人間関係は短期的に見ると結果が残せてよいのですが、長期的に見た時、メンバーの疲弊は蓄積され、退職しか考えられない思考に陥るリスクが高まります。
メンバーに幸福感を持ちながら仕事に取り組めるようにすれば、退職せず長期間安定して働き続けてくれるようになります。
そうなれば、各メンバーの熟練度も高まり、チーム全体のコミュニケーションもしやすくなって、組織全体の生産性がどんどん向上していくでしょう。
おわりに
人材不足の中で優秀なスタッフを確保するのがますます難しい時代になってきました。
プロジェクトメンバーの疲弊シグナルを早くキャッチして、長く働きたいチームを創ることもプロマネの重要な役割です。
▼仕事が多くて困るというディレクターの方に、こちらの記事もおすすめです▼
「大工の棟梁に学ぶプロジェクトマネジメント」感想／チームビルディングに悩んでいるプロジェクトマネージャーにオススメの一冊
コミュニケーションが希薄、目標に対するコミットメントが低いなど、チームビルディングに課題を感じているプロジェクトマネージャーも多いはず。
そんなときに読んでほしいのが「大工の棟梁に学ぶプロジェクトマネジメント」。
リーダーとしての考え方、メンバーとの接し方についてたくさんの気づきが得られました。
タイトルはプロジェクトマネジメントですが、どちらかと言うとリーダー論に近い内容です。
僕はもう10年ほどweb業界に浸かってますが、この業界にいるとよく「IT業界は、、、」とか「web業界は、、、」という表現をよく見聞きしたり自分でも言ったりしてしまいます。
しかし、ビジネスの根本的なところは業種業態によって変わるものではないんですよね。
僕らはもっと、異業種の歴史に学ぶべきことがある。
特に共感したポイントを2つだけご紹介します。
チーム作りに嵐はつきもの
そんなもん、これが答えっていうのはないよ。毎回、状況が違うんだから。ただな、どんな現場も途中で一回は荒れるってことを知っていれば慌てずに済むだろ。それでいいわけよ。 現場がもめたり荒れたりし出したら、「しめた！」ってもんよ。そうやって、それぞれが言いたいことを言い合った後ってのは、スッキリ納まるもんなんだよ
あるある、馴染めないメンバーがいたり、変な派閥が生まれてしまったり。
プロジェクトマネージャーがそれを負の課題と捉えるのか、正のスパイラルを作るためのチャンスと捉えるのかで、その後の現場の雰囲気は180度変わります。
穏やかに済ませようとトラブルに向き合わないマネージャーであれば、溝は日に日に深まってしまうでしょう。
一方、一度は荒れるものと心得たマネージャーは、むしろそれを利用してチームワークを強固にしてしまうものです。
敵は絶対に作らない
んなもん、すぐ謝っちゃうよぉ。絶対に戦っちゃダメなんだなぁ。どんな場合も周りから恨みを買わないようにするのが一番大事。家を建てている間だけじゃないでしょ、人間関係は。
建築現場のご近所にモンスタークレーマーさんがいたらものすごく工事が大変そうです。
そういった人たちとも上手に付き合っていくこともリーダーの役割なのですね。
関係を悪くしてしまったら、今後長い間その家に住むお客様の生活に関わるのでかなりセンシティブなんだろうなぁ。
開発プロジェクトでも、無理を通せば道理が引っ込むと信じているのではというような無茶な関係者がいるケースがあります。
そんなときには攻撃的になるよりも、意地やプライドを捨ててひたすら下手に出てみることも有効なのかもしれません。
この点については、僕も大きく反省をしたプロジェクトがあります。
相手が無茶を言うものだから、こちらはそれを跳ね返そうと防御的になり関係性が悪化。
こちらが防御的になるのに比例して、相手はどんどん攻撃的になっていきました。
こちらは相手の追加要求は一切受け付けないスタンス、相手は何としても自分たちの要求を押し通そうとするとスタンスで、そんなプロジェクトがうまくいくはずがありません。
結局そのプロジェクトは途中で契約解除となり、サービスがリリースされることはありませんでした。
もちろん線引きは重要なので相手の無茶を受け入れるというわけではないのですが、あのときもう少し柔和の態度でコミュニケーションをとっていれば、結末は変わっていただろうと思います。
関係性が重要ということについては、こちらの記事にも通じるところかもしれません。
プロマネはメンバーに好かれないとプロジェクトがうまくいかないという大前提
平易な文章でサクサク読めますので、気分転換にもお勧めです。
▼こちらの記事もオススメです▼
PMBOKをいくら学んでもそのまま実務には使えない！PMBOKを現場に活かす2つのポイント
プロジェクトマネージャーの成長を爆速にするcoach4pmのコーチングとは
やばい！間に合わない！工数見積を見誤ったときのリカバリ方法3選
まぁ、ありますよね、、、。
「あ、やばいっ！」てこと。
同じようなことをいつもやっている定常的な業務であれば工数見積もりは正確にできますが、新規性・不確実性を伴うプロジェクトの工数は「見積もり」というよりも「予測」的な要素が強まります。
そんな状況であっても、可能な限り初期の計画通りに物事を進めるのがプロマネが背負う使命。
工数見積もりを見誤ってしまった際には、どうやってリカバリーすればよいのでしょうか？
リカバリーの方法は3つしかない
完了期日と開発スコープを変更せずにプロジェクトを進めるためには、以下の3つの方法しかありません。
- クラッシング
- ファストトラッキング
- バッファを使う
気合いだけでは生産性は（少しだけしか）上がりませんので、間違っても精神論で乗り切ろうとしてはダメ。
精神論で戦っても自分もメンバーも疲弊するだけなので、この3つの方法論を上手に使ってプロジェクトの軌道修正をしましょう。
１．リソースを追加投入して解決する「クラッシング」
ひとつめの方法は、クラッシングです。
クラッシングとは、リソースを追加投入してスケジュールを短縮することを意味します。
最も確実なリソース追加方法は、担当メンバーへの残業や休日出勤の依頼です。
一時的な残業で済むようであれば、プロジェクトの内容を把握している既存メンバーが対応すれば速やかにリカバリーできるはずです。
なお、仮に工数を見積もったのが残業した本人であっても、計画を見誤ったのはPMの責任です。
残業への感謝の気持ちは忘れずに。
尊敬すべき僕の先輩は「とりあえず女子にはチョコさえ与えとけば大丈夫や」なんて言っていました。敬意をもって意訳すると、「大事なのは感謝の気持ちだけど、気持ちだけでは伝わらないから時には身銭切ってモノで示めしたほうがいいよ」ということでしょう。
冗談はさておき、一時的な残業で済めばよいのですが、計画と実績の乖離が大きく、それでは済まない場合もあります。
恒常的な残業はメンバーのモチベーション低下や肉体的疲労につながり、生産性を落としてしまうため避けなければなりません。
そんな場合に考えるべきはリソースの再配置です。
クリティカルパス上にないタスクに割り当てられているリソースのうち、再配置可能なリソースがないか探してみましょう。
うまく再配置できれば、プロジェクト全体のスケジュールを変更することなくリカバーすることが可能です。
それでもだめなら、新メンバーの追加を考えることになります。
但し、新規メンバーを追加する際はブルックスの法則を念頭に置く必要があります。
Adding manpower to a late software project makes it later. （遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけだ）
名著「人月の神話」の中で書かれたもので、ソフトウェア開発に関わる方であればご存じの方が多いのではないでしょうか。
ブルックスの法則は、新メンバーがプロジェクトに貢献するまでには一定の時間がかかること、人数が増えれば増えるほどコミュニケーションコストが上昇することを根拠としています。
ですから、新メンバーを追加する際は、この2点を克服できるかどうかを予め検討する必要があります。
プロジェクト初期段階であれば比較的克服しやすいものですが、プロジェクト後半に差し掛かっている場合は、(単純な人件費以外の)コストと効果をしっかりと天秤にかけて考えるようにしましょう。
２．ファストトラッキングは、やむを得ない見切り発車
クラッシングで対応できない場合は、ファストトラッキングと呼ばれる方法を検討します。
これは、本来前工程が完了してから着手すべき作業を、前工程完了前に着手して全体のスケジュールを縮めることを言います。
例えば、デザインがFIXする前にコーディングに着手することがファストトラッキングにあたります。
要は、見切り発車です。
うまくいけば大幅にスケジュールを短縮できる可能性がある一方で、前工程の状況によっては大幅な手戻りを発生させてしまうリスクもつきまとう方法です。
従って、ファストトラッキングは手戻りのリスクを受容できる場合にのみ適用すべきです。
３－１．バッファを使う前に、覚悟を決めて依頼者とスコープやスケジュールの調整を
クラッシングとファストトラッキングを適用してもリカバリーできないことがわかったら、悩んでいても仕方ありません。
依頼者とスコープやスケジュールの調整をしましょう。
そりゃー怒られますよ、でもしょうがないんです、それがプロマネの仕事です。
３－２．最後の最後は、バッファを食いつぶして微調整
そして、最後の最後の手段がバッファを食いつぶすことです。
重要なのでもう1回言います。
最後の最後の手段がバッファを食いつぶすことです。
炎上に突入する典型的なケースが、最初にバッファを食いつぶしてしまうことです。
バッファは、最後の最後まで残しておかなければいけないんです。
本当に万策尽きたときにしか、バッファを使ってはいけないんです。
バッファを食いつぶす前に、必ずスケジュールやスコープの調整にチャレンジしましょう。
怒られても、恨まれても、バッファは最後まで死守することが、最終的にプロジェクトを幸せに完了させるポイントです。
プロジェクトは最後の最後まで何があるかわかりませんからね。
僕がPMを担当するプロジェクトではバッファは最後まで使わずに、メンバーへの感謝の気持ちに休暇にするつもりでやっています。
（それでも、実際に休暇にできるプロジェクトは全体の半分くらいですが・・・涙）
リカバリーは、「率」ではなく「量」をコントロールする
これら3つの方法は、いずれも「率」ではなく「量」をコントロールしていることがポイントです。
クラッシングは、単純にリソースの量を増やします。
ファストトラッキングも、剰余リソースを稼働できる工数に変化させることでリソースの量を増やしています。
バッファを使うことは、作業日の量を増やします。
もちろん、メンバーを鼓舞したり、チケットを整理して残作業を見える化したりすることで効率を上げるなどもやらなければいけませんが、率を上げるには限界があります。
どうにかして量をコントロールしようとすることが、確実にプロジェクトをリカバリーするための考え方です。
▼こちらの記事もオススメです▼
コミュ障は治る！コミュ障プロマネのためのアサーティブ・コミュニケーションって？
高圧的な上司、無茶を言うクライアント、適当な同僚、言い訳を繰り返す部下、そんな人たちとのコミュニケーションに課題を感じていませんか？
そういった人たちとのコミュニケーションが苦手な人は、よくこんなことを言います。
「私、コミュ障だから・・・」
断言します、コミュ障は治ります。
聴覚器官や発声器官に障害をもっていたり、精神障害や発達障害だったりする方には僕は適切な克服法を（治療法？）を知りませんが、そうでない限りコミュ障はトレーニングで治ります。
なぜなら、コミュニケーションはスキルだからです。
スキルである限り、先天的にセンスをもっていなくても、後天的に身に付けられるということです。
自分の意見を率直に伝えるための「アサーティブ・トレーニング」とは？
自分も相手も尊重しながら、意見を率直に伝えて物事を前進させるためのコミュニケーションの方法論として、「アサーティブネス」という考え方があります。
アサーティブネスを身に付けるためのトレーニングが、アサーティブ・トレーニングです。
アサーティブネスを身に付けることで、相手の立場や態度に関わらず、自分の意見を表現できるようになります。
自己主張は怖いかもしれないけど、悪いことではない
アサーティブ・トレーニングの第一歩は、NOと言ったり、反対意見を言ったりするのは、自分にとっても相手にとってもよいことなのだと理解することです。
自分の意見を主張するということは、その意見を否定されたり、それによって嫌われたりする可能性があるように思えます。
しかし、そういったことが起きるのは、自己主張に対する反対意見を恐れて、必要以上に攻撃的な言い方をしてしまい、相手の気分を害してしまうのが原因です。
まず自己主張は良いことなのだと頭で理解してみましょう。
そうすることで、相手の立場も考えながら冷静に自己主張ができるようになります。
アサーティブネスの起源ともいえるアン・ディクソン氏が著書の中で、「自己主張の権利」を唱えていますので見てみましょう。（ちょっと意訳）
優先順位は、自分で自分のために決めていい
I have the right to state my own needs and set my own priorities as a person independent of any role that I may assume in my life.
相手がだれであっても、対等な人間として、敬意をもってあつかわれるべきだ
I have the right to be treated with respect as an intelligent, capable and equal human being.
自分の感情は素直に表現していい
I have the right to express my feelings.
自分の意見と価値観も素直に表現していい
I have the right to express my opinions and values.
｢ノー｣を言うのに罪悪感を抱く必要はない
I have the right to say yes or no for myself.
間違えたり失敗したりしてもいい
I have the right to make mistakes.
間違えたり、より良い考えを思いついたりしたら、言ったことを変えてもいい
I have the right to change my mind.
すべてを理解しなくてもいい
I have the right to say I don’t understand.
欲しいものは欲しいと言っていい
I have the right to ask for what I want.
人の責任まですべて負う必要はない
I have the right to decline responsibility for other people’s problems.
誰とどう接するかは、誰かの評価を気にせず自分で決めていい
I have the right to deal with others without being dependent on them for approval.
いかがでしょうか？ 自己主張をすることに、少し前向きになってきましたか？
事実、感情、要求を分ける
自己主張は良いことだと頭で理解できたら、次は具体的なテクニックを習得しましょう。
アサーティブなコミュニケーションを行うポイントは、事実、感情、要求の3つを客観的に認識して、それぞれを別なものとして相手に伝えることです。
- 事実：いまどんな状況なのか
- 感情：自分はどう感じているのか
- 要求：相手は何を求めているのか、自分は何を求めているのか、双方にとって最も望ましい結果は何なのか
アサーティブなコミュニケーションができないのは、この3つのいずれかを自分でもよくわかっていなかったり、あるいは混同して認識してしまっていたりすることが原因です。
＜ケーススタディ＞
「OK！」と言われて進めてきた仕様なのに、テスト工程になって「それじゃだめだから、こういう風に直してください」という仕様変更が入った
- 事実：現状の仕様には問題がある
- 感情：OKと言ったものを土壇場で覆そうとすることにいら立っている／メンバーに残業はさせたくない。
- 相手の要求：仕様を変更してほしい
- 自分の要求：変更するなら、スケジュールと費用の調整がしたい／手戻りはメンバーのモチベーションを下げるのでなくしたい
事実・感情・要求を分解できていない場合のコミュニケーション例
OKと言ったじゃないですか！
今さら変更は無理ですよ！
（苛立ちの感情が先行して攻撃的になり、要求を冷静に伝えられていない）
事実・感情・要求を分解できている場合のコミュニケーション例
（事実）この仕様だと問題があるのですね。先日確認させていただいた際にOKとのことでしたので、すでにその仕様で実装が進んでしまっています。
（感情）この段階での修正は困難で、困ってしまいましたね。
（要求1）この仕様では問題があることはわかりましたが、変更するには費用とスケジュールの調整が必要ですので、ご調整いただくことは可能でしょうか？
（要求2）お互いにデメリットが大きいので、なるべく手戻りが起こらないように今後の開発プロセスを見直したいですね。
理解してくれない相手に対するブロークン・レコードという方法
冷静に自分の意見を伝えても、相手がすぐに理解してくれるとは限りません。
そんなときに、再び自分が攻撃的になってしまい、「だから無理だと言っているじゃないですか！」と言ってしまえばせっかくのアサーティブ・コミュニケーションがフリダシに戻ってしまいます。
そんなときに知っておきたいのがブロークン・レコードと呼ばれる方法で、壊れたレコードのように同じメッセージを伝え続けることを言います。
この方法を知っていれば、いら立って攻撃的になってしまったり、妥協して安請け合いしてしまったりしまったりすることもなくせます。
前述のケースで、アサーティブにコミュニケーションをとっても、相手が「費用もスケジュールもどうにもならないんです、でもこの仕様ではダメなんです」と返してくることも容易に想定されます。
でも大丈夫、あなたはすでに事実、感情、要求を客観的に理解しています。
いら立ちの感情は切り離して、もう一度壊れたレコードのように同じ言葉を繰り返しましょう。
「しかし、変更するには費用とスケジュールの調整が必要なのですが、どうにかならないでしょうか？」
ロールプレイングで、アサーティブネスを手に入れよう
このようなアサーティブなコミュニケーションは、アサーティブネスに関する知識を学んだからといってできるようになるものではありません。
長年かけて身に付けた言い方や態度を変えるのはとても難しいので、普段からのトレーニングが必要です。
トレーニングとして最適なのがロールプレイングです。
会社の同僚などと一緒に、色々なシーンを想定して依頼者と作業者になりきって、実際にコミュニケーションをとってみましょう。
その場で臨機応変に事実、感情、要求を切り離して考えるのは困難ですが、あらかじめ色々なシーンを想定しておくことで、いざその場面がきたときに焦らず対応ができるようになるはずです。
また、自己表現のバリエーションも増やせるので、より伝わりやすい表現でコミュニケーションをとれるようになることも期待できます。
さらにロールプレイングでは、ロールによって相手の立場を疑似体験することができるのもポイントです。
アサーティブコミュニケーションは、自分を尊重すると同時に、相手も尊重しなければうまくいきません。
相手のロールでコミュニケーションをとってみることで、これまで以上に相手の視点で物事を捉えられるようになります。
「相手の立場」に関して、この記事もとても参考になりました。
相手の気持ちが分からない人は 「自分が相手の立場ならどう思うだろうか？」 と考えます。 しかし、本来は 「相手が相手の立場ならどう思うだろうか？」 と考えるべきです。 相手の気持ちが分からない人は常に主語が『自分』なのです。
一緒にロープレしませんか？
coach4pmでは、不定期にプロマネ/ディレクター仲間で集まってロープレを行っています。
場所は都内主要駅（渋谷、新宿、池袋等）で行うことが多いです。
私もロープレしてみたい！という方がいましたら、開催する際にご連絡させていただきます。
場所の実費のみ割り勘させていただきますが、それ以外に費用はかかりませんのでご興味のある方がいましたら是非お気軽にご連絡ください^^
coach4pm@riso-labo.com(担当：千歳)
▼こちらの記事もオススメです▼
【4つの原因別】上司の言うことが二転三転して手戻りが多い！モチベーション下がるわ！というディレクター向け方法論
プロジェクトに関する質問に答えてみるシリーズの第2回。
▼第1回の内容はこちら▼
ディレクション誰やるの？ディレクション責任が不明確なプロジェクトが200%炎上する理由と対策
さて2回目の今回は、某人材系ポータルサイトで、社内開発チームのディレクターをしているHさんからの質問です。
言うことがコロコロ変わる上司に悩まされています。既に制作は進んでいるのに根本のコンセプトが変更になったり、一度OKが出たのに次の日には「やっぱりこうしてくれない？」と言われたりして、手戻りが多くすごくモチベーションが下がります。どうしたら手戻りをなくせるのでしょうか？
手戻りがモチベーションを下げることは行動経済学で証明されている
依頼者である上司やクライアントの指示が朝令暮改、頭の痛い悩みです。
社内プロジェクトでも受託プロジェクトでもよくある問題ですが、受発注契約で線引きされておらず、部下側の拒否権が弱い分、社内プロジェクトで大きくなりやすい問題です。
受託プロジェクトの場合は「中にはそういうクライアントもいるよねー」というワンオブゼムの話ですが、社内プロジェクトの場合は直属の上司からは逃げられませんのでストレスレベルは日に日に高くなっていくはずです。
手戻りがモチベーションを下げることは行動経済学でも証明されています。
デューク大学で心理学や行動経済学を研究しているダン・アリエリー教授の「シジフォス実験」と呼ばれる実験が有名です。
レゴブロックを組み立てるという簡単な作業をAB2つのグループにやってもらいます。
Aグループは出来上がったものを目の前に並べていき、Bグループは出来上がったものをバラしてまた同じものを組み立てるという実験をしたところ、作業そのものはまったく同じなのにもかかわらず、圧倒的にAグループのモチベーションが高く維持されるという結果が出ました。
非常に抽象化された実験内容のため、この実験結果は当然のことのように思えますが、プロジェクトの手戻りによるモチベーション低下は、これと同じ現象が起こっていると言えます。
詳しくは以下の動画をご覧ください。
シジフォス実験以外にも、200人のエンジニアのモチベーションを一瞬でなくさせたある企業の話など、示唆に富む話がたくさんあります。
TED TALK：仕事のやりがいとは何か
手戻りが発生する4つの代表的な原因
ここで問題の本質に目を向けてみると、実は「手戻り」そのものではなく「モチベーションの低下」が問題であることがわかります。
ですから、手戻りをなくす方法と、手戻りが発生した場合にモチベーションを低下させない方法という2つの観点を念頭に置いて話を進めます。
手戻りが発生してしまう代表的な原因は以下の4つです。
手戻りの原因
- 前提となる状況の変化
- 上司が手戻りの害をあまり理解していない
- 上司が作業プロセスを理解していない
- 新たなステークホルダーの出現
それでは、1つずつ対策を見てみましょう。
１．前提条件の変化は防げない
いきなり諦めモードかよと言われてしまいそうですが、これはプロジェクトチームでコントロールできるものではないため、残念ながら防ぐことはできません。
環境変化が激しいビジネスシーンでは、すぐに前提が変わってしまうことも少なくありません。
そんなときは迅速に判断を改めてやり直さなければ時代遅れになってしまいますから、手戻りを恐れずに判断の変更をすべきです。
ですからこの場合は、手戻りを防ごうとするのではなく、手戻りが発生してもモチベーションが下がらないようにすることを考えましょう。
そのために必要なのは、「あらかじめ手戻りを想定しておく」ということです。
当たり前にも聞こえますが、手戻りが発生してからそれに対する対応を考えるのではなく、あらかじめ手戻りを「発生し得るリスク」として認識し、発生した場合の対応についてメンバーと共有しておくことが非常に効果的です。
「きっとうまく行くだろう、あとちょっとでリリースだ・・・・・と思ってたら手戻ったーーーー！！！！」というのはモチベーションがダダ下がります。
しかし、 「このタイミングで手戻りが発生するかもしれないから、そういう場合にあわてないように心の準備をしておこう」というだけで、実際にそれが発生した場合のモチベーション低下をかなり軽減できます。
また、心の準備だけでなく、あらかじめ手戻りが発生した際にそなえるスケジュールバッファ、コストバッファを用意しておけばもう怖いものはありません。
２．上司に手戻りがプロジェクトに与える影響を理解してもらうには
上司は「ここやっぱりこうしておいてー」と気軽に言うけれど、「やってるほうの身にもなってみろゴルァァァァァ（言えないけどorz）」というやつです。
このタイプの上司は、忙しいことを理由に確認が雑だったり、返事が話半分で言ったことを忘れてしまったり、あるいは検討もそこそこに見切り発車をしてしまったりということが頻繁に発生します。
その対策は・・・、この記事を共有して読んでもらうことです（笑）
そして手戻りがあるたびに、「また手戻りですよーーーモチベーション下がるんですって！」とにこやかに言い続けていくしかありません。
３．上司が他分野の出身である場合、細かいWBSで進捗の差異をこまめに報告しよう
マーケティング系や営業系で成果を上げてきた人が、制作・開発プロジェクトの責任者に配置されるケースがあります。
この場合、上司が制作・開発プロセスをよくわかっていないために悪気なく手戻りを発生させてしまうケースがあります。
「あ、ごめん、それってもっと前に決めなきゃいけなかった？ちゃんと検討してなかったわ＞＜」 というやつです。
上司は他の分野のプロフェッショナルですから、「デキない上司だ・・・最悪や・・・」と嘆いていても仕方ありません。
上司をマーケティングや営業の観点を現場に取り入れてくれる貴重なビジネスパートナーという視点で見て、制作・開発に関してはあなたがリーダーのつもりで上司をリードしてあげる必要があります。
このケースでは、かなり粒度の細かいWBSを作成し、進捗の差異を頻繁に報告するのがお勧めです。
手戻りが発生するとその差異が一気に広がるため、上司も「良くない判断をしてしまったのだな」と反省できる材料になり、次第にプロセスを理解して手戻りが減ってきます。
４．ステークホルダー登録簿を作成して、早期に関係者を洗い出す
当初は想定していなかった新たな関係者が出てきて、その人の影響によって方針が変わり手戻ってしまうこともあります。
「上司！そこ制御してよ！」と言いたくなる気持ちもわかりますが、なかなかそうも言えないのが実情です。
これは、プロジェクトの初期段階でステークホルダーの洗い出しができていないことが原因です。
ステークホルダーは増えれば増えるほど調整が増えて面倒なので、なるべくこじんまりとプロジェクトを進めようとしてしまいがちですが、そうやって進めた結果あとからひっくり返されるという経験が皆さんにも一度はあるのではないでしょうか。
例えば、あとから営業部門がまったく別のことを言い出したり、広報部門がレギュレーションについてNGを出してきたり、法務部門が各種表現についてチェックさせてくれと言ってきたり、、、。
そういった状況にならないようにするためには、あらかじめ「ステークホルダー登録簿」を作成するのがお勧めです。
ステークホルダー登録簿のサンプルフォーマットを以下に用意しましたのでよろしければご利用ください。
※今後のさらに役に立つ情報提供のために、簡単なアンケートにご協力いただけますと幸いです。なお以前アンケートにお答えいただいた方は、直接メールいただければお送りします
このファイルを参考に、プロジェクトに影響しそうな人を最初に洗い出してみてください。 ポイントは、以下の３つです。
- ステークホルダーは「個人名」でリストアップ
- 各ステークホルダーがどういった役割の人なのかを確認
- 発言力や影響度を検討
発言力や影響度の高い人には、直接あるいは上司を通して初期段階からコミュニケーションをとっていくことで、後からひっくり返るリスクはかなり軽減できます。
コミュニケーションは、必ずしもオフィシャルなものでなくても構いません。
非公式な飲み会や趣味の付き合いなども含めて関係性を築いておくことが重要です。
こちらの記事も是非参考にしてみてください。
プロジェクトの改善に魔法の杖はない
手戻りを軽減するヒントは得られたでしょうか？
どの対策も、関係者とコミュニケーションをとりながらプロジェクトの進め方を改善していく必要があるため、一朝一夕にはいかずモヤモヤすることもあるかもしれません。
しかしプロジェクトの改善に即効性のある魔法の杖はありません。
すぐにうまくいかなくても何度も言い続ける、少しずつ取り入れて風土を作っていくような心構えで取り組んでいきましょう！
炎上プロジェクトは害悪なのか？受託Web業界で10年以上戦ってきた4人によるぶっちゃけ本音トーク座談会
先日公開したこの記事がだいぶバズりまして盛大な反響がありました。
ディレクション誰やるの？ディレクション責任が不明確なプロジェクトが200%炎上する理由と対策
共感の声を多数いただき、みなさん炎上案件を経験していて、解決策を探しているんだと改めて感じました。
これはもっと語り合うしかない！と思い、主に受託系のWeb業界で活躍する仲間に声をかけ、「炎上プロジェクトをなくせ！」というテーマで座談会を開催しました。
一部、実際の会社名、案件名を伏せるなど編集を加えていますが、ほぼそのまま公開します。
座談会は、各自が自宅でビールを飲みながら、チャットワークで語り合うといういかにもWeb業界らしい形式で行いました。
めちゃ楽しかった！
目次
- まずは参加者プロフィール
- では、自己紹介から始めていきましょう。
- 突然の納期圧縮、Webを知らないデザイナー…みんなの炎上体験
- 炎上の火種は結局ディレクターの自爆？！
- クライアント社内のコンセンサスが取れていない問題
- 独立・創業したては臭う案件でも前のめりに受けてしまいがち問題
- 納期と費用に余裕があっても炎上は起こるもの？
- 炎上は絶対に避けるべき害悪なのか、あるいは成長のきっかけか
- まとめ
まずは参加者プロフィール
No1. きんぴら系プロデューサー！！！！
甘いけど辛い、辛いけど甘い・・・人に優しく、仕事に厳しいプロフェッショナル、ちょっと真面目すぎるのが欠点・・・ジャパニーズソウルを受け継いだきんぴら系プロデューサー。年商数億円のWeb系開発会社を経営。
No2. 要件おもらし幼女系ディレクター！！！
開発会社、ウェブサービス運営会社を経て現在はフリーのディレクターとして活躍。幼女のころはよくおもらししてたらしい。（TωT）ｼﾞｮﾎﾞｼﾞｮﾎﾞー 今はきっとだいじょう・・・ぶ。
No.3 胸熱系デザイナー！！！
元ボクサー。胸板が厚い。 デザイナーとして若くしてフリーランスの道を歩み始め、現在10年目。
No.3 ブラック系フロントエンジニア！！！
見た目はブラック、心はホワイト。 少数精鋭のエンジニア会社を経営。自身もバリバリコードを書くフロントエンジニア。
No.4 酔拳系プロマネ！！！
そしてファシリテーターは私、coach4pm中の人、アルコールを摂取すると偏差値が20上がる酔拳系プロマネの千歳です。
では、自己紹介から始めていきましょう。
着席！
着席！
着席！
ブラックさん来ないけど、時間なので始めましょうか。それでは本日はどうぞよろしくお願いします。 今日は「炎上をなくせ！」というテーマでざっくばらんに語り合いたいです。 「炎上」というと人によってイメージが違うかもしれませんが、ここではかなり広く捉えて、「精神的に通常のプロジェクトより疲れて、みんなが嫌な思いをしたプロジェクト」くらいのイメージで進めさせてください。 では、まずは皆さん簡単に自己紹介しましょうか。
僕は大手Webインタグレーター、Webサービス会社を経て独立。 今はWebサービスの立ち上げや運営のお手伝いをさせていただきながら、プロジェクトマネージャーやWebディレクターの育成を行うcoach4pmというサービスを運営しています。
こんばんは、きんぴらです。2000年からLAMP系システム開発ベンチャーLinuxサーバ構築、管理やシステム開発のマネージャーからスタート。ディレクターの部署を立ち上げ、数年後にその会社の代表になりました。 組織のマネジメントを行いながら、自分もプレイヤーとしてプロジェクトマネージャー、Webディレクター的なところから営業、コンサルティングなどを2012年くらいまでやっていました。 2013年ごろからはプレイヤーとしての仕事はほとんどやらなくなり、今は会社経営とWebディレクターを育てる仕事に従事しています。
ちゃっす！私は当時全盛期だったガラケー公式サイトの立ち上げや運用からキャリアをスタートしています。 その後、Webサービスを運営する会社に転職して新規事業の立ち上げメンバーを経験。 フリーになろう！と一念発起して2012年に独立して、Webディレクターとしてお仕事させてもらってます。 私はディレクターのなかでもプランナー寄り。 ときどき要件おもらし系（TωT）ｼﾞｮﾎﾞｼﾞｮﾎﾞー
どもー。僕は大学を卒業後、制作会社で2年半勤務したのちにフリーランスとして独立しました。 元々は紙媒体の案件が多くて、アートディレクションから制作までトータルやらせていただいていました。 最近はWebの案件もだいぶ増えてきましたが、四苦八苦しています(笑)
みなさん色んな経験されてそうですね。 きっとその中には炎上案件も・・・。
ばんはー。
ブラックな人ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
ブラックな人ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
ブラックな人ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
すいません息子が階段で転んで怪我しちゃって。 自己紹介だけして離脱しますスンマセンm(_ _)m チャットワーク覗きながら隙をみてコメントします！ 僕は大学を卒業したあと、リクルートに入社して編集業務をやっていたんですが、独立願望があって26歳で友達と会社を作りました。 最初はインテリア用品の通販をやっていたのですが、徐々に受託案件の売上比率が増えていって今ではほぼ受託案件で成り立っています。 ってことでバイバイ！
ブラックさん、離脱前に炎上ネタひとつだけください！
そういう無茶振りが炎上を生むんですよ。
う・・・。
突然の納期圧縮、Webを知らないデザイナー…みんなの炎上体験
ではブラックさんはそっとしておいて、まずはおもらしさん、何か炎上体験ありますか？
紙媒体系の人とWeb案件を一緒にやると、プチ炎上みたいな状況に陥ることがあります。 ちょうど今、そんな案件をやってます(笑)
アサインミスと言ってしまえばそれまでなんでしょうけど、確かにそういう人と組む場合は依頼側できちんと制作ディレクションしてあげないとしんどいですよね。 紙の場合は「デザイン⇒入稿⇒納品」という工程だけど、Webの場合は「デザイン⇒コーディング⇒システム⇒運用改善」という工程になるので運用改善フェーズまで含めてデザインが考えられているかどうかってすごく重要ですもんね。
ですね、オペレーションを考慮するか否かでデザインは全然変わってきますからね。
ウワァと思ったのはテンプレートとかCSSとかって概念が紙媒体のデザイナーにはないこと ・・ 意味上の段階わけ（title/h1/h2/pみたいな）とかを考えずに、絵を描くように自由にページごとに作るんだもん。 紙、Web問題はいまだに結構根深いと思う。
運営の設計までちゃんと見据えて実作業者に要件を伝えられるかっていうのはすごく大事よね。 もちろん実作業者のスキルの問題はあるのでアサインのところで防がなければいけない問題ではあるんでしょうけど、現実問題そういうアサインになってしまうことはあるので、そのときにディレクターの腕が試されるよね。
ビール2本目～(^○^)
早っ。 とりあえずパソコンにこぼすのだけは死守してくださいよ・・・。
うぃす(＠_＠;) 買ってまだ半年も経ってないmacbookだから死守！
おもらしさんがビール2本目いったところで、胸熱さんはどうですか？ 何か炎上案件と聞いてぱっと思い浮かぶ体験あります？
僕は円満なので、特に問題はありません。
というのは冗談で、よくあるのはスケジュールが無理やり縮まってしまうような案件でしょうか。制作に20営業日かかりますということでスタートしたのに、途中から「やっぱり10営業日で納品していただけませんか＞＜」という無茶な相談がきます。当然最初は無理です！ということで調整をお願いするのですが、クライアントの担当者の上司のさらに上司くらいのレイヤーでの決定事項だとかで、なんとかしてほしいと。 結局、毎日ほぼ徹夜で進めることになるのですが、作業中にも修正依頼がメール、電話で色々な担当者からどんどん個別に来てカオスになっちゃって。さらに、グロッキーな中で納期焦らされてる中だと、どうしてもチェックの時間がとれなくなってしまい、修正漏れで怒られたり・・・。代理店案件なので、そこは代理店側で仕切ってよという感じではありますが。
それって、代理店が本来そこを担うんじゃないの？ 胸熱さんとクライアントが直接やるのはどうして？
うん、代理店が機能してなそうな気が・・・。
筋としてはそうなのかもしれませんね。 ただ現実問題として、代理店側の担当者も若手で仕切りきれないというケースは多いと思います。そういうときはやっぱり僕が直接進めちゃったりしますね～。
炎上の火種は結局ディレクターの自爆？！
クライアント→代理店→フリーランスの構造問題ですね。 あとはディレクションというところで、クライアント、代理店、作業者の枠組みを取って考えると、結局はディレクターが火種になっているケースが多いんだよね。
同感です。 企画〜設計〜提案して、デザインと開発に落としていく（＋検収）がディレクターの責任領域なので、ディレクターの立場としては「泣かされる」というより「自爆」なんですよね。
エンドカスタマーと作業者との間に入るポジションの人の勉強不足は、大きな問題ですよね。 前述の記事に書いた、ディレクションの責任 というところにもつながる部分です。
わたしのPM&Dの過去の反省事例としても、制作会社や開発会社に甘えすぎていたというのはすごくあるなー。 勉強不足でおもらししちゃった（TωT）ｼﾞｮﾎﾞｼﾞｮﾎﾞー
そうですね、そこの問題も大きいと思います。
クライアント社内のコンセンサスが取れていない問題
あとは、クライアント側の担当者と上司でコミュニケーションがとれておらず、ただ上司に従うしかない状況というのが一番の原因な気がします。
依頼側の担当者とその上司のコミュニケーション問題、これは大きいですね。
ウンウン。担当者が社内の合意形成できない。 担当者と上司の距離が結構あるケースは多いと思います。 「社内」＝「身内」という意識がそんなになくて、「外注先」＝「下請け業者」＝「立場が下」＝「言いやすい」という意識が感じられる。 担当者が「社内でコンセンサスをとる」というのができていないんですよ。 「いいですよー」と言われるからそのまま進んだ挙句、形になって責任者に見せてひっくり返されるという。 担当者は上司に何も言えないので、外注先がかぶされるという。
依頼側の担当者が社内での合意が形成できないというのは、炎上原因の上位にランクインすると思います。 この中では一番ベテランのきんぴらさん、こういう臭いを感じたらどうするんですか？
担当者ではなく社内の決裁権ある人か、せめてその1段下くらいの人がきちんとコミュニケーション取れる人かどうかというのは最初から意識してヒアリングしますね。 で、「あ、臭うな」と思ったら、最初の段階で断ります。
臭ったら断ることができるかどうか。 こういってしまうと元も子もないけど、これこそが炎上対策のベストプラクティスですね。
独立・創業したては臭う案件でも前のめりに受けてしまいがち問題
ここで制作会社側の社長とか営業とかディレクターあたりがスケベ根性でやろうとすると、現場炎上の火種発生ですね。
若いうちは「がんばります！」みたいな感じで請けちゃうんですよねー。 請けて燃やしてました。反省。
ウンウン。
それを制作側のスケベ根性といって、失敗した場合は自分たちを省みる必要ありですね。 ただ、もちろん根性でやるべきときもあるので、どっちがいいかは決定した人の責任ですよ。 仮に、制作会社の社長がやるという判断をしたのなら、その人が最後の帳尻を合わせるべきで、現場に押し付けちゃいけない。
そうかぁ。 フリーランスだと1人で請けて、1人で燃やして泣いて、1人でなんとかして、、、っていうことなので、自分を省みろってことですね。
僕も同じで、何度も泣きそうになりました(笑) まぁでも、そういう体験があったからこそ今があるんですけど。
ただ今戻りましたブラックですよっと。 流れを読まずに割って入っちゃうかもしれませんが、炎上するクライアントは、線引きを嫌がりますよね。明確に線を引こうとすると、何とかしてぼやかそうとしてくる。
ブラックな人ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
ブラックな人ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
ブラックな人ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
戻りました(笑)
線引き=面倒くさい的な依頼者は多いよね。
単にめんどくさいというよりはもっと根深いものを感じる。 なし崩し的にっていうやつ。 良いようにいえばフット・イン・ザ・ドア。 悪く言えば「何にもしないから！トイレ貸して！」
「線引き=面倒くさい」＝「立場（力）の弱い方が負ける」ですよ。 そのリスクを合理的にどこまで考えるかです。
意図的にやってるんじゃないかと思ってしまうケースはありますね。 意図的というか、本人は意識してないかもしれないけど、自分の逃げ道を確保するために線引きしないほうがいいっていうのを経験的に学んでる感じ。
ブラックさんは、ブラックなだけに肌感覚ありそうですもんね(笑) ブラックさんはそういう依頼者に出会ったらどうしていたんですか？
肌感覚はあります！笑 あ、この単語出た、臭う！みたいな。 創業当初は、臭う案件も気にせず取りにいってました。
気合いでやるしかないんじゃ！！ってやつですね。 ブラックだな～笑
そですw この山を登れば楽になるんじゃ！きっと！！っていう。 最初はとにかく、月160時間の従業員のリソースを埋めることが最優先だったですから。 時給1000円以上ならとにかく取ってリソースを埋めに行く。
会社経営的にはせめてマイナスにしないっていう最初の戦略だよね。 たまごの経営戦略。
仕事がある（仕事してる）っていう安心感もありますよね。 フリーランスの場合も、食べるためにちょっと臭うけど受注してしまうケースは多かったです。 独立して売上が月10万円を切るようなこともあったので、その頃は取りあえず何でも来い！って感じでしたよ。 僕は大きな制作会社出身というわけでもないし、有名な賞を取った経験があるわけでもない。 だから自分の価値を売ることが1番の課題だったので、クライアントを選ぶなんておこがましいと思っていた。
わたしも最初はそうでしたー。 精神的に若かったのもあったし、勉強させていただきます的な（関西弁じゃない意味の）スタンスでがんばります！みたいな。
みんなそういう時代を乗り越えてきて、臭うものを未然に防ぐようになってきているんですね。
今は臭ったらすぐに線引きして、工数バッファのために価格も値上げという交渉をします。
基準は「対価－リソース（時間・費用）＞＝0」という計算式だと思うんです。 そして、これに短期的、長期的という概念を入れるとスッキリする。 恩、人間関係、今後の仕事、ランニング売上、経験などの長期的利益と、業務報酬という短期的利益をしっかり分けて考えるのがいいと思ってる。
そして、リソースは状況によって大きく変動してしまうので、リスクを考慮して判断ができるかどうかというのがポイントですね。
納期と費用に余裕があっても炎上は起こるもの？
ところで、「納期」と「費用」に余裕あれば炎上も起きないんですかね？ それがあってもコミュニケーションの問題など他にも大きいファクターがあるのかしら？
コミュニケーションの要素はとても大きいと思います。 納期や予算に最初は余裕があったとしても、スコープクリープを防げないと結局炎上になる。 スコープクリープを防ぐのはコミュニケーションなのかなと。
できるだけ深度のコミュニケーションでしょうかね
スコープクリープというのは、やりながら「あれもこれも！」とか、次の工程に進んでいるのに前の工程まで戻るような変更が発生するとか、そういうイメージであってる？
前の工程まで戻るようなものだと意外と防げるんですけど、そこまでいかないようなのが怖いなと。 単体で見ると担当者レベルでさくっと要求にこたえられちゃうけど、チリツモで意外と工数を圧迫して、気づいたらスケジュール遅れてるとか。
ありますね～。 あと、「見てみないとわからない」「見てみたら違った」というのもよくあります。 ワイヤーで詰めたのに、デザインにしてみたら・・・コーディングしてみたら・・・という。 レイアウトが違うよ！とかでなく、「イメージと違った」 「見てみないとわからない」問題は結構あったりします。 画像の話とかじゃなくてそれデータベースからちゃうやんけ！みたいな
泣くｗ
見てみないとわからないってずるい言葉ですよね。 でもこれは本質的な課題です。 どんな案件でもこれが起きてしまうと結局利益を生まない。
この「見てみないとわからない」問題はみなさんどうやって立ち向かってるんですか？
僕は修正回数を制限することにしています。 スケジュールこれなので、修正回数は2回しかとれません、仮にここで決まらなかったら、スケジュールと費用がこう変わりますと先に説明しておく。そうすると万が一「見てみたら違った」となった際でも予算とスケジュールの相談がしやすい。
原則は確かに修正回数で防げそうな気もするんですが、そうもいかないケースが多いような・・・。
要件を満たしているのに依頼側の都合（や担当者の性格・・・ｗ）で修正が膨らんでしまった場合と、作業側の力量不足で修正回数が膨らんでしまう場合の線引きが難しいよね。
うん、修正回数っていうのは確かにわかりやすいんだけど、依頼側の心情としては「希望通りになってないのに修正回数とか意味わかんない。Why Japanese People!!!」ってなりません？
そうそう、「修正」と「仕様変更」の線引きというんですかね。 こちらは変更なのでカウントします、こちらは修正なのでカウントしませんという会話ができればいいんだけど、なかなか難しい。
やっぱり実務では「変更」ではなく「修正」になってしまうことがほとんどな気がするなぁ。
うん、これが受託会社（立場の弱い）のジレンマ。
ただ、あらかじめ決めた修正回数を超えたときに追加費用をいただくかどうかは別にして、制限する意味は充分あるとは思います。 制限することで依頼側が最初の確認に本気になる。 納期間際でようやく本気で確認し出すようだと、絶対に大変なことになりますから。
ウンウン
ウンウン
ウンウン
ウンウン
炎上は絶対に避けるべき害悪なのか、あるいは成長のきっかけか
ここまで話してきて、みんな炎上を乗り越えてきての今のポジションがあるんだなというのがよくわかりました。 今日のテーマは「炎上をなくせ！」ですが、「炎上で人が育つ」というのもひとつの側面なのかもしれませんね。 僕は炎上なんてさせたくないし、世の中から炎上案件をなくしたいと心から思ってるけど、でも自分を育ててくれたのは炎上案件だし、、、。 皆さんは、過去の炎上案件をやってよかったと思いますか？ それとも、避けられるものなら避けたかったですか？
僕は良かったですよ。 コレやってなかったら今の僕はないです。 多分、仕事無くなって就職してましたね。
わたしも、少なくとも自分にとってはやってよかったです。 会社員時代は最終判断も自分じゃないし、どっか人のせいという意識があった（お恥ずかしいですが）。 自分で決めて自分でやって、お金をいただくという意味がよくわかった。 それこそ初歩的ですが「できないことは線を引く／断る」ということが身を持ってよくわかった。 いままで甘かったなあと。
ですよね。僕も、炎上して学んでこなかったら、今の自分はないと思います。
僕は最初の師匠からは「デザイナーは一回精神的にやられて倒れて、そこからがスタート」的なの言われました。 今すごく分かります。 完全に炎上しないという保証があればいいですけど、もしあったとき、対応策を下の子に伝えるにもやっぱり炎上経験が必要だと思います。 「このケースはこう炎上する臭いがするから、こう伏線張っておこう」みたいなのも出来ますよね。
僕は新人教育として、こっそりプチ炎上を経験させるというのは意図的にやっています。
子育てと近い感じですね。 資質の問題などもあって、立ち直れないケースが出てきてしまうこともありそうだけど・・・。 フリーランスで全く一人で目の前で燃えている火を見て、当然ながら誰も助けてくれる人が居なくて、という状態で、多少やけどしても死なねえなと思えるか、もう火は怖い！と思ってしまうかどうか。
僕もよく考えるんですが、炎上体験は一つの成功ルートだなって思います。 若くて自分で稼ぎたい！というような子たちに何か授業をもつとしたら、「まずはなんでもやる、自分の時間をとにかく仕事で埋めろ」って言います。
そのルートは、それを戦略として理解した上でやるならいいと思うけど、他の人に迷惑をかけるリスクもありますから注意が必要だよね。 キャリアのスタートアップの一手として、炎上体験が必要というのは理にかなっているとは思いますが。
炎上はしたくないけど、成長するためには炎上しなきゃいけない。 だとするなら、育成という意味では擬似炎上研修というのはアリなのかもしれないですね。
それ、coach4pmでやりたい！
まとめ
ということで話は尽きませんが、本日は時間がきてしまいましたね。 簡単にまとめますと、
- 結局、火種を作ってるのはディレクター。
- ディレクター的なポジションに立つ際は、その責任をちゃんと考えよう 依頼側が社内で合意形成できない臭いは危険。ここで断れるかどうかが炎上を防ぐ砦
- チーム全体で深度のコミュニケーションをとることが、スコープクリープを防ぐ
- 依頼側の確認に初期の段階から本気になってもらうことが重要。そのためには、修正回数の制限などは効果的。
- 炎上経験はキャリアとしてはとても強い。疑似炎上ワークショップなんかは有効そう
という感じでしょうか。
それでは最後にみなさん、悩めるプロジェクトマネージャー、Webディレクターに向けて一言お願いします！
大規模化、高度化しているWeb案件でプロマネやディレクターがどんな価値を提供できるか。 PM/Dは炎上の火消し屋ではなく、お客様に最高の音を届けるオーケストラの指揮者／新大陸を目指す船長でなければならない。 そのための努力と時間は相当なものだと思いますが、それ相応のやりがい・報酬もある職種だと思っています！ サービスをつくる喜び、お客様の笑顔をみる喜び、チームで行うという達成感、そのキーになれることにやりがいを感じる人が、PM/Dとして相応しいかなと。
板挟みのPM/Dは、孤独になりがち。 でもだいじょうぶ。おもらしを恐れないで！ クライアントや制作会社・開発チームのおにいさんおねえさんもみんな仲間だよ！ みんなでぷろじぇくとをたのしもうね！^^ （TωT）ｼﾞｮﾎﾞｼﾞｮﾎﾞー
知識と経験どっちも大事。 若い子は頭でっかちにならずとにかく経験を！ ベテランは経験だけに頼らず新しい知識の吸収を！
生命は炎上だよ。 僕たちは遺伝子の乗り物だよ。
coach4pmでは、今後もプロジェクトを幸せにするための意見交換を積極的にやっていきたいと思っています！ 熱い想いを持った方がいましたら、是非お気軽にご連絡ください^^
coach4pm@riso-labo.com
