「そもそも」1秒つぶやきで仕事の生産性は上がる！-プログラミング的思考で仕事の生産性UP！#04-
クローゼットが片付いている人は仕事のできる人
いきなりですが、皆さんの自宅にあるタンスやクローゼットには、どんなものが入っていますか？
ワンピースやスーツ、シャツやパンツ、帽子にカバンなどなど。
いろいろあると思います。
それらをどのように片付けていますか？
きっと、形や種類、大きさなどで分類して、収納しているのではないでしょうか。
ちなみに私は、色で分類しています。
毎日目にするクローゼットは、色のグラデーションになっている方がキレイだから、という理由ですが、まぁ、理由は何でも良くて。
自分なりのルールで似たもの同士を分類して、ちゃんと整理整頓できている人は、きっと仕事ができる人、のはずです。
そんな自覚ないけど？という方も、安心してください。
分類したカタマリに、ラベルをつけることができれば十分、素質があります。
ラベルの付け方でいうと例えば・・・
シャツ、スーツ、帽子・・・種類で分ける場合
普段用、仕事用、冠婚葬祭用・・・目的で分ける場合
夏物、冬物・・・季節で分ける場合
こうしてみると、分け方にもいろいろありますね。
このように、似たものを一つにまとめてラベルを付けることを「抽象化」と呼びます。
ビジネス書などで、モノゴトの本質が分かる人は優秀である、と書かれているのを読んだことがありませんか？
その話と、クローゼットの中を整理整頓できる話は、同じです。
つまり、モノゴトの本質が分かる人＝抽象的に捉えられる人、ということです。
抽象化は幼児にもできる
ちなみにこの抽象化という考え方は、特別でもなんでもなくて、幼児でも使えるものです。
幼児向けの本には、なかまあつめ、をテーマにした本がいくつもあります。
例えば、私の好きなこの本もそうです。
https://www.fukuinkan.co.jp/book/?id=462
■がたくさん並んだ中に、●が一つだけ書かれた絵を見せて、●という形は1つしかないので、なかまはずれ、だと教えます。
その上で、花や虫などの絵がかかれたものを見ながら、この絵の中で、なかまはずれはどれ？
と、理由とあわせて尋ねます。
小さな子どもと一緒に外を散歩すると、犬がいれば、あれは犬だよ、と教えてあげることもあるでしょう。
すると、子どもは、隣の家で飼われている秋田犬のハナが「犬」であることを学びます。
そして、スーパーへ行く途中にすれ違った散歩中のトイプードルのマロンも「犬」と認識します。
四本脚で尻尾のついた動物は全て「犬」なのかと思いきや、「猫」とか「オオカミ」のように、似ているけど違う種類の動物を、別のものと認識する力を、人間はもっているようですね。
生物学の中に、分類学、という専門の学問が生まれるくらいですから、似たもの同士をあつめて名前をつける、というのは人間の本能ではないかと思います。
（分類学の難解さは置いておくとして）
なぜそんな難しいことがいとも簡単にできるようになったのか？
脳は、生存のために最小限の力で処理する方が都合が良かったから、と私は予想しています。
プログラミングの世界でも、似たものはまとめるが鉄則
人間の脳がムダなエネルギーを使わずに生きられるよう進化したように、実はプログラミングの世界でも省エネは歓迎されます。
たとえば、一つ前に出したじゃんけんの手が「パー」だったら次は「グー」を出す、「グー」だったら「チョキ」を出す、「チョキ」だったら「パー」を出す、というじゃんけんプログラムを作るとします。
このとき、プログラムをどのように作るか？によって、優秀なエンジニアか、そうでないエンジニアかが分かれます。
if (一つ前に出した手 == 'パー') {
プログラム実行 ('グー'を出すプログラム);
} else if (一つ前に出した手 == 'グー') {
プログラム実行 ('チョキ'を出すプログラム);
} else if (一つ前に出した手 == 'チョキ') {
プログラム実行 ('パー'を出すプログラム);
}こんな感じで、3つのプログラムをそれぞれ実行し分けるのが一つのやり方ですね。
ちなみに、それぞれのプログラムの中身を見てみると・・・
'グー'を出すプログラム {
ジャンケンの合図が聞こえたら手の形を変える（'グー');
ポンという掛け声とともに手を（'グー')の形に変えて前に出す;
} 'チョキ'を出すプログラム {
ジャンケンの合図が聞こえたら手の形を変える（'グー');
ポンという掛け声とともに手を（'チョキ')の形に変えて前に出す;
} 'パー'を出すプログラム {
ジャンケンの合図が聞こえたら手の形を変える（'グー');
ポンという掛け声とともに手を（'パー')の形に変えて前に出す;
}はい、そうです。ムダが多いな、と気づきますよね。
こういうプログラムをつくるエンジニアは、あまり評価されません。
一方で優秀なエンジニアは、こんなプログラムを作ります。
if (一つ前に出した手 == 'パー') {
プログラム実行 (じゃんけんの手を出すプログラム('グー'));
} else if (一つ前に出した手 == 'グー') {
プログラム実行 (じゃんけんの手を出すプログラム('チョキ'));
} else if (一つ前に出した手 == 'チョキ') {
プログラム実行 (じゃんけんの手を出すプログラム('パー'));
} じゃんけんの手を出すプログラム (次に出す手) {
ジャンケンの合図が聞こえたら手の形を変える（'グー');
ポンという掛け声とともに手を（次に出す手) の形に変えて前に出す;
}3つのプログラムが、1つにまとめられました。
似たようなプログラムをたくさん作ってしまうと、あとで変更したくなったときにとても大変なので、似たような機能は1つにまとめる、というのが鉄則です。
たとえば、ジャンケンの合図が聞こえたら手を後ろに隠す、という動きを加えたくなったとき、最初に書いたプログラムだと、3つのプログラムの全てを変更しなければいけないですよね。
でも、1つにまとめておけば、変更するプログラムは1つで済みます。
じゃんけんの手を出すプログラム (次に出す手) {
ジャンケンの合図が聞こえたら手を後ろに隠す;
手の形を変える（'グー');
ポンという掛け声とともに手を（次に出す手) の形に変えて前に出す;
}今回は、じゃんけんという非常に分かりやすい題材で説明しているので、そんなの当たり前だよね？
と思うかもしれません。
ところが、スマホアプリや企業のシステムを動かすプログラムはもっともっと複雑なので、気付くと似たようなプログラムが大量に作られる、ということはしょっちゅう起きてしまいます。
ちなみに、ベテランのエンジニアになると、ある程度の変更が発生することを見越して、はじめから汎用的なプログラムを作ることもできてしまいます。
なので、作ったプログラムを見れば、そのエンジニアの力量はある程度、分ってしまうのですよね。
「そもそも」を考える癖をつける
プログラミングなんてIT業界の話だから、自分たちには関係ない、と思われたかもしれません。
しかし、似たようなことは私たちの身の回りにたくさんあるので、もう少し分かりやすい例で紹介します。
ここに、自社の会員データを分析する仕事を任されているAさんとBさんがいるとします。
ある日、上司のCさんから、性別ごとに10年分の売上傾向をみたい、と言われました。
Aさんは、さっそく会員データを男性と女性それぞれに分けて、10年間の売上推移をレポートしました。
その次の日、住まい（エリア）ごとの違いを見たい、と言われたので、今度は都道府県に分けて、10年間の売上推移をレポートしました。
そしてさらに次の日、年齢ごとの違いが見たい、と言われたので、今度は年齢を10歳刻みに分けて、10年間の売上推移をレポートしました。
さらにさらに次の日、都内在住の20代男性の過去10年分の売上傾向がみたい、と言われたので・・・
一方のBさんは、性別ごとに10年分の売上傾向が見たいという上司のCさんのリクエストを聞いてすぐ、期待されているのはそもそも何か？と考えました。
性別以外の違いも知りたくなるだろうから、いろいろな軸で分析できた方が良さそうだ。例えば、年齢や住まい（エリア）、会員の継続年数別、でも比較できるようにしたらどうだろう？
要するに、会員の属性をさまざまな切り口で見られれば良さそうだ、と気づいて、自ら工夫したレポートを提出しました。
さて、あなたが上司のCさんだとして、どちらが優秀な部下だと思うでしょう？
言うまでもないですよね。
どうしてこんなにも差が生まれてしまうのでしょうか？
ちなみにAさんは非常に勉強熱心で、タスクは小さく分けるべし、集中力のある朝のうちに仕事を片付けるべし、などなど、HowToの書かれたビジネス本をたくさん読んでいる人です。
だから、上司からのリクエストには毎回、とても頑張ってスピーディにこたえる真面目なところが評価されています。
でも、どうしてもBさんと比べてしまいませんか？？
前回もお伝えしたように、生産性を表す式はこちらです。
生産性＝成果/時間
だから、生産性を上げる方向性としては大きく2つです。
①「時間」を減らす
②「成果」を増やす
Aさんは、たくさん読んだHowTo本を参考にして、1回あたりの作業時間をわずかに減らせたかもしれません。
一方のBさんは、上司のCさんとのコミュニケーションを1回に減らしただけでなく、上司の期待以上の付加価値もつけたので成果も増やしています。
Bさんの方が評価されるのは、こうした生産性の違いです。
しかも、かなり大きな違いがあるのです。
時間を減らす、という点についてもう少し考えてみます。Bさんがやったのは、仕事の数を減らす、ということです。
世の中には、仕事を増やすのが好きな人が多いな、と感じます。
もちろん、好きで増やしているわけではない、とは思うのですが、あれもこれもやらなきゃ、とどんどん増やしている人はわりと多いです。
それでは忙しくなる一方ですよね。
前々回の記事に書いたように、モノゴトを工夫することで「時間」を減らすには限界があります。
だから、仕事そのものを減らすことが一番、効率が良いのです。
（もちろん、それでいて成果は一緒かそれ以上のものを、というのが前提ですが）
仕事に取り掛かるまえに、「そもそも」と一秒つぶやいてみる。
そして、要するにこれは何の仕事なのか？ということを考えてみる。
それは、クローゼットの中を片付けてラベルをつけることと同じです。
だから、誰にでもできます。
分け方はみんな違う。だからこそおもしろい
最後に、少し余談です。
こちらは、4年ほど前にやったあるワークショップのレポートです。
この中で、ワンピースやネクタイ、シャツや浴衣、眼鏡などなどのパーツをテーブルに並べて、似たもの同士を集めて片付けよう、というゲームをやりました。
数人のグループに分かれて会話しながらやるのですが、人によって分け方がけっこう違う、ということに途中から気付くところがポイントです。
形だったり、素材だったり、色だったり。
分け方には個性が出るものです。
分け方は多様、だからこそ、冒頭に出した分類学は難しいのですよね。
お気づきと思いますが、これは数学で習う「集合」の考え方です。
ちなみに、集合については過去にこちらで書きました。
集合の考え方を理解するためには、何が同じで何が違うのか？ということが理解できなければいけません。
私たちは普段、無意識でモノゴトを分類していますが、よく考えたらすごいことですよね。
実際、難しくないことがほとんどなのですが、たまに、うまく分類できないものが出てきたりしますね。
例えば、性別は男と女、と2つに分けていた時代から、いまでは多様な性を認める時代へと変わり、単純な分類はできなくなりました。
似たもの同士を判別して、分けて、ラベルをつける。
幼児でもできることなのに、奥深くて、正解があるわけでもない。
そんな抽象化の考え方を、面白い！と感じることができたら、仕事への取り組み方が変わって、気づいたらきっと生産性はUPしているはずです。
探プロではこのように、プログラミング的思考の中で使われる様々な考え方を、仕事や家事といった私たちの日常に応用することで、生産性を上げる方法を紹介していきます。
次回は少し専門的になりますが、オブジェクト指向、についてご紹介します。
ではまた。
この記事が気に入ったらサポートをしてみませんか？