fc2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

第3回CodeIQ感謝祭「春のエンジニアまつり」 に参加しました

2016/3/5(土) 第3回CodeIQ感謝祭「春のエンジニアまつり」 に参加してきました。

ATND
https://atnd.org/events/74999

Togetter
http://togetter.com/li/947034

場所は東京駅隣接のグラントウキョウサウスタワー41Fです。
参加者は400人弱でしょうか。

及川さんや増井さんはじめ著名なギークが登壇されること、厚切りジェイソンという芸人さんも登壇されるとのことで楽しみでした。
ちなみに私、普段TV見ないので、厚切りジェイソンさんの事はこの日、初めて知りました・・・
及川さんはNHKのプロフェッショナルという番組で以前、特集されてましたね。

以下、講演&ディスカッションのみ、自分用の復習メモ。


基調講演(1) 及川卓也さん



情報共有から始めるチーム開発とキャリア戦略 from Takuya Oikawa


情報共有
  • 情報共有そのものが会社のミッションとなっている。
  • 永遠のテーマと思われるほど課題となってる。

1980年代後半
  • OA(オフィスオートメーション)の時代。
  • 事務作業をいかに効率化するか、がテーマ。
  • 当時はダム端末を使ってキャラクタベースの処理を行っていた。「ダム」という単語の意味は「バカな」。
  • OAでオフィス作業効率向上の次に、知識共有と協調作業がすぐに出てきた。

情報 OR 知識?
  • 情報と知識ってどう違うかな?
  • 情報共有は「Infomation Sharing」。Wikipediaだとちょとニュアンスが違った。
    • Knowledge Sharingのほうが近い、と紹介されていた。
  • 「情報」は明治維新のころに出てきた日本初の用語。情状の報知(軍事用語)から来ているのでは。
    • リアルな状況を通知、報告しあうという意味で使われた。
  • 「知識・知恵」は、それに加え、人間がどう思っているか、コンテキストが追加されたもの。
  • 共有フォルダとか入れ物の問題ではない。
  • 「情報」の先に「知識」があり、どう活かすか、という話がある。これは技術が発達しても、変わる部分じゃない。

知識管理(Knowledge Management)
  • 野中郁次郎さんの「知識創造企業」とうい書籍が出展。
  • 「SECIモデル」というのが紹介されていて、非常におもしろい。あとで調べて欲しい。

SECIモデル(4つの知識変換モード)
  • 人と人との間において知識がどのように発展していくかをモデル化したもの。
  • 暗黙知が共有されると「共同化」になる。
  • 共有により暗黙知から形式知にするのが「表出化」。
  • 形式知を読んで、暗黙知として咀嚼化するのが「内面化」。
  • そして次のサイクルに入っていき、共有され発展していく。
  • SECIモデルは野中先生が提唱されたが、いまだに非常に大事なコンセプトである。

Knowledge Management System
  • 90年後半からナレッジマネジメントシステムが出てきた。
  • これに関して40個くらいの製品がある。
  • 共有ストレージだけじゃなく、もう少し踏み込んだ製品を出している企業もある。

作業効率から知識共有&協調作業へ
  • OAが出てきて効率化が提唱された後、「知識共有」と共に出てきたのが「協調作業」。

CSCW
  • Computer Supported Cooperative Work
  • 今でもいろんな研究がされていて、日本でも盛ん。
  • 「CSCWとグループウェア」という本がある。著者の石井さんは協創メディアラボの副社長。
  • 当時どんな本だったか、というと、1994年刊行で「電子会議室システム」を扱っていた。
  • OHPで映す時代から、どう会議を活性化するか、というテーマを扱っていた。
  • その後、ホワイトボードやプロジェクタがあたりまえになった。
  • 6章で「ClearBoard」を扱っている。1つのクリアなボードを自分と遠隔地で書き合って作業していく。
  • 当時から、今のグループウェアよりもいろんなものが入った形で研究されていた。
  • 昔は、コンピュータによって人のディシジョンが進むのでは、と考えられていた。

CSCWの例
  • 人間の、人と人との関係はいくつかある。
  • こういう依頼がきたらこうしよう、というフローがあって、このフローどおり人間を動かすシステム。
  • 強制があってナチソフトと呼ばれていた。乱暴。でも、おもしろいものがあった。

CSCWからグループウェアへ
  • CSCWで一番成功したのがLotus Notes。
  • シンプルに情報を共有していく、その使い易さがあった。

ACM CSCW Conference
  • CSCWは今もカンファレンスとかが開かれている。

脱線しますが・・・
  • 大好きな本に「アジャイル開発とスクラム」というのがある。非常に良い本。
  • 「スクラム」という名前は野中先生の論文から取られた。

  • 上の図で、Type BとType Cはフェーズがオーバーラップしている。
  • Type Bは、前のフェーズの人が次のフェーズに関わる、という図。
  • Type Cは、最初から最後のフェーズまで全てに関わる、という図。

現在の情報共有
  • 現在、情報共有が進んでいるか、というと、いろんな問題がある。

共有を阻害するもの
  • 情報漏洩リスクへの不安 ・・・ 共有することによって、知らなくていい人が知ってしまう問題がある。
  • 共有することへの理解/共感不足 ・・・ 共有しても共感して進めてくれるだろうかという不安。
  • これらに対応する3つの方法が、「システム」、「ルール」、「文化」。

システム/ルールだけで解決しようとすると
  • 例えば、USBを使えなくする、メール転送できなくする、といった解決案がある。
    • つまり、雁字搦めにする。システムとルールで強制していく方法。でも、これで解決できないことある。
    • 例えば「印刷できない、メール転送できない」としても、写真でPCの画面を取られたら防げない。
  • なので、「システム」、「ルール」だけでなく、「文化」が大事になってくる。

文化醸成
  • Googleでは「Share Everything You Can」という思想を社員に奨励している。「共有できるものは全部しなさい」
  • 1.Google Resume
    • 会社に入ってからこれまでの経歴を履歴書にしていく、公開していく仕組みがある。
    • 自分の取り組みを常に公開しておく。
  • 2.Weekly Snipeet
    • 週報みたいなもの。今は関係なくても、いつか使うかもという考えで、共有しても問題がないなら、どんどん共有していこう。
  • 3.Codebase (Repository)
    • ソースコードは全部見える状態で公開している。

空間・時間特性による分類と応用例
  • CSCWの本で紹介さRている4象限(縦2×横2)の分類はいまでも生きているのでは。
  • 横の時間軸は「リアルタイム(即時)型」と「蓄積非同期型」の2パターン。
  • 縦の空間軸は「対面型」と「分散型」の2パターン。

ヒューマンコミュニケーションの氷山モデル
  • もう1つ大事なのが、人と人との協調、メンタルモデル。
  • 人に伝わっているのは氷山の一部。その下には相手の価値観だったり習慣だったり、いろんなものがあるのを忘れてはいけない。

Slack
  • ただのチャットツールとは全然違う。
  • Facebookのメッセンジャーは、メールの代替にはなりえない。検索が貧弱で、過去の発言を参照して相手と話すことが大変。
  • SlackはURLで過去の発言を共有できる。
  • テーマごとにチャンネルを分けられる。
  • 絵文字で顔文字とかできる。
  • 検索機能が強力。
  • Slackはフロー型と同時にストック型と同時に対面で使いながら分散型でもある。

最近のチーム開発におけるSECIモデル
  • 職人の匠を盗もうと思ったら、その場の空気を味わうことで盗む。
  • エンジニアはテキストやチャットをすることが増えている。オフィスにいても、静寂の中でSlackを使ってしゃべってる。
  • 最近はそれをミックスにしている。

システム/ツールの使い分け
  • 人はツールを自分の好きなように使う。
  • ツールは所詮、器にすぎない。何を乗せるかが大事。

Slackも万能じゃない
  • Slackも昔のメールのようになりつつある。
  • どう使うかが大事。

Botの可能性
  • 情報共有をしてくれない人はいる。
  • その人は、ミーティングでも情報共有しないのか、それともSlackとか使っても情報共有しない人なのか。
  • 口下手な人でも、テキストなら話せる人は、Slackとかは救いかもしれない。
  • Botで会話を引き出すこともできるのでは。会話が楽しい、という人ばかりではないのでは。
  • やっぱり、人と話すの疲れる。でも発信したりしたいことはある。
  • Botによって引き出されるコミュニケーションは結構ある。



リモートワーク
  • どうしてもリモートにいることで不利なことはあった。
  • オフィスの通路で、「このまえのアレ、どうだった?」、「~でしたよ」という会話をSlackでやるのは無理。
  • Face to Faceの利点はやっぱりある。
  • メンタルモデルを、P.68の図の左(1つのオフィスに人が所属する)から右(人同士がネットワーク型)にする必要がある。
  • メインオフィスが存在しない、ネットワークモデルにする。メンタルモデルとしてこーゆうのは重要。

学び方
  • 中から外へ。
  • Googleの、「共有して問題ないなら、してしまえ」という考え方。Share Everything You Can.社外へもOpen Sourceで。
  • アウトプットから考える。吐いてから吸う。どんどんアウトプットしていくと枯渇するので、吸う。
  • 「マズローの欲求5段階説」の5段階の更に上に「自己超越」がある。世の中のため、人のために行動する。

個人とチーム
  • 人は1人では生きていけない。チームの成長を考えていく。

One More
  • 野中先生の「アジャイル開発とスクラム」という本に衝撃的なフレーズがある。
    • 「自分の思いをコミットせずに、もらった仕様書だけを見て仕事をしている限りは、単なる情報処理者(Information Processor)です。」
    • 「われわれは知の創造者(Knowledge Creator)であって単なる情報処理者ではないんだ」
  • 如何に知の創造者になっていくかを考えてほしい。



プレゼン塾 澤円さん


20160305_codeiq1.jpg

自己紹介
プレゼン三層構造
  • 1.ビジョン ・・・なんのためにプレゼンするのか?これが説明できないとプレゼンはぜったい成功しない。
  • 2.核 ・・・ 何を伝えるプレゼンか?
  • 3.話術 ・・・ どうやって伝えるのか?
    • 話術はもちろん大事だが、上の2つの方がはるかに大事。
  • why, what, how。

お店を繁盛させるためには何が必要?
  • おいしいごはん、宣伝、リピータ、etc。
  • プレゼンで「話し方を教えてください」、というのと、ウェイターさんの「運び方を教えてください」は同じ。
  • 一番大事なのは、料理がおいしいこと。まずはレシピ、材料、素材が大事。
  • そして、立地。そして、日々のオペレーション。ちゃんと日々掃除しておく。
  • 開店の前に勝負は決まっている。美人なウェイターさんを採用しても、それだけで繁盛させることは無理。
  • プレゼンもまったく同じ。

ビジョンとスコープ
  • 2つの考え方ある。「ビジョン」と「スコープ」。

ビジョン
  • 究極の理想の形で、一度決めたら変更してはならないもの。
  • 決めるまでにたっぷり時間をかけてかまわない。でも一度ビジョンを決めたら、変えるな。
  • ビジョンを共有して納得すると、揉め事になったりした時に、ビジョンを確認することで全員を同じ方向に向き直せる。
  • これができないと成功が遠のく。

スコープ
  • 個々のタスクの範囲。変更可能。

まず、ビジョンを決める
  • プレゼン終了後、聴衆にどうなってほしいのか?
  • そして行動してもらわないとだめ。
  • 及川さんも、アウトプットしろ、といってた。
  • 行動しないと意味がない。相手の行動を引き出すこと。

プレゼンには「未来」を描け
  • プレゼンには未来が書かれていることが大事。
  • プレゼンには未来を描け。
  • 未来の行動を明確に謳う。

ホウ・レン・ソウ
  • 日本えはホウレンソウ(報連相)とよく言う。報告、連絡、相談。
  • 報告と連絡は「過去」の事象を対象にしている。そこに異常に時間をかけるのは効率が悪い。そんなのSlackやメールでいいんじゃないの?
  • 相談は「未来」が描かれるので大事。プレゼンには「未来が書いてあるのか」を見直せ。
  • ミーティングだって合コンだって、朝、「おはよう」という言うのだって、プレゼン。
  • 「時間と空間の共有」は貴重。しゃべることを目的にするのではない。話を聞くのと聞かないのとは、未来が異なる一歩を踏み出すくらいにならないと。

「なぜ自分がここにいるのか」を明らかにしましょう
  • なんでここにいるのか。
  • ビジョンは北極星。動いちゃだめ。動かないから船を出すことができて世界が動き始めた。正しい方向に向ける北極星を作るのだ。
  • ビジョンにはたっぷり時間をかけてください。

プレゼンの「核」とは?
  • 聴衆がプレゼンの後で、他の人にワンセンテンスで内容を説明できるもの。
  • きちんと言語することが、「核を作る」というプロセスにある。言語化のプロセス。
  • もう1個いうと、「聴衆がプレゼンの後で他の人にどうしても教えたくなってしまうもの」

伝言ゲームを制するものは世界を制する
  • 世界の有力者は伝言ゲームの先頭をとることがすごく上手い。
  • 先頭と最後がズレれない状態で、同じ熱量があること。そうなると世界が変わる。
  • 内容・価値が変質しない「普遍性」、「シンプルさ」が歌われているか。

シンプルであること
  • これは非常に大事。
  • エンジニアのちょっとした傾向に、難しい言葉を使ってしまう、というのがある。
  • 相手は思考が止まってしまう。宇宙人だと思われてしまう。もっともっとシンプルにしてあげること。
  • 冗長な説明は避ける。数字は強調表示すること。偉い人ほど数字が好き。
  • 詳細説明はスライドでなく添付資料で。プレゼンが伝われば、後で添付資料をちゃんと見てくれる。行動してくれる。

アクションの明確化
  • アクションを明確化してください。
  • 誰がなにをいつまでに
  • あながたやるんですよ、と当事者意識を持たせる。
  • 求められる結果と効果を明確に表現する。

"I have a dream"
  • キング牧師の有名な言葉だが、プレゼンのどのへんでこのフレーズを言ったか?
  • 真ん中を超えた、2/3あたりで言った。17分くらいの12分くらいで、7回言った。
  • そのうち2回は、「I have a dream today.」とリズム取るために言った。
  • 熱量があるので、50年以上前なのに、この場でも共有されている。
  • 今、オバマ大統領のような黒人の大統領まで出てきた。

"労働者に仕事とパンを"
  • ヒトラーがプレゼンで何度も繰り返し、大衆が動いた。
  • 名プレゼンの代表だが、人類の黒歴史なのであんまり共有されてない。
  • 「労働者に仕事とパンを」。これが彼のコミットだった。
  • 政治手腕が凄かった。本当に失業率が悪かったドイツを立て直した。
  • 彼の周辺で働く人たちを、ある名で呼ぶようになった。ゲシュタホ。親衛隊。
  • 熱烈なファンを作った。

プレゼンはファンを作る方法でもある
  • 二次感染、三次感線する言葉にしておくことが重要。
  • 自分ならではの「核」を作りましょう!

核を盛り込む、スライド作成の具体的なテクニック
  • 以下、説明していく。

スライド1枚にテーマ1つ・説明3つ
  • これ以上あると理解されない。
  • 人間は5つまでしか1回で理解できない。
  • 理解度が上がる確率があがる。
  • 問題提起したあとで3行程度で説明する。
  • ですます調は必要ない。

アニメーションは控えめに
  • あくまで視点誘導のために使う。
  • 人間は83%を視覚で得ている。視覚に依存しやすい。なのであえて誘導する。

色使いもシンプルに
  • 1スライド中、4色以内に。
  • 意図しない意味を持たせないように注意。
  • 赤とか黄色は警告色。意味がある印象を与える可能性がある。
  • 薄い色は印象が弱くなる。

文字を「閉じ込める」
  • 画面が広すぎるので、文字を詰め込みたくなる。
  • 文字は落とすほど良い。
  • 枠を決めて、その中に文字を入れ、際立たせる。

改行の位置もとても大事
  • 文中の意味のない場所で改行しない。ノイズをいれない。

視点誘導の方向
  • 視点誘導は左→右か上→下へ。
  • 数字の表現は、右肩あがりにする。
  • 右肩下がりは印象が悪い。ネガティブな印象を防ぐがめ、右肩上がりに。
  • 事故率は減ったほうがいいが、儲かりまっせ、なら右肩上がりがいい。

思いついたキーワードで画像検索
  • セキュリティ、だと鍵、パスワード、盾、ガードマンなどのキーワードが思い浮かぶ。
  • そのキーワードで画像検索してみて、この絵を使って話しようかな、としている。

スライドタイトルと画像を混ぜる
  • なんの話題がすぐわかるし、かっこよくなる。
  • なんの話題なのかを強調する。
  • 関連が読み取れない画像は逆効果。

画像を背景にする
  • 洗練された印象を与える
  • こちらも関連が読み取れないものは逆効果。

お勧めサイト
「最後に」のスライドのススメ
  • トドメの印象づけをする。
  • 時間調整にも使える。
  • 途中参加の人にも安心感を与える。

話術
  • プレゼン三層構造の最後。

自分のくせ、わかってますか?
  • 何かを考えているときに出る言葉
  • センテンスの前につけがちな言葉
  • 気づけばいい。えーと、あのー、とか。

よく使い回す言い回し
  • ちなみに、基本的に、etc。
  • その言い回しが前後の文脈で全然繋がってなかったりすることがよくある。
  • 意味を考えないで付けるとノイズになる。

"くせ"を気にする余裕を持つことが大事
  • プレゼンの機会は録画するのがよい。
  • 最初は、自分の録画プレゼンを見るのはすごく気分が悪い。でも、2度3度とやると改善する。絶対にやってほしい。効果は保証する。

バリエーションを増やす
  • 同じ意味で同じ効果を言葉を増やす。
  • 例:簡単に
    • 言い過ぎると薄れるので、以下のようなバリエーションで言い換える。
    • 少ないステップで、ワンクリックで、この画面だけで、シンプルに

今日から練習!
  • まっすぐ立つ
  • はっきり話す
  • 腹筋を意識して立つ、座るを意識するだけで違う。人間は腹筋から衰えていく。

毎日できる練習方法: 「話す」
  • お店の人とのやりとりで丁寧な言葉を使ってみる
  • 「お箸は結構です」とか、「おつりありがとうございます」とか。
  • コンビニのレジでやってみる。
    • 隙間時間の有効活用になる。
    • レジの相手がニコッとしたら成功体験になる。
    • レシートを受け取って無言で去る、とはぜんぜん違う。

毎日できる練習方法: 「視線」
  • 電車に乗ってる人たちの顔を短時間ずつ均等に眺めてみる。
  • ちゃんとみんなの顔が見られるか。
  • 見てない人を見るテクニックを身につけるため、電車の中でやる。
  • 顔を見たほうがいい。

プレゼン当日までの過ごし方
  • 隙間時間にプレゼンのことばっか考える。
  • 通勤中、入浴中、食事中に、自己紹介とかを考える。

アイスブレーク
  • 笑わせるところに集中するとリスク。
  • 決死の覚悟でのギャグ発射はリスクが高い。
  • あくまでも、ちょっと雰囲気を柔らかくすれば十分。

ちょっとずれた表現の効能
  • 印象が残る。
  • 「非常に便利」じゃなく、「便利さに全米が泣いた」、みたいな。

デスクトップ画面のメニューなどが見えた状態でプレゼンしないこと!
  • アイコンなどが視覚的なノイズになる。
  • スライドショーの機能を使ってやりましょう。

スライドショー
  • プレゼンテーションモードを使うと良い。次のページのスライドとか、話すべきメモが見える。
  • スライド一覧モードを使うと、スライドを自由に行ったり来たりできるので、スライド飛ばしに有効。
  • プレゼンの最後に時間が無くなって、スライドをペラペラめくると慌ただしい印象を与えるので注意。スライド一覧機能で移動すべし。

背中で語らない
  • 相手に背を向けてプレゼンをすると一体感が生まれない。
  • 聴衆と会話すること。

笑顔はプレゼンの最大の武器
  • 女性のほうがやはり得意。化粧する時に自分の顔をよく見るので。
  • ちゃんと自分の顔を見て、顔の筋肉がどう動くのかを知ること。笑顔が引きつってる人とか、結構いる。

表情
  • まじめ、時々にっこり。ずっと笑顔じゃなくてよい。
  • 口角が下がるのはダメぜったい!筋肉が衰えれば、ぜんぶ下がる。その印象を与えてしまう。

堂々と見せるテクニック
  • 口と足。
  • 話す速度よりもゆっくりと歩く(動く)。
  • せわしない印象を与えないように。

手の動きは重要
  • 意味のない動きはしないほうがいい。

最後に
  • プレゼンのポイントは3つ。ビジョン、核、話術。
  • 誰でも必ず上達する、そして必ず成功します。
  • 聴衆は決して敵ではない。
  • 相手の期待に応える努力をする。
  • みんなは自分の上達を支えるためにいる、と考える。


今日の話は全部これに書いてある。
外資系エリートのシンプルな伝え方
澤 円
KADOKAWA/中経出版
売り上げランキング: 233,088



パネルディスカッション


増井雄一郎さん・Jason Danielsonさん・澤円さん・及川卓也さん・星野俊介さん


テーマ:「海外と日本との違い」
  • 1.ワークスタイルの違い
  • 2.キャリアの違い

アメリカは労働時間が短いイメージがある。定時で帰って、アフター5を楽しむイメージがある。

ジェイソンさん:
  • 2種類の場合がある。
  • 大手企業は残業の概念がない。会社に来ないとクビだけど、細かく時間は見られない。
  • ベンチャーは時間にあまり決まりがない。
  • 朝、運動してから仕事してるとか。
  • 結果が出るなら、仕事の順序を入れ替える。子供と食事したあとに仕事とかもある。
  • 机に座ってるのが仕事じゃない

Googleと日本
  • 世界でワークスタイルを合わせる、というスタイルがある。
  • どこのオフィスもだいたい同じカルチャーがある。
  • 日本って時間に厳しいっていうけど、開始時間だけ。ミーティングはエンドレスに伸びたりする。
  • 時間が余ったら他の話題について話し始めたりとか。
  • 日本は効率性を考えない。精神論でがんばろーぜ、ってのがある。
  • なぜ大東亜戦争で負けたか、というと精神論で勝てると言ってたから。それは昔から変わってない。
  • 工場の生産性とインフォメーションワークは違う。

マネージャによる部下の評価
  • マネージャは目の前に部下がいないと評価できない、と言う。
  • 評価する能力がないので、目に見える労働時間で部下を評価する。
  • 雪で4時間かけて出社した、とかSNSで見かけるが、そんなの全然意味がない。

解雇について
  • 外資ではすぐクビになるイメージが強い。
    • そういう契約になってる。実際はクビの前に警告が出る。警告が数回あってからクビ。前フリがある。
  • 海外は転職しやすいのでクビはあんまり心配してない。会社を変わることで給料が上がる。
  • 日本は指名解雇ができない。
  • マイクロソフトでは、解雇までの猶予を与えて転職活動しなさい、というのはある。
  • クビにできるようにしないと、怖くて採用できない。
  • 日本ではパフォーマンスが低くてもクビにしない。それは教育コストをかけてるから。

解雇と能力の関係について

  • Googleはポテンシャルがある人を採用しているので、成果が出ないのは何か原因がある、と考える。なので面談とかして原因を探す。
  • 能力が低いのではなく、仕事が合ってないことも多い。仕事と能力がミスマッチなことが多い。
  • ミスマッチなら他に行ったほうがいい。でも日本は人材流動性が低いので不幸。
  • 「アップ or アウト」という考えがある。能力や成果が上昇しなければクビ。
  • 仕事を普通にやってても、他の人に抜かされればクビになる。
  • 能力が低い人が組織にいると、「こーゆう人でも許されるのだな」と職場に認識されてしまう。それで組織が腐っていく。
  • 成長しないなら辞めてください、が正しい。
  • クビにできないと、能力が下の人のレベルに合わせなくてはいけない。

Googleの「ボトム5%ルール」の思想
  • 100人うち、ボトム5人をアイデンティファイしろ。
  • トップとボトムをはっきりさせる。

クビにできない文化
  • クビにするための墓場のような出向先があった。キーボードが打てない人が管理者になってやってくる。
  • 部長にしてやるから行け、みたいな。
  • 大きい企業ではその仕組みができちゃってるのでは。ある意味不幸。給料もらえればいいや、となる。
  • でも、これではコストがかかるからグローバルで戦えない。
  • これまではそういうのに耐えられる時代があった。
  • グローバルは暗い話になるかも。競争が激しいので。
  • 大学に行っても初任給が低ければ大学へ行く意味がない。

採用
  • 外資は新卒採用が難しい。1年後の状況さえわからないので。
  • 通年採用のほうが楽。
  • 楽天も4月の大量入社が無くなった。通年採用のみ。

給料
  • アメリカは給料比較サイトとかがある。
  • お金の話しない=交渉しない=低い給料

何歳になってもコード書ける?
  • マイクロソフトでは、マネジメントに飽きたから卒業して、コードを書く、という人がいる。
  • 40歳を過ぎてもコードを書いていけるものか?
  • コードを書く、というのと、ピープルマネジメントは排他じゃない。両立できる。
  • 部下を持たずにエンジニアで偉くなる人もいる。コードを書かなくてマネジメントで行く人もいる。
  • コードをずっと書くことは何歳までもできる。デイブ・カトラーも現役。でも難しい。
  • コードで人を評価するの難しい。「コードが凄い」というのをどう評価するか。
  • 言語化してフェアに評価できるかは、かなりのエンジニアがいないと無理。なので難しい。組織がついてこないと。
  • 「インパクト」を定義して、本人とマネージャで評価するというのがある。インパクトの定義は自分でやる。
  • ハックしたもの勝ち。でも、派手さと下支えの評価は難しい。下支えを評価するの難しい。
  • 日本はソフトウェアを舐めすぎている。
  • 評価される → 成長する → もっとすごいことができる

海外での仕事
  • 英語でぱっと短く説明できる能力が必要。やりことをまず言語化する。
  • インターネットがあれば海外OSSの仕事とかはすぐできる。
  • 自分のいいたいことをきちんと伝える。
  • いきなり巨大なOSSじゃなく、小さいなところからやればいい。パッチ上げたりバグ直したり。

最後に一言ずつ
  • 日本初の世界サービスで世界に行きたい。
  • 日本では200万人くらいしかコードを書いてる人がいない。
  • 日本はぬるま湯。このままだと、気づかないうちに茹で上がって死んじゃう蛙のようになる。
  • 日本語と英語の時間のギャップは利点になる。先に制したほうが儲かる。
  • 日本にいながらにできることはある。
  • とにかくなんでもいいからグローバルに接点してほしい。
  • アウトプットをどんどんしていく。アウトプットしているとオファーが来る。どんどん接点が増えてくる。
  • アウトプットを英語でやるともっと見につく。
  • 自分でやりたいこと自分で決める。諦めたらそれが失敗。自分で決めて、やればいい。


基調講演(2) Jason Danielsonさん テーマ:「考える力」




生い立ち
  • ミシガン州生まれ。田舎。最寄りのコンビニまで車で20分かかる。
  • ミシガン州立大学でコンピュータサイエンスを修めた。

日本語の勉強
  • 大学で、外国語で日本語を勉強するようになった。2年間勉強してもまったく会話できなくて悔しかった。
  • 完璧な文法や単語なくても、なんとかなる。思いは伝わる。
  • 日本語が上手くならないうちにいろいろやった。楽しいことをやった。
  • 勉強のための勉強は続かない。成功するためには、続ける仕組みが必要。やろうとしていることが上手くなる。

お笑いの道と結婚
  • 日本語勉強の副作用で、お笑いにも手を出した。
  • 嫁は通訳。通訳を嫁としてお持ち帰りした。

修士号の取得
  • GEに学費を出してもらって修士号を取った。でも、日本へ行かせてくれなかった。
  • 人生は1つだけだから、やりたいことやるだけ。GEで日本に行かせてくれないから、修士号を取ってからすぐ会社を辞めた。

パッケージソフトを扱う会社への転職
  • 日本はパッケージソフトをそのまま使おうとせず、カスタマイズをバリバリやる。
  • なのでパッケージソフトが売れなかった。
  • 日本Why!? あるものつかえばいいじゃん!

仕事と人生
  • 会社で偉くなりたかった。会社で出世してきた。でも、仕事だけじゃないな、と思った。
  • 魚をもっとつれば売れるよ → たしかに凄そうだね → それで儲けてお金いっぱい貯めて、それで退職して魚を釣ればいいじゃん → もうやってるよ!
  • 命は限られてる。出世ばかりじゃない。

すぐやることは大事
  • ITの進化スピードは凄い。車の進化はそれほど速くは無かった。せいぜい燃費が少し良くなった、とか。
  • この30年で、人類の知識がスマホに入るようになった。大きい進化はIT業界だけ。
  • 気をつけないといけないのは、何百年もかかる考え方をITに入れても合わない、ということ。
  • ソフトウェアを5年もかけて出しても、その間に市場も変わる。スピードがぜんぜん違う。
  • ひとつ伝えたいことは、「すぐやることは大事」ということ。
  • 日本のIT企業は時間をかけすぎ。NTTドコモの「i-mode」も、簡単なスマホだけど普及しなかった。
  • それは、会社が価値を見いだせなかったから。スピードが合わなかった。
  • アップルは違う。iPhoneは一瞬で広まった。

英語
  • 新しい情報は英語で出てくる。
  • 英語を勉強すると価値が上がる。
  • wikipediaは、英語のページは日本語のページの13倍以上ある。英語のほうが13倍以上の情報量。
  • 英語を知ってるだけで世界が広がる。

人生は仕事だけじゃない
  • 夜遅くまで残業ばかりしていたら、新しいことはできない。
  • 仕事以外のことやることで世界が広まる。
  • ITとは全く関係ないこともやったほうがいい。自分の意見も広がる。
  • 私も、芸人活動で考え方が変わった。プレゼンですべっても怖くなくなった。そういう付加価値も身につけられた。

やってることの理由を考える
  • 是非、自分がやってることの理由を考えて欲しい。言われたことだけをやってる、ではダメ。
  • 自分がなぜやってるか、理由がわからななら、やらないほうがいい。理由がわかるまで、やらないほうがいい。
  • 使われないものを作っても意味がない。
  • なぜやってるか、説明できないといけない。
  • もっといい方法があるかもしれない。価値を出しましょう。
  • 付加価値だけじゃない。
  • 最近、TVにムカついてる。業界の方ではなく、機械の方ね。いらない機能がありすぎ。でも機能を絞ったTVは提供してない。
  • TVを開発してる側が、いらないものを付加価値だとずっと思ってる。
  • 無いもの足せば価値がある、ではない。課題を解決できるか、が大事。
  • 問題がないところを解決しようとしても意味がない。

最後に
  • テラスカイは平均残業時間が0.8時間/週なので、自分で勉強する時間はいっぱいある。
  • 明日、R1グランプリの決勝がある。4000人弱の参加者で、9人くらいが決勝に残った。
  • 視聴者投票があるので、Dボタンが無ければ今日TVを買ってね。

考える力
  • 自分が何をやってるのかを考えることで、よりよいものが生まれる。
  • 自分の考え方からぜんぶ始まる。


感想


期待通り、とても有意義なセッションばかりで勉強になりました。
関係者の皆様、ありがとーございました。

「AngularJS入門者向けハンズオン」に参加しました

2016/2/27(土) 「AngularJS入門者向けハンズオン」に参加してきました。

connpass
http://connpass.com/event/25154/

場所は渋谷ヒカリエのレバレジーズ本社です。
参加者は60人くらいかな。

先日、Angular2勉強会の勉強会に参加してブログに書きました。
「第1回Angular2勉強会 #ng2Curry」に参加しました

この日は↑の3日後の、また別のAngularの勉強会です。
同日AMには別の所でAngularの勉強会も開催されていたようで、Angularの勉強会が増えてきたのは良いですね。

以下、復習用のメモ。


Angular.jsのきほん


@can_i_do_web 氏

ngTeratail from Kenichi Kanai



Concepts
  • SPAに必要だよね、と言われていた機能達を、AngularJSはすべてサポートします。
  • めちゃめちゃ特化している

特徴
  • フルスタック
  • HTML enhanced
    • htmlにngなんとかを書いてHTMLを拡張する
    • 本家サイトのロゴの下にも書いてある

得意なところ
  • CRUD系アプリ
  • 管理画面
  • ハイブリッドアプリ
    • Ionic、OnsenUIではSDKの内部でAngularが使われている。簡単にハイブリッドアプリが作れる。

苦手なこと
  • モバイル向けアプリ
  • ゲームのグラフィックやエフェクト
  • いわゆるWebサイト
    • SEO(検索エンジン最適化)を必要とするところはAngularは適していない。そもそもSPA自体が適していない。
  • Angular1系は若干遅いが、速度を意識しない場合はぜんぜん採用してよい。

Data-Binding
  • 入力したものを出力する。
  • <input ng-model = "モデルの名前">
  • jQueryを数行書いてたのより遥かに楽。

Built-in Directive
  • Angularが元々用意してくれたDirectiveがたくさんある。
  • ng-なんとか

Dom操作
  • aタグは使えるが、Angularで拡張されたaタグになってる。同じように使える。
  • formとかinput属性がすごく拡張されてて、formのvalidation機能が強力。

From Validation
  • requirede ・・・ 必須チェック
  • min / max ・・・ 最大と最小のレンジ指定
  • バリデーションはHTML5の機能としてブラウザに搭載されている機能だが、なんで流行っていないかというと、すごい使い勝手が悪いから。
  • 自分自身であれこれバリデーションをしたいので、Angularが用意している。
  • ng-pattenは特殊。正規表現で定義できる。あんまりお薦めしない。居所的に使うのがよい。
  • URLのチェックしたいなら、<input type="url">と書くだけでバリデーションが走る。
  • form[name].input[name].$valid etc
  • バリデーションがどういう状態か、我々がわからないとどう処理していいかわからない。
  • これ、つらいっすよね。書くと簡単だけど説明するとこーなった。
  • form[name].input[name].$valid
  • name属性を使って取得するのでname属性で関連づけていくことになる。
  • ng-disabled ・・・ フォームのチェックが通るまでボタンが押せなくなる。割とコレが使える。

Filter
  • Angularの中身のデータをTemplateエンジンの表示変換で使う。
  • dateが一番使う。filterも何でも定義できるのでよく使う。
  • サーバから返ってきた日付を、表示形式を変えて出力してください、とかよくある。
  • dateフィルタを使って好きなフォーマットに変換して表示できる。
  • サーバからもらったデータを加工してしまうと、サーバに返すとき変換しなおす必要があるが、Filerは加工しない。表示するときだけ変換する。
  • orderBy ・・・ 並び替え。日付順とかアルファベット順とか。
  • limitTo ・・・ ループ処理のディレクティブの検索結果10個のうちの3個だけ出すとかできる。

Custom Directive (Component)
  • タグとか属性を勝手に作れる。そのAngular版。
  • count upをコンポーネント化しようとするとangularだとこうなる。
  • angular.module().componentという書き方が1.5から使えるので使って欲しい。
  • コンポーネントの中にコントローラを書いて、カウントアップのコードを書く。
  • 何が良いかというと、myCounterがHTMLのタグとして使えるようになる。
  • 小さいUIコンポーネントの塊を定義しておくことで、自分のアプリで使える。
  • 世の中的にはコンポーネントが流行るに連れて、こーゆうのが増えていく。
  • Angularとしても覚えていくと使い回しが効く。

Plugin
  • AngularUI ・・・ bootstrapを使ったりもできる。Angularのバージョンアップのときに足枷になるので注意。
  • Angular Mdules というサイトでプラグインをいっぱい探せる。
  • Angularはフルスタックだけど、こーゆう機能ほしいなぁ。でも、自分で作るの面倒なので、プラグイン無いかなぁ、と探す感じ。

ng-japan 2016
  • 3/1申込開始。
  • http://ngjapan.org/



ハンズオン


ハンズオン題材はこちら。
https://github.com/can-i-do-web/ngTeratail

講演資料で紹介されたAngularの機能を使ってのハンズオンです。

makopi23がハンズオンで書いたコードをGitHubに上げました。
四苦八苦して書いた糞コードです・・・
https://github.com/makopi23/ngTeratail

実行させるとこんな感じです。
20160227_ngTeratail1.jpg

先日、社内のAngular勉強会でAngular1.5のコンポーネント機能を紹介したのですが、良い復習になりました。







質疑応答メモ


エディタ
  • エディタはVisual Studio Codeを使うと、ng-なんちゃらとか補完してくれる。

SPA
  • SPAはデータの管理が楽。フロントエンド側で完結するので。
  • Ajaxが使えると、非同期で画面を一部書き換えられるので、通信を最小限に抑えることができ、レスポンスが早くなる。

Angular vs React
  • AngularはRouterがデフォルトで組み込まれている。RouterはURLと描画を結びつける。
  • いくつかのページを跨いだアプリはReactよりAngularの方が良い。

Angular 2
  • なぜAngularJSの後継としてAngular 2が登場したのか?
  • AngularJSはJavaScriptで出来ることだけで工夫するというライブラリ。でも、それだけじゃGoogleの満足じゃない。
  • Angular2は、AngularJSの「JS」が名称から外れている。
  • TypeScript、ES6、Dartなど、最新の技術を駆使したのがAngular 2。あと、1より高速化している。
  • Angular 2は、AngularJSにパッチを当ててる領域じゃないレベルの改変が入っている。

ControllerやComponentの粒度
  • Q: JavaScriptのサイズはどのくらい?
  • A: ケースバイケース。1ディレクティブで、1ファイル=1モジュールとする。

Angular 2とTypeScript
  • Angular 2の開発がTypeScriptで行われている。
  • 公式ドキュメントもTypeScriptが多い。
  • 個人的にはTypeScriptを使うと安心する。
  • でも、Angular2はTypeScript専用ではなく、ES5でもES2015でも行ける。
  • ただ、Googleチームで議論したら、TypeScriptで書く、という結論になったらしい。
  • ES5は古い仕様で、陳腐化していく。
    • ⇒ ES2015でも書けるようにしよう。
    • ⇒ それに型を加えたTypeScriptで書けるようにしよう。
    • ⇒ 将来、ES2015で書けるようになるならそうしよう。
  • Babelを使うくらいならTypeScriptの方が良いかな。
  • Angular 2のDIで、TypeScriptだと型を元にDIできる。Type-Based DI。これはBabelでは出来ない。

Directiveの粒度
  • Directiveは、一番多くても150程度だった。管理が大変。
  • 粒度は、自分の直感を信じて大丈夫。
  • ただ、ng-repeatを使っている場合は問題になる。
    • ng-repeatの中の要素にDirectiveが3~4個あるとすると、100回の繰り返しでDirectiveが300~400回も使われる。
    • Directiveは1回で5ms~10msかかるので、ng-repeatで数秒かかってしまう。
    • なので、ng-repeatの中のDirectiveは極力小さくすべし。

Angularの速度
  • 普通の使い方をする分には気にしなくて良い。
  • 気にしないといけないのは、アニメーションとかレンダリングとか。
  • 数msの世界で戦うアプリにはAngularはおすすめしない。
  • 多少遅くても、インタラクティブにしたいならば、レスポンシブなCSSを適用してAngularを使えば良い。
  • フリックに対して何かのイベントが発火して、のようなスマホ特有のものはAngularオススメ。
  • 速度 vs 書きやすさ、で天秤にかける。
  • Angularがモバイルに向いてないのは、遅いから。モデルの数に比例して遅くなる。
  • Angular 2では速度が劇的に速くなるので、モバイルでもOK。


感想


まず、メンターによるサポートが充実してて、ハンズオンの時はとても助かりました。
やっぱ実際に手を動かして動作させてみるのが一番理解が早くて、楽しいですね。

あと、途中からお酒飲みながら、という進行も良いですね。
最後の懇親会も、いろんな方とAngularについて話す機会は貴重でした。

関係者の皆様、ありがとーございました。

「第1回Angular2勉強会 #ng2Curry」に参加しました

2016/2/24(水) 「第1回Angular2勉強会 #ng2Curry」に参加してきました。

connpass
http://lig.connpass.com/event/26115/

場所は上野のコワーキングスペース「いいオフィス」さんです。
参加者は60人くらいかな。

Struts1ベースだった自社の開発フレームワークがAngularJS+Springベースに刷新中で、個人的にもAngularJSを勉強している最中なのです。
部内でもAngularJSの社内勉強会を毎週やってます。
Angular1しか触ってませんがAngular2にも興味はあったので、ちょうど良い機会、ということで参加しました。

以下、自分用の復習メモ。


はじめてのAngular2


金井 健一 氏 (AngularJS Japan User Group 管理人)

はじめてのAngular2 from Kenichi Kanai


Concept
  • Angular2はSPAに必要な要素をすべてカバーしている。
  • Data Binding、Template Engine、Routing、Ajax Support、Test、Security、DI

Concept - from Angular2
  • Angular2からComponet-BaseとUniversal JavaScriptというコンセプトが追加になった。
  • Componet-Base ・・・ Angular2ではタグを書いて、すぐコンポーネントを宣言しないといけない。
  • Universal JavaScript ・・・ JavaScriptが動作する環境なら、どこでも動けばいいじゃん。

Dependencies
  • Angular2をやるにあたって、知っておかないと苦労すること
  • ES2015
  • RxJS ・・・ 非同期通期で、Stremでデータを管理するライブラリ。RxJSを知らないと辛い。
  • TypeScript
  • SysteJS ・・・ モジュールをカバーしてくれる?

Hello Angular2
package.json
  • 6、7行目のlite-serverが動かなかったので、消した
  • npmをインストールするといい。

app.component.js

  • 以前よりコード量ちょっと増えた

main.js
  • componentをロードする

Directive
  • Angular1のDirectiveは70くらいあった。
  • Angular2でDirectiveの数は実質減った。ng-showとかng-hideは無い。代わりにNgClassでやることになる。

Angular v 1.xとの違い
  • Angular1のServiceは、Angular2だとClassになる。
  • Angular2はES5でも書けるが、オフィシャルはTypeScriptのサンプルしかない。昔はES6のサンプルとかもあった
  • TypeScriptは決して必須ではない。無理して使わないでもよい。

オフィシャルがTypeScriptになぜなったかの経緯
  • コミュニティのユーザに、どのトランスパイラを使うかアンケートをしたら、以下の結果だった。
  • TypeScript 45%
  • BABEL 33.2%
  • ES5 9%


Angular2 With Libraries


laco 氏 (株式会社トップゲート)

20160224_ngcurry1.jpg

AngularJS Library
  • モジュールシステムがあるのが特徴。
  • 文字列ベースのDIでライブラリの機能を使う。
  • 標準機能とライブラリ機能の使い方に差がないのがよい。
  • 公式ライブラリがいくつもある。
  • 公式で提供されてオープンソースなので、お手本になる。
  • npm以外でも全部で1万を超えるんじゃないか。

Angular 2 Library
  • 独自のモジュールシステムが無くなって、ES6のモジュールを使う。
  • Type-based DI : 引数の名前が間違ってDIができない、ということが無くなる。
  • サードパーティ製のライブラリ作るお手本となる。

Angular 2のライブラリの使い方
  • importで読み込む
  • 読み込んだクラスをDIでコンポーネントから取得して使う。
  • 2段構成から外れないことが混乱しない方法。

DI:Provider/Injector
  • DI ProviderとInjectorがセットになって動く。
  • SampleServicはhttpをDIする。

Official Libraries
  • 基本的なところから外部化されている。
  • コアな機能にはAjaxの機能がない。

http
  • httpパッケージ使うにはHTTP_PROVIDERSをimportする。
  • bootstrapで定型的に書く。

Http classの使い方
  • httpをインポートする
  • SampleServiceにInjectする。
  • httpを使う機能を書く。

Observableとは?
  • ReactiveX/RxJSが提供しているクラス。
  • Angualr 2はRxJSに依存している。
  • Angular2をちゃんとのやろうとおもうとRxJSを勉強しないとダメ。

Component Router
  • URLのパスとコンポーネントを紐づける機能。
  • ui-routerをベースにしてる。
  • 4つの登場人物がいる。RouteConfig、RouterOutlet、RouterLink、Router。

Setup
  • 2つimportする。後者はbaseタグ。
  • 嫌な人はHashを使える。

Route Definition
  • どこからどこへ、を定義する。
  • コンポーネントに対して設定する。
  • /fooにFooComponentを出すように書く。
  • 設定できるプロパティは5つ。

Manual Navigation
  • router.navigateはPromiseを返す。

testing package
  • 依存が無くて個別に利用可能。
  • angular2/tesging は単体テストで使える。いろんな単位でテストできる。Jasmineに依存している。

angular2/http/testing
  • httpリクエストをモックする。
  • Jasmine非依存でシンプルに使える

angular2/router/testing
  • ドキュメントが0。
  • ソースコードが2つしか無いのに使い方がわからない・・・

Summary
  • httpはObservableと共にある。
  • RouterはPromiseと共にある。
  • Angular 2はβなので、今後変わる可能性がある。
  • APIを追うのではなく、APIの思想を理解しておきましょう。
  • angular2とbootstrapは衝突しない。
  • angular2materialが開発中で、マテリアルデザインできる。


Angular2へのマイグレーション


稲葉 聡 氏 (株式会社LIG)

Angular2 migration from Satoshi Inaba


現在携わっている某受託案件の場合
  • 3つのアプリ App1、App2、App3のうち、App2でマイグレをやってみようかなと考えた。
  • でも、Directiveが55個もある。

マイグレーションの2つの選択肢
  • 1.Angular 2で一から書き直す
  • 2.少しづつマイグレーションする。
    • モジュール単位で1こずつAngular2に置き換える。

少しづつマイグレーション
  • Angular 2にはマイグレーションの補助ツール ngUpgrade がある。

マイグレーションは簡単ですか?
  • 会場で挙手した人は1人~2人。
  • 答えは、「プロジェクトによる。」

マイグレーションしやすくする為の準備
  • Angular Style Guideに従う。
  • トランスパイラの導入
  • モジュールローダの導入

Angular1.5のComponetは必須か?
  • Directiveでも定義を気を付ければ済む話でもある。

TypeScriptの導入
  • TSは始めると意外に平気。素晴らしい。
  • けど数があるので、TSへの書き変えが大変で、挫折した・・・


感想


Angular1しか触ったこと無いので、内容が難しくて付いていけない部分も多々ありましたが、勉強になりました。
いざ、Angular2が正式にリリースされて勉強を始めた時に見返したいと思います。

関係者の皆様、ありがとーございました。

「Developers Summit 2016 - Hack the Real - 」に参加しました - Part3 -

2016/2/18 ~ 2/19 「Developers Summit 2016 - Hack the Real - 」に参加してきました。

公式
http://event.shoeisha.jp/devsumi/20160218/

デブサミ2016、講演関連資料まとめ
http://codezine.jp/article/detail/9255

先日、聴講メモPart1とPart2を書きました。


その続き、Part3。自分がスライドをメモを見返して復習するため、チラ裏の描き殴り。

【18-B-6】 マイクロサービス時代の大規模動画配信基盤 ~ 
Ruby × Go = ∞


http://event.shoeisha.jp/devsumi/20160218/session/994/

マイクロサーヒ・ス時代の動画配信基Ruby×go=∞ from DMMlabo

  • 組織構造とアーキテクチャは密接に関わる
  • PUB/SUBメッセージングモデル ・・・ Part2のりアクティブアーキテクチャのセッションにも登場した非同期通信のモデル
  • HATEOAS ・・・ Restful APIを拡張したアーキテクチャパターン。レスポンス値にリンクを付与し、次への遷移先を選べるようにする。
  • トレースIDをHTTPヘッダに入れて、ログから追えるようにしてデバッグの容易性を上げるようにしている。



【18-D-7】 エンジニア・コミュニティで組織は動き出す
 ~これからの時代のエンジニア、組織、エンジニアと組織の関係とは


http://event.shoeisha.jp/devsumi/20160218/session/1011/

エンジニアコミュニティで組織は動き出す from Haruo Sato

  • 創造性を失わせる最大の敵は、できないかもしれない、という恐怖。
    • 不安がなくなるまでは技術を徹底的に身につける。 → 自信がつき、心が安定し、不安が少なくなる
    • 求められる結果にはいったん付箋で蓋をして、プログラミングを楽しむ。 → 集中できて、結果につながる
  • 感動が少ない人は好奇心が薄れ、記憶も弱まる → 結果、退化していく。



【19-B-1】 情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~


http://event.shoeisha.jp/devsumi/20160218/session/1028/

(資料公開待ち)



【19-A-2】 大規模BIクラウドWebサービスの裏側 ~ Waveの内部アーキテクチャとデザイン理念 ~


http://event.shoeisha.jp/devsumi/20160218/session/1021/

大規模BIクラウドWebサービスの裏側 from Mitushiro Okamoto

  • PODは横にコピーすることでスケーラビリティを担保できる。
    • 組織を飛び越えてデータをシェアすることはあまりないので、このアーキテクチャは有効。
  • ステートを持っているのは最上位のエキスプローラのみ。
    • → コンポーネントの再利用性に注力している。
  • Wave Client コードベースは、データの横渡しはさせない。 → Client/Common経由で渡す。
    • → 製品を超えて、Analytics Commonを置いた。どんどん共通化していく。
    • → コードベースを綺麗に保って独立性を保つことで、プルリクで取り込むテストが短くて済む。



【19-D-L】 エンジニアを成長させるための組織作り


http://event.shoeisha.jp/devsumi/20160218/session/1046/



講演者さんのブログ


  • 求めるのはプログラミングで課題を解決する力
  • 機械学習愛会でボンバーマンの対決バトルなどをやっている。
  • ドローンの自動制御などにも取り組んでいる。



【19-B-3】 HTTP とサーバ技術の最新動向


http://event.shoeisha.jp/devsumi/20160218/session/1031/

HTTPとサーバ技術の最新動向 from Kazuho Oku


  • 最近、端末の画素数と画面サイズが大きくなって、ネットワークの転送量が増えた。
  • HTTP/1.1では1RTTあたり1リクエスト/レスポンス。緩和策として同時6本のTCP接続があるが、っそれでも遅い。
  • HTTP/1.1パイプラインも使われていない。
  • HTTP/2
    • ヘッダ圧縮して通信量を削減 → バイナリプロトコル
    • 同時に100以上のリクエスト発行可能
    • 優先度制御 ・・・ クライアントがリクエスト毎に優先度を設定



【19-C-4】 事業に貢献する顧客開発とその成長の仕組み作り~これからのエンジニアに必要とされるスキルとは~


http://event.shoeisha.jp/devsumi/20160218/session/1040/

事業に貢献する商品開発と その成長の仕組み作り ~これからのエンジニアに必要とされるスキルとは~ from JustSystems Corpration

  • ひとことで言えない会社にしたい。
  • 部隊を分けない。部署を分けない。組織としてわけない。良い意味でのカオス状態にして議論を生み出す。
  • 訴求ファースト
    • 提案することを止めない。
    • ビジネスは心を動かせるかどうかが勝負。
    • エンジニアは作るのが楽しいからすぐ作っちゃうけど、ちょと待て!訴求するか考えて社内議論する。
  • TechCABINET(技術内閣) ・・・ 商品軸でなく技術軸で課題を抽出。
  • 成果を出すための手段として、学ぶ。



【19-A-6】 アジャイル開発(GINZA)


http://event.shoeisha.jp/devsumi/20160218/session/1026/

20160218_devsumi3.jpg
  • Practice Slaves kill Development
    • プラクティスに執着するあまり、プロジェクトを壊している人がいるんじゃないか?
  • 「Do Agile right」という言葉がある。でも、「正しい」アジャイルって何ですか?それはわからない。
    • 安心感はあるが、実情が伴わないことが起こる。
    • 学術的アプローチからアジャイルを説明したい人が出てきて、資格制度が出てきた。
    • → Dave Thomasが「Agile is Dead.」という表現をした。
    • ドワンゴも、アジャイルが上手く行ってるのは3割くらい。まあまあが6割。まずいのが1割くらい。
  • ゆっくり進路を変える。
    • 変えるのに時間がかかるなら、マネージャは先に率先して変えていかなければならない。
    • 変えるのが悪いのではない。なぜ変えるのか、説明しないのが悪い。合意を得ましょう。
  • Practiceは型。守ることによる安心感により、変えない人が多い。もっと自由にやってよい。
  • アジャイル開発を止めて、アジリティの高い開発を目指す。



【19-E-7】 IoTの未来はここにあった!大集合おうちハックLT祭


http://event.shoeisha.jp/devsumi/20160218/session/1059/

IoTの未来はここにあった!大集合おうちハックLT祭 from Tsubasa Yumura


頭のおかしい(?)発表が多数、とのことで、とても楽しいLT大会でした。
私もラズパイ弄ったりしてたので、こーゆうのやってみたいなぁと思いました。

各人のLTスライドは↓に公開されてます。
http://codezine.jp/article/detail/9255


感想


今年のデブサミもとても有意義で楽しい一時でした。
来年も是非、仕事に都合をつけて参加したいと思います。

関係者の皆様、ありがとーございました。

「Developers Summit 2016 - Hack the Real - 」に参加しました - Part2 -

2016/2/18 ~ 2/19 「Developers Summit 2016 - Hack the Real - 」に参加してきました。

公式
http://event.shoeisha.jp/devsumi/20160218/

デブサミ2016、講演関連資料まとめ
http://codezine.jp/article/detail/9255

先日、Part1として聴講メモを一部書きました。


Part2として引き続き、聴講したセッションのメモを自分の復習のため書いていきます。


【18-A-1】 Yahoo! JAPANが考える、テクノロジーとITエンジニアの未来


http://event.shoeisha.jp/devsumi/20160218/session/980/

Yahoo! JAPANが考えるテクノロジーとITエンジニアの未来 #devsumi from Yahoo!デベロッパーネットワーク

インフラの進化

  • VMは10kでオペレータが限界になった。
  • ⇒ OpenStackを導入して80k VMへ到達した。

プログラミング言語

  • プログラミング言語の選定基準は3つの観点で。
    • 1.メンテンナンス、学習コストの最小化
    • 2.オープンソースとの親和性
    • 3.過去のソフトウェア資産の活用

Webサーバ
  • Webサーバは安定性とパフォーマンスのために独自のパッチを当ててカスタマイズしている。
  • 先頭にyを付けて、Apache ⇒ yApache、Node.js ⇒ yNode.js と呼んでいる。

HTTP Cache
  • WebサーバからCSSとかを配信するとコストがかかるので、自前でCDNを持っている
  • AkamaiなどのCDNサービスは使わない。
  • 大量のリクエストがWebサーバに行くことを防ぐために、中間にエッジ層を挟んでいる。

ヤフーテクノロジースタック
  • ここが強い、というより、Yahooを作るのに全部をYahoo Japanでやっている。
  • それは、システムがダウンした時の責任を自分たちが負えるようにするため。

利用する技術を議論して決める
  • 重要なのは、利用する技術をトップダウンで決めないこと。議論して決める。
  • GitHub Enterpriseにyj-tech-standardというリポジトリを作り、意見がある人はプルリクエストで議論ネタを上げるようにしている。

ヤフーは4月で20歳になる
  • Web業界で20年生き残るのはあまり無い。
  • 20年前の1996年は、ヤフーのトップページはカテゴリしかなかった。
  • Filo CGIというサービスエンジンを使っていたが、Yahoo創業者の独自開発だった。
  • Filo Serverも自分で組み立てていた時代。

目の前にあるユーザの課題をとにかく解決し続けた。例: ログイン認証
  • 1998年当時は、ログイン認証はどうやったらいいかわからなかった。
  • 2007年はBBAuth (Browser-Based Authentication) というブラウザベースの認証APIを提供していた。
  • 2008年はCBA (Client-Based Authentication) で、アプリに保存したIDとパスワードを認証サーバに送る方式だった。今では考えられない。。。
  • ID乱立の問題が出始めた。未来を考えずに作ると大体こうなる、という悪い例。
  • どうせ標準仕様を作るのなら、流行らせないと辛い。
  • 認証と認可を同時にできる標準仕様としてOpenID Connectを作った。
  • いつのまにか、国内ソーシャルログインのシェアNo.1になっていた。
  • つまり、Yahooのログイン=日本のログインなんだ。ヤフーのログインを作るということは、日本のログインを作るということ。
  • これに気づいていなかった。気づいていたら、もっと違うアプローチが取れたかもしれない。

ログイン → ビッグデータ
  • ログインする → 質の高いデータがたくさん集まる → ビッグデータ
  • この繋がりにも気づけなかった。気付ければもっと違うアプローチが出来たかもしれない。

変わらないものはない
  • 今日のベストは明日のベストではない。
  • もっと重要なことは、課題が分かってから対応するのは遅いということ。
  • 未来はどうあるべきか、を考えて取り組むことが重要だと痛感した。

未来の課題の予測と解決に必要なもの
  • 技術力とマインド。
  • テクノロジー(技術力)は陳腐化するが、マインドは陳腐化せず、普遍的なもの。
  • マインド醸成のため、会社で大決起集会をやった。

世界Top10を目指す
  • なぜマインドが大事なのかというと、世界Top10を目指そうと思っているから。
  • なぜ世界Top10を目指すのかということ、技術には国境が無いから。
  • GoogleやAmazonと勝負して勝たないといけないので、必要条件になっている。

未来への準備
  • 1.広告課金技術の特許 ・・・ 特許は数年単位がかりで取り組んでいる。
  • 2.オープンイノベーション ・・・ 強い企業と最強タッグを組みましょう。
  • 3.Open Compute Project ・・・ IoTで機器からたくさんログが来るが、数年先、インフラが間に合うかが一番の課題。
  •  → ハードウェアにもOSSの考え方を。オープン仕様に基づいたハードウェアを海外拠点に入れている。
  • 4.ビッグデータ関連の研究開発 ・・・ YahooはWeb企業だけじゃなく研究開発企業なんだ
  • 5.オープンソースへの貢献 ・・・ OSSコミュニティにContributeの形で貢献していく。


【18-C-3】 JavaScript.trend(spec) /* 最新言語仕様を軸とした JavaScript の最先端解説 */


http://event.shoeisha.jp/devsumi/20160218/session/998/

Java script.trend(spec) from dynamis .


JavaScript、ECMAScriptの誕生
  • Selfを取り込んでJavaScriptはプロトタイプ指向になった。
  • 設計がマズかったね、と後悔する部分もあった。
  • 最初はMozillaが1人でJavaScriptを頑張っていた。

ECMAScriptの成長
  • JavaScriptが足りない部分を補うためCofeeScriptやTypeScriptが登場してきて、それらのノウハウがJavaScriptに還元されていった。
  • JavaScriptの言語仕様を作り始めて3年くらい経って最低限のものが揃ったので、次は、それを立派な言語にしていこう、となった。
  • そのあと、折り合うところだけやりましょう、ということで標準化へ向かった。
  • ECMAScript2015(6th)で抜本的な修正が入った。Class、Module、・・・
  • 今後は6th、7th・・・ではなく、インクリメンタルに少しづつ年次改定していく。
  • ECMAScriptの仕様を知らないと、良さの半分も活かせてないことになる。
  • ECMAScript 2016で新機能が2つ入る。Array.prototype.includesとexponentiation operator
  • ECMAScript 2017はSIMD.jsとAsync Functionsの2つが注目。前者はマルチメディア演算。後者は非同期処理を綺麗に書けるC#から持ってきた機能。

Babelトランスパイラの利用
  • トランスパイラとは、最新の言語仕様で書いたコードを、IEでも動作するように変換してくれるツールのこと。使うことでバグが入りにくくなる。
  • トランスパイラによる変換は当たり前になってる。
  • HTTP Connectionを如何に減らすかが課題で、HTTP2になったらCSSを1つに纏めるより、個別に分けたほうがキャッシュが効いて良い。
  • → JavaScriptもそうなっていくのでは。いつでもモジュールに分けて設計し、タスクランナーで変換して合体するとか。
  • → タスクランナーを使いましょう。

ES6
  • これからはES6で書きましょう。
  • Template Literals(テンプレートリテラル)を使うことでコードが書きやすくなる。
  • Destructuring(分割代入)を使うと、代入の左辺も階層構造が取れる。JSONの階層構造の代入も一撃で行ける。
  • 今まではブロックスコープを作る機能が無かったので、何もしない即時関数を作って、そのスコープを利用していた。
  • → ES6でBlockscope(ブロックスコープ)の機能が追加された。
  • Readable Asyncで非同期処理がすごく書きやすくなった。



【18-E-5】 リアクティブ・アーキテクチャ~大規模サービスにおける必要性と課題


http://event.shoeisha.jp/devsumi/20160218/session/1017/

リアクティブ・アーキテクチャ ~大規模サービスにおける必要性と課題〜 #devsumi from Yuta Okamoto


なぜ分散システムか?
  • 例えば組織200人で開発、とかは無理なので、分ける。開発組織をスケールする。

マイクロサービスアーキテクチャ
  • マイクロサービスアーキテクチャは昔からあった。
  • 2011年に書かれたAmazonに対する記事がとても良いので、読むと良い。 http://anond.hatelabo.jp/20111018190933

コンウェイの法則

  • システムのアーキテクチャは、その組織のコミュニケーション構造のコピーとなる、という経験的法則。

マイクロサービスの方法論
  • サービス間はRESTや単純なMQで繋ぐ。SOAのESBのような重厚なものでは繋がない。
  • サービス同士の依存関係を減らし、独立化してコミュニケーションを減らす。

リアクティブ宣言


様々なリアクティブ
  • 世間のリアクティブは、Reactive Programmingを指すことが多い。これはReactive Architectureとは違う。

リアクティブシステムの性質
  • 4つの特製がある。即応性、弾力性、レジリエンス、メッセージ駆動。
  • ユーザへ素早く一貫性を持たせてサービスを届ける。その形態が「弾力性」と「レジリエンス」の2つ。
  • 三層アーキテクチャのシステムのやり方とは似ても似つかない。
  • ビジネスロジックが小分けになって、非同期で結びつく。

リアクティブなコンポーネント

  • 他のコンポーネントから非同期メッセージが到着したときだけ反応する。
  • この、「だけ」という点が重要。リアクティブ=受け身。
  • コンポーネントは、いつ動くかというのをシステム任せにできる。

レジリエンス
  • リアクティブ宣言では、レジリエンスを「対障害性」と訳しているが、ちょっと違う。
  • 障害で倒れてもいいけど、すぐ回復する、という特性がある。

Onion Layered State Management
  • 上の2つのコア(Error Kernel)は壊れちゃいけないけど、それより下のオブジェクトは壊れても上の2つがなんとかしてくれる。 

マイクロサービスとの比較
  • マイクロサービスは同期呼出がデフォルトで非同期呼出も許されるが、リアクティブは非同期呼出のみ。

データフローの決壊
  • Publisherが非同期でメッセージを大量に送りまくっても、受け取る側(Subscriver)の処理が追いついているなら問題ない。
  • 受け取る側(Subscriber)の処理能力がしょぼいと、メッセージバッファが溢れる。

Back-Pressure
  • 受け取る側(Subscriber)が、送る側(Publisher)に、いくつ送ってください、と言う。
  • 送る側は、リクエストされた分だけメッセージを送るので安全。

Reactive Streams in JDK 9
  • JDKにReactive Streamが入る。抽象的な概念がもうつ使えるところまで来ている。

分散オブジェクト設計の法則
  • 第一法則: オブジェクトを分散させるな by Martin Fawler 「分散って大変なんだぞ」

分散プログラミングのつらみ
  • 1.プログラミングが大変
  • 2.整合性の確保が大変

ログ指向アーキテクチャ
  • メッセージの順番は、ログを書いたところで確定する。



ひとまず自分の復習のため、スライドや当日メモを見ながら書きました。
残りのセッションはPart3以降に続きます。。。

「Developers Summit 2016 - Hack the Real - 」に参加しました - Part1 -

2016/2/18 ~ 2/19 「Developers Summit 2016 - Hack the Real - 」に参加してきました。

公式
http://event.shoeisha.jp/devsumi/20160218/

デブサミ2016、講演関連資料まとめ
http://codezine.jp/article/detail/9255

ここ数年、毎年参加してますが、今年も2日間、仕事に都合をつけて参加してきました。

場所は目黒雅叙園です。
参加者数は公式の概要ページを見る限り2000~2500名らしい。凄いですね・・・
ちなみにセッション間の部屋移動はこんな混雑具合。
20160218_devsumi1.jpg

今年の書籍ブースはこんな感じ。この左右にも書籍が広がっています。ワクワクしますね~
20160218_devsumi2.jpg

というわけで復習を兼ねて、自分が聴講したセッションのメモを書いていこうと思います。


【19-E-5】 生きる


http://event.shoeisha.jp/devsumi/20160218/session/1057/

2日間のデブサミで個人的ベストを挙げろ、と言われたら、このセッションを挙げるでしょう。


この圧倒的なタイトル・・・!惹きつけられずに入られない・・・
ちなみに私、講演者や講演内容の前提知識ゼロだったんですが、聴講中は驚きの連続でした。

【ご参考】CodeIQ
東大法学部卒・31歳無職はなぜ第一線プログラマになれたのか──freee平栗遵宜の「仕事の流儀」

【聴講レポート】人生はSelfQuest
生きる (freee 平栗氏 デブサミ講演レポート) #devsumi



平栗さんのこれまでの生き様は↑のCodeIQの記事が参考になると思います。
そんな彼も、最近は「なんでこんな仕事やってるんだろう」、「なんのために働いているのか」を自問自答することが多くなったとのこと。
その時は、以下に立ち返るようにしているそうです。
  • モチベーションの源泉を探す
  • 心のレバーを探す
  • 幼少の原体験を探す

これはいつも変わらない。
昔、何が好きだったか、を考えると、自分の進む道が見えてくるとのこと。

とても共感できる話でした。たぶんスライド公開されても、あの日あのセッションに参加した人にしか良さは分からないでしょう。
たぶん今年のデブサミのベストスピーカー賞を取るのではないでしょか。


【18-A-2】現場から変えた”サービスの作り方”
 ~何を作るのかではなくなぜ作るのか~


http://event.shoeisha.jp/devsumi/20160218/session/981/

現場から変えた“サービスの作り方” -何を作るのかではなくなぜ作るのか- #devsumi from Yahoo!デベロッパーネットワーク

  • 開発サイクルが安定すると余裕ができ、チームに目がいくようになる。改善の視野が広がる。
  • スプリントプランニングでストーリーだけでなく、4つのことをチームに伝える。
    • 1.ターゲットユーザ
    • 2.ユーザの抱える課題
    • 3.課題を解決することによるユーザが得る価値
    • 4.価値の定義
  • Scrum実践のサポートで、「目指すチームの決定」をまず行う。これを話し合わないと、チームの改善がどこに向かうのかわからなくなる。
  • サポート時にメンバー同士の意識合わせを行うのは、互いに過度な期待や負荷がかからないようにするため。
  • サポート時には、ストレス軽減を最重要視している。開発プロセスが従来から変わると、ストレスが溜まりやすくなるので。
  • 改善の取り組みでTIPSなどのコンテンツ配信を行おうとしている。勉強会とかに来ない人たちにも気づきを与えたい。見てもらえる工夫として、「マンガで配信」とかを考えている。4コマでパラパラと手軽に見てもらえるよう工夫したい。
    それで気付きとか発見を与えたい。マインドが低いチームにも届くようにしたい。



【18-C-L】 大規模 SPA ( Single Page Application ) を TypeScript と AngularJS を駆使して5ヶ月で作った話


http://event.shoeisha.jp/devsumi/20160218/session/998/

How to develop a huge Single Page Application from Naoki Yamada

  • CoffeeScript、BABEL、TypeScriptから1つを選択する際、
    • CoffeeScriptとBABELは動的型付けなので、動かすまでエラーがわからない点を考慮して避けた。
    • TypeScriptは静的型付けなので採用した。
  • AngularJSかReactかの選択では、ルーティング機能の充実を重要視してAngularJSにした。
  • GulpかGruntかの選択では、Gulpを採用した。Gruntよりプログラマブルなので。
  • プルリクエストは最優先に対応するようにした。
  • 先輩後輩は関係なく、分からなければ即座に教えを請うようにした。
  • クロスファンクショナルに作業を行い、1週間で50~60のチケットを消化していった。

TypeScriptの採用
  • 型を明示的に定義するようにした。コード量は増えるが、そうなるなら使用しているエディタを変えろ。
  • 実際、SublimeTextからInteliJ Ideaに変えて、コード量は増えたがタイプ数が減った。
  • AtomとかVisualStuido Codeとかも強力。
  • TypeScriptはJavaScript特有の仕様を綺麗に隠蔽してくれる。


AngularJSの採用
  • Vue.jsはAngularJSの開発者と同じ人が作っており、AngularJSより学習コストが低い。
  • Vue.jsから入って、後でAngularJSをやると、スッと入ってくる。


リファクタリング
  • コード全体を見ることになるので、全体を俯瞰するチャンス。
  • 勇気を持ってやると、それに見合う見返りがある。
  • プルリクエストは溜め込まず優先的に捌くようにしたのは、相手を待たせずに済むから。
  • プルリクを早く捌いて互いのコードを見るサイクルを早くすることで、互いのコードが似てくる。それによってレビューコストが減らせる。
  • プルリクのサイクルをたくさん回す。


残りのセッションについても復習を兼ねてメモ書いていこうと思います。

-->