Developers Summit 2014の参加記録(前編: 生メモ)では、会場で取っていた自分の生メモをそのままダンプし、
Developers Summit 2014の参加記録(中編: 2月13日整形版)では、1日目(2/13)の内容をまとめた。
この後編では、2日目(2/14)の内容をまとめる。
memo内の #で始まる行は georgenano の感想

[14-A-1]Webの現在過去未来

発表者:
 竹迫 良範 〔サイボウズ・ラボ〕
 宮川 達彦 〔クックパッド〕
 和田 裕介 〔ワディット〕



概要:
Twitter、Facebook。もしくはiPhoneやAndroidなどのモバイルアプリ。多くの裏側はWebの伝統的な技術で支えられています。一方で、Apple App Storeの中でしか公開出来ないiOSのアプリは、果たして「Web的である」と言えるのでしょうか?
「Web的である」とは果たして何でしょうか?BlogやPodcastのようなプラットフォームに依存しないムーブメントから、過去から現在を振り返ることで「Web的」考え方の変遷が見えてきます。
本セッションはWebの技術のみならず「Webっぽさとは何なのか」を、メディア性・開発環境・プラットフォームなど視点から振り返り、これからWebが生み出していくであろう「未来への妄想」をしていこうと思います。

memo:
# 大雪で30分遅刻。。
◯(文脈不明)
・APIを既存のものに揃えると皆に使ってもらいやすくなる
 - ex. Google ReaderはAPIを公開してなかったけど、皆がそれを使うようになった

◯多様なWebサービスのアカウント名問題
・複数のサービスで同じアカウント名を取りたいけど、できないことがある
 - Webの世界では早い者勝ち
・OpenIDならアカウント名問題が解決するかというとそうはいかない
 - Webサービスによって大文字・小文字を区別したりしなかったり問題
 - WebサービスによってHypenとUnderscoreのどちらかを認めない問題

◯個人の認証に関する問題
 - サーバの脆弱性とかではなく、ソーシャルハックでアカウントを奪われた
 - ドメイン管理会社のパスワード管理運用手順が杜撰だった
・E-mailだけで本人確認するのはイマイチ
 - パスポートや携帯電話とかの多段確認がbetter
・iPhoneのCPU(?)にアクセスするためにはAppleIDをもらう必要がある
 - AppleIDを渡すのはさすがに嫌
 - iOSに適切なOAuth的仕組みがあればいいのに、現状ないのはイマイチ
# iOSについて詳しくなくて話が理解できない箇所がでてきた。。

◯MobileWebはHTML5かNativeアプリか?
・最近はNativeアプリが主流
 - Nativeを書けるエンジニアが揃ってきた、SDKも使いやすく進化した
 - パフォーマンスや画面から簡易に起動できることからNativeのほうがメリットが大きい
 - Nativeはマーケットプレイスで課金できるのが強い。ユーザも課金しやすい。

◯マーケットプレイス
・マーケットプレイスができたおかげで個人のソフトでお金を稼げるようになった
 - 今までは個人開発者のマネタイズは広告しかなかったのが、直接課金できるようになった
 - 個人は法人よりもフットワークが軽いというメリットが有る
 - アフィリサイトは本質的なコンテンツとは違うテクニックが必要になるが、マーケットプレイスはコンテンツを磨くだけで良い
・AppStoreは実績重視。Google Playはランキングにランダム性があるようにみえる。
・FlappyBird
 - 2013/05にできたけど、最近ブレークした
 - HTML5版ではさっぱりだったけど、Nativeアプリにしたらバカ売れした
 - 広告料だけでひと月に1億円くらい儲かっているらしい

◯電子書籍出版
・電子書籍出版のメリット
 - AmazonのKindleだと印税70%。通常は30%以下。
 - 以前のKindoleでは1日30冊売ったらランキング1位になった。
 - 直販は自分を知っている人しか売れない
・紙の書籍出版のメリット
 - Amazonの検索で出てこないと買わない人が一定数いる
 - 電子書籍では広告をどうするかが問題
 - 紙の書籍だと書店で露出されるのが広告効果が大きい
・メルマガのメリット
 - 毎週1万文字のメルマガで月840円
 - 電子書籍は専用アプリが必要でユーザの敷居が高いが、メルマガはメールなので敷居が低い
・ニューススタンド
 - 海外ではiOSのニューススタンドが流行っている
 - iOSだけになってしまうのがイマイチ
 - 一方でiOSだと課金しやすいのがメリット

◯Podcast
・Podcastはappleの認証が甘くて、無法地帯
・日本語のPodCastが少なくて、すぐにランキング1位になれる
・PodcastはただのRSS

◯プラットフォームリスク
・プラットフォーム(AppStore、GooglePlay..)が潰れると立ち行かなくなる
・電子書籍もWebっぽくなる
・Gitを使った書籍の執筆・編集

# ゆる~い感じで色々な話題が連続的に出てきて面白かった。
# 自分も電子出版とかにチャレンジしたくなった。
# とりあえずiPadAirにKindleを入れてみた。
# iBooks Authorで執筆してみようかな。


[14-B-L]悩める金融系SEの軌跡~COBOLからScalaへ~

発表者:
 角谷 文康 〔TIS〕


概要:
COBOLを使って基幹系業務を行っていた悩めるSEがモバイル開発研修に抜擢されるまでのストーリーとその後のストーリー。文系(経済学部)卒でCOBOLを使用した開発を行っていたSEが何故、モバイル開発の研修の対象者に選ばれることになったのか。そこに至るまでにどんなアクションを起こしてきたのか。今までやってきたことと、研修でやってみたことの違いなど。理想と現実の狭間で揺れ動き、やってることとやりたいことのギャップに悩む、悩み多き金融系SEの話をします。

memo:
・スフィア大好き!
・釣りです!
# ScalaとCOBOLに釣られてやってきたら、見事に釣りだった。
# ランチのサンドイッチに夢中だった。
# Scalaの話を聞きに来たらリア充の写真を見せつけられたでござる。


[14-D-3]越境する開発 ~あの日開発していたサービスの名前を僕たちはまだ知らない~

発表者:
 市谷 聡啓 〔DevLOVE〕


概要:
ソフトウェア開発のあり方で理想のひとつである「正しいものを正しく作る」にはどのようにすれば向うことができるでしょうか。「正しく作る」ためには、適切なエンジニアリングとともに関係者間それぞれの「期待」をマネジメントし続けることが求められます。また、「正しいもの」を探すためには、プロジェクトに「仮説検証型」「最短距離型」の2つタイプがあり、それぞれのタイプに適したプランニング、プロセス、テクニックを選ぶ必要があるという前提に立たなければなりません。そのため使い分けなければならない道具は多岐にわたります。アジャイル開発やリーン開発、リーンスタートアップ、UXデザインと、開発現場を取り巻くものは百花繚乱です。本セッションでも様々な道具を紹介しますが、大切なのはコンテキストに適切な道具を使い分け、自分たちの手に馴染むやり方を見つけることです。
このセッションでは理論ではなく、実践の話をします。必ずしも成功事例ばかりではありません。手痛い失敗からの強烈なフィードバックを含めて、これまでの私の現場での経験を元に話します。開発現場の理想と現実の狭間で揺れ動く皆さんに向けて、「正しいものを正しく作る」ために辿り着いた「越境する開発」をお伝えします。

memo:
◯アジャイルソフトウェア開発について
・「正しいものを正しく作る」のは難しい
 - 「ダメなものをダメに作る→ダメなものを正しく作る→正しいものを正しく作る」というスッテプを踏もう
・正しいものをどう定義するのか?
 - 誰かが正解を持っているわけではない
 - 正しさは状況が決める

◯正しい作り方について
・期待とリスクを管理するのが大切
 - プロダクトオーナと開発者の双方向で期待とリスクを管理する
 - 目的を明文化し、期待を表明して、相互に理解する
・プロジェクトが進むに連れて管理すべきものも変わる
 - プロジェクト初期は期待管理、後半はリスク管理が重要
 - PMBOKの4版から同じことを言うようになった
 - 開発には期待もリスクもあるから価値がある。管理するのが重要。
・インスペクションデッキは皆でやるべき
 - Why→How→Whatの順で皆で意識を合わせる
・プロジェクトは仮説検証型と最短距離型の2種類がある
・仮説検証型
 - プロジェクト初期
 - 目的実現のための選択肢が色々ある時何を選ぶか思考し検証する
 - 期間契約にする
・最短距離型
 - プロジェクト後半
 - 手段と対象が決まってゴールまで最短距離を走れるようになる
 - 請負契約にできる
・プロジェクトの種類は途中で変わる
 - 境目は分からないので振り返りのタイミングでプロダクトオーナに確認しなければいけない
・スコープ決まってないのに時間決まっているのはヤバイ

◯アジャイルで使えるツール
・リーンキャンパス
 - 企画書の仮説を机上で検証
・エクスペリエンスマップ
 - ユーザの課題が解決できるか検証
・ユーザストーリーマップ
 - ソフトウェアとして必要なストーリーを検証
・カンバン
 - タスク・課題を管理

◯メッセージ
・取引(短期)か関係(長期)か。
・客と開発それぞれの境を越えて行け
・理想とはありたい姿に進み続けることである
・開発とは楽しいもの

# アジャイルで使えるツールを使い出してみようと思った
# 仮説検証型と最短距離型という分類は納得感があった
# 今このプロジェクトはどちらで、管理しなければいけないのは
# 期待なのかリスクなのかを把握しよう


[14-D-4]デベロッパー戦国時代!ストーリーをつなぐ開発環境と3つの秘訣

発表者:
 長沢 智治 〔アトラシアン〕:発表資料


概要:
ソフトウェアの可能性と期待値が飛躍的に向上している最中、開発者の資質が問われています。開発者がもつ本来の可能性を引き出し、よりよい価値を提供し続けるにはつながる開発環境が不可欠です。このセッションでは、開発環境にフォーカスを当てながら開発者をクリエイティブなことに注力するための開発スタイルとそれを支える仕組みについてご紹介します。具体例として Atlassian が提供するツールチェインもご紹介します。

memo:
・統制型マネジメント→自立型マネジメント
・必要なもの:モチベーション、目的、よいものを取り入れる勇気
・大人が変わるには1年以上かかる
 - 周りが変わりたいと思う環境を作るのが重要
・確証バイアスにハマらないようにする
 - 自分の都合の良い事実を重視すること
 - 複数人でやれば抜けられる(ex. プラニングポーカー)
・ソースコードは粒度が細かすぎる
 - タスク・バグとかの粒度が必要
 - 各成果物間のトレーサビリティが重要


[14-A-5]エンジニアだからできる自由な生き方

発表者:
 増井 雄一郎 〔ミイル/トレタ〕:発表資料


概要:
エンジニアとして自由に仕事をして行きたいと思っているひとは多いのではないでしょうか?
どんな自由を得たいの、そのために戦略を持つ必要があるのか、そもそも自由ってなんなのか、一緒に考えてみませんか?

memo:
◯自由とは
・自由には、お金/時間/場所/ルールの4種類がある
・大人になるに連れて年々自由度が増えている
 - 子供の頃は時間にも場所にも縛られていた
・自由とは何か
 - 自由とは自己決定権を持つこと
 - 自分が所属する社会を選択することが自由
 - 自分の人生を自分で決めること
・フリーランスもノマドも自由ではない
 - 時間は自由になるが、仕事の決定権はない
・自分にとって重視したい自由とはなにか?なぜ自由になりたいのか?
 - 全てを選ぶのはできない。自分にとって何が重要かを考える。

◯Connecting the dots
・関係のないもの・経験を線で繋げ
・大きなものを作るには多くのdotsが必要
 - 偏ったdotsでは小さいものしか作れない
 - あちこちに満遍なく多くのdotsを打つべし

◯環境を変える
・自分の自由を価値に繋げて社会に認めてもらう
 - 認めてもらえなければ、認めてもらえる社会を選ぶ
・環境を変える
 - やりたいことを仕事にするように会社に認めてもらう

◯メッセージ
・老いていく自分をメンテするのは自分自身
・リスクを可視化して管理するのが重要
 - 自由に生きるとリスクが可視化されやすい
 - 普通に生きているとリスクが見えにくいだけ
・自分の世界を広げよう。それがdotsをばらまくこと。
 - 言い訳をせずに、小さなことからでも新しいことをやる
・社会に関わって、社会を変えるのが本当の大人だ。
・自由とは闘って勝ち取るものだ。

# 今年のdevsumiで一番感銘を受けたセッション。
# 自由とは何かが腑に落ちた。
# 言い訳をせずに自分の世界を広げる活動をしようと思った。
# その一環がこのブログ。根気よく続けていきたい。


[14-B-6]ソフトウェア工学からコンピューターサイエンスへ - 今後のシステムアーキテクチャーに必要な技術的切り口とその裏側

発表者:
 萩原正義〔日本マイクロソフト〕:発表資料


概要:
今後のシステムアーキテクチャーを支配する新しいルール、考え方を提言します。また、なぜこのような考え方に至ったかの経緯や私自身の経験、これからの技術の方向性を判断するうえで重要となる思考形態を明らかにし、アーキテクトの考え方、仕事の内容をご紹介します。事例として、分散並列処理でのアルゴリズムの正当性、NoSQLの書き込みスループットの高速化など、先端的なテーマも含めます。

memo:
# ソフトウェア工学がdisられるセッションだと思って参戦。

・ソフトウェア技術者には課題が多い
・コンピュータサイエンス(CS)とソフトウェア工学(SE)には違いがある
 - CSは方向性志向、SEは品質志向
 - CSは原理原則、SEはプラクティス
 - SEは仮説検証が軽視されている。工学のレベルに達していない
 - 日本の開発現場はSEに偏りすぎている
 - SEは当たり前のことしか語っていない。CSは新しいことを語る。
 - 両者に共通するのはプログラミング
# 「SEは仮説検証が軽視されている」はカチンときた。
# 定量評価が少ないのは事実だと思うけど、軽視しているのではなく、
# 定量評価するのは難しい問題なので、
# 長年多くのSE研究者に共通課題として捉えられ続けていると思う。

・SEの名著の紹介
 - 実践UML-パターンによる統一プロセスガイド-
 - オブジェクト指向における再利用のためのデザインパターン
 - ソフトウェアアーキテクチャ-ソフトウェア開発のためのパターン体系
 - AWS-CloudDesignPattern
 - ドメイン駆動設計
 - データ中心アプローチによる情報システムの構築
 - アナリシスパターン-再利用可能なオブジェクトモデル
 - 人月の神話
 - リーン・スタートアップ
・SEの名著は日本語に翻訳されている
・CSの名著の紹介
 - Distributed Algorithms
 - The Art of Multiprocessor Programming
 - Distributed Systems Prinsciples and Paradigms
 - Guide to Reliable Distributed Systems
 - Concurrency Control and Recovery in Database Systems
 - Transactional Information Systems
 - プログラミング言語理論への招待
・CSの名著は日本語に翻訳されていないことが多い
 - 部数が少ないので永遠に翻訳されない
# CSに限らず新しい情報は英語しかないのは当たり前なのでは。

・コンピュータサイエンスが主軸
 - CSの進化の上にSEがプラクティスを体系化して提供
# CS→SEの順になるのは同意。
# そもそも他の分野でも「数学→科学→工学」の順番で応用されていくし。
# それがなぜ「CSが主軸」といえるのかは納得できなかった。
# 「皆CSを学びましょう」くらいなら同意できるけど、主軸だと言われてもなぁ。
# それとも「主軸」は「base」という意味だったのだろうか。


[14-B-7]なぜ、システム開発は必ずモメるのか? プロジェクト見積もりから契約作成まで

発表者:
 細川義洋〔東京地方裁判所〕
 山本一郎〔イレギュラーズアンドパートナーズ〕


概要:
完璧なプロジェクト管理を目指しても、起きてしまうのがトラブルです。それも、仕事の受注、見積もり段階で起きる問題から、進捗の管理、知的財産、契約書の揉め事まで、概略を総括します。東京地裁でじかに民事調停に携わる専門家・細川義洋氏と、コンテンツ投資に詳しい山本一郎氏のセッションです。

memo:
# 今年のdevsumiの中で最も面白く、最も闇が深かったセッション。
◯炎上の匂いを感じるキーワード
・追加費用、仕様変更
 - 仕様変更や追加費用が必要になったら、その都度言え
 - 窓口は一本化する
・Q:追加費用の切り出しは難しい。いつ誰がいうのが良いのか。
 - A:銀座や北新地はそういう時のためにある
 - システム開発も根回しと接待が大事。綺麗な体では開発できない。
・Q:プロジェクトの中断はベンダに責任が有ることになったが、切り出せない。
 - A:ベンダが中止の権限があることを認知されていない。
# ベンダ完全に詰んでるじゃないですか。やだーーー

・ITベンダは昔の登山のシェルパみたいなもの。
 - 昔はシェルパも尊敬されていなくて、下山を促しても受け入れられず、デスマ登山で多くのシェルパが命を落とした。
 - 今はシェルパは尊敬されていて、下山の提案は受け入れられる。
 - 今のITベンダは過渡期。尊敬されるシェルパにならなければいけない。
# シェルパの例えは秀逸。非常に分かりやすい。
# ベンダも多くの犠牲を払いながら尊敬を集めるしか無いのか。
# シェルパはどうやって登山家から尊敬を集めることに成功したのだろうか。
# 同じようなことをITベンダは学ばなければいけないのかもしれない。

・Q:ベンダからプロジェクトをやめませんかとはいえない
 - A:契約時に開始基準と中断基準を入れろ
 - SIerは中止条件の基準を知見として盛り込む必要がある。

・Q:中止基準になっても経営層が損害確定を嫌がって圧力をかけてくるのですが。
 - A:現場はそれでも報告を上げ続けて、経営層に正しい判断をしてもらうしかない。
# やっぱり現場詰んでるじゃないですか。やだーーー

・契約書の不備自体はそんなにない
 - 別紙や役割分担が重要。役割分担で「支援」は危険。成果物ベースで決める必要がある。
# 「支援」は危険ワードは覚えておこう。。

・「中国」案件は燃える。天ぷら油並みのすごい火力で燃える。
 - Q:順調に納品して検収まで済んでるのに訴えられるのですが。
 - A:メンツをとても大事にする国民性。とにかく顔を立てるのが重要。
 - この人は凄いと思わせるのも一つの手