デブサミ2011( #devsumi )2日目参加メモ
デブサミ2011の二日目へ参加した際のメモです．
■日時：2011/02/17(木) - 18(金) 09:30-18:15
■場所：目黒雅叙園
■参考：http://codezine.jp/devsumi/2011/
■参加者数：のべ1000名以上
■参加したセッション
□和田さん -プログラマが知るべき，たったひとつの大事な事柄-
□西山さん，高石さん -第三者作成ソースコードに埋もれている不具合を暴け！-
□吉田さん -システムアーキテクチャ構築の実践手法-
□及川さん -クラウド時代のソフトウェア開発-
□野村さん，市谷さん -未来の為に私たちの帆を立てよう-
■資料
- 講演資料：http://www.slideshare.net/event/developers-summit-2011
- Togetterのリスト：http://togetter.com/t/devsumi?page=1
- デブサミに関するツイートをゼンブ見る！＜デブサ見＞2011：http://labo.artry.net/devsumeet2011/tweets
- デブサミ2011 資料・Togetter集：http://labo.artry.net/devsumeet2011/afterlinks
- デブサミまとめまとめ:2011：http://devsummary.miukoba.net/
■感想
前日のLT大会や和田さんや野村さんのセッションなど，デブサミは感情へ働きかけるセッションが多いように感じます．
その意味でも二日間の最後に野村さんのセッションがあったのは，今後に向けての意識づけとして良かったと思いました．
自分が少しでも何かできたらと思う2日間でした．
■メモ
□和田さん-プログラマが知るべき，たったひとつの大事な事柄-
- #97prog_ja
- 大事だなと思うことを話す．
- ここでは，「自分」の話をする．ここまでの道のりをはなす
- 最も大事なきのこ．
- No.18の学び続ける姿勢
- 読む，書く，話す時代について話す
- 原メソッド
- 1996年にアメリカではじめてコンピュータに触れた
- ホームステイ先の子供と仲良くなるために，やってみせた．
- 無限ワンナップ
- →人の心をつかむためにはやってみせることが大事だと学んだ．
- 2000年にOOにどはまり．厨二級．
- 完全主義の呪いにかかった
- 2002年にまさーるさん(石井勝)会った．
- JUnitやテストに関して学んだ．
- 写経
- 技術書の写経の方法．でググルと出てくる．
- 深夜バスのなかでTDDを写経してた，
- ケントベックのTDDドラフトを写経
- ひたすら本，WEBを読んでいた．
- 身につけたい技術は写経していた
- 完璧主義から，まさーるさんとTDDが救ってくれた．
- 2004/7/1にチーム角谷にコーチとして参加した．
- 全開でXPやってくれ．
- 2004/7/1にはてなにアウトプットし始めた
- No.J02.ロールプレイングゲームをやりはじめた．
- No.54 見える化．
- No.80 1人より2人
- No.65 バーション管理システム
- No.79 テストのないソフトウェア開発はありえない
- No.51 プロジェクト自身にしゃべらせる
- 今なら，Jenkinsなどで回して，赤ランプ
- 常に自分よりレベルの高い人と仕事をするようにする．
- 自分の良い師匠が増えた
- 自分が学びたいことを人に教えたりするようになった．
- 2005/4/25に福知山線の事故でまさーるさんが亡くなった．
- それをきっかけに書くだけでなく，話すようになった．
- 人に対して伝えないとと始めた．
- テストの再分類するモデルを作り始めた．
- コードの4象限(動作する，きれいなコード)を作った．
- TDDと黄金の回転
- アウトプットするとインプットが増える
- そのアウトプットがどんどんアウトプットを増やす．
- その結果WEB+DBへTDD特集
- TDDを動画で解説
- そのアウトプットがどんどんアウトプットを増やす．
- これらによりTDDのブランディングができた．
- 自分の得意分野ができた．
- 2008/02/14にデブサミに初めて登壇
- デベロッパーテスティング・ライブ
- やってみせることが重要であること再認識した．
- java-jaに出会う
- ライブ再び
- Twitterが生き生きしてきたことを感じた
- Twitterの渦
- 渦を作る：Influence：インフルーエンス
- TDD Boot Campをはじめた(東京→北陸→名古屋→札幌，今後，九州→四国，大阪，横浜)
- 下記のものを伝えたくてはじめた
- 現実に立ち向かう術
- ペアプロの楽しさを学んでほしい
- プロとしての嗜み
- 会場内で20名くらい参加者
- 渦を作ることができたかなと思ってる
- 下記のものを伝えたくてはじめた
- 学び続けるコツ
□日本Rubyの会
□西山さん，高石さん -第三者作成ソースコードに埋もれている不具合を暴け！-
- コベリティ
- 課題
- 複雑になるコードの管理
- 肥大化する開発コスト
- 不具合が与えるビジネスへの影響
- 開発スケジュールの遅延
- ソフトウェアサプライチェーンにおける品質の担保
- 出荷後の修正コストは開発時の30倍くらい
- Forrester, Jan. 2009 より
- 納期どおりに間に合っていないケースが49％位
- balaco 〜 より
- 世界中の開発者や部品を利用することが増えている．
- Gartner調べで，2012年62%のOSSのOS利用となる
- Android
- トライアル提供中
- OSSを使っている場合，それの品質を知りたい場合はWEB参照
- 高石さん：アンドロイド解析デモ
- 別ファイルの参照もインラインで表示する
□吉田さん：-システムアーキテクチャ構築の実践手法-
- IBMのエンタープライズアーキテクト
- 聴衆の年齢層高い
- 機能ベースの開発方法論は多いが，非機能要件を満たすような開発方法論はあまりない．
- "システムアーキテクチャ構築の実践手法"の本の深読みのために．
- 流れ
- アーキテクチャとは構造である．
- システム構造と構成要素と責務を明らかにしなければコストを算出できない．
- アーキテクチャの特徴
- 見えない構造の可視化であり，一義的でなければならない．
- 設計・実装上の判断のよりどころとなる．指針となる．
- アーキテクチャは設計され，実装され，アセット化され再利用される．
- システム(ソフトウェア)構造の判断は開発の初期になされる．
- その時点では実際のシステム（ソフトウェア）は存在しない
- 十分な情報が揃った上で検討がなされることは少ない
- アーキテクチャ上の判断
- 開発上のリスクを踏まえて，システム設計の方向づけを行う必要がある
- 仮定も明確にする必要がある．
- ところどころで評価することで，最悪その時点まで戻ればいいようにする．チェックポイント．
- ステークホルダ
- アーキテクチャの表現
- 構造を一義的に解釈することができるのか．
- そもそも，対象の本質をひとつの視点からのみで表現できない
- そもそも，同一の理解に達することはできない
- 本質を表現し，理解するための複数の適切な視点が必要
- ステークホルダとのコミュニケーションにとって大切
- ステークホルダの関心ごとに応じた視点の採用が必要
- 4+1Viewなど
- ビューを作成するためのテンプレートとしてビューポイントがある．
- 機能ビューポイントと配置ビューポイント
- 基本及び横断的なビューポイント
- 基本：要求ビューポイント，機能ビューポイント，配置ビューポイント，妥当性確認ビューポイント
- 横断的：パフォーマンスビューポイント，セキュリティビューポイント
- ビューポイントと成果物
- 各ビューポイントからステークホルダに提供する成果物が明確になる
- アーキテクチャ記述
- 対象システムの特徴により重点は異なる
- メリハリをつけたアプローチが重要
- これらのことがあるので，アーキテクトは常に技術に目を光らせておかねばならない
- アーキテクトの主要ワークプロダクトと責任ロール
- アーキテクトのロールがビジネスアナリストの領域に広がっている．
- 手法の概念とその関係
- フェーズ，局面などはプロセス
- 最小単位のタスクがどういうロールを実行し，ロールがどういう成果を残すのかをいって，はじめて手法と言える
- OpenUp
- タスクの記述も定義する必要がある．
- 目的，実行するロール，入出力，ステップ，アーキテクトのロール
□及川さん-クラウド時代のソフトウェア開発-
- リリースマネージメントに関して話して欲しいという依頼を受けたが，やっていないので過去の経験を含め話す
- 大規模ソフトウェアが前提．
- （一般的な）大規模ソフトウェア開発
- googleの話ではない．
- 大規模ソフトウェアは失敗が許されない点が共通概念
- 失敗が許されないが故に堅いアプローチを取る
- plan, design, implementation, stabilization, release, plan を繰り返す
- 人・開発物のコントロールが重要になってくる．
- windows2000（NT5.0）はコードができたはリリースできるか不明になった，その時に，開発マネージャーを入れ替えた．
- "Brian Valentine" "Ian Mcdonald"
- リズムを作り出した．
- 大規模ソフトウェア開発では統制下に置かれる．
- フェーズアプローチとなる．
- 各フェーズごとにやることを明確に決める．
- フェーズ終了条件を始まる前に決める．
- 大きなプログラムを分割して，権限委譲していくことで，アジャイルを使ったりすることができるようになる．
- 分割しない場合は，WFモデルしか使いようがない．
- 分割・権限委譲をする際に，テーマが重要になる．
- 何も考えないとばらばらになってしまう．
- まず，テーマをしっかり決めておくことがとっても大事．
- google chromeではシンプル，スピード（速い），セキュリティ，の3Sがテーマ
- きちんときめておかないと，判断がしにくいし，ぼけてしまう．
- テーマを決める際には，わかりやすくしておくことをオススメする．
- シンプルかつ全員が覚えておける
- まったく新しい場合にはテーマが実現できないとき時がある
- その際には，次のバージョンで実現する．
- はずれないようにするためのテーマ
- ブランチのまとめのために，厳密なcheck in window
- 毎日定時に開始されるビルド
- ゴールが明確なときはもっと厳密なチェックインコントロールを行う
- テストは各フェーズでおこなわれる
- 一定のテスト期間を確保して，全員参加型の"bug bash","find it"を行う
- バグのインアウトをきちっと計測して，可視化して傾向をつかむ
- バグのクライテリアをつけて，直さないというジャッジもとりうる
- リリースは高い完成度が求められる
- 大規模ソフトウェアはリリース（デプロイ）がとんでもないコストがかかるので高い完成度が求められる
- googleでは，サービスダウンしないこととレイテンシーが落ちることが許されない
- bound's leader
- クラウドでは開発において，迅速さが求められる
- ローンチ&イテレート
- グーグルではマーケットリサーチなどあまり参考にしていない
- 市場が存在しないときは正しい解はない．
- WEBはユーザの使われ方がわかるので，それを最大限に活かす．
- これらができるのはデプロイコストが安いから．
- クラウドではバージョンの考え方がない
- 絶え間なく成長していくから．
- リニアに進化していく
- リニアに進化させていく際には，スケールすることが大事
- 5000以上の開発者
- 2000プロジェクト
- 毎月50%のソース変更
- 人による管理は無理．なので，自動&スケール．
- 従来13週ごとのリリースだったが，今は6週ごと
- オーバーラップする部分を削除
- グーグルではオープンにしないことが問われる
- 得られるメリットのほうが大きい
- フィードバックが得られる
- 得られるメリットのほうが大きい
- 日本語入力
- テーマ；ストレスフリー，素早い入力，WEB時代に即した
- ベースにセキュリティ，プラットフォーム&アプリケーション互換性
- テーマ；ストレスフリー，素早い入力，WEB時代に即した
- build orb，アルパカなど楽しく
- クラウド時代のソフト開発
- 短いリリースサイクル
- スケール手法の採用
- 可視化にこだわる
□OpenJam
□野村さん，市谷さん-未来の為に私たちの帆を立てよう-
- 野村さん背景
- 富士ゼロックスの第3の事業とするべく，15年前位からナレッジに関する事業開始．
- ナレッジ・サービス事業KDI (Knowledge Dynamics Initiative)
- 著書として，“裏方ほどおいしい仕事はない!”，“サラサラの組織”
- 富士ゼロックスの第3の事業とするべく，15年前位からナレッジに関する事業開始．
- 市谷さん
- 対話するには勇気が必要．その勇気をこのセッションで持てたら．
- 会社に帆を立てるにはどうしたらよいか．
- フューチャーセンタが広まってきている
- 問題が複雑になってきているため
- 解がない問題
- 問題が複雑になってきているため
- フューチャーセンタ
- 各事業部からの問題を社内外のステークホルダで解決する
- 市谷さｎ：Devloveっぽい
- 革新生産性モデル
- 革新のスピード
- ローカルな革新
- 連携した革新
- 全社的な革新
- やろうとしたことにすぐ組織が動く=サラサラの組織
- 効率追求がどろどろ感を生んでいる
- 革新のスピード
- クリエイティブ・モードを作るには．
- 内を見ていると現状の延長しかない．外や世界を見ていかないと広がらない．
- 仲間と約束する．
- 他人の#4tateを見て参考に．
- 思ったときに各．帆を立てる．
- 暇だと休み，忙しいとピークな働き方を変えるには．
- 川口さん：忙しいことにはあらがわず，やりたいことなどをメモしておく．暇になったら，メモを見て忙しくなることに備える．
- 岩切さん：やりたいことをメモしておく．
- コンサルティング業は時給を上げる
- ぶらぶら50％
- 客の知らないことを知る．経験したことのないことを経験する．
- 気づいてもらうためにずっとやる
- 問題解決と少しの感動
- 仕事の本質
- 野村さん：自分がやりたいことを求める客を捜すゲーム
- 岩切さん：世界を変えるために，開発者を支援しよう
- 市谷さん：誰かと何かを作る．二人で新しい価値を提供できる．
- 負のスパイラル
- 目標→仕事をリスト化し分配→一人の目標を決める→達成レベル管理→達成しない場合には罰→目標
- 正のスパイラル
- 目標←他人を助けたことをほめる←助け合う行為を見える化する←一人一人の不安感を共有する←目標達成したときのイメージ共有←目標
- これにより，クリエイティブ・モードを作れる．
- -
