2013年2月15日金曜日

Developer's Summit 2013 参加メモ(11)

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

開発者の資産形成に繋がるActionとは? / 東 賢@ インフラジスティックスジャパン

  • 2nd FactoryのDocZoom for Cloud
  • 25分なんでガンガン飛ばします
  • シニアUXエンジニア
  • NETADVANTAGE
  • IGUANA / IGNITEUI / NUCLIOS
  • データグリッドを商用利用OKな形で無償提供してます
  • プロトタイプツールIndigoStudioも無償提供してます

さて

  • デブサミ、これまでは「共感」
  • 今回は「Action」
  • 「デベロッパーの皆さんの活動が世界を良くします」

ところで「開発」って何でしたっけ?

  • 元は仏教用語
    • ブッセイを開き発する
  • ニーズや目標をソフトウェアに形で満たす
  • 社会をよりよく変えていく。

Actionの先には?

  • ゴールを考える。

  • Actionで社会を良くするには、あるレベル以上の「余裕」が必要になる

  • そのために何らかの形で「ビジネス」に関わる必要が出てくる

  • 望む・望まないに関わらず、私達は資本主義社会に生きていて、その経済活動の一部として暮らしている
    • それがいやならコルホーズ
    • なので、
  • 生きるための手段?趣味?Professional?
    • ならば商品だ
  • 僕たちはいつまでこんな働き方を続けるのか?40年間ラットレース

  • 商品価値
    • 使用価値
    • 交換(労働)価値
    • まず労働価値で決まり、そのご使用価値で商品価値が増減する
  • ガートナーのハイプサイクル
    • 浮き沈みが激しい
  • Matz
    • お客様に対して新しいサービスを提供
    • 技術からおもしろいもの
    • 基礎的なアルゴリズム
  • PLとかBSとか見てますか?

  • PL思考
    • 仕事の満足感 - 仕事の再生産のためのコスト=自己内利益
    • 再生産のためのコストが変わらなければ、仕事の満足感が低下し「損」が出る
  • BS思考
    • 負債にならず資産化するようなスキルを蓄積する
    • 仕事の再生産のコストを抑えられる

資産化できる「ポータブルスキル」を身につけよう!

  • 登壇者の経験
    • サーバサイドWebテクノロジー ColdFusion / adobe
    • フロントサイドは Flash/Flex、WPS/Silverlight、、
    • そこから“UI / UX”
    • UI, UX for the rest of us / Global work / Business Management
  • Action、細かいこともあるけど、中期的に自分のことを見たりすると、、

オススメのポータブルスキル

  • コミュニケーション能力:英語含む
    • 日本語はつたないけど迫力がすごい海外の方
    • コミュニケーションは態度で決まる
    • エージェント「英語が出来る」だけで、この年収の差は何だ!?
  • 環境適応能力
    • 「私達の身の回りの環境は変わる」という前庭
    • 鈍感力
    • 周りが変わっても、自分はブレずにやることをやる
  • デザイン思考
    • Visual Designではなく、何かをする前の検討
    • 自らをデザインする
  • マクガイバリズム
    • 冒険野郎マクガイバー
    • 武器がなくても立ち向かう
    • 「とにかくやってしまおう」というマインド

デザインのススメ

  • もともとSWは目に見えないもの
  • ユーザのニーズを満たすためにはUIで目に見える形にしてあげる必要がある
  • 商品を売るにあたって、デザインスキルは必須のものになる
  • デザインスキルは使用価値も労働価値も高める
  • デザインは積極的に人間を対象にしているので、ぶれない
  • デザインを実装するテクニカルな部分は習得しやすい
  • 習得するテクニカルスキル→蓄積され、レバレッジになる部分を増やす

今の時代とこれからの進み方

  • DeviceAge

  • DEV-ICE-AGE

  • 恐竜は生き残れない。俊敏に変化に適応出来る必要がある。

  • 自分自身が変われても、周囲が変わらなければ

  • 世界を変えるのか、部品になるのか

  • 自分たちが考えたサービスで勝負するために必要なSWを自分たちの責任で設計し、成功を収める実感を持てる場所で働こう

  • マトリックスの目覚めたシーン参照。
    • 目覚めて下さい。周りを見回してみて下さい。

まとめ

  • これからどこに向かうのか
  • 何を貯金してきたか、これからは、その貯金で何をしたいのか
  • デザインをうまく利用して、人生を実りある豊かなものにし、世界を変えて下さい!
  • リスクをチャンスに変換していこう

Developer's Summit 2013 参加メモ(10)

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

人が作るソフトウェア〜今「組織パターン」を読む意味〜 / 和智右桂@GxE・JavaEE勉強会

導入

自己紹介

  • @digitalsoul0124
  • グロースエクスパートナーズ株式会社勤務
  • JavaEE勉強会
    • 読書会
      • 黒猫本、EIP、DDD
  • ネコ好き
  • ITアーキテクト
  • 書籍翻訳
    • 継続的デリバリー、ドメイン駆動設計、実践TDD、組織パターン
    • 組織パターンは出版社向けに提案した初めての本

組織パターンとは?

  • 原書
    • 2004年刊行
    • 実質は90年代の本(10年にわたる組織研究)
    • scrumをはじめ様々なagile placticeのベースとなっている
  • なぜ今?
    • パターン言語 (PatternLanguage) ← 知ってる人は会場の1%くらいだった
    • ロール指向のチームモデル

たとえば、scrumって、、

  • よし、次のPJはscrumでやろう!
  • あなたの組織は (上司の頭さえ固くなければ) “scrum”を始められますか?
    • Three Roles
      • プロダクトオーナー、スクラムマスター、チーム
    • Four ceremonies
      • スプリントレビュー、スプリントレトロスペクティブ、、
    • Three Artifact
      • スプリントバックログ、、
    • こういったのをマルッと全部始めるのは難しい
    • ビッグバンというのがscrumの弱点
  • 価値を届けながら、一歩ずつ進めていかなければならない
  • どうすればいいだろうか?

パターン言語

  • パターンとは?
    • 繰り返し現れる
    • あるコンテキストにおける問題を解決する
      • scrum流行ってきた、よしやろう!→ビッグバン導入しなきゃ、とか *全体性に寄与する
    • 美的あるいは文化的な価値を反映する
  • パターン言語とは
    • パターンを一定の順序で組み合わせる規則

組織パターンの例

  • プロジェクトマネジメント
    • ワークキュー
  • 組織の漸進的成長
    • 防火壁
  • などなど、、
  • パターンに導かれて一歩ずつ進んでいこう

WFとAgileの違いは?

  • WFで批判すべきは「仕事を壁の向こうへ投げつけるスタイル」
  • プロセスはコミュニケーションと生産活動の構造から生まれる
  • ロール構造
  • 組織パターンの適用
  • コンウェイの法則
    • 汎用モジュールに職人
    • 個別モジュールは勉強中のエンジニア
  • 人のつながりがソフトウェアを作る

さいごに

  • 学びを、実践を「共有」しよう
  • 知の場=コミュニティを豊かにするために

Developer's Summit 2013 参加メモ(9)

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

Webが生み出し始めた世界 / 江渡浩一郎氏@産総研

導入

  • 情報メディア史の観点から話をします

自己紹介

  • メディアアーティストから産総研へ

作品紹介

  • ウェブ・ホッパー / 1997
    • ブラウジングの軌跡を可視化
    • アルスエレクトロニカ賞グランプリ
  • インターネット物理モデル / 2001
    • 日本科学未来館
    • 白黒のボールでパケットを表現
    • 5人チームで制作。Rubyを利用
  • Modulode / 2005
    • マッチ棒連結みたいなので「動く3Dモデル」を作り、投稿できるWebアプリ
    • 2005年公開
    • 「創作性の連鎖」の研究
      • モデル再利用ネットワーク
  • qwikWeb
    • メーリングリストとWikiを統合したコラボレーションシステム
    • ruby周りを中心としたコミュニティで利用されている
  • Wedata
    • データ集約を目的としたサービス
    • AutoPagerizeで利用されている
    • autopatchworkはクライアントの一つ

実践知の実践

  • これらの作品は「集合知の実践」のアプローチ
  • 本を書いた(XP〜〜)

利用者参加型設計プロセスの歴史的発展

  • アレグザンダーのパターンランゲージ
    • 建築業界には普及せず、忘れ去られてしまった
  • ケントベック・ウォードカニンガム
    • デザインパターン / GoF
      • プログラムの記述のみ。プロセスには言及せず
    • XP
      • ソフトウェア開発パターンランゲージ
  • Wiki
    • HyperCard パターンブラウザ / 1987
    • WikiWikiWeb / 1995
    • Wikipeedia / 2001

ニコニコ学会β

  • 野生の研究者が研究を行う、研究団体・シンポジウム *プロの研究者と野生の研究者をつなぐ
  • オンラインとオフラインの融合
    • 研究100連発
      • 5人が25個の研究発表を15分で行う
    • 研究マッドネス
      • つくってみた系の発表
  • ニコニコ動画の文化が基底にある
  • 日本技芸、ヤマハ、ドワンゴ、クリプトン、産総研、、
  • 調べた結果を発表し、議論するのが学会。
    • 研究しよう、発表しよう。
    • ニコニコ学会では他薦も受け付けている
  • グッドデザイン賞受賞
  • 「イグノーベル賞の狙い方」レクチャー
  • 冨田勲と初音ミク
  • 情報処理学会全国大会

宣伝

  • LIFE by MEDIA 国際コンペティション
    • 情報メディアを使って生き方・暮らしの空間を変える
    • アイデア募集は3月

Webが生み出し始めた世界

  • 情報メディアとは、という観点で話します
  • 新聞、ラジオ、テレビ、インターネット(Web)、そしてその次は?
    • Webが1位になるのは分かっている。そのを考えたい
    • 15年〜17年くらいに新しいメディアが出来るのでは?
    • それこそが「Webが生み出したもの」なのでは?

情報メディア史

  • 芸術史
    • 呪術と一体化していた洞窟壁画
    • 教会建築と一体化していた絵画、ステンドグラス、、
      • 字の読めない人に教義を伝える
    • 商業芸術が始まったのは近代
      • 「モダニズムの絵画」クレメント・グリーンバーグ
      • 「メディア・スペシフィック」ジャクソン・ポロック
  • メディア史
    • 20世紀、マスメディアの登場
      • medium
      • mass
      • 「メディアはメッセージである」マーシャル・マクルーハン
      • 「グーテンベルグの銀河系」「Global Vilege」マーシャル・マクルーハン
      • 「グッドモーニング・ミスターオーウェル」パイク
      • 「Hole-In-Space」ギャロウェイ
      • 「Electronic Cafe」
  • 思考の道具としてのコンピュータ
    • DynaBook アラン・ケイ / 1972
      • マクルーハンの影響を受けている
      • A Personal Computer for Children of All Ages
    • 「コンピュータリテラシー」
    • 未来を予測する最良の方法は、自ら創り出すこと
  • 1994から、ネットワークアート
    • 「訪問者リスト」「PeepHole」「DotPaint」「RemotePiano」
    • Webを「表現行為のための場」とするためのネットワークアート

Webの未来について語る

  • 未来は必ずしも魅力的ではない
    • 例:Twitter
      • 140文字しか書けない制限
  • Webがメディアの頂点に立ち、ユニミディウム化
  • HTTP/2.0 (SOAP, REST, HTTPng, AJAX, SPDY)
  • 歴史は反復する
  • アランケイからマクルーハンへ回帰する
    • アランケイは本の虫
      • 本を読むことで世界を変える
    • マクルーハンはテレビ・ラジオ
      • 音声の世界
  • VR、ARの世界へ

まとめ

  • ニコニコ学会で研究発表やりましょう!

Developer's Summit 2013 参加メモ(8)

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

最初に

コンテンツ委員 吉田パクえ氏から

  • もし貴方が何かを成し遂げたいなら、それはとても少しの勇気を持てたか持てなかったか。きっと、そのくらいの差でしかないと思います。

DevPower:デベロッパーが創る日本の未来を語ろう フューチャーセッション

登壇ゲスト

  • フューチャーセッション
  • 林浩一氏 @ ピースミール・テクノロジー
  • 市谷聡啓氏 @ 永和システムマネジメント
  • 山崎富美氏 @ Google

導入

  • DevPoewr:DevLOVEへのアンチテーゼ
    • 「あっ、そうなんですか」 / 市谷さん

自己紹介

  • セクター横断のイノベーションプラットフォームを提供します
    • 企業テーマ
    • 地域テーマ
    • 社会テーマ
  • これらをつなぐ対話の場。合意形成から創意形成へ
  • 多様なステークホルダー、未来のステークホルダーを招き、創造的な対話
    • 共通点ではなく、違いを見つけ、そこから気づきを得、アクションにつなげる。
      • (3/6にやるDevLOVEでやりたいこととイメージ近い!)

本日の「大切な問い」

  • Round1
    • デベロッパーにとって「必ず来る未来」
  • Round2
    • プロフェッショナルのデベロッパーとは
    • デベロッパーの「Love&Power」の高め方
  • 対話からコンセンサスを生み、Actionにつなげよう

“Power and Love” ?

  • アダムカヘン氏
  • Love
    • 分断していたものを統合し、つなげる力
  • Power
    • 他と分断し、自己を実現する力
  • 欠けちゃダメ
  • 高いレベルでの統合が、未来につながる

林さんより

  • 技術コンサルタント、エバンジェリスト
    • 「エヴァンゲリオンですか?」
  • ITコンサル、PM、ディレクター、ロジカルシンキング @ ウルシステムズ
  • PMTECH創立、利用者主導開発、プロジェクト管理支援
  • 昔も今も「イノベーター」でありたいと思い続けている

必ず来る未来

  • 企業システムを巨大会社に丸投げする時代は終わる
  • じゃあこれからの企業システムは誰が担う?
  • 担うのは進化したDeveloper
    • 深さ*幅*奥行き
    • OSSの奥の底まで潜れる技術力
    • 開発工程全体を見渡せる視野
    • ビジネスに繋がるステークホルダーとの調整力

市谷さんより

  • 開発現場のためのコミュニティ「DevLOVE」設立者
  • アジャイル開発のPM、よろずご相談受け @ 永和システム

必ず来る未来

  • 軸足を置く場所が「会社」から「自分」へ変わってきた
    • 会社よりコミュニティの方が長い
  • 面倒なことを処理してくれる「会社」と、自己実現のための「コミュニティ」
  • プロフェッショナルは「実現力」
    • (自分含め)誰かのために何かを成し遂げる力
    • それを重ね合わせ、チームで力を発揮していく
  • コミュニティは「可能性の厳選」
    • 存在し得なかった現実を創り出せる可能性
    • 共感→練習→計画設計→実践する

山崎さんより

  • Google Developers Group
    • Googleテクノロジーを使うデベロッパーのグループ
    • GDG Women
    • 日本のデベロッパーは会社主導よりコミュニティ主導のカンファレンス・学びの場が多い
  • Hack for Japan
    • 開発者からの「自分たちのスキルを役立てたい!」
    • OpenDataやhacker精神を広めるためのideasonやhackasonを実施
  • 東北Tech道場
    • ITやれる人を増やす取り組み
      • ビジネスが出来る可能性、夢と希望を与える
    • 道場、オフィスアワー、hangout
    • 少人数、初心者OK、学んだら教える

必ず来る未来

  • 市場・戦場がグローバルになる

  • 仲間も考え方もグローバルになる

  • 日本のデベロッパーコミュニティも変わっていっている
    • 世界一になる、世界一のモノを創る、English onlyなhackason
  • プロフェッショナルは好奇心
    • 14歳でW3CのML
    • 学ぶ→教える→伝える・シェア
  • “Open” がキーワード
    • Open to the world
    • 自分のDomainに閉じこもらない
    • Open to opportunities

さて、考えよう(参加者同士の対話)

「必ず来る未来」は?

  • 技術を突き進むか、マネジメントに進むかの分かれ道
  • 最近困ってることを紹介しあってました(よしおか氏)
  • 組織の支援以外に、一人一人が「何が出来るか」を問われるようになる
  • 会社の外での学びが、これまで以上に求められる

それに対して登壇者より

  • 一人が経験出来ることは限られている
  • 海外の人とのつながり、海外のコミュニティとのつながりを持ってみましょう
    • 実践してる人は会場の1%くらい
    • ぜひやりましょう!

プロフェッショナルのデベロッパーとは? デベロッパーの「Love&Power」の高め方は?

  • 視野狭窄にならないよう、自分と現場の目を開かせていく
  • プロフェッショナルに向かうコミュニティを創りたい

それに対して登壇者より

  • プロフェッショナルはお金を稼がなきゃ行けない
    • リスクを超えてチャレンジ出来る環境ができるといい
  • コンテキストごとの課題を解決出来る可能性を創れるのがコミュニティ
  • 大きい企業がITゼネコンじゃなくなったら、エンジニア個人個人が仕事を創らなきゃいけない。コミュニケーションをとっていかなければいけない

さぁ、Actionを考えよう

  • 「コミュニティと会社」じゃなくなっているんじゃないか
  • コミュニティに参加している人が、会社を利用して自分の幅を広げていく
  • コミュニティを学習の場だけでなく、自分の可能性を広げていく、出来ることを増やす、実現していく場と捉えていく。

Developer's Summit 2013 参加メモ(7)

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

TED(Technology Enterprise Development)

  • 登壇者
    • 川添真智子氏(兼司会)
    • あまのりょー氏
    • 石沢ケント氏
    • 志茂吉建氏
    • 梅原直樹氏
    • 篠田健氏

導入

  • リラックスして下さいね
  • 運動しましょう
    • 両手を上げて、手のひらを天井に向けて、ぐーっと上げて!

TEDってなに?/Actionカード

  • TED
    • あのTED
      • スローガン「広める価値のあるアイデア」
    • DevSumi風にもじってみました
      • 登壇6名が「価値のある話」をします
      • みなさんのActionにつなげて下さい
  • Actionカード
    • 価値を考えよう、価値のないコトは捨てよう!!
      • 今の世の中、色んなもの色んな情報がありますけども
      • 整理しよう。その基準として「価値」を考えよう
    • いつも2つ考えよう!!
      • 複数の選択肢を持っていれば柔軟に動ける

Actionの価値 / 川添氏

  • 行動の直後には変化が起こる
    • 行動→変化→結果→(次の)行動→変化→・・・
    • 行動することで、行動前には起きなかった変化を発生させ、循環させることが出来る

実験しましょう

  • 飲食物持ち込みNGなので、想像で、、
  • 昆虫食+キャサリン
  • 行動前
    • 食べたくない、気持ち悪い、嫌だ!!!
  • 行動後
    • まずい、意外とうまい、いける?←これが「変化」
    • 次の行動として、食べる、食べない、少し食べる、が生まれる
    • やってみなければ分からない

Actionの価値は?

  • 強化の原理(行動分析学)
    • 行動を繰り返す原理
      • 行動することで良いことが起こった
      • 行動することで悪いことが無くなった
  • 昆虫食の結果を受けて、カエルを食べてみよう
    • 行動に変化が出る!
  • 行動の結果=経験値
    • 行動の裏には「隠された真の経験値」が!
  • 「変化」はイノベーション(=変革)のトリガー
    • 個人レベルのアクションがイノベーションのキッカケ、種になる
  • 行動と行動力
    • actionにはpowerが必要
    • powerは年齢とともに失われていく
    • actionがめんどくさいなぁと思い始めたら、、
    • 自分が出来なくても、他の人がActionできるチャンス・場を与えてほしい
  • エンタープライズな世界でも、Actionには価値がある。
    • 個人のActionがきっかけで世界を変えることは出来る。

MY JOB WENT TO VIETNUM? / あまのりょー氏

  • チアリーダー
  • プロジェクトファシリテーション
  • オフショア開発の事例紹介をします
    • 真の所は、やってみないと分からない
    • 上澄みでも共有することには価値がある

オフショア事例

  • 激しく不安
    • オフショア開発でPLは初めて、、
    • しかも経験がある中国じゃなくて初めてのベトナム、、
  • チームビルディングのタックマンモデル
    • 混乱期=Stormingは必ずやってくる、という覚悟をしておく
    • その後のPerformingも来る
  • PJ説明などのための出張、説明以外の意味でもすごく重要だった。
  • 偏愛マップ(MindMap)を使って自分のことを知ってもらう
  • Chat
    • PFの鉄板技mスタンドアップミーティングは出来ない。なのでChat
    • 細かい技術的な話は常時つないだChatで行う。
    • なにか聞いたらすぐ返してくれる、という感覚を持ってもらうのが重要
  • ビデオレターとか、ミーティングとか、泥臭いことをずっと続けていく
  • これはオフショア開発に限った話じゃない。
  • オフショアは若い。日本はおっさん。
  • 経験とモチベーションを相互補完する
  • ベトナムの現場リーダーの女の子とのChat
  • Extreme Experience「誰と」重要
  • 情熱プログラマー
  • 状況そのものを楽しめるか?←Action
  • MY JOB IS STILL HERE AND THERE!

エンタープライズアジャイル開発 / 梅原氏

  • RICOHの中の新規事業開発を担当。
  • Ricoh UCS(Unified Communication System) for iPad
    • 映像、音声、資料共有
    • エンタープライズ向けに提供
  • 社内標準開発プロセス×従業員数=染み付いた常識化
    • 従業員数が多ければ多いほど、、
    • 脱皮しない蛇は死ぬ
  • WF
    • 良くも悪くも滝
  • Ag
    • パターンが色々ある
    • 成功体験もたくさんある
  • プラクティスをやれば良くなるのではない。プラクティスを通じて「行動を変える」ことが重要
  • 何かを変えたいと思ったら、まずは自分が正しいと思うやり方でそれをやる。
  • それが正しければいつか広がるさ。
  • Action:コードのコミットからバグ発見までを最小にせよ
    • =ATDDでやろう。
  • ウォーターフォールの最大の問題
    • 後になればなるほどコストがかかるのは分かっているのに、テスト工程が最後になっている。
    • QCD守れ!ってうるさい人が言い出す
    • 実装+コミットから発見までが長引けば長引くほど、
      • 修正範囲が大きくなる
      • 設計が壊れ出す
      • コストもかかる
  • だから、要求→提供する価値ベースのテスト見直し→設計+実装
    • 受入れテスト仕様から詳細設計・実装をつくる
    • テストの自動化で、コミットとバグ発見が同時になる
    • 障害が早く発見されるので
      • 障害総数が減る
      • 範囲も少なくなる
      • 設計も改善される
      • コストも抑えられる
  • やり方を変える。そして結果を肌で感じると、チームの行動が変わってくる。
  • それがエンタープライズアジャイル開発。

RBAで楽ちんインフラ構築

  • 仮想化・OSSコンサルタント
  • インフラエンジニア
    • インフラ設計
    • Excelによる設定シートを見ながらコマンド入力
  • Excelシートからパラメータを読み込んで勝手に入力してくれたら楽だよね!

Run Book Automation

  • 手順書の自動実行を実現するには
    • 手順書から属人性を排除
    • 作業内容を明確化
  • インフラエンジニアって
    • GUIよりCLIが好きで、プログラムはほぼ組めない。
  • プログラマって
    • CLIよりGUIが好きで、インフラはよく分からない。
  • RBAの実現に必要なスキル
    • インフラを知っていて、プログラムが書ける。
    • 楽したい、コピペは嫌。
  • RBAで何が自動化出来るのか
    • OS(Linux/Windows)のインストール
    • MW(Tomcatとか)のインストールと設定
    • アプライアンスの設定
    • 設定ファイルの生成
      • Excelシートからの生成とか
    • RubyとかPerlとかで実装可能
  • 今後の課題
    • 現実的なエラー処理の実装
    • RBAの実施結果の評価またはテスト

エンタープライズ開発にもう一つの文化を / 篠田氏

  • タクシー利用してますか?
    • 乗客:電話する
    • タクシー会社:配車
    • タクシー:迎車
  • 2016年までにアナログ無線→デジタル無線
    • 機器買い替えは高い
    • 携帯は安い
  • あったら使うけど、、、

  • 受託開発以外のエンタープライズなシステム提供は、お金になるかwからない。

  • Agileとか意識高い系プロセスは、、、

  • 受託開発エンジニアは「動いてるアプリには手を付けない」

  • 継続的な改善に耐えうるコード品質が必要。

  • エンタープライズがオワコンなのではなく、オープン化からクラウドに至る技術のコモディティ化がビジネスの多様化を促進している。

  • 開発プロセスや組織を後付けするのではなく、技術力や技術に裏打ちされた文化を作る。 新しい文化を創ろう、多様化させよう。

  • 日常的に、コミュニティやOSSのコードに触れる
    • 優れたコードから感じられる、利用者への配慮、コミュニティでの交流、エンジニアリングについての多様な考え方
    • 小さなことからこつこつと
      • OSSが分からない動きしたらコードを読む、自動テスト書いてCIしてみる、読書会開く、チェックリストから自動化を検討、、
  • 去年、今年、来年、同じ愚痴はこぼしたくない。身近なところから始める。

(ここでMacBookが電池切れ、、、紙メモとったんで後で更新します)

2013年2月14日木曜日

Developer's Summit 2013 参加メモ(6)

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

ノンプログラミングで高速開発-単純作業からクリエイティブワークへ- / 森一弥氏@インフォテリア

導入

  • コードはよく見るヤツ、ノンプログラミングはアイコンをつなぐようなイメージ
  • プログラミング楽しんでますか?
    • 始めた時は作りたいもののアイデアが山ほどあったり、作りたいアイデアが山ほどあったはず
    • それが、納期に追われ、無理な追加要求があり、長年の回収による属人化があり、、
  • プログラマーじゃなくても
    • 何度も同じことをしているのを自動化したり
    • 同じメールを何通も定期的に送ったり
  • ツールを使ってみよう
    • プログラマーは楽しい所だけに集中(クリエイティブワークへのシフト)できる
    • ノンプログラマもモノづくりの楽しさを味わえる

ASTERIA WARP FlowDesignerデモ

  • たとえば、DBの内容をExcelに出力
    • VBAとSQLの知識が必要になる。
    • それを不要とするアプローチがFlow Designer
  • IDEっぽいUI
  • プロジェクト作成
  • Flow
    • アイコンを配置してプロパティを設定(VisualStudio的)
  • SQLビルダー(Accessのクエリデザインビュー的)
    • コードを書かず、モデル(オブジェクト)の操作でSQLが生成される
  • Mapper
    • 抽出したデータを元にExcelのフォームへアウトプット

FlowDesignerデモ(WebAPIとの連携)

  • 顧客情報を引っ張って地図や最寄り駅の情報を付加する
    • salesforceの顧客情報 / GoogleMapの地図情報 / 様々なWebAPI をマッシュアップ
    • kintone(by Cybozu)にアウトプット
  • ちょっと複雑なフロー
  • 「テンプレート」にはコードを書く(JSONマッピング?)

FlowDesignerデモ(Webサービス、ファイル、社内システムの連携)

  • 社内で持っている売上情報とWebサービスの地域情報をつなげてWebアプリを作る
  • Excelファイルから抽出した情報と、GoogleAPI
  • ツールを作成して、ブラウザからそこにアクセスして画面が切り替わっていく
  • XMLでのやりとりが出来る⇒Ajaxアプリの自動生成が出来る?
    • ExcelからXMLを生成して、、、っていう細かいブロックを別フローで作る模様

まとめ

  • こんな時に有用です
    • IFの変更が多く発生する / 仕様が確定しない
    • 表示データの追加・変更要望が多く考えられる場合
    • 連携する項目が多い場合
    • プロトタイプ作成を繰り返すアジャイル開発
    • 開発経験者が少ない場合
      • ?コード経験者は必要なくても設計経験者は必要になるよね?

Developer's Summit 2013 参加メモ(5)

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

現場で役立つUX -エンタープライズUXの現在とこれから- / 仙波真二氏@オージス総研

導入

  • consumer [product -> service] -> Enterprise
  • 特定の顧客向けのスクラッチ開発が多いですよね

UXとは

  • ニールセン・ノーマングループの定義
    • 混乱や面倒なしで顧客の的確なニーズを満たす事
    • 所有する楽しさ、使用する楽しさを生み出す「簡潔さと優雅さ」
  • つまり個人の感覚に依存する部分

今日伝えたいこと:EnterpriseUX

  • 現在→これから
    • 見た目のデザイン
    • 行動のデザイン
    • 現場への適用
  • 社内のシステムとかイケてないよね

見た目のデザイン

  • 見た目は重要
    • デザイニングインターフェース
  • 見た目を良くするには?
    • レイアウト
      • 基本パターンを意識する
    • 整列と余白
      • 左揃えや中央揃えですっきりと
      • 余白を適度にとると洗練された印象に
      • ベースカラー、メインカラー、アクセントカラー
    • 一貫性
    • メリハリ
  • ソフトウェアにはデザインパターンがある
  • デザインにももちろんパターンがある
  • 学生向け開発コンペのポスターの例
    • 素材は全く同じで、デザインの原則に則ってリヴァイスすることが可能
  • アプリケーションでも一緒。
    • 画面幅いっぱいに文字を配置すると見づらい、とか
  • スマートフォンの画面デザインのパターン

行動のデザイン

  • ユーザーの行動を観察してデザインする
  • ユーザーが「こうなんだ」ということを鵜呑みにしない
  • コンテキストを考える
    • どういうユーザーか、どういう状況か、何を行いたいか
    • コンテキストにはストーリーがある
      • だれが、どこで、何をする
  • (機能ではなく)行動をモデリングする
    • これまでは機能をモデリングしていた
      • データ構造、処理フロー、画面遷移
      • ユーザーの頭の中、イメージをモデリングする
    • 家具選びなら、個々のカテゴリーから選ぶのではなく、全体のイメージから
    • コンテキストに応じて変える
      • 同じアプリケーションでも、PCとモバイルではコンテキストが異なる
        • PCならフル機能
        • モバイルなら必須のもののみ
  • どう感じるかを自分で体験する
    • 重要な所はプロトタイピング
    • 試行錯誤を繰り返す
    • スマートフォンアプリをデバイス無しで開発するようなのはNG
      • 予算の関係で調達出来ない、自分の端末はセキュリティ上使えない、、
      • FirefoxやChromeでも出来るじゃん ← これはNG
  • EVOLTA / robo-garage
    • ひとりで作った
    • 「設計書を作ってしまうとカッチョいいものは作れない」

現場への適用

  • 経済的な視点からの実行リスト / ユーザビリティエンジニアリング言論
    • 社内に置ける必要性
    • 経営陣からの支援
    • 担当者確保
    • 開発プロセスへの組み込み
    • ユーザテストの実施
  • きっとagileが欠かせない
  • これからは
    • お客様も含めた必要性・支援
    • Agile開発プロセス
    • 担当者確保、ユーザテスト

現場への適用:具体的なアプローチ

  • UXの価値をみんなで共有する
    • 開発者、デザイナー、お客様、経営陣、エンドユーザー
  • 社内の責任者と、各プロジェクトの担当者を設置
    • 多段階発注方式
      • 元請け、下請け、二次請け、、、とかだと収拾がつかなくなる
      • なので責任者を配置して、品質を担保する
  • お客様とともにAgile開発を行う
    • RFPに「UX品質を担保する」を入れる
    • 開発プロセスにUXアプローチ・レビューを入れる
    • チケットに登録してしまう(チケット駆動開発)
    • お客さんの意識も改善させていく
      • 既存システムは従来のやり方になる
      • スマホなんかだとお客さんの要求も変わるので、突破口になりうる
  • ユーザビリティテストの実施
    • 出題者・被験者
    • 合否判定者、タイムキーパー

Action!

  • お客様が自慢したくなるようなシステムをつくりましょう!
    • このメッセージには“UX”という言葉はあえて使っていない

Developer's Summit 2013 参加メモ(4)

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

デザインを考える時にデザイナーが考えること〜デザイナーの頭の中〜 / 秋葉ちひろ氏@Baidu Japan

導入

  • 立ち見がいっぱい
  • とにかくデザイナーが必要!
    • 必要なデザイネーにリーチ出来ていますか?
    • うまく協業出来ていますか?

自己紹介

  • デザイナー/アートディレクター
  • Web制作関連、Androidアプリ制作関連
  • 農学部出身
  • Simejiの画面(UI)デザイン
    • 新しい機能をどういう風に配置しようか、とか
  • Android App Designs勉強会
    • デザイナー向けのつもりが、半分くらいデベロッパー
  • デザイナーズハック
    • 「技術に縛られないでデザインを考えていく」コミュニティ
    • iOS向けとAndroidでは実装技術が違う、、、とか

デザイナーとエンジニアの協業

*こんな印象ないですか? * どちらからも文句しかない、、 * 美意識高そう、プライド高そう、馬鹿なことできなさそう、、 * 会話のキャッチボールが出来ないことがある、、 * 分からない話をされると自分の世界に入り込む、、

  • デザイナーへのリクエストの例
    • きれいにしてほしい
    • かっこよくしてほしい
    • ださいのでなんとかしてほしい
  • これら、具体的に説明出来ますか?
    • 伝えたいことがキチンと伝わるデザインにしてほしい?
    • アートな要素を入れてほしい?

デザインを考える時の頭の中

コンセプトメイキング

  • ターゲットを考える
    • 欲張りすぎず、明確に決める *いつどんな時に使うのか
    • ユースケースを想定する
      • Simejiの録音入力:中国のBaiduから「入れなよ」って
        • おじいちゃんおばあちゃんに孫の声を!
        • 誕生日におめでとうメッセージ
        • アリバイの録音
      • Voicepic
        • 写真と一緒に音声を送る
        • マッシュアップアワード最優秀賞
        • 利用シーンを示すプロモーションムービー
      • paper (iOS App by 53)
        • いいかんじなオシャレなムービー
      • 用途を意識しないグラフィックだけの「カッコイイデザイン」が多い
      • シンプルさと世界観の中間点を考える必要がある

画面の設計

* シンプル過ぎ vs 要素多すぎ
    * デベロッパーは要素過多なデザインに慣れてしまっている
    * シンプルすぎるとアクションが増える
    * 要素が多いと迷いが生まれる
* 画面の設計はインターフェース、ユーザーとのコミュニケーションの端
* 「人間のためのコンピューター」インターフェースの発想と

デザインと実装

  • Everything comes from observation:全ては観察から
    • 電車の中吊り広告の美しさ
    • その美しさからデザインパターンを見つけ、適用する
      • パルテノのポスターは「アレっ?」ってなる
  • 使いやすく/コミュニケーション
    • カンペリモート
  • ○○しているように見せる
    • ふくらみ、へこみ、光っている、、
    • 現実世界の光の当たり方
  • デザイン vs コード
    • デザインを考える時にコーディングのことを考えない
    • コーディングはデザイン通りに
  • 画像で書き出すと
    • 複雑なの表現には楽
    • ピクセラレーション
    • 縦横比
    • 画面密度
  • コードで書き出す と
    • できるだけこちらに寄せる

演出、は省略

まとめ

  • 料理に例える
    • 材料を用意:画面の設計
    • 切ったり下ごしらえ:デザイン、実装
    • 調味:コンセプトメイキング
    • 納期やなんやで省略・優先順位が下がっちゃうと良くないよね!

Action!

  • 一般教養レベルの知識を、まずみんなが持ってほしい
    • 「世界は分けてもわからない」
    • デザイナーだけど、プログラムで何が出来るか知っている
    • エンジニアだけど、デザインの最低限のTipsを知っている
  • 身の回りのデザインを自分で分析することからはじめよう

Developer's Summit 2013 参加メモ(3)

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

SIの未来ってどうなのよ?/大石良氏@サイバーワークス

導入

  • サイバーワークスはAWS専業特化というアプローチをとった会社

自己紹介

  • クラウドノ助
  • 切腹します
  • 「私達の過去のActionがきっと皆さんの材料になります」

会社紹介

  • 大学向けの合格発表サービスを提供:私学の60%くらいが利用
  • 2月の特定の数日にピークが集中
    • そこに合わせたリソース調達は現実的でない
  • AWSと出会う⇒社内サーバ購入禁止令
    • 使い物になるのか、セキュリティは、、などを社内利用で実証
  • AWS Solution Provider⇒最上位へ
  • 日経コンピュータクラウドランキング総合スコア56.6

Action! by AWS

  • 心の底から「やっててよかった」と思ったこと
  • 震災時「赤十字社に繋がらない」というtwitterの声
  • 日本赤十字社にAWS導入(ボランティア)
    • AmazonEC2にサイトのコンテンツを移し、キャッシュにアクセス
    • 30minで稼働 *「 義援金受付システム」やってくれ、というリクエスト
    • 負荷分散、メールサーバー、webサーバー、、
    • 環境構築2時間、AP構築48時間
    • 震災後の迅速な義援金募集に一役買ったのはAWS+ServerWorks

SIって死ぬの?

ネガティブな声

  • SIは必要悪
  • SIは終わった
  • SIは保険屋
  • 倒産過去最多
  • 厳しいのは事実っぽい

AWSでSIオワタ

  • AWSでハードがいらなくなる
  • ソフトの流通もいらなくなる
  • ユーザ企業が自分でシステム構築できてしまう

仮説と検証

  • AWSをユーザーがコントロール出来る仕組みを作ればいいのでは?
  • “cloudworks”フリーミアムモデルのサービス
    • ユーザー数はうなぎのぼり
    • 有料ユーザーが全く増えない
  • 原因は?
  • 予測不能
    • リーマンショック
    • 震災・原発事故
    • AKBあっちゃん
  • 大切なことは、「予測の精度を高める」のではなく
  • 「予測不能な事態が起きても最前手を打つ」=「適応マネジメント」
  • 顧客が望んでいるのはセルフサービスではなく、新しい技術を安全に利用するための保険
  • 突発的な事態への迅速な対応が求められる
  • Agileな意思決定

Pivot & Action

  • cloudworksは無料提供を続ける
  • SIで収益化

クラウドをやって分かったこと

調達モデル

* SIはいらないんじゃないか?⇒No!
    * これを言うのはみんな「中の人」
    * 顧客はSIerを求めている
    * ただし、求めるものが変化する
* 今までのSI
    * 喉が渇いた!
        * 調達チームと品質チーム
        * 意思伝達にドキュメント
    * 人が変わっても同じサービスを提供出来るように
    * ピラミッド型
        * 人が多いことが前提
        * コミュニケーションが重要スキル
        * 下請け企業は技術じゃなくて人材のバッファ
* これからのSI
    * 喉が渇いた!
        * アマゾン工場からHとHとOを持ってきて、組み合わせて水を作る
    * つまり、組み合わせる
        * Amazonのサービス、MQが最初
        * 使い方が分からないと訳が分からないけど、組み合わせて使えば効果を表す
    * クラウド型調達
        * 非常に小さいチーム
        * つくらない技術≒使う技術
        * 「組み合わせる」分子式の知識
            * AWSのCDP
            * HerokuとEC2+SQS
            * S4cとS3
* 分業モデル崩壊による下請けニーズの縮小
* コミュニケーションより技術
* 人材バッファとしての役割は終了

国産クラウドとAWSは何が違うか

  • 戦艦大和と零戦の共通点は? ⇒ 一点豪華主義
  • 欧米はシステム思考
  • レーダーを例にとると
    • 日本
      • 技術としては確立していた
      • 実地で戦闘員が外しちゃう
      • 通信網として意味を為していない
    • 米国
      • 開発者を母艦に乗せて現場を見ながら一緒に改善を回していった
      *
  • クラウドでは
    • 日本
      • SIer、自社クラウドに載せてる? *米国
      • 4兆円のECサービスをクラウドに載せて一緒に枯れさせていく
  • 一点にこだわる姿は日本人特有の姿
    • 世界に類を見ない美点
    • でも、戦争にしてもSIにしても、システマティックな部分では仇
    • システム志向が必要なサービス開発には仇
    • クラウド構築は車輪の再発明。得意な人に任せる。
    • で、日本のSIerは「使う技術」の洗練に拘ろう。
    • 黒船に対抗した人、黒船を作ろうとした人は成功していない。
    • 成功したのは黒船を利用して商売した人。

AWS導入に必要なもの

  • クラウドを利用するために必要なものは何?
    • その答えは「予算」
    • 社内に、社外に未来を示す
  • 利益減るんじゃないの?
    • HW+保守運用+SI費用
    • 保守運用+クラウド利用料+SI費用
    • トータルコストは下がっても、SI費用は上がるのではないか
  • セキュリティは大丈夫なの?
    • クラウドってセキュリティが不安?
      • 外部からのアタック、データ漏洩
      • 内部からのデータ盗難
      • クラウドだと、場所も分からないし誰が見てるか分からないし、、
    • AWSは、内部の面は担保します(第三者認証)
    • 外部は今まで通りお願いします
    • 会社経営に必須の資源は何ですか?それはどこにありますか?
      • 資金は銀行に預けてますよね?
      • セキュリティも可用性も利便性もある
    • クラウドも一緒です
      • ファイル耐久性は1千万年に1件無くなるレベル
    • NASAと御社ではどちらが強固なインフラ持ってますか?
    • クラウドに預けた方が積極的にセキュリティ担保出来る

聞かれるポイントは分かっている

  • 事前に想定し、相手の立場で「何がメリットになるか」考える
    • チームが小さくなる
    • 一人がカバーする範囲が増える
    • 伝える能力がより重要になる
  • サーバーワークスのAction
    • 毎週金曜の夕方、無作為に選んだ2名のエンジニアが社内でLT+UST配信
    • Yammerでリアルタイムにフィードバック

まとめ

  • 保険いいじゃないか!
    • 日本人は90%生命保険に入る民族
    • 顧客は保険を求めている。自信を持って突き進もう
  • 会社も個人も、未来の予測より適応力を身につけよう
  • クラウド分子式・説明力を身につけ、クラウド時代を突き進もう!

suggest your Action

  • 自分で変化を起こす方法を学ぼう!
  • 周りの独りに、あなたが進めたい技術の話をしてみて下さい
    • そしてフィードバックを受けて下さい
  • 変化を楽しもう。SIは楽しい!未来がある!というメッセージを発信しよう
    • 中の人がSIをdisるのは、もうやめよう。
  • 未来は、今日の私達のActionの連続の先にある。

Developer's Summit 2013 参加メモ(2)

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

HBase at Ameba / 鈴木俊裕氏@サイバーエージェント

導入

AmebaにおけるHbaseの導入事例

自己紹介

  • @brfrn69
  • Ameba ソフトウェアエンジニア
  • テクノロジーラボラトリー

HBaseについて

  • 会場で使ったことある人は20–30%ほど
  • BigTableのOSSクローン
  • 可用性が高い、多次元ソートマップ、ハイパフォーマンス
  • Auto Sharding
    • 自動分割、運用負荷の分散

Master-Slave型アーキテクチャ

  • アーキテクチャ説明(Region,、SPOF回避、HDFS)
  • HBaseの信頼性はHDFSに依存

HBaseのデータモデル

  • 列志向データフォーマット
  • RowKey/ColumnFamily/Column/Timestamp/value
  • ColomnFamilyはIO分割したいときに使う

HBaseのAPI

  • Get
  • Put
  • Scan
    • 範囲・フィルタ
  • Increment
    • valueのインクリメント
  • CAS(Compare Ans Swap)
    • 簡単なトランザクションが実現できる

HBaseの設計

  • RowKeyの設計で負荷やデータ量が偏る可能性がある
  • RowのColumnはいくらでも増やせる。ソートもされるし、更新もAtomic
  • Joinはない=非正規化がほぼ前提
  • クエリに対してスキーマが決まる。
    • RDBだとまずスキーム
  • Codezine「初めてのHBase」読んでね!

グラフDB “Hornet”

  • Amebaのスマホ向けプラットフォームをリリース
  • デカグラフ構想
    • 各サービスのユーザ層:ミニグラフ
  • ユーザのグラフ構造を保持するデータベースが必要
    • スケール、高スループットが必須
  • 従来はMySQL+Sharding
    • Pigg、グルっぽ、なう、みんなMySQL *書き込みのスケールに難
    • Shardingの管理が大変
  • そこでHBaseの採用
    • スケールする、速い、Scan、AutoSharding
    • 元々ログ解析にHadoopを使っていたので、ノウハウもあった

Hornet

  • データモデル:プロパティグラフ
  • JavaAPIの説明
  • スキーマ(リレーションシップ)の説明:フォロー関係を例に
    • RowKey:hash(NodeId)+StartNodeId+type+direction+timestamp+endNodeId
    • ColumnFamily:“h:”(単一の値)
    • Column:""(未使用)
    • Value:Serializeしたプロパティ(dateとかfavoriteとか)
  • プレフィックススキャンを使ってリレーションを取得(正引き・逆引き)
  • 今後オープンソース公開したい。

社内ライブラリ

  • 社内で複数サービスを同時展開している
  • DB、一部基盤化はされているが、各サービスで個別に構築している。
    • MySQL,MongoDB,Casandra,,,
  • DBをHBaseに統合することで運用を一元化・障害削減したい
  • いかにRDBに慣れているエンジニアにとって簡単にできるか

Json Persister

  • 「JSONデータとしてJavaオブジェクトを永続化する」社内フレームワーク
    • Beanをシリアライズする
    • 主キーとかインデックスとかをannotate
    • 主キーで取得(load)、リスト取得(list)。シンプル。
  • このシンプルなインターフェースを介してHBaseを使おう。
  • これもオープンソース公開したい。

おわりに

  • HBase触ってみませんか?

Developer's Summit 2013 参加メモ(1)

★受講中に書いていたメモを、推敲無しでそのまま上げています。
★誤字脱字、内容の漏れなどあるかと思いますがご了承下さい。。

600億件を数十秒で検索するクラウド検索クエリサービスBigQuery / 佐藤一憲氏@google

導入

BigQueryのプレゼン

自己紹介

  • @kazunori_279/#gaeja/#gcloudja
  • クラウドソリューションチーム ソリューションズアーキテクト
  • appengine ja night管理人(23回くらい)
    • AppEngine技術者のための情報交換イベント

Agenda

  • ビッグデータをGoogleスピードで
    • 「Googleスピード」は社内用語、すごく早い
  • デモ&事例紹介
    • WhitePaper
  • なぜ早い?
  • MapReduceとGoogleBigQueryの適材適所

ビッグデータをGoogleスピードで

  • Googleではコードを書く時に最初にスケーラビリティを考える
  • アベイラビリティを持つデータ構造
  • Googleのサービスはビッグデータ
    • Youtubeは72h/1min
    • Googleの検索インデックスは100PB
    • Gmailのアクティブユーザー数は4.25億ユーザー
  • もともとはAdwords 、結果をすぐに知りたがる
    • すぐデータ分析したい、どうする?MapReduce?DWH?

MRもDWHも使わない

  • DWHはメモリ・SSDをたっぷり積んだアプライアンスが多い
  • 数千万〜数億円規模のハイコスト
  • ad-hocなデータ分析には対応しにくい
    • インデックス・ディメンジョンの事前設計がないとフルスキャン/テーブルスキャンしか無い
  • データ量に比例して性能向上はハイコストすぎて無理!

so, whatabout Hadoop?

  • DWHより安価
  • RDBMSよりスケールする
  • けど、レスポンスが遅い。簡単なクエリでも数分かかる。長ければ数時間
  • やはりad-hocな分析には向かない

Dremelという虎の子

  • 大規模並列クエリインフラ
  • 数百億件のフルスキャンが数十秒で完了。
  • 検索は全てフルスキャン
  • Webコンテンツの分析、スパム解析、トラッキング、デバッグ、解析、全部Dremel
  • で、そのDremelの公開版がGoogle BigQuery

Google BigQuery

  • 2012年5月公開
  • 1クエリ、35ct/GB、月額120ct/GB
  • デモは無償で一般公開(2TBまで)
  • Dremelのサブセット
    • ProtocolBufferのツリー構造には未対応
  • 使い方としてはGAE/CSVインポート⇒Cloud上のエンジン⇒Googleスプレッドシート/etc

デモ&事例

  • Wikipediaの全ページの全更新履歴から、ページ更新TOP10を検索して表示
    • select top(title), count(*) from publicdata:samples.wikipedia where wp_namespace = 0;
  • Wikipediaの全ページからタイトルに数字が含まれるものを抽出
    • 正規表現の文字列マッチングが速い⇒非構造化データのクエリも速い
  • サブクエリも普通に書ける。従来ではスケーラビリティを上げるために制限が多かった

  • 3rdPartyのERPパッケージからインポートした4.5億件の売上データを分析
    • bime / cloud上のBIツール
    • ちょっと時間かかったけど
  • Crystalloidsの事例:リアルタイム意思決定支援ツール

なぜ速い?

  • カラム志向
  • 数万台での並列処理
    • Google DCの「規模の経済」
    • ディスクI/Oを極限まで並列化
    • 圧倒的なフルスキャン性能
  • 階層アーキテクチャ
    • クエリの分配

得手不得手

  • MapReduceも無くならない
  • MapReduceは大規模バッチ処理
    • アドホックには向かない
    • レスポンスも遅い
    • 技術がややこしい(Tenzing/Hive)
  • BigQueryは巨大なデータのエクスポートが出来ない
    • 複雑なロジック、データ生成、更新、データマイニングには向かない
    • マージ処理なんかには向かない

なので

  • BigQuery
    • Try&Errorな分析、トラブルシューティング、あたりをつける、特性をつかむ
  • MapReduce
    • しっかり分析(駆け足でメモ取れず、、)

2013年2月5日火曜日

[DevLOVE]『セカイとカイシャと自分の仕事を考える』参加レポート(メモ)

2013/2/4 セカイとカイシャと自分の仕事を考える@日本オラクル青山センター

http://devlove.doorkeeper.jp/events/2503
参加時に書き溜めたメモです。

本日の目的(私の)

  • 自分と会社の関わりについて再考する
  • 自分がやりたいこと(仕事)を組織ベースで考えてみる
  • 「組織の中での存在意義」「自分にとっての組織の存在意義」について考えてみる

はじめに

  • 「ようこそオラクル青山センターへ!」by papandaさん
  • 説明前後で謎の拍手

概要(DoorKeeperより)

  • DevLOVE2012ではいろいろ考えすぎてうまくまとまらなかったので、もう一度リベンジしてみます。
  • 会社の中でどうするか、あるいは別の会社を探そうか……などと考える前に、そもそも「カイシャ」と仕事について考えてみましょう。
  • 形式:レクチャー
  • 登壇:高橋征義氏
    • 札幌出身。株式会社達人出版会代表取締役、一般社団法人日本Rubyの会代表理事。
    • Web制作会社にて主にWebアプリケーション開発に従事する傍ら、日本Rubyの会を設立。
    • 2010年にITエンジニア向け技術系電子書籍の制作と販売を手がける (株)達人出版会を創業。
    • ちなみにそれまで勤めていた会社2社はどちらもすでに現存しない。
    • 著書に『たのしいRuby』『Rails3レシピブック』(どちらも共著)など。 好きな作家は新井素子。

intro

  • DevLove2012では物足りなかったので再演(再構成)
  • 「かつて所属していた会社は2社とも存在していない」ところが重要

本日のなかみ

  • 本日夕方、ファイルぶっとび
  • TimeMachine超重要
  • 「もうDevをLoveしていないんですか?」
  • 自分戦略、だけど自分の経験は参考にならない、、
  • けど、色々やってきたのでシェアしたい。
    • 会社員
    • 任意団体代表
    • 営利法人代表
    • 非営利法人代表
  • 会社はツール
  • 自分に合ったツールを使う
  • なければ作る、作らせる、外から使う

わたしの自分戦略?

  • 卒業、入社、吸収されて転職、Rubyの会設立、退職して創業、Rubyの会が社団法人化
  • 自分の戦略を予め考えるのは苦手。難しい
  • ソフトウェア技術者の戦略ってこんな感じ
    • 社内で頑張る
    • 転職する
    • 独立する
    • 起業する
  • 転職
    • そもそも他人の評価や時期の問題
    • つまり客観的とも実力勝負とも言い切れない
  • 独立・起業
    • リスクが大きい、運に左右される
    • 全力でリスクがとれるか、リスクを下げられる手がある場合意外はオススメしない
    • 成功した人の話はバイアスだらけだし、失敗した人は語りたがらない
  • なので、心に棚を作る
  • 現実を直視するのは厳しいので、現実から全力で目を背ける

会社とは何か

  • 「Ruby知ってますか?」「(会場苦笑)」「この質問で笑いが起こるのは嬉しいことですね」
  • 法人と自然人
    • 法人でなければ「任意団体」
      • 会場も口座も個人名義
      • なにかあったら個人に責任が降ってくる
    • 法人になると
      • 口座も作れる
      • 契約も結べる
      • なにかあったら訴えられるのも法人
      • 義務も権利も構成員じゃなくて法人になる
  • 民法:一般的な話:法人の定義
    • 権利を有し、義務を負う
    • 登記すれば出来る
    • 法人
      • 営利法人:構成員に利益を還元できる:頑張って儲けたらウハウハ:事業拡大できる:構成員の生活は保証してくれる(法人差があります)
      • 非営利法人:構成員に利益還元できない:
    • 法人以外
      • 権利能力無き社団
      • 任意団体
  • 会社法:会社固有の話:会社法人の話
    • 会社はうまくできてる:冒険もできる:税金がとられる
    • ひとりが所属出来るのはだいたい1つ
      • それを回避するのが非営利団体とか
      • けどNPOは縛りが多い
        • 理事が10名以上、報告書提出義務、、、
        • 一般社団法人の方が楽

会社と自分との関係を考える

  • 目的が必要
    • 「報酬の目標」は実現するのが案外難しい
    • それよりも「何かをやりたい」「一人ではできないことをやりたい」を実現するためのツール、と割り切って再定義する

会社っていいよね

  • 平日昼間から動ける
  • 会社は任意団体とするよりも組織を大きくしやすい
  • 一人じゃ出来ない規模のはたらきが出来る
  • ⇒じゃあ何をやりたいの???

たまたま見つかった高橋さん

  • 「日本の技術書も電子書籍で読みたい」
  • できるまで1年
  • 利益が出るまで3年+数百万円溶けた
  • やりたいことを思いつくのも難しいし、実現するのも難しい。

実現方法は色々あった?

  • 社内の事業
  • 他社とくむ
  • 個人で取り組む
  • 非営利法人としてやる
  • けど、会社でやってよかった
    • 時間を投入出来る:サービス開発に注力出来る
    • しばらく赤字でもOK:会社じゃ許されない
    • 関係者(原稿書いてくれる人、読む人)にも安心感
    • 周囲に対して本気度が伝わりやすい

「あったらいいな」から考える

  • 突き詰めると、、、
    • あったらいいなを考え続ける
    • 実現方法を考える
    • 実行する
  • この「実現」の一手段に「会社に所属する」「会社を経営する」etc がある
  • でも「やりたいこと」が無いとやっぱりしんどいよね

スタートアップと目標設定(DevLove2012ボーナストラック再現)

  • テーマ「世界を変えるのは、自分自身だ」
  • 大きい言葉。大げさな言葉。
  • 普通の開発仕事とはギャップがある。
  • けど、よくそういう言葉はよく聞く(特にスタートアップ方面)
  • 多くの場合、実際のところ世界はそんなに変わらない
  • 騙しているわけではなく、進めるにあたって、遠くの目標が欲しい
  • 組織は(犯罪じゃなければ)何をやってもいい
  • すると、何をしていいか分からなくなる。混乱する
  • 新規事業のほとんどはうまくいかない
  • 上手く行かない事業は、変えないと死ぬ。
  • 最初上手く行かない、のは迷走なのか遠回りなのか進んでいるのか分からなくなって不安
  • なので、すごく遠くの目標を立てる
  • 多少ぶれても誤差の範囲。それで充分。
  • 例えば「北極星を目指す」は431万光年先を目指すのではなく「北上する」ということ
  • 無限遠にある目標としての「世界を変える」

だけれども

  • 全部が全部遠いわけでもなく
  • Social Change
  • Kent Beck 時を超えた〜〜
  • XPの課題は、ソフトウェア開発と社会の関係の再構築。ソフトウェア開発への新たな価値の創造。
  • 言ってることとやってることのギャップがありすぎないか??
  • 1987の論文:プログラミングにパターンランゲージを導入したら?というやつ
  • 顧客と開発の関係性を変えるhttp://c2.com/doc/oopsla87.html

まとめ

  • 日常の「あったらいいな」を実現しよう

ここで休憩。

たのしい会社戦略

概要(DoorKeeperより)

  • 自分戦略って考えるのはしんどいし、都合のいい戦略はあまりない。
  • だったら、「自分」を一旦離れて、「どんな会社があるといいのか」を考えてみませんか。
  • 自分が働きたい会社ではなく、世の中にとってあると良い会社。
  • ここで考える会社がまだ無いなら、作っても良いかもしれませんね。
  • 形式:ダイアログ

どんな会社・事業があると世の中にとってよいか / 10min

ひとりで考える(メモ)

  • ひとに優しい
  • 貧乏人にやさしい
  • たのしくなる
  • 苦しくなくなる
  • 夢がある
  • やりたくないことをやってくれる

だいあろーぐ(4人で) / 15min

  • 夢を失った人を救う「褒め屋」
  • 個人の夢を応援してくれる会社

いいね!を付箋に / 5min

みんなで話をする / 20min

なんでも出来る人がなんでもやってくれる会社

  • なにかをやるには、なんでも出来なきゃいけない
  • 少数精鋭でのなんでも屋

エンジニアの欲望をそそる会社

  • 「どんな会社がいいか」だと黒い話が多い
  • 負の感情、欲望がうずまいてくる
  • 男性エンジニアが女の子とペアプロ出来るような会社

二次会できる場所を探せるサービス

芸能プロダクション的な会社

  • 派遣の発展系みたいな
  • フリーランスの仕事をマネージング、プロデュースしてくれる
  • 本当のマネージャーはこれ。ピープルマネージャー

会社の枠を超える、制約の少ない、ハッカブルな仲間と出会えるあれ

  • どういう事業であるのかは気にしない
  • 事業にはこだわらず、働きやすいかとかそういうことの方が優先順位が高いのではないか
  • 誰と働くか、が
  • 金が儲かる会社に集まるよね

国境、文化を気にしない会社

  • 公用語を英語にしたりしなくても、自身の行動力や考えで、世界中と仕事ができる
  • 言語より文化
  • どうやったら仲間になれるのか?
  • どうやったら仲間だと考えられるのか、思わせられるのか?

社内版クラウドソーシング

  • Googleの20%のアレ的なのを使って全社的に人を使う
  • 隠れた適性に気づいたり
  • 普段プログラミングしてるけど、実は板前のスキルあるよ!とか
  • 仕事と人のマッチングを、社内でやってみることが出来る仕組みがあると面白いね

吉岡さんより

  • 「どういう事業をやりたいのか」にフォーカスしたかった
  • nice to have な組織構造は世の中を変えない
  • 世の中を変えられる事業を考えたかったが、そこまで深堀できなかった
  • コトを起こすために組織が出来て、事業になって、そこにエンジニアや営業やマネージャーが集まってコトを為す。で、その「コト」って何だろう?という話がしたかった

高橋さんより

  • 会社っていうと悪いイメージがある
  • 会社じゃ出来ないからコミュニティ、ってなる
  • けど、出来ること、したいことベースで考えたら、やっぱり会社というツールは良く出来てる。
  • 入りたいとか入れるとかは一旦置いといて、やりたいことに対してのアプローチとして「会社」という仕組みはうまいこと出来ている。
  • でも自分ベースだと考えにくいし、辛くなるし、制約もある。
  • なので、「やりたいこと」とか「あったらいいなサービス」をベースにして考えたら、もっと会社に対しても前向きになれるんじゃないかな、というのが今回の発表を通じて得られたl気づき。

メモは以上です。
ほかの参加者の方のメモはこちら。

貴重なお話を提供いただいた高橋様、
主催の@papandaさんはじめDevLOVEの皆様、
会場提供いただいた日本オラクル様、
ありがとうございました。