レッツゴーデベロッパーNextに行って来た

昨日のうちに書こうと思ったけど、不覚にも子供と一緒に寝てしまった。
どれも良い内容でした。個人的には倉貫さんの昔話が今の自分と同じ様な境遇だったのであるあるという感じでよかった。60枚前後のスライドを60分ぐらいの時間でしゃべらなくちゃいけないので超早口でした。

各コミュニティのミニブースというかテーブルがあって、いろいろお話も出来てよかったです。
TDDBC仙台 も開催するということは伝わってて、すくすくスクラムとコラボとかそういう話も聞けてよかったです。

以下は私のメモです。それぞれのユーストへのリンクも貼っておきます。

• スタートアップなら Rails
  • Ustream.tv: ユーザー tohoku-dev: レッツゴーデベロッパー2012 THE NEXT Part001, Recorded on 2012/06/09. コンピュータ
  • 10年前 cgi.rb 使ってた。オレオレフレームワーク化して嫌になった
  • Ruby カンファレンスを見て Rails 以降を決めた
  • 開発時間が1/3になった
  • cgi.rb は本当に辛かった。まじでいやになる
  • Railsの欠点
    • method missing
    • テストが長い
    • 実行速度が遅い（クラウドでカバー）
    • バージョンアップが速すぎる
  • Railsの利点
    • 達人のみができる超短期開発。知らなければ出来ない。
  • You-OKの構成
    • ロードバランサー
    • Webサーバー ^ n
    • memchachd
  • WEBと組み込みを一緒にしたい
  • BegleBone にLinuxが載る。そのままRubyが動く
    • 組み込みRubyいらないんじゃ・・・
  • ライブコーディングは gvim でしたっ。

• 足を使ってリーンUX
  • Ustream.tv: ユーザー tohoku-dev: レッツゴーデベロッパー2012 THE NEXT Part002, Recorded on 2012/06/09. コンピュータ
  • UXの定義
    • ISOの定義はわけわからん！
    • ざっくりいうとUX＝UI
  • 下絵から作ればUXになるか？ならない
    • ５層で構成される
      • Surface Skeleton Structure （Scope Strategy）
      • 魅力がない 使いづらい 使えない （必要ない）
      • 誰も使わないソフトは悲惨
  • その製品は「誰の、どのような問題を」解決するのか？
    • Problem interview
    • いきなりコーディングしない。話を聞く
  • Early adapter
  • Must-have problem
  • 既存代替作・既存製品の把握
  • これは顧客開発プロセスの９つのうち２つ
  • シリコンバレーでは Product/Market Fit が終わった段階で資金を集める
  • Get out of the building
  • 手を動かす前に足を使って仮説を検証する
  • ダメだとおもったら戦略変換するPivot

• 継続的デリバリーが拓く新世紀
  • Ustream.tv: ユーザー tohoku-dev: レッツゴーデベロッパーズ2012 THE NEXT Part003, Recorded on 2012/06/09. コンピュータ
  • 継続的インテグレーションの範囲はビルド・テスト・静的解析まで
  • デリバリーは本番環境までのデプロイを含む
  • とにかく本番環境へのデプロイは大変！
  • ワンクリックデプロイから始める
  • 継続的デリバリーの体験談
    • ステージング環境まではほぼMavenで出来ている。
    • 本番環境へはDBのパスワードをリポジトリに入れるわけにはいかない。
    • DBのスキーマが変更された場合どうするか
  • 日本で多い「受託開発」の案件でも継続的デリバリーを適用できるか？
    • 難しい。政治的な理由で
    • 一括請負な受託開発は納品時の品質が重要なので途中の継続的デリバリー自体が価値がない
  • データ構造（スキーマ）の変化に大して継続的デリバリーするためのベストプラクティスは？
    • Rails は migration
    • DB屋とプログラマーが別チームなので、手動しか無い
  • 結論：人ができることだけ人がやろう

• プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン
  • Ustream.tv: ユーザー tohoku-dev: レッツゴーデベロッパー2012 THE NEXT Part004,
  • どうやってアジャイルを広めたか
    • 新人教育
    • とらぷっているプロジェクトにあえて入る
      • アジャイルプラクティスを実践するがアジャイルと言わない
      • 成功したらアジャイルと言う。失敗したら言わないｗ
  • ガラパゴスなキャリア戦略
    • 自分の置かれている環境を味方につける
    • 自分自身の名前を出す
    • 1000人〜2000人規模の会社でアジャイルしていますとかなかなか居ないんじゃない？
  • ３０歳でチーム解散転職を決意
    • でもキャリア的にSIerでマネージャーでJAVAで次も同じ仕事になってしまう
    • やりたいことをやってみよう。アジャイルとRuby
  • 人月による見積もりと成果物の完成責任
  • オープンソース化に４月決意して１２月
    • 最初マネージャに言うも跳ね返される
    • 段階を踏んでなんとか決済通った
  • 会社で新しいことを導入する
    • 提案ではなく相談
    • ショートカットするための肩書き
    • トップからの視点と言葉
  • 自分戦略についてのふりかえり
    • オーナーシップとスタートアップとビジネスモデルについて
    • 給料を貰っているなら会社はお客さん
    • アジャイル出来ないとかグチグチいうんじゃなくて提案する。
    • 起業するときにビジネスモデル大事
  • どうやって定額サービスをしているか
    • 生産性を高める
    • ドキュメントを作らない
    • 移動しない
    • 営業しない