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

勉強会


(写真：目黒雅叙園)


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

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

ばっちり有休申請を済ませ、仕事の調整も完了し、晴れて参加の日を迎える事が出来ました。

この日参加するセッション及び関連イベントは以下の通り。朝から夜までびっしりです。

10:00〜10:50 [Web Technology]           【16-C-1】HTML5の今と未来 〜HTML5との正しいつきあい方〜 / 羽田野 太巳 氏
11:10〜11:55 [Web Technology]           【16-C-2】大規模化するピグライフを支えるインフラ 〜MongoDBとChefについて〜
                                         / 桑野 章弘 氏、並河 祐貴 氏
12:00〜13:00                             ＜昼食：日本鼻メガネの会メンバーによるランチ＞
13:10〜14:00 [開発プロセス]              【16-B-3】教科書と現場のあいだ　〜学びを活かすために〜 / 和智 右桂 氏
14:20〜15:05 [開発プロセス]              【16-B-4】アジャイル開発の10年と今後を語ろう。 / 平鍋 健児 氏
15:25〜16:15 [これからのアーキテクチャ]   【16-E-5】デザインの最前線 / 田川 欣哉 氏
16:35〜17:20 [Mobile Technology]        【16-D-6】比べてわかるフィーチャーフォンとスマホのアプリ開発・運用のポイント / 北村 雄騎 氏
17:40〜19:10 [Special]                  【16-C-7】特別出張！エバンジェリスト講座@デブサミ / 西脇 資哲 氏
20:00〜　　　　　　　　　　　　 　　 　　  ＜デブサミ2012アンオフィシャルパーティー＞

そして会場は目黒雅叙園＠目黒。数々の大規模勉強会イベントが行われてきたこの会場は個人的には今回初参戦でした。

割とギリギリな感じで会場到着、この日は一日を通してネット回線との戦い、Togetterまとめに関する情報収集との戦い、そしてブログまとめ用のメモ取りとの戦い…という感じで休まる暇も無く(途中バテて休憩入れたけど)、全セッション終了後はかなりぐったりした状態でした。朝方レッドブルをロング缶4本買っていったのに結局イベント期間中は飲まなかった(飲めなかった)とか、今迄からしたら有り得ない…(笑)

セッション講演内では写真NG、という事で中身については文字のみのメモとなります。

午前の部

10:00〜10:50 [Web Technology]【16-C-1】HTML5の今と未来 〜HTML5との正しいつきあい方〜
ウェブ業界でHTML5を知らない人はいないといっても良いほど、ここ数年、HTML5の話題で持ちきりでした。
マークアップが新しくなっただけでなく、さまざまなAPIが加わり、ウェブ標準でリッチなコンテンツが
制作できるようになったことはご存じの通りです。
スマートフォンやタブレットの普及の後押しもあり、すでにウェブ制作の現場ではHTML5を積極的に取り入れていると言えます。
しかし、HTML5をはじめとしたウェブ・テクノロジーは、その範囲を増すばかりで、すべてに精通することは難しいと言えるでしょう。
しかし、世の中はめまぐるしいスピードで進化していきます。

本講演では、2011年現在のHTML5の状況をおさらいし、今後、HTML5をはじめとしたウェブテクノロジーが
世の中にどのような影響を与えていくのかを考察します。

HTML5をウェブ・ページの進化という文脈で捕らえていると、将来を大きく見誤ります。
HTML5をはじめとしたウェブ・テクノロジーの進化の本質は何かを理解する必要があるのです。
方向性がないままむやみにウェブテクノロジーを学んでも意味はありません。世の中の動きを敏感に感じ取り、
将来を見据えた上で、技術を学ぶべきでしょう。

大きく変わろうとするウェブの将来の考察が、ウェブ業界はどの方向へ進むべきなのか、
そして、みなさん個人はどういった方向に軸足を置くべきかを考えるきっかけになれば幸いです。

まず始めに、岩切さんからの開始挨拶がC会場ではありました。

  • わくわくする場を設けたい
  • 当時は、勉強会ブームでも無く、コミュニティもない状態
  • 何か面白い事が出来るのではないか？となって始めたのがデブサミ。
  • 皆さんが参加し、楽しむ事が一番。
  • どんどんつぶやいてください。

そして羽田野さんの講演へ。

  • 自己紹介
    • 名前にはふりがなふってます。
    • 最近ではルビもまともにふれなかった。これがこれまでのWebの現状
    • HTML5になってルビが振れるようになった。
  • そもそもWebとは何か？
  • HTML5をはじめたWebTechがどこに進むのか、私達は何をすべきなのか。
  • HTML5 = Markup + API
    • 黄色本：だいたい言いたい事は書ききった。

徹底解説HTML5マークアップガイドブック

徹底解説HTML5マークアップガイドブック

    • 青本：まだ網羅はしてない。HTML5と言われている全体の中の、ほんの1部。

徹底解説HTML5APIガイドブック ビジュアル系API編

徹底解説HTML5APIガイドブック ビジュアル系API編

      • APIはHTML5に沢山盛り込まれている。皆さんがイメージしているHTML5とは少し異なるかも
  • ウェブとは
    • ブラウザーで閲覧するドキュメント
    • HTML/CSS/jsで作成
    • jsによるRIAは限界
    • 動画再生/アニメーションは無理
  • ウェブ標準の進化
    • HTML4/XHTML1.0から10年振り
    • プラグインの役割をウェブ標準で徐々に移り変わると予想されたが･･･
  • モバイル向けFlash 開発終了
    • プラグインによるウェブの開発は止まる。
    • 将来、AndroidでされFlashが繋がらなくなる可能性あり。
    • Silverlightについてもお先は暗い状態。
      • →最早、HTML5で作るしか無い状況になりつつある。
  • ウェブ化がもたらすインパクト
    • 1999年日本でケータイの表示情報がウェブ化
    • 2011年世界であらゆるコンピュータのアプリがウェブ化
  • API基盤となるウェブ技術
    • HTML5がOSの役割を担う：本来OSが提供すべき機能をHTMLが担う様になってきた
      • マルチメディア, 2D/3Dグラフィック, スレッド, ストレージ, ネットワーク, デバイス連携,カメラ,GPS
    • スレッド処理(Web Workers)
    • ファイル/ディレクトリ操作(File API/File Writer/…)
    • グラフィックス(Canvas/WebGL)
    • オフライン(Application Cache)
    • 双方向リアルタイム通信(Web Socket API/Web Protocol)
    • カメラ、マイクロフォン(Media Capture/Web RTC)
    • GPS(Geolocation API)
    • ジャイロスコープ/加速度センサー(DeviceOrientation Event)
    • バッテリー(Batttery Status API)
    • ネットワーク接続情報(The Network Infomarion API)
  • マルチデバイス
    • 最近で一番大きなキーワード。
    • もはやWeb＝パソコン向け
    • 日本では携帯電話向け、という事で先駆けではあった
    • サービスのクラウド化
    • デバイスのマルチ化
    • サービスの利用形態の変化
      • Buy Once, Read Everywhere
      • Pay Once, Play Anywhere
  • アプリ経済
    • 米国では30〜50万人の雇用創出
  • 企業システムのシフト
    • Bring Yout Own Device
    • 企業から社員にデバイスを配布する時代から、社員個人固有のデバイスでアクセスする時代へ
  • ネイティブApps開発の問題
    • 基盤の違い
      • Write Once, Run Anywhere ウェブ基盤をネイティブAppsの基盤に。
      • （HTML5/CSS3/Javascript）
    • 基盤をシフトする
  • ブラウザパフォーマンス
    • IEとも言えども、以前のレガシーなものと比べれば大分改善されている。
  • 組み込み機器の進化
  • 利用端末のシフト
    • 特殊な例の紹介。
    • あるメーカの調査：CE Devices（家電）の割合が増えている。（7割：PC&Macは3割）
  • 汎用端末へのシフト
  • ウェブ利用範囲の拡大
    • SmartTV：スマートフォンが巨大になったもの、とイメージ。
      • テレビもどんどんアプリケーション化
    • Opera TV Srore：ストアプラットフォーム。
    • HTML5がTVの世界でも基盤になる。
    • Access Netfront ACCESSMyTV
  • 放送と通信の連携
    • Web And TV IG/LIME/Open IPTV Forum/HbbTV
  • App基盤の動向→HTML5がApp基盤に。
  • ウェブスキルの応用範囲の拡大
    • あらゆる業界で、コアビジネスの中にHTML5/Webが組み込まれていく。
    • 青：成熟産業のウェブ政策でパイを奪い合う？
    • 赤：新たな世界に挑戦しパイを想像する？
  • 『われわれが進もうとしている道が正しいかどうかを、神は前もって教えてはくれない。』(アインシュタインの言葉)
11:10〜11:55 [Web Technology]【16-C-2】大規模化するピグライフを支えるインフラ 〜MongoDBとChefについて〜
オープン3週間でユーザ数100万人を突破したピグライフは、これまでのアメーバのサービスの中でも類を見ないスピードで成長しています。
そのため、このピグライフを構成するアーキテクチャや開発/運用についても、よりスケーラビリティが確保できるインフラが求められます。
本セッションでは、それらを支える取り組みについて、実際の事例をベースにお話しします。

(桑野さんパート)

  • なぜMongoDBを採用したか
  • アーキテクチャの課題
    • 開発スピーとの構造
      • Node.jsとの相性の良さ
        • データのやりとりがJSONで統一される
      • スキーマレスなデータ構造による柔軟なデータ管理
        • 機能追加時
      • 例：ユーザコレクションに最終ログインタイムを追加したい場合
    • スケーラビリティの問題
      • Sharding
    • 冗長性の問題
      • ReplicaSets
        • 相互死活監視＆投票により冗長性を保つ。最小単位は3台。
  • 実運用での課題
    • MondgoDBの機能は自動でスケーラビリティ
    • サーバキャプラ
      • mongos
        • スケーラビリティは無し
        • アプリサーバに同居する形にしている
        • サーバへの負荷は少ない
      • mongoc
        • スケーラビリティはない
        • 運用時に負荷は掛からないが、潤沢なリソースを使える状態にしておく方がよい（上記理由）
        • 冗長性は同期書き込み（2フェーズコミット）
      • mongod
        • DiskI/O：定期的に書きだすのである程度の性能が必要
        • CPU：書き込みはグローバルロックが存在しているために、複数コアを効率良く使えない
        • メモリ：index、データをメモリにキャッシュするため多ければ多いほど良い
      • バックアップ
      • グローバルロック
        • 同じサーバ上に異常に書き込みの多いコレクションがあった場合には、（結果的に）
      • Chunkの偏り
        • AntoBalanceがonの場合、chunkは『データ量』もしくは『オブジェクト数』によって分割される
        • データアクセス頻度によるSHARD分割をしたい場合にはManualBalanceにする必要がある
    • バグとの戦い（今まで踏んだバグ）
    • サーバの台数増…定期的なサーバ追加が必要


(並河さんパート)

  • 自己紹介：100人本に寄稿しています。
  • 最近、割と良くある光景
    • ○△のサーバ負荷がひどいので対応して欲しい。来週まで。→gkbr
  • アメーバピグ・ピグライフの構成
  • ピグのサーバ増設・運用管理
    • 共に右肩上がり
    • 急な増設を求められることもある
    • そこでChefを使ってみた
  • 1.chefの概要
    • サーバの構築作業やシステム管理のツール
    • オープンソース、ruby製
    • 利用実績
    • 手作業では、そもそも時間が掛かる
      • 数十代数百台の規模になると･･･
      • →サーバ投入までのリードタイムが長くなることで、機会損失を発生させることは避けたい
      • 人為的なミスを押さえたい
        • 作業漏れ、ルーチン作業でのオペミス
        • 作業者によってスキルにバラつき
        • →運用中のサーバでのミスは特になくしたい。設定に間違いがあっても自動化しておけば対応可能

    • Chefでの主な登場人物
      • Node(管理対象のサーバ)
      • Role(管理対象のグルーピング)
      • CookBook(システムのあるべき形を定義する設定（レシピ）)
    • Chefのリポジトリ構造
      • atteibutes(設定したいパラメータを記述したもの)
      • recipes(システムのあるべき姿、つまり設定内容を実際に記述したRubyスクリプト)
      • templates(サーバへ配置する設定ファイルのテンプレートで、eRubyで記述)
    • Recipe, Templateの一例(記載例)
    • chefのちょっとイケてないところ
      • サーバのセットアップが面倒臭い
        • 必要なのは最初だけなので、許容出来る。クライアントは簡単
      • 名前がSEO的に致命的
        • リアルに調べ物をする時に困ります、普通にイカ料理のレシピが出て来たり
      • dry-runが出来ない
        • テスト環境が必須
  • 2.Chefの運用
    • chefを活用したサーバ増設
    • 今はオンプレミスな物理環境を想定
    • クラウド環境でも応用可能

    • cookbookの使い方
      • cookBookの例
        • ネットワーク設定（拠点など）
        • H/Wに必要な設定
        • 各サーバで必要な設定
        • 各Roleで必要な設定
    • chefを使う上でやっていること
      • Script Resourceは基本的に使わない
        • 何度でも実行される
        • chef-client実行時のチェック・運用が面倒
        • 何度実行しても問題ないものしか使わない
    • 各Nodeのchef適用は、chef-clientを実行
    • NodeのAttributeの登録
    • アンインストール・削除などの処理も忘れずに
    • Environment（0.10〜）の活用
  • まとめと今後の展望
    • Chefを活用することで多くのサーバの増設、管理にかかる負担を軽減
    • クラウドなどの基盤サービスと連携して、インフラ構築/運用の完全オートメーションが出来る仕組みにしたい。

昼休憩

日本鼻メガネ界隈の面々で集まって、建物付近の社員食堂的なところでサクッと昼食。既にこの時点で『時間の無さ感』『余裕の無さ感』(この辺り、ネット環境が繋がらなかった影響やTogetterまとめが円滑に進むか否か不安があった部分も影響していたと思われる)

なお、会場にはこんな感じで名前が出ていました。

あと、途中トイレにも立ち寄ったのですが何かすげ〜雰囲気だったので思わずパチリ(笑)


午後の部

13:10〜14:00 [開発プロセス]【16-B-3】教科書と現場のあいだ　〜学びを活かすために〜
ソフトウェア開発理論に目を向けると、オブジェクト指向が目指した理念やパターンの歴史、
スクラムなどの開発手法やTDDのようなデザイン手法など、魅力的な概念にあふれています。

その一方で、皆さんの開発現場はどうでしょう？本で読んだとおりのことを現実に行えているのであれば、
それは素晴らしいことですが、おそらくは、うまくいかないこともたくさんあるのではないでしょうか。

でも、だからといって、理論を学ぶ意味がないということにはなりません。
学んだことを実際の現場で活かすためにどうすればよいのか、私自身の模索の過程を踏まえてご紹介していきます。
  • 自己紹介
    • グロースエクスパートナーズ
    • ときどき翻訳
      • DDD本

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

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

      • 継続的デリバリー

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

      • ？？？(もう1冊仕込んでる)
  • 経歴
    • 文系大学院出身（ドイツ文学）
      • 抽象概念の操作が大事
    • プログラマとしてこの業界に
      • プログラムが純粋に楽しかった
    • 某ゼネコンを経て現職に
    • 今は中規模プロジェクトのリーダー
      • 要件定義から方式設計、チーム運営等々
    • アンケート取らせてください。
      • 勉強会に行く、本を読んで現場に適用、うまくいかず→半分位？
      • 勉強会に行ってみようかな〜→やはり半分位？
      • Agile/WFならAgileやっているぞ→約1/5
      • WFですよ→6〜7割。
    • 仕事はSI、休みの日には翻訳やブログ。
    • 時々、セミナーに参加したり、登壇の機会を頂いたり。
  • こんな風に捉えた方が良い。
    • 泥臭いものもオシャレなものも、＜原則（プリンシプル）＞がまず下敷きにあり、その上に＜実践（プラクティス）＞がある。そしてその両端に泥臭いもの、オシャレなものが

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

    • プロマネとしての失敗体験
      • ふるまい駆動開発（BDD）･･･give when then
        • スケジュールが完全に崩壊･･･
        • ハンドルを任されて、ちょっとやってみようと思った。
        • 当時、和智さんはBDDを素晴らしいと思っていた。
          • 周りの人達の調整が上手く行かない部分あり
    • なぜだろう？
      • デザインパターンが優れていて、BDDが･･･という訳ではない。
      • 閉じた世界･･･枠として問題を解くための枠組みが出来ていた。
        • そこに和智さんが投入された
        • 和智さんが上手くやったのか、そうでないのか？
      • 開いた世界
        • 囲い込みが出来てない状態でボールを渡された。
      • どっちが優れていると言うわけでは無く、そもそもどうやってその問題を解くべきか、そういう人が居なければならない。
      • 批判は凄く簡単だけど、実際凄く怖い状況。
    • 開いた世界に立ち向かう
      • ソフトウェア開発のステップに本質的な違いは無い。
        • 要件→設計→実装→テスト→リリース
        • （バリューストリーム：価値の流れ）

      • 抽象的なものを具体化させる"流れ"
        • マクロ：要件→リリース
        • ミクロ：1つ1つの流れで小さいステップが存在
          • 抽象度がバラバラだと厄介、次の工程に備えて形にしていく事が必要

      • 予算と期限
        • 決められた条件の中で抽象的なものを具体的な形にする
          • このプロセスが全ての基本
            • 進捗の可視化
            • 課題管理
            • 変更管理
        • ※いろいろなものを見て行く必要がある。
    • おしゃれなプラクティスを試したい！
      • その思いが大局観を狂わせる。
      • ※勉強するリーダーほど、気を付けないといけないのでは。
  • 原則（プリンシプル）と実践（プラクティス）
    • 朝会の運用にも障害はある
      • 朝、顧客との打ち合わせが入っている
      • そもそも自分が起きれない
      • 来ない人がいる
      • 各自が自分のタスクをやっているだけなので、作業状況を共有する意味が無い（スクラムマスター研修で出た声）
    • スクラムの原則：作業をひとつのキューに入れ、チームで取り組む
      • →ここに持ってくるのはそんなに簡単な事ではない。
    • 原則を理解してはじめて、実践に意味が与えられる
    • 原則を辿れば、バリューストリームに行き着く
      • 作業のチャンクを小さくしよう
      • ふりかえりをして改善案を模索しよう
      • 痛い思いは早めにしておこう
      • ※方法論上の区別に意味がない世界
    • 原則を理解すれば、実践に幅が生まれる
    • アジャイルのプラクティスってカジュアルすぎて、口に出せないことありません？
      • ※アジャイルサムライ読んだ事ある人？→6割位挙手
        • インセプションデッキ：結構空気を読むと、出来なかったりする。
        • プランニングポーカー：多少無理をさせている現場に【カードを額に当てて】とは･･･
    • コンテキストに乗せれば、組織の中で会話するための言葉が手に入る
    • 自分が価値だと信じるものを相手に伝える能力は本当に大切。
  • 成熟とは
    • 成熟とは組織の成熟、組織とはそこに関わる人々。
    • 受託案件：常に新しいコンテキストが待っている
      • 保守フェーズ：一番アジャイルをやりやすいフェーズでは？繰り返し、イテレーティブ･･･
      • PMから学んだ：価値の流れがある中で、特定のコンテキストに応じた価値の流れを作るにはどうしたら良いか、をプロセスとして持っている。
      • Sier：難しいと思うが、きちんとデリバリーしているというところにほこりを持って良いのでは？
  • 最後に
    • 実践レベルのものに意味がない訳ではない。役に立つものが多い
      • JUnitテスト
      • 課題管理ツール
      • ワンクリックデプロイ
    • 要素技術（HTML5）の勉強も意味があるし、大事。
    • 開発のリードは必須だが、難易度は高く求められるスキルは幅広い
      • （俯瞰出来る）地図を作ろう。
    • 原則の学び方
      • 名著を呼ばれている本は、やはり読む価値はある
      • 精読しよう。
      • 入門書は実践レベル。専門書は・・・
      • 和智さんにとっては、翻訳は究極の精読。
      • 英米圏の人は、原理原則を大体最初の方に書く。
        • 著者に会える機会を大切にしよう。
          • 言語の問題で萎縮するのは勿体ない。
          • 本に書かれていることはごくごく一部。
          • 原則をベースに：
          • ロジックからこぼれ落ちてくる物は非常に多い。そこを聞くだけでも有用。
          • 意外と彼等も悩みを抱えている。
    • そしていつも、地に足をつけていよう。


最後に質疑応答が幾つか。

  • (Q).アーキテクチャ・プロセスについて：モデルについてはどこに属する？誰がやる？
    • (A).モデリングをする時の切り分け：難しい場所とそうでは無い場所。難しいのはそんなに多くあるわけではない。どこが困難でどこがシンプルかを切り分ける。枠を閉じた世界として固める
  • (Q).原則を学ぶ事の大切さを教えてくれた『守破離』についてどんな考えか？
    • (A).和智さん自身、昔弓道をやっていた。
      • 守：型。どういう風に体を動かすか学ぶ。
      • 破：自分のコンテキストとスリあってくる。型どおりにやらないんだけど、それが正しいと思える
      • 離：自分のコンテキストに合わせたものが組み上がってくる。自分の型。
14:20〜15:05 [開発プロセス]【16-B-4】アジャイル開発の10年と今後を語ろう。
デブサミが10年たったのと同時に、アジャイル開発も10年がたちました。
現在、日本でもアジャイル開発の採用が進み、ぼくらが目指してきた「デベロバーの形」と「ビジネスの形」が
一致するのではないか、と思っています。

アジャイル開発の10年をふりかえり、新しい開発の形を一緒に考えましょう！
  • 実は1回目から出させて貰っている！
  • 時代は変わりましたね〜。
  • セッションによって参加者層が異なる。
  • 自己紹介
    • XP本(桃、オレンジ、紫、赤)
      • この辺りの本はあまり売れてない（笑）時期を間違ったかな･･･
  • アジャイル宣言から11年
  • ケントベックとの写真『XP！』
  • アジャイルの現在位置：図を交えて、様々なプラクティスの歴史に触れつつ歴史を眺望。
  • 今どういう方向に向かっているか。
  • 小さい規模のはもう出来る。
  • 最近、kanbanという動きが
    • もう少し、agileをサイエンスしたい。
  • 更にはLean Startup
    • 開発をアジャイルにしてもしょうがない。売れないものを作ってもしょうがない
    • お客さんと製品を開発するサイクルを両輪で回す。
  • 本の話。

XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法

XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法

    • 1999年　eXtreme Programming explained
    • 2004年　eXtreme Programming explained Second Edition
    • 平鍋さん、訳そうとするも版権取られている。悔しいのでHP作った。
    • まず、動く物を試してみないと。その感覚が大事。
    • 人と人との、会話のプロトコル。
    • どういうコミュニケーションが起こるのか、をデザインした。
    • 一番目覚めた点『システムをリリースしたらお客さんと一緒にシャンペン・食事しなさい。』
      • 目玉が飛び出した。本当にこれはやりたい。
      • 読んでいくうちに、『これは俺が書いた本じゃないか？お前は俺か？』
      • 2004年度版は奥さんと共著らしい。
  • XP2:プロセスの表現
    • 5つの価値
    • 原則
    • プラクティス(基礎13,応用11)
  • 会社のビジョン、ミッションの表現に似ている。
  • 本の話。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

  • 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/05
  • メディア: 単行本
  • 購入: 94人 クリック: 3,091回
  • この商品を含むブログ (312件) を見る

    • 『いつまでたっても印税入ってくるんだよね〜』（著者談）
    • 現場で初めてリファクタリングが上手く使われ始めた。
  • 本の話。

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

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

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

  • TOOL1：無駄を認識する
    • 生産工程の7つのムダ
      • 在庫のムダ、加工そのもののムダ、作りすぎのムダ、運搬のムダ、手持ちのムダ、動作のムダ、不良を作るムダ
    • ソフトウェア開発の7つのムダ
      • 未完成の作業のムダ、余分なプロセスのムダ、余分な機能のムダ、タスク切り替えのムダ、待ちのムダ、移動のムダ、欠陥（バグ）を作るムダ
    • ムダを省く作業に人が絡む。
  • ソフトウェアかんばん
    • リーンの本から取った。
  • 作業の見える化
    • ToDo（未実施）
    • Doting（実施中）
    • Done（テスト完了）で定義
  • ファシリ−テーション大人気。2005年デブサミでベストスピーカー賞、以降様々な場所で講演。

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

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

    • アートオブアジャイルデベロップメント（XPへの回帰）

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)

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

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

      • 今日一番手が上がったかも知れない。
        • ジョナサンが大阪にやってくる。
        • この本、好き。現場感がある。
    • 2012：KANABN / David Anderson

Kanban

Kanban

    • 2011：The lean Startup / Eric Ries

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

  • 『100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊』
    • 平鍋さんは『XP白本』を推薦。

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

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


    • Scrum 5割%。
    • カンバンは割合小さい。
    • 9%カスタマーハイブリッド。顧客が自分達で作っている。

(注：画像の図は集計年度が違うものです)


  • 日本から、何かだそう！
    • イノベーションスプリント：ジェフ meets 野中さん
    • 実践知のリーダー
      • 動きながら考え抜く（Contemplation in Action）
      • 知的体育会系
        • intellectual Muscle
        • 共通善に向けた『よりよい』の無限追求
      • 野中さんへの質問
      • (Q).ステークホルダーがたくさんいると優先順位が決められない。
        • (A).ガブリエル：それは視点が違っていて
        • (A).野中先生：『ん〜、3日間合宿しなさい』
          • そもそも量で測れるようなものか？
          • 1日目：形式知の話/2日目：お前は誰で、何のために･･･/3日目：本題を議論(その後、温泉がある方が良いw)
          • PDCAっていうけれど、Pって最初にあるのかね？

15:25〜16:15 [これからのアーキテクチャ]【16-E-5】デザインの最前線
デザインとエンジニアリングの両面から、美しさ・機能性・使い勝手を高い次元で融合するための
新しい製品開発のスタイルを、プロトタイプ駆動型の製品開発プロセスやワークショップを用いた
デザインプロセスなど独自の手法を例に挙げながら解説する。
  • 自己紹介
    • Desin エンジニアリング　Firm
    • 中で働いている人達の大半が、エンジニアリングの背景を持っている。

  • 元々会社自体、プロダクトデザインをやっていた人が多い。
    • ロボットとか
    • 空間系のお仕事とか
    • 興味のあるかたはtakramでググれ！

  • 仕事をやる上での使命：
    • デザインとエンジニアリングのトータルコントロール
    • 大きなメーカーにはデザイン部門、エンジニアリング部門が存在
    • 近年、特に先端のテクノロジー系の場合はデザイン・エンジニアリングが融合
    • UXを踏み越えた先に、根っこの部分で融合している必要がある
    • それにちなんだ人材が必要
    • 人材としてのデザインエンジニア
      • 両方の経験・知識を持っている人材を製品開発の現場で育てていくことで打開が測れるのでは
    • クリエイティビティとテクノロジー、と言い換える事が出来る
  • プロトタイピング：
    • ものつくりの進め方
    • プロセスを進める人材
  • まとめ
    • デザインをして行く上で幾つかのポイント(5個位)

…このセッションはほぼ写真・イラストで文字そんなに無し＆ここまでの連続セッション参戦で諸々疲弊していたのでメモ少な目です... orz

しばし休憩

第6セッション目も予定では参加する方向でしたが、ここまでの疲労及びPCのバッテリーの持ちが危うい状態でしたので小休止。

PCを充電状態(且つ日本鼻メガネの会界隈の方にお願いしました。ありがとうございます)としたうえで、建物内の喫茶店で数人で休憩。

軽く食事もしたり。ここで休憩取る事で心身的にもPCバッテリー的にも幾らか回復する事が出来ました。

17:40〜19:10 [Special]【16-C-7】特別出張！エバンジェリスト講座@デブサミ
大好評を続けている人気セミナー「エバンジェリスト養成講座」のダイジェスト版を、
Developer Summit 2012 に参加するエンジニアの方々に特別出張！
エンジニア視点でのプレゼンテーションやスーパーデモンストレーションを実現するノウハウを惜しみなくご紹介します。
参加された方々にはお楽しみも準備したいと思います。

こちらのセッションについては、元が有料講演のものであったりするので、

  • 自己紹介
    • エバンジェリストとしてのノウハウお作法をプレゼンテーション形式として行うセミナーを実施。
    • 10年後の技術者の為に。
    • MSのではなく、純粋なエバンジェリストとして。
    • セッション資料は配っていません。有償の講座としています。エバンジェリスト養成講座 6、ちょうど集客中。
    • Windows Developer Days ： Bingで検索（月曜）！
    • 100人本にも寄稿…2番目に推薦。地味な本を推薦しています。
    • 本当に知りたかったプレゼン/デモの秘訣
      • エバンジェリストな人？→意外と少ない
      • プリセールス・営業の人：エバンジェリストの要素を持っている
      • 技術職の人：エバンジェリストの要素を持っている
      • エンジニアの方はそれを重要な役割と思って頂きたい。
      • オラクル時代の写真（2000年頃の記者発表時）
      • 今：MSカンファレンスでの写真
        • MSの価値や楽しさや魅力を伝える為にご一緒させて頂いている。
        • 第三者に伝える：非常に重要。自分自身をより向上させる事が出来る。
        • プレゼンが上手いと、カッコ良くて輝いて見える。
      • エバンジェリストとは何か：
      • なぜ？：Google先生が教えてくれる
        • 候補一覧としてサジェストされる
        • bbクリーム強敵
      • なぜ？翔泳社さんが･･･
        • 本も出している。結構な方が持っている。4割。
      • Think！（シンク！）にも乗っている
  • 本日の内容と進め方
    • 自己啓発トレーニング
    • ワークショップ・シミュレーションガタ
      • 実際にプレゼンテーションを『目の前のリンゴをプレゼンしてください』　感想ではない
    • 米国では、『あなたが一番大好きなおもちゃを説明』が教育現場で使われているプレゼン
      • つまり体験を語ることがプレゼンテーション
    • プレゼンの内容は、本当に自分が好きで大切な物について話すもの。

    • デモンストレーションを披露するわけではない
    • プレゼンを聞いて貰うのでもない
    • 誰でも出来る
      • プレゼンは特別な能力ではない
      • デモンストレーションは特別な能力ではない
      • 少しだけ努力は必要
        • とても簡単な事から始めよう
        • 繰り返し、繰り返し、考えながら進めてください
      • 他の人よりも数多くの努力をしている自信がある。
  • 約束しましょう、『やる』という約束
    • 思います、という表現は辞めましょう。
    • 人と同じです。やる！と約束しましょう。
    • チャレンジしたい、ではなくてチャレンジする。
    • 具体例を実際のプレゼン、デモンストレーションで紹介
    • そもそもプレゼントは何を届けるのか？誰のために、どういう内容で行うのか？
    • どういうスライドがインパクトを与えるのか？
    • どういうデモンストレーションが印象に残るのか？
    • 本番直前までにやっておくこと
    • 効果的な使い方
  • MS生活：6割、プレゼンデモ生活：4割。
    • 家電の照明機器を売るための講習
    • 化粧品を売るための講習
    • 保険会社さんの商品のプレゼン講習
    • 環境省が地方自治体に受入説得のためのトレーニング

(この辺からボカします...)

  • はじめに
  • さまざまなシーンで行われるプレゼン
  • プレゼンテーション・デモの種類
  • 顧客フェーズに合わせて伝える物がある
  • テーマ・シナリオ
  • プレゼン準備について
  • スライドを作成
  • 当日まで（直前まで）の準備
  • 本番
  • 言葉使いのマジック

(ボカし終わり)

プレゼン・デモンストレーションを上手く格好良く、綺麗に見せる手法を実演を交えて様々な形で見せて頂きましたが、『なるほど！』と目からウロコなポイントが多数得られたセッションとなりました。この日でも個人的には1,2位を争うセッションだったかも。


そんなこんなで1日目終了。

アンオフィシャルパーティー


目黒雅叙園での本編終了後、同じく目黒で行われていた『アンオフィシャルパーティ』なるものに参加してきました。

…と、その前に長丁場で疲れた心身に鞭打つように迎え撃つ急坂(笑)

次の日もあるので途中で中座致しましたが、参加メンバーは濃いというか凄い人が割と多め、開催場所も普通の居酒屋orバー的なものを予想していたのですが実際はマンションの1室？を改装した作りとなっており、正直面喰らいました(笑)





今回のイベントハッシュタグ/Togetterの件で翔泳社の岩切晃子(TwitterID:@kohsei)さんとも改めてご挨拶させて頂くが出来ましたし、喜んで頂けたようで何よりでした。『日本鼻メガネの会』なる謎の団体の発足があり今回のTogetterの件があったようなものなので、(実際ご挨拶したのは私と(@orange_clover)さんの2人だけでしたが、実際作成編集に参加された方は他にも数名いらっしゃいますし、改めて会長を引き連れて…みたいなお話をしたりもしました。いや〜、どこでどう話が大きくなるか分からんもんですね。そして、今回の懇親会で参加された方々の中に『日本鼻メガネの会』を認識している方々も数名居たようで、『何をしてるのか分からない』という印象でした(笑)


以上、1日目のレポート終わり！


その他関連：

  • ブログレポート