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

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

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

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

たとえば?

「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ブームに繋がっている.

JDLAのG検定に向けて_1

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

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

資格試験っていうとなんかこう色々思うところはありつつも,勉強する過程である程度まとまった知識が得られるという点は利点だと思いますので活用します.

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

人工知能とは何か

一言でいうと「人間のように考えるコンピュータ」のこと. 1956年のダートマスで開かれたワークショップにて生まれた言葉であり概念.

人工知能は作れるのか?

脳は電気回路のようなものであり,思考はなんらかの計算であると捉えられる. その場合,アルゴリズムで表現できるものはチューリングマシンにて実行することが可能なので,人工知能は作れるはずだ.

知能理解へのアプローチ

構成論的アプローチ

脳を作ることによって知能を理解することを目指すアプローチで,人工知能の研究はこちらのアプローチである.

分析的アプローチ

脳を解剖学的に理解するアプローチである

強いAIと弱いAI

人間の知能の原理を理解し,それを工学的に再現するAIを強いAIといい,限定的な知能によって一見知的な問題解決が行われれば良いと言った スタンスのAIを弱いAIという. 中国語の部屋のようなAIは弱いAIである.

とりあえずこんなもんかな?