2012年2月アーカイブ

ソーシャルゲームをスクラムで開発してるんですが、社内の(隣の部の)プロダクトオーナー (Product Owner : PO) にデモをしたら
「なにこれ、すげーじゃん!もう出来てるじゃん。これで出しちゃおうよ!」
って言われた。

Potentially Shippable Increment を作る、ということがちゃんとできたんだなぁ、と思った。

資料やドキュメントで語るよりも、あるいはコードで語るよりも優れたコミュニケーション手段は動いているものを見せることだと思うので、スクラムはゲーム開発に向いていると思う。


From Legacy to Agile ~レガシー開発からアジャイル開発へ~

  • 野口さん
  • 塩谷さん
  • レガシー開発からアジャイル開発へ
    • 移行するのに障害があるはず。それをどのように乗り越えていくか。またキャリアデザインなど

アジェンダ

  • 3周回った俺達のアジャイル
  • レガシーの現実
  • レガシーからアジャイルへ
  • クロージング

3周回った俺達のアジャイル

  • 塩谷さん
  • dwango の中の人。1月からドワンゴモバイル。

このセッションについて

  • 去年の9月にXP祭りで喋ってきた内容の再演みたいなもの
  • もう少し時間をかけて、大勢の前で喋りたいと思った
  • カオスなゲーム開発からSI式ウォーターフォール(略)アジャイルという草原にやってきました
  • 一昨年のdevsumiで、 @yoshiori さんの3周遅れのXP → ベストスピーカー賞
    • その時はまさか同じ会社で働くことになるかとは思わなかった
  • 一昨年そのセッションで感銘を受けた人が、実際に現場に入ってみてどう感じたかを紹介します

きっかけ(社内事例紹介)

  • きっかけ1
    • ホワイトボード1枚にタスクボードとバーンダウンチャートをつけている
    • 新卒で入って1年目、がんばってタスクボード更新したりしてる
  • きっかけ2
    • プランニングポーカーをして見積もりをしているチームがある
  • きっかけ3
    • コードレビューをたくさんやっている
    • ペアプログラミングが大好きで、作業量全体の半分くらいはペアプロでやっている
    • セオリー通り、キーボードを奪い合うような感じではなく、後ろでコード書いているところを見守るとかしてる
  • きっかけ4
    • 朝会(夕方やっているので夕会)
    • イテレーションを1週間でやっている。リリースとはリンクしていなくて、振り返りするための区切りにしている
    • KPTをアレンジ -> KPTZ
    • Z -> 雑感
    • 「今日は8/33。夏休み終わりたくないでござる」
    • 「烏賊がなくなりそうでござる」
      • 大所帯なので、コミュニケーションの役に立っている
  • 傾向
    • 導入プラクティスは割りと共通
      • 朝会、CI、バーンダウン、
    • アレンジを恐れない
      • 本に書いてあるとおりに続けて硬直化して続かないよりも、現場に合わせた方がいい好例
    • 飢餓感
      • プラクティスに縛られない。自分たちのチームをよくしていこう、という意識が強い
  • アジャイルサムライが発売されてすぐの時期のこと
    • 「今までやってきたことに名前がついているのを知った」

まとめ

  • 高速道路がたくさんある
    • こうするとうまくいくことが多い、うまくいく可能性が高い、という知識は本とかWEBに書いてある
    • 高速道路を活用すればいいが、現場では守破離が大事
    • 守 → 最初はセオリー通りにやる
    • 破 → アレンジしてみる
    • 離 → 自分たちのやり方を確立させる

自分がやったこと

  • 壁にホワイトボードでタスク看板作成、みんなで(企画職の人も含めて)朝会
  • 見える化されたので、他職種の人ともタスク量を共有することができた
    • こういうアナログなツールは、Redmineとかよりも効果を発揮するケースがある
  • 事例を紹介しましたので、devsumiの「次は君の番」の慣例に従って、あなたのところでもやってみてください

レガシー開発の現実

自己紹介

  • 野口さん
  • 2011年12月に転職。dwangoの中の人。ニコニコ静画とかやってます
    • それまではエンタープライズ向けシステム開発

レガシー開発とは

  • 開発をレストランだと考えてください
    • 予約されたコースをその通りに出す(フルコース)
    • カウンターで、お客さんと話しながら一つ一つ注文していく
  • それぞれにメリット、デメリットがある
    • 結婚式とかのパーティーに向いているのはどっち?
    • 無駄が多いのはどっち?
  • カウンターで、お客さんと話しながら一つ一つ注文していく → アジャイル
  • 予約されたコースをその通りに出す(フルコース) → レガシー
  • 変更を許容しない
  • 顧客と開発者は別
  • 決められたとおり(仕様書)に従ってモノを作る

現場のあるある

  • ヒトが倒れたりするw
  • それ、〇〇さんの書いたコードなんで
  • 「なんかいけてないんだよねー」(ざっくりした要求)
    • ざっくりした要求をマネージャーが部下にRT(右から左に流すだけ)
  • 「仕様書とテスト項目少ないよ」 → 「え?これ以上どうしろと?」
    • 仕様書少なすぎるパターン
  • 「何ステップ書いた?」 → 「200くらい。見積もりより少ないです」 → 「少なすぎ。さぼってね?」
    • コード何ステップ書いた?パターン。ステップ数で生産性図る時点で問題がある
  • 「あー、今回もデスマだったけどリリースできたわー」「3日寝てねーからつれーわ」

レガシー開発をまとめると

  • 人のコードは人のもの
  • 伝言ゲーム
  • Document Driven Development
  • 開発標準 ISO9001
  • 「開発ってのは辛いもの」というイメージを持ってしまう。仕事だから辛いのは当たり前だよね

生存戦略

  • このスライド、今回のデブサミで相当見ていると思うんですけどw
  • これからこの生存戦略を皆さんと一緒に考えていこうと思います

質疑応答

  • レガシーな会社を変えることができるか?
    • できると思っています (野口さん)
  • なぜ会社を変えたんですか?
    • 人生そんなに長くないので、つまらないことには付き合いきれないなと思った (野口さん)

座談会的な

  • アジャイルに対する誤解
    • 優秀な人たち向け
    • モノだけ作る
    • お客さんのいいなり
    • 対話とかいいから、お前ら手を動かせ

優秀な人たち向け

  • よれよれと手書きでホワイトボードに書いているようなやり方でも実践できる
    • そう言えるのは優秀だからですよね?w
  • レガシーのやり方だと、数割のスゴイ人と残りの普通の人だけど、アジャイルだとみんなでスゴイことをやろうよ、というやり方。
    • できるところからみんなでやろう

モノだけ作る

  • 仕様書とかドキュメントとかは要らない?
  • 仕様書は30kg納品してください → 仕様書の単位としておかしい。環境破壊だからヤメレ
    • 引継ぎのドキュメントとか、共有にドキュメントが必要であれば最適で効率的なやり方を探した方がいい
    • wikiは便利だけど、wiki最高!は思考停止
  • エクセル方眼紙は人の心を汚す
    • 最近のエクセルは方眼紙がデフォルトテンプレート。マイクロソフトはソフトウェアエンジニアをこr(ry

お客さんのいいなり

  • お客さんを「同じバスに乗せる」というのが成功に一番近い
  • 「お客さんがこう言っているから」というマネージャーのセリフはおかしい
    • お客さんをコントロールできるマネージャーは強い。はい、というよりいいえ、といえる方が強い。それはアジャイルであれレガシーであれ変わらない

対話とかいいから、お前ら手を動かせ

  • アジャイルのツールの多くはコミュニケーションのためのものなので、対話要らないってことはない
  • 朝会が「朝礼」になっちゃっているとかヒドイ。1時間朝礼で立ちっぱなしとか
  • 開発現場でしゃべるか?
    • その場の空気。隣の席の人とチャットすることもあれば、大声で話すこともあるし

アジャイルはじめるには?

  • ドキュメントどうする?
    • 砂でも入れておけば。アマゾンで1トン買うとか
    • 全くドキュメントを書かない、と思っている人がいるが、そんなことはない。必要なドキュメントは書く
  • ペアプロの生産性
    • チームのコードの作り方を学んだり、教育にとても有効
    • 書いたものをレビューするよりも、書きながらレビューする方が品質は高い。お得。割安。
    • コードの読みあわせ。プリントアウトしたものを1時間くらいかけて説明するようなことをレガシー開発ではやってた
  • 見積もりは?
    • お客さんとの信頼をコツコツと作っていくしかない
  • 仕様変更
    • 仕様変更は、発生するのが当然として考えておかないとダメだと思う(野口さん)
    • 仕様変更が発生するのは、別に誰も悪くないと思う(塩谷さん)
      • エンジニアにできるのは、仕様変更に強い作りにしておくことだと思う
    • レガシーな開発だと100%納品が求められる
  • スケジュールは
    • 確定するのは難しいので、だからこそお客さんを巻き込むのが重要
    • 正確な見積もりは不可能だし、要件はどんどん変わっていくので、外れた時にどうするのかコンセンサスをとっておくことが大事
    • ガントチャートがない世界に行きたいw
      • 変化がある以上、期日通りにはなかなか難しい

アジャイル関連書籍

  • アジャイルマニフェスト
    • レガシーなものとアジャイルの対比、で書かれている
    • 10年経っても色褪せない
  • アジャイルサムライ
    • 各地で読書会が開催されているヤツ
    • カッコ悪さを隠していないところがいい。脱力しまくりのイラストとか、それが現場のリアル
  • アジャイルプラクティス
    • Javaとかで言うデザインパターンとかに近いような気がする
    • 八重洲ブックセンターで「なんじゃこりゃ」って手にとった本。衝撃的だった。
    • 現場で試しにやってみよう、というのであればアジャイルプラクティスは最適。朝会とかやり方が具体的に書いてあるし。
  • アジャイルな見積もりと計画作り
    • 見積もり手法について書いてある。計画ってのは立てて完遂するのが美ではない。いかに修正するか
    • 自分のチームの生産性を把握しておくことが重要
    • チームが5~6人以上であれば、読んでおくことをオススメ

プランニングポーカー

  • 他の人のタスクであっても、みんなで見積もりして共通認識を作るのって大事
(第2部は手書きなので後ほど・・・)


  • 見入ってしまって全くまとまってない

アジャイルマニフェスト ディケイド

  • 角谷さん

自己紹介的な

  • 「ご講演いただく感じじゃぁないですw」
  • E和のRubyistです
  • Ruby Evangelist in Japan
    • Ruby会議を運営していました
  • アジャイルサムライという本を同僚と一緒に翻訳しました
    • もともと洋書なので、サムライは Jedi くらいに捉えるといいかも

宣伝

  • 3/24 Agile Samurai Dojo Gathering @ オラクル青山センター
    • スポンサー募集してます

これまでの振り返り

  • 2001年2月、アジャイルマニフェスト
  • アジャイル以前の主流はウォーターフォール式のソフトウェア開発
    • 人工のソフトウェア
    • 経済的な要請に基づいて、要請されたソフトウェアを作成する
  • HWの進化、要素技術の発展、全球的ネットワーク、ビジネス変化の加速
    • 自然なソフトウェア
    • ウォーターフォールの作り方に合わない
    • 不正義。正義が行われていないというのが20世紀末の状態
  • Kent Beck -> XP
    • 建築の手法をソフトウェア開発に持ち込んだ
  • ココらへん話すと長いので、パターン,wiki,xpを読んでください

アレグザンダー

  • 少しずつ成長させる
  • 人間の完成に深く基づく
  • 繰り返し実施される

今日のタイトル decaed

  • decade = 10年
  • ググると仮面ライダーディケイドが出てくる
  • 仮面ライダーディケイドの説明
    • (興味ないんで省略)

  • ソフトウェアの作り方は決まっていた ie. water fall
    • それが今は前提として回らなくなってきている
    • 決められたやり方でやればいい、という時代は終わった
  • water fallじゃないやつって、どうすればいいのか
    • 一人一人がやらないといけない時代

現在のアジャイル

  • 受け入れられている
    • イギリス政府で採用されたりしている
  • そういう一般的な話はいろいろなところに書いてるので、今日はそういうところに出てこない話をする

The Nature of Software

  • Nature => 本質的なもの、特性、特質
    • 人とソフトウエアの間に価値がある
      • ソフトウェアに価値があるのではなく
    • システム全体を構成する
    • 変更に対応できることが求められている
      • 「ソフト」なんだから、本来変更に対応できるはず
    • 人がソフトウェアを使ってみないとわからない
      • 動かすのにハードウェアやドキュメント、場合によっては運用支援も必要
      • 変化に対応するために、作りっぱなしじゃなくて変化に対応しないといけないがなかなかそうはいかない、技術的負債がある

人とソフトウェアの間に価値がある

  • ソフトウェアは頭の中にある
    • 目に見えない
    • 使った人が「あ、こういうことね」と認識するもの。使ってもらって、FBをもらったりしないとわからない
  • ビジネス要求からビジネス価値につなげるまで、end-to-endのサイクルをつなげていかないといかん

変更に対応できること

  • Programming as thearoy building
    • プログラミングは世界観を構築して、それを創りだすこと。文字列を並べる簡単なお仕事ではない
    • プログラマがどう捉えて、どう表現しているか
  • 変更できるようにつくらないといけない
    • "「コードはドキュメントである」と受け入れることだ。それからコードをクリアにしようと務めること"
    • コードにしたことと、しなかったことがプログラミング
    • どういう世界観をコードを通じて伝えれば伝わるかを考えて、プログラマはコードを書く

自然のソフトウェア

  • 人工のソフトウェア
    • ビジネス上の要請に基づいて作られる、仕事のソフトウェア
  • 自然なソフトウェア
    • Free / Open Source Software
    • Bazzar style
    • 使われるソフトウェア

開発プロセス

  • 人が作るので、そこにプロセスは何ら頭の形で存在する
  • アレグザンダーのパターンによる建築プロセスの特性
    • 少しずつ成長させる
    • 人間の完成に深く基づく
    • 繰り返し実施される

アジャイル開発

  • you can't do agile.
    • アジャイルは名詞ではなく形容詞。アジャイルをやることはできないが、身軽に、活発にいきいきと動くってこと
  • どれだけアジャイルにできているか、度合いを形容するもの。プロセスがどれだけいきいきとしているかを示す度合い
  • 現場は全部異なるので、全部に当てはまるものはない。その場状況に当てはまるものを作り上げていくしかない
  • スクラムの概要
    • 軽量
    • 理解が用意   * 習得は非常に困難
  • 3回おこればパターン、名前をつけると流通する、流通すると他の人が使うようになる
  • 名前の後ろに、問題が起こっているコンテキストとか、解決方法とか制約があって、それらが全く同じという現場はない
  • 朝会で「今日やること」を聞くのと「今日ぶちかますこと」を聞くのの違い

アジャイルマニフェスト

  • 噛み締めて呼んでください
  • 自分だったらどうするか、という視点で噛み締めるように

次の10年に向けて

  • アジャイル開発はもう皆知ってるし、一つのゴールにはきた
  • 自然なソフトウェアに近いものを、どう人工的なソフトウェアの環境で作っていくか
  • Social Coding で他の人と関わるとか
  • やれることを一生懸命やる
    • やれることだけやっているとなかなか先に行けないけど
  • アジャイルは素晴らしい考え方だけど、その考え方に対して問を発していく
    • 答えは自分で探す


Scrumで組織改革

  • 貝瀬 岳志さん
  • SIer -> ゲームポータル -> DeNA(4年前)
  • 2011年夏から、スクラム導入を開始
  • 2011年秋、認定スクラムマスターに

why do we scrum

背景

  • スマートフォン業界が急成長

課題

  • 経営目線の課題
    • アウトプットやスピードが上がっていないように見える
    • 新人が増えても、意味のあるアウトプットが増えていない
    • 新しいアプローチやスケールする取り組みがない
  • メンバーの課題
    • いつもやることが多い
    • 周囲のやっていることがわからない
  • ここまで聞いていると、「残念な組織」と感じる方もいらっしゃるかもしれmせん
  • 課題を解決し、自己成長型の組織にしたい
    • スクラムを使って現場の課題を解決することにした

なぜ問題なのか

  • 困難なスケジューリング
  • 不明確な責任範囲
  • 放置された問題、課題

なぜ緊急の案件が多いのか

  • 目の前のタスクに追われていて、やらなくてはいけないことが見えていない
  • 優先順位の認識が人によってバラバラ、というのが根本的な原因
  • どうすれば優先順位を適切に付けられるのか、がこの課題に対するアプローチ

どうして責任が不明確なのか

  • 組織の目標とかわかってないし、頻繁に組織が変わるし
  • どうすればお互いの目線をあわせらるか
  • 役割の可視化とマインド

なぜ目先の仕事を優先するのか

  • どうすれば、課題や問題に真摯に向き合えるか
  • 日々の作業と同じくらい、課題解決や問題解決が重大なことだ、と認識する

なぜスクラムなのか

  • 先程の課題を解決するのに適していると考えたから

スクラムとは何か

  • (メモ省略)

導入実例(時系列) Phase1

トライアル

  • スマートフォンモバゲーのリニューアルプロジェクト
    • UI設計を海外、実装を日本という特殊な構成
    • 海外
      • SM * 1 IA * 2, Graphic *2
    • 日本
      • PO * 1, SM * 1 eng * 4-6
  • 海外のデザイン会社がスクラムをやっていたので、日本でもそれをやることにした
  • Daily standup を朝と夕方の二回実施(時差の関係で)
  • プレプランニング、プランニング、
  • ツール
    • Basecamp でプロダクトバックログの管理
    • 日本国内では Basecamp の情報をホワイトボードと付箋に貼り出した → 見える化
    • 全く同じ情報をJIRAにも登録

振り返りの結果

  • KPTでProblemとtryばっかり、よかったことがほとんどなかった
    • 朝会がなかなか終わらない(人数が多かった)

スクラム導入の課題がどうなったか

  • スケジュール、優先順位について
    • スプリント単位で優先順位を合意できたので、突発案件は減った
    • 日々のdaily standup meetingで日々の優先順位も調整できた
    • スクラムをやっていないチームからの差し込み
    • 会議やツールがうまく機能していなかった
  • 責任の範囲が不明確だったこと
    • プロジェクト内部で責任の所在が明文化された
    • POが意思決定できない状況やSMが解決できない状況もあった
  • 放置された課題・問題
    • 振り返りを使って問題提起、改善のサイクルが回り始めた
    • 助け合いができるようになった
    • 大きな問題ほど先送りになった

導入事例 Phase2

  • トライアルが終了した直後に、スマホ版モバゲーを運用する企画・開発部門でやってみた
  • Phase1からの教訓をいかし、企画者と開発者を1箇所に集めた(もともとは別の席だった)
    • 背中合わせとか隣に
  • Phase1で人数が多すぎて朝会が破綻したので、10人以内に収まるようにした
  • Sprint 0 を1~2週間実施した
  • 使い慣れたツールに集約して整備した
    • もともとJIRAに使い慣れていたのでJIRAに
    • 付箋とホワイトボードは二度手間なので、思い切ってデジタルに一本化した

チーム

  • ミッションごとに4つのチーム
  • 各チームにSMとPOを1人ずつ
    • 他プロジェクトとも兼任
  • チームメンバーーは専任

Sprint0のテンプレート

  • 経験の浅いスクラムマスターでもできるように、テンプレートを作成した
    • ミッションの明確化
    • 責任範囲の明確化
    • 役割の明確化
    • ストーリーの抽出
    • プロダクトバックログの作成
    • Doneの定義

Phase2 振り返り

  • 困難なスケジューリング
    • 突発案件は減った
  • 不明確な責任範囲
    • プロジェクト内部の責任の所在が明確に
    • チーム間のポテンヒットみたいなものは減った
    • マネージャー経由で担当をアサイン、というボトルネックが解消された
    • POが意思決定できない状況やSMが解決できない状況もあった
  • 放置された問題、課題
    • バックログがなかなか増えない
    • スクラムの進め方に否定的なメンバーやチームが出てきた
  • スクラムの理解が浅いまま実施すると逆効果
  • スクラムだけでは解消しない問題もある
  • 問題の可視化やチームの成長を促すフレームワークだと実感できた

立て直し Phase2.5

  • スクラムの理解を深める
  • 時系列で振り返って今後に活かせるようにした

理解を深める

  • 認定スクラムマスターに
  • その内容を社内に持ち帰ってワークショップ形式でFB
    • Phase2 のふりかえりをやって、問題を集めてどうしたら改善できるかのアイディア出しをしてもらった
  • 振り返りの風景 (写真)
    • 壁に付箋を貼って、改善したいこと一覧を書きだしてバックログとして管理
    • 課題の振り返りをした。振り返りの機会はよい場だったと実感してもらえた
  • ものづくり以外にもスクラムはフレームワークとして使える

Phase3 アレンジ

  • 自部門の開発に関わる前組織で導入、12のチーム、100人を超えるメンバー

アレンジした点

  • スクラムは突発案件は受け入れないが、受け入れることにした
  • チーム構成を変えることも容認した
    • 組織自体や市場の変化に対応していかないといけないので
  • ストーリーの定義
    • ユーザーに提供するものの終わりが見える課題や作業
    • エンジニア、UIデザイナなどが見積もりできるもの
    • ポイントで見積る
  • プレプランニング
    • プランニングの前に、全体の優先順位を決めるための会議。全マネージャー、全PO、全SMが参加
    • この結果次第で次のスプリントのメンバーを変更したりする
  • スクラムマスター会議
    • 各チームのスクラムの状況を共有する会議
    • 良かったことはルール (common rule)に反映して共有する
  • EPICの定義
    • ストーリーの上位に来る概念、企画者やアナリストが使うもの
    • ストーリー同様見積る。EPIC自体の事業価値。基準値は売上
  • スクラムのスクラム
    • メンバーが10人以上の場合はサブチームに分解し、サブチームごとにDaily Scrum
    • プランニングなど、その他は全員参加
    • バックログも全チームで共有

ScrumでどうJIRAを使っているか (デモ)

  • JIRAにストーリーを追加
  • product backlog -> spring backlog にドラッグ&ドロップで移動
    • 移動後の product backlog は「ただやりたいことの一覧」
  • メンバーは「その日に作業する」ものを TODO から DOING に移動
  • 時間を入力すると、burndown chart に自動で反映されて進捗が可視化できる

導入の結果

  • 結果的に何が起こったか
    • マインド
    • 自己組織化
    • 生産性を可視化できるようになった

マインド

  • チーム間だけじゃなく、他部署とのコミュニケーションが良くなった
  • 素直に意見交換ができるように
  • 振り返りをすることで、自発的な改善サイクルが生まれた

自己組織化

  • 新規プロジェクトがスクラムで動いている
  • 担当が変わっても生産性が落ちない
  • バックログが増えている

生産性可視化

  • JIRAのグラフ?
    • ストーリーの追加に追従して、消化したストーリー数も増えている
    • Burndown している
  • 見積もりの精度が上がった
    • 過去のブレが大きかった見積を、チームの振り返りで見直す

課題はどうなった?

  • 冒頭で述べた、経営者目線からの課題とメンバー目線での課題、いずれも改善されてきたと感じている

困難なスケジューリング

  • POに優先順位が一任
    • 改善された
  • バックログで管理ができる
  • スケジューリングの参考になる指標が可視化されたので、可能性の高い粒度で考えてもらえるように

不明確な責任範囲

  • PO / SM / チームの責任を明文化した
  • チームのミッションも明文化した

放置された問題、課題

  • 振り返りを実施するので、放置されることはなくなった
  • システム改善スクラムを立ち上げて、専任で対応するということも
  • 有志をつのり、プロジェクト横断で改善するような組織も作った

まとめ

  • スクラム大変
  • 効果はあった
  • ぜひトライして
  • 半年やってダメだったらDeNAにきて僕と一緒にスクラム!

言語の世界

  • 松本さん

  • マニアックな話ばかりするので、明日の仕事には役に立ちません。他のセッション出たほうが役に立つと思いますw

  • Rubyを作ったけど、言語好きです

プログラミング言語って

  • プログラム = 手順書
  • プログラミング言語 = 手順書記述用人工言語
    • コンピューターは道具、何かコンピュータで達成したいことがある
    • コンピュータに達成させたいことを記述するもの
    • 自分の理想はなにか、思考の表現をするため、具体化された思考を記述するための実行言語
  • せめぎあうふたつの立場
    • 機械のためか、人のためか、という立場がせめぎ合う

プログラミング言語の歴史的な話

  • FORTRAN
    • FORmula TRANslator
    • 1954年に登場した、世界最初のプログラミング言語
    • アセンブラも存在していなくて、マシン語をそのまま書くような時代に登場したので、画期的だった
    • 「コンピューターのためではなく、人間が楽をするために」
    • 背景:コンピュータが遅かった
      • 1985年のスーパーコンピューターとiPhone4の処理能力がだいたい同じ
    • フォートランの頃は「言語の常識」がなかった
  • LISP
    • LISt Processor
    • 人間のために始まったもの。機械の都合ではない、という点でFORTRANとは対照的
    • ラムダ計算モデルを表現するために作られたものを、そのままコンピュータで動かせば動くんじゃね?って動かしたら動いた
    • IBM704計算機
      • car : content of address registerr
      • cdr : content fo data register
    • ガーベージコレクタ
      • 実装されていた。一般的になるのはJavaの登場によって
  • FORTRANとLISPでバトルしてたら、最終的にAlgolが勝った
    • Algol -> PL/1 とか Pascal とか
    • みなさんが使っている C, C++, Java あたりは Algol 属
  • Lisp へのゆり戻し
    • Smalltalk、Ruby
  • プログラミング言語におけるカンブリア爆発
    • 1960年代~1970年代前半くらい、多種多様な言語が乱立する時代。アイディアなどが次々登場していた時代が
      • C : 1972年
      • Simula : 1967年
      • Shell : 1971年
    • 変な言語も
      • Prolog, APL, アクターモデル
    • 2002年、はRubyもJSもJavaもあった。この10年くらいプログラミング言語は大きな変化はなかった
    • 1960年代~1970年代に生み出されたアイディアを食いつぶしているような状態
      • 「どうせ既存のものの組み合わせさ」
  • 人気の言語はそれなりに新しい。ここ数年で新しいものはあまりないけど
    • Java : 1995年
    • C# : 2000年
    • Scala : 2003年
    • Erlang : 1986年
    • Ruby : 1995年
    • PHP :
    • Perl :
    • 「言語の世界じゃ10年くらいはまだまだはなたれ小僧」

新しい言語の動機

  • 作りたかったから
    • 30年前に雑誌とかみてて、プログラミング言語を作りたい、と思っている人が5人に1人とかいるだろうと思ってたら、実は全然いなかった
  • 新しいパラダイム
    • オブジェクト指向とか、関数型とか
    • ここ20年くらい新しいパラダイムは登場していないので、どちらかと言うとそれらの組み合わせ
      • 並列型と関数型の組み合わせ、とか
      • 組み合わせで難しいのはバランスよくする、使いやすくすること。組み合わせるだけなら簡単
  • 新しい環境
    • 新しいCPU、メモリが増える、
      • WEBとかMapReduceとかも「新しい環境」
      • PHPなんかはWEBで普及した言語
  • 新しい制約
    • データ量が爆発的に増える(ビッグデータ)、アクセス量

どこまでが言語か

  • 文法
  • ライブラリ
    • COBOLとか、言語そのものは古臭いかもしれないけど、業務システムのライブラリやそのデザインがCOBOLに最適化されていたりする
  • アーキテクチャ
    • ウェブそのものがアーキテクチャを支援しているような
  • デザインパターン
    • 本が出た時C++プログラマは喜んだが、Smalltalkでは当然のもの(言語に組み込まれている)だった
  • コミュニティ
    • ユーザーコミュニティ、開発者コミュニティ
    • 言語やライブラリよりも、コミュニティやエコシステムが重要。言語を選ぶときはそういう観点も大事にして欲しい
  • 思想・人格
    • 使っている人、作っている人の思想とか

温故知新 歴史の振り子

  • 集中 vs 分散
    • 昔はコンピュータが高かったので、コンピューターのところに行って、処理をお願いしていた
    • 中央のコンピューターに仕事を依頼する → 集中
    • コンピューターの性能が上がるよりも単価が下がる方が早かったので、処理を分散するように向かっていったらWEBが出てきた
    • ブラウザという形の汎用の端末を通して、データがサーバーに集まる → 集中へ
    • 今はみんな amazon に移行していってるが、amazonの中では分散されている(集中の中での分散)
  • 性能 vs 生産性
    • 1950年代には「世界中にコンピューターが5台あればいい」と言っていた人もいた
      • 人間はリソースがあればあるだけ使ってしまうという悪い癖がある
      • リソースは計算パワーにしても容量にしても、あればあるだけ使ってしまう
    • コンピューターの能力を若干無駄使いしても、その方が生産性が良かったり
  • 静的 vs 動的
    • 実行性能をとって柔軟にするか、その逆にするか
  • 正確さ vs 柔軟さ
    • 積極的により早く間違いを見つけようとするか、柔軟にしてTDDなどで間違いを見つけるアプローチか

未来にある言語はどういうものか

  • APL
    • 3年前のこのセッションで話しました
    • 記号を多用する配列言語。ライフ言語プログラムが1行で書ける
    • 昔は専用の端末を使わないと記号を打てなかったのが、今はユニコードなので全部入ってる
    • 予想通り、流行らなかった
  • Whitespace
    • スペースとタブで構成されているので、これを実行するとhello worldが実行される
    • ネタですけど
  • 「新しいぶどう酒は新しい革袋に」
    • これからの時代に即したプログラミング言語が必要
    • ビッグデータ、マルチコア、クラウド etc
    • Erlang / node.js / R / SQL の発展形

Erlang

  • 関数型 + 分散型
  • 信頼性の高い分散モデルを作れる
    • 大規模システムでCPUが増えたり、クラウドでシステムを構築するノードが増えた時、メッセージパッシングによる分散は価値を発揮できそう
    • Erlang がそのまま流行る、というよりも Erlang っぽい実装をされたり、 Erlang の後継が出たりとか

Node.js

  • サーバーサイドJSの典型
  • たくさんアクセスが来るからと言って実際のCPU数よりもスレッドを上げるとパフォーマンスが落ちる。それをカバーするために非同期IOによって多重化している
    • Node.js そのものが来るというよりも、既存の言語に大量アクセス対応をする機能がサポートするかもしれない

R

  • 統計、解析が非常に得意な言語
  • すたティスティクができるエンジニアの給料が上がっているので、統計ができる方はぜひ
    • Oracle が R-ODM という Oracle に対するアクセス機能がある R を作っている
    • ビッグデータと統計を組み合わせたものに未来があると思っている

sql

  • SQLそのもの、というよりも SQLの発展形
  • SQL の良いところは宣言的にデータを取得できる
    • 「こんなデータがほしい」といえば、裏で何やってるかわからないけどデータが出てくる。非常に抽象度が高い
    • こういう宣言度の高いものが来ると思っている
  • SQLそのもの、ではなく、宣言的に使えて結果が取得できるような何か

言語の楽しさ

  • プログラミングの楽しさ
    • 言語そのものが楽しい
    • なぜ言語が楽しいか、というと、やはり本質はプログラミングの楽しさ
  • 自分の思ったとおりにコンピュータが動くというのは楽しい
  • 中学の頃、ポケコンでBASICでプログラミングしてた
    • 400ステップとか
    • 命令した通りにコンピュータが動くのが可愛い。犬にお手ってやると手を出して可愛いのと同じだと思ってる
  • 言語 = プログラミング
    • 言語の楽しさはプログラミングの楽しさに密接な関連がある
  • 処理系を作るのがとても楽しい
    • コンパイラ → 構文解析
    • コンピュータサイエンスのあらゆる領域に、すこしずつ触ることができる
  • 言語設計
    • どんな言語を作るか
    • プログラミング言語によって発想の仕方が変わる。つまり、言語設計 = 発想をプログラミング
    • RUbyを使っているとRubyの発想にそまっていく
      • まつもとさんが決めた仕様なので、Rubyプログラマはまんまとまつもとさんにプログラミングされているw

アジャイルリーダーシップと組織改革

  • 楽天 藤原さん
  • @daipresents
  • 職業
    • プログラマ、リーダー、コーチ

楽天の紹介

  • 楽天にはたくさんサービスがある。カンパニーで、開発部は1つ
  • 開発部隊を支援する部署に所属
    • 標準化、PHPだったりJavaだったり
    • ツール、subversion とか Redmine のようなツール
    • アジャイル
  • エンジニアは1000人以上、グループ数が70くらい、プロジェクトも1000以上
  • 社内の開発プロセスはウォーターフォールがベース
    • 厳守しなくてはいけない、というわけではない。言い換えれば楽天という会社には開発プロセスはない

アジャイルを導入してみたところ

  • 最初は2009年、藤原さんを含めて3人
  • チームのモチベーションがあまり高くない状況、閉塞感があってミーティングでもネガティブな話が多かった
  • まずはじめにXPを導入してみた
    • 「XP エクストリームプログラミング入門」本を買って、やってみた
    • ペアプロを始めた
      • 3人しかいないから、リスクヘッジも目的
    • レガシーコード改善のため、CIを導入
      • テストがなかったりするので。テストの無い文化にテストを導入するのは難しい
      • テストすることでリリースが遅れることを懸念した上司に「どこまでやるの」と言われて「最低限やりましょう」で決着させたが、最後で裏切った
      • 上司が正しいとは限らないじゃないですか

規律

  • まかせる
  • チェックはする
    • チェックポイントは決める
  • 週一回のマネージャーの報告とか、朝会とか
  • 攻めの選択をする
    • 一つの判断が、全部署について正しい判断とは限らない。とか言っているとなかなかよくならない。
    • リスクありきでどこまで攻めるかを考えましょう

工夫したこと

  • 「それはロックか?」
    • もっとロックなことやっていきましょうよ!
  • 時間
    • 開発の時間を確保するため、ライブラリを作った。ライブラリ数が当初比3.5倍
    • 月に100時間くらいは開発以外の作業をしていた
  • Unit Test の割合
    • 40%くらいがテストの時間に。初期のリリースまでの時間が長くなった気がする
    • が、楽天のビジネスはリリースして終わりではない。サービスが続く限り作業が続く
    • なので、リリースしてから「過去のテストがあってよかった」が生きてくる
    • 運用が長く続けば続くほど、テストの価値が高くなる

アジャイル開発を展開してみたところ

  • アジャイル、CI、自動化を社内に展開

CIのアラートメール数

  • 成功したチーム
    • 最初は下がるんだけど、コミットした瞬間に増える。それがまた下がる
    • ビルドを安定させようとする意思が感じられる
  • 失敗したチーム
    • 質の悪いコミット文化が根付いている
    • アラートメール数のグラフが下がらない、横ばいになる

自動化の効果

  • Capistrano を使った。時間が75%削減できた
  • 自動化の広がりは最初は早かったが、徐々に普及速度が遅くなった
    • 始めてみたけど、難しかったとか

結果

  • CIも自動化も全然浸透しなかった
  • アジャイルも浸透しないんじゃないか?と思った
  • 新人研修でがっつりやってみた
    • 60+ 人の新人でやったら、できちゃった。もしかして、老害?

やり方を変えていった話

  • 他部署と連携
    • QAにCIを連携
    • プロセス改善
    • 育成協力
      • 社内にスクラムマスターを増やしましょう

結果

  • うまく行かなかった
  • 一緒にやっている感がない
  • 部署は隣同士なんだけど、レポートラインも目標設定も違う。連携がしにくかった
    • 一緒に働くってのが難しい、というのを実感した
  • 自分のやっていることを2010年くらいに整理してみた

やっていることを整理して考えなおした

  • 工場 vs 創造
    • 楽天のビジネスは工場的な要素が強かったので、ソフトウェア開発があるべき「創造」の方に引っ張っていく方が良いのではないか、と思った
  • 乱立アジャイル
    • 社内に色々あった
    • 勘違いアジャイル、ひどいアジャイルもあった
  • 軽い気持ちで導入した人が失敗して「アジャイル使えない」という評価がされてしまうのが嫌だった
  • アジャイルが残念になる前に、成功事例を作ることにした。そのために、今までの普通を全否定することに

今までの普通を全否定

  • その承認プロセスは本当に必要?効率的?
  • 楽天主義
    • コップに半分の水 → もう半分しかない、か、まだ半分残っている、か
  • 新技術は積極的に導入していきましょう
  • アジャイルは本気でやりましょう
  • 積極的にチャレンジしてきましょう
  • 現場にアプローチしても伝わらないので、現場でアプローチする。見えないなら見に行けばいいじゃない。

現場に行ってみた

  • ほとんどが新人と若手、教育が行き届いていない
  • レガシーコード山盛り

やってみたこと

  • 朝礼。ちょっとでも遅れてきたら発言させない
    • 自分に関係しそうな所に耳を傾けるようになったり、だんだん慣れてくる
  • 見える化
  • イベントに積極的に参加させる
    • 外に出て行って、会社とのギャップをどんどんフィードバックさせた

良かったこと

  • スピードが上がった
  • 楽しかった
  • 一体感があった。他部署との仕事で一体感がここまで感じられるとは思わなかった

定量評価

  • 開発時間が6倍に
    • つまり、それまでは優先順位付けができていなかった
    • 横槍の作業が多かった。プロジェクトに集中することができた
      • ちょっとくらいならいいよね、がものすごく邪魔
  • カバレッジ 98%、バグ 0.02%
    • 後でやればいいじゃん、がやらなくてよくなった
  • 問題点
    • 3ヶ月の準備期間
    • ビジネスへの展開

止まった

  • もともと問題があったから改善したが、元に戻ってしまった
  • アジャイルでもウォーターフォールでもなんでもいいんだけど、改善しようということをやらなくなった
  • 失敗から学んで、再度チャレンジした
    • 現場改善の熱意は人を変えて人を育てる

リーダーシップと組織改革を考えた

アジャイルは組織を変えられるか?

  • マネージャーが介入してこない形、が重要
  • 介入してくるマネージャーだと失敗する
    • チームでやっていることが、マネージャーによってひっくり返されてしまう
  • 楽天に1000人エンジニアがいる。1年で20人どうにかするのは、組織改革じゃぁない。全部変えるのに半世紀かかる
  • 今年は20人を支えて、ねずみ算式に増やして行けばいいんじゃん、という考え
  • 自分はやるけど、相手には求めない
  • ファシリテーションスキルが、アジャイルリーダーには必要なんじゃないか
  • Agile leadership model という資料に色々まとまっている
    • servant leadership
    • self organize
    • flat
    • empowered
    • self directed
    • merit based
  • チームを勇気づける (empowered) は共感できるところ

一番伝えたいこと

  • チームを勇気づける、ってのが一番重要
  • 表紙の写真は横須賀にある三笠のマスト
  • Z旗
    • 「客員一層奮励努力せよ」
    • この号令が全員を奮起させた
  • チームにがんばれ、頑張れと言い続ける仕事だった
  • 最終的に相手を信じてまかせるのが一番いい
  • アジャイルやってると社内にも仲間ができるが、社外にも、海外にも仲間ができる

Yahoo! アジャイルクロニクル

  • Yahoo の中でアジャイル開発の推進役
  • 取り組みの参考になれば幸いです

アジャイル (Scrumの実践)

  • 8サービス、11チームで、推進役のコーチチームがサポート中

コーチ編

自己紹介

  • 高橋 一貴さん
  • Yahoo R&D統括本部
  • Scrum道スタッフ
  • @kappa4

1. 社内アジャイルコーチ誕生

  • 2010年8月、恵比寿にあった小さなベンチャー企業の買収
  • そのベンチャー会社が、ずっとアジャイル開発に本気で取り組んでいた
  • 買収に伴って、サービスをやっていたエンジニアが辞めたりした
  • この会社の存在意義を考えた
  • 買収された会社で scrum master をやっていた
  • Yahoo! はウォーターフォールだけ、と聞いていたので、メスを入れることに
  • 配属希望を、標準化チームにしてくれ、と。ウォーターフォール開発をひっちゃかめっちゃかにしてやろうという野望
  • 蓋を開けてみれば、アジャイル開発を検討し始めていた
    • 敵だと思っていたら、実はそうではなかった
  • アジャイルコーチを名乗る
    • 会社の正式な職種名ではないが、自分で名乗っている
  • 向いているなー、と思う資質というか状況
    • アジャイルを何年もやっている
    • 組織の文脈を知らない方が、自然にこうやってやっていきましょうと摩擦を起こせる
    • 「Yahooのこういうことは・・・」と第三者目線で見れる
    • 保身を考えずにモノを言える。買収された会社出身なので、Yahooへの帰属意識が無い
    • 開発をよくしていきたい、という思いがある
    • 会社を買収してアジャイルに詳しい人を雇うのはレアケースだと思う
      • 普通はアジャイルコーチを雇うとかする

2. 二人三脚で進む

  • 攻めと守り
    • 攻め → 前線を切り開く
    • 守り → 社内制度を整えるとか調整とか
  • 両方やるためには、二人三脚が良い
    • 社内のことをよくしらない高橋さんと、社歴の長い人がコンビを組めたのが良かった
    • 守りを固めてくれる相棒がいてくれたから、安心して攻められた
  • 推進の進め方
    • ルール作りから始めましょう、という話をYahooにジョインしたタイミングで「ルールを最初から作るのは辞めましょう」とした
    • ルールが実際の運用に耐え切れず、形骸化してしまうため
    • 開発プロセスは文化といって差し支えない。ルールで積極的に行動を促していくのは難しい
    • 小さな成功事例を積み重ねていくしかない
    • 成功した人の心の火になって、それが大きく広がっていく
  • テストプロジェクトを探す
    • 社歴の長い相棒の人脈で、適切なプロジェクトを探した
    • アジャイル開発の基礎知識、みたいな社内セミナーをやって、アジャイルに興味がある人を探した
    • AIDMAやAIDAのような心理プロセスを意識
      • 知ってもらう、興味を持ってもらう、やりたくなってもらう、やってもらう
  • 共感大切
    • 現場の人からリーダーの人まで、漠然と感じている不安感を積極的に引き出すようにし、共感を表して寄り添っていくことを大切にした
    • ダメならいつでもやめていいんですよ、頑張るなら経験者として全力でバックアップしますよ
  • コーチの関わり方
    • 教示的
      • やり方を事細かに支持する。Scrumマスターとしてがっつり入っちゃう
      • 違うやり方なので、プロフェッショナルとしての仕事のやり方の理解を深める
    • 質問的
      • 目の前にあるものを質問することで、気づき→理解に
    • 委任
      • だんだん理解してきたら、ある程度まかせる
  • シチュえーショナルリーダーシップ (SL理論) を参考にしたりした
  • チームの成熟
    • 守破離
  • 会社の制度をなおざりにしない
    • J-SOX, ISMS
    • 業務の邪魔をしないで、どうやってこういうものを取り入れていけるか、担当の人も悩んでいた
    • 敵だと思っていたら、向いている方向は一緒だった

3. 公式化

  • やってみたチームのポジティブな反応
    • 楽しそうに仕事している
    • 他の人がなにをやっているかがわかる
      • 副次的な効果。本当は開発スピードを早める目的だった
  • やってみたチームのネガティブな反応
    • スプリントで成果を求められるのが辛い
    • スキルセットにばらつき
  • 1年間、テストしてみた
  • 生産性向上
    • 平均77%UP(Scrum取り組み開始から)
    • ウォーターフォールとの比較はしていない。ウォーターフォールで生産性を比較する方法がないから
    • 慣れの部分もあるが、それ以上の効果はあったと思う
  • 品質
    • 重大な障害は発生しなかった
    • 細かいものはちょろちょろとあったが
  • アジャイル版開発ワークフローを公式化 (2011/10)
  • コーチによるサポートを継続、ウォーターフォール以上にドキュメントを用意した
  • ウォーターフォールとアジャイルは両立させている
    • やりたい、と思わない限り今までのやり方を続けられる、という選択肢を残している
    • 2つのプロセスがあることで、開発プロセスそのものに意識が行く。どうやって仕事をすればいいかの議論が活発になる
  • ルール化はただのマイルストーン、ゴールではなく過程にすぎない
  • 「火を灯すスピードを上げる」
    • 個別に、人づてに「やってみませんか」だったのを、もっと広いやり方ですすめる
    • 社内に広く告知、やりたいところは手を上げてくれればサポートしますよ
    • アジャイル開発そのものに触れる接触機会を増やした
      • t-wada を呼んで、社内TDD Bootcampをやったり、アジャイルサムライYahoo道場をやろうとしたり
  • 社外からも後押しする
    • 社内での事例を社外に出すなど
    • Scrumギャザリング東京で本部長とエンジニアが取り組みを公開
      • 上長を巻き込んだ
    • Dev Sumi 2012 ← イマココ
  • 本来のゴール「お客様に継続的に価値を提供する」に近づいていけてると信じている
  • 結果はコントロールできないが、着実に一歩一歩進めていく

4. まとめ

  • 今日のはなしを持ち帰って、Yahooのクロニクルが自分のクロニクルになれば嬉しい
  • 自分の(自社の)クロニクルができたら、それを是非コミュニティなどに還元して欲しい
  • そのクロニクルがつながっていくと、日本のエンジニアが強くなる
  • 身の回り3mに小さな火を灯していってください

Yahoo アジャイルクロニクル エンジニア編

  • 検索でYahooを使っている人挙手してください → ほとんどいないw

コーチとエンジニアの体験記

発表者自己紹介

  • 長岡 実さん
  • ガンダム好き
    • デスクの写真がスゴイ
  • Yahoo!ニュース トピックス担当4年目

サービスについて

  • Yahoo! ニュース トピックス
  • 1998年7月にサービス開始、14年目
  • 約3000件/日のニュース内からピックアップ
  • 開発メンバーは5人
  • 日々の開発でメンバーに感じていたこと
    • 個人が黙々と開発していて、お互い何をやっているかわからない
    • 明らかなコミュニケーション不足 → いやだった
  • 期日に間に合うのか、お願いしたものが出来上がってくるのか不安だった
    • これもコミュニケーション不足に起因
  • そんな時、アジャイルと遭遇。元上司が標準化チームのリーダーで、高橋さんの上司だった。
  • テストプロジェクトを探しているときに、その上司から話があった
    • 経験豊富なコーチがサポートしてくれるよ、と

最初の一歩

  • 説明会は全員で
  • 説明会は意外と好評で、ほぼ全員から「やってみたい」という意見が聞かれた
  • 実際導入してみると、すぐにいい効果が多数見えてきた
    • 見える化されたことで、関係者全員が全体感を把握できた
    • 残業が減った(!)
    • メンバーが助けあうことができた
  • 良いことばかりではなく、問題も起こった

発生した問題

  • ルールに囚われることが多い
    • スプリントを1週間に設定していた。5営業日なので、すべて完了させるのが非常に難しい
    • タスクの漏れとか、リリースの失敗とかが起こるように
    • 軌道修正するために、「1週間で終わらせる方法を必死で考えていた」
    • スクラムマスターの助言 → スプリントを2週間にすればいいんじゃないの?
      • 「その発想はなかった!」
    • 常に見なおして、チームに最適な形にやり方を変えるのは重要
    • 経験豊富なスクラムマスターの存在、マジありがたい
  • メンバーのモチベーションがだんだん低下していく
    • 導入して数ヶ月で慣れてくると、タスクを淡々とこなすだけになってくる。価値になっているのか?と考えたりする
    • チーム手動で、新しいサービスを考える活動を開始
      • 通常はPOから要件をもらって開発をすすめる
      • POを巻き込んで、アイディア出しやプロトタイプ制作などをした
      • この活動で、チームメンバーのモチベーションが復活

なぜうまく導入できたのか

  • アジャイル経験者の説明会に、上長含めて全員が参加
    • 共通の理解を得られた
  • 経験豊富な人の助言
    • 要所要所のうちわせなどで、いい助言や指摘を得られた
    • よき相談相手として、アジャイルコーチの存在はとても大きかった

最後に

  • 今日みたいなセミナーに、上長や同僚を2名以上誘って参加してください
  • そうすると「アジャイルでやっていこうよ」という雰囲気が生まれると思う
  • 実際に導入するときは、導入を支援する会社があるので、サポートをお願いすることをおすすめ
  • お金が発生するので、支援会社を使うのが難しければ、外のコミュニティに参加すればいいよ

2/10(金)〜2/11(土)に「インフラエンジニア&アプリエンジニア合同合宿」に行ってきました。

僕はスタッフとしての参加でしたけど、チームかにたまのメンバーとして一緒に作業したので、このエントリは参加者としてのイベント全体の振り返りになります。

スタッフとしてどうやってこのイベントを作ったか、みたいな話は気が向いたら書くかもしれません。

Mac で Rails 3.2.1 を使おうとしたら、rails new するときにエラーになった。
% rails new myapp --skip-test-unit
      create
      create  README.rdoc
      create  Rakefile
      create  config.ru
      create  .gitignore
      create  Gemfile
      create  app

...

      create  vendor/assets/javascripts/.gitkeep
      create  vendor/assets/stylesheets
      create  vendor/assets/stylesheets/.gitkeep
      create  vendor/plugins
      create  vendor/plugins/.gitkeep
         run  bundle install
/Users/yz/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:799: [BUG] Segmentation fault
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin10.8.0]

-- Control frame information -----------------------------------------------
c:0042 p:---- s:0226 b:0226 l:000225 d:000225 CFUNC  :connect
c:0041 p:0011 s:0223 b:0223 l:002620 d:000222 BLOCK  /Users/yz/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:799
c:0040 p:0031 s:0221 b:0221 l:000220 d:000220 METHOD /Users/yz/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/timeout.rb:54
c:0039 p:0026 s:0209 b:0209 l:000208 d:000208 METHOD /Users/yz/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/timeout.rb:99
c:0038 p:0485 s:0203 b:0203 l:002620 d:002620 METHOD /Users/yz/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/1.9.1/net/http.rb:799

...

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html

中略している部分も含めたすべてのエラーメッセージはココ
解決したので、以下対応履歴のメモ

環境は MacOS X 10.6.8 rvm 1.10.2 MacPorts 2.0.3

このアーカイブについて

このページには、2012年2月に書かれた記事が新しい順に公開されています。

前のアーカイブは2012年1月です。

次のアーカイブは2012年3月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

月別 アーカイブ

ウェブページ

OpenID対応しています OpenIDについて
Powered by Movable Type 6.1.2