このコースの概要部分を受講したので、備忘録としてエントリをあげておく。このコースはGoogleが提供しているコースで、似たようなコースにCrash Courseというものがある。Crash Courseはどちらかというと手を動かして学ぶ開発者向け。それに対して、このCourseraのコースは機械学習を導入したい組織向けのコースといった印象。機械学習のライブラリの使い方にはそんなに触れず、どうやって機械学習を組織として取り入れていくかがしっかりと説明されている。これを見ると機械学習はAIエンジニアを入れたらすごい成果が得られるのではなく、組織としてどうやってデータを集めて、検証サイクルを回せるようにするかが重要であるように思う。

機械学習の導入には、データがまだない、学習ループが全自動、自前主義などの10個の落とし穴がある。
1人の貢献者、委任からデジタル化、ビッグデータ、機械学習という経過をたどる。
ビジネスプロセスをデザインする際に、フィードバック、インサイト、調整を組み込む#HowGoogleDoesMachineLearning
— かざいむ＠三重 (@kazaimu_) 2020年4月19日

MLに至るステップについて、その内容とスキップした際の危険性、そのステップで足踏みする危険性を説明していた。
ステップは以下の通り。
１．1人の貢献者
２．委任
３．デジタル化
４．ビッグデータ・アナリティクス
５．機械学習 #HowGoogleDoesMachineLearning
— かざいむ＠三重 (@kazaimu_) 2020年4月21日

この辺りの考え方が最近気になっているキーワードDXの真のゴールになるのじゃないかと思う。単純に技術を使うのではなく、どうやって検証をして、改善していくか、そのためにデータをどのように利用するか。DMMの松本さんがDXについてNoteで書いていて参考になる。

note.com

本編に戻ると、このコースでは、どのように組織に機械学習を取り入れるかが丁寧に説明されている。よくイメージされる、ぱっと自動化されるというのは実際には最後の方のステップで、まずその仕事の手順がはっきりしていて、複数人で分担できる、手動で分析ができるなどを経て最終的に機械学習が導入されるとのこと。

また、機械学習では現実の世界に存在するバイアスが反映されるのでそれについても意識的に対策を促していてとても勉強になった。例えば、特定のポジションの採用を機械学習にした場合、これまでにたまたま男性が就いていることが多かった場合、男性を優遇するよう間違えて学習してしまうことがある。

機械学習ではこういった点に自覚的に取り組むべきとのこと。

2020-05-27

JAMStackとは。

最近関心をもって進めているものがJAMStackと名付けられているのが分かったので、ちょっと調べる。興味のきっかけはGatsbyJSという静的Webサイトのジェネレータ。描画がとても早いので面白いなと思ってちょっと自分でもチュートリアルを見ながら調べたりした。

JAMStackとは、LAMPやMEANと同じように、構成する要素の頭文字を取った、アーキテクチャパターンの一つ。それぞれJavascript、API、Markupを表す。この名前はNetlifyの人が考えたが、名前は後付け。今はこんな感じの定義らしい。

Fast and secure sites and apps delivered by pre-rendering files and serving them directly from a CDN, removing the requirement to manage or run web servers.

Jamstack | JavaScript, APIs, and Markup

そもそもの動機としてはWordpressがその脆弱性で攻撃されたり、レスポンスをより早くしたいというニーズがあった。また、クライアントでゴリゴリ描画するSPAが、レスポンス面で遅い、Googleの検索エンジンに上手く引っ掛からないという課題があり、サーバー側での描画を行うSSRが解決策として提起されていた。

Gitでリソースを全部管理できて、GitHubとかにコミットしたら、HTMLの生成処理が始まって、ホスティングサービス上に生成済みのHTMLが展開される。このホスティングサービスや、連携したCDNサービスを通じてレスポンスの早い、堅ろうなWebサイトを提供するものというイメージ。

同様のフレームワークにはNext.js、Nuxt.js、Hugoなどがある。こういった形式でのホスティングを提供しているのが、Netlify、GitLab Pages、GitHub Pagesあたり。Webサイトの内容のみを管理するコンテントフルなどのサービスもあり、より柔軟な管理ができるようになっている。

www.gatsbyjs.org

employment.en-japan.com

developers.google.com

Microsoft Buildでも同様の取り組みとして、Static Web Appsが紹介されてにわかに勢いがついているように感じる。Microsoftのサービスも試してみたい。

コード記述で提供される近道は糖衣構文、エディターで提供される近道はショートカットキー

タイトルそのままだけど、Visual Studioについてのブログエントリを見てちょっと話がつながったのでエントリにしておく。

前にこんなツイートをした。

糖衣構文
同じ内容の記述をより簡潔に記述する手段を指す。面倒なものを飲み薬の糖衣のように飲み込みやすいものでくるむ。
・裏にある定型の記述を理解することを脱糖衣 desugar
・人への苦言も糖衣が必要https://t.co/CYJpIKjL98 https://t.co/eyRNOJZw30
— かざいむ＠三重 (@kazaimu_) 2020年5月9日

糖衣構文は面倒な定型的な記述を簡易にするもので、ループが簡単に書けたり、データ操作が簡単に書けたりする。で、このVisual Studioについてのブログを読んで、すごいと思うとともに、これもある意味糖衣構文だよなと思った。

blog.okazuki.jp

このブログで紹介されているショートカットを使うとするするとコードをきれいにできる。これって、ちょっとしたコーディングだけど、自分でしなくてもいい。

そう考えると、自分で考えるからコードまでの距離はどんどん近くなっている。

さらに、最近はNoCode開発とか言って、いろんなサービスを組み合わせて設定をするだけでサービスが作れるというのもできている。これはサービス開発のショートカット。

2020-05-17

ちょっとだけプログラミングのプロセスの改善をした。

ここ数日慣れないPythonでグラフを出力するコードを書いてたけど詰まりながらも途中で軌道修正できたので、その中で気づいたことを書いておく。

f:id:name_untitled:20200517003341p:plain — Pythonで出力したグラフ

言いたいことは大体こんな感じ。

制約をベースに手段を考える
具体化は出来るだけ遅らせる
ドキュメントから関連するものを漁る
実現方法は何パターンか考える
おもちゃを用意してこねくりまわす
機能分割は無意識にやりがちなので気をつける
コードではなく思考プロセスを振り返る

昨日久しぶりにやや手探りでPythonでグラフを書いたけど、前回はまったので注意しようと思った。前にも数回Pythonでちょっとしたコードをかいたことがあるけど、毎度毎度けっこう引っ掛かってはまってしまう。この時の考え方に癖やはまるポイントがあると感じたので、投稿。

背景として書こうとしたコードの説明をする。模擬試験を受けられるサイトがあり、試験結果をCSVファイルでダウンロードできる。これが、1問1行で学習日、分野、正誤のデータを持っている。この過去の試験の正答率の推移を折れ線グラフでプロットしようとした。

自分の持っている地図が合っているか確認する＝公式ドキュメントをあさる

プログラミングが少し分かると自分の手持ちでやろうとしてしまう。今回もそこから手順を考えてしまっていた。C#の経験が長く、C#でもうっすらLINQまでで最近の文法はあまり追っていないので、C#をベースに考えそうになった。前回もやりたいことのキーワードをいくつかググってごちゃごちゃ組み合わせたが、けっこう無駄が多かったように思う。

問題となるのは、現在持っている言語の知識が今取り組んでいる言語やフレームワークに適合するか分からないことだ。ググるスキルが上がってピンポイントで調べて、一歩先に進むのが早くても、違う言語なら地図も違うはずで、頑張った末に行き止まりになってしまうこともある。逆に方向性が合っていれば、一発解決の可能性もある。

この問題には今回以下の考え方で進めた。グラフに出す場合はどのように呼び出すかでデータの形が決まるので、そこが制約になる。固い制約があれば、そこはぶれないのでロスは少ない。

また、取り組んでいる途中で前にやった機械学習のコースをちょっと思い出した。その動画では講師が何度も公式サイトのドキュメントやサンプルを紹介していたように思う。これは多分意図的で、公式ドキュメントでその言語やフレームワークでのキーワード群を押さえるとググるキーワードがその言語向けに良くなる気がする。まずはキーワード＋ライブラリで検索をかけて、ライブラリの公式ドキュメントで関連する部分を探す。そこからブログなどを探すとまずまず良かった。

この問題に長期的に取り組むにはよく言われている毎年１つ新しい言語を学ぶことなのだと思う。ToDoアプリを作ると一通り新しい言語が分かると聞く。ToDoアプリを目的にすると、上のようなその言語やライブラリの特徴を逃しそうな気がする。その言語らしく書くにはどうすればいいかはもう少し調べた方が良さそう。

機能分割は無意識にやりがちなので気をつける、実現方法は何パターンか考える、具体化は出来るだけ遅らせる

手段を考えるときに思いだしたのが、国際協力の分野での問題解決手法。ゴールを決めて、そのために必要な状態を書くのだけど、ポイントは具体的なアクションではなく、実現したときの状態を書くというもの。

最終ゴール：グラフ表示

サブゴール１：ファイル読み込み

サブゴール２：データを１つずつ読んで、XXXする

ではなく、

最終ゴール：グラフ表示

サブゴール１：ファイルの内容が取得されている

サブゴール２：データがXXXな状態になっている

これは、単に表現の問題のように思うかもしれないが、下の形で考えておくと、１つの手段で詰まった時に代替案を考えやすくなる。

これに関連して、具体策を探すのは、出来るだけ遅らせるか、すぐに結果が出せるようにするのがいい。あまり詳しくないものを時間をかけて調べると結果が出づらい気がする。これは、下のおもちゃの話に関係する。

おもちゃを用意してこねくりまわす

『アプレンティスシップ・パターン: 徒弟制度に学ぶ熟練技術者の技と心得』では壊していいおもちゃ、すぐに取り換えのきくサンプルコードを用意する。いきなりファイルを読み込んで表構造のデータを作成するじゃなく、ベタうちの表構造データを数件用意するとかがいい。あとは、おもちゃとおもちゃは分ける。検証したい処理が3つあったら、それぞれ別々に簡単に動かせるコードを用意して、動作を確認してから、組み込む。そうすると、一つが使えなかったらすぐにべつの実現方法に切り替えることができる。

コードではなく思考プロセスを振り返る

問題解決手法の中では解決した状態をゴールとして、〇〇が実行されるとはしない。これは手段の目的化を避けるため。目的から手段を考えると、いろんなオプションが考えられる。
こういうプロセスをふりかえるのが大事で、考えはすぐに消えてしまうのでやる前や詰まったときにメモを取ると良さそう。こういうプロセスの改善がパフォーマンスに大きく影響するように思っていて、プログラミングではライブコーディング（練習なしの）やペアプロ、モブプロがそれにあたると思う。ライブコーディングはYoutubeとかを探しても良さそう。