#devsumi 2016 に行ってきました
今年もデブサミに行ってきました
ここ数年は毎年行っているのですが、やっぱりデブサミは良いですね。
なんというかモチベーションが上がります。参加者には開発者からデザイナーから経営者から色々な方がいるんだと思います。それぞれが色々なものを良くしようと思ったり、仲間を募ったり、はたまた単に趣味の話をしにきたりして一つの場所に集まっているのだなと思うとなんとなく気分がアガります:)
Day 1
いきなり素敵なお話でした:)
要件定義とか仕様書出したりとかしてる段階ではお客さんはおとなしくて、動くものが出てきてから色々な話が出始めるというあるある話。
動くものを見ないとわからないことが多いのは当たり前の話で、お客さんから(悪い意味ではなく)クレームが出てくるのは当たり前だと。それを意識しておかないと、お互いに嫌な気持ちになってしまうわけですね。
クレームが出てから直されるまでの間が開くと「諦め」が発生する。これは改善の機会を逸することになるので、短い間隔で継続的にリリースできることが大事。コツコツ継続的にやっていこう。
失敗を0にすることは出来ない。リスクを0にしようとするのは不可能をなそうとしている、リスクをマネジメントしなければいけない。
大事なことは「価値がある」「使える」「作れる」こと。それぞれを判断できる人は別であることが多いので、一緒に考えなければいけない。みんなで集まって解決していこう。
なるべく小さなアウトプットで、なるべく大きなインパクトを出そう！
友情→努力→勝利！！！
2つ目は1つ目と内容がもろかぶりだったので、本を立ち読みしてから休憩と充電を兼ねてカフェに行ってきました^^;
バナナ美味しかったです:)
打って変わって言語のお話。
JavaScriptも大分こなれてきたという話(だと勝手に理解)。2015年にガツンとバージョンアップされて、しばらくは緩やかな変更にとどまるらしい。他の言語からもいろいろ取り入れているとのこと(C#からAsync Awaitとか)。
JavaScriptにありがちな「でもその機能はこのブラウザで実装されてないよね」問題。トランスパイラ(BABEL)で解決する。最新の言語仕様で書いて、実際にデプロイするときは環境にあった形に変換する。LESSだのSASSだのminifyだのと同じタイミングでやる。
2015でめんどくさかったこととか色々良くなるらしい。文字列内で変数展開できる(バッククォート括り)とか、デフォルト引数とか、可変長引数とか、オブジェクトの特定のプロパティのみ抜き出して変数に代入とか、classとか、ブロックスコープの導入( (function() {...})() ←これを書かなくていい)とか、定数とか、矢印関数(thisが差し替わらない)とか、非同期処理にasync awaitが使えるようになるとか、Setとか、とにかくいい感じとのこと。
パフォーマンスも順調に最適化が進んでいるとのこと。生JSを書くのが苦痛でなくなっているのか、仕事で使ってみたい。
こちらはアーキテクチャの話。トレンド(？)になっている「リアクティブ」とか「マイクロ・サービス」とかですね。プロジェクトの進め方系の話と並んで興味のある分野です。
個人的にはカタカナが多めでそこが結構厳しかったのですが、無理して翻訳しないというのは大事ですよね、うん。
スライドがしっかりバッチリしていて内容については読めばわかるのですが、まとめるとこんな感じだと捉えました。
- 分散分散言うけどちゃんと考えて気をつけてやれよ
- ネットワークとかそんなに信用できないからエラーのケアしろよ
- サーバとか増えて運用辛くなるからしっかり自動化とかしとけよ
- 自分たちで頑張るんじゃなくて先人に頼れよ
1日目最後はこちら。毎年これを選んでます:)
インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門
- 作者: みやたひろし
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2013/12/27
- メディア: 大型本
- この商品を含むブログ (8件) を見る
↑ おすすめポイントはインフラに関して散らばっていた知識が繋がることだそうです:)
個人的には結構興味深い内容だったのですが、いかんせんクラウドイケイケの世相から不利でしたね:(
↑ 業界外の人にITについて興味を持ってもらうのが意図だ的なことだったと思います(うろ覚え^^;)。
個人的にはとても喜ばしいという印象で、技術書部門はこの本に投票しました:)
会社に買ってもらう候補です。
プログラマ脳を鍛える数学パズル シンプルで高速なコードが書けるようになる70問
- 作者: 増井敏克
- 出版社/メーカー: 翔泳社
- 発売日: 2015/10/14
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
↑ 技術書部門大賞ですね:)
個人で購入したのですが、「サイン本ラス1です^^」と言われてTwitterに投げたら同じことを呟いている方がいて、どっちが真のラス1なのだろうか…
↑ ベン・ホロウィッツさんが実際に直面した困難と教訓をまとめた本とのことです:)
人→製品→利益 の順番で大切にしろとのこと。読んでいると胸が痛くなるとのこと^^;
ビジネス書部門はこの本に投票しました:)
会社に買ってもらう候補です。
↑ 去年も似た本が出てましたが、所謂Googleの働き方というやつですね。
帯には「グーグル」と入っていますが、別にGoogle独自じゃなくてGoogleだって他から取り入れたりしている、「あのGoogleが！」的な先入観を抱いてほしくないと言っていた気がする。
人工知能は人間を超えるか ディープラーニングの先にあるもの (角川EPUB選書)
- 作者: 松尾豊
- 出版社/メーカー: KADOKAWA/中経出版
- 発売日: 2015/03/11
- メディア: 単行本
- この商品を含むブログ (10件) を見る
↑ ビジネス書部門大賞ですね:)
ディープラーニングの入り口的な立ち位置だとか？個人的に購入したいと思ってます:)
電子書籍版が紙媒体の売上を上回っている稀有な本とのこと。
Day 2
(資料が見つからなかった…;)
大体の問題はプログラミングではなくマネジメントの問題。これはまさしくそのとおりだなと思います。
大規模開発をマネジメントし切る実力を持っているマネージャなんてそんじょそこらにはいないのではないか。しかし壁を超えた先には魅力的な世界が広がっている。
アジャイルに期待しすぎるのはダメ。ウォーターフォールはダメだからアジャイルでやりましょうよ的な言葉は鵜呑みにしてはいけない。
問題は方法論ではないのではないか、その場合はウォーターフォールだアジャイルだ言ってても解決できない。アジャイルが言っているのは当たり前のこと。乱暴に考えるとウォーターフォールでも細かくやればアジャイルではないか的な(私個人の捉え方です、マサカリが飛んできそう;)。
アジャイル=無計画 ではない(当たり前ですな)。
ツールに振り回されてはダメ。ツールありきで仕事の進め方を決めているのでは本末転倒、やり方が先にあってそのためにツールが有る。
常に反省すること。結局は最初から最後まで「覚悟」と「人」の話である。
会場を間違えました…(そしてそれに気づいたのは結構経ってから…^^;)
まとめとしてはこういうパラダイムシフトの導入にあたって費用対効果を出すのは無理なので、熱意で頑張れとのこと。もう流行りとかじゃないんだよ、普及してるんだよ、使えるのがメリットなんじゃなくて使えないことがデメリットなんだよ。
はじめはAWSの宣伝かな？と思いましたが、思ったより得るものが多かったです。わりとこれからやろうとしているところにハマりそうな内容でした:)
マイクロ・サービスはクラウドとの相性が良い。小さな部品を組み合わせる的なね。
モノリシックなシステムから開放されよう(「モノシリック」だと思ってた…^^;)。
ここでも分散システムの難しさについて釘を刺される。
API GatewayとLambdaの組み合わせでEC2を使わずに構築するのがイケてる気がする。API GatewayもLambdaも面倒なことを色々やってくれて大変よろしい。ビジネスの本質と関係ないコードの量を減らせる。大抵の場合はEC2よりコストが減る。もちろん必要であればEC2を使ったって構わない。
(資料が見つからなかった…)
途中からで立ち見だったのでろくにメモも取っていないです…^^;
しかし良い話でした:)
マネージャになって辛いことがあったが、自分のモチベーションを考えなおしてみると意外に合っている仕事だと思い直したとか:)
最後は気になっていたブロックチェーンについて。ブロックチェーンの有用性についての話かとおもいきやDisの立場からのお話でした^^;
やっぱり難しくて曖昧な解釈しか出来てません…><
ブロックチェーンは「新聞」の代わり。群衆が「(出来事の証拠としての)新聞」を発行していくようなイメージ(？)。
ブロック(塊)・チェーン(連鎖)
ブロックは取引(TX)の集まり。取引(TX)は状態の変化の記述(例: 送金)。状態の変化の塊の連鎖。
3つの層があり、コンセンサスのプロトコル、ダイジェスト(ハッシュ値)を格納するブロックの連鎖、デジタル署名によるデータ構造となる。
コンセンサスのプロトコルとしては現実と同期して動く上では問題がある。ダイジェストを格納するブロックの連鎖の構造は想定されていたほど強固ではない。デジタル署名によるデータ構造は有益である。
整合性の担保を確率に頼っている部分があるので、コンセンサスの成立とするには弱い(という私の理解)。
Proof of Work。作業コストを膨大に、検証を容易にすることでスパムや不正行為を抑止する。例えば「先頭20ビットが0になるダイジェストを生成できる乱数」を作る、作成には時間が掛かるがその乱数が条件を満たすかどうかの検証は一瞬で可能である。
取引の改ざんはデジタル署名によって不可能であるが、取引の削除は可能性がある。POWによって改ざん者vs世界という図式を作り、事実上不可能にするという理屈だが…あくまでも事実上であって、改ざん者がタイミングを見計らってコストをつぎ込めばBitcoinが破綻する可能性は存在した(する)といえる。
世界各地の主要金融機関がブロックチェーンの研究・実験をしているらしい。
小さいブロックチェーンは小さいコストで破綻させることが可能である。そもそも小さいなら従来の手法でコンセンサスをとればいい。
分散システムは一貫性・可用性・分断耐性の全ては満たせない。ブロックチェーンは一貫性を確保できていない。例として「ビットコインを支払うと上空のドローンがドリンクを落としてくれるサービス」を考える。ドリンクはいつ落とせばいい？ビットコインの取引は確定するタイミングを予測できない。同時に2つのブロックが成立することがあり、そのうちどちらのブロックが有効であるかは時間が経たないと確定しない仕組みである。そのため現実に当てはめるにはリスク(取引が後で無効になる可能性)をとらなければならない。
ブロックチェーンは不確実性というリスクをとれるのであれば有用であり、可能性がある。しかしそうでないシステムには向いていない。
だがしかし、ブロックチェーンが示した世界には魅力がある。
まとめ
やっぱりデブサミはその場にいるだけでも得るものがあるのではないかと思います:)
社長とか忙しいので行けないとの事だったが、ぜひとも優先順位を上げていただきたい。
モチベーションを頂いたので、得たものを活かして楽しくやっていきたいです:)
他に気になったお話
失敗から学ぶデータ分析グループのチームマネジメント変遷 （デブサミ2016） #devsumi
【資料公開】強いチームの作り方(デブサミ2016版) | Ryuzee.com
外注が主な企業でどのように内製開発を立ち上げ・進化させているのか？
