トップ «前の日記(2009-02-11) 最新 次の日記(2009-02-13)» 編集

ヨタの日々

2001|08|09|10|11|12|
2002|01|02|03|04|05|06|07|08|09|10|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|12|
2024|01|02|03|04|

2009-02-12 :-)

_ 朝ッ

0730 起床

_ おひる

20090212_0.jpg

@ベローチェ

_ 俺の妹がこんなに可愛いわけがない2

20090212_1.jpg

読む

_ [冨久屋][イタリアンロール][おやつ]おやつ

20090212_2.jpg

冨久屋のイタリアンロール。昨日の残り

_ [俺の妹がこんなに可愛いわけがない]俺の妹がこんなに可愛いわけがない2

コミケ初参加した妹が国際展示場駅前でばったり親友に会ってしまいオタク趣味を説得するのに難儀したでござるの巻。

4048674269

_ [リッジレーサー7]リッジレーサー7

DUEL を進めた。ようやっと Seaside Route765 のコーナーを曲がれるようになったので CRINALE に勝てた。

  • 走行距離 4566.513km
  • RSGP 進行度 84.7%
  • 名声 9754FP

_ [デブサミ2009][devsumi2009]Developers Summit 2009 1 日目

【12-E-1】品質で失敗しない大規模システムの開発 (NTTデータ 浅井省吾)

  • 「品質が悪くて失敗した」
    • →品質は結果であり原因ではない
  • 大規模とは
    • プロジェクトに関わる人間が総勢500名くらい
  • 大規模システムの難しさ
    • 作り直せない
      • 作り直すと他の作業が止まる
      • 空き時間ができる
      • そのぶんの人件費がかかる
    • 要員が多い
      • 多階層
      • インターフェースミス
      • 伝達ミス
    • 品質がばらつく
  • 工程の定義と終了条件
    • 前工程のアウトプット | 次工程のインプット
    • どれくらいのアウトプットにすればインプットとして使いものになるのか? をちゃんと定義する
    • 1 工程は 2 ヶ月くらいがいい
    • 経験的に
    • 工程定義の意識ズレをかろうじて修正できる期間
  • 管理定義
    • 量が多すぎてはダメ、誰も読まない
    • 誰でも同じように作業できるように書く
  • インターフェースが少ない組織構成
    • 現実の組織構成をそのままモデル化するとインターフェースが多くなる
    • 一方通行が最適
      • pipe みたいな
      • foo | bar | baz
    • サービスの始めから終わりまでを貫くようにグルーピングする
    • 組織をそれに合わせる
      • →なんだって?

【12-A-3】時を超えたプログラミングの道への道 (永和システムマネジメント 角谷信太郎)

  • 「今日の講演は電波出てます」
    • →たしかに電波だった
  • XP is social change
  • 竹内預言( 竹内郁雄 )
    • 「プログラムを書いたことが無いような人が威張っている組織は早晩 滅びる」
  • 陰陽
    • TAO
    • 二元論じゃないよ
    • テクノロジとビジネス
    • ワークとライフ
    • コードとドキュメント
  • クリストファー・アレグザンダー
    • XP はアレクザンダーがやろうとしていたことをやろうとしている
  • しかしアレグザンダーは失敗した
    • 建築方面では「アレグザンダー? ああ、居たねそーいうひと」という認識
    • → 失敗した理由を聞き漏らした。儲からなかったから失敗したのか?

正直なところ角谷さんが何を言いたかったのかよく理解できなかったんだが、たぶん角谷さんは平鍋さんと同じことを問題として捉えていて Xdev [ 20080905#p03 ]のときに平鍋さんが言っていた「持続可能なソフトウェア」「ソフトウェアを育てる」「農耕型」をどうやって実現するか、ということを考えてるんじゃないかと邪推する。その行き着く先がアレグザンダーがやろうとしていたことであり「XP はアレグザンダーがやろうとしていたことをやろうとしている」ならば XP が適しているんだろう。

あー。そうか。そしてそれが 『WikiとXPをつなぐ時を超えたプログラミングの道』江渡 浩一郎, オブラブイベント2007夏 - 角谷HTML化計画 (2007-06-21) に繋がっていたわけか。角谷さんのところで紹介されている 「なぜそんなにもWikiは重要なのか」(PDF) にアレグザンダーの失敗についても書かれている。

【12-E-5】難易度の高い超短期開発におけるPM (NTTデータ 樫部昌弘)

  • 中規模
    • プロジェクトに関わる人間が 500 人から 1000 人
    • 電子マネー
    • 基幹システム
  • 超短期とは
    • 最適工期の 0.5 倍
    • つまりデスマーチ
  • タイムマネージメント
    • 予定と実績の記録
    • 個人ごとのスケジュール
    • {朝会,夕会}
  • スコープマネージメント
    • 要件定義
    • いつまでに何を作るか
    • エンドユーザーが忙しいならば仕様を決定できるキーパーソンと一緒に多少強引に進める
  • 統合マネジメント
    • QCD のうち D が最優先事項である
    • ということを顧客と同意しておくこと
    • Quality( 品質 ), Cost( 価格 ), Delivery( 納期 )
  • 品質マネジメント
    • 省略できない
    • ドキュメント
    • レビュー
    • テスト
    • 手戻りはある、という前提

【12-A-6】オブジェクト指向エクササイズのススメ (オージス総研 菅野洋史 大村伸吾)

「ThoughtWorksアンソロジー」に書いてある 9 つのエクササイズの話。この 9 つがどうも見たことがあると思ったら OOコード養成ギブス - rants で見たものではないか!和訳を待ち望んでいたんだが「ThoughtWorksアンソロジー」がそうだったのか。id:yojik のブックマークで眺めているだけの日々を過ごしていたんだがとりあえず注文した。

  • オブジェクト指向
    • 責務を持ったオブジェクトがコラボレーションしてシステムを作る
  • エクササイズ
    • 強制的に適用する
    • かなりきついコーディング規約
    • 1000 行くらいのプロジェクトで実践
  • 設計時の判断の集積がアーキテクチャーになる

487311389X

【12-A-7】「使う」と「作る」がつながるシステム開発

  • 平鍋健児
  • UFJIS 千貫素成
  • SonicGarden 倉貫義人
  • TIS 橘浩則
  • TIS 藤原士朗

TIS 多いすね。

平鍋さんが「船と橋」の図( どこかで見たことがある図だと思ったら XDev 2008[ 20080905#p03 ] だったか )を描いてから自己紹介。

  • 平鍋
    • 使う人と作る人が会話してないんじゃないか
    • 日本では 2 者に距離感を感じる
    • 仕様書で断絶されている
  • 倉貫
    • SaaS やってます
    • ディフェンシブな開発
    • 作る人は契約以上上のことをやらない
    • 余計なことをやらない
    • 余計なことに対して金を貰えないかもしれないから
  • 千貫
    • ユーザーとベンダーが離れている
    • ユーザーが全部出来れば良い
    • 受託開発の生産性の低さに絶望した
    • 間違ったシステムを使っていることが問題

議論はけっこう発散した。

  • SIer は不要になる
  • 社内システム部門が作ればいい
  • 人月は儲からない
  • 客の価値を単価にする
    • 1画面いくら
  • 建築業務
    • 1ボルトいくら
    • ペンキ ○○ m^2 でいくら
  • ユーザーと一緒に育てていく
  • オフショア使ったら「船」が増えるだけだろ(倉貫)
    • 船を使うならば仕様を完璧に仕上げる必要がある
    • いっさい仕様変更が無いようにする

↓倉貫さんによるまとめ。「SIerって要らないよね」という結論になった