株式会社コパイロツト COPILOT Inc. のブログ

Good Team Building & Project Management を掲げプロジェクトファシリテーションを行う会社です。ちなみに株式会社コパイロツト(ツが大きい)とかいてコパイロットと読みます。

ブログをはじめようとおもいます

思い立ってしまったコパイロツト代表の定金です。

いまコパイロツトでは絶賛採用活動を進めているのですが、急に採用を熱心に始めても日ごろの発信がないので慣れておらず、また会社の雰囲気がわかるものがなかったりするので、とりあえずコパイロツトの説明や、取り組みのまとめ、コパメンバーが思うことなどを発信していこうと思います。

いまブログ始めるならmedium、note、LINEブログなどと迷ったのですが、一番落ち着く感じがするね、ということでこの「はてなブログ」となりました。

続きを読む

「とりあえずやってみる」その前に仮説のための仮説をたてる

 

何か物事を始めるときに「やってみなきゃわかんないじゃん!」という人がいる。逆に、「いやいやもうちょっと考えてからやろうよ」という人もいる。

「人もいる」といったが、この言い方はややミスリーディングかもしれない。場合によって、とりあえずやってみるか、立ち止まって考えてみるかが異なるというのが本当のところだろうから。

世の中にはアクションとストップのバランスがとれている人がいて、そういう人が「仕事ができる」とか言われたりする。その人は、仮説のたてかたがうまいのだ。

仮説を分解する

「あれをやったらこうなるだろうな」というのが、仮説である。

小難しく考える必要はなく、「こんなツールαをつくったらみんなの仕事が効率化するんじゃないかな」とか、そういうことでも、立派な仮説といっていい。

言いかえると、プロセスに対する結果の予測が仮説なのである。

何かを「やってみる」ためには、プロセスがしっかり考えられている=プロセスの仮説をたてる必要がある。さっきの例でいうと、「チームメンバーに課題を詳しくヒアリングすると、こんなツールαができるな」とかいうことが考えられていればよい。

すると今度は、「チームメンバーに課題を詳しくヒアリングする」ための仮説が必要になる。例えば、「チームメンバーをグループに分けて3回ディスカッションすると、課題を詳しくヒアリングできるな」というのが、この場合の仮説になる。

以上の話を図にすると、こんな感じである。マトリョーシカ構造になっているのがお分かりだろうか。

 
仮説のマトリョーシカ

「やってみる」ためには、このマトリョーシカ構造を意識して、仮説をブレイクダウンし、できるだけ細かなアクションからスタートするのがよい。

仮説を評価する

じゃあ、仮説をブレイクダウンできれば「やってみる」ことはできるのか?それだけでは実は不十分だ。ブレイクダウンした仮説のそれぞれを、評価しなければならない。そうしなければよりレイヤの高い仮説にうつれないからだ。

さっきまでの具体例を使うと、「チームメンバーをグループに分けて3回ディスカッションしてみたが、果たして課題を詳しくヒアリングできたのか?」ということをきちんと確認できないと、ツールαをつくることができない。

つまり、ブレイクダウンした仮説を評価する指標と、次の仮説に移れるかどうかの水準を、あらかじめ設定しておくべきなのだ。仮説のマトリョーシカの一つ一つの品質を図る基準を決めておく、というと、わかりやすいだろうか。

実は、これが難しい。指標は必ずしも定量的なものにならないこともある(「課題をヒアリングできたかどうか」なんて、肌感でしか測れない気がする)し、水準をどこに設定するか(どの程度までいけば「課題を詳しくヒアリングした」ことになるのか?)なんてもはや決めの問題である。

指標や水準の測定があまりにも難しい場合は、その仮説の評価は不可能である。そのときは、「とりあえずやってみた」だけで、それが何?ということになってしまうため、いったん立ち止まって、もう少し考えてみたほうがいいだろう。


仮説を立てるとは、想像することである。

「あれをやったら、こうなるだろうな」という想像がたつかどうかは、どうしても経験値の有無が影響してしまう。しかし、仮説をしっかりブレイクダウンしていけば、自分の想像力でもアクションを起こせるレベルまでもっていくことができる。まずは小さな仮説からはじめよう。

 

思考を形にするコツ---アウトプットこそが正義---

今働いている会社が広告クリエイティブの文脈をもっていたり、また自分の職種が企画だったりプロジェクトマネジメントだったりすることから、抽象的なことや不確定なことを考えて、それを形にすることが多い。

具体的には、
・クライアントの考えているぼやっとしたイメージを制作物に落とし込む
・ディスカッションの結論から企画書を書き上げる
・先行き不透明なプロジェクトについて、関係者が共通認識を持てるようなドキュメントを作成する
とかがそれにあたる。

これらは業務領域こそ違えど、「思考を形にする」という点ではすべて共通している。すなわちアウトプットを出す作業だ。

「思考を形にする」というと、「言語化する」と捉える向きがあるが、それは大ざっぱな考えなように思う。確かに言語化することで思考の輪郭がはっきりすることもあるのだが、文字にするのか、言葉に出すのか、でもアウトプットの形は変わってくる。

文字にする

文字にする、さらには文章にするという行為は、一つ一つの語の意味を厳密に考え、きれいな文章やコピーを生むことができれば、誰の目にも明らかでその後も運用しやすいアウトプットになる。本を書く、という行為がその際たるもので、完成した本はアウトプットとしての自己紹介ツールや営業ツールとして機能する。

ただし文字にする行為はハードルが高い。言葉の意味に厳密になりすぎるあまり、「この言葉で適切か?」ということを常に考える必要があるし、逆に厳密にならない言葉は価値を持たない(「整理する」「まとめる」「検討する」この辺の言葉は、それが意図的に使われているのでない限り、だいたい無意味なことが多い)。文字は具体性と抽象性の間の曖昧さを許してくれない。

口に出す

そんなとき、口に出して言葉にする、誰かを相手にしゃべる行為が便利だ。表情、声のトーン、しゃべる速さ、体の動き、また、「同じ場所で話している」という事実、多くの非言語情報が、抽象的な言葉に具体的なニュアンスを、具体的な言葉に抽象的な要素をつけくわえてくれる。

例えば、「いやーこれはちょっと厳しいですね」と口に出したそのとき、その人が苦笑いをしているのか、険しい顔つきをしているかだけで、「できないことはないけど正直ありえないと思っている」のか、「真剣に考えた結果本当にできないと考えている」のか、という推測が可能になる。あくまで推測であって曖昧さは残るのだが、これがしゃべるという行為のハードルを低くしている。

だから僕は、頭の中の整理ができてなさそうな人がいたときは、できるだけしゃべってもらえるように促すことにしている。

しゃべってもらうときにも、ある程度コツがある。一つの方法は、「~~~なんですか?」と、質問することだ。だいたい人は「こうだ!」という絶対的な答えを持っていなくても、「そうじゃない」という相対的な比較のうえでなら考えを述べることができる。

もっとシンプルな方法としては、「とりあえずなんでもいいからしゃべってください」ということである。ダイレクトに伝えてしまう。ただし、この場合はニュアンスに注意しないと、「おら、しゃべれよこら!」みたいな空気が醸し出されてしまうので難しいときもある。相手との関係性も、当然考慮する必要がある。

チャットツールとかだと、基本は会話ベースのアプローチをとるものの、やはり非言語情報がなかったりするので、これらの方法はうまくいかないときが多い…というのが最近感じているところ。

絵をかく

しゃべってもらう→文字にするの流れに、絵をかく、という術がある。これは、できる人とできない人…というより、その重要性を理解して訓練している人といない人、で大きな差がでる。

要は、いわゆるビジュアルシンキングというやつである。さっき書いた「非言語情報」の代わりを、絵の構成要素の一つ一つが担ってくれるのである。パワポのスライドのコンポーネントで、四角をつかうのか、丸をつかうのか。前者はしっかりとしたイメージを与えるので、固まった用語や定義に使うのがよさそうだ。後者は文字通りまるっとしているので、何か抽象的な概念を表すときに使うのが適切だろう。

さらに図は、構造化して考えを形にできるという点では文字や口頭の言葉よりも優れている。構造化できると何がいいのかというと、すぐに全体像を把握できること、何が足りていないか気づくことができること(MECEに考えられること)、だ。そして、往々にしてその足りていないところに重要な気づきがある。

絵を描くことはそんなにハードルが高くない。なので、自分が人の考えを引き出したいときは、まず口に出してもらう、それから絵にかいてもらう、または自分で書いてそれに追記してもらう、みたいなアプローチをとっている。

ちなみに自分で図をかけるようになるためには、『描きながら考える力 ~The Doodle Revolution~』がおすすめ。

アウトプットが生むものはアウトプットである

思考を形にするとは、つまり何かのアウトプットを出しやすくするということである。アウトプットが出るということは、それを周りの人間がインプットして、またアウトプットを出すということである。

当たり前のことを言っているだけなのだが、これがすべてだ。アウトプットしない思考は、誰にも伝わらないし、何も生まない。

だから、とにかく口に出す、図にかく、文字にする。それが成果を生み出すための必要条件なのである。

あれなんか進まねーなー、と思ったら、まずはアウトプットが足りないんじゃないか?と疑おう。


…といいながらこの文章には図もなにもないのである。折に触れてこの文章の中身を図示しよっと。

目指せナレッジワーカー!常に思考するための気づき記録ツール10選

皆さんは、ナレッジワーカー(知識労働者)という言葉をご存知でしょうか?

ナレッジワーカーとは、かの有名なピーター・ドラッガー先生によって提唱された概念で、ごく単純化していうと「ナレッジ(知識)から付加価値を生む労働者」のこと。

大量生産・大量消費の時代における「決められた仕事を単純にこなしていく労働者(マニュアルワーカー)」とは一線を画した存在です。

テクノロジーの力で多くの定型的な業務がロボットに代替されつつある昨今、私たちはナレッジワーカーになることでより職業人としての価値を高める必要があるんですね。

では、どうやったらナレッジワーカーになれるのでしょうか?そのための第一歩が、業務のなかで気づいたことを記録すること。

ヤングが『アイデアのつくり方』で、些細なことでも頭によぎったことをひたすらカードに残して記録することを推奨したように、ユーレカ(アイデアががひらめくこと=知識から付加価値を生み出すための最初のステップ)にたどり着くためには、記録をすることで思考を練磨していくことが必要なのです。


さて、業務の大半がプロジェクト型(つまり、今まで誰も経験したことのない未知の仕事)であるわれわれコパイロツトでも、ナレッジワーカーになることが全力で推奨され、メンバーは考えたことを日々メモし、思考のトレーニングをしています。

前置きが長くなりましたが、今日は、弊社メンバーの実践している気づきの記録方法を公開したいと思います!

1. Evernote

(メンバーコメント)

  • ・テキストもファイルも一元管理ができて、かつタグづけができ、さらに検索可能だから
  • 必要なタイミングで検索を行いやすい
  • バイス問わず気軽に記録できる
  • いままで使っていたから

パイロツトメンバーが最も採用しているのはEvernoteでした。その人数たるや実に12人中7人。記録形式の多様さやタグづけができることなど、リッチな機能に加え、対応デバイスが豊富で簡単に利用できる点が支持される理由のようです。「いままで使っていたから」という理由も、定番感を感じさせますね。

2. メーラーの下書き

(メンバーコメント)

・Gメールの画面は、常に開いているため。PCを開いている時(作業中)に記録できる。

・なにかのはずみで書いたことを思い出し、なにかしらのキーワードで検索する。(検索されなかったメモは、使われるレベルや内容ではなかったと判断する)

  • すぐに送れたり、案件とひも付けられるから。

意外(?)にもメーラーの下書きを利用している人も複数名いました。業務中でも常に画面に表示していること、メモ内容を誰かに送りやすいことといった、業務との連続性が主な採用理由。検索性が重視されている点は前述のEvernoteと同様ですね。

3.Google Keep

(メンバーコメント)

  • MacでもiphoneでもAndroidでも開きやすい。
  • Evernoteほど分類をしたりすることがない。後から見た時に一覧性が高い。

実は筆者が愛用しているのがコレ、Google Keepです。付せんを並べていくような感覚で、シンプルに使えるところを気に入っています。複数デバイスで使いやすいのも◎。

4.Googleドライブ上で保存

(メンバーコメント)

  • マニュアル的なある程度の分量のものをまとめるときは、DocumentやSpreadsheetのほうがすぐれているから。
  • 自分のやりかたで参考書類等をまとめたかった。

メモ専用ツールであるKeep以外に保存している人もいます。ある程度まとまった分量のある気づきをまとめる際に利用されている様子が伺えます。

5.ローカルのテキストに保存

(メンバーコメント)

  • 特定のツールを決めていないため、取りあえずメモする場所が常用されている
  • 端末さえあればメモできる
  • 最も簡単だから

ローカルのテキストに記録している人もいました。理由としては、とにかく記入が簡単であることが挙げられています。アクセス制限が厳しい会社のパソコンを利用している人などにとっては、この方法が採用しやすかったりするかもしれませんよね。

6.Googleカレンダー

  • PCを開いているときは、だいたい開いているから。

なんと、カレンダーを利用している人もいました。メーラーと同じく、常にひらいていることがその理由のようです。

【他にもこんなものがありました】

7.手書きノート

8.写真

9.Pocket

10.Facebook

手書きノートや写真といったアナログツールも、未だに根強いですね。PocketはWeb上の記事や動画をログしておき見返すためのツールですが、同様の用途を、開く頻度の多いFacebookで実現している人もいました。


いかがでしたでしょうか?最も重要なファクターとして「記録のしやすさ」が挙げられますが、その意味するところは「どのデバイスからも記録しやすい」「どの形式でも記録しやすい」「どのような状況でも記録しやすい」等、様々であることが見て取れるのではないでしょうか。また、「記録する」ことに加えて、「検索する」「見返す」ことができるかどうかも、ツール選定に影響を与えるようです。

さあ「日々の業務が作業ゲーでつまらん!」とお嘆きのそこのあなた、これらのツールを利用し、ナレッジワーカーとして働きませんか?


 

パイロツトとは?

パイロツトは、デジタルマーケティングの支援を中心としたプロデュース&プロジェクトマネジメントを手がける会社です。

もともとはWebディレクションをメインとしてきましたが、プロジェクトマネジメントが施策の成果に大きく影響することを痛感し、徐々にプロジェクトマネジメントにシフトして現在に至ります。

社内に制作部門はなく、プロジェクトごとに最適なパートナーをアサインして課題解決に挑みます。制作部門を持たないメリットは、社内リソースの機能にとらわれることなく、クライアントにとって最適な打ち手を考え、実行できることです。たとえば、Webサイトリニューアルのご相談をいただいてお話を伺っていると、Webサイトのリニューアルが最適な打ち手ではない場合も少なくありません。そんな時には、軽やかに他の方法に切り替えた提案をすることができます。そのため、頻繁ではありませんがリアルイベントの戦略策定から実施までをお手伝いをすることもあったりします。

パイロツトは、こんなふうにして事業会社のさまざまなサポートをしています。おかげさまで、口コミやら紹介やら別案件のご相談やらで、営業活動をする暇もなくお仕事が継続しています。

コパラボとは?

そんなコパイロツトにコパイロツトラボ(通称コパラボ)を設立しました。

設立といってもクライアントワークを続けながらの兼任という格好ですが、すこしずつラボの業務にあてる人員を増やし、稼働時間の振り分けも少しずつ大きくしています。

ラボで行なっているのは、ひらたく言えば「ナレッジマネジメント」がメインです。社内にあるナレッジを集めて、抽出して、みんなが活用できるメソッドにしていくプロセスを構築しようとしています。

ナレッジマネジメントを構築する目的は「チームとしてのシナジーを出す」ということです。

以前は、ひとつのプロジェクトに対してひとりのプロデューサーやプロジェクトマネージャーがつくということが多く、フリーランスの集まりのような状態でした。それならば、なぜコパイロツトというチームで一緒にいるのか? チームにいることの価値をもっとあげなければいけないのではないか? そんな課題意識がありました。

そこで、ひとつのプロジェクトに2〜3名のチームで臨む態勢をつくったりといった取り組みをしています。

ナレッジマネジメントに取り組むのは、この課題意識から生まれたものです。

プロジェクトを通して個人が得た経験や知見は、日常の会話や、ちょっとした相談、社内にシェアするなどの方法でこれまでも共有してきました。メンバーも積極的に共有しようという意識はあって、個々人がさまざまな方法で取り組んできました。週1回の全員出席の会議も、メインに据えているのは個人の気づきのシェアや議論です。そのため、知恵はシェアしようというカルチャーは、以前から根付いていると思います。しかし結局はシェアする方法、あるいはそもそも何をシェアするかといった判断は、あくまでも属人的なままでした。

そこで、チームとして最大限の価値を生み出すために、より構造的で業務にもインパクトを与えるナレッジを構築するしくみづくりに取り組んでいます。

そうすれば、各人の成長も強力に促進され、コパイロツトにいることの価値が生まれていくのではないかと思います。

そして基幹業務が体系化されたメソッドになったとき、コパイロツトの主要サービスが可視化されて、クライアントやパートナーのみなさまに、いま以上に価値あるサービスを提供できることになると思います。

ここまで読んでくださったみなさまへ。

では、コパラボって実際に何やってるの?ということは、これから少しずつ、ここお伝えしていきたいと思います。

こんなふうに考えてこんなことやってますということをまとめた記事や、現在進行形のレポートを公開していきます。

・「そう! うちはいまそれで困ってるんだよ!」というクライアントさま →どうぞお気軽にお声がけください!

・「ちょっとその話聞かせてよ!」というパートナーさま → もちろん、どうぞお気軽にお声がけください!

・「似たようなことやってるんだけど、一度会わない?」という方 → ぜひお会いしましょう!

・「それもううちでやってるよ。話聞いてみる?」という方 → もちろん、ぜひお話しさせてください!

・「おもしろいなー」と思ってくださった方 → シェアしていただり、コメントを残してくださると、コパラボ一同が喜びます! ぜひ!

…ということで、まずはコパラボページ開設のごあいさつのエントリでした。

「走りながら考える」というスタンスで公開していきたいと思いますので、ご興味ある方は、寛容な心持ちでどうかお付き合いください。

結局どうやってつくればいいの?プロジェクト憲章について真剣に考えてみた

 

最近、プロジェクトをスタートするときに必要とされる文書「プロジェクト憲章」について社内でディスカッションしたので、その結果をシェアしたいと思います。「プロジェクト憲章って大事っぽいけど、どうやってつくったらいいのかわからーん!」という悩みをお持ちの迷えるプロジェクトマネージャの皆さま、ぜひお読み下さいませ。

1.プロジェクト憲章とは?定義と作成のメリット

さて、まずはプロジェクト憲章の定義を確認しておきましょう。

プロジェクト憲章とは、プロジェクトを立ち上げる際に策定される、プロジェクトの目的や条件、内容などを明確に定義した文書。(IT用語辞典E-Wordsより引用)

つまり、プロジェクトを始める際に、プロジェクトメンバー間で「このプロジェクトの目指すところ(目的)はこれで、スケジュールはこのくらいで、かけられるコストはこれで…」とあらかじめ決めておく大原則・根本ルール(=憲章)のことですね。

プロジェクトが迷子になったとき、「目的に照らすとこのプロモーション企画はやるべき」とか、「スケジュールとコストはこのくらいで考えているから今回はこの機能の実装は諦めよう」とかいう話がプロジェクトメンバー間でできるようになるという、スーパー文書なのです。

2.プロジェクト憲章失敗例

とはいえ、このプロジェクト憲章、なかなか作成するのが難しいんです。過去たかつが実際に経験した数々の失敗例を紹介しましょう。


ケース1 つくったプロジェクト憲章を読んですらもらえない

たかつ「ボス、今度社内で始める新しいプロジェクトのプロジェクト憲章を作りました。チェック頼みます」

ボス「項目多っ。読む気にならんわ!」

たかつ「なるほど」

Google画像検索で、「プロジェクト憲章」と検索してもらうと分かるのですが、プロジェクト憲章に記載する項目数はフルに書こうとすると相当なものになります。がっつり気合が入っているときは全部埋めようとがんばりますが、読む方からしたらけっこうな手間。そもそもプロジェクトの大原則を決めるものなのに、ガチガチに詰めたってしょうがないんですよね。。


ケース2 読んでもらっても強烈なダメ出しを受ける

たかつ「ボス、がんばって項目しぼりました。読んでもらってもいいですか?」

ボス「え、目的とかこういう認識だったの?あなたも書いてるけど、そもそもこのくらいしかコストかけないんだからこんな目的達成できるわけないじゃん。」

たかつ「なるほど」

プロジェクト憲章を読んでもらった結果、ダメ出し→大量の修正、ということはままあります。まあ、そもそもこの認識のすり合わせ自体がプロジェクト憲章を作成する理由の1つではあるのですが、とはいえあまりにも大きい手戻りは避けたいところです。


ケース3 相手のテンションを下げる

たかつ「ボス、チェックありがとうございます。じゃあ次はこっちのプロジェクト憲章をチェックしてもらってもいいですか?」

ボス「え、まだあるの…これ読むのつまらないし疲れるんだよね…」

たかつ「なるほど」

そう、決まったテンプレートはないにもかかわらず、なぜかプロジェクト憲章は多くの場合表組みで作成され、結果、文字ばかりの読みやすいとは言えない資料として完成します。プロジェクトの進行中、何回も立ち戻って読むべきプロジェクト憲章のユーザビリティが悪く、参照されないものになってしまう可能性があるのというのは非常に問題です。

3.カギは「見せ方」と「作成の順番」

さて、上記の会話から、以下の課題が浮かび上がります。

  1. ・項目が多くて読む気にならない
  2. プロジェクト憲章に記載する内容の認識にメンバー間で大幅なズレがある
  3. 読む気にならない

これらを解決するため、弊社メンバーが考えたのが、プロジェクトの諸条件を、1つの項目につき一枚のスライド形式でまとめるという手法です。そもそもプロジェクト憲章が表組み形式だから読む気にならないんです。スライド形式なら図形や絵、なんならホワイトボードの写真だって載せながら認識合わせをすることも可能です。これで、読むのがつまらないという問題は大幅に改善する(はず)です。

このとき、「目的」の項目のスライドは最後に作成します。なぜなら、プロジェクトの目的は、現実問題として立ちはだかる他の諸条件(スケジュールとかコストとかメンバーの数とか)を暗黙の前提としてつくられていることが多いからです。この目的という項目はプロジェクトの中でも超重要項目であるがゆえに、表組みにした場合冒頭に掲げられている場合が多いのですが、実は先に外堀(他の諸条件)を埋めてからのほうが認識ズレを防げるのではないでしょうか。

ここまで書くとお気づきの方もいるかと思うのですが、上記の「スライドでプロジェクト憲章をつくる」という考え方は、ソフトウェア開発におけるインセプションデッキというドキュメントから発想したものです。項目数は、インセプションデッキを参考に、開発特有の項目をより汎用的なプロジェクトマネジメント的な項目に置き換えることで必要な十分な数に抑えることができそうです。

4.もはやプロジェクト憲章ではない?プロジェクトデッキ開発へ

長々と考察してきましたが、もはや、「われわれがつくろうとしているのはプロジェクト憲章なのか?」という疑問が湧いてきました。

多くの方が「プロジェクト憲章=表組みないし文字だけの一枚ドキュメント」とイメージするなか、何枚かにわたってつくられるであろう、まだ見ぬスライド資料…そう、これを、プロジェクトデッキと名づけよう!

というわけで、コパイロツトでは現在プロジェクトデッキの作成に鋭意取り組んでおります。もう同じようなのつくってるぜ!という方は、ぜひコパイロツトまでご一報を!情報交換しましょう。

それでは皆さん良い一日を!