  |
はてなキーワード: Pythonとは
とりあえず、ここで伝えたい事はブコメやトラバで「皆さんのおすすめの本を教えてください」ということです。
↓以下駄文
学内に無線が通ってないどころか、作業スペースも1GB もないからUSBを持ち歩かなきゃいけない。
というのはまあ慣れるんだが、図書館に本を借りて勉強しようとしても、情報系まともな本が置いていない。
大学の利点といえば、高い本をただで何冊も読めることだと思っていたのに、なんだCS5のフォトショやイラレ、2010年頃のMOS教本ばかりが並んでいる。
挙句の果てにはiPhoneの使い方などの本ばかり。高校のほうがもっとマシな本が置いてあった。
ということで最近、友達と結託して図書館に何冊か技術書などを買ってもらえるように届け出を出している。
最近届け出を出して入った本は、リーダブルコード・入門 Python 3・みんなのPython・Gitが、おもしろいほどわかる基本の使い方33・Atom実践入門など色々ある。(友達が凄い出してたけど、僕はあまり把握しない)
僕の周りはとりあえずPythonで適当な数学の計算とか、あわよくばアプリ開発などをしてみようと思って活動しているからPythonの本の届け出が多い。
だけど、他の知り合いや他ゼミの子の話を聞くと、プログラミングをしたいけど何から始めたら良いかわからないと言う子が多かった。
だから、何をしたいか決めて、言語も決めて(気に入らなかったら変えても良い)とりあえず何か初めてみようと言う提案をした。
僕自身Pythonの次はRubyもやってみたいと思ってるから、もっと他の本も欲しい。
こういう活動をしていたら、情報系の学部生はあまり図書館に届け出をしないらしく、だから本が足りないと司書の方に教えてもらい、何か必要な本があればドンドン教えて欲しいと言っていただけた。
だから、大学で初心者から上級者までとりあえず幅広く(出来ることなら就職してからも苦労することのないように）対応できる本を入れてもらえるように申請を出そうと思ってる。
でも、僕の知見は広いとはいえず、出したのもそのGitなどの本ぐらいであんまり貢献できてない。
ーーー
あー、Cの縛りがあるのか...
(Rで1コマンドで済みそうだが...)
Cによる統計ツール作成の社内開発案件にしろよ！(RとPythonの件は伏せる)
そうすりゃ1年ぐらいせっせと車輪作って、
元々コンサル会社から事業会社のほうでデータサイエンティストをやるようになって１年経つが辞める。そのきつかったことを匿名という場所で卑怯ながらも話したいと思う。
元々私は大学院でそこそこ統計をやってきてから、コンサル会社に行きデータサイエンティストとして事業会社へ移った口だ。
根本的にデータサイエンティストとしての資質としてざっくりいうと以下の３つが必要だと思われる。
2. KPI設計及び事業からのKPIへの落とし込みからそのKPIからどう事業繋がるかというビジネス設計能力
私能力的には１がやや強く、その次に２がまぁまぁそして３はまだまだといった所で事業会社でデータサイエンティストとして孤軍奮闘をすることになった。
データはあるが、なかなか活用できていないこともあり、分析から企画から関われるという事で入社しようと思った。
後そこそこ大きな会社で働くのも良い経験と思い入社を決意した。ニッチな分野ではあるが、この分野ではTopカンパニーである。
最初の４日ぐらいは会社の研修とかで潰れるのは仕方ないもので、それが終わり早速の業務を行う事になった。
貰えない。
許可申請の関係で３週間程かかってからまず最初にデータを頂けるようになった。この時点でやる気を削がれた。
更にデータの確認という事で事業へのヒアリングを進めるだけで・・・６週間程かかった。更にやる気を削がれた。
この辺りで気付いた事だが、コンサル会社でいたときは、データの確認がスピィーディーだったのに何故こんな遅い作業なったかというと
日本の企業は部署跨ぐというのはとても大変で、コンサルとしてやっていたときは単価も高いし、期間内でやらないといけないという事で
いろいろと調整がスムーズに進んでいたという事がこの時に分かった。コンサルとして外から見ているとやはり分からない事は多い物である。
データの確認も終わり、分析をし、改善を行うテーマを決めて進める事になった。この時点で２カ月ぐらい過ぎていた気がする。R/Pythonの自分のパソコンへの許可申請を出すが、降りない・・・。会社的にはCならばOKだと言われる。でもCの追加ライブラリーの関係はダメらしく・・・悩んだ結果エクセルを基に分析をする事になった。現状把握のために基礎集計をするが、エクセルでSQLで言うGroup_byやら違うデータ同士をくっつけるためのJoinを32 bit エクセルで関数ベースでやると何度も落ちる・・・。この時点でやる気は地の底へと落ちていた。
この辺りでCベースでもう書き直そうかと悩むが、流石にCのライブラリーがない所でフルスクラッチ調に書くのは工数的にかかると考えたのでvbaを用いていた。
エクセルベースでの可視化から上司や関係者にデータの分析の結果を見せていく。この辺りでデータ分析から改善策はまとまっていた。しかしこの辺りでやる気をマイナスにして頂ける言葉を伺う。
私がVBAを書いているのをちらっと見て
「プログラミング何かやっていても仕方ないし、プログラマーではねぇ・・・。今後会社ではプログラマーなんていらないから企画できるようにならないと」
勿論これは直属の上司からのお言葉ではないが・・・正確には同期であるが・・・もはや殺意すら覚える。因みにこの人の既存サービスの改良プロジェクトが回った時のデータを収集したら分析する事になっていたが、プロジェクトのスケジュール感を見ると
開発 4カ月
運用以降
みたいな形でうん？何か少なくないか？と思ったら既存のサービスに関してのギャップ分析無しに既存サービスの改良を進めているらしい
・・・その上取れるデータは〇〇〇で〇〇〇は無いらしい。あっそんなん改善出来んやん・・・。一応私はアリバイ工作のためにメールや会議にて発言する
が・・・空気を読めないと言われ会議呼ばれなくなってしまう（因みにこのプロジェクトは要件定義から運用以降まで外注である）。
私のコンサル的な能力がなかったと言えば確かにその通りである。でもいやうん日本の企業の中で、分析をやっていくのは本当に難しいというのがよくわかる。
一人だったというのもある・・・でも殆ど基礎集計レベルで難しい用語を使わずに改善を行おうとしたいやでもこの日本の企業では無理だった。そしてやりたいと思わなかった。
たまに日本の企業でのエンジニアの不遇差を嘆く記事を見かけるが、割と同じようなパターンの臭いがする。
追記
２００万ｐｖの会員サイトでAmazon aws料金を月々リザーブドインスタンスで８０万ぐらい払っていてクラウド安くないと社内的に炎上しているらしい。どんな設計したのかは
もはや手をつっこみたくないレベル。
客先常駐のSES派遣で体壊して２年のブランクを経て求職中の31歳男なんだけど、本当に人手不足なの？って思うくらい決まらない。
SES派遣時代は事務的な仕事（資料のコピー・書類整理・元請けの新卒受入れの準備・資料の配布と更新）ばかりでしかも残業が終電近くまであった生活を１年。
夜勤ありの24時間365日年中無休の2交代制（夜勤メイン・明けは昼過ぎまで残業あり）で体壊した。
転職活動してても会ってもらえるのは特定派遣と「未経験者歓迎！」「アットホームな会社です！」「ネットワークエンジニア募集！（何してるか不明）」「エンジニア募集！（何してか不明）」の自称SIerばかり
知識の更新のためにLPICのレベル2とCCNAとマイクロソフト認定ソリューション アソシエイト (MCSA)のWindows Server 2012も取得してみたのに面接で聞かれるのは経験とか経歴ばかり・・・・
SES派遣時代では技術に触れることがほとんどなくて端から見ていた記憶をつなぎ合わせて面接で話したりしてるけどそこそこ名の知れた企業はダメ（不採用）
でも客先常駐のSES派遣メインと思われる企業に行くと採用通知が届くけど行きたくない、劣悪な労働環境が目に見えて予想できる所ばかりなんだ。
プログラマはどうなのか聞かれるけど、自分には向いてないと思う。
理由は専門学校・職業訓練・eラーニングでjavaやPythonなどを学んだりしたのだが、Cとjavaはifとかelseの段階で理解不能で講師に聞きまくっても理解できず講師に匙を投げられPythonも同様に講師に匙を投げられ
eラーニングでは、はてブで見つかるおすすめjava参考書を使って勉強してもまったく理解できなかったから本当に向いてないんだと思う。
ただlinuxのコマンドは少しわかるしCiscoのネットワーク製品も少しは使えるしwindowsサーバーに関しても構築くらいはできる自信がある、でも見向きもされない。
IT業界って本当に人手不足なの？ハロワで見つかるクソみたいな会社の中から少しでもクソくない会社を選ぶしかないのだろうか。
3年前の大学4年生の4月、まだ内定がなかった。同じゼミの就職希望組は全員内定があったこともあり、相当焦っていた。大学内で会社説明会が行われる時は積極的に参加した。5月に最初に内定が出た。自分は内定が出たことにより安堵してそれ以降の就職活動はやめてその会社に行くことにした。
2年前に入社式があり、当時は社内でプログラミングし、何かシステムを作るんだなと漠然と思っていた。だが現実は違った。入社式のあった週の金曜日に大阪に行くことになった。大阪に行き面談し、客先での了承が降りればその会社が勤務先になるのだと言われた。当時は相当混乱した。IT企業に正社員で内定=社内で作業と思っていたのだ。実際に金曜日に大阪のある会社に行き面談を行った。面談で言われたことはCは出来るかということや長時間働くことは出来るかのような内容だった。自分はCに関しては大学の授業でやった程度なら出来ると答えた気がする。それ以外のことは確か元気が無さそうに否定的なことを言った気がする。正直もうほとんど覚えていない。結果その会社に行くことはなかった。
次に別の会社に面談することが決まった。2社目の面談が決まるまでは社内でCの勉強をしていた。面談ではpythonは出来るかと言われた。当時の自分はpythonをやったことはなかったが一生懸命がんばりますと言ったら受かった。2週間後からはその会社に派遣契約で行くことが決まった。そしてここは8ヶ月で終了となった。この8ヶ月間はほぼ客先に行き、自社に行くことはなかった。
次の会社に面接するのは2ヶ月後だった。Androidの開発のプロジェクトに参加するということで、大学の授業でJavaの勉強をしていたのでそこに決まった。だがここで主に行ったことはCentOSの環境構築とドキュメント作成だった。Javaはほとんど使わずに5ヶ月で終了となった。この会社はおそらくSES契約だった。SES契約についてはあとで説明する。ここにいた5ヶ月間もほぼ客先に行き、自社に行くことはなかった。
3社目はC#を使う会社だった。小規模な社内で使うツールを1から開発するというプロジェクトで技術者的に成長できるだろうと思っていた。このプロジェクトも客先での作業だった。ここで作業していて最初は忙しかったが、段々他の人の作業を待つことになり時間が出来た。時間が出来た結果、帰属意識を考えるようになった。自分はいったいどこの社員なんだろうと。自社の正社員なのだろうけど、実際に行く会社も違うし、指示を受けるのも他社の人で自社との関わりは数カ月に一度様子を見に来るのだけだった。
ここのプロジェクトに参加したときにプロジェクトの説明が書かれた紙を渡された。その紙のあるところにSES契約と書かれていた。自分なりにSES契約について調べた結果、派遣契約をせずに派遣として他社の社員を使うものなのだろうと判断した。正確にはみなさんの自身の手で調べてほしいと思う。そしてこのIT業界では殆どのプロジェクトでこのSES契約が使われていることを知った。
3社目も5ヶ月で終わった。
4社目はJavaを使い、大規模システムの一部機能の開発を行うことだった。2社目と違い、本当にJavaのしかもかなり難しい知識が必要となり、かなり勉強になった。だが、ここもSES契約で客先での作業だった。この頃になると自分は自分の働き方に嫌気がさしていた。正社員で入社したのに実質派遣という。同じフロアの別の人を見れば正社員で、しかも客先常駐せずに働けているのに何が違うのだろうと。結果は自分の入った会社が間違えていたのだと知った。そのため今月で辞めた。
ここで一つ謝らなければならないことがある。タイトルにはIT企業をやめた話とあるが、正確にはSES企業をやめた話である。IT企業をやめた話にしたほうが沢山の人が見てくれると思うからこのタイトルにした。
この業界にいたからわかるのだが、SES契約をメインの事業として収益を上げるのと、自社システムを開発して製品として売るのではまったくビジネスモデルが違う。SES契約のメインの事業は単なる派遣である。だがITに詳しくない人(別業種)からすれば全てIT企業として統一されてしまうのである。
自分はプログラミングが好きだから約3年間働くことが出来た。だが、同じ業界で自分と同じ状況で働けなくなった人を何人も見てきた。今SES契約メインの会社で働いている人は本当に今の働き方(派遣のような働き方)でいいのか考えてほしいと思う。
今大学生でこれからIT系に行く人は自分と同じ目に合わないでほしいと思う。実質派遣なので勤務地はコロコロ変わる。3社目からは通勤時間が片道2時間を越え、まともに睡眠時間を確保することができなかった。通勤時間が長かったのもつらかったが、それ以上に暇なのがつらかった。客先での作業を例えばその月の10日に終えたとして次の案件が来月に始まるとしたらその間ずっと放置である。さらにその上に日報や週報の提出を求められれば何も書けないのである。それ以上につらかったのが、PCが用意されていなかった時である。その会社のプロパーの作業用PCの申請が遅れた結果、プロジェクト開始と同時にPCが用意されておらず、PCが無いけど定時まで客先にいてくださいと言われた時はほんとうにつらかった。PCがなければ何をしているかというと虚空を見つめるだけである。それがだいたい三週間続いた。
プロパーといえばIT業界ではプロパーはまったくプログラミングが出来ないと言われているが、自分の印象では半々が出来て、半々が出来ないという感じだった。おそらくこれはIT業界の多重下請け構造のどこらへんに客先常駐するかで変わると思う。この業界にいて未だに分からないのはプロパーはSES契約で来ている人に直接指揮命令している人って偽装請負ってわかっているのかそれとも偽装請負と知らずに指揮命令しているかってことです(本人達に聞く勇気はさすがに無かった)。自分がもしプロパーで偽装請負って知っててSES契約で来てる人に直接命令したら多分罪悪感で潰れてしまいそうと思った。
iOS版の新クライアントが導入されたのは12月の頭位であった。この月の頃には僕の所で前から起こっていた、ダンジョンからの帰還操作に時間がかかる、という問題だが、これが帰還操作をしてからだいたい30秒以上かかるようになっていた。この問題は、30秒以上になると通信エラーを起こすという問題に発展しており、通信エラーが起こった時には帰還が失敗することが多くなってきていた。
この問題は新クライアントになる前から観測されており、何度もユーザサポートに問い合わせを行ってはいたのだが特に何も対応されることはなかった。僕としては何度も通信エラーを起こしていればたまに帰還が成功するわけなので遊べないことはない、というような言い訳をしつつ、15分の冒険を行わせるために30分位は帰還しようとして通信エラー、再起動させてまた通信エラー、という事を繰り返していたのである。
さすがにこんな事に時間が取られてしまうのは面白くないと思っていた所で、新クライアントがリリースされ、「お知らせタップ」が知らされるまでは遊ぶこともできなくなり、何故「お知らせタップ」で解決するのかを観測してみたところでスキマの通信が平文で見放題であることに気づいてしまったわけである。そこにやってくる正月休み。なるほどこれは僕に与えられたハックの時間なのですねと僕は正月休みをスキマの解析に当てた。
解析自体は簡単であった。帰還時に時間がかかっているのはクライアント側ではなくサーバ側であることも観測から明らかになった。何故時間がかかるのかは皆目検討がつかなかったが、とにかくサーバ側(多分DBアクセス等をしている)で時間がかかる処理が行われることによって、PHP側のタイムアウト(default では 30秒)にひっかかって50*のサーバエラーが起こる。クライアントは50*が返った事により「通信エラー」を表示する。サーバ側では処理が終わることもあるようだが大半は処理は終わらずそのプロセスごと殺されているようだ。従って、帰還するためのPUTリクエストを送って、失敗したら/login2からセッションキーをもらってもう一度PUT、と繰り返す事で30分(その頃には45分を越え50分位はリトライし続けないと駄目だった)以上かかる帰還操作を自動化することができた。
ここまでで検証作業自体を終了とし、検証で明らかとなった問題(遅いのはサーバ側、30秒以上の処理が行われる事によって50*が発生する、PHPで動いているようだがPHPのtimeoutの初期値は30秒、ワークアラウンドとしてはこの30秒のタイムアウトを60秒とかにすれば当面の問題は回避可能であるが、このままいけば早晩60秒の壁も突破するので根本的な修正が必要)といった事を詳細に書き、Pythonにより自動化された帰還操作を繰り返す(つまりは問題となっている50*のサーバエラーを起こすための)プログラムを添付して、「ここまでやったのでBANするならすればいいよ」と添えてサポートに提出した。
しかして返答としては「BANはしないけど今後はしないでくれる？」という温情あふれるものであり、その後すぐにタイムアウトの設定が増えたらしく30秒で50*が返される事はなくなり、一回で帰還操作が正常に終了するようになり、僕は帰還操作で50分も無駄な時間を奪われる事はなくなった。(といってもその2ヶ月後には60秒の壁が立ちふさがって同じ事が起こったのであるが)
年が明けて5月、一ヶ月後にスキマのサービスが終了することが発表された。先程も書いたように僕は帰還操作がうまくいかないためにまともには遊べなくなっていたが、サービスが終了するのであればこれ以上とりたてて修正を願い出ることもあるまいとそれ以上は特に何も言わないで最後の一ヶ月を過ごした。
振り返ってみるとバグを攻略するという楽しいゲームであった。最後の方では通信の解析を行ってBOTのようなプログラムも作成して非常に楽しんだ(実際、二週間位(一つのイベントが終了するまで)は自分が操作しないでほったらかしておいてもやりたいことはだいたい全部できているようなBOTが作成できた)。今となっては起動してもタイトル画面しか見えないゲームであるが、データが見えなくなるのは寂しいのでとクライアント側に保存されているキャッシュデータ(sqlite形式だった)の中身を閲覧するためのWebアプリを書いたりもしてとても楽しかった。多分運営側としてはいちいちバグ報告と称して長たらしいmailを投げ込んできたり、果ては通信内容を解析してサーバ側の設定を書き換えろと指示するといった迷惑極まりないユーザであったとは思うが、まぁ、終わってしまったゲームであるのでもう何を言ってもいいのかなぁと思ってあけっぴろげに書いてしまった。
また、スキマを最後に開発していた会社はその後解体されて本社に吸収されている。
そういえば、色々とお世話になった2chのスレッドはまだ残っているようである。せっかくなのでスレの方にもこの文書の事は紹介しておこうと思う。
こんなのそこらへんの学生でも持ってるスキルだろ。こういう甘い条件で人を集めてバサバサと不採用にして何がしたいのかわからん。たまにいいのが来ればいいや？みたいな感じ？どうせ内部では経歴や年齢や学歴で差別してるんだろ（と疑われても仕方がない）。
score_list = [] while True: score = int(input()) if score == -1: break score_list.append(score) print(min(score_list)) print(sum(score_list) // len(score_list)) # // round off print(max(score_list))
itertools でこうか... すごい.., これが generator か..
itertools.takewhile の lambda x: x != -1 が False になると
itertools.repeat も yeild を止めるのか..
import itertools score_list = list(itertools.takewhile(lambda x: x != -1, (int(input()) for i in itertools.repeat(None)))) print(min(score_list), sum(score_list) // len(score_list), max(score_list), sep="\n")
仕事柄、UXとかデータ分析とか、その辺が少し強いと思われているらしい。
職場の人からその辺の勉強の仕方を聞かれたので答えようとしたら、意外と長くなりそうだったのでメモがわりに書く。
そもそも、UXという言葉が流行りだしたのは最近の話だと理解していて、バズワードに近いと思っている。概念自体は遥か昔からあるものだし、何を今更世の中がUXというワードを使いたがっているのかが良くわからない。（が、ここでは面倒くさいので、定義が曖昧なUXという言葉で色々お茶を濁す）
また、UXを勉強するという言葉も、正直なところ違和感がある。
というのも、具体的なケースと紐づいて考えない限りは意味がない気がするからだ。文章の批評ばかりしていても小説家になれないのと一緒で、UXについて本や講義だけで勉強していても、UXに強くなることはないと思っている。つまり、自分たちが作っている（関わっている）サービスの中でUXを考えつくすこと自体が、一番の勉強なんじゃないかと思っているので、UXを本や何かで勉強するというのは効果は薄いんじゃないかと思っている。
とはいえ、体系化出来るメタスキル的なものがあるのは事実だし、その部分の話を書いてみる。
「UXを良くしたい」という話をよく相談されるのだが、そもそもとして、UXが良くなった後の世界をちゃんと考えられていないことが多い。
「そのサービスを使ってユーザは幸せになるの？」という問いにきちんと答えられない場合、黄色信号という印象。
UXUXってバカみたいに唱えている人はたくさんいるけど、自分たちのサービスのUXが良くなることでこんな世界が実現できるよっていう話を、具体的に、鮮明に、誰が聞いても腹落ちする形で話せる人ってどれだけいるのかな。UXを良くしたいと言っているのに、良くした後の先の世界がイメージできていなくて、どうやって良くしていくのか甚だ疑問なんだよね。
なので、UXを考えるにあたっては、「自分たちがどうしても叶えたい世界」があって、それが叶うことによって「世の中の誰かがすごく幸せになる」という確信が必要条件だと思ってる。なので、そこがない時点でUX改善どころかサービスを作ること自体をやめた方がいい。
もし、そんな感じの祈りにも似た思いが少しでもある場合は、自分たちが作りたい世界についてしっかりと考えて、そしてそれらを検証して確信に変え、具体的な言葉に落とし込むというプロセスを徹底的に行うことを、UX改善の前に行なった方が良い。そうやって生み出された言葉が、UXを考えるにあたっての拠り所になる部分になっていくから。
自分たちが作りたい世界を言語化できた後は、ユーザの観察と妄想に尽きる。
課題解決系のサービスなら、ユーザに当たる人が本当に困っているのか、何に困っているのかを見極めるために観察すべきだし、何らかのバリューを付加するサービスなら、「このサービスを使ってもらうことで幸せになるのかという妄想」をいかに具体的にできるかが鍵になる。
これらの観察および、具体的な妄想をしていくこと自体がUXを考えることである。
炊飯器が目に入ったので炊飯器のUXを考えるとした時の例で話す。
多分、こんな妄想をする。
炊飯器とか既に他の製品が存在するものは、ユーザの行動もだいたい想像できるし、何より自分が使うものだから妄想しやすい。
逆に、全く新しいものを作ろうとする時なんかは、妄想も中々大変だと思う。バイアウトして話題のCASHとかは、その辺りの参考になるものが中々なく、妄想もやり辛かったと思うので、それを形にできたUXデザイナーの人はすごいなと思う。会ってみたい。
これはかなり適当に書いたが、自分たちが行なった観察に基づく妄想に対して、それらが意味のあるものかどうかを見極めていく必要がある。これがいわゆる価値仮説の検証と呼ばれるもので、妄想が本当に必要とされるものなのかを見極めるフェーズである。必要とされないものなんて作っても意味がないから、この段階できちんと仮説の検証をしておく。検証については対象によって全く異なるため、都度考える必要があるので割愛。
例はかなり適当に書いたが、ユーザをしっかり観察して、その上でどうやったら幸せになるかを妄想して、それらを検証していくというフェーズを、手抜きせず行うことが大事だ。これが業務系のサービスだと、業務フローを作ったりするのだろうし、C向けサービスだとカスタマージャーニーなんかを作ったりすることになる。その辺りの手法は色々あるが、ユーザを見て、考えて、検証してという基本はどれも変わらない。
ユーザをひたすら観察したあとに、初めて解決策を考えるフェーズに移る。
解決策ありきのプロダクトだと（昔の技術先行型の日本の家電だけど）、あまりいい感じにはならない。
あくまでも、ユーザの観察が先にあって、それに対する「解」としてプロダクトを作っていく。
この、課題に対して適切な解を出していくこと自体が、UXの磨き込みに当たるという理解をしている。
そして、それらが部分最適にならないよう、全体最適も意識しながら解決策を考え、プロダクトに落とし込んでいく。
「ご飯は1分で炊けるけど、風呂釜より大きい炊飯器」とか、誰も必要としないよね。だけど、部分最適だけを考えるとそんなことになりがちである。そのためにも、部分を考えたら、全体を見るということを繰り返し行なっていくことが大切だと感じている。その意味では、捨てるべき部分と、活かすべき部分のバランスをどう取るかが大切になる。ここも結局ユーザが教えてくれるので、事前にしっかり観察できていれば、勝手に答えが出る。
長々と書いたが、自分たちが作るサービスを使ってくれる人たちが、「どうやったら素敵な感じになるかを考え尽くすこと」が最高の勉強方法だと思っている。なので頑張って考えると良いと思う。
とはいえ、何を考えればいいかわからないということもありそうなので、その時は
・誰のためのデザイン
・複雑さと共に暮らす
・融けるデザイン
あたりを読んでみるのは良いかもしれない。少なくとも、何かを考えるにあたっての視野は広がるような気がする。
また、解決策を生み出していくにあたっては、ロジカルシンキングが出来るに越したことはないので、
あたりを読んで見るのも良いかもしれない。後者は分類的にはロジカルシンキングの本ではないのだが、ロジカルに考えた時の解決策って一つだけじゃないよねということを身を以て知るためには良い本だと思う。
また、散々書いたが、UX云々の前に、自分たちが作っているサービス（だったり、炊飯器だったり椅子だったり）で「何を届けたいか」という部分が一番大事だと思う。それ抜きにはUXがどうとか議論するのは無駄というか、意味がないので、しっかり考え抜いてほしい。
データ分析というと、Pythonでごにょごにょやるのがそれだと思われがちだが、一部のデータサイエンティストを除いては、基本的にスプレッドシートで十分なんじゃないかと思っている。むしろ、電卓レベルでも足りるんじゃないかという気がしている。（ここで話しているのは一般的なインターネットサービスを運営していくときの話で、気象予報とか経済予測とかそんな感じの難しいデータ分析の話ではない）
というのも、多くの場合において、四則演算以上のことをしなくてもなんとかなるからだ。
どちらかといえば
といったことの方が大事だし、そもそも「何のために分析するか」が抜け落ちていることが多い。
whyの部分が明確でない分析はそもそも意味がないので、まずはなぜ分析するのかを考えるところから始める方が良い。
データ分析ときいて「統計学」や「Python」を勉強すること自体は悪くないのだが、それよりもまず先に、「なぜ分析するのか」「どんなデータが自分たちのサービスのキモになるのか」といった分析の前提になる部分をまずはしっかり見極めることの方が、統計学の勉強よりも優先されるべきだ。それらがハッキリすれば、手法はいくらでもあるし、だいたいはスプレッドシートの関数でなんとかなるので、難しい計算は特に必要ない。
実務でよく使うデータなんて、売上、利益、利益率、ARPU、CPA、CTR、CV、CVRとかくらいだし、これら全て四則演算のみで出せる。分析といっても、平均だったりそれらをユーザの属性で割り振ったりするだけだし、中学生でも問題なく出来ると思う。ただ、重ね重ねになるが、whyの部分がない場合はいくら分析しても何も生まないので、まずはそこを見極めることに重点をおいた方が良い。
長くなったので無理やりまとめる。
勉強＜＜＜＜＜実務であることは間違いないので、まずは自分が関わっているサービスについて真剣に考えたり、真剣に考える上で必要な数字が何かを自分の頭で考えることが、最高の勉強だと思う。教材とか、具体的なHowを期待していた人、ごめんなさい。でも、Howの意味で見ても、実践に勝るものはないと思っている。
まともな職歴がないけど、就職したい！
あわよくばいっぱいお金がほしい！
ということで、取り敢えずHTML5、CSS3、jQuery、WordPress、フォトショ、イラレを勉強した。
そこそこ見栄えのする（と思う）サイトをいくつか作ったり、自作サイトに合わせたWordPressテンプレートを一から作ってみたりした。
……が、次に何をすればいいのかわからない。
Web制作は思ったより楽しいけど、最初から作りたいものとかはないし、また新しいサイトを作るのとかはだるい。
Rubyでもやればいいのかね？
機械学習とかに興味わかないからPythonは勉強するつもりないんだけど。
PythonにはPerlとは真逆の「やりかたはひとつ」というポリシーがあり、ある処理をコードとして表現すると、ロジックに個性は出ても、記法に個性があまり出ない（多少は出ますけどね）。可読性（保守性）の高さは、プロダクションとしてコードを書くとき、非常に大きな利点になります。
http://aiweeklynews.com/archives/49678692.html
・Excelはがっつり使える
・Pythonのnumpyやpandasでデータの処理ができる
例えばですが、pythonを自分のパソコンに環境構築して、「Hello,world!」と表示できるようになったら、面接に申し込んで、「少しはpythonできます」と言ってみるのも一つの方法かもしれません。
実際に見分け方がわからなくてこれに引っかかって採用してしまう場合もあるんだろうな、とも思う。
自分がこの手の人材（エンジニア）を採用する場合にどうやって質問をすれば見極められるのかエンジニアの採用にも関わっている身としてを考えてみた。
AI人材という呼称自体がぞわぞわするけど、一旦そこは我慢する。
まず採用を行う前に、AI人材を取って何をしてもらいたいのかをチームないし採用意思決定者としっかり確認する。
など、あとは案件ベースなのか自社開発なのかそれぞれ必要となる能力がオーバーラップしつつも異なっているため。
バックグラウンドを確認する。実務や研究の経験の話が出てくるのがメジャーだと思うが、エンジニアとしてのバックグラウンドがあれば独学勢でも野良kagglerなどレベルの高い人はいるので実務経験に絞らなくても良いと思う
機械学習全般の基本的なところから確認していく。質問としてはこんな感じだと思う
・過学習ってなんでしょうか
イメージとしては非エンジニア職でも必要になる「この辺りの言葉が通じないと絶対困ったことになる」一般常識を確認する感じ。
画像や映像の認識などディープラーニング系の業務が多い想定の場合
から始まって
・どうやって訓練したのですか？
・どうしてそのような構成にしたのですか？
と突っ込んでいく。
確認したいことはディープラーニング「しか」できない人かではないかという点。
ある程度統計やベイズ法周りの知識が無いと詰むため。逆にディープラーニングが不要な業務ならこっち一本でも可。
・勾配降下法について説明してください
・畳み込みニューラルネットワークについて仕組みを説明してください
盲目的にライブラリを使ってるだけでないかという点を確認したい。
SVMを入力に適用するだけならsklearnで5行書くだけで誰でも出来る。手法の背景や対象データの特性をきちんと考えて使っているかを見たい。
・kaggleのコンペに参加したことはあるか
・メダルの取得状況
kaggleに参加した経験があればnoteからその人の手付きを直接評価できるし、メダルという他メンバからも客観的に評価できる定量指標もある。
学習意欲とか普段の姿勢を確認したい。もしかするとここが一番重要かも。
・普段何を参考に勉強しているか / 論文を読む習慣があるか(最近読んだ論文があれば教えてください）
・今興味のあること
