みんなのPython勉強会#21 に参加してきました
Python3の進化について
辻真吾さん
いろんな意味で3に移行したほうがいい気はする
ライブラリが移行しきってないとかそういう問題はあるんだろうけど。
3.6から非同期処理のサポートがstableになっているそうです。
また、型ヒントが必須じゃないけれど使えるようになっているそうです。
動的型づけは今後も続くので、型ヒントは厳密な運用にはならないかも、とのことらしいです。
virtualenvやcondaの話については、環境を完全に固めるならDockerをちゃんと使ったほうがいいなーと思いました。
それでUbuntuを入れようと思い至った感じです。
Ubuntu入れようと思ったもう一つのきかっけは、Macbook-> Lenovo -> Macbookに戻した人の記事を受けて、Lenovoでgentoo入れて開発環境作ってる人の記事を読みました。 いろいろ思うところはあるけれど、自分もVagrantとかDocker-toolboxとか使ってファイルシステムの問題気にするより普通にLinux入れたほうがいいなと思ってWindowsのマシン(ノート)にgentooは難しそうなのでUbuntuを入れ始めています。 キーボードの問題についてはHHKB持ち運びで良いんじゃないかと思うんですよね 16.04LTSを入れたのですが、ubuntu16.10からはSurface 3にも対応してるみたいなので、いきなり16.10にアップグレードしました。 ちょっとドキドキ
システムトレードとPythonの利用
森谷博之さん
話の内容も非常によかったのですが、Jupyter Notebookでそのままプレゼンをしていることに驚いた。 気軽に使えて当たり前のツールになっているんですね。 Pandasのデータリーダーを使うとスクレイピングなどを頑張らなくても１行でダウンロードできる 統計学の可能性と限界について詳しくお話をされていて、システムトレードに応用するんだったらその実際の取引の知識もあったほうが圧倒的にいいとのこと。 現在は１０万円でも試してみることはできるし、取引場のＨＰなどは端から端まで、見尽くすことなどをやってみるべき。
「明日から使える AIシステム開発シナリオ事例特選10〜pythonを使ったAI開発」
井原 渉さん
機械学習やＡＩについてのお話でした。
データ分析のレベルを４段階に分けて説明されていていました。
いきなり「AIやりたいんだけど」「DeepLearningやりたいんだけど」みたいなことを言う人はちゃんと処理したいデータが何なのかが決まってからやるべき、とのことです。
機械学習などを応用された様々な実例を紹介されていて非常に面白かったです。
特にバイトのシフト問題の最大幸福最適化問題とか
画像評価システムについては、TensorFlowつかえば４時間くらいで使える物が書けるそう たとえば不動産の部屋の画像写真をDeepLearningさせたとき、D-89のタグ コンバージョン率が高いということがわかる。 人間に認知不可能なタグでも役に立つことがあるとのことでした。
感想
一番受けた感想としてはデータ分析計のPythonの流れもしっかりつかんでおかないとエンジニアとしては時代遅れになるんじゃないかということです。 今はWebの技術を使いこなすことを急務にしていますが、PandasやJupyterNotebook、TensorFlowなどのキーワードが当たり前のように使われている感じがします。
StaPyの勉強会自体は初心者だったり、これからPythonで何か始めたいという人向けの勉強会とのことなので非常に参加しやすい感じでよかったです。
発表者の皆様、運営の皆様、ありがとうございました。
DevLOVE199 越境CONに参加してきました
2017年1月28日のDevLOVEの越境CONというイベントに参加してきました。
イベント趣旨としては（若手の人が）現場で取り組んでいる工夫や挑戦について語る、という感じで、どれも非常によかったのですがその一つについて書いてみたいと思います。
『ガチガチの SIer が一皮むけようとしている話 ～Arumon の紹介～（仮）』
盛 慎さん
なぜ越境するのか？
Innovationを起こすため
組織の枠に縛られない、スキルではなくパッション、変化に対応できる、
responsive to change
１００年以上続いている会社も大きな変革を経ている
e.g. ノキア
NRIでは本業は社内の受託内製だけれど、Arumonというイノベーションの活動を行っている。
イノベーションへのパッションを持ち、失敗を恐れずにチャレンジしていくこと、どんどん失敗しようという心構え
大企業病 価値を守ることを重視し、どんどん変化できなくなり、リスクを取れなくなる
最初に海に飛び込むfirst penguin（新しい市場の新しいチャレンジャー）になれない
だから、Arumonがかわりにどんどん失敗する
Arumonがどのように起こったか？
新しいことをやりたい パッションを持つ人参加しているとけっこうわかる
そんなつながりの有志で活動開始 草の根で勉強会やプロダクトを作ったりする活動をやり始めた
かっこいい上司（役員の方？）「ハッカソンをやるような元気な人を応援したい。」
結びついて、予算もついたちゃんとした活動に
活動内容
やってみたいことをどんどんバックログにためておき、「これいいんじゃね？」と引っ張り上げる ジョインする人が挙手して参加
大体１つのバックログアイテムを３－４人で
コンセプトの段階だとペーパープロトを使ったり、Googleが提唱しているアイデアだしのフォーマット（クレイジーエイト）を使ったりしている
最終的にはスマートフォンのアプリをローンチしたりするところまで。
課題
- Arumonもいいけど仕事もちゃんとやってねという意見がある。
理由はArumonのような活動が遊びに見える。
きっちりと決めるウォーターフォールの受託開発に比べると仕事の進め方が「クイック ＆ ダーティ」だったりする。
ロジカルシンキング VS デザイン指向
何が必要だったか
社内への意識改革
- デザイナーにとの協業
何をお願いしたらいいのか？
エンジニアは「見た目なんてどうでもいいんだよ」みたいな人も多かった
デザイナーの生産性基準の判断が難しい。良いものは工数で測れない。
エンジニアの常識が通用しない 使う言葉も違ったり
お互い若干押し付け合いがあった
解決策：違いを受け入れること
デザインボードの作り方を教えてもらう
とにかく話し合う
収穫
Arumonでやったことが本業で生きる
ブロックチェーン、機械学習
大切なこと
アピール：ハッカソンなどのイベントの参加
エンジニア以外の交友も広げる
組織としてチームとして動くという意識
社内で個別に動いているイノベーターは意外と多いのでそれを結び付けていける
質問
- 変わりたくない人はどうしたらいいの？
強制はしない
「今までやってきたお金を稼ぐこと と イノベーション」の２階建て、どちらも大事
認めてもらうことを目指す
- 機械学習やブロックチェーンなど学習コストが高い問題は？
本来解決したいこと 技術で解決すること
そういう人が集まるのでそんなに困らなかった
- デザイン指向について
ロジカルシンキングだけでなく、付け加えて考える
まずつくってみて、機能的なところじゃない快感などがあるかどうかなどを考える
例えばヒースロー空港の手荷物受取りのように、たどり着くまでの距離を長く調節することで、待っている時間を感じさせない。
感想
エンジニアとしての学習のアジリティをどう確保したらいいのか、っていうことを常日頃悩んでいる感じですが、このようにイノベーションに情熱をもって取り組むことができるというのは非常に素晴らしいと思います。
開発者はプロダクトのインクリメントを作ることだけに集中する、というのが一見正しく思えるけれど本当はそれだけじゃなく、「売上」だったり「顧客に向き合うこと」だったりを総合したプロダクトを売っていく生産活動やエコシステムそのものが大事だと思います。
当然、顧客に向き合うならよりよい経験を提供するために、イノベーションを起こしたり、最新の技術を取り入れたりしなければいけないかんじです。
それもどっちかというと枯れた技術の水平思考的なイノベーションな気がする。。。
他の発表でもありましたが、「停滞は後退と同じ」ととらえられることもあるので、こうした活動のやり方や精神はまねていきたいと思いました。
開発合宿とか社内アイデアソンとかよさそうです。
話はそれますが、Titan Fall2というゲームが面白いとのことでめちゃくちゃプッシュされてました。
気になる…
イベント全体の感想
いろんな人がいろんな現場で挑戦してることを知ることができ、encourageされる場だったと思います。
自分も自分の現場で、あるいは自分の学びの場の中でチャレンジして行きたいなーと思わせる良さがありました。
スピーカーの皆様、スタッフの皆様、会場のYahoo様、ありがとうございました。
エンジニアリングマネージャー勉強会に参加しました
2016年12月13日に「エンジニアリングマネージャー勉強会」に参加してきました。
（結構前のメモになるのでうろ覚えでの記述になります。すみません。）
「エンジニアのマネージャ(リーダ)による、メンタリング、指導、立ち居振舞いについて現状を共有します」というテーマだったのですが、全体的にキーワードとして「心理的安全性」というのが出ていました。
@muddydixon さんの「ボトムアップとトップダウンの技術組織への変革をしている話」というお話では、動機づけ要因とか衛星要因というキーワードが出てました。「組織としての目標やゴールに対して、責任を持つ（モチベーションを保つ）ということ」と「心理的安全性を作るということ」とを両立するというお話だったと思います。
面白かったのが、メンタリングを考える際にその人の「指向・姿勢・その人が持つアセット」を「キャリアアンカー改」という方法で分析されていることです。詳細についてはスライドでわかると思います。
あんちぽさんの「『いるだけで成長できる環境』を作るメンタリング」というお話では、基本的に「いいじゃん いい感じに ばーんと」という3つの言葉しか言っていないという話をされていました。
「いいじゃん」が、まだ最初の段階であまり信頼関係がないときに「肯定」をすること
「いい感じに」が、だんだん信頼できるようになってきてその「信頼」を示すこと
「ばーんと」は、もう完全に信頼しているので完全に任せきる「期待」を示すこと
という感じでやってるそうです。
あんちぽさんがCTOをしているGMOペパボではメンターを受けたひと（メンティー）が次の世代のメンターになるような親方と弟子みたいな関係や、同僚だったり同じような役割の人たちからの横からのメンタリングも入れて「上から下から横から」「公式にも非公式にも」というメンタリングモデルを目指しているそうです。
あと、質問の時に話されていたのですが定例会議を完全にリセットする取り組みをやって実際にうまくいったとのこと。。すごい。
@kenchan さんの「メンタリングはじめの一歩」というお話でも、心理的安全性を高めることと達成感を高めるということの両立の話をされていました。
1 on 1で心理的安全性アップをおこない、目標の面談で責任と期待のマネジメントを行うようにしてるとのこと。
目標の設定は、達成できないと評価されないので達成できるレベルよりも若干楽にしてしまうような「防御的」な目標にしてほしくないということを考えているそうです。
@takesako さんの「エンジニアリングマネージャの職務要件」という話では、他のロールとの比較のお話が出ていました。
プロデューサーは思いがつよく、「あれもやりたいこれもやりたい」
プロダクトマネージャーは逆にやらないことを決めることで映画の監督のような立ち回りをする
そしてエンジニアリングマネージャーは最初からチームに関わる
エンジニアリングマネージャーはエンジニアの「得意なことを伸ばす」ということが重要。
まず「快適」ということめざし、それだけでは堕落してしまうので「チャレンジ」というステータスを目指す。
エンジニアはとがった人が多かったりもするのだけども、「チームの隙間を埋めていく人材」にならなければならない。
それを実現するのがリクルートグループで共通で用いられている用語のATIを持つ人。
ATIとは圧倒的当事者意識のことで、その人は完全に枠にとらわれない。
ずっと前に、DevLove甲子園でリクルートの黒田さんという方が話されていたお話を聞きましたが、問題を解決するために上限を設定しないという態度は確かにという感じでした。
具体的にはスクラムを導入するコーチの選定の仕方や、スクラムで働きやすくなったということは利益の成長につながっていないことをちゃんと評価してそこから先に進むためにリーンの手法を導入したこと。
というのを思い出しました。
@yuku_t さんの話と@tatsushim さんの話はビアバッシュ中のLTだったのでちょっとメモもなくて申し訳ないのですが、@yuku_tさんの話は「スタートアップ的な組織」だと組織の規模が小さい黎明期はメンバーが本当に知っている人しかいないのでコミュニケーションなどに問題は起きないんだけど、組織が成長すると知らない人が増えて難易度が上がるというお話だったと思います。
特に意思決定の適切なプロセスや、メンバーの良好な関係をつくることが難しくてそれがマネジメントに影響を及ぼすという感じだったと思います。
@tatsushim さんの話もそれと似た感じの文脈はあるのですが、そのようなマネジメントの問題に対してスクラムを導入したお話をされていました。
案件管理のスプレッドシートの「優先度」カラムが最重要が複数あったり、「must」や「スター」などの別のカラムが追加されたりしてカオスになるという話はすごくよくわかる感じです。
スクラムを導入するのでも、拒否反応っていう結構難しい問題をはらんでいるのでその辺の心理的安全性をどう保つか、というお話だったと思います。
どの話もすごく面白く、今後自分がどのように仕事に向き合うかということにもかかわってくるものだったと思いました。
２回目のエンジニアリングマネージャー勉強会があるならまた参加したいです。
additional
@kenchan さんのお話でも少し出ていましたが、RebuildFMというポッドキャストで過去にポッドキャストのオーナーの@miyagawaさんと@naoyaさんが心理的安全性や「チームが機能するとはどういうことか」ということについて話されていた回があったと思います。
また、直近の171でもお話されていて、そちらも聞くといろいろと考えさせられて非常に良いと思います。
プロダクトファーストな考え方と、エンジニアとして主体的に働くこと
エンジニアとして主体的(アカウンタブル)であることを放棄している状態というのがいくつかあります。
- 上から言われた仕様や要件を実現させるだけのための技術的な解決方法やスケジュールにだけこだわってリリースすること
- 別のエンジニアや組織に発注する側である場合、自分たちの要件についての交渉可能性を放棄し、「私たちはあなたたちのこれができていないせいで困っている。とにかく何とかしろ」という態度で望むこと
- これはそもそも、７つの習慣などで言及されているWin-Loseなコミュニケーションをしている状態であると思います。こんな人とは一緒に仕事はしたくなくなります。
- アジャイルやウォーターフォールといったプロセス論にだけこだわり、プロジェクトの危機的な状況にたいして本当に見える化や継続的改善することに対してフォーカスされていないこと
こういった状況は仕事をする上では犠牲的つまり主体的でない状態の仕事であると思います。
こうしたことが起こる原因は、もっとマネジメントに関して、プロダクトファーストな考え方にシフトしていないせいではないでしょうか？
プロダクトのオーナーと「要求」には合意している状態で、「要件」については「交渉可能」である状態であるというのが望ましいのではないでしょうか。
つまり、「これをやりたいんだ」ということに関しては合意していて、それをどう実現するかについては交渉可能な状態であることです。
よく例として挙げられるのがオレゴン大学の実験の話です。
こうした状況で出来上がるプロダクトとして、「こんなはずではなかった」とか「かかったリソースの割合にできたものの売り上げが見合わない」といった状況も起こりうるだけでなく、継続的にそのプロダクトをメンテナンスすることに関しても弊害が出るはずです。 「言われたとおりに作ったんだから、なんで改修しなければならないんだ」とかいう気持ちになることはよくあります。
プロダクトオーナーと要件について交渉が可能であれば、少なくともこうした事態は避けられるのではないかというのが個人的な実感です。
前職であるeコマースの会社では元エンジニアであったデータマーケティングの担当者がこうした要求をこちらに伝えたうえで、要件に関してはこちらとの交渉可能性を残してくれている状態でした。
結果としてそのプロジェクトに関して、自分は（プロフェッショナルであるべきアーキテクトに関して）アカウンタブルな状況でのぞむことができ、ある一定の成果を出せたのですが、それは要件の合意について交渉かのうであったことが一番の大きな理由だと思います。
アカウンタブルであったため、シチュエーショニング(その要件や要求を整えるための状況の作成や他のエンジニアとしての交渉）についても気を使うことができ、他のエンジニアに発注する側であったとしても要求の「Why」の部分を伝えることに注力したつもりです。(ただしこれはまだまだ未熟な部分も多かったのですが)
個人個人の働く環境によってこんな交渉が可能な状態でいつも仕事ができるわけではないかと思いますが、エンジニアの成長可能性を一番高めるのはこうしたことが実現されていることが重要な差をつけるものになってくるなのではないかと思います。
そういう意味では、DDDなどの考え方を自然に開発に取り入れられているKRAYさんの取り組みなどには本当に感心させられます。 かかわる人間すべてが同じ言葉で会話できるだけでなく、設計や要件についても善しあしを交渉する足がかかりになっているのではないかと思います。この辺は推測でしかないのですが。
プロダクトファーストな考え方で仕事をするのが望ましいとは思うのですが、「そうは言うが大佐、このプロジェクトは納期だけが決まっているんだ」「オーナーとは交渉する余地がない」みたいなときはどうしたらいいかというと、メンタルだけには気を付けて「仕事は金のため」と割り切りましょう。
その上で「メンタルがやばい」とか「ソウルジェムが濁って魔女化しそうだ」みたいなときは「手を手遅れになる前に」転職先を探したり、よいカウンセリングのサービスでも探すしかないかと思っています。こんな解決方法しか思いつかなくて申し訳ないです。
理想を言えば、以下のスライドにあるようなチームに所属したいですね。 このスライドは本当に素晴らしいです。
とにかく自分の仕事が犠牲的な考え方（他の人のせいで私は仕事ができない）になっているかどうかについては気を付けつつ、基本的には「プロダクト」をよりよくするためにはどうしたらよいか、なんかあったら自分がそのプロダクトに対して責任を持つ(アカウンタブルである)ということを考えながら仕事をするべきです。 自分もそれがまだまだできてるとはいい難い状況なので恐縮なのですが。。。
あと最後に日曜朝にやっていた戦隊ものの特撮番組「トッキュウジャー」の中で怪人が「世の中金だー！」と叫んでいましたが、「お金は大事」です。 これについては自戒も含めて。
プロダクトファーストな考え方と、エンジニアとして主体的に働くこと
エンジニアとして主体的(アカウンタブル)であることを放棄している状態というのがいくつかあります。
- 上から言われた仕様や要件を実現させるだけのための技術的な解決方法やスケジュールにだけこだわってリリースすること
- 別のエンジニアや組織に発注する側である場合、自分たちの要件についての交渉可能性を放棄し、「私たちはあなたたちのこれができていないせいで困っている。とにかく何とかしろ」という態度で望むこと
結論としてはプロダクトのオーナーと「要求」には合意している状態で、「要件」については「交渉可能」である状態であるというのが望ましいのではないでしょうか。
つまり、「これをやりたいんだ」ということに関しては合意していて、それをどう実現するかについては交渉可能な状態であることです。
よく例として挙げられるのがオレゴン大学の実験の話です。
顧客が本当に必要だったものとは (コキャクガホントウニヒツヨウダッタモノとは) [単語記事] - ニコニコ大百科
プロダクトオーナーと要件について交渉が可能であれば、少なくともこうした事態は避けられるのではないかというのが個人的な実感です。
前職であるeコマースの会社では元エンジニアであったデータマーケティングの担当者がこうした要求をこちらに伝えたうえで、要件に関してはこちらとの交渉可能性を残してくれている状態でした。
結果としてそのプロジェクトに関して、自分は（プロフェッショナルであるべきアーキテクトに関して）アカウンタブルな状況でのぞむことができ、ある一定の成果を出せたのですが、それは要件の合意について交渉かのうであったことが一番の大きな理由だと思います。
アカウンタブルであったため、シチュエーショニング(その要件や要求を整えるための状況の作成）についても気を使うことができ、他のエンジニアに発注する側であったとしても要求の「Why」の部分を伝えることに注力したつもりです。(ただしこれはまだまだ未熟な部分も多かったのですが)
もちろん、個人個人の働く環境によってこんな交渉が可能な状態でいつも仕事ができるわけではないかと思いますが、エンジニアの成長可能性を一番高めるのはこうしたことが実現されていることなのではないかと思います。
ルビィのぼうけん 読書感想
ルビィのぼうけん
DevLove関西のイベント「それぞれの現場におけるチームづくりの試行錯誤」に参加したのですが、その中で翔泳社の岩切さんが１冊だけプレゼントしていただけることになりました。
１冊しかないので参加者でじゃんけん大会となり、じゃんけんとても苦手なのですが自分が勝ちとりました。
岩切さん、ありがとうございました！
内容の紹介と感想
帯の紹介によるとプログラマー的思考法を育む知育絵本、とのこと。
読んでみた感想ですが、非常に示唆に富んだ物語で面白いなーと思います。
子供が気に入って何回も読めばいろんなことに気付きそう。
そのために結構読み聞かせる親御さんなどのアシストも重要な気がします＾＾；
ルビィのほかにペンギンたち・ジャンゴ・雪ひょう・ロボットたち・きつねたちといったキャラクターが登場するのですが、たとえばペンギンたちはLinuxというよりもUnixの基本的な考え方「小さいまとまりに分けられた問題を好む」という性格で描かれていて、おもしろいです。
プログラミングが好きな人が読んでも、このキャラクターの性格は、こういう理由かなと想像しながら楽しめたり。
ルビィはある目的のために、そういうキャラクターたちとかかわりながら冒険を繰り広げる感じです。
周りのキャラたちとコミュニケーションをしつつ、出てくる難題を解決するのにはどうしたらいいか工夫をして解決していくのですが、どう伝えたらペンギンたちなど他のキャラクターに伝わるか、道具をどうつなげたら取りたいアイテムにたどり着けるか、みたいなところが見どころだと思います。
絵柄もカラフルで非常にかわいいので子供が見たら単純に楽しいんじゃないかなぁと思います。
後ろのほうに子供と一緒にパズルをとくみたいなワークがついていて、課題解決するためのアルゴリズムとか考え方を身に着けるのにとても役立ちそう。
そしてそれはプログラミングにつながっていくものだと思います。
ワークは子供とやる前にちょっと大人同士で練習してみてもいいかもしれないと思いました。
これからの時代、プログラミング的な思考のあるなしの違いは大きくなってくると思います。
それだけがすべてじゃないけれど世界を変えていく力の土台部分ですし。
子供たちのこれからを変えていくインパクトのある本だと思います。
「Whyの依存関係を明確にすることにフォーカスした質問」をどう活用するか？
暗黙知になっていること、とくにタスクや課題の依存関係などを明快にするには質問を「いい感じに考えるべきポイントにフォーカスして」繰り返すといいなと最近思っています。
というのもそういう質問の仕方がうまい人が同僚に入ったからなのですが。
『考えるときには考えるべきポイントを間違えないことが大事だ』
俺ガイル２期で平塚先生が何回もおっしゃっています。いや、何回も言ってるんじゃなくて何回も見てるんだった。
会社なら会社としてのビジョン、ミッションというのがまずあるはず。
ビジョン、ミッションにより近い質問からブレイクダウンしていく。
「プロジェクトのこの作業はこのミッションに貢献しているからやっているのですか？」
ということに答えるために、なぜなぜ分析っぽく
「会社の目標は何か？」
「会社のミッションは何か？」
「IT部門として成し遂げたいミッションは何か？」
「利益向上、コスト削減、リードタイム短縮のために作りたいインフラ基盤・アプリケーション開発基盤は何か？」
「なぜこのプロジェクトをやるのか？」
という依存関係のわかる化につなげていきます。
ハイコンテキストからローコンテキストへ置き換える作業でもあると思います。
で、その場で質問とその答えを聞いた人はわかるんだけど、それだけじゃなくて見える化したい。
そうすることで「ぶれないマニフェストをサジェスチョン」（※俺ガイル２期の意識高い系会議より）することが可能になると思うのです。
『「Whyの依存関係を明確にすることにフォーカスした質問」をどう構造化するか？』
前回参加したDevLove関西のイベントの情報設計の話ともつながると思います。
やり方自体はツリー構造でいいんじゃ、ってことなのですが。
メンバーだけで通じる暗黙知、ハイコンテキストを少なくし、周囲の人(ステークホルダー)に、常に見える状態にして『透明性』を出したいです。
その上で「本当に透明になっているか？正しいか？」ということを『検証』できる状態にしたいです。
さらには検証した結果を常に改善、『適応』できるようにしたいです。
それも楽に。
『ぶれないマニフェストをサジェスチョン』
Whyを共有できてないことに起因する本当に無駄な会議をしたくない。
やるべきことにフォーカスして仕事していきたいものです。
