書籍版と同じストーリなのに、漫画になるとドキドキしてしまって、数式どころではなくなってしまう (^^;
ミルカさんもテトラちゃんも可愛いです。はい。
2009/01/25
コミック版「数学ガール」購入
今更ながらですが、コミック版の「数学ガール」を読みました。
書籍版と同じストーリなのに、漫画になるとドキドキしてしまって、数式どころではなくなってしまう (^^;
ミルカさんもテトラちゃんも可愛いです。はい。
書籍版と同じストーリなのに、漫画になるとドキドキしてしまって、数式どころではなくなってしまう (^^;
ミルカさんもテトラちゃんも可愛いです。はい。
2008/10/05
積ん読から2冊
積ん読から2冊
数年前に購入し、他の本に下敷きになっていた本を2冊ほど読みました。少し部屋の片付けをしたのがきっかけです (^^;両方とも既に古典とされつつある、大変有名な本です。
1冊目は『イノベーションのジレンマ』。
最近、『イノベーションへの解 実践編』が発売になりましたが、そのシリーズ第一弾といった位置づけでしょうか。
最終章から論旨を引用させていただくと、こんな感じ。
これ対する本書での提案は「邪魔せず、支配する環境を作り出す」ということですが、これは『XP エクストリーム・プログラミング入門 第2版』の
で問題は、これら独立部隊が独立性を保ちながらも、全体として、一本、確とした筋を通すにはどうするのか、という点なのですよね...。
もう一冊は『会議が絶対うまくいく法』。
ファシリテーションに関する本で、ポイントがサクサク読めます。会議を主催する側になった人には、勿論、多くの論点がぼけた会議に業を煮やしている人にも、自分が同じことをしない為の注意点を知る為に、お薦めです。
さて、この本では「問題解決のコツ」として、
自分の周りで起こっている、上手く行っているプロジェクトや、残念ながら、少し空回りしているプロジェクトなどを見ると、ファシリテータの存在やビジョンの提示、スーパーエンジニアの存在性などに各種特徴が見られ、あぁ、やっぱりプロジェクトって面白いな、と思うのでした。
数年前に購入し、他の本に下敷きになっていた本を2冊ほど読みました。少し部屋の片付けをしたのがきっかけです (^^;両方とも既に古典とされつつある、大変有名な本です。
1冊目は『イノベーションのジレンマ』。
最近、『イノベーションへの解 実践編』が発売になりましたが、そのシリーズ第一弾といった位置づけでしょうか。
最終章から論旨を引用させていただくと、こんな感じ。
見事な成功をおさめてきた企業の有能な経営陣が、ひらすら利益と成長を求めるうちに、最高の経営手法を使って、企業を失敗に導く場合があることを学んだ(p.293)。
マネージャはまず、これらの衝突がどのようなものかを理解する必要がある。つぎに、各組織の市場での地位、経済構造、開発能力、価値が、顧客の力と調和し、持続的イノベーションと本格的イノベーションという全く異なる仕事を邪魔せず、支配する環境を作り出す必要がある(p.297)。やっぱり、こういう話を読むと、自身に関係の深いソフトウェア開発プロセスとの関連で考えてしまうわけで、例えば、成功する為のパターンを模索して手に入れたソフトウェア開発のチームが、その成功故に、維持するものが大きくなり、だんだんと機動力と言うかAgilityが失われてしまう、という悲しいパターンに近いのかなぁ、と。
これ対する本書での提案は「邪魔せず、支配する環境を作り出す」ということですが、これは『XP エクストリーム・プログラミング入門 第2版』の
小規模なチームでプロジェクトを始め、自立したチーム間で作業を分割する(p.116)と、同じ思想に根差しているのだろうな、と感じました。
で問題は、これら独立部隊が独立性を保ちながらも、全体として、一本、確とした筋を通すにはどうするのか、という点なのですよね...。
もう一冊は『会議が絶対うまくいく法』。
ファシリテーションに関する本で、ポイントがサクサク読めます。会議を主催する側になった人には、勿論、多くの論点がぼけた会議に業を煮やしている人にも、自分が同じことをしない為の注意点を知る為に、お薦めです。
さて、この本では「問題解決のコツ」として、
集団で評価をするときには、判断を下す前に、共通の判断基準をつくり、合意しておかなくてはならない(p.216)という記述が出てきます。そして恐らくこれこそが、「全体で筋を一本通す」ことの肝なのだろうな、と。
自分の周りで起こっている、上手く行っているプロジェクトや、残念ながら、少し空回りしているプロジェクトなどを見ると、ファシリテータの存在やビジョンの提示、スーパーエンジニアの存在性などに各種特徴が見られ、あぁ、やっぱりプロジェクトって面白いな、と思うのでした。
2008/08/24
Enterprise Architect入門
勤務先でEnterprise Architectを使う必要が出てきたので、Amazon で検索して「はじめての ENTERPRISE ARCHITECT」と「UMLモデリングツール Enterprise Architect入門 〜基本操作完全マスター〜」を購入。
届いて中身を見て、後者は、前者のアップデート版だということに気がつきました。ぎゃー。って、上記Webサイトでは、しっかりと情報を公開して下さっているのですけれど (^^;。
内容は、うーん、もう少し踏み込んでもらえると嬉しかったかな、と言う感じ。本当に基礎的な点に注力して書かれているので、これを足がかりに自分で試して学習して行く、という位置づけなのかもしれませんね。
届いて中身を見て、後者は、前者のアップデート版だということに気がつきました。ぎゃー。って、上記Webサイトでは、しっかりと情報を公開して下さっているのですけれど (^^;。
内容は、うーん、もう少し踏み込んでもらえると嬉しかったかな、と言う感じ。本当に基礎的な点に注力して書かれているので、これを足がかりに自分で試して学習して行く、という位置づけなのかもしれませんね。
2008/06/30
『C++の設計と進化』読み終わりました
『C++の設計と進化』をようやく、読み終わりました。
ほぼ発売と同時に購入した気がしますが、少し読んでは他の本に浮気、読み直しては別の本へ浮気、とちっとも進みませんでした。
内容は、C++の歴史と考え方が分かって面白い本です。この機能の実装にあたり、なぜこう考えたのか、というのが分かるのは、大変楽しい驚きです。ARMをパラパラ眺めて(読んでいたとはおこがましい)、いちいち感心していた頃を思い出しました。
一方で、C++という言語が、かくも難解になってしまったのは、設計者の真面目さ故なのかも、と感じる本でもあります。なんというか、メインフレーム時代のプログラマが携えていた(であろう)気品を感じるというか...。この真面目さが、なかなか読み進めなかった原因なのかも知れません。
まつもとさんが書かれているように「低レベルを切り捨てることができなかった」故にC++が人気の無い言語になってしまった、というのは確かに一理あるなぁ、と感じて、その「切り捨てることができなかった」理由が、設計者の真面目さにあるような気がして、そして、それがなかなか上手くかみ合っていない、また、受け入れられていない気がしていて、少し悲しくなるのでした。
とは言え、この真面目さは、書籍としての完成度を高めるためには、大変有効に機能しています。(私がそうだったから、というわけではないですが)ゆっくり、著者の考えに浸りながら読まれると面白いかな、と思いました。
ほぼ発売と同時に購入した気がしますが、少し読んでは他の本に浮気、読み直しては別の本へ浮気、とちっとも進みませんでした。
内容は、C++の歴史と考え方が分かって面白い本です。この機能の実装にあたり、なぜこう考えたのか、というのが分かるのは、大変楽しい驚きです。ARMをパラパラ眺めて(読んでいたとはおこがましい)、いちいち感心していた頃を思い出しました。
一方で、C++という言語が、かくも難解になってしまったのは、設計者の真面目さ故なのかも、と感じる本でもあります。なんというか、メインフレーム時代のプログラマが携えていた(であろう)気品を感じるというか...。この真面目さが、なかなか読み進めなかった原因なのかも知れません。
まつもとさんが書かれているように「低レベルを切り捨てることができなかった」故にC++が人気の無い言語になってしまった、というのは確かに一理あるなぁ、と感じて、その「切り捨てることができなかった」理由が、設計者の真面目さにあるような気がして、そして、それがなかなか上手くかみ合っていない、また、受け入れられていない気がしていて、少し悲しくなるのでした。
とは言え、この真面目さは、書籍としての完成度を高めるためには、大変有効に機能しています。(私がそうだったから、というわけではないですが)ゆっくり、著者の考えに浸りながら読まれると面白いかな、と思いました。
2008/06/15
ファシリテーション技術の本
仕事関係で、『ワークショップ・デザイン』と『ファシリテータの道具箱』を読みました。
どちらもノウハウ集であり、記述も平易なので、併せて数時間もあれば読めてしまうほどの軽めの書籍です。
今までプロジェクトマネジメント等で使ってきたいろいろなアクティビティが、その効果と目的とに応じて綺麗に整理されており、頭の中がスッキリした感じです。過去、悩んで来た場面で、このアクティビティを適用すれば良かったのかな、と感じたものもありました。
別にテクニック本を読んだからと言って、ファシリテーションが上手くなるわけでは決してありません(やっぱり、臨機応変さなど、最後は経験数だと思います)。逆に、経験を積んでない方が、色々な本を読んでしまうと、頭でっかちになって、心が落ち着かなくなってしまうのでは、とも思います。
もしこれからファシリテータを努めてみたい、という方は、自分が臨む会合に関して軽めの知識を入れた後、何度か身内で体験を重ねてみるのが良いのではないでしょうか?その上で、このような各種手法に関する書籍を読むと、自身の血となり肉となると言う点で、効果的なのではないかな、と思います。
どちらもノウハウ集であり、記述も平易なので、併せて数時間もあれば読めてしまうほどの軽めの書籍です。
今までプロジェクトマネジメント等で使ってきたいろいろなアクティビティが、その効果と目的とに応じて綺麗に整理されており、頭の中がスッキリした感じです。過去、悩んで来た場面で、このアクティビティを適用すれば良かったのかな、と感じたものもありました。
別にテクニック本を読んだからと言って、ファシリテーションが上手くなるわけでは決してありません(やっぱり、臨機応変さなど、最後は経験数だと思います)。逆に、経験を積んでない方が、色々な本を読んでしまうと、頭でっかちになって、心が落ち着かなくなってしまうのでは、とも思います。
もしこれからファシリテータを努めてみたい、という方は、自分が臨む会合に関して軽めの知識を入れた後、何度か身内で体験を重ねてみるのが良いのではないでしょうか?その上で、このような各種手法に関する書籍を読むと、自身の血となり肉となると言う点で、効果的なのではないかな、と思います。
2008/05/25
『アップルとグーグル - 日本に迫るネット革命の覇者 -』
少し時間があったので、軽く立ち寄った本屋で『アップルとグーグル - 日本に迫るネット革命の覇者 -』を購入。非常に軽く書かれているため、1時間位で読み終えることが出来ました。
内容は、ちょっと辛口に言えば、「Apple と Google の宣伝本」という感じでしょうか? Web上に書かれている Apple と Google の興味深い革新点が、簡単にまとまった本、というイメージで、詳細に企業分析を行った、という感じの本ではありません。
「アップルとかグーグルとか言う会社の名前を良く聞くけど、どういう会社なんだろう?」という位の興味をおもちの方がターゲット読者なのかな、と思いました。
内容は、ちょっと辛口に言えば、「Apple と Google の宣伝本」という感じでしょうか? Web上に書かれている Apple と Google の興味深い革新点が、簡単にまとまった本、というイメージで、詳細に企業分析を行った、という感じの本ではありません。
「アップルとかグーグルとか言う会社の名前を良く聞くけど、どういう会社なんだろう?」という位の興味をおもちの方がターゲット読者なのかな、と思いました。
2008/05/04
『Macintosh名機図鑑』と『CORE MEMORY』
ゴールデンウィークということで(?)、以前購入して、積んだままになっていた、『Macintosh名機図鑑』と『CORE MEMORY』をのんびりと。
どちらも懐古趣味的な本ですが、デザインの美しいコンピュータを見るのは、大変わくわくします。特に『CORE MEMORY』は写真の取り方が大変美しく、鑑賞品として十二分に楽しめます。写真集としての完成度が高く、多分、本物見るよりも感動度合いが強いのでは、と感じました。
初期のコンピュータの持つ、無機質の中にある静かなデザインは、安心して見ることが出来ました。またMacintoshのデザイン変遷の中では、私の好みは、初期のフロッグデザインモデルと最近のアルミ系モデルなんだなぁ、とも感じました。
最近Macintoshに再び惹かれているのも、ReadyNAS NV+ のデザインに愛着を持っているのも、このシンプルさに心奪われているのかも、と考えながら、ぼーっと過ごした午後でした。
どちらも懐古趣味的な本ですが、デザインの美しいコンピュータを見るのは、大変わくわくします。特に『CORE MEMORY』は写真の取り方が大変美しく、鑑賞品として十二分に楽しめます。写真集としての完成度が高く、多分、本物見るよりも感動度合いが強いのでは、と感じました。
初期のコンピュータの持つ、無機質の中にある静かなデザインは、安心して見ることが出来ました。またMacintoshのデザイン変遷の中では、私の好みは、初期のフロッグデザインモデルと最近のアルミ系モデルなんだなぁ、とも感じました。
最近Macintoshに再び惹かれているのも、ReadyNAS NV+ のデザインに愛着を持っているのも、このシンプルさに心奪われているのかも、と考えながら、ぼーっと過ごした午後でした。
2008/04/30
『Googleを支える技術』読了
『Googleを支える技術』(西田圭介著、技術評論社)を読み終えました。平易に書かれており、また校正も丁寧で、大変読みやすい本でした。
内容は、色々な書評で書かれている通り、また序文でも述べられている通り、主に、Goole自身が過去に公開した様々な情報を、平易にまとめたもの、と言えます。
しかし、Googleの論文や、講演資料など、色々と目にする機会はあるものの、私は、ついつい、視点が論じられている特定技術や技法そのものへと向かってしまい、ここまで「Googleという1組織全体」という方向性から再整理して再定義した乏しかった為、大変有益でした。
実際、偏在している情報を綺麗に整理し、一本の筋道でまとめあげ、平易に理解できる文章として再構成する、というのは包括的な視点と全体を把握して上でのストーリ展開が重要ですから、そうした点で、見た目の柔らかさとは裏腹に、価値の高い本だと感じます。
さて、この本を読んで感じたことは「Googleは正しいことを、正しく行っているなぁ」ということ。
例えば、コードを書いていると、「うーん、ここはちょっと問題があるけど、他の仕事もあるし、ひとまず場当たり的な実装で進めてみよう」と安易に判断してしまうことがあります。そして多くの場合、このコードを再利用する段階で、この判断結果に悩まされ、苦しめられることがシバシバ。
XP的な視点では「十分に判断した上でKISSに従い、必要に応じて適切にリファクタリング、それを支えるために、常に包括的テストを構築する」ですが、大抵この判断をするときには、気が急いていて「十分に判断」していないことが多かったり、テストが不十分だったり。
Googleの分散テクノロジにしても、開発スタイルにしても「達成することを明確に判断し、その為に実装。状況が変化したら、素早くこまめに修正する。その為には、テストなど、やらなければならないことは決して手を抜かない」という、本来の「常識」が会社全体に広がっているように(正確には、広がるよう、常時努力しているように、かな?)感じました。
最近Googleに対しては「少数精鋭的のサイエンティストで攻めていた従来とは異なり、最近は大量に技術者を雇っているように見えるけど、大丈夫?」的な話を聞きます(私もそう感じていました)。しかし、本書を読んで、実は、データセンターの構築から、ソフトウェアの基礎プラットフォーム、また開発プロセスに至るまで、何れにおいても開発規模を拡大しても十分に「Googleらしさ」を維持できる体制が擁立できた、との自信を深めた上での業務拡大なのでは、と感じました。
とすると、これからの10年が、真のGoogleの成長神話になるのかも知れません...。
内容は、色々な書評で書かれている通り、また序文でも述べられている通り、主に、Goole自身が過去に公開した様々な情報を、平易にまとめたもの、と言えます。
しかし、Googleの論文や、講演資料など、色々と目にする機会はあるものの、私は、ついつい、視点が論じられている特定技術や技法そのものへと向かってしまい、ここまで「Googleという1組織全体」という方向性から再整理して再定義した乏しかった為、大変有益でした。
実際、偏在している情報を綺麗に整理し、一本の筋道でまとめあげ、平易に理解できる文章として再構成する、というのは包括的な視点と全体を把握して上でのストーリ展開が重要ですから、そうした点で、見た目の柔らかさとは裏腹に、価値の高い本だと感じます。
さて、この本を読んで感じたことは「Googleは正しいことを、正しく行っているなぁ」ということ。
例えば、コードを書いていると、「うーん、ここはちょっと問題があるけど、他の仕事もあるし、ひとまず場当たり的な実装で進めてみよう」と安易に判断してしまうことがあります。そして多くの場合、このコードを再利用する段階で、この判断結果に悩まされ、苦しめられることがシバシバ。
XP的な視点では「十分に判断した上でKISSに従い、必要に応じて適切にリファクタリング、それを支えるために、常に包括的テストを構築する」ですが、大抵この判断をするときには、気が急いていて「十分に判断」していないことが多かったり、テストが不十分だったり。
Googleの分散テクノロジにしても、開発スタイルにしても「達成することを明確に判断し、その為に実装。状況が変化したら、素早くこまめに修正する。その為には、テストなど、やらなければならないことは決して手を抜かない」という、本来の「常識」が会社全体に広がっているように(正確には、広がるよう、常時努力しているように、かな?)感じました。
最近Googleに対しては「少数精鋭的のサイエンティストで攻めていた従来とは異なり、最近は大量に技術者を雇っているように見えるけど、大丈夫?」的な話を聞きます(私もそう感じていました)。しかし、本書を読んで、実は、データセンターの構築から、ソフトウェアの基礎プラットフォーム、また開発プロセスに至るまで、何れにおいても開発規模を拡大しても十分に「Googleらしさ」を維持できる体制が擁立できた、との自信を深めた上での業務拡大なのでは、と感じました。
とすると、これからの10年が、真のGoogleの成長神話になるのかも知れません...。
2008/04/23
『ふつうのHaskellプログラミング』を読み終えました
期せずして、Lispの話を聞いたその日に『ふつうのHaskellプログラミング』読了。
学んでいると、いつもMonad周辺で煙に巻かれたような気分になってしまうHaskellなのですが、この本のお陰で、概要が随分と整理できました。この本を読んでから、「モナドのすべて」を読むと、すーっと話が入ってきます。
青木さん著、ということで、大変丁寧に、分かりやすく、取っ付きやすく書かれています。第3部の「実戦Haskellプログラミング」は、ただの文法解説書ではなく、実際の使い方が学べる書籍という点で、良い展開だなと思いました。この章に関しては、多少駆け足気味かな、という感じもありますが、コードをじっくり読んで自分で考えろ、という事なのかと思います。
MLもOCamlも適当に避けてきたので(おぃ)、静的型付けをもつ関数型言語、というのは新鮮で、いろいろいじってみたい、という感じが強くあります。しかし Haskell っぽいコードを書けるようになるまでは、もう少し、頭の転換が必要な感じです。
うーむ、修行あるのみだのぉ。
学んでいると、いつもMonad周辺で煙に巻かれたような気分になってしまうHaskellなのですが、この本のお陰で、概要が随分と整理できました。この本を読んでから、「モナドのすべて」を読むと、すーっと話が入ってきます。
青木さん著、ということで、大変丁寧に、分かりやすく、取っ付きやすく書かれています。第3部の「実戦Haskellプログラミング」は、ただの文法解説書ではなく、実際の使い方が学べる書籍という点で、良い展開だなと思いました。この章に関しては、多少駆け足気味かな、という感じもありますが、コードをじっくり読んで自分で考えろ、という事なのかと思います。
MLもOCamlも適当に避けてきたので(おぃ)、静的型付けをもつ関数型言語、というのは新鮮で、いろいろいじってみたい、という感じが強くあります。しかし Haskell っぽいコードを書けるようになるまでは、もう少し、頭の転換が必要な感じです。
うーむ、修行あるのみだのぉ。
2008/04/04
ソフトウェア開発者雇用ガイド(Joel Spolsky)
Joel Spolskyの「ソフトウェア開発者採用ガイド」読了。
Joel on Software 等でも語られている「チームには、本当に納得できた有益な人物しか雇用してはならない」という理論で、語られた書籍。また、その為に雇用者が開発者をどのように扱わなければならないか、という視点でも述べられています。
この「納得行かなければ雇用してはならぬ」というのは、雇用する側も雇用される側も、大変厳しい姿勢だと思います。一方で、このようなプロセスを経て作られたチームは、パフォーマンスの面でも信頼性の面でも、大きな優位性が得られるかと思います。
で、何時もの話になりますが、これはGoogleが使ってきた採用プロセスなんですよね...。これが、GoogleやFrog Creekなどの優秀なIT企業が当たり前と認識している採用プロセスであるならば、日本の企業は、相当厳しいのではないでしょうか? それとも日本のベンチャーなどは、積極的にこうした方式を採用しているのかな?
現在の勤務先でも、派遣さんにお手伝いいただく際には、「派遣さんとは面談したら、特に理由が無い限り断れないからね」「面談ではコードを書かせるなんて、言語道断だよ」などの指示がなされます。勿論派遣さんの場合、正社員の雇用とは、取り巻く法律などは全く違いますが、履歴書だけで判断するだけでなく、もう少し自由に語らせて貰えると嬉しいな、と思います。
Joel on Software 等でも語られている「チームには、本当に納得できた有益な人物しか雇用してはならない」という理論で、語られた書籍。また、その為に雇用者が開発者をどのように扱わなければならないか、という視点でも述べられています。
この「納得行かなければ雇用してはならぬ」というのは、雇用する側も雇用される側も、大変厳しい姿勢だと思います。一方で、このようなプロセスを経て作られたチームは、パフォーマンスの面でも信頼性の面でも、大きな優位性が得られるかと思います。
で、何時もの話になりますが、これはGoogleが使ってきた採用プロセスなんですよね...。これが、GoogleやFrog Creekなどの優秀なIT企業が当たり前と認識している採用プロセスであるならば、日本の企業は、相当厳しいのではないでしょうか? それとも日本のベンチャーなどは、積極的にこうした方式を採用しているのかな?
現在の勤務先でも、派遣さんにお手伝いいただく際には、「派遣さんとは面談したら、特に理由が無い限り断れないからね」「面談ではコードを書かせるなんて、言語道断だよ」などの指示がなされます。勿論派遣さんの場合、正社員の雇用とは、取り巻く法律などは全く違いますが、履歴書だけで判断するだけでなく、もう少し自由に語らせて貰えると嬉しいな、と思います。
2008/03/19
無限回廊
ちょっと不思議な感覚のゲーム無限回廊のPSP版を買いました!
最初にデモムービーが公開されたときから興味津々で、これは絶対買おう、と決めていました。
小さな頃からエッシャーの騙し絵が好きで、一時期は、METAMORPHOSISのポスターとか部屋に貼っているような変なガキでしたので、その世界に触れられるだけでも、これは、凄い、と。
体験版の「練習曲」は、PS3版とPSP版の両方を試してみましたが、流石にPS3の方が滑らかで、操作しやすいなぁ、と。でも、これは、大画面でドーン、とやる、というタイプのゲームじゃないなぁ、と思いましたのでPSP版を購入。
ゲーム自体は、パズルゲームと言うよりも半分アクションだったり、少し運的な要素も必要だったり、時間制限があったりと、なかなか騙し絵の世界に浸る、という感じではありませんが、それでも新機軸なアイディアは「買い」です。
『ゲーデル、エッシャー、バッハ - あるいは不思議の環』にピンと来る方は、是非(!?)。
最初にデモムービーが公開されたときから興味津々で、これは絶対買おう、と決めていました。
小さな頃からエッシャーの騙し絵が好きで、一時期は、METAMORPHOSISのポスターとか部屋に貼っているような変なガキでしたので、その世界に触れられるだけでも、これは、凄い、と。
体験版の「練習曲」は、PS3版とPSP版の両方を試してみましたが、流石にPS3の方が滑らかで、操作しやすいなぁ、と。でも、これは、大画面でドーン、とやる、というタイプのゲームじゃないなぁ、と思いましたのでPSP版を購入。
ゲーム自体は、パズルゲームと言うよりも半分アクションだったり、少し運的な要素も必要だったり、時間制限があったりと、なかなか騙し絵の世界に浸る、という感じではありませんが、それでも新機軸なアイディアは「買い」です。
『ゲーデル、エッシャー、バッハ - あるいは不思議の環』にピンと来る方は、是非(!?)。
2008/03/18
デーモン君のソース探検
昔、BSD Magazineで斜め読みしていたのですが、ふとした拍子で購入。サクサク読めてあっという間に、読了。でも、内容は結構深い記述があったりします。
Amazonの書評に「C言語入門書の次に読む本」という意見がありますが、まさに、初級を脱出して、さてこれから、という若手プログラマの取っかかりに良いかな、と思いました。この本片手に、2004年前半位のBSDのコードを読むのが、楽しいかも知れません。
Amazonの書評に「C言語入門書の次に読む本」という意見がありますが、まさに、初級を脱出して、さてこれから、という若手プログラマの取っかかりに良いかな、と思いました。この本片手に、2004年前半位のBSDのコードを読むのが、楽しいかも知れません。
2008/03/17
Best Software Writing
Joel Spolsky編の『Best Software Writing』を、読了しました(ちなみに、原書は、
Googleブック検索で参照できます)。
『Joel on Software』でも語られていましたが、私はJoelの採用に関する話が、大変好きだったりします。本書でも、Joelと同様の視点に基づいた採用に関する話が編まれていて、興味深く読みました。
チーム開発とソフトウェア開発プロセスでも書きましたが、「チームで作業をする」というのは、なんであれ、一人で作業をするよりは制約が増えることになるわけです。そして、当然それに向く人、向かない人、というのがいるわけで、そこの所を上手く汲み取って、現実にそくして考えないと、どうしてもチームが崩れます。また、チームの色、というのもありますから、例えチーム作業に向く人でも、そのチームに合う、合わない、という問題も出てきます。
学生時代、ツルんで莫迦話に時間を過ごす気の置けない友人、って、ある程度固定化していました。この話をするのはこいつらだな、という感じ。そのような中で連帯感が生まれたり、共通のビジョンが育まれていったり。で、チームの本質って、それと変わらないと思うんですよね。
よく「仕事だから、公私混同するな」とか、「子供じゃないんだから、オトナの付き合いで対処しろ」とか言う人が居ますが、意外にそういう人ほどチームワークを分かっていなかったりするのは、うーむ、とか思ったりしてしまいます。わはははは。
馴れ合いの仲間内で固まるのが良い、と言っているわけではありません。ナーナー(ツーカーじゃないよ!)で進むチームは眩暈がしますし、そもそも進歩なんて望めません。
適宜新しい人材を取り入れて、水の淀みは無くすべきだと思いますし、個性は衝突しあってこそ、だと思います。そしてこれを可能にするのが、「オトナのウワベのツキアイ」ではない、チームワークなんだと思います。頭脳労働なプログラムを優秀な人材の集団で作り上げるためには、どうしても最後は人と人とのぶつかりあいになりますから、心を割って話せなければ、どうやったって、思想もアーキテクチャも実装もゆがんでしまいます。衝突しっぱなしでは、チームになりません。それ故、相手の話を聞くことが出来て、意見を議論できて、最後は皆が笑って納得できるチームを作らねば!
と、こんな視点でチームを見ている自分にとって、採用を大変重視しているJoelの考え方は、大変参考になるのでした。
相変わらず青木さんの訳は(当然)読みやすく、お薦めの一冊です。
Googleブック検索で参照できます)。
『Joel on Software』でも語られていましたが、私はJoelの採用に関する話が、大変好きだったりします。本書でも、Joelと同様の視点に基づいた採用に関する話が編まれていて、興味深く読みました。
チーム開発とソフトウェア開発プロセスでも書きましたが、「チームで作業をする」というのは、なんであれ、一人で作業をするよりは制約が増えることになるわけです。そして、当然それに向く人、向かない人、というのがいるわけで、そこの所を上手く汲み取って、現実にそくして考えないと、どうしてもチームが崩れます。また、チームの色、というのもありますから、例えチーム作業に向く人でも、そのチームに合う、合わない、という問題も出てきます。
学生時代、ツルんで莫迦話に時間を過ごす気の置けない友人、って、ある程度固定化していました。この話をするのはこいつらだな、という感じ。そのような中で連帯感が生まれたり、共通のビジョンが育まれていったり。で、チームの本質って、それと変わらないと思うんですよね。
よく「仕事だから、公私混同するな」とか、「子供じゃないんだから、オトナの付き合いで対処しろ」とか言う人が居ますが、意外にそういう人ほどチームワークを分かっていなかったりするのは、うーむ、とか思ったりしてしまいます。わはははは。
馴れ合いの仲間内で固まるのが良い、と言っているわけではありません。ナーナー(ツーカーじゃないよ!)で進むチームは眩暈がしますし、そもそも進歩なんて望めません。
適宜新しい人材を取り入れて、水の淀みは無くすべきだと思いますし、個性は衝突しあってこそ、だと思います。そしてこれを可能にするのが、「オトナのウワベのツキアイ」ではない、チームワークなんだと思います。頭脳労働なプログラムを優秀な人材の集団で作り上げるためには、どうしても最後は人と人とのぶつかりあいになりますから、心を割って話せなければ、どうやったって、思想もアーキテクチャも実装もゆがんでしまいます。衝突しっぱなしでは、チームになりません。それ故、相手の話を聞くことが出来て、意見を議論できて、最後は皆が笑って納得できるチームを作らねば!
と、こんな視点でチームを見ている自分にとって、採用を大変重視しているJoelの考え方は、大変参考になるのでした。
相変わらず青木さんの訳は(当然)読みやすく、お薦めの一冊です。
2008/03/13
XP 1st Ed.
チームでソフトウェア開発をする場合、チームビルディングが最も重要になります。
「え、スケジュール間に合わないの? 何人追加すれば終わるの?」等と聴いてくる管理職が多いのではないか、と偏見まじりに想像しますが、これが機能しないのは、例えば人月の神話等で、もう30年以上前から言われている事で、ちっとも新しい事ではありません。各人の能力を最大限に発揮させられるチームをマネジメントすることは、大変難しく、奥深いものです。
一方で、ソフトウェアを開発するには、勿論、個々人の開発スキルが重要です。開発系のプラクティスも、達人プログラマーなどで美しくまとめられています。
今振り返ると、XPは、2000年初頭という時期にありながら、この両者で必要となるプラクティスの選択バランスが、最高に絶妙だったと思うわけです。
当時の開発プロセスと言えば、CMMを筆頭とする管理者向けの内容が多かった中、「開発の中心は人間だ」という大前提をまず冷静に認めた上で、管理に必要なプロセスと開発に有益なプロセスとを、チーム全体で目的を達成する為に、一つの流れに組み込んだバランス感覚は、今振り返ってみても、大変素晴らしいな、と感じています。
ScrumやLeanなどの実践が、ブームから日常へと一歩一歩、着実に歩みを進めるのは非常に心強く感じています。この進歩を、更に確たるものとするために、
XPの持っていたバランス感覚を大事にして行きたいな、と感じています。
なお、XP 2nd ed.は多少方向性が変化しましたが、それでも心にとどめて置くべき内容は(勿論)満載で、お薦めです。
「え、スケジュール間に合わないの? 何人追加すれば終わるの?」等と聴いてくる管理職が多いのではないか、と偏見まじりに想像しますが、これが機能しないのは、例えば人月の神話等で、もう30年以上前から言われている事で、ちっとも新しい事ではありません。各人の能力を最大限に発揮させられるチームをマネジメントすることは、大変難しく、奥深いものです。
一方で、ソフトウェアを開発するには、勿論、個々人の開発スキルが重要です。開発系のプラクティスも、達人プログラマーなどで美しくまとめられています。
今振り返ると、XPは、2000年初頭という時期にありながら、この両者で必要となるプラクティスの選択バランスが、最高に絶妙だったと思うわけです。
当時の開発プロセスと言えば、CMMを筆頭とする管理者向けの内容が多かった中、「開発の中心は人間だ」という大前提をまず冷静に認めた上で、管理に必要なプロセスと開発に有益なプロセスとを、チーム全体で目的を達成する為に、一つの流れに組み込んだバランス感覚は、今振り返ってみても、大変素晴らしいな、と感じています。
ScrumやLeanなどの実践が、ブームから日常へと一歩一歩、着実に歩みを進めるのは非常に心強く感じています。この進歩を、更に確たるものとするために、
XPの持っていたバランス感覚を大事にして行きたいな、と感じています。
なお、XP 2nd ed.は多少方向性が変化しましたが、それでも心にとどめて置くべき内容は(勿論)満載で、お薦めです。
登録:
投稿 (Atom)