先日、ギグエコノミーについて調べようと思ったときに一緒に購入した。「ギグ・エコノミー襲来」はギグという働き方と社会の変化、ギグワーカーとして働く上での押さえておくべき要項などをまとめて、ギグエコノミーと呼ばれる経済活動全般について説いた書籍だった。
私が知りたかった内容や興味をもった箇所などを次にまとめた。ギグエコノミーとは？が知りたい方はまずこちらから読むとよい。

「ギグ・マインドセット」は、実際にギグエコノミーを活用してビジネスをしている実践者によるプラクティスをまとめた本である。著者はギグワーカーの先駆者、且つ普通のサラリーマンからギグワーカーへの転身者でもある。より個人の経験に基づいた実践書になるので、ギグエコノミーのギグワーカーの働き方の実態が伺える。

一方で本書で紹介されているのは、ギグワーカーに仕事を依頼する側 (マネジメント) の心構えや方法論が主になる。またピラミッドのトップレベルの専門技能をもつギグワーカーへの依頼内容の紹介が主になる。ギグエコノミー全体の働き方というより、一部のハイスペックな領域での働き方とみるべきだろう。

本書は米国での事例について書かれているので、日本では事情が大きく異なることも念頭に入れながら読み進めるとよいと思う。

ジェネレーションY (ミレニアル世代)

本書の中では1980年代から2000年代初頭と書いてあるが、wikipedia によると1980年代から1990年代中盤という区切りになっている。ミレニアムが2000年を指すことから解釈の違いがあるのかもしれない。1990年代中盤までか2000年ぐらいまでかの誤差がある。

本稿の執筆時点で年齢を換算すると、いま20代から40歳程度までの世代をジェネレーションY (ミレニアル世代) と呼ぶ。この世代の特徴を次のように述べている。

私はぎりぎりジェネレーションXに含まれるが、親や祖父母が現役の頃の社会や働き方とは大きく異なるため、お互いにその価値観を共有することは難しいという点について共感している。

私自身、親の言いつけを守っているのは連帯保証人にはなるなぐらいである。父は学校を卒業してから42年間、1つの勤め先で働き、定年を迎えた。一方の私は1つの会社で3年以上働いたことがなく、6社を転々とした後、独立した。働き方についてお互いの価値観を共有できるわけがない。

働き方が大きく異なる背景の1つに世代という切り口でみれば、その時代の社会の変化、ジェネレーションYで言えばパソコンの普及やインターネットの勃興というテクノロジーの発展が大きく影響を与えているという説は受け入れやすい。

これまで社会の変化や働き方の違いを世代としてみたことがなかったので私は新鮮に感じた。

解雇同然の体験

著者がフリーランスになってギグエコノミーで働き始める前、普通のサラリーマン家庭で育ち、マイクロソフト社で働いていた。当時、プロジェクトがうまくいっていない状態で上司から 1on1 を持ちかけられ、次のように言われたらしい。

退職勧奨ではなく社内で別の仕事に就くこともできたらしいが、著者は IT 業界で (当時) 15年働いてきたベテランエンジニアであり、自分が必要とされない現実に大きなショックをうけてしまったらしい。この一件が著者が会社を辞めて独立するきっかけになったと本書の中で何度か出てくる。

私の父は定年まで働いたが、55歳で役職定年を迎え、それからの5年間は充実した働き方ではなかった。慣れない現場の仕事に戸惑いもあったが、それ以上に職場いじめが辛かったように聞く。65歳まで残ることも可能ではあったが、父はそれを選択しなかった。

分業制の宿命かもしれないが、業務の役割分担や平準化ができている組織ほど、年配の労働者の勘と経験を必要としない業務になっていく。年配の労働者は管理職に落ち着くわけだが、すべての年配の労働者に管理職のポジションは用意されていない。日本ではそのことを明確にする儀式が役職定年と言えるのかもしれない。付加価値をつけにくい誰でもできる仕事を高給取りである年配の労働者が行うようになり、組織の歪みが現場に現れてしまう。

著者のこの気持ちに私は共感できた。私も、退職する前の仕事そのものは嫌いではなかったが、そこで自分の能力を100%発揮しているかというとそうではなかった。且つ、さして難しくない業務の要職を自分が占めているだけで、若い人たちが学ぶ機会を奪っているようにも思えた。いわゆる、上が詰まっていて若い人たちの邪魔になっているように考え始めていた。

組織で働くにしろ、独立して働くにしろ、70歳まで働くと考えるといまの延長上で想像できそうか、自分が変わっていく必要性を迫られるか、人それぞれに考えることはあるだろう。

私はある日、退職勧奨される日まで漠然とした不安や恐れをもって働き続けるよりも、自分が変わって稼ぐ力を学ぶ方がよりよい未来になると考えて独立することを選択した。そのため、本書の著者の心情には共感するところが多い (なので本稿にバイアスがかかりやすいので注意して読んでほしい) 。

学び直しのための余暇

たいていは過去の経験や学習を土台にしてその延長上で学び続ける。これ自体は悪い学習方法ではないが、全く異なることを学ぶことに対して億劫になるときがある。もしくはこれまで学んだことが邪魔をして、新しい概念を軽視してしまい、その本質を見誤ったりすることもある。

著者は学ぶためには余暇が必要だと解き、次の3点を念頭に取り組むことを提案している。

1. 時間をつくるかどうかはあなた次第である
2. 実際にやりながら学ぶことも可能である
3. 学び直しは必須である

1. と 2. はだいたい想像がつく。みんな忙しい中でどうやって時間をつくるか。2020年に公表された「デジタル・トランスフォーメーション（DX）推進に向けた企業とIT人材の実態調査」によると、IT従業者の業務外の、週あたりの平均勉強時間は約1-3時間程度であることがわかる。

私も業務の中でも学ぶもので必ずしも業務外で多くの勉強時間を割く必要はないと思う。一方で分業によって業務が固定的な役割に落ち着いてしまうと、新しいものに挑戦したり試したりといったことが難しくなる場合も出てくるので注意が必要だ。

3. の学び直しはどうだろう？この言葉は幅広い意味で使われるようにみえる。早期退職した人や子育てや介護などで一時的に就業を中断している人だけでなく、現職者も対象にしている。大学や専門学校の社会人枠、コミュニティの勉強会、独学や通信講座など学ぶ手段も様々である。

著者はフリーランスの方が学び直しの時間を取りやすいと言及している。それは仕事の隙間を、会社で従業員として働くよりは相対的に、コントロールしやすいからだ。

次は課題管理システムに私が登録した本を読むタスクのうち、読みかけと完了したものの一覧だ。ちょうど仕事の切れ目の時間を使って、約1ヶ月で10冊ほどの書籍を読むことができた。いくつかは書評も書いている。

書評を書く目的は、その書籍から自分が得た学びを深めるためである。書くことで思考が整理され、記憶への定着や深く理解することにつながる。学びには書くことも大事だとメタ認知に関する本を読むことで気付けた。

歳を経るごとに本を読まなくなる人もいるのではないだろうか。私がそうだった。自分の時間を確保できたことで本を読もうという動機づけにもなった。これも学び直しの1つと言ってよいだろう。

ビジートラップ

ギグワーカーに仕事を依頼することを推奨する根拠の1つとしてビジートラップという現象を著者は次のように表現している。

仕事に夢中になって取り組むこと自体は悪いことではないが、そうではない責任感やプレッシャーなどから仕事以外のことが何もできない状態に陥ってしまうときがある。この状態に陥ると、たった30分でできる作業すらできなくなってしまう。自分一人という感覚にとらわれてしまい、自分のやることリストを人に手伝ってもらうことができないと思い込んでしまう。

ビジートラップに陥らないためにも日々の生活における雑用をギグワーカーに依頼することを著者は提案している。しかし、そのためには自分が当たり前に思っていた考えや習慣を変える必要がある。よりよい行動の指針はいくらでも手に入るが、多くの人は実践しない。その理由は本当に変えたいと思って自分の意識を変えられないことに問題がある。

従って、ギグエコノミーを活用して、日々の生活や仕事のタスクを外部のギグワーカーに依頼するようになることはそう簡単なことではないと著者は説明している。そういった行動を習慣化しないと変えられないかもしれない。新しい習慣を身につける目安として平均66日かかるという説がある。簡単な行動ほど習慣化しやすく、複雑で面倒な行動ほど習慣化しにくい。また個人差も大きい。あくまで参考情報としてこのぐらいの期間をがんばる目安にするとよいと説かれている。

ギグエコノミーを用いた仕事の仕方改革

著者は次の5つの事柄を決めて改革に取り組んでいる。

1. 時間を設けてまで会議をする必要があるかを確かめる
わざわざ時間を設ける必要が本当にあるか、別の方法で同じ成果を得られないだろうかとチームで相談することを奨めている。著者は、会議は時間と労力を湯水のように使うにも関わらずメリットがどんどん少なくなっていると指摘し、本書の複数の箇所で会議の時間を節約できる可能性について言及している。

私も会議をなるべく減らす方向で検討する姿勢に賛成する。この数年、毎日朝会をする組織で働いてきた。ある組織では朝会の本当の目的は、メンバーが日々の活動を情報共有することではなく、毎日メンバーが出社しているかを上長が確認するのに都合がよい機会なのでそうしていただけだった。
会議の時間を短くして効率をあげようとする試みもあるが、私はあまり同意しない。もちろん長くても効率が悪くなるので、例えば最長1時間という制約を課すことは役に立つが、30分の会議なら毎日開いてもよいというわけではない。会議は会議そのものよりも同期のためのコストが高い。30分の会議のために、参加メンバーがその前後30分ぐらいは複雑な課題に集中して取り組む時間を奪っている。
従って、時間の長短よりも会議の数を減らすことに注力しようという姿勢を私は支持する。

会議にかかっているコストを計算するアプリケーションがハーバード・ビジネス・レビュー誌のサイトで公開されている。試しにやってみるとおもしろいと思う。

2. オープンに仕事をする
ガラス張りの状態で仕事を進め、透明性を高めていく。それにより、会話が円滑になり、速いペースでイノベーションが起き、質の高いプロジェクトができる。
コラボレーションツールを活用してアイディアを形成し、計画を書き出すようにする。コラボレーションツール活用の主目的は創意工夫のペースアップとチームの強化にあるが、正式な会議を開く必要性を極力下げる役割も果たすという。

私の中では、これはまさに課題管理システムの役割である。日々の自分がやっている活動を、取り組んでいる課題のコンテキストと一緒に書き出すことで、口頭で報告を受けなくても、誰が何をやっているか課題のチケットをみれば把握できるようになっていた。

3. ビジネスチャットツールを活用する
他者との自然発生的な会話にもっと時間を費やす。どうでもいいような会話の中に実はイノベーションを引き出すような事柄を語り合うことがある。著者の過去の経験では、散歩をしたりコーヒーを買いに行ったりしながらメンバーと戦略の話しをする方が、より生産的で活発な会話につながったことがあるという。
ここでは仕事以外のおしゃべりもできるようにして、社内だけではなく外部の人たちも参加できるようにしたいと説明している。

私もチャットツールに仕事とは直接関係ない趣味のチャンネルがあることで、メンバー同士のやり取りやコミュニケーションが活発になる現象を実感している。技術系のコミュニティなどで開発者は比較的、このメリットを理解しているように思う。
一方で参加者が増えることで健全なコミュニティを維持していくコストが大きくなっていく。たった1人の変な人がコミュニティを壊してしまうことにもつながる。そのバランス感覚はなかなか難しい。

4. 考えを書き出す
自分の頭にあることをじっくり考え、書き出す。著者の過去の経験では、誰かに情報をくれとメッセージすると「電話で話した方が早い」と言われた経験は信じられないほど多いという。考えを書き出すことで、頭の中が整理され、自分の目標や優先順位、意図することが明確になる。

先日、知人とモブプログラミングについて話す機会があった。スキルの共有や集合知による課題解決などのメリットがある。一方で深く考えることには向いていないといったデメリットも聞いた。次の記事でも、モブプログラミングがうまくいかなかった事例が紹介されている。

私自身、周りの人たちと比べて考えるのが遅いのだと思うが、短い時間で瞬発力をもって深く考えることは苦手である。認知心理学の知見から自分でできる限り考えた上で他者の考えに触れることが効果的だとある。

5. 「ノー」と言えるようになる
好奇心旺盛な人ほど何かを断るのは困難だという。その理由は自分が取り残される不安と、勉強の機会を逃してしまうかもしれないという考えにある。自分が価値を提供できない会議は断ることを著者は述べている。

ここ数年、自分の中で品質を保証できないような業務は断ることを意識している。業務の内容や特性にもよるが、一定の責任を担うようになると、可否よりも品質の善し悪しを重視している。見た目上、動くだけでよいならシステム開発はいくらでも手を抜くことができる。しかし、ソースコードをみれば手を抜いたことや設計が稚拙なことはすぐに分かる。それを経験のある人が確信犯でやっていると信頼をなくす。可否よりも信頼の方がずっと大事なのだ。

自分が是とする品質を提供できそうにないときや信頼を失うリスクが大きいときなど、最初の段階で断るという判断はすごく大事なものだと考えている。

T.I.D.E メソッド

著者が自身で編み出したギグエコノミーを活用して成功を収めるための方法論を頭文字を取ってこのように呼んでいる。この方法論を目新しくみえるか、そうでないかは読者の職種や働き方によって変わってくるように思う。

1. Taskify (タスク化する)
・仕事をタスク単位に分解する
2. Identify (特定・認識する)
・自分の手でやらなければならない作業、不要な作業、後回しにする作業、人に任せる作業を特定・認識する
3. Delegate (委託する)
・適切なエキスパートを見つけ、何をしてほしいかを伝え、仕事を上手に任せる
4. Evolve (進化する)
・進化を続け、ギグ・スタイルを自分のものにし、この手法を自分と自分の会社なりに活用する

個人的に、いま私は課題管理システムの目的と用途に大きな関心をもっている。そのため、本書の中でタスク化するというプロセス、著者のチームのエキスパートたちのインタビュー記事で語られるタスク化の内容についての箇所を私は興味深く読めた。

私にとっては当たり前のタスク化ではあるが、タスク化がうまく出来ていない組織にとって、タスク化が働き方を大きく変えるきっかけになったことがインタビュー記事から伺える。言い換えると、日々の業務をタスク化すらできていない組織やチームは生産性を大幅に改善できる可能性があることを示唆している。

著者は、T.I.D.E メソッドが優れていることを、ヘンリー・フォードがモデルTの組み立てに導入したライン生産方式に見立てて説明している。その前段で働く人たちの意識の変化について言及している。

「鶏が先か、卵が先か」のような話しだが、働き方を変えるには、働く人たちの意識を変えることが重要だと説いている。働き方が変わったことで働く人たちの意識も変わるだろうし、働く人たちの意識が変わることで働き方も変わるだろう。もしくはその両方かもしれない。

それにより、当時、熟練工がモデルN (モデルTの前機種) の組み立てに12時間かかった作業をライン生産方式の改善により、モデルTの組み立ては2時間半に短縮できたらしい。

過去に改善を目的として働き方を変えることだけに着目して提案したことがうまくいかなかったのは、働く人たちの意識を軽視していたのではないか。私にとっては示唆に富む指摘だった。

Taskify (タスク化する)

自分がやっている仕事、これからやろうと考えている仕事をタスク化することに慣れていない人は練習が必要になる。実際にやってみる以外にこのスキルを向上させることはできない。まずは調べものをタスク化することを身近で簡単な事例として取り上げている。

著者はタスク化において重要なものとして次をあげている。

・最終的な目的を自分でよく理解しておく
・自分の能力とその限界を認識する

前者は、複数の独立した小さなタスクをまとめて最終結果を得るには、その目的が大事であることを述べている。大きなタスクをサブタスクに分割していくようなトップダウンのアプローチでは自明かもしれない。解きたい課題が曖昧でわからないときは、小さなタスクからボトムアップで全体像を探索するようなときに役立つと思う。

後者は、自分のスキルが未熟な領域や苦手な作業などを認識しておいて、専門家に依頼することを言っている。

タスク化が会議の削減につながることも言及している。仕事の仕方改革で「オープンに仕事をする」でも述べられていたことを強調している。私も課題管理システムを使ったイテレーション開発の経験からこの内容を支持する。

アジャイル開発の1つであるスクラムでは、デイリースクラムという毎日の会議で情報共有するという施策で同じことをやっている。私がスクラムでの開発経験がある開発者たちにヒアリングした限りでは、課題管理システムを付箋紙の代わりに使っているだけだという。スプリントバックログアイテムと呼ばれるチケットにはほとんどコメントを書かない。日々の進捗は数時間から1日程度で完了するチケットを完了させているかどうかで透明性を測り、想定外の事態や遅れなどはデイリースクラムで共有する運用をとっている。

単純に効率だけの視点で比較すれば、会議で報告する内容をチケットに書き込み、それらを関係者が必要なときに確認して協調すれば、会議を開くことが不要になる。同じことを口頭で伝えるか (同期) 、文章で共有する (非同期) かの違いでしかない。まさに開発者の意識の違いとも言える。一方でチケットに自分のやっていることをうまく書き出せない人たちが一定数いることも私は知っている。書けない理由はともかく、そういった人たちを救うために会議を設けるというのも考え方としては理解できる。

Identify (特定・認識する)

タスク化ができれば、そのタスクを誰に割り当てるかを検討するプロセスと言える。当然、そのタスクを達成するスキルをもつ熟練した専門家を探す必要がある。

社員を雇う場合、多種多様なタスクを行う必要があるので、何でもこなせるゼネラリストを求めるとどの分野の達人でもない人になってしまう。外部のギグワーカーでは、独立したタスクを扱うだけなのでふさわしい人材を正しく特定する必要がある。

著者の経験から、プレゼンテーションのスライド資料を自身で作っていたが、そこそこの出来の資料でしかなかった。資料を自分一人で作るものと思い込みがあったが、外部の専門家と協働するようになって、計画的ストーリーテリングの重要性とデザインの力を思い知ったと述べている。

スライド資料という身近な事例においても、タスク化して外部の専門家へ依頼する余地があることが伺える。

Delegate (委託する)

著者はこのプロセスが最も難関であると述べている。最初のうちは失敗を受け入れて、試行錯誤しながら慣れていくしかないと言っている。「委託する」という単語だけをみてしまうと誤解してしまうが、このプロセスは委託した後のギグワーカーのマネジメントを含んでいる。つまり、著者が難しいと言っているのはマネジメントそのものを指している。

社員とギグワーカーの大きな違いの1つとして、タスクに示された期日を守るための進捗管理の大半をギグワーカーに任せることにある。ギグワーカーという働き方のメリットとして、自分のライフスタイルにあわせて仕事ができるという点がある。そのため、依頼側の都合で細かな進捗管理や報告を促すのは、ギグワーカー側の視点から望まれるものではない。

著者は、他者にうまく仕事を任せるスキルとして次をあげている。

1. 自分の最終目的を明確に伝える
2. 進捗を判断するための管理手法と中間目標を設定する
3. シンプルな進捗の報告や確認の手順を確立する
4. 何より、信頼する

会社という枠組みでは、企業文化をある程度、共有している社員とは異なり、外部の、もしかしたらほとんど人となりを知らないギグワーカーに仕事を任せることは、社員よりもずっと相手を信頼するという姿勢が求められる。原則として、自分のコントロールを手放すという覚悟がいる。

OSS (オープンソースソフトウェア) の世界では、機能拡張の提案をしたり、不具合を報告したり、ドキュメントを書いたりと、ソフトウェア開発のコミュニティを築く上で他者を信頼するという価値観が広く共有されていると言える。OSS 文化に慣れ親しんでいるソフトウェア開発者であれば、信頼のネットワークの強力さを実感している人も多いだろう。ギグエコノミーにおいても、信頼でつながる世界の価値観がさらに広がっていくのかもしれない。

小さなプロジェクトを繰り返すうちに慣れていき、さらに信頼できるギグワーカーのネットワークも広がっていき、うまくマネジメントできるようになるとある。

Evolve (進化する)

このプロセスは改善のスパイラルをまわしていくことを言っている。とはいえ、最も難しいのはその前段にあたる「委託する (マネジメント)」にあるので、ここまで来れば実践しながら改善をしていくだけでよいように読める。

問題の存在を認めることから始まる。

地道に小さな改善や進歩をしていくことを説いている。日本語でも「継続は力なり」という言葉があるので疑う余地はないだろう。

まとめ

本書の評価は読者によって賛否両論わかれるのではないだろうか。

著者の経験から成功を収めるための方法論を述べているが、ハイスペックな領域での成功事例に偏っていて、生存者バイアスが大きいように読める。T.I.D.E メソッドという汎用的な方法論を提案しているが、働き方としてとくに目新しいものではない。だからこそ、実用的で役に立つという点には私も同意する。

従来の働き方との大きな違いは、社員のみで構成されたチームやプロジェクトで働くのではなく、そこに外部の専門家を迎えて成功を導くには、なにかしら働く人の意識や働き方を変えないといけない、ということは確かであるように読める。では、何を変えないといけないかについて、本書の中で著者や著者のフリーランス仲間が話している内容が役に立つのだろうと推測する。

また本書にあるのは米国での事例である。日本ではどうだろう？少し前にヤフーが外部からギグパートナーを募集するといったニュースをみかけたことを思い出した。

このニュースをみかけた当時、私は特に関心をもっていなかった。ギグエコノミーに関する書籍を読んでみて、ギグの意味や背景を理解して、このニュースの意図する内容も (以前より) 深く理解できるようになった。

ギグエコノミーやギグワークといった働き方が広まっていくのか、それが良いものかどうか、私にはまだよく分からない。一方で本書を読んで言葉や背景の勉強になったことは確かである。

最後に著者のアドバイスで締めくくることにする。