どれが読みたいですか？に対しての回答

　○スーツチーム
　エッセイ：８３
　設計したとおりにはならない。

　○メガネチーム
　エッセイ：０８
　すべてのものはかならずエラーを出す

　○ヒゲチーム
　エッセイ：５８
　３つから２つだけを選ぶ覚悟を決める
　エッセイ：９６
　エンドユーザの立場からは、インターフェースこそがシステム

　○ブレザーチーム
　エッセイ：２０
　継続的にインテグレーションを実行せよ

-------------------------------------------------------------------------------------------------------------------------
1回目 エッセイ８３「設計したとおりにはならない」を読んだ各チームの感想。


ヒゲチーム
　そのとおりだな。
　そのとおりだな。
　じゃあ、どうするのか。
　設計書は開発しているうちに変わっていく。
　設計書作る目的が変わってくる。
　インフラの方も最初の設計から、変わっていく。
　→クラウドで解決。
　だからこそアジャイルと言いたい？

ブレザーチーム
　みんなが気になるところはどこ？
　そうだよね。
　どうしたらいいの？
　イテレーションをやりながら作りながらフィードバックしながらやる
　設計したとおりにならないことを受け入れるべきでは。
　奇麗に作りすぎる→どこでとめればいいか。
　イテレーションでプロトタイプ作って、まわりに見せて、判断できるようにする
　仕様そのものを差し引いていく。
　→設計している途中で、違っているなら棄てる勇気も必要。
　コンセプトだけでも作る。
　枝葉の部分は変わっていくことを受け入れる。
　→何が枝葉なのか？を見分けるのが難しい。
　　→ビジネスプロセスは変わらない。
　　→（ワークフローエンジンなら）フロー、アクション、ステートで管理していく
　　→バッチはあきらめるんだ

スーツチーム
　ピーターの肩書きは何なの？
　ここでいう、設計とは何？
　アジャイルなら、コーディングも設計だよ。
　テヅカさんの話
　→ヒトは見た範囲でしか理解できないよね。
　　→それを越えるとうまく設計できない。
　ユーザが望んでいるものは本当に欲しいものなのか
　→ディズニーが美術館を作った話
　　→当初の要望とは似ても似つかないもの
　　　→でも、顧客は満足
　　　　→言われたとおりに作ってもダメですね
　　　　　→顧客は設計できたんだっけ。

メガネチーム
　こういうことあるよね。
　どうやったら変わっていかないのか？
　顧客とコミュニケーションをとっておく
　作っていくうちに変わっていく部分があるよね
　ユーザに対して提供する価値が大事。
　変わっていくことは当然
　それは全部開発側で受け取るのか？
　顧客にも協力してもらいたい
　誰かが泣くようなのはまずい
　コミュニケーションを取りながら作るのが良いのでは
　だから、アジャイルだね。
　では、お客様にコストをみてもらう必要。

アジャイルというやり方で仕事をしている？
アジャイルだったら、上手くいくんじゃないかと思ってる。
→アジャイルって何よ。アジャイルっぽくはやっているよ。
　→最初に要件は全部を決めずにやるのがポイントでは。

アジャイルで、上手く行っているのか。
→上手く乗れる。

--------------------------------------------------------------------------------------------------------------
2回目 　各チームそれぞれがエッセイを読んだ、その感想。

○メガネチーム
28：地上300メートルからの目

P56の6行が大事。
6行目→"適切なレベルで情報を与えてくれます"
→後半は読まなくていい。
　→具体的すぎて理解しにくい

UML/Unitテストの結果←300メートル

何が何メートルなのか洗い出してみる
→300メートル付近を目指す。

ソースコードが地上の目
要望が1万メートル
→現場のヒトは、1万メートルで見れているのか？

------
○ブレザーチーム
日本人の11番目のエッセイ：説明責任を果たす

第2段落の始め
→アーキテクトの、開発者に対する説明責任
　→ドキュメントを作って渡す
　　→読まれない。腐る。

→アーキテクトの、お客様・PMに対する説明責任
　→開発者向けとは別のドキュメントが必要。
　　→誰がどういうシチュエーションで読むのか
　　　意識することが必要。
　　　→自分の覚書では他のヒトの共感が得られナい。
　　　　→開発チームの中でも大事だと思う。
　　　　　例）開発環境の設定メモ

52：と類似。
コメントの中に判断を残さないといけない。消えてしまう。

----
○スーツチーム
日本人の11番目のエッセイ：

保守を引きついだとき、経緯が分からないと困る

大量のドキュメント
→計画当初は、工数があったが、だんだんドキュメントを
　作る工数がなくなっていく。

仕様を知っているヒトがドキュメントを作る。
→引き継いだとき、ドキュメントがない場合がある
　→ドキュメントを書く能力必要。

仕様変更を全部ちけっとで切る。
→15000件のちけっと
　→仕様変更の内容がどこにあるか分からない
　　→素晴らしいこと。なぜ混乱しているの？
　　　→作業依頼のチケットもある
　　　　「サーバ再起動して。」的なチケット。
　　　　→仕様変更に絞れば？
　　　　　→仕様変更の管理が統一されていない
　　　　　　→統一されていれば良いね。
→自然とドキュメントになるのが良いよね。
　→書き方を最初に決めておく
　　→リリースバージョンとの関連の管理が大事。

----
○ヒゲチーム
96：エンドユーザの立場からはインターフェースこそシステム

まず自分たちが使うとき、どうか。
→ユーザビリティ、インターフェースを見るヒトが
　いない。
　→そういうメンバーを入れることに敷居がある
　　→費用対効果が見せづらい
　　　→悩んでる