読書感想文」カテゴリーアーカイブ

あぁ、テストエンジニア

いちばんやさしいソフトウェアテストを読んだ

いちばんやさしいソフトウェアテストの本 (技評SE新書 19) (技評SE新書)
石原 一宏 布施 昌弘
技術評論社
売り上げランキング: 14416

ソフトウェアを開発するうえでテストというものは必要不可欠な話である。ただ、ソフトウェアのテストエンジニアや品質管理者というものを目指す!という話をあまり聞いた事がない。これは私が聞いた事がないだけの話かもしれない。
本書はその現状を打破するために作られた本ではないかと思う。
テスト工程は、あくまでテストする対象となる機能。ここで言うとプログラムがない限りは実際のテストは出来ない。もちろん、仕様上の不備・不具合を指摘したりそれに合わせてテスト計画を練る事もとても重要な作業だ。ただ、肝心の開発が予定通り進む事は稀で往々にして遅れが発生する。その時に削られるのはまっさきにテスト工数がやり玉にあげられる。
バグを見つけたら見つけたで開発側からは裏切り者扱いされたりもするかもしれない。もちろん、バグを見つけたという事は間違いなく評価されるべき事で、そのままプログラムが世に出た時の被害を考えれば素晴らしい事。ただ、納期が迫ってただでさえ遅れが発生している開発担当者の感情的な心根としてそういう発想につながってしまう事もあるだろう。
本書でも第6章で涙ぐましい対策が語られている

常に挨拶と礼節を心がけ、開発者とチームメンバーとよりよい関係を目指します!
(中略)
そこで、テストエンジニアは常に開発者と良好な信頼関係を保ち気軽に話ができるようになっておく必要があります。(P126)

開発側に属する私としては色々と頭を下げたくなる内容だ。
これからのソフトウェア開発を考えると品質というものはより求められ、それに比例するかのようにテストエンジニアの価値というものはどんどん上がっていくだろう。
本書がそのきっかけとなってくれる事を願う。

ただ、本書は対象とする読者をどこに置いているのだろうか?実際に開発に携わっている人間にとっては本書は優しすぎる。そうなると、対象読者はだれになるのだろうか?
第1章は優しいものの、その後はV字モデルの説明、W字モデル。名前だけならAllPairsや直交表も出てくる。
うーん、対象は学生なのかな?

既知への向き合いかた

小飼弾氏著「決弾」を読んだ

決弾 最適解を見つける思考の技術
小飼 弾 山路 達也
アスペクト
売り上げランキング: 103246
おすすめ度の平均: 3.5

4 電子書籍で読んでみました
5 もう決断に悩まない
3 頭の体操に
4 機械以下の奴隷にならないために
4 決断は買えない

前作となる弾言とは異なり、本書はQA形式仕立ての構成になっている。
実は今回もiPhoneで購入したのだが…iPhoneはリアル書店と違って試し読みができない。小飼氏がどういう思いでこの構成にしたのかは不明だが、個人的にはあまり好きじゃないなぁーと思った
小飼氏に共感できるか以前に質問に共感できないことがしばしば有るからである
勿論、それらに対してなんて答えるのか?という意味においては、興味深いものも有るのですけどね

あ、それ知ってるな

最近、本をそれなりの量読むようになってきた。私は速読とかフォトリーディングとか出来ない(うまく見についてない)ので、読むスピードは遅いですが。
ただ、「あ、それどっかに書いてあったな」と思うことは良くある。

たいていはどの本の内容も既知の知識であり、人によっては知っている内容です。
けれど、「この知識をこう表現できるんだ」ということは勝間さんの本を読むまでしらなかった。1つの事実に対しても、表現は複数ある。目にとっての読書の楽しみとは、新事実との遭遇ではなく、新表現との遭遇なんです

なるほど、確かに書いて有ることの、私は9割とはいかないかもしれないが、多くは読み手側が既に知っている内容なのかもしれない。知りたいと思う内容に関して、現代では本当の意味での”新事実”なんてそうそう簡単には出てこないだろう。
ただ、知っているのと自分の言葉に出来る、使うことが出来るというのは違う。
こう言う使い方や表現方法も有るんだ!って言う読み方は、自分の言葉にするための手助けになるかもしれないと思った。

私は情けない話ではあるが、セミナー。特に暗転している場のセミナーでは寝てしまうことがある。話の中に「あ、それ知ってるな」があった瞬間に一気に興が削がれてしまう感じ。そして、肝心な部分を見逃すんだから世話ない話だ。
気持ちの持ちようなんだろうけど…ちょっとこの考え方を取り入れてみよう

え?根がいい加減だからそんなことになるんだって?
たぶん、それも当たっているんだとは思う。

何を読み取るのか

これまで、本を読むときには「何かを得なきゃ!」という気持ちが強い。たぶんこれは、”元をとる”っていう意味ではそんなに間違ってはいないスタンスなんだろうけど、得るものが、必ずしも本のタイトルにある分野である必要はないということに気がついた気がする。
もしかすると、これはそもそもの小飼氏の思惑とは外れるかもしれないが、本にある言い回しであったり表現だったり。そこに行きつくまでの背景だったりを読み取ることも一つの成果ではないだろうか。
これらを積み重ねて自分のものとして整理することに今後気をつけていくことにしよう。

謎解き謎解き

ようやく「数学ガール フェルマーの最終定理」を読み終えた

数学ガール/フェルマーの最終定理
結城 浩
ソフトバンククリエイティブ
売り上げランキング: 5141
おすすめ度の平均: 4.5

5 数学は難しいけど、その面白さ、美しさが分かる小説
2 著者のインタビュー
5 数学を魅せる本第2弾
3 数式は良い
5 背理法の切れ味が心地よい

目次

  • あなたへ
  • プロローグ
  • 第1章 無限の宇宙を手に乗せて
  • 第2章 ピタゴラスの定理
  • 第3章 互いに素
  • 第4章 背理法
  • 第5章 砕ける素数
  • 第6章 アーベル群の涙
  • 第7章 ヘアスタイルを法として
  • 第8章 無限降下法
  • 第9章 最も美しい数式
  • 第10章 フェルマーの最終定理
  • エピローグ

そこそこの厚みがある上に数式を毎回追いかけて考えたりするととても読むのに時間がかかる。数式の細かいところはいくつかは読み飛ばしたし、自分の手で計算をしてないから頭には入ってないけどやはり時間がかかる。
ただ、時間をかけるだけのことはあったのではないかとも思う。

ピタゴラ

懐かしいっていうか、習った定義とかってほとんど覚えてないんだな~ということを再実感。もう、色々と思いだしながら読んでいました

  • ピタゴラスの定理
  • 合同
  • 複素数

言葉の定義を覚えていないのはやはり使っていないこともあるけど、本書で出てくるたとえで言うところの”しっくりときてなかった”のだろう。その場その場で覚えた気になっていただけなのだ。

証明せよ

様々な定義や予測を立てながら証明をしていく様を読みながら、私は自分の仕事をなぜか思い出していた。
あちらこちらから来る障害の内容を確かめ、一つ一つ事実を確認しながら最終的に問題点や解決策を探していく。その過程では過去の障害事例や解決案を織り交ぜながら思考を巡らせていく。
それは、すでに過去に証明された内容を定義として利用し、命題を解いていく証明の進め方と結構ダブルのではないだろうか。
著者はJavaの本も多数執筆しているプログラマー。やはり、この仕事は数学的な考え方が。。。。!
ちょっとこじつけかな。

でも、与えられた命題を解く…という意味においては同じ作業なのではないかと思う。
そして、それを楽しいと思えるのは、理系な人間なんだろうなぁと思った。

ソフトウェアアーキテクトが知るべき97のこと

O’REILLYから出ている「ソフトウェアアーキテクトが知るべき97のこと」を読んだ

ソフトウェアアーキテクトが知るべき97のこと
オライリージャパン
売り上げランキング: 747

珍しく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本を含んでいる

何を知るべきなのか

実際には、それぞれの立場や会社の性質。従事しているプロジェクトの内容やチーム編成によっても立ち位置は変わってくると思うので、「おー!そうだよね!!」って思うこともあれば「ふーん」と思うこともあった。
ただ、まとまっていないといっても、考えることというのは比較的似通っていて、言っていることはある程度のカテゴリに分けられている

  1. 技術を正しく把握・使うことの重要性
  2. コミュニケーションの重要性
  3. ビジネスを考えることの重要性

とってもざっくばらんに分けるとこんな感じじゃないかな?
たぶん、この人たちにとっては”ソフトウェアや技術に対する知識を持っているのは当たり前”で、プラスして何が重要かということが言いたいんだろう。技術ばっかりの頭でっかちになってはだめですよって。本書でたびたび出てくるところの「象牙の塔」ですね

  • 象牙の塔 http://ja.wikipedia.org/wiki/%E8%B1%A1%E7%89%99(Wikipedia:象牙)
    • 現実からかけ離れた夢想の世界。学者が閉じこもる研究室の比喩。ミヒャエル・エンデの『はてしない物語』にも登場する

面白いと思い、やはり悩ましいのはコミュニケーションだろう。

そんなときに必要なのは、昔から定評のあるテクノロジーです。実際、そのテクノロジーは、人類の歴史で最も重要な技術上のイノベーションです。何だと思いますか。それは話し合いです(P.6 Mark Ramm)

ソフトウェアアーキテクトをビジネスとデベロッパーの間に置くとなると、やはりこのスキルは必須になるだろう。これはプロジェクトをチームとして、会社として成功に導くためには間違いなく必要なことだ。
その割に、これにかかるコストだとか労力というものは軽視されがちで、結果としてプロジェクトはとん挫したりする。
また、もうひとつ。重要なコミュニケーションがある

ソフトウェア・アーキテクトは、どのプラットフォームの仕事をしているかにかかわらず、相互のコミュニケーションを円滑にするための手段を持たなければなりません。その手段の1つが、アーキテクチャー/デザインパターンによるコミュニケーションです。(P.84 Mark Richards)

そう。同じプラットフォーム、同じ言語で開発を行ったとしても別のチームのプログラマがすぐに他のチームで活躍できるとは限らない。仕様書が情報を知るための重要なリソースになることもあるが、プログラマであればまずソースを見ることが多いのではないか?その時に内容を理解したり、プログラムの意図や流れというものを理解するのにこれらデザインパターンというのは間違いなく威力を発揮する。
逆を言えば、本来であればデザインパターンを適用すると効果的な場面において適用されていないとすると、不必要な誤解を招く可能性まであるということだ。

私自身は、デザインパターンに対して習熟しているとはまだまだ言えない。
一人の技術者としてのコミュニケーションがとれるよう、勉強していかなければいけないと痛感することになった。

考具を読んだ

加藤 昌治さん著の考具を読んだ

考具―考えるための道具、持っていますか?
加藤 昌治
阪急コミュニケーションズ
売り上げランキング: 1683

この本自体が2003年に発売され、その後の数々の本や雑誌によって発想法は紹介されているので、特別”新しい”というものはなかった。もちろん、これを2003年に読んでいたら目からうろこ状態で歓喜していたかもしれない。
ただ、”知っている”ということと”できている”ということは別の話だ。「あー、これね。うん、知ってる知ってる」って言ったところでやったことがなかったり実際にそこから気付きが生まれる前に辞めてしまったり。
アイデア・発想法に関しては本書にも描かれているとおり「量が質を生む」という性質はあると思う。それがわかっているくせに続かない私はやはりわかっていないのだろう。

というわけで、さっそく会社で試してみることにした。本書とは直接関係はないのだが、KJ法によって「理想の職場」ってテーマでメンバーを集めて話し合ってみた。

KJ法(Wikipedia)
http://ja.wikipedia.org/wiki/KJ%E6%B3%95

やり方を知ってはいたものの、実際にやってみるとまとめるのが難しい!あまり、仕事直結の話以外に関して意見を出し合う機会も少なかったので、なかなか面白い発見がいくつかあった。
なかなか本で得た内容を実践することは難しいが、やはり実践することによって気付くことは多い。これからも忘れないようにしていかなければいけない。

クラウドコンピューティング仕事術

ふと目に入ったので西田 宗千佳著 「クラウドコンピューティング仕事術」を読んだ

クラウド・コンピューティング仕事術 (朝日新書)
西田 宗千佳
朝日新聞出版
売り上げランキング: 33003

読んだ・・・のだが・・・ううむ、これは

仕事術というよりは入門?

クラウドを有効利用した仕事術ということで私が期待したこととは結構食い違っている内容であった。本書で取り上げられている内容は

  • GMail
  • EverNote
  • スマートフォンの利用
  • バックアップは大事だよ

くらいではないだろうか。
ラインナップからしても物足りない。私自身がIT関連の企業に勤めているからそう思うだけなのかもしれないが、どれも十分すぎるほど認知されている内容だ。
もちろん、それぞれで書かれている内容はそんな変なことが書かれているわけではなく、分かりやすく書いてはいるのでこれらのサービスをあまり活用していない方にとっては参考になるかもしれない。
だが、ここまで広まっているモノに対して今更感があるのは否めないだろう。
数多いサービスがあるのであまり手広く広げすぎても読みづらい内容になってしまうかもしれないが、もう少し「イヒッ」って思えるようなサービスだったり使い方だったりが紹介されているといいと思った。

では、何を?

あれこれ考えてみたけど、自分自身でクラウドを利用した目新しいものはあまり使っていない。最近はiPhoneとOutlook、OneNoteあたりを旨い事何かできないかな~とは思っているけど、あまりクラウドって感じじゃない。
Windows AzureやGoogleAppsを使って自分でサービスを…ってのはちょっと現実的ではない。
さしずめ、個人でもメリットの出るセールスフォース等の利用方法なんてのも面白いのかもしれない。
「これって企業向けじゃない?」
って内容のサービスも、見方を変えれば個人で十分活用できるものもあるはずじゃないかな?

でも、案外そんなものなのかもしれない。

伊坂作品を続々と

伊坂幸太郎作品を多く持っている友人から借りて、いくつか読んでいます。

読み終えたのは

オーデュボンの祈り (新潮文庫)

オーデュボンの祈り (新潮文庫)

アヒルと鴨のコインロッカー (創元推理文庫)

アヒルと鴨のコインロッカー (創元推理文庫)

今読んでいるのは

重力ピエロ (新潮文庫)

重力ピエロ (新潮文庫)

読み終えたら

ラッシュライフ (新潮文庫)

ラッシュライフ (新潮文庫)

を借りる手はずが整っている。それに魔王の続編といわれる

モダンタイムス (Morning NOVELS)

モダンタイムス (Morning NOVELS)

も読みたいと思っている。伊坂作品をひたすら読む日が続いているわけだが、さすがにここまで読み続けていると作者の傾向が見えてくる。なんとなく今回もこんな感じで終わるのかな~と思ったりしながら読むのは私にとってはなかなか新鮮でそれはそれで面白い。考えてみると、小説にしろビジネス書にしろ”特定の著者”の書物を立て続けに読むということはそれほどなかったこと。出来うることならば作者が書いた順に読むのが作者の意図が何かしら見えてきそうでいいような気もするけれど。まぁ、なかなかそう思っては見ても難しいものかな。2巡するくらいの意気込みでもあれば別だろうが。

それにしてもビジネス書以外の本をここまで立て続けに読んだのは初めてではないだろうか?あったとしてもそれは子供時代の話になりそうだ。うん、ドリトル先生とか

ドリトル先生アフリカゆき (岩波少年文庫 (021))

ドリトル先生アフリカゆき (岩波少年文庫 (021))

実はとなりにいたりする?

誰がどれだけの資産を持っているなんて分からない。実はあなたの隣にも?って事で「となりの億万長者」を読んだ

となりの億万長者―成功を生む7つの法則
トマス・J. スタンリー ウィリアム・D. ダンコ
早川書房
売り上げランキング: 1581
おすすめ度の平均: 4.5

4 FInd out what the rich do.
4 20代の時に巡り合いたかった。
5 お金持ちになるための“守り”の教科書。
4 高額所得者ではなく、金融資産を持っている人=となりの億万長者
3 あんまり・・・

億万長者の定義

本書で述べている”億万長者”は、収入がものすごい高い人という意味ではなく、莫大な”資産”を持っているのか?ということにフォーカスしている。
つまり、どれだけ収入があったとしても、支出をし続けていれば資産としては貯まるわけはない。実は、億万長者は高級な服や装飾品で身を固めたり高級車を何台も所有していたりするとは限らず、倹約していたりするというのが本書内の調査結果とされている。

収入を越えるような支出をしたり、それに近しい支出をする。これは別に億万長者に限らず普通の会社員であっても同じ考え方は適用できると思う。収入を上げることは短期的にはなかなか難しいかもしれないが、支出を下げることは比較的容易だ。それはわかる。

支出をコントロールする。これは支出をただ単に抑えるというわけではなく”意味のある支出をする”ということに尽きるのだと思う。
つまり、そのお金を投資しているのか浪費しているのか。これの見極めがどれだけできるか…。自分を納得させるために、実は浪費なのにもかかわらず”投資”だと思いこんでしまってはいないか。
他人にとっての投資行動が、必ずしも自分自身にとっての投資とは限らないはずで、これらは自分自身がしっかりと見極めていかなければならないこと。

自分自身が使うためにどれだけ資産が必要で、子供のためにどれだけ資産が必要なのか。もういい加減に真剣にならなければいけないだろうなぁ

革新的ソフトウェア企業の作り方

Eric Sink著。青木 靖訳の「革新的ソフトウェア企業の作り方」を読んだ。内容は、Eric Sinkという人がMSDNのコラムにしるしたものを集めたのだと思う。

Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方
Eric Sink エリック・シンク
翔泳社
売り上げランキング: 24226

本書はソフトウェア開発者に向けられて作られた本であるけど、実際の内容は完全なビジネス書だと思う。著者はもっと多くのソフトウェア企業が世の中にはあるべきだと考え、マイクロ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はモバイル端末に対してアプリケーションを配布する一つの入り口としての機能を持っている。
これらの場を生かして、早く、小さくともアウトプットを出していくことが大切なのだろう。エピローグに載せられた言葉をもって今日のエントリーを締めくくりたい

(君の考えは)クールなアイディアに聞こえる。実装はそう難しくないだろう。君にはそれをやる時間がある。基本的に心配すべきリスクはあまりない。このアイディアが良いものか見極めようと多くの時間を使ったところで。結局確かなことはわからないだろう。そうする代わりに、同じ時間をこのアイディアの実装に使う事も出来る。そうすればこのアイディアが良いものかどうかが本当にわかるだろう。

日本語が亡びるとき

以前、日経新聞の文化欄に記事が載っていた水村美苗さんの日本語が亡びるときを読んだ

日本語が亡びるとき―英語の世紀の中で

日本語が亡びるとき―英語の世紀の中で

実はこの本、ずっと前に買っていたのですが内容の濃さにやられてしまい、途中で数冊に浮気をしていて読み終えるのに随分と時間がかかってしまいました(^^;

この本を読んでいると、著者の日本語を愛する気持ちがヒシヒシと伝わってきます。かつて、これほどまで一つの言語が世界に広がったことはないのではないか。この現代において英語が読めるか・読めないか。これは多くの知識を手に入れることが出来るか・出来ないかに直結する。そしてそれは日本人に限ったことではない。そうなると、他の”英語以外を母国語”としている人にとっては私たちと同じように英語の文は読むかもしれない。しかし、日本語で書かれた文はどうだろうか?
“読まれるべき文”は必然と英語でかかれるようになるのではないだろうか?それでも日本語が日本人にとって”読まれるべき文”であるにはどうあるべきなのか。

色々と考えさせられる本だった。今までの私は “言葉は時代とともに変わっていく。話し方や話し言葉が変わっても、それはそういうものだろう”と考えていた。しかし、本書を読んだ後で考えると本当に今の言葉は魅力ある日本語として変わっているのだろうか?
少なくとも、若者言葉を見ている限りでは余りそうは思えない。日本語がどうあるべきなのか。
私は子供のころからそれほど本を読んでいるわけではない。大学、そして社会人になってからも本を読む週間がそれほどあったわけでもなく著者の言う”近代日本文学の古典”で表されている日本語の素晴しさ。これに関しては正直今の私には分からない。
しかし、非常に興味は沸いてくる。私が、日本人が、日本の文化を知るために。読んでみようかな