少し縁があってTEFに参加させていただいています。いや、縁っていうか、参加したいって言って参加しているだけですが
Testing Engineer’s Forum
http://www.swtest.jp/forum.html
ソフトウェア開発を行っていて、自分のテストに対する認識だとか考え方に関して不足を感じていました。その状態を打破しようと参加させていただき、勉強会も時々出させていただいてます。近くでやったときだけですが。。。
そちらのMLにてちょっと話題になっていたので手に取ってみました。ちなみに私自身はJavaでの開発経験はありませんが、Javaという言語に関係なくソフトウェアテストの基本的な教科書として読みやすいものでした。
うん、これはなかなか良書だ。会社の仲間にも広めないといけませんな。
ようやく「数学ガール フェルマーの最終定理」を読み終えた
数学は難しいけど、その面白さ、美しさが分かる小説
著者のインタビュー 数学を魅せる本第２弾
数式は良い 背理法の切れ味が心地よい
目次
- あなたへ
- プロローグ
- 第1章 無限の宇宙を手に乗せて
- 第2章 ピタゴラスの定理
- 第3章 互いに素
- 第4章 背理法
- 第5章 砕ける素数
- 第6章 アーベル群の涙
- 第7章 ヘアスタイルを法として
- 第8章 無限降下法
- 第9章 最も美しい数式
- 第10章 フェルマーの最終定理
- エピローグ
そこそこの厚みがある上に数式を毎回追いかけて考えたりするととても読むのに時間がかかる。数式の細かいところはいくつかは読み飛ばしたし、自分の手で計算をしてないから頭には入ってないけどやはり時間がかかる。
ただ、時間をかけるだけのことはあったのではないかとも思う。
懐かしいっていうか、習った定義とかってほとんど覚えてないんだな～ということを再実感。もう、色々と思いだしながら読んでいました
言葉の定義を覚えていないのはやはり使っていないこともあるけど、本書で出てくるたとえで言うところの”しっくりときてなかった”のだろう。その場その場で覚えた気になっていただけなのだ。
様々な定義や予測を立てながら証明をしていく様を読みながら、私は自分の仕事をなぜか思い出していた。
あちらこちらから来る障害の内容を確かめ、一つ一つ事実を確認しながら最終的に問題点や解決策を探していく。その過程では過去の障害事例や解決案を織り交ぜながら思考を巡らせていく。
それは、すでに過去に証明された内容を定義として利用し、命題を解いていく証明の進め方と結構ダブルのではないだろうか。
著者はJavaの本も多数執筆しているプログラマー。やはり、この仕事は数学的な考え方が。。。。！
ちょっとこじつけかな。
でも、与えられた命題を解く…という意味においては同じ作業なのではないかと思う。
そして、それを楽しいと思えるのは、理系な人間なんだろうなぁと思った。
O’REILLYから出ている「ソフトウェアアーキテクトが知るべき97のこと」を読んだ
珍しくAmazonが新刊を速攻で届けてくれた。つまり、予約があまりされなかったということだろう。技術書なんてそんなものだ…。
本書は、読んで字のごとくソフトウェアアーキテクトが知っておかなければいけないことや、何に注力していかないといけないのか？ということに関して数々の人がその考えを述べている。
本全体としてまとまっているというわけではなく、どちらかというと「あなたはどう思いますか？」って感じの質問に対しての解答集のようなものだ。
ちなみに、日本語訳は無いが原文はこちらにある
97 Things Every Software Architect Should Know – The Book
http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book
日本語版である本書は、上記97の内容以外に日本人アーキテクトによる追加の内容11本を含んでいる
実際には、それぞれの立場や会社の性質。従事しているプロジェクトの内容やチーム編成によっても立ち位置は変わってくると思うので、「おー！そうだよね！！」って思うこともあれば「ふーん」と思うこともあった。
ただ、まとまっていないといっても、考えることというのは比較的似通っていて、言っていることはある程度のカテゴリに分けられている
とってもざっくばらんに分けるとこんな感じじゃないかな？
たぶん、この人たちにとっては”ソフトウェアや技術に対する知識を持っているのは当たり前”で、プラスして何が重要かということが言いたいんだろう。技術ばっかりの頭でっかちになってはだめですよって。本書でたびたび出てくるところの「象牙の塔」ですね
- 象牙の塔 http://ja.wikipedia.org/wiki/%E8%B1%A1%E7%89%99（Wikipedia:象牙）
- 現実からかけ離れた夢想の世界。学者が閉じこもる研究室の比喩。ミヒャエル・エンデの『はてしない物語』にも登場する
面白いと思い、やはり悩ましいのはコミュニケーションだろう。
そんなときに必要なのは、昔から定評のあるテクノロジーです。実際、そのテクノロジーは、人類の歴史で最も重要な技術上のイノベーションです。何だと思いますか。それは話し合いです(P.6 Mark Ramm)
ソフトウェアアーキテクトをビジネスとデベロッパーの間に置くとなると、やはりこのスキルは必須になるだろう。これはプロジェクトをチームとして、会社として成功に導くためには間違いなく必要なことだ。
その割に、これにかかるコストだとか労力というものは軽視されがちで、結果としてプロジェクトはとん挫したりする。
また、もうひとつ。重要なコミュニケーションがある
ソフトウェア・アーキテクトは、どのプラットフォームの仕事をしているかにかかわらず、相互のコミュニケーションを円滑にするための手段を持たなければなりません。その手段の1つが、アーキテクチャー/デザインパターンによるコミュニケーションです。(P.84 Mark Richards)
そう。同じプラットフォーム、同じ言語で開発を行ったとしても別のチームのプログラマがすぐに他のチームで活躍できるとは限らない。仕様書が情報を知るための重要なリソースになることもあるが、プログラマであればまずソースを見ることが多いのではないか？その時に内容を理解したり、プログラムの意図や流れというものを理解するのにこれらデザインパターンというのは間違いなく威力を発揮する。
逆を言えば、本来であればデザインパターンを適用すると効果的な場面において適用されていないとすると、不必要な誤解を招く可能性まであるということだ。
私自身は、デザインパターンに対して習熟しているとはまだまだ言えない。
一人の技術者としてのコミュニケーションがとれるよう、勉強していかなければいけないと痛感することになった。
加藤 昌治さん著の考具を読んだ
この本自体が2003年に発売され、その後の数々の本や雑誌によって発想法は紹介されているので、特別”新しい”というものはなかった。もちろん、これを2003年に読んでいたら目からうろこ状態で歓喜していたかもしれない。
ただ、”知っている”ということと”できている”ということは別の話だ。「あー、これね。うん、知ってる知ってる」って言ったところでやったことがなかったり実際にそこから気付きが生まれる前に辞めてしまったり。
アイデア・発想法に関しては本書にも描かれているとおり「量が質を生む」という性質はあると思う。それがわかっているくせに続かない私はやはりわかっていないのだろう。
というわけで、さっそく会社で試してみることにした。本書とは直接関係はないのだが、KJ法によって「理想の職場」ってテーマでメンバーを集めて話し合ってみた。
KJ法(Wikipedia)
http://ja.wikipedia.org/wiki/KJ%E6%B3%95
やり方を知ってはいたものの、実際にやってみるとまとめるのが難しい！あまり、仕事直結の話以外に関して意見を出し合う機会も少なかったので、なかなか面白い発見がいくつかあった。
なかなか本で得た内容を実践することは難しいが、やはり実践することによって気付くことは多い。これからも忘れないようにしていかなければいけない。
ふと目に入ったので西田 宗千佳著 「クラウドコンピューティング仕事術」を読んだ
読んだ・・・のだが・・・ううむ、これは
クラウドを有効利用した仕事術ということで私が期待したこととは結構食い違っている内容であった。本書で取り上げられている内容は
くらいではないだろうか。
ラインナップからしても物足りない。私自身がＩＴ関連の企業に勤めているからそう思うだけなのかもしれないが、どれも十分すぎるほど認知されている内容だ。
もちろん、それぞれで書かれている内容はそんな変なことが書かれているわけではなく、分かりやすく書いてはいるのでこれらのサービスをあまり活用していない方にとっては参考になるかもしれない。
だが、ここまで広まっているモノに対して今更感があるのは否めないだろう。
数多いサービスがあるのであまり手広く広げすぎても読みづらい内容になってしまうかもしれないが、もう少し「イヒッ」って思えるようなサービスだったり使い方だったりが紹介されているといいと思った。
あれこれ考えてみたけど、自分自身でクラウドを利用した目新しいものはあまり使っていない。最近はiPhoneとOutlook、OneNoteあたりを旨い事何かできないかな～とは思っているけど、あまりクラウドって感じじゃない。
Windows AzureやGoogleAppsを使って自分でサービスを…ってのはちょっと現実的ではない。
さしずめ、個人でもメリットの出るセールスフォース等の利用方法なんてのも面白いのかもしれない。
「これって企業向けじゃない？」
って内容のサービスも、見方を変えれば個人で十分活用できるものもあるはずじゃないかな？
でも、案外そんなものなのかもしれない。
伊坂幸太郎作品を多く持っている友人から借りて、いくつか読んでいます。
読み終えたのは
今読んでいるのは
読み終えたら
を借りる手はずが整っている。それに魔王の続編といわれる
も読みたいと思っている。伊坂作品をひたすら読む日が続いているわけだが、さすがにここまで読み続けていると作者の傾向が見えてくる。なんとなく今回もこんな感じで終わるのかな～と思ったりしながら読むのは私にとってはなかなか新鮮でそれはそれで面白い。考えてみると、小説にしろビジネス書にしろ”特定の著者”の書物を立て続けに読むということはそれほどなかったこと。出来うることならば作者が書いた順に読むのが作者の意図が何かしら見えてきそうでいいような気もするけれど。まぁ、なかなかそう思っては見ても難しいものかな。2巡するくらいの意気込みでもあれば別だろうが。
それにしてもビジネス書以外の本をここまで立て続けに読んだのは初めてではないだろうか？あったとしてもそれは子供時代の話になりそうだ。うん、ドリトル先生とか
誰がどれだけの資産を持っているなんて分からない。実はあなたの隣にも？って事で「となりの億万長者」を読んだ
FInd out what the rich do. 20代の時に巡り合いたかった。 お金持ちになるための“守り”の教科書。 高額所得者ではなく、金融資産を持っている人＝となりの億万長者 あんまり･･･
本書で述べている”億万長者”は、収入がものすごい高い人という意味ではなく、莫大な”資産”を持っているのか？ということにフォーカスしている。
つまり、どれだけ収入があったとしても、支出をし続けていれば資産としては貯まるわけはない。実は、億万長者は高級な服や装飾品で身を固めたり高級車を何台も所有していたりするとは限らず、倹約していたりするというのが本書内の調査結果とされている。
収入を越えるような支出をしたり、それに近しい支出をする。これは別に億万長者に限らず普通の会社員であっても同じ考え方は適用できると思う。収入を上げることは短期的にはなかなか難しいかもしれないが、支出を下げることは比較的容易だ。それはわかる。
支出をコントロールする。これは支出をただ単に抑えるというわけではなく”意味のある支出をする”ということに尽きるのだと思う。
つまり、そのお金を投資しているのか浪費しているのか。これの見極めがどれだけできるか…。自分を納得させるために、実は浪費なのにもかかわらず”投資”だと思いこんでしまってはいないか。
他人にとっての投資行動が、必ずしも自分自身にとっての投資とは限らないはずで、これらは自分自身がしっかりと見極めていかなければならないこと。
自分自身が使うためにどれだけ資産が必要で、子供のためにどれだけ資産が必要なのか。もういい加減に真剣にならなければいけないだろうなぁ
Eric Sink著。青木 靖訳の「革新的ソフトウェア企業の作り方」を読んだ。内容は、Eric Sinkという人がMSDNのコラムにしるしたものを集めたのだと思う。
本書はソフトウェア開発者に向けられて作られた本であるけど、実際の内容は完全なビジネス書だと思う。著者はもっと多くのソフトウェア企業が世の中にはあるべきだと考え、マイクロISVという形態を提唱している。
本書で言うところの「マイクロISV」というのは、個人がISV（Independent Software Vendor:独立系ソフトウェア会社）を立ち上げる事になる。ただ、本書で薦められているものは脱サラ起業ではなく、いわゆる”週末起業”的な話。技術者であるソフトウェア開発者がそれを行おうとした場合に何に留意するべきか。どういう方向性で考えて行くべきかが本書では指南されている。
先般、ソフトウェア開発未来会議においてクラウド・コンピューティングが話題になった。ここで個人からみた視点として、iPhoneで言うところのAppStoreを例に挙げ、個人が作成したソフトウェアを世界に向けて配信する方向性の話が聞けた。オフライン会議に参加して、ここに強く共感を覚えたのはおそらく本書を読んでいる最中だったからだろう。
かなり刺激的な内容で、私自身も小さいながらISVに努めている事から色々と学ぶ事が多い一冊だった。また、昨今のクラウドに対する考え方やMarketPlaceがこの時期に出てきたのはもはや自分のためにあるのではないかと甚だ恥ずかしい勘違いをしたくなった。
また、ソフトウェア開発者であるならばぜひ読んでいただきたい私にとってお勧めの本となった。
どんなアプリケーションを作るのか。技術者の多くにとって不足しがちな商品開発におけるマーケティングの重要性があげられている。私もどちらかというとそうなのだが、”この技術を何かに使えないか？”という出発点ではなく、”この内容を実現するのにはどの技術が使えるのだろうか？”という、本来当たり前の出発点が必要になる。
「重要なのはユーザーにとってどうかということ」というのを覚えておこう。ユーザーが普通の人たちなら、彼らが.NET CLRをダウンロードしインストールする準備ができているだろうか注意して考える必要がある。普通の人々はすべてが「当たり前のように動く」ことを期待している（P.174）
そう、結局のところ技術は技術者にとっては主役なんだけどユーザにとってはどうでもいいことなんだ。Silverlightがどんなに操作性が良くても.Netの生産性が高くて製品の値段が抑えられても、インストールの手間がかかっていたのでは障壁になってしまう。これは意外と馬鹿に出来ないコストだ。言ってしまうと、我々開発者はその技術が一般化するまでは待たなければいけないことになる。ユーザーがアプリケーションを仕事として使っているのでない限り。
また、製品のマーケットの中での位置づけはどうするのか。
最近よく読む”週末起業”だとかの中では主に”その分野の先がけ・パイオニアになれ”という事がしきりに言われている。本書でのアプローチはこうだ
競合を避けることの大きな問題は、それが顧客をも避けることになるという事だ。競合の存在はお金を払っている顧客の存在を意味する。あなたのアイディアで商売をしている人が誰もいなかったとしたら、それが本当にお金になる事なのか怪しいと思うべきだ
（中略）
彼は、一番良いアプローチは「大きくて無能な」競合を見つけることだと言っている。（P.144-145）
完全に新しいマーケット。ブルーオーシャンは認知されるまでに大変大きい労力を要する。個人が週末レベルでそれを広めているのでは何年先になるのかがわからない。また、それがマーケットとして成り立つのかが不明だ。
マーケットの中で出来るだけ無能な競合を選び、そことの差別化を図る。製品の値段を決定する場合にも競合製品と見比べ、さらに価値を高めて値段を上につけて売り出す。もちろん、差別化した内容が、その価格差に適合しているのかは見極めないといけない。
だが、これらを考える基準を作る事が出来るのも競合がいて、そこのビジネスが成り立っているからであろう。やみくもにブルーオーシャンを探してニーズを無理に自分で想像していないか、確認する必要がある。
もちろん、そこにマーケットを見つけ出せるのであればブルーオーシャンを否定するものではない
この本で面白いのは、この主題を書きあげるためにEricが自らソフトを作って試してみたということだ。彼が作った”必ず勝つ方法があるソリティア”。その名も「Winnable Solitaire」だ。だが、彼の試みた今回の挑戦は結果として失敗した。
2004年9月29日の時点で、Winnable Solitaireは6本売れ、あんまりすごくない合計42ドルの収入を上げた。
支出が0だったなら、新たに得られたこの富で豪勢に買い物をするところだが、開発の際、アートワークのために379ドル使った。また、リリースして以来271ドルを広告で使っている。<中略>結論として、私の損益計算書には現在純損失626ドルと記されている。（P.50）
この失敗に対してEricは10の考えを記事にしている。「勝てる」というのは差別化要因としては弱かったのか？別な種類の製品であったなら？等々
これはよく言われる話ではあるけど、成功するためには多くの失敗をし、その多くの失敗から学ぶ必要があるという事だ。今回もEricは「これは素晴らしい失敗の仕方だと思う」、「小さな失敗で私が傷つくことは全くないと思う」等々の記事を記している。
結局のところ、多くの失敗をして学んだとしても次につなげることができなければ最終的な成功を収めることはできない。そのために致命的な失敗をしないための保険なりをかけておくべきなのだろう。
作ったばかりで売れてもいないソフトウェアに一人で惚れこんで、勢いあまって会社を辞めてしまうようなことはするべきじゃない。そこまでしなくてもマイクロISVという形態であれば十分可能性を試すことができるんだよってことだろう。
実際のところこのマイクロISVという事を実践するための環境は着実に整ってきているのではないだろうか。
クラウドコンピューティングは多くの開発者にサービスを提供する場を与え、AppStoreやWindowsMarketPlaceはモバイル端末に対してアプリケーションを配布する一つの入り口としての機能を持っている。
これらの場を生かして、早く、小さくともアウトプットを出していくことが大切なのだろう。エピローグに載せられた言葉をもって今日のエントリーを締めくくりたい
（君の考えは）クールなアイディアに聞こえる。実装はそう難しくないだろう。君にはそれをやる時間がある。基本的に心配すべきリスクはあまりない。このアイディアが良いものか見極めようと多くの時間を使ったところで。結局確かなことはわからないだろう。そうする代わりに、同じ時間をこのアイディアの実装に使う事も出来る。そうすればこのアイディアが良いものかどうかが本当にわかるだろう。
以前、日経新聞の文化欄に記事が載っていた水村美苗さんの日本語が亡びるときを読んだ
実はこの本、ずっと前に買っていたのですが内容の濃さにやられてしまい、途中で数冊に浮気をしていて読み終えるのに随分と時間がかかってしまいました(^^;
この本を読んでいると、著者の日本語を愛する気持ちがヒシヒシと伝わってきます。かつて、これほどまで一つの言語が世界に広がったことはないのではないか。この現代において英語が読めるか・読めないか。これは多くの知識を手に入れることが出来るか・出来ないかに直結する。そしてそれは日本人に限ったことではない。そうなると、他の”英語以外を母国語”としている人にとっては私たちと同じように英語の文は読むかもしれない。しかし、日本語で書かれた文はどうだろうか？
“読まれるべき文”は必然と英語でかかれるようになるのではないだろうか？それでも日本語が日本人にとって”読まれるべき文”であるにはどうあるべきなのか。
色々と考えさせられる本だった。今までの私は “言葉は時代とともに変わっていく。話し方や話し言葉が変わっても、それはそういうものだろう”と考えていた。しかし、本書を読んだ後で考えると本当に今の言葉は魅力ある日本語として変わっているのだろうか？
少なくとも、若者言葉を見ている限りでは余りそうは思えない。日本語がどうあるべきなのか。
私は子供のころからそれほど本を読んでいるわけではない。大学、そして社会人になってからも本を読む週間がそれほどあったわけでもなく著者の言う”近代日本文学の古典”で表されている日本語の素晴しさ。これに関しては正直今の私には分からない。
しかし、非常に興味は沸いてくる。私が、日本人が、日本の文化を知るために。読んでみようかな
別所哲也さん著「夢をカタチにする仕事力」を読んだ
日本の映画史に名を残す人になる プロジェクトの成功は、プロジェクト･マネジャーの情熱です 熱意とあるべきビジョンは必ずしも一致しないんだなぁ 感服すべき行動力
目次
- プロローグ
- 1章 「ショートショート フィルムフェスティバル」とは
- 2章 夢をカタチにする方法
- 3章 夢を持続する方法—-人とのつながり
- 4章 映画祭のグランドデザイン—-夢は自分で歩き出す
- エピローグ
正直言うと、私は余り芸能人に明るくない。昔からドラマを余り見ないこともあるけど、テレビの中の人の名前と顔を覚えることができないことにある。たぶん一番の原因は「自分のこととして考えられない対象」だからなんだと思う。
覚えられるのは、せいぜいお笑い芸人のみだ。顔が特徴的だから（笑）
そんな私がこの本を手に取ったのは一重に「結果を出す人」はノートに何を書いているのか (Nanaブックス)の著者である美崎さん主催の「築地朝食会」にゲストとして出るという理由から。
いやはや、何とも何とも。不純な動機である。
本書は俳優である別所さんが実際に映画祭というプロジェクトを成し遂げる中で身に付けた仕事術を紹介している
仕事術や仕事力というと、どちらかというとノウハウを思い浮かべてしまいますが、本書の中で別所さんが書いていること。実はそのほとんどは仕事に対する向き合い方や心構え。そういったものが中心になってきています。
特に本書の中でたびたび出てくる「If you go fast, you go alone. If you go farther, go together」（早く行きたいのであれば一人で行きなさい。遠くに行きたいのであればみんなで行きなさい）という言葉は、なかなか。なるほどと思った。
確かにそういうところはある。
特に技術系の仕事をしているとそういう印象を強く感じてしまう（と思う）。何かしら調べ物やモノを作る時に、人に教えたり私事をしたりするよりは明らかに自分でやってしまったほうが早い場面は結構ある。特に、人に任せて思うような結果がいつまでたっても出てこない時。自分自身の仕事に対する姿勢が厳しければ厳しいほどその思いは強くなってしまうだろう。
時として、それを最終的に自分の手でこなしてしまう時もあるけど、それを最初から行ってしまっては最終的に全員の利益につながらない事が多い。自分自身がより高みに成長するためにも、今の自分の仕事を人に与えるという考え方もあると思う。
目的は早く行くことなのか
それとも遠くに行くことなのか
しっかりと見極めて歩いていかなければいけない。
今の私の課題は、「では、どのくらいまでの状況を許容するのか」の見極め。任せるというのは放置することではないのである程度フォローはするが、時として自分が手を出さなければいけない場面もあると思う。
全体として、遠くに行くために。私自身、遠くに行くために。
何を考え、どう動くのか。
難しいのぅ