ITと哲学と

IT系エンジニアによる技術と哲学のお話。

事業を創る人の大研究を読んだ

「事業を創る人」の大研究を読んだ.

タイトルの通り「人」に着目した新規事業立ち上げに関する本で,独自研究で得られた沢山のデータをもとに考察を進めていくというスタイルの本でとても参考になったので要点をまとめてみようと思う.

本書との出会い

本屋さんでパラパラと新規事業関連の書籍を探していた際に『はじめに』を立ち読みし「あるあるw」と共感し,続きが気になったので,さらに序章を読んだところ「あるあるあるあるw」と深く共感したので購入した.

簡単にまとめると「新規事業ってなんか大変そうだし,あんまり関わりたくないよねw」というのと「新規事業って社内からの風当たり強いよね」という点に共感した.

ターゲット

既存事業がある会社における新規事業立ち上げをターゲットにしている. スタートアップ企業を立ち上げましょうとかそういうことではない点が通底して重要な特徴になっている.これによって様々な軋轢が生まれる.

ターゲットとしているロールは,新規事業を創る人自身はもとより,それを支える上司や経営層を主に狙っているように思う. 本書では「人」として「創る人」「支える人」「育む組織」の3つをあげているが,育む組織の人に遍く届くようにというよりは,むしろ組織をつくる人(つまり経営層)をターゲットにしていると思われる.

本書の立ち位置

新規事業立ち上げに関する書籍は色々ある.カリスマ経営者的な人の自伝に近いような実践系の書籍と学術的な研究に基づく学術書の2つに分けられる. 本書は学術書に分類されるものであり,学術書の中でも新規事業立ち上げについて「人」に着目した点がユニークな点となっているとのこと.

つまり他の書籍とは異なりプロセスから人へ視点を移した点が面白いところ.結局人だよねーという.

第1章

新規事業を取り巻く環境

新規事業を「既存事業でえたモノを活用し,新たな経済効果を生み出す事業」と定義している. 既存事業で得たモノを活用するという点がポイントになる.

ライフスタイルの変化により,新規事業をつくるというのは企業にとって生存戦略として必要不可欠なものになりつつある.

なお,それだけにこれに対する期待はとても大きいようで,「予算的には成功しているプロジェクトであっても経営層の満足度は低く満たされないケースが多い」という面白いデータが示されている.

これ,ゴールポストが動いているということであり,担当者にとっては悪夢でしかない...ちなみにこの問題自体については今後議論されない.

新規事業に必要な能力

新しいアイディアを形にして,それをお客様に届けることができて初めて新たな経済効果が生み出せる.

独自研究で得られたデータから経営者は新規事業を進めていくためには「新しいアイディアを考えて,未知を恐れず,最後まで突き進むことができる」力が必要だと考えているケースが多いらしい.

一方で,新規事業立ち上げ担当が実践を通じて必要だと感じた力は「現場を正しく観察し,上手に他者を巻き込める」力である. 新規事業を立ち上げるために,社内からの理解が得られず苦しむというケースがとても多かった模様.

この結果から,これから新しく担当になる人は社内理解をいかに得るかという点をもっと意識した方が良さそうに思った. これができるかどうかってかなり人間力が問われるテーマだと思う.

特に新規事業はその構造から社内からの風当たりが強くなりがちだし,孤立しがち.しんどいことも多い. その証拠に,新規事業を去っていく人の理由は「事業自体がうまくいかなかったことよりも,新規事業をめぐる構造によるもの」が多い.

まとめ

新規事業はアイディアそれ自身よりもいかに周囲を巻き込むかが大事であり,そこに人の力が問われる.さらに,新規事業の構造上,しんどいことが多いので,折れない心の力も大事.

いかに心が強い人でもサポートがないと折れてしまうので,支える人や組織がさらに大事.それらもマルッと含めて,人が大事ということ.

第3章

創る人に求められるスタンス

新規事業は結果が出るかどうかわからないものであり,業績志向になりすぎても結果が出るかどうかはわからない. むしろ事業を出そうというプロセス自体から学びを得て,それを糧にさらにブラッシュアップできるような成長志向のマインドセットが必要.

ゼロから試行錯誤しながら形作る経験からしか学べないことは大きい.これを学び,生かしていくマインドセットが重要.

事前知識があることの優位性

前述の通り,新規事業の構造からきているしんどさが多いので,嵌る可能性のある落とし穴が独自研究の成果から見つかっている. 11の問題とそれをまとめた4つのジレンマという形でそれらが以降の章でまとまっている.

これを知っておくことで,自分が今置かれている状況を俯瞰的に理解できるし,それによって「これは自分だけの固有の問題ではなく構造上の問題なんだ」とリフレーミングでき,前向きに問題に取り組めるようになる.

これが本書の大きな価値になっていると思う.

第4章

前述の11の問題について解説がある.が,個別具体的なこうしたら良いというのは残念ながら示されていない. 示されてはいないが,問題の粒度が大きいため,個別具体的な解決は状況によるところが大きいからこれは仕方ないと思う.

大事なのは,こういう問題が実際に起こりうるだろうということを理解しておくこと.

「既存事業部門からの批判」とか「新規事業プランを生み出せないジレンマ」あたりがとてもとても身につまされる.

既存事業部門からの批判

新規事業の人たちは何やってるかわからんというところが原因になってこの問題が起こるように思う. 何やってるかわからん人たちが,自分たちが必死に生み出した利益を食いつぶしているように見えるという構造が,この批判をうむ.

進め方や情報発信を考えてやっていかないと,簡単に孤立しまっせというお話.つらい...

新規事業プランを生み出せないジレンマ

創る人は,その事業が軌道に乗るまではできていない状態が続くわけで,できない自分の姿に苦しみ続けることになる.

第5章

新規事業を創る人はそんな感じで孤立したり,しんどかったりするようなので,それを折れないようにサポートする組織風土が必要だというお話.

事実として,他部門が新規事業を応援しようという組織風土は新規事業の業績を有意に高め,新規事業をお金の無駄だと思っている組織風土は業績を有意に下げるというデータもある.

若干ポジショントーク的に感じなくもないけど,データが出ている以上そういうことなのかなという印象. とはいえ,組織風土は片方が頑張って作れば良いものではもちろんないとも思う. 創る側の人も,自身がどう見られる可能性が高くて,実際にどう見られているのかということを常に自問して,事業を成功させるために社内の周囲との関係性づくりを怠ってはいけないんだと思う.

読了後まとめ

本書では人の側面が強く論じられていたけど,もちろん技術的な面やアイディアが出せるかという面も大事.というかそっちこそが前提だとは個人的に思う. その上で人としての力も求められるということで,新規事業を成功させるためには高い総合力が求められる.

そのための補助輪として本書は有用だと思う. 事前に予期できるだけで心構えができるし,準備もできる.自分だけが抱える問題じゃなくて構造上起こりうる問題なんだと捉えられるようになる点も,将来本書に助けられるところがあるかもしれない.

ところで,人間力ってどうしたらつくんでしょうね........

「事業を創る人」の大研究

「事業を創る人」の大研究

「○○がない」ということについて最近考えること

「○○がない」という言葉を聞くたびに、最近思うことがある。

「○○がない」って、一見問題提起っぽく見えるけど、その実はただの事実を述べてるにすぎない。

これをどうやったら解決すべき問題や、より良くするためのアクションを誘発する問いにできるか?を考えてみたい。

たとえば?

「hogehoge分析をしてみた結果、第N象限に関する取り組みがないです」とか「UnitTestが無いです。テストコード自体も、テストコードを書く文化自体もないです」みたいなやつ。

どういうこと?

「○○がない」ってのは事実であり、○○が存在していないってことを指摘している。

「問題」というのはなんらかの不都合があるから解決する対処だとすると、「○○がない」という事実が、そのまま全てなんらかの不都合に結びつくものでは無いと思う。

例えば、「弊社には薬剤師がいない」という事実があったとして、弊社はソフトウェアメーカなので別段不具合はないのでそれは問題ではないと思うわけで。

このように、「ない」という事実は問題に直結しない。

ここまで極端な例ではなくても、「みんながあったらいいかも」と思うような内容であっても、様々な制約や優先事項から取り入れていないケースもあるかも。 例えば、「弊社にはテレビCMがない」という事実があり、テレビCMがあればもっと売れるようになるかも?という期待はあるけど、予算や理念、効果についての考えなどからそういう選択をしている(?)ものであり、それは問題ではないと思う。

このような切り分けなく「○○がない」という事実自体を問題として扱うと、それの解決方法は「○○がある」という状態を作ることにもなる。 その結果、「○○がない」を裏返した「○○がある」状態をやみくもに目指すことになり、有限なリソースをへんな配分で消費してしまったりすることになる。

さらに、「○○がない」事実を「○○がある」状態に変えたところで、その奥にある問題を発見できていないので、真の問題に対するカイゼンが進まないと言う問題もある。

前述の「テレビCMがない」こと自体を問題として捉えてみると、それを解決するためには「テレビCMをうつ」ということになる。 が、解決するべき問題って、売り上げが少ないとか購買層からの認知が低いとかそういうことですよね。

購買層からの認知が低いことが問題であれば、テレビでマス向けに広告打たなくてもいいかもしれないし、売り上げが少ないことが問題であれば、もっと営業活動に投資するとかあるかもしれない。利益が低いみたいな問題であればCM打つことによって余計費用がかさんでマイナス効果が出るケースもあるかも。

じゃあどうしたらいい?

問題まで落とし込んで考えるべきだと思う。 「○○がない」ことでどんな不都合があるのか?

テストコードがないから、どんな不都合があるのか?みたいな。

テストコードがないことで、テスト工数が余計にかかっているとか、バグが流出しているとか、リファクタリングできないとか。そういう具体的な問題をベースに考えるようにしたい。 そうしないと、ただ「ある」状態をやみくもに目指すことになると思う。

問題まで落とし込めば、ある状態を作る以外のもっと良い解決策にたどり着くかもしれない。

おちは?

ないです。

会社でハッカソンをやってみた 進め方編 2

前回記事の続き。 ハッカソンを行う上で「何を作るか?」の決め方について。

結論から言うと、メンバーに任せっきりで特段問題はなかった。

ハッカソンプレ実施で得た学び

前回記事のアイディアソンのフレームワークを運営メンバーだけで実施し、短縮版のハッカソンを行った。 その結果、以下の通りの問題が浮かび上がった。

  • お客様ロールの人の課題を解決することに固執し、技術的のアップデートという点が追及できなかった
  • SI的なお客様のお困りごとをヒアリングし、それを解決するような取り組みになってしまい、自分たちで考えて進めるワクワク感が目減りした

今回は製品開発に活かしたり実用的なアイディアを出すことが目的ではなく、新しいことをやることや、自分たちで主体的にアイディアを出して開発をすることに重きを置いていたため、前述のフレームワークでは上手くはまらないとの結論に至った。

チーム内で相当議論を重ね、最終的には「進め方を決めないで各チームに任せる」という一見丸投げなアイディアに至った。 一応ここに至る前に、チーム内で下記の方法を試しており、当初の進め方よりは目的に沿ったアイディア出しが出来ることを確認していたが、それでもやはりお仕着せ感が拭えず、最終的には各チームに任せるという結論に至った。

ただ、完全に任せる形では事故る可能性があるので、各チームに運営メンバーが付き添い、上手く進まなそうであれば下記の進め方を紹介し、事故らないようにフォローする体制を敷いていた。

改良した進め方案

ターゲットについて

ターゲットを未来の時点でのお客様と設定する。これによって今のお客様の御用聞きにならず、自分たちで未来の時点でのお客様を想像しながらアイディア出しを行うようになる。

どんな未来か?を考える

どんな時点での未来をターゲットとするかを考え、その時点で起きていそうなことを考える。 たとえば2020年をターゲットとした場合、オリンピックがあり、国外の人たちが沢山来日するとか。 もっと先であれば労働人口の減少や働き方改革の推進による変化(在宅ワークが増えたりフレックスが増えたり)など、どんな未来になっているかを考える

どんな課題か?を考える

その上で、お客様はどんな課題に直面するだろう?という点を考える。 そしてそれを解決するためにはどんなものが必要だろうか?と考えて、アイディアとする。

結果

事故るのでは?というのは、はっきり杞憂だった。 全てのチーム(9チームとも)が自分たちの進め方を見つけ、とても興味深く面白いアイディアを出すことができた。 こればっかりは参加メンバーの能力によるところが大きいが、うちのメンバーはみなその能力に長けていたんだと思う。

会社でハッカソンをやってみた 進め方編 1

前回のきっかけ編の続きです。

ハッカソンをどう進めるか?を考える

ハッカソン自体の進め方についても色々と考えることがある。

何に時間を使うか?

全体に大きく影響する要素として、何に時間を使うか?という観点がある。

例えばGVCの言っているようなデザインスプリントを見てみると、5日間のうち、3日間は何を作るか?に時間を使い、1日でモノを作って、1日で検証をする。 通常のモノづくりでは、「どう作るか?」よりも「作ったモノが解くべき課題はどれか?」という問題の方が100倍くらい大事だと僕は思っているので、このくらいの割合には納得感がある。

逆に、作ったものが解くべき課題をあらかじめこちらから指定して、それをどう作るか?に集中させる方法もある。 こうすることで、何を作るかに時間を割く必要がなくなり、どう作るか?という技術的な課題にのみ参加者をフォーカスさせることができる。

ここでも目的とやらないことによって実施内容が変わる。

今回はイノベーション起こして云々と言ったものはスコープ外なので、何を作るか?については重視しない進め方にすることとした。とはいえ一方で、自主性というキーワードがあるので、こちらから解くべき課題を指定するような進め方も片手落ちになる。

そこで今回は、半日で作るべきものを決め(これをアイディアソンと呼ぶことにした)、残った時間でそれを組み上げるという時間の使い方にすることにした。 また、経験から学習しそれを身につけるための振り返りと、ある種のプレッシャーとして働くことを期待した発表会を最終日の半日に入れ込むことにした。さらに発表会を盛り上げるために発案者の上司の独断と偏見で優秀チームを選んでもらい、表彰するような建てつけとした。お祭りのような感じで盛り上がる会にしたい。

さらにさらに、経験から学びを得て今後の業務に活かしてもらうことを目指してチームごとの振り返りの時間も確保することにした。

アイディアソンをどう進めるか?

では半日のアイディアソンをどう進めたらいいのだろうか。 想定するターゲットはどうするべきか。

限られた時間の中で、ターゲットに絞って価値を提供するためには、ある程度すでに理解が進んでいるターゲットである必要があると考える。全く普段考えていないようなターゲットだと、相手を理解するところから始めなければならず、時間がかかってしまう。

ということで今回は、我々が普段の開発でターゲットとしている「情シスさん」を設定することにした。

アイディアソンの目的

決まった時間でチャレンジすべき問題を決めきる。ターゲットは情シスさん。

実施方法概要

ターゲットにヒアリングをして困りごとを引き出す。 解決策を考えて、ターゲットに当ててみてフィードバックを得て、ブラッシュアップして結論を出す。

ゴール時に達成したい状況

「〇〇という問題を、△△を利用し××することで解決する」という形で結論を出す。ハッカソンでは上記を実装していく。

具体的な進め方について

具体的な進め方については運営チームでプレ実施を行い、時間的に・仕組み的に無理がないか確認しておくと良い。実際に実施してもらう人たちの気持ちもわかるだろう。今回記載している内容は、プレ実施を行なった結果、あんまり良くなかったねとなり、実際に本番では大きく組み替えた。ここら辺の詳しい話は次回。

1.課題「〇〇」候補の収集 0.5H

ターゲットにヒアリングして解決すべき課題の候補を収取する。 普段の仕事で感じる課題について話してもらう。 話の中から出てくる問題点を「どうしたら◇◇◇できるか?」と言う形で付箋にメモしまくる※。

※ ここら辺はデザインスプリントから拝借している。

ヒアリングが終わったら付箋を壁に貼り付けて、チーム内でお互い共有し、得られたモノの共通認識を作る。

2.サービス「△△」候補の収集 0.5H

世の中で利用可能なサービスを可能なかぎりいっぱい集めてもらう。 これはチームごとではなく、全チームで最終的に共有するのがポイント。

チーム単位で見ると課題候補に近しいものばかり集めることが懸念されるが、それらを集めることでいい感じにばらけることが予想できる。

3.結論案「〇〇という問題を、△△を利用し××することで解決する」を作成 2.0H

1と2を組み合わせて、結論案をチームごとに作る。 組み合わせで考えることによって思わぬ発見やアイディアが生まれる可能性を作り出す。

いくつか結論案を作る。

4.結論案をターゲットに説明し、フィードバックを得る 0.5H

再びターゲットにヒアリングしてフィードバックをもらう。 1発の思いつきで正しい結論に至るわけがないので、ターゲットからフィードバックをもらう。

5.フィードバックを元に、結論案をブラッシュアップし、結論を得る 0.5H

フィードバックを元に、各チームで話し合って、結論を得る。

このように作られた結論「〇〇という問題を、△△を利用し××することで解決する」をハッカソンの中で開発する。

前述の通りこの方法は、プレ実施時点であまりうまく行かなかった。 問題は「お客様の声を聞きすぎてしまい、自分たちがワクワクするものづくりができない」という点だ。 ここら辺の詳しい内容は次回の記事で書くと思う。

会社でハッカソンをやってみた きっかけ編

社内でハッカソンの運営メンバーを経験させていただいたので、その際に考えたこととかの知見をまとめてみようと思う。(所属する組織の意見や考え方ではなく、あくまで私個人の考えや得た知見であるので注意)

今後同じようなフリを受けて悪戦苦闘する人の役にたったらいいなと思う。

先にハッカソン全体の結論だけ述べておくと、やって良かった。とてもとても。

自分の中で、一緒に働くメンバーへの信頼感が大きく育った。 具体的には、なんの制約もない世界だと、普段一緒に働いているメンバーはこんなにもぶっ飛んだワクワクするアイディアを出してくるんだ。と思った。 限られた時間の中でモノを作り上げようとするみんなの姿に尊敬を覚えた。

きっかけ

9月下旬の期が変わりそうなタイミングで上司が席に訪れて「ハッカソンとかやってみたい」とおっしゃった。 「泊まりで温泉旅館とかにこもって、バリバリ開発したら楽しいんじゃないか」とのこと。 ここから全てが始まった。

まずは目的を明らかにしよう

ハッカソンとかやってみたい」ということがどんな目的を持っているのかをまずは浮き彫りにする必要がある。

ハッカソンとかやってみたい」と一言で言っても、純粋になんとなくハッカソンってモノを知って面白そうキラキラってなってるのか、それとも感じている問題がありそれを解決するための方法としてハッカソンとおっしゃっているのか。 背景となる問題があるのであれば、それを解決する最良(つまり最速or最善)の方法がハッカソンなのかどうかなど、急にハッカソンと言われて焦る気持ちを落ち着けて、考えていく必要がある。

これを明らかにするためにまず、なる早でかつ関係者全部入れてMTGをセッティングした。 熱いうちに想いをチームで共有するためになる早で。かつ想いは「単なる事実」ではないため、伝言ゲームしていくと事実より大幅にずれる。なので、キックオフは全員参加で直接一次ソースから全員が熱を受け取れるようにしたい。

このMTGの結果、以下の通りの目的を上司が持っていることを明らかにできた。

  • 技術のアップデート
  • 自ら出したアイディアで開発を進めることによる主体性の発揮
  • 共同で生活をすることでお互いを知る(エンジニア系メンバー以外も全員で参加すること※)

※ なお家庭の事情などで宿泊が難しい人もいるのでその人たちは通いでも可とした

逆に今回目指さないものを以下の通り定義できた。

  • 製品化に向けた実用的なアイディア
  • イノベーションを起こして今後の製品開発に活かす

特にこの目指さないものを決めるという点が忘れがちだが大事で、プロジェクトを進める上での意思決定の重要な基盤となっている。 可能であれば目指すものについて優先順位もつけたかったが、MTGの中で「ごめんこれらの優先順位は決めきれない」との宣言があり、優先順位づけは諦めた。

なお、これによりトレードオフ(特に以下の2点)の場面での意思決定の難易度が上がった。

  • 技術のアップデート
  • 互いを知る

技術を磨くことを目的とした場としつつ、エンジニアでないメンバーにとってもプラスになるような場を作るという点が、このプロジェクトの一番の課題となった。

目的を受けてやるべき内容を考える「本当にハッカソンなのか?」

例えば共同生活により互いを知ることが目的なのであれば、ハッカソンではなく一緒に宴会をしたり、社員旅行(部署旅行?)をしたりすれば良い。ハッカソンの準備とかすげえ大変なので、これが最良の選択肢になり得るだろう。

目的によってはハッカソンまで行かなくてもアイディアソンの実施でも良いかもしれない。 みんなでユニバに行こうとかでも解決案になりうる。ユニバはとても楽しい。

今回は技術的なアップデートなど様々な点から検討し、ハッカソンが一番目的を達成できるだろうということでハッカソンに決定した。

今回はここまで。

JDLAのG検定に向けて_3

JDLA(日本ディープラーニング協会)のG検定というのが12/16(土)に実施されるようです.

ディープラーニングを事業に活かすための知識を有しているかを検定する」を目的としているようなので,事業に活かすための知識を得るためにはこれを取得するために勉強するのも良いかと思ったので,ちょっと勉強してみようと思います.

http://masamasa.hatenadiary.jp/entry/2017/11/12/125725の続きです.

この記事はシラバス人工知能分野の問題」について,参考図書「人工知能は人間を超えるか ディープラーニングの先にあるもの」をもとにまとめて見ました.

トイプロブレム

明快なルールがあり,非常に限定された状況下での問題. 現実的に解く必要のある問題に比べて比較的単純であり解きやすい.

フレーム問題

知識の応用時における選別に関する問題. 自分の状況や解きたい問題に関わる知識とそうではない知識を機械は簡単に判別することができない.

そのため,持っている知識全てを思考しないといけないので,レスポンスタイムがかかりすぎたりして実用に耐えないという問題.

弱いAI/強いAI

知能や心の原理を解明して工学的に作り出すのが強いAI. 心をもたず,限定された知能によって一見知的な振る舞いをするのが弱いAI. 中国語の部屋は弱いAIの典型的な例.

身体性

AIに体を持たせることで,記号とモノとを紐付けることを可能にし,シンボルグラウンディング問題を解決できる という考え方.

シンボルグラウンディング問題

記号とモノを紐づけることができるか?という問題. 例えば「シマウマは縞模様の馬である」という知識を持っていたとして,かつシマウマを見たことはないとする.

人間は初めてシマウマを見た際に,その特徴から「これがシマウマか!」と気がつくことができるが,機械はそれができない. 「縞模様」や「馬」という概念について記号とモノが紐づいていないことが要因.

特徴量設計

画像認識などのタスクを実施する際に,Inputとなるデータの何に注目して判定したらいいか?という特徴量を いかに定義するかがこれまでの機械学習の分野では大事な点だった.特徴量を定義することを特徴量設計という.

特徴量の設計は,従来の機械学習の分野において精度にダイレクトに反映される重要な作業であり,研究者の腕の見せ所だった.

DeepLearningではこの特徴量の設計を人間がする必要がなく,機械がデータから特徴量を学びとることができ,特徴量設計を 技術者が行う必要がなくなった.

DeepLearningはこの特徴から,特徴表現学習とも呼ばれる.

チューリングテスト

アランチューリングによって提唱された,AIのテスト. テスターが人とAIとそれぞれ会話し,AIを人と誤認させることができるか?というテスト.

2014年にユージーン・グーツマン君というAIが史上初のチューリングテスト合格者となった. 13才の非ネイティブスピーカという設定が付けられており,テスターのハードルが下がったこともこの結果に影響していると思う.

シンギュラリティ

技術的特異点のこと. AI自身が自分より賢いAIを作り出せるようになる点をさす.

AIが自分より賢いAIを作り出すようになると,そこから発散的に賢いAIがAIによって作成されるようになる. 自身を基準として賢さが0.999のような値であれば1000回かけ合わせると0に近くが,1.001のように1.000を越えると無限大に発散する.

このように,AIが作り出せる賢さが1を越える点が特異点である.

JDLAのG検定に向けて_2

JDLA(日本ディープラーニング協会)のG検定というのが12/16(土)に実施されるようです.

ディープラーニングを事業に活かすための知識を有しているかを検定する」を目的としているようなので,事業に活かすための知識を得るためにはこれを取得するために勉強するのも良いかと思ったので,ちょっと勉強してみようと思います.

http://masamasa.hatenadiary.jp/entry/2017/11/12/125725の続きです.

この記事はシラバス人工知能をめぐる動向」について,参考図書「人工知能は人間を超えるか ディープラーニングの先にあるもの」をもとにまとめて見ました.

探索と推論(第一次AIブーム)

推論

人間の思考過程を記号で表現し,実行する

探索

様々な選択肢のパターンを網羅するように木構造を作り(これを探索木という),どんどん場合分けを進めていくことで 最終的にゴールにたどり着くような方法.

例えば,迷路を解くときに,それぞれの選択肢をとるとどんな状態になるのか?をどんどん木構造で表現していき, ゴールにたどり着くまで続ける. 深さ優先探索とか幅優先探索とか戦略は色々ある.

プランニング

プランニングと呼ばれる,ロボットの行動計画も探索木で作ることができる. 前提条件と行動と結果からなるノードをそれぞれつなぎ合わせることで,最終的に目的達成にたどり着くことができるというもの. 仮想的な世界においては,これは一定の成果を納めるに至った考え方.

だが,探索では迷路や将棋など明確に定義されたルールに基づく問題は解くことができるが,現実的に解きたいような応用問題を解くことが できなかった.現実の問題は複雑すぎたり,ルールが明確でなかったりするので.

これにより期待がしぼみ,第一次AIブームが終わった.

知識表現(第二次AIブーム)

第二次AIブームでは,工場や現実の産業への応用が始まった.

エキスパートシステム

大きな役割を果たしたのは「知識」である. 特定の専門領域の知識を大量に取り込み,推論を行うことで,ある特定の領域におけるエキスパートのように振る舞うことができる ようになったエキスパートシステムというものが作られた. 例えばMYCINというシステムは田先生の血液疾患の患者を診断して適切な抗生物質を処方することを目指す.

この頃のAIには知識を入れるのにコストがかかるという課題や,知識自体の矛盾解決など維持管理が大変だという課題があった.

実際,より汎用的な一般常識を知識として表現しようとするCycプロジェクトというプロジェクトが立ち上がり,実施されているが, 30年経った今でもまだ完遂されていない.

オントロジー研究

さらに,そもそも知識を正しく記述するのが難しいという問題もあり,オントロジー研究という分野が生まれた. その中でもウェブデータの解析などを通して,人間が知識を与えるのではなく機械が勝手に知識を獲得するための方法の研究分野を ライトウェイト・オントロジーと呼ぶ.Wikipediaからライトウェイト・オントロジーで知識を生成し,成功を収めたのがIBMのワトソンである.

知識利用の難しさ

ところで,知識をいっぱい溜め込んだとしても,機械はその意味を理解しているわけではないため,機械が知識を扱うということはかなり難しい問題になる.

フレーム問題

機械は解こうとしている問題に対して知識を活用し解決策を推論するが,解こうとしている問題や背景と関係のある知識なのかない知識なのかを 見分けることができない.

そのため,持っている知識全てについて考え始めるため,知識の量が増えるに従って,機械が考える領域が広がり, 実用に耐えるレスポンスタイムを得ることが難しい.人間は関係のある知識とない知識を無意識に選別できるが,機械はこれができない. これをフレーム問題と呼ぶ.

シンボルグラウンディング問題

知識として得られた概念(記号)と実際のモノを結びつけることが機械はできない.

「シマウマは縞模様の馬である」という知識を得たとしても,それぞれが実際のモノと結びつかないため,例えば人間が 初めてシマウマを見たときに,前述の知識から「シマウマってこれか」と思いつけるが,機械はそれができない.

このような問題をシンボルグラウンディング問題と呼ぶ.

これを解決し,モノと概念を結びつけるためには,「身体」をもつ必要があると主張する科学者がいて, そのような考え方に基づいた研究を「身体性」に基づく研究と呼称する.

機械学習

プログラム自身がデータから学習する仕組みのこと. 大量のデータの中から,例えば分類タスクの場合は「分け方」を見つけ出す. 分け方の見つけかたには色々あるが,なんにせよ,分け方を見つけ出す.

分け方を見つけ出す作業を学習と呼び,これには大量のデータを対象に長い時間をかける必要がある. 一方で,得られた新しいデータを分ける作業は一瞬でできる.

機械学習にも問題があり,それは分けるためにどの情報に着目したら良いか?は人間が決める必要があるという点だった.

注目する情報のことを特徴量と呼ぶ.例えば画像認識であればエッジに注目したり,尖った部分に注目させたりといったような特徴量を人間が設計してあげるしかなかった.

この作業が結局キモになる作業であり,高い技術力と時間をかけて調整する必要があるものだった.

深層学習

2012年の画像認識コンペ「ILSVRC」にてトロント大学が革命を起こした. エラー率で10%以上の大差をつけて,優勝した.

これまでは,いかに特徴量を設計するか?という点で各研究機関がしのぎを削っていたが,トロント大学はこの特徴量を機械が自分で見つけ出すという方法で大きな成果を出した.

これが深層学習であり,上記の通り特徴量を機械が自分で獲得することから,特徴表現学習とも呼ばれる.

特徴表現の問題は第一次AIブームや第二次AIブームで問題になっていたような問題の根本にあった課題であり,これに対する回答が示されたため, 機械学習の分野の大きな飛躍が期待されている.これが現在の第三次AIブームに繋がっている.