Tweet

新聞、テレビ、Webと、毎日のように人工知能関連のニュースが流れているが、この業界で働いていて概要も知らないんじゃ恥ずかしいだろうということで、やっと私もこの領域に足を踏み入れてみました。

人工知能。はっきり言ってこの分野を本気で勉強したらいくら時間があっても足りないので、資料作成というか当日どこまでやるかを決めるのに本当に悩みました。テーマも当初は『AIのビジネス化に向けて』ではなく『人工知能とディープラーニング』とし、勾配降下法の説明やニューラルネットワークをPythonで作ってデモしようとか色々考えてましたが、当日が近づくに連れて、まず自分の勉強が追い付いていないことに気が付くわけですよ。（笑）たとえ追いついたとしても今度は資料を作成してる余裕がない・・・これは駄目だ！ってことになり、若干テーマを変更。今回は、AIをこれから学びビジネス化するためのきっかけになる回になれば良いかなと思い、アジェンダとしては「人工知能の歴史」、「人工知能の概要」、「機械学習の利用」、そして「ビジネス化に向けて」の順番でまとめることにしました。

まず歴史では、人工知能という言葉が生まれた1956年のダートマス会議から現在、そして未来までの主な出来事を並べてみました。これまでに何回か人工知能のブームがありましたが、やっぱり2012年のディープラーニングの活躍あたりからが本当のブームかなという感じがします。

次に概要ということで、機械学習、ディープラーニング、そして強化学習について簡単に説明しました。この辺は、どこまで深くやるかが難しいところで、突き詰めると偏微分とか行列とか高校・大学レベルの数学が出てきてそれこそ大変ですが、今回はAIのキックオフ的な回として、深過ぎず朝過ぎず適度な感じに纏められたのではないかなと思います。

機械学習の利用では、Watson等のサービスや機械学習クラウド、TensorFlowやScikit-learn等のフレームワークはこんなのがありますよという紹介程度とし、使った人がいたらディスカッションしようかなと思ってました。

最後にビジネス化に向けてということで、見積り、契約、権利についてまとめてみました。この3つ（見積り、契約、権利）を出した時点で、ボスには何の本を読んだかバレてたようです（笑）そう、『人工知能システムを外注する前に読む本』です。上記3つの観点で解説した書籍は他にあまり見当たらないため、貴重だなと思い取りあえげてみました。というか、この本があったから今回のテーマに変更したのもありますね。。。

発表はスライド70ページを1時間位で、残り1時間はディスカッションというほぼ予定通りに進めることが出来ました。これから急速に発展していく分野だと思いますので、チームで情報共有しながら何かビジネスに繋げられるよう今後も学び続けて行こうと思います。

シンギュラリティはもう始まっている・・・

Tweet

台風直撃中の日曜昼下がり。
皆さんいかがお過ごしでしょうか。

さて今回の勉強ですが、某社で開催された講習内容の社内展開という形で実施しました。受入検証と一言で言ってもただ漠然とテストをすれば良いというものでもありません。
品質、目的を明確にし、『効率的、効果的かつ網羅的』に行うことが大切です。品質に関する仕様、要件の決め方について共感する部分がありました。改修内容は上層部の鶴の一声で決まることがある、上層部（ベテラン）は色々な機能を詰めたがる、結果初心者には使いづらいシステムとなることが多いということ。共感できました（笑）。また、仕様か不具合かで揉めることが多々あるそうで、開発ベンダへ文書等で明確に伝えること、ベンダも仕様理解に努めお互いに歩み寄ることも重要です。

テストの基本はテスト段階で不具合を発見し、運用開始後、ユーザ業務に支障が出ないようにすることです。今一度、受入テストの本来の目的を考え、テスト内容の見直し、テスト準備等を行っていこうと思いました。自分事ですが、年内にも新システムの検証を控えています。NO障害で行きたいと思います！！

以上、またテーマがあれば司会立候補しようかなと思う今日この頃でした。

Tweet

気付けばもう50回…
思えば遠くに来たものだ…

　さてさて、今回の勉強会はテスト駆動開発と題して、開発手法の一つである、テスト駆動開発をする上でのメリット・デメリットなんかをデモを交えながらやっていきました。テスト駆動開発はテストファーストで、まずテストコードを書いていってその後プロダクトコードを書くってのが一番の特徴になります。テストがまずは書かれるので、何がしたいのか仕様が明確になるってのと、テストが通っているってことで、コードのリファクタリングがしやすくなるというメリットがあります。でも、当然コードの量が増えるので、短期的に見るとコストが掛かる手法であり、仕様そのものの間違えていたら、テスト結果も間違えますので、バリバリコードが書ける人に取っては面倒くさい手法とも言えます。

単体テストってしていると思うのですが、普段はどのようにやっていますか？

　昔からのソフトウェア会社では、割とエクセルにマトリクス表みたいなのを作成して、1件1件パターンを人間が入力しながらやっていったりしているのがあるのではないでしょうか。このマンパワーを駆使した方法って、NGパターンが見つかったらもう一度やり直ししたり、エビデンスとして画像をエクセルに貼り付けたり、貼り付ける画像がちょっと失敗したらもう一度やり直したり等非常に手間がかかっている事が多かったりします。
　テスト駆動開発とは若干外れるのですが、テスト駆動開発をやる上では、VisualStudioやEclipseなどの統合開発環境にはこういったテスト支援ツールが導入されているので、テストコードを書くことで、こういった処理が自動化出来るので、戻りの手間が少なくなるという副次的な効果もあったります。
　今回のデモでは、Eclipseを使ってJUnitのデモをやってみたり、Seleniumを使ってWebUIテストの自動化のデモをやったりしてみました。JUnitのデモはライブコーディングをしながらやってみましたが、うーん。。。見ているだけで終わってしまった感じがして若干残念な感じがしました。その後、最近のプロジェクトでテスト駆動開発を利用したので、その感想をプロジェクトメンバーから話してもらってディスカッションをしていこうと思いましたが、デメリット面が強く出てしまった感じもして、企画倒れ的な感じになってしまって。難しいですねぇ。。。
　ただ、今後は積極的に導入していきたい手法ではあるので、この機会に触りだけでも感じていただければ良いのかなと思いました。自分自身ももう少しテスト駆動開発をやる上でのスキルを上げていかないといけないかなと実感したり。

それでは今回はこのへんで。
次回もテスト絡みのお話になるかと…。