simotin13's message

simotin13といいます。記事の内容でご質問やご意見がありましたらお気軽にコメントしてください\^o^/

労働と教育の未来を予想してみる

教育

Twitterでもつぶやいたのですが、少し前にすき家でご飯を食べることがあったのですが、従業員がかなり残念なレベルでした。


AIとか人工知能とかロボットといったキーワードが語られることが多いですが、AIやロボットが普及した時にどういった未来になるのか、「労働」と「教育」という視点で考えてみました。

どうして「労働」と「教育」なのか

人工知能やロボットの技術が今後さらに進化した場合、よく言われることですが、人間がやっていることをロボットがやるようになると思います。

  • タクシー運転手の代わりに自動運転が普及する
  • 飲食店の給仕(配膳)をロボットが行う。
  • 各種サービス業(窓口業務)などをロボットが行う。

といったことはそう遠くない将来実現するのではないかと私は思います。

ロボットが人間に代わって働くようになった場合、人間はロボットと異なる仕事、もっというとロボットにはできないような仕事をする必要があります。

では、ロボットにできないような仕事とは何かというと

  • 高度な技術、センスなどが求められる仕事(キーワードを上げるとするならば、名人芸・職人・カリスマといった感じでしょうか)
  • 人間の感情を扱う仕事(人間関係・ウェット・営業・コンサルティング・カウンセリング・ヒアリング・接客業)

といった職種が思いつきます。

安価な労働力をこき使いたい奴が得をする

ロボットやAIが人間の代わりに仕事をするとなると大きく変化するのは当然「人件費」です。

例えばロボットであれば「深夜残業手当」も「休日出勤手当」などは不要ですし、２４時間３６５日働かせても何も問題ありません。

ですので、Twitterでもつぶやいた通り、安い人件費で人手を沢山確保したいデフレ系企業や単純労働の多い工場等にとってはロボットは大変嬉しい存在になるはずです。

ブラックだブラックだと叩かれている企業も、ロボットを使って安くて安定した品質で製品やサービスを提供できれば、一転して優秀な企業として世間から評価される可能性があります。

マニュアル人間が損をする

ロボットが活躍する職種というのは単純作業やマニュアル化しやすい作業です。

単純作業やマニュアル化された作業をロボットがするようになれば、当然そこで働く人間は必要なくなります。

そうなった時に、そこで働く人間はどうするのか？

恐らくロボットの仕事を管理したり、ロボットには対応できない仕事(恐らく対人的な仕事)をする人が必要になるのでそういった仕事へとシフトしていく流れができると思います。

そういったロボットには対応できない仕事は、それまでの単純作業よりワンランク上の知性や能力が求められることになります。必要な人の数も従来の作業していた数よりは少なくなるでしょう。

管理する仕事にありつけなかった人はどうなるのか？

仕事にあぶれ職を求めることになりますが、世間には単純作業の仕事は恐らく限られており、また時給(単価)も今と比べて安くなるであろうと思います。

言われたことしかできない人、自分の頭で考えて行動できない人を指して「マニュアル人間」という言葉がありますが、プログラムされていないことはできないAIやロボットは人間ではないですが、まさしく「マニュアル人間」です。

しかし、学習する機能を持ったロボットであれば「マニュアル人間」以上に優れた存在になることは明らかです。

そう考えれば、仕事を得たいと思っている人間が最もしてはいけないことは、「マニュアル人間になること」です。

この考えは、以前ロボットと人間の違いについて考えた記事にも書きましたが、

相手の立場に立って考えて行動しない(愛の無い行動・心無い行動)をする人がいますがそういった人「マニュアル人間」として淘汰されていくんじゃないかと思います。
mcommit.hatenadiary.com

というより個人的には淘汰されて欲しいと思いがあります。

というのも、皆さんも１度や２度は経験されたことがあると思いますが、例えば市役所に行って窓口の人が

「ここの窓口ではそれはできないのでＸＸのところに行ってください」

とか

「必要な書類を揃えてからくてください」

などと無愛想な態度で応対されることがあります。

窓口業務はいわば接客業・サービス業なのでそのような応対をするのは本来仕事ができていないことになると思いますが、役所ではこういった人はときどき見かけます。
※もちろん親身になって丁寧に対応してくださる方の方が多い思いますが。

こういった人達の業務はロボットに置き換わってもサービスを受ける側の人間としてはデメリットは少ないです。
むしろ相手がロボットであれば、相手が機械だと初めからわかっている分感情的にはなりにくいでしょう。

役所の人側をフォローする立場で考えると、窓口にはちょっと変わった人やクレーマーのような人も一定の割合でくるので、受付業務は決して楽な仕事でもなければ楽しい仕事でもないかと思います。窓口の人がそう感じるのであればなおさらロボット化を進めてもよいかと思います。

これからどうすればよいだろうか

いろいろと書きましたが、今後人工知能やロボットの技術が進んでいく中で、マニュアル人間を量産しないような教育が必要なんじゃないかなと思います。

個人的には、

いろんなことを広く浅く学ぶのではなく、自分の好きなことを早く見つけて、長い時間それに取り組むような教育

が必要なんじゃないかなと思いますが、これからの社会と教育がどうなっていくのか気になるところです。

C言語のシフト演算は気まぐれ

C言語

仕事でC言語のコードを見ていて、シフト演算に関するバグにはまったので備忘録として挙げておきたいと思います。

#include <stdio.h>
int main(int argc, char **argv)
{
    char num = 0xB3;    // - 77
    unsigned short hoge = (num << 0); 
    printf("0x%02X", hoge);
    return 0;
}


のようなコードを書いた場合hogeには何が入るでしょうか。

ここではchar型の変数を0bitシフトして、unsigned short型の変数に代入しています。

恐らくhogeは0x00B3になると思われたのではないでしょうか。というより私はそう思いました。


残念ながら答えは

「分からない」

が正解です。

私の手元のGCCでは、hogeには0xFFB3が入りました。

ちなみに unsigned char num = 0xB3;

とした場合には、hogeは0x00B3になります。

シフト演算による上位ビットに何が入るかはC言語の仕様では定義されておらず、処理系依存になっているそうです。この挙動は知りませんでした。

ビット演算やシフト演算を扱う際は無意識に符号無し型(unsigned)を使っていたのでこれまで遭遇しなかったんだと思います。

感想

C言語には仕様として未定義の動作がちらほらあるようです。
そういったコードについては処理系(コンパイラ)によってどう動くかがわからないので、移植性を妨げ、バグの温床になります。

何が未定義なのかを把握し、どのようなコードを書くのが正しい姿(安全な書き方)なのかを知っておくことが重要だと強く感じました。

上記のビット演算に関する話は、きちんとした入門書などでは解説されていることが多いようです。

コミュニケーション能力の本質は何か？

ひとりごと ライフハック

2017年もはや20日を過ぎました。
正月からいい感じに忙しく仕事をさせて頂いているのですが、最近コミュニケーション能力について考えることがあったので私の考えをまとめておきたいと思います。

なぜコミュニケーションについて考えたのか？

詳しく書くと長くなってしまうので、簡単に状況を説明すると、複数人で開発するプロジェクトに参加していて、何名かのメンバーの方達と十分に理解しあうことができませんでした。メンバーの方達の基本的な技術力が一定のレベルに達していないということが要因としてありましたが、それ以前に、仕事の進め方や取り組み方について、私がその方々の事よく理解できなくて、悩んだというというか、いろいろ考えてしまい、自分なりに一定の答えが出たので書いておきたいと思いました。
※仕事の技術力のレベルというのは主観にすぎませんが、ここでは能力として、プログラミングの仕事をするのに、ブラインドタッチができなかったり、自力でコンパイルエラーやリンクエラーが取れない状態のことを指しているものとします。

コミュニケーション能力とは何か？

そもそもコミュニケーション能力とはどのような能力でしょうか。

「コミュニケーション」という言葉は英語ですが、日本語に訳すと「意思疎通」となります。

つまり、

「コミュニケーション能力」＝「意思疎通能力」

となります。この訳違和感を感じる人はにあまりいないと思います。

つまり、コミュニケーションをキャッチボールに置き換えるならば、お互いにボールとして投げ合っているのは「意思」になります。

世間一般で、コミュニケーションを語る際に、このことが重要視されていないように思います。

一般的にコミュニケーションについて語られるときは、

「会話上手は聞き上手」
「相手の話に合わせて、あいづちを入れよう」
「共感することで、コミュニケーションが上手く行く！」

と言った視点で語られることが多いように思います。

そういった考え方が間違っているとは思いませんが、やり取りしているものが「意思」であるということを前提としてあまり語られてはいないように思います。

意思疎通の状態

意思を伝えるということにはいくつかの状態があります。

  1. 周りの人の意思を尊重しつつ、自分の意思を明確に伝える
  2. 周りの人の意思を優先して、自分の意思をないがしろにしてしまう
  3. 自分の意思を優先して、周りの人の意思を尊重しない
  4. 意思はあるがうまく伝えることができない
  5. 自分の中に明確な意思がない
続きを読む

2017年にやりたいこと

ひとりごと

2017年あけましておめでとうございます。

去年のお正月は比較的時間があったので、読書したりコードを書いたりできたのですが今年はあまりそういった時間が取れませんでした。
年に一度のお正月なので、今年取り組んでみたい事をあげたいと思います。
※といいつつここ数日、色々と勉強したり考えたりしていることもあるので出来ればこの後も早めに記事を更新したいと思います。

2017年の目標

ここ数年やろうやろうと思っていてもできていないことも多いので、自分の整理の為にも2017年の目標・やりたい事を書いておきたいと思います。
※いざ列挙してみると沢山上げてしまったのでそれぞれの目標の「期間」「規模」「難易度」のイメージを合わせて書いておきたいと思います。

やりたいこと 期間 規模 難易度
コンパイラorインタプリタを自作する 長期 大 高い
月に2記事はブログを更新する 長期 中 まあまあ
ディープラーニングについて勉強する 短期 中 高い
FPGAで遊ぶ 長期 中 まあまあ
経済学の勉強をする 短期 小 まあまあ
Linuxのデバイスドライバを書いてみる 短期 小 低い

う～んこうして列挙してみると長期にわたってやりたい事が多いですね。

- コンパイラ/インタプリタを自作する

3年前位にやりたいと思ってから少しずつ勉強しているのですが、なかなかまとまった成果物ができていないのでいい加減ある程度の成果物を出したいです。

そもそもある程度ってどんなものだろうかってか考えてみたのですが、3年前にコンパイラを書きたいと思った理由は

「C言語のコードを解析して、自作関数のテストコードを自動生成したい！」

とCUnitでとあるC言語の作業のテストコードを、ガリガリ・ダラダラと書いていた時に思いついたからでした。

最初にとったアプローチはテスト対象のCの関数をRubyの拡張モジュール経由でRubyから呼び出し、CUnitを書くよりも簡単にテストできるようにするというものでした。

関数のプロトタイプ宣言をパースして、拡張モジュールを自動生成し見かけ上動的にRubyからテストを行うということはできたのですが、Cのデータ型とRubyのデータ型の違い(特にポインタ型変数の扱い)をどうするかで悩んで途中で放置してしまいました。

いまでも無残で情けない残骸がGithubには残っていますが・・・github.com

まぁそういうことをしなくても、

RubyのFFIやpythonのctypes
github.com

15.17. ctypes — Pythonのための外部関数ライブラリ — Python 2.7.x ドキュメント

を使うことでやりたかったことは、今ならばもう少し簡単にできそうですが、失敗に終わった取組みを今更もう一度する元気も無くしてしまっています・・・

じゃあ今はコンパイラの勉強をして何がしたいのかと言われても困るのですが、ちょっとした静的解析ツールみたいなのを作ってみたいなと思っています。

学習に関しては、「解析」なので、最適化とかのコンパイラのバックエンドはとりあえず横に置いておいておけそうです。
ここ最近の学習の成果として、字句解析～構文解析まではなんとなく実装の道筋は見えた(見えたけど構文解析のコードはフルスクラッチで書くと面倒臭くて量が多くてきたなくなることが分かってきて、なんというかモチベーションの低下との戦いになります)のであとは意味解析の手法とかについて理解できればとりあえずコードはかけそうな気がしています。

このへんの学習成果(というより学習経過か・・・）については、

mcommit.hatenadiary.com

の続きのエントリとして早く書ければと思います。

- 月に2記事はブログを更新する

無理にノルマにする必要もないのですが、毎月のアクセス数が増えるとモチベーションも少しはキープできるのでなんとか頑張りたいです。

書きたいことはあるけど文章にまとめる時間やコードを動かしたりする調査の時間がかかるということが多いので、とにかく集中して記事を書く習慣を身に付けたいです。

- ディープラーニングについて勉強する

単純に人工知能系の技術が面白そうという軽い気持ちです。
やって見たい事として自宅に付けている防犯カメラの動体検知や人体検知の精度があまりよくないので勉強して改善してみたいなぁと考えています。

- FPGAで遊んでみる

評価ボードが積み基板になっているので・・・なんとかしないと。
論理回路の勉強もきちんといちからやりたいな。

- 経済学の勉強をする

去年、高橋洋一氏の本で経済学にはまってからちょこちょこと本を読んだりするようになりました。

戦後経済史は嘘ばかり 日本の未来を読み解く正しい視点 PHP新書

戦後経済史は嘘ばかり 日本の未来を読み解く正しい視点 PHP新書

自分にとって何かプラスになったかと言われると直接的なメリットはないのですが、それでも経済学って自分達の生活に関わってくることなので知れば知るほど面白いです。

今年中に、積本になっている

この世で一番おもしろいマクロ経済学――みんながもっと豊かになれるかもしれない16講

この世で一番おもしろいマクロ経済学――みんながもっと豊かになれるかもしれない16講

高校生からわかるマクロ・ミクロ経済学

高校生からわかるマクロ・ミクロ経済学

の2冊とマンキューの本を何冊か読み終えたいと思います。

- Linuxのデバイスドライバを書いてみる

これは完全に仕事向けです。
Linux開発に詳しい方が「一回くらいは書いといた方がいいよ」と言われていたのでなんとなくラズパイとかで書いておくかみたいな気持ちがあります。
イメージ的にはコードを書く部分は大したことないんだと思うんですが、事前の準備とか(カーネルのコード用意したり)調査が面倒そうです。
※過去に何回か既存のドライバを修正したりとかはあるのですが、きちんと環境構築とか手順とか、作法とかを把握しておきたいです。

こういうのは短期間で、2～3日時間を決めてバッっと勉強してみるのがよさそうですね。

課題

長期の目標はモチベーションと時間の確保が難しいです。
辛い時期を乗り切るために計画を立てたり、自分の中で小さな目標を設定したり、人に発表する機会を無理やり作ったりしてなんとか頑張りたいと思います。

まとめ

だらだらと書いてみましたが、あれやこれやとやりたい事があって浮気性な自分がちょっと嫌になります。
勉強してみたからと言って直接プラスになることは少ないかもしれませんが、できる仕事の幅が広がったり知的好奇心が満たされたりするので、悪いことでもないのかなと思います。

仕事や勉強で知り得た知見などはできるだけこのブログに上げて行きたいと思いますので、読んでくださった方にとって何かプラスになれば幸いです。
ということで、2017年は仕事と合わせて勉強を頑張る年にしたいと思います。

エイ、エイ、エイ！

最近買ったおすすめの絵本ベスト5冊を選んでみた

教育 育児 読書録

「コんガらガっちの絵本」を買ったみた

先日本屋さんで、

「コんガらガっち あっちこっち すすめ!の本」

を買ってみました。

コんガらガっち あっちこっち すすめ!の本

コんガらガっち あっちこっち すすめ!の本

早速子供たちと一緒に読んでみましたが、この絵本はとても面白い本でした。
この本は「絵本」というより「一緒に遊ぶおもちゃ」という感じです。
おもちゃと言っても付録がついているとかそういう意味ではなく、絵本に出てくる道をゆびでなぞって遊ぶ迷路のような形になっています。

迷路やしりとり・すごろくの形式で道を辿っていく形でページが進んでいき、場合によっては元のページに戻ることもあります。
ピタゴラスイッチを作られている方が書かれた本のようですので、読んでみてよく考えられているなぁという印象を受けました。

うちの子供たちはすごろくや迷路が好きなので、大喜びで遊んでいました。

コんガらガっちの絵本はシリーズになっていて、他にも何冊か出ているようです。
本を買ったジュンク堂では、サンプル用の本で「コんガらガっち ぬきあしさしあし すすめ!」の本もおいてあり、こっちの方も面白かったです。

コんガらガっち ぬきあしさしあし すすめ!の本

コんガらガっち ぬきあしさしあし すすめ!の本

「コんガらガっち」を知ったきっかけ

「コんガらガっち」のことは最近まで知らなくて、Twitterで育て上げネットの工藤さんのツイートを見て知りました。

続きを読む