『DevLOVE 今、未来に繋がるために帆を立てるとき。』(デブサミ2011再演)に参加してきた

勉強会 

◆横を縦に！デブサミ2011の再演◆ 
2011/2/17〜18に目黒雅叙園で開催されたDevelopers Summit 2011 
（通称：デブサミ2011）4トラックが同時併催で走るセッションの中で 
最も、受講者の方がどのセッションを選択するか迷った、 
2/18の朝一番のセッション4つを、スピーカーのみなさま、会場を 
提供してくださる楽天さまのお陰で、DevLOVEが横並びから 
縦並びへ転換し、再演いたします

上記こくちーずページからの抜粋。ichitani (TwitterID:@papanda)さんによるDevLoveの説明、今回の勉強会に至る経緯等のトークの後、4本立てで開催始まりました。

ちなみに開催会場であった楽天タワー2号館内の開催会場はめちゃめちゃ広かったです。定員200名でしたがキャパ的には全然それ以上、1000人は余裕で収容出来る広さでした。ちょっとした野球が出来る位(笑)

『再演』という事で、2011年02月に開催された各セッションの資料やブログエントリ・まとめ等も各所で展開されています。このエントリでもそれら過去の資料・情報を展開しつつ触れていこうかと思います。


まずは『デブサミ2011』自体の纏めページ各種。


そして、セッション別の関連資料、開催時個人メモ等は以下へ。

これからのRIAの話をしよう 〜システムの利用者と開発者にやさしいUXとUI設計について〜

講演動画


関連情報@デブサミ2011
関連書籍

上記嵩原さんのブログで紹介されていた書籍各種。

使いやすいソフトウェア―より良いユーザインタフェースの設計を目指して

使いやすいソフトウェア―より良いユーザインタフェースの設計を目指して

デザインのためのデザイン

デザインのためのデザイン

ソフトウェアユーザーエクスペリエンス設計 (MSDNプログラミングシリーズ)

ソフトウェアユーザーエクスペリエンス設計 (MSDNプログラミングシリーズ)

インタラクションデザインの教科書 (DESIGN IT! BOOKS)

インタラクションデザインの教科書 (DESIGN IT! BOOKS)

ウェブ戦略としての「ユーザーエクスペリエンス」―5つの段階で考えるユーザー中心デザイン (Web designing books)

ウェブ戦略としての「ユーザーエクスペリエンス」―5つの段階で考えるユーザー中心デザイン (Web designing books)

プロジェクトコスト見積もり入門

プロジェクトコスト見積もり入門

これからの「正義」の話をしよう――いまを生き延びるための哲学

これからの「正義」の話をしよう――いまを生き延びるための哲学

ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト

ペルソナ作って、それからどうするの? ユーザー中心デザインで作るWebサイト

検索と発見のためのデザイン ―エクスペリエンスの未来へ

検索と発見のためのデザイン ―エクスペリエンスの未来へ

ソフトウェア品質知識体系ガイド―SQuBOK Guide

ソフトウェア品質知識体系ガイド―SQuBOK Guide

ソフトウェア開発へのSWEBOKの適用

ソフトウェア開発へのSWEBOKの適用

IA100 ?ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計

IA100 ?ユーザーエクスペリエンスデザインのための情報アーキテクチャ設計

個人メモ
  • スライドは220枚越え。2011/02/18講演では自重してやらなかった部分も紹介。
  • RIAという言葉が出て来て5〜6年経った
    • User Experience Designの説明：ユーザーがある製品やシステムを使ったときに得られる経験や満足などを指す言葉
    • 喜ばしいもの：User Experience Designの領域。ある領域に対して明確に作り込まれるモノ
    • ウェブ戦略としてのユーザエクスペリエンス
    • 5S：Strategy(戦略)の所が重要。
      • [具体的]Surface:表層
      • ↑ 　Skelton:骨格
      • ｜ 　Structure:構造
      • ↓ 　Scope:要件
      • [抽象的]Strategy:戦略
    • 『アクセス』：助力や指示なしで使えるものでなくてはならない。
    • 『支援』：より易しく、より単純に、より早く、楽しく。
    • 同じ機能を提供する場合、そんなに幾つも方法を提案する必要は無い(悪例：Wordのフォント設定手順)
    • 概念的過ぎるし、考える事が多すぎる。どうしたら良いか？
    • 指針はシンプルに。『早く』『間違わない』
    • ユーザビリティに関する工数・手間は、掛けた工数分良くなる位程度でOK(あんまりゴリゴリ工数掛けても無駄)
    • UXデザイナ…現状日本にはあまり居ない。育ててください！
    • クロスブラウザの問題は残る
      • テスト(環境種類別)の手間
      • 開発期間＋稼働期間
    • Adobe AIRとクロスドメイン…システムフロントエンドをAIRで作成、AIRアプリをハブとする事でユーザに意識させる事無くシステムの変更・拡張が可能(となりうる）
    • 使う人、作る人、人が大事。
  • プロセス
    • アジャイルであるべきか？
      • UXを取り入れたRIA開発ではコンセプト・採用した技術は変えられない為、難しい側面も
    • UP：統一プロセスが良さげ？
    • RIA,UXは検証要素が多い：必然的にアジャイルに
    • アジャイルは請負契約と相性が悪い？
    • テクノロジーや手法が進化するのなら、契約形態も進化する必要がある！
    • 良いデザインを褒めてください
    • 悪いものほど記憶に残る
    • 良い噂：3人、悪い噂：50人に広まる
    • 意識しないで扱える良いモノは記憶に残らない
    • 正しい行動パターン
      • 1.考える
      • 2.実行する
      • 3.確認する
    • 良いモノを意識して褒めること。
    • IT為す術無し？
    • ITは無力なのか？
    • 情報の扱い方を、非ITな方達へ
    • 使いやすいソフトウェア
      • 『助力や指示無しに使えるもので無くてはならない』･･･限度がある
      • 道具の用途が何たるかを理解しない人には意味が無い
      • ツールだけでは何も解決しない
      • 知るだけで済む話は一杯ある
      • 少しずつ教える
      • ITで出来る事を最大限にする


個人的には今Flex/ActionScript/Javaな現場での仕事をしていて、Android(Java/AIR/Web[HTML/CSS/Javascript])にも手を付けようとしている所なので興味深い内容でありました。

AIRは作る方の手間軽減・使う方の教育コスト等を考えると現状かなりの効率化を見込めるテクノロジーなのですねぇ。

UI・デザインについても以前書籍を幾つか購入したまま積読状態。体系的に情報を整理して勉強する機会を持ちたいところです。


なぜソフトウェアアーキテクトが必要なのか〜未知なるソフトウェアに形を与えよ〜

講演動画


関連情報@デブサミ2011
再演資料 #devLove0423
個人メモ
  • <ソフトウェアとは何か>
    • 利用時：使う人によって品質の捉え方が違う。
    • 外部・振る舞い…仕様書上のテスト
    • 内部品質・構造…ソースコードそのもの
    • プロセス行動：内部品質を作る為のコード（を書くところ）

    • システム
      • ミッションを持っている、何らかの制約・環境下にある
      • システムに関わる利害関係者（ユーザ、システム部、社長、株主／アーキテクチャ、プログラマ、設計者、運用者）は関心事を持っている
      • 利害関係者の関心事、それぞれの立場からビューとを持っている、モデルによって記述される
    • 色々な事を考えた結果の構造。
    • マネジメントとは何か
    • PMBOK
      • 計画を立てて、実行して、調整していく事を定義している。
    • なぜPMは記事になるのか？
      • 『危機を救うヒーローだから』
      • ※そもそも危機になるのがいけないんじゃ･･･
    • アジャイルマネジメント：『変化ヲ抱擁セヨ』
    • 基本手法
      • イテレーティブなタイムボックス管理
        • 完成していなくても棚卸しを評価
      • リスク手動
        • 不確定な部分から手を付ける。
        • プロトタイピング、継続的統合（CI）
    • アジャイルの考え方
      • ズレを許容しながら、正しさを探索するテクニック
    • アジャイルを機能させるためには
      • 機能の分割と実施淳がそれなりに正しい
      • 不確定な部分を上手く取り出す
    • 全体の計画は正しく無くても良いが、正しさを見つけるプロセスはきちんと決める必要がある
    • ユーザとアーキテクト
      • 越えられない壁の部分を『DDD』で補う
      • DDD：使うことと作ることを繋ぐ手法の1つ
      • 暇なドメインエキスパート（＝重要ではない）には注意しろ
      • Eric Evans(DDD提唱者)：その場でモデルを考えて、ユーザに提示・セッション
      • Eric Evansの提唱する渦巻きモデル(whirlpool)
    • 周辺トピックス
      • BCP（事業継続性計画）
      • DR（災害時復旧）
      • 省電力
      • クラウドへの興味
    • 質に対する考え方の変化
      • 専用線の復旧が一番遅れた
      • 完璧なBCP/DRは有り得ない…完璧ではなく最適な対応を考える
      • これまでとは違う価値観の提示…慣性力に逆らう必要がある
    • アーキテクトの在り方
      • アーキテクチャは全ての要素から客観的
      • アーキテクトは全ての要素を客観視する(神の視座)
      • デザインの中心は、システムでも人でもなく、自らの思いであることに自覚的でいたい
    • 『デザインとは色や形ではなく、人の世界観を拡げる仕事でしょう？』by 西村佳哲

ここで、休憩中の合間時間を使って『エリック・エヴァンスのドメイン駆動設計』の翻訳をなされた和智 右桂(TwitterID:@digitalsoul0124)さんが登場(今回は1参加者として来訪されていた)。今話題のDDD本についての簡単な紹介をされていました。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

鈴木雄介さんのセッション内で登場した『Eric Evansの提唱する渦巻きモデル(whirlpool)』については、日本語訳の許可を求めたのですが『まだDraft段階なので1.0まで待ってて』との事らしいです。日本語訳はもう少し間が空きそうですが、楽しみですね。


プログラマが知るべき、たったひとつの大事なことがら

講演動画


関連情報@デブサミ2011
個人メモ
  • 依頼を受けて、若干(この講演をやるかどうか)悩んだらしい(※再びやるとは思ってなかったので)
  • 97きのこ本(ハッシュタグ #97prog_ja)

プログラマが知るべき97のこと

プログラマが知るべき97のこと

    • セッションのお題としては悩ましい(書いている人・中身バラバラなので)
    • でっちあげた概略→要約すると『何か話します』
  • 『自分』の話をすればよい。という結論に。※本については本を読めば分かる。
  • きのこ本で一番大事なきのこは『きのこ18：学び続ける姿勢』(独断)。
  • なぜ私がここにいるのか：これまでの道程を話します。
  • 今日話す3つのこと：明確に、それぞれの間に忘れられない出来事があった。
    • 読む(read)
    • 書く(write)
    • 話す(talk)
  • 2000年
    • OO厨をこじらせ、結局体力任せの仕事
    • 完璧主義の呪いにハマる

達人プログラマー―システム開発の職人から名匠への道

達人プログラマー―システム開発の職人から名匠への道

  • 作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/11
  • メディア: 単行本
  • 購入: 42人 クリック: 1,099回
  • この商品を含むブログ (347件) を見る

    • プロジェクト
      • 『全開でやってよし』の契約依頼内容
      • お客さんがXPをやってみたかった、との事でオーダーからしてXP盛り込みまくりの内容
    • J02：ロールプレイングゲーム
      • 理想のプログラマを演じてしまう
      • だって仕事でしょ？
      • 色々な良いプラクティスを実施
        • きのこ54『見えないものを見えるように』
        • きのこ80『1人より2人』
        • きのこ65『バージョン管理システムを有効に使う』
        • きのこ79『テストのないソフトウェア開発はあり得ない』
        • きのこ51『プロジェクト自身にしゃべらせる』
    • 常に自分よりレベルの高い人と仕事をするようにする
    • 自分の良き師になり得る人をネット上で探す
    • 自分が学びたいことを人に教えたり
  • 2005/04/25
    • 福知山線の事故、まさーるさんが乗っていた…
    • まさーるさんから教えてもらった事を引き継がなければならない
    • →『話す』時代へ
    • テストの再分類/TDDのサイクル
    • TDDを使った議論、啓蒙を始める
    • 黄金の回転 by jojo
    • アウトプットするとインプットが増える
    • インプットは更なるアウトプットへ
    • WEB+DBプレス　テスト駆動開発

WEB+DB PRESS Vol.35

WEB+DB PRESS Vol.35

    • 渦を作る時代：influence
      • 現実と立ち向かう術
      • ペアプロの楽しさ
      • プロとしてのたしなみ
      • それらを伝えるイベントを作れないか
      • TDD Boot Camp 東京
      • 渦が出来た。
      • TDD Boot Camp今後の実施予定：札幌第2回→大阪→横浜（秋頃）→四国→東京（第2回）
  • 最後に
    • 学び続けるコツ
      • 身の回りをプログラミングする(※googleでやってるプレゼンツールを改善している)
      • 毎年新しい言語を学ぶ（達人プログラマ）　仕事とは関係ない。
      • 手段の目的化は是である（自分周り範囲内であれば）
    • 若い人から学ぶ
      • 一生プログラマーでいれるかどうかは、言い換えれば年下から学べるか否か。
    • 技術の学びは『らせん』
    • なぜTDDにこだわるのか
      • 自分自身から改革していくには『一人ではじめる』
    • TDDはスキルです
      • 才能ではなく、習得可能です／量は質に転化します／写経しましょう！
    • 渦に入り、渦を作る
    • 次はあなたの番。渦を作る人間になって欲しい。


和田さんのセッションについては、デブサミ2011でのスライドを事前に拝見していたのですが、リアルで目にするとやはり深み・感銘の度合いが違ってきますね…。まさーるさんとの出会い→別れの流れの部分は、和田さん自身も『再び感情が揺れた』と振り返るように聴いていて来るものがありました。

TDD Boot Campについては、今後も各所で展開されていくようなので楽しみです。TDD周辺スキルについては自主トレを重ねて、機会があれば参加してみたいなと思いました。


ハッカー中心の企業文化を日本に根付かせる

講演動画


関連情報@デブサミ2011
再演資料 #devLove0423
個人メモ
  • ゴール
    • 自分が素晴らしいと思っていること（企業文化など）を紹介する
    • どうしたらよいか、考えるきっかけを
    • 技術者が豊かで生き生きとした社会を作る為にはどうしたら良いか
  • 3.11の震災が私たちにどのような意味があったのかを考えたい
  • 楽天イーグルスの開幕戦がNY Timesの1面を飾った。何かが変わったと実感。
  • 勉強会勉強会 6月予定
  • debug hacks 共著者。
  • 情報処理2011 vol.52
    • 全国技術系勉強会マップ:技術者のライブセッションに参加しよう
  • わたしのエンジニアリング人生に影響を与えたDECの文化を紹介。
    • ミッドナイトプロジェクト（スカンクワークス）
    • 社内コンピュータネットワーク
    • 情報共有
  • 未開の文明ではなく、コンピュータ業界のソフトウェア開発現場もフィールドワーク
  • 組織文化は、外からは良く分かんない（中の人以外には知りようが無い）
  • その文化では当たり前の事を記述する
  • 勉強会を当たり前だと思っている。
    • それは何なのか
  • （民俗学）明示的に伝える努力をしよう。
  • dec - digital equipment corp(会社はもう無い)
  • DECのエンジニアリング文化
    • ミッドナイトプロジェクト（スカンクワークス）
      • 業務説明
      • 何か面白いことやってんの？
  • 社内のコンピュータネットワーク
    • 全てのコンピュータが1つのネットワークで結合していた
    • 情報共有が勝手に始まる
    • ありとあらゆる事が議論されていた
  • 統制の手法
    • 強制的統制
    • 功利的統制
    • 規範的統制
  • すぐれた民族史
    • 超マシン誕生

超マシン誕生 新訳・新装版

超マシン誕生 新訳・新装版

}

闘うプログラマー 上巻

闘うプログラマー 上巻

iモード事件

iモード事件

  • ハッカーって
    • コンピュータ技術に精通した人（辞書的な定義）
    • ちょっとした技巧（ハック）を操るひと
    • 社会を変えた人（なんでもかんでもハッカー？）
  • 行動するエンジニアになりたかった
  • ハッカー
    • 共通の価値観
    • 企業文化
    • どう根付かせるか
  • 共通の価値観
    • コンピュータによって社会を良くする
    • 管理より自由、反権威的
    • ラフなコンセンサスと動くコード
    • 許可を求めるな、謝罪せよ
  • 社内コミュニティ
    • コミュニティ・オブ・プラクティス
    • 組織：縦割り
    • プロジェクト：横串
    • 社内コミュニティ：縦でも横でもない

  • 社内勉強会を社内でやると･･･
    • メリット
    • リスク・コスト
    • メリット＞コスト
  • 勉強会の法則
    • 開催のメリット＞開催のコスト（よしおかの勉強会第一の法則）
  • もうひとつの方法
  • 3.11後
    • ハッカー中心の企業文化の理解
    • project60 電力使用量40%削減の取り組み
    • 震災が組織を変えるチャンス
  • エンジニアとして、社会をよりよくしていきたい
  • そのために、ハッカー中心の企業文化を日本に根付かせたい
  • それが自分が幸せになる道だと思っている。


よしおかさんのセッションについては、後半の勉強会に差し掛かった辺りからセッション終了後の質疑応答に関して、個人的に印象に残り、感銘を受けました。質問もそれぞれ個人的に気になる所、悩んでいるところだったりしましたし、それに対するよしおかさんの回答も明快で腑に落ちる部分も。以下個人メモベースではありますがその辺のやり取りを。

  • Q：個人で企業を変えていく上で、抵抗勢力（良かれと思って批判的な事をいう人）をどうやってクリアしていくか。
  • A：気にしない。
    • 孤独を感じる（devLoveでの熱い思いは…）→組織の５％位はそう思っている人がいる。
    • 半径５mの中でとりあえず頑張ってみる
    • 勉強会に参加して思いを普遍化
  • Q：よしおかさんが（行動を）進めて行くなかで抵抗する人たちは何を守っている(いた)のか。
  • A：殆どの人は興味(を持って)ない。
    • 自分の数字を追っている。
    • →明確なKPIがある。
    • 売上を上げる、コスト面、活性化、メリット
    • 『柳腰』のスタンスで
  • Q：勉強会を個人ベースで続けているが、後続が続かない。
    • 後続に続いてもらうには。そのコツは？
  • A：メリット＞コスト　であれば続く。
    • 無理にがんパリ過ぎる必要はない？
    • 開催のコストを『ほぼゼロ』にすればよい。
    • 忙しいときには、やらないという選択肢もあり。
    • マジメにやらない。

デブサミアワード2011の表彰式

最後に、今回の再講演での元となった本編『Developers Summit 2011』に於ける表彰式が各種執り行われました。スケジュールの都合で今回参加出来なかった方達はコメントを寄せており、受賞者の方々もそれぞれコメント。自分自身はデブサミ2011は不参加(申し込んでは居たが、スケジュールの都合で参加出来ず)でしたが、これら皆さんのコメントから想像するに相当な盛り上がりであったのかなぁと。

締めは今回のイベント参加者全員で集合写真をパチリ。この辺の写真はいずれ関連記事にて公開されるのではないでしょうか。楽しみです。
(追記)CodeZineにレポートが紹介＆全体写真も掲載されました！

都合4つのセッション、5時間近くの長丁場となりましたが、そのどれもが意義深い、参加した甲斐のある内容でした。

全員が『3.11』(東日本大震災)以前・以後について語っていたのも印象的。我々日本人・日本国民に降りかかった厄災な訳で避けて通る訳には行かない事象なのは当然と言えば当然なのですが、ITの世界に於いても何かを変える・何かが変わる大きなきっかけと

  • DevLoveスタッフの方々から『しおり』のプレゼントがありました。表裏合わせてこんな感じのデザイン。

  • IBMさんからはノベルティとして小型クリップ詰め合わせも頂きました。


このブログエントリもエラい長編となってしまいました…(^-^;) 個人メモの部分は勢いで若干未整理な部分も有るかと思いますが御容赦頂ければと思います。m(_ _)m いずれ今回発表されたスライドも各種公開される事でしょうから、随時反映、参照の方向で宜しくお願い致します。

その他『デブサミ再演』に関するエントリ