■なぜこの本を手に取った？
→見積もりがとにかく下手だから。物事をブレークダウン、もしくは積み上げることがとても苦手、つまり、始める前にゴールまでの道筋を計画することが苦手。（ゴールを決める力は、イシューからはじめよ、か）
→この本は、「プロジェクトの遂行にはどれくらいの人月がかかるのか？」を出すテクニックを紹介している。これだ、と。
→今の問題は「同じ失敗を繰り返さない様にするには？」
→前回のプロセス、各プロセスの問題点、それに対するトライを考えてみる。そうすれば、価値提供になる。個人戦でいい。そこから。
■読んだ後にどうなっていたい？何をする？
→コレぐらいかな？根拠はこうかな？を言えるようになりたい。
→はじめの一歩を見つける。因数分解だ！
■人は、結論に至った考え方、所作を含めた働き方＝「ここまでちゃんと考えてきっちり仕上げてくれた、一つひとつの行動」を信頼し、納得してくれる。
■因数分解には、違和感が大事。その因数分解、全員が保持しているのか？毎年買い替えるのか？一つしかないのか？
P115
・設計の時点で、前回バグを作り込んだ問題を振り返る。
→その観点が無いか？あったらどう対応するか？のチェックはしたい。ベンダーに出してもらう？こっちがある程度道筋を立てる。予測して、先回りする。こういう事起きませんか？と。
・テストしてエビデンスを取る。それを確認する。問題があれば差し戻し、無ければOK。このプロセスを明確にする。
・具体的にどれぐらい時間がかかるか？
3社ある。一社、二回ずつ？それで目的は達成される？
説明する。考えを聞く。もしくは読んでもらう。キチンと反映された事を、何を持って確認する？仕様書をレビューする？しんどくないか？説明してもらう、か。
自分がレビュアーなら出来る。前回どうやった？議題にする。
・エビデンスについては、仕様から逆算する。
総合テスト、業務チームがやったレベルのモノを出してもらう。
・テスト計画、テストのスコープ、マエさんがやって成功したやり方を、踏襲する。もれなく行うために。最初から「全量を出して、今週ここまで出来てないとまずい、で、どこまでエビデンス出せた？」を徹底しないと、ベンダーさんも辛いはず。
■P123 二つ以上の選択肢を作る。答えの無いゲームに勝つ。
■チームビルディング、チームリーダーとは。
少なくとも、マエさんは、俺の意思を、前に立ってリードする姿を見せて欲しいんだと思う。その期待に応えたい。答える事で俺は一つ上に上がれる。
■「とりあえず答えを作る事」にめちゃくちゃ価値がある→P163
今日、俺が出した答えを否定された。サーパントリーダーシップはダメだ、と。自分で手を動かさず、部下に手を動かさせる方法を考えろ。コムドットヤマトもそう言っている、と。わかるよそれは。でもそのやり方が分からねえ。部下も潰れるし、俺もミスる。
でも、確かに良い線いってる。今若手を任されたら、俺は一杯一杯になって終わる。
スタンスを取ることが大事だった。今回も決めさせてしまった。最悪だ。もっと思った事を言わなきゃ。
勇気を持って答えを言うから議論が進む。
■この人は、変える技術、考える技術のひとだった。
明日やること。。。
それが価値につながる。脱属人化？
失敗を次に活かす。それだけで良い。
前に出なかった。
フローを作る。当てなきゃ。来週木曜には。
集める。
備える。
午後やる事。何かあるっけ？。
