@thorikiriのてょりっき

@thorikiriがWebとかAndroidとかの技術ネタや本を読んだブログです

Developers Summit 2012に行ってきました 2日目

2日目も参戦してまいりましたので、メモったことをつらつらと。
感想とかは、後日書こうかなと思います。

17-E-1 エンタープライズシステム開発クラウドの未来 @ayumin

  • 多重請負のウォーターフォールだよね
    • 問題も多くあるけど、恩恵があるのも確かなのね
  • クラウドは?
    • 単なる技術要素じゃなくて、全てを変えるものだ
    • 経済のルールだって変えてしまう
  • salesforceって?
    • 定額で使い続けてくれるので売上は減らない構造
    • ソーシャルエンタープライズとかソーシャルカスタマープロファイルとかが成功してる
  • 常に原点を意識しなさい
    • カスタマーを向いて仕事をする
  • 未来は?
    • クラウドの未来というより、自分の未来
    • 未来を予測する最善の方法は、それを創りだすこと by アラン・ケイ
    • 未来は過去と今の上に積み上げる

スタートアップ Ruby 10章を書いてるそうです。まだAmazonに出てない。右上矢印が目印。

17-D-2 エンタープライズにおけるスマートデバイスアプリ開発の未来 @iphone_business, 苅田氏, @lalha2

  • MIJS立ち上げて色々やってます
    • 日本発の製品を世界へ
  • クライアントサイド
    • スマートデバイス
      • PCから携帯ではメリデメ考えるとダメだった
      • PCからスマホは可能、出来るようになってきた
    • スマートデバイスは2015年にはマジョリティ
      • でも、今からビジネスでガラケー対象って言うのはあり得ない
    • iOSAndroid
      • 世界的には半々くらい
      • 日本だとiOS圧倒的
      • Tabletで言えばiPadがほとんど
      • ビジネスの世界ではiOSなんじゃない?
    • 企画
      • いかにシンプルにするか
      • 高機能でもシンプル、5機能1アプリじゃなくて、5機能5アプリにするとシンプル
    • 設計
      • それぞれのOSのアプリっぽくないとダメ
      • UXをあわせるの重要
    • 開発運用
      • OSのアップデートに同対応するのか
      • アプリのアップデートをどうするのか
      • この2点を考えておかないとダメ
    • プロモーション型
      • 2〜3ヶ月 数100万
    • サービス型:多い
      • 半年〜 数1000万
      • 全機種対応、Androidでコストがかかる
    • エンタープライズ
      • 社内システム連携など幅広い
      • 来期分は今から予算取りされてる、流行るよ!
    • 事例:ビジュアルエイド
      • カタログ見せる用
      • 1個のアプリに見えるけどバックで沢山動いてる
    • 事例:みずほナビ
      • 窓口営業用、金融商品のセールスの人が使う
      • あえてシンプルな飾り気のない見た目にしている
      • 導入前に商品カタログの見た目でカタログを判断していた人がそのまま使えるようにしている
      • 外に持ち出すとデータが消える仕組みにしてる
      • 操作ログで商品の効果測定をしている
    • ポイントは?
      • マルチデバイス対応
      • ネイティブとWebのハイブリット化
      • ソリューション化されるだろう
  • バックエンド
    • 現場の端末をスマートデバイス
      • パイロットもいくつかやらないとダメ
      • 作業指示とか、変更、優先度変更、通知機能
      • 電波状態が悪いときの業務が課題
    • やってみるとミドルウェアが必要になる
    • XMPP
      • Googleの通知するやつ、Androidと親和性が良い
      • Google AppEngineでも使える
      • オンプレミスでも使えるよ
    • 今後
  • キーは?
    • 要求はあれもしたいこれもしたい
      • 単機能でシンプルにすることがポイント
    • サーバサイド技術をどこまで取り込むか
      • PCと同じようなことはできるが、同じではない
    • 予算どりをしてやるぞ!みたいなのもあるが
      • スモールスタートが良い、改善を繰り返す
  • ネイティブかWebか
    • それぞれの向き不向きをわきまえる
    • 自社サービス対応ならネイティブ
    • ちょっとしたものだったらWeb
    • 何が大事なのかを考えよう:優先順位

17-C-3 オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 @kuranuki

  • 2006年のデブサミはXPユーザグループで発表
    • この時宣言したことの成果がようやく実行出来た
  • 経歴?
    • インターネットに魅了されて、これで一生生きて行くと決意 大手SIに入る
    • デスマ三昧、ベンチャーではみんなプログラミング楽しそうにしてたのに、みんな死んだ魚の目
    • 俺がガンダムを一番うまく操縦できるんだ!と思うも挫折、一兵卒で変えるのは無理
    • 勉強しないとと思って、XPを学ぶ。ケントベックの本。これが自分の生きる道なのか
    • 社内勉強会するも賛同者0なので、社外勉強会。
      • 同じ人がいつもいる、みんな意識高い。お酒おいしい。
      • 脳のブレーキを壊すキッカケになった
    • エンジニアからマネージャになった
      • ケントベックの言うとおりやってみた
      • 社内でチャンスをもらえた
      • 新人教育をかってでて、アジャイル教え込んだ。全員じゃないけど、残った。
      • 赤字プロジェクトの火消しに志願した。わらにもすがる気持ちでアジャイル受け入れてくれた
      • うまくいけばヒーロー、ダメなら初めから駄目だったんだからね。
      • 環境をdisるのではなく、活かす
    • プログラマに戻る
      • アジャイルっぽいはディフェンシブだ。何が大切なのか?コストを下げるだけになる
      • SIは保険屋。赤字でも最後までやってくれる。だからデカイとこが勝つ
      • 人月による見積、成果物は納品:矛盾
      • ボンクラ集めて何をするつもりか
    • 社内システムをつくる
  • 思うこと:ゲーミフィケーション
    • 提案ではなくて、相談にすること
    • ショートカットのための肩書き
    • トップから視点と言葉
  • Point of Sales と Point of use
    • 製造業と捉えるかサービス業と捉えるか
    • SIを製造業と考えればしっくりくる
  • リーンソフトウェアビジネスとライフスタイルカンパニー
    • ソフトウェアパートナーシップモデル
      • 受託をする、けど今まで通りではダメ、下請け構造はバッファの積み重ね
      • オーダーメイドだけど納品はしない
      • 月額定額で出来る限りのことをやる
    • クラウド限定
      • 開発と運用を分けたくないから
      • チーム、メンバーを固定した専任とする
      • 今新規事業を始める人達でIT無しはあり得ない、そこをターゲットにする
      • 月額もらい続けるために一生懸命やらざるを得ない
    • クラウドツールを使いまくる
      • 移動は時間もコストも無駄
    • 価値観を変える
      • 継続が大事
      • バグは出さないではなく、すぐになおす。落ちてもすぐ復旧させる
      • 生産性を高めれば、掛け持ちできて、給料沢山貰える
    • クラウドOSSでほぼ人件費だけでいける
    • スタートアップは経験と学びが必要
  • ソフトウェア開発は
    • 属人性のあるものです。ナレッジワーカー。
    • 人を信頼する、小さい組織でやる、個人が見える範囲で。社内も対顧客も。

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

17-B-5 アジャイルマニフェスト ディケイド @kakutani

仮面ライダー

  • アジャイル侍、ジェダイなイメージ。
  • 2001 アジャイルマニュフェスト
  • ハード、ソフト、要素技術の発展が早くなった
  • ケントベック XP 建築からのパターンランゲージ
    • パターン、wiki、XP 少しずつ成長、完成に基づく、繰り返す
  • 行われていないなら正しましょう。
    • 17人のヒーロー!マニュフェスト出来る。
  • 仮面ライダーディケイド
    • カードを使って変身する。カード売れる。すごいビジネスモデル!メタな感じ。
    • 歴代ライダーはそれぞれの世界で生きていて、別の世界だ。
    • ソフトウェアもそんな感じで、視点の違いがある
  • ウォーターフォールは弱りつつある
  • ソフトウェア
    • コード
      • 人とソフトウェアの間に価値がある
      • システム全体で構成される
      • 変更に対応する ・・・からこそ「ソフト」
    • ということで
      • 人が使わないと価値がわからない
      • ハード、ソフト、文書、運用
      • 育てることと、技術的負債の解消
  • 人とソフトの間
    • ソフトウェアはどこにあるのか?頭の中にある。
      • 言われた通り作ってみても、使ってみないとわからない。使って初めて認識される
  • 変更に対応する
    • そういうソフト、アジャイルソフトウェア開発
    • プログラミングとは?文字を並べることじゃない
    • コードはドキュメントである
    • コードにしたことと、コードにしなかったことの分け、それこそがプログラミング
  • 自然なソフトウェア
  • 開発
    • プロセス・・・つまり、実行すること
    • パターンと機能
  • アジャイル
  • スクラム
    • 軽量である、理解が容易、「習得が困難」
  • 繰り返しの問題はある
    • 3回起こればパターン→名前がついて流通
    • でも、名前や手法は万能じゃない。コンテキストが裏にある。
    • 似た状況はあるかも知れないが、同じのはない
  • 朝会パターン:立ってやるだけじゃダメなのよ
    • そのままやってもダメ
    • 何故やるのかを考えないとダメ
    • パッケージは通用しない
  • アジャイル宣言の裏にある原則
    • それを考えよう、スラっと読めちゃうけど、真剣に考え向き合え
  • アジャイルに出来ない理由は沢山ある。それを全部とっぱらった時に、果たして良いものが出来るチカラがあるのか?出来るようになるために
    • コミュニティの一員になる
    • github
  • UnitTest
    • Greenになれば何でも良いわけじゃない
    • それらの目的はなんなのか?それを考えるべきだ。向きあえ。
  • スタート、ゴール、ゴールは次のスタート
    • 考える過程、それを交換するのが大事
    • この先10年続けていければ良い

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

17-D-7 実践Android Developer Testing @ussy00, @mike_neck, @nowsprinting

  • Androidテスト部
    • 発足して1年半
    • 情報共有、情報発信
    • 4月にテスト祭りやります。
    • AndroidのOSのコードネームがお菓子なので、ソースかつチームとハッピーターンチームがある
  • DeveloperTesting
    • V字ModelのUTとITあたり
    • 自動化が前提
      • Drive
      • Judge
      • Report
    • 自動化ツール
      • View系と座標系
    • View系
      • Robotium シナリオに沿って実行する
      • ActivityInstrumenttationTestCase
      • scirocco junitベース
      • NativeDriver junitベース
      • FoneMonkey
    • 座標系 ゲームとかで良いかも、色々捗る
      • monkey runner
      • Monkey
      • SIKULI
  • UT
    • AndroidTestingFramework
    • AndroidMock
  • UIテストの自動化をどう判断するか
    • 有利
      • 実行機会が多い バージョンアップ対応
      • 特殊なテスト:連続タップ、同時タップ、負荷テスト
    • 不利
      • 自動テスト記述にコストがかかる:データの準備とか
      • UIの変更が多い、テストコードが無駄になる
    • 無理なく、計画的にやればいいよ
      • そのかわりUTは厚めにやるべし!バリエーションのテストは下層でやるべき。
  • UTの導入
    • Activityのレガシーコードをテストします。
    • onXxxxにMVCのコードが混在
      • Mはアプリのコアになる部分
    • Android時代の永続化:Activityから分離する
      • Database
      • ネットワーク、SNSとか
      • センサー
    • マイグレーション問題
      • 確認が非常に面倒
      • SQLiteOpenHandlerをDBのバージョンごとに作る
  • 自動化ツール