メールの問題点と注意三万な集合精神
面白かった本について語るポッドキャスト、ブックカタリスト、第42回の本日は、「超没入!メールやチャットに邪魔されない働き方の正解!」について語ります。
はい、よろしくお願いします。
はい、お願いします。
今回は僕のターンなんですけども、この超没入というタイトルはあんまり心を惹かれなかったんですよ。
副題とあんまり関係なさそうですよね。
なんとなくイメージとして、いわゆるライフハック的な集中力を上げるためのノウハウが詰まった本なのかなと当初は思ってたんですよ。
で、著者を見た時に、カルニューポートって何か聞いたことあるぞと思って検索したら、デジタルミニマリストという本の著者の方で、僕の記憶が確かならデジタルミニマリストは確かにすごく良い本だったんですよ。
なんか結構流行ったというか、概念としていい、割と大きな影響を与えたようなイメージがありますよね。
なので、とりあえずちょっと見てみようかなということで、本屋さんで見かけた時にパラパラと中を見たら、あれ、ちょっと違う本やぞということで手に取ってみた次第で、読んでみたら面白かったので、今回紹介させていただくということになっております。
副題でいう、要するにメールやチャットをうまく使おうとか、どう付き合っていけばいいのかみたいなのがメインなテーマと考えていいんですかね。
おだしょー はい、そうですね。英語の原題がWorld Without Emailと、Emailのない世界っていうタイトルで、結構これはキャッチーというか、Emailのない世界を作ろうというような提言で、結構大規模な話をしているんですけど、別にEmailを使わないということではなくて、そのEmailに振り回されないワークスタイルを作ろうということを提案している本ですね。
おだしょー なんかそもそもで言うと、言ったらEmailから脱却しようって、なんかもう5年前ぐらいから言われているような印象はあるんですけど、元々は新しい本なんですかね。日本は2022年の5月って書いてあるんですけど。
おだしょー 現状も2021年ですね。
おだしょー じゃあもう分かってて、その時代にそれをやってるってことなんですね。
おだしょー そういうことですね。大きく2部立てになってまして、全7章なんですけど、前半第1部が、そもそもそのメールって何が悪いのかっていうのを考えるのが1から3章で、後半の2部がそれを確認した上で、じゃあどのような仕事の組み立て方をしたらいいのかっていうのを考えていくために、4つの原則。
注意手本の原則、プロセスの原則、プロトコルの原則、専門家の原則って4つの原則をそれぞれ具体的に紹介していくというのが大きな構成です。
おだしょー なんか構造がしっかりしている感じが。
おだしょー 非常に分かりやすいですね。とりあえずその第1部、メールの何かいけないのかということなんですけども、とりあえずその電子メールというのは、我々の世代にとってみたら、解放のツールというか、煩わしいことをしなくていいというふうに基本的には捉えられてたと思うんですよね。
おだしょー 最初の使い始めて5年までぐらいだったかな、そういう印象があったのは。
おだしょー 幸いなことに僕もゴリゴさんも組織人ではないので、おそらくメールをそれほど困ってないと思うんですけども、組織の中で働いている人はメール的なもの、チャット的なものに振り回されていると。
おだしょー よくマルチタスクの弊害みたいなことが言われますけど、状況はそんな名前やすいものではないと著者は言うわけですね。本書の第1部の主要なテーマになっているのが、注意三万な集合精神という、著者独自の用語なんですね。注意三万な集合精神。
おだしょー 注意三万もわかるんですけど、集合精神っていうのが若干わかりにくいと思うんですけど、どういうものかというと、会社とかチームとか部署とかでメールをやり取りしている。内緒はスラックなどのチャットに入っていると。何かあったらそこに書き込む。それを見た担当の人が受け取って返信するっていうことが、状態化している状態のことですね。
なので、例えばそこで仕事する人は、自分がメインでやっている作業を通しながらも、常にメールの受信箱なりスラックなりを、注意をそこに一定量必ず注いでおかなければならないと。なぜなら必要な情報は全てそこに入ってくるから。
となると、たまに入ってくるメールなりにマルチタスク化するとかじゃなくて、そもそもマルチタスクが仕事のプロセスに組み込まれてしまっているってことなんですね、これは。なんせその受信箱を放っておくわけにはいかないわけですから。
なので、細切れの作業時間しか取れないワークフローになっちゃってるっていうことを、著者はまず問題視してます。つまり、例えば僕がフリーランスでエディターで文章を書いてる、で、Twitterをつい見に行ってしまうっていうのとは違うわけですね。
まあ、Twitterはそうですよね。クラスターさんが能動的に現実を逃れるために見に行く方ですよね。
だから、これはまあ脱線ですけど、言ったらワークプロセスそのものから外れてるわけですけど、著者が問題してるのは、そのワークプロセスそのものの中に集中させない、集中できない環境が出来上がってしまっていると。つまり、メールを常時見ることが仕事の仕組みになってしまっていることが問題だと言ってるわけですね。
メールを見ないと仕事ができないし、メールを見ていなかったら仕事をしていないということにされてしまう。
あるいは、その人がメールを見ないことで他の人の仕事が止まってしまってるような状況になってしまってると。
多分、そっちの方がやばいんですよね。
だから、ここを解決しない限り、例えばメールを素早くチェックしようとか、メールを見るのは午前中にしようって言っても、結局何も変わらないと、著者は言うわけですね。
仕事の進め方そのものが受信箱経由、内緒スラック経由の進め方でなってたら、結局人はそこに向かってしまうから変わらないっていう。
だから、まずそこを変えていく必要があると。
仕事の組み立て方を考える
メールっていうのは仕事の進め方の一つの象徴的な存在であって、別にメールじゃなくてチャットでも一緒なんですけど。
電子的な情報の非同期的なんだけども、結局高速でレスポンスを求められるものと常時接続している状態で仕事が進んでいることがまず問題であると。
なんか、すごい良いなと思って。何て言うんだろう。ライフハックじゃなくて、もっとちゃんとシンクロアゲインして考え直そうという。
ライフハックでは対応しきれないんですよね。
これまでのライフハックだったら、メールを高速で処理するとかって言って、結局メールの根本は変えずに入ってくるものを処理しよう。
自分をちょっと変えて対応するだとか、やり方でしか対応できなかったけど、そうじゃないですね。
そうそう。組織の働き方そのものからリシンキングしていかないとダメだっていうことなんです。
だから、このテーマ性が僕は面白いなと思って本集をちょっと紹介しております。
この問題提携ができた時点で、なんか勝ちな感じがする。
確かに。そもそも、なぜそんなに仕事のワークロールに電子メールっていうのが中学になったかという、一つの著者にとっての仮説なんですけど、
まずシンプルで柔軟に使えると。メールっていうものはどんな仕事でも使えるじゃないですか。当然のように。
多分そのやりとりコミュニケーションにおいて最も有用なツールと言えるのかな。
しかも文章を書く力があれば誰でも使えますよね。広く。つまり学習コストがほぼゼロに近いんですよ。
メールアドレスを使うことを覚えれば、例えばチケットシステムの発行の仕方を覚えるとかってあるじゃないですか。
でもそんな、そういうのを全く新しいツールの使い方を覚えずに、メールが使えればある種のコミュニケーションなしのタスク管理に参加できてしまうと。
さらに多分どんな職業でも通用するスキルですよね。
だからメール自身が持つ柔軟性とナレッジワーカーがすぐに使える仕切りの引き差っていうのがまず電子メールが有用に使われている非常に重要な理由であると。
これがメリットなんですけど、デメリットはさっき言ったように誰かが受信箱を確認するのを怠るとメールが返ってこないからその間作業が遅延してしまう。
作業が遅延してしまうのが困るから結局みんな積極的に受信箱を見ざるを得ない。
つまり集中が必要な作業が分断されてしまう。時間が細分化されてしまうということが一つ問題と。
もう1個は大規模になると破綻すると。
2、3人であればメールを返した仕事もおそらくは有用だろうと著者は言うんですけど。
30人ぐらいでCCカーボンコピーをつけてメールをやり取りすると、自分に直接関係ないものまであの人にも送っておこうかみたいな感じでメールが送られてしまうと。
メールっていうものの敷居の低さ、送りやすさ、低コストさが必要のないメールを発生させたり必要な人までメールを送ってしまうことが生まれると。
これを精神がタフな人は見ないっていう選択は多分できるんですけど、著者はここで人間が社会的動物であるという点を指摘するわけですね。
見ないわけにはいかない。
コミュニケーションを阻害しそうだからコミュニケーションからはぶられるってことは理性では別に大したことないと思っても、社会的本能がそれを非常に重要なこととして捉えてしまうと。
だからメールの受信箱で通知欄がピッてきたら放っておくわけにはいかないと、システム一致的に。
これが人間のこっちのその性質があるからメールを使って30人でメールをやるとしまうと、もうみんなメールの虜になってしまうっていう状況があると。
この辺が大体1章2章あたりの過去にですね。
私たちがなぜメールを使ってるのか、そのメールがなぜ問題なのかっていう点。
これは僕はそこまでメールに仕事を支配されてないんで実感はないんですけど、おそらく会社組織ではこういうことになってるんだろうなとはちょっと思います。
メールの使用方法の問題と社会的動物の性質
企業組織からメールが来ると、10中8区2名以上のCCが含まれていて。
俺はそれを返信にCCを含めるべきなのかどうなのかも、考えずにdefoで返信ボタンを押して何も操作しないということを積極的に選んでるんですけど。
中間管理職の人はめんどくせえだろうなっていうのをすげえ思います。
ああいうメールが常に入ってきて、自分に直接関係あるものからほとんど関係ないものまで受信箱があふれかえて、それの処理することに作業時間の多くが使われているっていうことは、そりゃ生産性が低くなっても当然だよねという話ですね。
生産性が低いだけじゃなくて、メンタル的にもよろしくないと。
そういう仕事が常に受信箱をお気にしているような精神状態っていうのはやっぱりストレス負荷になるから幸せにもならないだろうという指摘もあります。
本社では上手いコミュニケーションのやり方も提案されてるんです。ライフハック的なことも提案されてるんですけど、前半の主な問題提起としては、組織の中で電子メール、ないしはチャットによって、常時接続でコミュニケーションしていることがおそらく問題だろうと。
それをそのような形に、つまり全体として見たら、明らかに非効率的なコミュニケーションになっているのに変わっていないのはなぜかということも一応考察してまして。そこで彼はドラッガーを引いてるんですよ。ピーター・ドラッガーを。
原点に戻るみたいな感じですね。
ドラッガーはマネージメントを問いた人で、彼は特にこれからの社会ではナレッジワーカー、知識労働者が主役になる事態だろうと。知識労働者の管理、マネージメントは工場労働者のマネージメントとは手法、考え方が異なるぞと言われまして、それは何かというと彼らの仕事の仕方そのものを管理することはできないんだと。
そうですね。
作家に文章の書き方をいちいち言うことはできないのと同じようで、アイディアを考える人にどんなアイディア、どんな風にアイディアを考えたからいいかっていうのも言えないと。
知識労働者の仕事の仕方とワークフローの改善
だから知識労働者っていうのは、その仕事の仕方のそれぞれを裁量を与えてあげなければならないと。これを細かく管理するんではなくて。だから、逆に知識マネージメントは一人一人がエグゼプティブタントと、自分自身を管理する管理者でないといけないっていうことを説いて、僕もそれはそう思うんですけど、その考え方が実は罠になってるんではないかと著者は言うんですね。
で、先ほど言ったメールとかチャットによる即時制から逃れるためには何をしないかといけないかというと、ちょっと不便になることを受け入れないといけないですね。
で、例えば僕がこの情報を聞きたいBさんにメールを送る。可能であればすぐ帰ってきてほしいですよね。すぐ帰ってきてくれるシステムは好ましいと感じるじゃないですか。でも、それを受け入れると今度は僕にやってくるメールをすべてに返信することを受け入れるわけじゃないですか。
自分がやってほしいことを人にもやりましょうってことですよね。
彼が言うには、知識労働者が自分の仕事をするための方法論はもちろん彼らに裁量に任せてるけど、仕事をどう割り振るのかアサインするのかというのは、実は彼らのマネジメントの裁量じゃなくて、それを管理者で一括して決めて、彼らに仕事のやり方をこの方法で仕事を受け取って、その中身はどう進めてもあなたが勝手ですけど、
その成果物をこの方式で返してくださいっていうことを決めなければならないって言っているところが、大体第一部の前半です。
この視点は確かになかったなと思います。
僕自身も知識労働者って、人から言われない方がいい仕事をすると、管理されない方がいい仕事をすると思っている立ちですけど、言われてみれば確かに、そういう非効率の罠からは抜け出せないだろうなと思いますね、これは。
ダーウィンエコノミーを思い出したりしていて、個々の生物が自分にとって最善なことを求めてしまうと、全体にとっての効率が落ちてしまって、その種族全体にとって不幸になってしまう。
メールがそれと同じことになっているっていうのは、だとすると、進化論的にはどこかで止まってくるはずなのか。
どこかで止まってくるか、その人がメールでの仕事に耐えられなくなって辞めるとか、あまり好ましくない終わり方をするわけですね。
だからあれですね、何らかの管理をする政府がもっと大きくなれっていうのと同じで、上司が権限をもっと持った方がいいってことなんですよね。
メールやチャットによるコミュニケーションの問題点
だから仕事の、作業の管理かな。仕事を遂行するものではなくて、仕事をアサインする割り振る管理はちゃんと管理者に返してあげた方がうまくいく。むしろそれこそが管理者の仕事と言えるかもしれないですけど。
まあそうですね、中間管理職と言われる役目がそこを円滑に進めるところにある。
だから管理者がその管理を放棄して、それぞれ好き勝手やってくださいって言うと全体効率がひどく悪くなってしまうと。だからある程度強制的に、このツールの使い方ちょっと面倒かもしれないですけど、覚えてくださいということ自体は全然悪いことではないっていうことですね。
何らかのルールもあったほうがいいぐらいな言い方ってことなんですかね。
おそらくそういうことだと思います。例えば電子メールが使えるようになりましたってなったときに、おそらくですけど、これ今までなかったテクノロジーが我が社に入ってきた、新しいワークスタイルを検討しようってやったとこ多分どこもないと思うんですよ。おそらくは。
どうなんだろう。そこは確かに経験してないから想像できないですね。なかなか。
おそらくです。なんとかさんに質問があったら、その隣の席の人に喋りかけるのと同じ程度で使ってる感覚ですね。おそらく。
だから、会話を投げかけるのがリアルの1人だったりですけど、それが30人とか40人になってしまって、つまり新しいツールの適切な使い方を検討せずに、おしゃべりの延長線上として、延長線上じゃない、おしゃべりの代替としてメールが使われていると。それは破綻して当然だろうなと、著者は言いたいわけですね。
そうですね。30人、隣の席の人がいる状態になってるってことですよね、たぶん。
だから、それをメールからスラックに変えたところで、結局そのコミュニケーションのやり方とワークフローのやり方が変わっていないのであれば、問題は結局そのままというか、おそらくメールからスラックだったらより悪化すると思うんですけど、その問題っていうのは。
なんかこの2,3年は、そうですよね。明らかにそのスラックの方がやばくなって、むしろもうちょっとゆっくりなメールにしようっていう流れがある。
ちょっとニュアンスが必要なやり取りをする場合って、そのメールの往復がめちゃくちゃ多くなって、結局まとまらないっていう話で。何回か出てくるんですけど、直接会ったほうが早いっていう話なんですね。同じ会社で働いてるから。
なんか戻ってきた感じですね。それは。
わかる気がする。
やってもやらなくてもいいけど、できたらやっておいてぐらいのものが全てメールやったら気軽に遅れちゃうから、タスクとして発生してしまったと。話しかけるっていうハードルの高さが生まれたことで、常識がタスク化するものがそこまでもハードルが生まれて、タスクの数が減ったと。
だとしたら一体メールは何を生み出しているのかということが、著者にとっては疑念になっているわけですね。
おだしょー プルシッドジョブを作り出すノートになっている。
そうそう。簡単なコミュニケーションを取れることは必ずしもいいことではないし、例えば僕らのように全然違う場所で時間帯で働いてる人にとっては非常に喜ばしいことですけど、少なくともこの本の中では同じ組織の中で働いてる人間で、例えばリモートワークじゃないとして、そこまで歩いてその人に話しかけるんであれば、その人に話しかけに行ったほうが絶対いいと。
おだしょー やっぱりよく言われますけど、さっきの話にも通じるんですけど、テキストだけでやり取りするのと、こうやって喋るのでは言葉外コミュニケーションが、ノンバーバルコミュニケーションの質が違うじゃないですか。
で、その微妙なニファンスを伝えるために文字を書く訓練してる人は少ないわけで、そうするとやっぱり誤解が生じるわけですね。テキストだけやと。で、誤解が生じることをテキストのやり取りが増えて、で、手間がかかると。
一言ちょっと喋りに行ったら解決するようなことが、むしろ増えちゃってると。会議とかでも、確かに会議を集まるコストは減ったけど、それと同じことをメールでやったら、その会議の時間以上の時間がかかった上に、むしろ話が全くまとまらないようになってしまってると。
だから、テキストだけでメッセージをやり取りする訓練がほとんどされてないのに、それを主要なコミュニケーションとしちゃってる罠もあるわけですね。
さらに言えば、もう多分人間の本能には根付いていない機能ですもんね。テキストでのコミュニケーションというのは。
これは徹底的に訓練した人たちなら成立するけど、会社一般のコミュニケーションとして言い出るのは、結構いろいろ問題あるぞということの問題定義が前半でされてます。
ここはおそらくそうでしょう。書いていることは派手に誇張されていることじゃなくて、おそらく現実の社会で起こっていることだと思います。
ちょっと思ったのが、リモートワークが進んでくると、もっとこの問題は大きくなってくるんじゃないかという気がして。
僕が見聞きするところって、例えばアジャイル方式とかスプリントってありますけど、2週間に1回テーマ決めてっていうようなやつですけど、
ああいう時はビデオ会議するところが多いですね。週に1回か2回は顔を合わせてリアルでしゃべるっていうことをやってるところが多いです。
普段のやりとりはチャットとかで済ませているんですけど、週に1回ぐらいはリアルタイムで顔を合わせるってことを自覚的にしてるところが多くて、
やっぱり会って話すことの強さっていうのは、そこで実感されてるんじゃないですかね、きっと。
少なくとも、そういう集まる時間を定期的に取らないとチームとしてはうまくいかなさそうな感じはしますよね。
そこはやっぱり、どれだけデジタルで高速で進んだとしても、僕らが人間である、つまり社会的な動物であり、基本的に言語は後付けのものである生物からするとやっぱり物足りないんでしょうね、やりとりが。
おだしょー だから、やっぱ効率ではないしコストではないんですよね、コミュニケーション、無駄なコミュニケーションと思われるものも。
無駄、実際には見えないメリットがあったと。テキストにすると、すげー効率的やって言うけど、見えないコスト分を支払うことになっちゃってるよと。
注意と洗練された生産工程の重要性
それを積み重なってきて、今になってると。僕らっていうか会社人のコミュニケーションがメールに最適化されてしまってるので、結構大掛かりになたを振らんとなかなか変えられへんぞっていう問題提起ですね、本章は。
この辺が前半で、確かに言われてたらそうやなっていうところを確認した上で、当然問題提起だけじゃなくて、どうしたらいいのかっていうんで、4原則が紹介されてますので、一個ずついきますけど。
注意し方の原則というのが一つ目で、原則を読み上げますけども。知識産業の生産性は、人間の頭脳が持つ情報に継続して価値を付け加える能力を、これまで以上に最適に活用できるようなワークフローを確立することにより、大幅な向上を望めるという原則です。
おだしょー 言葉ではね、大幅な向上を望めるしかわからなかった。
例えば、ナレッジワークではない例を著者は挙げてるんですけど、T型フォードの例を挙げてるんですけど、自動車ですよね。それまでは人が車の周りを回って作業をしていたけど、フォードは人を止めて車のほうを動かすという新しいラインの作り方をしたと。
それによって、技術労働者の技術を発揮できる時間を増やしたわけですね、当然。動き回る時間がなくなって、ずっと作業してられるようになったと。これは知識労働ではないけども、車を作ることそのものはT型フォードとそうじゃないのって変わってないわけじゃないですか。新しい車の作り方をしたわけじゃないじゃないですか。
車の構成部品とか構造自体は大雑把には一緒で。
ワークフローそのものを変えただけであくまで劇的な売り上げと生産性を生み出したと。この点に注目しようと著者は言ってるんですね。だから知識労働者も同じだと。
ワークフローとかプロセスそのものを変えて、僕らが頭をうまく使えるようにすれば、知識労働における生産性っていうのは上がっていくと。
だからメールを5倍早く処理するとかではなくて、どうやって集中してある物事にあたる考え事をするとかっていう時間を確立させてあげると知識労働の生産性は上がるぞっていうのがこの一つ目。
注意資本の原則。つまり僕らにとって頭脳労働を動かすその注意が資本なんだってことですね。
本文と内容がなんか自分の中であんま繋がっているような気がしなかったんだけれども、注意という資本を最大限に使えるワークフローを考えようというイメージですかね。
そうです。だからあんまりこの辺でもまだちょっとタイトルが違うようなという感じはするんですけど、イメージとして知識労働者をうまく働かせる方法ということですね。要するに全体としては。
何か劇的な方法があるんじゃないか。それが何って言っているわけではない。
具体的にこういういくつか例は挙げてますけど、少なくとも今の形は違うだろうと言ってますね。そりゃそうですね。
それが一つ目の原理で、二つ目の原理が肯定の、漢字で言うと肯定の原理、カタカナで言うとプロセスの原理なんですけど、
洗練された生産工程のナレッジワークへの導入は業績を大幅に向上させるとともにストレスを経験すると。
さっき言った話の具体的な功能ですね。洗練された生産工程っていうのがどういうものかっていうのは難しいところなんですけど、いくつか例が挙がってまして、
ある動画制作の会社ではメールを一切使わないと。ある人は教材の、学習用の教材の動画を作ってる会社なんですけど、ある人は台本を作る。
ある人は動画を撮影する。ある人はそれを編集する。ある人は音声とか字幕を加える。それぞれ役割決まってると。
工程表がスプレッドシートでまとまってて、それがドロップボックスに入ってると。各自はそのスプレッドシートを見ると。
仕事の効率化
自分が作業したらそのスプレッドシートの新着を変えて、作業したファイルをドロップボックスに上げると。
新しいファイルが上がってきたら次の人がやると。ただそれが毎日繰り返されてるだけ。
メールはどこにも発生しないっていうワークフローが紹介されてます。
おだしょー めっちゃ普通な感じがしたんだけど、やっぱそうじゃなくなるってことなんですね。
大平 そうじゃない。
おだしょー 普通は。
大平 普通はそうじゃない。普通はその間に全てメールが挟まってくるっていうパターンが多いですね。
これはかなり極端なとこなんですけど、もう一個よくあるというか、よく導入しやすい例として、トレロが上がってるんですね。
おだしょー あれあれば確かに消せるというか、メールをいらない。大幅に減らせるかもですね。
これまでトレロっていうツールを見たときに、いわゆる看板式やんだなと思ってたら、それほど劇的な感じは受けなかったんですよね。
別にタスクリストでいいじゃんってずっと思ってたんですけど、この本を読んで気がついたのは、
普通のメールでやり取りしている企業の人たちって、例えば次の作業何やったかなっていうときに、今までのメールを読み返すところから始まるらしいんですよね。
CCが20件あって、目的のメールを見つけて。
おだしょー 見つける。で、この作業を担当している関係者は誰かっていうのを探して、またその人にメールして進着を確かめるみたいなことをするっていうことが書いてあって、
確かにそれと比べれば、トレロは確かに今どんなタスクがあって、そのタスクに誰が関係してて、今どんな進着かっていうのが一目瞭然やなと。
で、その2つは確かに劇的に違うよなと思ったんです。
おだしょー もう神ですね、ツールとしてはもう。
だから、ライフハッカーとしてはトレロなんてもうちょっと前のツールぐらいの認識ですけど、
そのトレロを使うことでメールやり取りをなくすっていうワークフローの改善がもし行われたとしたら、生産性は多分2倍とかでは済まへんやろうなと思いますね、これは。
おだしょー そうか、興味深いのが本当に実例でその人がどのぐらいの時間メール見てるか計測してほしいですね。
そういうデータもちょっとあって、ある企業から生産性拡大のために各自がどんな作業をしているのかっていうのを確かめたものがあって、
やっぱりその分断してるのがやっぱりメールらしいです、メールのチェック。
で、どういうメールの種類かっていうところも合わせて確認すると、どんな種類のメールでもらしいです。
やっぱりメールを読むと気がそれる。気がそれるといったらコンテキストをスイッチするために認知資源が使われて、結局作業があんまり進まないっていう。
おだしょー ただ時間だけじゃないか、そのスイッチの切り替えっていうエネルギーが結構あるから。
だからもうクタクタに使われてしまうと、やっぱりでもまとまった時間30分でも45分でもまとまった時間バッと集中したときに、
細切れで作った2時間とやっぱり成果が全然違うのは僕も感じてるんで。
だから企業の中で言うと、そのワークフローの作り方っていうのは、学習コストが各従業員にあったとしても、覚えてもらったほうが絶対いいよなとは思います。
おだしょー そうか、取れろか。確かに言われてみると思いつく限りの一番簡単なやつは取れろかもしれないですね。
大平 そう、1回慣れたら簡単ですし、やっぱりビジュアルでわかるじゃないですか。視覚情報で。あれは結構強いですよね、人間にとって。
おだしょー さらにアイコンで誰がここにいるかわかって。そのよくできてるツールですね。
大平 僕からしたらそんなに革新的ではなかったんですけど、やっぱりチームで仕事をしたことがほとんどないからっていうことなんですね。
おだしょー 多分2人だったらいらないんですよね。4人とか5人から。
おだしょー 5人とかになってきたときにやっぱり必要になってくる。それぞれが今何してて、どんな感じでそれを続けて誰に聞いたらいいのかっていうことがわかるっていうシステム取れろっていうのがいいよなと。
プロトコルの重要性
あとさっき言ったチケットシステム。問題が起きたときに担当者に直接連絡するんじゃなくて、チケット発行システムのメールを投げたらナンバーのチケットが発行されましたと。
もし新着が気になった方はこのチケット番号でシステムを検索してくだったらこんな状況になってますってわかってるっていうレッドマインやったかなっていうようなチケットシステムも紹介されてて。
これも僕からしたら普通やなと思ったんですけど。それでも逆に言うと、例えば中小企業とかのパソコン担当の人は4,6時中多分メールが来てて。
サーバーの立ち上げ直しとかっていう時間がかかるような作業って多分永遠にできないんだろうなとはちょっと思いました。
レッドマインなんて多分見た目だけで拒否理想な。
でもそうやって考えるとエンジニアがやっている方法というのが結構学べるところが多そうですよね。
結構そういうSEとかエンジニアの人がよく使ってるツールが言及されてますね。
GitHubとかも違う。ここでは違うかもしれないけど、やっぱ使ってみるとすげえなってなりますからね。
その辺やっぱり自分が使う道具を自分で作れる人たちっていうのはやっぱ強いですよね。そこは。
そういうことに積極的な人たちなので相当進んでいますよね。単純に考えれば。
やっぱり最先端を進んでて、いわゆるナレッジワーカーと言われる人たちはその5歩後ぐらいを歩いてるから。
日本企業で本当にナレッジワークしてる人たちがどれぐらいいるのか僕にはわかりませんけど、
真剣にそういう仕事をしようと思ったらやっぱり細切れの時間では絶対足りず、ある程度まとまった時間を作っていくっていう方向性を持って会社をデザインしないといけないだろうなと思います。
今から企業を作る人は逆に言えばそこがしっかりできれば割とそれだけで勝てるかもしれない。
知識労働者でも会社に仕事をさせてもらってないっていうような不満をTwitterでもよく見かけますけど、やっぱりそういうところあるじゃないですかね。
知識労働者の使い方を知らないっていうことですね。
一般的に年上の人たちほどパソコンへの親しみは低いですからね。
うん、確かに。やっぱりそこを頑張ってもらわない、そこに合わせると破綻するよなっていうことですね。
3つ目の原則がプロトコルの原則で、これがまあまあ面白い話なんですが、
例えとしてモールス信号が出てきたんですよ。
とんと2っていう、言ったら01デジタルで、あれもとんとんとかって組み合わせたら何でも表現できるわけじゃないですか。
で、例えば8個続けたら、2の8以上やから、196ぐらいまで、256はどっちかな、そのぐらいまでいけると。
例えば1から200までの数字に1個1個とんとんを割り当てていけば、全ての数字が表せることになると。
ある仕事をする人がいて、その人はある一定時間ごとにメーターを監視すると。
その値をモールス信号で相手方に送信するという仕事があるとすると。
普通に設計したらさっき言ったように、全ての数字に8桁のとんとんを割り当てると。
だから毎回その仕事ごとに8桁を送信するわけですね、普通にデザインしたら。
でもその仕事が仮にメーターの異常を確認する仕事で、大半はゼロやったとしましょう。
異常が出た時に数字が出てくるという時には、例えばとんやったらゼロやと。
で、2やったらゼロじゃないってして、その2の時に後で続けて8桁の番号を言えると。
そうすると全体の送信コストというか送信数って激減しますよね、最初の場合に比べて。
回数8分の1を何回繰り返すかですからね。
でもその異常事態やった時を見ると送信する桁が1個増えてますよね、9桁に。
で、この違いに注目せよと著者は言うわけですね。
この9桁で増えてるやんっていうことをコスト増にとらわれると、さっき言ったような最適化ができなくなると。
だって8桁の方が短いじゃないですかって言われてしまうと。
8回に1回より頻度少なければもう勝てますからね。
そうそう、実際はね。
で、こういうところ、つまり最初にとん2を与えるっていう、とん2、このゼロかゼロじゃないかを入れるっていうのがある種のプロトコルになってるわけですね。
で、プロトコルっていうのは規約じゃないですか。
このメッセージをどう送るかっていうルールをそのメッセージの中に加える。
つまり、若干単純から複雑に言ってるわけですね。
でも、そうするとコストが下がるんですね。
ここにジレンマがあるんですよ。
一般的にルールを決めない方が簡単なように見えて、実はルールを決めた方が簡単になるっていう。
おー、これもそしてまたエンジニアというかインターネットまんまですよね。
このやり方も。
だから、例えばですけど、自由いつでもメールを送ってくださいよりは、この時間からこの時間を送ってくださいと決めてしまうっていうプロトコルもありますし、要望は150時以内にまとめてくださいでもプロトコルになりますし、それは職場で決めてもらったらいいんですけど。
何でも自由じゃなくて、あるルールを決める。
で、そうすると送る側にとっては制約になったりとか、さっき言ったように手間が増えるけど、全体のコストとしては絶対に下がるっていう話です。これがプロトコルの原則。
これはいいですね。すげえいいですね。言われて思ったけど、まさに今のMoles信号の送信だけにしても送ると受け取る。2人だけでも毎回8の仕事しないといけなかったのが1ですんで。そのルールが例えば午前中はメールしてはいけませんとかでもいいかもしれないし。
で、例えばその障害が起きたときに、例えば使っているパソコンの名前を入れてもらって状況を書いてもらってっていうんですけど、自由文じゃなくて、ある種のテンプレートに沿って送信してもらったら受け取り側はすごい楽じゃないですか。
おだしょー よくありますし、しかも送る側も分かんない人ほどそのフォーマットがないと分かんないですからね。
このコミュニケーションのコストを極大化してしまうんで、ある種のプロトコルを定めた方が全体のコストは下がるという話があって、これは多分僕ら単独で仕事してる場合でも多分言えることだろうなとはちょっと思います。
あと、プロトコルの原則という言葉が納得が深いというか、それはその通りだって感じですね。
ここは結構職場だけじゃなくて、仕事の仕方そのものにもきっと関係してるんじゃないかなというところがあります。
専門家の存在
最後、四つ目。専門家の原則なんですけど、一応読み上げると、ナレッジワークでは取り組む仕事の数を減らし、一つ一つの仕事の質を上げて結果に責任を負うことが精査性を大幅に向上させるための土台になり得ると。
一見当たり前の話なんですけど、ここで問題となっているのはパソコンなんですよね。パソコンってありとあらゆるソフトアプリケーションがあって、いろんな業務ができますよね。
だから、一人のナレッジワーカーがあらゆる業務を生半可にできてしまうんですよ。
たぶん大学教授が一番あれだと思うんですけど、あらゆる雑用をさせられてるわけですね、彼らは。
講義とか研究に関係ない事務処理をだいたい一点に引き受けてるわけですよ。それはなぜかというとパソコンがあればできるからなんですね。
本来すべきでない仕事すらもパソコンはできるようにしてしまったと。
なので、新しい専門家を一人雇うぐらいだったら、その知識労働者にやらせときゃええっていう短期的なコストの考え方になっちゃうわけですけど、
結局そうすることによってその知識労働者の知識的生産性が落ちてて、全体の生産性がすごく悪くなってしまってるっていう状況があると。
一見短期的にコストになるけど事務作業をする人を雇ったほうが、実はその作業の全体的な結果としての生産性が上がるっていう話がここに続きます。
ちょうど最近ブルシットジョブの原本を手を出して読んでいて、
分かっててあえて言うんですけど真逆のことを言っているんですよね。
そういうふうに専門家が増えたことによって、いらない仕事が生み出されて、
専門家によってやらなくていい仕事が増えてしまった。
官僚機構で特にそう言えますし、事務作業をする人がいるおかげで事務作業がなくならないということも間違いなくあるんですけど、
でも現実的に今事務作業をしている知識労働者は事務作業をするために雇われたわけではないということを考えたら、
過剰な状態を減らした後にさらに減らすと行き過ぎかもしれないですけど、
だからブルシットジョブの想定はたぶんまだその真ん中ぐらいの段階?
ある程度事務作業が減った状況だったらいいんですけど、明らかに過剰に仕事をしている状態なんで。
だからレイヤーが違うというか高さが違うというかね、その分業の。全然分業できてない。
考えている話のレイヤーが違うみたいなことはおっしゃる通りで分かる上で、安易にそれだけではないよなっていうことを思ってしまって。
でもやっぱり知識労働者の仕事時間に、彼でもなくてもできる仕事をさせるというのは非効率ですし、
その非効率さが単純に非効率だけじゃなくて、さっき言ったようにいらない作業をすることによって集中力が妨げられるという問題。
これをどれぐらい重く見るかですね。
個人的にはプロトコル原則によって専門家原則はかなりなくても済むんじゃないかみたいなことを思ったんですよね。
報告がゼロに済むことはやっぱりあり得ないと思うので、デスクワークを100%ゼロには絶対できないと思うんですよね。
たとはいえ、無駄なデスクワークが過剰にあるというのは、お役所と絡むような書類とかを書いてみるとよく分かるので、非常によく分かって。
それはでもプロトコルが改善すれば、ほとんど90%以上は解決するのではないかという気がして。
なるほどね。その辺は会社の実態に合わせてということなんですけど。
もちろんそうですね。
でもやっぱり専門家には、なるべく専門家の作業をさせてあげようという考え方そのものは、
特に日本の場合は一人の人に多様な仕事を押し付けることがあるので、これは結構意識した方がいいかなと。
要するに、さっき言ったナレッジワーカーの業務、彼が行う業務の遂行と、全体のワークフローっていうのを分けて考えようと。
最初にした話。
ワークフローそのものが、専門家は別に触らなくていいし、専門家は自身の庭の中で最大の材料を発揮してくれたら、それで仕事ができるはずやというところで、全体的な4つの原則と。
これらの4つの原則を踏まえた上で、その効果的な生産工程に共通する特徴というのが3つ挙げられてまして。
作業ごとの担当者と進捗の確認
1つ目が、作業ごとの担当者と進捗を容易に確認できること。
その2が、散発的なコミュニケーションが最小限でも作業が進むこと。
3つ目が、工程の進行に合わせて担当者を更新する際の手続きがあらかじめ決められていることという3つがありまして。
これは会社組織の話なんですけど。
まず1つ目、作業ごとの担当者と進捗を容易に確認できるという話なんですけど。
ゴルゴさんのタスクマネジメントでこれはできてますかね?
誰が何をしているのかを、進捗と担当者が簡単に確認できるようになってます?
奥さんと一緒にお仕事をすると、全然上手にできません。
1人ならできる?
1人ならすごくよくできる。
進めているプロジェクトの進捗を簡単に確認できます?
言うならば、そこをちゃんと分かるようにしないといけないと思って、今ちょっとずつ改善されつつあると思っているんですけれども。
少なくとも今年の成果で言うと、今までの成果で言うとできていない。
これ結構難しいんですよね。
毎日やっているような作業って別に進捗とか管理しなくてもいいやろうと思って、結構適当にやってしまうところがあって。
それだと多分、効果的な生産工程になってないかなと、この本を読みながら反省してたんですけど。
具体的な手順で言うと、最近はそれを原稿などなどGitHubで管理していて、やることリストというテキストファイルをちゃんと作って、まめに更新するという方法で、前回にも失敗しているんだけれども、次回は同じ失敗をしないようにしようとしているところですね。
前回の失敗はどんな失敗ですか?
ほぼ同じことをもう一回やっています。
中長期に渡って、例えば本を作るとかって3ヶ月4ヶ月かかって、1回目の最初にやったことを忘れてしまうんですよね。
そういう意味で言うと、作業ログを残すだとか、次回仕事を始めるときに前回の反省点を踏まえるという仕組み作りができていない。
というところを、今は自覚はできているけど、次始めたらどうなるか。一応、前よりはマシになっていると思うんですけど、自信はないぐらいですかね。
だから、ワークフローの確立そのものがなかなか難しいところはあるんですよね、これは。
これは組織向けに書かれている本で、生産工程に共通する特徴も組織向けに書かれているんですけど、
挙げられたその3つの特徴のうち、特にその先ほどの担当者と進捗を容易に確認できるかっていうのは、おそらく個人にも言えて、
ここに先ほどプロトコルの原則が多分効いてくるんですけど、タスクの書き方とか進捗の書き方もプロトコルを定めたほうがいいんだろうなと今は考えているところなんですよね。
大きな意味でのプロトコルでいうと、例えば自分の場合、GitHubの導入というのはすごく良かったと思うんですよね。
GitHubとGitHub内のテキストファイルでの進捗管理。
言ってみたら、GitHubで何かをやった場合に、メールでプッシュ通知が来るだとか、GitHubのアプリケーションから基本毎日触っているので進捗が分かるというところもあるけれども、
GitHubをどうやって使うかというルール決めでいうと、全然足りてないと思いましたね。
たしかにね。
例えば、コメントの書き方?
そもそもコミットメッセージをどういうルールで書くかって、自分がまずルール決めれてないんですよね。
だから書き方も日本語にするか英語にするかも決まってないし、
どういうことを中心に、それはもちろんIT業界でのお作法というのはあるとは思うんですけど、それは別にして、
執筆作業におけるコミットメッセージの書き方とかも全然プロトコルがないし、
結構、図3。自分も含めて図3っていうのをちょっとこの本を読んで感じて、
何か組み立てていったほうがいいんだろうなと今思っているところですね。
自分だけのことで言うと、最近はログシークを作業ログとして重視するようになったおかげで、
中期プロジェクトみたいなものは、やっと毎回きちんと言えるかわからないけど、
毎回ちゃんと前回、今回何をやったかを残せるようになったんですよね。
これは目に見えてやっぱり結果を変えてくれているというか、
土日やらなかった間に忘れていることも記録から戻れるし。
そう、それ重要ですよね。やっぱり作業記録をつけてないとスッて抜けるんですよね、あれ。
忘れることは得意になってきていて、先週やってたことは、もうお仕事おしまいの時間になると頭から完全になくなるんですよね。
それは素晴らしいことですけど。
そうそう、それはいいことだと思うんですけど、そうすると次がどこかに書いてないと何も思い出せない。
確かに。
やっとそこは個人レベルでならできるようになってきたかなっていう。
それも作業記録を取るっていうのは単純に、短期的に見たらコストなわけじゃないですか、手間なわけじゃないですか。
完全にコスト増ですね。
でも長期的に見たときに、それが助ける生産性の高さっていうのがあるわけであって。
だからやっぱり長期的な、あるいは一歩下がった視点で見ないと、なかなか作業記録を取ろうっていうだけでは進まないと思うんですよね、これ。
GitHubの導入と作業記録の重要性
どうやったら取れる、なぜ取れるようになったんだろうか。
取れるようになったのかっていう、ここが多分一つポイントで、個人でもチームでも、今までになかったテーマを絶対発生させることになるわけで。
この導入式をどう超えるのかっていうのは本書では提案されてないですけど、それができたときのメリットを最初に提示できたら多分いいんでしょうけど、なかなか難しいだろうなと。
むずいですね。どうなんだろう。エンジニアの人たちは基本的にはそういうことに対して積極的な人率が高いですもんね。
確かに、そうそう。でも会社全般で言うとそういうわけでもないから。
そしてそうじゃない人をやる気にさせないと意味がないんですもんね。
そこら辺が多分導入においての一番の問題で、現実的に進んでいないのもそこら辺が問題なんだろうなと。
例えばの話で言ってGitHubを親しくない人に導入してくれなんて無理だろうなと思っているので。
すごく便利なことは、よっぽど特殊な業務でない限り便利だと思うんですけれども。
でもよっぽど仲が良くないと一緒にそれでやろうぜって言えないっていうのも思って。
そうやね、確かにね。あれね、自分も分かるんですけど、やったらめっちゃ簡単なんですね。
でも、やろうと思う難しさがあって、実際やったらいくつかのコマンド叩くだけで済むし、
それもそんなにたくさんのコマンドを全部網羅する必要なくて、3つぐらいコマンドを覚えたら大体なんとかなるんですけど、
それでも特有の誓いがたさっていうのが最初はありましたね、僕も。
さらに言うとコマンドなんてなくて、アプリを使えば大体できるので。
ただ、分かってないと特に衝突が起こったときにどうしようっていうことになってっていう。
難しいですね。というか、衝突が起こってもいいから使えるということが本来はメリットなんだけど。
確かにね。でも慌てるよね、きっと。なぜプッシュできないのとかそういうことになって、後々慌てることはありそうよね。
でもそういうとこを地道に乗り越えていかんといけないっていうのはあるでしょうね。
そうするっていうことが、さっき言ったその注意三万な集合精神のワークフローから逃れる。
そこから逃れられたら別にどんな実装してもいいけど、常時接続でメールでやり取りすることからとりあえず何とかして脱出しようっていう意気込みが結構必要かなと。
そうですね。ライフハックになってしまうんですけど、自分の場合午前中はメールとかを来ようが何だろうが見ないようにしているだとか、そういうことはやっているけれども、組織レベルでもそれを考えないとなんでしょうね。
一つのルールとしてそれをして、そうして各人の時間を守ることが大切なんだよっていう職場の文化にしていかないと、なかなか知識生産者の生産性っていうのは上がっていかないんだろうなと。
だからそこが別に一つのやり方を押し付けるのが正解とは限らないので、ある程度話し合って進める必要はありますけど、さっき言ったように個々の労働者にとってメールでやり取りするのが一番簡単で楽だという点は認識しておかないと、結局そこに落ち着いちゃうよなと。
おだしょー だから受け入れられないのか。自分は不便にしかならないから。
そうそうそう。圧倒的に自分は不便にしかならないから買いにくい。会社に入ってメールじゃないものを最初に使ってたら多分それはそのままいけるけど、もうメールというところにその位置に落ち着いちゃってるから、抜け上がるためのパワーがないというか。だって面倒だもんだから。
そこを染み付いちゃってるメール文化をどう乗り越えるのかっていうところで、結構おそらくは大胆な提言が必要になるでしょうね。実際の中では。
おだしょー 大抵の場合はトレロで解決するんじゃないかということを結構見てて思ったんですけどね。聞いてて。
結構そのトレロとかそのテノンを導入して、ここに情報を集めましょうってことをちゃんと言えたら、わりかし解決、解決というかその良さがわかってもらえるかなという手間の価値があると思ってもらえるかなという気がしますね。
おだしょー うん。なんかね、うち家族でね、ゴールデンウィークに家の片付けプロジェクトみたいなことするときとか、トレロとか便利で。
なるほど。
効率化の落とし穴
おだしょー やっぱこれをいつやる。ちょっとやり方が特集ではあって、横軸を日付とかにしてたんですけど。
おだしょー この日にこれをやる予定で、誰がやる予定でって二人なんだけど、その資格化しておくだけでも、ガートチャートとかでもいいかもだけど、トレロの方がそんな難しいことをしなくていいちょうど良さはやっぱトレロにはあって。
おだしょー やっぱり片付けとか引っ越しとかっていうふうに、明確にタスクになるものを扱う上でトレロはすごく優れてるなとは感じますね。
おだしょー その執筆作業ってそこまで明確じゃないんで。だからその辺のツールの使い分けはあるにしても、逆に企業のプロジェクトの場合ははっきり性格物を定期的に上げていかなあかんのが使命なわけで。
おだしょー そういう意味ではトレロ的なのの方が役立つかもしれないですね。
おだしょー 家庭の導入っていうのは結構個人レベルの話なんだけれども、テストとしてはいいかもですね。
おだしょー 確かにね。あれは本当に万人に分かりやすいもんな。
おだしょー スマホアプリでも触れるから一覧はしづらいけど、すごいですね確かに。
おだしょー とりあえずその全体を通して僕が一番印象に残ったところが、序盤にも出たんですけど、能率が上がれば成果も上がるという考え方に慣れている頭には、物事を要因すると問題が生じるという因果関係は納得しにくいかもしれない。
おだしょー しかし私のような技術者の間ではこの概念は広く共有されているとかあって、確かにーって思う。
おだしょー これはちょっと僕がこの本の中で一番ああそうやなっていうこの能率が上がれば成果は上がるとは限らないし、物事を要因になれば問題が生じるっていうことを理解しておかないと、効率化って変なとこに行くよねとは思います。
おだしょー そのやっぱ自分の中のメインテーマなんですけど、効率化は必ずしもいいことではない。
おだしょー どころか多分自分の脳内で言うと効率化というものはむしろ警戒した方がいいんだぞぐらい最近は思うようになっていて。
おだしょー 効率化を必要としている状況そのものを変えた方がいいことが多いですよね要するに。
おだしょー うんうんうん。
おだしょー 目先の効率化で片付く問題って一番大きな問題を無視してる可能性があるので。
おだしょー でもそうか。だから効率化という言葉に何か間違ったものがあるような気がするな。
おだしょー なるほどね。なるほど。
おだしょー 効率化は目的にはそぐわないか。
おだしょー なるほど。
おだしょー 目標に対してしか有効に機能しない。
おだしょー なるほど。まあそうか。目的に対しての機能を担保しない。
おだしょー 目的に対して必ず機能するとは限らないから。目標への有効度しかない。
おだしょー 確かにそれはその通りだと思う。
おだしょー だから定期的に目的に対して機能するかを確認しない効率化は変な道に曲がってしまってそのまま迷子になってしまうということが起こるということだよね。
おだしょー 結構この本省が提示してる問題はアメリカだけではなくて日本の企業でもそうで特にIT企業じゃないナレッジワーカーの企業の人たちは共感する話も多いんじゃないかなというのはちょっと読んでて思いました。
おだしょー タイトルだけなんでこれなんやろうって。
ツールとプロトコル
おだしょー これちょっと結構わからないんですよね。ビジネス風に仕上げたかったんかもしれないけどタイトルのメールのない世界へとかってほうがよりインパクトがあった気がするんだけどなというのがちょっと印象でした。
おだしょー そこはアームチェアクォーターバック商工軍かもしれないのであんまり我々が言うことではないかもしれないけれども。
おだしょー そうだね。なんかノウハウ書として読まれそうですけど実際はさっき言ったように職場のワークフローそのものを変えようという大きな話ですし、
メールなりチャットなりと僕らがどう付き合っていけばいいのかっていうところを考える一冊にもなってるんで結構猶予度が高いし個人で働く人にとってもなんか考えるさっき言ったプロトコルとかっていうのはなんかヒントになりそうな一冊でした。
そうかビジネス書よりも射程が広く思想書に近いぐらいの何かがあるんですねきっと。
おだしょー 思いますね。ビジネス思想っていうかそういう感じですね。だから前も終わりにも言いましたけど知識労働者とかデジタルツールがどう働くかっていうことを正面から論じた本ってほとんどないんですよね。
ドラッガーは確かに知識労働者これからは知識労働者の時代だとかそのマネジメントができないっていうことは言いましたけど具体的にどういうワークフローで働いたらいいのかっていうところはあんまり深くは検討してない。
基本的にドラッガーの中ではセルフマネジメントの問題なんですね彼にとっては。それぞれの人がどう働くかが問題であって職場の話はたぶん二の次やったんですよ彼の著作を読んだ限りでは。でも実際そんなわけはなく絶対コミュニケーションっていうのが発生して仕事の割り振りっていうのも生まれる以上そこのデザインについてようやくこういう本で議論されるように。
つまりITツール書ではないところでこういうITツール書の話がITツールの話が出てきたのかなっていう感じです。
大平 そうですね当たり前だけどドラッガーさんは多分パソコンがある時代に仕事をしていないわけですからね。
寺田 一応パソコンは若い頃はなかったと思うけど。存命中はパソコンはあったと思うけど。
大平 まあパソコンじゃないか。常時接続インターネットというのか。
寺田 常時接続インターネットそれはほとんどなかったでしょうね。それの中でスラックでみんながメッセージやり取りする状態を見てないと思います。
大平 そこを予想してねそれまで何か考えるというのはちょっと無茶なことですからね。
寺田 実際だからそんな風に使われるとは電子メールも思ってなかったでしょうし。
メールの柔軟性の高さが問題でさっき言ったように定型的なプロトコルを与えないと暴走してしまうっていうのが絶対にあるので。
でもそれは結局ITツール全般に言えることで。Twitterとかもそうですよね結局。
寺田 そうか汎用性が高いことが良いことじゃないって難しいですよね。エヴァノートの話にしたってエヴァノートはプロトコルが少ながらがいいんですよね多分。
寺田 少ない。ユーザーが好き勝手に使えるけどそうなるとこのツールって結局なんやねんっていう問題が出てしまうと。
寺田 でもプロトコルに縛られているツールでクリエイティブなことができるかと言われると難しい。それはそれで違うような気もするし。
寺田 だからやっぱり仕事任務の達成のためにはプロトコルはいらなくてコミュニケーションにおいてプロトコルがいるっていうことかな。
寺田 そうかそういう風に考えればいいのか。だからエヴァノートをみんなで使うにはプロトコルが足りなさすぎる。
寺田 その場合は共通なルールを自分らで作らなければいけないっていうことやと思いますねきっと。
寺田 スクラップボックスもみんなで使うにはプロトコル少なすぎるからやっぱ難しいんですよね。何もルールがないところで。
寺田 だから自分たちでそこに付与していくっていう。ルールそのものは付与。ルールっていうのは要するに僕らの心の中にある種の名文化された命令なわけやから。
あとで付け加える。機能じゃなくて僕らの中の暗黙ルールで付け加えたらいいわけで。そこは別に後付けしたらいいかなという気はしますけども。
寺田 スクラップボックスでガイドラインみたいなのを作ったっていうのもプロトコルだなということを持って。
寺田 そういうことですね。まさに。
デジタルミニマリストの視点
寺田 一生ですね。本質で言うと。
寺田 ああいうところは現実的にそういうことの実例や実際理やなと思いながら読んでました。
寺田 これはいいですね。すごいですね。やっぱさすがデジタルミニマリスト著者というか。
寺田 そうそう。いろんな広い視点から。やっぱり名のない世界でっていうとメールを使わないっていういわゆるラッダイド運動的なものを想像されがちですけど。
寺田 そういうわけじゃなくて、常時メールを確認しないといけないというちょっと神経症的なものから離れましょうと。そういう仕事の働き方っていうのを作っていきましょうっていうことを提案している本ですね。
寺田 なんかいいですね。これはこういう本がちょっと増えてほしいなって思いました。パッと聞いて思いつかないのでなかなか。
寺田 そうそう。
寺田 デジタルとその生き方、働き方をどう付き合っていくのか。How toではないレベルでのその考えを教えてくれる本。
寺田 結構だからいい本やなと。もちろんその具体的なノウハウもさっき言ったようにそれらの話とか出てきて役に立ちますけど、一つ上の視点から働くっていうのは知識労働者にとっての成果っていうことを考えている本だなという感じですね。
寺田 うん。これはいいですね。ぜひ皆さんもメールどのぐらい大変なのか、そういうのは我々体験していなくて知らないので。
寺田 ほとんど知らないですからね。CCに巻き込まれた経験ってちょっとぐらいしかないんで。日常ではないんで。たまにプロジェクト的に巻き込まれるだけであって、普段は1日メール5通ぐらいしか処理しないんで。5通も処理せんかな。だからメール状況っていうのは分からないですけど、でもきっとそうなってるだろうなと思いますね。
寺田 うん。ので、もしそういうご意見ご感想体験談などありましたら、Twitterのハッシュタグ、シャープブックカタリスト、もしくはメールで届くお便りフォームなどで教えていただければありがたいです。ということで、今回もお聞きいただきありがとうございました。
寺田 ありがとうございまーす。
