asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

デザインの学び方

はてなにも書いたけど、

 http://d.hatena.ne.jp/asato-d/20060617

どうやってデザインを学ぶのかに興味がある。

特に、ドメインを考慮したデザインの学び方に興味がある。

近いものとしては、Evans の「Domain Driven Design」や Fowler の「アナリシスパターン」が該当するのかもしれない。

どっちの本もまともに読んでいないけれど、少し僕の興味と異なりそうな気がする。

デザインパターン」にしろ「アジャイルソフトウェア開発の奥義」にしろ比較的にドメインに依存しない形でデザインの仕方を教えてくれる。

もちろん、ドメインに特化したデザインパターンもあると思うので、それはそれでよいと思う。


一般的にどう表現したらいいのかわからないけれど、やりたいのは比較的具体的。

今、ゲーム開発をしているので、そのゲーム開発している内容を(小さな)ドメインとして扱って、そこにおけるデザインの試行錯誤について書き留めたい。

あるいは、昔開発してたパターン認識システムがあるので、そのドメインにおけるデザインについても同じようにして書き留めたい。

問題は、どうやって書き留めるのか。パターンランゲージ形式が適切なのだろうか。

ただ、焦点は、それらのドメインにおけるデザイン上の困難な点を共有したいの ではなくデザインを学ぶ方法として、特定のドメインを扱ってみるとどうなるのか、という部分。


デザインを学ぶ方法を模索したいということかもしれない。

棋士は、定石から学ぶ。棋譜から学ぶ。実践から学ぶ。誰かに教えることで学ぶ。

では、ソフトウェアデザイナは、どうやって学ぶのか。
スポンサーサイト

よい主人 vs 悪い主人

大学院生生活も3年目。自分より下の学生の相手をすることもたまにある。研究の相談をする/されることもある。

いくつか注意しなければいけないことを学んだ。

学生には、助言を聞くことになりうる人が二人以上いる可能性があることだ。

もちろん、一人目は、研究室の(助)教授。もう一つは、たとえば、僕のような院生。

学生にとって、よろしくない状況になるのは、助言者の意見が食い違う可能性があることだと思う。

これが結構困る。僕も学生だったときに、一緒に研究していた教授と講師の方の間で身動きが取りにくいことになった。


院生となった僕は、じゃあ、学生相手にどうすればいいのか。一つは、たぶん、「僕の助言は無視してくれていいよ」と一言いっておくことじゃないかと思う。もう一つは、ここで書いたようなことを、そのままストーリーとして話すことじゃないかと思う。

ドラッカーがいい感じに諺としていってくれてる。農民の諺らしい。

 「二人のよい主人よりも、一人の悪い主人のほうがまし」

 マネジメント - 基本と原則 [エッセンシャル版] (単行本)
 P・F. ドラッカー (著), 上田 惇生 (翻訳)  
 http://www.amazon.co.jp/gp/product/4478410232/

Software Engineering コミュ

ソフトウェアエンジニアリングの実践者・研究者向けのコミュニティってないんだろうか。

wiki にしろ SNS みたいなのにしろ、あればよさそう。

まあ、失敗しそうなものだけど。


でも、ウィキペディアとかゲームの攻略 wiki とか、非集中的(?)に情報が蓄積されていく状況を見ていると、成功の可能性もあるのかもしれない。

テスト

テスト

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。