Tweet

Disclaimer

• 聞き取ったことのメモです。聞き取りミス等あると思います。
• 発表者のスライドで補填していこうと思っていましたが、2/23現在、まだあまりスライド上がっていないようですね。。。

---

下記、長文のため、先にまとめておく

まとめ

• 1日目と比べエモイのが多かった。
• お金の話：すごく参考になった。損益分岐点と、定量的な根拠による提案。
• IBMの人は自社製品売り込みすぎ（Jenkinsまつりでも。。。）
• Azureのひとのクラウドの話。　ベンダー資格じゃないクラウドの資格を初めて知った。とってみても損はないなと思った。
• GCP、やはりすごい。。。
• 社内スタートアップの話、かなりためになりそうだったか分量多すぎるので後でスライドちゃんと見よう
• ビズリーチCTOの人の話、雰囲気がおかしな漢字だったけど、最終的に具体的な育成計画の詳細に入っていて、面白かった。
• 2020年の話、大学教授がパネラーでアカデミックだったけど、一番エモかった気がする。人工知能とUIの相性が悪いなんて、考えたこともなかった

---

2015-02-20 10:00【20-E-1】2F E会場（華しずか）"なぜ俺の提案は通らないのか" - エンジニアが知っておきたいお金の話

土居 昭夫〔NTTPCコミュニケーションズ〕　データセンタ事業部　部長

• 具体的な話多くて、話していいところもあるのかなというところもあるよ
• 社畜型ITリーマン
• 株式会社アイル→GMOへ（当時６名）
• 器用貧乏

はじめに

• 前回のデブサミの時の飲み会で「若い人ってお金知らないよね〜」
• イマジネーションは大事　今後のことを考える
• 将来のために　→　マネジメント系のキャリアプランを考えている人のために

• つくる、うる、ささえる　すべて大事　←　ここでの共通のプロトコルは金とモノ

• 「原価厨にならない」

• 簿記は損にならない

• 今日の目標

• お金の構造をわかる

• 頻出ワード（会計用語多し）

• 諸注意

  • 裏はとっているが、経験ベースのはなしなので、まるまる鵜呑みにしないでね
  • 仕組みを理解してもらって、実際やるときは会社の経理と相談しながら
  • 数字の経営感覚もバラバラ　PL重視派、BS重視派　など
  • 所属組織とは関係ないよー

クラウドでコストダウン？

• かつてクラウドのウリ文句は　→　コストダウン
  • ほんとに？
  • コストは費用
    • 固定費用
      • かならずかかる費用（※長期的に変動しうるものも有り）
    • 変動費用
      • 拡大に伴って変動する費用
        • AWSの帯域とかもココ（？データ転送量のことか？）
• ちょっと考える
  • 数字の例
  • 減価償却
    • 耐用年数　資産価値を年々減らしていく
    • 一戸建て、
      • 土地と家屋で分ける
      • 家屋は１０年で価値ゼロに
  • 人員大丈夫？
  • 減価償却は年々下がる
  • 変動費の項目読みきっている
    • 従量課金怖い
  • クラウドのメリット
    • 管理コスト、固定資産のメリット内
    • ダメだったとしてもダメージは最小
    • 「スピードが最大のメリット！」

金は企業にとってのガソリン

• 支払い

  • 「給与の支払が滞る！」
  • キャッシュ・フローをみる

• 個人の場合

• 企業の場合

  • ☆当座と普通の違い
  • ☆現金のやりとりしない

• ↑個人も企業も変わんない

• キャッシュ・フロー超大事

なぜ提案が通らないか

• 情熱だけではダメ。決済通らない
  • 承認する人の思惑がある
• わからせないと話がすすまない
• 経営、管理、エンジニアで　考える事の優先順位が違う
  • ビジネスプランも分かっておく必要
• 経営者は事業継続が最優先事項
  • それは儲かる？どれくらい金と時間がかかる？
    • 売上じゃない、利益
    • WEBサービス（ストック案件）だと市場とかによってくるので、もうそれはマーケティング手法
      • 期間でかんがえることが必須！
• 損益分岐点を図る、長期的に計画
  • サービスがマイナスからスタート、どこで黒字に転じる？
  • 人件費はなくなるものじゃない、プロダクトという資産に転じる
  • 売上が総費用（固定・変動）を超えたタイミング
  • マイナスの時に、どう会社を支えるか（スタートアップでキャッシュ・フローが重要なところ）
• 損益分岐点の例
  • 単月黒字（月あたりのトントン）、累積黒字（今までのマイナスがチャラ）
  • どれくらいの投資が可能？販売が可能？売れた時のコストは？どこまでグラフが下がるとまずい？
• 「どうやって、いつ、勝算は？」
  • どう　手法
  • いつ　スケジュール
  • 勝算　トレンドなど
  • 技術のわかるひとが、↑に協力してあげる
  • アメリカのイノベーティブなサービスでただ　→　作り手が売上があがるかどうかがわかっていない。

質問

• 損益分岐点の見込みってどうやって根拠をだす？

  • ライバルがいる状態？ゲームの例
  • 自社にある数字がいい例
  • パズトラに似たゲームなど、協業他社のゲーム、例えばパズドラとかの決算を参考にしてみる。

• 社内向けのシステム、直接利益にかかわらないものは？

  • 業務プロセスの変革が目的が例
  • 今までのプロセスの精算をしてみる
  • バリューチェーン全体のなかでどれくらいコストが掛かるかあ
  • 変えた場合、人が二人必要ない、とか。
  • 効率が良くなって単価がさがるという構図はカンタン
  • 今までなかったものに、追加するのはかなり難しい

• 生命保険会社システム子会社　ポジションごとの視点がいろいろあって、自分自身がとまどっている。今後どうしていくか

  • 現場のエンジニアでも、ベテランだったらお金の話が通じる。
  • あまり意識してなくても、数字を見ていれば段々慣れてくるよ
  • 日本の場合、成長の最終形がマネジメントになっちゃってる、それはあんまり良くないと個人的には思う
  • 自分で決めた形を通していくのがいいと思う
  • プレイングマネージャーという茨の道
  • 「これが食える」というところで判断もひとつの道　自分もインターネット業界に入ったのは食えると思ったから

• 社内教育に携わっている人、教育の結果が見えづらい。教育の損益分岐点も出せば企画も通りやすいのではと思った。

  • 難しい話題
  • 教育を定量化できる？
    • 実績
    • 資格
    • そのあたりをKPIにするしか無い。
    • それ以外はふわっとしちゃうのでは？

• 損益分岐点　このWEBサービスがダメだ、の判断はいつ？

  • 経営者が決めるしか無い。
  • 明確な基準はない
  • さくらインターネット　損益分岐点は８年後だった
    • 最初から目標を決めていたので、
  • 偉い人に、いつやめるかと、聞いてみる、じゃないと現場が壊れる

まとめ

• 共感に至れば勝ち！

---

2015-02-20 11:05【20-B-2】2F B会場（夢扇）

「DevOps」やってみた。そして、気づいたこと、陥ること、見直す

• IBMの人 @akawase

• 諸注意

  • スライド多し
  • DevOpsの一般論は話さない
  • 実例とか（お客さんとか）は曖昧に

• YDK HNK

• 経歴

  • 各種会社やってきた

本日のまとめ（先に）

• でぶさみのあいうえお作文

DevOpsとは

• みんなちがうよ。自分が考えているものを話す
  • KEEP on Developing, keep on operatin
  • 作り続ける、生かし続ける
    • 「使い続けられる、買ってもらい続けるものを提供
    • つくり、以下し続けられる「仕組み」
      • ちゃんとフィードバックを反映など
• 作って届ける　距離と時間を縮める

きづいたこと

• 全部頑張るひと、フルスタックエンジニアの話は面白く無い。
• 人やサービス規模が大きくて仕事が細分化しているところでの話をしたい
• 運用と開発の言葉のていぎ（本講演）

陥ること

見直すこと

小さなチーム小さな改革

• 開発‥運用とか全部頑張るチーム
• 無秩序な環境から脱却
  • 暗黙のルールでどうにか回っていた
• ここから変革（上層部からの声）
• 自動化を検討してみる
  • コスト小さいけど効果大きそう
    • テスト、デプロイ自動化
• 部分だけじゃなく↑、全体の最適も考えてみたら？
  • オンプレからクラウドに移行するところも踏まえて、自動化
  • 将来を見据えた構成管理の見直し　（並行開発）
    • デプロイを自動化しようとして、気づいた！
• ファイル管理のずさんさに気づいた！
  • ☆IBMUrbanCodeDeployを使った
    • （こないだJenkins祭りでみたやつだな）
• 構成管理の見直し　デプロイフレームワークに対応するもの
  • デプロイ単位でのファイル管理
  • 作業とデプロイの関連付け
  • ☆IBMRational〜
  • ドキュメント化
• 自動化で最小限にやろうとしたら、思った以上にやることがあった。
  • やることは、人数と正比例しない
  • １０人と１００人でもやること変わらなかったりする

CIをすすめたてみたがいいが

• ↑とは別案件、部門が細分化されているところのはなし。
• 標準化部門、CIの標準化を　各開発チームにサーバを配る
  • 開発チームのソース管理がバラバラで、共通のビルドの仕組みに乗れない。
• 陥ったこと
  • 共通ビルドサーバがだめなので、チームごとの個別のビルドサーバを用意した
• 標準化（ツール選定）部門の検討内容
  • コスト以外も、理想的な将来像を
• ビルドとその前後の見直し

Opsから変えてみたら

• 運用はコストの削減、開発はスケジュールの死守
• まず自動化を考える。特に運用がらみで　運用人員ゼロへ！
  • 手順書を自動化へ
    • 自動化の対象が多すぎる
  • 運用側、コードは読めるけど、開発が不得手だった
• 当初の予定倍に、スキルも足りなかったので人件費も
• 見直し
  • 部門部署個人の得意不得意を
  • じゃあ開発と運用を合体させればいい？
  • 他部門の作業詳細知っている？
  • クラウド化による運用のあり方の変革
  • なにから進める？
    • 自動化対象の優先付け
      • 自動化は２割やれば、８割ぐらいの効果があったりする（個人的経験則）
    • 急がばまわれ
      • やるまえによく整理

さらなる処方箋（IBMの宣伝）

• ☆ShiftLeft
  • ☆ブルー・グリーン

---

感想

• うーんと思うところが幾つかあり
  • 金融庁の開発・運用を分けろという話は「？？？」
• やっぱり宣伝多いｗ
• ちょっとぼかしすぎててあんま共感できるところがなかったー

---

12:10～12:40【20-B-L】テストケースの優先順位をつけてテストを最適化しよう! 津村 直史〔日本シノプシス〕

• Coverity

  • OSSなら無料でつかえまっせ

• 静的解析

  • コーディング規約チェック
  • ランタイムエラー検出（coverity（製品）の誤検知率は低い）

• コピペして修正中にエラー検出　←（IDEで十分なのでは？）

• カバレッジの罠

  • テストできないコード
  • テストを行う価値がないコード
    • デバッグコード、例外処理など

---

感想

• 対応言語気になる
• ほかのことに気を取られており、まじめに聞いてなかった。途中退室

---

2015-02-20 13:05【20-E-3】2F E会場（華しずか）　クラウドを活かす組織運営 ～ガバナンス入門

• パブリッククラウドエバンジェリスト　吉田パクえ　さん
  • 吉田ゆうやさん
    • マイクロソフト（Azure）

当セッションの目的

• クラウドのアンチパターンの共有と、見落としがちな点を考える
• 組織論とやり方の話　←　正解はないよ

ケース１〜ケース７まで（全部実例だけど、ちょっと変えてる）

ケース１

• サーバ２０台の予定が２００台にんった
• なぜか：導入することが目的になっていた
  • サーバ購入の承認印を押すタイミングが無かった。
  • ものが見えないところの怖さ
• 全く稼働していない意味不明なインスタンス
  • 意味不明なインスタンスの存在　「なにしてるの？」「がんばってます」
• 稼働後のリソース見直しが実施されていない（少なくする、小さくする）
  • オーバースペックの見直し
• 監視、運用体制の見直し
  • ちゃんと負荷状況をみて、適正なサイジングを（関しとかの情報をちゃんと収集する）
  • PDCAサイクルを回す　←　軍隊由来　
    • どういう判断をしなければいけないか
• クラウドの効果をえるために
  • クラウドを利用すると得られるもの
    • 結果
    • 費用
    • 結果を評価して、「効果」を実感する
    • 費用はインスタンスがすぐに立つので、結果の評価のやり方を最初から考えておく！

ケース２　知らない社内システム

• フレキシブルさに欠ける組織
  • 部門間などの信頼がなく、勝手に進めちゃうなど
    • 開発部と情報システム部（☆ネットワーク部とかが相当するかな）の信頼関係
• ルールがない
• 権限の譲渡とレポーティングのガイドライン
  • 知らない社内システムが立ち上がるのは防げない
    • 善意からやっている
    • 改善したいと思ってやっている
  • その「知らない奴」に入れられると困る情報　←　ガイドライン
  • ↑が適正に守られているかのレポーティングが重要
    • チェックが可能なアカウント
    • 規定に沿ったレポートが出せるか
  • 自分たちがいやなのは時間が使われること
  • 権限の譲渡について
    • 組織のツリー図
    • 自分の部下はちゃんとみるが、自分の部下についてはレポーティングを要求する　←　マイクロソフトはちゃんとしてる（外資だからというのもあるかも）

ケース３

• リソースが調達できない（稟議）
  • サーバを上げれば、上司が止める
    • サーバがすぐに立ち上がるのに、稟議がいちいち必要、稟議５日かかった例も（本来２ヵ月かかる稟議がすごく短縮したので、その人がんばった）
• 導入時にワークフローを見なおしていない
  • クラウド利用の仕方を考える↑
  • 権限譲渡の範囲を規定に落としこむ　←　時間かかりがち
    • 例：APIたたいて２００台立ち上げるのは、本当に許可されてる？
    • デベロッパのお金の感覚がたりないと↑みたいにやっちゃうことがあうる。　サーバ代のコスト意識を。

ケース４

• Paasを使っているけどアジャイルにならない　（？？？）
• 管理手法が従来のままだから
  • 要件定義ながめ
  • 仕様書紙
  • デプロイは１回
• タスクサイズを小さくする
  • 要件定義が長いのがそもそもだめ
  • すぐに「１回作ってみた」
• デプロイまでのループを回す手法にする（イテレーション）

• まずは小さな成功体験を

  • 前回聞いた要件について、ちょっと作ってみました
  • 毎月ある程度工数をきめて、ちょっとずつ進めていこうというやりかたに、お客さんとシフトしていく

• フィードバックループの獲得

  • 設計〜開発〜デプロイ〜運用　のループを何度も回す
  • 要件定義で帳票をRails のScaffoldそのままDB定義してデモ
    • そのままScaffoldの画面を使ってもらう
    • そこからやりたいことを吸い上げていく

ケース５

• クラウドを導入したら学習コストが増大した
  • 余談：Azureも今年いっぱいでるよー
• 新しい機能を追いかけることが正しいという文化
  • なんとなく新しいのでたら追わなきゃいけない感覚
• 情報共有で個人の学習コストから、全体の学習コストの削減
  • ノウハウに対するドキュメンテーションの共有
  • 新人研修　やってみせて、やるがわにマニュアルを書かせる
• コスト意識（学習コストも「コスト、工数」だよ）
  • 学習も自分のタスクに入っているか。
• 課題の明確化
  • 何のために学習するか
• 外部リソースの活用
  • 得意な人を先生にする
    • ボランティアしすぎない。その人を支援してあげる形で
• デブサミにいつも来ているが、一向に会社が良くならない
  • 意識高い空気から、月曜会社に行って　現実とのギャップに「なんだこの会社は」

ケース６

• 属人化が進んだ
• ナレッジの共有が行われてないから
  • Chef書いたのに、その人がやめたらChef廃止になった。
  • ↑「ソースコード読め」的な人だった
• トレーニングしてみては？
  • 同じモノ（サーバ、環境）をつくる
  • 障害が起きているサーバをコピーして、新インスタンスを立ち上げる。障害インスタンスは削除。素敵！
  • 先輩が障害を仕込んで、後輩がその障害を解決する（トレーニング）
    • ↑は教育面とかなので、これメインの目的だと企画が通らないよ

ケース７

• 能力を評価できない
  • やってる人の評価
• 基準が無いから
  • 将来求めるスキルの基準にしてみる
    • 今必要なスキルじゃない
  • 各種資格を活用して、スキルの見える化
• クラウドを知っている、の正体
  • ベンダーに依存しない部分 *コンピューティングとか、ネットワークなど
  • ベンダー特有の部分
  • まずはベンダーに依存しない知識を学ぼう
  • CompTIA CloudEssentials
    • おすすめ
    • 実務ベース
    • 営業でも取れるよー
  • ベンダーを追う
    • ３ヵ月で陳腐化したりするけど、基本的な部分は変わらない
    • コミュニティーの参加
    • 利用者のブログ、スライド

まとめ

• ガバナンスの基本
  • 権限の譲渡レポーティング（ギブアンドテイク）
  • 見れる範囲をサイジング
• 組織運営の基本
  • ワークフローを見直す。クラウドは時間の感覚が違うのでそこを考慮

---

感想

• 稟議のあたりのスピード感の話はやっぱり共感できた。
  • この辺りを意識したチーム作り、仕組みづくりにしていくべきなんだろうなぁ。。。

---

14:10～14:55【20-E-4】ここまで来た！Google Cloud Platform の真価と進化 福田 潔〔グーグル〕

• GoogleAppEngineは知ってもも、GCPは知らない人も
• 他のプロバイダと目指しているものが違う

• エンタープライズ、企業向けにGoogleのソリューションを得る人

• 検索エンジンからスタートした会社

  • WEBから提供する形をずっとやってきた（クライアントサイドのアプリじゃない）
  • 現在は膨大なDC
  • 検索エンジンだけじゃない
    • メール、マップ、ブラウザ、泥、GCP
  • 他のDCと同じようにスケーラビリティをめざす（？）

• 既成品サーバじゃない

  • サーバ自体を自分たちで組み上げる
  • ハードは壊れるので、すぐに取り換えられるように

• 世界中のDCからコンピュートリソースを提供

  • 世界各地（現在１３箇所）全部自分たちで作ったDC
  • 日本にはまだDCないよー

• 「日本にDC無いけど大丈夫？」

  • ネットワークのバックボーンを自分たちorキャリアと提携して引いているので、レイテンシが少ない
  • 東京・大阪に、ピアリングポイント（POP)がある（バックボーンにつなぐポイント）
    • ピアリングDB
    • 主要なキャリア？と接続済

• インフラだけじゃないよ

  • クラウドテクノロジーの革命（の歴史）
  • 「あくまでも自分たちの基板を良くするために」が原点

GCP

• コンピュートGAE（Paas）から、GCE,GKE（コンテナ）
• ストレージ（CloudStorage、CloudSQL,CloudDatastore）
• ネットワーク（InterConnect　DCとつなげる　VPN、専用線（キャリアを使う方法とピアリングポイントまで自分でつなぐ方法））
• ビッグデータ（BigQuery,Pub/Sub、DataFlow（アルファ版。ベータになったらみんな使える）
  • DataFlow　Hadoopじゃなく、べつのメカニズムで（SQL以外のやり方）
• マネジメント（モニタリング
  • ComputeEngineはまだ１年ちょっとしか
• モバイル
  • Firebase（買収したやつ）
  • モバイルのホスティング先として１位を目指す

直近一年の動き

• アジアDCのオープン
  • レイテンシはアメリカだと120msecくらい、アジアDCだと、50~60msecとか
• StackDriver（モニタリング、アラート型の買収）
  • GCEでちょっとみれる？
• Zync（買収）
• Firebase（買収）
• Kubernetes
  • Docker去年もりあがったよねー
  • １つのマシンだと良いけど、クラスタが多くなってきたら管理どうするのか？という解決策
  • Googleの中では週に２０億個コンテナ立ち上がってるけど、という記事

GCE

• Iaasのベンダ間の差は、あんまなく、基本的なところ
  • 品質
    • プライベートネットワーク　リージョン間のVMをつなげるよ
    • 透過的なメンテナンス（Googleのほう）
      • 物理サーバ上の客のサーバに影響無いように
  • スケール
    • １０００ノードのクラスタを５分以内に起動
  • 低コスト
    • １分単位の課金（１時間じゃないよー）
    • 継続ディスカウント（自動）
  • ディスク
    • ディスクを増やすと、IOPSが勝手に上がる（標準ディスク）
  • 一貫した性能
  • 高性能なロードバランサー（４秒で立ち上がる）
  • 透過的なメンテナンス
    • ライブマイグレーション　VMを動かしたまま別の物理マシンに移動
      • 全く影響が無いわけではない。一時的なスパイクはあるよ。
  • 使えば使うほど安くなる（１００％利用で、最大３０％オフ）
• デモタイム
  • 新規インスタンスを作るデモ
    • 万が一、なんかあったとき、仮想マシンが止まったら、勝手に再起動してもいいか？というオプション（可用性オプション）
    • ライブマイグレーションするかどうかのオプション
    • サービスアカウント。GCEに入れれば、他のGCPサービスにアクセスできるように
    • SSHコンソールがブラウザで立ち上がる
  • デベロッパーコンソールを、ターミナルから使う。gcloud（CLI）
  • ネットワークのデモ
    • hanoiからparisへpingを投げる
      • 249msecくらい
      • host名から名前の自動生成
  • 監視機能
    • トレース
      • あるURIの呼び出し
        • 例えば１秒かかったとして、その内訳をみることができる。
• AppEngine（BeansTalkみたいなもんかね）
  • 負荷に応じて自動的にスケールアウト（

• BigQuery

  • 億件レベルに対応
  • 自動スケールアウト
  • BIツールで非技術者でも

• DCは単なるコンピュータの集まりじゃない。全体として大きなコンピュータとして、機能している、というイメージ（Google中の人）

• ぜひみんな試しに使ってみてね！

---

15:15～16:00【20-B-5】社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(拡大版)～スクラム&リーンスタートアップ導入について～ 黒田 樹〔リクルートホールディングス〕

※スライドの分量が多いので、よく読む

• @i2key

• 前職SIer

• 現在はcameran カメラアプリ（1000万DL）の開発全体責任者

• ぎすぎす、いざこざについて

• 文脈によって、制約になるものがちがう

  • アジャイルサムライの絵から引用
  • 全部死守みたいな例も
  • 社内スタートアップなので、「スコープ」は比較的調整しやすい

• さいしょの体制

  • スモールチーム
  • アジャイルのような何か、でリリース
  • ツイッター３日で一気にふくれた！
  • これは行ける！　超特大開発に！

• エンジニア、ディレクター、アライアンス、デザイナ盛り盛り

  • やるべきことに着手できない焦り
  • 全部最優先（最優先のなかの最優先）
  • 伝言ゲーム（コミュニケーション）
  • 技術的負債の山
  • バグ解決だけで１日が終わる

• 今なら言える失敗

  • 少人数ならうまくいくなにかをアジャイルと呼んでただけだった

• 師匠を招いた

  • 希望を伝えた
    • 小さくする、エンジニアを取りまとめる役はいらない、仕事の見える化
  • スクラム採用、XPのプラクティスをちょこちょこ後から入れていく
  • iOSエンジニアからScrumチーム化
  • スクラム始めるあるある
    • 〜〜をやらなきゃいけない！というのにとらわれちゃう
    • ↑は間違い、型にはめることに意味があるわけじゃない。やりたいのはタスクの優先順位付け

• 優先順位付けするために必要なこと

  • そのエンジニアが今何をやっているか？
    • ☆acunote（スクラム特化型）

• スプリントバックログ

  • 開発、バグ、MTGも、休暇も　ポイント換算（１日１ポイント、１スプリント１０ｐｔとして）

• スクラムマスターが、iOS→サーバ→Androidに伝授していく。伝授していく時に、各チームにスクラムマスターを立てる

  • 各チームのスクラムの同期をとる

• バグマネジメント *ポイント振ったバグ対応の中で何をやっていくかは、優先度を決める

  • バグMTG２つ
    • バグトリアージMTG（一次切り分け）　別に直すわけじゃない。短時間で。クリティカルかどうかがポイント。１時切り分け自体に時間がかかるのであれば、ポイントを振る
    • バグマネージメントMTG
      • 振り返り、優先度の確認

• リリースマネジメント

  • デリバリーに乗るか乗らないかは自分次第
    • （逆に詰め込み過ぎたりしないのかな？）
  • 最優先でやれよ！　←　わかったけど、糞コードでリリースするけど、リリース後に技術的負債の改修期間が必要。

• ProductOwner、ProductOwnerProxy（Ownerだけじゃなく。プロキシに意思決定の権限がある。権限はひっくりかえさない）

• アジャイルは時に残酷

  • 可視化されたくないひとまで可視化（進捗がないひと）

• メンバーを信頼しよう

  • 信頼してもらうためにパフォーマンスを出すこと

• 信頼できるメンバを最初に入れることが重要

• 今の状況

  • スクラムマスターみんな出来るよー
  • 自己組織化が進んでる
  • プルリク→ビルド自動化
  • 非エンジニアのプロダクトオーナーがエンジニアにムチャぶりしなくなる

• （サービスの）成長スピードの鈍化に対しては？どう対応する

  • タスクが本当にやるべきことなのか

• リーンスタートアップ

  • 実装が必要なエビデンス（根拠）はなにか？
    • 「お前の中ではそうなんだろうな〜〜」
  • UXの講師とかを招いたり。小手先じゃなく、第一人者をまねく
  • 無駄の無い判断をする　→　効率化へ
  • DropBoxは作らずに、動画を作って、ニーズを検証した
  • 例：ダミーボタンを用意してユーザの１０％に出て、クリックされるかどうか、でニーズを図る、実証する
  • ☆LeanCanvas
    • 仮説の実証
    • ☆MVP Canvas （仮説検証）　☆コホート分析
      • 例仮説：SNSログインが障壁になっているのではないか？
  • ☆言葉の定義多い

• いまの形を回していく

  • やらないことが最大化
    • 検証とそれの実装ベースになっていく
    • 仮説の検証していくと、やるべきことがどんどん減っていく
    • エンジニア体制の縮小（タスクが小さくなっていく）
    • LeanEngineerは、仮説検証のサイクルを早めること（そうじゃないエンジニアはステップ数が実績）
      • ハイレイヤーなKPIにコミットできる
      • 例：退会率現象にコミットしたエンジニアが、自ら仮説検証したり

• まとめ

  • 営業の人のしごと（成約率など）が、エンジニアの仕事になりつつある。

---

16:20～17:05【20-B-6】情報革命時代における新しい多様性の共存と、これからのエンジニアのキャリア、評価制度について 竹内 真〔ビズリーチ〕

• ビズリーチCTO

• 悩みがある（ココ３ヶ月ぐらい）

  • いいものと売れるものが一致しない
    • ビズリーチ内での組織的な課題でもある
  • いいものはエンジニアが作りたい、売れるものは売り手営業側が作りたい　という２項対立
    • あちらがたてばこちらが立たず状態
  • べつにどっちが優性とかじゃない

• 歴史を振り返る。世の中的に、売り手と作り手は分かれてる

  • 自動車や、日本の伝統工芸の例
  • 「完成品」であれば↑の形でもうまくまわる
    • ITの世界にフィットしないのでは
      • 完成品、ではない、提案と改善の繰り返し
      • 無理やり伝統的なやり方をしようとすると、スピード感生まれない
  • 売り手と作り手の一体化が必要
    • でも別部門だったりしたりする。

• なぜ組織の一体化が難しいか

  • 人間は内向的人格と外交的人格の２種類に大別される（遺伝子レベルで決まってる）
    • 脳科学、脳の扁桃体の大きさとかが関係ある？
    • 刺激の感じ方の個人差（敏感・鈍感）
      • 鈍感な人、新しいものとかがちょうどいい刺激
      • 程度の違いはある
    • 内向的・外交的　はちょうど反対
      • 多人数との社交　ができる・できない
      • 話をしたい・話を聞きたい
      • 深い志向が得意・不得意
    • 外交的な人の至上主義　（スーザン・ケイン）
      • ディベートで相手を打ち負かすなど

• ビジネスとものづくり

  • 内向型・外向型、営業系でも半々とか
  • 内向型人材を、外向型のように振る舞わさせることと強いる文化

• コミュニケーションでよくある問題

  • 外向型「BBQ来れば？」　内向型「（えー疲れる）」
  • 内向型　緻密なレベルでのハイクオリティな要求　外向型「（言葉で言ってくれないとわからない）」

• 遺伝子レベルでの違いなんだから、指向性の違いによる要求は「ハラスメント」と考える

• 内向的人材の特性

  • 口頭よりも文書
    • インターネット上での非同期（メールやLINE）のコミュニケーション　←　熟考できるので、得意
  • コンテンツに価値がある（？？？）

• 外向的人材と内向的人材の相互理解が前提として必要

  • 社内のプロダクトマネージャーにパネルディスカッション（という社内イベント）
    • 内向的な人にも刺激を（新しい、リアリティのある知識は心地の良い刺激）
      • 受ける心地よい刺激量はどこかなー？
  • 内向的なひとたちはモラルハザードを嫌う
    • 個室や静かな別室など、内向的な人たちには向いている（性善説で信じる）

• キャリアと評価制度はどうあるべきか？

  • オリジナルすぎる評価制度は、社会的に見た時に評価されない（自社でしか通用しない人材）
  • ビジネススキルとマネジメントスキル
    • 役職とそれに対応するマネジメントスキルの図
    • マネジメントスキルは心の研鑽でしか磨けないのでは
  • ビジネススキルは技術力とビジネス力（儲ける力）
    • ビズリーチの役職とスキルの対応の図
    • マーケティング力や、経営力。KPIについて立案・検証・実証できる力。こういうのを培える会社に *　マネジメントスキル
    • ☆アウトプットサーキット
    • 感情のコントロールについて

まとめ

• 内向型・外向型の相互理解
• 技術者にもビジネス力を
• 例外的な完全技術志向の人を受け入れられる柔軟さ
• 評価制度の因数分解と、その論理的説明

感想

• 会社のポリシーとしての話で、この育成・評価体制は社員とも共通理解がとれていることなのだろうか？

---

17:25～18:45【20-D-7】CodeZineスーパー対談 「2020年のUI/UX ～ スマホ・タブレットの先にあるもの」黒須 正明〔放送大学／人間中心設計推進機構〕/渡邊 恵太〔明治大学／Cidre Interaction Design 株式会社〕/【モデレーター】坪田 朋〔DeNA〕

渡辺先生　明治大学　ぼくらはいま何の設計をしているか

• タブレットでレシピを見ながら料理の図　←　なんか変
• 道具自体に計量機能をもたせたりとか（メモリを気にしなくていい）
• スマホで計量カップの水量を図る

• 体積、重さの可視化、次は長さ

  • スマホで長さを図る。例えばメジャーとして利用
  • １次元プリンタ　テープを引っ張るだけで、所定の長さに勝手に切れる

• アクセス、理解、行動

  • 情報の道具化　
  • アクセスと理解を一体化して、UIとコンテンツが形、仕組みを持つ
  • UIとコンテンツが別れて設計していた。
  • コンテンツとUIをわけない方がいい

• IoT　センサーを利用する例が多いけど、それだけじゃないよ

• まとめ：ぼくらはいま何の設計（インターフェースづくり）をしているか？

  • 機械　→　コンピュータ　→　次は？
  • つぎは、インターネット
  • グラフィックデザインから、今度はプロダクトのデザイナまで（もしかしたらの今後）　UI設計的志向が求められる
  • インターネット前提でのプロダクトデザインは結構まだ課題が多い
  • ☆書籍「融けるデザイン」

黒須先生　HCD　放送大学　エンジニアの進むべき道

• ユーザビリティをずっとやってきた
• 意味性を考えてほしい
  • 人工物がどんな状況で、どんな人にとって、どんな目標達成に意味があるのか
  • 意味があると、人が満足する
    • ☆キャズム（アーリーアダプタとアーリーマジョリティの間）
  • イノベーターは何でも触ってみているけど、↑のキャズムは意味があるかどうかによっている
  • 品質特性
    • 客観ｘ主観ｘ人工物品質ｘ利用品質
    • 主観・利用品質が大事
• 人工物進化学
  • 元をたどってみる
  • 基本的欲求は昔から変わっていない
    • それを満たすものの形が変わってきただけ
• 必要性のあるものは消滅しない
  • たとえば、カチッとした格好で登壇「したい」　この感覚はずっと消えないだろう
• 衣服のシワを取る進化　の例
  • 不満からどんどん形が進化
• 現在地と目的地を知る　進化　の例
  • 地図、カーナビ、スマホ　
• ユーザ工学が必要
  • ユーザの多様性（ユーザの属性、状態）　
  • ユーザの理解
    • ←フィールドワークで調査する
• 失敗の事例
  • イオン発生装置付きテレビ
  • グーグル・グラス
  • 失敗の秘訣
    • 開発者の思い込みで突っ走る
    • 新しく、奇抜なもので面白そうなもの
    • なんとなくよさ気　これいけるかもな〜

• 成功事例

  • メッカを示す腕時計（ムスリム向け）
  • インド式桁表示の電卓　（桁区切りが違う）

• 2020への方向性

  • スマホ、タブレット機能的に飽和
  • Web,スマホ、アプリのサービスデザインはどこまで伸びる？（サービスはこれからも必要）
  • ウェアラブルやARがどこまで実用に堪えるかあ
  • ☆ナレッジナビゲータ（Apple）
  • ☆BicentennialMan、Her
  • ☆HAL
  • ↑このへんのインテリジェンスなインターフェースが必要になってくるのでは？
  • シンギュラリティ
  • 自然言語対話　またこれからくるのでは？
  • デザイナーの出る幕は？
    • プロダクトの終焉？（会話のデザインってどんなもの？たとえば司会や、カウンセリング）
  • むしろ心理学者、言語学者の出番

• 教訓

  • 和文タイピストがワープロで消えた
  • ↑の例がそのうちデザイナーやWebクリエイターのしごとが奪われるのでは？

• 2045年には？

  • かな漢字変換で感じをかけなくなる（自身の予言）
  • 先端技術の進歩で職能者の失業
  • APIの登場で考えることが不要に。また、人が考えられなくなってくる。
    • 大学教授も失業？
  • 感情や自我をもったAIの登場？
    • 人間がいらなくなっちゃう？

パネルディスカッション

GoogleWatch の失敗、AppleWatchは克服できる？

• クロスさん　ウェアラブルを信用していない、発展性を。

  • 腕時計や、メガネ、ブレスレット、ペースメーカー（病気関係）
  • メガネはものをみるため
  • スマホはものをみるために十分？（という検討がされていない）
  • ３次元テレビの奥行き　生理学的なレベルの眼球運動
    • ３ｄでは、生理学的なレベルの眼球運動がついてこない　←　画面酔いの原因か
  • AppleWatchも同じか
    • スマホとどういう違いがあるの？
    • スマホはポータブルだけど、ほとんど密着している
    • アプリが後から考えられている感じ？
      • 腕に巻いたら、健康データが取れるだろう
  • モデ：気持ちが良いぐらい全否定

• 渡辺さん：失敗しやすそう

  • アプリから考えて、デバイスをつくるべきだなーとは思う
  • とはいえ、ハードウェアの普及は難しい
  • google glass あまり興味なかった
    • 歩きスマホ　←　常に情報を得たいという要求
      • 情報を得たいことをどうやって実現させていくか
  • バッテリー、大きさ　みたいな課題
  • チャレンジしていかなきゃいけないとは思う

• もで：キャズム超えられなかった。とか。でもデベロッパとしては作りたい *

IoT　

• モデ：メーカーは必ず出してくる。２三年後とか、僕らに期待しているものは？
• 渡辺さん：GoogleGlassの失敗は、コードに繋がないこと。
  • 「それ画面でいいじゃん」というものがある

• クロスさん：IoTについて

  • 益々普及していくことはまちがいない。が、どういう意味を持っている？
  • 意味が解析できないと、ログを解析しても意味が無い
  • 会話の断片がインターネット上にビッグデータとしてある
  • 教育とか、人間の学力などに合わせて教育してくれるAI

• モデ：AIが発達してくると、UIが変わってくる　

インターフェースの方向性

• モデ：どういうものになっていく？
• クロスさん：　目と耳が重要。パーソナルな情報はパーソナルな機器で。　←　スマホ完成度高い
• 渡辺さん：人工知能（Agent）とインターフェース（DirectManipulation）は相性悪い。過去の議論。
  • 人工知能が発展すると、人間何するの？
    • 楽しみも奪われる？
    • 楽しみを作ることもインターフェースの仕事
    • 人工知能が運転しても、趣味として運転する　
  • 人工知能に奪われた部分を補完するようなインターフェースを考えていくのでは
  • これから楽しみを提供していくのか？
• モデ：Oculus　楽しみを提供していく？

今後どのような人材が求められるか

• モデ：どんな方向に伸びていけばいい？

• クロスさん：プロダクトは現状維持路線？、サービスデザイン。

  • サービスはコト。できることが多くなる。
    • 知的な水準がとても低い人の話し相手など（介護の例）
    • ５年後ぐらいでもかなり進んだことができるのでは。
  • 外から炊飯器操作できて、意味ある？

• モデ：サービスを考えられる人が必要？

• クロスさん：コトのデザインをする人は必要になってくる

  • 人が人に対してやっていたことを代替。
  • 看護師さん、図書館の司書、
  • どういうサービスを受ければもっと満足できる？
  • 出来なくて当然、をひっくり返していく

• モデ：昔流行っていたことが、UIをシンプルにしてヒットしたり。本質的なニーズを再構築

• 渡辺さん：DeNAどういうひとが来ている？

• モデ：必要な人は、プロトタイピングしながらサービスを考えられる人。サイクルを回す人。

• 渡辺さん：プロトタイピングという意味では学生はガンガン回す。はじめからプログラミングしてくる学生も。話すのも見せるのもだめ、動かすのを見せる

  • 企業に行くと分業でしょというのが不安を持っている学生も

• モデ：目に見える形で。動かして。という人が圧倒的に前に進む感じする。

  • 学生でも↑のような人多い
  • 企画の人がなくなってきている。。。

• 渡辺さん：文系の下請けにはなるな。アイデアもコーディングも優れている人に。

2020年に世の中はどうなってる？

• クロスさん：いつまでもアイデアを頭のなかに留めない
  • 拡散型の思考方法（？？？）
  • やっぱものじゃなくてこと（ものを含めたコト）
  • デザイナーの本質を、エンジニアがとってしまったほうがいい

• 渡辺さん：各言語対応とかの対応に追われちゃうのかなあ（オリンピックに向けて）←これでちょっと意識が変わるかもなぁ

  • それほどテクノロジー的にはウェアラブルとかはやってないよ
  • 翻訳とかのアプリ増えてるのでは

• モデ：コーディングも重要にという感じ

QA

• 人工知能の話　理不尽なことヒステリーなことを言わない人工知能がでてくるかどうか？
  • クロスさん：ヒューマニスティックな人間に対して優しいものとしてのAIがどうやって発展していく
    • ある方向に考え方を方向づける　←　ディープラーニング分野での心配事
    • ロボット３原則じゃないけど