The more you write, the more you'll be able to write.

前のエントリーにも書いたが、現在、Joel on Softwareを読んでいる。Joelの文章能力が高いからだと思うが、Software開発の基本が優しく解説されている。小難しく書いてないから、頭にもスムーズに入ってくるし、1エントリーごと納得しながら読める。

今日、僕にとって、ためになったなーと特に思えた部分。

Painless Functional Specifications – Part 1: Why Bother?

I think it’s because so many people don’t like to write. Staring at a blank screen is horribly frustrating. Personally, I overcame my fear of writing by taking a class in college that required a 3-5 page essay once a week. Writing is a muscle. The more you write, the more you’ll be able to write. If you need to write specs and you can’t, start a journal, create a weblog, take a creative writing class, or just write a nice letter to every relative and college roommate you’ve blown off for the last 4 years. Anything that involves putting words down on paper will improve your spec writing skills. If you’re a software development manager and the people who are supposed to be writing specs aren’t, send them off for one of those two week creative writing classes in the mountains.

正直に告白すると、僕はスペックを書かずにプログラム(コード)を書き始める事が多々ある。理由は時間がかかって、面倒くさいからだ。要するにスペックを書くのが嫌いだ。なぜ面倒なのか?なぜ嫌いなのか?私のスペックを書く力が弱いのだ。Joelによれば、「ライティングは筋力だ、書けば書くほど上達する」と本の中で言っている。僕は、それはプログラミングも同じだと感ずる。プログラム(コード)を書く力は、プログラムを書けば書くほど上達する。機能スペックがソフトウエア開発に及ぼす良い影響は明らかだ。僕は良いソフトウエアを作るためにも、より良いソフトウエア開発プロセスのためにも、よい機能スペックを書かなければならない。よいスペックを書くためにも、普段からもっと文章を書かなければならない。

「パクリ」で影響を与え合う、それは音楽の基本です

「日本の底力は『おもしろければなんでもあり』にあり」

「パクリ」で影響を与え合う、それは音楽の基本です

―― ところが、我々の年代ぐらいになると、探す時にどうも思い込みがはいるんですよ。「J-POPは若い人向けで、つまらない」とか、「パクリだろ」とか、「洋楽のマネ」だとか……。

マーティ: 誰がそれを言いだしたのかは知らないけれど、それはバカな人だよね。どんな音楽でも、ミュージシャン同士、いろいろ影響しあってる。ビートルズだって、プレスリーから影響受けてるじゃん。プレスリーも、チャック・ベリーも、影響しあってるじゃん。

 どんなミュージシャンも、100%、誰かの影響を受けてるから、パクリとかそんなことは考えない方がいいんですよ。「その音楽が好きだから。好 き」。誰かがパクったとか、パクリ=悪とか、もったいないよね、その考え方。だって僕、ビートルズは嫌いだけど、PUFFY大好き(笑)。

 そういうイメージは、すごく消えてほしい。だって、まったく同じように洋楽だってパクっているんだし。日本では元曲が分からないから、わからない のかな。それに……最近、アメリカのアーティストは日本のアーティストをパクってるよ。 ビジュアル系の影響が少しずつ入っているし、イメージだけじゃなくて、音楽のセンスもパクってる。僕の音楽だって、日本に住んでいる影響がいっぱい。みん な、お互いに影響あるんだから、そしてそれがいいんじゃない。

「日本発のソフトウエア・ネットサービスってないよな、日本にあるソフトウエア・ネットサービスってアメリカの真似だよねって」って長い事思い続けて来た。だからと言って自分に独自の物を作り出すアイデアや実行能力があるわけではないのだが。でも、音楽の世界で「パクリ+自分のエッセンス」がOKならば、ソフト・ネットの世界だって「パクリ+自分(達)のエッセンス」はOKなのではと思えた。現在世界最高峰の日本車だって、元はアメリカの自動車からの派生だし。他のソフト・ネットサービスからアイデアをパクッタリ、影響受けたりして、そこに自分(達)のアイデア、エッセンス、何かを足して、ユーザーに喜ばれる物を作る。これは、けして反則技ではない。しかし、ただ単に「何かのコピー」って、コピーしている人もつまらない。やはり自分(達)のエッセンスを加えなければ、自分達もつまらないし、ユーザーから見たら何が違うのって事になってしまう。小さなアイデア、小さな改良でよいから、独自の物が必要だ。小さなアイデアを足し続けたり、小さな改良を続ける事によって、次の世代のソフトウエア・ネットサービスに進化して行く事も十分考えられる。「パクリ」=「悪」だと思い込んでいた自分にとって凄く面白い記事でした。

他の人に貢献することで評価される

渡辺千賀さんのセミナーのお知らせの中に大事な事がのっていた。

「きっかけを自ら作り出し、変化を起こすための7つのルール」 
1. 実力発揮の場を作る 

  • 「きっかけ」は外からふってくるものが多い。そのためにはなるべく多くの人に自分ができることを知ってもらうのが大事。
  • 「わたしがわたしが」と自己顕示欲でしゃしゃりでるのではなく、他の人に貢献することで評価される。仕事の場でのワークグループ参加、プライベートでオープンソースに参加したりボランティアをしたり、などいろいろな方法がある。

from 19日のセミナー「スタート×キッカケ×ブログ」で話すこと

経験からの感覚では分かっていたのだが、自分を知ってもらう為には、他の人に貢献しなければならない。僕は会社務めなので、面白い仕事を回してもらったり、給料を上げてもらうためには、上司に僕の事を知ってもらわなければならない。僕を知ってもらう為には、上司に貢献するのが一番手っ取りはやい。他の人がやりたがらない事をやり遂げるのは中々良いアピールになるし、自分を実力を知ってもらう良い機会だと思う。他の部署のプロジェクトに興味があるのだったら、その部署で開催しているイベントに参加して、そのイベントに何らかの形で貢献した方がよい。その方が良く知ってもらえる。ヘルプを求められた時は、出来る限り協力したほうがよい。困っている人を助ける時は自分を知ってもらうよいチャンスだ。
口でただ「僕は出来る」と言っても中々伝わらない。これは世界共通だと思う。
僕自身の課題は、どうやって多くの人に自分の事を知ってもらうかだ。

The Joel Test

前から読みたいと思っていた、Joel on Softwareを読み始めた。出だしから中々良いです。ソフトウエア開発に関して、今まで、当たり前の事だけど、言葉として上手に整理出来ていなかった事がいくつかあった。それらの事を彼の言葉を借りて再確認している状況。今日中々良いと思えたものThe Joel Testに付いて。

The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

これはJoelが考え出したソフトウエア開発チームの質をはかるテスト。

  1. ソースコードバージョン管理システムを使っているか?
  2. 1ステップでアプリケーションをビルド出来るか?
  3. 毎日コードをビルドしているか?
  4. バグ管理システムを使っているか?
  5. 新機能を追加する前にバグを修正しているか?
  6. スケジュールは絶えずアップデートしているか?
  7. コードを書き始める前にスペックは書いているか?
  8. プログラマーが仕事に集中できる環境であるか?
  9. 最高のツールを使っているか?
  10. QAエンジニアはいるか?
  11. 仕事の面接で候補者にコードを書かせているか?
  12. ユーザービリティ・テストをしているか?
僕が働いてきたソフトウエア会社は、どこも、1番、4番、10番は満たしている。しかし、その他の部分は会社に寄って違う。7番に関しては、ソースコードが仕様書だとか言って、いきなりコードを書き始める事もある。6番に関して、いざ開発が始まるとスケージュールのアップデートなどは後回しになってしまう。インタビューでは、僕が今日の面接官は出来る人だったなと感じた人は、インタビューの中で、実際のコードもしくはpseudoコードを書かせていたなー。上記の12リスト当たり前の事だけど、当たり前に出来ていないので、この本の中でJoelが上手に説明してくれていて大変役に立つ。この本は読むのが楽しい。
(*)この本はJoelのブログを元に書かれています。

出来るソフトウエアエンジニアの10の習慣

Top 10 Traits of a Rockstar Software Engineer

  1. Loves To Code
  2. Gets Things Done
  3. Continuously Refactors Code
  4. Uses Design Patterns
  5. Writes Tests
  6. Leverages Existing Code
  7. Focuses on Usability
  8. Writes Maintainable Code
  9. Can Code in Any Language
  10. Knows Basic Computer Science
  1. コーディングが大好きである
  2. やり遂げる事ができる
  3. リファクタリングを心がけている
  4. デザインパターンを利用する
  5. 単体テストを書く
  6. コードの再利用をする
  7. ユーザービリティを大切にする
  8. メインテナンスしやすいコードを書く
  9. どんな言語でもコードが書ける
  10. 基本的なコンピューター・サイエンスの知識を持つ

どんな職業でも1番は重要だと思う。昔から「好きにはかなわない」といわれている。2番も凄く重要で、何事も最後までやり遂げ世に出さなければ、やってないのと/できないのと同じ。3-10はソフトウエア・エンジニアとしての重要な知識・技能・習慣などである。3番から10番に関してどれほどの知識があるか、実際実行しているかによって、ソフトウエア・エンジニアから作りだされるソフトの質に影響してくると思う。

ReadWriteWebで紹介されていた「Software Craftsmanship」は是非読んでみようと思っている。

物の立場にたってデザインする

デザイナーのスピーチを聞いてきたのでその中で重要だと感じた話

デザインをする上で重要な事:

  1. 中身と外見のバランス - 車だったら、エンジンの乗るスペースや、人の乗るスペースと車のデザインのバランスを考えなければならない。機能とのバランスも重要。
  2. 物の立場にたってデザインする - デザインされる物の立場にたって考える事によって、より良いデザインをする事が出来る
  3. デザインはアートではない - アートは自分の作りたいものを作る。デザインは目的を持って作る。

その他にも色々話されていたがこの3つが重要だと感じた。

Ideas are Cheap. Execution is hard.

Ideas are cheap

JoelのForumでも書かれているが、殆どの個人、企業がアイデアを持っていても、実行しないか実行できない。だから実行能力の高い個人、企業は成功する。もう一つ加えると、だからHackerは凄いのである。

カリフォルニアに移って来てからアイデア帳に書き込まれるアイデアの数は増えて来た。特別なアイデアというのはまだないのだが。多分色々な物、情報に触れる機会が増えたので、アイデアを思いつきやすい環境に自分を置けたのだと思う。問題はアイデアを実現する為のExecution(実行)。小さなアイデアでもプライベートの限られた時間に実現しようとするとそれなりに時間がかかる。中サイズのアイデアでも途中で息切れしてしまう。自分自身、Executionは難しいと感ずる今日この頃です。

世界一の研削盤を目指してきたら

世界最大級の望遠鏡レンズを研削でつくるマシンを開発した男たち

パラダイス鎖国 」を読んでから、毎日「パラダイス鎖国」状態を打開する為のソリューションを知らない間に探している。多分答えは一つではなく、様々な答えがあるのだと思う。日経BPで紹介されているナガセインテグレックスの方々が通って来た道が一つの答えとなるのではないか?自分達を信じ、一つの事(研削盤技術)を磨き続け、その世界で一番になる。その磨き上げた技術(力)が、一つのきっかけを通し、世界で認知される技術となった。内容は日経BPを読んでください。ナガセインテグレックスの方々がやってきた事は、日本が得意とする「改善&効率化」であり、「パラダイス鎖国」の中では「改善&効率化」では、現状は打破できないのではないかとの意見もある。しかし、「改善&効率化」を繰り返して行き、臨界点を超えたとき次のステージに到達する事ができるのかも知れない。

自分達、個人個人が、自分を信じ、自分が信じた物を磨いていく事が遠回りのようで、意外と近道だったりするものなのかな?多分、自分達に足りないものは、奇抜なアイデアではなく、自分(達)を信じることなのかもしれない。

最後ににナガセインテグレックスの方の言葉を載せます。

「何にもないところから、世界一になろうとバカみたいに言い続け、本気で信じてやり続けてきた。それが大事。自分が信じなければ、誰も信じてはくれません」

(追記) 自分は大学生時代、機械科だったので、自動化されていない旋盤で、マテリアルの表面を磨いていた経験がかなりある。僕にとって、それはかなりつらい作業だった。ナガセインテグレックスの方々の費やした努力は凄いものである事は簡単に想像できる。言葉で言えば、一行、「旋盤技術を磨いてきた」。でも、その中身は、マテリアルを旋盤に設置し、何度も何度もその表面を磨き、失敗したら、最初からやり直し、その繰り返しを何度何度もやったのだと思う。単調作業もかなりあるだろうし、重労働もかなりあったと思う。そのつらさから逃げなかった、ナガセインテグレックスの方々はかっこ良い。「ものづくり日本大賞」受賞おめでとうございます。

はてなスターをブログに設置

読者が少ないのに、怖いもの見たさで、はてなスターをブログに設置してみた。
設置方法は下記を参照

2007-07-07 はてなスターをブログに設置するには

このブログにはWordpressを使っているのと、Themeがカスタムなので以下の変更が必要だった。

  • タイトルのタグが<h3 class=”h1″>なので下記のラインをheader.phpに追加Hatena.Star.EntryLoader.headerTagAndClassName = [‘h3′,’h1’];
  • もう一つシングルエントリーのケースのタイトルタグは<h1>だったので、メインのタイトルとタグを同じにする為に<h3 class=”h1″>に変更。

またTheme変えてしまいました。
あと、Flickr Badgeもサイドバーに追加

WordPressの2.5へのアップグレード少し待つべきだった

2.5 Comments In Moderation Problem & A Work-around

The Manage/Comments function does not seem to work. I can have a flag on that panel indicating comments awaiting moderation, but they cannot be displayed through the Manage/Comments page, however, I have discovered a work-around. If you are aware that you have received comments that require moderation, you can review each of your recent posts in the Manage/Write Post window, and click on See comments on this post in the sidebar, any published comments or comments awaiting moderation will display. You can then approve the comments awaiting moderation.

Comment Moderation機能に問題があって、Moderationが必要なコメントが表示できない。コメントの内容も確認できない。
自分のブログはポピュラーではないので大きな問題でないのですが。でもやっぱりね、正確に動作してほしい。

今回の反省点として、いくつかのマイナー・アップグレードを待つべきだった。