97本読書会
昨日は、id:papanda0806 さん主催の97本読書会に行ってきた。
- 作者: 鈴木雄介,Richard Monson-Haefel,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2009/10/05
- メディア: 単行本（ソフトカバー）
- 購入: 17人 クリック: 362回
- この商品を含むブログ (81件) を見る
人数はざっと20人ほどでしょうか？ ぼくは、よくわからないけど、『ブレザーチーム』でした。ブレザー着てる人はいなかった気がするが。
形式は、108のトピックの中から、2つ(最初は、各チーム共通の話題、もう一つは自由課題)選択して、チームで話し合った内容を発表する、と言うもの。
と言うことで、うちのチームは下記のトピックについて話し合いました。
- No.83『設計した通りにはならない』
- No.108『説明責任を果たす』
(二つ目の話題は、Rubyのrand関数で出したもの。まさか最後のトピックが出てくるとは)
おそらく、詳細については、id:papanda0806さんがそのうちGoogle Groupに出して頂けると思うので、ぼくらのチームのメモ書きを最後に晒そうと思う。
ぼくの立場は、ソフトウェアアーキテクトと言う立場でもなければ、システム屋さんでもない。そのため、97本全てのトピックが参考になるわけではない。しかし、ソフトウェアを上流から下流まで作る立場から見て、印象に残った文言を以下に記してみる。
- 『判断した内容を残せ』
- 『ディベロッパを大切にしろ』
- 『本当の顧客は、今の顧客の顧客だ』
このうち特に1,3については、身につまされる思いをしている。
1については、普段ドキュメント等を残す場合でも、決断したことは書いても、決断した経緯まで残すことはしていない。しかし、引き継いだものが一番知りたいことは、決定事項ではなく、決定に至るまでの思考プロセスなのだ。
特に、矛盾した決断の場合、『なぜ、そうなったのか、自分だったら、XXXで実装するのに』と思うことがある。そして、同じプロセスをたどって失敗するのだ。このようなことを起こさないように、思考プロセスを残す、ということを今後やっていきたい。
3については、僕らは開発している時に、大抵顧客の言うことを聞かざるを得ない(僕の仕事の場合には、その顧客の役目は上司かな)。でも、その顧客の出した方針に違和感を感じることがある。その時に、まず何を考えるべきかと言うと『本当の顧客はどのようなシステムが欲しいのか？』と言うことを考えて議論すべきなのだ。今までのことを振り返ると、決断するときに真の顧客のことを考えなかったばかりに、利用率の上がらないソフトウェアを作っていたような気がする。やはり、裏に隠れている顧客の利益を考えてシステムを作るべきなのだ。
しかし、本当行ってよかったなぁ。なんたって、監修者のarclampさんが隣りだったんだぜ。こんなチャンスは滅多にないよ、ホント。
- No.83 設計した通りにはならない
- 問題点
- 最初のコンセプトはばらばらになる。
- 細かく設計すると。。。自信が大きくなるが、
- 最初の設計に固し。。。
- 設計は継続的で経験的なプロセス
- 設計は発見的なプロセス(設計の終わりとは？)
- 設計の中の小さな変更はあっと言う間に積み重なり。。。
- 疑問点
- コンセプトと設計の違い。
- 継続的で経験的で発見的な。
- 解決点とは
- 時間ができたので、挑戦したいこと
- 設計通りにはいかないのは理解しているが、詰めたい
- 最初のコンセプト(幹)を固めて、枝葉をつけていく。枝葉は差し替え可能な作りにする。
- 幹: ワークフレームワーク、考え方
- 想定外仕様が突然起きて、設計通りにはいかなくなる。
- No.108 説明責任を果たす
- 読後の感想
- 開発ドキュメントと保守のドキュメントを分ける。
- 活用されていない。
- 読まれるドキュメントにするには？
- 読まれる人に向けて書く。
- 設計のためのドキュメントとコミュニケーションのためのドキュメント
- 自己満足に陥らないように、人を向いて作る。
- 種類。ドキュメントで引き継ぐのは難しい。あくまで人間に引き継ぐ。
- メンテしている人が触らなくなる。
- 保守の視点でアーキテクチャが作られている。
- 判断、経緯を残す。→コメントに残す。 #52
- 全員が共有できるコンセプトワードを残す。
- 最上位の概念を残す。
