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よ！今後は決断する前に一度、常識を疑え！
講師の江端さん、参加者の皆さん、ありがとうございました。
あ、あと折り畳み傘、ようやく回収できたよ。。。
-->
