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

【13-A-1】クラウドがもたらした多様な破壊と創造

発表者:
 新野 淳一 〔Publickey〕
 玉川 憲 〔アマゾンデータサービスジャパン〕:発表資料
 長谷川 秀樹 〔東急ハンズ/ハンズラボ〕
 大石 良 〔サーバーワークス〕:発表資料
 三村 真宗 〔コンカー〕
 仲 暁子 〔ウォンテッドリー〕
 佐俣 奈緒子 〔コイニー〕
 吉田 浩一郎 〔クラウドワークス〕


概要:
クラウドの登場のお陰で、新規事業を始めるしきい値が下がった今、あちらこちらで社内スタートアップを含めて、新たなチャレンジが起こっています。ただし、破壊の速度を加速することが、産業の活性化やエンジニアリングの多様性を産み、豊かなエコシステムのある社会を作れる可能性がある一方で、、日本の現状を見ると、ややもすると破壊と創造をやっている業種や企業がソーシャルゲーム業界だけに開発者には見えてしまっているのではないかと思われます。
本企画は、新たに破壊と創造を事業のミッションに据えて世の中と勝負されている経営者の方に登壇いただき、お送りいたします。

memo:
【新野さん】
◯テーマ
・クラウドがもたらす変化、破壊、創造するものは何か
◯変化するもの
・クラウドがもたらす変化とは、即時性・自動化・低価格である
◯破壊するもの
・従来型のSIが破壊された
 - オラクルでは受注単価が2桁下がった
 - 売上を維持すために短期間で今までと同じ仕事をこなして、数をこなすことでカバー
 - 受注単価が下がったのでこれまでの大型案件を中小SIerができるように
# 単価が「2桁」下がるのヤバイ。
# 2桁カバーしたということは100倍の案件をこなすってこと?中の人ヤバイ。
# いくら自動化が進んだからといって本当にできるのだろうか。
# とはいえ、オンプレで構築するよりは圧倒的に楽だからできるのか。
# すげー世界になってるな。。
# そもそもそんなに案件とれるの?需要あるの?そこがビジネス的には一番の問題な気がする。
# 中小SIerが手がけられるようになったというよりも、大手SIerが儲からなくて撤退していった(or 撤退していく)というのが正しいのかもしれない。
 
・労働集約的なシステム運用が破壊される
 - システム運用の担当者は減り、ソフトウェアの知識が必要になる
 - 運用もChefを使った自動化になるので、運用もプログラミングになる
・ソフトはオンプレミス・パッケージソフトからクラウドサービスに
 - 例:MSのOfficeもソフトから、Office365というクラウドサービスに
◯創造するもの
・マーケットプレイス化
 - 今までは出向いてサポートしなければならず、場所に縛られていた
 - これからはサポートやメンテナンスが、場所から自由になる
# 「サポートやメンテンナンスが場所に縛られている」 という発想はなかった。
# 確かにこれは凄い変化だと思う
 
・ビッグデータの活用
・マルチデバイス展開
・活発なコミュニティによる個人の成長
 - クラウド技術は多数存在し変化も激しいので社内に有識者が居ないのが当然
 - 社外のコミュニティで学ばなければいけない
 - 社外で活躍することで個人が成長する
# なるほどと思わされる論理構成
# 社外のコミュニティに出なければいけないと強く思わされた

【玉川さん】
・「10年後に何が変わっているか」と聞かれて「10年経っても変わらないもののほうが大事」
# 痺れるメッセージ。思わずメモに赤線引くくらい。
 
・Amazonが考えるお客様が求める「10年たっても変わらないもの」
 - 低価格、フレキシビリティ、イノベーション
 - 例1:申請ベースでしか使えないスパコン → C3インスタンス
 - 例2:はじめるのに数億円必要なDWH → Amazon RedShift
・日本のITは2つに別れた
 - Information Technology:大資本・高品質・高可用性・高コスト
 - Internet Technology:高成長率・新技術・スピード重視・低コスト
# どちらが良いという話はでなかったけど、Internet Technologyの考えが有効な場合って多いよな。。
# うちの会社は、というよりもSIerは高品質・高可用性を重視しすぎている気がする
# 業務やお客様によってはスピード重視・低コストが求められることも多いのに。

【長谷川さん】
・Accentureから現職へ
 - ベーマガのソースを打ち込むくらいプログラム好き
・破壊したいもの: 企業の情シスと企業向けSIer
 - 既存のITは紙を電子化するだけで、おもろない
 - 業務の効率化はできるけど、売上には貢献していない
・高品質さを求めるのに、システムが落ちるよりも入力ミスの方が多い
・企業の情シスは自前で開発すべき。うちでもそうやってる。

【大石さん】
・(開発に)時間のかかる旧来型SIを破壊したい
・スピードという評価軸を加えるとオンプレよりもクラウドが選択されるはず
 - 例:手紙と電話
 - コストとか専門家のヘルプだと手紙が勝つが、スピードという軸なら電話が圧勝
 - 業務的に求められるのは圧倒的にスピード
# 先ほどの玉川さんと同じ論陣。スピード重視の世界があるといっている。
・非常に小さいチームで素早いデリバリー、つくらない技術が重要

【三村さん】
# 記憶が無い。。
# なんか最後のデモムービーが長かった記憶しかない

【仲さん】
Wantedlyというソーシャルな転職仲介サービス
・年収ではなく一緒に働きたいか、何をやりたいかで、転職を仲介する
# とりあえず登録してみた
# でも友人が誰もやってないから全く役立たない。。
# コレ皆やってたら面白そうなんだけどな。
# まずはそういう友人を作るところからということか。

【佐俣さん】
Coineyというスマフォに刺すとクレジット決済端末にできるHWとサービス提供
・日本の決済のルールを変えるのが目的
・ハードウェアを作るのは、ルールを変えるのに比べたら簡単
・既存のルールを変えるのが難しい
# これは需要ありそうなサービス
# 目的も大きいが共感できる。頑張って欲しい。
# HW作るのは敷居が高そうだと思うけど、それをさらっとやっているのが凄い
# さらに「それよりも既存のルールを変えるのが難しい」というのが含蓄深い

【吉田さん】
・世界の流れは「所有→借りる→時間貸し」
 - 例: 不動産、サーバ
 - 労働力も同じ。正社員→派遣社員→クラウドソーシング
・価格は原価に紐付けられなくなってきた
・今後は皆から共感を得ることがモノづくりの未来に
 - 多数の個人が共感で労働を結集させると仕事ができる
・貨幣経済から共感経済に
# 「共感経済」に共感はできるけど、それでどうやってご飯を食べるかが問題。
# Facebookの「いいね」を100万集めるとそれでどうやってご飯が食べられるのか。
# いつの日かそういう未来が来るといいなと思うけど、どうやるのだろうか。
# その方法の検討を自分の個人バックログのひとつに積もうとおもう。


[13-B-L]テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする

発表者:
 安竹 由起夫 〔コベリティジャパン〕


概要:
コベリティの静的解析は、数多くの開発現場で導入されテスト工程の手戻り作業を削減してきました。クリーンなコードはテストを円滑に実施していくうえで既に必須条件となっています。では、開発マネージャ、開発組織は次に何を目指すべきでしょうか。
本セッションでは「テスト自動化」に焦点をあて、開発チームの利益を拡大するために、いつ、どこを自動化すべきなのか、自動化作業をサポートするツールを含めご紹介します。

memo:
・本当に自動化は必要か
 - 同じテストを4回やったらツールに費用も含めてpayする
# 逆に言うと4回もやらない一発コードは自動化する必要はないということか
# システム更改時のデータ移行ツールとかはいらないということかな
# それ以外の状況の場合は、大概4回以上はテストする気がするな
 - 修正担当者が決まらないと不具合が修正されるまで30%遅い
  - 伊原, 大平, 松本, "不具合管理システム利用時の不具合修正プロセス改善のための滞留時間 分析手法の提案," 情報処理学会 マルチメディア,分散,協調とモバイル (DICOMO2009) シンポジウム論文集, pp. 1221--1227, 2009年7月.
# なんかの論文書くときに参考になりそうメモ
・可視化の対象の一つに「バグが見つかってから修正されるまでの日数」
 - Linuxでやったところ、100日から10日まで減少できた
# 減少した結果どうだったのか(ユーザからの不満が減ったとか、品質が上がったとか)が語られておらず片手落ち感あり
・テストの自動化をどう評価するか
 - コールグラフ+条件分岐からカバレッジ100%となるテストの数は分かる
 - デッドコードや非到達コードがあるため、カバレッジ100%は目指す意味が無い
 - コピペ時の変数名の書き換えミスを検出できる
・追加するテストの優先度を付与できるか
 - ビジネス的な優先度でやる
 - 新しいコードに対するテストを優先すると効率が良い
・クリーンなコードになっているか
 - コーディングするときには、ユニットテストを書く
 - 最新状態でCIする
EZSourceというCOBOLの静的解析をやっている会社がある


[13-B-3]社内システムの構造と設計、実装のはなし

発表者:
 田籠 聡 〔LINE〕:発表資料


概要:
自分たちが使うシステムを自分たちのために自分たちで作るとき、それがどのような構造のものであるべきか、どのように設計をすると良いのか、実装をどこから進めればいいのか、といった内容について自分の知見からお話しできればと思っています。社内システムと題していますが、もちろんそのようなシステムに特徴的なことが他のコンピュータシステムと大きく変わるわけではない、ということについても改めて議論したいと思います。

memo:
◯社内システムほど他システムとの連携を考えよう
・権限の分断を最小限に
・情報の参照方法は複数あったほうが良い
 - ブラウザ、テキスト、JSON...
 - 社内システムのUIでも外向きのAPIを使うようにすべき
・モジュール化
 - 単機能を連携させる
 - 単機能ならアップデートが容易
# このへんの考え方は関数型プログラミングに通ずるものがあるな
・他システムとの連携を考えて機能をAPIとして公開しよう
 - そのシステムの更新も容易になる
・APIの互換性を考えよう
 - プロトコル(SSH、FTP...)
 - データ構造(リスト、ハッシュ...)
 - 意味の一貫性(OKとSuccessを混同しない)
 - クライアント要件の不変性(クライアントに依存しない)
・ドキュメントは人に頼ること。人に頼らない方法を考えよう。

◯社内システムではJSON APIを使おう
・おすすめのプロトコル
 - HTTP & JSON
 - データの中身を見やすい、アップデートしやすい、テストしやすい
 - アップデートするためには「見れば分かる」状態を保つ

◯実装は必要なところから必要なだけやろう
・社内システムは動くことが重要
・機能を細かく切り刻む
 - 細かければ優先度をつけやすい
・修正単位を最小化する
 - 欲しくなった時にすぐリリースできるからやらなくても怖くない
・要件定義は難しい。必要なときに必要な分だけやろう。
・アーキテクチャはシンブルにして割り切る


[13-A-6]Mobageを支えるテストエンジニアリング

発表者:
 中川勝樹〔ディー・エヌ・エー〕:発表資料


概要:
Mobageプラットフォーム開発では、主にテストを担当するソフトウェアエンジニア (=テストエンジニア)を開発チームの中に置いて、技術的アプローチでテスト自動化を進めながら、スピード感を持って品質保証するという、エンジニアリングとしてのテスト(Software Engineer in Test, SWET) を実現しています。本セッションでは、普段私達がどのような技術を使ってSWETを体現しているか、およびどうしてSWETが必要だったのか、といった点を事例ベースにお話する予定です。

memo:
・SWETグループというのを立ち上げた
・立ち上げの方針:
 - End-to-Endテストを確立する
 - テストを自動化する
 - テストしやすい環境を提供する
・独立したチームにすることで、横串チームによる戦略的展開を狙った
・GoogleはSET(Software Engineer in Test)
 - SETは開発者に着目
 - TE(Test Engineer)は品質に着目
・MicrosoftはSDET(Software Design Engineer in Test)
・DeNAはSWET(SoftWare Engineer in Test)
 - SWET = SET + TE
 - Not a tester but a test engineer
・ホワイトボックステスト、ブラックボックステストの他にグレイボックステストを行っている
 - グレイボックステスト:テスト時にDBやCacheの値を手動で直接いじるテスト
# グレイボックステストの名前付けに違和感
# ホワイト/ブラックボックステストはテストケースを作成する技法だと思っているのだけれど
# このグレイボックステストって「テスト実行時に前提条件をどう準備するか」の手法の一つ
# なだけでテストケースの作成技法じゃないんじゃない?
# そもそもGray Box Testingの定義はSoftware Testing Fundamentalsによると
# 「内部構造を部分的に知っている状態で行うブラックボックス」(georgenano意訳)
# とあるので一般的な用語の使い方でもないようにみえる
# もしかすると正しい意味でやってるのかもしれないけど、説明が異なってきこえた