転職する。

前回の転職から３年とちょっとが経過し、再び転職することになった。来週から働き出す。
転職した。 - seikoudoku2000のブログ

一番のきっかけは↓の孫泰蔵さんのセッションやテレビを見たこと。
デブサミ2013に行った その１ #devsumi - seikoudoku2000のブログ
2013年4月4日放送 モビーダジャパン 社長 孫 泰蔵（そん・たいぞう）氏｜カンブリア宮殿：テレビ東京
所謂スタートアップと呼ばれる所で少数のエンジニアでガリガリとやっていけてるサービスを作ってるみたいな記事や講演をちょいちょい目にしていて、格好いいな〜、いつかそういう所でチャレンジしてみたいな〜という思いは漠然とあった中、その思いがムクムクと膨れ上がってきた。
アジアのベンチャー生態系の中で１エンジニアとして働いていたいなと。あと、もっと年を重ねた後に急にそっち方向に舵をきるというのも難しそうな気がしたので、このタイミングでの転職を決断して転職活動を始め、無事に、ここだ！と思える会社から内定をいただけて今に至る。


転職が決まってから、前回の転職の時と同様、垣根涼介さんの「君たちに明日はない」シリーズを読み返す。初めて読んだ時はそこまで印象に残らなかった、「リヴ・フォー・トゥデイ」が凄くグサッときた。

勝ち逃げの女王: 君たちに明日はない４

勝ち逃げの女王: 君たちに明日はない４

どういうキャリアパスを描きべきとか、どういうスキルを身につけておくべきとか、これを身につけてないとダメだとか、これからの働き方はこうだとか、日常的にそういう本や記事に触れて、あーだこーだと頭で考えて、勿論そういうスパンで物事を考える事も大事なんだろうけど、"今"をおろそかにしていた部分があったんじゃないかなと。特に転職を意識しだしてからはそっち方向に偏りすぎた感があるので、当面はもっと今の一日一日にフォーカスしてやってみようかなと。（そして、その思考の切り替えのおかげか、あんまり次のことは考えすぎずに、有給消化をしっかり楽しめた気がするw。）


あと、ちょっとこじつけかもしれないけど、この登場人物の考え方は最近話題になっているDeNAの南場さんの"コトに向かう！"ってことにもつながっているのかもしれないな〜と思ったり。
Ustream.tv: ユーザー NIKKEI_Japan_Channel: グローバル・ウーマン・リーダーズ・サミット, 米フェイスブック最高執行責任者（COO）シェリル・サンドバーグ氏、ディー・エヌ・エー取締役、ファウンダーの南場智子氏ら、世界を飛び回って活動する女性リーダーが一堂に会し、自らの体験を交え...

不格好経営―チームDeNAの挑戦

不格好経営―チームDeNAの挑戦

そういえば、Jobsのスタンフォードでの名スピーチでもこんな文言もあった。
You can't connect the dots looking forward you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.


あんまり先のことを考えすぎずに、やるべきコトをしっかりと見据えて、毎日しっかりとやりきる。次の職場では、そういうのを意識しつつ、しっかりと働いて楽しめればなと。

ちなみに転職活動中、「不格好経営」に登場するナベさんの会社の日本法人も受けたが落とされた。めちゃくちゃ刺激的な１冊だったので、残念さがちょっと増したw。でも、そのおかげで?、よりいいと思える今回の出会いがあったので、とにかく頑張ろう。

DMM英会話始めました

英語力向上の必要が出てきたので、２ヶ月ほど前からDMM英会話なるものを始めた。特に結論はないけど、当時こんな事を思っていたんだな〜と振り返るためにメモ。

いまから始められる「ネットで英会話」♪オンライン英会話ならDMM.com
f:id:seikoudoku2000:20130706220248g:plain


◎DMM英会話にした理由

  • 比較的新しいサービスなので敷居が低そう。
  • 初月980円 + 最初の更新月は4900円だった。
    • ただ、７月の更新から高くなる(というか通常価格になる)ので悩み中。
  • 国際色豊か。
    • 東欧の国々の人とかブラジル人とか、普通に生きてるとなかなか話す機会は無いよな的な。
  • (元)社会人教師、在宅妻教師もちらほら。
    • 自分のそもそものコミュニケーション能力的に、大学生よりそっちの方が安心できそうww。


◎やっていて思った事

  • とにかく話せない。
    • 嫁からは、「日本人相手でも初めての相手は人見知りして上手く喋れないのに、そりゃ、そうでしょ」というグウの音も出ない指摘を受ける。。が、話せないと困っちゃうのでそうも言ってられない。
    • 英語の記事を初見でそれなりに音読できても、それに対するちょっとした感想ですら言葉に詰まる事が多い。こっちが止まると、当然向こうも喋るのをやめるので、ヒヤリングだけできてもあんまり意味ない。
    • 自分の普段話している/考えている言葉を英語にするという所に注力したほうがいい気がする。
      • 例えば、自分の仕事をITに詳しくない人にどう説明するか？とか。
      • 「村上式シンプル英語勉強法」で紹介されていた、"自分に関していろいろなシナリオに応じての話を100通り用意しておく"、"興味のあることを英語で話せるようにする" って辺りがかなり重要と思った。
  • レッスンするだけで満足しがちw。
    • レッスン中は自然と緊張しているので、それだけで何かを成し遂げた気になってしまう。要注意！復習しないとほぼ何も残らない。
  • でも、復習のやり方がよく分からない。
    • アーティクルレッスンとかであればそれを読み直せばいいけど、上手く喋れなかったこととかは、それ自体が形に残らないので振り返りずらいし、逆に逐一英作文するというもはコスト高くて続かない。
  • 最初の頃は30分くらい前から緊張してPCの前でそわそわww。
    • とりあえず回数重ねることで、ここの苦手意識は克服できた気がする。

引き続き、試行錯誤しながら頑張るのみ。また、何ヶ月かしたらブログに書いてみよう。

村上式シンプル英語勉強法―使える英語を、本気で身につける

村上式シンプル英語勉強法―使える英語を、本気で身につける


サンワサプライ USBヘッドセット MM-HSUSB10SV

サンワサプライ USBヘッドセット MM-HSUSB10SV

AWS Summit Tokyoの１日目に行った #awssummit

AWS Summit Tokyo、１日目だけ参加。
今年が初参加で先日初参加したJAWS DAYS と似たような感じなのかな〜と思っていったのですが、数倍、いや１０倍くらい？の規模だったのでちょっとビックリでした。
JAWS DAYS 2013に行ってきた day1 #jawsdays #jawsug - seikoudoku2000のブログ

以下、メモと感想。
特にテクニカルセッションは、講演だけでは理解できなかった所も多々あったので、復習がてら関係ありそうなリンクをペタペタ貼っといた。
インフラ/ネットワークのことはフワッとしか分かってないな〜というのを痛感したり、Netflixが障害を日常に組み込むために意図的に本番で障害を起こしてるという話を聞いて、言いたいことは分からなくもないけど、、いまいち咀嚼しきれない感じで、自分は守りに入ってしまっているのか？？と自問自答したりw。きっと講演の内容/出てたキーワードをしっかり消化できれば、「月〜木はGame Dayやりましょう」と上長に提案できる男になれるはずなので、もうちょっと頑張って勉強してみる。（おお、そのやり方いけてるからやってみよう！と思った人はどれくらいいるのだろう？？）

資料と動画

ここに一通りアップされている
AWS Summit Tokyo 2013 レポート セッション動画・資料一覧| アマゾン ウェブ サービス（AWS 日本語）

基調講演

いわゆるAWSとは、、 + 事例の話。
その中で、Cycle Computingという会社の偉い人が少し話をしていたのですが、個人的に最近読んだ「ジェノサイド」という小説の世界の話とリンクしていて、ちょっとワクワクしました。webやエンタープライズのシステムをAWSに置き換えるというのは色々と聞くようになってきましたが、こっち方面だとこれからまだまだ未知のことが起きそうだな〜と。全くその世界のことは知らない状態での妄想ですがw
ちなみに↓は「このミステリーが凄い」第１位に輝いた名作で、とても面白かったのでオススメです。
ジェノサイド

  • Cycle Computing
    • AWSのHPCを活用
    • 製薬や遺伝子研究向けのHPCクラウドを提供
      • オンデマンドで調達できるという特性がとても有効。
      • 39年が11時間に！
      • ジェノサイドは進化した人類が新しい薬を開発するためのソフトを作ったり、通信の暗号を解読(膨大な計算が必要)したりという話だったが、HPCがそれを実現するのか？？？、、、(と勝手にドキドキ)

ハイブリッド構成を支えるAWSテクノロジー

  • AWSだけではできないこともある！
    • 片側に今までのDC , 逆側にAWS
  • ハイブリッドのユースケース
    • 開発で使う
    • DRで使う
      • データの同期どうする？
    • アプリケーション単位での順序置き換え
      • 監視とか大変だよ
    • 一つのシステムをハイブリッドに
      • レイテンシ、帯域の問題
  • VPCシステム構築のポイント
    • ネットワーク分割のベストプラクティス
      • ELB, RDS, Elasticacheなど、ログインの必要のないプロダクト用のサブネットを準備する。/22, /24 などで台数を確保できるように。
    • AWSのAPI接続にはインターネット接続が必要なので、DNS経由でアクセス！
    • Direct Connect
      • 自分たちでコントロールできるネットワークを持てる。
  • ファイルコピー
    • S3使おう
      • リージョン確認
      • 数十MB以上ならマルチパート化
      • 並列転送
      • 無駄なオペレーションしない
  • サードパーティーの提供する運用支援サービス
    • 環境構築
      • Puppet, opscode(chef)
    • 監視
      • App Dynamics, new relic
    • ログ蓄積
      • splunk, loggy, treasure data

クラウド利用もハンズ流。POSシステムもAWSで

  • クラウド導入に向けて
    • 「クラウド」じゃなくて、「超可用性データセンター」みたいな名前だったら良かったのに、、
      • 漠然としたものという先入観を持たれてしまう。
    • サービス継続性の話、SLAの話は出るよね。
      • でも、今、御社はどういう数値ですか？と聞くと、大体答えが返ってこないww。
        • 「時々は止まってしまうかな〜」みたいな感じ。
    • イノベーティブな進化があった時に多くの人がネガティブな反応をするのは仕方ない
      • 携帯電話、webメール、（多分データセンターも）も最初は受け入れられなかったが、今は当たり前に業務で使われている。
  • 導入の話
    • 震災を機にDRの観点からAWSの導入を始めた。
    • 無難な所/ぽしゃっても影響ない所から始めるのが定石かもしれないが、それって意味あるの？
      • 最後までやりとげられる？途中でダメになったら二重運用だよ。
    • 基幹を含めた本丸からいく！
      • それがダメだったら撤退する。
      • リーダーがどこまで本気かは言葉で伝わる。それに合わせた結果が部下から上がってくるよ。
  • その他



AWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ

結論：マルチAZがおすすめ。マルチリージョンはとっても難しいから、明確な目的があってどうしても必要な時だけ、制約を理解した上で取り組むべし。

  • リージョンとアベイラビリティーゾーン
    • リージョン > アベイラビリティーゾーン
    • マルチAZはAWSのコアコンセプトの一つ
    • マルチリージョンはAWSのビルディングブロックの範囲外であり、非常に難しい
  • マルチリージョンが必要なユースケース
    • UXの向上
      • データのローカリティの保持
      • Tsunami, Aspera, Cloudpackなど
      • Route53のレイテンシーベースでのルーティング
      • データの近さを意識してアーキテクティング
      • データのリージョン間での受け渡し
      • SQSを使ったpub-sub
    • ディザスタリカバリ
      • AMIやデータをリージョン間でコピー。非常時にはそっちを起動。
      • Route53の重み付け切り替えでフェイルオーバーを容易にできる。
      • AWS内のプロダクトで完結するので比較的やりやすい
    • 非常に高い可用性が必要
      • NASA (GlusterFSをマルチリージョンで使ってる)
      • Netflix
      • Obama For America
  • 合意プロトコル
    • 分散システム内で合意が必要
    • リーダー、マスター選定
    • 分散ロック
    • Paxos, ZooKeeper
    • 耐障害性の維持
      • データセンター間では非同期レプリケーションになる。
      • 同期でやろうとすると、1トランザクション辺り70-80msはかかる。サービスとして厳しい。
      • ここが障害復旧時のリカバリーで難しい所
  • 事例
    • NASA
    • Netflix
      • Cassandraを利用
      • QUORUM(X台以上から応答があった時点で書き込み成功とする) + Geo Replication
        • 難易度が超高い
      • Fail fast & silent
      • Netflix内部のテクノロジーで色々カバーしている。
  • マルチリージョン化のポイント
  • テストどうする
    • GameDay！！
    • 実際の負荷、本番環境
      • ほんとの本番環境
        • このセッションを聞くまで、本番環境相当の環境を準備してやるものと勘違いしてましたが、そうじゃないんですね。すごい&恐ろしい。。
    • Netflix の Chaos Monkey
    • 障害は避けられない。受け入れて日常へ。
    • リカバリーオリエンティドコンピューティングパターン
    • ボーアバグ、ハイゼンバグ


↓も関係してそう。

Tatsuhiko Miyagawa's Podcastを聞いて思ったこと　#bulknews

最近、遅ればせながら話題になってた宮川さんのpodcastを聞いた。
Tatsuhiko Miyagawa's Podcast

第５回のmatzさんとのやり取りの中で、なるほどな〜と思った言葉があったのでメモ。

オープンソースは安定すると死んでしまう。
Javaなどを引き合いに出して安定性云々を言う人は、Java自体にValueを見いだしているのではなく、その上で動くプロダクトにValueを見いだしている。
しかし、Rubyを作っている我々からするとRuby自体がValueなので、そこに安定性を入れることは受け入れられない

というような感じ。

で、ふと思ったのは、巷で、うちの会社では技術が評価されない云々の話をよく聞く気がするけど、状況としてはこれに近いのかな〜と思った。
技術評価してくれ云々の思いの裏にあるのは、技術が会社の利益につながるはずという思い(これがうまく数値化しずらいのも問題)に加え、技術者/エンジニアとしてやっていくには自分を安定させてしまう(=新しいものを取り入れない)と死んでしまうかもしれないという危機感なんじゃないかなと。

従来、新技術の導入にあたってはその技術が会社の利益にどうつながるかというロジックを作るのが一般的でしたが、西條剛央さん曰く「価値は関心に応じて決まる」ということなので、評価する側にエンジニアとして死んでいくということに対することに関心を持ってもらうというのも一つの手段なのかなと思いました。
一方でcookpadのような、なぜそんなバリバリいけるんだ！？と思う会社はそっちのへの関心も強いのかな〜と勝手に思ったり、そういう関心の違いのことを会社のカルチャーと呼ぶのかなと思ったり。

35歳定年説なんてものは信じてませんが、実際近づいてくると色々と考えてしまいます。（まだ数年ありますがww）

構造構成主義 - Wikipedia

JAWS DAYS 2013に行ってきた day1 #jawsdays #jawsug

↓に行ってきました。
JAWS DAYS 2013 | 2013/3/15（金）～16日（土）東京ビッグサイトで開催！
一週間経った今でもちょいちょい思い出すくらいにインパクトの強いイベントだったので、今更感は気にせずにブログ投稿。

ユーストのアーカイブ
jaws daysのメインチャンネル

メインどころはPulblicKeyで素晴らしいレポートがまとめられているので主に感想など。

Obama For America on AWS

これを生で聞けただけでも休暇とっていった価値はあったな〜と。といいつつ、ゲームデイでインフラの手順書作るとかデータセンタ移設を９時間でやったとか、自分の常識とはかけ離れすぎてて逆に中々腹落ちしてきませんでしたが、他の人のtweetを眺めたりPulblicKeyのレポート読みながら復習したりしながら、そういうことか！と後からジワジワときましたw。
あとはAWSの話をした時によく聞く反例として、
・ミッションクリティカルな所はダメでしょ？
・セキュリティ大丈夫なの？
というようなのが自分の周りでは多いですが、
・選挙当日に絶対落ちてはいけないアメリカ大統領選挙選で使われていました。
・1分あたり40万ドルもの寄付を取り扱って問題は起きていないそうです。
・災害に備えたデータセンタ移設が９時間で行えたそうです。
みたいな回答ができるなと。





クラウドファースト時代に求められるシステムインテグレーター像とは？

自分はSI業界で働いているわけではないのですが、とても聞き応えのあるパネルでした。
自分がクラウドってとんでもないものだな〜と初めて感じたのは2010年の楽天techの時の日経コンピュータ中田さんの話を聞いた時だったと記憶していますが、ここで語られていたことがいよいよ広まってきたんだなというのを実感できました。そして、その頃は全く知りませんでしたが、大石さんは2008年から社内サーバ購入禁止令を出していたわけで、自分が海の向こうでえらいことが起こっているようだぞと知識として知った時には、既にそっちに舵をきっていたわけで、あの頃にそういうアクションがとれるってのは凄い行動力だな〜と。
これからの時代に求められるのは「使う技術」って言われても、それだけだとどんどんコモディティ化していきそうだし、これからどうやったら生き残れるんだろうか？という思いが頭を占領して不安になったりしつつ、クラウドという波に早くから乗っていった人たちが今になって花開いているのをみて勇気づけられたりと、自分にとっては大きな問いを投げかけられた気分のセッションでした。まあ、答えなんてないんでしょうがww。

  • 自分のtweet






クラウド時代の個人に必要な変革とは?

いい意味であっちいったりこっちいったりしたので、あんまりメモとかとれなかったですが聞いてて面白かったです。先のセッションとは違ってゆるい感じを保ちつつ、でも凄くコアな話がいっぱい出てました。
印象に残ったのはTreasure Dataの太田さんの「AWS使ってるとこいつらAPIの切り方分かってるな〜と思う」という(若干の上から目線の)発言で、AWSってやっぱイケてるプロダクトなんだな〜というのを改めて感じさせてくれました。

（自分が思ったことなのでこの例が正しいかはよく分からないですが、）最近、↓のような記事が公開されていましたが、
DynamoDBにおけるスループット超過対策 〜 Fallback-Queueingパターン ｜ Developers.IO
これもオープンソースのNoSQL製品を導入しようとすると、ミドルウェアの選定、ハードウェア構成の検討〜購入、パフォーマンステスト、障害時のリカバリー方法の調査等々、それだけで数ヶ月の準備期間が必要そうな所を、
DynamoDBではこれだけお金払えばこれだけのスループットは保証するよ & 他のサービスと併用することでスループット超えた分もリカバーできるという形での提供になっているわけで、目から鱗な感じを味わいました。
一方で、AWSが一人勝ち状態で他のIaaSベンダーはそれに追随している形なのがどうなんだろう？みたいな話も出ていましたが、これは確かにな〜と。ベンダーロックインされないようにオープンソースを使いこなせるようになろう！みたいな所から、やっぱAWSが楽&いいねってなりつつあるような感じもするので、次はどういうトレンドが起きてくるのかな〜と。そういう所をふまえていくと、最終的に古典を読もう！って話につながるのかなとも思ったり。

  • 自分のtweet



LT (一部抜粋)

Redshiftの衝撃・性能は？用途は？Hadoopとの関係は？実際どうなの？ Hapyrus 藤川(@fujibee) さん

RedShiftって言葉だけは知っていつつ、実体はほとんど知らなかったので、短い時間の紹介でしたがかなりイメージは湧きました。一方で、hadoopは既存バッチの置き換えという課題があってある意味分かりやすかったのですが、RedShiftが既存のDWHを1/100のコストで実現できると言われても、既存のDWHを使っていない層(=自分)にはまだピンときづらいものがあるので、その辺の話をもっといい感じにブレイクダウンしたりラップしたりしたプロダクトなりが出てくると、コストの話と合わさってもっとドーンといくんじゃないかなと思ったり。

AWSはとんでもないものを盗んでいきました @shimy_net

アマゾン芸人恐るべし。。ムダに技術を使って面白いことをするというコンセプトは秀逸だなと。
内容もめちゃめちゃ面白かったです。SlideShareのPV数も半端ないですね。
今の所、AWSは仕事での出番はないので、A1グランプリを目標に頑張って勉強していきたいと思いました。



(多分)２日目に続く。

(第０回?)新宿鮫に行ってきた。 #jawsug

Amazon Web Services 勉強会（新宿） on Zusaar
今の所、仕事で導入するあてはないけれど、ただただ面白そうなのと、これからのキャリアプランとか考えると必須のスキルだよな〜という所で、CDP本を買ったりしつつ勉強中な所に見つけたので行ってみました。

ちなみにタイトルの"新宿鮫"というのは、この回の主催者の吉田さんがこれから立ち上げようとしている新宿コミュニティの仮称だそうですが、いい響きだなと思ったのと、普通に今回の資料の先頭に記載してあったので拝借。

最初に感想を書くと、本編の中ではAWSの共有責任モデルの話&コイニーの導入事例が印象に残りました。セキュリティって大丈夫？くらいの認識だったのが申し訳ない感じです。。逆に自分は何でオンプレの方が安全だと思っていたのだろうかと自問自答してしまいました。個人利用では中々気にすることはないですが、会社に導入するとなると必ず話題になるはずなので、聞かれた時用にしっかり勉強しておく必要があるなと。
あとはAWSカルタが面白かった。カルタデータ公開されたら社内の興味ある人と一緒にやってもいいかもしれないww。
懇親会はcloudpackさんのビール奢り(しかも余った分はお土産でいただきました。あざっす！)&500円でピザ。
人数少なめで、素人ながらに吉田さんから色々と聞けてとても勉強になりました。
来る日に向けて、楽しみながら、しっかりと知識を蓄えたり、ちょいちょい使ったりしつつ、時間が合えば新宿鮫にも参加してみたいなと思った次第です。


以下、本編のメモとか資料とか。

趣旨、AWSの概要とか

AWSカルタ





セキュリティに関して

  • 共有責任モデルの採用
    • インフラはAWSが責任を持つ。
    • その上で動くアプリに関してはユーザが責任を持つ。
  • AWSのセキュリティ
    • データセンターの場所は秘密！！
    • 第三者認証。
  • 利用側のセキュリティ

コイニーの導入事例

  • PCI DSS v2.0
    • クレジットカード会社５社が制定したセキュリティ基準
    • アメリカでは結構浸透している。
      • データが漏洩した場合、PCI DSSの運用をちゃんと行っていたことを証明できれば、被害の訴訟を避けることができる(州がある)。これがインセンティブになっている。
  • 登場人物
    • Coiney(サービス提供者)
    • cloudpack(AWS導入支援)
    • Payment Card Forensics(監査会社)





※懇親会で絶賛されてた#devsumiでのサーバーワークス 大石さんの講演資料

Amazon Web Services クラウドデザインパターン 設計ガイド

Amazon Web Services クラウドデザインパターン 設計ガイド


Amazon Web Services クラウドデザインパターン実装ガイド

Amazon Web Services クラウドデザインパターン実装ガイド




2/28 追記：
試しに"新宿鮫"でぐぐった所、大沢 在昌さんのシリーズ小説があることを知った。。

新宿鮫 (光文社文庫)

新宿鮫 (光文社文庫)


毒猿　新宿鮫ＩＩ: 2 (光文社文庫)

毒猿　新宿鮫ＩＩ: 2 (光文社文庫)


屍蘭　新宿鮫ＩＩＩ: 3 (光文社文庫)

屍蘭　新宿鮫ＩＩＩ: 3 (光文社文庫)

デブサミに行った その２ #devsumi

前回のエントリーの続き。

最初２つは言語の話。長年の付き合いのJavaと最近学び始めたRuby。
付き合いの長さ(?)、自分はまだまだJava愛が強いなと感じることができましたww。

Ruby2.0 by Matz

  • ruby 生誕20周年！
    • 1993年2月24日に開発開始
    • 1995年12月21日に公開ver 0.95
    • 1996年12月に1.0
    • 以降順調にバージョンアップを重ねたが、1.8と1.9の間がかなり間が空くようになった。
      • 心理的な障壁。

  • とうとうやってきた2.0
    • RubyConf2001 で始めてruby2に言及
      • 第一回。31人の参加者。
    • 新VM、新GC、埋め込み、ネイティブスレッド
      • 2001年に考えていたことは1.9で実現された

  • 現代のRuby2.0の起源
    • ruby conf2003で言及していたのが最初。
    • 壁を乗り越える要因
      • 20周年！(誰に言われたか忘れたけど、強く後押しされた。)
      • ADD(=Aniversary Driven Development)
      • キーワード引数、メソッドコンビネーション、セレクターネームスペースが2011年位にできあがってきて、いけそうな気がした。


Java! 日本オラクル 寺田さん

寺田さんの話を聞いているうちに自分の中のJava愛が目覚めてきて、普段はあんまりやらないんですが、頑張ってつぶやいてみました。














QA@ITの事例 西村さん

GitHub時代の開発委託とは？ デブサミの資料を公開しました - QA@IT公式ブログ



後半のパネルでメモった内容を補足。


Q.技術的負債、プロト作成について
負債を溜め込んででも開発速度を極限まであげるべきでは？
離陸しなければ、そもそも開発が継続しない。プロトを捨てる必要はあったのか？

A.うらしまさん
ケースバイケース。今回に関していうと、ローンチ = 開発終了というわけではなく、ゴールが明確ではなかった。この状況では、ある程度、きれいなものを積み上げていくしかなかった。
プロトは何を作るかを理解するために作ったもの。三回作れば勝てる仮説。

A.西村さん
テスト無いプロダクトで幸せになった人はいない。 by うらしまさん
(あとからの機能追加がすごく大変。メンテコストが高くなってプロダクトが死んでしまう。)



Q.これって特殊解なんじゃないの？

A.角谷さん
プロジェクトは全て特殊(そうじゃなかったら980円/月とかで提供されるでしょ)だけど、そこは掘り下げずに。
ジム・コブリン：三回起きたらパターン。二回だとcoincidence。一回だとaccident。
今は特殊かもしれないが、そういう潮流は肌感覚として感じている。これからあり得るんじゃないか。


朝のセッションで日本は付加価値をつけるIT投資が苦手だが、そこを伸ばしていかないといけないという話がありましたが、こういう事なのかな〜と思った。SI云々の話はよく聞くけれども、アメリカと比較して日本が全然伸びれていないということは、それだけの伸びしろを秘めてるとも言えなくもないので、逆にチャンスは転がっているんじゃないかと思ったり。
個人的にちょっと気になったのは、西村さんがpull-req送った話や、Github云々の話も多く、ツールにフォーカスあてすぎかなと感じました。本質的/普遍的な言葉で説明がもうちょっとあったら、腹落ちの度合いも増した気がします。
あとは角谷さんの↓がちょっと気になります。。