2013/9/24(火) SQLアンチパターン読書会 「ラウンディングエラー」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/5668以下の書籍をターゲットとした読書会なのです。
場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。
参加者は12人かな。けっこう会議室のキャパ、ギリギリです。
この勉強会、もうすっかり全員、顔見知り。
毎度、出席率がほぼ100%な勉強会も珍しい。それだけ充実しているということですね。
■アジェンダ今回は中澤さんがアジェンダを作成して説明してくださいました。感謝！
各RDBMSの小数点型の調査など、独自に纏めてくださっているのが良いですね。
あと、@akuraru さんも2進数演算について説明するスライドを作ってきて説明してくださいました。
こーゆう自発的なのは良いですね～
以下、個人メモ。
■ディスカッションいつものように、ディスカッションしたいネタを各自、付箋に書き出して模造紙に貼りました。
■ラウンディングエラーが原因による事故今回衝撃的だったのは、ラウンディングエラーが原因で多数の命を失った事故事例の話でした。
●パトリオットミサイルの防御失敗http://www.sydrose.com/case100/298/湾岸戦争時に、ラウンディングエラーによる誤差によりミサイル撃墜に失敗、28名が死亡し100名近くが負傷したとのこと。
これは恐ろしいですね。。。
あと、小数点がらみでロケットが爆発した事故とか。
●アリアン5型ロケット爆発事故http://www.sydrose.com/case100/284/64ビットの浮動小数点数から16ビットの整数暗号に変換する過程で変換に失敗し、これが原因でロケットが爆発したとのこと。
あと 通称「きのこ本」のP.124あたりにも、これ関連の話が掲載されています。@t_wada さんに紹介いただきました。
エンジニアのミスが人命に関わるというシビアな話で、いきなり身が引き締まる思いである！
■小数の表現方法・基本的に、DBに「小数」を持たせないように設計する。
（案１）DBには「計算式」を文字列で持たせておき、必要な時まで計算しないようにする。
（案２）DBには「整数」で値を持たせておく。そのため、単位変換を行う。
（例１）"0.5時間"という持たせ方ではなく、"30分"というように単位変換して整数にする。
（例２）消費税を持たせる場合は"1.05"ではなく、"5"と整数で持たせる。
・DBのカラム名には単位を入れましょう、という話は昔よくあったらしい。
・小数を使わない、というのはアプリケーションの設計ではありえる。
例えば、センチメートルではなくミリメートルで扱うようにしましょう、とか。
・上記（案２）でデータを「整数」で持たす場合は、画面への表示時に小数に変換する。
→ 単位変換ライブラリを使う、あるいはストアドプロシージャで変換することもある。
→ どちらが良いかは場合による。
①ストアドで変換した方が性能が良いことがある。
②DBにいくつシステムが繋がっているかによって、どちらに計算させるかは変わる。
・金融業界だと、銀行の合併でシステム統合する際、データの持たせ方が互いに異なり、困ることがある。
→ マテリアライズドビューを使うのが選択肢の１つ。
■DBMSやプログラミング言語の差異・リテラルで書いた値が処理系によってどう解釈されるかが問題になる。
例えばPostgreSQLだと、SQLの比較演算の右辺に59.95と書くと、Numericとして判定される。
でもPostgreSQLのDB側は値をFloatで持つので、比較すると一致しないという事象が生じる。
・MySQLは、バージョン5.1より前はDecimalでも丸め誤差が生じるらしい。
5.1より前は、保存は10進数、計算は2進数だったらしい。
5.6.4より前はマイクロ秒が扱えなかったらしい。
・Oracleは10進数表現のNumber型がデフォルト。そもそもFloatでさえ10進数で扱われるらしい。
・MySQLのNumericは64桁まで扱えるらしい。
・PostgreSQLのNumericは、バージョン9までは1000桁で、バージョン9.1以降は1000桁以上扱えるらしい。
・Javaだと、金額にはFloatではなくBigDecimalを使え、というのは暗黙の了解。
・C言語はDecimalに対応する型がない。
・Groovyはデフォルトで小数をBigDecimalで扱うらしい。
・PHPはビルドオプションを指定しないとDecimalが扱えないらしい。
・PHPはオーバーフローするとIntからFloatに勝手に切り替わるので怖すぎる。。。
・PHPは型がないので、DBにFloatで入っている値を取り出すときに絶望的になる。。。
→ なのでドライバの段階で文字列として取り出して、そこで必要な桁数だけシフトしてデータを残したりして対処したりする。
・Javascriptは倍精度浮動小数点がデフォルト。
・COBOLは金額処理が多いのでDecimalの概念に馴染み深い。逆にFortranだと科学技術計算が多いのでFloatやDoubleに馴染み深い。
■ラウンディングエラーに関するお勧めブログエントリ@t_wada さんオススメ、iakioさんのエントリ。
■Float/DoubleでDBに入った値をどうするか問題・これが一番辛い。。。
・まず、DBから一度「文字列」で取り出す。
・その後、文字列からDecimalに変換する。でも移行が辛い。。。
■FloatとDecimalの性能差・FloatよりDecimalの方が性能は（数倍？）悪い。
★感想：今回のラウンディングエラー、FloatじゃなくNumeric使え！というオチで、ある意味単純で話が膨らむかなぁ、と思っていたんですが、予想に反して話題がとても多く驚きでした。
いやぁ、自分の知らないことは多いもんだ。。。
あと、そもそもDBでFloatを使ったことがない、という方も何名かいらっしゃいました。
DB上では整数で値を持たせる設計にする、という話は私にとって斬新でした。
ちなみにこの章を読んでて、FloatやDoubleの仕組みや2進数計算、みんな当たり前のように理解しているのだろうか？という疑問が沸きました。
ちなみに私、大学は情報工学専攻だったので、このへんは徹底的にブチ込まれたクチです。
なのでラウンディングエラーなんてこの業界、当たり前じゃん！という思いで読んでたんですが、もしかして、当たり前じゃないと受け取るエンジニアは案外多いのだろうか・・・とか疑ったり。
そして、そーゆうエンジニアが人命に関わるシステムを設計してるとなると・・・恐ろしや。
あと小数の扱い自体が、DBMSやプログラミング言語の差異により結構あるなぁ、というのが感想です。
ここはかなり注意する必要がありそうです。
参加者の皆様、ありがとうございました。
2013/9/21(日) "勉強会「HerokuではじめるRailsプログラミング入門 （テキスト輪読）」 第6章 モデルをさらに使いこなそう"に参加してきました。
告知URL
http://www.groupy.jp/study_groups/1/study_group_schedules/4 以下の書籍をターゲットとした読書会なのです。
参加者は4人かな。2人欠席で、ちょと少なめ。
場所は新宿の
マルチメディアスクールWAVEです。今回も会場の無料提供、感謝！
Railsのマイグレーションの仕組みとかに興味を持ったのがキッカケで始めたRailsのお勉強ですが、前回の5章に引き続き今回の6章もマイグレーション絡みで、興味深く勉強することができました。
今回は私も6-3節の発表を担当しました。
6-3節はテーブル間の関連付けを管理する機能である「アソシエーション」に関する説明がメインです。
この仕組みはJavaメインの私にとっては非常に興味深いですねー
ふつーはRDBに外部キーを使って参照制約を貼りますが、Railsはフレームワーク側でこの仕組みを保証するとのこと。
SQLアンチパターン読書会でも「キーレスエントリー」の章で参照制約の話を扱いましたが、そのときに紹介されててたRailsの仕組みがようやくわかりかけてきた気がします。
has_one、has_many、belongs_toという3種のアソシエーションが用意されているのも興味深いですね。
RDBだとhas_manyが標準だと思いますが、has_oneも、RDBだとUNIQUE KEY制約を付ければ実現できますね。
成果物は以下にアップロードしておきました。
■Herokuにデプロイしたアプリケーション (1) Memo登録画面
http://makopi23-rails-chapter06.herokuapp.com/memo/index (2) Sample登録画面（Sampleに紐づいたMemo情報も合わせて表示）
http://makopi23-rails-chapter06.herokuapp.com/sample/index ■ソースコード（Github） https://github.com/makopi23/Rails_Programming_Using_Heroku/tree/master/chapter06/myapp
あと、6-2節でエラーメッセージを日本語で表示させる方法が出てきますが、これは rails-i18n というライブラリを使えばもうちょっとスマートにできるそうです。
この辺のブログが参考になるのかもしれない。↓
Railsの多言語化対応 I18nのやり方を整理してみた！【国際化/英語化】
http://morizyun.github.io/blog/i18n-english-rails-ruby-many-languages/ あと話に出たのが、ループでぐるぐる回しながら一覧表示する処理ではID単位でSQLが発行されるらしいとのこと。
なので、この仕組みを理解した上で性能とかに気をつける必要がありそうです。
あとは、SQLが発行されるのがControllerじゃなくてViewになることがあるので、ログを追うときに注意、との話がありました。
今回の6章だと、画面へ表示するデータの取得は *.html.erb ファイルに書いてたりします。 例えばリスト6-41とか。
<td><ol>
<% mydata.memo.each do |data|%>
<li><%= data.comment %></li>
<% end %>
</ol></td> |
これだと確かに、Viewデータ取得処理が走ってSQLが発行されそうです。
あと、どんなSQLが裏で走ってるのか、フレームワーク任せにすると見えなくなるのも一長一短でしょうかね。
★感想：実際にRailsのマイグレーションやアソシエーションを写経することで理解が深まりました。
こーゆう仕組みはJavaメインの私にとっては新鮮です。
次回は7-3節の発表を担当します。
参加者の皆さん、ありがとうございました。
2013/9/14(土) 「XP祭り2013 〜 XP 〜」に参加してきました。
公式サイト
http://xpjug.com/xp2013/Togetter
http://togetter.com/li/564392場所は早稲田大学理工学部キャンパスです。
参加者は200人くらい？でしょうか。大きなイベントですねー
私、参加は今回が2回目です。
去年はとても楽しかったので、今回もとても楽しみにしてました。
会場に到着すると、昨年と同様、書籍の山が。
今年も参加者へのプレゼントがあるようで、協賛の出版社様に感謝！
あと、ピアソン桐原が技術書から撤退という衝撃ニュースが先日流れましたが、絶版から書籍を救うべく、アンケートが実施されてました。
ピアソンの魅力的な技術書が多数掲載されてて、お気に入りのものにシールを貼る方式ですね。
私は以下の書籍にシール貼りました。
「達人プログラマー」は入社2年目の時に読みました。
達人プログラマになることを夢見ていたあの頃。。。
思い出深い本です。
私が買った「人月の神話」は、もうちょと古い、赤い本でした。これは新人の時に読んだなぁ。懐かしい。
ピアソンの技術書、なんとか絶版にならないようになるといいですねー
以下、セッションの個人メモを復習を兼ねてダラダラ書きおこしてみる。
■A-1 オープニング＋アジャイルよもやま噺【トークライブ】http://xpjug.com/xp2013-contents-a1/去年もあった、冒頭セッションのトークライブですね。
今年は１時間まるまる漫才やるんかな・・・？ と思ったら、スライドを使ったちゃんとした講演が2本あった。
■XPの目標・優れたソフトウェア開発を行うこと。
・世の中には悪い方法でソフトウェアを開発をしてて失敗しているプロジェクトが多いのでは。
・そこで、良い方法をケントベックが考えた。ソフトウェア開発に建築のパターンを初めて持ち込んだ。
・パターンを集めて、パターンランゲージとしてやればうまくいくんじゃないか。
・GoFのデザインパターンは「ソフトウェア」、XPのパターンは「チーム」を対象にしている。
■XPの焦点大きく３つに焦点を絞っている。
１．ソフトウェアのプログラミングに対してどうするか
２．コミュニケーション
３．チームとしてのパワー
■XPのプラクティス・どのプラクティスを使うかは、各チームによって違う。
・自分に合ったものを選んで組み合わせる。カスタマイズすることが必要。
・でも、絶対やるべきプラクティスがある。必要に応じて選べばいいプラクティスもある。
■XPの理念・XPの理念は人にフォーカスしているのが特徴的である。
・５つの価値を挙げている。
①コミュニケーション
②フィードバック
③シンプルさ
④勇気
⑤尊重
・理念のうち「シンプルさ」というのがXPのが面白い。
→ 物事に対して「シンプルにあれ」というのがXPの大きな特徴である。
・XPとウォーターフォールの大きな違いが「フィードバック」があるかないか。
■短期の開発サイクル・プロジェクトを最初にスタートするとき、メンバーは詳細なドメインの情報を持ってない。
・すべての人が同じように高いドメイン知識を持ってるわけじゃない。
・なので、少しずつ進めながらフィードバックを得てどんどん回していく。
・「最初から全ては分かっていない」ということを認めてからスタートするのがXP。
■価値、原則、プラクティス・プラクティスは「やり方」。１つ１つのパターンと考えても良い。
・XPが提唱している13のプラクティスは、ほぼ全部やったほうが良い。
ちなみに入り口でXPの資料が配布されてました。以下が紹介されてます。
・５つの価値
・１４の原則
・１３の主プラクティス
・１１の必然的結果プラクティス
XPを１枚によく纏めた良い資料だと思います。
・「価値」と「プラクティス」って遠い。なので、上手くプラクティスを選べなかった。そこで「原則」を用意した。
・「価値」と「プラクティス」があって、それを繋ぐのが「原則」。
・「価値、「原則」、「プラクティス」の３つの関係を理解することが、XPをやろうとしたときに大事になる。
・全部やれとはいってない。あなたのチームにとっての価値はなんですか？ということををまず考えること。
・ここに書いてある価値、原則、プラクティスが全てとは言っていない。
・これらはケント・ベックが挙げているだけ。チームによって付け足して良い。
・ただ、３つの関係を崩さないようにカスタマイズするのが正しいやり方である。
・困っている所に対してプラクティスを当てはめる。
・困っているということは、価値の反対。そこから考えていけば価値に結びつく。
■XPの真髄(1) 社会的な変革（Social Change）・ケント・ベックがなぜXPを作ったかというと、Social Changeが挙げられる。
・まず、障害となっているものを除きましょう。
・あの時やったから今回もやる。それで失敗する。そして前例を言い訳にする。そうじゃなく、考えること。
(2) 自己改革・「子供じみた自己」はダメ。視点を変えましょう。
・これだとビジネスに利用できないコードを作っちゃったりする。
・ビジネスの場合だと「十分」というのがある。100点は求められない。
・小井戸さんは、最近は、読みやすい、わかりやすいコードを書くことを意識するようにした。
・ペアプロとかTDDとかやると自分のコードがよくわかる。
■今日全力を尽くすことに対して自分自身を評価する・良い言葉やな～・・・
■まとめ・ソフトウェア開発はチーム。
・XPで面白いのは、個人、開発者として幸せな人生を送るにはどうすればいいか、が書いてある事。
・今回のプロジェクトだけじゃなくて、長い人生、自分をどう成長させるか、人にフォーカスしている。
・相手は人間。思い遣り、お互いの理解が重要。それが良いソフトウェアを生み出す。
---
引き続き、楽天の川口さんによる講演です。
■アジャイルの全体像を理解する・「塹壕より Scrum と XP」という書籍がある。ここで「塹壕」というのは「一番下」、「現場」という意味。
・「Scrum and XP from the Trenches」の「Trenches」を塹壕と訳したのは直訳。本来は「現場」と訳すべき。
・塹壕こそが現場である。現場レポート大事。
・今回は一番下の現場ではなく、一番上から捉えてみよう、というのがスライドタイトルの趣旨。
■Agile and Lean・AgileとLeanがいろんなとこで聞くようになった。それらの歴史の話を纏めたのがP.3の図。
・まずアジャイル宣言が2001年に発表された。これは文化を表したもの。
・派閥がScrumとXP。
(1) XP・XPはケント・ベックが提唱した。これは建築のPatternsから来ている。
(2) Scrum・Scrumも同じく、Patternsから来ている。
・Scrumは、日本の製造業の製品開発を体系化した野中郁次郎氏の論文が源流にある。
・ホンダの「シティ」という車を作るプロジェクトで、若手を大部屋に集めて、「今後のホンダを担う車を作れ」、という話が原点。
→ 結果として斬新な車が出た。
・このポイントは、達人を集めたのではなく、若手を集めたこと。
(3) Lean・Leanはトヨタのプロダクションシステムから来ている。
・トヨタの生産方式を元にLeanと名前をつけた。
・AgileとLeanは全然絡んでいないが、海外の人は両方とも日本から来たと思っている。
・Leanをソフトウェアの分野に持ってきたのがメアリー・ポッペンディークの
「Lean Software Development」。
・その後、デイヴィッド・アンダーソンがLeanに衝撃を受けて
「Kanban」を出した。
・最近、エリック・リースの
「Lean Startup」が出た。AgileとKanbanをビジネスに活かす。
⇒ Leanには「Lean Software Development」、「Kanban」、「Lean Startup」の３派がある。
---
・他の人と話をするとき、「おまえのアジャイルはどれやねん！」と最初に話すことが大事。
・この図だと非常に広いことがわかる。
■内部構造の話(1) プロセスエンジニアリング
・プログラマとして無駄のないアウトプットを出しましょう。
(2) コラボレーション/信頼のコミュニティ
・チームとしてのコラボレーションが大事。
・書籍「組織パターン」の著者、ジェームス・コプリエンも、これが根幹としている。
(3) フロー状態/イノベーション
・「フロー状態」とは、要するに「凄いアウトプットが出る状態」のこと。
(4) プログラマーのライフハック
・@t_wada さんは、TDDをやる理由として「一人でも自分から始められるから」と言っている。
→ これはココに該当する。
(1)～(4)の、どのアジャイルをやっていこうかな、と考えるのがよい。
■外部インタフェースの話(1) 組織と仕組み
・Agileをやろうと思ったらどういうアーキテクチャにすればリリースし易くなるか？
・そういうところを固めておかないといけない。
・変更のインパクトの大きいものと小さいものを分けないといけない。
・変更のインパクトが大きいものは最初にきちっとやらないといけない。
(2) インフラ系の継続的デリバリー
・モノを作っても、出てかないと意味ない。
(3) 要求と品質
・全体のテストをどーするの？とか、お客さんにとってどう嬉しいの？とか、作り手が固まってくると、このあたりが勝負のポイントになってくる。
(4) マーケットイン
・商売の話が出てくる。
・マーケットを捉えるにはどうすればいいか。仮説検証がどうしても必要。
■アジャイルの構成要素・技術プラクティス：CI,TDD
→ 開発者のヘルシーさ。ここから始める方が多い。
・Metrics
→ 効果計測。最近注目のリーンスタートアップでも言われている。数値化されることで比較できる。
■アジャイル適用のADAPTモデル・人はどうやればアジャイルやるようになるか？
→ Mike Cohn（「アジャイルな見積りと計画づくり」の著者）が定義している。
①まず知る
②やってみたくなる
③教えて、出来るようになってもらう。
④成果を出し始めると、社内がアジャイルになっていける。
・いきなり最後の「変える」をやろうとする。でも一人ひとりがやれるように左から順にいくべき。
■初期のスプリント・ウォーターフォールだと、伏線が最後にあるのでを回収できない。
・途中でスコープの変更により昇龍拳がおきている。
■チームの成熟（4ヶ月後）・バーンダウンチャートが最初に１回落ちている。あと、最後に課題が発見されている。これは良い。
・フィードバックを得ている。
■アジャイルテスト・V字モデルはアジャイルじゃない、ということはない。これをどう回すかがアジャイル。
・要求を書く人が受け入れテストを書くと回ってくる。
■A-2 SEMATに関する講演【講演】http://xpjug.com/xp2013-contents-a2/■SEMAT：ソフトウェアエンジニアリングのエッセンス・Ivar Jacobsonの考えやアイデアが中心。
・どう成長していけばいいのか。
・まず知識を伸ばしていこうとするが、それだけじゃダメ。
・そこで経験やガイダンスを得て、プロフェッショナリズムを身につけていく。
・普段は、技術や知識が溢れている中で手にとって、それに実践を積んでプロフェッショナリズムを高めていこうとする。
・でもそれは島々のアイランド状態では。密接に関連づけられていない。
・試行錯誤が必要だが、それは時間がかかり、間違った方向性に向かう可能性もあるし、リスクがある。
・そこでSEMAT！
・孤島を見ていって試行錯誤するんじゃなく、共通基板があって、きちんと関連付けられて整理されていれば、それを使うことでよりよく早く幸せにプロフェッショナリズムを高められる。
・ソフトウェアエンジニアリングはファッション業界のようなものである、という批判がある。
・いろいろ、あれがいいぞ、が出て群がっては、明日どうなっているかがわからない。
・いろいろでてきて流行り廃りが出てくる。１つ１つは魅力だが、点在状態である。
・我々がより良く進める際にすべてをカバーしているわけではない。
・共通基盤がないことが深刻な問題をもたらしていて、産業界と学術会に大きなギャップがあった。
・そこで2009年、運動が立ち上がった。それがSEMAT。
・堅固な理論、実証原則、ベストプラクティスに基づくソフトウェアエンジニアリング再建（共通理解）
・Ivar Jacobson、Bertrand Meyer、Richard Soleyの3人はトロイカと呼ばれる。
■共通基盤・ソフト開発の核を定義しよう。
・理論がないわけではない。でも、いずれも共通基盤ではない。
・そこでSEMATが共通基盤を与える。
・同じ土台にのって議論したり、プラクティスを交換したり。そういうところに繋げる。
・理論的共通基盤のことを「エッセンス」と呼ぶ。
■エッセンス（カーネル＋言語）がOMG提案承認へ・階層構造の一番下に「言語」がある。プログラミング言語じゃなくて、ビジュアル言語。図形のDSL。
・その上にカーネルが定義されている。大事なことの基本的な関係が定義されている。
・カーネルはプロセスとは独立している。広く共通に使えるものがつまっている。
・「言語」と「カーネル」がエッセンスで、その上にプラクティスを定義し、組み合わせる。
・手法やプロセスありきではなく、まずエッセンスありき。
■カーネル・ソフト開発の状況、状態を表現するのに欠かせない情報。
・一番重要なのかアルファ。
・アルファ（alpha）は、AspirationLed Progress and Health Attribute略称。
・まず「アルファ」という名前ありきで略称を頑張ったｗ
・今どのくらい進んでいるのか、うまくいっているのか把握すべき最低限の事柄をアルファと呼ぶ。
・アルファの状態を遷移させていくために必要な作業があり、活動空間、活動がある。
・カーネルの中には、活動空間のテンプレートも入っている。それを各人において具体化、明確化して使う。
・SEMATはアジャイルの影響を強く受けている。チームや仕事の仕方など、取り組みを大事にしている。これがあってこそ進めていける。
・要求はいろんなステークホルダーから出てくる。
・要求だけじゃなく、取り組みや顧客も大事。そこから７つのアルファを抽出している。
■カーネルの特徴と留意・ソフトウェア以外の事柄を大切にしている。
・アジャイル宣言を支持している。
・状態思考（not プロセス思考）
---
ここまでが午前のセッションでした。
■D-3 アジャイルセンター試験：出題編【その他】http://xpjug.com/xp2013-contents-d3/午後1発目のセッションは「アジャイルセンター試験」を選択しました。
問題用紙と解答用紙はこんなカンジ。
会場でお会いした @shinyaa31 さんからも受験を薦められました～
センター試験、懐かしいなぁ。。。
受験生時代を思い出します。
あの時代はPCやインターネットが自宅に無かったので、受験勉強に集中できたというのはあるな～
ファミコンや漫画をダンボールに詰めて封印して頑張ってた（笑
今の時代はPCとかスマホとか部屋にあるので、誘惑が多くてとてもじゃないが勉強に手がつかんかも・・・とか、いろいろ思いながらコレ受験してました。
難しかった。。。
■A-4 かんばん in Wonderland【講演】http://xpjug.com/xp2013-contents-a4/ おなじみ Devloveの市谷さんと楽天の藤原大さんのセッションです。
■リーン開発の現場Lean from the Trenches
・なぜこの本を訳したのか？というと、Agile2012でHenrikのセッションに出たのがキッカケ。
■本の特徴・まえがきをケント・ベックが書いている。
・「彼の本のいいところは、理論めいたところを協調してやれ、というのではなく現場でやった物語なのでリアリティがある、納得感がある。」
・Agile2012のダラスからの帰り道に、日本の現場に届けたいなぁと思った。
・翻訳やったことないのでどうしようかな・・・
・翻訳書で心に残ったものを思い出してみた
①アジャイルプラクティス
②アジャイルな見積りと計画づくり
③アジャイルサムライ
・これらの書籍で共通することは「二人で訳している」ということ。
・一人で訳すと、合ってるかどうか悩んで進めなくなる。でも二人だと意見を交わせる。
・相棒を探そうと思ったら、藤原大さんに行き当たった。
・翻訳は簡単じゃなかった・・・
・「ベニヤ板を磨き倒して、つるつるにする作業や！」 by藤原大さん
■Kanban・Kanbanって馴染み深い言葉だけど知られる機会がない。
・2種類の表現がある。大文字と小文字の差。以下のように使い分ける。
①Kanban： 方法論
②kanban： タスクボードとかツール
・あと、カタカナが「方法論」、ひらがなが「トヨタ系のかんばん」で使い分けることにした。
■著者のDavidさん：皇居東御苑での出来事・入口でカードを渡されて、このチケットの意味を考えた。
・これで量をコントロールしてるんじゃないか。
・カードが無くなると入れない。これってWIP（Work In Progress）制限じゃん。
・これをみて、製造業じゃなくてもかんばんは使えそう、と思った。
■カンバンの誕生・量のコントロールが今日は重要。
・安定した開発をしたい。より良い作り方があるんじゃないか？
・「Drum-Buffer-Rope」とは、みんなでロープで繋いで歩いていく方式。これだと、一人だけ早く、とかできない。
・タスクボードとかスクラム版はカンバンシステムではない。
■リーンカンバン・リーンカンバンは、縦に割ったり横に割ったりする。
・ゆるふわ原則が４つある。
・プラクティスは6個ある。昔は5個だったらしい。
■作り方・タスクボードとかスクラムボードなど、いつものカンバンは、デービットさんは「カンバンじゃない」と言っている。
・リーンカンバンにするために一歩進化させる。
・ToDo, Doing, Doneの他に、AnalyzeとTestを追加して、更にDoingをDevに変更して、合計５区画にする。
・更に、AnalyzeとDevにもDoingとDoneを付ける。
・更にWIPを制限する。
■使い方・POは機能を選ぶ（Pull ＝ 引っ張る）だけ。
・その時点でタスクはアサインされていない。
・イテレーションという概念がない。
・機能の開発は完了したら次の機能へ。
・ジャストインタイムに近い。
■さいごに・見える化のためにやる。見える化は何のためか、まで考える。
・開発チームが枠を超えてテストチームを助けに行く。
→ カンバンの境目を超えろ。
A-5 Agile2013報告＋鷲崎先生講演【講演】http://xpjug.com/xp2013-contents-a5/道場主のAgile2013聴講報告あり。
横浜道場ではなんも言ってなかったのに・・・w
■D-6 アジャイルセンター試験：解説・発表編【その他】http://xpjug.com/xp2013-contents-d6/午後一で受験したアジャイルセンター試験の解答解説です。
まこぴ、一番最初に答案をマチコ先生から返却されましたが、渋い顔・・・
うーむ、６１点。
平均点が６４点らしいから、３点足りなかった・・・
このイベント、なかなか注目度も高かったようで、Togetterにもまとまってます。
Togetter
http://togetter.com/li/564194出題者もアジャイルで著名な方ばかりで、解答解説もアジャイルサムライの西村さんとか、豪華でした。
こーゆう取り組みは面白いですねぇ。
珍回答とかもチラホラ紹介されてて、楽しいヒトトキでした。
■A-7 LT祭り【LT】http://xpjug.com/xp2013-contents-a7/今年もLT祭り！
今年は13人で、一人5分なので1時間ちょいかな。
楽しいヒトトキでした。
特に佐野さんのラグビーの話とか、印象深いですねー。
おーなるほどなぁ、と感心したり。
XP祭りはLTで締めるのが良いですねぇ。盛り上がります。
そして最後に参加者への書籍プレゼントタイム！
@makopi23 は最後の方になって、以下の書籍をいただきました。
ありがとーございます。
ちなみに @t_wada さんからもコメントが！
今年はほぼ全員に書籍が行き渡ったようです。ありがたい！
★感想：今年のXP祭も、とても有意義でした。
午前のセッションでは、XPの講演を体系的に聞けたし、SEMATも初耳で参考になったし。
午後はカンバンも、アジャイルセンター試験も、Agile2013報告も、LT大会も、どれも濃い内容でした。
新しい知識が得られたのもそうなんですが、やっぱイベント自体が楽しいのが良いですね～
来年も楽しみです。
講演者さん、スタッフさん、会場提供者さん、皆様ありがとうございました。
2013/9/3(火) 横浜道場 特別編 「現場で役立つ（かもしれない）ビジネスモデル・キャンバスのワークショップ」に参加してきました。
DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/4836以下の書籍をターゲットとした読書会なのです。
場所はいつもの横浜、株式会社アットウェアさんです。いつも会場提供ありがとうございます。
参加者は20名くらいでしょうか。
この日は特別編ということで、嵩原 將志さんを講師にお招きしてワークショップをやりました。
ビジネスモデル・キャンバスというものを作る、とのことですが、私は予備知識無しで参加しました。
■講演スライド今回の横浜道場特別編で使用した資料はFacebookで限定公開となっています。
ですが、ほぼ同様の内容が記載された資料がSlideshareに公開されています。↓
■ビジネスモデル・キャンバスビジネスモデル・キャンバスは対象ビジネスを９つのブロックに分けて整理することで、組織のビジネスモデルを分析したり、情報を整理するためのツールだそうです。
例えば、事業計画書を作成する前に、自分が今考えているアイデアがイケそうか考えたりするのに使えるそうな。
９つのブロックについては資料参照。
ということで、チームでビジネスモデル・キャンバスを書いてみました。
私のチームは3名＋道場主で、ターゲットはチームメンバのお1人に関係がある「Sony」！
うむむ、イメージが沸きやすい企業だ。
以下、講演時の個人メモ。
■ビジネスモデル・キャンバスの左半分と右半分の違い・左半分は「論理」、右半分は「感情」を表している。
・左半分の「論理」はコストがかかるので、リズムで削っていく。
・右半分の「感情」は価値を届ける。
■リソース（KR： Key Resource）・KRには、差別化できる要因を書く。
・例えば各企業には経理とか人事はいるけど、それは差別化にはならない。
・オフィスもリソースとして書かなくて良い。ただし喫茶店とかだと「駅前」とかは差別化になるので書いてよい。
・Googleのリソースを考えてみる。
・Googleは社員を500人レイオフしても痛くないが、システムが１日でも停止すると影響大。
・でも、それは一時期のスナップショットでしかない。長期的にみると、Googleのリソースは「人材」である。
■主要活動（KA： Key Activities ）・あくまで「主要」で「差別化」できる活動であること。
・主要な活動は、弄ると影響を受ける場所を指す。
■顧客セグメント（CS： Customer Segment）・おおまかな情報を書くだけでOK。
・ニーズや背景を読み取ること。
・小型EV車の例が紹介されている。
- 「セグメント」で考えてしまうと市場は小さくなる。
- でも、「利用用途」で考えてみると、自動車ユーザの70%は1人で乗っている。
→ 「セグメント」ではなく「利用用途」を切り口にすると、「売れるかもしれない」となる。
■価値提案（VP： Value Propositions）・価値提案のコツは「顧客視点」で書くこと。
・VPは要素がすごく多いので、必要に応じて分解して考えるのもアリ。
・「価値」と「活動」は違う。でも区別するのは難しい。
・例えば「プログラミング」が「価値」のように見えてくるが、これは「価値」じゃなくて「活動」。
・「活動」のその先の、プログラミングした結果によって収益を貰うことが「価値」である。
■チャネル（CH： Channel）・AARRR指標を考えることも必要になる。「どういう順序で提供するか」
・そもそも市場が十分に大きか？が重要。市場が小さいのにコンバージョンしても仕方がない。
■顧客との関係（CR： Customer Relationships）・CRには2種類ある。
①物理的関係の観点。
②愛着を持たれているかの観点。
・リピーターを獲得する要因は何か？を考える。
■パートナー（KP： Key Partners）・CR（顧客との関係）に書いたものがKP（パートナー）に入ることが結構ある。
・競合他社とか自分たちのビジネスを脅かすものをメモしておくと良い。
・マーケティングのパートナーを推奨する。
・プラットフォームベンダーは、展開してくれるパートナーが必要になる。
・特にメディア企業は集客が命なので、マーケティングパートナーは重要。
・クラスメソッドでは社員が技術系ブログを書くことを推奨している。
・技術系のブログ記事はしぶとく検索で引っかかるので、費用対効果が高い。
・マーケティング担当者はコミュニティとかで顔見知りをたくさん作っておくと、そのマーケティング担当者が所属する会社や製品の悪口を、顔見知りがSNSとかで発信することが無くなる。
（見られている、という牽制になる）
■コスト構造（CS； Cost Structure）・「金持ち父さん貧乏父さん」という書籍があるが参考になる。
・収益を生み出さない資産は、「資産」ではなく「負債」である。
・いずれ収益を生み出すものは、切り捨てないようにする。
■ビジネスモデル・キャンバスのコツ●バリューストリーム・バリューストリームの流れを確認することが大事。
・というのも、みなさん思い入れがあるので、どうしても都合がいいことばかりキャンバスに書いてしまう。
・キャンバスに要素がたくさんあるけど、きちんと繋がって収益にいっていますか？
・そういう視点で見ると、けっこう穴が見つかる。想定しているお客さんへのチャネルが無かったりとか。。。
●作成順所・９つのカテゴリの作成順序だが、目的によって順序は変わる。フォーカスするところから書くべき。
●書き方・キャンバスを書くときの注意としては、人を巻き込んで書くこと。煙たがられるが、めげずに書くこと。
・何回も、何パターンも書く。
・破綻することを実行するのは意味が無いので、机上で検証できることは机上で行うべき。
●仮説検証・キャンバスは半年とか３ヶ月くらいで見直すようにする。
■パーソナル・キャンバス次は、チームではなく各自で、パーソナルキャンバスというものを作成しました。
なお上の資料にはパーソナルキャンバスの説明がありませんが、横浜道場Facebookの方の資料にはあります。
あとは、講師の嵩原さんが書いている以下のページが参考になるかも。
パーソナルキャンバスを描いてキャリアをデザインするhttp://dev.classmethod.jp/etc/career-design-and-path/自分自身のキャリアを整理し、今後をどう生きていくかを考える時に使えるとのこと。
ということで、その場で書いたのは以下。
でも、道場ではあんまり時間がなく落ち着いて作成できませんので、帰宅してから復習を兼ねて再度書いてみた！
（クリックで拡大。画像サイズは1067×529）
自分に向き合う、というのが新鮮ですね～
私はファミコン世代なので、小さいころからずっと、将来はゲームプログラマになりたいと思っていました。
んで大学では情報工学を専攻し、最終的にはゲームプログラマではなくメーカー系のSEを職に選びました。
ゲーム開発の道からは逸れましたが、ずっとプログラミングにワクワクしていた気がします。
なので、パーソナルキャンバスに真っ先に書いたのが「プログラミング」でした。
自分で手を動かして何かを作るのが幼稚園児のころから好きでした。工作ばっかやってたしｗ
時は流れて、最近はExcelやPowerPointと戯れる時間が増えて。。。
ということで、期末の面談では、「やっぱ開発に近い仕事がやりたい！」と上長に再度伝えることにした。
・・・な～んてことを考えたりする機会になりました。
■ビアバッシュにてビアバッシュにて、講師の嵩原さんと会話させていただく機会を得ました。
「キャンバスは、まず書く。その後で数字を付けてみて検証することが大事」とのことでした。
あと、前のホワイトボードで説明されてましたが、キャンバスは3種類あるそうです。
１．ビジネスモデルキャンバス
２．リーンキャンバス
３．エクスペリエンスビジョンビジネスモデルキャンバスで、VP（価値提案）という括りは雑すぎる、とのこと。
そこでエクスペリエンスビジョンでは、バリューシナリオとして以下の観点でVPを更に細分化しているそうな。
・ユーザのニーズ
・S/Pの提供形態
・～のメリット
・使用頻度
あと、エクスペリエンスビジョンは矛盾と重複があるそうです。
リーンキャンバスだと、VPの中に更に「ハイレベルコンセプト」というものがあるらしい。
角さんのRunning Leanが参考になるそうです。
半分酔っ払ってたので、間違ってるところがあるかもしれません。ゴメンナサイ。。。
★感想：興味深いワークショップでした。
分析する手法としては世間にたくさんあると思うのですが、こーゆう切り口の分析もあるんですね。
弊社では分析にKT法（ケプナー・トリゴー法）というのがデフォルトで教育に組み込まれてますが、ビジネスキャンバスはそれより手軽に分析できると思います。
（いや、KT法は最近使ってないから正確には言い切れませんが。。。）
たださすがに2時間のワークショップだけでマスターしたとは言い切れないので、機会があれば関連書籍とかも読んでみたいなぁ。
講演の中でチラッと出てきた以下の本なんかどーなんだろ。
やっぱ、ワークショップはいろんな気付きがあって面白いですね。
横浜道場の通常会はラスト１回ですが、今後も特別回を含め継続して欲しいです。
とりあえず道場主の、Agile2013報告会を特別回できぼんぬ。
あ、そういや今回、道場主から現地のRed Bullのお土産ありましたね。まさかシルバー、赤、青の缶とは・・・
講師の嵩原さん、道場スタッフさん、参加者の皆さんありがとうございました。
2013/8/29(木) SQLアンチパターン読書会 「メタデータトリブル」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/5478以下の書籍をターゲットとした読書会なのです。
場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。
参加者は10人です。
初めての方が1名いらっしゃいました。新しい風が入るのは良いですね。
ということで久々に自己紹介をやったんですが、テーマは「夏休み」。
・・・皆さん、夏休みほとんど取れてないようで（笑
今回は8章「メタデータトリブル（メタデータ大増殖）」がターゲットでした。
ちなみに「トリブル」は8.2節にも紹介ありますが、アメリカのSFテレビドラマ「スタートレック」シリーズに登場する、架空の動物だそうです。
こんなのｗ ↓
（出展：
http://f.hatena.ne.jp/Kumappus/20080421131814）
8章のタイトル、メタデータがトリブルのように増殖する、というイメージなんでしょうね。
ちなみにちょうど今、映画「スター・トレック イントゥ・ダークネス」も公開中だったりします。
私、偶然ですが夏休みに両親と観てきました。しかも先行公開の初日に。とても面白かった！
「スタートレック」シリーズを知らない人でも問題なく楽しめる作品です。オススメ。
・・・と、私は自己紹介でこの夏休みネタを紹介したのであった。
ちなみに @t_wada さん曰く、洋書は「スターウォーズ」ネタや「スタートレック」ネタが多く出てきて翻訳が大変だそうです（笑
■アジェンダ @tonyuchi さんがスライドを作成して発表してくださいました。
検証や考察まで入っていて、素晴らしい出来です。
最後のページの「テストデータトリブル」とか、実に興味深いですねー
■ディスカッションいつものように、ディスカッションしたいネタを各自、付箋に書き出して模造紙に貼りました。
以下、つらつらと個人メモ。
■メタデータへのデータの混入・「メタデータ」とは、テーブル名やカラム名のことを指す。DBに格納する値自身ではなく、メタなデータ。
・「メタデータへのデータの混入」とは、テーブル名やカラム名に、西暦などのデータが混入すること。
・例：Bugs_2008
■メタデータトリブルとデータ規模・そもそも扱うデータが少ないと、メタデータトリブルは検討する必要さえないかもしれない。
・例えば企業内システムとか、それほど規模が大きくないシステムとか。
■シャーディング・データベースを「Shared Nothing Architecture」にすることらしい。
・Googleがスケールアウトするアーキテクチャに「sharding」と命名したことが、広く知られるキッカケになった。
・PostgreSQLはシャーディングの設定が、他のDBMSに比べて大変らしい。
・シャーディングはディスクを物理的に分けないと旨みが無い。
・なおDBを扱う人からは、ディスクが分散されていることが隠蔽され見えない。
・SQL ServerはEnterprise Editionじゃないとシャーディングできないらしい。
・Oracleだとシャーディングのことをパーティショニングと呼ぶようである。
・ググったらこの辺の記事が参考になりそう。
Agile Cat — in the cloud Database Sharding _1 http://agilecatcloud.com/2009/06/28/database-sharding-_1/■MyISAMとInoDB・P.98の8.5.2節に「MyISAMストレージエンジン」という単語が出てくるが詳しくないので質問してみた。
→ MySQLにはMyISAMとInoDBという二つのストレージエンジンがあるとのこと。
・MyISAM ・・・全文検索は速いがトランザクションや外部キー制約をサポートしない。テーブルロックになる。
・InoDB ・・・ トランザクションをサポート、外部キー制約が装備されている、行ロックでいける。
・最近はMyISAMとInoDBの性能は変わらなくなってきた。
・MyISAMとInoDBの違いについてはこの辺の記事が参考になりそう
MySQL、MyISAMとInnoDBを選ぶ方法 http://news.mynavi.jp/news/2009/03/27/048/index.html■シャーディングとPreparedStatement・PostgreSQLでシャーディングを採用した際、PreparedStatementのバインド変数に最後まで何が入るか分からず、実行計画がFull Scanになったことがあった。
・サーバ側でSQLの実行計画を立てる場合は、バインド変数に何が入ってくるかわからなのでディスク振り分けができなかったらしい。
・ORACLEだと「地域」と「時間」といった2段階でシャーディングができるらしい。
■水平パーティショニングと垂直パーティショニング・垂直パーティショニングはテーブル分割が絡むので、設計の話になる。
・水平パーティショニングはSQL標準ではないので、ベンダ依存になるため調べる必要がある。
・ORACLEはALTER TABLEで途中からパーティショニングを導入できるらしい。
・MySQLはテーブルのCREATE時にパーティショニングのオプションを指定する必要がある。
・垂直パーティショニングはディスクがスカスカになるのを避けられる。
→ BLOBカラムにはデータが入ることが少ないので、別テーブルに切り出すことで必要最小限になる。
■8.2.4節「一意性の保証」・ROLLBACKの指定は、直前のINSERTを無効化するため。（データ容量が増えないようにする）
・ROLLBACKされても、INSERTされた際に採番されたSIRIALのNext Value（連番ID）は、LAST_INSERT_ID()関数で取得できる。
・8.2.4節は、複数のテーブルに跨って主キーの重複を防ぐための仕組みで、シーケンスオブジェクトが無いMySQL独特のやり方。
・ROLLBACKは無くても動作するが、データが増えるので付けている。
・LAST_INSERT_ID()関数は、BEGINからENDまでのトランザクション内で最後に取れたIDを返す関数。
・一意採番の仕組みはDBMS依存になる。
■8.5節の解決策の３つの選択指針・3案のどれを採用するかは、性能要件とデータ要件による。
・8.5.1節「水平パーティショニング」は、スケーラビリティの話。
・8.5.1節「水平パーティショニング」と8.5.2節「垂直パーティショニング」は、人力の話。
・これらで出来ない場合の話は、8.5.3節の「従属テーブルの導入」。これは正規化の話。
・水平パーティショニングが出来るか否かは、テーブル構造による。
→ 例えばテーブルが1個だけど水平パーティショニングは楽である。
→ だが、普通はテーブルをJOINしてデータを取得するので、関連するひとかたまりのデータをシャーディングして近い所に置けるかどうかで決める。
・機械的に分割できるキーがあるかどうかで水平パーティショニングが使えるかどうかが変わる。
・Googleのアーキテクチャは、アグリゲートルート単位でトランザクションが発行される。
・
データ構造が、起点とするデータを頂点とするツリー構造になっていれば、水平に分けやすい。・RDBの機能として暗黙的に分割するかアプリで分割するかによるが、水平パーティショニングは割り易い/割りにくいが圧倒的にある。
■マルチテナントアーキテクチャ・マルチテナントアーキテクチャでは、同じテーブル上に複数の契約会社のデータを入れる。分割キーは"テナントID"などを使い、キーで内部的に分けている。
・DB操作の際は、必ず"テナントID"がSQLのWhere区に入るので、同じテーブルを共有しているけど、データは絶対に混ざらないようにしている。
・このアーキテクチャでは、テナントIDがシャーディンの際のの分割キーになる。
・シャーディングには何種類かあるが、ハッシュでテナント毎に保存域を散らすように設計する。
・このように、シャーディングしやすいキーがデータとしてあるかどうか、水平分割しやすいデータ構造になっているかで、水平パーティショニングをするかどうかを決める。
■スケーラビリティ・スケールアウト： 水平パーティショニング
・スケールアップ： 構成は同じまま、CPUとかをパワーアップさせる
・スケールバック： あまり使わないデータを履歴系テーブルに逃がす
■水平パーティショニング採用時の注意点・水平パーティショニングという、DBMS固有の機能にあまり期待し過ぎない方が良い。
・1テーブルだけ見れば良いことは多いが、完全に透過的にデータが散るかというと、全体的にはそうはいかない。
・シャーディングを実現するには、MySQL SpiderエンジンのようにOSSの外部で提供されている場合と、OSS同梱の場合とがある。
・DBMS依存の部分は自分で調べたり、検証する必要があり、自己責任となる。
★感想：私も水平パーティショニングは業務で使ったことがありました。
全国26,000の郵便局のデータを一括集計する締め処理をシャーディングで分散させる際、レンジ分割を使ったんですが、新宿郵便局とか特定局のデータがデカすぎて、そこがボトルネックになって性能問題になってしまった。。。
分散するだけじゃ当然ダメで、データ量に合わせてきちんと設計しないとダメな典型ですね。
私の場合、個人的には正規化が染み付いてるので、まずは8.5.3節の「従属テーブル」を第一の採用候補で考えると思います。
たぶん自然と第三正規系にすれば従属テーブルに行き着くはず。
そのうえで、物理的にディスクI/Oを分散したいとか、性能がヤバげな場合に水平分散を検討することになるかなぁ。
その場合、水平分散への構造変換はALTERでできないこともあるようなので、移行手順とかきっちりしとかないとですね。
その際は書籍「データベースリファクタリング」の出番かもしれない。
他に、@t_wada さんオススメの一冊はコレだそうです。
参加者の皆様、ありがとうございました～
2013/8/28(水) 「DAD読書会#2」に参加してきました。
Facebook（メンバーのみ）
https://www.facebook.com/groups/172404826272150/以下の書籍をターゲットとした読書会なのです。
通称、DAD本。
以前、DevloveでこのDAD本のイベントがありました。そんとき書いたブログはこちら。
このイベントの後に、DAD本の読書会が立ち上がりました。
今回はその第2回目です。（ちなみに初回はお盆で帰省中だったので、残念ながら欠席）
場所は渋谷のキャロルシステム株式会社さんです。
主催の @terahide27 さん、会場提供ありがとーございます！
参加者は6人かな。ディスカッションするにはちょうど良い人数かもしれない。
この日は6～12章の「方向付け」フェーズがターゲットでした。
■会場案内の貼紙会場ビルの1Fエレベーター前に貼紙が。。。
「ゼロの使い魔」のルイズ！
懐かしい。。。
@terahide27 氏曰く、12章のケーススタディに登場するLouise氏から思いついて取ってきたとのこと。
P.214のLouise氏のセリフ
「それは清書していませんよ！」 とか、ちょとツンの要素あるよね。。。
おバカなこと書いていたら、久々にくぎゅ～したくなったのでポチっとな。。。
・・・気を取り直して。
最初に訳者のお1人、岡 大勝 氏より6～12章の読み方についてレクチャー戴きました。感謝！
ダラダラと個人メモを起こしてみる。
■「6～12章：方向付けフェーズ」読み方レクチャー by 岡さん
■6～12章「方向付けフェーズ」・6～12章の「方向付けフェーズ」がDADの全てといっても過言ではない。
・方向付けフェーズに本の1/3を割いている。
・受託開発は難しい。このギャップを埋めるエッセンスが「方向付けフェーズ」。
・プロジェクト全体を自己組織化したチームでJIT(Just In TIme)でどう進めるかがDADのテーマ。
・受託なんだけど計画もJITでやりたい、でも全部は無理。じゃあどうやるか？その解がDADの方向付けフェーズ。
■DADの使い方・DADの細かいところを覚える必要はない。
・DADもJITで使ってください。
・各章のまとめをポインタにして、掘り下げてブレークダウンして読むのが良い。
・DADは、落としどころを探すための辞書として使う。
■10章まとめ・受託開発については10章のまとめに書いてある。著者のスコット・アンブラーのアドバイス。
・ある程度予測して、マイルストーンを立てておきつつやりましょう。
・推奨は「アジャイル・リリース・プランニング（簡易に予測型）と適応的な計画型を組み合わせること」と書いてある。
・更に先に行くならば、イテレーションじゃなくてリーンになる。
・「リリースのリズムも大事」と書いてある。
・例えばエンタープライズでは、２週間ごとにリリースしても、業務も、運用とか教育も回らない。
・なので「内部リリース」と「外部リリース」に分ける。
・例えば内部リリースは２週間毎。外部リリースは３ヶ月毎とか。
・逆にサービス開発なら毎日リリースもあるかもしれない。
・結合テストは、自動化する前提でイテレーションの最後に毎回やる。内部リリースでも同じ。
■「方向付けフェーズ」の役割・方向付けフェーズはアジャイルサムライの「インセプションデッキ」と同じ。
・自分が使える武器は限られている。アジャイルサムライと同じやり方になることもある。
・お客さんからの指定がある時は、互いにきちんとすり合わせしましょう。
・「武器が少なくて合わないからアジャイルは適用できない」という文脈が増えてきちゃう。
→ そうじゃなくて、かなりのプロジェクトに適用するための武器を各章に表で一覧に載せている。
・各章にある表は、上の方はNASAとか医療系とか、厳密性が求められる分野に適用する。
・それだけじゃなくて、普通はこういう選択をしてくださいね、というアドバイスも各章に書いてある。
・選択肢を方向付けでざっと考えて、大枠を組み立てて、その枠が標準となる。
・ガバナンスで、中間成果物を途中納品する話は20章に出てくる。
・中間成果物を途中納品するスタイルはアジャイルに向かない。中間成果物がマイルストーンとなったら終わり。
・中間成果物はオンデマンドでリーダーが決めてあげればいい。
→ その方向付けを「方向付けフェーズ」でしましょう。
・方向付けフェーズは「見通しを立てる」という表現がしっくりくる。
・方向付けフェーズは要件定義フェーズに該当し、準委任契約が一般的。
・受託開発の見積もりを作る期間で、Agreeするためのフェーズ。
・DADはスコープも予算も前もってある程度決める。その枠組みを方向付けフェーズで幅を持たせて決める。
■「方向付けフェーズ」のアンチパターン・P.115に方向付けフェーズのアンチパターンが書いてある。
・方向付けフェーズでやっちゃいけないこととして、「独裁的プロジェクト管理」や「実装に飛び込む」がある。
・アジャイルだと「要件を聞いたらコードを書こう」と思ってしまうが、エンタープライズそれがと大きな手戻り原因になる。
■ウォーターフォール、RUP、DAD・ウォーターフォールが悪、という文脈で語られることがあるが、必ずしもそうじゃない。
・ウォーターフォールの良いところは、スキルの高低が平準化される点。
・今はオブジェクト指向とかモデリングとかで、横並びの大量生産が減っている。
・でもエンタープライズでは、ある程度の規模を超えた時に平準化が必要になってくる。
・RUP（Rational Unified Process）は細かい定義に走りすぎてて、重い。
・アジャイルはRUPの両極端にある。
・RUPとアジャイルの真ん中を狙うのがDADである。
・エンタープライズの受託開発は、95%くらいはウォーターフォール。
・ウォーターフォールからアジャイルは遠いと思う顧客は多いが、実は隣ぐらいの位置にある。
・プロジェクトの回し方は、ウォーターフォールだと成果物駆動でフェーズを切るが、アジャイルだとタイムボックスのイテレーションでフェーズを切る。
・違いは、フェーズの切り方の角度が90度変わるくらい。
・やるならミニプロジェクトで切っていきましょう。タイムボックスで区切ってやりましょう。
・そのようにやるためには、まず開発側がお客さんに信用してもらわないといけない。
・DADでは、設計書は必要なものは作成する。手書きメモも納品物に入れる。
・設計書は「必要になったら」作る。
・それをできる自由度をタイムボックスに残しておきましょう。
■ディスカッション岡さんが最初の40分くらいで当初の予定通り退席されたので、その後は残ったメンバでディスカッションです。
ホワイトボードと付箋はこんなカンジ。
以下のようなネタについてディスカッションしました。
■やりすぎない計画って？どうやるの？
■P.104の表6-1に「3週間の方向付けフェーズでのスケジュール例」があるが、これって最初に作れるの？
■エンタープライズだと現行システムの機能を踏襲しながら新システムを開発することが多いよね。
でも、現行機能を踏襲するならウォーターフォールの方が向くんじゃね？
移行開発がウォーターフォールでいいなら、DADって意味ないんじゃ。。。
■P.120で、開発構想書に「プロセスにDADを採用」と書くとあるが、「DAD」とだけじゃ広すぎじゃね？
各章の表で、一番上と一番下のやり方はほとんど別モノだし。。。
■方向付けフェーズで見積りの話が出たけど、イテレーションの中でストーリーをタスクに分解したあと、タスクの見積りってどうやってる？
---
議論は多岐に渡り、なかなか熱いディスカッションになりました。
んで時間が足りずにタイムアップなカンジ。
次回は、話し足りない方向付けフェーズのディスカッションを再度やるか、構築フェーズ（13章～）に入るかはFacebookで別途相談することになりました。
★感想：「DADの全て」とまで言わしめる方向付けフェーズ、奥深し！
エンタープライズだと、最初により一層しっかりとした「方向付け」が必要なんですね～。
この点については同意です。
具体的に何をどうやればいいかまでDAD本に書いてある点も、頼もしい限りだ。
あとは、書いてある内容をどれだけ自分が理解して、自分の言葉として語れるかが重要になると思う。
本に書いてあるからやりました、じゃ当然通用しないので。。。
主催の @terahide27 さん、読み方レクチャーしてくださった岡さん、参加者のみなさんありがとうございました。
2013/8/27(火) 横浜道場 特別編 「Challenge our Product Development's Assumption Change! ～ adapt PDAC to PDCA ～」に参加してきました。
DoorKeepr
http://yokohama-dojo.doorkeeper.jp/events/5061以下の書籍をターゲットとした読書会なのです。
場所はいつもの横浜、アットウェアさんです。
参加者は20人弱でしょうか。
今回は特別編ということで、江端一将氏をお招きしてワークショップをやりました。
■ディスカッション＆模造紙ウチのチームは道場主含む4名で、模造紙はこんなカンジ。大半が、道場主が書いたものｗ
以下、個人メモ。私が印象深かった点は
赤字にしました。
■江端さんの自己紹介・これまでは海外で活動してきたが、今は千葉にいて、活動の拠点を日本に移すとのこと。
・アジャイルコーチをやっている。
・オープンソースのコミッターをやっている。
・
「すくすくスクラム」というコミュニティを立ち上げた。他にもいくつかコミュニティで活動している。
■今日の議題大きく3点。今日はこれらに踏み込みたい。
１．成功の定義・プロダクト開発の常識が間違ってるんじゃないか？
・そもそも成功ってどう定義されるのか？
・「プロジェクトの成功」をきちんと定義してからプロジェクトに入った人って、どのくらいいるのか？
２．柔軟性・「柔軟性」って何を持って考えるべきなのか？
・柔軟じゃないほうが良いのは何か。
３．ものごとの賞味期限・ものごとには賞味期限がある。価値がある情報がインテリジェンスである。
■１．成功の定義■成功の定義とは？・成功ってどういうふうに定義しているのか？例えばプロジェクトとか製品開発の成功を例に考えてみて欲しい。
この問いに対し、ウチのチームから出た意見は以下。
・お客様のほしいものを提供できた時が成功。
・チームの人間関係が良い。
■プロジェクトを成功させるためのルールって必要だと思うか？この問いに対し、参加者から出た意見は以下。
・4人とか5人とか、一定の人数を超え始めたらルールは必要では。
・いや、一人でもルールがいるのでは。
・例えば、フレックス勤務でコアタイムが無いと、メンバが揃わないのでやりにくいことがあった。
→ チームであるためのルールが必要だと思った。
・法律順守は絶対必要だよね。
■プロジェクトで勝手にルールを作ってませんか？・プロジェクトで「ルールを作りましょう」って言い出す人って、どのくらいいますか？
・お金とか納期のデッドラインは、お客さんから言われますよね。
・でも、働き方のルールをお客さんから言われることはあまりないですよね。
・で、お客さんに「何かルールありますか？」と聞くと、「無い。どーゆうやりかたをやってもらってもいい、モラルに反しなければ」と言われる。
■プロジェクトのルールは決めたほうが良い！・なぜなら、
互いの意見が分かれたときに「私はこの前提でやってます」と言えるようになるから。
・ルールが無いと、コミュニケーションが難しい。
・でも、プロジェクトでルールを作ろうとはなかなかしない。
・自己組織化とか言われるけど、それって妄想だよね。
・ルールが必要だから、スクラムでも「スクラムマスター」を必要としてる。
■プロジェクトの終盤には大抵ルールがあるのに、なぜ最初に働き方のルールを決めないのか？この問いに対し、参加者から出た意見は以下。
・そんなルールなんて当たり前でしょ、というのがあるから。
・どこまで決めたら良いのかが分からないから。
・前例とか実績とかで暗黙で決まっているから。
■ルールは、合わなければ変えれば良い！・ルールは変わる。
・最初にルールを完璧に作る必要ってありますか？
・最初から完璧を求めると、難しいから誰もやりたがらない。
・そうじゃなく、
ルールを変えるためのルールを決めればいいのでは。
・イギリスのお客さんは、働き方のルールを最初に決めていた。
・最初にルールを決めることで、プロジェクトの成功率が25%くらい上がった、という実績もある。
・スクラムのルールは走ってるが、プロジェクトを成功に導くルール決めをしないことが多い。
・それは思考停止である。
■成功に完成形はあるか？・成功に完成形が無いなら、なぜ「プロジェクトが成功した」というニュースが聞こえてくるのか？
この問いに対し、参加者から出た意見は以下。
・完璧じゃなくて、ある指標を超えたら成功、としているのでは。
・時間は動いているので永続的な成功が定義できない。
・成功の判断は他人がしているので、自分と他人の成功の基準が違うことが多い。判断軸の違い。
・成功の定義が主観的。
■楽天は成功していると言えますか？この問いに対し、参加者から出た意見は以下。
・判断が付かない。
・分野によって違う。成功してる分野もあれば失敗してる分野もある。
・成功してると思う。なぜなら、ベンチャーがこれだけ高い倒産率を示す中で高い企業生存率を示しているから。
・企業が大きくなって規模が永続しているので、成功と見なせるのでは。
■プロジェクトに入った時に、何を目標にしますか？・何かを目指していますか？
・それをプロジェクトの完成形に置き換えることはできますか？
この問いに対し、参加者から出た意見は以下。
・成功を決めると足を止めてしまう。なので目標を決めて達成を目指す。
・「黒字化」という前提があるのでは。
・大きな会社を超えるぞ、みたいな目標を立てる。より大きな目標をきめる。その際は売上が目標になることが多い。
・納期内に仕様を満たしたものをリリースする。
■プロジェクトの目標は「黒字」が大前提になっている。それで合ってますか？この問いに対し、参加者から出た意見は以下。
・エンドユーザ向けなら、エンドユーザの満足度が成功では。
■エンドユーザの満足度が高ければ成功と言えるなら、大赤字でもいいのか？・「ビジネスに黒字は大前提だけど、成功の完成形はない」と、どの国でも言う。
・でも、そんなたくさんのこと考えてますか？
・
何に基づいて目標が定められるのが理解されていない状態を検証しないで、本当に良いのか？・プロジェクトを進める上で、何を変えることが良いことなのか。
・ビジネスは難しい。なにをやれば黒字になるかわからない。
・根拠のない数字が、従うべき数字なのか？例えばマイルストーンとか。
■プロジェクトを成功させるために常識を変えたほうが良いものはあるか？・他の人と自分が考えることの共通認識をどう取るか？
・コミュニケーションのキッカケはルールでなくてもいい。
・ルールをいくつ置くかで、プロジェクトの成功を高められるのでは。
・スクラムの良いところは「フィードバックループを上手く使いましょう」という思想がデフォルトで入っているところだと思っている。
・でも、それを超えるものがあるはずだ、と思っている。
・
目に見えてるところと実際は、必ずしも一致しない。向こう側にきっと別の誰かがいる。・意思疎通のキッカケが多いほうが、成功の確率を高めるひとつの方法である。
・どうやってみんなをフォーカスさせていくかが重要。その方法はたくさんある。
・
「標準化」も良い。「標準化」が悪いんじゃなくて、「標準化したものが形骸化すること」がダメなんだ。・「標準化」することで、時間をかけずに済むメリットもあるはず。
・実は形骸化する前に気づけるものがあるはず。
・
「あなたの思っている常識がカイゼンのポイントになる」とはスクラムではよく言う。
・
「常識には罠がある」と思ってみるのがよい。２．柔軟性アジャイルをやってると「柔軟性」というキーワードによく遭遇する。
・では、私達が柔軟性を持つべきものはどういうものなのか。
・柔軟性は何種類あるのか。
■柔軟性を持たせたほうが良いものと、持たせないほうが良いものは何か？この問いに対し、ウチのチームで出た意見は以下。
●柔軟性を持たせたほうが良いもの ・失敗から学ぶ姿勢
・常識に囚われない
・相手の意見を取り込む
●柔軟性を持たせないほうが良いもの ・自動化する際のルール。
→ 例えば、コーディングルールとか。静的解析ツールで自動チェックしようとすると、厳密性が求められる。
■出た意見を他のチームと共有してほしいチーム4名のうち、2人が他のチームへヒヤリングへ行きました。残り2人は、他のチームから来た方に説明する係。
他のチームでは以下のような意見が出てました。
●柔軟性を持たせたほうが良いもの ・開発場所
・仕様
・ルール
・チームメンバ（例えば、ピンポイントでデザイナーさんを呼んでくるとか）
●柔軟性を持たせないほうが良いもの ・チームメンバ（アジャイルはチームメンバをあまり変えないほうが良いとしている）
・ルール変更のためのルール
・コアタイム
・信念
■「ヒヤリングする側」と「伝える側」の成功として、あなたは何を定義したか？・皆さん、共有の場でどういうことに貢献しようとしましたか？
・それは私（江端さん）の意図と一致しているか？
・なぜ、「どういう役割をこなせばいいのか」と私（江端さん）に確認しに行く選択をしなかったのか？
・「聞くまでもない」という考えが、皆さん常識としてあったのでは？
・では、あなたの常識をどう証明しますか？
■間違っていることを証明するのは難しくない。正しいことを証明するのは難しい。・「お客様に聞けば良い」という文脈で、「確認する」という文脈は思い浮かばない。これが罠。
・互いに「なぜ教えてくれないのか」、「なぜ分かってくれないのか」となる。この齟齬は何か？
・それではお互い繋がりっこないが、お互いに言い分がある。
・果たしてそれでコミュニケーションが成立しますか？
・真剣にやってるほど、そうなってしまう。相手に「こうして欲しい」となってしまう。
・「当たり前だろ」となってしまう、そここそが問題なんだ。
■柔軟性と適当は同じではない・どこを疎として、どこを密とするかの戦略が無いと、ものごとは上手く進まない。
・どこにボトルネックを持たせるのか、持たせないのか、を考えること。
・
「当たり前」に気づけることが大事。
・出会いや縁は偶然だが、学んだり経験することは自分から機会を持っていける。
・柔軟性を考える上で、直感に従うと間違っていることが多い。
・人間が考える「常識」には、罠がある。そこに気付けるかどうか。■３．ものごとの賞味期限（消費期限）■ものごとには賞味期限がある。では、賞味期限のないものはあるか？この問いに対し、参加者から出た意見は以下。
・信念、ポリシー
・でも信念やポリシーは時代の移り変わりによって変わるのでは。
・普遍なものはない、という考えは普遍。
■ものごとに賞味期限がある場合、それをどう計測しているか？・何かを変えるために、何かを計測していますか？それとも、闇雲？
・何か判断軸があるはずでは？
■PDCAサイクルは意識しないと回せない・プロジェクトの最後にやる「振り返り」を活かしたのはどれくらいありますか？
・なぜ「振り返り」をするのに改善できないのか？
・それは、
仮説検証をしていないから。
・明文化せず勝手に思い込んでることが原因になる。
・気づいたこと、考えにも、維持するための期限がある。
・チャンスを活かすにも期限はある。
・インパクトだけじゃなく、改善までに取り込む時間に法則がある。
・改善が可能な時間を超えると、改善することができなくなる。・それは、日々の雑務よって遠くなる。
・改善しないといけないこと以外は雑務。活かすこと以外は雑務。
■４．まとめ・今日の話は、どのプロジェクトにも共通だからテーマとして選んだ。
・プロジェクトに最初、ルールがないのに、途中から「あたりまえ」という言葉が出てくる。そうじゃない。
・
持ってる情報には期限がある。情報は持っているだけじゃダメなんだ。・人間がもっとも思考しにくい部分が今日の話のテーマ。
・関わるのが人間である限り、今日のテーマは世界中でもあまり変わらないことがわかった。
・なので、しばらくは日本で活動しようと思っている。光石探しに世界に出たが、なにひとつ無かった。
・整理する、定義していくことが日本人はあまりにもヘタ。
・ルール決める１つとっても、海外は「とりあえず決める」。
・日本は、ルールが嫌になると、勝手に守らなくなる。それって「柔軟」とは違うよね。
・そこに気付いて改善してくことがプロジェクトの成功率を高めていくと思う。
・プロジェクトの振り返りを活かせないのは世界共通。
・
期限があるなら計測しましょう。検証しましょう。・成功しないプロジェクトは、仕組みがイケてない。
上手くいかないときは、仕組みを変えるべき。・考えるプロセスも仕組みの１つ。考える順番だったり、人との接し方とかも仕組みの１つ。
・感情面はコントロールできない。でもそういう感情にならない仕組みは取り入れていけるのでは。
・変えるべきは「仕組み」なんだ。
★感想：非常に興味深い切り口のワークショップでした。
心の奥底に踏み込むというか。。。ｗ
ハッ！とさせられるキーワードも多かったですねー。「情報や改善には期限がある」なんて、グサッと。
例えば勉強会で学んだ知識もINPUTばっかじゃダメで、実践を通してOUTPUTしたりしていかないと、いつかは「期限」を迎えるわけで。。。
この日のワークショップで学んだ知識も、活かせるまでの期限があるわけで。。。
あと、常識を疑う、という点が実に興味深い動作だ。
何かの判断を下す際、自分という存在から一歩引いて、第三者の視点とか立場の異なる人の視点から物事を考え直してみる、というプロセスを個人的には意識してみようと思いました。
あと、やっぱ自分1人では気付けないことも多々ありそうで、他の人の考えを参考に自分の下した判断や常識を補正する、というのも必要そうです。
@makopi23よ！今後は決断する前に一度、常識を疑え！
講師の江端さん、参加者の皆さん、ありがとうございました。
あ、あと折り畳み傘、ようやく回収できたよ。。。
-->
