2013/11/20(水) SQLアンチパターン読書会 「インデックスショットガン」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/7054以下の書籍をターゲットとした読書会なのです。
場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。
参加者は8人かな。毎度の顔馴染みメンバーです。
今回は12章「インデックスショットガン」がターゲットでした。
DB性能と言えば避けられない話題で、大変楽しみでした。
■アジェンダ今回は @tonyuchi さんがスライドを作成し説明してくださいました。感謝！
書籍の本題に入る前にインデックスの仕組みについての説明があったり、実際にOracleを使って実験し考察までしていたりと、素晴らしいスライドです。
■ディスカッション今回もディスカッションしたいネタをみんなで付箋に書き出しました。
以下、個人メモ。
---
■12.2 インデックスを多く定義し過ぎる・ほとんどのデータベースは、主キーのインデックスを自動的に作成するので、明示的に定義するのは冗長。
・Oracleは主キーにインデックスを付与しようとするとエラーになるらしい。
・外部キーに自動でインデックスが付与されるか否かは、データベース製品によって異なる。
■12.2.3 インデックスが役立たないとき・LIKE検索で、中間一致だけでなく後方一致もインデックスが効かない。
■12.5 解決策：「MENTOR」の原則に基づいて効果的なインデックス管理を行う・「MENTOR」という単語はこの著者のみが使っている独自用語。
・P.130の2行目に「君には、ちょっとしたメンタリングが必要なだけなんだ」とあるが、実はこの文章は「メンタリング」に「MENTOR」を掛けた布石だった！
■オプティマイザ・オプティマイザには大きく2種類ある。
①ルールベースオプティマイザ
②コストベースオプティマイザ
・昔はルールベースオプティマイザが主流で、WHERE句の上に書いたものから順にインデックスが使われた。
・今はコストベースオプティマイザが主流で、WHERE句のインデックスの使い方は書いた順序によらない。
・ただコストベースオプティマイザでも、SQLの可読性の関係で上から書いた方が良い。
■バキューム処理・PostgreSQLは「追記型アーキテクチャ」なので、掃除しないと遅くなる。
・昔のPostgreSQLは、掃除を自動でするオートバキューム(autovacuum)の機能が無かった。
・(参考) 追記型アーキテクチャ：
ある行にUPDATE文を実行すると、既存の行の領域には「このデータはこの時点で書き換えられた」ということだけを書き換え、更新後内容の行を新たに追記して書き込む方式のことらしい。
参考： 第1回 PostgreSQLの概要とアーキテクチャ
http://thinkit.co.jp/article/1038/1/page/0/2・ちなみにMySQLは上書きアーキテクチャ。
■インデックスを付けるタイミング・インデックスはSQLの結果に影響を与えない。
→ まず、わかるやつは先にインデックスを付けておく。わからないのは後で付ける。
・まず正規化をしましょう。
・性能問題は、一番遅いボトルネックを対策しないと、他をチューニングしても意味がない。
・MENTORは測定(Measure)と解析(Explain)が先に来ているのが良い点。
■Explain(解析)・MySQLのEXPLAIN結果は複雑で、初見では読めない。。。
・ベンダの商用データベースのEXPLAINはGUIが充実していて見やすい。
・IBMのDB2は、EXPLAINをツリーで表示させてくれる。
・オープンソースと商用データベースのEXPLAINは、だいぶ差が付いている。
→ SQLは差別化しにくいので、ここが差別化の要因となってたりする。
■性能チューニング・ヒント句を使うのはバッチアプリケーションで多い。Webアプリではあんまりない。
・ORMはヒント句が使えないので嫌、という意見もある。
・iBATISとかS2Daoとか、生SQLも書けるORMの方が歓迎される現場もある。
→ SQLを外出しにできるので、手でチューニングしやすいので差別化できる。
・RDBMSだけが選択肢ではない。
→ メインはRDBで、サブはDynamo DBを選択したりとか。
→ あいまい検索とかは全文検索エンジンを使用したりとか。
→ KeyValue型とか、いろいろ選択肢はある。
■インデックスの数・１つのテーブルに100以上のインデックスが貼られているのを見たことがある。
→ データマイニングのアプリで、多面的な分析を考慮してインデックスを貼っていた。
・複合プライマリキーを使うとインデックスが増えがち。
■苦戦した翻訳ｗ・12章の冒頭に出てくるオクラホマ訛りの翻訳がすごく大変だった。。。
・翻訳者の児島さんに相談して、翻訳を止めた by @t_wada さん
■ORDER BY 狙いのキーの話・@kamipo さんのTogetterが参考になる。
①ORDER BY 狙いのキーの話：
http://togetter.com/li/564015 ②ORDER BY 狙いのキーの話2：
http://togetter.com/li/579823・Webアプリでは、LimitとOrder by狙いの方を、絞込よりも優先したほうが良い。
・並び順と取得件数を考慮しましょう。
・このスライドも面白くて参考になる。 by @grimrose さん
とあるイルカのバーボンハウス (
http://www.slideshare.net/yoku0825/ss-27597161 )
■インデックスに対するコメント・インデックスにもコメントを付けて欲しい。インデックスの設計書とかに。
・SIerとかではインデックス設計書を良く見かける。
でも、マトリクスに○付けるあのフォーマットは、複合インデックスを作りたくなるので良くないかもｗ
■インデックスの種類以下のような種類がある。インデックスはSQL標準ではなく、各RDBMSに依存する。
・B-Treeインデックス
・ビットマップインデックス
・降順インデックス
・ハッシュインデックス
■選択性（Selectivity）とカーディナリティ・選択性は「カーディナリティ」って言葉で使われることもあるが、これは3つの意味があるので紛らわしい。
・「カーディナリティて何ですの」というブログが参考になる。
http://d.hatena.ne.jp/tgk/20070517/1179414774 ①relationのカーディナリティ
②relationshipのカーディナリティ
③キーのカーディナリティ
・テーブル同士の関係は「relationship」で、タプルの数が「relation」である。
・リレーションについてはSQLアンチパターンの付録Aにも書いてある。
■インデックスに関する普遍の事実・まず、きちんと計測しましょう。
・一番遅い箇所から対策しないと意味がない
■KPT（ふりかえり）今回で第Ⅱ部まで終了し、キリが良いということでKPT（ふりかえり）をやりました。
遠くから撮ったのでピンボケしてます。。。
主催の @natsu_nanana さんが文字に起こしてFacebookのグループに投稿してくださいました。感謝！
★感想：DB性能と言えばインデックス！というくらいに、性能チューニングでインデックスに悩まされた経験がある人は多いのでは。。。
ということで、この章は大変興味がありました。
MENTOR、という考え方は、DB性能を考える上でキーワードとして使えるのでは、と思いました。
あと個人的には、B-Treeインデックスとかビットマップインデックスとかが、どういう仕組みで実現されているのか、中身の構造をちょと勉強したいと思いました。
結局、いつも推測の範囲でやっちゃってたところもあるので、きちんと理解した上で判断することが重要だなぁと思うことが度々あったので。
参加者の皆様、ありがとうございました～
★オマケとりあえず第Ⅱ部の12章まで終わったので、いったん自分のブログエントリを纏めてみる。
---
1章：SQLアンチパターン読書会 「ジェイウォーク」に参加しました
http://makopi23.blog.fc2.com/blog-entry-65.html2章：SQLアンチパターン読書会 「ナイーブツリー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-70.html3章：SQLアンチパターン読書会 「IDリクワイアド」に参加しました
http://makopi23.blog.fc2.com/blog-entry-73.html3章：SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-77.html4章；SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-84.html5章：SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
http://makopi23.blog.fc2.com/blog-entry-90.html6章：SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-94.html7章：SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
http://makopi23.blog.fc2.com/blog-entry-97.html8章：SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-105.html9章：SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
http://makopi23.blog.fc2.com/blog-entry-109.html10章：SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
http://makopi23.blog.fc2.com/blog-entry-115.html11章：SQLアンチパターン読書会 「ファントムファイル」に参加しました
http://makopi23.blog.fc2.com/blog-entry-118.html12章：SQLアンチパターン読書会 「インデックスショットガン」に参加しました
http://makopi23.blog.fc2.com/blog-entry-121.html---
一応、毎回書いている！ｗ
2013/11/17(日) 「第3回 神戸マラソン」に参加してきました。
公式サイト
http://www.kobe-marathon.net/もちろんエントリーは42.195kmのフルマラソン！
今年は定員18,000人に対し、申し込みは80,416人で、倍率は約4.5倍だったそうです。
makopi23が当選したのも、きっと日頃の行いが良(ry
ちなみに関西での大阪マラソンと神戸マラソンの扱いは、関東での東京マラソンにも匹敵します。
電車には神戸マラソンの広告が多数ぶら下がり、新聞でも前日・当日は数ページが割かれて大きく扱われます。
そしてもちろん、TV中継はスタートからフィニッシュまで、7時間まるごと生放送！
http://www.sun-tv.co.jp/special/kobe_marathon13/今年の沿道の応援は、過去最高の57万人だったそうです。
関西人の応援は人情味があってエエわ～
コースは神戸市役所前をスタートし、明石海峡大橋を折り返し、ポートアイランドがフィニッシュです。
http://www.kobe-marathon.net/pdf/course.pdf海岸沿いを走る絶景はもちろん、沿道の熱い応援がとても素晴らしい！
ちなみに私、入社して最初に配属された部署がまさしくこの地、神戸・三宮だったのでした。
スタート地点の神戸市役所や、隣駅の兵庫県警察本部にはよく通ったものです。懐かしい～
実家の大阪府箕面市からも阪急電車で約1時間、たった360円で来れるという、けっこー近場なのです。
↓は、スタート地点に隣接している震災復興記念公園の手荷物預け所にて。早朝7:50、快晴。
ということで、9時に神戸市役所前からスタート！
さすがに人数が多くて、スタートラインを超えるまでに10分以上かかりました。
あと、いろいろ仮装してるランナーが多くて、こちらもマラソンを楽しむ要素になってると思います。
ルパン、五右衛門、次元、銭形の衣装を身にまとった4人組とか、下駄で走ってる弁慶の人とか、素直にすげーなぁ、と思いましたね。
ルパン一味とはけっこー長い間、併走させていただきました。こっちも元気になります。
つーか今回、25km付近のでコンビニで、ウイダーインゼリーと壮健美茶を買って自前でエネルギー補給しちまった！
・・・ということで、makopi23のゴールシーン。動画13:35付近。ヘロヘロでワロタｗ
ネットタイムで、6時間1分。。。
過去最低タイムになってしまいました。。。
2週間前に湘南国際マラソンを走って、足にダメージが残っていたという点は否めないが、他に原因は分かっている。
神戸マラソンの制限時間が7時間で緩い、という点。
やっぱ走ってると、制限時間までに完走するための逆算を何回もして、それにペースを合わせてしまいます。
体が辛くなってくると、どうしても体が制限時間に合わせてしまう。。。
・・・ということで、ゴール地点で完走メダルを貰いました。今回もなんとか完走できてホッとしました。
ゴール前で有森裕子さんとハイタッチしたのが印象的でした。有森さんと言えば、バルセロナ五輪で金メダル！
やっぱ、コースのど真ん中で、ランナーと同じ高さの目線でのハイタッチとは、有森さんらしいですね～
マジ、最後に元気出た！
ま、まけた。。。
★感想：素晴らしい大会でした！
コースも、応援も、運営も。とても印象に残りましたね～
特に、沿道の応援が素晴らしい。スタッフさんも、ボランティアさんも、市民の方々も、温かい応援。
やはり関西のノリがあるんですかね～。心に染み入ります。
また来年も走りたいと思いました。
あとは、フルマラソンを走るたびにタイムが悪くなるという負のスパイラルを打開したい。
経験を積むたびに、体が勝手に計算してセーブしてしまう。
次回は来年1月の、館山若潮マラソンです。
そこまでにもっと練習をして、日々精進したいと思う今日この頃なのでした。
2013/11/7(木) SQLアンチパターン読書会 「ファントムファイル」に参加してきました。
DoorKeeper
http://sqlap.doorkeeper.jp/events/6957以下の書籍をターゲットとした読書会なのです。
場所はいつもの湯島、株式会社アルティネットさんです。
いつも会場提供ありがとうございます。
参加者は9人かな。
最初はおなじみの顔ぶれ8人で始まりましたが、1時間ほど遅れて1名、新規の参加がありました。
新しい風が入るのは良いですね～
今回は２６のアンチパターンの中で最も意見が分かれると言われる「ファントムファイル」がターゲットです。
■アジェンダ今回は @akuraru さんがアジェンダ資料を作成して説明してくださいました。感謝～
LOBロケータが興味深いですね。これについては後述。
■ディスカッションいつもと同様、ディスカッションしたいネタを付箋に書き出しました。
以下、当日の個人メモ。
---
■LOBロケータ・外部のファイルと関連付けられたポインタのこと。
・OracleだとBFILE型が該当するらしい。
→ BFILE型とは、DB外に保存される大きなバイナリ・ファイルへのロケータを格納するデータ型のことらしい。
・この型を使うと、DBにはファイルパスしか格納されていないが、外部のファイルと関連付けられる。
→ DBに格納されているのはファイルパスの文字列だけど、ファイルと関連づいていることをOracleが知っている。
・ちょとOracleのマニュアルを調べてみた↓
①BLOB、CLOBおよびNCLOBは、データベース表領域に永続的に格納され、これらのデータ型に対する操作はすべて、トランザクション制御の下で実行されます。
②
BFILEデータは、トランザクション制御下にはなく、データベース・バックアップでは保存されません。
→ BFILEはトランザクション制御下に無いらしい！残念。。。
出典：
http://docs.oracle.com/cd/E49329_01/java.121/b71308/oralob.htm■トランザクション分離レベル・ファイルを外部に格納すると、ファイルの変更がコミット前に他の人に見えちゃう。
→ （これは多分、ファントム・リード(Phantom Read) の一種になるのかな。。。）
・トランザクション分離レベル：
wikipedia・トランザクション分離レベルはDBMSで設定できる。
→ 実際のプロジェクトでは、トランザクション分離レベルの設定をあまりやってないことが多い。
（DBMSのデフォルトのまま、ということが多い）
■ファイルパスをDBに格納する弊害・ファイルパスをDBに格納すると、開発環境と本番環境でディレクトリ構成が異なっている場合にバグやエラーの温床となりやすい。
■BLOBの利点・マルチテナントアーキテクチャと相性がいい。
→ 同じ環境上に複数のテナントが入る場合、DBにバイナリを突っ込むと、他のテナントからは見えなくできる。
→ 逆に、外部にバイナリを置くと、他から見えてしまう。
・ただ、今ならマルチテナントとして同一環境に乗せるより、仮想環境をそもそも分けるべき。
・クラウド環境でファイルシステムが自由に使えない場合は、BLOBを使うのが有効。
・バイナリの履歴を管理しなければならない場合、BLOBでDBに突っ込むのはアリ。
■BLOBの欠点・BLOBを使うと、BLOBの数だけ、HTTPリクエストのコネクションが多くなるらしい。
・BLOBにバイナリを格納すると、毎回DBにバイナリを取りに行かないといけないので、負荷分散できない。
・画像だと、並列アクセスできるようにディスクに置いておけば性能が上がる。
・BLOBはDBから取り出すまでサイズが不明なので、DBエンジンの最適化が効かない。
・HTTP通信では、If-Modified-Sinceという設定をリクエストヘッダに付けることで、バイナリをキャッシュしてくれる。
→DBにバイナリを入れるとこの仕組みが使えないので、自分でキャッシュの仕組みを作り込まないといけない。
・BLOBに画像を格納すると、気軽に中身を確認できない。アプリ通さないと画像を見れなかったりとか。
■画像ファイルのBLOB格納・ファイルシステムに画像を格納しようとすると、日本語不可、などの制約が掛かることがある。
・そのため、DBに画像ファイル名を格納するためのカラムを用意して、その名称でダウンロードさせるようにすることが多い。
・ファイル名、Content-Type、ファイルサイズ、の3種類は、画像と一緒にDBに格納することが多い。
■日本語ファイル名の扱い・ブラウザによって、ファイル名の文字コードの扱いが違う。
・ファイル名はOSとサーバの組み合わせの関係で、そのまま使えないことが多い。
・日本語ファイル名でアップロードされてきたものをUTF-8で保存して、エンドユーザに返すときにUTF-8でエンコードして返すような工夫が必要。
・HTTPヘッダのContent-Dispositionフィールドに文字コードを指定することで、ファイル名の文字化けを回避したりする工夫が必要なことがあるらしい。
・日本語ファイル名の扱いは面倒くさいので、ダウンロードの際にユーザにファイル名を入れさせて、自己責任な設計にしたことがあった。
・空白込みのファイル名とかも在り得るので、扱いは面倒。
・ブラウザがデータを表示させるときのHTTPヘッダを見ると勉強になる。
■11.2.5節 アクセス権限・ファイルシステムへのアクセス権限は付与しにくいため、誰でもアクセスできてしまう。
→ バイナリファイルを格納すると、第三者に見えてしまう。
・SQLアクセス権限はGLANTを使ってDB接続ユーザごとに設定でき、アクセス制限をDBレベルで制御できる。
→ BLOBとしてバイナリを格納すれば、必要なユーザのみ参照を制限できる。
・コネクションユーザによって権限を変える、という制御は、Webアプリではあまりやらない。
・SQLインジェクションでDROP TABLEできてしまうのは、サーバにその権限を与えているから。
→ CREATEとかDROPとかは業務でやらないはずだから、REVOKEで権限を削除しておくべき。
・DBAがいないプロジェクトだと、全権ユーザにしていたりとかがよく起こる。
・ガチガチのとこなら、参照系テーブルを全部Viewにして、物理的に更新できないようにしたりすることがある。
■11.2.節 バックアップ・DBでバイナリ格納用にスキーマを分けると、バックアップ運用が楽になる。
■バイナリをBLOBに格納するか、DB外部にファイルとして格納するかの判断・どちらにするかは、パフォーマンスを取るか、整合性を取るかで変わる。
・外部の第三者に見えないようにするのか（BLOB採用）、外部から見えてよいが性能を重視するのか、状況による。
・アンチパターンなのは、「バイナリはファイルシステムに入れるのが正解」と固定概念で考えてしまうこと。
・ファイルシステムに置くとこーゆうことが出来なくなりますよ、ということを知った上でやることが重要。
■バイナリをBLOBに格納する時の工夫点・システムが稼動開始し保守フェーズに入ると、メンテのためにSELECT * のSQLを発行することが多い。
→ そのテーブルにBLOBカラムが途中にあると、SELECT * の取得結果が悲惨なことになる。
・そこで、主キーとBLOBカラムだけ持つようなバイナリ格納用テーブルを別で用意する。
→ そのテーブルへの外部参照キーを設定しておき、バイナリが必要になった時だけJOINするようにする。
→ こうすると、毎回BLOBを取得する必要がなくなり、参照性や性能が向上する。
■Last Resource Commit Optimization (LRCO)・トランザクションに参加できない処理を最後に扱いましょう。
→ 例えば、ファイルシステムにあるファイルの削除など、後戻りできない処理は最後の方にずらす。
・JavaのAPサーバの世界はトランザクションが強い。その理由は２フェーズコミットにある。
→ ２フェーズコミットに乗れるなら整合性の面で安全である。
→ ２フェーズコミットの仕組みに乗れない処理は、一番最後にやるようにすべき。
→ 例えばファイルの移動なら、別の場所にファイルを置いておき、一番最後にリネームでパチッと切り替える。
・PHPとかは、この仕組みがないので絶望することになる・・・
・有償のアプリケーションサーバ（WebSphereとかWebLogicとか）がなぜ高価なのかというと、それはトランザクションモニタが高価だから。
・トランザクションモニタが高価なのは、２フェーズコミットが困難だから。
・トランザクションモニタは、エンタープライズ分野で性能よりも整合性を重視する時代に発達した。
■ファイルアップローダを作ろう・URL：
http://rosylilly.hatenablog.com/entry/2013/10/21/190019・ファイルアップロードを実現するには、バイナリとかストリームとかURLとか、考えないといけないことが多いので、すごく勉強になる。
★感想：ファントムファイルはシンプルなので、議題がそれほど出ないのでは、という意見も当初ありました。
ところがどっこい、とても多くの議論ポイントが出てくる出てくる！
とても有意義なディスカッションでした。
あとディスカッションでも話に出ましたが、このアンチパターンの本質は「バイナリはファイルシステムに入れるのが正解」と固定概念で考えてしまうことかもしれません。
いわゆる思考停止ですね。
BLOBで格納するかDB外部に格納するかは、両者の利点と欠点をきちんと理解した上で選択することが大事！
あとは、Last Resource Commit Optimization (LRCO)という概念も大変勉強になりました。
LOBロケータや２フェーズコミットの仕組みも大変興味深いです。
ファントムファイル、奥深し！
参加者・関係者の皆様、ありがとうございました～
2013/11/5(火) 『横浜道場 特別編 「見せて貰おうか、KPTの性能とやらを・・・。」～KPTの基本と、その活用法～』に参加してきました。
DoorKeepr
http://yokohama-dojo.doorkeeper.jp/events/5949以下の書籍をターゲットとした読書会なのです。
ちなみに本を読む通常会は先日最終回を迎えたので、今回は特別編です。
テーマは、アジャイルではおなじみの、KPT～
場所はいつもの横浜、アットウェアさんです。
参加者は満員御礼の30人かな？特別編は人気がありますね～
講師は、先日以下の書籍を執筆された永和システムマネジメントの天野 勝さんです。
今回の題目にある 「見せて貰おうか、ＸＸＸの性能とやらを・・・」というのは、もちろんあの名言が由来ですね。
というわけで久しぶりに赤い彗星の美声を聞きたくなったのでポチっとな。
以下、天野さんの講演時の口頭説明を中心に自分メモ。
■講演＋ワークショップ ■KPT・KPTは、物事を整理するためのフレームワーク。
・みんなが思っているほど有名じゃない
・今日の話の内容は以下の書籍にほとんど書いてある。
・出版社が「これだけ！○○」シリーズを出版していて、今回執筆のお願いが来た。
■KPTとは （P.8/33）・アリスター・コーバーンが書いた「アジャイルソフトウェア開発」という書籍にKPTが出てくる。
・KPTは、分かってくるとどこでも使えて便利。
・「やりっ放しってよくないよね」ということで、そこで使うと効果的なフレームワーク。
・振り返りによく使われる。
・KPTのKeep, Problem, Tryのそれぞれの日本語訳はどーでもいい。
・KPTは「けぷと」と発音する
■KPTのステップ （P.9/33）・左側のKeepとProblemから始める。
・次にKeep, Problemのそれぞれに対して改善策を考える。
・Tryの領域がKeep,Problemより大きくなっている点がポイント。
・ProblemだけではなくKeepに対してもTryも考える。ProblemからだけTryを考えるのは日本的である。
・Keep, Problemからだけではなく、工夫したいこともどんどんTryに入れる。
・Tryに挙がった中から、試すことをいくつか選んでやってみる。
・上手くいったことはKeppにまた入る。
・これらのステップががグルグル回る。
■KPTによるナレッジサイクル （P.10/33）・Keepに良い行動のナレッジが蓄積される。
・これが次へ次へ、と繋がっていう。
・このグルグル回るフォーマットがKPTの良いトコだと思っている。
・領域が３つしかないので単純で、工夫の余地ある。自分なりにアレンジしてよい。
■Ｋｅｅｐ（続けたいこと、良いこと） （P.11/33）・Keepを上げるのすごく難しい。いきなりKeepが出てくることは少ないんじゃないか。
・それに対し、Problemは簡単に出てくる。
・Keepを出すときのヒントは、「些細なことでも挙げる」こと。
・個人的なことも挙げてよい。「共通のことを挙げなきゃ」というプレッシャーは必要ない。
■Problem（不満点、問題点） （P.12/33）・Problemに対し、「不満」というニュアンスが気に入っている。
・Problemを「問題点」というと、大げさ。分析しないと出てこないイメージになる。
・未来の問題をあげておくとよい。
・Problemがうまく行かない代表的なポイントは、「行動の否定系」を書いちゃうとこ。「～してない」は要注意。
→Tryが「～してない」の裏返しとして「～する」しか書かれなくなる。
・「～してない」だけだと、その背景が探れない。
■Try（改善策、工夫してみたいこと） （P.13/33）・Tryを出す時は３つの視点で考える
①ProbllemからTryへ
②KeepからTryへ
③閃きからTryへ
・Tryが形骸化するパターンは、Tryをたくさん挙げて一気にやろうとすること。
・次の振り返りで、「前回のTryのどれもやれてない。。。」というようなことが続くと、「改善策を考えてもなぁ・・・」となってしまう。
・なので、効果がありそうな改善策をいくつか絞ってやるのが良い。
・抽象的なTryは行動できないので、どこかのタイミングで行動できるようにブレークダウンする。
・「しっかり～する」とか「ちゃんと～する」は、行動に移すにも困ってしまう。なので具体的なキーワードを入れること。
■演習：明日の私 （P.15/33）・各自、KPTで今日を振り返り、明日の行動を考える。
・KPTはマインドマップ風にやるとやり易かったりする。
・ということで、自分でちゃちゃっと書いてみた。
・各自書いた後、それを隣の人と確認する。ポイントは「Problemが行動の否定系になっていないか」という点。
・あと、Problemは「行動に移せる指標に繋げられるものがあるとよい」というコメントを隣の参加者から戴きました。
・天野さん曰く、Problemのダメな例：「メールを数時間見ていなかった」
→ 「メールを数時間見ていないと何が悪いのか」という所まで踏みこめていない。
→ 「メールを数時間見ていなかったことで、緊急のメールに対する返信が遅れた」というくらいまで掘り下げて考えるべき。
・掘り下げることが重要。そうすることで、Problemの裏返しじゃないＴｒｙが出てくるようになる。
■KPTの活用法 （P.17/33）・KPTだけで頑張るのは限界。
→ 「これだけ！KPT」の本は、KPT以外のことがたくさん書いてる。
→ どうKPTを活用するかがポイント。本の中心もそこにある。
■ソフトウェア開発でのKPTの適用例 （P.18/33）・KPTはウォーターフォールでもやれる。各工程の終了毎にKPTをやったりとか。
・保守でも「案件毎」に振り返りをする。「案件毎」でなく「1ヶ月毎」にやったりすることもある。
■ソフトウェア開発以外でのKPTの適用例 （P.19/33）・PMOでの情報共有や、コールセンターでモチベーション向上を狙ってKPTをやったりとか。
・朝会ブームの時に、毎日の発言が「通常の業務です」しかでなかった。。。
→ 朝会の満足度を手で表現してください、としたら、１とか３しか出なかった。
→ 「それでいいんですか？」ということで打開策を考えるようにした。
■自宅でのKPTの適用例 （P.20/33）・バスケットボールチームでもKPTをやった事例がある。
→ K：よいところ、P：もうちょっと頑張れたと思うところ、T：次はどうするか
・K, P, Tのそれぞれの訳はどーでもいい。
・ピアノの練習で、K：練習した時間、P：遊んだ時間、T：来週の練習時間、というふうにした事例もあった。
・「KPTとは」という話を聞かなくてもできるのがポイント。
■ふりかえりとは （P.22/33）・過去の学びを未来に活かすこと。
・個人でやるよりも、チームでふりかえるのが効果的。
・PDCAのCAと相性がよい。
・PDCAの図で、サイクルを回していかなければいけない。
・週ぐらいの単位でリズムを決めて見える化する。
・詳細は道場の告知ページにある以下のガイドを参照。
「プロジェクトファシリテーション価値と原則編」
「プロジェクトファシリテーション実践編：朝会ガイド」
「プロジェクトファシリテーション実践編：ふりかえりガイド」
「プロジェクトファシリテーション実践編：見える化ガイド」
「プロジェクトファシリテーション実践編：計画作りガイド」
■ふりかえり会とは （P.23/33）・ふりかえり会のポイント
①時間をかけると嫌がるので短くやる方法を考える。KPT本にやり方が書いてある。
②気兼ねなく話をすることがポイント。
③そのために付箋紙を使う。
■ふりかえり会の効果 （P.26/33）１．対話の場作り
・話さないで疑心暗鬼になるより、強制的でも話す場があればよい。
２．ナレッジの共有
・気付きの場作り
３．コーチング効果
・目標管理イベントがないとやろうとしない。
・チームでふりかえりをやると、腹落ちして目標に向かって進もうとする。
４．チームビルディング
・個人的には、チームの行動規範がうまれること。
・和気藹々ではない。スポーツでいう、アイコンタクトで進められる状態が近い。
■演習：ペアドロー （P.28/33）・2人1組になって、ペアで交互に一筆ずつ、制限時間2分で天野さんの似顔絵を書く。
・KPTで振り返りをやった後、再度ペアで天野さんの似顔絵を書く。
・再度ふりかえり
・次は対象を変えて、道場主の似顔絵を描く
ということで、今回は絵がお上手な @s_kic さんとペアで似顔絵を描きました。
右から左に、順に 道場主似顔絵1st ← 天野さん似顔絵2nd ← 天野さん似顔絵1st。
うむ、なかなか良いカンジに描けました。毎回のふりかえりも上手く行ったんじゃないかなｗ
似顔絵を描くたびに振り返りをやり、Tryで次回チャレンジすることを決め、次回達成できたらKeepに移動させていきました。
Pの、ひげムズイｗ
あと、付箋に書くと、自然と次回意識するようになりますね。
■演習：気づきの共有 （P.29/33）最後に、テーブル毎にふりかえりをやりました。
★感想：私もなんちゃってアジャイルを社内でやっていた時に、イテレーションの最終日のふりかえりでKPTをやってました。
んでも、KPTはけっこー我流でやってたので、これでホント良いのかどうか、いまいちピンと来てない所もあったり。
ということで、今回の特別会はとても参考になりました。
ProblemからTry、だけじゃなく、KeepからTry、更にTryからKeepへ、という流れは新しい気づきですね。
あと、Problemに「～してない」と書いちゃうのはありがちなので、今度から意識して気をつける。
こーゆう特別会はホント良いですね～。アジャイルサムライの題材にぴったりだ。
来年もこんな企画を楽しみにしてます。
講師の天野さん、スタッフさん、参加者の皆さんありがとーございました。
2013/11/3(日) 「第8回 湘南国際マラソン」に参加してきました。
公式サイト
http://www.shonan-kokusai.jp/8th/index.html去年からチャレンジし始めたフルマラソンですが、去年は3回とも42.195kmを完走できました。
- 第32回 館山若潮マラソン
- 第50回 六無月東京喜多(北)マラソン
- 大阪マラソン2012
今年の1月にも館山若潮マラソンにエントリーしてましたが、両国発のマラソン臨時特別号が信号機故障で運行できず、マラソンのスタート時間に間に合わないというJR東日本の大アクシデントがありました。
なので実質、今年はこれが初マラソン！否応にも気合が入ります。
会場はJR東海道線の二宮駅から無料シャトルバスで15分ほどの場所にあります。
会場へは8時くらいに到着。
さすが1箇所に21000人も集まると、溢れんばかりの人混みです。
みろぉ、人がゴミのよう（ry
会場で弊社のIT系グループ会社ブースを発見！
湘南国際マラソンの協賛スポンサーなんですね～
---
湘南国際マラソンの42.195kmは、公認コースなのです。
湘南の海を眺めながら海岸沿いを走ります。
http://www.shonan-kokusai.jp/8th/_src/sc2076/3.pdf今回は大会運営の公式スポンサーであるNewBalance社のTwitterサービスに登録しました。
コース上に10km刻みで設置された計測ポイントで、シューズに付けたチップを読み取ってツイートを飛ばす仕様のようです。
通過タイムは画像でツイートに埋め込まれるようです。これはありがたいサービスですね～
このツイートに沿って、コースを振り返ってみる。
■スタート地点さすがにフルマラソンの部は18000人がエントリーしているだけあって、スタートの号砲が鳴ってから走り出すまでに時間がかかります。
ちなみに私は、号砲が鳴ってからスタート地点の計測ポイントを通過するまでに20分もかかったよ。。。
スタート地点では芸能人の徳光和夫さんや間寛平さんらが台上から応援のエールを送っていました。
マラソンと言えば間寛平さんは有名ですし、徳光さんも24時間テレビの走りで話題になったりしましたね～
■10km地点今日は曇り空で気温は18℃前後ということで、最高のコンディションでした。
コースもアップダウンが少なく、とても走りやすかったです。
10kmくらいはみなさん、まだまだ元気です。
■30km地点ここからが本当の地獄である。。。
体力には余裕があっても、足の疲労度がハンパない。徐々に足が付いてこなくなってくる。
大幅なペースダウン。
走ったり歩いたりを繰り返しながら、直近の給水給食ポイントを目指して気合で走るのみ！
■39.6km地点（第8関門）コースの要所に関門が設けられており、制限時間内に通過しないとリタイアとなってしまいます。
今回、39.6kmの最終関門で、あと10分くらいで引っ掛かりそうでした。。。
沿道のスタッフさんがコース途中で関門までの残り時間を知らせてくれるのですが、それを聞きつつ動かない足に鞭打ってみなさん走ります。
やっぱここまで来てリタイアは悲しいですからね。。。
逆に言うと、この最終関門さえクリアできれば、あとは3km弱に迫ったゴールが待ち受けるのみ！
・・・
とは言うものの、このラスト3kmが拷問である！
両手は痙攣で痺れるし、眩暈もするし。過去3回はこんなことは無かったなぁ。年齢による衰えなのか。。。
まさかの直前でリタイア！？というシナリオも脳裏によぎりました。
■42.195km ゴール！へろへろになりながらなんとかゴール！
そのまま地べたにバタリ。。。
そんな私にボランティアスタッフのおねーさんがドリンクを持ってきてくれました。
ドリンクを飲みつつ、しばらく地べたで休憩したあと、完走メダルを受け取りました。
■感想：今回もなんとか完走できました。
今年もまだ42.195kmを走りきれる自分がいる、ということが分かってホッとしてます。
あとやっぱ、自信にもなりますね。
4年前くらいにバスケでアキレス腱を断裂した時は、大好きなスポーツをもう2度とできないのでは、と酷く落ち込んだものですが、諦めずリハビリ頑張れば案外なんとかなるもんだなぁ～
大怪我をしようとも、体重が100kgくらいあろうとも、42kmくらいなんとかなる！
あと忘れてはいけないのは、大会を支えてくれるスタッフさんやボランティアさんの存在です。
マラソンは非常に多くのスタッフさんやボランティアさんが関わっているのですが、ホント感謝の一言に尽きる。
ちなみに今回のボランティア募集人員は3500人だったそうです。
沿道で笑顔で声援を送ってくれたり、給水所で「頑張ってください！」の一言と共にドリンクをくれたり、これがパワーになる。
沿道の市民のみなさんも、応援ありがとうございましたっ！私設エイドのコカコーラとチョコレートも美味しかったです。
2週間後は神戸マラソンがあります。
実家が大阪なので、帰省を兼ねてまた走ってきます。
が、正直今はへろへろで気が滅入っているｗ
あと２～３日は休養に当てて、もう一度頑張ろうと思います。
次は自己ベストを目指して！
-->
