2017-02-17

DeveloperSummit 2017に参加してきた

昨日、今日とDevelper Summitに参加してきた。

面白いセッションが多かったし、エンジニアとしての今後をもっと深く考えるきっかけにも なったので、遠方から参加してよかった本当に良かったと思う。

特に聞いてよかったのなぁと思ったのは、以下の3つ。

  1. コネクティッドカーがもたらすモビリティの可能性と日産自動車における挑戦

Note

Nissanというゴリゴリのハードウェア業界に「いた」企業が、ソフトウェア、しかもインターネットに接続されることまで意識したソフトを 作ることに本腰を入れて、わざわざ部門まで作るというフットワークの軽さに驚かされた。 内容が新鮮で、朝イチで頭も冴えていた、というのもあるが、参加したセッションでは一番楽しいセッションだった。

  1. 教育、医療、もの書き市場で戦うプロダクトマネージャーの考え方(訴求ファーストとこだわり駆動開発とは?)

Note

JustSystemの社風と、開発現場での動き、成功事例が見えるお話。わかりやすく、非常に良いセッションだったなぁと思った。 個人的な知り合いにJustSystemに転職した人がいるが、その人からJustSystemはベンチャー的文化がかなり強い、と聞いていた通りだった。 受託開発0、ということができるのも規模の大きな、余裕のある会社の強みですね。

  1. コミュニティとエンジニアの生き方

Note

開発手法や技術の話ではなく、コミュニティ運営に関する話だが、非常に熱く良いセッションだった。 2部構成だったが、特に後半のKanJavaの人の話は実体験に基いていて、Java(好きな言語)への 熱い思いも感じることができて、かなり刺激を受けた。今年は自分もOSSへ貢献したいと考えているので、早く足を踏み入れたいと思う。

ほとんどのセッションは資料も公開されるようなので、 後からまた振り返るつもりだが鉄は熱いうちに打て、であるので、 印象に残ったセッションのメモを以下に残す。

参加したセッションのうち、特に印象に残ったものを以下挙げていく。

02/16 コネクティッドカーがもたらすモビリティの可能性と日産自動車における挑戦

日産の方。こういったサミットで車業界の人が登壇するというのは結構珍しいのではないかと思う。

以下、本セッションのメモ。 (スライドが英語だったので、英語で記載している部分が一部ある)

はじめに

自動車業界もハード重視からソフト重視に以降

  • 参加者にはWeb業界の人もいる

SpeakerはYahoo! -> Fast Relaitling(ユニクロ)-> Nissan という複数業種を渡り歩いてきた

Nissanの考えるモビリティ、コネクティッドカー=車というモノではなくサービス、情報の提供先(PC, mobile...と並ぶもの)

Now ----------> | ------------------------------------------------------->
Car(Hardware)-> Connected Car -> Autonomous Driving -> Mobility services

これからこうなる

100$ of new cars will be conneced by 2025

safety and convenience are key expectations from drivers

urbanization requires new mobility solutions

Nissan Intelligent Mobility

自動運転、電気自動車、コネクティッドカー 3つの柱をNissanは重視

Mobility serviceはこれから伸びる予測:

  • 2015 -> 2030で+30%市場成長(3500 billion doller -> 6700 billion doller)

Software is a Key

車が人へのインターフェースになる ->
ハードの世界からソフトの世界が重視
-> Googleなどのハードにかかわらないところがたくさん入ってきてる
車の会社にはソフト専門に作っている人がいなかった
-> ソフト専門部門を作った

Car Centric から Customer Centric へ

とある国では60%の人が、車についているナビを別の会社のナビに交換してしまう。
-> 顧客にとって使いやすいものを「最初から」提供することが重要

Iot Architecture

                        --- Service --
                       |              |
                       |              |
x 10M/year             |              |                x 10M/year
Mobile <- https -> Server <-----> IoT Hub <- MQTTs -> Car

Mobile, Carは10M/yearで増えていく。

Car <–>IoT Hub は複数体複数を考慮する必要あり、しかもMobileと異なり、 Carはエンジンがかかっているか? 何人のっているか?誰が運転しているのか?といった情報が情報提供に必要となる。

そこが面白いところでもある。

Developer Friendly Environment

Location:Urban
Working Hours:Flexible, remote work
Toolsets:Mac, github,...

などなど

環境を用意できないと、ソフトの人たちは来てくれない

ソフト専用の開発拠点

Japan, France, India

Partnership

Microsoft, DeNAなど




02/16 パネルディスカッション:「エンジニアが作るプロダクトの未来 〜エンジニアからプロダクトマネージャーへ〜」

  • 高橋さん(Sony mobile communications)
  • 鈴木さん(Biz reach)
  • 横道さん(Cyber Agent)

という3名のプロダクトマネージャーが集まってのパネルディスカッション。

これから先の自分のキャリアを考える上で参考になる話も多かった。

なんにしても、製品や作りたいものへの愛、情熱が大事。

以下、本セッションのメモ。

以下敬称略

言葉の定義

プロジェクトマネジメント -> PM

プロダクトマネジメント -> PDM

  • ロードマップ
  • ビジネスケース、
  • 新製品開発
  • 市場投入
  • ライフサイクル管理
  • ブランド管理
  • マーケティング

などなどをやる。

PDMは何をやっている?

チーム・ピープルマネージメント

PDMの仕事は、「強いチームを作ること」

チーム立ち上げ:
人ごとの得意不得意の把握をすることが重要と感じている

高橋:フェーズにより異なるが、

  • 人のマネジメント2割
  • 他部署調整3割
  • 要件定義2割
  • ロードマップ・現状分析3割
  • 関連部署調整、マネージメント調整にかなりの工数を費やす

横道:

  • セールス支援もある(BtoB,BtoCどちらも製品がある)

PDMになったきっかけ

高橋
  • 育児にかける時間が必要な中、仕事のアウトプットをいかに出すかを考え、PDMになることが面白いと考えた
鈴木
  • 技術は大事だが、その前に良い戦略がなければうまくいかないことを痛感
横道
  • 自分自身のエンジニアとしての市場価値から、エンジニアではなくPDMとなった方がよいと考えた

エンジニア出身であることの強みは?

Inspired(本)を読もう

横道

  • 実現可能性を、エンジニア視点から考えることができる点
  • ソフトウェアは必ずバグがある。作らないことで、負債を減らすことができるー>つまり作らないでいかに実現するか、を考えることができる

鈴木

  • 技術がわかることが強み

    • 技術は魔法だ、と考えている人が世の中にはいるが、そんなことはない
    • テクノロジーがわからない人には、だんだん難しくなったことが多くなってきた

プロダクトマネージャーに向いている人は?

仕様調整、ステークホルダーの調整が苦手、っていう人は無理

鈴木

  • ソリューション思考型のエンジニア
  • 顧客へ提供する価値とビジネスとのバランス
  • 喋りたがり、仕切りたがりという人もあり
  • 自分が全部やらなくても、この技術はこの人に任せればよいや、と割り切れる人

高橋

  • 自分がこれを成し遂げた!よりもチームの人が満足して働いている様子が好き、という人、奉仕精神?のある人

横道

  • ステークホルダーコントロールがうまい人(関係している人の調整、落とし所を見つける)

プロダクトマネージャーでなくとも明日からできることは?

横道

  • ユーザ視点、ユーザストーリを書いてみる(ユーザがどう使うか、ユーザにとって何が嬉しいか、を書いてみる)
  • ユーザストーリを作る訓練は必ずフィードバックが必要なので、誰かに監修してもらうと良い

高橋

  • なんでもやります、を実践する

    - 自分の責任範囲以外でも、とりあえず取り組んでみる.すると、色々なチャンスがやってきやすい。

    • 色々なミーティングに参加してみる。隣がやっていること、隣の隣がやっていることを知ることは結果的に自分の力になる。

- 自分の熱中できるもの、愛せるものが仕事で作り上げるものになると良い

鈴木

  • 顧客視点をしっかり持つこと

    • 自分のプロダクト、競合他社のプロダクトを使ってみる

      • 自分の会社で、自分の会社のサービスや競合他社のサービスに登録してもらい、比較、体感してみる.そこから更に改善提案などできると良い

おまけ:PDMを漢字一文字で表すと

高橋

愛:とにかく同じプロダクトに愛がある人を集めて、ものをつくることが重要

鈴木

情:情熱と感情

責任を負うポジションになって辛いこともあるが、顧客に喜んでもらうこと 顧客の感情をいかに掴むか

横道

省:労力を省き、最小限の労力で、最大限の効果を目指す



02/16 市場で勝ち続けるための品質とテスト技術

Yahoo!のセッション。

今回のDevelopers Summit では、1日目に一つの会場でYahoo!のセッションがずっと行われていたが、 その中の一つ。

品質改善のためのペアプロ、XPの話が前半、後半がテスト自動化の話。

全体としてこれまでの実戦経験に基づいた話で、説得力があり面白かった。

以下、本セッションのメモ。

ビルド時間の増加、単体テストのしずらい設計。。。

  • ヤフオクアプリを一つビルドするのに数十分。これが開発時間を圧迫していく。
  • 不十分な単体テスト、リードタイムの増加。

ピボタルラボで修行

開発チームでLEAN XPをならってきた。

LEAN XP = リーンソフトウェア開発+XP(エクストリーム・プログラミング)

リーンXPでやったこと

PDM + エンジニア

エンジニアはペアプロをする。

作るものの一部の機能を担当し、ペアの片方を次の日別のペアに入れる

A,B -> A,E C,D -> C,F E,F -> E,B

みたいな感じ。

必ずペアプロをする。

ペアで作業したことを共有することで、コードに責任を持つ(ソースコードの共同所有

テスト駆動開発

ナビゲーター: 失敗するテストを書く人 ドライバー:成功するテストを書く人 リファクター: ロジックを変更せず、改善する

バックログマネジメント

ユーザがアプリを利用するシナリオを考える
-> シナリオからテストに落とす

作った人がテストするのではなく、PDMがテストする

前半まとめ

  • より小さくより価値の高いものを順に実装

  • 単体テストの修復を最優先

    • 単体テストが通ることは自信に繋がる
  • 実装は自分以外が確認

    • 自分の実装は正しいと信じ込んでしまっている。

      • だから他の人が確認する。

ここから後半:テスト自動化

テスト自動化はもう必須になってしまった

しかし

  • やり方がわからない
  • たくさんあってどれやればいいかわからん
  • メリットがわからない
  • 工数が余計にかかるのでは?という疑念

これを解消する。

テスト自動化の始め方

  • ユニット(単体)テストから始める

    -> ユニットテストは導入が簡単、かつ効果が見えやすい

    -> ユニットテスト、受け入れテスト、GUIテスト、手動テストの順のピラミッにあるように、ユニットテストは一番数が多い

  • 座学やワークショップは正直役に立たない。
    • ハンズオンで実際に手を動かしてその価値を「体験」させることでやっと分かる。

アプローチの手順

  • Cyber DojoでTDD・ペアプロを体感させる
  • プロダクションコードへユニットテストを追加する(即実践で鍛える
  • 必要になってから理論やテクニックを深く教える

習うより慣れさせよ!

落とし穴とその回避方法

コードカバレッジの罠

コードカバレッジが重要なのではなく、価値のあるテストを作ることを意識付けすることが重要

-> 障害の頻発する箇所、頻繁に修正する箇所、追加/修正する箇所に集中してテストを実施する

コードがテストしづらい

-> テストをしやすくするためのツールを探し出して適用する -> テストをしやすいアーキテクチャに変える

仕様化テストを整備する
-> 今あるコードをベースにしたテスト。必ず通るはずのテストを実施する。

マンネリ化を防ぐ

-> テストへの感心がなくなったりする。飽きる。

-> 定期的に目標を設定させる -> 自主的なテストルールの見直し、テスト自体のコーディング規約の見直し

-> 自主性のあるチームへ

目的のために良い手段を選ぼう。

テスト自動化のためのステークホルダーマネジメント

ステークホルダーがそもそも多い問題
  • サブリーダ、リーダ、部長、テクニカルディレクターなど。。。
  • 更にステークホルダー間の連携ができてない
-> ステークホルダーのマネジメントをやることにエンジニアは消極的
-> ステークホルダーを説得して環境を作ることもテスト自動化の一部だ、と考える
-> チームが自らステークホルダーを集めてミーティングをするようになった

テスト作成に集中できる環境を作ることも立派なテスト自動化




02/17 自動化はどこに向かうのか〜まだ開発・運営の自動化で消耗しているの?〜

テスト自動化の方法の話かと思っていたが、テスト自動化に対する考え方の話だった。

さくらインターネットのエヴァンジェリストの方のお話。

以下、本セッションのメモ。

自動化の流れ

開発の方で自動化の流れがあるが、運用でも同様に自動化の流れがある。

  • 「自動化」が目的になると地獄
  • 「ツール」は私達の問題を解決しない
  • 「問題解決の道標」必要は発明の母

そもそもゴールが間違っていることがある:

  • 「ツールを導入すること」が目的化してしまう
  • 業務フローが全体が捻じ曲げられる。

ゴールを共有することが大事

そもそもなぜ自動化が必要になったのか?

  • 省力化
  • 時間短縮
  • 人的ミスの防止
ブロードバンドで常時接続(PC)
-> ケータイで常時接続
-> スマホで常時接続

という時代の流れ

サーバなどが止められなくなり、サーバの増減を早く行う必要が出てきた
-> クラウド化
-> 自動化へ -> サーバ監視も自動化

ツールを入れれば解決するんでしょという誤解

  • 物理システム基盤を仮想化で解決した
  • 速さ・リソース有効活用につながった
  • コスト削減につながった

しかし本来は、競合他社に勝つために必要だったはず

はやくリリースする、早く開発、テストする
-> 省力化、時間短縮、人的ミスの防止

現場視点と全体俯瞰:単に使いたいはNG、使うべき理由がある

自動化には2段階

  • 手作業の自動化 -> 目の前の辛い仕事を楽に

  • 手作業の先の、本来あるべき理想状態

    -> チームやプロジェクト全体が正しい方向性を向いているのか -> 目的を達成できているのか

    を意識する。

    あるチームがこのツールを使って成功した -> じゃあ全社導入しよう!は間違い

    「あるチームがこのツールを導入した理由」はあるチーム特有の作業があったからかもしれない

    ただ結果だけを見て、導入するのではなく、その理由、目的を理解して導入する。

課題は環境によって異なる

  • 本当に自動化が必要なのか

    • 自動化で何を達成するのか
    • 「速さ」「品質」「コスト」のバランスを考える
  • 自動化「したい」ではなく「すべきか」を考える

    • 現場視点・・・常に正しい努力をしているか(このツールを使えば作業を減らせる

    • 組織視点・・・会社として、チームとして全員が同じ方向を向いているか

      そのツールは本当に自分たちの仕事を助け、競合他社に勝つ、という目的にそっているのか?をきちんと検討すること
      • 必要性の判断。必要は発明の母。

DevOps Defined

HashiCorpの定義

あくまで目的達成のための自動化

ツールを使いたい、その気持はわかる

組織全体として何が正しいか?他チームに強制していないか?

目的を喪失したツールの話は間違い

個人の効率化と組織レベルの自動化の混同は駄目。

ちょっと脱線: 農業IoT

農業にも機械化、自動化、IoTの波が来ているが。。。

  • 田んぼの水調整は、その水源(同じ川)を利用している田んぼ農家全体で調整する必要がある。

    • 上流の田んぼで水を沢山入れると、下流の水調整がそもそもうまくいかない

    • 一つの田んぼでIoTで水調整をやりましょう!というのはうまくいかない。

      • やるなら全体でやる。

現実的な課題は組織の話になる

  • 自動化やツールありきではない

    • 全体として何を達成するのか? - 組織にとって課題は異なる
    • 自分で手を動かして、そのツールが目的に沿うか確認してから!
  • 運用の仕事・開発の仕事

    • 運用の仕事はなくなるのか?
    • 組織が別れている場合は?
    • 人を減らす話じゃないよ



02/17 教育、医療、もの書き市場で戦うPDMの考え方〜訴求ファーストとこだわり駆動開発とは?〜

JustSystemの社風と、開発現場での動き、成功事例が見えるお話。

以下、本セッションのメモ。

訴求ファースト

「訴求」=商品における”買う理由・使う理由”

「訴求ファースト」= 訴求を先に決める。
-> 作った後に売る、ではなく「売り方を決めてから作る」

JustSystemでは訴求をまとめた、「訴求シート」というのを使う

教育「スマイルゼミ」

家庭学習:紙からタブレットへ

今までは
  • 紙で解いて、それを郵送して、採点されて戻ってくる
  • PCでE-learning

が多かった

ジャストスマイル:全国の小学校80%で利用されているソフト

JustSystemでは母親が多く働いている
-> 子供がなかなか家で勉強しないという悩みがある

企画検討

ちょうどiPadが出たころ

2020年には一人1台のタブレット
-> タブレットで通信教育がいいな、からスタート

しかしまだ作り始めない

どう作るか、はまだ。

何を作るか、に徹底的にこだわる
これが訴求ファースト

何を作るか:スマイルゼミの顧客は?

使用者と購入者が異なる

使用者:子供

購入者:親(主に母親)

何を作るか:何が刺さるのかを探る

アンケート(FastAsk)

インタビュー

  • 嫁レビュー、子供レビューを実施

「どんなものがほしい?」には答えてくれない

  • 何に困っているか?
  • 仮説=訴求シートをぶつけてみる
  • どこがいいのか?

何を作るか:訴求シートをどんどんぶつける

  • 訴求シートの実例

    (売る時のちらし/カタログ的な感じ)

訴求シートからわかったこと

訴求ポイント

夢中になる!だから続く。

↑これはウリ文句にもなった

  • 子供はなかなか勉強しない

    ->すぐに飽きて続かない

教材ももちろん重要だが、子供が続けられる仕組みを作る必要がある

-> 訴求シート紙面の大半を「続けられる仕組み」を説明するために使った

開発において:訴求シートが仕様書になる

訴求シートによって

  • ゴールが明確になる

    • 詳細な仕様書は必要なし(重要な画面はすでに訴求シートで決まっている
    • 後戻りがない(作るものは決まっているので、作った後に手直しする必要がない
  • 作るべきものにメリハリがでる

    • 重要機能に注力(重要機能は既に訴求シートに書いてある。書いていない機能は重視しない)
    • 余計な機能に時間を割かれない

新規立ち上げだが、半年ほどでお客様に渡せた。

半年でタブレット渡せるのはすごいな、、、

医療「JUST DWH」

医療におけるJUST SYSTEM

ATOK+医学辞書

JUST DWH:

医療向けデータウェアハウス 患者の医療データを二次利用することを目的として作る

訴求シートからカタログへ

訴求シート -> 簡易カタログ -> 営業カタログ -> 本カタログ

訴求シートがあると

  • BtoBでも、仮説に対する解は「現場」にあり

  • ヒアリングを重ね、「訴求シート」を成長

    -> MVP(Mnimum Viable Product)も定まり、作るものに自信がもてる -> 訴求シートは社内のステークホルダーも確認し、社内の方向付け、ビジネス推進にも役立つ

もの書き「一太郎」

一太郎:1985年から開発

  • 警察、学校、役所、企業向け
  • コンシューマ向け

の二種類あるが、今回はコンシューマ向けの話

一太郎で「もの書き向け」に何かできるのではないか、こだわりをもってやりたい

もの書きの流れ

小説執筆・構成
-> 商業作品、電子書籍、公募、同人誌、小説投稿など

Twitterからの気付き

リアルタイムの”ことば”

-> JustSystemにとってTwitterは「感情や要求+具体的な状況を把握する」たからの山

-> プロフィール、利用シーン、何に満足/不満といった情報を取り出す

コンスタントにツイートする層への気付き=もの書き(プロ、アマ問わず

開発コストvsビジネス効果

商業作家向けと考えると市場は小さく、ビジネス的にはいまいち。

しかし作家予備軍・趣味まで広げるといけるかも?と考えた

-> 当たるかもしれない、ならやる!(Just Systemの風土)

同人誌即売会から

コミケにエンジニアが直接足を運んで、活動のポテンシャルを実感

しかし冷静に技術的要件を把握

−> 印刷物やスタイル -> ターゲットの声を直接吸い上げる

コミケはアニメ・漫画が人気だからアニメ・漫画も研究した。

「小説」から

文芸作品・ライトノベル作品の調査
-> 文体に特徴があることがわかった。
-> 新機能として作れるかも?しかしこれはまだ仮説

仮説検証:作家ヒアリング

開発者がプロアマ作家にアプローチし開拓

  • 具体的な質問にする(この文字を入力するときにどうやって入力している?など

    -> 「こだわり」駆動開発へ

物書きさんがほしい機能要件がわかった

まとめ

ターゲットとその要求を理解するために、やれることはすべてやる
-> こだわり駆動開発



02/17 コミュニティとエンジニアの生き方

コミュニティの成長やエンジニアの関わり方の話。

以下、本セッションのメモ。

勉強会、コミュニティの始まりと成長

TickleCode @yoshiii514

Ruby, Swift, WordPressの勉強会主催をしている方。

勉強会を始めた動機

  • プロダクトを作る時間もあって、学んだことを発表して、というような勉強会がなかった
  • もっと自分たちが勉強する場が欲しかった

勉強会運営のコツ

  • 信条を含めた概要書を作る

    -> 勉強会のコンセプト、企画書をしっかりと作って、勉強会が開催されるたびに話した
    • 運営スタッフやスポンサーも全員これを確認する

    -> これがあると、継続して実施しても初心を忘れない

参加者にスポットライトを当てる仕組み

  • 最初にアイスブレークを入れる
    • 名刺交換、自己紹介をすることで参加しやすく
  • 初学者や登壇経験のない人を優先して登壇させる

セッション+もくもく会(自主学習)

  • 発表と自主学習で参加者の満足度も向上
  • 参加者も「自分も発表するかもの緊張感ができる
コミュニティを中心に
  • 転職、案件
  • 出版物、共同開発、講座などを作ることができるようになった。

得たもの

  • 名前を覚えてもらえる
  • 契約金が上がる(フリーランスの契約金が上がった?
  • 出版の話がくる
  • オフ会すると人が集まる
  • スキルアップしやすい

人の話がきけるように 個性が尊重できるように 躍動的になる

Javaコミュニティ作ったら人生変わった

ここから2部

  • 関西Javaエンジニアの会主催

@jyukutyo さん

KanJavaは2ヶ月に1回程度開催

コミュニティの運営

  • 運営に関わろう
  • コミュニティがなければ作ろう

運営はQoELを大きくする

Quality of Engineer Life

エンジニア人生がよくなる!

コミュニティ運営が何を良くする?

  • 自分の変化
  • 仲間の変化

をもたらす。

こうなりたい 人との時間をふやす

運営を通じて、「なりたい人」に触れる
あこがれのエンジニアと話す、触れる機会を作る。

すごい人には普通のこと

  • すごい人がどんな気持ち、とんな思いでやっているのかわかる
  • その人たちの普通に触れることで、自分の”普通”も変化していく

すごい人がやっていたことの登っている山の頂上が見えるようになる

-> 自分もできる、という気持ちになる

運営メンバも変化する

  • 最初はよくいるJavaコーダー

    • 今はメンバが成長して書籍出版したり、海外でのスピーカになったり

会社の仲間は選べない、コミュニティなら技術好きな人たちを獲得できる

コミュニティは”ある”もの?

コミュニティは「参加者」「運営」「スピーカー」で成り立つ

コミュニティは必ずしも継続しない

KanJava参加者500 -> 運営に関わった人10人(2%)だけ。

参加者は「お客様」ではない。これらのコミュニティ、勉強会は貢献で成り立つ。

コミュニティやOSSに対する貢献: 日本は異様に少ない

好きなものに対して「参加者」のままでなく、少しでいいから貢献してみてほしい。

それがコミュニティの継続に繋がる

まとめ

運営にかかわろう、なければ作ろう