Readingagilesamuraiinhiroshima20150715
２回目より「すごい広島」と共催？させていただいております、場所はムービンオンになります。 今回はインセプションデッキの最終章なんだけど、カッキーが本を忘れて電子本（ただし英文）を読んでました、比較しながら読むと面白いですね。例えば、「具現化させる」は「Make it Real!」なんだけどよく「まじめにやろうぜ」ってかんじもあるなあとか、グーグル先生は「それは本当の作ります」と訳されました。エキサイト翻訳だと「それを本当にしなさい。」になりました。それ以外も原文はどうなの？って思うところが沢山あります。それはより理解を深めるためには必要なのかなあと感じました、カッキーさすがです。英文でないと真意は理解できないというのは、ISO文書ぐらいしか読んでないや(^^)
「だいたいわかった、とっととやろうぜ」この、「とっとと」になるための「だいたい」に個人差がある。 現実的な解決策を示す所から、技術、リスク、期間、諦めるもの、必要リソースなどを示していこう。 現在問題になっている、新国立競技場の建設費問題などについてはどうすべきなのだろうか？そもそもアジャイルで考えるべき問題でないと言うのは簡単だが、どこがアジャイルとそぐわなくて出来ないのかについては、言えた方が良い。
アーキテクチャ（方式設計）はここで決めるのか？ 全体的な具現ストーリーについてもここで決める必要がある（見積りはどうするか） チームを選ぶことはアーキテクチャを選ぶことである＝遅れた技術のチームなら遅れたアーキテクチャってこと？ より現実的な路線というのはわかるんだが、作れて初めてなんぼってか？
間違いなく、初めてやることである。技術的問題が一番リスクが高いと思っているから。（そもそも出来ないことを約束しなきゃいいのだがそれではいつまでたっても進歩しない）メーカーの売り文句通りに売り文句言っちゃう リスクを話し合うことはいいことだ、プランニングポーカーも同じような側面がある。多分全開の読書会では、入ってきたメンバが前のプロジェクトの仕事ばかりして、というようなことを言った記憶がある。（チーム全員が揃わない） 開発チームとお客さんでブレインストーミングして、プロジェクトで起きそうなリスクを話し合うことは良いことだが、チームにとってリスクとお客さんで考えるリスクは、不一致で相反するかもしれない。（これを説得しないといけない）
全体にかかる期間を見極める、ということは全体の見積りがざっくりできるということだ（前提条件）はいろいろあるけど。 ランディ・モットはHP社を2011年に退社しGM（ゼネラルモータース）に替っている、その後GMはHPの社員を3,000人雇用して内部開発に変えようとした。それまでGMのIT開発業務のうち10%くらいが本社業務ってことだったらしい。日本でも同じようなことが起きればいいのにw ランディのITプロジェクトの守備範囲は６ヶ月以内、 長いプロジェクトに参加すると会社は喜んでいた、派遣される方も喜んでいたし、自慢にもしていた。長い＝立派なプロジェクト。
スコープを諦めた時に、業務が回るか（もしくは健全か？）どうかの判断はどうするのか？ トレードオフって二律背反？ マツダの研究者でそれをつき破るのがイノベーションという話があった。 プロジェクトの早い段階で、納期、予算、品質、スコープのどれを諦めるプロジェクトなのかを意識しておく必要はあるかもしれない。
最終判断を下すのは誰か、をはっきりさせることができたとして、責任はその人にあるのか？部分部分によって分けたりされたらどうするのか？社長（役員）レベルでないと難しいのではないか？ 単にエスカレーション先を知っておけなのか？ インセプションデッキで作る最後のスライドは、いつ？いくら？でまとめる。
忘れないためのメモ、次回は付箋を用意して各自記入するようにする。