書評：やり抜く力
やり抜く力――人生のあらゆる成功を決める「究極の能力」を身につける
- 作者: アンジェラ・ダックワース,神崎朗子
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2016/09/09
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
Amazonのアフィリエイトのお試しがしたくて、この前読んだ本を貼ってみた。
いい本でした。感想も書いておきます。
- 「才能」じゃなくて「やり抜く力」ですよ、という本です。
- 米国陸軍士官学校の最初の基礎訓練、通称「ビースト」で5人に1人はやめてしまう。やめてしまう人は成績とは関係がなかった。「やり抜く力」が強い人が残った。
- ↑「やり抜く力」が強い人がやり抜いた、って当たり前みたいだけど、もうちょっとちゃんと書いてあります。
- ↑成績とは関係なかった、というように書いてあるけど、それは統計学的な誤解かも。。。成績優秀者だけを集めたから成績との相関が低くなるだけかも。
- やり抜きゃいいってもんでもないでしょ、と最初の方を読んでて思いました。途中でそういう点もフォローされています。いろいろ試して、合うものが見つかったらそれをやり抜こう、と。
- なんか、ところどころにある図解がいまいちわかりにくい。なぜなんでしょうね。。。
- 「意図的な練習」が重要
- 「子どもはおとなの言うことを聞くのは得意じゃないが、まねをするのは抜群にうまい」
才能✕努力＝スキル
— Akiya Mizukoshi (@Akiyah) 2016年10月10日
スキル✕努力＝達成
GRITやり抜く力 より pic.twitter.com/hCH5JFaD30
↑努力と才能とスキルの図解がわかりにくかったから自分なりに書き直した。
「タイトルのみ入れます。サブタイトルは入れません」？ pic.twitter.com/zGrMVhbH87
— Akiya Mizukoshi (@Akiyah) 2016年10月5日
↑表紙の画像につけた文字がおかしいのかな。
スクラムの概要の画像をいらすとやで作りなおしてみた
スクラムのバックログの日本語訳を聞いたら色々意見が集まった
スクラムのバックログは日本語にするならなんなのだろう。作業とか機能とかじゃないと思う。価値はカタい気がしている。ひとまず「やりたいこと」にしておく。
— Akiya Mizukoshi (@Akiyah) 2016年10月6日
こういうことを書いたらTwitterから自動的に転送する設定にしているFacebookで色々意見をもらったので軽くまとめておきます。
【日本語訳の案】
- やりたいこと
- 実現したいこと
- 残
- 仕事
- 予定残
- リスト
日本語訳になってないじゃん、とかありますが、バックログの言い換えの言葉として理解してください。考えてくれた人に感謝して名前を書いておきたかったのですが、なんか私の責任放棄みたいな気もしたので、名前は書かない方針でいきます。
もともと、バックログという言葉を使いたくなかったのは、バックログというサービスがあって仕事で使っているからなんですよね。
というわけで、意見をもらってから言うのもなんですが、私の基準は「まぎらわしくないか」がまず一つ目です。何か他のことを連想しちゃうかどうかですね。
もう一つは、facebookの議論中に出てきたのですが、「全部やるという印象を与えるかどうか」という点です。全部やるっていうのは誤解なんですよね。バックログを作ってプロッジェクトが始まって、最後に成功だったね！という場合でもバックログって残っているものなんですよね。結果やらないこと、というのも当たり前にあるのです。
というわけで並べてみました。
。。。
うーん、並べてみたけど、自信を持ってこうだと言いにくい。。。言葉の印象っていうものがあいまいでふわふわしているのに、ロジカルに並べようとするとなかなか難しいのですね。
まだ自分の中でもこれでいこうというのが決まってないです。ご意見ある方は教えてください。
ちなみに、ここで私が書いたバックログとは、プロダクトバックログのことです。プロダクトバックログとスプリントバックログがあって区別されているのです。
インターネットにこどもの写真を載せる時のパターンの整理と質問と要望
ちょっと気になったことがあったので、インターネットにこどもの写真を載せる時のパターンを整理してみようと思いました。
画像はいらすとやさんからいただいて、GIMPとCSS*1で加工して使っています。
【こどもの写真の公開のしかたの分類】
| パターン | 例 |
|---|---|
|
1) 家族に送る |
|
|
2) 友達とかクラスの人にのみ公開 |
|
|
3) だれでも見られる |
【（こどもの）写真に写っているものの分類】
| パターン | イメージ |
|---|---|
|
a) 風景 人を写さない 場所とか雰囲気を写すのみ |
 |
|
b) かおなし 顔を写さない （そういう風に写真を撮る） |
 |
|
c) スタンプ 顔に目線やスタンプをして隠す |
 |
|
d) 他人スタンプ 一部の子（自分の子）以外の顔に 目線やスタンプをして隠す |
 |
|
e) そのまま 顔が写っている |
 |
（えいやと分類しだだけなので、もっと細かくしたりとか、もっと大雑把にしたりとか、分類の種類を増やしたりとかしたほうが良い分類になるかもしれません。）
私の場合だと、 子供の写真をスマホでとって奥さんに facebook messenger で送るときは 1-e です。facebookに友達限定で載せるときはあんまり明確になってなくて、後ろからとったり手元だけをとったりして 2-b にしたり、場合によっては顔が写っていて 2-e になっていたり。twitterに載せるときは顔が写っていないようにして 3-a か 3-b です。スタンプとか目線とかは面倒だし、なんとなく好みじゃないのでやりません。加工をするとしたらトリミングで切り取るか、縮小とかぼかしてはっきり見えなくするようなものですね。
表にするとこうなります。
| a) 風景 | b) かおなし | c) スタンプ | d) 他人スタンプ | e) そのまま | |
|---|---|---|---|---|---|
| 1) 家族 | ○ | ○ | ○ | ||
| 2) 友達 | ○ | ○ | △ | ||
| 3) だれでも | ○ | ○ |
facebookの知り合いの写真を見ててもこういう方針はいろいろ違うようで、そのまま載せている人もいれば、他人のこどもだけスタンプで顔を隠している人もいれば、自分のこどもだけが写っている場合でも顔にスタンプをつけている人もいます。
で、なんでこういう整理をしたくなったかというと、保育園がとった写真を保育園のfacebookページやwebページに載せていたりするんですよ。その時に、上の基準では 3) だれでも で e) そのまま で公開していたりするんですよね。もちろん保育園から親へ許可を取っています。でもなんか親側の基準とずれているというか、親側のそれぞれが選択している基準のうちで保育園の選択がゆるい方によっているのが気になるんですよね。
私を含めて親側もリスクとかメリットを明確にして基準を選択しているのではなくて、なんとなくこれくらいかなという基準を自分で作っているだけなんですよね。たぶん。で、保育園から同意を求められて、まあ保育園に任せればいいかと思って同意している、と。一方で保育園側は同意が得られたからすべてオーケーということで、ゆるい基準を採用してしまっている、と。
そもそも、インターネットに写真を載せることのリスクってなんなんだろう。こういう議論を探すと一度でも写真を公開してしまったらアウトみたいな意見もありますが、だとしたらもう取り返せないわけで、だったらぎゃくに面倒なことはしたくないな、なんて思ったりもします。
【質問】
インターネットにこどもの写真を載せることのリスクってなに？
【要望】
保育園（or区、市、都、県）でこどもの写真をインターネットに載せることのリスクを明確にして、そのうえで保育園の採用する基準を示してほしい。その上で親に同意を得て、どうしても従えない人のこどもは写真に取らないとか、そういう風になってほしい。
このブログエントリーではリスクによったことを書いているけど、自分のこどもの写真を見せびらかしたいという気持ちはあるし、保育園での様子を写真で見せてもらえるのもうれしいので、できるだけリスクが少ない形で、公開して欲しいと思っています。
あと、保育園のことばかり書いているけど小学校も同様に思っています。小学校のほうが現状では少し厳し目にこどもの写真を扱っているようには感じています。
「オープンデータ・ベリーとちぎ」のデータをExploratoryで見てみる
このニュースを見て、せっかくのオープンデータが不発だなんてもったいない、と思って、ちょっとだけ触ってみました。
このなかの2016年8月26日の新規登録データから、グラフにしやすそうなものという基準で「トラフィックカウンター日光市_湯元」を選びました。
このあたりかな。
CSVファイル（約1MB）をダウンロードして、Exploratoryから文字コードにShift_JISを指定して読み込みました。「年月日」と「時分」が別の列になっていて扱いづらかったので、
time = ymd_hms(str_c(年月日, ' ', 時分))
として「年月日」と「時分」をつなげてから日時のオブジェクトに変換しています。
横軸を時間(日)で、縦軸を総交通量にして、車線（上り、下り）で色分けして折れ線グラフにしました。
一週間でグラフの形が繰り返していますね（日曜日じゃなくて月曜日が交通量が少ないように見えるのですが、もしかしてわたしがデータとExploratoryのタイムゾーンをうまく合わせられていないのかも）。2015年の9月にデータが無いのは、なにかの測定失敗なんですかね。
えっと、それ以上に不思議なのは、上りのほうが下りより多い！！本当？？そういうものなの？？
栃木県と群馬県の境目のような地点で、地図を見てもどちら向きが上りでどちら向きが下りかわからないけど、上りと下りの交通量が毎日偏っていたら、どちらかの県に車が多くなっちゃうという心配が、、、
もうちょっと調べてみると大型貨物・小型貨物と乗用車で上り下りの交通量の差が逆転しているようですが、まだよくわかりません。車種と車線で色分けしてみてみようと思ったのですが、それは次にします。
心理的安全は流行語候補！ XP祭り2016：国際会議 Agile 2016の風 – とある参加報告 - #xpjug
今年のXP祭り2016はムスメとの散歩がてら参加するという計画だったので講演はちょっとだけ見られたら良いやというつもりでしたが、昼過ぎからムスメを奥さんに預かってもらったので自由に動けるようになったので、エンタープライズアジャイルの後に国際会議 Agile 2016の風 – とある参加報告 -を聞いてきました。
で、講演者の伊藤さんと竹葉さんのパートで紹介されていたのがモダンアジャイルです。（昨日ググった時に英語だけだと思い込んでいたのだけど、なんと実は翻訳されていました。）
- 人々を尊重する
- 安全な状態を前提とする
- 素早い実験と学習
- 価値を継続的に届ける
この４つのうちの1つの、安全な状態を前提とする（Make safety a prerequisite）の更に中に含まれている、心理的安全(psychological safety)がとても興味深いです。
心理的安全、は言葉通りの意味で、「安心」と言ってもいいだろうし、「くだらない質問しても、自分が思っていることをブログに書いても、攻撃されない」という環境だと思っても良さそうです。そりゃあ、そういう状態のほうが良いに決まっていますよね。牛尾さんの講演で言っていた西洋文化の心地よさもこれに近いと思います。「思ったことを言わない」ではなくて「思ったことを言っても大丈夫」ということですね。
牛尾さんは西洋文化と表現していましたが、モダンアジャイルの基本理念（の一部）としてわざわざ挙げるということは、西洋の文化でも空気のように当たり前というわけではなくて、みんなで意識して心理的安全を守って文化にしているのでしょうね。
それにしてもこういう当たり前のことを明言してしまうのってすごいですね。ローコンテクスト文化の強みというのか。。。当たり前すぎて反論できないし、モダンアジャイルを避けて開発なんてできないですよね（心理的安全を守っただけでモダンアジャイルに入っちゃうと思うと。4つの基本理念が全部そうですが）。アジャイルは宗教だという人もいますが、こういう宗教ならソフトウェア開発者はみんなベースとしてこの宗教を信じちゃえばいいじゃんって思ったりします。
ところで、心理的安全に戻りますが、「自分が思っていることをブログに書いても炎上しない」という状態はどうやって作るのかなと少し考えました。「反論禁止」というわけではないんですよ。反論も自由にできるのが心理的安全でしょうし。たぶん、プロジェクトファシリテーションで言うところの問題 対 私たち(Problem vs. Us)がその答えかなと思いました。
反論したいようなブログエントリーを見つけた時に、反論するのは良いけど、書いた人を叩くような事はしないで、その横にある問題（Problem）に対して意見を言うというのが必要ですよね。第一印象として書いた人を叩きたくなっちゃうのは人間としてしょうがないとしても、ちょっと冷静になって問題に目を向けて、みんなで心理的安全の文化を守っていきたいと思います。
XP祭り2016：吉原さんのエンタープライズアジャイル開発の導入事例
XP祭り2016では吉原さんのエンタープライズへのアジャイル開発の導入事例も目当ての一つだったので、1回家に帰ってから午後にもう一度会場に来ました。
エンタープライズという環境の中でアジャイル開発をしたいという要望があり、そのためにアジャイルコーチとして参加した、というお話ですね。
チームのメンバーはアジャイル開発をしたことがなくて半信半疑であるので、アジャイルのプラクティスを厳選してコアプラクティスとして、その段階での成功を体験してもらって、アジャイルに慣れてもらうという方針で進めていたようです。
多くのプラクティスをいきなり導入しないというのは、半信半疑とか不慣れとかでなくても、チームビルディングとしてはとても重要なことだと思います。どんなに優れたメンバーをそろえても、最初は（チームのルールのようなものである）プラクティスは少なく始めて、ふりかえりを繰り返しながらチームを変えていくという作業が良いやり方だと思います。そういう意味では"ふりかえり"と、そのタイミングを制御する"イテレーション"が、最初にやりたいプラクティスだなと改めて思いました。
吉原さんの講演を聞いていて、タイムボックスをうまく使っているのが印象的でした。終わりが読めない全体設計的な作業に関しては、最初にタイムボックスを決めてしまってその範囲で終わらせる、と。2:8の法則を未来の自分たちに適用する良い作戦だと思いました。
【気になったこと】
・そもそも、エンタープライズってなんでしょうか？
なんとなくわかるけど、いまいち明確ではなくて、エンタープライズの制約だというふうに言われてもそうかなーと思う場面が何度かありました。アジャイルプロセス協議会のエンタープライズアジャイルWGでじっくり聞いてみます。
・プロダクトオーナーの不在問題。
エンタープライズだからプロダクトオーナーをできる人なんてほとんどいない、というのは、私も実感として納得しているところでもあり、一方でそれを解決しないとなにをやってもうまく行かないと思っていることでもあり。プロダクトオーナーって、そのシステムを欲しい人、というプロジェクトのモチベーションであるはずなので、それが明確でないということはそのプロジェクトは不要なんじゃないかなと思ってしまいます。
・アジャイルコーチの必要性
アジャイルコーチは最初からの契約でが3ヶ月間だったようです。でも吉原さんがアジャイルコーチとして参加することでチームはアジャイルチームとしての振る舞いをすることができているようだったので、ずっといるように交渉したほうが良かったのではないかなーと思いました。そもそものプロジェクトが、システムが必要というよりはアジャイルを組織に導入したいという事じゃないかと感じたので、だったらなおさらアジャイルコーチをもっと長期間使ったら良いのじゃないかなと。
おまけ。なぜか会場では最初からエンタープライズ＝アヤシイとなっていて面白かったです。終わったあと、小井土さんが「あやしくなかったね」って言ってたり。
