仕事も家事もリンパ流し！つまり（ボトルネック）を解消して生産性UP！#07
毎日、仕事に家事に育児にと、忙しい私たちの身体は疲れもたまりやすいですね。
ちゃんとケアしていますか？
今回は、身体ケアの中でも、私が最近気になっているリンパマッサージを例に、仕事などの生産性を上げる方法を紹介します。
といっても美容の話ではなく・・・このnoteはプログラミング思考がテーマなので、とりあげるのは「デバッグ」です。
リンパマッサージしてますか？
リモートワークが続いているせいか、最近は身体の浮腫（むくみ）が気になって仕方がありません。
なんとなく身体が重く感じたり、疲労感が抜けないのは浮腫のせいかな・・と思い当たることがたくさんあるので、最近はYouTubeで自分でやるリンパマッサージを紹介している動画をよく観ています。
リンパマッサージというのは、身体の細胞などから出てくる余分な水分、老廃物などを、体中に張りめぐされているリンパ管を通じて外に出しやすくするためのマッサージです。
身体のめぐりが良くなるので、免疫力を高めるのにも有効だと言われます。
余分な水分や老廃物はリンパ液という液体と一緒に運ばれるのですが、このリンパ液がうまく流れないとつまってしまい、身体に不調が出やすくなります。
このつまってしまう箇所は、関節の近くにある「リンパ節」というところです。
主なリンパ節は、首や肘、鼠径部（そけいぶ）などにあるので、この辺を上手に刺激してあげると、つまっている老廃物が流れてスッキリする、というわけです。
仕事におけるリンパ節とは間違ったやり方をしているところ
リンパ節には老廃物がたまりがちで、リンパの流れが悪くなると身体に不調が出やすくなる、という話と似たようなことが、私たちの身近でもおきています。
たとえば、駐車場などで発生する渋滞がそうですね。
近所にあるショッピングセンターは平屋で、わりと広めの１階駐車場と、建物の上にある屋上駐車場があるのですが、週末になるとひどい渋滞を引き起こすのです。
出入り口が全部で３箇所あり、駐車スペースもかなりあるので、一見すると問題があるようには思えません。
でも、実際に車が敷地内に入ると、絶望的に動線がイケてないことが分かるのです。
３箇所ある出入り口でそれぞれ、入る車、出る車が交差する形になり、1階の周遊スペースには上りと下りが合流する箇所がいくつかあるため、車同士が向き合うたびに、どちらかが止まらなければいけません。
これはひどい・・・
そのせいか、広さのわりに交通整理をする係の人の数が多いように感じます。
仕事においても、似たようなことがあると思います。
稟議をあげるためにワークフローをまわしても、忙しすぎる上司Aのところでいつも止まってしまい、承認されるまでに時間がかかってヤキモキするとか。
部下Bに急ぎの仕事をお願いしても、いつもタスクが溢れかえっていて優先順位がつけられず放置されてしまうせいで自分の仕事がなかなか終わらないとか。
つまり、リンパ節に該当するのは、駐車場で車同士が意図せず合流してしまう地点であり、上司Aであり、部下Bである、というわけです。
これらは全て、間違ったやり方をしているがために、期待する生産性を上げられない、とも言えます。
間違い探しのやり方（デバッグ）
老廃物がリンパ節にたまるように、ある場所にタスクが積み上がるなどして流れが滞ることを、ボトルネックが発生する、と言います。
ボトルネックといえば、製造業でよく使われる言葉なので、聞いたことがあるかもしれません。
例えば自動車工場の生産ラインの中で、塗装の工程に何らかの問題があると、他の組み立て工程などに比べて時間がかかりすぎてしまい、部品が塗装工程にたまってしまいラインの流れが滞ったりします。
みたいな話は、こちらの本が有名ですね。
生産性を上げるには、このボトルネックを解消しなければいけません。
生産性とは、いつも書いているようにこちらです。
生産性＝成果/時間
よって、生産性を上げる方向性としては大きく2つでした。
①「時間」を減らす
②「成果」を増やす
ボトルネックを解消することは、①の時間を減らすことに繋がります。
つまっている箇所を特定することさえできれば、あとは解消する方法を考えれば良いのですが
そもそもボトルネックとなっている箇所を見つけることは、意外と難しい
のです。
（ボトルネックを見つけることに苦労する話は、『ザ・ゴール』にたくさん書いてあるので良かったら読んでみてください）
ボトルネックを見つけようとするとき、やみくもに問題探しをしようとするのはNGです。
重要なことは
はじめに全体像を把握し、調べる対象を分解する
ことです。
これは、リンパマッサージをするときに、人間の身体にリンパ管がどのように張りめぐされているか？つまりを引き起こすリンパ節がどこにあるか？ということを知識として知っておくことと同じです。
自動車工場のラインでいえば、ラインの全体を工程ごとに分ける、ということになります。
ちなみに、全体を分ける、という話については、前回のマルチタスク編でも書きました。
全体を分けたら、次に一つ一つの箇所を順番に調べていきます。
首や肩、腰などをさわりながら、どこに老廃物がつまっているのかを探っていくわけですね。
仕事でも同じです。
このように、問題を引き起こしている原因を特定するためには
全体を分解し、対象を順番に調べる
ということが出来なければいけません。
プログラミングの世界ではこれを「デバッグ（debug）」と呼びます。
デバッグとは、プログラムがうまく動作しないとき、その問題となる部分を見つけて修正する仕事のことです。
ちなみにデバッグで見つける不具合のことを「バグ」と呼びます。
de（取り除く）-bug（虫）
なんでも昔はコンピュータに入り込んだ虫を取り除いて故障を直したという逸話からきた名前だとか・・・
デバッグの仕事はストレスフル、だけどロジカルシンキングを鍛えるには最強
ちょっと話は変わりますが。
数年前に子ども向けのプログラミング教育が流行ったとき、試行錯誤がロジカルシンキングに効く、といったメッセージがたくさん出回りました。
IT業界で働く身として、そのメッセージがどうにも受け入れがたく、当時こんなBlogを書きました。
論理的に試行錯誤するのであれば、ちゃんとロジカルに考えるスキルが身につくと思うのですが、子どもの試行錯誤は、わりとでたらめです。
大人だってそうです。
TVのリモコンがうまく動かないとき、電池の蓋をあけてみたり、動かしてみたり、リモコンを叩いてみたり・・・
なんとなく、その場で思いついたことをやってみる、という試行錯誤ではロジカルに考えるスキルは身につきません。
私の経験上、ロジカルに考えるスキルを身につけるなら
システム開発の現場でデバッグの仕事をすることは非常に効果的
だと断言できます。
システム開発の現場では、自分の作ったプログラムがうまく動作しないときは、自分で間違いを見つけて直さなければいけません。
テスト中に見つける分には良いのですが、困るのは正式にサービスや製品としてリリースされたあとに不具合が発生したときです。
わりと致命的な不具合が起きて、一刻も早く解決しなければいけない緊迫したシチュエーションというのは、エンジニア経験のある人なら一度は体験したことがあるのではないでしょうか。
私にも経験があります。
こういうとき、緊張で手や身体は冷たくなり、震えをなんとか抑えながら目の前のパソコン画面にうつるプログラムを凝視して、バグを見つけることに集中します。
プログラムの全体を把握し、分解し、順番に調べる、をするわけですが、この緊迫したシーンでは、それを超高速に行っています。
頭のCPUがふりきれそうなくらいに・・・
生産性を上げるというけど、しらみつぶしに順番に調べるというのはどうにも効率が悪そうだな、と思った方は勘が鋭いです。
そうなんです。
時間があれば、順番に調べればよいのですが、時間がないときは、必死に頭を働かせて、調べる順番を考えます。
分解した結果、考えられるケースが4パターンあれば、1つずつつぶしていくことになります。
このとき、最初のパターンに何を選ぶか？というのが、熟練エンジニアと初心者エンジニアの大きな違いになってきます。
言葉で説明するのは難しいのですが、何度か経験しているうちに、問題を引き起こしている箇所を見つける最速のパターンが瞬時に判断つくようになるわけですね。
エンジニアの仕事に限らず、他の仕事でも似たことはあるのではないでしょうか。
自分が見つけられなかった原因を、上司がいとも簡単に見つけてしまった、というようなことが。
基本的にはこういうとき、「もしAのとき・・・」「もしBのとき・・・」のような思考がぐるぐるしています。
要は、AとBとCとDというパターンの洗い出しと、最初に実行するパターンをどれにするするか？ということを決めるロジックが超高速に動いているわけです。
世の中には、ロジカルに考える力を身につける本、というものや講座がたくさんあるので、基本的な考え方はそういったところで学ぶのが良いです。
ただ、実践の中でスキルを身につけるなら、制限時間のあるような極限状態の中で必死に頭を動かす経験が、かなり効果的だと思います。
ちなみに、医師の仕事もそうですね。
最近ちょっと事情があってあちこちの病院で医師の方々と会話をすることが多いのですが、非常にロジカルだなとあらためて感心してしまいました。
人間の命がかかっていますからね。やはりそのスキルは桁違いだと思います。
ゲームで身につけるロジカルシンキング
エンジニアや医師が経験するようなシチュエーションは、誰でもあるわけではないですが、工夫すれば疑似体験することができます。
例えば、ゲームにするのがオススメです。
ボトルネックや間違いを見つける仕事は楽しいものではありませんが、ゲームにすると途端に面白くなるので不思議です。
探プロでは過去に何度か、幼児を対象にデバッグをテーマにしたワークショップをやったことがあります。
就学前のお子さんたちが、保護者の方と一緒に電子ブロックを使って、スイッチをONにしても電気がつかない理由を考える、というものでした。
いまでも覚えているのは、3,4歳ほどの子たちが、保護者の手を借りずに、電子ブロックを動かしながら黙々と集中している様子です。
ワークショップのあと、保護者の方からは
「うちの子がこんなに集中しているのを初めてみました！」
という声があがりました。
問題を見つけ出そうとするのは、人間の本能なのでしょうか。
なんとかして解決したい、という前のめりになるマインドが、こんなに小さな子にも備わっているのだ、と目の当たりにして非常に驚きました。
仕事の現場にも是非、ゲームを取り入れてみてください。
たとえばチーム全体の生産性を上げるために、一人ひとりのパフォーマンスを測ってみるのも良いでしょう。
ただ気をつけてほしいのは、犯人探しをするようなことにはならないように、ということです。
先に紹介した『ザ・ゴール』の中に、山登りをする子どもたちの話が出てきます。
確か、ちょっと太った子が足並みを狂わせて、グループの歩みのスピードが遅くなってしまった、という話だったと思います。
どこに問題があるのかが分ったら、すぐさま「どうやって解決するか？」を皆で一緒に考えるのが良いです。
犯人探しをすることが目的ではないので、そこだけは気をつけてほしいと思います。
ちなみに、エンジニアがプログラムの中から見つけるバグは、間違いなく犯人ですけどね。
こうしたことは、自分自身の生産性を上げるためにももちろん使えます。
例えば、タイムトラッキングツールなどを使って自分の仕事のどこにボトルネックがあるのかを調べてみるのも良いと思います。
私は細かいことが苦手なのでやれませんが・・興味のある方は是非、ツールを利用して生産性を可視化することも、ゲームのように楽しんでみてはいかがでしょう。
さて、次回はアルゴリズムの話をします。
ではまた。
読んで役にたったと思えたら、noteのハートマークを押してもらえると嬉しいです！