Developers Summit 2012 Day2に参加してきた #devsumi

勉強会


(写真：目黒雅叙園内/目黒駅からエスカレーター経由で目黒雅叙園に行き着いた先から見た風景)



去年の話〜参加申込に至る部分は以下のエントリを参照。

そしてTogetterまとめ周りに関する部分は以下のエントリを参照。

一日目(2012/02/16)に関する部分は以下のエントリを参照。

前日に引き続きこの日もデブサミ2012に参加してきました。

この日参加するセッション及び関連イベントは以下の通り。前日が予想以上にハードだったので若干緩やかなスケジューリングに変更しております。

10:00〜10:50 [Web Technology]            (参加せず)
11:10〜11:55 [開発プロセス]             【17-C-2】10年後も通用する開発環境の秘訣 〜 継続的フィードバックとVisual Studio 11 / 長沢 智治 氏
12:00〜13:00                             ＜昼食：日本鼻メガネの会メンバーによるランチ＞
13:10〜14:00 [10th Special]             【17-B-3】言語の世界 / まつもと ゆきひろ 氏
14:20〜15:05 [開発プロセス]              (参加せず)
15:25〜16:15 [Mobile Technology]        【17-D-5】Java/Android セキュアコーディング入門 / 久保 正樹 氏
16:35〜17:20 [Special]                  【17-C-6】ライターズ・フィロソフィー―IT業界で書いて食っていくひとたちの哲学をきこう（仮）
                                         新野 淳一 氏 / 西村 賢 氏 / 毛利 勝久 氏 / 五味 明子 氏 / 小泉 真由子 氏
17:40〜19:10 [Special]                  (参加せず)
20:00〜　　　　　　　　　　　　 　　 　　＜日本鼻メガネの会メンバーで軽く打ち上げ＞

会場は前日同様目黒雅叙園＠目黒。

前日の目黒駅との往復により、ご多分に漏れず若干足もも裏が疲労感に苛まれたので(笑)何か良い回避策はないものかと思案していたところ、某所から有力な情報を入手。

勉強会レポートの前に、まずは目黒駅からの比較的楽ちんなルートの実践確認から。

目黒駅〜目黒雅叙園(エスカレーター経由)

通常まっすぐ降りて坂を下るところを、『香港園』が見えるところのT字路を左へ。

しばらく直進の後、ここの建物の路地を右に。

奥に突き進み、コンビニを左手側に直進。

後は道なりに、指示通りに進めば雅叙園に辿り着きます。

通常通り坂を上り下りし、会場内に入ってもしばし歩かなければならない事を考えるとだいぶショートカットになりますし、何より足腰が楽ちんです(笑)

皆さんもまた今後目黒雅叙園に来るような事がある場合は、こちらからのルートでの来訪をお試しになってみてはいかがでしょうか。

午前の部

本当であれば朝イチの川口さんセッションに参戦する予定だったのですが、交通事情等もあり若干遅刻してしまい、前日までの疲れもあったので諦める事に。到着後はしばしラウンジにて休憩＆ネット作業をしておりました。

11:10〜11:55 [開発プロセス]【17-C-2】10年後も通用する開発環境の秘訣 〜 継続的フィードバックとVisual Studio 11

長沢 智治 氏 (TwitterID:@tomohn)

10年前からALMが注目され、継続的デリバリーが実現できるまで成熟してきました。
ビジネスを加速させるアジャイルな取り組みがツールを活用して実現できる世界になりました。

ただし、これは欧米の話です。日本ではようやくSCMやBTS、継続的インテグレーションが注目されている状況です。
このセッションでは、価値の流れを絶やさない継続的フィードバックの必然性を最先端の開発環境である
次期バージョンVisual Studio 11のコンセプトを題材にしてみていきます。

ツール紹介セッションではありませんのでVisual Studioの使用有無にかかわらずご参加ください。
  • 自己紹介
    • このセッションで気になったことは是非連絡ください。
    • 色々なコミュニティに参加しています。
    • E-Agility（協議会）4/11に何かイベントをやるらしいです。
  • Takeaway Declining(はじめに)
    • 現場の解はチームで見つけてください。
    • 講演を是非俯瞰してお聴きください。
    • VisualStudio11のコンセプトをお伝えします。
  • You Size？
    • チーム単位　7人
    • 部門単位　4000人
    • が開発に携わっている。
    • 更にピラミッドを拡げて行くと…2,000,000,000人！[利用ユーザ数] この辺を意識していかないと行けなくなるかも。
  • Traditional Planning
    • ある程度の時間を掛けて価値を提供する
    • →範囲を特定すると、時間に対する価値の提供度合が異なる。ここを改善する必要がある。
    • 最大のパフォーマンスを出し続けるには…
    • アジリティ・アジャイルはまさにこれ。短い時間で適切なものを提供する。
    • 価値の頭打ちを打破し、ソフトウェアの価値を最大化
    • 継続的に価値を提供し続け、ビジネスを牽引出来るようになる。
  • ふりかえり：ビジネス×IT…Value Up(MSから前々から言っているフレーズ)
    • 便利
      • ビジネスと非同期/固まった要求/十分な時間
    • 有効
      • ビジネス課題の克服/要求は変わる/QCDの明大
    • 不可欠
      • ビジネスを加速/アジリティへの対応/just-in-timeなデリバリー
    • このときの開発の現場はどうなのか？
      • 90年代　デベロッパー主役　開発環境
      • 00年代　開発者＋開発チーム、テストツールや管理ツール等
      • 10年代　開発チーム＋運用チーム＋ユーザ…ビジネスそのものが主役、ツールは個別→ALMをサポートするツールに意識が変わる。
  • プレイヤー
    • 開発者、テスター、アーキテクト、マネージャー / "I am done."
    • ↓
    • PO、開発チーム、ユーザー、利害関係者 / "We are done."
  • 開発（Development）
    • Reduce Waste/Technical Debut
    • 無理ムダを極力高める努力を
    • どのロールの人達も価値を生み出す流れを考えていかなければならない
  • 動くソフトウェアを提供し続けるとは
    • 開発者はすぐに対応して価値を提供してくれる、とお客さんは思っている
    • でも単純な話ではない
    • フィードバックのサイクルが無数にある。それを回していくことによってデリバーされる
    • 幾つあって、どこがどう回しているのかを意識していく必要がある。でないと『継続的デリバリー』になっていかない。
    • →されていないと、I am doneのままである。
    • フィードバックの連鎖：継続的デリバリー
    • 開発ツールの話
      • 緑色の箱（要素）
      • 使っているもの、使っていないもの。
      • 開発、テスター、管理の視点のみでは届かない。
      • →じゃあ全部やりましょう！でもやるのは凄く大変。
    • Artifacts Driven Tools→Work Driven Tools
  • Visual Studio 2010 Case Study
    • これで実現出来ている。
    • Team Foundation Server
    • 様々なOSS、3rd Partyのツールと連携可能。
    • 後ろから支える感じのイメージ：価値を回すサイクルを。
    • 例：継続的インテグレーション
      • Gated Checkinの機能で、不具合のあるコードをコミットさせない。無かったことにする。
      • 人の作業を邪魔しない環境を構築している。
    • 例：テスター＆デベロッパーの間
      • バグのピンポン状態
      • テスターの裏に膨大なバグ情報がある
      • →バグの情報に、実際に行った作業の情報を提供している。ビデオなども！
      • 自分達の見やすい方法でアクセス・提供してくれる。
    • 例：テスターによるテストを開発者テストで活用
      • テストと開発の確認を早める事が出来る
  • 2010-2011へ。
    • 継続的デリバリーから継続的フィードバックへ。
    • アプリケーションの全ライフサイクルを全て管理してあらゆるフィードバックを返せるように
    • 運用：
      • DevOps
      • 障害発生：インシデント発行
      • これからは：あらゆる運用を自動化してスピードアップする事が出来る
      • System Center Orchestrator 20122
      • 何でも自動化してしまうことが出来る。
    • 開発：
      • ユーザのフィードバックは大切。
      • ストーリーボード
      • パワポでUI等のパーツ的なものを作る、用意する事も出来る。
      • フィードバックマネージャー
      • スクリーンショットやメモも簡単に取れる。
      • サブミットするとTFSに全部蓄積される。
      • Webだろうが何だろうが、情報として見ることが出来る。
      • バックログの管理：非常に直感的に行える。
      • ※ツールで出来ることが、結構増えてきている。
      • デベロッパー：非常に忙しい。色んな情報を見なきゃならん。
        • 肝になるのは、重要な作業をこなしているデベロッパー。
      • Team Explorer / MY Work
      • 刷新。My Work：今行っている作業の一覧が見える。
      • ペンディングしたい作業を棚上げしておく事が出来る。
      • やりたい事駆動で切り替えが簡単に出来る。
    • テスト
      • Unit Test Explorer
        • コードを書いている最中でも自動でテストを実行してくれる。
        • 行った操作・ログを全部捕っておいてくれている。
  • まとめ
    • 是非継続的デリバリーだけでなく、フィードバック、ビジネスを回すと言うところまで意識してください。
    • ツールを活用しない手はない。それだけ進化している。
    • VisualStudioはその点かなり成熟している。
    • イベント各種参加しています。
    • 2/20 ms.com.japanを見てね！

昼食

前日同様、日本鼻メガネの会メンツで付近の社食に。この日は何だかんだで総勢11名の大所帯となりました。そして半数の6人がカレーという偏りっぷり。

午後の部

13:10〜14:00 [10th Special]【17-B-3】言語の世界
プログラミング言語の奥深い世界を眺めます。「あなたはこのトークについていけるか？！」
  • 自己紹介
    • Rubyを作った人です
    • ホントにマニアックな話ばかりします。明日の仕事に役立たないかも（笑）
    • 言語マニア、言語オタク
    • 未来の話、未来に向けて言語がどうなるか
  • FORTRAN(1954)
    • FORmula TRANslator　の略。
    • それ以前のコンピュータはアセンブラ
    • コンピュータに数式みたいなのが書ける、というのは画期的。
    • 人間が分かる言語で記述出来る…人工知能と見なされていた
    • 人間のため：数式でプログラムできるよう
      • 人間が楽をする為にプログラムしても良いんじゃないか。
    • ループアンローリング
    • ベクトル化
    • 背景：コンピュータが遅かった。
      • スーパーコンピュータとiPhone4の性能が同じ。
    • 背景：『言語の常識』がまだなかった
  • LISP（1958）
    • List Processor
    • 人間のため；数学的背景からスタート
    • ラムダ計算
    • 機械のため
      • IBM704計算機
    • 人間のため：ガーベージコレクター
    • 人間のため：Lispプログラマは値は何でも知っているが、コストについては何も知らない
    • 漁夫の利
    • LISPへの揺り戻し
  • どうせ既存の言語の組み合わせさ…
    • そうは言っても、人気の言語はそれなりに新しい
  • 新しい？
    • とはいっても10年、20年
  • 新しい言語の動機
    • 作りたかったから
    • 新しいパラダイム
    • 新しい環境
    • 新しい制約
    • 言語を作りたい：そう思う人が多いと思っていた。
    • 5〜10人に一人くらいはいると思っていた…

  • 新しいパラダイム
    • ここ20年位登場してないなぁ
    • 既存のパラダイムの組み合わせ
    • バランスの良い組み合わせは難しい
  • 新しい環境
    • 新しいOS
    • 新しいCPU
    • 新しいアプリケーション
  • 新しい制約
    • CPU数
    • メモリ量
    • データ量
    • アクセス量

  • 温故知新
    • 歴史の振り子
      • 集中vs分散
      • 性能vs生産性
      • 静的vs動的
      • 正確さvs柔軟さ
  • 言語の楽しさ
    • プログラミングの楽しさ
      • 自分の思った通りに動く。
      • 言語実装＝プログラミング総合芸術
      • 言語設計＝プログラミング
      • 言語設計＝発想をプログラミング
    • We Program you!
      • 米国戦争時の？
    • enjoy programming!

まつもと氏の冒頭の宣言通り、本当にマニアックな内容ばかりでした(笑)そして最後の下り(We Program you!)で、人の意志を操っているところに喜びを見出している(Rubyを使わせている＝Rubyにその人を染めている、的なニュアンスで)、的なコメントを残されたのが印象に残りました。なかなかこうしてMatzさんの姿を見ることは出来ないと思うので、貴重な体験でした。

14:20〜15:05 (休憩)

この時間についても、本来の予定ではDeNAのスクラム導入事例に関するセッションに参加する方向でしたが、想像以上の開始前の行列に比較的早く心が折れ(笑)この時間帯も休憩に充てました。

前日から通して会場内をゆっくり見て回ると言うこともそんなになかったので、適当にぶらぶらしつつ時間を過ごしてました。

忍者さんが居たり、オープンセッションが開催されていたり、様々な書籍が販売されていたり。

後は様々なコミュニティの方々がブースを出しており、多いに盛り上がっておりました。

15:25〜16:15 [Mobile Technology]【17-D-5】Java/Android セキュアコーディング入門
情報家電やスマートフォンまたそれらの上で稼動するアプリの脆弱性を狙った攻撃が増加する昨今、
製品の利用者を守るためには、製品開発の段階での脆弱性対策が求められます。

プログラミング言語に潜在するセキュリティ上の問題を理解し適切なコーディングを行うことで、
製品の脆弱性を低減しセキュリティを強化できます。

本セッションでは、ソフトウェア開発において脆弱性の混入を防ぎ品質向上に寄与するセキュアコーディングについて、
Java言語に焦点をあて、Androidアプリ開発でのポイントなどを織り交ぜてご紹介します。
  • 自己紹介

Javaセキュアコーディングスタンダード CERT/ Oracle版

Javaセキュアコーディングスタンダード CERT/ Oracle版

  • 今日お話すること：モバイルアプリをとりまくセキュリティ問題
  • Android/Javaのセキュリティのヘッドライン
    • スマホを狙ったワンクリックウェアを確認
    • Android端末を狙う不正プログラム、2012年末までに12万個に？
    • SMS詐欺に利用される偽のAndroidマーケットが再登場
    • プラットフォーム、マルウェアの話題が後を絶たない
    • マルウェアに狙われたアンドロイド
      • モバイルマルウェアの63％がアンドロイド狙い
      • アプリを改竄して配布
      • 目的はお金

    • モバイル端末に対する脅威
      • 成熟度の異なるプラットフォーム
      • ユースケース、利用パターンの複雑化
        • 従来のウェブアプリと異なる
      • アプリ単体だけで考えていてはだめ
    • モバイルアプリのトップ10リスク（ドラフト：OWASP）
      • M1：危険なデータ保存
      • M2：不十分なサーバ側のコントロール
      • M3：トランスポート層の保護が不十分
      • M4：クライアントサイドインジェクション
      • M5：お粗末な認証・認可の実装
      • M6：セッション管理不備
      • M7：信頼できない入力に基づいたセキュリティ上の判断
      • M8：サイドチャンネルでの情報漏洩
      • M9：暗号化メカニズムの欠陥
      • M10：センシティブな情報の漏洩
  • モバイルアプリの脆弱性
    • TencentQQPhotoのパスワードハッシュ漏洩
    • Kaixin001のコンタクトと平文パスワードを読まれる問題
    • 360 MobileSafeのSMSメッセージを読まれる問題
    • 基本的な間違いが繰り返されている…

    • アンドロイドという新しいプラットフォーム
      • アプリ250億ダウンロード（2011）
      • 大きなマーケットシェア＋金銭的価値＝攻撃
    • 繰り返される過去の過ち
      • 暗号化鍵のハードコーディング：42％
      • 乱数のエントロピー不足：61％
      • センシティブな情報の外部送信：39％
      • エラーメッセージにセンシティブな情報：6％
    • 数年前のウェブアプリ脆弱性のデジャヴ
    • プログラマが知らない
      • 古い脆弱性が新しい脆弱性
      • プラットフォームが成熟過程
      • 新たな脅威・攻撃手法が日々発見される世の中。
        • 経験年数が物を言わない
      • サプライチェーン
        • 知っている（分かっている）けどできない！
  • 何を知らないのが問題？
    • １．言語非依存のセキュアコーディング
    • ２．Java言語特有のセキュアコーディング
    • ３．APIやプラットフォーム固有のセキュアコーディング
    • セキュアコーディング
    • プログラム上のある種の欠陥が脆弱性を生む
      • 仕様・デザインの欠陥
      • コーディングエラー
      • パターンがある
    • セキュアコーディングとは
  • ＜事例1.言語非依存の〜＞
    • 最近JVNで発生したStrutsの脆弱性
    • 入力値検査
    • ファイル名やファイルパスにはASCII文字セットのみを仕様
    • FIleI/O、NW I/Oの両端で互換性のある文字エンコーディングを行う
  • ＜２．Java言語特有のセキュアコーディング＞
    • サブクラスの依存性を保つ
      • Java.security.ProviderとHashtableクラスに関するバグ
      • セキュリティチェックを行わないentrySet()を使ってしまった。
      • スーパークラスに変更を加える場合（コードの保守時）、サブクラスの不変条件が侵害されないよう考慮する
        • 本来存在すべきセキュリティチェックが回避され…
    • ボクシングとアンボクシングに注意
    • 条件演算子『？：』
      • 型の評価は結構複雑
    • Java/Androidでも整数オーバーフロー
      • long幅にキャストして演算する
  • ＜３．APIやプラットフォーム固有のセキュアコーディング＞
  • セキュアコーディングの実践
    • Java/Androidプログラマに求められる資質
      • Javaセキュアコーディング CERT/Oracle版
        • (コード解析ツールでサポート)
        • 1.言語被依存の注意点
        • 2.Java言語特有の注意点

＋

      • コーディングスタンダードを活用するメリット
        • Java言語自体の理解が深まる
          • コード例に学ぶ
          • コード保守の負荷低減、品質安定、レビュー短縮
    • 宣伝１：
    • 宣伝２：
      • jpscert 出張セミナーやってます
16:35〜17:20 [Special]【17-C-6】ライターズ・フィロソフィー―IT業界で書いて食っていくひとたちの哲学をきこう（仮）
「デベロッパーズ・メディア・サミット」ふたたび！今年は、IT業界の中で「書く」ことを仕事にしている人たちに集まっていただき、
今、業界とどう向き合い、メディアを作り上げているのかといった大きな問題から、どのツールで書くのがいちばんはかどるかといった
小さな問題まで、各人のフィロソフィーを語っていただきます。
  • 小泉氏
    • ライターズフィロソフィー、書く事でお仕事している人達に集まってもらいました。
    • 10周年、10年の間にメディアも変化。書く事についても同様。
    • 思ったよりもじもじ(文字文字)している
    • 映像が発達すると思ってたのに（某氏）
    • やたらと10年でテキストを書くようになった
    • 意見、反論もある
    • ブログ、Twitter、情報発信
    • プロ／アマ関係無い。
    • メディアが特別じゃ無くなってくる？
    • 『マスゴミ』等と叩かれる対象にはなるけれど…
    • 我々編集者も『これでいいのか？』と。
    • IT業界で書いて食ってる人達に聞いてみる。
  • 自己紹介LT：
  • ＜五味氏＞
    • 【あるひ突然クビになっても路頭に迷わない為に】
    • 技術者の方々でも突然クビになる可能性も
    • 自分の身に起こるかもしれません
    • 経験談が少しでもお役に立てば。
    • フリーランスライター＆エディタ
    • 翔泳社『DB Online』キュレーター
    • その他エンタープライズIT
    • フリーランスになったきっかけ
      • 3月一杯で辞めてくれ
      • 2011年3月震災２〜３日前退職勧告
      • 大地震
      • しばらくひきこもる
      • 4月からフリーランス
      • 今は法人化してオフィスも構えている
    • フリーランスとしてやっていくために必要なちから
      • 1.社会人としての力
      • 2.ゆるく繋がる力
      • 3.仕事を断る力
    • 最後に
      • クビになることは辛い。
      • あなたが会社や上司、組織の事を嫌いならば、相手側も間違いなく嫌っています
      • なので早めに自分の方から嫌な環境を抜け出す具体的な準備をすべし。
      • 会社の外でも通用しない、と言っている人は会社の中でも通用していないはず
  • ＜毛利氏＞
    • 【わたしの自分戦略 2012 春】
    • もともとイベント主催、翔泳社の書籍の編集をやっていた

だれが「音楽」を殺すのか? (NT2X)

だれが「音楽」を殺すのか? (NT2X)

    • 食えてない：朝起きれてないので。
    • 45歳、フリーランスの編集者です
    • 大学はまつもとさんと同じです。
      • 主にfj.*というところを読み書きしながら編集していた。
    • 今は本の編集などを。
    • 首尾一貫した人生、人生成り行き
    • 書籍にフォーカス

いますぐはじめる　Facebookナビ

いますぐはじめる　Facebookナビ

    • Facebook会の津田枠を狙っています
  • ＜西村氏＞
    • IT系媒体の過去未来とある編集記者の過去未来
    • 自己紹介
      • IT系の記者・編集者
      • 学生時代にはじめたバイトからそのままパソコン雑誌スタッフに
      • ピーク時：40し位雑誌が出ていた
      • 2000年頃から急速に市場が…
      • シュリンク：俺の人生も…
      • そうだ、エンタープライズ！
      • @ITへ転職
      • まつもとさん、面白い！2007年の記事
      • この辺から狂ってきた、技術系に
      • ソフトウェアエンジニアリングの黄金時代がくる！
      • 一方、従来型メディア市場はシュリンク中
      • 逆に台頭してるのは
        • 少人数によるブログメディア（Publickeyなど）
        • サービスでレバレッジを効かせるメディア
      • メディア＝容れ物＋コンテンツ
        • ↓：紙媒体(写植、DTP)
        • ↓：web媒体(HTML)
        • ↓：Webサイト運営(P言語+DB)
        • ↓：Webサービス(WAF:例えばRails)
        • ↓：Webコンテンツ時代？(ECMA6+HTML5)
      • 2つの仮説とその帰結
        • メディアでもサービスが重要になる
        • コードの読み書きができないのはダメ？
      • プログラミングをやるようになる
      • Railsでサービスを作ってみた

      • 会社でも『サービス作らせろ』と騒ぐ
        • →Asakura.rbの皆さん、一緒にやりませんか？となる
        • で、今は会社で新規サービス開発プロジェクトをやっています。
          • Qatmarkit（仮）prototype
      • サービス＋メディアの可能性
  • ＜新野氏＞
    • publickeyの中の人

    • ITジャーナリスト
    • @it、年間売り上げ10億円らしい
    • 自己紹介
    • 2000年、株式会社アットマーク・アイティ
      • 資本金3000万円
      • サーバ、回線、その他
      • 雑誌を立ち上げるより簡単
      • 社員10人位
      • 編集スタッフ2人＋α
      • 2006年、米国でブログメディアブーム
        • ブログ出もメディアが成り立つのか！
        • サーバも年間数万円で借りられるし、個人でメディアができるはずだ。
      • 2007年IPO、2008年アイティメディア退社
      • 2009年PublicKey開始
      • 2011年 Publickey売り上げ報告
      • なぜブログでメディア？
        • 既存のメディアはコストが掛かりすぎている
        • 優秀な人が組織を離れてメディアで生活できるようになったら、もっと多様性が実現する
        • 小さなメディアの可能性を広げていきたい

と、ここまでで自己紹介LT完了。次いで前以て用意されていた質問に各者が応えます。

  • (Q).自己プロデュース、していますか？
    • (新野氏)何で自己プロデュースが必要か？
      • itmedia立ち上げ当初、オンラインメディアは呼んでもらえなかった
      • 呼んで貰うまでに3〜4年かかった
      • メディアそのものの存在感を示すのは大変
      • 今は細分化
        • メディアの組織の中の人であっても、この人に書いて貰いたい！というのが多い
      • ブログが認知されたのと同様ににいのさん個人も認知されるようになってきた
      • それがメディアの中の人にも…
      • セルフブランディングが大事になってきている
    • (西村氏)
      • アスキーは割と自分で書く人が多かった。私は書きたい方だった。黒子でもなかった
      • 別にbyNameで仕事をしたいという訳でもない
      • でも今はbyNameで仕事をとる時代（にいのさん）
      • 実際ブログでセルフプロデュース
      • 会社としてスキルスタンダードを示すようになってきた
      • ちゃんと自分の意見を言える記者を育てたい
    • (毛利氏)
    • (五味氏)
      • 会社を辞めるようになってから、twを中心にIT系情報を書くようになった

ここで時間がほぼ無い事が判明。その他にはこんな質問も用意されていました。

  • (Q).情報源として重視しているものはなんですか？
  • (Q).記事を書くときの環境を教えてください。オフィスありますか？スタバ？道具は
  • (Q).今後の情報発信はどうなる？雑誌とかWebとか…

そして最後に用意されていた質問に各者が簡単に応える形でセッションは終了。

  • (Q).今後の俺たちはどうなる？
    • (新野氏)
      • 読者の方々が元気であってほしい。ライターはフリーで良いじゃん。
      • 専門職を社内で育てるのは大変。
      • みんなフリーランスでも生きていけるように頑張ろうよ。
    • (西村氏)
      • ここ数年で面白かった：シリコンバレーでの事
      • TechCrunch羨ましい、スタートアップメディアもどんどん出て来て欲しい
      • 10年やると形になる：英語もしゃべれるように
      • やって悪いことはなにもない、
      • 書いて食っていくか・・ソフトウェア作りにのめり込んで…
      • 今は会社から見ると何やってんだと思われてるかも知れない
      • 今は弓を引いて力を溜めている状態？
    • (毛利氏)
      • ものすごいノープランです。
      • 今年2011年に悔いがある事があった
        • ruby会議
          • 岩切さんに『もうり〜ｔｗ！東北でハッカソンやるから来てよ！』
          • 行きたいのはあるけれど…
          • 取材になのかなと思った･･最終的に諦めた
          • ust見ながら『俺は行かなきゃいけなかったな〜』
            • 現場に居ないと分からない事がある
            • 現場感がない
            • 震災復興のハッカソン/その時の無念さがまだ残っている
      • 10年後もリアルな場に居たい。
    • (五味氏)
      • ITが10年後に無くなることはない
      • ITを仕事に
      • 皆さんが活躍出来るように情報発信できれば。
17:40〜18:30 (休憩)

この時間帯も、予定ではAndroid Testingに参加する方向だったのですが変更して休憩に。1階の喫茶店でしばし寛ぎ、終了まで会話を楽しんでおりました。

19:30〜 懇親会(軽めの打ち上げ) at 日本鼻メガネの会

本編終了を待って、参加希望者を募りつつ目黒界隈にて軽く打ち上げ。計6人が参加しました。


16日(デブサミ1日目)、17日(デブサミ2日目)、18日(StartupGroovy)と3日間同じ日程の人も多く、その辺についての過ごし方のお話とか、急速に人数が増えている会の今後についてのお話とか、次回以降の会開催内容についての割とこれまでに無いアイデアについて話してみたりとか、毎度の様に内容の濃いトークが続いておりました。


デブサミについては今回の2012が初参加ですが、いや〜これは内容・密度共にかなり濃いイベントですね。次回以降も都合が合えば是非参加してみたいですが、そんな中でも幾つか改善されると嬉しいなぁ〜と思う点も。

  • ネット環境：2日目はそうでも無かったけど、初日の回線の繋がらなさには参った。会場自体の環境の都合もあると思うけど、もう少し快適になるとよりつぶやきやネットアクセスも増え、盛り上がりやすくなるのではなかろうか。
  • お昼休みについて：各間の休憩時間(20分)は妥当な長さだと思うが、昼休みの時間(60分)はもう少し長くしても良いのかな〜とは思った(例えば90分)、あれだけの人数が大移動して、場合によっては少し遠出して昼飯を食べに行くとなると、行って食べて戻ってで60分では少々厳しいのでは無かろうか。あと単純に疲労感もあると思うので休息自体も長くなると嬉しいかも。
  • Togetterについて：来年はどうなると良いのかな〜？ある程度の時間的余裕と人数が居ればそこまで大変でも無いというのが掴めたので、同じ手法するにしても有志で参加しやすくなると思うし、別の方法でもより良い方法があれば是非採り上げてもらって、当日来れない人やふりかえりに使いたい人の為になって欲しいと思います。


最後に、デブサミ2012に関わられた全ての皆様、ありがとうございました！


その他関連：

  • ブログレポート