2019/04/02

不正確さは他人の仕事を増やす

前回のエントリでは、人に何かを頼むときは、事前に互いの認識を揃えましょう、という話をしました。

今回はそれを疎かにした場合に起こる認識のズレがどれほどのコストを生むのか、というお話です。

ところでみなさんはよく、作業が早いだけでその人を優秀な人と判断していないでしょうか？

エンジニアの仕事に例えると、タスクを振ったらすぐにプルリクエストをあげてくるような人です。

それを受け取った依頼者は「もう終わったの。さすがだねぇ」みたいに言うわけです。

この時点ですべての仕事が完了になるなら「さすが」です。

しかし内容を確認してみると、コメントが全く無かったり、コメントがあっても雑でよく理解できなかったりで、相手にいろいろ「ここのこれってどういうことなの？」みたいに更に確認が必要になったりします。

さらに、バグがあったり、仕様とは違った実装だと発覚すると最終的にリジェクト(却下もしくはやり直し)になったりもします。

こうなってくると、プルリクエストの時点でほぼほぼ完了だと思っていたのが、進捗率0%の振り出しに戻ってしまいます。

確認に手間取ったり、再提出となると作業者のコストも依頼者の確認コストもどんどん積み重なっていきます。

ここで、それぞれのパターンにおけるコストを図示化してみていきましょう。

まずは、普通のスピードで作業を行い、提出物が一発で通った場合です。

この時の作業者のコストを100、確認者のコストを10ぐらいと見積もると、トータル110のコストでタスクが完了します。(図1A)

次に、仕事の早い人がいて、半分の50で作業を終わらせたとしましょう。

しかし、成果物の内容のすり合わせなどが必要になり、互いに更にコストが発生した場合が図1のBです。

トータルではコストが低くなっていますが、作業者が倍の成果を出しているかと言われると、そんなことはなく、トータルで1.3倍ぐらいの成果です。

しかも、確認者のコストを余分に使っているので、第三者の労力をスポイルにした成果ともみれるわけです。

そして、やり直しとなると普通の速さで作業したときよりもコストが増えます。(図1C)

しかも、その分のコストは自分ではなく他人になるのです。

ここからさらに確認作業が長引いたり、やり直しとのダブルコンボになったり、それらが複数回発生してくると、無限にコストが増殖していきます。(図1D)

作業者が正確に仕事を行い、確認者に対して分かりやすい状態まで準備をしてからバトンを渡してあげれば、少なくとも確認者のコストを最小限に抑えられます。

自分ひとりの仕事がいくら早くても、それが雑なアウトプットであれば、チェックする側だったり管理する側だったり、利用する側の人が無駄なオーバーヘッドを強いられるのです。

そして最終的にチーム全体としてのコストは膨らんでしまい、全員の仕事時間をすべて足すと想像以上にコストが膨らんでいた、ということは往々にして発生します。

タスクにまつわる人と時間が増えるほど、他者に可能な限り無駄な時間をかけさせないことに価値が生まれるのです。

長期的には自分の仕事を速く終わらせるより、他人の仕事を早く終わらせるようにするほうが価値が高いのです。

自分ひとりだけだと一人分の時間の節約にしかなりませんが、他の人の時間も節約できるなら、最大でチーム内にいる人数分の時間を節約できます。

ですので、作業の速さよりも正確性を求めたほうがチームとしては早く作業が終わるようになるのです。

2016年のリオ五輪で日本が400メートルリレーで銀メダルをとれたのは、まさにこの理屈による成果です。

個別の実力では他国の個別選手のほうが圧倒的に上でしたが、連携時の無駄なコストを可能な限り削減し、チーム全体としてのタイムを一番短縮できたのです。

バトンをうまく渡すことによって、次に走る人のアウトプットを最大限引き出せた上での結果なのです。

ウサイン・ボルトが第一走者だったら日本が金メダルを取れていた可能性すらあるほど、個人の実力以上に他人のオーバーヘッドをなくすほうがチーム戦においては価値があるのです。

そこで次に、作業の質が後の作業にどのような影響を与えるかを分かりやすく図にしてみました。

作業には時間がかかったが、その後の影響度が少ない場合が図2のEとなります。

最初に作ったシステムから機能の追加や改善タスクが増えていっても、改修コストを低く抑えられます。

限られたコストの中で沢山の改善タスクを回せます。

次に作業が速くても、その後の影響が大きい場合を表現したのが図2のFです。

雑な作業の結果が後に関わる仕事すべてに影響を及ぼし、限られたコスト内でみると、先ほどよりも改修できる作業の数が減ってしまいます。

そして現実では関わる人が増えるほど、改修が繰り返されるごとに、エントロピーの法則により作業に対するコストは上昇していきます。(図2G)

これが一般的に言う技術的負債です。

エントロピーの法則に可能な限り抗うためには、雑に早く作業するよりも、少し時間がかかっても丁寧に作業を行うほうが良いのです。

以上のとおり、一人の仕事が早かったとしても、その仕事の結果が後に与える影響まで考慮した場合、生産性が低くなるケースはまれによくあると分かりました。

目に見えないコストは他にもたくさんあるので、人が協力してうまく仕事をこなしていくのは大変ですね。

2019/04/01

等しいのスコープ

「これとこれは同じ」という認識であるとき、その「同じ」がどのレベルで等しいかは文脈によって大きく変わってきます。

ミートアップ後に軽い立食パーティーがあって、紙コップにお茶を注いでみんなに配る場面を想像してみましょう。

そのお茶が「烏龍茶」だろうが「緑茶」だろうが「麦茶」だろうが、基本的に「お茶」として配ると思います。

最初は烏龍茶のペットボトルで注いでいたのが、途中でなくなってしまい、新たに緑茶のペットボトルを買い足して緑茶を配るようになっても、基本的には同じ「お茶」として配ると思います。

この時、烏龍茶も緑茶も大枠として同じ「お茶」の扱いになります。

烏龍茶が途中で緑茶に変わっても、出されたお茶に対して「さっきと違う！」といって騒ぎ出す人はほとんどいないでしょう。

いたらキチガイなので、そっとその人とは距離を取るようにしましょう。

提供側もお茶の種類の違いをそこまで気にする人はいないと思います。

上記の例だと、烏龍茶も緑茶も「お茶」として一緒、という扱いにまります。

次に、普段冷蔵庫に麦茶をストックしている家庭を想像してみましょう。

その家庭で子供に「いつものお茶買ってきて」とおつかいを頼みました。

その結果、烏龍茶を買ってきてしまったらどうでしょう？

もちろん「違うお茶」として扱われ、返品に行かされるか、その場は怒られてしぶしぶ烏龍茶を冷蔵庫に突っ込むことになるでしょう。

同じ「お茶」という括りでも、状況によって一緒と扱われたり、扱われなかったりします。

今回想定した2つの状況は、比較的、一緒にしてよいかダメなのかが分かりやすいですが、状況によっては互いに認識をしっかり合わせないと「一緒」にしてよいかどうかの判断が難しい場面もあります。

例えば、スーパードライを常飲する人があまりビールに興味のない部下にビールのお使いを頼んだとしましょう。

頼んだ人は「あいつとはよく飲みに行くし、自分はいつもスーパードライ頼んでるからスーパードライ買ってくんだろ」とほぼ無意識に思い込んでおり、頼まれた側は銘柄の違いに無頓着な人で「特売で売ってる適当なやつでいいや」と思って金麦を買ってきました。

頼んだ側は「ビール＝スーパードライ」の認識でしたが、頼まれた側は「金麦∈ビール」ぐらいの認識でした。

なんだったら金麦は厳密には「ビール」ですらありません。

この場合、頼む側はしっかりと「ビール」ではなく「スーパードライ」という商品名を提示しておけば、ちゃんと自分の飲みたいビールを買ってきてもらえたはずです。

「こうと言えば当然こう受け取られるだろう」という思い込みは、我々が普段仕事をする上でも割とよく発生しており、その結果起こる伝達不備により、大なり小なり様々な問題が日々発生し続けています。

ビールの例で見たように、特段意識をしない限り「自分の解釈と相手の解釈は違うんじゃないか？」という懐疑心を持つことはありません。

日常会話レベルであれば、多少齟齬が発生しても大きな問題にはなりませんし、話のテンポの方が大事だったりもするのであまり気にしなくてもいいですが、仕事上の話になってくると、これが積もりに積もって最終的にはデスマーチを生み出したりします。

ですので仕事上でしっかり仕事を進めようと思ったらまずはじめに、言葉が持つ解釈のスコープ(範囲)を互いに同じ認識になるようにしないといけません。

この作業をドメイン駆動設計ではユビキタス言語と言ったりします。

ドメイン(仕事の領域)において、関係者みんながある言葉に対して同じ認識を持つことは大事なことです。

複雑な仕事をつつがなく遂行するためには、ビールという言葉を漠然と大きな括りとしてのビールという認識のままで運用するのは危険なのです。

みんながビールをスーパードライだと認識している間はいいですが、ある日、ある人が「え？サッポロ黒ラベルじゃなかったの？」という日が来ればプロジェクトに火が燻りはじめ、いずれ炎上していくでしょう。

バカみたいな例えですが、炎上案件もこういった小さな齟齬が積み重なって最終的には取り返しのつかないところにまできてしまうのです。

こうならないために、最初に「我々の間ではビールといった場合、スーパードライのことを指すようにします」という認識合わせと明文化が必要なのです。 (ちなみに、スーパードライにも複数の商品があるので単一の商品を特定できませんし、350mlか500mlなのか瓶なのかといったより細かい分別が可能ですし、そういったより細かいレベルまで認識合わせをする必要もあるでしょう)

さて、「一緒」や「等しい」には、各人の間で認識のズレが存在し、人によっていろんな解釈の仕方があることが分かりました。等しいと等しくないの境界線は意外とボヤけているのです。

「等しい」という簡単な言葉をしっかり運用しようと考えるだけでも、

１．人によって言葉の解釈が違うことを認識する

２．言葉の解釈を明確にする

３．その言葉の解釈を相手に認識させる

といった手順を踏まえた上で、やっと「等しい」が「等しく」なるのです。

「等しい」という基本的な言葉ですら多様な解釈が存在するのに、仕事上ではさらに多様な言葉が跋扈し、解釈の違いを生みだし、表現・伝達の難易度を上げています。

人と人との間で認識を統一するのは、実はとても大変なことなのです。

ついでにいうと「等しいとはなにか？」と自問する能力はプログラミングにおいてもとても大切な姿勢です。

プログラミング上にはたくさんの「等しい」という概念があります。

「1 == 1」という評価式があった場合、それが

オブジェクトが表現している値が等しいのか？

オブジェクトのクラスの型が等しいのか？

オブジェクトの中身(メモリ上のビット配列が一致している)が等しいのか？

オブジェクトの実体自体(メモリ上の同じ番地を指している)が等しいのか？

といった様々な可能性を考えることができます。

そして実際に手を動かしながら「この式だとこの条件で等しくなる、このレベルまでの等しさを比較するためにはこうやって書かないといけない」といった学びを得ていくのです。

こういった自問力がバグを未然に防ぐ実装力を身につけさせ、また、バグを解決する糸口となる知識を授けてくれるのです。

2019/03/12

コミュニティにおける約数束縛論

(※今回は割と強引な理屈になっていますが、書いている本人もその認識はあります。ちょっとした思考実験だと思って読んでください。)

コミュニティが発生すると、自然と似た者同士の人たちが集ります。

似た者同士が集まれば、その集まりの中で交わされる話題は自然とコミュニティごとに偏った内容になると思います。

医者の集まりであれば医療業界の話で盛り上がるし、エンジニアの集まりであれば技術的な話で盛り上がると思います。

医者の集まりでVim対Emacsの論争は起きないですし、エンジニアの集まりでムンテラについては語り合わないでしょう。

電子カルテあたりの話題ならそれぞれの集まりで話題として登場するかもしれません。

このようにコミュニティの属性によって、その集まりの中で交わされる会話には一定の「偏り」が発生します。

コミュニティは、似た者同士が集まりやすく、さらにそこでの情報のやり取りが所属する集団に依存するので、人々の持つ「情報」はどうしても偏ってしまいます。

そこで、このエントリではコミュニティ内で知識の偏りが発生する現象を数値を用いて説明していきます。

まず、仮にですが、個人ごとに、その人の知識を数値として表せるとしましょう。

そして、「6のAさん」「12のBさん」「36のCさん」の3人がいたとします。

さらに、それぞれの人が話題に出せる内容をその人の数値の約数だとしましょう。

この約数が個人ごとの話題の「偏り」を表現してくれるレトリックとして機能します。

さて、さっそく各人の約数を並べてみましょう。

Aさんは「1, 2, 3, 6」

Bさんは「1, 2, 3, 4, 6, 12」

Cさんは「1, 2, 3, 4, 6, 9, 12, 18, 36」の話題を扱えます。

そしてこの3人が集まった場合、「最大公約数6」のコミュニティである、と言えます。

このコミュニティにおいて全員が共通で話せる話題＝公約数となるので、当コミュニティ内においては「1, 2, 3, 6」の話題を出せば所属メンバー全員が盛り上がって話せる内容となります。

BさんとCさんは「12」の話題も扱えますがコミュニティ内のコミュニケーションとしては基本「6」までの話題しか出しません。

さらにいうと「4」の話題もAさんには扱えないので自然と「4」の話題も扱われません。

Cさんは「36」で、一番大きい数値で知識を持っており、さらに最大9つの話題を取り扱えます。

しかし「最大公約数6のコミュニティ」内ではそのうちの4つまでしか披露できません。

コミュニティ内の一人が深く多彩な知識を持っていたとしても、そのコミュニティ内の他の人がその知識と邂逅できるわけではないのです。

コミュニティ全体のコミュニケーションが円滑に行われる限界が、所属するメンバーの「最大公約数」に束縛されるからです。

ですので、コミュニティ内に、数値の高いとても教養の深い人がいたとしても、その知識の深淵に触れられるわけではないのです。

さらにです。

このコミュニティに「49のDさん」が加わったとしましょう。

数値だけで判断すると、Cさんよりも更に高い数値なので、よりコミュニティに多様性と話題の多さを提供してくれるのではないか、という期待が持てます。

しかし、大半の読者の方はもう気付いていると思いますが、49の約数は「1と7と49」しかありません。

こうなった場合、コミュニティ内の最大公約数は「1」という最低値になってしまいます。

これは最初のエンジニアの集まりでVim対Emacsの話をしている最中にお医者さんが入ってきたようなものです。

そうなると、そのお医者さんも含めてコミュニティ内で会話をしようとすると「今日は暑いですね」みたいな当たり障りのない日常会話にせざるを得ません。

すべての(0以外の)自然数は「1」という約数を持っているので「1」の話題は挨拶レベルの日常会話だとみなすことができます。

今回の例えでは、エンジニアが「6」の倍数の知識体系で、お医者さんが「7」の倍数の知識体系を持っていると捉えられます。

もしDさんが「14」や「28」のいる人のコミュニティに入れば「7」までの話題で盛り上がれ、多少は専門的な話題も扱えます。

ちなみに、冒頭の話に出てきた電子カルテの話題は6と7の倍数である「42」の話題だと例えることもできます。

この約数論を前提にした場合、コミュニティの所属要員が「偶数＞奇数＞素数」の人たちの順にコミュニティの組成確率が下がっていきます。

人が一番集まりやすいコミュニティが偶数コミュニティで、人が一番集まりにくいコミュニティが素数コミュティとなります。

個人の数値の高さより「偶数・奇数・素数」という素養で所属できるコミュニティに差が出てきます。

なんといっても素数コミュティだと、その分野で何かを話そうと思ったら自分と同じ数字の人を連れてこなければならないわけですから。

例えるなら、サッカー好きの集まりが偶数コミュニティで、タスポニー好きの集まりが素数コミュティです。

「3571のEさん」は所属できるコミュティの数で「6のAさん」に負けるのです。

数値の大きさだけをみると圧倒的に「3571のEさん」さんが良さそうに見えますが、「6のAさん」さんのほうが世間を渡りやすいのです。

こう例えてみると、素数の人はいわゆる「変わり者」として世間に馴染みづらい、悲しみの運命を背負った人たちだと言えます。

自分と同じ数値の人と出会わない限り世間話ぐらいしか人と合わせる話題がないのですから・・

2019/02/06

コンテキストスイッチとタスク分割コスト

ある作業をしている途中に割り込みが発生して別の作業に切り替える、ということは仕事上よくあります。

フロー状態でプログラムを書いているところに電話がきて強制的に集中状態が途切れてしまったり、障害が発生して緊急的に調査タスクが発生し、その対応が終わった後に、もともとやっていた自分の作業に戻ったりする時、脳内メモリが一度リフレッシュされてしまいます。

A作業からB作業に切り替わる際、それぞれの作業で必要な情報や思考は別物なので、別の作業に取り掛かるために必要な情報を脳内メモリにリロードする必要があります。

ここでの脳内メモリのリフレッシュと再割当て作業による頭の中の切り替えをコンテキストスイッチと呼びます。

そして、このコンテキストスイッチは当然オーバーヘッドが発生します。

仮にAとBのタスクがあり、それぞれ50の労力が必要だとします。(図の灰色枠)

AとBのタスクをそれぞれ最初から終わりまでまとめて処理できれば、純粋に合計100の労力で終わらせられます。(図1A)

しかし、Aのタスクの途中でBのタスクもこなそうとした場合、コンテキストスイッチのオーバーヘッドにより合計100以上の労力が必要になります。(図1B)

Aのタスクが複雑であればあるほど「切り替えコスト」の数値は上がり、Bのタスクが途中で差し込まれると労力がどんどん膨らんでいきます。

特に「フロー状態」を崩されると再度フロー状態に持っていくのに時間がかかるため、より切り替えコストが掛かるようになります。(図1C)

「フロー」という言葉の意味が分からない人はここでは説明しないのでググるか無視してください。

各単体のタスクごとのコストだけをみて見積もりを出したとしても、その作業の必要集中度によって、割り込みが発生した際の作業者の負担はどんどん膨らんでいく可能性があるのです。

個人の頭の中だけでもこれだけマルチタスク処理にオーバーヘッドが発生するのですから、これがさらに複数人の作業になってくると、いよいよオーバーヘッドファンタジーが始まってしまいます。

先程のAとBのタスクを10人で振り分けてやったとしましょう。するとどうなるか。

単純計算だと合計100の労力で終わるので一人あたり10の労力で済む計算になります。

ところがどっこい、そうは問屋がおろしません。

それぞれの「10」の作業を繋ぎあわせたり、前任者までの作業内容を確認したり、伝えあったりするにもコストがかかります。

自分担当分の実作業をこなす以外にも多大なコストがかかるようになります。

結果、実際のタスク自体の作業コストよりも分担したことで発生したオーバーヘッドのコストのほうが高くなり、トータルの労力が一人で完結させた場合の倍、もしくはそれ以上になってしまいます。(図2D)

またAとBのタスクを並列して5人ずつで作業を行ったとしても一人で完結させるより時間がかかってしまう可能性すらあるのです。(図2E)

後半の話は『人月の神話』に似たことが書いてあるので興味があればぜひ読んでみてください。

作業と作業の間には可視化されていない作業がたくさん潜んでいるのです。

2019/01/15

錯覚の科学

この本の簡単な要約というかメモです。興味を持ったら読んでみましょう。

視覚の錯覚

これは見逃すわけはない、という思い込み。

この錯覚の実験に使われたのが原書のタイトルである"The Invisible Gorilla"です。 ハチに刺されたらその痛みで蚊に刺されたかゆみは感じなくなる、みたいなやつです。違うかもしれません。

記憶の錯覚

強く印象に残っている記憶は絶対正しい、という思い込み。

過去の思い出は美化される、というやつです。違うかもしれません。

自信の錯覚

自信があることと、それが正しいこととは比例しない。

意識が高いことと実際に成果を出すことはぜんぜん違う、というやつです。そのとおりです。

知識の錯覚

それが扱えることと、それについての仕組みを理解していることとは別。

ものを扱うのに必要なのは知識ではなく使い方です。 「使い方」という概念は日常では「知識」として扱われません。 テレビの視聴や録画予約、スマホの使い方、新幹線のチケットのとり方などは知識というよりかは教養の範疇です。 そういった意味で錯覚というよりかは言葉の定義のあやふやさが悪いだけかもしれません。

原因の錯覚

相関関係に因果関係を見てしまう錯覚。いくつかの事実の間に隙間を埋めて前後の因果関係を作り上げる。

地球のCO2濃度が増えると温暖化する、というやつがそうです。相関関係はあるようですが因果関係はまだ証明されていないはずです。因果が逆で温暖化によりCO2濃度が上がっているかもしれないですし、そもそもその2つの現象はなんの関係性もないかもしれません。

可能性の錯覚

あるトレーニングを行い、その成果範囲を拡大解釈してしまう錯覚。

数独をすれば数独を解く能力が向上するだけで、別に頭の回転自体が速くなるわけではありません。 「筋トレが最高のソリューションである」も可能性の錯覚だったと最近は思い始めています。